安全成熟度模型

建立最低可行的安全态势，作为进一步构建的基础。

成熟度模型的级别 1 可帮助工作负荷团队实现坚实的安全基础，以便在整个工作负荷生命周期内扩展和改进这些基础。 此基础称为 安全基线，可捕获需要实现的最低安全要求和期望。 将基线定位在明确定义的成熟行业标准和监管框架指南中。

基线应为工作负载的架构设计提供指导。 它应指示在何处实现安全机制以及这些机制如何与其他工作负荷组件交互。 基线不仅应影响安全工具，还应影响围绕工作负载操作的标准化流程，包括 DevOps 做法。 默认情况下，编码做法（如输入验证和输出编码）必须内置安全进程。 定期执行代码评审和自动安全扫描。

关键策略

• 将基线安全性集成到软件开发生命周期（SDLC）的开发阶段

在开始实施工作负载的开发阶段时，标准化与您的安全基线要求一致的做法。 这些做法应包括定期进行的代码评审和自动安全扫描、输入验证和输出编码。 有关最佳做法的详细信息，请参阅 在 Azure 中开发安全应用程序。

• 将标识和访问管理外部化到标识提供者（IdP）

随着工作负荷开发的进展，标识和访问管理可能会很快变得复杂而繁重。 使用 IdP（如 Microsoft Entra）通过严格控制对工作负荷组件的访问和使用非人身份（如托管标识）来帮助维护安全标准。

IdP 还通过多重身份验证和详细的访问日志增强了安全性和合规性。 这些功能简化了用户交互，同时减轻了作负担。

• 观察密钥标识的访问模式并应用适当的安全级别

实施您的 IdP 解决方案时，花一些时间观察您工作团队的访问行为。 了解用户如何访问不同的工作负荷组件，以便可以确定要授予的适当访问权限级别。 寻找机会，用托管标识替代人类在流程（如部署和数据库更改）中的参与。 如果人工帐户需要访问敏感资源，请标准化实时访问作为默认机制。

折衷： 采用这些访问策略时可能会遇到阻力。 某些用户可能会认为这些策略会降低其工作速度。 确保所有工作负荷团队成员都了解安全性是每个人的责任，并实施强大的访问控制有助于每个人维护安全的工作负荷。

✓ 对静态数据加密

保护静态数据，以帮助确保数据保密性和完整性，这是现代安全性的两个基石。 使用强加密，对数据存储应用严格的访问控制。 默认情况下，Azure 会在基础硬件级别加密所有数据存储。 但是，你可以对工作负荷数据实施加密，以添加额外的安全措施。 使用内置机制在虚拟机（VM）磁盘、存储帐户和数据库上配置加密，使设计保持简单。

折衷： 可以将自己的密钥（BYOK）引入许多 Azure 服务，而不是使用Microsoft管理的密钥。 BYOK 提供对资源的更多控制，并可能满足法规要求。 但 BYOK 增加了操作负担，因为你必须管理密钥轮换。 如果丢失密钥，则可能会失去对数据的访问权限。

• 加密传输中的数据

保护传输中的数据，以帮助保护工作负荷免受可能访问数据和系统的攻击者的攻击。 如果不使用加密或使用弱密码，攻击者可以截获数据。 请勿在任何组件中使用传输层安全性 （TLS） 版本 1.1 或更高版本。 迁移旧版本，使 TLS 1.2 成为所有系统的默认版本。 跨网络或 Internet 发送数据的所有 Azure 服务都使用 TLS 1.2。

• 保护应用程序机密

应用程序机密是有助于在工作负荷组件之间进行通信的机密组件，包括密码、API 密钥以及用于身份验证和资源访问的证书等敏感数据。 正确管理这些机密，以维护安全性和完整性。 不当处理可能导致数据泄露、服务中断、法规违规和其他问题。 使用 Azure Key Vault 等解决方案安全地管理机密。

加强部署安全性，并在工作负荷基础结构中建立威胁防护措施”。

