1、 金融行业云原生安全体系研究报告 北京金融科技产业联盟 2024 年 4 月 版权声明 本报告版权属于北京金融科技产业联盟，并受法律保护。转载、编摘或利用其他方式使用本白皮书文字或观点的，应注明来源。违反上述声明者，将被追究相关法律责任。编制委员会 编委会成员：聂丽琴 赵 海 陈 芳 苏建明 严羽楠 张 升 秦 玮 董金程 李晓敦 杨 杰 潘 华 万 化 编写组成员：府淼淼 王文柏 袁思思 苏 涵 金 睿 姜 城 范鑫禹 旷亚和 朱鑫栋 邢文静 周 杰 李 钢 陈德锋 吴 猛 成 涛 宋 宁 丁 涛 陆绍益 赵汉杰 严 伟 罗逸枫 黄建德 李梓铭 袁 晟 黄金坤 陈靖远 郭思麟 浦 明 张小勇

2、 钱 岩 张 威 廖 军 张京东 金哲磊 张 龙 鲁 帅 程 度 胡 俊 李 漫 何正民 朱 超 李 鹏 石 伟 郑三军 路俊杰 李 根 刘静远 张 政 白黎明 熊永灿 张婉莹 左伟震 张晓居 杨冬富 纪兆钢 刘英杰 王广驰 张剑强 杨增宇 常 青 刘奇志 张宪铎 宋子虎 曾志强 何 琰 吴国友 王宏刚 张汝成 郭 洋 刘逸伦 刘 丹 李高峰 王子健 何 鑫 于雪松 赵 月 姜英伟 李雁南 王兆阳 高浩浩 赵佳祥 刘海洁 郑 驰 王道谊 赵宇轩 黄莉群 牟 晨 史巍威 詹汉培 王明亮 贾腾飞 编审：黄本涛 刘昌娟 统稿：王文柏 施森佳 王晓云 参编单位:牵头单位：牵头单位：北京金融科技产业联盟

3、秘书处、中国银联股份有限公司 联合牵头单位：联合牵头单位：中国工商银行股份有限公司、中国农业银行股份有限公司、中国建设银行股份有限公司、中国邮政储蓄银行股份有限公司、上海浦东发展银行股份有限公司、建信金融科技有限责任公司、北京长亭科技有限公司、绿盟科技集团股份有限公司、阿里云计算有限公司、亚信科技（成都）有限公司、北京升鑫网络科技有限公司（青藤云安全）、奇安信网神信息技术（北京）股份有限公司、北京小佑网络科技有限公司 参与单位：参与单位：中国民生银行股份有限公司、中国光大银行股份有限公司、平安银行股份有限公司、北京银行股份有限公司、中央国债登记结算有限责任公司、中债金科信息技术有限公司、中国信

4、息通信科技集团有限公司、北京数字认证股份有限公司、深信服科技股份有限公司、杭州安恒信息技术股份有限公司 目 录 一、概述.1（一）背景.1（二）定义.12（三）安全架构.13（四）研究意义.36 二、云原生安全体系.38（一）云原生安全体系概述.38（二）云原生研发运维安全.44（三）云原生应用与数据安全.73（四）云原生计算环境与基础设施安全.116（五）云原生安全管理.140（六）关键技术方案创新.141 三、应用案例.169（一）云原生研发运维安全.169（二）云原生应用与数据安全.183（三）云原生计算环境与基础设施安全.194（四）云原生安全管理.201 四、总结和展望.209（一）

5、金融行业云原生安全研究总结.209（二）云原生安全技术路线展望.210 五、附表.213 六、参考文献.290 1 一、概述（一）背景（一）背景 1 1政策发展背景政策发展背景 1 1）国外政策）国外政策 网络安全框架（Cybersecurity Framework，简称 CSF）是美国国家标准与技术研究院（National Institute of Standards and Technology，简称 NIST）发布的一项具有重大影响力的网络安全标准，该框架于 2014 年首次发布、2018 年进行了首次修订，2023 年 8 月发布了 CSF 2.0 的草案版本。该框架的核心目标在于协助

6、各类组织提升其网络安全防护、检测、响应和恢复能力，以有效应对不断演化的网络安全威胁。该框架提供了一套全面且系统的网络安全管理方法，包括安全控制措施、安全培训、安全漏洞修补流程等，以及安全技术与管理方面的指南，如基础设施安全建设、安全策略制定等。该框架对于企业构建云安全管理体系具有重要的参考价值，可以帮助企业更好地管理云服务安全并确保数据和系统的安全性。此外，该框架还推动了一系列相关的网络安全标准的发展，如 ISO 27001、COBIT 等，同时也促进了各类解决方案的发展，如安全审计、安全管理等，这些标准和解决方案不仅有助于提高企业的网络安全水平，更进一步推动了整个行业的网络安全发展。通 用

7、数 据 保 护 条 例 （General Data Protection Regulation，简称 GDPR）是欧洲的一项重要法规，旨在全方位地保护公民的个人信息。该条例要求数据控制者和处理者必须确保个人信息的保密性、完整性和可操作性，任何组织机构不得以任2 何理由未经授权地泄露、修改或删除个人信息。为了应对这个条例，云服务提供商和使用者必须加强云环境下个人信息的安全保护和合规管理。这个条例不仅为云服务提供商设定了新的标准，也为云服务使用者提供了保障，确保他们的数据在云端的安全性。因此，通用数据保护条例在推动云服务提供商和使用者采取必要措施，加强云环境下个人信息的安全保护和合规管理方面，起着

8、至关重要的作用。云安全联盟（Cloud Security Alliance，简称 CSA），这一组织持续进行云安全的研究与培训工作，并发布云安全知识体系认证（Certification of Cloud Security Knowledge，简称CCSK），这对推动云安全的可测量性与人才培养有积极作用，有利于产业的健康发展。该联盟的贡献不仅在于理论层面，更涉及实际应用的探索与实施。云安全联盟 CSA 通过发布 CCSK 认证，为云服务提供商和用户提供了一个衡量云服务安全性的标准，为云服务提供商之间的互操作奠定了基础。此外，该联盟还致力于增强云服务用户的安全意识，通过培训计划和宣传材料等方式，帮

9、助用户更好地理解和使用云服务。这些举措有助于提升整个云安全领域的水平，进一步促进产业的健康发展。总之，云安全联盟 CSA 在推动云安全领域的发展中扮演着重要的角色，其研究成果和举措为云服务提供商提供了参考和指导，也为云安全用户提供了更安全、更可靠的云服务体验。健 康 保 险 流 通 与 责 任 法 案 （Health Insurance Portability and Accountability Act，简称 HIPAA 法案）和 卫 生 信 息 技 术 促 进 经 济 和 临 床 健 康 法 案 （Health 3 Information Technology for Economic a

10、nd Clinical Health Act，简称 HITECH 法案）是两个对美国医疗健康领域具有重要影响的法案。这两个法案对医疗数据保护和电子健康记录管理提出了严格的要求。HIPAA 法案旨在提高医疗保险的可携带性和加强医疗信息的保密性。该法案要求医疗保险公司、医院和医生等医疗信息处理机构保护患者的隐私，违规者将面临严厉的处罚。HIPAA 法案中的隐私规则要求医疗保健提供者、保险公司和相关机构遵守严格的数据保护标准，以防止患者信息的未经授权地访问和使用。HITECH 法案旨在促进电子健康记录的普及和使用。该法案要求医疗机构实施安全的电子健康记录系统，以确保数据的机密性和完整性。HITECH

11、 法案还规定了违反隐私规则的医疗机构将面临的严厉处罚，这进一步强调了医疗数据保护的重要性。金融行业在处理个人健康信息方面扮演着重要角色，这些法案的数据保护要求同样适用于金融行业。支付卡行业数据安全标准（Payment Card Industry Data Security Standard，简称 PCI-DSS）是由支付卡行业数据安全标准委员会（PCI SSC）发布的一套全球性的数据安全标准。该标准旨在确保信用卡信息的保密性、完整性和可用性，以防止数据泄露和欺诈行为。PCI-DSS 对数据传输安全、身份认证机制、数据加密技术、脆弱性管理和安全补丁、物理和环境安全。PCI-DSS为金融行业提供了

12、一套严格的数据安全标准，有助于保障金融业务中的支付安全和客户隐私，确保云原生环境在处理信用卡信息时符合相关的安全规范，可以帮助金融机构满足相关的监管要求，减少潜在的数据泄露风险。4 2 2）国内政策）国内政策 中华人民共和国网络安全法是一项非常重要的法律，明确规定了网络运营者所应承担的安全保护义务。该法律要求网络运营者，特别是那些运营关键信息基础设施的网络，必须在技术和管理上采取必要的安全保护措施。这些措施旨在保护网络系统的安全，防止网络攻击、数据泄露等安全事件的发生。这一法律的实施，进一步推动了云服务提供商加大在网络安全方面的投入和合规力度。这些云服务提供商必须采取相应的安全措施，以确保其客

13、户的数据和信息安全得到充分保障。同时，这些提供商也需要遵守相关法律法规，以确保其业务运营的合规性。法律对于推动云服务行业的发展和规范具有重要意义。国家网络空间安全战略 为我国的网络空间安全发展指明了方向。该战略明确提出了要加快推进网络空间治理体系和规则建设的核心目标，以完善网络安全标准体系为基础，全面提升我国在网络空间安全方面的综合实力。其中，推动关键信息基础设施安全保护是战略中的一项重要任务，以保障这些设施在网络空间中能够安全、稳定地运行，有效防范各类网络安全事件的发生。这一战略的提出，为云原生安全发展提供了重要的指导思想和行动纲领。云原生安全是一种以云为基础、以应用为核心的安全理念，强调在

14、应用开发、部署和运行过程中，采用自动化、智能化、敏捷化的安全技术手段和管理方法，保障云环境中的数据安全和应用安全。在战略的指引下，云服务提供商需要加大在安全方面的投入力度，积极采用先进的安全技术和管理手段，确保云环境的安全和合规。同时，战略还要求网络运营者采取技术上和管理 5 上必要的安全保护措施，这进一步推动了云服务提供商加大安全投入和加大合规力度，为云原生安全发展注入了强大的动力。中华人民共和国个人信息保护法 是一项具有重大影响的法律，该法律对采用云服务处理个人信息的企业与组织提出了严格的安全保护规定。该法的实施，有效地推动了云环境下的个人信息生命周期的标准化管理和安全控制，为个人信息的安

15、全与隐私保护提供了坚实的法律基础。该法规定，企业与组织在进行个人信息处理活动时，必须严格遵守相关法律法规，确保个人信息的安全性和隐私性。对于采用云服务进行个人信息处理的业务，法律特别强调了保障安全性和隐私的重要性。因此，针对个人信息云安全问题，已研发并应用了多种解决方案，以满足法律对安全性与隐私保护的要求。这些解决方案不仅涵盖了技术层面的措施，如数据加密和安全存储等，还包括管理层的措施，如构建完善的信息安全管理制度和应急响应机制等。这些措施的实施，能够有效地保护个人信息的安全和隐私，防止信息泄露、篡改或损坏。此外，该法还鼓励企业与组织采用标准化的管理方式来保护个人信息，这意味着在信息的收集、存

16、储、处理和利用等各个环节上，企业与组织均需制定明确的标准和规范，以确保个人信息得到合法、公正、合理的保护。同时，该法的实施，不仅对采用云服务处理个人信息的企业与组织提出了安全保护要求，还有效地推动了云环境下的个人信息生命周期的标准化管理与安全控制；这不仅强化了个人信息保护工作的实施，也为个人信息的安全和隐私保护提供了坚实的法律保障。网络安全等级保护制度 要求对不同安全等级的信息系统 6 采取相应的安全防护措施，这一制度为云安全管理体系标准的制定提供了重要的基础，同时也促进了云原生环境安全管控规范的形成。该制度的核心思想是将不同的信息系统划分为不同的安全等级，包括一级、二级、三级、四级等，并针对

17、每个等级采取相应的安全防护措施，包括物理安全、网络安全、主机安全、应用安全、数据安全等多个方面，这些措施必须严格遵守国家和行业标准，以确保信息系统的安全可靠。在云原生环境中，制定相应的安全管控规范同样至关重要。云原生环境是一种高度动态、高度自动化的 IT 环境，与传统 IT环境相比，具有更高的灵活性和可扩展性，但也因此带来了更多的安全风险。通过网络安全等级保护制度的实施，更好地制定云原生环境的安全管控规范。这些规范将覆盖基础设施、平台组件、应用等多个层面，包括安全设计、安全配置、安全漏洞修复等多个方面。这些规范的制定将有助于确保云原生环境的整体安全性，保护用户的数据和隐私不受侵犯。2 2金融行

18、业发展背景金融行业发展背景 1 1）金融行业数字化转型势在必行金融行业数字化转型势在必行 客户体验需求正日益提升，驱动金融机构加快其数字化转型的步伐，促进数字化生活更加便捷、高效，以更好地满足客户的需求。科技创新压力逐渐加大，给市场带来了前所未有的挑战。这种压力促使传统金融机构加速采用云计算与大数据等前沿技术，以实现业务的科技创新和突破。金融机构运营成本迅速上升。为了应对这一挑战，金融机构 7 开始积极寻求采用新技术降低成本的有效途径，以确保业务的持续发展和盈利。监管要求不断加强，特别是在服务连续性和数据安全能力方面。这进一步推动了金融机构加快基于云的数字化转型，以满足监管要求并提升整体竞争力

19、。2 2）云原生技术带来机遇与挑战云原生技术带来机遇与挑战 优化客户体验。微服务架构提高业务可靠性，有助于金融机构提供连续稳定的客户体验。提高业务灵活性。云原生技术提高 IT 资源灵活性，帮助金融机构快速部署新产品与服务，提高业务创新力。减少运营合规成本。云原生技术实现自动化部署，简化金融机构的应用系统运营和合规验证流程，降低运营合规成本。增加安全风险暴露面。云原生环境的分布式与开放特性使金融数据安全面临更大威胁，这制约其广泛应用。云原生领域人才短缺。云原生技术的特殊性使其人才培养难度较大，这也制约了金融机构的转型步伐。3 3）云原生安全的重要作用云原生安全的重要作用 云原生安全技术与解决方案

20、可以有效解决金融机构采用云原生技术所面临的安全与合规风险，实现安全的云原生金融，具有重要作用：一是保障服务稳定。防护金融业务环境，保证服务的高可用性与连续性。二是防护数据安全。保护敏感数据，防止数据泄露与攻击，达到监管要求。8 三是简化合规。帮助构建标准化安全治理体系，自动化合规验证流程，降低成本。四是释放技术潜力。降低采用新技术的风险，推动金融机构安心采纳云原生技术，实现数字化转型。综上，金融行业数字化转型势在必行，云原生技术带来机遇与挑战并存。云原生安全的发展与应用，有利于金融机构深化转型，拥抱云原生，实现安全稳定与合规高效。但也面临技术与人才等方面短板，需要各界加强合作推进。3 3发展历

21、程发展历程 云安全产业发展历程主要经历了以下阶段：云计算起步时期（2000 年前）、基础安全服务萌芽（20002010 年）、安全产业加速发展（20102015 年）、云原生应用安全兴起（2015 年后）以及数据安全与合规加速（近年来）。安全技术、服务与产品不断演进，促进着云计算环境的营造与应用。云计算起步时期（云计算起步时期（20002000 年前），年前），云计算技术刚刚起步，云安全并不是相关企业和组织最关心的问题。当时，云计算的概念还不太为人知晓，公有云厂商的主要关注构建基础设施并提供基本的计算、存储和网络资源。安全机制较为简单，主要依靠网络隔离和用户管理维持。基础安全服务萌芽（基础安全

22、服务萌芽（2000200020102010 年），年），随着云计算技术的逐渐普及并被企业广泛采用，云计算安全问题开始受到了业界更多的关注。例如，公有云服务提供商 Amazon Web Services（AWS）开始提供一些基本的安全服务，如身份与访问管理和密钥管理等，这些服务的推出旨在帮助企业更好地管理其在云环境中的安全 9 性和访问权限。此外，第三方安全厂商也针对云计算安全推出了各种解决方案，如防火墙和漏洞扫描等。随着云计算的快速发展，安全厂商们开始将他们的安全技术和产品进行云端适配和优化，以应对不断变化的云计算安全威胁和挑战。在此期间，随着云计算被越来越多的企业所采纳和应用，安全问题变得更

23、加重要和引人注目。为了应对这些挑战，AWS 于2010 年开始提供云上身份与访问管理服务（IAM），该服务提供基于角色的访问控制和多重身份验证等功能，帮助企业更好地管理和控制其在云环境中的访问权限。同时，第三方安全厂商也开始推出各种适用于云计算的安全产品，这些产品包括云版本的防火墙和漏洞扫描等解决方案。随着云安全威胁的不断变化和发展，这些安全产品和解决方案也在不断演进和改进，以应对不断变化的云计算安全威胁和挑战。另外，云安全联盟（CSA）于 2008 年成立，这是一个由多个厂商和组织组成的联盟，旨在制定云安全的最佳实践、评估方法和标准等。该联盟的成立对于推动云计算安全技术的发展和应用起到了积极

24、的作用，并为云计算用户提供了更好的安全保障和服务。安全产业加速发展（安全产业加速发展（20015 年），年），云安全问题成为企业采用公有云的主要阻碍之一。随着公有云服务的普及，安全问题受到了厂商们的重视，并在安全方面加大了投入。为满足日益增长的安全需求，公有云厂商们推出了多种安全服务，如日志服务、DDoS 防护和 Web 应用防火墙等。这些服务能够帮助企业更好地管理和监控其云环境中的安全状况。与此同时，第三方厂商们也纷纷推出了一些创新产品，如云 10 工作负载防护和云访问安全代理等。这些产品能够更好地保护企业的云环境，使其免受恶意攻击和潜在威胁的影响。此外，一些第三方认证

25、如 ISO 27017 和 SOC3 也开始发布，为企业提供了更加可靠的安全保障，并加速了云安全的采用。这些认证的推出标志着云安全进入了一个更加成熟和规范化的阶段。云原生应用安全兴起云原生应用安全兴起（20152015 年后）年后），随着云原生应用的高速发展和普及，采用微服务的分布式应用逐渐被广大企业和组织所采纳。然而，随之而来的是应用安全问题也日益凸显。在此背景下，DevOps 文化进一步强调了云原生应用的安全性。因此，在云原生应用的设计、开发、测试和部署过程中，安全性应始终是重要环节。公有云厂商积极响应该需求，提供了全方位的云原生应用安全防护，包括容器安全、服务网格、API 网关等。这些公

26、有云厂商不仅提供了丰富的安全产品和服务，还为用户提供了更加灵活的定制化选择，满足不同用户的安全需求。除了公有云厂商的努力，第三方安全厂商也不断推陈出新，针对云原生应用推出了各种 WAF（Web 应用防火墙）、容器安全和服务 Mesh 安全产品。这些产品针对云原生应用的特点和需求，提供了更加精细化的安全防护功能。例如，针对容器安全的防护产品可以帮助用户实时监测和防止容器逃逸、容器间通信攻击等问题；服务 Mesh 安全产品则可以保护微服务之间的通信安全，防止 API 被攻击或者被恶意篡改。云原生应用安全逐渐成为一个新兴领域，围绕容器、服务网格、API 等技术与架构，提供了一系列针对性强的加固、监控

27、与 11 控制产品。这些产品不仅保障了云原生应用的安全性，也加速了云原生应用的发展。例如，AWS 于 2017 年推出了零信任网络与Detective，Azure 于 2018 年推出了容器服务 AKE（Azure Kubernetes 引擎），这些产品的推出进一步推动了云原生应用安全的发展。第三方厂商推出的产品如 NSX-T（网络虚拟化平台）、Istio（服务网格平台）和 Apigee（API 管理平台）等也加速了这一时期云原生安全的发展。这些产品为用户提供了更加灵活的网络虚拟化解决方案、更加精细化的服务管理和更加高效的应用程序接口管理，从而进一步提升了云原生应用的安全性和可用性。同时，这些

28、产品的推出也进一步促进了云原生应用安全市场的繁荣发展。数据安全与合规加速（近年来），数据安全与合规加速（近年来），随着数据上云的需求增加，数据安全和合规成为企业最关心的问题。云厂商推出密钥管理、日志检测和保留等服务。第三方数据安全与合规产品也蓬勃发展。云计算产业与安全领域发展相互促进，安全问题的变化推动新的技术和产品不断涌现，随着更多受管制的数据被置于云上，数据安全与合规成为企业最为关心的问题之一。AWS、Azure 与 GCP 相继推出数据安全与合规服务，如密钥管理、日志检测与保留等。第三方厂商也推出各类数据安全与法规遵从产品，以满足客户的要求。根据 Gartner 研究，在 2018-20

29、19 年度企业 IT 支出中，美国和加拿大地区合规安全支出增长最快，达到两位数，预计未来几年也将保持较高增长率。数据隐私保护条例如欧盟 GDPR 和加 12 州消费者隐私法案 CCPA，促使企业加大数据安全与合规投资以遵守法规要求。云服务商通过增强合规报告、第三方认证和专业服务等方式来减轻客户的合规负担，帮助企业构建安全的云数据环境。第三方厂商提供的数据安全与合规产品也越来越丰富，包括云访问安全代理、云原生应用安全和 DevSecOps 工具等。信息安全服务企业也推出各类合规咨询与审计服务以应对企业的需求。总之，治理、风险与合规（GRC）迅速成为云安全一个关键的领域。云服务商和 ISV 会围绕

30、数据隐私、合规要求和行业法规推出更多安全产品与服务，帮助企业通过安全与合规措施获得更高的业务灵活性与成本效益。这也为信息安全服务企业带来大量商机。（二）定义（二）定义 云原生安全包含两层含义：面向云原生环境的安全和具有云原生特征的安全。云原生安全所保护的对象，是指以容器技术为基础底座，以DevOps、面向服务等云原生理念进行开发并以微服务等云原生架构构建的业务系统共同组成的信息系统。容器服务、Service Mesh 与 Serverless 等均属于云原生范畴，是以容器技术为核心基础的不同交付/服务模式，不同的服务模式责任模型有所不同。1 1面向云原生环境的安全面向云原生环境的安全 面向云原

31、生环境的安全的目标是防护云原生环境中基础设施、编排系统和微服务等系统的安全。这类安全机制不一定具备云原生的特性，比如不是容器化、可编排的，而是以传统模式部 13 署的，甚至是硬件设备，但其作用是保护日益普及的云原生环境。例如对于容器云（CaaS）的抗拒绝服务，可采用分布式拒绝服务缓解（DDoS Mitigation）机制，但考虑到性能限制，一般此类缓解机制都是以硬件形态交付和部署的，正是这种传统安全机制保障了面向云原生系统的可用性。当然，云原生内部的安全机制以云原生形态居多，例如服务网格的安全通常使用旁挂串接（Sidecar）的安全容器，微服务 API 安全通常使用微 API 网关容器，这些安

32、全容器都是云原生的部署模式，具有云原生的特性。2 2具有云原生特征的安全具有云原生特征的安全 云原生环境中的安全防护会天然地要求一些主机侧的安全机制具有云原生特性。例如容器环境的短生命周期、业务变更极其迅速，导致访问控制、入侵检测等安全机制偏向于特权容器等形态。此外，还要求可以根据编排系统的业务调度策略进行安全策略的动态调整。要满足这两个要求，最后的安全机制必然与云原生系统融合，体现出明显的云原生特性。3 3云原生安全的关键点云原生安全的关键点 容器不是轻量级的虚拟化，容器安全不是轻量级的虚拟化安全。虚拟化安全关注的是资源，云原生安全关注的是应用。安全左移是云原生安全的必经之路。（三）安全架构

33、（三）安全架构 1 1概述概述 云原生应用已经成为企业数字化转型的重要支撑，云原生安全也是转型过程中不可绕过的一点。一方面云原生应用的复杂性和分布式特性也带来了新的安全挑战，另一方面云原生应用也是 14 从传统技术体系演进形成，并且传统技术体系仍是其技术底座。因此云原生安全研究过程中既要研究思考云原生技术应用所带来的新的安全特性和策略，也要继承发展传统通用的安全技术体系。在云原生技术发展过程中，产业界、科研界等已经提出安全模型标准、安全管理体系、通用安全架构等，并开展不同程度的实践，例如典型的 ISO/IEC ISO27001 信息安全管理体系、数据安全能力成熟度模型（DSMM）、NIST S

34、P800 系列标准、SABSA 安全架构等，这些标准模型不依托某一个具体技术实现，而是以不同的角度和思路，为企业建立一套完整的信息安全管理流程和控制措施，通过系统化、体系化和标准化的方式方法来管理和保护企业信息系统应用和数据。而在云原生环境中，目前也有一些较为成熟的安全标准和架构，为企业提供一套详细的操作步骤和最佳实践，指导企业在云原生环境中实现有效的应用和数据防护。云安全核心主题范围（Gartner）就云原生环境下安全架构和高级安全特性有过一个相对完整的梳理（见图 1）。主要包括网络安全网格架构（CSMA）、云原生应用程序保护平台（CNAPP）等。15 图 1 云安全核心主题范围（Gartn

35、er）1 本文将对现有的通用安全模型标准、安全管理体系、通用安全架构，以及云原生技术环境下的一些安全架构和高级安全特性进行简要介绍，为云原生安全架构的研究提供参考（详见图 2）。图 2 安全架构概览 1“Guide to Cloud Security Concepts”,URL:https:/ 16 2 2通用安全架构通用安全架构 1 1）NISTNIST 网络安全框架网络安全框架 2 2 随着网络技术的发展和信息化的普及，网络安全问题日益突出。为了降低关键基础设施网络风险，美国政府委托国家标准与技术研究所（NIST）制定了 NIST 网络安全框架（NIST CSF）。该框架于 2014 年首

36、次发布，2018 年进行了修订，以符合现代网络安全标准。NIST 网络安全框架是一个基于风险的网络安全框架，提供组织制定一致的迭代方法来识别、评估和管理网络安全风险。该框架提供了一个通用的框架，帮助组织识别、评估和管理网络安全风险。该框架旨在促进信息共享、合作和协调，增强网络安全意识和能力，从而保护关键基础设施免受网络攻击。该框架的核心内容是风险管理，通过识别、评估和管理网络安全风险，组织可以更好地保护其基础设施。该框架将风险管理过程分为五个步骤：识别（Identify）、保护（Protect）、检测（Detect）、响应（Response）和恢复（Recovery）。为了实现网络安全，组织应

37、采取综合的安全措施，包括几个方面：一是识别和分析网络安全风险，确定需要保护的信息资产；二是制定安全政策和程序，确保员工了解和遵守安全规定；三是采用合适的技术和工具来检测和预防网络攻击；四是制定应急计划和响应策略，以便及时应对安全事件；五是实施恢复策略，确保系统能够在遭受攻击后迅速恢复正 2 NIST（全称 National Institute of Standards and Technology)即美国国家标准与技术研究院，是一个物理科学实验室和非监管性机构，隶属于美国商务部。NIST 的历史可以追溯到 1901 年，他起源于国会授权建立的国家标准局（National Bureau of S

38、tandards)。1988 年，国家标准局更名为今天的国家标准与技术研究院（NIST)，官网地址是 https：/www.nist.gov/。17 常运行。NIST 网络安全框架的实施可以帮助组织实现以下效果：一是增强网络安全意识和能力，增强员工的网络安全意识和技能；二是降低网络安全风险，减少系统遭受攻击的可能性；三是提高系统的可靠性和稳定性，确保系统能够在遭受攻击后迅速恢复正常运行；四是保护组织的声誉和形象，避免因安全事件而造成的负面影响。总之，NIST网络安全框架是一个基于风险的网络安全框架，旨在帮助组织识别、评估和管理网络安全风险。通过采取综合的安全措施和关键活动，组织可以增强网络安全

39、意识和能力，降低网络安全风险，提高系统的可靠性和稳定性，保护组织的声誉和形象。2 2）SABSASABSA 安全架构安全架构 SABSA 是一种安全架构，是一种基于风险的、过程化的、以信息为中心的安全管理模型，旨在帮助组织有效地管理和保护其信息资产。SABSA 模型包括六个组成部分：背景层、概念层、逻辑层、物理层、组件层和运营层，如表 1 所示。SABSA 框架旨在帮助组织建立和实施有效的安全计划，以应对不断变化的威胁和风险。SABSA 安全架构层及其对云安全的价值，如图 3 所示。表 1 SABSA 安全模型 资产（什么）动机（为什么）过程（如何）人（谁）地点（何地）时间（何时）背景层 业务

40、 业务风险模型 业务过程模型 业务组织和关系 业务地理布局 业务时间依赖性 18 概念层 业务属性配置文件 控制目标 安全战略和架构分层 安全实体模型和信任框架 安全域模型 安全有效期和截止时间 逻辑层 业务信息模型 安全策略 安全服务 实体概要和特权配置文件 安全域定义和关系 安全过程循环 物理层 业务数据模型 安全规则、实践和规程 安全机制 用户、应用程序和用户接口 平台和网络基础设施 控制结构执行 组件层 数据结构细节 安全标准 安全产品和工具 标识、功能、行为和访问控制列表（ACL）过程、节点、地址和协议 安全步骤计时和顺序 运营层 业务连续性保障 运营风险管理 安全服务管理和支持 应

41、用程序和用户管理与支持 站点、网络和平台的安全 安全运营日程 图 3 SABSA 安全架构层及其对云安全的价值（Gartner）3 3 3）CSMACSMA-网络安全网格架构网络安全网格架构 网络安全网格（Cybersecurity Mesh Architecture，CSMA）3 “Essential Skills for Cloud Security Architects”,URL:https:/ 19 是一种现代安全架构概念方法，支持企业在其需要的地方部署和扩展安全性，如图 4 所示。遵循网络安全网格架构（CSMA）原则，可以实现分布式部署的安全产品之间的互操作性和协调性，实现统一的策略

42、管理和协调，提高组织的灵活性、适应性和整体更强的安全态势。CSMA 在整合组织资产和各类安全产品能力的基础上，建设了 4 个基础能力层：安全分析和威胁情报、身份认证和授权管理、策略和态势管理以及综合控制面板：一是安全分析和威胁情报层。需要汇集并标准化不同安全产品的日志信息、各类威胁情报信息和各类资产的基础状态信息，并应用基于关系的风险评分矩阵来对不同的实体和资源进行动态评分，评分对象包括不限于人、设备、网络、应用、数据、云环境等。动态评分的结果和威胁情报信息作为安全分析的输入，结合机器学习技术和数据挖掘技术，实现安全风险预感知，以及防护策略、安全配置的下发调整，阻断并消除风险。二是身份认证和授

