你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于 Azure 的 Microsoft 云采用框架中的安全性
正如云采用是一趟旅程，云安全也是进度和成熟度不断发展的旅程，而不是一个静态目标。
构想安全的最终状态
没有目标的旅程只是盲目漫游。 虽然这种方法可能最终会让人获得启发，但业务目标和约束通常要求关注目标和关键结果。
安全方法可提供完整的最终状态，指导你逐步改进安全计划。 下面的信息图提供了一些关键方法的直观映射，安全性通过这些方法与较大的组织和安全领域中的准则相集成。
云采用框架通过明确流程、最佳做法、模型和体验，为此安全旅程提供安全指导。 本指南基于我们学到的教训和实际客户的真实经验和 Microsoft 的安全旅程，适用于 NIST、The Open Group 和 Internet 安全中心 (CIS) 等组织。
观看以下视频，了解有关安全方法的详细信息，以及它如何随时间推移帮助指导持续安全改进。
映射到概念、框架和标准
安全本身既是独立的组织专业，也是与其他专业集成或重叠的品质/属性，这使得很难精确地定义和详细对应它。 安全行业使用许多不同的框架来捕获风险、计划控制和操作。 下面简要概述了 CAF 安全方法中的准则如何与其他安全概念和指南相关：
零信任：Microsoft 坚信所有安全准则都应遵循假定违规行为、显式验证和使用最低特权访问的零信任原则。 这些原则支撑任何可靠的安全策略，并且必须与企业赋能目标平衡。 零信任最首要、最突出的部分是访问控制，因此在访问控制安全准则说明中对其进行了强调。
The Open Group：这些安全准则与 The Open Group（Microsoft 积极参与该组织）发布的核心原则白皮书中的零信任组件密切相关。 一个值得注意的例外是，Microsoft 提升了创新安全的准则，使 DevSecOps 成为顶级元素，因为此准则对于许多组织来说非常新颖、重要且具有变革意义。
NIST 网络安全框架：对于使用 NIST 网络安全框架的组织，我们突出显示了该框架最密切对应的粗体文本。 新式访问控制和 DevSecOps 广泛对应于框架的完整范围，因此没有单独标记这些项。
对应于角色和职责
虽然安全性是一项高度技术性的准则，但它首先也是反映人类冲突的长期历史的人类准则（但针对计算机和 Internet 进行了更新）。 下图总结了安全计划的角色和职责。
有关详细信息，请参阅云安全功能。
安全转换
随着组织采用云，他们很快就会发现静态安全流程无法跟上云平台、威胁环境和安全技术演变的变化速度。 安全性必须转变为不断发展的方法，以匹配这一变化速度，而这将改变整个组织的组织文化与日常流程。
为了指导此转换，此方法提供有关集成安全性与业务流程（顶部行）和安全技术准则（底部行）的指导。 它们共同实现有意义且可持续的安全旅程进展，以降低组织风险。 很少有组织可以同时掌握所有这些过程，但所有组织都应持续巩固每个流程和准则。
更改驱动因子
安全组织会同时经历两种类型的主要转换
- 安全作为业务风险： 安全性已从纯粹的面向技术质量的专业推进到业务风险管理领域。 这由以下两个因素驱动：
- 数字化转型： 数字足迹的增加会不断增加组织的潜在攻击面
- 威胁形势： 利用特定技能和不断商品化的攻击工具和技术，工业化攻击带来的攻击量和复杂程度有所增加。
- 平台更改： 此外，安全性还与面向云的技术平台更改紧密结合。 这一转变在工厂从运行其自己的发电机转变为接入电网的规模发生。 尽管安全团队通常拥有正确的基础技能，但几乎每个过程和每天使用的技术都在变化，也使其捉襟见肘。
- 预期的转换： 在过去十年中，数字创新已重定义了整个工业。 业务敏捷性，特别是与数字化转型相关的敏捷性，可以快速地推翻组织作为市场领导者的身份。 同样，失去消费者信心也可能对业务产生类似的影响。 尽管从“拒绝”开始阻止项目和保护组织的安全性曾经是可接受的，但接受数字化转型的紧急性必须将赋能模型更改为“在你执行必要的操作以保持相关的同时，让我们讨论如何保持安全”。
指导持久转换
转换业务团队和技术团队对安全性的看法，需要使安全性与优先级、流程和风险框架密切地保持一致。 推动成功的关键领域是
- 区域性： 安全文化必须专注于安全地满足（而不是妨碍）企业任务。 同时，安全性必须成为组织文化规范化的一部分，因为企业在 Internet 之上运营，而它是开放的，允许攻击者随时尝试攻击。 这种文化转变需要在所有级别改进流程、合作关系和持续领导支持，以传达变革、为行为建模并强化转变。
- 风险所有权： 安全风险责任应分配给拥有所有其他风险的相同角色，使安全负责人成为受信任的顾问和主题专家，而不是替罪羊。 安全负责人应负责以这些领导者的语言传达可靠且平衡的建议，但不应对其他人的决策负责。
- 安全人才：安全人才长期不足，组织应始终规划如何以最佳方式开发和分配安全知识和技能。 除了直接提升安全团队的技术安全技能集，成熟的安全团队还会调整其策略，专注于以下内容
- 在 IT 和业务领域的现有团队中不断增强安全技能集和知识。 对于采用 DevSecOps 方法的 DevOps 团队来说，这一点尤其重要，它可以采用多种形式（例如安全支持人员、在社区中识别和培训优秀成员，或者工作交换计划）。
- 为安全团队招聘具有不同技能集的员工，为（业务、人类心理学或经济学等）问题带来全新的观点和框架，并在组织内部构建更好的关系。 对于锤子来说，所有问题看起来都像钉子。
业务一致性
由于这些变化，你的云采用计划应重点关注三个类别的业务协调
- 风险见解： 将安全见解和风险信号/源与业务计划协调一致。 确保通过可重复的过程向所有团队讲述这些见解，并使各团队负责改进。
- 安全集成： 通过可重复的过程和组织所有级别的深层合作关系，将安全知识、技能和见解更深入地集成到业务和 IT 环境的日常运营中。
- 运营复原能力： 专注于确保组织能够在攻击期间继续运营（即使是在降级的状态），并且组织能够迅速退回到正常运营状态。
安全准则
这种转换会对每项安全准则产生不同的影响。 虽然其中每个规则都非常重要，需要投资，但这些规则 (大致) 在采用云时具有最直接的快速获胜机会：
- 访问控制： 应用网络和标识会创建访问边界和分段，以降低任何安全违规操作的频率和范围
- 安全操作： 监视 IT 操作以检测、响应违规操作并实现恢复。 使用数据持续降低违规风险
- 资产保护： 最大程度地保护所有资产（基础结构、设备、数据、应用程序、网络和标识），以最大程度地降低整个环境的风险
- 安全治理： 委托决策会加速创新并带来新的风险。 监视决策、配置和数据以治理对整个环境、整个项目组合中的所有工作负载的决策。
- 创新安全性： 随着组织采用 DevOps 模型来加速创新，安全性必须成为 DevSecOps 过程不可或缺的一部分，并将安全专业知识和资源直接集成到此高速周期中。 这涉及到将一些决策从集中的团队转移到以工作负载为中心的团队。
指导原则
所有安全活动都应遵循并适应两个重点
- 业务赋能： 与组织的业务目标和风险框架保持一致
- 安全保证： 专注于应用以下零信任原则
- 假设违规： 为任何组件或系统设计安全性时，请假设组织中其他资源遭到入侵，来降低攻击者扩展访问权限的风险
- 显式验证： 使用所有可用数据点显式验证信任，而不是假定信任。 例如，在访问控制中，验证用户标识、位置、设备运行状况、服务或工作负载、数据分类和异常，而不是简单地允许从隐式信任的内部网络访问。
- 最低特权访问： 通过提供即使且恰好足够的访问权限 (JIT/JEA)、基于风险的自适应策略和数据保护，来限制用户或资源遭到入侵的风险，从而帮助保护数据和生产力。
相关资源
安全方法属于一组复杂的安全指南，它还包括：
- Azure 架构良好的框架：有关保护 Azure 上工作负载的指导。
- 安全体系结构设计：安全体系结构的实现级旅程。
- Azure 安全基准：Azure 安全性的规范性最佳做法和控制措施。
- 企业规模登陆区域：具有集成安全性的 Azure 参考体系结构和实现。
- Azure 的 10 大安全最佳做法：Microsoft 根据在客户和自己的环境中学到的经验建议的最重要的 Azure 安全最佳做法。
- Microsoft 网络安全体系结构：该图描述 Microsoft 安全功能如何与 Microsoft 平台和第三方平台集成。