Fabric中的安全机制（二）

上一次我们从整体的角度讲解了一下Fabric中的安全机制都有哪几个部分，这次我们来具体说一下上次所提及的MSP模型。

MSP模型

MSP主要实现的是在Fabric中的成员管理服务，而且，MSP有以下两种含义：

• MSP首先是一个用于身份认证的核心组件，主要功能有成员身份识别，证书颁发，成员准入，签名加密和证书注销等主要内容。
• 其次，MSP在Fabric中是通过PKI公钥基础设施与数字证书技术来实现Fabric成员身份管理的。而且，一个Fabric框架中的MSP通常不止一个，一些供Orderer节点使用，一些供Peer节点使用。

每一个MSP实例都会有一个特定的命名，比如在Org1中我们可以称之为Org1MSP，这也被称为 MSP标识符 或 MSP ID

Identity

每个MSP成员都被称为一个Identity，Identity表现为一个X509证书，在Fabric中MSP的默认内容如下：

• 1)一个自签名的CA根证书MSP CA Root Cert，用来对MSP成员的证书E-cert进行签名并完成对成员身份的验证；
• 2)一个自签名的用于TSL传输的CA根证书MSP TSL CA Root Cert
• 3)每个MSP成员（组织、Fabric节点、个人、客户端程序）的X509证书都必须被根证书签名
• 4)MSP证书中的OU字段给出了其从属的组织Org
• 5)每个MSP实例都可以拥有一个或多个管理员，管理员可以修改此MSP实例的配置

在增加一个MSP成员时，只要生成一个新的签名证书即可，为此，我们可以使用OpenSSL工具。
或者，使用Fabric中自带的crytogen工具来生成符合要求的MSP证书。MSP成员角色共有四种，分别是Member，Admin，Peer，Client。
在Fabric中对应的源码是：

message MSPRole {
    string msp_identifier = 1;
    enum MSPRoleType {
        MEMBER = 0;
        ADMIN = 1;
        CLIENT = 2;
        PEER = 3;
    }
    MSPRoleType role = 2;
}

其中，ADMIN对应为MSP的管理者，他可以修改MSP的配置信息，CLIENT说明此成员为某个Fabric客户端的程序，PEER说明此证书（成员）对应为某个Fabric Peer节点。
但MEMBER需要好好理解一下,我们可以从源码中获取到一些信息：

switch mspRole.Role {
case m.MSPRole_MEMBER:
    // in the case of member, we simply check
    // whether this identity is valid for the MSP
    mspLogger.Debugf("Checking if identity satisfies MEMBER role for %s", msp.name)
    return msp.Validate(id)
    ...
}

不难看出，一个MSP实例中的任一合法成员都拥有Member角色。
其实，我们在背书策略规则中可以看到以下配置：

OR('Org1.member', 'Org2.member')

上述函数表明请求Org1或者Org2这两个MSP实例中的任一成员对交易提案进行背书签名即可。

MSP证书体系

在Fabric中，CA证书的吊销采用的是在Client端存储一份由CA机构提供的证书吊销列表CRL，在要对某一个成员的证书进行吊销时，将改成员的证书放入CRL中即可收回授权。
一个MSP实例的证书目录结构如下：

• cacerts:PEM格式的MSP的根CA证书目录
• admincerts:MSP的管理员（角色）证书目录，同样为PEM格式
• keystore: 节点的私钥目录，以_sk结尾
• signcerts: 节点Identity的证书，其实就是节点的CA证书，同样是PEM格式
  在Fabric Orderer节点的进程启动参数中，有两个参数用来指定节点的MSP信息：

ORDERER_GENERAL_LOCALMSPID=OrdererMSP;
ORDERER_GENERAL_LOCALMSPDIR=/share/crypto-config/.../msp

不光是Orderer节点，Peer节点也是如此：

CORE_PEER_LOCALMSPID=Org1MSP;
CORE_PEER_MSPCONFIGPATH=/shared/.../msp/

MSP的映射问题

在同属于一个MSP实例下的Peer节点与MSP实例是呈一个一对多关系的，在这个MSP实例的节点中，不同的Peer节点可以相互分享资源，但一个Peer节点只能被一个MSP实例所拥有。
在不同的MSP之间是无法进行资源共享的，但是在同一个通道上的Org1和Org2却是可以交易数据的，但如前面所述，不同的组织之间是不同的MSP实例，和上面所述就会发生冲突，我们在一开始讲过gossip协议，在这个协议当中会通过根据消息中的一个属性来决定如何进行数据的传播，具体定义如下：

UNDEFINED: 未定义
ORG_ONLY: 只在同一个组织内传播
CHAN_ONLY: 只在同一个通道内传播
CHAN_AND_ORG: 同时在同一通道和同一组织内传播
CHAN_OR_ORG: 既可以在同一通道内传播，也可以在同一组织内传播

通过上述的几种定义，我们可以明白，的确有一些消息被限制在同一个组织内进行传播，这样就可以很好的保证组织间的隐私问题，其实，我们还可以将一个组织中的不同部门划分到不同的MSP实例当中，即组织与MSP形成对的关系。

最后还有一种是由一个MSP统一运营多个组织，我们可以认为它们在逻辑上是同属于一个组织的，因此可以将这多个组织同时归到一个MSP实例中进行管理。