Hyperledger Fabric译文之Membership Service Providers (MSP)

英文原址:http://hyperledger-fabric.readthedocs.io/en/latest/msp.html

Membership Service Providers (MSP)

该文档用于提供有关MSP设置和最佳做法的详细信息。

会员服务提供商(MSP)是旨在提供会员操作架构抽象的组件。

特别地,MSP抽取出发布和验证证书以及用户认证背后的所有加密机制和协议。MSP可以定义自己的身份概念,以及这些身份管理的规则(身份验证)和身份验证(签名生成和验证)。

Hyperledger Fabric区块链网络可由一个或多个MSP共同管理。这提供了会员操作的模块化,以及跨不同会员标准和架构的互操作性。

在本文档的其余部分,我们详细阐述Hyperledger Fabric支持的MSP的设置,并讨论了有关其使用的最佳实践。

MSP配置

要设置MSP的实例,需要在本地指定每个peer和orderer(启用peer和orderer签名)的配置,并在通道上启用peer,orderer,客户端身份验证和所有channel成员的各自的签名验证(认证)。

首先,对于每一个MSP需要指定一个可以在网络中引用的名称(例如msp1,org2和org3.divA)。这个名称可以在channel中引用并遵循联盟,组织或组织部门的MSP的会员规则。这也称为MSP标识符或MSP ID。对于每个MSP实例,MSP标识符必须是唯一的。例如,具有相同标识符的两个MSP实例在系统channel原始快中时被检测到时,orderer设置将失败。

在MSP的默认实现的情况下,需要指定一组参数以允许身份(证书)验证和签名验证。这些参数由RFC5280推导出来 ,包括:

  • 构成信任根源的自签名(X.509)证书列表
  • X.509证书列表,用于表示提供商认证用于证书验证的中间CA; 这些证书应该通过信托根源中的一个证书进行认证; 中间CA是可选参数
  • 具有可验证证书路径的X.509证书列表,以正确的信任根证书之一代表该MSP的管理员; 这些证书的所有者有权要求更改此MSP配置(例如,根CA,中间CA)
  • 该MSP的有效成员的组织单位列表应包括在其X.509证书中; 这是一个可选的配置参数,当例如多个组织利用相同的信任根和中间CA时使用,并为其成员保留了OU字段
  • 与列出的 (中间或根) MSP 证书颁发机构中的一个完全对应的证书吊销列表(CRLs); 这是一个可选参数
  • 自签名(X.509)证书的清单,构成TLS证书的TLS信任根源
  • X.509证书的列表,用于表示提供商认为的中间TLS CA; 这些证书应该通过TLS信托根源中的一个证书进行认证; 中间CA是可选参数。

MSP实例的有效身份需要满足以下条件:

  • 它们是X.509证书的形式,具有可信证书路径,恰好是信任证书根目录之一
  • 它们不包括在任何CRL中
  • 他们在X.509证书结构领域中列出了一个或多个MSP配置的中OU字段对应的组织单位

有关当前MSP实现中身份有效性的更多信息,请参阅读者MSP身份验证规则。

除了验证相关参数之外,为使MSP启用实例化的节点进行签名或认证,需要指定:

  • 用于由节点签名的签名密钥(目前仅支持ECDSA密钥)
  • 该节点的X.509证书,该MSP的验证参数下的有效身份

重要的是要注意,MSP身份永远不会过期; 它们只能通过将其添加到适当的CRL来撤销。此外,目前不支持强制撤销TLS证书。

如何生成MSP证书及其签名密钥?

要生成X.509证书以满足其MSP配置,应用程序可以使用Openssl。我们强调,在Hyperledger Fabric中,不支持包括RSA密钥在内的证书。

或者,可以使用cryptogen工具,其操作在入门中有说明 。

Hyperledger Fabric CA 也可用于生成配置MSP所需的密钥和证书。

MSP设置peer和orderer

