混合多云安全成熟度评估

副标题：云安全评估

最近在学习云安全成熟度评估的方法论，顺便学习和查看一些传统安全成熟度评估。感觉云安全评估和传统安全评估还是有些细微差别，有技术创新带来新的方法和方式，也有IT 运营成熟度提升带来的福利。这里，我们花点时间来做一些总结和思考，将自己的所见和所感，记录下来。

这里首先声明，以下内容均来自互联网及公开材料，所写内容仅供学习和交流，无任何商业利益相关。

郑重声明，本文所涉及内容及信息均来自网站的公开发布信息。

撰写本文仅作为个人学习兴趣及研究，所述内容与本人服务的组织并无关联关系。

前言：

因为工作的微调，我现在更多参与到公司的安全咨询顾问活动中，因此在接受新工作内容之后，会有更多时间同圈中大佬进行学习和沟通。这里，我把这段时间听到和看到有关成熟度评估的内容进行一下整理，同时将自己的理解和思考总结成文。

文章内容简单整理如下：

安全成熟度评估，组织和企业安全成熟度评估在很多组织都已有采用和体现。有自评自测的，也有请第三方咨询公司进场评测。评估的各类形式不限，绝大部分的评估内容和结论，都会针对组织当前安全现状及所发现问题进行总结和讨论。

通常利用调查问卷或者访谈问卷的形式，进行信息收集和分析，通过计算和模型评估，得出特定的结论。并以此结论为参考依据，作为一段时间内安全工作的总结和下一阶段安全工作的开展和依据。

评估之后的动作，发现缺陷，弥补缺陷。缓解风险，设计控制点。制定目标运营模式，制定路线图。完善流程和治理，加强策略制定和完善规章制度。

摸清现状，控制风险，量化管理，提升安全管理成熟度，持续优化。

第一节  安全成熟度评估方法论

在安全评估过程中，很多客户对评估方法论比较感兴趣，在参考一大圈之后，发现没有一个方法论能给覆盖所有的场景和满足其需求。

大部分客户都想通过定制化评估来解决此类问题。因此，我这里也不花太多时间来讨论评估方法论的问题，这些具体评估方法论的设计过程，大家可以参考其它文章。每一种评估方法论都有其优势和思路的合理性。

相似的，我也同时思考过如下几个问题？
成熟度到底是五级还是三级？
PDCA 戴明环？
如何评分才能真实反馈现状？
如何设计并完成下一步路线图？
评估的目标是什么？
安全评估如何打分？
云安全到底有什么不同？

带着一大堆的问题，我开始写这篇文章。

因为看 IBM 公司的资料比较多，开篇，我们先介绍 IBM 公司常用的IT成熟度模型。这里，五级成熟度，可以清晰体现每个阶段的特点，初级，可管理，可定义，量化管理，持续优化。

https://www.ibm.com/garage/method/practices/think/it-maturity-model/

文中有解释为什么选用这个五级模型，选用最流行的 CMMI 模型比较适合软件开发，因此对应到 IT 成熟度中还可以。如果对应到网络安全成熟度又如何呢？

Levels of maturity

The most familiar definitions of levels are defined in CMMI (Capability Maturity Model Integration), which has five levels: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. While CMMI is targeted at a software development process rather than another domain, a simple characterization of the five levels shows that they provide a sense of increasing maturity:

1. Initial(初始): No standards are in place and inconsistency exists across the organization.
2. Managed(管理): A process is in place and activities are managed, but the process is orchestration without insights.
3. Defined(定义): A process is defined as a standard across the organization and is tailored for individual projects.
4. Quantitatively Managed(量化管理): The process is measured and any deviation from the standard is addressed.
5. Optimizing(持续优化): The process is continuously improved.

在一份 2020 年的白皮书中，IBM Security 将 CMMC（Cybersecurity Maturity Model Certification） 的五级评估定义如下：

1. Performed, Basic Cybersecurity Hygiene
2. Documented, Intermediate Hygiene
3. Managed, Good Hygiene
4. Reviewed, Proactive
5. Optimizing, Advanced

这里可以看出，在 Level 2,3,4 部分，同 安全成熟度同IT 成熟度，有明显不同。在 Level 2更多强调安全管理的文档化和制度化，在 Level 4 中，主动防御和干预，似乎更关键。

除 CMMI 之外还有SSE-CMM， Security system engineer capability maturity model，其版本 2.0 之后没有再更新，更多关注安全软件工程，包含组织的安全工程，及过程必备的架构。

系统安全工程-能力成熟度模型ISO/IEC 21827:2008 specifies the Systems Security Engineering – Capability Maturity Model® (SSE-CMM®),该模型是安全工程实践的标准度量。
学术方面的资料，卡内基美隆大学网站有篇文章详细介绍 CMMC 模型。各位可以看看。

https://insights.sei.cmu.edu/blog/an-introduction-to-the-cybersecurity-maturity-model-certification-cmmc/

在第四级别中，特别提到 TTP 和 ATP。强调主动性动作。proactive activities。

第二节  安全成熟度评估模型

在网络安全评估过程中，有技术类型的框架模型，也有单纯成熟度的框架模型。这里，我们不做成熟度模型的介绍，很多公司和机构都有相关内容，请大家自行研究。

美国公司大多会参考和围绕NIST 的框架进行成熟度评估。（NIST Cybersecurity Framework），不同的政府部门也推出各自成熟度模型。

其它评估模型如下：
The (NIST) National Institute of Standards and Technology (NIST) framework
CISA Zero Trust Maturity Model
The Center for Internet Security (CIS) framework
CSA Cloud Controls Matrix
Cybersecurity Maturity Model (CMM)
Cybersecurity Capability Maturity Model (C2M2)
Cybersecurity Maturity Model Certification （CMMC 2.0）
Capability Maturity Model
CIS Critical Security Controls V7 Measures & Metrics

CMMC 2.0 was announced in November 2021 and the proposed changes build upon the CMMC 1.0 framework.

细节大家自行网上查询。

CMMC 2.0 builds upon the initial CMMC 1.0 framework to dynamically enhance DIB cybersecurity against evolving threats.  从五级变为三级。增加 Expert 作为最高级别。但是，Advanced 在 Level2 的内容变化比较大。目前 2.0 还在计划和细则制定中，暂时没有太多分析和讨论。

Level 1: Foundational, 17 Practices, based on basic cybersecurity practices.
Level 2: Advanced, 110 Practices, based on practices aligned with NIST SP 800-171.
Level 3: Expert, 110+ Practices, based on all practices in Levels 1 and 2 augmented by NIST SP 800-172, which supplements NIST SP 800-171 to mitigate attacks from advanced cyber threats.

回到文章题目，云安全成熟度评估，目前越来越多的组织开始针对现有的云环境进行安全成熟度评估。不同的组织有不同的云使用场景，有私有云也有混合多云。以传统 IT 成熟度或者网络安全成熟度进行分析和评估，似乎没能与时具进。但是，在基础的控制项和 domain 安全域的分布情况，似乎大部分内容都还可以适用。

因此，在云安全评估项目中，混合使用多个评估模型或者采用自定义评估 domain 和 control point 控制项的情况还是比较常见，很多大型企业会根据自身业务特点和重点关注点，主动进行适当裁剪和优化。

第三节  云安全成熟度评估模型

前文内容，我们讨论很多安全成熟度评估模型，在云安全成熟度评估方面，其实还有一些云成熟度及云计算成熟度评估模型，这里我们只看云安全这部分。

Cloud Maturity Model 云成熟模型
Cloud Computing Maturity Model 云计算成熟模型
Cloud Security Maturity Model 云安全成熟模型

云安全成熟度评估模型，目前广泛使用的是 Cloud Security Alliance (CSA) 提供的 CCM云安全控制矩阵, Consensus Assessments Initiative Questionnaire (CAIQ) to document compliance with the Cloud Controls Matrix (CCM). Certificate of Cloud Auditing Knowledge (CCAK)。 Auditing the Cloud Controls Matrix（CSA）。

另外，云安全能力成熟度模型集成CS-CMMI全称是Cloud Security Capability Maturity Model Integration, 是由 CSA 大中华区主导。基于CSA发布的《CSA CS-CMMI云安全能力成熟度模型集成评估指南》，对云计算产品和解决方案、云计算服务、云安全技术服务组织的云安全能力成熟度水平进行评估。

国内云原生安全成熟度模型标准，网上资料很丰富，大家自行搜索。国内银行届也有专业的银行信息安全成熟度模型，大家也可以看看行业级别，单独某个行业的成熟度评估。