43、权管理层。强调身份要素的集成化和模块化，为用户、应用、安全工具等提供身份认证、权限控制和自适应访问控制策略服务框架。增加身份认证和授权的安全性，提高用户体验，降低操作复杂度。三是策略和态势管理层。主要用于集中构建、存储和管理企业安全策略、态势感知配置和安全脚本。为企业安全团队提供集中统一的方式管理、编排不同类型和不同厂商的安全产品和服务，实现同一个安全策略或配置在不同安全产品和服务的一致性。四是综合控制面板层。基于动态实体评分的方式，通过可视化、集中化的方式展示企业安全风险现状，甚至实现风险预测，20 协同不同安全事件处置团队开展事件应急。总之，网络安全网格的优点。一是集中管理安全策略和配置；

44、二是更好集成不同供应商的不同安全产品和服务，实现集中的威胁数据存储；三是通过集中的安全脚本和自动化脚本，实现更快的事件应急响应。四是提高安全管理员和终端用户的可用性。图 4 CSMA 网格架构（Gartner）4 4 4）SASESASE安全访问服务边缘架构安全访问服务边缘架构 安全访问服务边缘架构（Secure Access Service Edge，SASE）是将网络安全功能与软件定义广域网（SD-WAN）相结合的 4 “Guide to Cloud Security Concepts”,URL:https:/ 21 产品和服务架构，通过设计分布式和云交付的安全控制，可将用户、系统、终结点

45、和远程网络安全地连接到应用和资源，实现对分布式数据资产的“任何设备、任何地方”访问，SASE 安全架构组件如图 5 所示。SASE 主要有四个特征，一是基于身份认证的网络接入，对于实体的身份认证，不仅仅依赖 IP 地址，用户和资源的身份决定其网络互连体验和访问权限级别。实体身份决定服务质量、路由选择、应用的风险安全控制策略。二是 SASE 架构充分利用云的特性，包括弹性、自适应性、自恢复能力和自维护功能。三是 SASE 为企业资源创建了一个覆盖数据中心、分公司、云资源和移动用户的安全的虚拟网络。软件定义广域网（SD-WAN）设备支持物理边缘，移动客户端和无客户端浏览器通过身份认证后就近接入边缘

46、网络。四是 SASE 采用分布式架构，充分利用靠近企业的边缘云等设施，提供网络和安全功能。SASE 主要组件为网络服务和安全服务两部分：一是网络服务通过 SD-WAN、网络即服务、分布式链接、CDN等技术使企业连接其远程办公室、数据中心和云环境。二是安全服务主要包括零信任网络访问（ZTNA）、安全 Web 网关（SWG）、云访问安全代理（CASB）、防火墙即服务（FWaaS）和安全邮件网关（SEG）。SASE 在云中部署这些安全服务，并为企业提供实时威胁检测和缓解功能。SASE 可以给企业提供全量的网络流量可见性，包括本地、云端和移动端应用访问和互联网的流量。SASE 提供一系列丰富的网络和安

47、全功能，各个分支节点不需要复杂的安全设备，技术路 22 线统一，维护成本低。所有安全能力对用户透明，提高用户易用性。图 5 SASE 安全架构组件（Gartner）5 3 3高级安全性架构高级安全性架构 1 1）CASBCASB-云访问安全代理云访问安全代理 云访问安全代理（Cloud Access Security Broker，CASB）解决了组织部署应用程序时产生的复杂性，是确保安全采用基于SaaS 的云应用的关键控制。CASB 充当安全策略强制网关，以确保用户的操作是经过授权的，并符合公司的策略，其执行功能还可以帮助减轻影子 IT 的威胁。同时，随着越来越多的组织将敏感数据移动到经批准

48、的云应用中，如 Microsoft 365、Google 5 “Essential Skills for Cloud Security Architects”,URL:https:/ 23 Workspace、Dropbox 和 Box，CASB 有助于识别和保护这些应用中的敏感数据，CASB 能力和架构如图 6 所示。CASB 的四个支柱包括可见性、合规性、威胁保护和数据安全性。其中，可见性通过云服务的使用跟踪、报告、日志和警报来实现；合规性通过整合身份验证、授权、单点登录和法规要求强制功能来实现；威胁保护和数据安全则是通过 CASB 工具提供的恶意软件检测、防火墙、加密和数据丢失预防功能来

49、实现。机构可以通过 API 或网络代理（前向代理或者反向代理）集成 CASB，实现跨所有 IaaS 和 SaaS 应用程序的安全功能。举例如下：一是 API 模式下的 CASB 策略“带外”连接到云应用程序，以通过各种内容检查技术识别敏感数据，删除有风险的外部共享，就地加密文件或撤销有风险的云到云连接。二是反向代理模式下的 CASB 策略部署在经批准的云应用之前，以提供基于风险的自适应访问控制、对非托管设备的功能受限访问、基于在线实时内容检查的数据丢失预防，或在下载敏感文件时提供临时权限管理保护。三是前向代理模式下的 CASB 为已批准和未批准的云应用程序提供细粒度的上下文感知访问控制。24

50、图 6 CASB 能力和架构综述（Gartner）6 2 2）CNAPPCNAPP-云原生应用程序保护平台云原生应用程序保护平台 云原生应用程序保护平台（Cloud Native Application Protection Platform，CNAPP）是一种新兴的功能，将云安全工具（包括 CWPP 和 CSPM）结合在一起。CNAPP 工具将整合来自 CWPP和 CSPM 的信息，以提供对云基础设施和平台服务（CIPS）部署中的安全行为的更详细见解，其核心概念如图 7 所示。CNAPP 工具为 SecOps 和 DevOps 团队提供了统一的可见性，提供了一套应对威胁和保护云原生应用的能力

51、，以及漏洞和错误配置修复的自动化。6 “Essential Skills for Cloud Security Architects”,URL:https:/ 25 CNAPP 根据风险对端点、网络和云中的所有工作负载、数据和基础设施进行识别和优先排序。可以防止配置漂移，并提供跨虚拟机、容器和无服务器环境的漏洞评估。使用 CNAPP，企业可以建立基于零信任的政策，观察行为，以消除误报，并通过良好的行为执行实现规模化。通过将云原生威胁与 MITRE ATT&CK 企业和云矩阵进行映射，增强了安全运营中心的能力。为同一团队配备单独的 CWPP 和 CSPM 工具意味着不必要的开销和对员工的额外培训

52、。将这些工具合并为一个 CNAPP 解决方案是合理的。图 7 CNAPP 核心概念（Gartner）7 3 3）CSPMCSPM-云安全态势管理云安全态势管理 Gartner 将云安全态势管理（Cloud Security Posture Management，CSPM）定义为一组安全产品和服务，包括合规监控、7 “Guide to Cloud Security Concepts”,URL:https:/ 26 动态云和 DevOps 集成、更全面的检测和事件响应能力（EDR）、风险评估和云控制平面的改进报告。CSPM 工具和服务可以在任何云环境中监视各种各样的问题。目的是创建一个策略来定义云

53、基础设施的“期望状态”或“期望配置”，此外还可以监视实际情况，CSPM 多云用户案例如图 8 所示。CSPM可用于进行持续的合规监控（CIS，NIST，HIPAA，GDPR），防止配置漂移，支持安全运营中心审计。CSPM 还可以作为 DevOps的护栏，通过设置云中的允许配置或行为的限制。CSPM 工具包括用于合规评估、运营监控、DevOps 过程集成、事件响应、风险识别和风险可视化的用例。CSPM 工具超越了云控制平面（通常用于 IaaS 和云服务提供商CSP提供的 PaaS 服务）的安全配置评估，以提供管理能力，包括 CSP 对策略违规采取行动的能力。通过审查云审计和运营事件来提供风险识别

54、和警报功能。CSPM 可以提供映射到定义的安全框架和标准的可视化和报告，以支持法规遵从性。CSPM 工具的好处在于：一是使得资产可见性，机构可以了解自身的云中的资产全貌及资产结构；二是了解安全策略全貌，机构可以了解云需符合的安全法规和标准、如何解决安全问题及需符合的内部安全政策等；三是持续监视和立即检测，机构可以控制新资产继续遵守安全策略及监控产品的安全水平；四是适应CI/CD 流程的安全性，提升 DevOps 的安全性；五是了解团队如何工作，了解他们在安全问题上的知识；等等。CSPM 工具可以识别常见的云控制平面问题，包括云存储或数据库未启用加密、对流动中的敏感数据没有加密、缺乏健全的 27

55、 密钥管理（包括旧的或陈旧的密钥）、糟糕的身份和访问管理（IAM）政策（如不遵守最小特权原则）、开放或允许的网络访问控制、公开的数据存储（如可访问的 S3 桶）、在云环境中启用最少或不启用日志记录等。图 8 CSPM 多云用户案例（Gartner）8 4 4）CWPPCWPP-云工作负载保护平台云工作负载保护平台 云安全的一个重要障碍是工作负载以不同的状态存在。例如，工作负载可能在某一时刻运行在公有云环境中的 Docker 容器上，而在下一时刻运行在私有云环境中。由于越来越多地使用多云和混合环境，云工作负载放置变得更加复杂。确保在正确的位置使 8 “Essential Skills for C

56、loud Security Architects”,URL:https:/ 28 用正确的控制部署正确的工作负载是一个复杂的过程，这使得安全事件很容易发生。云 工 作 负 载 保 护 平 台（Cloud Workload Protection Platforms，CWPP）这个术语是 Gartner 创造的，指的是为保护工作负载而设计的云本地安全策略。要理解这一点，首先要了解什么是工作负载，CWPP 类型如图 9 所示。一般来说，工作负载指的是功能或能力的原子单位，以及运行他所需的任何东西例如，数据、网络连接等。他是云功能的一个单元。CWPP 统一了跨多个云提供商的管理，并跨越了所有类型的工作

57、负载，包括物理服务器、虚拟机、容器和无服务器功能。CWPP 背后的思想是提供一种机制，以一致的方式保护这些工作负载；在多种云环境下运行良好，包括组织自己的私有云或混合云；无论周围发生了什么，他都具有相同的安全性和降低风险的价值。CWPP 的好处在于：一是降低复杂性，相较传统基于端点、物理机的防护产品，CWPP 安全产品能够适应私有云、公有云场景，可以以虚拟机、容器等粒度进行安全防护；也适合在无服务器的PaaS 中使用或 serverless 场景。二是一致性，在当前云 IT 架构日益复杂的今天，无论有多少工作负载，CWPPs 都提供更一致的视图。三是可移植性，这意味着无论工作负载在哪里或是什么

58、，产品都要提高安全性例如，今天运行在本地管理程序中的工作负载明天会转移到 IaaS 提供商，或者今天运行在专用 IaaS 中的引擎上的容器明天会转移到 AWS Fargate 或 Azure 容器实例。29 图 9 CWPP 类型（Gartner）9 4 4相关模型及标准相关模型及标准 随着金融行业深入推进数字化转型，越来越多系统采用敏捷开发模式，以便响应快速变化的市场需求。系统采用微服务框架，开展技术中台建设，通过 DevOps 流水线进行容器化部署。与合作机构构筑互联网生态协同圈，扩大获客营销场景，通过 API 接口与合作机构进行数据交互。利用云原生技术，提升系统研发交付效能的同时，也引入

59、了相应的风险因素，这对传统的研发安全运营安全模式提出了挑战。关于软件研发安全和运营安全实践领域的研究，对比国内外研究现状，美国的软件开发运营安全行业起步较早，在微软、思 9 “Essential Skills for Cloud Security Architects”,URL:https:/ 30 科等众多的软件企业实践基础上，例如微软的 SDL 流程。以及在美国国家安全局（NSA）、国家标准研究院（NIST）等政府和研究机构的推动下，形成了规范的软件开发能力成熟度模型框架，例如 CMMI、SSE-CMM、BSIMM 模型等。与国外相比，我国软件开发运营方法与规范研究虽然起步相对较晚，但随着

60、我国软件产业快速发展，软件研发运营安全能力成熟度发展迅速，目前在一些行业领域已经有具体的实践标准。2015 年 5 月我国正式发布了国家标准 GB/T 18336-2015信息技术 安全技术 信息技术安全评估准则，该标准覆盖软件全生命周期各阶段的安全管控要求，相关组织可以依据此标准开展软件安全测试评估实践。2018 年 6 月中国信通院发布研发运营一体化（DevOps）能力成熟度模型，该模型覆盖端到端的软件开发交付生命周期全流程，是一套体系化的方法论、实践和标准的集合，总体架构可划分过程（敏捷开发管理、持续交付、技术运营）、应用设计、安全及风险管理、评估方法、系统和工具、业务价值管理、合作开发

61、运维、持续测试等 10 个能力域。研发运营一体化（DevOps）标准通过工具链与持续集成、测试、交付、反馈与优化进行端到端整合，完成无缝的跨团队、跨系统协作，为软件研发全流程提供支撑，落地最佳实践，缩短开发周期、全面提升安全开发、安全交付和安全运营过程的效率和质量，实现全流程的安全保障。以下是对典型框架及能力成熟度模型简介。31 1 1）软件能力成熟度模型）软件能力成熟度模型 CMMICMMI CMMI（Capability Maturity Model Integration For Software，软件能力成熟度模型集成）是一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行

62、软件开发能力的评估。2018 年 7 月，CMMI 研究院正式发布了 CMMI 2.0 中文版。其中针对软件研发的 CMMI-DEV 基准视图包括：原因分析与解决方案、配置管理、决策分析与解决方案、治理、估算、实施设施、管理效能与度量、监督和控制、组织级培训、过程资产开发、过程管理、计划、过程质量保证、同行评审、需求开发与管理、风险和机会管理、供应商合作管理、验证与确认、产品集成、技术解决方案等 20 个实践域。这些过程域的实践涵盖了软件开发的各个环节和流程，提供了每个环节的最佳实践以及标准。2 2）ISO/IEC ISO27001ISO/IEC ISO27001 信息安全管理体系信息安全管理

63、体系 ISO27001（信息安全管理体系）认证是世界上应用最广泛与典型的信息安全管理标准，是目前国际上最权威、最严格，也是最被广泛接受和应用的信息安全标准，目前在全世界 150 多个国家和地区都有众多机构采用，在国内也被转化为国标标准（GB/T22080），被称为信息安全管理的“最佳实践”。目前，ISO27001 标准通过对组织信息科技各重点领域开展信息安全管理流程的全面完善和落地，帮助组织建立完善的信息安全管理体系，该标准最新版本已在 2022 年发布，包括 15 个运营能力域和93 个控制项。32 3 3）NIST SP800NIST SP800 系列标准系列标准 在开发安全理论和实践方面

64、，美国国家标准与技术研究院（NIST）发布的 SP800 系列标准是一套关于信息安全的系统性文件，其中涉及大量软件开发安全实践内容。SP800 系列标准涉及软件生命周期各阶段的开发安全管控内容，为每个阶段安全管控提供实践指导。4 4）系统安全工程能力成熟度模型认证（）系统安全工程能力成熟度模型认证（SSESSE-CMMCMM）系 统 安 全 工 程 能 力 成 熟 度 模 型（Systems Security Engineer Capability Maturity Model，SSE-CMM）是由美国国家安全局、美国国防部以及 60 多个著名公司共同开发的，主要用于测评和改进整个信息系统全生

65、命周期的安全工程活动，1996年 10 月正式发布，后成为国际标准 ISO/IEC 21827。SSE-CMM 将系统安全工程过程域划分为风险过程、工程过程和保证过程 3 个工程区，共包含 11 个过程域。模型为每个过程域定义了一组基础实践活动。每个基础实践活动都定义了取得过程域的目标的必要步骤，并规定每一个基础实践活动都是不可缺少的，基础实践活动具有以下特征：应用于整个生命周期，与其他基础实践活动不互相覆盖，并且代表着行业安全最佳实践。SSE-CMM 模型定义了 5 个过程能力级别，以及 1 个非正式的过程能力级别“0”级，其中“0”级也称作“未执行级”。5 个过程能力级别含义如下所示。级别

66、 1：“非正式执行级”，组织是否尝试执行包含上述基础实践活动的安全工程。33 级别 2：“计划与跟踪级”，在定义组织级的过程前，先解决项目层面的定义、计划与执行问题。级别 3：“充分定义级”，在组织层面将所有基础实践依照一组完善定义的操作规范来执行标准化的过程。级别 4：“量化控制级”，根据组织目标制定度量方法，对执行过程进行度量，并基于度量结果进行管理。级别 5：“持续改进级”，根据组织文化可以持续优化改进标准过程，以获得更优的实践成果。SSE-CMM的评估方法提供给组织对照该模型评价其安全工程能力的过程和工具，该模型说明安全工程是系统工程的一个组成部分。5 5）软件安全构建成熟度模型认证（

67、）软件安全构建成熟度模型认证（BSIMMBSIMM）2008 年 Synopsys 公司发布了软件安全构建成熟度模型（Build Security in Maturity Model，BSIMM），他不同于其他指导性模型，而是一种描述性模型，其借助可量化的业界数据作为基准，对组织实施的软件安全计划进行量化评估，通过各指标权重来评估组织的软件安全计划成熟度。2021 年根据 128 家企业的软件安全实践发布了聚焦开源、云、容器及软件供应链安全的 BSIMM12，该版本增加了云安全相关功能，加强对容器安全问题的管理，试图推进 DevSecOps，加强安全团队与开发团队和运营团队的沟通和相互理解。B

68、SIMM 适用于具备软件研发流程和信息安全能力的组织，衡量其在软件研发安全方面的成熟度。组织通过 BSIMM 评估，除了可以横向了解自身在软件安全计划的执行情况，从而改善软件安 34 全计划，还可以纵向评估自身在软件安全计划实施一段时间后具备的成熟度，从而可以更有效分配相对有限的安全资源。BSIMM12 的软件安全框架（SSF）划分了 4 个领域，分别为管理、情报、SSDL 触点和部署，每个领域又各自划分了 3 项实践，共形成 12 项安全实践，包含 121 项安全活动，并根据被调查公司参与的安全活动的占比排名，将安全活动分成 3 个等级。6 6）研发运营一体化（）研发运营一体化（DevOps

69、DevOps）能力成熟度模型）能力成熟度模型 中国信息通信研究院联合多家 IT 公司制定了 DevOps 系列标准，目前 DevOps 标准已经成为业界技术标准及企事业单位的技术水平衡量指标。借鉴业界先进的理论思想，并结合金融网络安全管理最佳实践制定形成，该模型是指导金融机构开展DevOps安全能力成熟度评估和网络安全能力建设的核心理论，模型如图10 所示。完善安全工具链建设，切实做到安全前移，提升 DevSecOps自动化水平可以提升安全研发管控效率，提高工程项目安全质量，将安全开发管控策嵌入到现有的 DevOps 流水线，能有效减少系统研发过程产生的安全漏洞数量，减少安全漏洞修复成本，降低

70、由于修复安全漏洞导致项目延期的风险，保证 DevOps 开发过程的产品交付安全质量。35 图 10 研发运营一体化（DevOps）能力成熟度模型 7 7）数据安全能力成熟度模型（）数据安全能力成熟度模型（DSMMDSMM）2019 年 8 月，GB/T 37988-2019 信息安全技术 数据安全能力成熟度模型（Data Security Capability Maturity Model，DSMM）国家标准正式发布，并于 2020 年 3 月正式施行，模型如图 11 所示。DSMM 按照数据生命周期分为 6 个阶段，包括数据采集安全、数据传输安全、数据存储安全、数据处理安全、数据交换安全和数

71、据销毁安全。DSMM 在安全能力维度，形成组织建设、制度流程、技术工具和人员能力 4 方面安全能力进行综合评估。DSMM 将数据安全能力成熟度划分为 15 个等级，从低到高分别为非正式执行级、计划跟踪级、充分定义级、量化控制级和持续优化级，从而形成一个三维立体模型，对组织的数据安全能力建设进行评估指导。36 图 11 数据安全能力成熟度模型 综上安全评估框架模型来看，基于上述类似 SSE-CMM、BSIMM方法论，形成评估组织系统安全能力成熟度的落地方法。DSMM 和SSE-CMM 在模型架构设计上基本相似，其核心目标也基本保持一致即评价组织在特定领域的安全能力，并根据差距分析指导后续网络安全

72、建设工作重点和优先级。（四）研究意义（四）研究意义 随着云计算、大数据、人工智能等技术的迅速发展，社会数字化转型的速度不断加快。云原生作为下一代信息技术与应用模式的杰出代表，充分展示了信息技术发展的前沿性和趋势性。云原生应用环境下的安全保障，即云原生安全，对于产业变革与商业模式重构具有重要的影响。云原生技术是云计算、大数据、人工智能等技术的集大成者，通过将应用程序及其依赖项在云环境中进行原生化，实现了应用与基础设施的解耦，提高了应用的可伸缩性、可用性和安全性。37 云原生应用具有快速部署、动态扩展、自我修复等特点，使企业能够更快地适应市场变化，提升业务敏捷性和创新能力。云原生安全是确保云原生应

73、用环境下安全的关键措施。由于云原生应用环境具有开放、动态、无边界等特点，使得安全问题变得更加复杂和严峻。云原生安全通过提供一体化、全方位的安全防护，实现了对云原生应用全生命周期的安全保障，有效防范了各类安全风险和威胁。因此，云原生作为下一代信息技术与应用模式的发展方向，将推动产业变革与商业模式重构。而云原生安全作为云原生应用环境下的安全保障，其重要性日益凸显，成为数字化转型过程中不可或缺的重要环节。1 1社会意义社会意义 驱动新技术创新与产业升级。云原生安全产品的研发与应用，促进相关技术如容器、服务网格的快速成熟与应用。这加速推动新的技术创新与产业变革。降低数字转型风险。云原生安全解决方案加强

74、对云原生基础设施与应用的安全防护与管控，降低企业数字化转型中的安全风险，促使其放心地迁移到云上。赋能数据驱动与智能化决策。云原生安全技术能有效收集与分析云环境的运行数据，为企业提供安全智能与可视化分析能力。这能帮助企业实现数据驱动与智能化运营。38 2 2行业意义行业意义 优化客户体验。云原生安全解决方案加强金融业务与科技风险管控，确保服务可用性与数据安全。这有利于金融机构提供稳定优质的客户体验。提高业务灵活性。云原生技术为金融机构带来更高的业务灵活性与运营效率。云原生安全解决方案减少相关安全风险，让金融机构可以安心采用云原生技术提升业务灵活性。降低合规成本。云原生安全解决方案帮助金融机构构建

75、安全的云原生环境，通过自动化与标准化简化合规验证流程。这可以显著降低金融机构的合规成本。3 3消费者意义消费者意义 保障信息安全。云原生安全解决方案加强对个人信息的防护与监控，减少数据泄露或被滥用的风险，保障消费者信息安全。提高服务质量。云原生安全技术有助于各行业企业构建安全稳定的云原生应用环境。这能为消费者提供高可用性与卓越的数字化服务体验。赋能个人化服务。云原生安全解决方案实现对云环境的全面监测与安全分析，为各企业提供打造个性化智能服务的数据支持。这有利于消费者获得更加个性化的产品与服务。二、云原生安全体系（一）云原生安全体系概述（一）云原生安全体系概述 39 1 1云原生安全架构设计原则

76、云原生安全架构设计原则 1 1）安全左移安全左移 安全左移原则的提出和云原生技术发展息息相关，在云原生环境中，因其持续交付集成、容器化、微服务等特性使得安全问题更加复杂和难以管理。云原生应用通常由多个微服务组成，这些服务可能运行在不同的容器或虚拟机中，服务实例通常生命周期短、业务复杂，使得安全管理变得更加复杂困难，此外，云原生应用的持续交付和部署特性也容易使得新的代码和配置可能在没有充分测试的情况下就被部署到生产环境，导致存在安全漏洞和隐患。安全左移强调在云原生应用建设生命周期的早期阶段引入安全措施，而不仅仅在开发过程的后期阶段或运行时投入安全资源，包括安全需求、安全编码、代码测试、开源组件检

77、测、镜像安全等。这种思想的目标是通过在整个开发运维过程中集成安全措施，帮助开发人员更早地发现和修复安全问题，及早发现、及早修复，从而减少潜在安全漏洞、数据泄露、权限不当等方面安全风险。2 2）零信任架构零信任架构 零信任原则是一种安全策略，其核心理念是“永远不信任，总是验证”。在零信任架构中，无论用户身处网络的哪个位置，无论是内部还是外部，无论是已知还是未知，都必须经过严格的身份验证和权限控制才能访问系统资源。这种策略的目标是消除网络中的任何潜在安全漏洞，从而防止未经授权的访问和数据泄露。在云原生安全架构设计中，考虑零信任原则至关重要。首先，云原生环境的特性决定了其对安全性的高要求。云原生应用

78、通常 40 具有高度分布式、动态扩展的特点，这使得传统的边界防御策略难以适应。而零信任原则能够提供一种更加灵活、精细的安全控制方式，能够更好地应对这些问题。其次，零信任原则有助于提高云原生应用的安全性。通过实施零信任原则，可以确保只有经过验证和授权的用户才能访问系统资源，从而有效防止未经授权的访问和数据泄露。3 3）智能化安全运维智能化安全运维 智能化安全运维是一种基于人工智能和机器学习技术的安全运维方式，能够自动化地识别、预测和应对各种安全威胁。在云原生环境中，由于系统的复杂性和动态性，云原生环境的数据量通常非常大，传统的安全运维方式的时效性往往难以满足实际需求。因此，智能化安全运维成为云原

79、生安全架构设计中不可或缺的部分。智能化安全运维的主要目标是提高安全防护的效率和效果。通过自动化的方式，可以快速地发现和处理安全事件，减少人工干预的时间和成本。同时，通过机器学习和人工智能技术，可以对安全威胁进行预测和预防，提前做好防护措施。在云原生安全架构设计中，考虑智能化安全运维有以下几点好处：一是提高安全防护效率：通过自动化的方式，可以快速地发现和处理安全事件，减少人工干预的时间和成本。二是提升安全防护效果：通过机器学习和人工智能技术，可以对安全威胁进行预测和预防，提前做好防护措施。三是降低安全风险：智能化安全运维可以帮助企业及时发现和处理安全威胁，降低安全风险。41 四是提升运维效率：通

80、过自动化的安全运维，可以减少人工的工作量，提升运维效率。五是提供更好的用户体验：通过智能化的安全运维，可以提供更安全、更稳定的服务，提升用户的体验。4 4）过程可观测过程可观测 过程可观测是一种在云原生环境中安全实施过程的可视化展示。其涉及对系统、网络和应用程序的运行状态进行持续监控和分析。这种原则的目标是通过收集和分析大量的数据，及时展示任何可能的安全威胁或异常行为、处置过程、处置状态、后续预测等。通过对大量数据的分析和挖掘，可以为企业决策者提供有价值的信息，帮助他们做出更好的决策 5 5）混合部署混合部署 在云原生的环境下，应用系统和应用数据可能部署在不同的地方，本地和云端、公有云和私有云

81、、公有云和公有云等不同场景。混合部署方式给企业带来了一些挑战和机遇，既让业务部署获得了充足的弹性和可扩展性，同时也增加了攻击面，因为数据和应用程序分布在多个环境中。这要求安全架构能够跨越这些环境，提供一致的安全策略和防护措施。其次，混合部署也使得数据保护和合规性更加复杂，因为不同的环境可能有不同的数据保护要求和法规。因此，安全架构需要能够适应这些差异，同时确保数据的安全性和隐私性。为了适应混合部署，云原生安全架构应该考虑以下策略：42 一是统一策略：无论数据和应用程序在哪里，都应该实施统一的安全策略。这意味着需要在本地环境和云环境中使用相同的身份验证、访问控制和加密方法。二是集成安全：安全架构

82、应该能够集成到混合部署的所有环境中，包括本地环境和云环境。这可能需要使用安全信息和事件管理（SIEM）工具，以及网络防御和威胁检测解决方案。三是数据保护：安全架构应该能够保护混合部署中的数据，无论数据在哪里。这可能需要使用数据丢失防护（DLP）解决方案，以及数据加密和备份策略。四是合规性：安全架构应该能够帮助组织满足混合部署中的所有合规性要求。这可能需要使用合规性管理工具，以及与合规性相关的审计和报告功能。2 2云原生安全整体架构云原生安全整体架构 基于以上原则，本次研究形成的金融行业云原生安全研究体系总体分为云原生研发运维安全、云原生应用与数据安全、云原生计算环境与基础设施安全和云原生安全管

83、理四个部分，共包含7 个能力域、28 个一级能力、123 个二级能力和 683 个三级能力，详见附表“云原生安全能力清单”，云原生安全整体架构如图 12所示。云原生研发运维安全，是指在云原生环境下，采用云原生的理念、架构和工具进行应用程序开发的方式，并对云原生应用和基础设施进行持续监控、管理和优化，以确保其安全性和合规性。43 云原生应用与数据安全，是指保障云原生的微服务、API、Serverless 等多形态的应用安全，并确保云原生环境下数据的安全性和隐私性。云原生计算环境与基础设施安全，是指保护云原生环境的底层基础设施（例如数据中心、服务器、网络和存储设备等）和计算环境（例如运行时、镜像、

84、集群编排、组件等）的安全，防范未经授权访问、数据泄露、恶意攻击、服务中断等威胁。云原生安全管理，是指适配云原生环境的、以应用为中心的安全流程和安全管理模式，通过资产识别、安全审计、安全策略、身份管理等内容建设，实现统一的、多维度的安全风险分析、处理、管理。图 12 云原生安全整体架构图 3 3云原生安全职能边界云原生安全职能边界 云原生安全与传统安全和云安全有所不同，他更加关注云原生应用和运行时的安全性。随着容器、微服务和无服务应用的兴起，企业也需要重新考虑其安全隐患和防护措施。在传统的安全模式下，安全团队通常负责整个应用程序的安全，包括应用程序 44 本身和底层基础设施。然而，在云原生环境中

85、，由于应用程序被拆分成多个独立的微服务，每个微服务都有自己的容器和运行环境。云原生服务有不同的交付/服务/架构模式。不同的服务模式下平台方和客户方责任模型也有所不同，如图 13 所示。图 13 云平台安全责任模型 （二）云原生研发运维安全（二）云原生研发运维安全 1 1概述概述 目前国内金融行业尚未形成一套针对云原生安全研发运营的能力成熟度模型，指导金融机构完善基于云原生的研发运营安全体系建设落地方法论。根据对以上国内外能力成熟度模型分析，根据软件全生命周期各阶段，分为不同阶段过程的能力域，实现覆盖系统全生命周期安全管控。从能力维度划分角度，分为组织建设、制度规范、技术工具、人员能力 4 个能