在安全支柱的第 2 级中，您将在基线安全配置基础上构建，以进一步降低部署工作负载过程中的潜在威胁。 此阶段强调加强部署实践、为代码资产和工作负荷组件制定维护计划、开发数据分类框架、保护网络入口点和强化工作负荷组件，这一切都是增强整体安全态势的必要步骤。

权衡：保护 SDLC 是一个迭代过程，需要采用新流程，有时开发人员需要转变思维模式。 对部署应用控制可能会令开发人员感到沮丧，因此有助于培养共同负责安全的文化。 虽然可能会降低开发速度，但保护部署可让你的团队长期取得成功。 这些措施可帮助你安全地构建工作负荷，并使其可供作使用，同时保持坚实的安全态势。

关键策略

✓ 确保 SDLC 的部署阶段安全

安全支柱级别 1 侧重于保护 SDLC 的开发阶段。 级别 2 假设你为开发阶段建立了基线安全措施，并且你已准备好部署工作负荷或工作负荷组件的第一次迭代。

在此阶段，重点构建部署自动化，以优化效率和安全性。 使用如 Azure Pipelines 或 GitHub Actions 的部署管道，并规范化使用这些管道处理所有工作负载变更。 定期执行良好的代码卫生做法，以确保你的代码库没有缺陷和可能带来风险的代码。 最后，您的团队需要熟悉Microsoft 安全开发生命周期。 随着工作负荷的发展，请定期重新访问本指南中的建议，以确保 SDLC 保持针对安全性的优化。

权衡： 确保 SDLC 的安全是一个迭代过程，需要你采用新流程，有时开发人员也需要转变思维模式。 对部署应用控制可能会令开发人员感到沮丧，因此有助于培养共同负责安全的文化。 保护部署可能会降低开发速度，但它为团队的长期成功奠定基础。

• 制定维护计划

在安全上下文中，维护计划是指你采用的标准做法，在整个生命周期内维护代码和工作负荷组件的安全性。 生成机制和流程来处理部署管道中的紧急修复。 例如，您可以通过团队间直接沟通与快速回滚、前滚计划，借助质量门提高部署速度。

在标准进程中包括软件、库和基础结构修补，以确保工作负荷的所有组件始终是最新的。 保留版本化资产目录，以在事件响应、问题解决和系统恢复期间提供帮助。 还可以使用自动化将这些版本与常见漏洞和暴露程序中的已知漏洞进行比较。

• 根据敏感度需求对数据进行分类

采用数据分类系统及其支持流程来帮助确保保持保密性和完整性。 从公共、常规、机密和高度机密等广泛类别开始，并应用适当的安全级别来保护整个数据存储中的这些类别。 考虑投资 Microsoft Purview 等工具来管理数据。 有关详细最佳做法，请参阅Microsoft合规性文档中 的数据分类指南 。

权衡：即便使用了工具，数据分类在成本和精力方面仍可能是项代价高昂的工作。 创建初始类别并执行初始分类练习后，请确定手动或工具持续维护所涉及的工作量。 请务必在估算中考虑训练的时间和成本。

• 应用授权和身份验证控制

作为 IdP 解决方案实现的一部分，可以开始应用与授权和身份验证相关的控制。 使用基于角色的访问控制，通过基于用户角色对资源应用精细权限来帮助限制对工作负荷组件的访问。 根据最低访问权限原则应用这些权限。

使用条件访问策略进一步增强控制。 这些策略根据用户地理位置等特定条件授予或拒绝对资源的访问权限，或者用户设备是否符合安全策略。 还可以利用实时访问等功能来锁定对敏感组件的访问。

风险： 管理帐户是环境中最重要的攻击途径之一。 在仔细考虑需求以及它们如何与 特权帐户最佳做法保持一致后，才应创建和使用它们。 如果攻击者控制管理帐户，则整个环境可能面临严重风险。

• 保护网络入口

尽可能切实地保护网络入口，以提高整体安全态势。 安全网络入口是针对外部攻击者的第一道防线。 云提供商可能具有可在特定环境中使用的各种工具，但请务必了解工作负荷中的所有可能的入口点。 可以将防火墙添加到虚拟网络或其子网，例如 Azure 虚拟网络中的网络安全组。 如果使用 Azure SQL 数据库等平台资源，则可以在资源本身的配置中限制或禁用公共和专用访问。 同样，在实际范围内限制或禁用对虚拟机的任何直接访问。

