联盟链通用技术要求(T-FJBCA 001—2022).pdf

《联盟链通用技术要求(T-FJBCA 001—2022).pdf》由会员分享，可在线阅读，更多相关《联盟链通用技术要求(T-FJBCA 001—2022).pdf（17页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、福 建 省 区 块 链 协 会 团 体 标 准T/FJBCA 0012022联盟链通用技术要求General technical requirements of Consortium Blockchain2022-01-17 发布2022-02-17 实施福建省区块链协会发 布ICS 35.240CCS I65T T/FJBCAT/FJBCA 0012022I目次前言.II1范围.12规范性引用文件.13术语、定义和缩略语.14总体要求.35数据要求.36共识机制.47智能合约.58身份要求.59接口要求.610性能要求.611运维要求.712安全要求.9附录 A（规范性）接口管理.10参考文

2、献.14T/FJBCA 0012022II前言本文件按照 GB/T 1.12020标准化工作导则第 1 部分：标准化文件的结构和起草规则的规定起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由熵链科技（福建）有限公司提出。本文件由福建省区块链协会归口。本文件起草单位：熵链科技（福建）有限公司、福州清之漾科技有限公司、福建神笔马良智能科技股份有限公司、福州天棣互娱网络科技有限公司、福建省标院信息技术有限公司、福建省标准化研究院、数研院（福建）信息产业发展有限公司、莆田市数字城市互联网信息服务有限公司、熵链科技（厦门）有限公司、福建福链科技有限公司、数字福建区

3、块链工程实验室、福建省工业互联网+区块链联合实验室、三明市信息产业发展有限公司本文件主要起草人：宋志刚、斯雪明、陈意斌、王超博、毛岱山、李跃发、林朱瑞、郑松、华东、王聚师、黄胜魁、张毅瑜、王彬彬、钟山、柯亚萍、肖苗苗、林涌、陈一彬、张耀森、柳书苗、齐贺、邓婕T/FJBCA 00120221联盟链通用技术要求1范围本文件规定了联盟链技术应用的总体要求、数据要求、共识机制、智能合约、身份要求、接口要求、性能要求、运维要求、安全要求等。本文件提供了联盟链的通用技术要求，为计划选择和使用联盟链的组织和机构提供依据，适用于联盟链开发企业。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必

4、不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 5271.182018信息技术词汇第 18 部分：分布式数据处理GB/T 222392019信息安全技术网络安全等级保护基本要求GB/T 250692010信息安全技术术语GB/T 370432018智慧城市术语GM/T 00042012SM3 密码杂凑算法GM/T 00092012SM2 密码算法使用规范GM/T 00192012通用密码服务接口规范GM/T 00282014密码模块安全技术要求GM/T 00292014签名验签服务器技术规范JR/T

5、 01842018金融分布式账本技术安全规范3术语、定义和缩略语3.1术语和定义下列术语和定义适用于本文件。3.1.1区块链block chain一种在对等网络环境下，通过透明和可信规则，构建不可伪造、不可篡改和可追溯的块链式数据结构，实现和管理事务处理的模式。注：事务处理包括但不限于可信数据的产生、存取和使用等。来源：GB/T 370432018,2.5.83.1.2联盟链consortium blockchain也称许可链，由多个通过身份验证的组织经许可后参与构成并共同运营管理的区块链。3.1.3智能合约smart contractT/FJBCA 00120222一种旨在以信息化方式记录、

6、验证或执行合同的计算机协议，其在去中心化账本上体现为需达成共识方可执行的计算机程序。来源：JR/T 01842020，3.20，有修改3.1.4节点node在网络中，将其连接到一个或多个其他实体的实体。来源：GB/T 5271.182008，18.01.023.1.5交易transaction区块链上的一次原子性账本数据状态变更及其过程和结果记录。3.1.6数字签名digital signature附加在数据单元上的数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的接收者用以确认数据单元的来源和完整性，并保护数据防止被人（例如接收者）伪造或抵赖。来源：GB/T 250692010

7、，2.2.2.1763.1.7身份证书certificate关于实体的一种数据，该数据由认证机构的私钥或秘密密钥签发，并无法伪造。来源：GB/T 250692010，2.2.2.2183.1.8CA 证书CA-certificate由一个 CA 颁发给另一个 CA 的证书。来源：GB/T 250692010，2.2.2.2193.1.9散列/杂凑算法hash function将比特串映射为固定长度的比特串的算法，该算法满足下列特性：对于给定输出，找出映射为该输出的输入，在计算上是不可行的对于给定输入，找出映射为同一输出的第二个输入，在计算上是不可行的注：计算上的可行性取决于特定的安全要求和环境

8、来源：GB/T 250692010，2.2.2.1663.1.10共识算法consensus algorithms去中心化系统中，节点间形成共同认识或达成一致意见的算法。区块链共识机制保证了以去中心化方式维护分布式数据库的一致性。其中去中心化是指数据或程序执行结果不以单个组织、节点的结果为准，而是以系统中大部分节点一致的结果为准。3.2缩略语下列缩略语适用于本文件。PoW工作量证明Proof-of-WorkPoS权益证明Proof-of-StakeDPoS委托权益证明Delegated-Proof-of-StakeT/FJBCA 00120223RAFT分布式一致性复制协议Replicated

9、 And Fault TolerantPBFT实用拜占庭容错算法Practical Byzantine Fault ToleranceDDoS分布式拒绝服务Distributed Denial of ServicePKI公钥基础设施Public Key InfrastructureTPS每秒事务处理个数Transactions Per Second4总体要求4.1联盟链的参与组织应不少于两个，运行节点宜不低于四个，各组织相互独立且拥有身份证书及保存数据的节点等资源。4.2联盟链应基于某种算法提供能追溯的数据结构如分布式账本，并通过以区块或其他组织形式为单位将一段时间内发生的交易数据进行存储和同

10、步。4.3应提供智能合约服务，具备将业务规则等集成到分布式应用程序中的能力。4.4应提供网络通信服务，保证节点之间能直接进行网络通信或能间接进行消息传递。在网络拓扑中，应防止单个节点故障而形成网络隔离。4.5应提供跨链服务，实现一个链到另一个链的通信协议。本文件不对跨链技术实现做要求。4.6应具备身份管理及权限控制机制，如基于合约、用户、区块链等级别分级进行权限控制。4.7应具备隐私保护机制，所有加密保护机制均应符合国家加密算法规定。4.8应具备安全防护机制，能抵抗或应对智能合约攻击、共识机制攻击、算法漏洞攻击、核心代码攻击、网络通讯攻击、基础协议缺陷等问题。5数据要求5.1数据结构5.1.1

11、应具有防篡改性，宜使用块链式或近似块链式的存储结构并使用哈希链接和嵌套保证数据无法被篡改。5.1.2应具有数据校验功能，任何一条记录被非法篡改后都可通过历史账本数据回溯以快速检验出来。5.1.3应具有可追溯性，任何历史数据的生成、变更、删除，均可追溯其发起者及达成共识者。5.2数据通信5.2.1通信连接建立前，应使用符合国家密码标准 GM/T 0003.3 的密钥交换技术生成公共密钥，并进行双向身份认证，确保通信双方身份信息真实、准确。5.2.2通信通道建立时，应使用工作密钥对通信过程中的整个报文或会话进行加密处理并使用符合国家密码标准的技术来建立安全通信通道，确保通信数据的保密性。5.2.3

12、通信协议制定时，应包含应对通信延时、中断、数据完整性被破坏等情况的处理机制，确保通信时数据的完整性。5.3数据存储5.3.1实行数据分类存储制度，涉及证书、私钥等重要/敏感信息可根据需求按本文件“12.1 加密要求”进行加密处理并设置访问权限。5.3.2执行数据可靠保护机制，应确保在系统断电、重启、网络异常等情况恢复后数据能够正确读写。T/FJBCA 001202245.3.3设立存储空间监控预警机制，应提供因存储空间问题导致的数据存储异常应急处理方案。5.4数据处理5.4.1身份数据应按照本文件“8 身份要求”进行身份核实。5.4.2需要共识的数据应根据数字签名机制对数据进行签名验签、数据合

