12.4 权限管理和策略

权限管理是联盟链中十分重要的功能，一般要解决谁（身份）在某个场景（条件）下是否允许采取某个操作（行动）的问题。

超级账本Fabric项目通过策略（policy）来指定和实现网络中的各种场景下的权限限制。

12.4.1　策略应用场景

常见的策略场景包括10种情况，总结如表12-3所示。其中，大部分都与系统配置链码相关。

表12-3　常见的策略场景

12.4.2　身份证书

执行策略检查的基础是身份证书机制。

通过基于PKI的成员身份管理，Fabric网络可以对接入的节点和用户的各种能力进行限制。

Fabric设计中考虑了三种类型的证书：登记证书（Enrollment Certificate）、交易证书（Transaction Certificate），以及保障通信链路安全的TLS证书。证书的默认签名算法为ECDSA，Hash算法为SHA-256：

·登记证书（ECert）：颁发给提供了注册凭证的用户或节点等实体，一般长期有效；

·交易证书（TCert）：颁发给用户，控制每个交易的权限，一般针对某个交易，短期有效；

·通信证书（TLSCert）：控制对网络层的接入访问，可以对远端实体身份进行校验，防止窃听。

目前，在实现上，主要通过ECert来对实体身份进行检验，通过检查签名来实现权限管理。TCert功能暂时未启用。

12.4.3　权限策略的实现

权限策略，负责对通道内数据的各种操作权限进行管理。一般包括对读身份（Readers，例如获取通道的交易、区块等数据）、写身份（Writers，例如向通道发起交易）、管理员身份（Admins，例如加入通道、修改通道的配置信息）等权限进行限制。

操作者通过签名组合满足了指定的规则，则证明拥有了对应的权限身份，允许执行相应的操作。

1.数据结构

实现上，每种策略结构都要实现Evaluate（signatureSet[]*cb.SignedData）error方法。该方法中会对于给定的一组签名数据，按照一定规则对它们进行检验，看是否符合约定的条件。符合则说明满足了该策略。

图12-19　策略相关的数据结构

策略相关的数据结构定义在protos/common/policies.proto文件中，其中主要包括 Policy、SignaturePolicyEnvelope（内嵌SignaturePolicy结构）和ImplicitMetaPolicy三种 数据结构，如图12-19所示。

Policy消息的定义如下。

---

message Policy {
   enum PolicyType {
       UNKNOWN = 0;    // 初始化保留类型
       SIGNATURE = 1;
       MSP = 2;
       IMPLICIT_META = 3;
   }
   int32 type = 1;     // 类型
   bytes value = 2;    // 规则
}

---

其中，PolicyType的数值代表策略的类型，具体含义为：

·0：表示UNKNOWN，保留值，用于初始化；

·1：表示SIGNATURE，代表策略指定必须要匹配签名的组合，如某个MSP中至少三个签名；

·2：表示MSP，代表策略必须要匹配某MSP下的指定身份身份，如MSP的管理员身份；

·3：表示IMPLICIT_META，表示隐式类型规则。该类规则需要对策略域下子策略进行检查，并通过Rule来指定具体的规则，包括ANY、ALL、MAJORITY三种：

·ANY：满足任意子组的对应策略；

·ALL：满足所有子组的对应策略；

·MAJORITY：满足过半子组的对应策略。

目前已经实现支持的策略类型包括SignaturePolicy和ImplicitMetaPolicy两种。

2.SIGNATURE策略

SIGNATURE策略指定通过签名来对数据进行认证，例如数据必须满足一定的签名身份组合。

相关数据结构主要包括SignaturePolicy消息体和封装后使用的SignaturePolicyEnvelope，两者定义如下所示。

---

message SignaturePolicy {
   message NOutOf {
       int32 n = 1;
       repeated SignaturePolicy rules = 2;
   }
   oneof Type {
       int32 signed_by = 1;
       NOutOf n_out_of = 2;
   }
}

