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

Azure 安全最佳做法

  • 项目

本文介绍建议的安全最佳做法，这些最佳做法基于客户学到的教训，以及从我们自己的环境中的经验中吸取的经验。

有关视频演示，请参阅 Azure 安全性的最佳做法。

1. 人员：针对云安全之旅培训团队

团队需要了解他们将经历的旅程。

什么？

向安全和 IT 团队介绍云安全旅程及其将导航的更改，包括：

  • 云中的威胁
  • 共享责任模型及其影响安全性的方式
  • 对文化和角色和职责的更改，这些角色和职责通常随云采用而来

为什么？

云安全需要转变思维模式和方法。 虽然安全为组织提供的结果不会改变，但在云中实现这些结果的最佳方法可能会显著改变。

转换到云的过程类似于从独立住宅搬迁到高层公寓。 你仍然拥有基本的基础设施，例如管路系统与电力系统，进行着类似的活动，例如社交、烹饪、看电视、上网等等。 然而，在公寓楼的配套设施、公寓楼的提供者和维护者以及你的日常生活方面，往往存在着巨大差异。

谁？

安全与 IT 组织中的每个人都必须熟悉这些更改，从 CIO 或 CISO 到技术实践者的任何安全责任。

如何操作？

为团队提供所需的环境，以便其在转换到云环境的过程中成功完成部署和操作。

Microsoft 发布了以下课程，客户和 IT 组织在云之旅中已进行了学习。

有关详细信息，请参阅 Azure 安全基准 角色、职责和责任。

2. 人员：针对云安全技术培训团队

人们需要了解他们的目标。

什么？

确保团队有时间参与有关保护云资源的技术培训，包括：

  • 云技术和云安全技术
  • 建议的配置和最佳做法
  • 在何处了解更多技术详细信息

为什么？

技术团队需要访问技术信息才能做出明智的安全决策。 技术团队擅长在工作中学习新技术，但云中的详细信息量通常过大，使他们难以在日常工作中展开学习。

留出专门的时间用于学习技术。 学习有助于确保人们有时间对评估云安全的能力充满信心。 它可以帮助人们思考如何调整其现有技能和流程。

谁？

直接与云技术交互的所有安全角色和 IT 角色都必须投入时间学习有关云平台的技术以及学习如何保护它们。

安全经理、IT 技术经理和项目经理可以熟悉一些有关如何保护云资源的技术详细信息。 熟悉这些信息有助于他们更有效地领导和协调云计划。

如何操作？

确保专业的安全技术人员有时间进行有关如何保护云资产的自定进度的培训。 提供正式培训，由经验丰富的讲师授课并提供动手实验室（虽然并非总是可行）。

重要

标识协议对于云中的访问控制至关重要，但通常不会在本地安全性中确定优先级。 安全团队必须专注于开发熟悉这些协议和日志。

Microsoft 提供了广泛的资源来帮助技术专业人员提高其功能。 这些资源包括：

3. 流程：针对云安全决策分配责任

如果没有人负责制定安全决策，则不会做出安全决策。

什么？

选择负责为企业 Azure 环境做出所有类型的安全决策的人员。

为什么？

明确安全决策归属权可加快云采用速度并增强安全性。 缺乏所有权通常会产生摩擦，因为没有人觉得有权做出决定。 没人知道该找谁做出决策，也没人有动力去研究明智的决策。 摩擦会频繁影响：

  • 业务目标
  • 开发人员时间安排
  • IT 目标
  • 安全性保证

摩擦可能导致出现：

  • 等待安全审批的停滞项目
  • 无法等待安全审批的不安全部署

谁？

安全领导层选择负责做出有关云的安全决策的团队或个人。

如何操作？

选择要负责做出关键安全决策的组或个人。

记录这些所有者和他们的联系信息，并在安全、IT 和云团队中广泛宣传这些信息。 宣传可确保所有角色都可以轻松联系到他们。

以下领域通常需要做出安全决策。 下表显示了决策类别、类别说明以及经常做出决策的团队。