86、力维度，通常划分为 1-5 级成熟度，来体现组织所处的不同阶段能力成熟度层级，45 指导组织评估自身在云原生研发运营安全的能力水平，合理分配安全资源，完善网络安全能力建设。从成熟度模型设计思路上看，根据目前业界已有指导安全能力成熟度编制的成熟方法论，主要分为如下 3 个步骤：第一步。安全过程维度设计：首先基于云原生应用安全研发运营的全生命周期划分安全过程，并根据管理对象的特点和实际需要制定安全能力域，云原生研发运维安全共划分为 8 个一级能力、24 个二级能力和 160 个三级能力，如图 14 所示，一级能力域包括安全开发规范、安全需求设计、安全开发、安全交付、运维组织管理、安全管控、安全事件

87、处置分析和情报获取与处置，其中安全开发和运维组织管理能力域为组织建设、制度规范和人员能力要求，其他能力域属于技术工具类要求。图 14 研发安全和运维安全范围 第二步。安全能力成熟度等级设计：根据安全研发安全运营实践活动过程的规范性，参考相关法律法规、行业监管、标准规 46 范以及最佳实践，设置能力成熟度级别，并编制具体实践指标内容。第三步。制定安全能力成熟度评估方法，包括评价范围、输入数据和输出结果。2 2云原生研发安全云原生研发安全 1 1）开发安全规范）开发安全规范 （1 1）开发需求设计规范）开发需求设计规范 开发需求规范开发需求规范：安全需求的创建、评审以及验收都应该由具有足够专业能力

88、的安全人员负责，并且相关角色人员以职责分离的原则设立。根据行业最佳实践、法律法规以及行业规范，建立开发需求基线。在项目的需求分析中落实开发基线，梳理安全需求，在需求清单中对安全需求与业务需求进行统一管理。安全需求覆盖如认证、授权、安全日志与审计等功能性的安全需求，也要覆盖系统健壮性、可用性、保密性等非功能性安全需求。安全需求需要由专业团队进行评审，评审通过后，针对需求清单中的安全需求应该有明确的验收标准，可以通过给每个安全需求关联对应的测试用例用于对安全需求进行验收。安全需求验收有明确的负责人进行，通过后有验收报告产出。开发设计规范开发设计规范：组织上对业务的安全风险级别有明确的分级分类方法和

89、标准。在风险级别的要求下，具有专业技能的人员针对识别出的安全需求，进行威胁建模，制定缓解措施，产出安全设计。安全设计需要由专家团队进行方案评审，并达成一致，形成最终的安全设计方案。在组织中，针对基础的安全业务领域，例如身份认证、访问控制、会话控制、加密解密、日志审计等，47 应该有安全设计规范。针对这些安全常见领域的安全设计进行总结沉淀，形成组织级的安全设计方案和安全组件库，并进行持续优化。（2 2）开发规范开发规范 开发人员管理规范开发人员管理规范：根据组织级的管理规范，对开发过程参与人员的角色有明确的分工定义，人员工作权责明晰，具有有效的权限管控机制。安全相关角色有分配到人员，且根据制度分

90、配相应权责。团队人员具有足够的专业技能。组织提供安全编码规范，从技术上提高人员安全相关技术能力提高代码安全质量，从管理上宣贯安全相关知识避免人员非安全行为。开发环境规范开发环境规范：一是确保开发环境安全，包括主机、操作系统、中间件安全，以及网络安全，且在开发过程中环境安全持续被监控。二是确保开发环境的基线与测试和生产环境一致，以免因环境不一致引入安全风险。三是开发过程中贯彻落实安全编码规范，并且对代码进行审查，通过自动化方式确保代码符合代码质量规范，通过人工评审方式确保代码不含有高危代码或恶意代码。四是开发过程中采用安全的加密算法，弃用过时的算法，确保算法自身安全。（3 3）构建规范构建规范

91、构建过程管理：构建过程管理：组织对于构建工作的流程，有相关的管理规范。有专职的构建人员负责项目的构建检查，负责构建系统的构建工作。构建人员遵循构建流程对构建代码和构建环境，构建工具的正确性、安全性进行核查，满足构建条件后进行构建工作。48 正确性就是保证进行构建的代码必须是正确的项目版本。安全性是保证构建的代码是符合代码安全要求的，构建过程中项目所需要的依赖包是满足安全要求的，构建工具和环境是满足安全要求的。构建环境安全构建环境安全：编译构建应在组织级统一标准化的构建环境中完成。构建基础设施环境包括构建机所处的主机环境、网络环境，以及相关联的中间件。构建基础设施环境需要定期进行安全检测，确保环

92、境安全可靠。并且构建环境软件版本应和生产环境保持一致，生产环境的基础软件版本等重要构建信息发生变更，由生产环境基础软件提供方知会组织级配置管理员，由组织级配置管理员完成构建环境统一维护。构建工具安全构建工具安全：构建工具本身应满足无安全漏洞等安全管理要求，不会因工具自身的问题引入安全漏洞。例如 devOps 自动化构建流水线自身没有安全漏洞；maven 构建工具使用安全的版本。同时构建工具可以确保业务的连续性，具备高可用架构，以保证无间断地提供服务，具备一定灾备能力等级。构建工具定期进行安全扫描，定期加固升级工具，发现潜在安全漏洞和风险及时进行安全事件处置。对于安全活动日志进行保存，定期进行审

93、计。构建过程安全构建过程安全：在构建的过程中进行安全检查，设置安全卡点，确保制品的安全性。构建的流程应该为自动化过程，采用以流水线为载体的方式持续集成。流水线中集成安全检测工具，在流水线中自动化进行安全测试。根据安全策略制定流水线中的安全门限，按照相关管理规范配置扫描规则。且配置的权限由授权 49 的安全人员进行配置，其他人拥有执行权限，无法对其进行修改。当未达到安全门限时，构建流水线会中断构建，避免产出带有风险的制品。构建过程中有效的追溯机制和防篡改机制，可以从制品可有效地回溯到源代码，并且对于构建的操作有日志记录，对日志信息合理保存，定期审计。构建安全度量与优化构建安全度量与优化：收集构建

94、过程的数据，并进行分析，对产生的问题进行有效度量分析问题原因，触发适当的安全活动，持续优化安全能力。尤其是构建的过程中，安全检测活动未通过安全门限时会中断构建。对于失败的构建活动分析根本原因。（4 4）测试规范测试规范 在组织制度中测试作为制品输出的前置条件。明确在测试活动中的人员角色分工，请确保角色权责清晰。对于测试的流程在制度中有明确的说明，相关人员按照测试流程进行安全测试操作。测试人员制定业务系统测试方针后确定测试范围和级别，根据不同测试类别准备测试环境、测试数据，执行测试用例并生成测试报告。对于测试过程中发现的缺陷，有明确的流转处理流程，对于缺陷均进行有效处置。测试环境应与生产环境保持

95、一致，避免因为环境不一致引入风险。测试数据如果使用生产数据，应进行脱敏避免数据泄露。（5 5）部署规范部署规范 部署制度管理规范部署制度管理规范：组织发布部署规范中对于安全提出明确的要求，并且明确安全的职责以及安全角色，要求在部署的过程中安全角色职能范围定义清晰、覆盖全面，且能够落实到具体人 50 员。部署流程管理规范部署流程管理规范：在部署规范中，明确需要有安全卡点作为部署的前置条件，有安全角色进行相关审核。部署的流程需要完备，确保部署过程的安全。在部署的流程规范中，有要求部署前有备份机制，部署异常时有安全回退机，并且有安全发布指南来确保部署安全性。部署环境管理规范部署环境管理规范：一是部署

96、环境在管理规范中有对应的角色确保环境的安全。安全角色确保部署环境具有安全性、可靠性。不会因为部署环境自身不带有安全漏洞，引入安全风险。二是部署的环境应为受控环境具有完善的权限管理机制，在管理规范中明确部署环境的权限发放与回收机制。三是部署环境管理规范中应该明确有安全角色对安全负责，持续监控，定期巡查，更新补丁，加固组件，对于发现的安全风险，会有角色和机制进行安全事件处理。四是部署环境应该与测试开发环境保持基线一致，确保不会因环境不一致引入安全风险。五是部署环境安全活动的日志，定期进行审计。2 2）安全需求设计）安全需求设计 （1 1）安全需求分析）安全需求分析 安全需求风险安全需求风险：安全需

97、求在需求分析的过程中存在被遗漏的风险，并且分析得到的安全需求存在没有在项目建设过程中被有效满足和进行可靠检验的风险。由于安全是一个体系工程，涉及多重层次，包括物理安全、网络安全、主机安全、应用安全和数据安全，因此在对系统进行安全需求分析时，容易出现对于安全需求的遗漏，造成风险敞口。51 安全需求通常为非业务需求，只能在异常操作或者极端情况下才能进行检测，例如越权操作安全需求和并发性安全需求，因此在进行系统建设的过程中这类非显性需求容易被项目建设方忽略，同时在系统的验收时，业务方对此类安全需求的检验也存在困难，因此安全需求从创建到关闭的闭环存在风险。安全架构安全架构：在工程项目立项阶段开展安全架

98、构设计，符合组织的整体安全架构规划，根据安全分层原则覆盖物理安全、网络安全、主机安全、应用安全和数据安全。物理安全包括机房环境、安防门禁、消防、防水、电力、监控和温湿度控制等安全措施。网络安全包括区域边界、网络部署、网络接入控制、网络访问控制、网络通信等安全策略。主机安全包括操作系统安全、容器安全、中间件安全和数据库等安全策略。应用安全包括身份鉴别、访问控制、会话安全、安全审计、应用漏洞防范、输入校验、SDK与 API 等其他方面安全要求。数据安全是以数据的完整性、保密性和可用性为目标，根据不同数据的安全定级，对数据全生命周期各阶段的安全要求。安全需求安全需求：建立组织级安全需求基线库，结合业

99、务场景形成项目级的安全需求清单，在需求阶段进行安全需求评审，根据业务需求提出基于业务场景的安全需求，强化金融数据全生命周期保护。如果项目为敏捷开发模式，则历次迭代的功能点制定安全需求。通过 JIRA 或自研工具对安全需求进行跟踪，安全需求应与安全测试用例相对应，在测试阶段对安全需求进行测试验证，实现安全需求和安全测试闭环管理。52 为提升安全需求分析效率，借助基于业务场景式安全需求分析工具，集成了组织级的安全需求基线库。通过人工填写调查问卷信息，根据不同的系统类型，自动生成项目级的安全需求清单。（2 2）安全设计安全设计 安全设计风险安全设计风险：安全设计前没有制定安全政策方针对项目进行安全定

100、级，或者项目安全防护级别定义不准确，导致对于项目安全的设计存在偏差，导致不同级别项目的安全需求错配，导致存在安全暴露面。安全设计不能有效对安全需求设计出安全控制措施。进行安全设计的人员如果缺乏体系性的安全设计视角，容易在进行安全设计的对于攻击面的防御补充，导致在项目中有风险遗留。针对相同的安全需求可以通过不同的安全设计来满足需求，对于不同的项目，使用不同的安全设计满足相同的安全需求，会导致安全测试的难度增加，安全设计标准不够统一。安全威胁建模安全威胁建模：对系统进行安全威胁建模，分为标准安全威胁建模和轻量级安全威胁建模。其中传统安全威胁建模类似微软STRIDE 安全威胁建模方式，此方式需要投入

101、更多人工时间，不太适用于敏捷开发类项目。轻量级安全威胁建模，通过划分信任边界，根据不同系统类型的攻击面，以及是否涉及资金动账类交易、是否涉及敏感数据，制定差异化的安全控制措施，形成系统安全设计方案。安全设计安全设计：制定组织级的安全设计规范，对系统进行数据安全分类分级，对不同级别的数据，围绕数据全生命周期，采用差异化的安全控制策略来确保数据安全。在工程项目总体设计和详 53 细设计中应体现安全设计内容，安全设计内容与安全需求相对应，在设计阶段进行评审。如涉及与第三方合作机构进行数据交互，除了进行数据安全评估外，还应对数据交互过程中的安全控制。同样，也可以使用自动化的工具基于业务场景和数据流程自

102、动生成项目级安全设计，并对安全设计结果进行跟踪，建立通用安全组件或安全服务，比如统一身份认证、权限控制、输入输出校验、安全审计日志组件等，在安全设计中使用通用安全组件和安全服务，将以上安全组件纳入组织级的开发平台或框架，系统均基于开发平台进行开发，调用相关安全组件，统一安全功能实现标准。3 3）安全开发）安全开发 （1 1）制品安全）制品安全 制品管理安全风险制品管理安全风险：组织级的制品分在不同的项目组中，由于项目组各自管理的流程和风格不同，导致制品分类分级没有统一的标准，并且制品的命名不规范，导致库中的制品难以追踪定位，管理混乱。组织分别在制品库中引入新的制品，缺乏统一管理，统一授权的管理

103、机制，没有严格的准入准出标准，会造成引入带有安全隐患的制品进入制品库，在使用库中带有安全隐患的制品进行构建时会导致业务制品存在安全风险。制品库中的制品可能存在零日漏洞，此类风险如果不持续监控，及时评估受制品漏洞影响的项目范围，并且更新修复制品，则也可能造成业务制品带有安全风险。54 对于制品的创建，组织如果没有统一的规范或者指导，可能导致各自项目组的制品安全防护等级不统一，因此如果没有组织级的制品管理也可能导致安全风险。制品制品管理规范：管理规范：具有组织级的制品管理规范，对于组织内的制品进行统一管理。在管理规范中对于制品的安全管理提出明确的要求，明确设立安全角色，对制品的安全负责。在规范中对

104、于制品库中的制品有明确的分级分类定义，可以对制品进行明确的分类，并且对不同分级分类的制品有安全要求和管理措施。管理规范中对于制品有命名规范，保证制品库中的制品有统一且唯一的命名。规范中对于制品有要求版本管理，做到制品的可追踪和可回退，并建立组织级别的资产清单，可以从组织对制品及其依赖关系进行度量。管理规范明确要求有安全角色人员，定期对制品库进行安全巡查和漏洞扫描，发现安全隐患后及时进行处置。制品库有完善的权限管理机制，制品在入库和出库以及在制品库中晋级都要有安全角色进行审核，确保库中制品的安全性。管理规范中对于制品库中的准入和退出有明确的流程要求，安全人员需要按照规范进行安全审核，才能进行操作

105、，确保引入的制品安全。对于制品库操作的日志进行妥善保存，并且定期进行审计。制品库安全制品库安全：制品库本身具有完善的权限管理机制。根据最小授权和职责分离原则，设置不同的安全角色。安全角色的完善的鉴权机制和权限管理，防止越权操作，引入不安全的制品。55 制品库中的制品有唯一的命名，并且有完善的防篡改机制，可以保障制品库中的制品不会被恶意替换。制品库工具定期进行升级和漏洞扫描，确保工具本身安全，同时确保所处环境安全环境，防止因为工具和环境引入安全风险。制品库本身具有备份机制，定期进行数据备份，防止数据丢失。制定业务连续性计划，并且定时进行应急演练。组件安全组件安全 项目级组件安全：项目级组件安全：

106、组件库有完善的权限管理机制，组织级别配置管理员为每个项目分配单独的项目级别组件库。项目级组件库以项目为单位隔离，用于存储项目产生的程序类、数据类、配置类、文档类等组件。按照使用场景分为项目过程库、项目依赖库、项目预发库。项目过程库项目过程库用于存储项目研发的组件。项目过程库按照组件的版本又分为 Snapshot 库和 Release。其中 Snapshot 库用于存储组件的快照版本，允许同版本覆盖，Release 库用于存储组件的非快照本，不允许版本覆盖。项目依赖库项目依赖库用于存储为其他项目提供构建依赖所需的组件，以满足项目间的组件共享需求。项目依库的组件由 Release 库晋级而来。项目

107、预发库项目预发库用于存储项目交付到生产的组件。项目预发库的组件由 Release 库晋级而来。二方组件安全：二方组件安全：二方库用于存储企业内共享复用的公共组件，例如安全公共组件、企业公共框架组件、基础服务组件、基础开发平台组件、基于开源组件定制化开发的组件等。二方组件的准入规则应该明确，确保只能由 release 库中晋级，同时晋级需要安全审核，确保进入二方组件库的制品通过相关安 56 全测试。三方组件安全：三方组件安全：三方库来源于第三方开源组件或商业软件等。三方组件的引入应进行安全评估，并且进行安全检测和漏洞扫描，安全人员对组件评审通过后才允许组件准入。安全人员持续对三方组件扫描，并且通

108、过安全情报源持续检测三方组件，跟踪零日漏洞，发生潜在安全风险时，及时启动安全事件处理流程，消除安全隐患。黄金镜像安全：黄金镜像安全：对于常用组件和应用，组织通过安全基线体现了已经确认的安全配置组，通过将安全配置实例化，形成可以直接使用的黄金镜像是组织内的最佳安全实践。使用安全的配置和经过安全检测的组件构建黄金镜像，并且根据组织管理规范定期更新安全基线，继而更新黄金镜像制品，以确保黄金镜像的安全。对于需要更新新版黄金镜像的系统，由安全人员评估风险和影响，制定更新计划以及回退方案，确保更新过程不会给系统引入新的安全风险。（2 2）开源管理开源管理 开源管理安全风险开源管理安全风险：组织级别如果没有

109、建立统一的开源软件管理规范，则对于开源软件的风险评级，准入和准出的标准在不同的项目组之间存在不统一的问题，不能全部和安全基线拉齐，导致安全隐患。对于已经使用的开源组件，如果不能持续地进行监控，则对于开源组件暴露的零日漏洞可能会存在被利用的安全风险，所以需要对开源组件持续地进行安全扫描追踪。开源组件如果不进行统一的引入，对于引入开源组件的安全 57 测试可能会存在疏漏，并且可能重复引入相同的开源组件，导致给构建环境引入一些意想不到的安全风险。开源管理规范开源管理规范：在组织级制定开源软件使用规范，明确划分安全责任归属，明确组件合规制度，统一进行开源软件准入准出管理，设置组件黑名单，使用安全组件库

110、中的开源组件进行开发。定期梳理开源组件的信息建立组织级别的 SBOM，使得开源组件的使用可追踪，可统计。并且对全员进行安全意识培训，提升供应链安全意识。组织级别对于开源组件漏洞风险建立明确的分级分类标准，对于开源组件许可证设立准入白名单。制定开源组件的漏洞级别所对应的安全活动，确保风险可控。开源组件在制品库中统一管理，遵守制品库相关安全管理规范，确保库中三方开源组件安全。开源组开源组件生命周期管理件生命周期管理：开源组件建立全生命周期的管理规范和流程。开源组件有明确的准入准出流程，已在库中的开源组件要持续监控安全风险。当出现安全风险时，有明确的安全事件响应处理流程，处置安全风险。按照开源管理规

111、范，相关安全角色在开源组件的引入过程中，对开源组件进行安全评估和测试，通过安全评审后，才可以进入制品库。对于进入制品库的开源组件持续进行跟踪，建立开源组件和业务制品的对应关系，以便在发现安全风险时，可以快速定位开源组件的影响范围，让开源组件的使用可分析、可追溯。在组织级别创建开源软件的白名单，指导项目建设中使用白名单内的开源组件，避免在业务制品中引入安全漏洞。58 持续通过安全情报源对开源组件的风险进行追踪，制定相关的漏洞修复计划。当发现安全风险时。由安全人员进行评估，并根据相关管理规范进行安全修复工作。修复相关安全漏洞后进行验证，完成对于开源漏洞处理的闭环管理。对于存在安全隐患无法修复或者版

112、本过时的开源组件，在定期进行开源组件白名单更新时，评估业务影响后，进行准出操作。（3 3）代码安全代码安全 代码安全风险代码安全风险：开发人员可能存在对于高危代码的认识不足，或者编程技能方面存在短板，因此需要对开发人员进行安全编码辅导，提升相关能力，并且代码提交时进行有效代码评审也是对于此类问题的一个有效解决机制。协同进行项目开发的过程中，对于代码修改和添加如果没有进行有效的同步，则会引入安全风险，因此使用代码版本管理工具，建立合理的源代码管理机制，是有效防范此类安全风险的机制。源代码作为重要的数据资产，如果没有完善的权限管理机制，则对于源代码，出现代码泄漏事件，可能会让恶意人员通过分析源代码

113、发现安全暴露面，因此需要对源代码的访问建立有效的权限管理机制。代码代码安全管理安全管理规范规范：建立组织级的代码管理规范，从组织级和项目级对代码进行管理，定义安全角色，明确职责定义，权责明晰。建立有效的权限管控机制和配置管理机制，使源代码受控且可追踪。建立代码管理的基线，确保从组织级代码产出物满足安全标准。组织定期对代码管理进行培训，对管理工具提供支持，59 并定期对合规、权限配置、基线建立等，进行检查和督促问题整改。编码安全编码安全：针对常用的开发语言建立安全编码规范，对开发人员进行安全编码指导。通过技术培训提高开发人员代码安全质量，通过安全宣贯增强开发人员安全意识。开发过程中落实安全设计中

114、的有效安全设计，例如防止越权漏洞。在编码过程中落实安全编码规范，进行自动化的方式审核代码确保代码符合安全规范，进行人工方式审核代码确保制品中不含有高危代码或恶意代码。持续进行代码的安全审查和测试，包括静态代码分析、漏洞扫描和安全测试设置代码审查机制，确保合并的代码满足代码质量要求，并且对代码进行有效人工评审。使用静态代码分析工具和漏洞扫描工具，发现潜在的安全问题。编码过程中使用安全的加密算法，弃用过时的加密算法，确保加密算法的安全性。对编码过程中的度量数据进行统计收集，安全人员对数据进行分析，发现安全问题根本原因，并对管理类问题和技术类问题分别进行专项安全活动提升编码安全质量。代码管理工具代码

115、管理工具安全：安全：组织级别采用统一的代码编写工具，确保工具经过安全检测，不存在隐患与法律合规风险。定期对组织内的开发工具和编译工具进行检查。组织级别统一管理源代码仓库，有明确的权限控制，防止代码泄露风险。根据代码管理规范，设置组织级和项目级的角色，并且角色权责清晰。代码仓库本身确保不存在安全漏洞，不被利用发生越权操作。并且有备份机制，确保源代码不存在丢失风险。60 使用自动化的代码白盒扫描工具，在代码入库前进行自动化扫描，确保代码质量，提高安全性。确保开发环境安全，包括主机、操作系统、中间件安全，以及网络安全，且在开发过程中环境安全持续被监控。且开发环境的基线与测试和生产环境一致，以免因环境

116、不一致引入安全风险。对代码管理工具的日志妥善保存，定期审计。编排文件安全编排文件安全 编排打包安全：编排打包安全：镜像的打包有明确的规范指南，确保镜像打包过程和制品的安全。在规范中对编排文件从安全配置、访问权限、信息泄露等方面进行了安全编码指导，镜像打包工具需要定期更新升级，并且持续进行漏洞扫描，防止因为工具的不安全引入安全风险。编排文件安全：编排文件安全：编排文件被有效进行权限管理，确保只有授权人员可以对编排文件进行修改。同时对编排文件进行配置管理以便对编排文件的变更进行追溯。在编排文件中应避免出现敏感信息，造成信息泄露。对于敏感信息采用动态方式提供。在编排文件中应该限制容器的权限，尽量避免

117、 root 权限，并且防止容器逃逸。编排过程中，应该从安全的制品库中引入安全的组件，并且将无关或冗余的内容打包进镜像。对于编排文件进行安全检测，编排文件中的输入进行验证和过滤，防止恶意代码注入攻击。61 4 4）安全交付安全交付 （1 1）安全交付风险）安全交付风险 业务制品进行交付后就在生产环境中，可能被多种潜在攻击者进行恶意渗透和缺陷利用。因此在投产前，需要尽可能修复安全缺陷。但是业务制品可能存在因为工期不足，不能对安全测试用例进行足够的检测，或者未能修复已经发现的安全隐患，导致存在安全隐患的制品上线，带来潜在安全风险。业务制品交付的环境如果不能保证安全、可靠，则有可能导致系统被恶意渗透，

118、因此交付的过程中，不仅制品要安全，也要保证环境的安全，防止研发交付环境带来安全风险。（2 2）安全安全测试测试 安全测试管理规范安全测试管理规范：在组织制度中明确要求需要设置安全角色，并且在全生命周期中，有对应的人员对安全进行负责，做到安全职责能够落实到角色人员。在组织级制度中，对测试提出明确的要求，要求设置明确的安全卡点，通过后才能进入下一个环境。且安全的测试结果作为生产发布的前置条件，确保上线制品的安全可靠。企业应该对安全测试的结果有明确的分级分类标准，可以对测试出的风险进行统一的客观的评价。并且在管理制度中对不同分级分类的测试结果，有明确的处置要求和处理流程，确保检测到的潜在安全隐患得到

119、有效处理。测试数据管理测试数据管理：测试数据应该满足业务测试需求和安全测试需求。对于安全测试需要覆盖机密性、完整性、身份验证和鉴权。测试数据满足测试方案所提出的测试要求。当使用生产数据 62 进行测试时，应该确保数据的安全性，做好数据脱敏工作，防止数据泄露风险。安全测试工具管理安全测试工具管理：安全测试工具应该满足安全管理规范中对于安全测试能力的要求。覆盖软件生命周期，在各个生命周期阶段有对应的测试工具，包括但不限于白盒测试、黑盒测试、灰盒测试以及渗透测试工具。测试工具自身需要具有安全性、可靠性，定期进行维护，确保生成的测试结果可以有效反映安全状况。测试工具能有明确的产出物，可以根据测试工具的

120、结果明确地对应到组织级别定义的风险等级，进而可以进行对应的处置。安全测试流程管理安全测试流程管理：组织级管理制度中具有完善的安全测试流程和规范，且明确安全测试结果作为发布的前置条件。在前期明确安全策略方针，包括制定安全测试的策略，分析测试环境的资源，确定安全测试边界，以及确定项目的总体安全测试方案。在安全需求明确后，将安全需求和安全测试用例进行明确的关联，在确定安全测试用例的同时，确定安全测试计划。安全测试执行前，需要确保安全测试环境和安全测试数据准备完备。执行安全测试后得到的测试结果，根据相关制度规定执行相关流程，确保安全测试流程全部关闭后，产出安全测试报告。安全测试持续改进优化安全测试持续

121、改进优化：安全测试的流程中，收集测试过程中产生的数据，并且对数据进行分析，形成度量结果，根据度量结果与根据安全方针指定的指标进行对比，发现安全短板。由安全人员牵头，启动安全活动改进相关过程，提升安全效能，使度 63 量结果提升。当度量结果全部达标后，再根据安全方针对指标进行提升，形成持续优化改进的闭环，达到持续优化的目的。（3 3）安全工具集成安全安全工具集成安全 将安全测试工具通过内嵌到 devOps 流水线上，使源代码在构建的过程中安全测试工具可以被自动化地执行。根据安全策略方针，可以在流水线上设置安全门禁，安全测试工具产生的数值指标不满足安全门禁，则构建流水线中断，防止潜在安全风险的制品

122、构建成功。构建在自动化测试工具链上的安全测试工具不仅可以包括白盒测试工具、黑盒测试工具以及灰盒测试工具还可以包括合规检测工具、交互式安全测试工具、容器镜像安全扫描工具、移动App 应用安全测试工具、第三方 SDK 安全检测工具、二进制安全检测工具等。通过将多种安全测试工具内嵌到 DevOps 流水线工具中，可以统一收集安全测试工具产生的数据，并进行统一统计分析，形成安全度量。可以通过指标度量安全测试和漏洞修复情况的能力。通过收集分析研发安全管理过程数据，开展安全后评估工作，如安全漏洞修复率、代码安全缺陷密度、安全缺陷修复时间、安全测试覆盖率等量化指标。第三方开源软件管理工具：第三方开源软件管理

123、工具：加强供应链安全管控，建立开源软件安全准入机制，通过 SCA 软件成分分析工具，进行开源软件安全扫描，从安全角度评估第三方开源软件是否满足安全准入要求，并形成系统 SBOM 库。DevOps 流水线通过 API 接口的方式集成了第三方开源软件安全扫描工具，开发人员在开发过程中，通过代码触发流水线，针对构建依赖的三方组件的漏洞、许可等进 64 行扫描，及时发现三方组件的漏洞情况，并进行改进，有效提升交付制品的安全能力。源代码安全审计工具：源代码安全审计工具：引入自动化源代码安全扫描工具，实现代码上线前的安全审查，支持根据组织级安全编码规范自定义扫描规则，形成符合安全编码规范的源代码安全扫描规

124、则。支持以 IDE 插件的方式集成到 DevOps 流水线，由研发人员自行触发源代码安全审计工具，即时反馈代码审计结果，将安全测试前移至编码阶段，降低安全缺陷修复成本，提升安全测试响应效率。灰盒（交互式）安全扫描工具：灰盒（交互式）安全扫描工具：为了提高安全测试效率，建设交互式的 IAST 扫描工具。安全测试人员只需要像功能测试人员一样点击每个功能即可完成自动化的安全漏洞扫描。IAST 工具分为流量扫描和插桩代码扫描两种方式进行，在测试阶段两种方式均需完成扫描。基于流量方式的扫描工具，安全测试人员通过代理方式将 IAST 工具与测试目标系统关联，获取交易流量，再通过工具中的算法引擎完成包括业务

125、逻辑安全漏洞在内的安全漏洞扫描。基于插桩模式的扫描工具，通过嵌入测试目标系统服务容器中探针，扫描系统运行时的源代码，发现安全漏洞。该工具可以与 DevOps 流水线集成实现项目自动化插桩，然后在后续的功能、安全测试过程中，通过测试人员点击功能完成自动化安全漏洞扫描。黑盒应用安全漏洞扫描工具：黑盒应用安全漏洞扫描工具：测试阶段使用黑盒全自动化智能渗透测试工具完成扫描，可以覆盖部分安全测试用例。通过对目标进行信息收集，端口探测，Web 指纹识别，路径探测，分析服务器的响应进行探测，中间件识别探测以及进行针对性的漏洞 65 验证和利用。移动应用安全扫描工具，针对移动 App 应用软件客户端建设移动应

126、用自动化安全扫描工具，在测试阶段完成客户端的安全自动化测试。覆盖 Android 应用和 SDK 安全，iOS 应用和 SDK 安全，微信公众号和 H5 小程序安全检测。镜像文件安全扫描工具：镜像文件安全扫描工具：支持对镜像文件进行安全漏洞扫描，通过在镜像仓库中集成开源安全扫描插件，参考通用的安全漏洞库对镜像文件进行安全扫描。安全开发管控度量评估：安全开发管控度量评估：建立了研发效能度量指标体系，量化采集研发活动的各项指标，安全开发过程的度量指标包括安全缺陷密度、安全测试覆盖度、安全漏洞修复时间，评估度量结果，采取有针对性地优化安全开发管控活动。基于大数据建模分析，对研发过程中的各环节，制定有

127、针对性地提升研发交付效率的策略，并通过自动化的工具将策略嵌入到 DevOps 流水线，从指标、模型、策略和工具层面提升研发管控效能。对以上度量指标，能够真实反映某系统项目的整体研发风险情况，从而判断此项目是否具备投产上线的安全要求。3 3云原生运维安全云原生运维安全 1 1）运维组织管理运维组织管理 （1 1）监控响应组织）监控响应组织 安全风险：一是安全风险：一是安全事件发现滞后：现很多公司并未建立专门的监控组织来监控云原生环境，可能导致安全事件的延迟发现，增加潜在威胁对系统和数据的风险。二是协作效率低：缺乏明确的责任链和沟通渠道，在未建立明确的职责分工，以及事件分类 66 分级等相关规范情

128、况下，可能导致不同团队之间的沟通和协作可能不畅，导致响应时间延长和问题解决的效率低下。建设思路：建设思路：一是成立专门的监控响应团队：组建由专业人员组成的监控响应团队，7X24 小时负责监控和响应云原生环境中的安全事件和异常情况。持续跟踪公开的数据源，进行风险的预测，提前对潜在风险进行处置。二是团队培训和演练：定期进行培训和演练，增强团队成员的安全意识和响应能力，确保他们能够快速有效地响应安全事件。有应急预案确保业务的连续性，通过不断地演练发现问题，不断优化更新应急方案。三是明确责任和沟通渠道：明确团队成员的角色和职责，建立清晰的责任链和沟通渠道，确保及时响应和问题解决。四是建立相关规范：梳理

129、安全事件类型，以及事件的分类分级、事件处置等相关规范。（2 2）监控响应管理监控响应管理 安全风险：安全风险：一是无法准确识别安全事件：缺乏完善的监控系统和规则，无法准确识别和报告安全事件，导致潜在威胁的漏报或延迟发现。二是告警误报和漏报：告警规则和阈值设置不合理，可能导致频繁的误报或重要事件的漏报。建设思路：建设思路：一是建立综合的监控系统：包括日志分析、行为分析和威胁情报等，以便及时发现异常和安全事件。采用先进的监控技术和工具，提高监控的准确性和覆盖范围。二是设计有效的告警规则和阈值：结合业务需求和风险评估，制定合理的告警规则和阈值，以减少误报和漏报的情况。定期审查和更新告警规则，确保其与

130、实际情况相符。发现告警后，有规范的流程，安全专家根据相关规范评估安全事件等级，确定安全事件的影响范围。67 然后启动事件处理流程。三是自动化告警和通知机制：实施自动化的告警和通知机制，确保监控响应团队能够及时获得关键信息并采取相应行动。这可以提高响应速度和准确性，减少对人工干预的依赖。（3 3）安全应急流程安全应急流程 安全风险：安全风险：一是对安全事件的响应不规范或混乱，导致处理时间延长和问题未得到妥善解决。二是缺乏明确的应急响应流程，使得团队成员难以在紧急情况下迅速行动。建设思路：建设思路：一是制定详细的安全应急计划和流程，包括事件识别、报告、分类、处置和恢复等阶段。二是确定应急响应团队的

131、职责和权限，明确各个步骤的负责人和操作规范，确保团队成员能够快速、有序地响应安全事件。事件处理完成之后，进行根本原因分析，形成报告，并从根本上解决问题原因，杜绝安全事件重复发生。三是定期进行应急演练和模拟测试，以提高团队成员对应急流程的熟悉度和应对能力，同时发现和弥补流程中的不足之处。（4 4）人员技能人员技能 安全风险：安全风险：一是由于技术能力问题，无法有效识别和处理安全问题，延误了对安全事件的响应和处理时间。二是人员对最新安全威胁和攻击技术了解不足，难以跟上不断演进的安全挑战。建设思路：建设思路：一是提供安全培训和教育计划，确保运维人员具备基本的安全意识和技能，包括对常见安全漏洞和攻击技

132、术的了解。二是鼓励运维人员参与安全社区和行业会议，保持对安全领域的关注和学习，了解最新的安全鼓励交叉培训人员技能，关键 68 岗位有 AB 角色，确保人员技能可以保障业务连续性 2 2）安全管控安全管控 （1 1）运维准入）运维准入 安全风险：安全风险：在云原生的安全运维阶段，运维准入是指对云原生环境加载的各类资源和参与云原生环境运维工作的人员或团队进行准入控制和审核的过程。他是确保云原生环境的安全性和稳定性的关键步骤之一。从云上工作负载资源、制品资源、云平台配置三个角度常见风险，如下：工作负载资源权限管控不足：没有正确配置和管理权限，导致人员拥有超出其需要的权限，可能导致数据泄露、误操作或滥

133、用权限的风险。制品入库缺乏管控：缺乏制品入库的审批流程和验证机制，可能导致未经授权的制品更改，从而破坏系统完整性或引入风险。云平台配置缺乏安全检测：未经审查或配置不当的云平台设置可能导致安全漏洞、访问控制不当、网络配置错误等问题。建设思路：建设思路：工作负载准入控制人员的管理，建立有效的权限管理机制，对于权限的发放和回收有明确的规章制度依据，确保权限受控。定义明确的准入规则和权限控制机制，确保只有经过授权的运维人员能够访问和操作云上工作负载资源。建立审计机制，对运维人员的操作进行监测和记录，以便进行后续的审计和追溯。制品入库准入控制生产环境中的制品库要遵守之前章节中 69 的制品安全要求，有严

134、格的准入准出机制，并且对库中的资产进行持续性的安全检测，且有版本管理机制。确定制品入库的准入标准，包括对软件包、容器镜像等制品的安全性进行评估和验证。设计制品入库流程，包括安全扫描、漏洞检测和完整性验证等环节，确保只有通过验证的制品才能被接受并入库。云平台配置的准入控制落实严格的配置管理机制，有安全基线确保配置的合理设计云平台配置管理策略，包括制定安全配置标准和最佳实践，并对云平台进行配置合规性检查。实施访问控制措施，限制对云平台的管理权限，确保只有经过授权的运维人员才能进行配置变更。（2 2）监测预警监测预警 安全风险：安全风险：系统的检测预警有可能在基础监测能力、日志汇聚分析、未知威胁三方

135、面存在安全风险。监测系统可能会生成虚假的警报或过多的噪音，导致运维人员忽视真正的安全事件；现有检测机制可能漏报真实的安全事件，或者误报正常操作为安全事件，导致无法及时发现或错误地响应潜在威胁。不同检测设备安全告警日志缺乏日志汇聚点，无法进行自动化或人工关联分析，缺乏事件关联分析能力，导致多源日志零散缺乏汇聚分析点。监测系统可能无法识别未知的威胁和新型攻击，因为这些威胁和攻击可能具有先进的技术或未被已知的安全规则所覆盖。建设思路：建设思路：对于检测预警的安全风险，首先建立全面的安全监测机制。在云原生各个维度，包括基础设施、基础架构、应用 70 等建设具备独立的威胁监测预警能力。其次，建立多源日志

136、汇聚点，收集到的数据将经过分析和筛选，用于识别潜在的安全问题。这可能包括使用机器学习、行为分析或规则引擎等技术来检测异常活动、异常访问模式或已知的攻击识别。最后，定期更新监测系统和安全规则，以包括新的威胁情报和攻击模式。实施威胁情报分享和合作机制，获取来自安全社区的最新威胁情报。通过使用人工智能或语义分析等新型技术手段，加强对于未知威胁的检测能力。3 3）安全事件处置分析安全事件处置分析 （1 1）响应处置响应处置 安全风险：安全风险：在安全响应处置阶段存在告警信息、处置手段、响应策略等方面的安全风险。首先，可能由于缺乏专门的安全事件响应团队或不足的人力资源，导致无法及时响应和处置安全事件。其

137、次，缺乏有效的处置手段就发现的安全事件告警进行处置。最后，缺乏详细的安全事件响应计划，导致响应过程混乱，或缺乏自动化响应策略和手段，延误了响应时间。建设思路：建设思路：风险发生前，具有有效的安全事件处置预案与流程，并且常态化进行演练；设置合理的风险阈值，当触发阈值后，安全专家对事件风险进行评估，确定安全事件的影响范围和程度，根据相关规定对事件定级，并触发相应的相应流程采取措施控制风险蔓延，实施有效的相应流程解决安全事件。事件解决后，开展根本原因分析，进行整改，杜绝事件重复发生。建立专门的安全事件响应团队，负责迅速响应和处置安全事件。团队成员应具备必要的技术知识和经验，能够有效应对各种 71 类

138、型的安全事件；及时识别、呈现和报告安全事件，确保相关人员了解事件的发生，并能够采取适当的措施。这包括实时监测、日志分析、异常检测等技术手段。云原生环境需要在各个阶段设置安全卡点。能够帮助运维人员迅速采取必要的措施，以限制安全事件的扩散，并降低其对云原生环境的影响。这包括隔离受影响的系统、修复漏洞、更新凭证、恢复备份数据等。制定详细的事件响应计划，包括响应流程、责任分工、沟通渠道和联系人等。确保团队成员清楚其角色和职责，并能够按照计划快速、有序地进行响应；建立自动化响应机制，如预设响应策略，基于自动化编排，多维度设备联动响应。（2 2）溯源分析溯源分析 安全风险：安全风险：溯源分析是在云原生环境

139、，通过收集、分析和关联各种日志、事件数据和证据，以确定安全事件的来源、入侵路径和攻击者行为的过程。通过深入的溯源分析，可以帮助确定受攻击系统的漏洞、攻击手法和未经授权访问的来源，从而为安全事件的响应和后续防御提供重要线索和指导。不完整的日志和数据导致安全风险。缺乏足够的日志和事件数据，或者数据被删除、篡改或不完整，使得溯源分析无法得到准确的结果。攻击者可能使用隐蔽的技术手段，如高级持续性威胁（APT）工具、代理跳板等，使溯源分析变得更加困难。在云原生环境中，生成的日志和事件数据量可能非常庞大，导致溯源分析过程复杂、耗时和容易遗漏关键信息。72 建设思路：建设思路：确保正确配置和收集关键系统、应

140、用程序和网络设备的日志和事件数据，包括网络流量、系统日志、安全事件日志等。同时，保护日志数据免受篡改和删除。及时获取和应用最新的高级威胁情报，以了解最新的攻击技术和工具，从而更好地识别和分析复杂的攻击行为。利用先进的安全分析工具和技术，如安全信息和事件管理（SIEM）系统、行为分析工具、机器学习等，来处理和分析大量的日志和事件数据，以辅助溯源分析的效率和准确性。在溯源过程中，有效保留电子证物，确保保存的流程合法合规，确保事件发生后的电子证物在法律上有效。在合法范围内，依靠社会工程学进行溯源，并请求相关机构协助。4 4）情报获取与处置情报获取与处置 （1 1）情报管理）情报管理 在云原生场景下，

141、情报的管理涉及情报的生产、更新、录入、删除、情报质量的评估和反馈以及情报共享。其中，为了保障情报的实时性和有效性，允许情报平台能够联网更新，同时通过代理上网方式保证安全性。针对临时性的第三方情报，可以采用批量导入和删除的方式进行快速地管理。情报质量可以从可信度、及时性、丰富度、可运营、能闭环等五个维度进行评估，不断优化和挑选更加合适的情报源。情报共享可以对有行业针对性的情报进行行业共享，以为行业安全赋能。（2 2）情报处置）情报处置 基于不同的威胁情报的告警采用不同的处置模式。如果是失陷类的告警，将对应域名或 ip 等封禁，并进行恶意样本的排查 73 和定位，一般该类型情报会带有处置建议，在处

142、置的过程中可以参考该建议。如果是 IP 信誉情报告警，一般在研判和分析后决定是否拦截该攻击 IP，基于威胁程度和置信度不同，一般处置结果分为告警、封禁、阶梯封禁。如果是 Hash 情报预警，将相关Hash 通过终端安全软件进行全面排查和查杀。如果该样本关联到 APT 组织，会同厂商确认以做进一步的定位和溯源。（三）云原生应用与数据安全（三）云原生应用与数据安全 1 1概述概述 云原生为应用系统提供了敏捷、可靠、高弹性、易扩展和持续更新的特性。在云原生环境中，应用系统一般基于容器进行快速部署，并通过服务编排实现业务管理和控制，如负载均衡、应用更新、应用扩容、灰度发布等。云原生环境中，金融行业应用

143、系统最典型的特点是采用微服务架构和无服务模型，以及 API 的使用。传统 Web 应用系统通常为单体应用系统，从前端到中间件再到后端，各个组件一般集中式部署在服务器上。后来随着 Web Service 标准的推出，金融机构基于面向服务的架构（Service-Oriented Architecture，SOA）将庞大、异构的系统通过服务总线实现服务的复用。在云原生环境中，金融机构采用微服务架构对原有应用系统进行重构，将业务系统拆分成大量独立、细粒度的服务。微服务架构使得每个服务聚焦在自己的功能上，然后通过应用编排组装，实现等同于传统单体应用的复杂功能，同时大幅提升灵活性。无服务（Serverle

144、ss）是一种基于代码和计算任务执行的云 74 计算抽象模型，函数即服务（FaaS）、后端即服务（BaaS）是这种模型的实现。相比微服务，Serverless 的颗粒度进一步缩小，具有更强的弹性伸缩能力。在云原生环境中，由于业务功能的拆分细化，以及 IT 管理平台越来越复杂，API 的种类和数量都出现了大幅增长。这些变化增加了金融机构的技术和管理难度，尤其在资产管理、访问控制、可见性等方面容易出现安全风险。在此背景下，业界正在探索通过服务网格等治理框架解决微服务、Serverless的安全风险，并通过 UEBA 等行为分析技术解决海量 API 流量的异常分析。云原生应用与数据安全包含 9 个一级

145、能力、41 个二级能力和 207 个三级能力，如图 15 所示。图 15 云原生应用与数据安全范围 75 2 2云原生应用安全风险云原生应用安全风险 云原生环境中运行着大量微服务、无服务应用，这些新型的应用体系同样存在着安全风险。首先，除了传统网络攻击风险外，由于微服务、无服务将业务功能进一步拆分，使得应用攻击面扩大，一笔业务的处理节点大幅增加，在访问控制方面更容易出现问题，同时这也导致难以在海量日志中标注攻击链路，从而识别攻击或溯源分析。其次，微服务、无服务应用以及云原生环境各应用系统暴露了大量异构 API，可能遭受拒绝服务攻击或存在API 滥用的情况。最后，云原生环境中，应用系统存储、处理

146、、传输的数据类型和数据量有所提升，可能通过云原生 API 或云原生应用的脆弱性造成数据泄露，给金融机构数据安全管理带来了较大挑战。1 1）微服务安全风险）微服务安全风险 （1 1）攻击面扩大）攻击面扩大 由于云原生应用架构的变革，应用从单体向微服务化拆分，每个微服务都是单一的组件，且各组件之间都是通过 API 进行远程调用，应用的访问入口从单体场景下只有一个入口变成分散在很多微服务进程的多个入口，应用暴露的端口数量也急剧增加，导致攻击面比原来大幅度扩大，受攻击风险变高。（2 2）访问控制失效）访问控制失效 所有微服务均需对访问者进行身份验证并校验权限，不恰当的身份验证和访问控制机制可能导致未经

147、授权的访问。微服务除了对传统用户授权外，还需对其他微服务授权，由于金融业务较为复杂，导致微服务间的调用关系也异常复杂，增加了访问控制 76 难度。如果仅在网络层进行访问控制，一旦网络区域内某个微服务失陷，攻击者将获取整个区域微服务的访问权限。（3 3）数据泄露）数据泄露 由于微服务间存在大量东西向的 RPC、HTTP 远程调用，如果通信未采用加密协议，攻击者可能监听并伪造服务请求进行数据窃取；如果微服务的访问控制存在问题，攻击者可能会利用未授权或越权漏洞窃取敏感信息。特别是对于 RPC 方式的调用，较难通过传统流量监控技术识别异常，给数据窃取攻击的防护带来了挑战。（4 4）微服务应用程序安全风

148、险）微服务应用程序安全风险 微服务本身也是独立的应用程序，和传统应用一样，其自身存在的安全问题可能被攻击或利用，包括代码注入、SQL 注入、命令注入等风险。此外，由于调用微服务一般需要进行序列化和反序列化，若对可反序列化的对象控制不严，则可能遭受反序列化攻击。（5 5）微服务框架安全风险）微服务框架安全风险 主流微服务框架多为开源或商业软件，如：Apache Dubbo、Spring Cloud、Kong、Istio 等，框架的各种组件（如：注册中心、网关、配置中心、链路监控、流量控制等）可能存在漏洞，如 2022 年公布的 Spring Cloud Gateway 远程代码执行漏洞（CVE-

149、2022-22947）和 2021 年公布的 Apache Dubbo 远程代码执行漏洞（CVE-2021-30179）。同时，微服务框架中各组件的不正确配置也会带来安全隐患。微服务框架作为基础支撑广泛在金融机构应用，一旦出现安全问题可能造成大范围影响。77 （6 6）缺乏可见性）缺乏可见性 攻击检测和安全事件溯源需要基于应用程序执行情况进行链路分析，传统应用的业务主要由单个程序处理，调用的外部服务较少，容易通过日志或其他技术跟踪用户请求。而微服务实现了业务功能的细粒度拆分和复用，一笔业务一般需要经过数个甚至数十个微服务程序处理，调用链路变长，调用次数显著提升，调用日志数据量大，若缺乏完善的链

150、路跟踪技术支撑，对攻击行为的识别和当出现安全风险时，对微服务调用过程的追踪定位与溯源分析难度变大。2 2）ServerlessServerless 安全风险安全风险 （1 1）访问控制失效）访问控制失效 Serverless 应用提供函数级的无状态服务，需要对每个资源进行访问控制。由于函数服务数量繁多，导致管理权限和角色成为一项非常繁琐的任务。在这种情况下，金融机构可能被迫对所有功能使用单一权限模型或安全角色（如：授予每个Serverless 应用对所有其他系统组件的完全访问权限）。当所有Serverless 应用共享同一组过度特权时，单个 Serverless 应用中的漏洞最终可能升级为系统

151、范围的安全灾难。与其他类型的应用程序类似，随着时间的推移，一些Serverless 应用和相关的云资源可能会过时，脱离访问控制管理，成为攻击者的目标，包括弃用的 Serverless 应用版本、未使用的云资源（存储桶、数据库、消息队列等）、未使用的用户、未使用的软件依赖等。78 （2 2）数据泄露）数据泄露 敏感数据泄露在 Serverless 架构中和其他任何架构一样受到高度关注。传统架构中使用的大多数方法，如：窃取密钥、执行中间人攻击以及在静态或传输中窃取数据，仍然适用于Serverless 应用。但攻击的数据源可能与传统应用不同，攻击者可以瞄准云存储和云数据库服务，而不是从攻陷服务器进行

152、窃取数据。在 Serverless 架构中，密钥、API 令牌、存储凭证和其他敏感设置等机密信息可能在云函数和代码之间共享，这会增加敏感数据泄露的风险。（3 3）函数执行序列控制不足）函数执行序列控制不足 Serverless 应用通常遵循微服务设计范式并包含许多离散功能，这些功能以特定顺序连接在一起，实现了整个应用程序逻辑，调用顺序对于实现所需逻辑可能至关重要。设计可能假设某些功能仅在特定场景下且仅由授权调用者调用，随着应用设计不断变化，这些函数更改了执行序列，从而使攻击者有机可乘并发起业务逻辑攻击，如绕过验证步骤直接处理业务交易。（4 4）底层资源隔离不足）底层资源隔离不足 Serverl

153、ess 平台为 Serverless 应用提供运行环境，在运行环境中，Serverless 应用唯一可写的空间是/tmp。攻击者可以利用 Serverless 应用运行时环境的脆弱性以获取服务端的 shell权限，从而访问/tmp 目录并窃取敏感数据。Serverless 应用在被调用时创建，在调用完成后销毁，在创建时如果存在其他未被销毁的容器，那么 Serverless 应用所处的容器环境的网络、数 79 据资源是被共享的，如果应用将一些数据写入用户空间（如：/tmp），使用后没有手动删除，并且认为容器将会销毁，那么攻击者就可以窃取其他用户的数据。（5 5）ServerlessServerl

154、ess 应用程序安全风险应用程序安全风险 Serverless 应用程序如果没有对外界输入数据进行过滤或编码，可能会出现 SQL 注入、系统命令注入等风险。对于 Python、NodeJS、Java 等动态语言编写的 Serverless 应用，通常应用间传输数据使用序列化，使得 Serverless 中的反序列化攻击更加常见。Serverless 应用是执行单个离散任务的一小段代码，功能往往依赖于第三方软件包、开源库，甚至通过 API 调用第三方远程 Web 服务来执行任务。然而，当导入易受攻击的第三方依赖代码时，即使是最安全的 Serverless 应用也可能变得易受攻击。Serverle

155、ss 架构中提供了许多定制选项和配置设置，以适应特定的需求、任务或环境，某些配置参数对应用程序的整体安全态势具有重要影响。（6 6）拒绝服务）拒绝服务 在 Serverless 架构中，每个事件都在一个单独环境（容器）中处理，传统的 DoS 攻击对 Serverless 应用无法造成严重影响。即使攻击者设法使容器不可用，但他也只会影响进入此环境的函数，而不会影响下一个即将触发的函数。但是，攻击者仍可以针对如下场景进行拒绝服务攻击：函数并发限制（如：触发函数，直到达到预设上限的并发为止）；环境磁盘容量（如：填充 80 /tmp 文件夹，使存储空间不足）；账户读写容量（如：触发允许最大的数据库并发

156、读写数量）；账户配额耗尽（如：消耗账户的网络、存储等资源，使账户配额不足）。（7 7）缺乏可见性）缺乏可见性 虽然许多 Serverless 平台提供了日志记录工具，但因为Serverless 应用执行链路长、创建和销毁频繁，这些日志难以满足完整的安全事件审计跟踪的目的。（8 8）ServerlessServerless 滥用滥用 用户部署完 Serverless 应用后，通常使用 Serverless 平台提供的 API 网关作为触发器，并使用 Serverless 平台提供的域名作为访问入口，这些域名一般具有较高的可信度。攻击者通过Serverless 应用可以隐藏真实攻击 IP，并通过可

157、信域名躲避检测。3 3）云原生）云原生 APIAPI 安全风险安全风险 （1 1）访问控制失效）访问控制失效 未授权访问：未授权访问：云原生环境中，API 未授权访问的风险多是由于应用自身 API 漏洞或访问权限错误的配置导致。应用自身方面，Redis、MongoDB、Jenkins、Docker、Zookeeper 等应用都曾曝光过未授权访问漏洞。访问权限配置方面，由于云原生环境中的API种类和数量相比传统环境显著增加，管理难度大，容易出现使用默认配置或错误配置导致未授权访问。身份认证失效：身份认证失效：认证机制的实施过程不正确，从而允许攻击者破坏身份令牌或利用实施缺陷仿冒其他用户的身份，从

158、整体上损害了 API 的安全性。若 API 存在以下错误认证机制，则会导致 81 身份认证失效风险：允许攻击者对同一账户执行暴力破解，或使用默认弱口令进行密码喷洒，而无需提供验证码/账户锁定机制；允许弱密码；在 URL 中发送身份认证信息，如身份验证令牌和明文密码等；未验证身份令牌过期时间；允许接收未签名/弱签名的 JWT 令牌。错误的功能级别授权：错误的功能级别授权：云原生环境中，API 的调用往往需要不同层次结构、组和角色的复杂访问控制策略，金融业务的复杂性以及业务功能、管理功能、IT 功能的权限涉及众多业务和科技部门，控制策略容易出现疏漏。通过利用这些缺陷，攻击者可以越权访问本不属于其权

159、限级别内用户的资源或管理功能。错误的对象属性授权：错误的对象属性授权：用户请求中可能包含处理对象的ID，如客户编号、交易编号等，在传统单体应用中，应用会校验当前登录用户是否具有业务处理权限。而在云原生环境中，单体应用被拆分成多个小的应用，用户会话信息可能并未通过渠道应用发送到处理具体业务的应用，同时业务处理应用可能完全信任调用方的请求，导致权限校验步骤丢失，出现越权漏洞。（2 2）数据泄露）数据泄露 存量资产管理不当：云原生环境中，API 作为主要的服务交互载体被企业和用户大规模使用。由于 API 数量呈指数级增长，若未对 API 资产进行及时梳理，将会导致资产中出现老旧或存在漏洞的 API，

160、此类 API 可能是第三方公开 API，攻击者可通过资 82 产探测或漏洞利用的手段访问敏感数据，导致数据泄露风险。服务端请求伪造：服务端请求伪造（Server-Side Request Forgery）是一种恶意攻击技术，主要利用应用程序访问资源权限控制不严的漏洞，访问攻击者本不具备权限的资源。如某互联网应用程序提供了日志下载功能，支持用户输入日志地址，攻击者可利用漏洞下载与该应用程序服务器联通的内网服务器上的文件，这些文件原本是无法通过互联网访问的。微软 Exchange 高危漏洞 CVE-2021-26855 就属于该类漏洞。协议增多：云原生应用环境中，应用间的通信不仅采用HTTP/HT

161、TPS 协议，还采用 gRPC、GraphQL 等协议，由于 gRPC 等协议默认不加密，可能为数据泄露带来了更多的风险。（3 3）拒绝服务）拒绝服务 遭受拒绝服务攻击是 API 面临的常见风险，造成拒绝服务的主要原因包含两方面，一方面是由于 API 自身漏洞所致，例如ReDoS 漏洞、Nginx 拒绝服务漏洞、业务功能本身需要消耗大量资源（如大表查询、大量 IO 处理）等。另一方面是由于访问需求与资源能力不匹配所致，API 复杂的调用关系给网络、存储、计算等资源的分配带来了困难，在遇到拒绝服务攻击时更容易出现资源瓶颈。（4 4）缺乏可见性）缺乏可见性 云原生环境中，由于 API 种类和数量增

162、多，调用变得更加复杂，用户请求一般需要经过多个系统进行处理，这些系统可能部署在不同的网络区域、由不同的自有或外部厂商开发、采用不同的技术架构，日志也可能分散在不同的平台，这使得整个 IT 系 83 统的可见性变得缺乏。当 API 资产受到攻击时，很难及时定位攻击入口和攻击链路，从而错过最佳处理时间，增加安全风险。（5 5）供应链安全风险）供应链安全风险 云原生环境中，供应链安全风险更加突出。一方面环境中存在大量供应链产品（如 Kubernetes、Docker、harbor）的 API，另一方面微服务、Serverless 不可避免大量使用第三方组件（如log4j、fastjson），这些供应

163、链程序的广泛使用，可能存在漏洞或后门，增加了产生安全风险的可能。（6 6）APIAPI 滥用滥用 金融机构对重要业务 API 的调用方一般有较严格的控制，这使得只有少部分用户具有调用权限，一些具有权限的用户（如分红、子机构）可能将 API 再次封装提供给外部调用，导致对 API的管控能力变弱，从而引发业务或安全问题。此外，攻击者可能通过高频或慢速低频方式大量调用 API，以获取金融机构数据或通过金融业务获利，如使用自动化工具大量调用金融机构业务营销活动 API，获取红包、立减金等进行倒卖。84 （7 7）东西向防护不足）东西向防护不足 图 16 云原生环境下的东西向流量 云原生应用场景下的流量

164、不仅包含传统基于边界的南北向流量，还包含集群节点间、微服务间、Serverless 应用间访问的东西向流量，如图 16 所示，这给安全防护带来了困难。如果攻击者通过漏洞攻入集群内部，进而可能利用脆弱的认证机制或应用漏洞横向移动入侵至其他微服务、Serverless 应用，导致集群整体的瘫痪或通过容器逃逸到宿主机。3 3云原生应用安全防护云原生应用安全防护 1 1）微服务安全防护）微服务安全防护 （1 1）微服务资产发现与管理）微服务资产发现与管理 云原生环境中，微服务的资产发现与管理机制主要可以分为以下几类：一是服务注册与发现：微服务在启动时将自身的信息注册到服务注册中心，其他微服务可以通过服

165、务注册中心来发现和获取可用的微服务实例。常用的服务注册与发现工具包括 Consul、Etcd 和 Zookeeper。85 二是 DNS 解析：微服务可以通过域名解析来进行资产发现。每个微服务会有一个唯一的域名，其他微服务可以通过解析该域名来获取对应的 IP 地址和端口，从而实现资产发现。三是配置中心：微服务可以通过配置中心来获取其他微服务的信息。配置中心中存储了微服务的相关配置和依赖关系，其他微服务可以通过配置中心来获取需要调用的微服务的地址和端口等信息。四是服务网格：服务网格是一种微服务治理框架，他通过在微服务之间插入一个代理层，实现了对微服务的流量管理和监控。服务网格可以通过代理层来进行

166、资产发现，代理层会自动感知和管理微服务的实例。五是容器编排平台：在云原生环境中，常用的容器编排平台如 Kubernetes、Openshift 等可以用来管理和调度微服务的部署。这些平台可以通过监控和管理容器的方式来实现微服务的资产发现。（2 2）微服务调用链路可视化）微服务调用链路可视化 在基于微服务的云原生架构中，客户端的一次业务请求，会产生大量的微服务调用。追踪这些复杂的调用过程，对于微服务的安全性分析、故障定位，以及性能提升等，有着重要的作用。因此，分布式链路追踪系统是微服务架构下不可或缺的重要组成部分。自 Google Dapper 首先提出分布式链路追踪的设计理念以来，许多分布式链

167、路追踪工具不断涌现。当前，常见的分布式追踪工具包括 Dapper，Zipkin，Jaeger，SkyWalking，Canopy，鹰 86 眼，Hydra，Pinpoint 等。这些分布式追踪工具大致可分为：基于 SDK、基于探针以及基于 Sidecar。基于 SDK 的分布式追踪工具：以 Jaeger 为例，Jaeger 提供了大量可供追踪使用的 API，通过侵入微服务业务的软件系统，在系统源代码中添加追踪模块实现分布式追踪。此类工具可以最大限度地抓取业务系统中的有效数据，提供了足够的可参考指标。但其通用性较差，需要针对每个服务进行重新实现，部署成本较高，工作量较大。基于探针的分布式追踪工具

168、：以 SkyWalking Java 探针为例，在使用 SkyWalking Java 探针时，需将探针文件打包到容器镜像中，并在镜像启动程序中添加-javaagent agent.jar 命令实现探针的启动，以完成 SkyWalking 在微服务业务上的部署。SkyWalking 的 Java 探针实现原理为字节码注入，将需要注入的类文件转换成 byte 数组，通过设置好的拦截器注入正在运行的程序中。这种探针通过控制 JVM 中类加载器的行为，侵入运行时环境实现分布式追踪。此类工具无需修改业务系统的源代码，相对 SDK 有更好的通用性，但其可获取的有效数据相对 SDK 类工具较少。基于 Si

169、decar 实现：Sidecar 作为服务代理，为其所管理的容器实现服务发现，流量管理，负载均衡和路由等功能。在流量管理过程中，Sidecar可以抓取进出容器的网络请求与响应数据，这些数据可以记录该服务所完成的一次单个操作，可与追踪中的跨度信息对应，因此可将 Sidecar 视为一种基于数据收集的分布式追踪工具。Sidecar 无需修改业务系统代码，也不会引入额外 87 的系统的开销。但由于 sidecar 所抓取的跨度不包含追踪链路上下文，要将 Sidecar 所抓取的跨度数据串联成追踪链路是很困难的。（3 3）微服务应用安全防护）微服务应用安全防护 身份认证：身份认证：微服务架构下，服务可

170、以采用 JWT 机制、基于服务网格如 Istio 治理框架自带的认证方式：基于基于 JWTJWT（JSON Web TokenJSON Web Token）的认证）的认证 微服务架构下，每个服务是无状态的，传统的 session 认证方式由于服务端需要存储客户端的登录状态因此在微服务中不再适用。理想的实现方式应为无状态登录，流程通常如下所示：客户端请求某服务，服务端对用户进行登录认证；认证通过，服务端将用户登录信息进行加密并形成令牌，最后再返回至客户端作为登录凭证；在 2 步骤之后，客户端每次请求都需携带认证的令牌；服务端对令牌进行解密，判断是否有效，若有效则认证通过，否则返回失败信息。为了满

171、足无状态登录，可通过 JWT 实现，JWT 是 JSON 风格轻量级认证和授权规范，也就是上述流程中提到的令牌，主要用于分布式场景，其使用流程如图 17 所示：88 图 17 JWT 认证流程 通常可在微服务业务应用中建立 JWT 认证机制，也可通过如云原生 API 网关中自带的 JWT 认证机制去实现微服务认证。基于服务网格的认证基于服务网格的认证 本节主要介绍基于Istio的认证，其安全架构如图18所示：图 18 Istio 安全框架 图 18 展示了 Istio 的认证和授权两部分，Istio 的安全机制涉及诸多组件，控制平面由核心组件 Istiod 提供，其中包含 89 密钥及证书颁发

172、机构（CA）、认证授权策略、网络配置等；数据平面则由 Envoy 代理、边缘代理（Ingress 和 Egress）组件构成。IstioIstio 通常提供两种认证方式：通常提供两种认证方式：对等身份认证：借助控制平面 Istiod 内置的 CA 模块，Istio可实现为服务网格中的服务提供认证机制，该认证机制工作流程包含提供服务签名证书，并将证书分发至数据平面各个服务的Envoy 代理中，当数据平面服务间建立通信时，服务端的 Envoy代理会拦截请求并采用签名证书和另一端服务的 Envoy 代理进行双向 TLS 认证从而建立安全传输通道，保障了数据安全。请求身份认证：请求身份认证是允许最终用

173、户和系统使用请求身份认证，与微服务进行交互。通常使用 JSON Web 令牌（JWT）执行该操作。请求身份认证定义工作负载支持哪些请求身份验证方法。网关或 Sidecar 会根据配置的认证规则对请求进行认证。如果请求携带了非法的认证信息，则会被拒绝。一个请求如果没有包含任何认证信息也会通过认证，但不会获得认证过后的合法身份。（4 4）访问控制）访问控制 微服务架构下，授权服务可以通过基于容器编排系统的角色授权、基于服务网格的授权方式、OPA（Open Policy Agent）策略。基于容器编排系统的角色授权服务基于容器编排系统的角色授权服务 基于角色的授权服务为 RBAC（RoleBased

174、 Access Control），通过角色关联用户，角色关联权限的方式间接赋予用户权限。在微服务环境中作为访问控制被广泛使用，RBAC 可以增加微服务 90 的扩展性，例如微服务场景中，每个服务作为一个实体，若要分配服务相同的权限，使用 RBAC 时只需设定一种角色，并赋予相应权限，再将此角色与指定的服务实体进行绑定即可。若要分配服务不同的权限，只需为不同的服务实体分配不同的角色，而无需对服务具体的权限进行修改，通过这种方式不仅可以大幅提升权限调整的效率，还降低了漏调权限的概率。如果用户选择在 Kubernetes 中部署微服务应用，则可以直接使用 Kubernetes 原生的 RBAC 策略

175、，具体使用方式可参考官方文档。基于服务网格的授权服务基于服务网格的授权服务 有了前述提到的 Istio 认证机制作为基础，Istio 还提供授权机制，其主要用于对服务进行授权。在 Istio 1.4 版本之前，其授权机制依赖于 Kubernetes 的 RBAC 策略，相比 Kubernetes的原生 RBAC 策略，Istio 对其进行了进一步的封装，可让用户直接通过 Istio 的声明式 API 对具体的服务进行授权，不过 Istio为 了 更 好 地 用 户 体 验，在 其1.6版 本 中 引 入 了AuthorizationPolicyCRD（Custom Resource Defin

176、ition），相比 1.4 版本，AuthorizationPolicy CRD 带来了更多的优势，一方面该 CRD 将 RBAC 的配置变得更为简化，从而大幅提升了用户体 验，另 一 方 面 该 CRD 支 持 了 更 多 的 用 例，例 如 对Ingress/Egress 的支持，且同时不会增加复杂性。OPAOPA 策略策略 开放策略代理（OPA）是一个策略引擎，可用于为应用程序实现细粒度的访问控制。OPA 作为通用策略引擎，可以与微服务一 91 起部署为独立服务。为了保护应用程序，必须先授权对微服务的每个请求，然后才能对其进行处理。为了检查授权，微服务对 OPA进行 API 调用，以确定

177、请求是否被授权。通常可以在服务网格集成了 OPA 插件，通过 OPA 定义访问控制策略，实现细粒度的访问控制。（5 5）传统应用安全防护）传统应用安全防护 应用程序代码漏洞缓解：应用程序代码漏洞缓解：应用程序代码漏洞缓解应当从两方面考虑，包括安全编码和安全测试。安全编码：针对安全编码，开发者需要具备安全编码的能力。例如面对 SQL 注入漏洞，开发者需要将数据和命令语句及查询语句分离，那么最佳的选择便是使用相对安全的 API，而避免使用解释器，提供参数化界面的接口及迁移至 ORM 或实体框架。此外，对参数输入的有效过滤，例如白名单机制，也有助于防御注入攻击。再如针对 XSS 类型的漏洞，主要的防

178、护原则为将不可信的输入源与动态的浏览器内容分离，具体实现的手段也非常多，例如使用从设计上就会将危险输入进行编码或转义以防止 XSS 攻击的 Web 框架，例如 Ruby on Rails 或 ReactJS 等。由于漏洞类型较多，本文由于篇幅限制，不再赘述，更多的针对代码漏洞的防护方法可以参考 OWASP 组织发布的应用十大风险报告。安全测试：安全测试工具可以帮助研发团队发现应用漏洞，业界比较主流的测试技术有静态安全测试、动态安全测试、交互式安全测试等。需要注意的是这些工具也不是万能的，可能会产生误报或漏报的现象。92 （6 6）应用程序依赖库漏洞防护）应用程序依赖库漏洞防护 使用受信任的源：

179、使用受信任的源：使用受信任的源是最直接的方法，应用开发者可以仅从官方渠道获取第三方组件，同时也可以关注已含有CVE、NVD 漏洞的第三方组件，避免试错过程，这些含有漏洞可在官方网站上进行查询，例如 Node.js 库 CVE 漏洞列表、Java 库CVE 漏洞列表、Python 库 CVE 漏洞列表。使用软件组成分析工具：使用软件组成分析工具：如果应用程序较为复杂涉及的组件较多，仅通过手动移除含有漏洞的第三方组件往往效率较低，且容易造成漏洞遗漏，鉴于此，业界通常采取软件组成分析（Software Component Analysis SCA）技术，其原理是通过对现有应用程序中使用的开源依赖项进

180、行统计，并同时分析依赖项间的关系最后得出依赖项的开源许可证及其详细信息，详细信息具体包括依赖项是否存在安全漏洞、漏洞数量、漏洞严重程度等。最终 SCA 工具会根据这些前提条件判定应用程序是否可以继续运行。（6 6）应用程序访问控制）应用程序访问控制 随着业务量逐渐复杂，用户数量不断增多，准确识别每个用户需要哪些权限、不需要哪些权限是一件具有挑战性的工作，且为每个用户赋予单一权限的方法易造成权限泛滥的风险，应遵循最小特权原则，即给予每个用户必不可少的特权，从而可以保证所有的用户都能在所赋予的特权之下完成应有的操作，同时也可以限制每个用户所能进行的操作。使用基于角色的访问控制是实现最小特权原则的经

181、典解决方案，基于角色的访问控制就是将主体（用户、应用）划分为不 93 同的角色，然后为每个角色赋予权限，例如上述提到的业务量大，用户数多的应用程序中，使用基于角色的访问控制就显得很有效，定义每类角色所具备的访问权限，这样即便有成千上万个用户，只需按照用户的类型去划分角色，从而可能只需要有限个数的用户角色即可完成访问控制。（7 7）数据安全防护）数据安全防护 应用程序的数据安全防护应当覆盖安全编码、密钥管理、安全协议三方面。安全编码涉及敏感信息编码，密钥管理涉及密钥的存储与更换，安全协议涉及函数间数据的安全传输。安全编码：安全编码：在应用的开发过程中，开发者常常为方便调试将一些敏感信息写在日志中

182、，随着业务需求的不断增多，开发者容易忘记将调试信息进行删除，从而引发了敏感信息泄露的风险。更为严重的是这种现象在生产环境中也频频出现，例如 python的 oauthlib 依赖库曾被通用缺陷列表（Common Weakness Enumeration CWE）指出含有脆弱性风险，原因是其日志文件中写入了敏感信息。此外，一些开源项目可以帮助开发者避免敏感信息被硬编码至源码中，例如 AWS 的开源项目 git-secrets 和 Yelp 的开源项目，读者可以参考。使用密钥管理系统：使用密钥管理系统：为了应用程序环境的安全，应当使用密钥管理机制，该机制主要用于对密钥进行创建、分配、更换、删除等操

183、作。在创建密钥时，利用 KMS（Key Management Service）对密钥值使用指定对称密钥经信封加密后保存在专属的存储空间。如图 19 所示。94 图 19 密钥管理系统架构 当应用程序向 KMS 请求密钥时，可以使用证书对应用进行身份认证，验证通过后似乎用 RBAC 进行权限校验获取角色权限，此外校验网络访问控制权限，在认证和权限检查通过后，KMS 解密密钥并通过 TLS V1.2 协议将其安全地传输给应用，KMS 应用方式如图 20 所示。图 20 KMS 应用方式 使用安全协议：使用安全协议：为避免敏感数据在传输过程中泄露，应确保传输中的数据是加密的，例如 Web 应用中，可

184、以通过使用 HTTPS协议替代 HTTP 协议，确保用户传输的数据不被窃取和篡改，从而在一定程度上避免被中间人攻击的风险。传统应用架构中，可以通过安全编码、使用密钥管理系统和 95 使用安全协议的方式防止数据泄露，在微服务应用架构中，可以考虑使用 Kubernetes 原生的安全机制或微服务治理框架的安全机制去进行防护。针对 Kubernetes 原生的安全机制，例如 Secret 机制，可以使用其进行密钥存储，从而规避了敏感信息硬编码带来的数据泄露风险，更详细的内容可以参考官方文档。针对微服务治理框架的安全机制，如 Istio 支持服务间的TLS 双向加密、密钥管理及服务间的授权，因而可以有

185、效规避由中间人攻击或未授权访问攻击带来的数据泄露风险。（8 8）微服务高可用性）微服务高可用性 针对微服务的高可用机制可以通过容器编排技术实现，容器编排是指通过工具如 Kubernetes，将微服务部署到多个节点和命名空间中，并自动进行负载均衡和故障恢复。这样，当某个微服务出现故障或需要水平扩展时，系统会自动将请求转发到其他可用的实例上，以确保微服务的持续可用性。2 2）ServerlessServerless 安全防护安全防护 （1 1）ServerlessServerless 资产发现与管理资产发现与管理 由于云平台通常缺乏一套自动化机制对现有 Serverless 应用中包含的函数、数据

186、进行分类、追踪，评估等操作，因此开发者在不断完善应用的同时，可能疏于管理，从而导致攻击者利用敏感数据、不安全的函数发起攻击。为了避免这种情况，开发者需要在应用的设计阶段对资产业务进行详细梳理。其中包括但不限于以下几个部分：确认应用中函数的业务类型；96 确认应用中函数的数据类型及数据的敏感性；确认不同函数间的调用关系。（2 2）ServerlessServerless 调用链路可视化调用链路可视化 由于 Serverless 应用通常以微服务形态运行，因而相应调用链路可视化实现也可参考前述微服务安全防护相关章节。（3 3）微服务应用安全防护）微服务应用安全防护 身份认证：由于 Serverle

187、ss 应用通常以微服务形态运行，因而相应身份认证可参考前述微服务安全防护相关章节。访问控制：传统的访问控制防护方法在 Serverless 上也同样适用，可以遵循最小特权原则、使用基于角色的访问控制去实现，可参考前述微服务安全防护相关章节。（4 4）底层资源隔离）底层资源隔离 仅仅对函数层面进行访问控制是不够的，例如攻击者仍可以在 AWS Lambda 运行时环境中通过获取 shell 权限进行滥用，为了预防上述场景的发生，应当从底层进行资源隔离，例如可通过Kata Container、Firecracker 安全容器由上至下进行防护，再如可通过 Kubernetes 的网络策略（Networ

188、k Policy）实现由左至右的网络层面隔离。（5 5）传统应用安全防护）传统应用安全防护 可参考前述微服务安全防护相关章节。（6 6）数据安全防护）数据安全防护 可参考前述微服务安全防护相关章节。97 （7 7）拒绝服务攻击防护）拒绝服务攻击防护 针对拒绝钱包服务（Denial Of Wallet DoW）攻击，公有云厂商可通过提供账单告警机制，如 AWS 开发者可通过在 Lambda控制台为函数调用频度和单次调用费用设定阈值进行告警；或提供资源限额的配置，大多数 Serverless 公有云厂商已提供了以下资源选项供开发者配置：函数执行内存分配；函数执行所需临时的磁盘容量；函数执行的进程数

189、和线程数；函数执行时长；函数接收载荷大小；函数并发执行数。通过上述的选项的合理配置可以在一定程度上减轻 DoW 攻击。（8 8）ServerlessServerless 被滥用的防护措施被滥用的防护措施 访问控制：实施严格的访问控制策略，限制对 Serverless 函数的访问权限。使用身份验证和授权机制，例如使用 API 密钥、OAuth、IAM 角色等来验证和授权请求。限制资源配额：在 Serverless 平台上设置合理的资源配额，限制函数的并发执行数量、内存使用量、执行时间等。这可以防止滥用者占用过多资源，影响其他合法用户的使用。监控和日志：实时监控 Serverless 函数的执行情

190、况，包括请求量、响应时间、错误率等指标。通过日志记录函数的调用情况，可以及时发现异常行为和滥用行为，并采取相应的措施。98 自动化扩展和弹性：使用自动化扩展和弹性功能，根据实际需求动态调整 Serverless 函数的资源配额。这样可以确保函数能够在高负载时提供足够的资源，同时在低负载时节省资源。安全审计：定期进行安全审计，检查 Serverless 函数的代码和配置是否存在漏洞和安全隐患。及时修复漏洞和强化安全策略，以防止滥用者利用漏洞入侵系统。反滥用机制：实施反滥用机制，例如设置访问频率限制、IP封禁等。这样可以防止滥用者通过恶意行为对 Serverless 函数进行滥用。（9 9）Ser

191、verlessServerless 函数高可用性函数高可用性 通常 Serverless 函数的部署形态为容器，借助容器自身的弹性扩缩容机制可达到云函数高可用的效果。3 3）APIAPI 安全防护安全防护 （1 1）APIAPI 资产发现与管理资产发现与管理 API 资产发现是 API 安全的前期信息收集阶段，通常通过多种方式结合来实现，包括人工导入、被动发现和主动扫描。人工导入人工导入是指将 API 资产单个或批量导入到平台的方式。目前广泛使用基于 OpenAPI 标准的 OAS 文件来描述 API。OAS 文件具有以下优势：可读性强：OAS 文件使用简洁的 JSON 或 YAML 格式来描

192、述API，使得文档易于阅读和理解。开发人员可以快速了解 API 的功能、请求和响应参数等信息。与代码同步更新：OAS 文件可以与代码库保持同步更新，确保文档与实际代码的一致性。开发人员可以在代码中直接注释和 99 标记 API，然后使用工具自动生成 OAS 文件，减少了文档与代码不一致的问题。可交互性强：OAS 文件提供了一个可交互的 UI 界面，可以通过该界面来测试 API 的各种请求和响应。开发人员可以在不离开文档的情况下，直接在 UI 界面中进行 API 的调试和测试。可扩展性：OAS 文件支持扩展，可以根据具体需求添加自定义的元数据和注解。这使得开发人员可以在文档中添加额外的信息，如认

193、证方式、权限控制等，提供更详细和全面的 API 文档。缺点是需要维护：随着系统的演化和变化，API 资产也会发生变化，需要定期维护和更新导入的 API 资产。被动发现被动发现是在业务入口处部署 API 网关，通过监控流量来识别 API 资产。当有请求经过 API 网关时，可以被动地发现API 资产并记录下来。此种方式的优点在于：实时性强，被动识别方式可以实时地截获网关流量，及时发现和识别新的 API资产。自动化程度高，不需要人工干预，可以自动地识别和记录 API 资产，减少工作量和人为错误的可能性；缺点在于：精确性有限，被动识别方式可能无法获取到所有的 API 资产信息，特别是一些隐藏的或者不

194、常用的 API。需要依赖网关，被动识别方式需要依赖网关来截获流量，如果系统中没有合适的网关或者网关配置不正确，可能无法进行识别。需要处理大量数据：截获的网关流量可能非常庞大，需要进行处理和分析，可能需要额外的计算和存储资源。主动扫描主动扫描是通过端口扫描和爬虫等技术主动地识别 API 资产。通过扫描网络端口和爬取网站的方式，寻找潜在的 API 资产 100 并进行识别。API 资产是一个动态变化的过程。即使经过一段时间的学习和修正，形成了相对完善的资产列表，也不能保证一劳永逸。因为总会有新的业务上线、旧系统下线，甚至是攻击者植入的恶意代码，这些都可能导致 API 资产与实际情况不同步。因此，A

195、PI资产管理是一个动态的过程。未被纳管的 API 很可能会成为攻击的目标。在已有的 API 资产列表的基础上，自动识别不在列表中的 API，并将其标记为影子 API。对于影子 API，需要确认资产归属和 API 信息，并关注由影子 API 可能引发的安全事件，及早将影子 API 纳入资产列表进行管理。（2 2）OASOAS 文件合规性校验文件合规性校验 在云原生环境中，存在多个微服务应用，每个微服务由不同的研发团队和开发语言构成。这些微服务之间需要通过 API 进行交互。然而，传统的 API 文档记录方式存在一些问题，比如更新不及时、可读性不强、交互性弱、可扩展性差等。为了解决这些问题，广泛使

196、用基于 OpenAPI 标准的 OAS 文件来描述 API。针对 OAS 文件的合规性校验，可分为两个方面的内容。首先，校验 OAS 文件自身的格式是否合规。其次，通过 OAS 文件中预先定义的 API 语义信息作为基准，进行被动流量检测，识别异常参数、调用方法等。（3 3）APIAPI 威胁防护威胁防护 API 漏洞缓解：针对传统的 API 风险，可以使用传统的 API防护方式，例如针对失效的认证，可以采取多因素认证的方式或 101 采用账号锁定、验证码机制来防止攻击者对特定用户的暴力破解，再如针对失效的功能授权，应当默认拒绝所有访问，并显式授予特定角色访问某一功能，更多典型的 API 防护

197、方式各位读者可以参考 OWASP 组织在 2023 年发布的 API 十大风险报告，该报告针对每种典型风险均提出了较为详细的防护方法，本文限于篇幅，不再赘述。API 滥用识别：云原生环境中，可通过微服务安全小节中提出的调用链路可视化技术获取 API 上下文信息及调用拓扑，这些信息可以作为 API 滥用防护引擎的输入源，通过业务异常检测引擎（如图 21 所示）对正在运行的业务系统进行异常检测。图 21 业务异常检测引擎设计 检测引擎中每部分的具体功能为：分布式追踪工具。相比 Skywalking、Sidecar，Jaeger 可获取的数据字段最多，能够检测的异常场景最丰富，然而，Jaeger需要

198、在业务系统的源代码中进行插桩，对开发团队而言有较强的侵入性。相反，Sidecar 模式没有代码和镜像的侵入性，但通过反向代理截取流量的模式也决定了他不能获得丰富的上下文，如云原生应用的 API 调用关系树（TraceID）是无法获得的。如何 102 利用侵入性更低的采集工具收集到的数据来实现覆盖更多场景的异常检测仍需要很多后续工作。数据筛选与整合模块。此模块主要功能为过滤掉数据集中的脏数据，以及提取出可以表示业务系统行为的数据。在云原生应用中，可以表示业务系统行为的数据为 API 调用关系树、服务名、操作名、HTTP POST 参数等。数据训练模块。将预处理后的历史数据利用机器学习或统计学的方

199、法，训练出业务系统中的正常行为，并生成与业务系统正常行为匹配的特征数据。业务系统中大量存在的行为是正常行为，而数量很少的行为是异常行为。在训练过程中，需要根据专家知识对训练结果的检验不断调整训练模型的参数。检测引擎。将业务系统当前数据与特征数据库中数据进行检索匹配，并利用序列相似性计算等方法找出特征数据库中与当前行为最为匹配的特征数据。检测引擎需要将特征数据与当前数据的相似性与基线进行比较，若比较结果显示当前行为与正常行为的差异在基线限制范围内，则为正常行为，若超出基线限制范围，则判定为异常行为。对于基线，首先需要根据专家知识设置合理的初始基线，并根据不同场景，或利用无监督模型自行调整基线，或

200、由运维人员手动维护基线。（4 4）APIAPI 异常行为检测异常行为检测 API 在业务中的应用非常广泛且灵活。不同的 API 调用顺序和条件组合可以满足不同的业务需求。然而，这也给 API 带来了风险，因为攻击者可以利用业务逻辑漏洞对 API 进行攻击。传统的通用型攻击可以被常规的检测手段发现，但基于业务 103 的逻辑漏洞攻击很难被及时发现。因此，需要使用基于用户和实体行为分析（UEBA）的行为建模来识别异常行为。实时监控高风险 API 接口、涉及敏感信息的 API 流转、涉敏应用、缺少认证的访问等异常情况。同时，使用威胁建模可以定义异常时段 API 访问检测、异常 API 访问次数检测，

201、以及基线外IP 访问 API 检测等。通过对各种类型的接口请求和响应数据进行基线分析，可以发现接口设计中的安全弱点，找出可能导致敏感数据泄漏和账号风险的接口。举例说明，通过学习客户端账号的行为基线，可以发现普通账号和特权账号在行为时间、访问 API 和传输数据方面的差异。当普通账号越权访问特权账号时，就可以及时发现异常行为，并引入人工研判来确认异常的严重程度和优先级。4 4云原生应用安全解决方案云原生应用安全解决方案 104 图 22 云原生应用安全解决方案 云原生应用安全解决方案可以从微服务安全、Serverless安全和 API 安全三个方面进行防护，如图 22 所示。微服务安全主要关注微

202、服务应用的资产和安全性，以及访问控制和调用链路的可视化。保护微服务应用的重要数据和功能，确保不受未授权访问和恶意攻击的影响。根据安全责任划分原则，Serverless 安全聚焦于保护应用本身和应用部署平台的安全。此外，Serverless 特征也会引发一些风险，如 API 滥用，因而解决方案也应该具备相应的防护措施。API 安全则从 API 的整个生命周期来进行防护。在 API 开发的早期阶段，需要有效地发现、分类和分级 API 资产，这将成为后续 API 检测和防护的重要依据。此外，由于云原生环境下 API交互的增加，解决方案还应提供基于 IP、域名、业务和 API 数据实体的多角度资产画像

203、可视化，以及数据标签、数据风险、安全事件探索和全方位的访问记录可视化能力，即数据流转可视化能力。1 1）微服务安全）微服务安全 微服务安全根据不同的应用场景可以分为三种解决方案：RASP、Service Mesh（服务网格）和平行容器。RASP 方案适用于将业务以容器或 Pod 形式部署的用户，如图 23 所示。在构建微服务镜像时，RASP 会将防护模块注入镜像中，以实现容器运行时的实时防护。可以监控和保护应用程序的运行状态，例如防止 SQL 注入、跨站脚本攻击和命令注入等安全威胁。与传统的防火墙、IPS/IDS 等安全技术不同，RASP 能够深入到应用程序内部，确保应用程序的安全性。凭借 R

204、ASP 注入应 105 用的特性也可以实现微服务内东西向的安全防护，同时为应用增加身份标签实现应用级零信任。图 23 RASP 部署示意图 Service Mesh 方案适用于业务已经使用微服务治理框架（如Istio）进行治理的用户，如图 24 所示。利用 Service Mesh 的边车容器，并注入安全模块来实现微服务的安全防护。这种方案具有安全模块与业务分离的特点，降低了整体系统的复杂性。106 图 24 Service Mesh部署示意图 平行容器方案适用于业务通过主流容器编排工具（如Kubernetes）进行治理的用户，如图 25 所示。通过平行容器来收集微服务和节点信息，并通过流量传

205、输方式将微服务的七层流量传输到安全引擎中。这样可以实现应用访问控制、API 限速，甚至提供云原生 WAF 攻击防护能力，以应对 OWASP 应用安全十大风险。图 25 平行容器部署示意图 107 微服务安全方案能力展示，如图 26 所示：图 26 微服务安全功能视图 在容器集群中，微服务安全解决方案通常包括三个功能层：接入层、处理层和可视化层。一是接入层负责微服务的发现，包括服务的 IP 和端口等信息。他还通过一定的引流方式将集群的流量导入到处理层进行进一步的分析和处理。服务发现技术自身依赖容器编排平台内部机制，如通过调用容器编排系统的 API Server 组件对微服务状态进行监测，以便及时

206、捕捉微服务实时状态。需要注意的是在生产环境中，常存在多个业务集群，由于涉及跨集群的服务发现，因此服务发现需要由单集群模式扩展为多集群模式，即能识别到服务在多集群中的变化，需要涉及多集群管理 API 概念的介入，主流容器编排平台如 Kubernetes 已提出 Fed2 集群联邦机制用于处理此业务场景，除此之外，采用多集群编排开源框架如KubeSphere 也可较好地解决此问题。二是处理层负责收集集群中微服务的基础信息并进行存储。同时，他还会收集集群的实时流量，并进行威胁检测、可观测性 108 和异常行为检测。在威胁检测方面，他覆盖了 OWASP 应用安全风险的防护，并通过 Service Me

207、sh Envoy 代理实现微服务间的认证授权和流量治理，例如百分比路由、熔断、故障恢复、金丝雀部署和超时重试等功能。在可观测性方面，他利用 Service Mesh Envoy代理实现微服务的可观测性能力，包括日志、监控和追踪。日志可以对接主流的开源云原生日志平台，如 Fluentd 和Logstash；监控可以对接主流的开源云原生监控平台，如Prometheus 和 Cortex；追踪可以对接 Jaeger 和 Skywalking 等APM 平台。需要注意的是，Sidecar 在 Pod 级别共享代理会引入CPU、内存资源利用不足的问题，为了解决此问题，Istio 在 2022年 9 月推

208、出了主机代理模式（Ambient mesh），这种模式将会带来许多优势，除了解决性能问题之外；还包括不侵入业务 Pod，自身升级或重启时不会影响主线业务等优势；Ambient mesh 将Istio 分成了上下两层，如图 27 所示，底层主要处理 L4 层流量及零信任安全，通常以 Kubernetes 的 Daemonset 资源部署在每个节点上，上层处理 L7 层流量，通常以 Deployment 部署，可动态伸缩。需要注意的是，上下层对应的能力是独立的，如果用户无需 L7 层流量管理那么只部署底层能力即可，此外两层均无需对业务 Pod 进行修改。109 图 27 Ambient mesh

209、流量处理分层 在异常行为检测方面，方案支持基于 UEBA 的行为建模，例如基于微服务访问频次和参数异常等进行建模分析。三是可视化层主要负责将处理层的结果进行可视化展示。他可以展示微服务资产的访问统计、微服务安全事件统计、微服务安全日志、微服务资产管理等信息，使用户能够直观地了解微服务的安全状况。2 2）ServerlessServerless 安全安全 Serverless 安全包括运行时安全、可信软件供应链、基础架构安全，如图 28 所示。110 图 28 Serverless 安全功能视图（1 1）运行时安全）运行时安全 安全巡检：安全巡检：攻击者往往是利用应用 Pod 中开启的不必要的特

210、权能力发起逃逸攻击，开发人员应该遵循权限的最小化原则配置应用部署模板，因此需要具备应用运行时刻的安全配置巡检能力，策略管理：策略管理：PSP（PodSecurityPolicy）是 Kubernetes 中 Pod部署时重要的安全校验手段，能够有效地约束应用运行时的行为安全。他能够在应用部署时对 Pod 进行强制的安全校验，在集群的安全纵深防护中发挥了像 AppArmor，SELinux 这类策略引擎的作用。PSP 是 Kubernetes 原生的集群维度资源模型，通过 API Server 的 Admission Controller 准入机制，在应用部署时刻对Pod 的安全参数进行强制校验

