金融|IMF研究报告:零售中央银行数字货币综述( 四 )



涉及创建数字代币来结算零售交易的CBDC安排 , 也将引发与结算批发交易类似的问题 。 尽管它们的分类不同 , 但它们的设计选择可能对安排的安全和效率产生影响 。 这包括可用性、发行和赎回过程、访问、基础资产/资金和索赔、转移机制、隐私和法规遵从性 , 以及互操作性(BIS, 2019) 。 以前存在的传统支付、清算和结算安排的强大法律基础可能也不一定明确地延伸到CBDC安排 , 需要覆盖更广泛的法律确定性来减轻潜在风险 。 因此 , 如果CBDC安排被确定为一个支付系统 , 并被认为具有系统重要性 , 它将被期待观察PFMI 。 此外 , 开发商可以考虑在设计CBDC安排时更符合国际标准 。

更普遍的是 , 为了获得终端用户的信任 , 需要对参与的第三方进行适当的监管和监督 。 最近国际货币基金组织金融科技关于加密资产监管和监督的报告讨论了私营加密资产监管框架 , 包括如何监管私营加密资产的提供、交易和托管(Cuervo等 , 2019) 。 虽然CBDC在市场风险等方面比私有加密资产要低 , 但在其他方面的风险可能是相似的 , 比如服务提供商的运营风险和违约风险 。 许多国家现有的货币条例也将为与CBDC合作的实体的适当条例提供有用的参考 。 对参与第三方进行适当的监管和监督 , 有利于CBDC生态系统的社会信任实现 。 此外 , CBDC本身(如重要的产品特性)的透明度也很重要 , 特别是在可能对用户征收费用或负利率的情况下 。
网络安全注意事项不断变化的复杂网络安全威胁在不同的组件或级别危及CBDC , 为恶意用户带来丰厚的回报 。 网络安全对任何支付基础设施都是一个持续且重大的风险(BIS, 2016) 。 这就强调了中央银行设计、建设和运行一个安全、有弹性的CBDC生态系统的重要性 。 这将要求中央银行专注于两个主要的信息技术(IT)安全组成部分:

  • 审查并加强中央银行的IT运营弹性及安全状况 。 主要组件是中央银行内部IT流程、技术和技能 , 用以维持中央银行网络、集成系统、应用程序和数据的最高级别保障 。 内部IT流程应与最佳实践相保持一致(例如 , 美国国土安全部 , 2016年) , 并强化安全运营中心等关键角色 , 无论是由中央银行内部运营还是委托第三方运营 。
  • 加强围绕CBDC组件的设计、实施和部署的安全活动以及影响整个CBDC生态系统的安全决策 (见下文) 。
下面介绍一种加强CBDC设计、实现和部署的典型双层方法 。 每一层都需要适当的安全控制和实践 。 主要目标是按照“深入防御”的方式设计CBDC , 并在项目的初始阶段而不是后期阶段考虑安全性 。
  • 业务和流程层 。 该层依赖于早期的决策和中央银行的安全工作实践来管理人员、流程和技术 。 该层的安全性只能与上述中央银行的操作弹性和安全态势相匹配 。 目标是能够持续降低风险 , 如弱访问模型、特权升级【49】、滥用特权功能、过度许可、缺乏对源代码的保护、数字货币发行或停用过程中的缺陷 。 中央银行最好通过专门的独立第三方来验证其运作弹性和安全态势 。 附录2更详细地讨论了这些层的一些关注点 。

  • 基础设施和应用层 。 该层可以利用已建立的框架 , 如开放系统互连(OSI, 1994)模型 , 以正确的粒度级别执行威胁建模和架构风险分析 。 ITU(2019)引入了一个有用的统一安全模型(USM)来连接目标和相应的威胁 , 以确定一组特定的保护方案 。 像OSI或USM这样的模型 , 有时一起使用 , 可以帮助执行系统安全威胁建模 , 显著减少在CBDC的基础设施和应用层漏掉重要风险的机会(图7)
与任何易受恶意或非恶意事件影响的关键系统一样 , 在设计阶段实施了严格的安全活动和适当的预防控制(NIST, 2020) 。 这些安全威胁预防包括(i) CBDC架构风险分析 , 以识别任何安全设计缺陷 , 包括智能合同设计和与CBDC账本集成 , 无论基于DLT还是非DLT(ii)安全威胁建模的设计、集成和数据流 , 以确定总体CBDC目标、威胁和对策(iii)手动和自动安全代码审核 , 以验证CBDC的关键组件(包括智能合约) , 并识别和补救源代码中的任何漏洞(iv)手动和自动渗透测试 , 以检查暴露的组件 , 达到CBDC生态系统的最高水平的保证 。 这些活动应由独立的网络安全保障专家进行 , 并应定期重复进行 , 以保持整个CBDC生态系统的最高保障水平(附录2) 。


推荐阅读