决策 说明 典型团队
网络安全性 配置和维护Azure 防火墙、网络虚拟设备和关联的路由、Web 应用程序防火墙、NSG、ASG 等。 基础结构和终结点安全团队重点关注网络安全性
网络管理 管理企业范围的虚拟网络和子网分配。 中心 IT 运营中的 现有网络运营团队
服务器终结点安全性 监视和修正服务器安全性，包括修补、配置、终结点安全性等。 中央 IT 运营 和 基础结构和终结点安全 团队联合
事件监视和响应 调查和修正 SIEM 或源控制台中的安全事件，包括 Microsoft Defender for Cloud、Microsoft Entra ID 保护等。 安全运营团队
策略管理 设置使用 Azure 基于角色的访问控制（Azure RBAC）、Defender for Cloud、管理员保护策略和 Azure Policy 来管理 Azure 资源的方向。 策略和安全体系结构团队联合
标识安全和标准 为 Microsoft Entra 目录、PIM/pam 用法、多重身份验证、密码/同步配置、应用程序标识标准设置方向。 标识和安全体系结构团队联合进行标识和密钥管理、策略和安全体系结构团队

注意

  • 确保决策者在云领域接受过适当的培训，以履行相应职责。
  • 确保在策略和标准中记录决策，以便提供记录并为组织提供长期指导。

4. 流程：更新云的事件响应流程

提前规划。 你没有时间在危机出现时针对危机做出规划。

什么？

为 Azure 云平台上的安全事件做好准备。 包括准备任何已采用的原生威胁检测工具。 更新流程，让团队做好准备并利用模拟攻击进行练习，以便他们可以在事件调查、修正和威胁搜寻的过程中发挥出最大能力。

为什么？

主动攻击者会给组织带来直接风险。 这种情况可能很快变得难以控制。 快速有效地响应攻击。 此事件响应（IR）过程必须对整个资产有效，包括托管企业数据、系统和帐户的所有云平台。

尽管云平台与本地系统在很多方面相似，但它们在技术上是不同的。 本地系统可能会中断现有进程，通常是因为信息以不同形式提供。 安全分析师可能难于快速响应不熟悉的环境（可能减慢其响应速度）。 如果仅在经典本地体系结构和网络/磁盘取证方法上进行训练，则此语句尤其如此。

谁？

IR 流程现代化通常由安全运营团队主导。 其他团队常常会提供知识和专业技能支持以协同完成此过程。

  • 发起：安全运营总监或同等职位人员通常是流程现代化的发起人。

  • 执行：调整现有进程或首次编写这些进程是一项协作工作，涉及：

    • 安全运营：事件管理团队或领导层主导向关键外部利益干系人提供流程与集成更新。 这些团队包括法律与沟通团队或公共关系团队。
    • 安全操作：安全分析师提供技术事件调查和会审方面的专业知识。
    • 中心 IT 运营：此团队通过云卓越中心或外部顾问，直接提供云平台方面的专业知识。

如何操作？