type SignaturePolicyEnvelope struct {
   Version    int32  `protobuf:"varint,1,opt,name=version" json:"version,omitempty"`
   Rule     *SignaturePolicy `protobuf:"bytes,2,opt,name=policy" json:"policy,
       omitempty"`
   Identities []*common1.MSPPrincipal `protobuf:"bytes,3,rep,name=identities" json:
       "identities,omitempty"`
}

---

其中，SignaturePolicy结构体代表了一个策略的具体内容。支持指定某个特定签名，或者满足给定策略集合中的若干个（NOutOf）即可。NOutOf用法十分灵活，基于它可以递归地构建任意复杂的策略语义，指定多个签名规则的与、或组合关系。

SignaturePolicyEnvelope结构体代表了一个完整的策略，包括版本号（Version）、策略规则 （Rule）和策略关联的实体集合（Identities）。注意实体集合采用MSPPrincipal结构表示，代表了MSP中的一组特定身份的集合。 比如属于某个MSP的成员或者管理员身份的实体，或属于MSP中某个具体组织单位（OrganizationUnit）的实体，当然也可以指定为某个特定 的签名实体。

MSPPrincipal结构如图12-20所示。

图12-20　MSPPrincipal数据结构

例如，某个策略指定签名内容需要满足MP1集合中身份签名，或者MP2集合和MP3集合中身份同时签名，则可以表达为MP1||（MP2&& MP3））。对应的策略结构如下所示：

---

SignaturePolicyEnvelope{
   version: 0,
   rule: SignaturePolicy{
       n_out_of: NOutOf{
           N: 1,
           rules: [
               SignaturePolicy{ signed_by: 0 },
               SignaturePolicy{
                   n_out_of: NOutOf{
                       N: 2,
                       rules: [
                           SignaturePolicy{ signed_by: 1 },
                           SignaturePolicy{ signed_by: 2 },
                       ],
                   },
               },
           ],
       },
   },
   identities: [MP1, MP2, MP3],
}

---

需要注意，策略的匹配过程是有序的（可参考FAB-4749）。进行策略检查时，给定的多个签名会依次按照策略顺序依次 跟MSPPrincipal指定的集合进行匹配，某个签名一旦匹配某MSPPrincipal则会被消耗掉。例如上述例子中，假如MP1代表组织A的管理 员，MP2代表组织B的成员，MP3代表组织B的管理员，那么对于签名组合[S1={组织B的管理员}，S2={组织B的成员}]，并不会匹配成功。因 为，S1在匹配MP2后会被消耗掉，剩下的S2在匹配MP3时会失败。因此，签名时要将优先级较低的签名放到前面，比如代表成员身份的签名应当放到管理员 身份前。反之，对于策略的Principal列表，则应该将高优先级的放到前面。

对于策略的检查主要实现在msp/mspimpl.go代码文件的SatisfiesPrincipal（id Identity，principal*m.MSPPrincipal）error方法中。

另外，对于管理员身份的检查，是将签名的证书跟节点msp/admincerts路径下的证书列表进行匹配，查找到则认为匹配；对于成员身份，则需要所签名证书是被节点同一MSP根签发即可。

3.IMPLICIT_META策略

IMPLICIT_META策略不直接进行签名检查，而是通过引用其子元素的策略（最终还是通过SIGNATURE策略）来进行检查。检查结果通过Rule来进行限制。

相关的结构体主要为ImplicitMetaPolicy，定义如下：

---

message ImplicitMetaPolicy {
   enum Rule {
       ANY = 0;                        // 任意子策略被满足即可
       ALL = 1;                        // 所有的子策略都必须满足
       MAJORITY = 2;           // 超过一半的子策略被满足
   }
   string sub_policy = 1;      // 在子元素中查找的子策略类型名称
   Rule rule = 2;              // 限制规则为MAJORITY
}

---

其中，sub_policy限定查找的子策略的类型（Readers、Writers或Admins），rule指定限制的规则。

例如，对于应用通道，如果包括两个组织Org1和Org2，那么如下的通道读策略（/Channel/Application/Reader）实际上意味着Org1和Org2中任意读权限的拥有者都对拥有通道读权限：