原生安全成熟度评估，评估面向云原生平台的安全体系，包括云基础设施安全、云原生基础架构安全、云原生应用安全、云原生研发运营安全和云原生安全运维5个能力域、15个能力子项、42个实践项和近400个细分能力要求，由中国信通院征集网络安全成熟度评估行业标准参编单位和专家完成。

云原生能力成熟度体系（CNMM-TAS）包括技术架构（T）、业务应用（A）、安全（S）三部分，由云计算标准和开源推进委员会（TC608）制定标准。

以上模型和文档，大家请自行搜索下载。大部分模型都是 5 个级别。

云安全成熟度评估，有一些自身特点。比如，混合多云，大部分组织都会使用多种云平台，有 SaaS，PaaS，IaaS 的不同云服务商。另外，在云上，服务共享责任模型也对安全责任模型有很多影响和不同。

第四节  云安全成熟度评估目标

在云安全评估过程中，无论是自评还是第三方评测，组织都需要制定一个合理的目标和预期。在目标定义清楚之后，成熟度评估就可以有针对性地展开。

定期和持续性的评估并持续进行改进，比如 PDCA 模型， Plan，Do， Check，Action。其实，我们的成熟度评估就是典型的从 Check 检查开始。

通常安全成熟度评估的目标如下：

1. 综合当前安全现状。
2. 对比同行业基准。
3. 为持续安全投入提供依据。
4. 平衡安全职责及职能。
5. 安全战略及路线图。
6. 提供参考建议至高管及管理层。
7. 发现安全隐患及风险点，并通过修复计划缓解。
8. 对内部风控和审计部门工作提供支撑和依据。

清晰的目标和定位，是评估工作的良好开端。这也是我们在评估过程中，特别容易迷失和经常需要回顾的地方，初心不忘，目标不变。

第五节  云安全架构评估部分

架构和云安全架构这个部分最难写，各家都有自己的特点和架构设计。我这里就不班门弄斧啦。详见各个云厂商发布的架构及安全最佳实践部分。链接如下：

https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/architecture.html
https://docs.microsoft.com/en-us/azure/azure-government/compliance/secure-azure-computing-architecture
https://docs.microsoft.com/en-us/security/cybersecurity-reference-architecture/mcra https://www.alibabacloud.com/zh/product/security https://help.aliyun.com/document_detail/209842.html
https://www.ibm.com/cloud/architecture/architectures/securityArchitecture/
https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=909505
https://www.cisecurity.org/controls/v8
https://www.cisa.gov/sites/default/files/publications/CISA%20Cloud%20Security%20Technical%20Reference%20Architecture_Version%201.pdf

Figure 1: Cloud Security Technical Reference Architecture Composition and Synergies

Cloud Security Technical Reference Architecture （CISA August 2021 version 1.0）

CISA 的云安全架构文档比较详细定义云安全的能力，其中 CSA 及其它业界对云服务商的安全能力评估和安全架构要求，更多强调云服务商的安全能力。这里，我们不重点讨论。

共享责任模型：

这里我想简单讨论一下，共享责任模型和云模式的交叉安全责任覆盖模型。云服务模式从开始就一直被安全专家各种质疑，在云上和云下的安全管理思路不断碰撞。这也是很多云安全成熟度评估项目遇到的共性问题。首先，在责任模型和责任共享层面进行深度剥离和定义。其次，针对不同业务特点进行安全需求梳理。最终，在安全功能和策略的能力前提下进行梳理。

比如数据 data，这里在on premise 和 IaaS，PaaS，SaaS，都有涵盖。但是每个场景里面数据安全的方法和方式都有所不同，从业务团队和安全团队的认知层面，都会有所冲突。虽然我们可以借助画图进行分析和讨论。但是具体到不同的云服务商，其内容和范围的定义均有细微的差异。我这里不展开讨论，但是建议大家考虑求同存异的原则。根据组织和企业的自身业务特点，有针对性的设计和考量。

Figure 2: Responsibilities for Different Service Models

身份安全：

目前云上的身份管理和认证，都比较现代化，众多云服务商都支持先进的认证和授权方式。对应到评估工作中，一般会以一套 IAM 或者 PAM 进行集中管理基础上，进行横向对比分析。更多的评估重点会关注，没有统一管理和单独人工管理的帐户。在特权管理方面，业务部门和安全部分的职能定义需要清晰和定期回顾，审查。