要设置本地MSP(对于peer或orderer),管理员应创建一个包含六个子文件夹和文件的文件夹(例如$MY_PATH/mspconfig):

  1. 一个文件夹admincerts,其中包括对应于管理员证书的PEM文件
  2. 一个文件夹cacerts,其中包括对应于根CA证书的PEM文件
  3. (可选)一个文件夹intermediatecerts,其中包括每个对应于CA中间证书的PEM文件
  4. (可选) 文件config. yaml 包括被考虑的 ou 的信息;后者被定义为称为 OrganizationalUnitIdentifiers 的 yaml 数组的 项的对, 其中证书表示证书颁发机构证书的相对路径 (根目录或中级), 应考虑为本组织单位的成员 (如/cacerts/cacert. pem), 和 OrganizationalUnitIdentifier 代表的实际字符串预计将出现在 x 509 证书 OU 字段 (如 “COP”)
  5. (可选)一个文件夹,crls以包括所考虑的CRL
  6. 一个文件夹keystore包含节点签名密钥的PEM文件; 我们强调目前不支持RSA密钥
  7. 一个文件夹signcerts包含节点的X.509证书的PEM文件
  8. (可选)一个文件夹,tlscacerts以包含每个对应于TLS根CA证书的PEM文件
  9. (可选)一个文件夹,tlsintermediatecerts以包含每个对应于中间TLS CA证书的PEM文件

在节点的配置文件(peer对应的是core.yaml文件和orderer对应的是orderer.yaml)中,需要指定mspconfig文件夹的路径和节点MSP的MSP标识符。mspconfig文件夹的路径被预期和FABRIC_CFG_PATH相关和作为peer的mspConfigPath的参数值,以及orderer的LocalMSPDir 参数值。节点MSP的标识符用来作为peer的参数localMspId以及order的参数LocalMSPID对应的值。 这些变量可以通过环境变量进行覆盖,如通过peer的CORE前缀(例如CORE_PEER_LOCALMSPID)和订单的ORDERER前缀(例如ORDERER_GENERAL_LOCALMSPID)。请注意,对于orderer的设置,需要生成一个提供给orderer的系统channel的原始块。下一节将详细介绍该块的MSP配置需求。

“本地”MSP的重新配置只能手动进行,并且要求peer或orderer进程重新启动。在后续版本中,我们旨在提供在线/动态重新配置(如不需要停止节点,而是通过使用节点管理的系统链码来操作)。

Channel MSP设置

在系统的起源上,需要指定网络中出现的所有MSP的验证参数,并将其包含在系统channel的原始块中。回想一下,MSP验证参数由MSP标识符,信任的根证书,中间CA和管理证书以及OU规范和CRL组成。系统原始块在其设置阶段提供给orderer,并允许它们验证通道创建请求。如果系统原始块中包含两个具有相同标识符的MSP,则orderer拒绝该系统原始块,并且因此网络的启动将失败。

对于应用渠道,仅管理channel的MSP的验证组件需要驻留在channel的起源块中。我们强调应用程序的责任是在一个或多个peer加入该channel之前,确保正确的MSP配置信息被包含在channel的起源块(或最新配置块)中。

在通过configtxgen工具的帮助下引导通道时,可以通过在mspconfig文件夹中包含MSP的验证参数来配置通道MSP ,并在configtx.yaml相关部分中设置该路径。

在通道上重新配置 msp, 包括与该 msp 的 ca 相关的证书吊销列表的公告, 是通过 msp 的一个管理员证书的所有者创建一个 config_update 对象来实现的。管理员管理的客户端应用程序随后将向此 MSP 出现的通道发布此更新。

最佳实践

在本节中,我们详细介绍常见场景中MSP配置的最佳实践。

1)组织/公司和MSP之间的映射

我们建议组织和MSP之间存在一对一的映射。如果选择不同的映射类型的映射,则需要考虑以下内容:

  • 一个组织采用多种MSP
    这对应于一个组织的情况, 其中包括由其 MSP 代表的各种部门, 无论是出于管理独立原因, 还是出于隐私原因。在这种情况下, peer只能由单个 MSP 拥有, 并且不会识别来自其他项目的对等点作为同一组织的对等节点。这意味着,peer可以通过八卦组织范围内的数据与一组同级成员共享, 而不是由构成实际组织的全套提供者组成。
  • 使用单个MSP的多个组织
    这对应于由类似会员架构管理的组织联盟的情况。在这里需要知道的是,peers将组织范围的信息传播给具有同一个MSP身份的peer,而不管它们是否属于同一个实际组织。这是MSP定义的粒度或peer的配置的限制。

