Contribuer à GitHub: |

Sécurité

IBM Support for Hyperledger Fabric fournit une plateforme évolutive et hautement fiable qui aide les clients à déployer des applications et des données rapidement et en toute sécurité. Ce document fournit des informations sur la sécurisation de votre instance de service IBM Support for Hyperledger Fabric , où s'exécute la console de blockchain, ainsi que les meilleures pratiques de sécurisation du cluster Kubernetes où les noeuds de blockchain sont déployés.

Sécurité sur la console d'opérations Fabric

Public : les tâches de cette section sont généralement effectuées par les opérateurs réseau de blockchain.

La configuration d'un réseau IBM Support for Hyperledger Fabric inclut le déploiement de la console de blockchain qui peut ensuite être utilisée pour créer des noeuds de blockchain qui résident dans le cluster Kubernetes du client.

Les facteurs suivants doivent être pris en considération :

IAM (Identity and Access Management)
Ports
Gestion des clés
Fournisseur de services aux membres (MSP)
Listes de contrôle d'accès (ACL)
Authentification d'API

IAM (Identity and Access Management)

La gestion des identités et des accès (IAM) permet au propriétaire d'une console de contrôler quels utilisateurs peuvent accéder à la console et quels sont leurs privilèges. IAM est intégré dans la console de blockchain et comprend l'authentification et la gestion des rôles. Lors de la première mise à disposition de la console, vous devez indiquer l'adresse électronique de l'utilisateur désigné comme administrateur de la console, également appelé Responsable. Cet administrateur peut ensuite ajouter et accorder à d'autres utilisateurs l'accès à la console à l'aide de l'onglet Utilisateurs. Il est également possible de modifier l'administrateur de la console. Chaque utilisateur qui accède à la console doit se voir attribuer une règle d'accès pour laquelle un rôle utilisateur est défini. La règle détermine les actions que l'utilisateur peut effectuer sur la console. D'autres utilisateurs peuvent se voir accorder les rôles Gestionnaire, Auteur ou Lecteur lorsqu'un gestionnaire de console les ajoute à la console. La définition de chaque rôle est fournie dans la table de mappage des rôles aux droits d'accès. Pour connaître les étapes requises pour ajouter de nouveaux utilisateurs, voir Gestion des utilisateurs à partir de la console.

Notez que les utilisateurs peuvent également être gérés avec des API.

Ports

Si vous utilisez une application client pour envoyer des demandes à la console, via les API de blockchain ou les SDK Fabric, le port HTTPS (443) standard doit être exposé dans votre pare-feu.

Gestion des clés

Le réseau IBM Support for Hyperledger Fabric est basé sur des identités dignes de confiance. Les clients utilisent les autorités de certification (AC) dans la console pour générer les identités et les certificats associés requis par tous les membres pour effectuer des transactions sur le réseau. Les clés publiques et privées générées sont de type ECDSA avec la courbe P256. Ces clés sont stockées dans le navigateur lorsqu'elles sont ajoutées au portefeuille de blockchain du membre de sorte que la console puisse les utiliser pour gérer les composants de blockchain. Toutefois, il est conseillé aux clients d'exporter ces clés et de les importer dans leur propre système de gestion de clés au cas où ils effaceraient le cache de leur navigateur ou changeraient de navigateur. Les clients sont responsables du stockage, de la sauvegarde et de la reprise après incident de toutes les clés qu'ils exportent.

Etant donné que ces paires de clés publique et privée sont essentielles au fonctionnement d' IBM Support for Hyperledger Fabric , la gestion des clés est un aspect essentiel de la sécurité. Si une clé privée est compromise ou égarée, des acteurs hostiles pourraient accéder aux données et aux fonctionnalités. Bien que vous utilisiez Fabric Operations Console pour générer les certificats et les clés privées, ils ne sont pas définitivement stockés par le navigateur ou la base de données cloud. Les clés publiques et privées sont temporairement stockées dans le navigateur et ajoutées au portefeuille du membre de sorte que la console puisse utiliser la clé privée pour signer numériquement les transactions. Les clients sont finalement responsables de l'exportation des clés et de la gestion de leur stockage, de leur sauvegarde et de leur reprise après incident.