数据安全：

混合云的数据安全是每次评估过程中，大家最关注的点。加密已经成为最低要求，但是评估过程中，还需要关注密钥的生命周期管理。在一些数据分级分类做的比较完善的组织，需要更多关注数据在业务系统中的流动性问题。会不会出发数据安全组的升级或者数据安全管理级别的变化。

最后简单提一下，办公安全和零信任。目前，远程办公场景下，组织会有大量云服务及 SaaS 应用在使用，一套有效的 CASB 安全策略管理及清晰的数据安全管理规范就很有必要。但是，在评估中，办公环境下的数据安全会耗费大量成本，建议可以考虑场景化的分析和单独进行场景评估。

网络安全：

云安全评估中，网络安全部分也尤其重要，云中网络访问关系的梳理，云上云下，微隔离是如何配置和定义。在云服务商的网络控制及限制能力，有没有其余 IP 白名单，以及部分场景下 SASE 的集成能力。这里我们不详细分析。

应用安全：

云环境下的应用安全非常复杂，有代码基本的，有微服务，有 API 能力，有容器化能力。大部分场景下，组织都会有 SDLC 的管理和 DevSecOps 能力。这里我们不详细分析。

需要提醒的一点，很多 SaaS 服务的交互不仅仅是网页和 APP 应用，其 API 接口和数据集成能力的安全性和配置管理，在某些组织中，并没有很好的管理起来。存在一些影子系统和未知的功能已被默认开启。

自动化：

云时代的最大技术变化就是自动化工具的介入，在成熟度评估中，既要观察自动化能力带来的成熟度体现，还需要同时兼顾安全的控制。甚至在安全工具的自动化能力同时，评估安全隐患和风险控制。CWPP 和CSPM 两部分，这里先跳过，我们在后面章节介绍工具的时候再讲。

测试开发环境：

在混合云环境下，还有一个特别需要重视的环境安全问题，开发环境及测试环境。大量的云上资源使用，带来便利的同时也带来很多安全问题。比如测试环境的管理和监控，有些组织对测试环境的安全重视不够。很多时候，测试环境就是在云平台上的另一个租户，在测试环境中的一些安全控制手段要明显放松。因为测试环境和生产环境是多租户隔离，大家普遍对测试环境的重视程度不够，但是，这里要强调，测试环境基本是功能相同与生产环境。因此，攻击者完全可以在测试环境，测试和验证所有的攻击方法和方式，从而在生产环境一击必中。

安全架构分层分析：

在架构分析和评估过程中，通常需要从暴露面的角度进行评估和分析。通常还会考虑到风险分析，将风险和暴露面一起进行综合分析评估。这里，安全架构并不是要求一切都向安全对齐，云环境尤其是混合云环境，很多架构以及突破传统 IT 的架构。我们的建议是，从业务视角出发，紧跟工作流程，逐步进行分析，最终落脚到安全能力和安全防护中。避免，主观的从安全视角出发，从而举步维艰。

第六节  云安全成熟度评估应急响应部分

IR（incident response） 应急响应部分，目前组织的安全管理都有已经在运行的流程和制度，针对云环境的安全响应部分都有涉及。这里，需要注意的是在应急响应过程中，基于服务共享和安全责任共享部分，划清界限，并主动干预和影响对方。不能简单适配流程，要基于一些云的特征和特点，在调查和取证方面更加注意。

SOAR，（ Security Orchestration, Automation, and Response）安全自动化编排与响应，评估过程中也会涉及 playbook 剧本的 review 查看。其实，在 OODA（Obeseve-Orient-Decide-Act）理念下，观察-调整-决策-行动已经能帮助组织快速响应云安全事件。在评估中，是否有相应的工具和能力，对评估成熟度会有明显效果。

BCP（Business continue plan）业务连续性 计划，云安全成熟评估也需要考虑更多，混合云场景下的业务连续性问题。比如DR （Disaster Recovery），迁移便利性（Interoperability and Portability），及供应链风险。这些内容，都会在一定程度上反映组织的云安全成熟度能力。

评估也会关注，定期安全演练及云安全事件的针对性沙盘推演及演习。

第七节  云安全成熟度评估工具部分