更新流程并让团队做好准备，以便他们了解在发现主动攻击者时要执行的操作。

  • 流程和 playbook：根据云平台工作原理的差异，调整现有调查、修正和威胁搜寻流程。 这些差异包括新的或不同的工具、数据源、标识协议等。
  • 培训：针对整体云转换、平台工作原理的技术详细信息以及新的或更新的流程培训分析师。 这些信息使他们能够了解可能会发生的变更以及如何实现他们的需求。
  • 重点领域：虽然资源链接中介绍了许多详细信息，但以下区域侧重于教育和规划工作：
    • 共担责任模型和云体系结构：对于安全分析师而言，Azure 是一个由软件定义的数据中心，它提供许多服务。 这些服务包括不同于本地的 VM 和其他服务，例如Azure SQL 数据库 Azure Functions。 最有用的数据位于服务日志或专用威胁检测服务中。 它们不在基础 OS/VM 的日志中，这些 OS/VM 由 Microsoft 运营，并为多个客户提供服务。 分析师需要了解此环境并将其集成到其日常工作流中。 这样，他们就知道需要哪些数据、在何处获取数据，以及数据采用什么格式。
    • 终结点数据源：使用本机云检测工具获取攻击和恶意软件的见解和数据通常更快、更轻松、更精确。 Microsoft Defender for Cloud 与终结点检测和响应 (EDR) 解决方案等工具可提供比传统方法（直接访问磁盘）更精确的数据。 直接磁盘取证适用于可能和需要走法律程序的情况。 有关详细信息，请参阅 Azure 中的计算机取证。 但是，此方法通常是检测和调查攻击的最低效的方法。
    • 网络和标识数据源：云平台的许多功能主要使用标识进行访问控制。 此访问控制包括对 Azure 门户的访问，但网络访问控制也被广泛使用。 此访问控制要求分析师了解云标识协议，对攻击者活动和合法用户活动有完整全面的了解，从而方便开展事件调查和修正。 标识目录和协议不同于本地目录和协议。 它们通常基于 SAML、OAuth、OpenID Connect 和云目录，而不是 LDAP、Kerberos、NTLM 和 Active Directory。
    • 练习练习：模拟攻击和响应有助于建立组织肌肉记忆和技术准备。 它们使安全分析师、威胁搜寻人员、事件管理员和组织其他利益干系人做好准备。 在工作中不断学习和适应是事件响应的自然组成部分，但你可以努力最大程度地减少通过危机来汲取经验和教训。

重要资源

有关详细信息，请参阅 Azure 的 Azure 安全基准事件响应过程。

5.流程：建立安全态势管理

首先，认识你自己。

什么？

确保采取以下措施主动管理 Azure 环境的安全态势：

  • 将明确的责任所有权分配给：
    • 监视安全状况
    • 缓解资产风险
  • 自动执行这些任务并简化任务流程

为什么？

快速发现和修正常见的安全卫生风险可大幅降低组织面临的风险。

云数据中心的软件定义性质可持续监视安全风险，例如软件漏洞或安全配置错误，以及广泛的资产检测。 需要确保安全配置资源并主动监视资源，才能够加快开发人员和 IT 团队部署 VM、数据库和其他资源的速度。

这些新功能提供了新的可能性，但要通过这些功能实现价值，则需要划分功能使用职责。 要在云运营快速发展的情况下实现执行一致，需要尽可能简化和自动化人工流程。 请参阅“简化”安全原则。

注意

简化和自动化的目标不是摆脱工作，而是免去人工重复任务，以便专注于更高价值的人类活动，例如与 IT 团队和 DevOps 团队互动以及为其提供培训。

谁？

此做法通常有两组职责：

  • 安全态势管理：此职能通常在现有漏洞管理或治理职能的基础上发展而来。 其职责包括使用 Microsoft Defender for Cloud 安全分数和其他数据源监视总体安全态势。 包括与资源所有者积极合作，降低风险并向安全领导层报告风险。

  • 安全修正：向负责管理资源的团队分配责任来化解风险。 此责任属于管理自己的应用程序资源的 DevOps 团队或中心 IT 运营中特定于技术的团队：

    • 计算和应用程序资源
      • 应用服务：应用程序开发和安全团队
      • 容器：应用程序开发或基础结构/IT 运营
      • VM、规模集、计算：IT/基础结构操作
    • 数据和存储资源
      • SQL、Redis、Data Lake Analytics、Data Lake Store：数据库团队
      • 存储帐户：存储和基础结构团队
    • 标识和访问资源
      • 订阅：标识团队
      • 密钥保管库：标识或信息/数据安全团队
    • 网络资源：网络安全团队
    • IoT 安全性：IoT 运营团队

如何操作？

安全性是每个人的工作。 不过，并非所有人都知道它的重要性、具体内容以及实现方式。

  • 资源所有者需对安全风险负责，正如他们对资源可用性、性能、成本及其他成功因素负责一样。
  • 为资源所有者提供支持，使其清楚地了解安全风险对其资产的影响，他们可以采取哪些措施来缓解风险，以及如何以最小的生产力损失实现这些措施。

重要

对不同资源类型和应用程序而言，资源保护的原因、内容和方式通常是相似的，但务必要将它们与每个团队已经了解和关心的内容相关联。 安全团队可以与 IT 和 DevOps 相关人员互动，他们是专注于使这些团队获得成功的受信任的顾问和合作伙伴。