13、法性验证及敏感信息验证后，根据共识要求达到共识，方可存入联盟链。5.4.3数据处理过程应符合本文件“12 安全要求”的各项安全要求。5.5数据同步5.5.1在新节点加入、节点出现数据缺失、新交易产生、新区块产生时，应进行数据同步或交易同步。5.5.2数据同步应在确保数据一致性、完整性的前提下进行，并提供相应的校验手段确保同步后参与共识的所有节点数据一致、完整。注：数据同步与参照节点无关。5.5.3交易同步应能覆盖到所有需对此交易达成共识的节点，且交易同步需在合理时间内完成。合理时间指在交易过期前能给交易处理和交易共识留出足够多处理时间。5.6数据保护5.6.1在区块链技术实施过程中应充分考虑上

14、链数据的隐私保护工作，对于不应公开的或部分公开的数据必须实施隐私保护。5.6.2优先采用密码学算法实现隐私保护，如杂凑函数、对称加密、非对称加密、零知识证明等；对于需进行数学计算的数据，优先考虑使用隐私计算技术，如同态加密、多方安全计算等。5.6.3应采用身份证书技术和数字签名技术确保数据真实、完整、可追溯。6共识机制6.1共识算法共识算法应具备一致性和可用性，应满足以下要求：a)应能够在参与节点互不信任的基础上达成共识；b)应支持节点独立进行智能合约的运行和验证，节点间不相互依赖，不相互影响；c)应具备一致性：任意节点发起更新账本请求，完成共识后，系统中参与共识的节点对该交易的处理的结果应该

15、是一致的。且账本状态更新后所有节点（包括参与共识的节点和不参与共识的节点）的账本最终状态一致；d)共识的达成应该在有限时间内完成，且该时间应能满足业务要求；e)应具备抗针对共识的恶意攻击的能力，能抵抗的攻击应至少包括女巫攻击、日蚀攻击、重放攻击、DDoS 攻击。6.2共识容错共识容错机制应满足以下要求：a)应能协调联盟链各参与方有序参与数据打包和共识过程，并保证各参与方的数据一致性；b)系统无故障节点或欺诈节点时，应能在规定时间内达成共识，输出正确结果；T/FJBCA 00120225c)在诚实节点数量超过(2n+1)/3，（n 为节点总数）的情况下，应能在预期时间内达成共识，并输出正确结果。

16、7智能合约7.1机制要求7.1.1智能合约的执行应在多方达到共识的前提下进行，未达成共识不可执行。7.1.2智能合约的执行是原子操作，执行过程中发生错误应回滚，所有的执行被回撤，没有中间态。7.1.3智能合约的执行应具备一致性，合约在所有参与共识节点上的执行结果应一致。合约重复执行时，在初始条件不变的前提下，执行结果保持不变。7.1.4智能合约应具备业务隔离性，不同合约业务数据互不干扰并按需隔离存储。7.1.5智能合约的执行需满足充分的检查，至少应包括：合约调用者身份为本联盟链参与组织颁发的证书，或者联盟链认可的证书或账户；合约调用内容（如针对接口和入参的签名）需有调用者签名并能验签通过；需有

17、足够节点对该调用做认可（如提供节点签名）；合约的执行需能通过共识算法，在节点间达成共识。7.2攻击防范要求7.2.1应有机制保证智能合约的执行需在预期时间内完成，防止系统因无法从无限循环等逻辑中跳出从而失去活性。7.2.2智能合约在编写中应充分考虑合约层面的安全风险，如数值溢出错误，本地环境数据获取（如使用本机时间）导致的无法共识等。7.2.3应有相应机制保障在系统遭受攻击、服务受到影响时，维护人员可人工干预，恢复服务。8身份要求8.1身份定义在联盟链系统中，身份信息采用 PKI 证书体系进行标识。证书格式和颁发过程需符合 ITU-T（国际电信联盟电信标准分局，International Te

