Hyperledger Composer权限在Fabric中的实现及隐私相关技术咨询

Hyperledger Composer的权限系统完全构建在Hyperledger Fabric的底层权限框架之上，核心通过以下几层联动实现：

• ACL规则映射到Fabric身份与策略：Composer通过permissions.acl文件定义细粒度访问控制列表（比如谁能创建资产、提交交易），这些规则会关联到Fabric的MSP（成员服务提供者）中注册的身份。当用户发起请求时，Composer首先校验ACL规则，再将合法请求传递给Fabric。
• Fabric MSP作为身份基础：Composer中的角色（如networkAdmin、participant）本质上是Fabric身份的属性标签。只有在Fabric MSP中合法注册的身份，才能被Composer赋予对应的权限角色。
• 通道策略的二次校验：即使Composer通过了ACL校验，Fabric还会触发通道层面的策略检查（比如背书策略、提交策略），确保交易符合通道的全局权限要求，最终完成权限的闭环。

如何在Composer中运用通道概念？ #

Composer直接对接Fabric的通道机制，主要通过以下方式实现数据隔离：

• 部署业务网络时，可指定对应的Fabric通道。通常每个Composer业务网络会部署到独立的通道，确保不同业务场景的数据完全隔离。
• 在Composer的连接配置文件（connection profile）中，需要明确指定业务网络关联的通道、以及该通道内的节点（peer、orderer）信息。如果需要跨通道交互，可以配置多个连接文件，分别对应不同的通道。
• 只有加入目标通道的Fabric节点，才能同步该通道的账本数据，Composer应用也只能通过关联通道的节点访问对应数据。

权限文件与隐私概念有何关联？ #

两者是互补的隐私保护层级：

• 通道是底层数据隔离：Fabric通道从节点层面隔离数据，非通道成员的节点根本不会存储对应账本数据。
• ACL是应用层细粒度控制：Composer的permissions.acl在通道内部进一步限制访问权限——比如同一通道内的不同参与者，可能被禁止查看特定资产、执行某些交易，甚至隐藏资产的敏感字段（通过条件规则实现，比如仅资产所有者能查看机密属性）。
• 两者结合：通道确保数据不会被无关节点获取，ACL确保数据在合法节点内也只能被授权用户访问，形成双重隐私防护。

无访问权限的节点是否仍会存储相关数据？ #

分两种情况：

• 非通道成员节点：完全不会存储该通道的任何数据。Fabric的gossip协议仅在通道成员间同步账本，非成员节点无法接收或存储对应数据。
• 通道内但无Composer ACL权限的用户：其关联的节点仍会存储通道账本数据，但该用户无法通过Composer的API读取或操作这些数据——Composer会在应用层拦截未授权的请求。

恶意攻击是否足以获取这些数据或相关信息？ #

需要分场景判断：

• 针对非通道节点：几乎不可能。因为非节点无法通过Fabric的合法协议获取通道数据，除非攻击者能攻破Fabric的orderer节点（但orderer仅存储交易排序结果，不保存完整账本），或者通过社会工程学获取通道成员的身份凭证加入通道，这属于极高难度的攻击。
• 针对通道内节点但无ACL权限的用户：如果攻击者仅拥有该用户的Composer身份，无法直接获取数据；但如果攻击者能直接入侵节点的服务器/容器（比如获取文件系统访问权），理论上可以读取节点存储的账本文件。不过Fabric支持账本数据加密存储，加上服务器层面的安全防护（如防火墙、访问控制），这种风险可以大幅降低。
• 另外，Fabric对传输中的数据采用TLS加密，攻击者即使监听网络流量，也无法解密获取有效数据。

内容的提问来源于stack exchange，提问作者Edoardo Conte