工具：Microsoft Defender for Cloud 中的 安全分数可评估 Azure 中各种资产的最重要的安全信息。 此评估是进行安全态势管理的切入点，可以根据需要补充自定义 Azure 策略和其他机制。

频率：设置定期频率（通常是每月），以查看 Azure 安全分数和具有特定改进目标的计划方案。 可以根据需要提高频率。

提示

如果可能，请让活动变得更有趣味性以提高参与度，例如为分数提高最多的 DevOps 团队准备有趣的竞赛和奖品。

有关详细信息，请参阅 Azure 安全基准 安全状况管理策略。

6. 技术：要求无密码或多重身份验证

你是否敢保证你的企业足够安全，你的管理员密码不会被专业攻击者猜到或窃取到？

什么？

要求所有关键影响管理员使用无密码或多重身份验证。

为什么？

正如古董骨架钥匙不会保护房子免受现代入室盗窃，密码无法保护帐户免受常见攻击。 有关技术详细信息，请参阅 pa$$word并不重要。

多重身份验证曾是一个繁琐多余的步骤。 目前，无密码方法使用生物识别方法（如 Windows Hello 和移动设备中的面部识别）来改进用户登录方式。 此外，零信任方法可记住受信任的设备。 此方法可减少提示令人恼火的带外多重身份验证操作。 有关详细信息，请参阅 用户登录频率。

谁？

密码和多因素计划通常由标识和密钥管理或安全体系结构团队主导。

如何操作？

实现无密码或多重身份验证。 培训管理员如何根据需要使用它，并要求管理员遵循书面策略。 使用以下一项或多项技术：

注意

目前，攻击者绕过基于文本消息的多重身份验证的成本相对较低，因此请关注无密码和更强的多重身份验证。

有关详细信息，请参阅针对所有基于 Microsoft Entra ID 的访问的 Azure 安全基准强身份验证控制。

7. 技术：集成原生防火墙和网络安全性

简化针对网络攻击的系统和数据保护。

什么？

通过将 Azure 防火墙、Azure Web 应用程序防火墙 (WAF) 和分布式拒绝服务 (DDoS) 缓解集成到网络安全方法中，简化网络安全策略和维护。

为什么？

简洁对于安全性至关重要，因为它可以减少混乱、配置错误和其他人为错误带来的风险。 请参阅“简化”安全原则。

防火墙和 WAF 是重要的基本安全控制措施，可保护应用程序免受恶意流量的影响，但其设置和维护可能会很复杂，会占用安全团队大量的时间和精力（类似于为汽车添加定制的售后零部件）。 Azure 的原生功能可简化防火墙、Web 应用程序防火墙、分布式拒绝服务 (DDoS) 缓解等功能的实现和操作。

此做法可以使团队腾出时间和精力来完成更有价值的安全任务，如：

  • 评估 Azure 服务的安全性
  • 自动执行安全操作
  • 将安全功能与应用程序和 IT 解决方案集成

谁？

  • 赞助：安全领导或 IT 领导通常赞助网络安全策略更新。
  • 执行：将策略集成到云网络安全策略中是一项协作工作，涉及：
    • 安全体系结构：与云网络主管和云网络安全主管一起建立云网络安全体系结构。
    • 云网络领导 中心 IT 运营 和 云网络安全领导 基础结构安全团队
      • 与安全架构师一起建立云网络安全体系结构。
      • 配置防火墙、NSG 和 WAF 功能，并就 WAF 规则与应用程序架构师合作。
    • 应用程序架构师：与网络安全合作，构建和优化 WAF 规则集和 DDoS 配置，以在不影响可用性的情况下保护应用程序

如何操作？