18、lecom Union-Telecommunication Standardization Sector）定义的 X.509 证书标准。节点和用户均需通过证书证明其身份。证书用于交易提交和验签，加密通讯等多种场景。8.2证书颁发8.2.1身份证书由所在组织使用根 CA 证书或中间 CA 证书签发。签发组织需对其签发的证书负责，签发时需对证书使用人员身份完成认证后，方可签发。后续该证书提交的交易被认为是该组织授权的。8.2.2每个组织均需公开其根 CA 证书，每个参与共识的节点均需保存链上所有组织根 CA 的公钥，用于对交易发起者身份做认证；只有本联盟链参与组织颁发的证书，或明确被联盟链认可的证

19、书（如证书白名单）发起的交易方可被接受。8.3证书生命周期管理8.3.1应建立具有健全的证书生命周期的信息系统，确保生命周期内证书信息安全。T/FJBCA 001202268.3.2生命周期管理包括证书的申请、颁发、撤销；联盟链参与组织需有能力完成如上操作，并保证各项操作的安全性。8.3.3使用证书时，应检查证书的有效性。8.4节点标识8.4.1各节点应明确授权机构及管理员。8.4.2节点加入前，应给予其在系统内唯一的节点标识，提供与之对应的标识鉴别信息和标识凭证，并在凭证中指定节点角色，其中：a)标识鉴别信息应不易被仿冒；b)标识凭证应具有完整性和真实性。8.4.3节点之间传输加密前，应先通

20、过标识鉴别信息实现双向身份认证，建立一条安全的数据通信信道，并满足本文件“12.1 加密要求”。8.4.4应设立节点标识认证失败处理机制，采取结束通信、限制认证失败次数和超时自动结束等措施予以处理。9接口要求9.1接口应设计良好，具有可扩展性及兼容性，并隐藏底层实现细节。9.2接口的调用方法应有详细说明。应至少包括接口的功能、编码格式、参数、返回值、使用方式、错误信息。接口管理应符合附录 A 的规定。9.3接口调用应保障安全性，服务方和调用方应互相验证身份，并保障调用过程中数据隐私性及完整性，防止中间人攻击等攻击类型。例如可使用 TLS 算法保护调用过程。9.4应采用鉴权机制控制接口的访问权限

21、。10性能要求10.1交易性能10.1.1智能合约执行性能智能合约执行性能以简单转账（例如以太坊 ERC20 合约转账)为例，应满足以下要求：a)申明的智能合约调用 TPS 不小于 1500；b)以申明的 TPS 调用智能合约时，交易上链成功率不低于 95%；c)以申明的 TPS 调用智能合约时，交易延迟时间不超过 5 秒；d)应在异常场景发生并恢复后仍能维持智能合约调用交易性能。10.1.2查询性能查询性能应满足以下要求：a)区块块头信息查询性能应不低于 5000 条/秒，节点应能在异常场景恢复后保持块信息查询吞吐率；b)交易信息查询性能应不低于 2000 条/秒，节点应能在异常场景恢复后继

22、续保证交易信息查询吞吐率；T/FJBCA 00120227c)智能合约数据查询吞吐率宜不低于 5000 条/秒，节点应能在异常场景恢复后继续保证智能合约数据查询吞吐率；d)历史数据查询吞吐率宜不低于 1000 条/秒，节点宜在异常场景恢复后继续保证历史数据查询吞吐率。10.1.3交易和块的同步性能交易和块的同步性能应满足以下要求：a)交易的同步分为主动广播和被动同步，交易同步应在块的共识完成前完成。因此交易同步的性能会影响 TPS 的性能。交易同步性能体现在 TPS 要求中，请参考本文件“10.1.1 智能合约执行性能”；b)交易同步时，节点收到的冗余交易比例不高于申明的数值；c)节点在网络波