---

ImplicitMetaPolicy{
   sub_policy: "Readers",
   rule: ANY,
}

---

12.4.4　通道策略

通道策略（Channel Policy）是层级化结构，最上层为/Channel，下面是各级元素。在每一级别都可以指定策略，作为本层级的默认策略。

一个典型的例子如图12-21所示，包括一个Orderer组织和一个应用组织。

图12-21　通道策略的层级结构

未经修改情况下，使用configtxgen工具生成配置区块，会为通道内元素预先定义一些默认的策略（代码在common/configtx/tool/provisional包中），如下所示：

---

# 全局默认默认策略
/Channel/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Admins : ImplicitMetaPolicy-MAJORITY Admins

# 应用通道的默认策略（仅当应用通道）
/Channel/Application/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Application/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Application/Admins : ImplicitMetaPolicy-MAJORITY Admins

# 应用通道中各组织的默认策略（仅当应用通道）
/Channel/Application/Org/Readers: SignaturePolicy for 1 of MSP Org Member
/Channel/Application/Org/Writers: SignaturePolicy for 1 of MSP Org Member
/Channel/Application/Org/Admins : SignaturePolicy for 1 of MSP Org Admin

# 系统通道的默认策略
/Channel/Orderer/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Orderer/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Orderer/BlockValidation : ImplicitMetaPolicy-ANY Writers
/Channel/Orderer/Admins : ImplicitMetaPolicy-MAJORITY Admins

# 系统通道中各组织的默认策略
/Channel/Orderer/Org/Readers: SignaturePolicy for 1 of MSP Org Member
/Channel/Orderer/Org/Writers: SignaturePolicy for 1 of MSP Org Member
/Channel/Orderer/Org/Admins : SignaturePolicy for 1 of MSP Org Admin

# 联盟组的默认策略（仅当系统通道）
/Channel/Consortiums/Admins: SignaturePolicy for ANY

# 联盟的默认策略（仅当系统通道）
/Channel/Consortiums/Consortium/ChannelCreationPolicy: ImplicitMeta-Policy-ANY for Admin

# 联盟中组织的默认策略（仅当系统通道）
/Channel/Consortiums/Consortium/Org/Readers: SignaturePolicy for 1 of MSP Org Member:
   ImplicitMetaPolicy-ANY for Admin
/Channel/Consortiums/Consortium/Org/Writers: SignaturePolicy for 1 of MSP Org Member
/Channel/Consortiums/Consortium/Org/Admins : SignaturePolicy for 1 of MSP Org Admin

---

12.4.5　背书策略

用户在实例化链码时，可以指定背书策略（Endorsement Policy）。

背书策略采用了SignaturePolicy结构进行指定，同样可以基于MSPPrincipal结构构建任意复杂的签名校验组合。

例如，指定某几个组织内的任意成员身份进行背书，或者至少有一个管理员身份进行背书等。

语法上，背书策略支持通过-P指定哪些SignaturePolicy会被需要；通过-T指定所需要的SignaturePolicy个数。

目前，客户端已经实现了对背书策略的初步支持，通过-P来指定通过AND、OR组合的成员身份（admin，member）集合。

下面的命令可以指定要么Org1的管理员进行背书，或者Org2和Org3的成员同时进行背书，才满足背书策略：

---

-P OR('Org1.admin', AND('Org2.member', 'Org3.member'))

---

12.4.6　实例化策略

实例化策略（Instantiation Policy）一般用于最终确认阶段，Committer利用VSCC对网络中进行链码部署的操作进行权限检查。

目前，实例化策略同样采用了SignaturePolicy结构进行指定，可以基于MSPPrincipal结构构建任意复杂的签名校验组合。

默认情况下，会以当前MSP的管理员身份作为默认的策略，即只有当前MSP管理员可以进行链码实例化操作。这可以避免链码被通道中其他组织成员私自在其他通道内进行实例化。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=902

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })();

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();