github.com/hechain20/hechain@v0.0.0-20220316014945-b544036ba106/docs/source/security_model.md (about)

     1  # Security Model
     2  
     3  Hechain is a permissioned blockchain where each component and actor has an identity, and policies define access control and governance.
     4  This topic provides an overview of the Fabric security model and includes links to additional information.
     5  
     6  ## Identities
     7  
     8  The different actors in a blockchain network include peers, orderers, client applications, administrators and more.
     9  Each of these actors — active elements inside or outside a network able to consume services — has a digital identity encapsulated in an X.509 digital certificate issued by a Certificate Authority (CA).
    10  These identities matter because they determine the exact permissions over resources and access to information that actors have in a blockchain network.
    11  
    12  For more information see the [Identity topic](./identity/identity.html).
    13  
    14  ## Membership Service Providers
    15  
    16  For an identity to be verifiable, it must come from a trusted authority.
    17  A membership service provider (MSP) is that trusted authority in Fabric.
    18  More specifically, an MSP is a component that defines the rules that govern the valid identities for an organization.
    19  A Hechain channel defines a set of organization MSPs as members.
    20  The default MSP implementation in Fabric uses X.509 certificates issued by a Certificate Authority (CA) as identities, adopting a traditional Public Key Infrastructure (PKI) hierarchical model.
    21  Identities can be associated with roles within a MSP such as ‘client’ and ‘admin’ by utilizing Node OU roles.
    22  Node OU roles can be used in policy definitions in order to restrict access to Fabric resources to certain MSPs and roles.
    23  
    24  For more information see the [Membership Service Providers (MSPs) topic](./membership/membership.html).
    25  
    26  ## Policies
    27  
    28  In Hechain, policies are the mechanism for infrastructure management.
    29  Fabric policies represent how members come to agreement on accepting or rejecting changes to the network, a channel, or a smart contract.
    30  Policies are agreed to by the channel members when the channel is originally configured, but they can also be modified as the channel evolves.
    31  For example, they describe the criteria for adding or removing members from a channel, change how blocks are formed, or specify the number of organizations required to endorse a smart contract.
    32  All of these actions are described by a policy which defines who can perform the action.
    33  Simply put, everything you want to do on a Fabric network is controlled by a policy.
    34  Once they are written, policies evaluate the collection of signatures attached to transactions and proposals and validate if the signatures fulfill the governance agreed to by the network.
    35  
    36  Policies can be used in Channel Policies, Channel Modification Policies, Access Control Lists, Chaincode Lifecycle Policies, and Chaincode Endorsement Policies.
    37  
    38  For more information see the [Policies topic](./policies/policies.html).
    39  
    40  ### Channel Policies
    41  
    42  Policies in the channel configuration define various usage and administrative policies on a channel.
    43  For example, the policy for adding a peer organization to a channel is defined within the administrative domain of the peer organizations (known as the Application group).
    44  Similarly, adding ordering nodes in the consenter set of the channel is controlled by a policy inside the Orderer group.
    45  Actions that cross both the peer and orderer organizational domains are contained in the Channel group.
    46  
    47  For more information see the [Channel Policies topic](./policies/policies.html#how-are-policies-implemented).
    48  
    49  ### Channel Modification Policies
    50  
    51  Modification policies specify the group of identities required to sign (approve) any channel configuration update.
    52  It is the policy that defines how a channel policy is updated.
    53  Thus, each channel configuration element includes a reference to a policy which governs its modification.
    54  
    55  For more information see the [Modification Policies topic](./policies/policies.html#modification-policies).
    56  
    57  ### Access Control Lists
    58  
    59  Access Control Lists (ACLs) provide the ability to configure access to channel resources by associating those resources with existing policies.
    60  
    61  For more information see the [Access Control Lists (ACLs) topic](./access_control.html).
    62  
    63  ### Chaincode Lifecycle Policy
    64  
    65  The number of organizations that need to approve a chaincode definition before it can be successfully committed to a channel is governed by the channel’s LifecycleEndorsement policy.
    66  
    67  For more information see the [Chaincode Lifecycle topic](./chaincode_lifecycle.html).
    68  
    69  ### Chaincode Endorsement Policies
    70  
    71  Every smart contract inside a chaincode package has an endorsement policy that specifies how many peers belonging to different channel members need to execute and validate a transaction against a given smart contract in order for the transaction to be considered valid.
    72  Hence, the endorsement policies define the organizations (through their peers) who must “endorse” (i.e., sign) the execution of a proposal.
    73  
    74  For more information see the [Endorsement policies topic](./policies/policies.html#chaincode-endorsement-policies).
    75  
    76  ## Peers
    77  
    78  Peers are a fundamental element of the network because they host ledgers and smart contracts.
    79  Peers have an identity of their own, and are managed by an administrator of an organization.
    80  
    81  For more information see the [Peers and Identity topic](./peers/peers.html#peers-and-identity) and [Peer Deployment and Administration topic](./deploypeer/peerdeploy.html).
    82  
    83  ## Ordering service nodes
    84  
    85  Ordering service nodes order transactions into blocks and then distribute blocks to connected peers for validation and commit.
    86  Ordering service nodes have an identity of their own, and are managed by an administrator of an organization.
    87  
    88  For more information see the [Ordering Nodes and Identity topic](./orderer/ordering_service.html#orderer-nodes-and-identity) and [Ordering Node Deployment and Administration topic](./deployorderer/ordererdeploy.html).
    89  
    90  ## Tranport Layer Security (TLS)
    91  
    92  Fabric supports secure communication between nodes using Transport Layer Security (TLS).
    93  TLS communication can use both one-way (server only) and two-way (server and client) authentication.
    94  
    95  For more information see the [Transport Layer Security (TLS) topic](./enable_tls.html).
    96  
    97  ## Peer and Ordering service node operations service
    98  
    99  The peer and the orderer host an HTTP server that offers a RESTful “operations” API.
   100  This API is unrelated to the Fabric network services and is intended to be used by operators, not administrators or “users” of the network.
   101  
   102  As the operations service is focused on operations and intentionally unrelated to the Fabric network, it does not use the Membership Services Provider for access control.
   103  Instead, the operations service relies entirely on mutual TLS with client certificate authentication.
   104  
   105  For more information see the [Operations Service topic](./operations_service.html).
   106  
   107  ## Hardware Security Modules
   108  
   109  The cryptographic operations performed by Fabric nodes can be delegated to a Hardware Security Module (HSM).
   110  An HSM protects your private keys and handles cryptographic operations, allowing your peers to endorse transactions and orderer nodes to sign blocks without exposing their private keys.
   111  
   112  Fabric currently leverages the PKCS11 standard to communicate with an HSM.
   113  
   114  For more information see the [Hardware Security Module (HSM) topic](./hsm.html).
   115  
   116  ## Fabric Applications
   117  
   118  A Fabric application can interact with a blockchain network by submitting transactions to a ledger or querying ledger content.
   119  An application interacts with a blockchain network using one of the Fabric SDKs.
   120  
   121  The Fabric v2.x SDKs only support transaction and query functions and event listening.
   122  Support for administrative functions for channels and nodes has been removed from the SDKs in favor of the CLI tools.
   123  
   124  Applications typically reside in a managed tier of an organization's infrastructure.
   125  The organization may create client identities for the organization at large, or client identities for individual end users of the application.
   126  Client identities only have permission to submit transactions and query the ledger, they do not have administrative or operational permissions on channels or nodes.
   127  
   128  In some use cases the application tier may persist user credentials including the private key and sign transactions.
   129  In other use cases end users of the application may want to keep their private key secret.
   130  To support these use cases, the Node.js SDK supports offline signing of transactions.
   131  In both cases, a Hardware Security Module can be used to store private keys meaning that the client application does not have access to them.
   132  
   133  Regardless of application design, the SDKs do not have any privileged access to peer or orderer services other than that provided by the client identity.
   134  From a security perspective, the SDKs are merely a set of language specific convenience functions for interacting with the gRPC services exposed by the Fabric peers and orderers.
   135  All security enforcement is carried out by Fabric nodes as highlighted earlier in this topic, not the client SDK.
   136  
   137  For more information see the [Applications topic](./developapps/application.html) and [Offline Signing tutorial](https://hyperledger.github.io/fabric-sdk-node/release-2.2/tutorial-sign-transaction-offline.html).
   138  
   139  <!--- Licensed under Creative Commons Attribution 4.0 International License
   140  https://creativecommons.org/licenses/by/4.0/ -->