2)一个组织有不同的部门(称组织单位), 它要向其授予对不同channel的访问权限。

两种处理方法:

  • 定义一个MSP以适应所有组织成员的成员资格
    该MSP的配置将包括根CA列表,中间CA和管理员证书; 会员身份将包括OU会员所属的组织单位。然后可以定义策略以捕获特定的成员OU,并且这些策略可以构成channel的读/写策略或chaincode的背书策略。这种方法的限制是,八卦peer将考虑具有其本地MSP下的成员资格身份的peer作为同一组织的成员,并且因此将其与组织范围的数据(例如他们的状态)进行闲话。
  • 定义一个MSP来表示每个部门
  • 这将涉及为每个部门指定一组根CA,中间CA和管理证书的证书,以便跨MSP不存在重叠的认证路径。这意味着,例如,使用每个细分的不同的中间CA。这里的缺点是管理多个MSP而不是一个MSP,但这避免了以前的方法中存在的问题。还可以通过利用MSP配置的OU扩展来为每个部门定义一个MSP。

3)将客户端与同一组织的peers分开。

在许多情况下, 需要将身份的 “类型” 从身份本身中检索出来(例如,可能需要认可的签名保证由peer派生,而不是仅充当 orderers 的客户端或节点)。

对这些要求的支持有限。

允许这种分离的一种方法是为每个节点类型创建一个单独的中间CA - 一个用于客户端,一个用于peer/orderer; 并配置两个不同的MSP - 一个用于客户端,一个用于peer/orderer。该组织应该访问的channel将需要包括两个MSP,而背书政策将仅利用peer的MSP。这将最终导致组织被映射到两个MSP实例,并将对peer和客户端交互的方式产生一定的后果。

八卦不会受到同样的组织的所有同行仍然属于一个MSP的严重影响。peer可以基于本地MSP的策略限制某些系统chaincode的执行。例如,如果请求由其本地MSP的管理员签名,而该管理人员只能是客户端(最终用户应该位于该请求的起点),peer将仅执行“joinChannel”请求。我们可以解决这个不一致的情况,如果我们接受只有作为peer/orderer MSP的成员的客户才是MSP的管理员。

使用这种方法考虑的另一点是,peer根据其本地MSP中的请求发起者的成员身份来授权事件注册请求。显然,由于请求的发起者是客户端,请求发起者始终注定属于与请求的peer不同的MSP,并且peer将拒绝该请求。

4)管理员和CA证书。

必须将 msp 管理证书设置为与 msp 为信任根或中间 ca 所考虑的任何证书不同。这是一种常见的 (安全) 做法, 即将成员资格组件的管理职责与颁发新证书和/或对现有认证的验证分开。

5)将中间CA列入黑名单

如前面部分所述,通过重新配置机制(手动重新配置本地MSP实例,以及适当构造用于channel的MSP实例的config_update信息)来实现MSP的重新配置。显然,有两种方法可以确保在MSP中考虑的中间CA不再被认为是MSP的身份验证:

  1. 将MSP重新配置为不再将该中间CA的证书包含在可信中间CA证书列表中。对于本地配置的MSP,这意味着该CA的证书将从intermediatecerts文件夹中删除。
  2. 重新配置MSP来包括由信任根产生的CRL,该CRL会声明提及的中间CA的证书。

在目前的MSP实现中,我们只支持方法(1),因为它更简单,不需要将不再考虑的中间CA列入黑名单。

6)CAs和TLS CAs

MSP身份的根CA和MSP TLS证书的根CA(和相对中间CA)需要声明在不同的文件夹中。这是为了避免不同类别的证书之间的混淆。这里不禁止MSP身份和TLS证书重复使用相同的CA,但是最佳做法建议在生产环境中避免这种情况。

你可能感兴趣的:(Hyperledger,Fabric,Hyperledger,Fabric)