一般情况下，选择本机防火墙或合作伙伴防火墙来控制工作负荷的所有入口。 还可以使用内置于负载均衡解决方案（例如 Azure Front Door）或 API 网关（例如 Azure API 管理）中的 Web 应用程序防火墙。

权衡：防火墙解决方案可能会大幅增加工作负载成本，尤其是在配置过度的情况下。 确保调查适合您场景的最佳解决方案，并确保可以从小做起，并随着工作负荷的变化而扩展，以控制成本。

• 强化攻击面

强化工作负荷是一个需要持续改进的迭代过程。 警惕和分析工作负载是否存在漏洞。 随着工作负荷的成熟，请使用漏洞扫描工具来帮助你轻松识别易受攻击的组件。 在开发早期，手动执行加固操作可能是更优策略。 查看组件的配置，查找潜在的弱点，例如配置不当或未配置的防火墙规则或不当权限。 检查是否存在未使用或不必要的组件以便关闭或移除，同时停用未使用的帐户。

通过全面的评估和响应功能主动识别和缓解安全威胁。

在成熟度模型的级别 3 中，应将高级流程和机制集成到工作负荷中，以主动识别和缓解安全威胁。 威胁建模、网络流分类和高级加密技术等策略基于你已具备的基础机制构建了额外的准备级别。 事件响应计划可统一威胁检测和缓解策略，同时标准化管理安全事件的方式。

关键策略

• 将威胁建模纳入软件开发生命周期（SDLC）

威胁建模是一种工程技术，可用于帮助识别可能影响工作负荷的威胁、攻击、漏洞和对策。 可以使用威胁建模来塑造工作负荷的设计，满足公司的安全目标，并降低风险。 执行威胁建模练习时，请包括以下策略：

• 验证工作负荷安全要求。 在工作负载开发初期完成收集和编编工作负荷安全要求的过程。 在级别 3 中，将要求作为威胁建模练习的初步步骤进行验证。

• 验证工作负荷体系结构关系图。 在工作负荷开发和实现过程中，应提前完成包含流的体系结构关系图。 在第三级，您应该重新审查设计以确保其满足客户要求。

• 识别潜在威胁。 从外部角度分析每个组件的潜在威胁。 确定攻击者如何利用特定资源来获取进一步的访问权限。 根据 STRIDE 等行业标准方法对威胁进行分类，以帮助你了解每个威胁的性质并应用适当的安全控制。

• 规划缓解策略。 确定潜在威胁后，开始构建缓解计划以增强强化设计。 在团队待办事项中包括这些缓解策略进行跟踪。

• 使用威胁建模工具。 使用 Microsoft威胁建模工具等工具 使练习更高效，并标准化方法和报告过程。

折衷： 威胁建模是一项密集的练习，可能会降低开发速度。 在开发计划中考虑这些额外的工作量。

• 对网络流量流进行分类

若要对网络流量流进行分类，请首先检查工作负荷体系结构的示意图，以了解流的意图和特征。 考虑流的网络特征，例如协议和数据包详细信息以及任何符合性要求。 根据流程在外部网络中的可见性进行分类。 区分公共工作负荷和专用工作负荷。 实施负载均衡器或防火墙等安全措施来保护关键流。

• 使用高级加密策略

查看合规性要求并重新评估加密配置，以确定如何使用高级加密策略增强设计。 例如，你可能要求 使用双重加密，或者可能需要 管理加密密钥。

如果需要管理自己的密钥，请使用密钥管理服务来降低丢失密钥或无法根据要求轮换密钥的风险。 确定哪种服务最适合 你的用例。

折衷： 使用双重加密或管理自己的密钥会增加工作负荷的成本和运营负担。 在实施这些策略之前，请务必研究这些策略以满足你的特定要求。

• 实现系统审核