在云安全评估过程中，自动化评估和配置检查工具可以帮助我们提升评估效率和准确率。访谈及提问环节，通常带有很强的主观意见。借助自动化配置检测工具及集中化配置收集和管理平台，可以在第一时间发现隐患和风险点。同时，自动化工具的优点还有动态检测修复结果和现状。部分自动化配置检查工具，会同时提供检测依据和修复建议。

• Identity-Based Segmentation
• Cloud Access Security Brokers (CASBs):
• Cloud Security Posture Management (CSPM):
• Cloud Workload Protection Platform (CWPP)
• Development, Security, and Operations (DevSecOps):
• Infrastructure as Code (IaC):
• Secure access service edge (SASE),
• Security Orchestration, Automation, and Response（SOAR）

自动化云管理工具+自动化云安全工具。CWPP+CSPM+CSAB 的组合使用。确实反映出在云环境下，自动化工具带来的便捷和效率提升。同时，云安全的能力还可以借助很多云原生自动化管理工具进行部署和修复。

在云安全评估中，发现问题到定位问题，都可以使用自动化的工具和方法。同样，在评估后期的整改和建议中，利用云安全工具和自动化工具，可以快速修复安全问题。

在安全评估中，访谈和配置检查项目，可以利用工具快速取证和验证。避免在传统评估项目中，对问题的定位困难，仅凭访谈经验和问卷来核实问题。在评估中，沟通效率和实践能力都有不错体现，推荐大家在评估中，利用工具快速固定证据及发现问题。通常从工具中发现的问题，调研方无法抵赖，修改和治理的方式比较容易沟通。绝大多数问题，会在短期完成整改和跟进。并且，在安全合规基线和安全配置基线方面，评估中发现的问题，可以整理并记录下来，用于后续的工作和经验积累。

当然，这些都是很容易量化和定位的，在不容易量化和定性的问题中，就需要后续的章节进行评估。

第八节  云安全成熟度评估风险评估部分

在云安全评估过程中，风险评估是不可或缺部分。部分组织和企业，有独立的网络安全和风险管理团队，也有些组织会有专业的风控团队。在评估过程中，安全团队也会多次要求进行系统性风险的分析和评估。这些评估的点和细节，其实很难在调查问卷进行体现，也是自动化工具无法直接检测和扫描的。通常，在成熟度分析过程中，会有打分环节。如何根据风险和危害程度进行风险分析和打分，经常是评估项目的讨论焦点。

风险管理：系统和工作分析、风险识别、风险分析、风险评价、风险控制。

风险识别：评估过程中经常会进行配置项检查和云上配置梳理。

风险分析：可用性风险，接入风险（网络，终端，认证，授权），数据安全风险。

风险评价：针对评估发现的控制点进行风险评估。

漏洞风险控制：针对相关漏洞管理和评估过程中，发现的问题进行风险控制。

上面这些风险的内容和知识，比较分散和凌乱。这里建议考虑引入风险量化模型进行风险计算。同时，各家的安全框架和标准，都有针对风险的部分，虽然各有关注点不同。但是，综合起来可以有针对性的进行风险的量化分析。这里也建议在评估过程中，引入风险计算的公式，针对评估发现问题进行风险分析。

但是，如果回到成熟度评估的话题上，感觉风险分析还是需要更多的关注和重视。

第九节  云安全成熟度评估量化分析部分

在云安全评估过程中，在成熟度第四级的量化管理级别中，对组织的量化管理能力有定义和要求。有提到量化管理和量化控制的两种概念。在评估过程中，我也多次思考过这个问题。一定要到量化管理，才是成熟度的较高级别吗？

在 IBM Security的模型中，我看到第四级别是主动。这里可以简单理解为，成熟度体现在能够主动进行安全管理以及在安全管理中能够做到主动干预，可以利用量化管理的能力进行安全风险控制及安全运营能力较强。

这里，我们再回到量化分析这个部分，整体云安全成熟度评估，包括访谈和风险分析。其实整体看安全成熟度，我们还会去评估制度定义和流程管理方面。甚至也会去看，体系管理，文化管理。这些都能反映一个组织的安全能力和安全运营的成熟度。

传统的量化管理不局限于数字化管理，不仅有定量机制，还有定性机制。评估内容和结果都需要进行量化分析，比如计算分值和打分环节。

在评估过程中，如何客观而已准确的评价当前安全现状及成熟度。就需要引入量化分析的模型和方法论，避免依赖于个人经验和主管判断。

在成熟度评估Auditing the Cloud Controls Matrix的手册中，针对每一类问题都有推荐的评估计分的推荐参考。