对于要简化运营的组织而言，有两个选项可供选择：

  • 扩展现有功能和体系结构：许多组织通常选择扩展现有防火墙功能的使用，以便将现有投资转向技能和流程整合中，尤其是在首次采用云时。
  • 采取原生安全控制措施：更多组织开始倾向采取原生控制措施来避免集成第三方功能带来的复杂性。 这些组织通常寻求避免负载均衡、用户定义的路由、防火墙或 WAF 本身配置错误的风险，以及不同技术团队之间的交接延迟。 对于采用基础结构即代码方法的组织而言，此选项极具吸引力，因为内置功能比第三方功能更容易实现自动执行和检测。

有关 Azure 原生网络安全功能的文档可在以下位置找到：

Azure 市场包括许多第三方防火墙提供商。

有关详细信息，请参阅 Azure 安全基准 DDOS 保护和Web 应用程序防火墙保护。

8. 技术：集成原生威胁检测

简化对 Azure 系统和数据的攻击检测和响应。

什么？

通过将原生威胁检测功能合并到安全运营和 SIEM 中，简化威胁检测和响应策略。

为什么？

安全运营的目的是降低访问环境的主动攻击者对环境造成的影响。 这种影响由平均确认时间 (MTTA) 和平均修正时间 (MTTR) 事件来度量。 此做法要求事件响应的所有元素都能快速且准确。 成果有助于确保将工具质量和流程执行效率放在首位。

使用现有工具和方法很难进行重大威胁检测。 因为云技术的差异和它的瞬息万变，这些工具和方法都旨在用于本地威胁检测。 本机集成检测提供云提供商维护的工业规模解决方案，这些解决方案可以跟上当前的威胁和云平台更改。

这些原生解决方案使安全运营团队能够专注于事件调查和修正。 他们可以专注于这些内容，而不是浪费时间针对不熟悉的日志数据、集成工具和维护任务创建警报。

谁？

通常由安全运营团队推动。

  • 发起：此项工作通常由安全运营总监或同等职能人员发起。
  • 执行：集成本机威胁检测是一项协作工作，涉及这些解决方案：
    • 安全运营：将警报集成到 SIEM 和事件调查流程中。 安全运营可以为分析师提供有关云警报及其含义以及原生云工具使用方式的培训。
    • 事件准备：将云事件集成到实践练习中，并确保团队完成实践练习以做好充足准备。
    • 威胁情报：研究并集成有关云攻击的信息，通知团队相关环境及情报。
    • 安全体系结构：将原生工具集成到安全体系结构文档中。
    • 策略和标准：设置用于在整个组织中启用原生工具的标准和策略。 监视合规性。
    • 基础结构和终结点 和 中心 IT 操作：配置和启用检测，以代码解决方案的形式集成到自动化和基础结构中。

如何操作？

为使用的所有资源启用 Microsoft Defender For Cloud 中的威胁检测，并使每个团队按上面所述将这些资源集成到其流程中。

有关详细信息，请参阅 Azure 资源的 Azure 安全基准威胁检测。

9. 体系结构：实现单一目录和标识标准化

没人愿意处理多个标识和目录。

什么？

在单个 Microsoft Entra 目录中标准化。 可以为 Azure 中的每个应用程序和用户实现单一标识标准化。

注意

此最佳做法专门针对企业资源。 对于合作伙伴帐户，请使用 Microsoft Entra B2B ，因此无需在目录中创建和维护帐户。 对于客户或公民帐户，请使用 Azure AD B2C 来管理这些帐户。

为什么？

多个帐户和标识目录会产生不必要的摩擦，从而在日常工作流中造成混淆：

  • 生产力用户
  • 开发人员
  • IT 和标识管理员
  • 安全分析师
  • 其他角色

管理多个帐户和目录会导致出现不良的安全做法。 这些做法包括在各种帐户中重用密码等。 这会增加攻击者对过时或弃用帐户发起攻击的可能性。

尽管有时能够更轻松地快速为特定应用程序或工作负载创建自定义 LDAP 目录，但此操作会造成更多的集成和管理工作量。 此操作类似于选择额外设置一个 Azure 租户或本地 Active Directory 林，而不是使用现有的企业租户。 有关详细信息，请参阅简化的安全原则。

谁？