23、动，重启等异常场景恢复后，广播/同步交易的速率应能满足设计要求；d)节点同步并写入区块所耗费的时间应不高于出块时间。10.2交易确认时间单位时间内交易请求量不大于申明的 TPS 时，交易从发出到被确认处理完成的时间应不超过出块时间的 2 倍。11运维要求11.1系统监控11.1.1应具备对系统状态实时监控的能力，包括物理服务器状态、虚拟机状态、数据库服务状态、节点同步状态等。11.1.2应支持自定义设置监控采集数据资料库保存时间。11.1.3应支持自动警告推送功能。11.1.4宜具备系统状态监控结果实时可视化展示的能力。11.2节点管理11.2.1应在系统保持正常服务的前提下动态或静态增删节点

24、。11.2.2应对节点运行状态以及节点与其他节点的连接进行监控。11.2.3应对节点采用高可用的架构，用来应对部分节点的异常。如发现部分节点运行异常，应在不影响服务运行的同时及时进行问题的排查，在规定的时限内将节点恢复至正常状态或启动备用节点，以保证业务的正常运行。11.2.4应收集系统中运行的状态数据，包括节点的远端同步节点数、账本同步平均耗时、节点的健康状态等，并写入日志供测试或者审查用，如异常应及时预警并处理。如发现恶意或者欺诈节点传播恶意损坏的账本数据，或者有节点篡改账本，应先定位节点位置，获取详细信息。11.2.5宜能提供节点数据备份能力。11.2.6宜能提供新节点快速参与共识服务的

25、能力，如通过快照恢复节点。11.3日志管理应具备系统日志能力：T/FJBCA 00120228a)支持各类事件日志记录，日志需完整正确；b)支持对节点日志进行管理，可对各个节点日志进行检索。11.4密钥管理11.4.1密钥生成11.4.1.1密钥生成需使用保证安全性的算法接口，任何情况下均不可以被预测，且生成过程中，密钥不得泄露。11.4.1.2密钥算法类型和密钥长度需满足系统安全要求。11.4.2密钥存储11.4.2.1基于软件方案存储的密钥应实现对密钥的加密存储。11.4.2.2基于硬件方案存储的密钥应符合国家密码管理部门的硬件安全模块存储要求。11.4.2.3可使用经国家密码主管部门认可

26、的其他类型密钥存储方式。11.4.2.4宜避免集中存储密钥。11.4.3密钥使用11.4.3.1密钥应按需隔离使用。11.4.3.2应支持基于非对称密钥对实现认证算法和签名算法。11.4.3.3应支持基于非对称密钥对的加解密算法。11.5设备管理11.5.1加密机应放于专门区域，指定专人管理，并定期进行维护管理。11.5.2应采用白名单机制控制对加密机的访问，阻止非授权设备访问加密机。11.5.3在报废加密机前，应将加密机内的密钥完全清除，确保加密机内的密钥等敏感数据无法被恢复重用。11.5.4严格控制加密机的变更操作，经过审批后才可进行变更操作，并须留下变更相关的审计日志。11.5.5加密机

27、以外的设备应遵循 GB/T 222392019“信息安全技术网络安全等级保护基本要求”中的相关要求。11.5.6对网络中的节点性能，需要根据实际承载的业务场景协商接入标准。注：网络中节点性能指标包括CPU、内存、带宽等指标。11.6数据/漏洞维护管理11.6.1漏洞发现/修复要求11.6.1.1涵盖节点服务器自身漏洞、软件漏洞、智能合约漏洞等不同层次漏洞至少每月扫描一次。扫描时可合理采用第三方扫描工具。11.6.1.2漏洞扫描记录保持与扫描策略一致，发现漏洞及时提出修改方案并修复，对于无法修复的漏洞及时报告，如果漏洞修复影响到账本数据，则应通过共识协议进行数据的修正。系统日志留存记录，达到漏洞

