Hyperledger Fabric Composer - restriction des droits d'accès des administrateurs système

Question

Ma question porte sur le contrôle d'accès dans hyperledger fabric composer.

Supposons que vous disposez d'un réseau d'entreprises, dans lequel se trouvent les participants suivants :

1. Vendeurs
2. Acheteurs (potentiels)

Un vendeur est un employé d'une entreprise qui vend des produits à une entreprise acheteuse. Un acheteur est un employé d'une entreprise acheteuse.

Exemple : L'entreprise acheteuse est Daimler. Trois employés de Daimler sont enregistrés comme acheteurs dans le réseau. L'entreprise vendeuse est General Electric. Deux employés de General Electric sont enregistrés comme vendeurs dans le réseau.

Grâce au langage de contrôle d'accès d'Hyperledger Composer, il est possible de restreindre à volonté les droits d'accès des acheteurs et des vendeurs.

Mais qu'en est-il du contrôle d'accès au niveau des nœuds ?

Il n'y a pas seulement des acheteurs et des vendeurs mais aussi deux administrateurs système : un administrateur système responsable du pair Daimler et un administrateur système responsable du pair General Electric.

Par défaut, les administrateurs du système ont accès à toutes les données. Autrement dit, l'administrateur système de Daimler a accès à toutes les données des employés enregistrés de General Electric. Vice versa, l'administrateur système de General Electric a accès à toutes les données des employés enregistrés de Daimler.

Est-il possible de limiter l'accès des administrateurs du système à une poignée de droits, tels que :

1. droit d'installer et de démarrer le réseau d'entreprises
2. le droit de contrôler les modifications apportées au système par l'autre administrateur du système (par exemple, si l'administrateur du système Daimler modifie le code de l'application, l'administrateur General Electric doit approuver ces modifications avant qu'elles ne soient effectives)
3. Accès en lecture aux employés de sa propre entreprise

Answer 1

L'accès à un tissu hyperledger (pour tout ce qui inclut l'interaction avec un réseau d'entreprise) est géré par les MSP du tissu hyperledger. Hyperledger fabric, dans le cadre de la mise en place du réseau et des canaux hyperledger fabric, définit quelles identités (créées via les MSP) ont l'autorité pour installer le chaincode sur les pairs et quelles identités ont l'autorité sur les canaux, pour pouvoir instancier ou mettre à niveau le chaincode. Il est possible de restreindre l'installation sur les pairs et l'instanciation/mise à niveau des canaux à des identités spécifiques. Des informations sur les Hyperledger fabric MSPs par exemple peuvent être trouvées à ce lien https://hyperledger-fabric.readthedocs.io/en/release-1.2/msp.html mais vous voudrez probablement être familier avec la section complète des opérations dont cette section fait partie.

Le contrôle d'accès dans Composer se fait via les participants et le fichier ACL du réseau d'entreprise. Vous contrôlez quels participants peuvent effectuer diverses actions sur les ressources contrôlées par le runtime Composer. Vous avez besoin d'une identité (générée par votre MSP) afin de pouvoir interagir sur un canal/un code de chaîne (comme l'exige Hyperledger Fabric). Cette identité doit être préalablement associée à un participant spécifique afin de pouvoir interagir sur le réseau d'entreprise. Lorsqu'une demande est envoyée à un réseau d'entreprise, le compositeur recherche ce participant spécifique sur la base de l'identité qui a fait la demande et utilise ce participant et son type pour déterminer, grâce aux informations du fichier ACL du réseau d'entreprise, ce qu'il est autorisé à faire.

Notez que des choses comme l'installation de Peer, l'instanciation/la mise à niveau du chaincode sont une capacité au niveau du tissu, et non une capacité du compositeur. Vous ne pouvez donc pas contrôler ces types d'activité par le biais des définitions ACL du compositeur.