对单个 Microsoft Entra 目录进行标准化通常是跨团队的工作。 这项工作由安全体系结构团队或标识和密钥管理团队推动。

  • 发起：标识和密钥管理和安全体系结构通常发起此项工作，但某些组织可能要求由 CISO 或 CIO 发起。
  • 执行：执行是涉及：
    • 安全体系结构：此团队将流程纳入安全和 IT 体系结构文档和关系图中。
    • 策略和标准：此团队记录策略并监视合规性。
    • 标识和密钥管理 或 中心 IT 操作：这些团队通过启用功能和支持具有帐户、教育等功能的开发人员来实现策略。
    • 应用程序开发人员 或 中心 IT 操作：这些团队在应用程序和 Azure 服务配置中使用标识。 责任根据 DevOps 采用程度的不同而异。

如何操作？

采用务实的方法，从全新的“绿色地带”功能开始。 然后，作为后续练习，解决现有应用程序和服务的“棕色地带”：

  • Greenfield：建立并实施一个明确的策略，即所有企业标识都可以将单个 Microsoft Entra 目录与每个用户的单个帐户一起使用。

  • 棕色地带：许多组织通常具有多个旧的目录和标识系统。 如果持续管理摩擦的成本超出消除摩擦的资金投入，则解决这些旧项目的问题。 尽管标识管理和同步解决方案可以缓解其中一些问题，但它们缺乏安全功能和生产力功能的深度集成。 这些功能可以为用户、管理员和开发人员提供无缝体验。

应用程序开发周期的以下阶段最适合结合使用标识：

  • 实现面向云的应用程序现代化。
  • 使用 DevOps 流程更新云应用程序。

尽管有正当理由针对独立业务部门或监管要求创建单独的目录，但在其他所有情况下都应避免使用多个目录。

有关详细信息，请参阅 Azure 安全基准 Microsoft Entra 中央标识和身份验证系统。

重要

单个帐户规则的唯一例外是特权用户（包括 IT 管理员和安全分析师）可以具有与管理任务相比的标准用户任务的单独帐户。

有关详细信息，请参阅 Azure 安全基准特权访问。

10. 体系结构：使用基于标识的访问控制而不是密钥

什么？

尽可能使用 Microsoft Entra 标识而不是基于密钥的身份验证。 例如，Azure 服务、应用程序、API。

为什么？

基于密钥的身份验证可用于向云服务和 API 进行身份验证。 但它需要安全地管理密钥，这很难做好，尤其是在大规模。 对于非安全专业人员（如开发人员和基础结构专业人员）而言，安全密钥管理十分困难，他们常常无法实现安全管理，因而时常给组织带来重大的安全风险。

基于标识的身份验证借助其成熟的功能解决了许多这样的问题。 这些功能包括密钥轮换、生命周期管理、管理委派等。

谁？

基于标识的访问控制实现通常需要多个团队协作完成。 这项工作由安全体系结构团队或标识和密钥管理团队推动。

如何操作？

若要为组织设置使用基于标识的身份验证的偏好和习惯，需要遵循流程并借助技术来完成。

该过程

  1. 建立策略和标准，明确概述默认的基于标识的身份验证和可接受的例外。
  2. 为开发人员和基础结构团队提供培训，介绍为何要使用新方法、为此他们需要做什么以及如何做。
  3. 从现在和将来采用新的绿地功能（如新的 Azure 服务和新应用程序）开始，然后对现有棕色场配置进行清理，以务实的方式实施更改。
  4. 监视合规性，并由开发人员和基础结构团队跟进以修正。

技术

对于非人为帐户（如服务或自动化），请使用托管标识。 Azure 托管标识可以向支持 Microsoft Entra 身份验证的 Azure 服务和资源进行身份验证。 通过预定义的访问授权规则启用身份验证，避免在源代码或配置文件中使用硬编码凭据。

对于不支持托管标识的服务，请改用 Microsoft Entra ID 在资源级别创建 具有受限权限的服务主体 。 应使用证书凭据配置服务主体，并回退到客户端机密。 在这两种情况下，Azure 密钥库都可以与 Azure 托管标识一起使用，以便运行时环境（例如 Azure 函数）可以从密钥保管库检索凭据。