211、。如果参数配置不满足指定 PSP 策略的定义，API Server 会禁止该 Pod 的部署请求。运行时监控和告警：运行时监控和告警：当容器应用通过 API Server 的认证鉴权和准入控制校验成功部署后，在云原生应用零信任的安全原则下，还需要在容器应用的运行时刻提供相应的安全监控和告警能力。安全沙箱管理：安全沙箱管理：相比于原有 Docker 运行时，安全沙箱提供一种新的容器运行时选项，可以让应用运行在一个轻量虚拟机沙箱环境中，拥有独立的内核，具备更好的安全隔离能力。安全沙箱特别适合于不可信应用隔离、故障隔离、性能隔离、多用户间负载隔离等场景。在提升安全性的同时，对性能影响非常小，并且具备

212、与 Docker 容器一样的用户体验，例如日志、监控、弹性等。111 机密计算：机密计算：机密计算可以把重要的数据和代码放在一个特殊的可信执行加密环境（Trusted Execution Environment，TEE）中，而不会暴露给系统其他部分，其他应用、BIOS、OS、Kernel、管理员、运维人员等，甚至除了 CPU 以外的其他硬件均无法访问机密计算平台数据，极大减少敏感数据的泄露风险。（2 2）可信软件供应链）可信软件供应链 镜像扫描：镜像扫描：容器镜像扫描可以识别镜像中已知的漏洞信息包括漏洞信息评估和相关的漏洞修复建议，降低使用容器的安全风险。容器镜像扫描需要支持镜像系统漏洞、镜像

213、应用漏洞和镜像恶意样本的识别。镜像签名：镜像签名：镜像的创建者可以对镜像做数字签名，数字签名将保存在容器镜像服务中。通过在部署前对容器镜像进行签名验证可以确保集群中只部署可信授权方签名的容器镜像，降低运行意外或恶意代码的风险，确保从软件供应链到容器部署流程中应用镜像的安全和可溯源性。云原生应用交付链：云原生应用交付链：在容器安全高效交付场景中，建立交付云原生的应用交付链，配置镜像构建、镜像扫描、镜像全球同步和镜像部署等，自定义细粒度安全策略，实现全链路可观测、可追踪的安全交付。保障代码一次提交，全球多地域安全分发和高效部署，将 DevOps 的交付流程全面升级成 DevSecOps。（3 3）

214、基础架构安全）基础架构安全 默认安全：默认安全：容器服务集群节点、所有系统组件按照某个安全基线例如 CIS kubernetes benchmark 进行加固，同时保证系统组件镜像没有严重级别的 CVE 漏洞。112 每个新建集群有严格的网络访问控制基线，例如对于公网入方向仅允许 ICMP 请求，默认不允许公网 SSH 连入，通过 NAT 网关访问公网等。身份管理：身份管理：容器集群内所有组件之间的通讯链路均需要 TLS证书校验，保证全链路通讯的数据传输安全。细粒度访问控制：细粒度访问控制：基于 Kubernetes RBAC 实现了对容器集群内 Kubernetes 资源的访问控制，他是保护

215、应用安全的一个基本且必要的加固措施。此外可以安装 Gatekeeper 组件，提供基于 OPA 策略引擎的细粒度访问控制能力。审计：审计：集群 API Server 审计，记录或追溯集群访问者的日常操作，可基于日志内容设置对指定资源类型操作的实时告警。Ingress 流量审计，审计集群 Ingress 的整体状态，通过算法从 Ingress 的指标中自动检测异常点，提高问题发现的效率。事件监控审计，实时诊断集群的异常和安全隐患。SecretSecret 落盘加密：落盘加密：Kubernetes 原生的 Secret 模型在 etcd落盘时只经过了 Base64 编码，为了保护 Secret 中

216、敏感数据的落盘安全性，可以使用密钥管理服务 KMS（Key Management Service）实现应用敏感数据的落盘加密。113 3 3）APIAPI 安全安全 图 29 API 安全部署视图 在云原生环境下，API 安全模块可以根据具体场景的需求进行不同方式的部署，以实现全向流量防护和南北向流量防护。以下是几种常见的部署方式，如图 29 所示：（1）节点部署（Daemonset 资源）：适用于全向流量防护场景。API 安全模块会被部署在每个集群节点上，通过引流机制对当前节点中工作负载之间产生的 API 流量进行相应的防护。（2）边车部署（Sidecar）：适用于南北向流量防护。API 安

217、全模块以边车的方式部署在每个微服务容器旁边，监控和保护微服务与外部请求之间的流量。（3）Deployment 部署：适用于全向流量防护。API 安全模块以 Kubernetes 的 Deployment 资源方式进行部署，具备弹性扩缩容的特点。他可以根据流量负载的情况自动进行扩展或缩减，以满足应用的需求。（4）需要注意的是，随着 eBPF 技术的兴起，传统基于iptables 进行微服务引流的技术存在一些劣势。例如，频繁经过Linux 网络协议栈增加通信链路会导致性能下降，使用 eBPF 技 114 术，这种限制不再存在。开发人员可通过 hook 不同内核函数加速流量劫持效率，提高整体系统的吞

218、吐率。图 30 API 安全功能视图 API 安全解决方案通常包括接入层、处理层、分析层和可视化层的功能，如图 30 所示。（1）接入层负责接收 API 流量，可以从多个来源获取，包括基于 OpenAPI 标准的 OAS 文件、源码、API 导入和第三方工具导入等。（2）处理层负责对 API 数据进行处理、识别、检测和响应。由于云原生环境中 API 协议类型繁多，很难从系统或应用层面清晰地区分他们，所以处理层需要进行 API 协议解析，完成基础的识别工作，包括去重、比对、识别和打标等。对于检测到具有攻击特征的 API，处理层还需要采取相应的措施，如实时阻断、定时封堵、动态脱敏和告警提示等。（3

219、）分析层是系统的核心能力，负责进一步处理处理层输出的信息，并给出确定性的结果或指令。他包含以下几个功能模块：APIAPI 发现发现：根据 API 流量特征进行主动和被动的 API 发现，115 输出 API 资产列表，为后续的安全检测和识别提供基础。APIAPI 分级分类分级分类：采用行业数据标准进行 API 分级，使用规则和机器学习方法对 API 进行分类。APIAPI 合规性校验合规性校验：支持对符合 OpenAPI 2.0 和 3.0 标准的OAS 文件进行合规性检测，支持基于 OAS 语义的流量合规性检测。OWASP APIOWASP API 风险防护风险防护：提供对 OWASP AP

220、I 安全十大风险的安全防护措施。APIAPI 异常行为检测异常行为检测：支持基于 UEBA 的行为建模，识别异常行为。可以实时监控高危 API 接口、涉及敏感信息的 API 流转、缺少认证的 API 访问以及异常访问次数超过预设阈值的 API 等。APIAPI 滥用识别：滥用识别：支持提前识别自动化工具的客户端，避免 API滥用行为的出现。具体流程可包括：一是客户端 APP 鉴权：通过静态、动态的方式验证客户端的可靠性；二是指纹信息采集：收集 C 端设备的硬件、软件信息，生成 ID 数据，以便进行区分；三是环境信息采集：检测 C 端的运行环境，收集数据以便初步确认客户端的安全性；四是 Toke

221、n 生成并传递：以动态代理的方式注入并传递 token 数据给 API 安全引擎。APIAPI 行为审计与溯源：行为审计与溯源：一是支持通过安全事件获取客户端信息，包括源 IP、用户名、token、客户端指纹；通过客户端指纹可追溯源 IP 和用户名；用户名可以追溯源 IP。二是通过已有客户端信息进行自动化分析，包含情报（通过源 IP 匹配情报信息，获取源 IP 标签）；安全告警（通过全部的安全告警进行风险评分）；业务系统（访问的域名和 API 是否正常，例如：是否访问了僵尸 API、过期 API；访问的 API 与用户权限是否保持一致）。116 三是针对客户端信息，提取所有审计日志供人工分析。

222、（4）可视化层负责将分析层的结果进行可视化展示，包括API 资产的访问统计、API 安全事件的统计、API 安全日志和 API资产管理等信息，使用户能够直观地了解 API 的安全情况。（四）云原生计算环境与基础设施安全（四）云原生计算环境与基础设施安全 1 1概述概述 云原生计算环境与基础设施安全包含 7 个一级能力、40 个二级能力和 198 个三级能力，如图 31 所示。图 31 计算环境和基础设施安全范围 2 2云原生基础设施安全云原生基础设施安全 1 1）计算安全）计算安全 （1 1）安全风险安全风险 云原生基础设施计算环境是指在云计算平台上构建和运行应用程序的一种环境。这种环境旨在充

223、分利用云计算的优势，如弹性、可伸缩性和灵活性，以满足现代应用程序的需求。以下是一些常见的云原生基础设施计算环境的安全风险：117 虚拟机漏洞：虚拟机可能受到漏洞的影响，攻击者可以利用这些漏洞来入侵系统、获取权限或执行恶意代码。恶意软件：恶意软件可能感染到虚拟机或应用程序中，可能导致数据损失、服务中断或信息泄漏。内部威胁：内部人员可能滥用他们的权限，泄露敏感信息或故意破坏系统。配置错误：错误的配置设置，如不正确地访问控制、开放的端口或默认凭证，可能导致安全漏洞。缺乏监控和日志记录：缺乏充分的监控和日志记录可能导致未能检测到异常活动或安全事件。身份和访问管理问题：不正确的身份和访问管理设置可能导致

224、授权不当、滥用权限或提升攻击者的权限。社会工程和钓鱼攻击：攻击者可能通过欺骗、诱骗或钓鱼攻击来获取凭证或敏感信息。（2 2）建设思路建设思路 资产管理资产管理：建立一个完整的资产清单，包括基础设施、虚拟机等，并进行定期的资产扫描和漏洞评估，确保资产的完整性和安全性。配置合规配置合规：根据相关的安全标准和最佳实践，制定配置策略，确保云环境基础设施的配置符合安全要求。定期进行配置审计，及时发现和修复非法或不安全的配置。风险发现风险发现：实施风险评估和漏洞扫描，定期检查云原生基础设施的安全状况，及时发现潜在的风险，并采取相应的措施进行修复。118 资源隔离资源隔离：使用网络隔离、虚拟化技术等手段实现

225、资源的隔离，防止不同的云原生基础设施之间的相互干扰和入侵。入侵防范入侵防范：采取防火墙、入侵检测系统、入侵防御系统等安全技术，对云原生基础设施进行实时监控和保护，及时发现和阻止入侵行为。恶意代码防范恶意代码防范：使用杀毒软件、恶意代码检测工具等技术，定期对云原生基础设施进行恶意代码扫描，及时清除潜在的威胁。响应处置响应处置：建立应急响应机制，对安全事件进行及时处置，加快恢复云原生基础设施的正常运行，同时进行事后分析和整改措施。安全有效性验证安全有效性验证：进行安全测试和演练，验证云原生基础设施的安全有效性，并及时修复发现的安全漏洞和问题。具体来说，包括以下几方面有效性验证：验证资产管理有效性：

226、如通过部署伪装成现有主机或者植入恶意进程的主机达到持久化目的的方式，验证资产发现的有效性。验证配置合规有效性：如通过模拟不符合基线要求的资源配置，验证配置合规的有效性。验证风险发现有效性：如通过模拟含有漏洞的主机、错误的风险配置、对现有主机进行扫描、提权、逃逸等操作，验证风险发现的有效性。验证风险发现有效性：如通过模拟含有漏洞的主机、错误的风险配置、对现有主机进行扫描、提权、逃逸等操作，验证风险发现的有效性。验证资源隔离有效性：如通过发现或者模拟漏洞，利用漏洞 119 进行逃逸到宿主机或者横向移动到不同的计算环境等手段，验证资源隔离的有效性。验证入侵防护有效性：如通过发现或者模拟漏洞，利用漏洞

227、进行注入攻击、实施反弹等技术手段，验证入侵防护的有效性。验证通信安全有效性：如通过模拟信息窃取、信息污染、中间人伪造等手段，验证通信安全的有效性。验证设备自身安全有效性：如通过模拟可能含有漏洞的应用或配置不需要的最大权限，查看安全能力是否在限定的时间内升级应用和更正最小权限等手段，验证设备自身安全的有效性。2 2）网络安全）网络安全 （1 1）安全风险安全风险 随着互联网和云计算的发展，越来越多的企业将业务迁移至云环境中运行。此时承载云业务的云计算环境的基础设施的稳定和安全运行尤为重要。针对云原生基础架构的网络安全风险主要凸显表现在以下几个方面：不安全的通信：不安全的通信：如果在云原生应用程序

228、中的通信不加密，攻击者可以拦截传输的数据包，从中获取敏感信息，如用户凭据或敏感数据。因此，应用程序之间和应用程序与数据库之间的通信需要使用加密协议（例如 TLS/SSL）来保护数据。不安全的不安全的 APIAPI：云原生应用程序通常通过 API 进行通信，如果 API 没有足够的安全措施，攻击者可能会滥用他们来执行未经授权的操作。这包括缺乏适当的身份验证和访问控制，以及不充分的输入验证。不足的网络隔离：不足的网络隔离：如果云原生应用程序的网络环境没有适当 120 隔离，攻击者可能能够通过侧向移动来访问其他容器、服务或资源。虚拟私有云（VPC）或网络策略可以帮助实现网络隔离。API API 密钥

229、和凭据管理：密钥和凭据管理：如果 API 密钥、凭据或访问令牌不受适当保护，攻击者可能会窃取这些凭据并滥用他们来访问云资源或云服务。恶意流量：恶意流量：云计算环境中的恶意流量指的是网络上传输的数据流，其中包含有害或恶意内容，通常是由攻击者故意发送或注入的。常见的恶意流量包含：DDoS 攻击流量、恶意软件传输、网络扫描和漏洞利用、恶意命令和控制流量（C2）、恶意数据包注入。未知威胁：未知威胁：未知威胁是指尚未被广泛识别或记录的潜在威胁或攻击，通常指那些新颖、复杂或深度隐藏的安全风险。这些威胁可能来自恶意行为、漏洞利用、恶意软件或其他安全漏洞，但尚未被传统的安全工具和方法检测到或防御措施所覆盖。综

230、上所述云原生基础网络的安全问题涉及多个方面。因此，需要采取纵深防御体系保障基础设施稳定运行。（2 2）建设思路建设思路 访问控制访问控制：建设云计算基础设施的访问控制是确保整个云环境安全性的关键要素。访问控制的建设中，首先确定谁可以访问云资源以及访问的级别。制定明确的访问策略，包括用户、角色、组织单元和资源的访问权限。其次利用访问控制列表（ACLs）或策略来定义资源级别的细粒度访问控制。在云环境中建立网络隔离，以确保不同的资源和服务之间具有足够的隔离。虚拟专用云（VPC）和安全组是实现网络隔离的工具。实施弹性访问控制，121 根据需要调整访问权限。这意味着可以随时调整权限，以适应不同用户或资源

231、的需求。入侵防范入侵防范：建设云计算入侵防范的思路是确保云环境的安全性，防止未经授权的访问、数据泄露和恶意活动。首先，明确你的威胁监测目标。这可以包括网络流量、系统日志、终端设备、云服务等。确定你要监测的关键资产和区域。其次部署实时监控系统，监控网络流量、系统日志和用户活动。这些系统应能够立即检测到潜在的威胁，并提供警报。使用行为分析和机器学习技术来检测异常活动。这可以帮助识别不寻常的模式和行为，包括高级威胁。最后不断改进威胁监测策略和技术，以适应不断变化的威胁环境和新兴的攻击技术。通信安全通信安全：云计算通信安全建设是确保在云环境中传输数据和信息时的安全性的关键组成部分。首先，明确定义云计算

232、环境的等级，以便根据等级要求采取适当的通信安全措施。其次强制对敏感数据在传输过程中进行加密。使用强加密协议（如TLS/SSL）来保护数据的机密性和完整性。确保加密密钥的安全存储和管理。最后使用安全网关来检查传入和传出的流量，以确保他符合安全策略要求。响应处置响应处置：云计算环境中，响应处置是指如何应对发生的安全事件和威胁，以降低损害并确保业务的可持续性。当发生安全事件时，平台应该能够及时检测到事件的发生，并迅速采取相应的响应措施。平台应具备监测记录能力，一旦发现安全事件，平台应具备能力对事件进行深入分析和溯源，以确认事件的发源地和影响范围。通过分析日志和监控数据，平台应能够追溯事件的 122

233、根本原因，并揭示事件的传播路径和影响范围。基于分析和溯源的结果，平台应迅速采取相应的处置措施，以减轻事件可能带来的影响和损失。平台应实施自动化的处置策略，如隔离受感染的容器、限制攻击者的访问、修复漏洞等。在处置过程中，平台应能够及时通知相关的人员和团队，以协同进行事件处置。平台还应提供一个中央管理界面，用于跟踪和记录事件的处置过程，以供后续的审计和分析之用。最后，平台应能够对安全事件进行全面地分析和总结，以提高平台的整体安全性和应急响应能力。能够自动化地汇总和分析事件数据，生成安全事件的报告和分析结果，为未来的安全改进提供有利的参考。这种持续的学习和改进过程有助于提升平台的安全性，确保他能够有

234、效地应对不断演化的威胁和风险。设备自身安全设备自身安全：云计算中设备自身的安全建设思路旨在确保终端设备在云环境中具备足够的安全性，以有效减少潜在的威胁和攻击风险。这一思路强调了一系列关键策略和实践，以确保设备的安全性、可用性和可靠性。首要之务是确保终端设备的操作系统和应用程序保持最新的安全状态。这可以通过定期进行安全更新和应用补丁来实现，以修复已知的漏洞和弥补安全漏洞。在这一过程中，自动化补丁管理工具可以起到关键作用，简化了安全更新的部署和管理，提高了效率。其次，定期扫描设备已发现潜在的漏洞是设备自身安全的重要环节。这种漏洞扫描可以识别设备中存在的漏洞和弱点，从而使组织能够及时采取措施，例如应

235、用安全补丁和更新，以减少潜在攻击者的攻击面。这是一项持续的工作，以确保设备的持 123 续安全性。最后，制定设备安全事件的应急响应计划至关重要。这一计划包括一系列步骤，以应对可能发生的安全事件，如设备受到威胁或遭受攻击。应急响应计划涵盖了设备的隔离，以防止威胁扩散，恢复设备的正常运行，通知相关方和进行详细的调查以了解事件的起因和影响。这确保了组织在面临设备安全问题时能够迅速而有效地应对和解决。安全有效性验证安全有效性验证：在网络安全中，建设安全有效性是一项至关重要的任务，因为他确保了网络安全措施不仅仅是一次性的、局部的解决方案，而是具备长期有效性和可持续性的安全策略。首先，全面的风险评估是建设

236、安全有效性的基础。这一步骤是为了深入了解组织所面临的威胁和漏洞，这些威胁和漏洞可能来自内部或外部，以及由各种因素引起的。风险评估的目标是识别潜在的威胁，确定他们的影响程度，并评估其发生的可能性。这使得组织能够根据威胁的优先级来制定有效的安全对策。建立有效的风险管理流程是建设安全有效性的下一步。风险管理流程包括识别风险、分析风险、评估风险和处理风险。这意味着组织不仅要识别问题，还要采取措施来减轻、转移或接受风险。这一过程不仅有助于降低潜在的威胁，还能够更好地分配资源以应对安全挑战。制定明确的网络安全策略和计划是确保网络安全有效性的关键一步。这些策略和计划需要明确定义组织的安全目标和战略。安全策略

237、应该与组织的业务需求和风险分析相一致，以确保安全措施不会妨碍业务运营。这些策略和计划还应该包括适当的安全政策、流程和控制措施。采用多层次的安全措施是确保网络安全有效性的重要组成部分。这意味着不依赖于单一的安全措 124 施，而是在各个层次和领域都应用安全性。例如，网络安全、终端安全、身份认证和访问控制、威胁检测和响应等。这种多层次的防御策略可以提高安全性，因为他不仅仅依赖于单一点的安全性。其次利用自动化和人工智能技术来提高安全性和效率是建设安全有效性的一种重要方式。自动化可以加速威胁检测和响应，减少人为错误的机会。例如，自动化的安全系统可以实时监控网络流量，快速识别异常并采取措施，而无需人工干

238、预。这提高了安全性，并降低了安全事件的响应时间。最后，不断评估和改进网络安全措施是确保安全有效性的关键。网络环境和威胁是不断变化的，因此安全策略和措施也需要不断适应新的挑战。定期的演练和测试有助于发现潜在的漏洞，并通过改进来提高安全性。这个过程是持续的，确保网络安全不断适应不断变化的威胁环境和新兴的攻击技术。3 3）存储安全）存储安全 （1 1）安全风险安全风险 云存储是云环境技术中的一项重要服务，他提供了便捷的数据存储、备份和共享解决方案，但与之伴随着一系列潜在风险，数据存储在云上可能受到黑客攻击、恶意软件、病毒或数据泄露的威胁。如果云环境未能采取足够的安全措施，组织的敏感信息可能会被盗取或

239、损坏，恶意软件和病毒也可能通过云存储服务传播，危害组织数据的完整性和安全性。以下是云存储的主要风险因素。身份认证风险：身份认证风险：身份验证过程中可能出现的各种潜在威胁，包括弱密码、密码泄露、钓鱼攻击、社交工程、中间人攻击等，125 这些风险可能导致未经授权的组织或攻击者获取系统或数据的访问权限。数据所有权问题：数据所有权问题：存储在云中的数据可能引发责任划分，因为组织可能认为他们拥有数据的所有权，但云服务提供商也可能主张一定的控制权。敏感信息泄露风险：敏感信息泄露风险：组织的敏感信息和重要数据存储在云中，如果未能适当保护这些数据，可能会导致组织的敏感信息泄露，造成较大的影响。数据损坏风险：数

240、据损坏风险：硬件故障、人为错误、恶意软件、病毒或网络攻击可能导致数据受到破坏、篡改或加密，以及数据的不可用性。合规性问题：合规性问题：国家和行业对于数据存储和处理有相应法规和标准要求。如果未能遵守这些规定，组织可能会面临法律风险和经济损失。综上所述，云存储虽然提供了众多优势，但也伴随着一系列潜在风险。为了最大程度地降低这些风险，组织需要采取适当的安全和合规措施，定期监控云存储服务的安全性，标准化的安全运营来保护数据和隐私。（2 2）建设思路建设思路 身份认证与权限控制身份认证与权限控制：云存储的关键优势之一是其强大的身份认证和权限控制能力。通过先进的技术工具和机制，确保只有经过授权的组织可以访

241、问特定的数据，同时精确限定他们的权限范围，通过多因素身份认证（MFA）要求组织在登录时提供多个验证要素，例如密码、生物识别、短信验证码或硬件令牌，以确 126 保只有授权的组织能够访问云存储中的数据。其次，基于角色的权限管理为不同组织分配了特定的角色，每个角色都有明确定义的权限级别。这使管理员能够更好地控制和管理组织对数据的访问权限，确保只能执行其职责所需的操作，遵循最小化访问原则。此外，细粒度的权限控制进一步细化了数据访问权限，使其可以根据具体数据和组织需求进行调整。这意味着即使在同一角色下，不同组织也可以拥有不同的权限，从而实现了高度个性化的数据访问控制。最后，动态访问策略根据组织的上下文

242、信息，如位置、设备和网络条件等，自动调整组织的权限。这种智能策略确保了数据的额外层级的安全性，以应对不同场景下的潜在威胁。综合而言，云存储身份认证与权限控制解决方案提供了多重保障，从多因素身份验证到灵活的权限管理和智能的动态访问策略，以确保数据的高级安全性和合规性，满足了现代云存储环境中不断增长的安全挑战。数据加密数据加密：云存储数据加密，是确保数据的绝对隐私和最高安全性的不可或缺的保障。通过采用相关技术，确保数据的保密性和安全性在各个环节得以充分保障。对于数据的存储，严格遵循国家加密标准算法，以保护敏感数据在云存储中的储存状态。即使是内部人员，也无法突破数据的加密壁垒，确保数据的完整性和机密

243、性。数据在传输过程中也需要加密处理，杜绝中间人攻击和数据窃听的可能性。密钥管理被视为至关重要的一环，通过一系列措施，确保密钥的安全性。通过访问控制采用强大的身份验证和权限管理，只有获得授权的组织和应用程序才有资格访问加密数据，进一步提高了数据的保密性。127 备份恢复备份恢复：数据备份和恢复是组织信息管理的核心组成部分。目标是确保数据的完整性、可用性和安全性，以便在面临数据损失、硬件故障、人为错误或安全威胁时能够迅速进行数据恢复。数据备份是数据保护的基石，定期复制关键数据，并将其存储在安全的位置。包括本地备份、异地备份或云备份，具体取决于组织的需求和风险管理策略。通过多种备份方式，包括精确的定

244、时备份、即时备份、全量备份和增量备份，为组织提供高度可配置的备份灵活性，满足各种备份需求。此外，本地备份数据自动同步到异地备份服务器，增强数据的容灾和可用性，为确保备份的连续性备份系统提供强大的冗余和容错机制，有效防范单点故障对数据安全的影响。数据恢复是备份解决方案的关键组成部分。当发生数据丢失或损坏的情况时，组织需要能够快速、可靠地恢复其数据。组织在关键数据丢失时迅速进行恢复操作，以最小化业务中断。同时支持从异地备份服务器快速恢复本地数据，有效应对本地数据误删除等意外情况。最后，组织应该具备自备份和自恢复的强大能力，为数据的持续可用性提供了坚实保障。通过自动化和监控功能，以确保备份过程的顺利

245、运行并能够及时检测到问题。帮助组织应对各种数据丢失场景。数据防泄漏数据防泄漏：随着数据规模的迅速增长和信息传输方式的多样化，数据泄漏已经成为组织所面临的一项严峻挑战。建立数据防泄漏策略显得尤为重要。首先，建立清晰而全面的敏感数据分类体系。明确识别组织内不同类型的数据，并明晰标记哪些数据 128 被认定为敏感、机密或受法律法规保护的。其次，数据监测和分析工具的部署是必不可少的。这些工具能够实时监控数据的流向和访问模式，识别不正常的行为，如未经授权的数据访问或大规模的数据传输，及时发出警报并采取措施，以降低潜在的泄漏风险。3 3云原生计算环境安全云原生计算环境安全 1 1）容器运行时安全）容器运行

246、时安全 （1 1）安全风险安全风险 一方面随着容器技术的快速发展和广泛应用，越来越多的企业将业务迁移到容器环境中运行。容器的灵活性和可移植性使其成为承载业务的理想载体。然而，容器运行时的安全问题也随之而来，成为企业急需解决的重要问题。另一方面容器在运行时主要会遇到容器逃逸、恶意容器运行、不安全的镜像、不安全配置以及恶意攻击行为等安全风险：容器逃逸：容器逃逸：攻击者可能利用容器运行时的漏洞，从容器中逃逸到宿主机或其他容器中。一旦攻击者获得了宿主机的权限，就可以对整个系统进行控制，获取敏感信息或发起其他攻击。恶意容器：恶意容器：恶意用户可能创建包含恶意代码的容器，通过容器运行时的弱点来攻击其他容器

247、或宿主机。这些恶意容器可能会执行恶意程序、窃取数据或进行拒绝服务攻击等；不安全镜像：不安全镜像：使用不安全的镜像可能导致容器运行时存在漏洞或配置错误。攻击者可以通过恶意镜像来获取容器的权限，进而控制容器或宿主机。不安全配置：不安全配置：容器运行时的配置错误可能导致安全漏洞，例 129 如权限不当、网络配置不当等。攻击者可以利用这些配置错误来获取容器的权限或进行其他攻击。恶意攻击行为：恶意攻击行为：容器环境相比于传统架构环境，一方面传统的攻击手段依然奏效，包括：漏洞利用、暴力破解、远程命令执行、Webshell、拒绝服务、SQL 注入等等，同时也会面临新的攻击手段，例如：镜像投毒、集群 API

248、调用、基础组件漏洞攻击等等；网络安全风险：网络安全风险：容器环境下微服务之间的调用关系复杂，东西向网络流量增大、容器间的网络隔离控制较弱、应用层防护能力缺失、流量封装 IP 快速变化造成的流量可视化不足，某个容器一旦失陷，就会被作为跳板攻击容器网络中其他可访达资产，整个网络中的资产会面临巨大的风险。综上所述容器运行时的安全问题涉及多个方面。因此，需要采取综合的体系化方式构建自适应的防护体系来确保容器安全稳定运行。（2 2）建设思路建设思路 资产管理资产管理：在传统架构转型云原生过程中，对资产进行清晰可视、易于查询和实时同步是非常重要的。这是因为在容器化环境中，资产数量可能会大幅增加，包括容器、

249、镜像、主机等。如果这些资产的信息不清晰可视，难以查询和实时同步，那么在发生安全事件时，排查问题将变得非常困难和耗时。全面及时的资产数据支持可以帮助安全运维人员缩短排查问题的时间周期，快速定位问题容器，并减少安全事件带来的损失。当发生安全事件时，可以通过资产数据了解到容器的状态、130 配置和网络连接等信息，从而更快地定位问题所在，并采取相应的措施进行应对。此外，资产信息与补丁、入侵检测等安全功能的协同联动也是非常重要的。通过将资产信息与补丁管理系统、入侵检测系统等进行联动，可以实现对容器的全面监控和管理。当发现容器存在安全漏洞或异常行为时，可以及时采取措施进行修复或隔离，从而确保容器环境的安全

250、性。因此，在云原生建设中，需对容器运行时的资产进行全面的管理，建立统一的资产台账，及时掌握容器资产变化，为安全管理提供最新的资产数据支持，消除容器环境下的资产盲点，让安全跟上业务发展 配置合规配置合规：容器常常大批量部署在非常动态的环境中，访问、网络及其他设置一旦出现错误配置，就会给网络犯罪分子留下可乘之机。另外，很多运维人员在配置容器时，通常会选择默认配置设置，不能充分利用更精细化的配置功能，配置错误或采用安全性远不如自定义设置的默认配置方案，都可能造成安全问题。配置错误的问题不仅局限于容器本身，容器编排引擎工具的配置错误也需关注。因此云原生环境应该支持对所有资产组件进行安全配置扫描，并对各

251、类资产的配置进行正确性和合规性检查。这可以帮助降低被攻陷的可能性，同时确保满足行业及国家合规要求。安全配置扫描可以检查容器、集群、运行时组件的配置是否符合安全最佳实践和合规要求。例如，发现容器没有启用安全隔离措施、容器以 root 权限运行、容器以特权模式运行、是否有 131 设置镜像使用规则等。一旦发现配置不满足合规基线的情况，应该立即采取相应的措施进行整改。例如，及时更新容器的安全配置，优化镜像使用策略，调整访问控制策略等。通过持续的安全配置扫描和合规性检查，可以确保云原生环境中的资产配置始终符合最佳实践和合规要求，提高整个环境的安全性和合规性水平。风险发现风险发现：在云原生架构下，传统的

