网站开发要注意安全性,营销网站建设与推广方案,wordpress广告插件,市场调研方案访问控制是区块链网络十分重要的功能#xff0c;负责控制某个身份在某个场景下是否允许采取某个操作#xff08;如读写某个资源#xff09;。
常见的访问控制模型包括强制访问控制#xff08;Mandatory Access Control#xff09;、自主访问控制#xff08;Discretionar…访问控制是区块链网络十分重要的功能负责控制某个身份在某个场景下是否允许采取某个操作如读写某个资源。
常见的访问控制模型包括强制访问控制Mandatory Access Control、自主访问控制Discretionary Access Control、基于角色的访问控制Role BasedAccess Control和基于属性的访问控制Attribute Based Access Control。功能越强大的模型实现起来往往越复杂。
Fabric 通过权限策略和访问控制列表ACL机制实现了基于角色的访问控制模型可以满足通道内资源访问、背书控制或链码调用控制等多个场景下的需求。
应用场景
访问场景包括采用不同策略如通道策略、节点策略、背书策略等按照访问控制列表如要求身份为 Admins、Writers 等对某资源的特定操作进行限制。 身份证书
实现权限策略的基础是身份身份的实现依赖证书机制。通过基于 PKI 的成员身份管理Fabric 网络可以对网络内的资源和接入用户的各种能力进行限制。
Fabric 最初设计中考虑了三种类型的证书登记证书Enrollment Certificate、交易证书Transaction Certif icate以及保障通信链路安全的 TLS 证书。证书的默认签名算法为 ECDSAHash 算法为 SHA-256。
●登记证书ECert颁发给提供了注册凭证的用户或节点等实体代表网络中身份。可以长期有效。
●交易证书TCert颁发给用户控制每个交易的权限不同交易可以不同实现匿名性短期有效。暂未实现。
●通信证书TLSCert控制对网络层的接入访问可以对远端实体身份进行校验防止窃听。可以长期有效。
目前在实现上主要通过 ECert 来对实体身份进行检验通过检查签名来实现权限管理。TCert 功能暂未实现用户可以使用 idemix 机制来实现部分匿名性。 身份集合
基于证书机制Fabric 设计了身份集合MSPPrincipal来灵活标记一组拥有特定身份的个体. 对应的 MSPPrincipal 的数据结构: 身份集合支持从以下不同维度对身份进行分类。
●Role根据证书角色来区分如 Member、Admin、Client、Peer、Orderer 等。
●OrganizationUnit根据身份证书中指定的 OU 信息来区分。
●Identity具体指定某个个体的证书只有完全匹配才认为合法。
●Anonymity证书是否是匿名的用于 idemix 类型的 MSP。
●Combined由其他多个子身份集合组成需要符合所有的子集合才认为合法。
基于不同维度可以灵活指定符合某个身份的个体例如某个 MSP 的特定角色如成员或管理员或某个 MSP 的特定单位OrganizationUnit当然也可以指定为某个特定个体。
注意目前对不同角色的认可采取不同方法。对于管理员角色会认可本地 msp/admincerts 路径下的证书列表或证书带有代表管理员角色的 OU 信息Client、Peer、Orderer 等角色则需要查看证书是否带有对应的 OU 域对于成员角色则需要证书是由对应组织根证书签发。 权限策略的实现
权限策略指定了可以执行某项操作的身份集合。以通道相关的策略为例一般包括对读操作例如获取通道的交易、区块等数据、写操作例如向通道发起交易、管理操作例如加入通道、修改通道的配置信息等进行权限限制。对策略配置自身的修改是通过额外指定的修改策略mod_policy来实现的。
操作者在发起操作时其请求中签名组合只有满足策略指定的身份规则才允许执行。实现上每种策略结构都要实现 Policy 接口。对于给定的一组签名数据或身份按照给定规则进行检验看是否符合约定的条件。符合则说明满足了该策略反之则拒绝。
数据结构
策略相关的数据结构定义在 fabric-protos-go 项目的 common/policies.pb.go 文件中其中主要包括 Policy、SignaturePolicyEnvelope内嵌 SignaturePolicy 结构和 ImplicitMetaPolicy 三种数据结构如图 14-20 所示。 其中Type 的数值代表策略的类型具体含义为
●UNKNOWN保留值用于初始化。
●SIGNATURE通过匹配基于签名的组合如某个 MSP 中至少有三个签名。
●MSP代表策略必须匹配某 MSP 下的指定身份如 MSP 的管理员身份。
●IMPLICIT_META隐式类型包括若干子策略并通过 Rule 来指定具体的规则包括 ANY、ALL、MAJORITY 三种仅用于通道配置内标记通道规则。
目前已经实现支持的策略类型主要包括 SIGNATURE 策略和 IMPLICIT_META 策略两种。
SIGNATURE 策略
SIGNATURE 策略指定通过签名来对数据进行认证例如必须满足给定身份的签名组合 其中SignaturePolicy 结构体代表了一个策略规则rule。支持指定某个特定签名或者满足给定策略集合中的若干个NOutOf即可。NOutOf 用法十分灵活基于它可以递归地构建任意复杂的策略语义指定多个签名规则的与、或组合关系。
SignaturePolicyEnvelope 结构体代表了一个完整的策略包括版本号version、策略规则rule和策略关联的身份集合identities。
例如某个策略要求满足 MP1 身份集合签名或者 MP2 集合和 MP3 集合同时签名则可以表达为 MP1||(MP2MP3)。对应的策略结构如下
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] // 身份集合列表
}
// github.com/hyperledger/fabric-protos-go/common/policies.pb.go
type ImplicitMetaPolicy struct {SubPolicy string // 子策略类型名称如 Readers、Writers、AdminsRule ImplicitMetaPolicy_Rule // 子策略的匹配条件可以为 ANY、ALL、MAJORITY
}
ImplicitMetaPolicy{sub_policy: Readers,rule: ANY,
}需要注意对签名策略的匹配过程是顺序敏感的参考 FAB-4749。进行策略检查时给定的多个签名会按照策略顺序依次与身份集合进行匹配签名一旦匹配则会被消耗掉再检查下一个签名。例如上述例子中假如 MP1 代表组织 A 的管理员MP2 代表组织 B 的成员MP3 代表组织 B 的管理员那么对于签名组合 [S1{组织 B 的管理员}S2{组织 B 的成员}]并不会匹配成功。因为S1 在匹配 MP2 后会被消耗掉剩下的 S2 在匹配 MP3 时会失败。为了避免这种情况进行签名时要将优先级较低的签名放到前面比如代表成员身份的签名应当放到管理员身份前。同时对于策略的身份集合列表则应该将高优先级的放到前面。 IMPLICIT_META 策略
IMPLICIT_META 策略用于通道配置它并不直接进行签名检查而是通过引用其他子策略最终还是通过 SIGNATURE 策略来实现。检查结果通过策略规则进行约束。 通道策略
权限策略的主要应用场景之一便是通道策略。通道策略采用了层级化树形结构最上层为 / Channel 组下面是各级子组。在每一级别都可以指定策略作为本层级的默认策略。
通道配置可以包括联盟组仅当系统通道包括联盟组织信息、应用组一般仅当应用通道包含使用通道的组织信息和排序组包括排序组织信息等不同的元素。
一个典型的应用通道的例子如图 14-23 所示包括一个排序组和一个应用组。 默认情况下通道内的策略使用的角色定义如下
# 通道全局策略
/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/Endorsement: ImplicitMetaPolicy-MAJORITY Endorsement
/Channel/Application/LifecycleEndorsement: ImplicitMetaPolicy-MAJORITY
LifecycleEndorsement
# 通道内应用组各组织的默认策略仅当应用通道
/Channel/Application/Org/Readers: SignaturePolicy for 1 of Org Member
/Channel/Application/Org/Writers: SignaturePolicy for 1 of Org Member
/Channel/Application/Org/Admins : SignaturePolicy for 1 of Org Admin
/Channel/Application/Org/Endorsement: SignaturePolicy for 1 of Org Member
# 通道内排序组的默认策略需要从排序组织中推断
/Channel/Orderer/Readers: ImplicitMetaPolicy-ANY Readers
/Channel/Orderer/Writers: ImplicitMetaPolicy-ANY Writers
/Channel/Orderer/Admins : ImplicitMetaPolicy-MAJORITY Admins
/Channel/Orderer/BlockValidation: ImplicitMetaPolicy-ANY Writers
# 通道内排序组中各组织的默认策略
/Channel/Orderer/Org/Readers: SignaturePolicy for 1 of Org Member
/Channel/Orderer/Org/Writers: SignaturePolicy for 1 of Org Member
/Channel/Orderer/Org/Admins : SignaturePolicy for 1 of Org Admin
# 通道内联盟组的默认策略仅当系统通道
/Channel/Consortiums/Admins: SignaturePolicy for ANY
# 通道内联盟组中某联盟的默认通道创建策略仅当系统通道
/Channel/Consortiums/Consortium/ChannelCreationPolicy: ImplicitMetaPolicy-ANY
for Admin
# 通道内联盟组中某联盟组织的默认策略仅当系统通道
/Channel/Consortiums/Consortium/Org/Readers: SignaturePolicy for 1 of Org Member: ImplicitMetaPolicy-ANY for Admin
/Channel/Consortiums/Consortium/Org/Writers: SignaturePolicy for 1 of Org Member
/Channel/Consortiums/Consortium/Org/Admins : SignaturePolicy for 1 of Org Admin其中通道内的元素默认对其进行修改的策略mod_policy为 Admins与排序相关的配置的修改策略则指定为 / Channel/Orderer/Admins主要包括系统通道内相关配置如 Orderer-Addresses、Consortiums 和具体的联盟配置。
另外应用通道的策略会考虑最新配置中的 Orderer 组和 Application 组系统通道的策略会考虑最新配置中的 Orderer 组和 Consortiums 组。新建应用通道时用户需要指定 Application 组配置如果不指定 Orderer 组配置会自动从系统通道中继承过来。 通道访问控制
目前Fabric 中大多数的访问权限通过通道访问控制列表来指定。访问控制列表位于通道配置中被通道内所有成员认可。可以在新建通道时利用 conf igtx.yaml 指定也可以后期通过配置更新进行变更。访问控制列表配置示例如下包括访问控制列表和其引用的策略
Application: ApplicationDefaultsACLs: ACLsDefault# Lifecycle 方法调用权限CheckCommitReadiness()、CommitChaincodeDefinition()、
QueryChaincodeDefinition()、QueryChaincodeDefinitions()_lifecycle/CheckCommitReadiness: /Channel/Application/Writers_lifecycle/CommitChaincodeDefinition: /Channel/Application/Writers_lifecycle/QueryChaincodeDefinition: /Channel/Application/Readers_lifecycle/QueryChaincodeDefinitions: /Channel/Application/Readers# LSCC 方法调用权限getid()、getdepspec()、getccdata()、getchaincodes()lscc/ChaincodeExists: /Channel/Application/Readers
lscc/GetDeploymentSpec: /Channel/Application/Readerslscc/GetChaincodeData: /Channel/Application/Readerslscc/GetInstantiatedChaincodes: /Channel/Application/Readers# QSCC 方法调用权限GetChainInfo()、GetBlockByNumber()、GetBlockByHash()、
GetTransactionByID()、GetBlockByTxID()qscc/GetChainInfo: /Channel/Application/Readersqscc/GetBlockByNumber: /Channel/Application/Readersqscc/GetBlockByHash: /Channel/Application/Readersqscc/GetTransactionByID: /Channel/Application/Readersqscc/GetBlockByTxID: /Channel/Application/Readers# CSCC 方法调用权限GetConfigBlock()cscc/GetConfigBlock: /Channel/Application/Readers# 通道内链码调用权限向 Peer 发送背书请求peer/Propose: /Channel/Application/Writers# 通道内跨链码调用权限peer/ChaincodeToChaincode: /Channel/Application/Readers# 接收区块事件权限event/Block: /Channel/Application/Readers# 接收过滤区块事件权限event/FilteredBlock: /Channel/Application/Readers# 默认应用通道内组织成员为空Organizations:# 通道内相关的策略可被 ACL 中引用用户也可以自定义全局策略Policies: ApplicationDefaultPoliciesReaders:Type: ImplicitMetaRule: ANY ReadersWriters:Type: ImplicitMetaRule: ANY WritersAdmins:Type: ImplicitMetaRule: MAJORITY Admins# 引用应用通道默认的能力集合Capabilities:: *ApplicationCapabilities目前通道配置支持的资源访问权限总结如表:
资源访问权限功能Lifecycle/InstallChaincode本 MSP Admins安装链码Lifecycle/QueryInstalledChaincode本 MSP Admins查询已安装的链码信息Lifecycle/GetInstalledChaincodePackage本 MSP Admins获取链码安装包Lifecycle/QueryInstalledChaincodes本 MSP Admins查询所有已安装链码列表Lifecycle/ApproveChaincodeDefinitionForMyOrg本 MSP Admins本 MSP AdminsLifecycle/CommitChaincodeDefinition通道 Writers提交链码定义Lifecycle/QueryChaincodeDefinition通道 Writers查询指定的已提交链码定义Lifecycle/CheckCommitReadiness通道 Writers检查链码定义提交状态Lscc/Install本 MSP Admins传统安装链码Lscc/GetInstalledChaincodes本 MSP Admins传统获取安装链码列表Lscc/Deploy通道 Writers传统实例化链码Lscc/Upgrade通道 Writers传统升级链码Lscc/ChaincodeExists通道 Readers检查链码是否安装Lscc/GetDeploymentSpec通道 Readers获取安装包Lscc/GetChaincodeData通道 Readers获取链码完整数据包Lscc/GetInstantiatedChaincodes通道 Readers获取已实例化链码列表Lscc/GetCollectionsConfig通道 Readers获取私有数据集合配置Qscc/GetChainInfo通道 Readers查询通道信息Qscc/GetBlockByNumber通道 Readers获取指定序号区块Qscc/GetBlockByHash通道 Readers获取指定 hash 区块Qscc/GetTransactionByID通道 Readers获取指定 ID 交易Qscc/GetBlockByTxID通道 Readers获取包括指定交易的区块Qscc/JoinChain通道 Readers加入通道Qscc/GetChannels通道 Readers获取已加入的通道列表Qscc/GetConfigBlock通道 Readers获取配置区块Peer/Propose通道 Writers调用链码Peer/ChaincodeToChaincode通道 Writers跨链码调用Event/Block通道 Readers监听完整区块事件Event/FilteredBlock通道 Readers监听过滤区块事件 背书策略
链码背书策略
用户在批准执行链码2.0 版本之前为实例化链码时可以指定调用该链码需要满足的背书策略Endorsement Policy并存放到链码定义中。当对链码的调用交易被提交时Peer 会检查是否交易携带了符合指定背书策略的签名信息。
背书策略可以采用 SignaturePolicy 或 ChannelConf igPolicy 两种方式进行指定构建十分灵活的策略组合。SignaturePolicy 方式指定使用特定身份签名组合来进行背书。例如指定某几个组织内的任意成员身份进行背书或者至少有一个管理员身份进行背书等。
语法上背书策略通过 - P 指定需要哪些 SignaturePolicy通过 - T 指定所需要的 Signature-Policy 个数。目前客户端已经实现了对背书策略的初步支持通过 - P 来指定通过 AND、OR、OutOf 组合的身份角色包括 admin、member、peer、client集合。
下面的策略指定要么 Org1 的管理员进行背书要么 Org2 和 Org3 的 peer 节点同时进行背书
OR(Org1.admin, AND(Org2.peer, Org3.peer))下面的策略指定三个组织中至少两个组织的成员进行背书
OutOf(2, Org1.member, Org2.member, Org3.member)ChannelConf igPolicy 方式则引用通道配置内的已有策略名使用对应的身份进行背书。
例如如果不显式指定背书策略则会使用通道配置中的 Channel/Application/Endorsement 策略其默认为通道内的大多数成员。 键值背书策略
除了面向链码该链码的所有状态的背书策略外自 1.3.0 版本开始Fabric 支持基于特定状态键值的更细粒度的背书策略。用户可以指定要修改某个指定状态时所需的背书策略。
包括如下的 shim 层 API可以在链码内使用。
●GetStateValidationParameter (collection,key string)([] byte,error)获取指定集合对指定键值的背书策略。
●SetStateValidationParameter (collection,key string,ep [] byte) error指定某个键值所绑定的背书策略。
●GetPrivateDataValidationParameter (collection,key string)([] byte,error)获取指定集合对指定私密键值的背书策略。
●SetPrivateDataValidationParameter (collection,key string,ep [] byte) error指定某个私密键值对应的背书策略。
Peer 在提交区块阶段会对背书策略进行检查. 私有数据集合背书策略
自 2.0 版本起用户也可以为每个私密数据集合指定对应的背书策略。当用户对私密数据集合内的键值进行写或修改操作时需要满足指定的背书策略。此时链码的整体背书策略会被忽略。发起写请求的用户不必为私密数据集合的成员。使用私密数据集合背书策略可以限制对私密数据的写操作实现更为安全的链码访问保护。
类似于链码背书策略私密数据集合背书策略支持 SignaturePolicy 或 ChannelConf igPolicy 两种方式。例如可以在集合配置文件 collection.json 中指定 signaturePolicy 或 channelConf ig-Policy 背书策略示例代码如下
[{name: collection1, // 集合名称policy: OR(Org1MSP.member, Org2MSP.member), // 集合成员requiredPeerCount: 1, // 背书之前至少扩散私密数据到的节点数maxPeerCount: 3, // 背书之前尝试扩散最多节点个数不能小于 requiredPeerCountblockToLive:99999, // 私密数据保存时长。0 意味着永不过期memberOnlyRead: true, // 是否只允许集合成员如客户端来读取私密数据v1.4 开始支持memberOnlyWrite: true,// 是否只允许集合成员如客户端来发起对私密数据的写交易v2.0 // 开始支持endorsementPolicy: { // 指定对私密数据进行写操作时的背书策略会取代链码的背书策略signaturePolicy: OR(Org1MSP.member) // 指定使用签名策略}
},
{name: collection2,policy: OR(Org1MSP.member),requiredPeerCount: 1,maxPeerCount: 3,blockToLive:3,memberOnlyRead: true,memberOnlyWrite: true,endorsementPolicy: {channelConfigPolicy: Channel/Application/Writers // 指定使用通道配置内已 // 有策略}
}
]基于证书属性的链码访问控制
另外用户也可以在自己的链码内通过基于证书属性的链码访问控制实现自定义的控制逻辑。例如可在方法入口处先检测调用者身份证书过滤某些特定身份调用者以实现基于键值或其他条件的细粒度的控制。
// github.com/hyperledger/fabric-chaincode-go/pkg/cid/cid.go
// 获取根据证书主题生成的唯一标识
func GetID() (string, error)
// 获取 MSP ID
func GetMSPID() (string, error)
// 获取证书某个属性的值
func GetAttributeValue(attrName string) (value string, found bool, err error)
// 检查证书中某个属性是给定值
func AssertAttributeValue(attrName, attrValue string) error
// 获取调用者的 X509 证书
func GetX509Certificate() (*x509.Certificate, error)
// 判断调用者是否属于给定 OU
func HasOUValue(stub ChaincodeStubInterface, OUValue string) (bool, error)用户可以使用这些方法在链码方法中对调用者身份进行访问控制。
例如在证书的 extension 域中设置自定义的属性 abac.role并在链码方法中判断只有证书带有该属性的用户才可以调用该方法示例代码如下
import github.com/hyperledger/fabric-chaincode-go/pkg/cidfunc (t *TestChaincode) Access(stub shim.ChaincodeStubInterface, role string) pb.Response {// 根据属性值来判断是否允许访问方法err : cid.AssertAttributeValue(stub, abac.role, true)if err ! nil {return shim.Error(Not allowed with missed attributionerr.Error())}...
}实例化策略
实例化策略Instantiation Policy仅在 2.0 版本之前生效负责对链码的实例化情况进行控制。Committer 在确认阶段利用 VSCC 对网络中进行链码部署的操作进行权限检查。
目前实例化策略同样采用了 SignaturePolicy 结构进行指定可以基于身份集合结构构建复杂的签名校验组合。
默认情况下会以当前 MSP 的管理员身份作为默认策略即只有当前 MSP 管理员可以进行链码实例化操作。这可以避免链码被通道中其他组织成员私自在其他通道内进行实例化。
实例化策略的检查发生在 Peer 的背书阶段。
fabricgogithubhyperledger
© 著作权归作者所有