28、修复可追溯的效果。11.6.2数据备份/恢复要求T/FJBCA 0012022911.6.2.1账本数据备份策略根据业务需要进行实时备份。11.6.2.2密钥等关键数据备份策略根据业务需要进行定期备份。11.6.2.3根据账本数据、密钥等关键数据的恢复策略定期进行恢复演练，最近一次恢复记录表明备份数据的可用性，保证在出现重大事件时能够及时的进行数据恢复。12安全要求12.1加密要求应使用符合中国国家标准的算法完成密码学操作，具体标准包括：GM/T 0003、GM/T 0004、GM/T 0009、GM/T 0010、GM/T 0015、GM/T 0028、GM/T 0029 等标准的规定。12

29、.2身份安全要求12.2.1应具有机密性，可采用对称和非对称加密技术，确保敏感信息不被窃取。12.2.2应具有完整性，可采用数字摘要确保身份信息不被篡改。12.2.3应具有真实性，身份鉴别可采用数字证书确保身份真实性。12.2.4应具有不可抵赖性，可采用数字签名确保数据发送方不可否认自己的信息。12.3网络传输安全12.3.1应在参与联盟链的节点之间建立安全传输通道，保证数据传输的完整性和不可篡改性。12.3.2应对数据和信息采取相应的防护措施，保证其能抵抗篡改、重放等主动或被动攻击。12.3.3应保证节点间通信过程中敏感信息字段或整个报文的保密性，宜采用密码学技术。12.3.4应确保信息在存

30、储、传输过程中不被非授权用户读取和篡改，可采用有权限的网络访问控制，在参与分布式账本节点之间构建虚拟专用网络（VPN），降低网络攻击造成的危害。12.4物理安全12.4.1场地安全部署物理数据中心及附属设施的，用于业务运行、数据存储和处理的物理设备需符合国家监管要求。12.4.2节点部署安全12.4.2.1应保证承担共识或记账的节点冗余部署，保证系统可用性；避免将所有承担共识或记账的节点部署在同一机房内，能在单一机房节点不可用时保证系统整体的可用性。12.4.2.2确保部署节点的硬件设备存储容量可扩展，避免因数据容量达到上限而无法同步账本。12.4.3硬件设备12.4.3.1应对设备运行状态、

31、资源使用情况等进行监控，能在发生异常时发出告警。12.4.3.2设备和存储介质在重用、报废或更换时，能对其承载的数据进行清除且不可恢复。T/FJBCA 001202210AA附录A（规范性）接口管理A.1外部接口外部接口评估内容见表 A.1。表 A.1外部接口评估内容表序号实现要求评估方法结果判定适用对象1传入分布式系统的数据应是可信的外部数据源，外部接口宜做限定来确保数据源的真实可信1.查阅材料2.测试系统1.系统接口文档中提供了外部数据源接入用户的账户安全认证方案，对使用的密码产品、时间源、时间戳技术等有安全可靠性要求。2.外部接口接入采取电子签名、电子数据摘要等技术手段确保数据不可篡改；

32、或者数据修改后能否被发现。金融业务系统、科技产品2外部接口应设置白名单制度1.查阅材料2.查看系统3.测试系统1.设计文档包含外部接口访问白名单及权限控制的说明，仅拥有管理员权限用户可设置访问白名单。2.外部接口访问调用时采取数字证书方式保证其身份真实性。经鉴权成功后，调用预言机服务。3.数据传输设备满足电子数据传输要求的安全功能，已正确启用和配置相关功能，并且日常运维流程中有保障此范围内功能的条款。金融业务系统、科技产品3系统应明确告知用户外部方法调用1.查阅材料2.查看系统3.测试系统1.设计文档包含接口调用方法的说明。2.系统提供了调用接口示例。3.系统提供了接口调用测试沙箱环境。金融业