252、安全漏洞风险仍然存在，例如：漏洞、补丁、弱口令等相关的安全风险，这些风险可能会对业务组件、运行容器、集群编排组件和运行时组件等产生影响。因此，云原生平台应该具备安全风险检测的能力，定期对这些组件进行安全风险检查。漏洞检测可以基于漏洞信息库如 CNNVD、CVE 等进行，也可以使用 POC 脚本进行检测。通过检测，可以发现存在的漏洞组件风险，并及时进行整改，以避免集群控制层被渗透和控制。弱口令检测应支持对环境内的容器应用进行弱密码扫描的能力，如ssh、weblogic、tomcat 等应用，弱口令检测字典库应具备常见弱口令以及结合企业自身特性的生成的弱口令。对于发现的安全风险应该建立相应的闭环流

253、程，确保问题得到及时解决。这包括及时修复漏洞、更新组件版本或配置，以减少安全风险。对于一些紧急漏洞，还应该提供临时的防护措施，以保护系统在修复之前不受攻击者利用。通过具备安全风险检测能力，云原生平台可以及时发现和解决安全漏洞问题，保障业务的正常运行和集群平台的安全性。同时，定期的漏洞检测也可以帮助企业及时了解系统的安全状况，132 并采取相应的措施进行风险管理和应对。入侵防范入侵防范：容器运行过程中，入侵者会采用多样化的入侵手段对容器侧进行攻击，包括病毒和恶意程序攻击、容器内部的入侵行为、容器逃逸和高风险操作等恶意攻击风险行为。其中，容器逃逸最为严重，他会直接影响到承载容器的底层基础设施和集群

254、内所有容器的安全稳定。诸如危险配置、挂载、程序漏洞、内核漏洞等行为均有可能造成容器逃逸。因此云原生平台的入侵防范应基于云原生的安全技术实践，深度感知容器内外部各类事件，利用容器的不变性和单一性，通过行为基线、流量对异常行为进行检测，多维度数据关联分析，对入侵威胁进行持续监控发现，自动感知失陷容器并做出响应，可全面覆盖各类已知和未知威胁场景。网络隔离：网络隔离：感知并可视化展示容器环境下的网络流量，提升网络流量的可观测性，掌握和梳理微服务之间的网络访问关系并按需控制东西向、南北向网络流量，并能够有效监管网络微隔离策略的实施效果，给予运维人员及时反馈调整，实现网络安全的可知可见与可控。感知容器环境

255、中的网络流量，并将其可视化展示出来。这可以帮助运维人员全面了解网络流量的情况，包括流量的来源、目的地、协议等信息。通过分析容器环境中微服务之间的网络通信，可以梳理出微服务之间的网络访问关系。这可以帮助运维人员了解微服务之间的依赖关系，并进行相应的网络流量控制。根据微服务之间的网络访问关系，可以按需控制东西 133 向（容器内部）和南北向（容器与外部网络）的网络流量。这可以通过网络插件或网络策略来实现，例如使用网络隔离技术、访问控制列表等。通过监控网络流量和访问控制的实施效果，可以评估网络微隔离策略的有效性。如果发现异常的网络流量或违规的访问行为，可以及时调整网络策略，并给予运维人员即时反馈。通

256、过感知网络流量、梳理微服务之间的网络访问关系、按需控制网络流量，并监管网络微隔离策略的实施效果，可以实现网络安全的可知、可见和可控。运维人员可以及时发现网络安全问题，并采取相应的措施进行风险管理和应对。容器行为监控分析：容器行为监控分析：基于事件驱动机制，可以采集容器内部的网络、文件、进程和系统调用等多维度数据，对容器运行时进行实时、深度、全面地感知。通过对这些数据进行分析和检测，可以发现入侵攻击行为并进行检测及告警，包括但不限于以下常见的入侵攻击行为：一是无文件攻击：通过监控容器内部的进程和系统调用，可以检测到无文件攻击，即攻击者在容器内部执行恶意代码而不留下文件痕迹的攻击行为；二是恶意文件

257、：通过监控容器内部的文件访问和文件系统调用，可以检测到恶意文件的存在，例如包含恶意代码的文件、病毒文件等；三是 Webshell：通过监控容器内部的网络流量和文件访问，可以检测到Webshell的存在，即攻击者通过 Web 应用程序上传并执行恶意脚本的攻击行为；四是挖矿程序：通过监控容器内部的进程和系统资源使用情况，可以检测到挖矿程序的存在，即攻击者利用容器内部的计算资源进行加密货币挖矿的攻击行为；五是反弹 shell 和远程控 134 制：通过监控容器内部的网络流量和进程行为，可以检测到反弹shell 和远程控制的存在，即攻击者通过网络连接获取对容器的远程控制权限；六是 Web 命令执行：通

258、过监控容器内部的网络流量和应用程序行为，可以检测到 Web 命令执行的存在，即攻击者通过在 Web 应用程序中注入恶意命令并执行的攻击行为；七是容器逃逸：通过监控容器内部的系统调用和容器宿主机的资源使用情况，可以检测到容器逃逸的存在，即攻击者通过利用容器内部的漏洞或特权提升攻击技术逃离容器的攻击行为；八是 SQL 注入和 XSS：通过监控容器内部的网络流量和应用程序行为，可以检测到 SQL 注入和 XSS 的存在，即攻击者通过在 Web 应用程序中注入恶意 SQL 语句或脚本代码的攻击行为。通过对容器内部的网络、文件、进程和系统调用等多维度数据进行实时监控和分析，可以及时发现这些入侵攻击行为，

259、并进行相应的检测和告警。这可以帮助运维人员及时采取措施来应对入侵攻击，并保障容器环境的安全性。响应处置：响应处置：云原生平台应该具备应急响应处置能力，能够对安全事件进行全面地分析、溯源和处置，形成一个完整的闭环。当发生安全事件时，平台应该能够及时检测到事件的发生，并迅速采取相应的响应措施。平台应该具备强大的日志和监控功能，能够对平台中的各个组件进行实时监控，并记录下关键的事件和日志信息。一旦发现安全事件，平台应该能够对事件进行分析和溯源，确定事件的来源和影响范围。平台应该能够通过分析日志和监控数据，找出事件的根本原因，并追踪事件的传播路径和影响范围。135 在分析和溯源的基础上，平台应该能够快

260、速采取相应的处置措施，以减轻事件的影响和损失。平台应该能够自动化地执行处置策略，例如隔离受感染的容器、封锁攻击者的访问、修复漏洞等。在处置过程中，平台应该能够及时通知相关的人员和团队，以便他们能够参与到事件的处置工作中。平台应该提供一个集中的管理界面，用于跟踪和记录事件的处置过程，以便后续的审计和分析。最后，平台应该能够对安全事件进行彻底地分析和总结，以提高平台的安全性和应急响应能力。平台应该能够自动化地收集和分析事件的数据，形成安全事件的报告和分析结果，为后续的安全改进提供参考。安全有效性验证：安全有效性验证：随着云原生平台业务不断增加和变化，已发布和落实的安全策略可能会发生失效，由于安全策

261、略多且覆盖范围广，无法有效地对安全策略进行监控。如何检验这些安全防护有效性，在面临内外部攻击时是否有效，在日常运营过程需要重点关注。因此云原生平台需要具备安全策略有效性的验证能力，模拟可能由犯罪分子实施的网络攻击，通过内置的攻击脚本及攻击行为，对云原生平台安全防护策略开展持续性、有效性安全验证，保证各项策略的实时有效和持续有效，持续提升日常运营工作中的防护能力和实战能力，有效应对外部攻击威胁，保障云原生平台稳定运行。136 2 2）镜像安全）镜像安全 （1 1）安全风险安全风险 镜像规模大、梳理难、潜藏恶意代码及漏洞等给组织带来巨大的安全隐患，组织面临如下风险：一是资产数据不清晰不可视，关联信

262、息及风险无统一管理手段；二是不安全的配置导致容器逃逸或者集群入侵等事件；三是镜像漏洞、敏感信息、恶意样本、Webshell 检测等镜像安全事件；四是镜像在传输流转过程中信息泄漏或被恶意篡改等多种安全风险，组织应该加大对镜像安全的重视程度。（2 2）建设思路建设思路 资产管理资产管理：使用资产发现与管理工具，自动化识别本地、仓库、集群镜像资产及各类软件包资产并实时展示最新的资产数据包括但不限于镜像来源、镜像资产的更新时间等，除识别清点外，能汇总展示资产关联信息及资产风险关联详情等。配置合规配置合规：建立自动化的配置合规基线检测能力，基于单位基线检查项进行定期扫描，检测覆盖容器、镜像、主机等多个维

263、度，对业务系统所在容器、集群以及容器原镜像进行合规检测，以防止不安全的配置导致容器逃逸或者集群入侵等事件。建议具备：可设置镜像、镜像仓库检查的风险类型并自定义仅扫描检查单个或部分类型风险的能力、可自定义设置定时检查周期的能力等。风险发现风险发现：使用自动化的风险发现手段，在镜像构建、分发、137 运行各节点对镜像进行检测及安全告警，除对漏洞、敏感信息、恶意样本、Webshell 检测等镜像安全事件进行定期检测外，建议具备：对安全风险进行统计及标签化标注能力、对漏洞威胁进行排序并提出处置建议和自动加固的能力等。通信安全通信安全：通过建立基于 IP、角色的访问控制、权限控制，使用加密传输协议、数字

264、签名以及安全的传输工具等以防止镜像在传输流转过程中信息泄漏或被恶意篡改。安全有效性验证安全有效性验证：定期检查测试验证相关规则、工具以及配置是否在资产管理、配置合规、风险发现、通信安全等方面有效保证了镜像安全，除管理员维护、工具验证有效性等，也可通过模拟攻击进行自检。3 3）编排平台安全）编排平台安全 （1 1）安全风险安全风险 云原生编排平台是用于自动化部署、管理和编排容器化应用程序的工具或平台。他提供了一套功能强大的工具和技术，帮助开发人员和运维团队在云环境中更高效地创建、部署和扩展应用程序。他在提供灵活、弹性和可扩展的云服务部署和管理方面具有诸多优势，但也存在一些安全风险需要注意。以下是

265、一些常见的安全风险：访问控制问题：访问控制问题：云原生编排平台可能面临访问控制不当的风险，如弱密码、未正确配置权限和角色等。这可能导致未经授权的用户或恶意攻击者获取对系统的访问权限。虚拟化漏洞：虚拟化漏洞：云原生编排平台在底层使用虚拟化技术，虚拟化漏洞可能使攻击者能够逃逸出虚拟机隔离环境，访问其他虚拟 138 机上的数据或者对云基础设施进行攻击。不安全的映像管理：不安全的映像管理：云原生编排平台使用映像来创建和部署应用程序。如果映像来自不可信的来源或未经验证，可能会存在恶意软件、后门或其他安全漏洞。数据泄漏：数据泄漏：未正确配置云原生编排平台的存储和网络设置，可能导致敏感数据泄漏。这可能是由于

266、不正确的权限配置、缺乏数据加密或未加密通信等原因造成的。安全性审计不足：安全性审计不足：云原生编排平台可能缺乏全面的安全审计功能，如事件日志和审计日志等。这可能使得对安全事件的检测、响应和调查变得困难。（2 2）建设思路建设思路 资产管理：资产管理：使用专门的资产发现工具，他们可以扫描编排平台上的容器、虚拟机、服务等资源，并生成清单。一些工具还能提供关于每个资产的详细信息，如 IP 地址、标签、操作系统等。配置合规：配置合规：确保编排平台的默认配置是安全的，并根据最佳实践进行修改。制定和执行安全配置策略，以确保组件和服务的安全性。风险发现：风险发现：使用漏洞扫描工具定期漏洞扫描，检测编排平台中

267、的漏洞，并及时修复。确保及时应用操作系统和组件的安全补丁。资源隔离：资源隔离：使用网络策略或安全组规则来限制容器和服务之间的通信。并使用加密协议确保容器之间和外部服务之间的安全通信。入侵防范：入侵防范：启用详细的日志记录，记录编排平台的活动，以 139 便审计和调查。建立监控系统，监视平台的性能和安全事件，实时发现潜在的问题。响应处置：响应处置：制定应急响应计划，准备面对安全事件时的应急响应计划，包括隔离受感染的组件和恢复服务。建立数据备份和恢复策略，以防止数据丢失。安全有效性验证：安全有效性验证：测试不同场景下的安全规则，确保他们有效地限制了不正当访问。测试入侵监控体系的有效性，模拟潜在攻击

268、以查看系统是否能够检测到。4 4）云原生网络安全）云原生网络安全 （1 1）安全风险安全风险 传统的静态网络安全策略难以应对网络边界模糊、资产复杂多变、东西向流量增加、流量关系复杂的云原生环境，云原生对组织来说也具备一定的学习成本，组织若无行之有效的网络访问控制策略及入侵防护手段，将会面临如越权攻击、容器逃逸、横向扩散等风险影响业务正常开展甚至造成业务瘫痪。面对日渐增加的未知攻击，组织需要行之有效地分析未知威胁的能力。（2 2）建设思路建设思路 访问控制访问控制：建立有效的网络访问控制策略，通过正确的network policy 配置、微隔离策略等，除隔离业务容器和管理容器、控制集群资源访问权

269、限等，还应具备对集群内各类粒度资源之间的通信进行网络隔离控制的能力，基于业务场景的设置访问规则，及时阻断风险流量。入侵防护入侵防护：进行网络流量采集监测防护，可以利用安全大数据分析、机器学习、人工智能等能力分析未知的攻击。防护能力 140 可以基于自动行为学习形成自定义的模型，当发现的模型外事件将自动识别为异常事件进行上报告警并可添加进入模型。响应处置响应处置：建立容器告警响应处置平台，进行容器级别流量阻断、对容器进行暂停、移除等响应操作等，及时阻断威胁扩散、应急处理入侵风险事件，具备可视化的资产及网络访问视图，清晰展示网络访问关系及流量数据。安全有效性验证安全有效性验证：定期检查测试验证相关

270、规则、工具以及配置是否在访问控制、入侵防护、响应处置等方面有效保证了云原生网络安全，除管理员维护、工具验证有效性等，也可通过模拟攻击进行自检。（五）云原生安全管理（五）云原生安全管理 云原生安全管理包含 4 个一级能力、18 个二级能力和 118 个三级能力，如图 32 所示。图 32 云原生安全管理范围 141 安全组织，为达成安全目标，应具备的组织体系，管理流程和职责分工，包含研发、运营、审计、评估等所有安全相关的工作场景以及各技术方向对人员的技能要求。安全合规，为满足监管合规要求，每个组织都应该评估哪些监管标准适用于他们，并决定他们将如何再根据实际情况实施这些标准。这种支持遵守特定标准的

271、证据收集机制应尽可能通过不可抵赖性保证自动化，并使得通过相关监管机构和审计人员能够快速获得相关数据。平台管理，用于描述管理平台所需要具备的各项管理功能，这些管理功能主要通过管理平台对接各项安全能力产品，获取所需管理信息，同时通过管理平台向各安全能力产品下达管理指令和管理策略等操作。策略管理，在云原生特点下从研发、发布和运营等阶段用来保障工程执行质量和安全管理效果的策略，包括研发工具集成、质量门控设置、平台所提供的安全能力配置和编排。（六）关键技术方案创新（六）关键技术方案创新 1 1概述概述 本课题组在研究云原生安全体系架构、安全原子能力和行业内云原生安全技术实践案例的过程中，提炼形成了 10

272、 项关键技术方案创新点，共涉及安全需求设计、安全开发、安全交付、安全管控、API 安全、微服务安全、容器运行时安全、镜像安全、网络安全和策略安全 10 个领域，如图 33 所示。142 图 33 关键技术方案创新领域概览 2 2创新点：应用人工智能大模型提升安全需求和安全测试创新点：应用人工智能大模型提升安全需求和安全测试效能效能 1 1）方案背景）方案背景 邮储银行建立了组织级的安全基线，但是安全基线中对于安全问题的描述是偏向于安全领域，在开发人员使用安全基线时，由于工程开发和信息安全领域存在专业壁垒，所以对于安全基线中描述的安全需求点理解存在困难。需要构建易于让开发人员理解的安全基线，借助

273、大模型生成安全需求点的正反示范代码便于开发人员理解安全基线。此外，借助大模型的安全编码能力对源代码安全审计报告初测结果进行过滤，筛出误报结果，提升安全测试效能。2 2）技术实现）技术实现 邮储银行将安全基线中的内容转化成为程序员能够理解的示例代码，便于开发人员进行使用。将安全基线中的安全需求点和安全设计要点归纳为编码需求，然后使用大模型的代码生成能力，生成不同语言版本的示例代码，包括正向的示例代码和负向 143 的示例代码，正向代码通过安全评估后融入编码规范。在实践过程中，邮储银行分析安全基线 142 条，并使用大模型生成正例代码示例和反向代码示例，总共生成示例 224 条，覆盖 24 个业务

274、场景安全需求。通过这些示例代码配合安全编码手册，开发人员能更容易理解安全需求中对于安全的设计要点，开展安全编码工作。通过给开发人员提供安全编码示例，可以让开发人员更好地理解安全基线，降低了开发人员和安全人员的沟通成本，通过实践有效降低了安全需求响应时间 15%，提升了安全支撑效能。源代码安全审计工具扫描后的源代码缺陷清单中标明了缺陷代码路径，获取源代码包（或代码仓库）中缺陷代码源文件，将缺陷代码段输入到大模型中进行安全漏洞审查，验证源代码缺陷是否为误报，为安全测试人员排除误报提供辅助支持，减少人工排除大量误报工作量。在邮储银行实践中，通过大模型对于缺陷进行自动识别，对于常见的误报通过自动化的方

275、式剔除，将误报率降低 12%，减少安全测试人员的重复劳动。3 3）创新方案）创新方案 邮储银行安全团队发现开发人员在使用安全基线的过程中，由于专业不同导致理解产生偏差，开发人员对于文字描述接受度不高，而更倾向于理解示例代码，通过大模型辅助将文字描述的安全基线转换成为示例代码，并将示例代码作为安全基线的补充内容，当开发人员对于安全基线的内容存在不理解时，可以通过阅读示例代码理解安全基线内容。通过将传统代码安全扫描工具整合人工智能大模型接口，对源代码安全审计结果进行检测，就会减少大量误报，从而提升代码安全审计的效率。144 4 4）总结）总结 邮储银行使用大模型基于安全基线生成开发人员易于理解的示

276、范代码，打通了安全领域和项目建设领域的壁垒。降低了因为专业领域不同，导致在沟通中信息传递的损失，让开发人员更清晰明了地理解对安全基线的内容。相较传统的白盒代码审计工具，借助 AI 通用大模型进行代码安全审计能够减少误报，提高分析的准确率，从而节省安全人工成本。3 3创新点：基于创新点：基于 eBPFeBPF 内核技术的镜像威胁动态分析内核技术的镜像威胁动态分析 1 1）方案背景）方案背景 随着金融行业日益数字化和云原生化的发展，安全威胁也变得更加复杂和具有挑战性。传统的金融机构需要采取先进的安全措施来保护其关键数据和资产。云原生安全是一种现代化的安全方法，旨在满足云环境中不断演变的威胁。镜像作

277、为云原生的基石，如果风险无法控制，则极容易导致供应链安全。然而在传统的镜像风险扫描中，更多地关注漏洞等静态风险，却忽视了镜像本身蕴含的动态威胁。在这个背景下，提出 eBPF 技术加持的动态沙箱作为威胁检测手段，弥补传统模式下镜像扫描的缺位。145 2 2）技术实现）技术实现 图 34 基于 eBPF 内核技术的镜像威胁动态分析 基于 eBPF（Extended Berkeley Packet Filter）进行系统调用插桩来监控容器镜像的运行状态，以及使用 containerd来管理容器的运行，是一个强大的技术实施方案，如图 34 所示。以下是具体的步骤和技术实施手段：准备环境：一是准备环境：

278、一是安装和配置 eBPF 运行时环境：确保主机上已经安装了 eBPF 运行时环境，以支持 eBPF 程序的加载和运行。二是安装 containerd：使用容器运行时管理器 containerd，他可以与 eBPF 集成以监控容器的运行。开发开发 eBPFeBPF 程序：程序：一是编写 eBPF 程序：开发 eBPF 程序，用于插桩容器镜像的系统调用。这个程序将监控容器中的系统调用，捕获关键事件和参数，以便进一步分析。二是集成 eBPF 程序和containerd：将编写的 eBPF 程序集成到 containerd，以便在容器运行时加载和运行该程序。这可以通过 containerd 的扩展机

279、146 制实现。容器镜像的运行和监控：容器镜像的运行和监控：一是部署容器镜像：当新的容器镜像需要运行时，使用 containerd 将其部署到容器运行时环境中。containerd 会加载 eBPF 程序以监控该容器的系统调用。二是异常行为检测：eBPF 程序可以实时监控容器中的系统调用，并分析他们是否符合正常行为。如果发现异常，程序可以触发警报，或者采取自动化响应措施，如停止容器。事件日志和分析：事件日志和分析：一是记录事件：eBPF 程序可以将关键事件和参数记录到事件日志中，以便后续的分析和审查。二是分析异常行为：使用事件日志和分析工具，如 eBPF 提供的工具或外部工具，来分析容器镜像的

280、异常行为，识别潜在的威胁和漏洞利用尝试。3 3）创新方案）创新方案 在以下多个维度，该创新方案都可以很好地发挥作用：CI/CD 流水线中的安全检测：金融机构可以在 CI/CD 流水线中集成动态沙箱的镜像威胁检测，确保在将镜像部署到生产环境之前，检测到并解决潜在的安全问题。第三方镜像审查：金融机构通常依赖于第三方提供的容器镜像，用于其云原生应用程序。动态沙箱可以用于审查这些第三方镜像，确保他们不包含潜在的威胁。高度敏感数据的保护：对于金融机构来说，某些应用程序可能处理高度敏感的金融数据。在这些情况下，动态沙箱的镜像威胁检测尤其重要，以确保数据的安全性和合规性。147 安全治理和合规性：金融行业面

281、临严格的合规性要求，如PCI DSS 和 GDPR，以及等级保护。动态沙箱可以帮助金融机构符合这些合规性要求，并提供安全治理的可见性。4 4）总结）总结 基于动态沙箱的镜像威胁分析的云原生安全解决方案，以自动化审计、实时动态沙箱技术为核心，应对云原生环境中的安全挑战。这一方案为企业提供了强大的安全基础，降低了风险，提高了威胁响应效率，确保了合规性，为数字化转型和业务增长提供了支持。4 4创新点：基于创新点：基于 Kubernetes Api Server Kubernetes Api Server 的细粒度准入的细粒度准入控制控制 1 1）方案背景）方案背景 云原生计算架构的兴起已经带来了巨大

282、的效率和敏捷性，但也带来了新的安全挑战。在一个典型的云原生环境中，数百甚至数千个容器和微服务以高度动态的方式创建、销毁和相互通信。这种复杂性和动态性使得安全事件的闭环响应成为一项重要挑战。为了应对云原生环境中的闭环安全事件挑战，提出基于 Kubernetes 准入控制方案，旨在缩减风险，同时完成云安全事件的完整闭环，如图 35 所示。148 2 2）技）技术实现术实现 图 35 基于 Kubernetes Api Server 的细粒度准入控制 策略定义：一是策略定义：一是使用 Kubernetes 的 Custom Resource Definitions（CRDs）来定义安全策略，这些 C

283、RDs 包含了对 Admission Controller 的自定义配置。二是策略可以定义容器镜像来源限制、特权容器权限、目录挂载权限、认证规则等。Admission Controller Admission Controller 扩展：扩展：一是编写自定义 Admission Controller 扩展，以监控 Kubernetes API Server 接收到的准入控制请求。二是 Admission Controller 扩展会在请求进入 Kubernetes 集群之前拦截请求，并与安全策略进行匹配。安全策略评估：安全策略评估：一是在 Admission Controller 扩展中，执行

284、安全策略的评估，检查请求是否符合定义的策略。二是如果请求符合策略，允许请求通过；如果不符合，拒绝请求，并记录审计事件。审 计 和 日 志 记 录：审 计 和 日 志 记 录：一 是 审 计 记 录 将 由 Admission Controller 扩展生成，并包括有关请求的详细信息，例如请求 149 源、目标和执行的策略。二是使用日志聚合工具将审计事件发送到中央日志系统，以供进一步分析和报警。自动化响应：一是自动化响应：一是基于审计事件的结果，可以在 Admission Controller 扩展中实施自动响应措施。二是响应措施可以包括拒绝容器创建请求、隔离容器、封锁网络访问等，具体根据安全策

285、略的定义执行。持续改进和合规性：持续改进和合规性：一是定期审查和更新安全策略，以适应不断变化的威胁和合规性要求。二是利用审计事件的分析结果来改进策略和响应措施，以不断提高云原生安全性。三是其中Admission Controller 扮演着关键的角色，确保容器和微服务在进入 Kubernetes 集群之前受到严格的安全策略的控制和审查。这个核心组件是云原生安全解决方案的关键部分，有助于确保整个云原生环境的安全性和合规性。3 3）创新方案）创新方案 基于 Kubernetes 准入控制的云原生安全解决方案，旨在帮助企业构建高度安全、可管理和可扩展的云原生环境。这个方案的核心思想是将安全性融入云原

286、生计算的 DNA 中，通过自动化、实时审计和可扩展性来保护应用程序、数据和基础设施。创新亮点如下：创新亮点如下：自动化安全：自动化安全：利用 Kubernetes 的准入控制机制，实现了对容器和微服务的自动安全审计和响应。这使得安全策略可以无缝集成到应用程序的生命周期中，降低了人工干预和错误的风险。150 实时审计：实时审计：解决方案生成详细的审计事件，包括所有与容器和微服务创建、配置变更和访问有关的信息。这为安全团队提供了实时的威胁检测和事件响应能力。可扩展性：可扩展性：可轻松扩展到不同的云提供商和大规模的容器集群。无论企业的规模如何增长，安全性和合规性都能得到维护。合规性：合规性：将合规性

287、规则内置到安全策略中，确保容器和微服务的操作符合行业标准和法规。这有助于企业满足监管和审计要求。价值和成果：价值和成果：这个创新方案将帮助企业在云原生环境中实现高水平的安全性和合规性。通过自动化和实时审计，企业能够降低安全风险、减少人工操作成本，并保护其云原生应用程序免受威胁。这个方案还有助于构建强大的安全基础，使企业能够自信地推进其云原生计算战略，应对不断演变的威胁和挑战。4 4）总结）总结 基于 Kubernetes 准入控制的云原生安全解决方案，以自动化审计、实时威胁检测和合规性监控为核心，应对云原生环境中的安全挑战。这一方案为企业提供了强大的安全基础，降低了风险，提高了威胁响应效率，确

288、保了合规性，为数字化转型和业务增长提供了支持。5 5创新点：服务网格安全治理创新点：服务网格安全治理 1 1）方案背景）方案背景 云原生环境中，微服务通常以容器或 Pod 的形式出现，这些微服务在容器编排平台，例如Kubernetes或OpenShift中运行，或者运行在服务网格（Service Mesh）中，此外，云原生应用场 151 景下的流量不仅包含传统基于边界的南北向流量，还包含集群节点间，微服务间访问的东西向流量，若攻击者通过漏洞利用攻入集群内部，进而可能通过利用脆弱的认证机制横向移动入侵至其他微服务导致集群整体的瘫痪。采用服务网格的边车设计思想可较好地治理微服务东西向防护难题。2

289、2）技术实现）技术实现 （1）安全能力容器化，通过引流将业务流量牵引至安全容器，引流可采用主流 iptables 或 eBPF 技术；（2）复用服务网格自身提供的扩展能力，如 Envoy 的扩展能力，实现将安全能力集成至现有的 Sidecar 容器，主要包括以下三种实现方式，见表 2。表 2 Envoy 的扩展方式比较 （3）安全能力 Sidecar 化，将其作为边车注入至现有集群云原生 API 关中，从而实现流量截获及检测防护。152 3 3）创新方案）创新方案 图 36 服务网格安全治理 适配于 Service Mesh 的微 API 安全网关方案，如图 36 的左图所示，安全能力采用轻量

290、级的方式，无感知地接入每个微服务应用中，根据集群具体业务不同，可采用不同的 API 安全模块进行精准防护。此方案与 Service Mesh 配合使用，能够快速将微API 安全网关注入至每个微服务应用中，同时对集群中的每个微API 安全网关运行数据进行管理面上统一分析，并通过安全编排层进行服务策略编排，实现基于微服务粒度的全向安全防护能力。适配于 Kubernetes 的节点 API 安全网关方案，如图 36 的右图所示，该方案采用 eBPF 技术将集群微服务引流从用户空间offload 至内核层实现，降低系统 CPU 消耗的同时，提升了处理性能，也同时支持全向流量安全防护及灵活的策略编排。4

291、 4）总结）总结 Gartner 早在 2020 年 1 月提出了 CNAPP（Cloud Native Application Protection Platform 云原生应用防护平台）的术语，其集合了 CWPP 和 CSPM 的功能，重点强调了云应用安全防护的重要性，以上所述方案可有效针对微服务进行应用层面防护，是企业构建 CNAPP 过程的必经阶段，也是未来构建云原生应用安全（微服务安全、服务网格安全、FaaS 安全）必不可少的一环。153 方案通过安全容器的多种部署模式解决了云原生不同场景下遇到的东西向流量难以解决的问题。6 6创新点：创新点：APIAPI 安全智能分析安全智能分析

292、1 1）方案背景）方案背景 API 在业务中的应用异常广泛且灵活。不同的 API 调用顺序和条件组合可以满足不同的业务需求。但这也导致了针对 API 的攻击方式的变化，从传统的通用型攻击转变为基于业务逻辑的漏洞攻击。在这种情况下，由于攻击行为与业务逻辑紧密相关，常规的检测方法往往无法及时发现攻击特征。因此，采用 UEBA（用户和实体行为分析）的行为建模来识别异常行为是一种可行的方法。2 2）技术实现）技术实现 技术上支持实时监控高危 API 接口、涉及敏感信息的 API 流转、涉敏应用以及缺少认证或访问异常的情况。同时，可以使用威胁建模来定义异常时段的 API 访问检测、异常访问次数的 API