为保持系统完整性，应维护系统状态的准确与最新记录，以便及时处理问题。 跟踪资源创建和解除授权、监视配置更改，并确保日志捕获更改的具体信息和时间。 此外，维护修补过程的综合视图，检测作系统中的更改，并针对意外更改设置警报。

• 生成事件响应计划

创建事件响应计划，以便快速检测和响应潜在和有效的安全泄露。 该计划应包括以下注意事项：

• 明确工作负载团队中事件的责任人。 工作负荷团队中的一个或多个个人应负责接收警报通知，并与会审团队协作，以有效地响应事件。

• 调查和会审过程。 确定合适的沟通方式，例如使用异步更新还是桥接通话。 仅限必要的人员参与，以便集中精力解决眼前的问题。 确保保持有关工作负荷的体系结构关系图和其他文档的当前状态，以确保团队能够高效地工作。

• 从事件中恢复。 处理安全事件（如灾难），并将事件响应计划与业务连续性和灾难恢复（BCDR）计划保持一致。 在重新引入已泄露的组件之前，通过缓解问题来最大程度地减少重复的风险。

• 从事件中学习。 执行事件后评审，也称为 事后验尸，以寻找改进机会。 在规划中预留出实施改进的时间，并将改进措施纳入业务连续性和灾难恢复演练。

• 与最终用户和利益干系人沟通。 在处理事件时，确保用户和相关方随时了解最新情况。 定义正确的通信通道和发送更新的节奏。

折衷： 调查、缓解和恢复过程可能会影响可靠性目标。 在事件发生期间，可能需要禁用系统的各个部分。 此方法可能会影响功能或非功能要求。 业务决策者必须在事件期间确定可接受的恢复目标。

根据生产见解和作数据优化安全控制。

在第4级，你的工作负荷在生产环境中应已运行足够长的时间，以便收集有关正常操作条件的有用数据。 出于安全目的，应具有可观测性数据，包括审核日志、漏洞扫描报告、防火墙日志、组件使用模式、事件报告和其他数据点，你可以分析这些数据点以获取改进机会。 规范对安全机制的定期评审，以帮助优化工作负荷安全性，并强化持续改进思维模式。

在优化安全机制时，请遵循成熟的变更管理做法，确保安全执行所有更改，并保持可审核性。

关键策略

• 不断重新访问和优化安全基线

作为运营持续改进实践的一部分，请定期查看安全基线并寻找改进机会。 使用新功能或技术增强工作负荷时，可能会引入新的安全漏洞。 因此，保持基线最新是一个必要的并行任务。 此外，随着团队的安全专业知识的增长，你可能会发现可以优化基线配置，以进一步加强安全态势。

使用像 Azure Policy 和 Microsoft Defender for Cloud 这样的自动化安全治理工具，以使资源更有效地符合您的基线标准。

• 优化安全监视策略

使用生产数据分析改进安全监控和警报。 首次实现资源审核、漏洞扫描或其他安全监视时，可能已遵循记录级别、保留策略或其他设置的通用方法。 使用在生产中收集的数据根据符合组织标准的使用模式来优化这些设置。 随着工作负荷的发展，持续查看安全监视和警报实现，以确保正确配置所有资源。

• 在边缘加强网络安全

通过应用微分段来增强网络安全，以防止跨工作负荷横向移动。 此策略可能包括将组件移到受网络安全组保护的单独子网中，或使用特定资源的内置功能来限制流量。 例如，许多 Azure 数据库服务包括一个内置防火墙，可用于限制公共和专用网络访问。 请考虑以下策略：

• 仅在工作负荷中使用专用网络。 在 Azure 中，尽可能使用 Azure 专用链接将虚拟网络连接到平台即服务和软件即服务资源。 有关详细信息，请参阅 服务可用性。

• 保护 API。 使用 API 网关解决方案（如 Azure API 管理）来代理 API 调用。 使用代理可最大程度地减少对后端 API 的网络访问，因为它仅向调用方公开代理，而不公开后端组件。