有关详细信息，请参阅 Azure 安全基准 应用程序标识。

11. 体系结构：建立单个统一的安全策略

大家劲往一处使，工作才能取得成功。

什么？

确保所有团队都符合允许和保护企业系统和数据的单个策略。

为什么？

如果团队之间没有遵循共同策略而各自开展工作，则团队的行为会在无意之中对另一团队产生不利影响。 未遵循一个策略可能会导致不必要的摩擦，这种摩擦会影响每个人的目标实现进度。

团队各自开展工作在许多组织内司空见惯，其中一个例子就是资产分段：

  • 网络安全：制定用于对平面网络进行分段的策略。 该策略通常基于物理站点、分配的 IP 地址/范围或类似项，可增强安全性。
  • 标识团队：基于对组织的理解和知识，为组和 Active Directory 组织单位 (OU) 制定策略。
  • 应用程序团队：发现很难与这些系统合作。 合作很困难，是因为系统设计时对业务运营、目标及风险缺乏足够的投入和理解。

当组织中出现这种限制时，团队常常会遭遇防火墙例外冲突。 这种冲突会对安全性产生负面影响，因为团队会批准例外情况。 生产力会对安全性产生负面影响，因为它会减慢部署业务所需的应用程序功能。

尽管安全性会带来积极正面的摩擦，推动批判性思维的产生，但这种冲突只会引发消极负面的摩擦，妨碍目标的实现。 有关详细信息，请参阅 安全策略指南。

谁？

  • 发起：统一策略通常由 CIO、CISO 和 CTO 共同发起。 发起通常获得了业务领导对某些高级别元素的支持，由每个团队的代表监督执行。
  • 执行：所有人都必须实现安全策略。 它集成了各个团队的数据，可强化归属权，提高认可度和成功的可能性。
    • 安全体系结构：此团队负责构建安全策略和据此而来的体系结构。 安全体系结构团队主动收集来自团队的反馈，并将其记录到演示文稿、文档和关系图中，以供不同受众查看。
    • 策略和标准：此团队将适当的元素捕获到标准和策略中，并监视其合规性。
    • 所有技术 IT 和安全团队：这些团队提供输入要求，然后与企业策略保持一致并实施。
    • 应用程序所有者和开发者：这些团队阅读并了解面向他们提供的策略文档。 理想情况下，他们会根据角色定制指导意见。

如何操作？

构建并实现云安全策略，所有团队都投入并积极参与。 尽管流程文档格式可能各不相同，但它始终涉及：

  • 团队积极投入：如果没有组织人员的认可，安全策略通常会失败。 理想情况下，召集所有团队一同构建策略。 在我们与客户进行的研讨会上，我们经常发现组织实际上处于运营孤岛状态，在这些会议上，人们往往第一次见面。 我们发现实现包容性刻不容缓。 如果某些团队未被邀请，常常要反复举行会议，直到所有参与者加入会议为止。 如果他们没有加入，则项目不会有进展。
  • 明确记录并清晰传达：所有团队都必须对安全策略有所认识。 理想情况下，安全策略是总体技术策略的安全组成部分。 此策略包含集成安全性的原因、安全性的重要因素以及安全性的结果。 此策略包含专门针对应用程序和开发团队的指导，这样他们可以获得清晰、有序的指导，而无需通读不相关的信息。
  • 稳定但灵活：保持策略相对一致和稳定，但体系结构和文档可能需要更加清晰明了并适应云的动态特性。 例如，即使从使用第三方下一代防火墙转到使用 Azure 防火墙并调整关系图和操作指南，筛选出恶意外部流量仍旧是一项需要保持一致的战略目标。
  • 从分段开始：有大而小的策略问题需要解决，但你需要从某个位置开始。 通过企业资产分段启动安全策略。 此分段是一项基本决策，以后很难对其进行更改，它需要业务投入和许多技术团队的参与。

Microsoft 已发布有关将分段策略应用于 Azure 的视频指导。 已发布有关企业分段和协调网络安全的文档。

云采用框架提供的指南可帮助你的团队：

有关详细信息，请参阅 Azure 安全基准 治理策略。