Si une clé privée est perdue et ne peut pas être récupérée, vous devrez générer une nouvelle clé privée en enregistrant et en inscrivant une nouvelle identité avec votre autorité de certification. Vous devez également retirer et remplacer votre certificat signCert dans tous les composants ou organisations dans lesquels vous avez utilisé l'identité perdue ou corrompue. Pour les étapes détaillées, voir Mise à jour d'une définition de MSP d'organisation .

Afin de sécuriser les clés privées dans un environnement de production, IBM Support for Hyperledger Fabric inclut l'option de configuration d'un module HSM (Hardware Security Module) pour générer et stocker les clés privées d'un noeud. Un module HSM est un dispositif matériel facultatif qui effectue des opérations de chiffrement et qui garantit que les clés privées ne quittent jamais le module HSM. Vous êtes responsable de la configuration d'une unité HSM qui implémente la norme PKCS #11. PKCS #11 est une norme cryptographique qui garantit le fonctionnement, la génération et le stockage sécurisés des clés. Voir Configuration du module HSM. La plateforme prend en charge les contrôles cryptographiques ECDSA Sign et Verify et la génération de clé EC. Lorsqu'un module HSM est implémenté pour un noeud, la clé privée du noeud n'est pas stockée dans le portefeuille du navigateur. La clé privée est plutôt accessible à partir du module HSM via le proxy. Lorsque vous enregistrez d'autres identités d'administrateur de noeud ou d'application client auprès d'une autorité de certification à l'aide de la console, leurs clés privées ne sont pas stockées dans le module HSM car elles ont besoin de la clé privée pour effectuer des transactions sur le réseau. Pour des instructions sur l'utilisation de HSM avec IBM Support for Hyperledger Fabric, voir Configuration d'un noeud pour l'utilisation d'un module HSM (Hardware Security Module).

Vous avez également la possibilité d'apporter vos propres certificats à partir de votre propre autorité de certification nonIBM Support for Hyperledger Fabric lorsque vous créez un noeud homologue ou un service de tri. Si vous utilisez vos propres certificats, vous devez générer manuellement le fichier de définition de MSP de service d'homologue ou de tri qui inclut ces certificats et importer le fichier dans l'onglet Organisations de la console. Voir Utilisation de certificats d'une autorité de certification externe avec votre homologue ou noeud de tri pour connaître les étapes requises.

Fournisseur de services aux membres (MSP)

Alors que les autorités de certification génèrent les certificats qui représentent les identités, la transformation de ces identités en rôles dans IBM Support for Hyperledger Fabric s'effectue via la création de fournisseurs de services d'appartenance (MSP) dans la console. Ces MSP, qui sont structurellement constitués de dossiers contenant des certificats, sont utilisés pour représenter des organisations sur le réseau. Chaque organisation aura un et un seul MSP et contiendra toujours au moins un admincert qui identifie un administrateur de l'organisation. Lorsqu'une définition de MSP est associé à un homologue, par exemple, il indique que l'homologue appartient à cette organisation. Plus tard dans le flux pour la création d'un homologue (ou d'un noeud), cette même identité d'administrateur peut être utilisée pour servir en tant qu'administrateur de l'homologue. Pour pouvoir effectuer certaines actions sur un noeud, un rôle d'administrateur est requis. Par exemple, l'installation d'un contrat intelligent sur un homologue nécessite que votre clé publique existe dans le dossier admincerts de la définition de MSP d'organisation de l'homologue, ce qui fait donc de vous un administrateur de l'organisation homologue.

Les MSP identifient également l'autorité de certification racine qui a généré les certificats pour l'organisation et tout autre rôle en plus de l'administrateur associé à l'organisation (par exemple, les membres d'un sous-groupe). Les MSP définissent également la base de définition des privilèges d'accès dans le contexte d'un réseau et d'un canal (par exemple, les administrateurs de canal, les lecteurs, les rédacteurs).

Les dossiers MSP des membres d'organisation sont basés sur une structure définie par Fabric et sont utilisés par les composants Fabric. Pour plus d'informations sur les MSP Fabric et leur structure, voir les rubriques Membership et Membership Service Provider Structure dans la documentation Hyperledger Fabric. L'autorité de certification Fabric établit cette structure en créant les dossiers suivants dans la définition de MSP :

Tableau 1. Dossiers MSP
Nom du dossier MSP	Descriptif
`cacerts`	Contient le certificat de l'autorité de certification racine de votre réseau.
`intermediatecerts`	Il s'agit des certificats des autorités de certification intermédiaires de votre chaîne de confiance (qui renvoient à une autorité de certification racine ou à plusieurs autorités de certification). Etant donné que les autorités de certification intermédiaires ne sont actuellement pas prises en charge par IBM Support for Hyperledger Fabric, cette zone est vide.
`keystore`	Contient la clé privée qui a été générée avec votre clé publique. Cette clé est utilisée pour générer des signatures en créant un hachage cryptographique qui peut être vérifié à l'aide de la clé publique connue des autres utilisateurs. Cette clé n'est jamais partagée et vous êtes responsable de la sécuriser et de la gérer. Si cette clé est compromise, elle peut être utilisée pour usurper votre identité. Il est donc essentiel de la garder en sécurité.
`signCerts`	Contient la clé publique qui a été générée avec votre clé privée. Elle est également appelée "certificat signataire" car elle est utilisée pour vérifier les signatures générées par d'autres utilisateurs.
De nombreux composants Fabric contiennent des informations supplémentaires dans leur dossier MSP. Par exemple, un homologue inclut les dossiers suivants :
`admincerts`	Contient les certificats d'administration de cette organisation ou composant.
`tls`	Contient les certificats TLS que vous stockez pour communiquer avec d'autres composants du réseau.

Notez que les MSP d'organisation sont stockés dans la mémoire du navigateur et doivent être exportés vers un système de fichiers local et sécurisés par le client.

Listes de contrôle d'accès (ACL)

Hyperledger Fabric permet un contrôle plus fin sur l'accès utilisateur à des ressources spécifiées via l'utilisation de listes de contrôle d'accès (ACL). Les ACL permettent de limiter l'accès à une ressource de canal à une organisation et à un rôle au sein de cette organisation. L'ensemble de listes de contrôle d'accès disponibles provient de l'architecture Fabric sous-jacente et est sélectionné lors de la création ou de la mise à jour du canal. Notez que les listes de contrôle d'accès sont restrictives, au lieu d'être additives. Si l'accès à une ressource est spécifié pour une organisation, cela signifie que seule cette organisation aura accès à la ressource. Par exemple, si l'accès par défaut à une ressource spécifique est le lecteur de toutes les organisations et que l'accès est remplacé par Admin de Org1, seul Admin de Org1 aura accès à la ressource. Comme l'accès à certaines ressources est essentiel au bon fonctionnement d'un canal, il est fortement recommandé de prendre des décisions de contrôle d'accès avec précaution. Si vous décidez de limiter l'accès à une ressource, assurez-vous que l'accès à cette ressource est ajouté, si nécessaire, pour chaque organisation.

Vous pouvez utiliser la console blockchain pour sélectionner les ACL à appliquer aux ressources d'un canal. Pour savoir comment configurer le contrôle d'accès d'un canal, voir Création d'un canal .

Authentification d'API

Afin d'utiliser les API de blockchain pour créer et gérer des composants réseau, votre application doit pouvoir s'authentifier et se connecter à votre réseau. Pour plus de détails, voir Connexion à votre console à l'aide de clés d'API .

Pratiques recommandées pour la sécurité sur le cluster Kubernetes client

Public : les tâches de cette section sont généralement exécutées par les gestionnaires d'infrastructure Kubernetes.

La console Fabric Operations Console vous permet de déployer et de gérer des noeuds sur un cluster Kubernetes que vous utilisez. La section précédente traite de la sécurité de la console. Les sections suivantes décrivent les meilleures pratiques que vous pouvez utiliser pour sécuriser votre cluster Kubernetes et les noeuds de votre réseau :

Sécurité du cluster Kubernetes
Sécurité des réseaux
Cluster et système d'exploitation (OS)
Clés et informations d'accès au cluster
Fournisseur de services aux membres (MSP)
Stockage
Confidentialité des données
RGPD

Sécurité du cluster Kubernetes

Le meilleur point de départ est de vous familiariser avec les fonctions de sécurité de l'infrastructure Kubernetes sous-jacente. La documentation open source fournit un examen des pratiques recommandées pour la sécurisation d'un cluster Kubernetes.

Pour plus d'informations sur la sécurité d' OpenShift Container Platform , consultez le manuel Red Hat Container Security Guide Service. Vous devrez utiliser des contraintes de contexte de sécurité (SCC) pour définir un ensemble de conditions avec lesquelles un pod doit s'exécuter afin d'être accepté dans le système. Des détails sont inclus dans les instructions de déploiement d' IBM Support for Hyperledger Fabric .

Si vous utilisez Azure Kubernetes Service, Amazon Elastic Kubernetes Serviceou IBM Kubernetes Service, vous devez configurer le contrôleur NGINX Ingress qui doit être en cours d'exécution dans Mode passe-système SSL

Sécurité des réseaux

Kubernetes Container Platform fournit le réseau sous-jacent, y compris les réseaux et les routeurs sur lesquels réside le réseau local virtuel du client. Le client doit configurer ses serveurs et utiliser des passerelles et des pare-feux pour acheminer le trafic entre les serveurs afin de protéger les charges de travail face aux menaces du réseau. Il est impératif de protéger votre réseau de cloud en utilisant des pare-feux et des périphériques de prévention contre les intrusions pour protéger vos charges de travail basées sur le cloud.

Sécurité du cluster et du système d'exploitation

Données sensibles : les données de configuration de cluster sont stockées dans le composant etcd de votre maître Kubernetes. Les données de etcd sont stockées sur le disque local du maître Kubernetes et sont sauvegardées sur IBM Cloud Object Storage. Les données sont cryptées lors de leur transmission à IBM Cloud Object Storage. Si vous utilisez OpenShift,, vous pouvez choisir d'activer le chiffrement de vos données etcd sur le disque local de votre maître Kubernetes en chiffrant les données au niveau du datastore de votre cluster.
UBI Linux: Les images Fabric Docker utilisent des Red Hat UBI, qui est une version plus petite, plus légère et plus sécurisée de Linux.

Clés et informations d'accès au cluster

Tableau 2. Types de clés et d'informations utilisés pour accéder au cluster Kubernetes du client
Type	Descriptif	Stockage	Accès
Informations sur l'accès au cluster Kubernetes du client	Pour que les composants de service accèdent et gèrent les composants qui sont déployés dans ce cluster, les composants de service génèrent un secret Kubernetes pour l'accès au cluster . Chaque secret Kubernetes est lié à ce cluster client spécifique.	Après génération, ces secrets ne quittent jamais le cluster IBM Kubernetes où les composants du service sont en cours d'exécution et sont supprimés chaque fois qu'un client supprime le cluster associé.	Accès uniquement par le code de composant de service et uniquement en réponse aux demandes des clients de déployer ou de gérer des composants via la console blockchain. Les développeurs du service n'ont pas accès aux informations des secrets.

Fournisseur de services aux membres (MSP)

Les organisations d'un réseau de blockchain sont représentées par des définitions MSP . Vous pouvez utiliser la console blockchain pour ajouter une nouvelle organisation au réseau en créant une nouvelle définition de MSP dans l'onglet Organisations. Si vous êtes administrateur d'un service de tri, vous pouvez utiliser la console pour ajouter cette organisation MSP à un consortium à l'aide de l'onglet Service de tri. Enfin, si vous êtes administrateur d'un canal, vous pouvez ajouter cette organisation à un canal existant afin que l'organisation puisse effectuer des transactions sur le réseau à l'aide de l'onglet Canaux (cette tâche peut nécessiter la signature d'autres organisations). Voir la rubrique Rejoindre le consortium hébergé par le service de tri pour les étapes détaillées.

Stockage

Lorsque la console de blockchain déploie un noeud, le stockage est mis à disposition de manière dynamique à partir de la classe de stockage par défaut pour ce noeud du stockage permanent. Vous avez la possibilité de chiffrer le volume persistant, mais le chiffrement peut avoir certaines incidences sur les performances.

Les clients sont responsables du chiffrement de leur propre stockage. Ce chiffrement doit avoir lieu avant le déploiement des composants de blockchain dans le cluster.

Pour plus d'informations sur la sécurisation de votre stockage persistant sur OpenShift, voir ce sujet sur Sécurité des volumes.

Protection des données

Lorsque vous avez des exigences en matière de confidentialité des données, les collections de données privées permettent d'isoler davantage des données spécifiques du reste des membres du canal. La combinaison de l'utilisation de canaux et de données privées offre diverses solutions pour atteindre l' Hébergement de données.

Sécurité Hyperledger Fabric

Etant donné que IBM Support for Hyperledger Fabric est basé sur Hyperledger Fabric, vous pouvez tirer parti des fonctions sécurisées incluses dans un réseau Fabric.

Communications TLS v1.2 : TLS est intégré dans le modèle de confiance de Hyperledger Fabric. Par défaut, TLS côté serveur est activé pour toutes les communications utilisant des certificats TLS. TLS est utilisé pour chiffrer la communication entre vos noeuds et entre vos noeuds et vos applications. TLS empêche les attaques Man-in-the-Middle (MiTM) et de détournement de session. Tous les composants IBM Support for Hyperledger Fabric utilisent TLS pour communiquer entre eux.
Intégrité des transactions : Fabric utilise la norme ECDSA cryptographique pour garantir l'intégrité des transactions. Avec ECDSA, l’initiateur de la transaction, telle qu’une application client, signe son message à l’aide de sa clé privée, et le destinataire, tel qu'un homologue, utilise la clé publique de l’initiateur pour vérifier l’authenticité du message. Si une transaction est altérée en cours de route vers le destinataire, la vérification de la signature échoue.
Canaux : bien que les canaux Fabric constituent un mécanisme puissant pour le partitionnement et l'isolement des données, ils constituent également le fondement principal de la confidentialité des données. Seuls les membres du même canal peuvent accéder aux données de ce canal. Pour garantir la sécurité des canaux, la stratégie de mise à jour de configuration de canal est configurée pour définir le nombre d'opérateurs de canal devant se mettre d'accord sur la demande de mise à jour de canal afin que l'opération soit effectuée. Par conséquent, un processus clair doit exister pour définir les organisations autorisées à rejoindre et mettre à jour le canal.
Données de registre : une notion implicite dans le réseau autorisé par blockchain est qu'une politique convenue de plusieurs valideurs est nécessaire pour signer (approuver) une transaction avant de pouvoir la valide dans le registre. Avant de pouvoir ajouter des informations au registre, un processus clair et bien établi permettant de définir les informations du registre doit exister. Les données du registre sont immuables.
Contrats intelligents : tous les contrats intelligents doivent être examinés par les membres du canal avant d'être installés et exécutés sur des homologues de leur organisation. De même, toutes les mises à jour du contrat intelligent doivent être examinées avant d'être appliquées à un homologue. Consultez la rubrique Mise à niveau d'un contrat intelligent pour connaître les étapes requises.
Intégration du module HSM : après avoir configuré un module HSM pour votre environnement, vous avez la possibilité de configurer vos noeuds de sorte qu'ils utilisent le module HSM pour générer et stocker des clés privées. Pour plus d'informations, voir Configuration d'une autorité de certification, d'un homologue ou d'un noeud de tri pour utiliser le module HSM .

Activer la règle réseau

L'activation de la règle réseau s'effectue automatiquement lors de la création de la console. Dans la spécification de déploiement d'opérateur, l'opérateur doit ajouter une variable d'environnement IBPOPERATOR_CONSOLE_APPLYNETWORKPOLICY et définir sa valeur sur true.

kubectl edit deploy ibp-operator -n <offering-namespace>

Dans la section relative à l'environnement sous spec.containers, ajoutez ce qui suit:

- name: IBPOPERATOR_CONSOLE_APPLYNETWORKPOLICY
   value:"true"

Lorsque l'option est activée, l'opérateur installe 2 règles réseau lors de l'installation de la console. Ces règles réseau sont destinées à fournir un mécanisme de sécurité défensive de base et n'ouvrent que les ports utilisés par l'offre. Il ne s'agit en aucun cas d'une règle qui peut remplacer un pare-feu. Les politiques appliquées fournissent une sécurité entrante, car le réseau de blockchain peut avoir besoin d'appeler des serveurs npm, gradle, maven pour obtenir des modules de code blockchain ainsi que pour communiquer avec les services de tri / peers/applications s'exécutant en dehors du cluster sur Internet, nous ne fournissons pas de politiques de sortie.

Voici les deux politiques que nous appliquons:

Refus de toutes les entrées.

Cette politique refuse tout le trafic réseau entrant (ingress: []) aux pods (podSelector: {}) dans l'espace de nom auquel elle s'applique. Cela garantit que seuls les trafics nécessaires sont transités.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: networkpolicy-denyall
  namespace: <>
  labels:
    type: "ibm-hlfsupport-console"
    app.kubernetes.io/name: "ibm-hlfsupport"
    app.kubernetes.io/instance: "ibm-hlfsupport-console"
    app.kubernetes.io/managed-by: "ibm-hlfsupport-operator"
    release: "operator"
    helm.sh/chart: "ibm-hlfsupport"
spec:
  podSelector: {}
  ingress: []

Entrée.

Cette règle réseau d'entrée s'applique au trafic réseau provenant de n'importe où (from: []). Elle s'applique à tous les pods qui libellés app.kubernetes.io/name: "ibm-hlfsupport" qui sont tous les pods liés à l'offre. Cette règle ouvre uniquement les ports requis pour les composants de blockchain et la console de gestion disponible de l'extérieur pour qu'ils se connectent les uns aux autres.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: networkpolicy-ingress
  labels:
    type: "ibm-hlfsupport-console"
    app.kubernetes.io/name: "ibm-hlfsupport"
    app.kubernetes.io/instance: "ibm-hlfsupport-console"
    app.kubernetes.io/managed-by: "ibm-hlfsupport-operator"
    release: "operator"
    helm.sh/chart: "ibm-hlfsupport"
spec:
  ingress:
  - from: [] # everywhere
    ports:
    - port: 7051 # peer-api
      protocol: TCP
    - port: 9443 # peer-operations / ca-operations
      protocol: TCP
    - port: 7443 # peer-grpcweb / orderer-grpcweb
      protocol: TCP
    - port: 7052
      protocol: TCP # peer-chaincode
    - port: 3000 # optools
      protocol: TCP
    - port: 7050 # orderer-grpc
      protocol: TCP
    - port: 8443 # orderer-operations
      protocol: TCP
      - port: 22222 # fileserver #check install/invoke chaincode
      protocol: TCP
    - port: 11111 # grpc #check install/invoke chaincode
      protocol: TCP
    - port: 7054 # ca
      protocol: TCP
  podSelector:
    matchLabels:
      app.kubernetes.io/name: "ibm-hlfsupport"
  policyTypes:
    - Ingress

Sécurité

Sécurité sur la console d'opérations Fabric

IAM (Identity and Access Management)

Ports

Gestion des clés

Fournisseur de services aux membres (MSP)

Listes de contrôle d'accès (ACL)

Authentification d'API

Pratiques recommandées pour la sécurité sur le cluster Kubernetes client

Sécurité du cluster Kubernetes

Sécurité des réseaux

Sécurité du cluster et du système d'exploitation

Clés et informations d'accès au cluster

Fournisseur de services aux membres (MSP)

Stockage

Protection des données

RGPD

Sécurité Hyperledger Fabric

Activer la règle réseau