33、务系统、科技产品4应保证数据源传输到分布式系统的过程中，数据真实可靠不被篡改，且传输到分布式系统中后，应保证各节点上数据的一致性1.查阅材料2.查看系统3.测试系统1.设计文档包含外部数据源传输数据到系统的安全通讯设计，对实现方式有完整说明，能够保证数据的真实可靠不被篡改。2.设计文档中包含系统存储外部数据结果基于节点共识描述。3.系统配置文件中外部接口安全通信配置参数、节点的配置以及安全配置与设计文档一致。4.安全工具扫描探测，测试外部接口传输数据到系统的流程，接口传入的数据无法进行篡改、替换，如果被更改会返回失败提示。5.系统收到接口测试数据后，每个节点上的数据测试结果符合预期结果。金融业

34、务系统、科技产品5应支持可信执行环境，保证数据处理过程的可信安全1.查阅材料2.查看系统3.测试系统1.设计文档包含外部数据可信执行环境完整设计，支持至少两种的可信环境执行方案。2.设计文档为开发人员提供不同类型的可信执行环境的接口API，并与设计文档支持的可信执行环境类型和版本一致。3.系统配置文件包含可信执行环境参数配置，符合设计文档。4.系统中网络和主机访问控制策略支持所用类型可信执行环境。5.安全工具扫描探测和攻击测试，测试可信环境数据执行，测试结果符合预期结果。金融业务系统、科技产品T/FJBCA 001202211A.2用户接口用户接口评估内容见表 A.2。表 A.2用户接口评估内

35、容表序号实现要求评估方法结果判定适用对象1应提供用户接口的详细说明文档查阅材料1.接口说明中有接口功能和接口使用方式的详细说明。2.接口说明中包含接口功能的详细描述，包括接口的通信协议标准、格式要求、输入输出参数、返回值等信息。其中对于接口的参数至少包括参数的类型、参数取值范围等信息。3.接口文档中有接口的错误码含义及产生原因相关描述。4.接口手册为开发人员提供与设计实现版本一致的说明。金融业务系统、科技产品2应对接口设置访问权限1.查阅材料2.查看系统1.设计文档对接口的访问控制有规划和设计，支持用户的权限管理到接口的粒度。用户对接口的访问有鉴权机制。2.设计文档为开发人员提供针对不同用户对

36、不同接口的鉴权机制及访问权限要求的详细描述。3.系统配置文件中用户的鉴权机制配置和接口访问控制配置与设计文档一致。金融业务系统、科技产品3应至少支持一种语言的 SDK 或者中间件1.查阅材料2.查看系统3.测试系统1.设计文档对支持的不同语言的 SDK 或中间件有规划和设计。2.设计文档对不同开发语言的SDK或中间件支持的功能和接口保持一致。3.设计文档为开发人员提供不同开发语言的 SDK 或中间的说明，并与设计实现支持的 SDK 或中间件保持一致。4.系统配置文件中不同开发语言的SDK和中间件的配置参数与设计文档一致。金融业务系统、科技产品4针对不同版本的区块链系统，应提供对应版本的所有相关

37、接口文档1.查阅材料2.查看系统1.设计文档对不同版本区块链系统，提供对不同接口层、不同版本的接口规划和设计。2.接口文档内对于不同版本系统涉及的接口有详细的功能描述及差异性解释。金融业务系统、科技产品A.3管理接口管理接口评估内容见表 A.3。表 A.3管理接口评估内容表序号实现要求评估方法结果判定适用对象1应提供管理接口说明1.查阅材料2.查看系统3.测试系统1.设计文档包含明确的管理接口功能说明。2.设计文档包含为开发人员提供对管理接口的功能、格式、方法、参数、返回值、使用方式等进行详细说明，接口文档包含完整的错误码和含义。3.系统管理接口的实现与设计文档说明一致。4.设计文档提供接口说

