你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

适用于 Azure 的 Microsoft 云采用框架中的安全性

正如云采用是一趟旅程,云安全也是进度和成熟度不断发展的旅程,而不是一个静态目标。

构想安全的最终状态

没有目标的旅程只是盲目漫游。 虽然这种方法可能最终会让人获得启发,但业务目标和约束通常要求关注目标和关键结果。

安全方法可提供完整的最终状态,指导你逐步改进安全计划。 下面的信息图提供了一些关键方法的直观映射,安全性通过这些方法与较大的组织和安全领域中的准则相集成。

CAF 安全方法

云采用框架通过明确流程、最佳做法、模型和体验,为此安全旅程提供安全指导。 本指南基于我们学到的教训和实际客户的真实经验和 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)、基于风险的自适应策略和数据保护,来限制用户或资源遭到入侵的风险,从而帮助保护数据和生产力。

安全方法属于一组复杂的安全指南,它还包括: