📚 课程目录第3章访问控制策略

3、访问控制策略：理解签名策略与隐式元策略

访问控制是 Fabric 网络的命门。说白了，链码能不能调用、通道配置谁有权改，全靠策略说了算。今天咱们就掰开揉碎，把 Signature Policy 和 ImplicitMeta Policy 讲清楚。

我个人习惯把策略比作「门禁卡」。签名策略就像一张写着「张三或李四签名即可开门」的卡片，而隐式元策略更像「需要管理员组中任意两人同时刷卡」。两种方式各有适用场景，咱们一个个看。

3.1 签名策略（Signature Policy）

签名策略是最基础的访问控制单元。它直接指定哪些身份（通过 MSP 标识）签名后，策略就算满足。

核心语法结构：

SignaturePolicy:
  Type: "Signature"
  Rule: "OR(Org1MSP.admin, Org2MSP.admin)"

这里的关键字是 AND、OR、NOutOf。你可以组合出各种逻辑：

AND(Org1MSP.admin, Org2MSP.admin) —— 两个组织的管理员都必须签名
OR(Org1MSP.member, Org2P.member) —— 任一组织的成员签名即可
NOutOf(2, Org1MSP.admin, Org2MSP.admin, Org3MSP.admin) —— 三个管理员中至少两人签名

我在项目中遇到过一个问题：有人把 OR 写成了 OR(Org1MSP.admin, Org2MSP.admin)，结果发现 Org1 的管理员一个人就能通过策略。嗯，这里要注意——OR 是「或」，不是「异或」。如果你想要「两个管理员必须同时在场」，得用 AND。

避坑指南：我曾经在配置通道更新策略时，把 NOutOf 的阈值设成了 0。你猜怎么着？任何人都能发起通道更新，包括非组织成员。这个 bug 在测试环境跑了三天才被发现。阈值一定要 >= 1。

3.2 隐式元策略（ImplicitMeta Policy）

隐式元策略是 Fabric 1.4 之后引入的「语法糖」。它不直接写死签名规则，而是引用其他策略的「聚合结果」。

ImplicitMetaPolicy:
  Type: "ImplicitMeta"
  Rule: "ANY Readers"

这里的 ANY、ALL、MAJORITY 是三个关键字：

关键字	含义	典型场景
`ANY`	子策略中任意一个满足即可	查询链码、读取区块
`ALL`	所有子策略都必须满足	通道配置更新、安装链码
`MAJORITY`	超过半数的子策略满足	组织级决策、共识变更

你想想看，为什么要有隐式元策略？直接写签名策略不就行了？

原因很简单：可维护性。假设你有 10 个组织，每个组织都有 admin、member、client 三种角色。如果用签名策略，你得写 30 条规则。而隐式元策略只需要定义三层：

底层：每个组织定义自己的 Readers、Writers、Admins 签名策略
中层：通道级别用 ImplicitMeta 引用这些策略
上层：应用策略再引用通道策略

这样，新增一个组织时，只需要在底层加一套签名策略，上层自动生效。

注意：隐式元策略不能单独存在。它必须依赖底层已经定义好的签名策略。如果底层策略没配好，隐式元策略会直接报错。我曾经见过一个案例，运维人员只改了通道的 ImplicitMeta 策略，忘了更新对应组织的 Signature 策略，结果整个通道的读写都挂了。

3.3 策略定义文件实战

咱们直接看一个完整的 configtx.yaml 策略片段。这是我在生产环境中用过的模板，稍作脱敏：

Policies:
  Readers:
    Type: ImplicitMeta
    Rule: "ANY Readers"
  Writers:
    Type: ImplicitMeta
    Rule: "ANY Writers"
  Admins:
    Type: ImplicitMeta
    Rule: "MAJORITY Admins"

Organizations:
  - &Org1
    Name: Org1MSP
    ID: Org1MSP
    Policies:
      Readers:
        Type: Signature
        Rule: "OR('Org1MSP.admin', 'Org1MSP.member')"
      Writers:
        Type: Signature
        Rule: "OR('Org1MSP.admin', 'Org1MSP.member')"
      Admins:
        Type: Signature
        Rule: "OR('Org1MSP.admin')"
    AnchorPeers:
      - Host: peer0.org1.example.com
        Port: 7051

这个配置里，通道级别的 Admins 用了 MAJORITY Admins，意思是「所有组织管理员中，超过半数同意」。而每个组织内部，Admins 签名策略只要求本组织的 admin 签名即可。

我个人习惯把组织级别的策略写得宽松一些（比如 admin 或 member 都能读写），通道级别的策略收紧（比如必须多数组织同意）。这样既保证日常操作灵活，又防止单点故障。

3.4 策略优先级与覆盖规则

策略不是平级的，它们有明确的优先级。Fabric 的策略查找顺序是：

应用通道配置中的策略
系统通道配置中的策略
默认策略（如果前两者都没定义）

举个例子：如果你在应用通道里定义了 Writers 策略，它会覆盖系统通道的 Writers 策略。但注意，覆盖只发生在同一层级。你不能用应用通道的 Admins 策略去覆盖系统通道的 Orderer 策略——类型不同，互不影响。

小技巧：我在调试策略问题时，常用 peer channel fetch config 拉取当前通道配置，然后用 configtxlator 解码。直接看 JSON 里的 policies 字段，比猜配置要准得多。

3.5 策略设计模式总结

下面这张图是我自己总结的策略分层模型，帮你快速理解两种策略的关系：

从这张图能看出来，底层 Signature 策略是基石。没有它，上层的 ImplicitMeta 就是空中楼阁。我个人建议，每次新建组织时，先把三套 Signature 策略（Readers、Writers、Admins）配好，再考虑通道层的聚合策略。

3.6 常见错误与调试方法

最后分享几个我踩过的坑：

策略名称大小写敏感：Admins 和 admins 是两个不同的策略。Fabric 不会报错，但会找不到匹配项，默认拒绝所有请求。
MSP ID 拼写错误：Org1MSP 写成了 Org1Msp，策略永远无法满足。我建议用 configtxlator 的 compute update 命令做一次预校验。
隐式元策略的递归引用：通道层的 Admins 引用了组织层的 Admins，而组织层的 Admins 又引用了通道层的策略——死循环。Fabric 会直接 panic。

重要提醒：生产环境中，永远不要在通道创建后随意修改 Admins 策略。一旦改错，你可能连改回来的权限都没有了。我见过一个团队，把 MAJORITY 改成了 ALL，结果有一个组织的管理员证书过期了，整个通道配置卡死。最后只能重建通道。

好了，策略定义这块就聊到这儿。记住一句话：签名策略管「谁能签」，隐式元策略管「需要多少人签」。两者配合好，你的 Fabric 网络才能既安全又灵活。