38、明，支持编写测试脚本进行管理接口测金融业务系统、科技产品T/FJBCA 001202212表 A.3（续）序号实现要求评估方法结果判定适用对象试。5.系统能够监控管理接口健康状态。6.系统能够记录管理接口操作日志，并提供日志格式及详细说明。2应保证只有登录节点 服 务 器 的 管 理员，才能访问系统管理员级别的运维接口1.查阅材料2.查看系统3.测试系统1.设计文档包含管理接口访问方式及权限控制说明。2.系统在接受管理员访问运维接口时，具有判断管理员是否已登录节点服务器的判断，且与方案说明一致。3.系统中只有登录节点服务器的管理员才能访问系统管理员级别的运维接口。4.设计文档包含管理员的职责和

39、权限。5.设计文档具备符合系统管理员登录、注销和注册机制的安全规范和标准。金融业务系统、科技产品3应确保系统管理员能使用管理接口创建 不 同 级 别 的 用户，并设置用户可访问的接口1.查阅材料2.查看系统1.设计文档包含管理接口创建用户的说明。2.设计文档包含支持 RBAC 等角色权限控制方案和说明。3.文档包含明确的系统管理员的职责和权限，并与实际相符。4.系统能完成用户创建，创建后的用户及其权限分配与设计文档相关说明一致。6.系统具备记录用户访问日志，便于监管审计。金融业务系统、科技产品4应控制系统管理员数目，并保证其安全性1.查阅材料2.查看系统1.设计文档包含系统管理员用户数量限制的

40、说明及系统管理员账户安全性设计的说明。2.设计文档含有系统管理员登录、注销和注册机制的安全规范和标准。3.系统管理用户创建数量与设计说明的一致。4.系统管理账户的安全性与设计文档相关要求一致。金融业务系统、科技产品5应确保管理接口仅做管理使用，并与其他接口分离1.查阅材料2.查看系统3.测试系统1.设计文档含有管理接口和其他接口有效隔离的设计说明。2.系统配置可以看到管理接口和其他接口的有效隔离措施，且与方案说明一致。3.系统中无法通过管理接口访问其他功能，通过其他接口也无法访问管理功能。金融业务系统、科技产品A.4系统间接口系统间接口评估内容见表 A.4。表 A.4系统间接口评估内容表序号实

41、现要求评估方法结果判定适用对象1应提供系统间接口功能、格式、方法、参数、返回值、使用方式、错误信息1.查阅材料2.查看系统1.提供系统间接口说明，指明对应的系统版本。2.系统间对应版本系统的实际调用表现与接口说明一致。金融业务系统、科技产品T/FJBCA 001202213表 A.4（续）序号实现要求评估方法结果判定适用对象等完整说明2应具有鉴权机制用于控制对接口的访问权限1.查阅材料2.查看系统3.测试系统1.提供系统间接口鉴权机制的完整说明。2.系统间接口的鉴权机制说明与系统的实际调用表现一致。3.系统间接口的鉴权机制包括身份鉴别、角色授权等能力。4.系统间接口鉴权机制的身份鉴别能区分合法

42、系统用户和不合法系统用户。5.系统间接口的鉴权机制的角色授权能对不同角色的合法系统用户分配不同范围的可访问接口清单。6.每一个接口得到授权后才能访问，包括进行授权操作的接口本身。7.每一次授权和鉴权都经过系统的所有共识节点达成共识。金融业务系统、科技产品3应能通过系统间接口访问其他区块链系统1.查阅材料2.查看系统1.提供本系统支持访问的其他系统类型和版本的完整说明，包括数据格式说明。2.对支持的其他系统的数据访问与文档说明一致。金融业务系统、科技产品4应提供系统间接口使其他区块链系统能访问本系统1.查阅材料2.查看系统1.设计文档、开发文档包含本系统提供访问的其他系统类型和版本的完整说明，包括接口版本、数据格式等内容。2.其他系统通过本系统提供的系统间接口进行数据访问时的表现与文档说明一致。金融业务系统、科技产品T/FJBCA 001202214参考文献1T/SIA 0072018区块链平台基础技术要求2JR/T 01932020区块链技术金融应用评估规则