293、检测以及基线外 IP 对 API 的访问检测。3 3）创新方案）创新方案 图 37 API 安全智能分析四象限 154 方案主要针对 API 端点和客户端进行建模，以便识别 API 异常行为，如图 37 所示。异常行为主要分为两种类型：API 端点异常和 API 客户端异常。对于 API 端点异常，需要快速采取措施进行根治。而对于客户端异常，可以采取封堵和观察等方式进行处理。通过对各种类型的接口请求和响应数据进行基线分析，可以发现接口设计中的安全漏洞，找出可能导致敏感数据泄漏和账号风险的接口。例如，通过学习客户端账号的行为基线可以发现普通账号和特权账号在行为时间、访问 API 和传输数据等方面

294、的差异。这样，当普通账号越权访问特权账号时，可以及时发现异常行为，并引入人工研判，确认异常的严重程度和优先级。4 4）总结）总结 API 安全智能分析是通过监控和分析 API 端点和客户端的请求和响应数据，识别异常行为的一种技术实现方式。通过监控、基线分析等手段，可以实现对异常行为的检测和识别。方案包能够提高异常行为分析的准确性和效率。7 7创新点：云原生可观测性助力安全可观测创新点：云原生可观测性助力安全可观测 1 1）方案背景）方案背景 云原生可观测性是指在云原生架构中，通过使用适当的工具和技术，实现对应用程序和基础设施的全面监控和可视化，以便及时发现和解决潜在的问题，并提供对系统性能和运

295、行状况的深入了解。帮助运维人员和开发人员快速定位和解决问题。云原生可观测性与云原生安全结合可以帮助提高系统的安全性和可靠性。155 监控安全事件：通过集成安全监控工具和技术，可以实时监控系统中的安全事件和威胁。将安全事件与可观测性数据结合，可以更好地了解系统中的安全漏洞和异常行为。日志分析和审计：将安全日志和审计日志与可观测性数据进行关联和分析，可以帮助发现潜在的安全威胁和异常行为。通过实时监控和分析日志数据，可以快速检测到安全事件，并采取相应的措施进行响应和修复。指标监控和警报：通过设置安全相关的指标监控和警报，可以实时监测系统的安全状况。例如，监控网络流量、用户访问权限、异常登录等指标，并

296、设置相应的警报规则，及时发现并应对潜在的安全威胁。安全追踪和溯源：结合追踪技术和可观测性数据，可以实现对安全事件的追踪和溯源。通过记录和分析系统中的操作和事件流，可以追溯安全事件的来源和影响范围，有助于进行事后分析和修复。自动化响应和修复：结合可观测性数据和自动化工具，可以实现对安全事件的自动化响应和修复。通过设置自动化规则和脚本，可以快速响应安全事件，并采取相应的措施进行修复和恢复。2 2）技术实现）技术实现 Opentelemetry 和 eBPF 是两种赋能云原生可观测性的技术。Opentelemetry 是一个开源的观测性框架，用于收集、传输和分析应用程序的跟踪、指标和日志数据。他提供

297、了一套标准化的 API 和 SDK，可以在应用程序中集成，以便在分布式系统中跟踪请求流和收集性能指标。Opentelemetry 支持多种编程语言和 156 多个云服务提供商，使得在云原生环境中实现可观测性变得更加简单和统一。eBPF（extended Berkeley Packet Filter）是一个内核级别的技术，可以在运行时对内核进行动态的、低开销的代码注入和修改。他可以用于在内核中实现高性能的可观测性功能，例如网络流量分析、系统调用跟踪和安全审计等。eBPF 可以在云原生环境中提供更深入的可观测性，通过在内核中收集和处理数据，可以实现更高效和精确地监控和分析。结合 Opentelem

298、etry 和 eBPF 可以实现更全面和深入的云原生可观测性。Opentelemetry 可以在应用程序层面收集和传输跟踪和指标数据，而 eBPF 可以在内核层面收集和处理更底层的数据，例如网络数据包和系统调用。通过将两者结合使用，可以实现从应用程序到底层基础设施的端到端可观测性，提供更全面的性能和安全监控。3 3）创新方案）创新方案 图 38 云原生可观测性架构 如图 38 所示，方案架构设计分为三部分内容：157 一是数据采集：数据采集分为应用层面和内核层面采集两部分，其中应用层面采用 Opentelemetry 或 Opentracing 标准提供的 SDK 实现，内核层面采用 eBPF

299、 的 Kprobe 探针对系统调用进行截取并分析，以上数据通过聚合后上传至云原生安全平台后端服务，如日志审计、监控指标、追踪服务等。二是数据关联：云原生安全平台收集后端服务收集的数据并与安全事件进行关联。三是大数据分析：通过 AI 引擎对关联数据进行分析，监控，安全事件追踪溯源、自动化响应和修复等操作。4 4）总结）总结 Opentelemetry 和 eBPF 可与云原生可观测性技术和工具配合使用，例如日志管理工具、指标监控工具和分布式追踪工具等。通过整合不同的技术和工具，可以构建一个完整的云原生可观测性解决方案，以满足不同的监控分析和安全需求。8 8创新点：基于零信任的细粒度访问控制创新点

300、：基于零信任的细粒度访问控制 1 1）方案背景）方案背景 随着云原生应用的快速发展，网络攻击也变得越来越复杂和普遍。传统的边界防御已经无法满足云原生环境中各种攻击的需求。此外，云原生环境中的服务和实例可以动态地启动、停止和迁移。这种动态性使得传统的固定边界安全策略无法适应。零信任安全策略能够提供更灵活、细粒度和动态的安全保护，以适应云原生环境中的挑战和需求。158 2 2）技术实现）技术实现 Istio 的 RBAC 策略主要用于定义服务之间的访问控制规则，可以基于源 IP 地址、用户标识、请求方法等进行授权决策。OPA是一个通用的策略引擎，可以用于定义和执行各种策略，包括访问控制、数据验证、

301、合规性等。OPA 使用 Rego 语言来定义策略，并提供了更灵活和可扩展的策略编写能力。结合使用 Istio 的 RBAC 策略和 OPA，可以实现更复杂和细粒度的访问控制。一种常见的做法是，使用 Istio 的 RBAC 策略来处理基本的访问控制需求，而使用 OPA 来处理更高级的策略和条件。例如，可以使用 Istio 的 RBAC 策略来控制哪些服务可以相互通信，而使用 OPA 来定义更复杂的访问控制规则，如基于请求内容、用户属性等进行授权决策。3 3）创新方案）创新方案 图 39 基于零信任的细粒度访问控制方案 如图 39 所示，方案分为控制平面和数据平面两部分：一是控制平面：用于管理访

302、问控制策略，完成策略的动态下发，可针对微服务粒度静态访问控制，如进行基于资源（Pod、159 Service、Damonset 等）的访问（get、put、delete 等）控制，再通过下发 OPA 策略完成更细粒度的访问控制，如 Pod A 访问Pod B 请求时，可针对请求协议、payload、请求体/返回体进行基于规则的访问控制，从而实现动态访问控制，动静结合实现全面的基于零信任的细粒度访问控制 二是数据平面：主要由 Istio 的数据平面组件 Envoy 及 OPA策略控制器 Gatewkeeper 组成，他们用于对控制面下发的策略进行执行操作。4 4）总结）总结 通过结合 OPA 和

303、 Istio，可以实现更灵活、动态和可扩展的访问控制策略。OPA 提供了更强大的策略定义和执行能力，而Istio 提供了流量管理和安全性等功能，二者结合使用可以实现更全面的服务治理和访问控制。9 9创新点：统一创新点：统一 AgentAgent 实现全局管控实现全局管控 1 1）方案背景）方案背景 在数字化的大趋势下，云计算、大数据、物联网、人工智能和移动互联网普遍使用，整体数字化环境越来越复杂，从系统层面涵盖了物理机、虚拟机、云主机、信创主机、容器等不同资产形态，从业务层面涵盖进程、端口、账号、中间件、数据库、开发框架、开源组件等不同的业务资产形态。以往只能通过手动表格录入，在如今复杂数字化

304、环境下上千台甚至上万台大规模资产管理，很难保证资产管理的时效性和准确性，亟需解决大规模并发场景下的自动化资产管理。160 2 2）创新方案）创新方案 提出了一种实现从物理机、虚机、私有云、混合云场景下的硬件、操作系统、中间件、数据库、软件应用以及软件组件和开发包的全方位深度的自动化资产管理设计，在大规模服务器集群的基础上研究高兼容性、高并发性的体系架构，解决传统资产管理需要手动录入以及表格更新不及时的问题，有效降低平均人力维护成本，提升资产管理效率。从以往基于人天级的资产管理效率提高到分钟级（单台扫描用时小于 1 分钟，多台并发扫描用时45 分钟）。3 3）技术实现）技术实现 统一 Agent

305、 实现安全防护是一种综合性的解决方案，他集成了多种安全措施和技术，以保护系统和网络免受各种安全威胁的侵害。这个 Agent 可以在各个层面上进行安全防护，包括主机、容器、应用、API 等。他可以监测和识别潜在的安全风险，并采取相应的措施来预防和应对安全事件。同时，他还可以提供实时的安全日志和报告，帮助管理员进行安全分析和决策。通过统一Agent 实现安全防护，可以提高云平台应用环境的整体安全性，减少安全漏洞和风险，保护用户的数据和隐私。4 4）总结）总结 通过构建细粒度的资产管理系统，实时追踪业务环境中的变化，并且与 CMDB 系统进行关联，补充数据缺失的部分，提高管理者的整体资产把控能力。该

306、系统可以追踪业务变化，包括业务服务器、线上业务程序、网络端口和关键文件的变化，快速变更资产覆盖范围，实现资产自适应。161 从安全角度出发，本成果重新定义了资产，结合通用安全检查规范和安全事件数据需求，构建了业务型资产对象，更加符合基于安全的实际需求。本成果还具备资产关联能力，为风险发现和入侵检测提供数据支撑平台。资产清点与风险发现和入侵检测系统全面关联，实现一键查看。用户还可以使用资产 API 系统将相关数据导入风险发现或入侵检测等其他系统，以获得更准确的信息。1010创新点：全流程供应链安全防护创新点：全流程供应链安全防护 1 1）方案背景）方案背景 在云原生环境中，打破了应用从开发阶段到

307、运行阶段的界线，引入了 CI/CD 的概念。CI/CD 是一种通过在应用开发阶段引入自动化来频繁向运行交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。他是作为一个面向开发和运营团队的解决方案，主要针对在集成新代码时所引发的问题（也称为：“集成地狱”）。CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。正是因为 CI/CD 的存在，使得云原生应用在开发、构建阶段存在的风险，会传递至运行时阶段，全流程供应链风险分析如图40 所示，比如：仓库中存储的自研镜像、第三方镜像均有可能包含漏洞或许可证风险；运行时阶段上传的第三方镜像未经严格

308、检测，有可能包含多种风险等。162 图 40 全流程供应链风险分析 2 2）技术实现）技术实现 如图 41 所示，平台通过在 CI、CD 两阶段使用扫描引擎对SBOM 进行检测，清点软件成分清单，区分安全镜像与风险镜像；通过对 SBOM 软件成分清点，快速定位开源代码引入源，从而定位对应开发人员；通过对云原生供应链资产运营，保证代码阶段、镜像阶段、运行时阶段的资产全覆盖；通过资产风险能力，开发流水线发现的漏洞可直接关联运行时容器，通过策略管理器将关联漏洞的容器进行隔离；通过资产风险关联能力，生产仓库镜像风险与运行时容器关联，通过策略管理器将关联漏洞的容器进行隔离；运行时阶段发现漏洞通过 CNA

309、PP 平台发送至制品安全，与代码、依赖、基础镜像进行关联，及时发现漏洞关联关系便于进行修复。IDECodeCI测试仓库生产仓库CD基础镜像仓库风险1：软件依赖包含漏洞风险2：基础镜像包含漏洞风险3：自研镜像包含漏洞风险4：自研、第三方镜像包含漏洞风险5：应用安全漏洞 163 图 41 全流程供应链安全防护方案 3 3）创新方案）创新方案 （1 1）供应链的完整性保障）供应链的完整性保障 SBOM 作为贯穿整个云原生应用生命周期管理的重要成分，平台通过对 SBOM 管理，实现基础镜像到制品镜像、制品镜像到基础镜像的双向风险追溯，构建可视化追踪链，确保供应链的完整性。具体实现方式如下：平台通过资产

310、管理获取到镜像、代码资产，通过开源扫描工具下发扫描任务；平台对接开源扫描工具，获取镜像的基础组成成分信息、漏洞信息及协议许可信息；平台根据任务资产 ID 将相关风险及成分关联到对应镜像资产，并构建资产指纹库，用户可通过镜像查询相关组成成分、漏洞及许可信息；平台对接镜像仓库，获取镜像及 RootFS 下引用镜像的 hash列表，通过基础镜像 hash 值在其他镜像所处层级，构建基础镜像、制品镜像关联图谱：IDEG i t开发环境CodeBuild Im age推送到仓库D evel oper基础镜像仓库测试环境测试仓库生产环境生产仓库阻断CI阶段准入CD阶段准出D ocker H U B自动化部

311、署Docker file检测Yam l配置检查阻断弱密码扫描漏洞扫描恶意文件扫描合规检测扫描引擎1扫描引擎2入侵检测集群组件扫描基线检测漏洞扫描软件协议SBOM阻断推送到仓库推送到仓库漏洞扫描软件协议SBOM弱密码扫描漏洞扫描恶意文件扫描合规检测容器安全代容器安全代码安全安全CNAPP平台代码安全及检测容器安全及检测基线安全及检测数据采集校对风险阻断下发风险隔离 164 场景一：当基础镜像存在漏洞时，通过对该基础镜像的引用检索，生成该基础镜像被引用到其他基础镜或制品镜像的关系链，快速确认风险影响范围；场景二：当制品镜像存在漏洞时，通过对该制品镜像的引用检索，生成该制品镜像所引用的基础镜像链，通

312、过更新开源扫描工具漏洞库，快速定位漏洞引入源。（2 2）供应链的可靠性保障）供应链的可靠性保障 传输通道加密：传输通道的安全设计主要是采取 https 加密的措施来防止数据泄露，接口提供用户鉴权。着重对各设备、部件的交接界面、输入输出端口等部位进行安全设计，以预防和杜绝泄露、毁坏事件的发生。数据访问控制：云原生安全运营中心对监测数据进行分级、分类，根据用户的身份和属性，数据资源的类别和属性进行授权管理，控制用户对服务和数据的访问，并记录全部操作日志以备审计和追溯。数据备份和恢复：针对系统中的关键参数、策略以及用户数据、资源数据、权限数据等提供数据冗余备份和恢复，系统从备份对象，备份方法、备份频

313、率和保存时限等方面按照数据重要程度、数据管理方式制定不同的冗余备份策略，同时对备份数据提供数据完成性校验以确保备份数据的完整性和可用性。数据完整性校验通过对比使用哈希算法和密钥对数据进行哈希运算获得的哈希值来实现。数据保护设计：为了确保关键数据不被窃取，主要密码算法加密方式来进行多层防护。采用对称加密的方法，隐藏加密算法 165 特征，使破解者无法用现存方式破解。加密强度采用了分割分组进行加密和多重多次加密的处理方式，在各个文件的加密以及解密过程中所用到的一些密钥，采取多种方式保证他们的安全性，如一些密钥不是固定字段，而是根据约定的格式和方法动态生成；一些密钥会拆分成多个分段，每个分段隐藏到不

314、同的文件，用的时候再通过特定的方式组合起来。隐私数据中除了采集的海量云平台数据之外，还包括大量引接的外部威胁情报数据、各种知识库，主要通过授权方式防止用户越界访问和滥用，避免带来不必要的法律风险和知识产权风险。4 4）总结）总结 通过对云原生环境资产进行全面梳理，建立统一的资产台账和全流程风险闭环安全管控能力，实现了云原生资产统一管理、应用风险源头快速排查与定位，有效提升了云原生安全运营效率。在网络安全攻防演练前期风险全面排查阶段，我单位利用流程化的云原生“三全能力机制”，及时发现多个存在安全隐患的应用系统，并快速定位涉及风险资产清单及相关负责人，通过平台推送风险整改流程，实现流程线上通知预警

315、、跟踪修复验证，极大提升了云原生架构下的风险处置和安全运营效率。1111创新点：云原生运行时安全策略自适应性创新点：云原生运行时安全策略自适应性 1 1）方案背景）方案背景 随着云原生技术的快速发展，越来越多的企业开始将应用程序和服务迁移到云上。然而，随之而来的是对云原生安全的关注。而在云原生安全平台的落地过程中，策略管理作为落地过程中面临的痛点之一，云原生安全策略的自动跟随成为一种创新的解决 166 方案，他可以在业务的上线/下线和业务弹性扩展时自动添加/删除安全策略，提升了云原生环境的安全性和业务弹性。在传统的云环境中，安全策略的管理通常是手动完成的。当应用程序上线或下线时，安全管理员需要

316、手动添加或删除相应的安全策略，来确保应用程序的安全性。然而，这种手动操作存在着一定的风险和延迟。安全管理员可能会因为繁忙或疏忽而忘记添加或删除某些安全策略，导致安全漏洞的存在。并且手动操作也会消耗人员大量的时间和精力。在云原生环境下使安全策略的自动生成和跟随解决了这些问题。2 2）技术实现）技术实现 云原生安全策略的自适应涉及范围以网络策略，运行时安全、安全基线为主，当应用程序上线时可以根据预定义的安全策略模板自动生成相应的安全策略，并将其应用到新上线的应用程序。同样当应用程序下线时，自动跟随系统会自动删除与该应用程序相关的安全策略。这种自动化的过程不仅提高了安全性，还减少了人为错误和延迟。除

317、了业务上线/下线时的安全策略自动跟随，云原生安全策略的自动生成也是一项重要的创新。在云原生环境中，应用程序的弹性扩容是一种常见的场景。当业务需要更多的资源来满足用户需求时，应用程序可以根据预定义的扩缩容策略，自动扩展以适应更高的负载。然而，这种弹性扩展也需要相应的安全策略来保护新增加的资源。面对云原生应用程序扩缩容的业务场景，安全策略的自动生成可以解决这个问题。当应用程序发生弹性扩展时，可以根据已 167 有的安全策略模板自动创建新的安全策略，并将其应用到新增加的资源上。这样，无论是应用程序的数量还是规模发生了变化，安全策略都能够自动适应，确保新增加的资源的安全性。3 3）创新方案）创新方案

318、基于云原生领域中“不可变基础设施”的理念实践，每个容器只运行特定软件，其行为模式是可以预期的，这为容器的策略自动生成提供了理论依据。通过对容器内的行为进行学习，持续建立自适应安全基线和策略模型。当监测到行为模型外的进程、文件访问、异常网络连接和系统调用时，会通过关联分析风险事件列表，进行告警处置。通过自适应安全策略，可以有效提升异常事件检出率，也可用于防御 0day 风险。云原生运行时安全策略自适应性方案如图 42 所示。图 422 云原生运行时安全策略自适应性方案 基于零信任的微隔离思想和技术路线，实现持续信任评估，动态访问控制，对容器集群内的网络流量进行持续信任评估，并且实现动态的自适应访

319、问控制，自适应微隔离实现集群内的东西向业务调用、东西/南北向的网络攻击进行风险预测和防护，并且以“不可变基础设施的理念”实现全自动地构建和管理容器集群内东西向的微隔离安全策略。自适应容器微隔离用于阻止容器间东西向攻击，减小攻击面，168 全自动构建和管理容器层的 ACL 隔离安全策略。通过双向控制、访问可视化、访问过程溯源的功能，对基于容器、容器组和业务视角进行超细粒度的双向网络访问控制，能够对非法访问的轨迹监控并溯源整个行为访问的过程。在自适应微隔离策略中，包括4 个部分。首先是抓取流量，洞察各个业务容器的访问关系，提升可观测性。其次是根据正常访问的业务流量自动生成隔离策略。但在执行策略前，

320、为避免策略设置不当导致业务容器受影响，通过策略预演确保策略的可靠性，在预演期间，所有命中阻断策略的流量将会进行告警和学习，并交由人工确认。预演一段时间后，通过对策略的调整和优化，策略变得完整而健全。此时开启策略执行，便可以有效地拦截非法访问流量，增加网络安全。当根据应用的业务逻辑自动生成自适应的运行时策略、网络策略后，形成自适应策略模板，可将其应用于一组云原生应用，通过云原生安全平台对云原生应用对应的容器资源进行持续监控，当云原生化应用发生上线或下线时，自动对策略覆盖进行调整，以确保运行中的云原生应用始终受到云原生安全平台防护。4 4）总结）总结 未来随着云原生技术的进一步发展，云原生安全策略

321、的自动跟随将会变得更加智能和自适应。通过结合机器学习和人工智能等技术，可以根据实时的安全威胁情报和业务需求来自动调整安全策略，提供更加灵活和精确的安全保护。然而值得注意的是，策略自动跟随和自动生成的安全策略并不意味着完全放弃人工干预。安全人员仍需要监控和审查策略的自动跟随和自动生成的安全策略，以确保其符合实际需求和安全 169 要求。此外，定期的安全审计和漏洞扫描也是必不可少的，以确保云原生环境的持续安全性。云原生安全策略的自动跟随作为一种创新的策略管理的解决方案，在保障业务弹性的情况下通过自动化的方式有效地提高云原生环境中应用程序的安全性，降低人为错误和延迟带来的风险，人工干预和定期的安全审

322、计仍然作为必要环节，以确保云环境的持续安全性。未来，随着技术的进一步发展，云原生安全策略的自动跟随将会变得更加智能和自适应，提供更加灵活和精确的安全保护。三、应用案例（一）云原生研发运维安全（一）云原生研发运维安全 1 1邮储银行在邮储银行在 DevSecOpsDevSecOps 方面云原生安全成功实践和创新方面云原生安全成功实践和创新 1 1）方案背景）方案背景 邮储银行在采用敏捷方式进行项目开发的过程中面临着一系列挑战和痛点。首先是安全需求和开发工程师之间的同步问题。安全专家分析出的安全需求和开发工程师之间的信息传递和沟通问题存在跨部门沟通横向沟通障碍。这导致了安全需求不清晰、开发进度滞后

323、等一系列问题，影响了项目开发的效率、安全性和持续优化能力。其次，评估和量化安全状况往往难以准确评估，并无法对安全控制措施的有效性进行量化分析。第三个挑战是安全检测往往依赖于人工操作，效率低下且易出错。往往无法全面覆盖安全漏洞和风险，导致潜在的安全威胁无法被及时发现。最后，传统的安全管理方法往往难以与敏捷开发流程有效结合，导致安全风险的漏洞。170 2 2）方案实现）方案实现 邮储银行通过在云原生安全架构上实施 DevSecOps 安全体系，成功地形成了高效、安全和持续优化的解决方案。首先，邮储银行采用了自研研发安全管理平台并与 Jira 系统相结合。这一创新点实现了操作风险管理系统中安全需求、

324、测试计划、测试用例和安全缺陷的全流程跟踪，实现了需求和开发的同步，确保了安全需求和开发工程师之间的同步。在操作风险管理系统的实践过程中，通过打通需求分析与安全建模的壁垒，从项目开始时的每个迭代中的 9 个安全需求增加到后期每个迭代中可以吞吐47 个安全需求，有效提升了安全工作的效能；其次，邮储银行建立了安全度量体系，通过可视化度量数值，能够精确地识别研发安全过程中的不足，并采取有针对性地优化措施，推动操作风险管理系统的软件安全成熟度提升。通过建立度量指标，使得安全改进可以以量化的方式得到体现，以便进行专项的能力提升，在操作风险管理系统的实践中，项目中严重安全缺陷修复平均时间，从最初的 3.2

325、小时/个缩减到平均 1 小时/个；第三，通过在云原生的 DevOps 平台集成了多个安全检测工具，通过自动化触发安全检测，并通过配置质量门禁来确保软件安全质量，有效保障了项目的安全性。通过在流水线上集成安全工具，确保制品可以保证在 100%符合安全门限要求，有效阻止带有安全漏洞的制品产生。最后，邮储银行将安全工作左移，安全内建于开发和交付过程中。通过标准对标和持续改进，从需求源头控制安全合规风险，保证敏捷项目快速交付的安全质量要求。在全行范围内，通过安全左移的安全管理实践实现 4400 余个安全漏洞在投产上线前的 171 修复整改工作，大幅降低安全漏洞修复成本。通过实施 devOps 和云原生

326、安全的结合，邮储银行大幅降低安全漏洞修复成本。在全行 70 个系统的投产变更安全管控，共计完成 267 个行内工程项目的安全评审工作，1000 余次投产变更安全管控，安全需求效率提升 40%，安全测试效率提升 20%，大幅提升安全开发管控效能，保证了产品快速交付安全质量。3 3）关键技术）关键技术 邮储银行落地云原生安全的关键技术包括以下三大支柱。第一，通过在敏捷项目中有效落实安全左移，通过有效的需求管理平台管理和流转安全需求，使安全需求明晰，开发人员和安全测试人员可以有效跟踪安全需求。第二，在全行建立统一的安全度量体系，包括安全需求覆盖率、安全缺陷密度数、安全缺陷修复率等指标，使安全问题可度

327、量、可评估，借助安全度量体系可以精确识别研发安全过程中的不足，并采取有针对性的优化措施，推动操作风险管理系统的安全性提升。第三，通过自动化的工具平台保障制品的安全、可靠。在 devOps 的流水线中集成多种安全测试工具，并且配置有效的安全门禁，确保构建成功的制品都是通过了安全测试，满足安全要求。4 4）方案推广和意义）方案推广和意义 邮储银行进行了研发安全运维一体化（DevSecOps）探索实践，将 ISO27001 信息安全管理体系与 DevSecOps 实践进行体系融合，从组织建设、制度流程和技术工具三个维度，将安全开发管控策略嵌入到系统敏捷开发全流程各阶段。加强业技融合，左移安全开发管理

328、至需求阶段，从需求源头控制安全合规风险，结 172 合典型业务场景落实安全合规要求。集成自动化安全测试工具链，设置安全质量门禁，建立了研发安全运维一体化安全度量指标体系，提升开发、安全、测试与运维团队的协同能力，保证系统快速交付的安全质量。2 2北京银行在应用发布方面云原生安全成功实践和创新北京银行在应用发布方面云原生安全成功实践和创新 1 1）方案背景）方案背景 当前应用系统架构从单体架构到微服务架构的演进以及云原生技术的快速发展，微服务在分布式系统越来越普及。微服务应用具备可扩展性、敏捷性和容错性的天然优势，也具有独立性、隔离性、服务独立维护和分工明确等鲜明特点，这些优势和特点让微服务架构

329、成为目前分布式软件系统最主流的解决方案。应用容器技术自诞生伊始，天然亲和微服务架构，搭配 Kubernetes 编排管理技术，在改变微服务应用分发方式上迅速征服传统的部署方式。随着 DevOps 理念愈发成熟，多样化的研发运维一体化生态体系促使着软件系统从设计、研发到发布、运维的根本性转变。进入云原生时代的软件工程，如何实现真正意义上的云原生研发运维安全成为一项挑战，北京银行深入研究和实践容器自动化编排技术，形成一套自主研发设计的云原生工程体系，完善从代码到自主运行的一体化服务能力，建设平台工程敏捷交付体系的标准化能力，从而降低开源技术风险，保障金融企业的信息安全。2 2）方案实现）方案实现

330、本方案是研发一种基于云原生框架的软件工程发布运行一体化智能工具，对其提供软件系统架构设计、代码整体编译、全局服务编排、应用部署、应用标准化运行、运行自监测、故障主 173 动告知、故障自动恢复等智能化能力的扩展控制器，面向软件系统微服务应用开箱即用，实现快捷可靠的微服务部署能力。解决了 Kubernetes 平台中没有安全可靠的一体化应用发布问题，通过打造一个以软件系统为核心的扩展控制器提供标准的、高度一致的模型。该控制器不仅仅代表软件系统的模板或者组成部分，而是代表着完整运行的微服务软件系统本身。从而该扩展控制器能够实现针对完整微服务应用的自动化部署、扩展、管理、监控、告警、故障自愈等任务。

331、通过这种方式，该控制器可实现为微服务应用提供一个专注于应用发布及管理的标准化解决方案，实现更高效、更稳定、更一致的应用管理，同时减轻了应用管理的复杂性和运维成本。3 3）关键技术）关键技术 本技术方案基于云原生架构和 Operator 控制器技术，解决微服务软件系统标准化智能发布运维的问题。采用自研的Kubernetes 扩展控制器，并借助发布运行一体化智能工具，实现软件系统的完整交付运维工作。首先，设计并预定义了 Kubernetes 中 CRD 资源的结构和字段类型，以便组建联合发布资源组。Kubernetes 控制器的核心部分是定义“期望的状态”，因此通过对 Kubernetes API

332、 接口的分析和调研，编写了不同的独立 Operator 控制器来管理不同 CRD的生命周期过程，从而分别控制不同自定义 CRD 的发布逻辑和实现联合部署发布逻辑。其中自定义信息项以参数化的方式实现，并且 Operator 控制器通过使用监测 API 监测 CRD 资源的相关事件，从而实现对其事件做出响应行为。此外，本技术方案设计还 174 包含了 Watch 监控器服务，他可以将所有发布的 CRD 资源视为期望标准进行变化监测，以确保自定义资源的正常创建并保持期望的运行状态。将 Operator 控制器将交付过程和运维过程相结合，从而实现联合发布运维一体化的目的。本技术方案将软件系统架构设计、

333、代码整体编译、制品构建、应用部署、全局服务编排、应用标准化运行、运行自监测、故障主动告知、故障自动恢复等过程进行统一整合为单一资源能力。从代码侧到运行侧再到运维侧，实现微服务的全生命周期整体管理。通过以一个视角统一编排统一发布运维的方式，将过往的云上发布只能单一资源创建发布进化为现在的更加高效且可靠的全链路自动化管理。4 4）方案推广和意义）方案推广和意义 至今，北京银行已有 140 余个应用系统上云部署，创建用户404 个，业务副本数量 6318 个。经过对所有上云系统投产情况的持续追踪，单系统单次投产平均耗时 2 小时以上；镜像变更 547次，单个应用镜像更新平均耗时约 10 分钟；新增服务等涉及架构编排调整 15 次。平均耗时约 60 分钟。经过自动化发布工程实践，在自动化投产及运维建设方面积累了宝贵的经验，从结果上看各系统在投产耗时、操作步骤和投产质量各方面表现良好，应用上云部署平