《金融行业云原生安全体系研究报告》

转载、编摘或利用其他方式使用本白皮书文字或观点的，应注明来源。违反上述声明者，将被追究相关法律责任。编委会成员：编写组成员：府淼淼王文柏袁思思苏涵金睿姜城范鑫禹石伟郑三军路俊杰李根刘静远张政熊永灿张婉莹左伟震张晓居杨冬富纪兆钢刘英杰王广驰张剑强杨增宇常青刘奇志张宪铎宋子虎曾志强何琰吴国友王宏刚张汝成郭洋刘逸伦刘丹李高峰王子健何鑫于雪松赵月姜英伟李雁南王兆阳高浩浩赵佳祥刘海洁郑驰王道谊赵宇轩黄莉群牟晨史巍威詹汉培王明亮贾腾飞黄本涛刘昌娟王文柏施森佳王晓云股份有限公司、中国建设银行股份有限公司、中国邮政储蓄银行股份有限公司、上海浦东发展银行股份有限公司、建信金融科技有限责任公司、北京长亭科技有限公司、绿盟科技集团股份有限公司、阿里云计算有限公司、亚信科技（成都）有限公司、北京京）股份有限公司、北京小佑网络科技有限公司有限公司、平安银行股份有限公司、北京银行股份有限公司、中央国债登记结算有限责任公司、中债金科信息技术有限公司、中国信息通信科技集团有限公司、北京数字认证股份有限公司、深信服科技股份有限公司、杭州安恒信息技术股份有限公司 1 1 12 13 36 38 38 44 73 116 140 141 169 169 183 194 201 209 209 210 213 2901一、概述2必要措施，加强云环境下个人信息的安全保护和合规管理3疗信息处理机构保护患者的隐私，违规者将面临严厉的处罚。45地推动了云环境下的个人信息生命周期的标准化管理与安全控67云原生安全技术与解决方案可以有效解决金融机构采用云8这些服务的推出旨在帮助企业更好地管理其在云环境中的安全9全问题变得更加重要和引人注目。为了应对这些挑战，AWS于Detective，Azure于2018年推出了容器服务AKE（Azure这些产品的推出也进一步促进了云原生应用安全市场的繁荣发州消费者隐私法案CCPA，促使企业加大数据安全与合规投资以构构建的业务系统共同组成的信息系统。容器服务、Service面向云原生环境的安全的目标是防护云原生环境中基础设以云原生形态居多，例如服务网格的安全通常使用旁挂串接云原生环境中的安全防护会天然地要求一些主机侧的安全因此云原生安全研究过程中既要研究思考云原生技术应用所带原生环境中实现有效的应用和数据防护。云安全核心主题范围（Gartner）就云原生环境下安全架构和高级安全特性有过一个[1]“GuidetoCloudSecuritNIST网络安全框架是一个基于风险的网络人业务过程模型业务组织和关系业务时间依业务属性配安全战略和安全实体模型安全有效期业务信息模型实体概要和特安全域定义和安全过程循环业务数据模型安全规则、实用户、应用程平台和网络基控制结构执行数据结构细节安全产品和为和访问控制安全步骤计业务连续性安全服务管应用程序和用站点、网络和安全运营日程[3]“EssentialSkillsforCloudSe并应用基于关系的风险评分矩阵来对不同的实体和资源进行动化、集中化的方式展示企业安全风险现状，甚至实现风险预测，的事件应急响应。四是提高安全管理员和终端用户的可用性。[4]“GuidetoCloudSecurityC云访问安全代理（CloudAccessSecurityBroker，CAS感数据移动到经批准的云应用中，如Microsoft365、Google[5]“EssentialSkillsfor云原生应用程序保护平台（CloudNativeApplication[6]“EssentialSkillsforGartner将云安全态势管理（CloudSecurityPosture[7]“GuidetoCloudSecurit制新资产继续遵守安全策略及监控产品的安全水平；四是适应CSPM工具可以识别常见的云控制平面问题，包括云存储或[8]“EssentialSkillsfor[9]“EssentialSkillsforCMMI（CapabilityMaturityModelIntegrationFor家和地区都有众多机构采用，在国内也被转化为国标标准（GB/T22080），被称为信息安全管理的“最佳实践”。目前，ISO27001标准通过对组织信息科技各重点领域开展信息安全管在开发安全理论和实践方面，美国国家标准与技术研究院4）系统安全工程能力成熟度模型认证（SSE-CMM）EngineerCapabilityMaturityModel，SSE-CMM）是由美国国2008年Synopsys公司发布了软件安全构建成熟度模型（BuildSecurityinMaturityModel，BSIM），与监控，减少数据泄露或被滥用的风险，保障消费者信息安全。二、云原生安全体系（一）云原生安全体系概述生应用的持续交付和部署特性也容易使得新的代码和配置可能智能化安全运维是一种基于人工智能和机器学习技术的安过程可观测是一种在云原生环境中安全实施过程的可视化无论数据在哪里。这可能需要使用数据丢失防护（DLP）解决方Serverless等多形态的应用安全，并确保云原生环境下数据的开发需求规范：安全需求的创建、评审以及验收都应该由开发设计规范：组织上对业务的安全风险级别有明确的分（2）开发规范开发人员管理规范：根据组织级的管理规范，对开发过程（3）构建规范构建安全度量与优化：收集构建过程的数据，并进行分析，（4）测试规范（5）部署规范此在进行系统建设的过程中这类非显性需求容易被项目建设方（2）安全设计（1）制品安全基础开发平台组件、基于开源组件定制化开体现了已经确认的安全配置组，通过将安全配置（2）开源管理定期梳理开源组件的信息建立组织级别的SBOM，使得开源组件（3）代码安全代码安全风险：开发人员可能存在对于高危代码的认识不（1）安全交付风险（2）安全测试（3）安全工具集成安全构建在自动化测试工具链上的安全测试工具不仅可以包括再通过工具中的算法引擎完成包括业务逻辑安全漏洞在内的安（2）监控响应管理（3）安全应急流程（4）人员技能（1）运维准入生环境加载的各类资源和参与云原生环境运维工作的人员或团制品入库缺乏管控：缺乏制品入库的审批流程和验证机云平台配置缺乏安全检测：未经审查或配置不当的云平制品入库准入控制生产环境中的制品库要遵守之前章节中（2）监测预警（1）响应处置（2）溯源分析利用先进的安全分析工具和技术，如安全信息和事件管理（1）情报管理量导入和删除的方式进行快速地管理。情报质量（2）情报处置Hash通过终端安全软件进行全面排查和查杀。如果该样本关联到后端，各个组件一般集中式部署在服务器上。后来随着Web应用系统暴露了大量异构API，可能遭受拒绝服务攻击或存在API滥用的情况。最后，云原生环境中，应（3）数据泄露（4）微服务应用程序安全风险（5）微服务框架安全风险攻击检测和安全事件溯源需要基于应用程序执行情况进行Serverless应用提供函数级的无状态服务，需要对每个资所有功能使用单一权限模型或安全角色（如：授予每个与其他类型的应用程序类似，随着时间的推移，一些Serverless应用和相关的云资源可能会过时，脱离访问控制管（2）数据泄露行中间人攻击以及在静态或传输中窃取数据，仍然适用于（3）函数执行序列控制不足Serverless应用通常遵循微服务设计范式并包含许多离散据资源是被共享的，如果应用将一些数据写入用户空间（如：（5）Serverless应用程序安全风险Serverless应用程序如果没有对外界输入数据进行过滤或Serverless应用是执行单个离散任务的一小段代码，功能远程Web服务来执行任务。然而，当导入易受攻击的第三方依（6）拒绝服务）；虽然许多Serverless平台提供了日志记录工具，但因为（8）Serverless滥用允许攻击者对同一账户执行暴力破解，或使用默认弱口（2）数据泄露者可利用漏洞下载与该应用程序服务器联通的内网服务器上的协议增多：云原生应用环境中，应用间的通信不仅采用（3）拒绝服务（5）供应链安全风险（7）东西向防护不足图16云原生环境下的东西向流量云原生应用场景下的流量不仅包含传统基于边界的南北向（1）微服务资产发现与管理可用的微服务实例。常用的服务注册与发现工具包括Consul、微服务可以通过配置中心来获取需要调用的微服务的地址和端这些平台可以通过监控和管理容器的方式来实现微服务的资产了大量可供追踪使用的API，通过侵入微服务业务的软件系统，（3）微服务应用安全防护方式由于服务端需要存储客户端的登录状态因此在微服务中不认证通过，服务端将用户登录信息进行加密并形成令牌，包含提供服务签名证书，并将证书分发至数据平面各个服务的代理会拦截请求并采用签名证书和另一端服务的Envoy代理进（4）访问控制基于容器编排系统的角色授权服务使用从设计上就会将危险输入进行编码或转义以防止XSS攻击（6）应用程序依赖库漏洞防护容易造成漏洞遗漏，鉴于此，业界通常采取软件组成分析（SoftwareComponentAnalysisSCA）技术，其原理是通过对最终SCA工具会根据这些前提条件判定应用程序是否可以继续使用基于角色的访问控制是实现最小特权原则的经典解决更为严重的是这种现象在生产环境中也频频出现，例如python的oauthlib依赖库曾被通用缺陷列表（CommonWeakness对密钥值使用指定对称密钥经信封加密后保存在专属的存储空（8）微服务高可用性编排是指通过工具如Kubernetes，将微服务部署到多个节点和（2）Serverless调用链路可视化（3）微服务应用安全防护通过上述的选项的合理配置可以在一定程度上减轻DoW攻（8）Serverless被滥用的防护措施主动扫描是通过端口扫描和爬虫等技术主动地识别API资利用侵入性更低的采集工具收集到的数据来实现覆盖更多场景根据安全责任划分原则，Serverless安全聚焦于保护应用微服务安全根据不同的应用场景可以分为三种解决方案：平行容器方案适用于业务通过主流容器编排工具（如处理此业务场景，除此之外，采用多集群编排开源框架如日志可以对接主流的开源云原生日志平台，如Fluentd和Logstash；监控可以对接主流的开源云原生监控平台，如（1）运行时安全PSP是Kubernetes原生的集群维度资源模型，通过APIServer的AdmissionContro（2）可信软件供应链基线例如CISkubernetesbenchmark进行加固，同时保证系统（4）需要注意的是，随着eBPF技术的兴起，传统基于（3）分析层是系统的核心能力，负责进一步处理处理层输过静态、动态的方式验证客户端的可靠性；二是指纹信息采（4）可视化层负责将分析层的结果进行可视化展示，包括（1）安全风险云原生基础设施计算环境是指在云计算平台上构建和运行（2）建设思路恶意代码防范：使用杀毒软件、恶意代码检测工具等技术，（1）安全风险（2）建设思路（VPC）和安全组是实现网络隔离的工具。实施弹性访问控制，首要之务是确保终端设备的操作系统和应用程序保持最新的安全状态。这可以通过定期进行安全更新和应用补丁来实现，（1）安全风险这些风险可能导致未经授权的组织或攻击者获取系统或数据的敏感信息泄露风险：组织的敏感信息和重要数据存储在云数据损坏风险：硬件故障、人为错误、恶意软件、病毒或（2）建设思路范围，通过多因素身份认证（MFA）要求组织在登录时提供多个（1）安全风险采取综合的体系化方式构建自适应的防护体系来确保容器安全（2）建设思路全面及时的资产数据支持可以帮助安全运维人员缩短排查因此云原生环境应该支持对所有资产组件进行安全配置扫令检测应支持对环境内的容器应用进行弱密码扫描的能力，如升网络流量的可观测性，掌握和梳理微服务系并按需控制东西向、南北向网络流量，并微隔离策略的实施效果，给予运维人员及时通过监控网络流量和访问控制的实施效果，可以评估（1）安全风险四是镜像在传输流转过程中信息泄漏或被恶意篡改等多种（2）建设思路（1）安全风险（2）建设思路（1）安全风险（2）建设思路访问控制：建立有效的网络访问控制策略，通过正确的保障工程执行质量和安全管理效果的策略，包括邮储银行将安全基线中的内容转化成为程序员能够理解的源代码安全审计工具扫描后的源代码缺陷清单中标明了缺邮储银行使用大模型基于安全基线生成开发人员易于理解统调用插桩来监控容器镜像的运行状态，以及使用containerd这种复杂性和动态性使得安全事件的闭环响应成为一项重要挑战。为了应对云原生环境中的闭环安全事件挑战，提出基于Definitions（CRDs）来定义安全策略，这些CRDs包含了对AdmissionController扩展：一是编写自定义Admission入控制请求。二是AdmissionController扩展会在请求进入改进策略和响应措施，以不断提高云原生安全性。三是其中在进入Kubernetes集群之前受到严格的安全策略的控制和审（1）安全能力容器化，通过引流将业务流量牵引至安全容图所示，该方案采用eBPF技术将集群微服务引流从用户空间方案通过安全容器的多种部署模式解决了云原生不同场景下遇求和响应数据，识别异常行为的一种技术实现方式云原生可观测性与云原生安全结合可以帮助提高系统的安eBPF（extendedBerkeleyPacketFilter）是一个内核级发，可针对微服务粒度静态访问控制，如进行基于资源（Pod、访问控制策略。OPA提供了更强大的策略定义和执行能力，而IDECodeCD生产仓库测试仓库风险3：自研镜像包含漏洞风险1：软件依IDECodeCD生产仓库测试仓库风险3：自研镜像包含漏洞风险1：软件依赖包含漏洞风险4：自研、第三方镜像包含漏洞风险5：应用安全漏洞基础镜像仓库风险2：基础镜像包含漏洞Gkubernetes容器安全代码安全DockerHUBkubernetes容器安全代码安全DockerHUBper基础镜像仓库DCNAPP平台数据采集校对风险阻断下发代码安全及检测容器安全及检测CI阶段准入基线安全及检测CD阶段准出（1）供应链的完整性保障SBOM作为贯穿整个云原生应用生命周期管理的重要成分，（2）供应链的可靠性保障性校验通过对比使用哈希算法和密钥对数据进行哈希运算获得密过程中所用到的一些密钥，采取多种方式保证他们的安全性，板自动生成相应的安全策略，并将其应用到新上线的应用程序。除了业务上线/下线时的安全策略自动跟随，云原生安全策建立自适应安全基线和策略模型。当监测到行为模向业务调用、东西/南北向的网络攻击进行风险预测和防护，并通过云原生安全平台对云原生应用对应的容器资源进行持续监整，以确保运行中的云原生应用始终受到云原云原生安全策略的自动跟随作为一种创新的策略管理的解三、应用案例（一）云原生研发运维安全邮储银行在采用敏捷方式进行项目开发的过程中面临着一安全专家分析出的安全需求和开发工程师之间的信息传递和沟的每个迭代中的9个安全需求增加到后期每个迭代中可以吞吐证在100%符合安全门限要求，有效阻止带有安全漏洞的制品产邮储银行进行了研发安全运维一体化（DevSecOps）探索实2．北京银行在应用发布方面云原生安全成功实践和创新当前应用系统架构从单体架构到微服务架构的演进以及云本方案是研发一种基于云原生框架的软件工程发布运行一微服务软件系统标准化智能发布运维的问题。采用自研的上发布只能单一资源创建发布进化为现在的更加高效且可靠的北京银行的企业级云原生应用发布工程体系是一项非常优在运营团队侧，设定了专门的情报运营人员，负责情报的六是情报管理：情报的管理涉及情报的更新、录入、删除、其中每个项目的案例包括标准案例和安全人员根据项目实（2）集成化安全测试工具－串联并联集合的安全测试能力+服务化架构模式向分布式+微服务+服务网格方向演进，微服务间访问及交易安全上下文主要通过安全节点号实现粗粒度的安通过对云原生微服务应用的典型交易链路及安全风险点分（1）云原生应用服务交易级鉴权技术（2）应用数据的细粒度访问控制技术与应用容器上一同运行数据访问控制引擎进行数据访问请求权限检查、敏感数据动态脱敏及数据内容最小化返回等应用、接口，以及访问发生时环境的属性出发，构建基于属性（3）基于探针技术实现应用运行时监测与自保护提升应用安全策略动态执行和微服务应用间的细粒度等管控能为成熟的云原生基础设施安全和编排平台安全向云原生应用和我行在金融操作系统内部搭建完成了API安全管理平台和流量日志和API威胁告警日志及敏感数据传输告警日志上传至攻击行为，并根据响应进行攻击结果研判，攻击结果包括失（3）API调用链分析能力（4）业务行为建模分析能力我行在API安全系统上开发实现了业务行为建模分析的落我行API安全系统在敏感数据识别和流动检测的基础上实（2）数据爬取风险监测分析（3）敏感信息传输风险监测分析（4）接口鉴权风险监测分析（6）业务建模分析与异常行为检测我行API安全系统可支持根据单个用户及用户群体日常访在此基线的基础上发现特定用户访问地址变化或者访问群体出生技术在给金融机构业务流程带来颠覆性改变的同时也带来了IT资产的多样化带来新的攻击方式和攻击对象。金融机构大规模引入云原生技术赋能Bank4.0多变的业务需求以及满足农行通过大规模部署行时安全平台并实现对接农行内部CI农行云原生安全保护平台采用通过提供覆盖容器全生命周障了农行在云原生基础架构域的安全同时顺利帮助农行通过信2．某金融机构在云原生计算环境安全方面的成功实践和创新某金融机构容器云平台作为驱动金融数字基础设施建设的集成安全能力。在创建Kubernetes集群时，便将防御容器以（1）全容器化部署故障自愈：软件存在故障时，可以利用平台的“故障自愈”（2）系统高可用仅要确保软件的所有功能都是可预期的，还要努力做到不存在究除了容器安全能力外是否能够挖掘出更优质更全面的安全防海量安全事件关联分析是指从大量繁杂的云网安全事件中2．某银行面向云原生架构的全生命周期一体化安全解决方案目前云原生环境的安全风险主要存在于容器环境的风险暴露面（1）云原生基础设施安全需要重点关注云原生应用运行环（3）容器安全面临的威胁最为严峻，因为越来越多用户已（4）云工作负载防护强调暴露面梳理、持续威胁监测以及（1）通过平台联动制品安全产品和运行时安全产品，与代通过对接K8S容器编排平台，获取云原生资产信息，包括基于开放架构，通过能力接口汇聚来自云原生架构全资产运行时提供有效的攻防对抗能力和攻击痕迹溯源取证能某银行建设的全栈容器平台作为驱动金融数字基础设施建根据某银行对云原生安全领域的探索和相关云原生安全解四、总结和展望（一）金融行业云原生安全研究总结数据高度敏感性以及严格的合规要求使得云原生环境下的安全五、附表级1范是否在工程项目立项阶段，具备安全架构评审流程，组织开展安234是否在需求分析阶段，基于特定业务场景自动生成项目级安全需求清单，进5是否具备开发测试环境管理制度，规范开发测试环6是否确保开发人员通过开发测试云桌面、移动测试终端管理、网络安全准入据防泄漏等工具，对开发测试环境内的敏感信息进行安全防7是否具备开发测试环境源代码管理工具、配置管理工具、研发项目管理工具89是否在编码阶段制定和发布组织级的安全编码规范，对于不同技术栈具有相安全编码规范相对应。应通过安全扫描工具对开源软件进行安全漏洞和法律合规许级会被植入恶意代码。支持对引用的开源软件依赖文件进行恶意行为检测，防止存在被植是否维护黄金镜像库，并要求业务镜像需要基于黄金镜像进行构建。并于黄金镜像构建业务镜像，还要持续地针对黄金镜像库进行是否在测试阶段具备基本的安全测试工具，包括黑盒安全漏洞扫描工具、白目特点制定安全测试方案，对不同级别的安全缺陷有相应的修复时限要求。能够根据安是否在测试阶段需要确定制品晋级（CI/CD）的规范断还是晋级，同时还要根据企业要求持续动态地维护制品晋级（级是否搭建自动化的安全度量分析平台，通过自动化方式对研发过程中的安全动数据进行采集、分析和可视化展现，可以支持从工程项目应用系统、研发团队、安全计是否支持智能化的安全需求管理平台，具备多渠道需求自动化收集与分析处级是否支持智能化的威胁建模平台，实现智能化威胁建模并输出安级级成是否将自动化的安全测试工具内嵌到DevOp是否有相应指标度量安全测试和漏洞修复情况的能力。通过收集分析研发安理是否明确重大安全事件的通报、响应、管理、决策是否设置安全监控相关专职人员，明确安全监控的职责和分工，设置安是否定期对安全人员进行相关的培训，帮助安全人员掌握日益增长变化的安是否明确与监管单位、外部服务商等外部机构的安全事件通报和处置管理机级目标、业务建立最大允许中断时间等，明确事件处置指标要求，包括处置时间、处置过是否结合法律法规、监管要求变化与工作实际，定期修订安全监控制度规范是否结合法律法规、监管要求变化与工作实际，每年分析事件处置的工作流是否定期检查安全监控工具的可用性及安全监控效果情况，及时优化安全监是否建立安全事件应急管理平台，实现安全事件处置流程的自动编排、自动级是否建立应急预案文档库和事件及典型问题知识库，完善、优化机构内部制是否在制度规范中明确针对不同类型、级别的安全事件应急响应是否建立、完善机构之间的协调机制，应对涉及与第三方协同的安全应急是否每年对相关人员进行安全应急流程及预案培训，记录应急预是否明确应急预案的优化更新和评审机制，每年或应急演练后或发生安全事是否具备人员安全培训机制，提升机构人员攻防实机构内部安全人员是否了解常见的云原生组件漏洞，并熟悉相关的攻击工具的使用。级云原生基础设施、基础架构、应用等是否具备独立的威是否支持云基础设施、网络、容器、应用等安全告警和日志信息的统一收是否支持对不同来源的安全告警和日志信息的统一分析是否支持对云原生基础设施、容器、应用等告警信息进行统是否支持对不同来源的安全告警和日志信息进行关联分析实级是否支持根据威胁情报自动完成风险识别和时间、资产理是否支持标准访问控制模型（如访问控制表或级应是否支持对Serverless平台及应用是否支持通过人工智能技术实现基于行为、身份等理是否支持标准访问控制模型（如访问控制表或基于角色、属性的访问控制等级应是否支持微服务以及相关组件安全扫描及修是否支持通过人工智能技术实现基于行为、身份等的攻理级应域级是否支持自定义检查能力，具体包括检测周期，达标的通过率、是否具备对容器内文件变化进行实时监控，发现可疑及恶意的文件，针对恶级是否支持对所有类型的攻击事件进行加白操作，如网络访问类、文件类、进证级），是否支持设置镜像、镜像仓库检查的风险类型，自定义仅扫描检查单个是否支持设置镜像、镜像仓库检查时的属性是否自级是否支持针对镜像提供相应的加密、签名技术，确保镜像的完整是否支持镜像和仓库镜像的定期自动扫描，并是否支持在镜像构建、分发、运行各节点对镜是否支持对长期未被下载使用且存在安全风险的镜像进行统计，并可设置策是否支持组织机构将开发工具、编排工具和容器运行时配置为只通过加密证级全是否支持对集群内组件的证书、密钥等敏感信息进是否支持对集群内组件的身份认证、密钥等敏感信息进是否支持限制用户和服务账号的权限，确保他们只能访问必需的证级是否具备安全大数据分析、机器学习、人工智能等能力分析证级域是否支持对弹性虚拟化或者容器化环境自适应加固和智级证是否具备安全大数据分析、机器学习、人工智能等能力分析证是否支持多因素认证及权限管理，对操作系统的所有身份验证进行审级是否支持租户间数据隔离，包括但不限于日志、监控数据、是否保证虚拟机所使用的内存和存储空间回收时得是否支持本地数据误删除后，从异地备份服务器恢证理域是否设立网络安全管理领导机构，负责审议重大网络安全策略、安全事项和告，听取有关安全管理工作情况汇报，研究部署机构整体安级全开发组件。开展相关岗位培训，培训内容包含安全需求分析、安全设计、安全测试等包括安全需求、安全设计、安全测试、安全开发培训是否设置事件响应管理职责，包括但不限于事件分类分级、事件处置、资源是否建立重大安全事件的通报、响应、管理、决策级是否设置安全监控相关专职人员，明确安全监控的职责和分工，设置安是否规范安全事件响应报告要求，包括分析和鉴定事件产生的原因、收集证是否建立与监管单位、外部服务商等外部机构的安全事件通报和处置管理机是否设置安全攻防相关专职人员，明确安全攻防的职责和分工，能够组是否设置安全攻防相关团队，明确团队的安全监控职责和分工，能够开展常是否设置机构内部安全监控响应人员，熟练使用安全产品，自主开展日志分是否设置机构内部安全监控响应人员，理解云原生相是否设置机构内部安全测试人员，熟练使用代码安全审计、交互式安全测试是否设置机构内部安全管理人员，根据本机构组织结构和人员现状，制定合级是否设置机构内部安全架构人员，熟悉本机构应用架构、技术架构和数据架是否设置机构内部攻防人员，攻击队伍成员应熟悉云原生常用攻击路径，参信息安全漏洞库、国家信息安全漏洞共享平台等国家漏洞相关平台术规范体系，明确各领域安全管理、工作流程、技术规范、安全配置理流程，包括安全需求、安全设计、安全编码、安全测试和投产变更前安全是否建立制度规范管理平台，统一网络安全管理制度现关键字、正则表达式等灵活查询与索引功能，满足用户高效查询、快速掌握制度级是否提供审计接口或支持国家相关第三方权威机构开展独立的全面安全审Ingress、工作负载、ConfigMap是否支持对边缘、混合多云等不同架构的云原生平台具备资产实时识别、关是否支持身份的角色\属性绑定和权限设置，级是否支持对接代码安全、测试安全、容器安全、微服务安全等云原生安全工是否支持与资产管理功能获取的资产信息进行关联，可以通过资产查询相级是否支持对安全策略的集中管控能力，包括但不限于策略的批量启用、停用是否具备独立安全策略管理能力，包括云原生基础设施、基础架构、应用、是否支持安全问题修复全流程的跟踪管理，能够分发修复任务并跟踪问是否支持将检查结果在开发构建、测试运行和生产运行各阶段的数据关联起题镜像是否在运行、运行容器中有漏洞软件包是否为在组件库中的如左移前置解决了多少安全问题，阻断了多少风险险，风险包括但不限于镜像漏洞、弱口令、敏感信息、恶意文件是否支持对云原生应用在开发阶段根据结果处置运营流程配置、按业务场景是否支持在开发阶段中提供控制能力，支持提供构建准入控制能力，对不符级是否应支持将测试阶段中的安全检查结果与对应项目及负责人进行关联，方是否支持云原生应用设计、开发、测试阶段的是否支持云原生应用设计、开发、测试阶段的开关管理、流程设置、检测环节配置管理，检测类型配置管理，以及基于检测结果的管是否支持提供部署、运行的准出控制能力，对不符合安全要求的镜检查频率配置、检查结果格式配置等，并且针对异常检测结果的镜像进行卡点控制策略级是否支持云原生应用创建、发布、运维等操作权限的配置管理及统一管控按于基于RBAC/ABAC，操作权限可控制到集群粒度/服务粒度是否支持容器环境入侵检测及阻断能力按业务需求的统一配置管理，包括但级是否支持容器环境入侵检测及阻断能力按业务需求的统一配置管理，包括但是否支持云原生集群准入策略的统一管控，能够对准入策略上下文进行定义于基于服务身份的应用层访问控制策略配置、微服务熔断策略配置对业务自全域全级级2）核心业务应明示个人信息采集的目的、方式和范围，并安全管理的制度，推动相关要求、流程的落地，并对具体业务或项目的风3）应明确数据采集范围、数量和频度，确2）应采取技术手段保证数据采集过程中个人信息和重级2）应跟踪和记录数据采集和获取过程，支持对数新业务产生的需求、行业新技术和最佳实践、合规新要求级制度等。根据组织内的业务梳理数据源的类型，并明确在关键的数据管理系统（如强或改进与数据服务相关的访问控制与合规级的有效性和效率目标，建立数据质量管理岗位人员与各业务团队的数据管理人员之有效沟通、反馈机制，能够持续、及时地针对数据质量管理工作全业务需求、合规要求，对传输通道、传输节点或数据采用了临时的加密保护2）应有对传输数据加密的技术方案和工具，级景2）应部署对通道安全配置、密码算法配置、密钥法，基于具体的业务选择合适的数据传输安2）应综合量化敏感数据加密和数据传输通道级3）组织应提供统一的数据加密模块供开发传输功能的人员调用，根理等2）应部署相关设备对网络可用性及数据泄漏风险用性的安全需求，能够根据不同业务对网络性能需求制定有效的可用性安全防级全2）应明确购买或获取存储媒体的流程，要求通过可信渠道购4）应对存储媒体进行常规和随机检查，确保存储媒体的使用符合机构公布的关于标、错误或损坏情况，对超过安全阈值的存储媒体级管理、访问控制、日志管理、加密管理、版本2）内部的数据存储系统应在上线前遵循统一的配置要求进行有效的安级面临的安全风险，从而能够保证对各类存储系统的有效2）应明确数据分片和分布式存储安全规则，如数据存储完整性规则、理规则、存储转移安全规则，以满足分布式存储下分片数据完整性、一致性和保密3）组织应根据数据分类分级要求，明确各类各级3）应建立满足应用层、数据层、操作系统层、数据存储层等不同够基于业务发展的需求、合规的需求制定有效的数据加密级复个人经验对部分数据执行了临时的数据备份和恢复2）应明确数据备份与恢复的操作规程，明确定义数3）应明确数据备份与恢复的定期检查和更新工作效期到期时对数据的处理流程、过期存储数9）明确过期存储数据的安全保护机制，对超出有效期的存储数据应具备再次2）应建立备份和归档数据安全的技术手段，包括但不限于对备份和归档级2）应对组织内数据备份的场景、数量、频率进行了定期的统计，了解组1）应建立在线/离线的多级数据归档方式，2）应为不同时效性的数据建立分层的数据3）应具备数据副本或数据备份存储的多种压级全级3）数据脱敏后应保留原始数据格式和特定属性，4）应对数据脱敏处理过程相应的操作进行记录，以满足数据脱级2）应具备对数据脱敏的技术方案定制化的能力，能2）核心业务团队应对涉及个人信息的数据2）应明确数据分析安全审核流程，对数据分析的数行审核，以确保数据分析目的、分析操作等1）在针对个人信息的数据分析中，组织应级2）应记录并保存数据处理与分析过程中对个人信息、重要数据等敏感3）应提供组织统一的数据处理与分析系统，并能够呈现数据处理前系b）应采取必要的技术手段（如对分析结果数据进行扫描并采取必要的控制措施）和管理措施，避免输出的数据分析结果包含可恢复的个人信息、重要数据等数据和d）应具备基于机器学习的敏感数据自动识别、数据分析算法安全设改进数据分析安全管理效果（如改进数据分析级业务系统中根据常识、法律法规或合同协议等要求关注了对数据的正当使用制估，满足国家合规要求后，允许使用。数据的使用应避免精确定位到特定个人，避免评价信用、资产和健康等敏感数据，不得超出与收集数据时所声明的目的2）应完整记录数据使用过程的操作日志，以备级3）组织应基于数据处理环境建立分布式处理安全要求，对外部服务核、分布式处理节点间可信连接认证、节点和用户安全属性周期性确认、数据文件和用户身份鉴权、数据副本节点更新检测及防止数据泄漏等方面进行安全要求和级相关的系统设计、开发阶段通过合理的设计以及运维阶段的有效配置规避相关风险2）应建立分布式处理节点和用户安全属性的或基于个人经验考虑了个别系统的数据导入级命名规则、标识属性等重要信息，定期验证导出数据的完整性和可级5）应配置规范的数据导入导出机制或服务组件，明确数据导入导出最全据的范围和合规性、共享方式的安全性、共享后管理责任和约束措施等方面进行则和技术能力的提供，并推广相关要求在相关施，及数据共享涉及机构或部门相关用户职责级2）应对共享数据及数据共享过程进行监控审计共享的业务执行相应的风险评估，从而提出实际的解决2）应定期评估数据共享机制、相关组件和共3）应在共享数据时，对数据接收方的数据安核级2）应明确数据公开内容、适用范围及规范，3）应定期审查公开发布的数据中是否含有程，通过了岗位能力评估，并能够根据实际发布要求建立相应的应急级核a）应对发布的数据，建立持续的追踪能力施，如身份鉴别、访问控制、授权策略、签名、时间戳、安全协3）应对跨安全域间的数据接口调用采用安全通道、加密传输级景，具备充分的数据接口调用的安全意识、技术能力和3）应按国家相关法律和标准销毁个人信息、级2）应配置必要的数据销毁技术手段与管控措施，2）应明确已共享或者已被其他用户使用的数级2）应依据存储媒体存储内容的重要性，明确磁媒