hag*_*gis 3 hyperledger hyperledger-fabric hyperledger-fabric-ca
让我们以 3 个公平组织的场景为例,即每个组织都运行对等体,并且应该平等地参与订购过程。
对我来说,将这 3 个组织配置为每个组织都有一个排序者节点和一些对等点是很自然的。然而,强烈建议不要采用这种设置。引用常见问题解答:
问题:我可以让一个组织同时扮演订购角色和应用角色吗?
回答:虽然这是可能的,但这是一种非常不鼓励的配置。默认情况下,/Channel/Orderer/BlockValidation 策略允许订购组织的任何有效证书对区块进行签名。如果组织同时扮演订购和应用程序角色,则应更新此策略以将块签名者限制为授权订购的证书子集。
在另一个 SO 问题中,一个答案提供了有关此主题的更多详细信息:
首先,很容易错误配置策略并显着降低系统的安全性。订购服务和应用程序根据权力分离的原则运作。重要的是,排序节点不能制造验证交易,同样重要的是应用程序交易者不能制造区块。
并继续:
其次,由于 MSP 定义必须出现在通道配置的两个部分中,因此您最终会得到两个相同的 MSP 定义副本,它们必须保持完全同步。由于两个 MSP 具有相同的 ID,如果内容不完全相同,则会在评估身份时产生歧义。
我整个晚上都在绞尽脑汁地思考,如果此设置配置不正确,哪些攻击媒介和参与者可能会给我的组织或整个网络带来潜在的安全风险。
不幸的是,我只能想到一种情况:如果排序者二进制文件中存在漏洞,则另一个组织的排序者可以利用此漏洞以我组织的身份创建交易。
问题:如果您在单个组织中拥有对等点和订购者并且配置不正确,可能会暴露哪些攻击媒介?演员会是谁?客户、管理员、网络的其他组织、完全的局外人?
额外问题:在给定场景中建议的替代方案是什么?每个参与组织是否应该分成单独的对等组织和订购者组织?喜欢Company1PeerOrg、Company1OrdererOrg、Company2PeerOrg,...?
问题:如果您在单个组织中拥有对等点和订购者并且配置不正确,可能会暴露哪些攻击媒介?演员会是谁?客户、管理员、网络的其他组织、完全的局外人?
对于正常的交易流程,本质上需要三种类型的参与方在交易提交之前进行签名。
首先是提交者或客户端,他们请求背书、创建交易并将其发送到排序。一般来说,客户端属于应用程序类别Writers
。他们被授权调用对等 API 和排序者广播。
其次,是执行交易并产生交易结果的对等点。对等方知道执行时的世界状态,以及与调用的链码关联的业务逻辑。节点对执行结果进行签名,以证明业务逻辑被正确执行。对等点通常属于应用程序类别Reader
,因为它们需要查看所有交易以保持其世界状态最新(因此它们可以执行以帮助生成新交易)。
最后是排序者,它为交易建立总订单,将其放入区块中,然后签名以证明对该订单达成了共识,并且同行可以认为该交易的订单是最终的。Reader
Orderers 属于 Orderer和的范畴Writer
,因为它们复制现有的链,并向其追加内容。
那么,关于你的问题,如果这些角色混为一谈,会出现什么问题。如果一个身份被设计不当,或者策略被设计不当,使得单个身份可以满足所有这些角色,那么该身份就有可能发起双花攻击。
架构松散,因为该身份符合客户端的资格,所以它可以创建两个看起来有效的交易,一个将 5 美元发送给 Alice,另一个将同样的 5 美元发送给 Bob。通常,交易被发送到排序,接收总订单,第一个获胜。然而,由于该身份可以充当排序者,因此它可以生成两个具有相同块号的看起来有效的块,每个块都包含一项交易。现在,如果没有有效的 TLS 服务器证书,客户端无法作为排序者将块注入到系统中,但是,如果身份是对等方,那么它现在可以尝试通过八卦设施将块注入到网络中。如果可以欺骗两个不同的节点采用两个不同的伪造区块,那么这些节点都会认为他们看到的交易是有效的。而且,您现在已经产生了双重支出。(当然,网络最终会检测到伪造的区块,这可以归因,但损害已经造成。)
可能还有其他新颖的攻击,但希望这表明使用单一身份履行所有三个角色是有问题的。在 Fabric v1.0 中,唯一的角色是“管理员”和“成员”。所以此时,订购组织和应用组织不重叠是绝对关键的。然后引入了“Peer”这个角色,最后引入了“Orderer”这个角色。这些新角色使制定策略以确保网络安全变得更加容易,但在 CA 级别拆分这些组织仍然比在角色级别拆分更安全。
额外问题:在给定场景中建议的替代方案是什么?每个参与组织是否应该分成单独的对等组织和订购者组织?喜欢 Company1PeerOrg、Company1OrdererOrg、Company2PeerOrg,...?
是的,建议为每个成员建立一个逻辑排序组织和应用程序组织。
归档时间: |
|
查看次数: |
342 次 |
最近记录: |