• 优化防火墙规则。 根据生产观察查找机会来优化防火墙规则。 在开发早期实施的一些宽泛规则可以收紧，或者清理掉未使用的规则。 同样，新的威胁和漏洞不断出现，这使得定期更新对网络安全至关重要。 为防火墙配置定义标准评审过程，作为持续改进做法的一部分，以便定期查看和更新设置。

折衷： 微分类配置和 API 网关可增加工作负荷的成本和复杂性。 请谨慎应用这些措施，以避免不必要的费用和运营开销。 例如，非生产环境或内部工作负荷可能不需要这些度量值。

• 优化 IAM 配置

分析访问模式，以确定 IAM 配置中的改进区域。 将条件访问和实时 （JIT） 访问控制应用于敏感组件。 查看所有人和非人类帐户的权限，以确保正确强制实施最低权限原则。 托管标识经常存在权限配置错误，应将其纳入权限审计。 作为操作实践的一部分，定期执行这些审核。

折衷： 条件访问和 JIT 访问策略需要持续管理，并且可能需要用户培训。 在实现用例之前，请确保它们适合你的用例。

• 优化事件响应计划

在生产环境中运行工作负荷之前，无法完全模拟安全事件。 实际事件提供了有价值的见解，有助于改进响应流程。 让所有参与事件响应的团队成员参加回顾性学习会，以确定哪些方面做得好，以及哪些方面需要改进。 将这些见解纳入事件演练，使其更加现实。

战略投资企业级安全解决方案和高级威胁防御功能。

成熟度模型的级别 5 侧重于高度成熟的组织的高级安全措施。 请仔细考虑以下每条针对 Well-Architected 框架的其他支柱的建议，以确保它们与工作负荷保持一致。 你应该清楚地了解合规性要求、组织标准、工作负荷生命周期计划和其他独特的环境因素，以告知决策。

关键策略

• 投资专用威胁防护

大型组织和特定行业更有可能成为专用威胁的目标。 若要缓解这些风险，请评估是否应投资更高级别的保护。 请考虑你的用例是否值得投资以下解决方案：

• 分布式拒绝服务 （DDoS） 保护。 具有大型公共状态的组织是 DDoS 攻击的最常见目标。 Azure 等云提供商通常包括免费的基本级别 DDoS 保护，这些保护足以满足许多用例。 它们通常还提供高级层，用于抵御更大、更复杂的攻击，并提供更高级别的待命支持，以帮助缓解正在进行的攻击。

• 自动数据丢失防护（DLP）。 DLP 是一种安全策略，用于识别、监视和保护敏感数据免受未经授权的访问、滥用或意外泄露。 处理大量敏感信息的组织（如金融机构、医疗保健提供商和政府机构）从 DLP 中获益匪浅，以维护数据完整性并遵守法规。 请考虑使用 Microsoft Purview 等工具自动执行 DLP 策略。

• 使用机密计算保护正在使用的数据。 默认情况下，云提供商通常会加密静态和传输中的数据。 为了进一步增强安全性，请使用机密计算解决方案保护正在使用的数据。 此解决方案对于政府实体的医疗保健和金融等受监管行业尤其重要。 Azure 提供机密 虚拟机、容器服务和其他平台即服务和软件即服务解决方案。 借助这些解决方案，可以安全地处理敏感数据，同时防止暴露未经授权的用户或系统并满足合规性要求。

• 投资 SIEM 和 SOAR 解决方案

SIEM 和 SOAR 解决方案（如 Microsoft Sentinel），自动执行异常行为检测、威胁搜寻和各种响应活动。 这些解决方案通过跨大型复杂环境管理数据收集和分析，显著减轻了运营负担，尤其是对于大型组织而言。 Microsoft Sentinel 为许多Microsoft产品提供内置支持。 此支持可确保无缝集成。

• 投资高级安全测试

在早期成熟度级别，可以标准化安全测试，包括网络、标识和应用程序评估。 在级别 5，考虑投资模拟攻击测试，如战争游戏演习和渗透测试。 在某些情况下，可能需要与非Microsoft供应商联系以执行渗透测试或其他安全测试以满足合规性要求。 研究和评估信誉良好的供应商，确保它们为你的组织提供最佳价值。