Hyperledger Fabric 网络与安全体系浅析 #
前言 #
上一篇文章《Hyperledger Fabric 架构详解》对Fabric的架构和工作原理进行了详细的解读与分析，那作为一个企业级的区块链系统，它是如何根据复杂的业务需求搭建网络，在运行过程中存在哪些安全问题，以及Fabric是如何从机制上进行预防的呢？
本文将通过实例阐释一个简化版的企业Fabric网络是如何构建的，并对其网络与安全体系进行分析，如有错漏，欢迎交流指正。
Hyperledger Fabric 网络 #
Hyperledger Fabric 应用场景实例 #
业务角色 #
假设有一个采用Fabric系统的应用场景里。
有 4 个组织R1, R2, R3和R4，R4是网络启动者，R1和R4共同担任网络管理员角色。
系统设置了 2 个通道，分别为C1和C2。R1和R2使用C1通道，R2和R3使用C2通道。
应用A1属于组织R1，于C1通道运行；应用A2属于组织R2，同时于C1通道和C2通道运行；应用A3属于组织R3，于C2通道运行。
P1、P2和P3分别是组织R1、R2和R3的节点。
排序节点由O4提供，属于组织R4.
搭建过程 #
与真正的商业应用场景相比，角色和商业和逻辑都很简化，但很适合用来理解不同节点和角色之间的功能和交互。接下来，我将一步一步说明网络的搭建过程。
创建网络并添加网络管理员
每一个组织需要通过MSP中的 CA 机构颁发的证书才能加入网络，因此，每个节点都需要有相应的 CA。
R4作为网络启动者，需要先配置网络并设立O4排序节点！网络创建后，添加R1作为网络管理员，因此，R1和R4可以对网络进行配置（NC4）。
定义联盟并创建通道
R1和R2将通过C1进行业务交互，因此需要在网络中定义联盟，因为现在R1和R4都可以对网络进行配置，因此都可以定义联盟。
接着为这个联盟创建通道C1（连接至排序服务O4）。
加入节点、部署智能合约与应用
P1节点加入已经建立的通道C1，维护着一个账本L1。
这时候就可以在节点上安装和实例化智能合约了。Fabric的智能合约是链码，把链码存储在节点的文件系统上称为安装智能合约，安装后还需要在特定的通道上启动和实例化链码，至此，应用可以发送交易 proposal 至背书节点了（需要遵守链码设置的背书策略）。
如下图所示，P1节点安装链码S5并在通道C1实例化后，就可以响应来自应用A1的链码调用了;P2节点安装链码S5并在通道C1实例化后，就可以响应来自应用A2的链码调用了。
通道中的每一个节点都是提交节点，可以接收新区块（来自排序节点）进行验证，并提交至账本；而部署了链码的一些节点则可以成为背书节点。
定义新联盟、创建新通道
在网络中定义新联盟并加入C2通道。
加入新节点并部署智能合约与应用
值得注意的是，有些节点会同时加入多个通道，在不同的业务中扮演不同的角色，其他流程同上。
网络搭建完成
Fabric采用权限管理、通道等机制，并通过对不同节点功能分工，提升了系统的运行效率，并保障了复杂业务场景中的安全和隐私；强大的链码和可自定义的背书策略等也保障了系统的拓展性，可以处理复杂的业务逻辑。
Hyperledger Fabric 安全分析 #
Fabric 安全机制 #
Fabric设计了很多机制来保障系统的安全性。
系统配置与成员管理 #
区别于比特币、以太坊等公链，加入Fabric网络需要进行权限验证，Fabric CA为成员管理使用X.509证书机制以保障其权限，避免潜在Spoofing攻击等。
现有的系统成员需要制定加入新成员的规则，比如进行多数投票等；现有成员也需要决定网络和智能合约的更新和改变，这样能够很大程度上防止恶意节点破坏系统安全性；现有节点不能自行升级权限；除此之外，还需要决定系统的通用数据模型等设置。
Fabric的网络传输采用TLSv1.2，可以保障数据的安全性；且系统中的操作，如发起交易、背书等都会通过数字签名技术来记录，很容易追溯一些恶意操作。但值得注意的是，排序节点可以获取系统中所有节点的交易数据，因此，排序服务节点的设定对于整个系统的安全性尤其重要，它的公正性会很大程度影响整个系统的运作，甚至决定了整个系统是否值得信任，因此，需要根据业务和系统结构慎重选择。
公链系统中，所有节点都有区块链账本的副本，并且执行智能合约；而在Fabric系统中，业务相关节点会形成节点组，存储与其交易（业务）相关的账本，而通过链码对账本的更新也会被限制在节点组的范围内，从而保障整个系统的稳定性。
智能合约的执行称为交易，对于Fabric系统内的交易，也必须要保持其一致性，往往采用密码学技术来防止交易被篡改，如采用SHA256、ECDSA等检测修改；Fabric采取模块化、可插拔的设计，将交易的执行、验证共识进行分离，因此，可以采取不同的共识机制或规则，不仅能够根据需求选择不同的共识机制，更具拓展性，也能提高系统安全性。
这些配置和规则共同决定了系统的安全性，需要在业务需求、效率和安全性上作权衡。
智能合约安全 #
Fabric的链码需要安装在节点上并且实例化，安装链码需要有 CA 的验证，因此要注意权限管理；启动后是运行在独立的 Docker 容器中的，更轻量级，但是因为它能够访问Fabric网络，如果没经过严格的代码审计以及对网络进行隔离，会造成一些恶意后果。
Fabric的链码可以用多种通用型的编程语言撰写，例如Go、Java等，这让系统有了更强的拓展性，也更容易接入现有系统和工具，但因为其执行结果是不缺性的，编程语言的一些特性（如随机数、系统时间戳、指针等）可能会造成不同背书节点执行结果不同，造成系统不一致性；此外，因为链码可以访问一些外部的 Web 服务、系统命令、文件系统和第三方库等，也会造成一些潜在的风险。因此，用这些通用语言开发的链码需要相对独立且加强代码审计，以避免一些因编程语言带来的安全风险。
交易隐私 #
Fabric采用了通道机制来划分整个系统为多个子区块链（账本），只有加入通道的节点才能查看和存储交易信息，但排序节点可以看到。
那有什么办法在通道中保障一些私有数据的隐私呢？
Fabric提供了一种存储私有数据的方式，使通道中的节点可以选择特定的数据分享对象（节点）。
在这种机制下，真实的数据会通过gossip协议发送到指定的节点，数据存放私有数据库中，只有授权节点可以通过链码进行访问，因为这个过程并没有涉及到排序服务，所以排序节点也无法获取。
而在系统内传播、排序与写入账本的数据是经过哈希加密的版本，因此交易仍然可以被各个节点验证，但因为哈希的特性，可以有效保护原数据不被泄漏。
但值得注意的是，如果在背书节点模拟交易过程中需要使用到数据，那需要采取额外的机制来保障数据对于背书节点的可读性和对其他节点的不可见性（如非对称加密等）。
总结 #
以上就是对Hyperledger Fabric网络搭建和安全体系分析了，接下来将会开始学习Go和链码的开发，通过项目实战来对其进行深入了解学习！
参考资料 #
- FITE3011 Distributed Ledger and Blockchain, Allen Au，HKU