在评估过程中，量化分析可以帮助我们快速计算出成熟度。但是，多种模型的混合使用，包括多种自动化工具的引入都会造成数学公式的超级复杂。更多的时候，权重和风险定性是容易发生争议的地方。在量化评估的同时，必须合情合理，要拿出能够服众的计算模型。

第十节  云安全成熟度评估其它部分

在云安全评估过程中，安全治理工作一直是重中之重。治理和合规可以保证组织在使用第三方服务时，要求 CSP 服务提供商，提供符合许多法规要求的服务，提供最低级别的遵从性。安全解决方案还包括针对某些监管需求持续评估云服务的部署和环境。

策略和制度的回顾，这些管理方式是否针对云环境有特别定义和针对性调整。

变更管理及运营能力，在云环境下的管理和运营能力评估。

安全意识培训：

在安全评估中，云环境的安全意识培训工作也需要重点关注。

RACI 模型分析，RACI charts (responsible, accountable, consulted, and informed) 明确各个角色及相关责任，业务部门和安全部门，云服务商责任模型，定期梳理和优化。

迁移便利性（Interoperability& Portability）

很多时候，云服务的粘性较弱，迁移便利性会考虑，如何从一个云服务供应商到另一个供应商快速上线。带着组织的数据，快速适配，敏捷性也很重要。

供应商管理

在评估云安全成熟度的过程中，其实供应链及供应商的安全能力评估也是需要兼顾。在评估过程中，如何准确评价一个云服务供应商，也是需要关注的点。通常，云服务商也会提供其安全认证的报告和一些第三方评测报告。例如 SOC2，

Azure AD 及 Office 365 这种强依赖的平台，以及 ERP 和 CRM 这种重型系统。

评估中会遇到 Office365 和 SAP 这两套大环境，期间各种安全功能的学习和掌握，耗费精力很多，由于篇幅的问题。这里不写，找机会再聊。

后记：

这篇文章断断续续写到一个多月，期间很多次写到从新思考和资料查阅。感觉每次都有新的想法和观点，因此文章的连续性会有一点问题。当然，不能穷举法，写不完的。感谢理解。

写文章的主要目标不是讨论技术问题，是想根据自己对安全成熟度评估的理解，给出一些实践总结。其实，我们在项目中，更多的时间和工作量用于评估过程的访谈和验证。在评估过程中，可以深入了解每个应用和系统的安全特性。同时，在思考这些安全功能是否开启以及开启的必要性。平衡安全与业务性能，兼顾组织的成本及效率。

不一定所有的评估都需要第三方独立进行，在自我评估中，能够针对一个阶段进行评估和总结，其作用和意义都会帮助到安全团队及整个组织。在前文有提过，评估的目标，以目标和结果做为导向。不见得所有的评估都是为证明现有安全工作的成功与不足，评估可以在一定程度上反映安全现状，可以做为未来改进的参考和动力。

同时，评估还可以做为一种高级健康检查，通过短期评估发现和集中整改部分安全隐患和潜在问题。以评估促进建设，以评估帮助提升安全基线，以评估制定将来的技术路线图，以评估为依据建立和改善现有安全运营模式。因此，安全评估可以是合规内容，也可以是技术梳理，还可以是安全管理完善及快速整改。

对组织和企业一定会有更多帮助，对团队和整体安全运营提成熟度。

安全度量和风险量化是在评估中，最多的争议点。

风险量化，真的是，值得在每一个组织和企业计算一次，分析一次，量化一次。

安全度量：可以衡量安全能力，通过建立基础基线，不断提升安全运营能力。将安全度量架构化，变成安全架构关注的问题，从安全架构来驱动安全度量，采用安全系统工程的方法论进行管理。 利用多种技术手段，在自动化和自适应方面不断提升安全成熟度。

辛苦做完评估项目，如何跟领导汇报呢？这汇报材料怎么写，藏着掖着，还是体无完肤呢？又开始跑题，最后欢迎大家多讨论和分享，交流起来，学习起来。

祝好！
郑磊 于 2022.04

致谢环节，在写文章过程中，多次在各位老师的微信公众号的文章中，查看和学习思路。
这里一并向各位安全圈的朋友表示感谢！
云安全一直在变化，文章中难免欠缺和遗憾，水平有限，能力一般，感谢理解！