你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 安全最佳做法
此列表包含建议的 Azure 安全最佳做法（排名靠前），这些做法基于客户经验及我们在环境中获得的经验。
有关这些最佳做法的视频演示，请参阅十大 Azure 安全最佳做法。
1. 人员：针对云安全之旅培训团队
团队需要了解他们将经历的旅程。
对象
针对云安全之旅以及将要应对的变化培训安全团队和 IT 团队，包括：
- 云中的威胁
- 共担责任模型及其对安全性的影响
- 通常随云采用而发生的文化变更和角色/责任变更
原因
迁移到云是一项重大变更，需要转变安全思维模式和方法。 虽然安全性为组织带来的结果不会改变，但在云中实现这些结果的最佳方式通常会发生变化，有时甚至发生显著变化。
转换到云的过程类似于从独立住宅搬迁到高层公寓。 你仍然拥有基本的基础设施，例如管路系统与电力系统，进行着类似的活动，例如社交、烹饪、看电视、上网等等。 然而，在公寓楼的配套设施、公寓楼的提供者和维护者以及你的日常生活方面，往往存在着巨大差异。
谁
安全 IT 组织中负有任何安全责任的每个人都必须熟悉这种环境。 他们必须熟悉从 CIO 或 CISO 到专业技术人员的变化。
方式
为团队提供所需的环境，以便其在转换到云环境的过程中成功完成部署和操作。
Microsoft 发布了以下课程，客户和 IT 组织在云之旅中已进行了学习。
- 安全角色和职责在安全组织中如何演变
- 安全威胁环境、角色和数字策略的演变
- 安全、策略、工具和威胁的转换
- 从 Microsoft 保护超大规模云环境的经验获得的知识，可帮助实现你的旅程
有关详细信息，请参阅 Azure 安全基准 gs-3：协调组织角色、职责和责任。
2. 人员：针对云安全技术培训团队
人们需要了解他们的目标。
对象
确保团队有时间参与有关保护云资源的技术培训，包括：
- 云技术和云安全技术
- 建议的配置和最佳做法
- 在何处了解更多技术详细信息
原因
技术团队需要获得技术信息，以做出明智的安全决策。 技术团队擅长在工作中学习新技术，但云中的详细信息量通常过大，使他们难以在日常工作中展开学习。
留出专门的时间用于学习技术。 学习可帮助确保人们有时间对自己的云安全评估能力建立信心。 它可以帮助人们思考如何调整其现有技能和流程。 即使是军队中最有天赋的特别行动小组也需要训练和情报才能发挥出他们的最佳状态。
谁
直接与云技术交互的所有安全角色和 IT 角色都必须投入时间学习有关云平台的技术以及学习如何保护它们。
安全经理、IT 技术经理和项目经理可以熟悉一些有关如何保护云资源的技术详细信息。 熟悉这些信息有助于他们更有效地领导和协调云计划。
方式
确保专业的安全技术人员有时间进行有关如何保护云资产的自定进度的培训。 提供正式培训，由经验丰富的讲师授课并提供动手实验室（虽然并非总是可行）。
重要
标识协议对于云中的访问控制至关重要，但在本地安全性中通常没有优先考虑它们。 因此，安全团队必须重点熟悉这些协议和日志。
Microsoft 提供丰富的资源来帮助专业技术人员提高保护 Azure 资源和报告合规性的能力。 这些资源包括：
- Azure 安全
- Az-500 学习路径和认证
- Azure 安全基准 (ASB)
- Microsoft 安全最佳做法
- Azure 合规性
- 标识协议和安全性
- Azure 安全文档站点
- Azure AD 身份验证 YouTube 系列
- 使用 Azure Active Directory 保护 Azure 环境
有关详细信息，请参阅 Azure 安全基准 gs-3：协调组织角色、职责和责任。
3. 流程：针对云安全决策分配责任
如果无人负责做出安全决策，则不会做出任何决策。
对象
选择负责为企业 Azure 环境做出所有类型的安全决策的人员。
原因
明确安全决策归属权可加快云采用速度并增强安全性。 归属权缺失通常会引发摩擦。 它引发摩擦，是因为没人觉得自己有权做出决策。 没人知道该找谁做出决策，也没人有动力去研究明智的决策。 摩擦会频繁影响：
- 业务目标
- 开发人员时间安排
- IT 目标
- 安全性保证
摩擦可能导致出现：
- 等待安全审批的停滞项目
- 无法等待安全审批的不安全部署
谁
安全领导层选择负责做出有关云的安全决策的团队或个人。
方式
选择负责做出关键安全决策的团体或个人。
记录这些所有者和他们的联系信息，并在安全、IT 和云团队中广泛宣传这些信息。 宣传可确保所有角色都可以轻松联系到他们。
以下领域通常需要做出安全决策。 下表显示了决策类别、类别说明以及经常做出决策的团队。
| 决策 | 说明 | 典型团队 |
|---|---|---|
| 网络安全性 | 配置和维护 Azure 防火墙、网络虚拟设备（及关联的路由）、Web 应用程序防火墙 (WAF)、NSG、ASG 等。 | 基础结构和终结点安全团队重点关注网络安全性 |
| 网络管理 | 管理企业范围的虚拟网络和子网分配。 | 中心 IT 运营中现有的网络运营团队 |
| 服务器终结点安全性 | 监视和修正服务器安全性，包括修补、配置、终结点安全性等。 | 中心 IT 运营团队和基础结构和终结点安全团队共同协作 |
| 事件监视和响应 | 在 SIEM 或源控制台中调查和修正安全事件，包括 Microsoft Defender for Cloud、Azure AD 标识保护等。 | 安全运营团队 |
| 策略管理 | 为使用基于角色的访问控制 (RBAC)、Microsoft Defender for Cloud、管理员保护策略和 Azure Policy 治理 Azure 资源设定方向。 | 策略和标准团队和安全体系结构团队共同协作 |
| 标识安全和标准 | 为 Azure AD 目录、PIM/PAM 的使用、多重身份验证、密码/同步配置以及应用程序标识标准设定方向。 | 标识和密钥管理团队、策略和标准团队和安全体系结构团队共同协作 |
注意
- 确保决策者在云领域接受过适当的培训，以履行相应职责。
- 确保在策略和标准中记录决策，以便提供记录并为组织提供长期指导。
有关详细信息，请参阅 Azure 安全基准 gs-3：协调组织角色、职责和责任
4. 流程：更新云的事件响应流程
你没有时间在危机出现时针对危机做出规划。
对象
更新流程，让分析师准备好响应 Azure 云平台的安全事件。 包括准备任何已采用的原生威胁检测工具。 更新流程，让团队做好准备并利用模拟攻击进行练习，以便他们可以在事件调查、修正和威胁搜寻的过程中发挥出最大能力。
原因
主动攻击者会给组织带来直接风险。 风险可能很快就会导致出现难以控制的局面。 快速有效地响应攻击。 事件响应 (IR) 流程必须对整个资产有效，包括托管企业数据、系统和帐户的所有云平台。
尽管云平台与本地系统在很多方面相似，但它们在技术上是不同的。 本地系统可能会中断现有进程，通常是因为信息以不同形式提供。 安全分析师可能难于快速响应不熟悉的环境（可能减慢其响应速度）。 这种说法是正确的，如果他们只接受过经典本地体系结构和网络/磁盘取证方法的培训，则尤其如此。
谁
IR 流程现代化通常由安全运营团队主导。 其他团队常常会提供知识和专业技能支持以协同完成此过程。
发起：安全运营总监或同等职位人员通常是流程现代化的发起人。
执行：调整现有流程（或首次编写流程）是一项协同工作，涉及：
方式
更新流程并让团队做好准备，以便他们了解在发现主动攻击者时要执行的操作。
- 流程和 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。
- 练习：模拟攻击和响应有助于培养组织肌肉记忆并做好技术准备。 它们使安全分析师、威胁搜寻人员、事件管理员和组织其他利益干系人做好准备。 在工作中不断学习和适应是事件响应的自然组成部分，但你可以努力最大程度地减少通过危机来汲取经验和教训。
重要资源
- 事件响应参考指南 (IRRG)
- 有关如何生成自己的安全事件响应过程的指南
- Azure 日志记录和警报
- Microsoft 安全最佳做法
- Microsoft 网络防御运营中心 (CDOC) 知识
有关详细信息，请参阅 Azure 安全基准 IR-1：准备 - 更新 Azure 的事件响应流程。
5.流程：建立安全态势管理
首先，认识你自己。
对象
确保采取以下措施主动管理 Azure 环境的安全态势：
- 明确以下责任归属：
- 监视安全态势
- 缓解资产风险
- 自动执行这些任务并简化任务流程
原因
快速发现和修正常见的安全卫生风险可大幅降低组织面临的风险。
云数据中心的软件定义性质使其能够通过广泛的资产检测对安全风险（如软件漏洞或安全配置错误）进行持续监测。 需要确保安全配置资源并主动监视资源，才能够加快开发人员和 IT 团队部署 VM、数据库和其他资源的速度。
这些新功能提供了新的可能性，但要通过这些功能实现价值，则需要划分功能使用职责。 要在云运营快速发展的情况下实现执行一致，需要尽可能简化和自动化人工流程。 请参阅“简化”安全原则。
注意
简化和自动化的目标不是摆脱工作，而是免去人工重复任务，以便专注于更高价值的人类活动，例如与 IT 团队和 DevOps 团队互动以及为其提供培训。
谁
此做法通常有两组职责：
安全态势管理：此职能通常在现有漏洞管理或治理职能的基础上发展而来。 其职责包括使用 Microsoft Defender for Cloud 安全分数和其他数据源监视总体安全态势。 包括与资源所有者积极合作，降低风险并向安全领导层报告风险。
安全修正：向负责管理资源的团队分配责任来化解风险。 这项责任归属 DevOps 团队（管理自己的应用程序资源）或中心 IT 运营中特定技术的团队：
- 计算和应用程序资源
- 应用服务：应用程序开发/安全团队
- 容器：应用程序开发或基础结构/IT 运营
- VM/规模集/计算：IT/基础结构运营
- 数据和存储资源
- SQL/Redis/Data Lake Analytics/Data Lake Store：数据库团队
- 存储帐户：存储/基础结构团队
- 标识和访问资源
- 订阅：标识团队
- Key Vault：标识或信息/数据安全团队
- 网络资源：网络安全团队
- IoT 安全性：IoT 运营团队
- 计算和应用程序资源
方式
安全工作，人人有责。 不过，并非所有人都知道它的重要性、具体内容以及实现方式。
- 资源所有者需对安全风险负责，正如他们对资源可用性、性能、成本及其他成功因素负责一样。
- 为资源所有者提供支持，使其清楚地了解安全风险对其资产的影响，他们可以采取哪些措施来缓解风险，以及如何以最小的生产力损失实现这些措施。
重要
对不同资源类型和应用程序而言，资源保护的原因、内容和方式通常是相似的，但务必要将它们与每个团队已经了解和关心的内容相关联。 安全团队可以与 IT 和 DevOps 相关人员互动，他们是专注于使这些团队获得成功的受信任的顾问和合作伙伴。
工具：Microsoft Defender for Cloud 中的 安全分数可评估 Azure 中各种资产的最重要的安全信息。 此评估是进行安全态势管理的切入点，可以根据需要补充自定义 Azure 策略和其他机制。
频率：设置定期频率（通常是每月），以查看 Azure 安全分数和具有特定改进目标的计划方案。 可以根据需要提高频率。
提示
如果可能，请让活动变得更有趣味性以提高参与度，例如为分数提高最多的 DevOps 团队准备有趣的竞赛和奖品。
有关详细信息，请参阅 Azure 安全基准 gs-2：定义安全态势管理策略。
6. 技术：要求无密码或多重身份验证
你是否敢保证你的企业足够安全，你的管理员密码不会被专业攻击者猜到或窃取到？
对象
要求所有严重影响管理员使用无密码或多重身份验证。
原因
就像老旧的万能钥匙没法防止现代小偷侵入屋子一样，密码也没法保护帐户免遭我们今天看到的常见攻击。 你的密码无关紧要中介绍了有关的技术详细信息。
多重身份验证曾是一个繁琐多余的步骤。 目前，无密码方法使用生物识别方法（如 Windows Hello 和移动设备中的面部识别）来改进用户登录方式。 此外，零信任方法可记住受信任的设备。 此方法可减少出现恼人的带外多重身份验证操作提示。 有关详细信息，请参阅用户登录频率。
谁
密码和多因素计划通常由标识和密钥管理或安全体系结构团队主导。
- 发起：此项工作通常由 CISO、CIO 或标识主管发起。
- 执行：执行是一项协同工作，涉及：
方式
实现无密码或多重身份验证。 培训管理员如何在需要时使用它，并通过书面政策要求管理员遵守。 可通过以下一种或多种技术完成：
- 无密码 (Windows Hello)
- 无密码（Authenticator 应用）
- Azure AD 多重身份验证
- 第三方多重身份验证解决方案
注意
目前，攻击者绕过基于文本消息的多重身份验证的成本相对较低，因此请关注无密码和更强的多重身份验证。
有关详细信息，请参阅 Azure 安全基准 ID-4：对所有基于 Azure Active Directory 的访问使用强身份验证控制。
7. 技术：集成原生防火墙和网络安全性
简化针对网络攻击的系统和数据保护。
对象
通过将 Azure 防火墙、Azure Web 应用程序防火墙 (WAF) 和分布式拒绝服务 (DDoS) 缓解集成到网络安全方法中，简化网络安全策略和维护。
原因
简洁对于安全性至关重要，因为它可以减少混乱、配置错误和其他人为错误带来的风险。 请参阅“简化”安全原则。
防火墙和 WAF 是重要的基本安全控制措施，可保护应用程序免受恶意流量的影响，但其设置和维护可能会很复杂，会占用安全团队大量的时间和精力（类似于为汽车添加定制的售后零部件）。 Azure 的原生功能可简化防火墙、Web 应用程序防火墙、分布式拒绝服务 (DDoS) 缓解等功能的实现和操作。
此做法可以使团队腾出时间和精力来完成更有价值的安全任务，如：
- 评估 Azure 服务的安全性
- 自动执行安全操作
- 将安全功能与应用程序和 IT 解决方案集成
谁
- 发起：安全领导或 IT 领导通常发起网络安全策略更新。
- 执行：将策略集成到云网络安全策略是一项协同工作，涉及：
方式
对于要简化运营的组织而言，有两个选项可供选择：
- 扩展现有功能和体系结构：许多组织通常选择扩展现有防火墙功能的使用，以便将现有投资转向技能和流程整合中，尤其是在首次采用云时。
- 采取原生安全控制措施：更多组织开始倾向采取原生控制措施来避免集成第三方功能带来的复杂性。 这些组织通常会设法避免负载均衡、用户定义的路由、防火墙或 WAF 本身配置错误以及不同技术团队之间延迟移交带来的风险。 对于采用基础结构即代码方法的组织而言，此选项极具吸引力，因为内置功能比第三方功能更容易实现自动执行和检测。
有关 Azure 原生网络安全功能的文档可在以下位置找到：
Azure 市场包括许多第三方防火墙提供商。
有关详细信息，请参阅 Azure 安全基准 ns-4：保护应用程序和服务不受外部网络攻击。
8. 技术：集成原生威胁检测
简化对 Azure 系统和数据的攻击检测和响应。
对象
通过将原生威胁检测功能合并到安全运营和 SIEM 中，简化威胁检测和响应策略。
原因
安全运营的目的是降低访问环境的主动攻击者对环境造成的影响。 这种影响由平均确认时间 (MTTA) 和平均修正时间 (MTTR) 事件来度量。 此做法要求事件响应的所有元素都能快速且准确。 成果有助于确保将工具质量和流程执行效率放在首位。
使用现有工具和方法很难进行重大威胁检测。 因为云技术的差异和它的瞬息万变，这些工具和方法都旨在用于本地威胁检测。 原生集成的检测提供工业级解决方案，这些解决方案由云提供商维护，能够与当前威胁和不断变化的云平台保持同步。
这些原生解决方案使安全运营团队能够专注于事件调查和修正。 他们可以专注于这些内容，而不是浪费时间针对不熟悉的日志数据、集成工具和维护任务创建警报。
谁
通常由安全运营团队推动。
- 发起：此项工作通常由安全运营总监或同等职能人员发起。
- 执行：集成原生威胁检测是一项协同工作，涉及以下解决方案：
方式
为使用的所有资源启用 Microsoft Defender For Cloud 中的威胁检测，并使每个团队按上面所述将这些资源集成到其流程中。
有关详细信息，请参阅 Azure 安全基准 LT-1：为 Azure 资源启用威胁检测。
9. 体系结构：实现单一目录和标识标准化
没人愿意处理多个标识和目录。
对象
实现单一 Azure AD 目录标准化。 可以为 Azure 中的每个应用程序和用户实现单一标识标准化。
注意
此最佳做法专门针对企业资源。 对于合作伙伴帐户，请使用 Azure AD B2B，这样便无需在目录中创建和维护帐户。 对于客户/公民帐户，请使用 Azure AD B2C 进行管理。
原因
多个帐户和标识目录会引起不必要的摩擦。 这种摩擦会给以下人员的日常工作流带来混乱：
- 生产力用户
- 开发人员
- IT 和标识管理员
- 安全分析师
- 其他角色
管理多个帐户和目录会导致出现不良的安全做法。 这些做法包括在各种帐户中重用密码等。 这会增加攻击者对过时或弃用帐户发起攻击的可能性。
尽管有时能够更轻松地快速为特定应用程序或工作负载创建自定义 LDAP 目录，但此操作会造成更多的集成和管理工作量。 此操作类似于选择额外设置一个 Azure 租户或本地 Active Directory 林，而不是使用现有的企业租户。 有关详细信息，请参阅简化的安全原则。
谁
实现单一 Azure AD 目录标准化通常需要多个团队协作。 这项工作由安全体系结构团队或标识和密钥管理团队推动。
方式
采用务实的方法，从全新的“绿色地带”功能开始。 然后，作为后续练习，解决现有应用程序和服务的“棕色地带”：
绿色地带：建立并实现一个明确的策略，即所有企业标识使用一个 Azure AD 目录，每个用户使用一个帐户。
棕色地带：许多组织通常具有多个旧的目录和标识系统。 如果持续管理摩擦的成本超出消除摩擦的资金投入，则解决这些旧项目的问题。 尽管标识管理和同步解决方案可以缓解其中一些问题，但它们缺乏安全功能和生产力功能的深度集成。 这些功能可以为用户、管理员和开发人员提供无缝体验。
应用程序开发周期的以下阶段最适合结合使用标识：
- 实现面向云的应用程序现代化。
- 使用 DevOps 流程更新云应用程序。
尽管有正当理由针对独立业务部门或监管要求创建单独的目录，但在其他所有情况下都应避免使用多个目录。
有关详细信息，请参阅 Azure 安全基准 ID-1：将 Azure Active Directory 标准化为中央标识和身份验证系统。
10. 体系结构：使用基于标识的访问控制，而不是密钥。
对象
尽可能使用 Azure AD 标识，而不是基于密钥的身份验证（Azure 服务、应用程序、API 等）。
原因
基于密钥的身份验证可用于向云服务和 API 进行身份验证。 但是，它要求安全地管理密钥，要做到这一点很难，尤其在大规模情况下。 对于非安全专业人员（如开发人员和基础结构专业人员）而言，安全密钥管理十分困难，他们常常无法实现安全管理，因而时常给组织带来重大的安全风险。
基于标识的身份验证借助其成熟的功能解决了许多这样的问题。 这些功能包括密钥轮换、生命周期管理、管理委派等。
谁
基于标识的访问控制实现通常需要多个团队协作完成。 这项工作由安全体系结构团队或标识和密钥管理团队推动。
方式
若要为组织设置使用基于标识的身份验证的偏好和习惯，需要遵循流程并借助技术来完成。
此过程
- 建立策略和标准，明确概述默认的基于标识的身份验证和可接受的例外。
- 为开发人员和基础结构团队提供培训，介绍为何要使用新方法、为此他们需要做什么以及如何做。
- 以务实的方式实现变更，即开始使用现在及未来会采用的“绿色地带”新功能（新的 Azure 服务、新应用程序），然后在后续清理掉“棕色地带”现有配置。
- 监视合规性，并由开发人员和基础结构团队跟进以修正。
技术
对于非人为帐户（如服务或自动化），请使用托管标识。 Azure 托管标识可以向支持 Azure AD 身份验证的 Azure 服务和资源进行身份验证。 通过预定义的访问授权规则启用身份验证，避免在源代码或配置文件中使用硬编码凭据。
对于不支持托管标识的服务，则请使用 Azure AD 在资源级别创建权限受限的服务主体。 建议使用证书凭据配置服务主体，并回退到客户端机密。 在这两种情况下，都可以将 Azure Key Vault 与 Azure 托管标识结合使用，以便运行时环境（例如 Azure 函数）可以从密钥保管库中检索凭据。
有关详细信息，请参阅 Azure 安全基准 ID-2：安全且自动地管理应用程序标识。
11. 体系结构：建立一个统一的安全策略
大家劲往一处使，工作才能取得成功。
对象
确保所有团队都遵循一个策略，实现并确保企业系统和数据安全。
原因
如果团队之间没有遵循共同策略而各自开展工作，则团队的行为会在无意之中对另一团队产生不利影响。 未遵循一个策略可能会导致不必要的摩擦，这种摩擦会影响每个人的目标实现进度。
团队各自开展工作在许多组织内司空见惯，其中一个例子就是资产分段：
- 网络安全：制定用于对平面网络进行分段的策略。 该策略通常基于物理站点、分配的 IP 地址/范围或类似项，可增强安全性。
- 标识团队：基于对组织的理解和知识，为组和 Active Directory 组织单位 (OU) 制定策略。
- 应用程序团队：发现很难与这些系统合作。 合作很困难，是因为系统设计时对业务运营、目标及风险缺乏足够的投入和理解。
当组织中出现这种限制时，团队常常会遭遇防火墙例外冲突。 这种冲突会对安全性产生负面影响，因为团队会批准例外情况。 生产力会对安全性产生负面影响，因为它会减慢部署业务所需的应用程序功能。
尽管安全性会带来积极正面的摩擦，推动批判性思维的产生，但这种冲突只会引发消极负面的摩擦，妨碍目标的实现。 有关详细信息，请参阅安全策略指导：恰当的安全摩擦程度。
谁
- 发起：统一策略通常由 CIO、CISO 和 CTO 共同发起。 发起通常获得了业务领导对某些高级别元素的支持，由每个团队的代表监督执行。
- 执行：所有人都必须实现安全策略。 它集成了各个团队的数据，可强化归属权，提高认可度和成功的可能性。
方式
构建并实现云安全策略，所有团队都投入并积极参与。 尽管流程文档格式可能各不相同，但它始终涉及：
- 团队积极投入：如果组织中的人员没有认可策略，那么策略通常会失败。 理想情况下，召集所有团队一同构建策略。 在我们与客户进行的研讨会上，我们经常发现组织实际上处于运营孤岛状态，在这些会议上，人们往往第一次见面。 我们发现实现包容性刻不容缓。 如果某些团队未被邀请，常常要反复举行会议，直到所有参与者加入会议为止。 如果他们没有加入，则项目不会有进展。
- 明确记录并清晰传达：所有团队都必须对安全策略有所认识。 理想情况下，安全策略是总体技术策略的安全组成部分。 此策略包含集成安全性的原因、安全性的重要因素以及安全性的结果。 此策略包含专门针对应用程序和开发团队的指导，这样他们可以获得清晰、有序的指导，而无需通读不相关的信息。
- 稳定但灵活：保持策略相对一致和稳定，但体系结构和文档可能需要更加清晰明了并适应云的动态特性。 例如，即使从使用第三方下一代防火墙转到使用 Azure 防火墙并调整关系图和操作指南，筛选出恶意外部流量仍旧是一项需要保持一致的战略目标。
- 从分段开始：在采用云的过程中，团队将处理大大小小许多策略问题，但需要将某个位置作为切入点。 建议从企业资产分段开始实现安全策略。 此分段是一项基本决策，以后很难对其进行更改，它需要业务投入和许多技术团队的参与。
Microsoft 已发布有关将分段策略应用于 Azure 的视频指导。 已发布有关企业分段和协调网络安全的文档。
云采用框架提供的指南可帮助你的团队：
- 构建云策略团队：理想情况下，将安全性集成到现有的云策略中。
- 构建或实现安全策略现代化：满足目前云服务和新式威胁的业务和安全目标。
有关详细信息，请参阅 Azure 安全基准治理和策略。