通过

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

Azure 上关键工作负荷的安全注意事项

  • 项目

安全性是基础设计原则之一，也是一个关键设计领域，必须被视为任务关键型体系结构过程中的一流关注点。

鉴于任务关键型设计的主要重点是最大程度地提高可靠性，使应用程序保持高性能和可用状态，因此在此设计区域内应用的安全注意事项和建议将侧重于通过影响可用性和阻碍整体可靠性的能力来缓解威胁。 例如，已知成功的拒绝服务（DDoS）攻击会对可用性和性能产生灾难性影响。 应用程序如何缓解这些攻击途径，例如 SlowLoris 将影响整体可靠性。 因此，应用程序必须完全防范旨在直接或间接损害应用程序可靠性的威胁，才能在本质上真正具有关键任务。

此外，请务必注意，通常存在与强化安全状况相关的重大权衡，尤其是在性能、运营敏捷性和在某些情况下的可靠性方面。 例如，对于下一代防火墙（NGFW）功能，包括内联网络虚拟设备（NVA），例如深度数据包检查，将带来显著的性能损失、额外的操作复杂性，以及如果可伸缩性和恢复操作与应用程序不紧密一致，将带来可靠性风险。 因此，为了缓解关键威胁途径而制定的其他安全组件和做法也旨在支持应用程序的可靠性目标，这将构成本部分中提供的建议和注意事项的关键方面。

重要

本文是 Azure 架构良好的任务关键型工作负荷系列的一部分。 如果不熟悉此系列，我们建议从什么是任务关键型工作负荷开始 ？

GitHub 徽标任务关键型开放源代码项目

参考实现是 GitHub 上提供的开放源代码项目的一部分。 代码资产采用零信任模型来构建和指导安全设计和实现方法。

与零信任模型对齐

Microsoft零信任模型提供了一种主动和集成的方法，用于在应用程序的所有层中应用安全性。 零信任的指导原则旨在明确和持续验证每个事务、断言最低特权、使用智能和高级检测来近乎实时地应对威胁。 它最终以消除应用程序外围内外的信任为中心，强制验证尝试连接到系统的任何内容。

设计注意事项

评估应用程序的安全状况时，请从这些问题开始，作为每个注意事项的基础。

  • 持续安全测试，以验证关键安全漏洞的缓解措施。

    • 安全测试是否作为自动化 CI/CD 过程的一部分执行？
    • 否则，执行特定安全测试的频率是多少？
    • 是否根据所需的安全状况和威胁模型测量测试结果？

  • 所有较低环境的安全级别。

    • 开发生命周期中的所有环境是否都具有与生产环境相同的安全状况？

  • 如果发生故障，身份验证和授权连续性。

    • 如果身份验证或授权服务暂时不可用，应用程序能否继续操作？

  • 自动化安全合规性和修正。

    • 是否可以检测到对密钥安全设置的更改？
    • 是否自动修正不符合的更改？

  • 在提交代码之前，机密扫描可检测机密，以防止通过源代码存储库泄露任何机密。

    • 在不使用凭据作为代码的一部分的情况下，是否可以向服务进行身份验证？

  • 保护软件供应链。

    • 是否可以跟踪已利用的包依赖项中的常见漏洞和暴露情况？
    • 是否有用于更新包依赖项的自动化过程？

  • 数据保护密钥生命周期。

    • 服务管理的密钥是否可以用于数据完整性保护？
    • 如果需要客户管理的密钥，安全和可靠的密钥生命周期如何？

  • CI/CD 工具应要求Microsoft具有足够订阅级别访问权限的 Entra 服务主体，以便对所有已考虑的环境订阅进行 Azure 资源部署的控制平面访问。

    • 当应用程序资源锁定在专用网络中时，是否存在专用数据平面连接路径，以便 CI/CD 工具可以执行应用程序级部署和维护。
      • 这引入了额外的复杂性，并且需要通过必要的专用生成代理在部署过程中执行序列。

设计建议

  • 使用 Azure Policy 为所有服务强制实施安全性和可靠性配置，确保控制平面在配置时纠正或禁止任何偏差，帮助缓解与“恶意管理员”场景相关的威胁。

  • 在生产订阅中使用 Microsoft Entra Privileged Identity Management (PIM) 撤销对生产环境的持续控制平面访问。 这将通过额外的“检查和平衡”来显著降低“恶意管理员”方案带来的风险。

  • 将 Azure 托管标识 用于支持该功能的所有服务，因为它有助于从应用程序代码中删除凭据，并消除服务到服务通信的标识管理操作负担。

  • 使用 Microsoft Entra 基于角色的访问控制 (RBAC) 对支持该功能的所有服务进行数据平面授权。

  • 使用应用程序代码中的第一方Microsoft 标识平台身份验证库与 Microsoft Entra ID 集成。

  • 如果所选的标识平台不可用或仅部分可用于应用程序授权，请考虑安全令牌缓存，以允许降级但可用的体验。

    • 如果提供程序无法颁发新的访问令牌，但仍会验证现有访问令牌，则应用程序和依赖服务可以在令牌过期之前运行，而不会出现问题。
    • 令牌缓存通常由身份验证库（如 MSAL）自动处理。

  • 使用基础结构即代码（IaC）和自动化 CI/CD 管道来驱动所有应用程序组件的更新，包括故障情况下。

    • 确保将 CI/CD 工具服务连接作为关键敏感信息进行保护，且不应将其直接提供给任何服务团队。
    • 将精细的 RBAC 应用于生产 CD 管道以缓解“恶意管理员”风险。
    • 考虑在生产部署管道中使用手动审批入口来进一步缓解“恶意管理员”风险，并为所有生产更改提供额外的技术保证。
      • 在敏捷性方面，其他安全门可能会受到权衡，应仔细评估，同时考虑到即使使用手动入口，也可以保持敏捷性。

  • 为所有较低环境定义适当的安全态势，以确保缓解关键漏洞。

    • 不要应用与生产相同的安全状况，特别是在数据外泄方面，除非法规要求规定需要这样做，因为这将大大损害开发人员的灵活性。

  • 为包含任务关键型工作负载资源的所有订阅启用 Microsoft Defender for Cloud（以前称为 Azure 安全中心）。

    • 使用 Azure Policy 强制实施合规性。
    • 为所有支持该功能的服务启用 Azure Defender。

  • 在 CI/CD 管道中接受 DevSecOps 并实现安全测试。

    • 应根据合规的安全状况来衡量测试结果，以通知发布审批，是自动化的还是手动的。
    • 在每个版本的 CD 生产过程中应用安全测试。
      • 如果每个版本的安全测试危及运营敏捷性，请确保应用适当的安全测试节奏。

  • 在源代码存储库中启用 机密扫描 和依赖项扫描。

威胁建模

威胁建模提供基于风险的安全设计方法，使用识别的潜在威胁来开发适当的安全缓解措施。 有许多可能的威胁具有不同的发生概率，在许多情况下，威胁可以以意外、不可预知甚至混乱的方式链接在一起。 这种复杂性和不确定性是为什么传统的基于技术要求的安全方法基本上不适合任务关键型云应用程序。 预计任务关键型应用程序的威胁建模过程会复杂且不屈不挠。

为了帮助应对这些挑战，应应用分层防御深度方法来定义和实施模型威胁的补偿缓解措施，考虑以下防御层。

  1. 具有基本安全功能和控制功能的 Azure 平台。
  2. 应用程序体系结构和安全设计。
  3. 内置、已启用且可部署的安全功能已应用于保护 Azure 资源。
  4. 应用程序代码和安全逻辑。
  5. 操作过程和 DevSecOps。

注意

在 Azure 登陆区域内部署时，请注意，登陆区域实现通过预配集中安全功能提供额外的威胁缓解层。

设计注意事项

STRIDE 提供轻量风险框架，用于评估关键威胁向量的安全威胁。

  • 欺骗标识：模拟具有权威的个人。 例如，攻击者使用他们的 -
    • 标识
    • 身份验证
  • 篡改输入：修改发送到应用程序的输入，或违反信任边界来修改应用程序代码。 例如，攻击者使用 SQL 注入删除数据库表中的数据。
    • 数据完整性
    • 验证
    • 阻止列表/允许列表
  • 否认行动：能够驳斥已执行的操作，以及应用程序收集证据和推动问责的能力。 例如，删除关键数据，而无需跟踪到恶意管理员。
    • 审核/日志记录
    • 签名
  • 信息泄露：获取对受限信息的访问权限。 例如，攻击者获取对受限文件的访问权限。
    • 加密
    • 数据泄露
    • 中间人攻击
  • 拒绝服务：恶意应用程序中断以降低用户体验。 例如，DDoS 僵尸网络攻击，例如 Slowloris。
    • DDoS
    • 僵尸网络
    • CDN 和 WAF 功能
  • 特权提升：通过授权利用获得特权应用程序访问权限。 例如，攻击者操纵 URL 字符串以获取对敏感信息的访问权限。
    • 远程代码执行
    • 授权
    • 隔离

设计建议

  • 在每个冲刺 (sprint) 中分配工程预算，以评估潜在新威胁并实施缓解措施。

  • 应采取有意识的努力来确保安全缓解措施在通用工程标准中捕获，以推动所有应用程序服务团队的一致性。

  • 从服务级别威胁建模服务开始，通过在应用程序级别合并线程模型来统一模型。

网络入侵保护

防止对任务关键型应用程序和包含的数据进行未经授权的访问对于保持可用性和保护数据完整性至关重要。

设计注意事项

  • 零信任假设存在违规状态，并验证每个请求，就好像它源自不受控制的网络一样。

    • 高级零信任网络实现采用微分段和分布式入口/出口微外围。

  • 通常通过公共终结点访问 Azure PaaS 服务。 Azure 提供了用于保护公共终结点，甚至使这些终结点完全专用的功能。

    • Azure 专用链接/专用终结点使用专用 IP 地址和专用网络连接提供对 Azure PaaS 资源的专用访问。
    • 虚拟网络服务终结点提供从所选子网到所选 PaaS 服务的服务级别访问权限。
    • 虚拟网络注入为受支持的服务提供专用专用部署，例如通过App 服务环境App 服务。
      • 管理平面流量仍流经公共 IP 地址。

  • 对于受支持的服务，Azure 专用链接使用 Azure 专用终结点可解决与服务终结点关联的数据外泄风险，例如恶意管理员将数据写入外部资源。

  • 使用专用终结点或服务终结点限制对 Azure PaaS 服务的网络访问时，部署管道需要安全网络通道才能访问 Azure 资源的 Azure 控制平面和数据平面，以便部署和管理应用程序。

    • 部署在专用网络上的专用自承载生成代理 ，因为 Azure 资源可用作代理，通过专用连接执行 CI/CD 函数。 应将单独的虚拟网络用于生成代理。
      • 需要从 CI/CD 工具连接到专用生成代理。
    • 另一种方法是修改管道中资源实时的防火墙规则，以允许从 Azure DevOps 代理公共 IP 地址建立连接，并在任务完成后删除防火墙。
      • 但是，此方法仅适用于 Azure 服务的子集。 例如，这不适用于专用 AKS 群集。
    • 可以对应用程序服务跳转框执行开发人员和管理任务。

  • 完成管理和维护任务是一个需要连接到 Azure 资源数据平面的进一步方案。

  • Azure DevOps 中可以使用具有相应Microsoft Entra 服务主体的服务连接，通过 Microsoft Entra ID 应用 RBAC。

  • 可将服务标记应用于网络安全组，以便与 Azure PaaS 服务建立连接。

  • 应用程序安全组不会跨多个虚拟网络。

  • Azure 网络观察程序中的数据包捕获限制为最多 5 小时。

设计建议

  • 将公共网络访问限制为应用程序实现其业务目的所需的绝对最低访问权限，以减少外部攻击面。

  • 处理专用生成代理时，切勿将 RDP 或 SSH 端口直接向 Internet 开放。

    • 使用 Azure Bastion 提供对 Azure 虚拟机的安全访问，并通过 Internet 在 Azure PaaS 上执行管理任务。

  • 使用 DDoS 标准保护计划来保护应用程序中的所有公共 IP 地址。

  • 将 Azure Front Door 与 Web 应用程序防火墙策略结合使用，以交付和帮助保护跨多个 Azure 区域的全局 HTTP/S 应用程序。

    • 使用标头 ID 验证来锁定公共应用程序终结点，使其只接受来自 Azure Front Door 实例的流量。

  • 如果其他在线网络安全要求（如深度数据包检查或 TLS 检查）要求使用 Azure 防火墙 高级或网络虚拟设备（NVA），请确保其配置为实现最大高可用性和冗余。

  • 如果存在数据包捕获要求，请使用网络观察程序数据包进行捕获，尽管捕获窗口有限。

  • 使用网络安全组和应用程序安全组对应用程序流量进行微分段。

    • 避免使用安全设备来筛选应用程序内的流量流。
    • 请考虑使用 Azure Policy 强制实施特定的 NSG 规则始终与应用程序子网相关联。

  • 启用 NSG 流日志，并将其馈送到流量分析，便于深入了解内部和外部流量流。

  • 在应用程序设计中使用 Azure 专用链接/专用终结点（如果可用）保护对 Azure PaaS 服务的访问。 有关支持专用链接的 Azure 服务的信息，请参阅 Azure 专用链接可用性。

  • 如果专用终结点不可用，并且数据外泄风险是可接受的，请使用虚拟网络服务终结点来保护从虚拟网络中访问 Azure PaaS 服务的安全。

    • 默认情况下，请不要在所有子网上启用虚拟网络服务终结点，因为这会引入大量数据外泄通道。

  • 对于混合应用程序场景，通过 ExpressRoute 及专用对等互连从本地访问 Azure PaaS 服务。

注意

在 Azure 登陆区域中部署时，请注意登陆区域实现提供与本地数据中心的网络连接。 一种方法是使用配置了专用对等互连的 ExpressRoute。

数据完整性保护

加密是确保数据完整性的重要一步，最终也是可用于缓解各种威胁的最重要安全功能之一。 因此，本部分将提供与加密和密钥管理相关的关键注意事项和建议，以保护数据，而不会影响应用程序的可靠性。

设计注意事项

  • Azure 密钥库对密钥和机密具有事务限制，并在某个时间段内对每个保管库应用限制。

  • Azure Key Vault 提供安全边界，因为密钥、机密和证书的访问权限是在保管库级别应用的。

    • Key Vault 访问策略分配单独授予对密钥、机密或证书的权限。
      • 现在可以对特定密钥、机密或证书的精细 对象级权限 。

  • 更改角色分配后，应用角色的延迟最长为 10 分钟（600 秒）。

    • 每个订阅的 Azure 角色分配限制为 2,000 个。

  • Azure 密钥库基础硬件安全模块（HSM）具有 FIPS 140 验证。

  • Azure 密钥库提供高可用性和冗余，以帮助维护可用性并防止数据丢失。

  • 在区域故障转移期间，密钥库服务可能需要几分钟才能进行故障转移。

    • 故障转移期间，密钥库处于只读模式，因此无法更改密钥保管库属性，例如防火墙配置和设置。

  • 如果使用专用链接连接到 Azure 密钥库，则连接可能需要长达 20 分钟才能在区域故障转移期间重新建立。

  • 备份将创建 机密、密钥或证书的时间点快照 ，作为无法在 Azure 外部解密的加密 Blob。 若要从 Blob 获取可用数据，必须将该数据还原到同一 Azure 订阅和 Azure 地理位置中的密钥库。

    • 机密可能会在备份期间续订，从而导致不匹配。

  • 使用服务管理的密钥，Azure 将执行密钥管理功能，例如轮换，从而减少应用程序操作的范围。

  • 监管控制可以规定使用客户管理的密钥进行服务加密功能。

  • 当流量在 Azure 数据中心之间移动时，基础网络硬件上使用 MACsec 数据链路层加密来保护不受Microsoft或代表Microsoft控制的物理边界外传输中的数据。

设计建议

  • 在可行时，使用服务托管的密钥进行数据保护，而无需管理加密密钥和处理密钥轮换等操作任务。

    • 只有在有明确的法规要求时，才使用客户管理的密钥。

  • 如果需要考虑其他加密机制或客户管理的密钥，请使用 Azure 密钥库作为所有机密、证书和密钥的安全存储库。

    • 在启用了软删除和清除策略的情况下预配 Azure Key Vault，从而允许对已删除对象进行保留保护。
    • 将 HSM 支持的 Azure 密钥库 SKU 用于应用程序生产环境。

  • 在每个区域部署标记中部署单独的 Azure 密钥库 实例，通过本地化提供故障隔离和性能优势，以及导航单个密钥库实例施加的规模限制。

    • 对应用程序全局资源使用专用的 Azure 密钥库 实例。

  • 通过将授权限制为永久删除机密、密钥和证书的专用自定义Microsoft Entra 角色来遵循最低特权模型。

  • 确保备份存储在密钥库中的加密密钥和证书，在不太可能的事件中提供脱机副本，密钥库不可用。

  • 使用 Key Vault 证书来管理证书采购和签名。

  • 建立密钥和证书轮换的自动化过程。

    • 使用公共证书颁发机构自动执行证书管理和续订过程，以简化管理。
      • 设置警报和通知，以补充自动证书续订。

  • 监视密钥、证书和机密使用情况。

策略驱动的治理

只有在所有应用程序服务和团队中一致地全面强制执行时，安全约定才会最终有效。 Azure Policy 提供了一个框架，用于强制实施安全性和可靠性基线，确保持续符合任务关键型应用程序的常见工程标准。 更具体地说，Azure Policy 构成了 Azure 资源管理器（ARM）控制平面的关键部分，通过限制授权用户可以执行的操作来补充 RBAC，并可用于跨已利用的平台服务强制实施重要的安全性和可靠性约定。

因此，本部分将探讨有关对任务关键型应用程序使用 Azure Policy 驱动治理的关键注意事项和建议，确保持续强制执行安全性和可靠性约定。

设计注意事项

  • Azure Policy 提供一种机制，通过强制实施安全性和可靠性约定（例如使用专用终结点或使用可用性区域）来推动合规性。

注意

在 Azure 登陆区域中部署时，请注意，在针对登陆区域管理组和订阅的实现中，可能会应用集中基线策略分配的强制实施。

  • Azure Policy 可用于驱动自动化管理活动，例如预配和配置。

    • 资源提供程序注册。
    • 验证和批准单个 Azure 资源配置。

  • Azure Policy 分配范围决定了覆盖范围和 Azure Policy 定义的位置，告知自定义策略的可重用性。

  • Azure Policy 具有 多个限制，例如任何特定范围内的定义数。

  • 执行部署（如果不存在）策略可能需要几分钟时间。

  • Azure Policy 为合规性报告和安全审核提供了关键输入。

设计建议

  • 将法规和合规性要求与 Azure Policy 定义对应。

    • 例如，如果存在数据驻留要求，则应该应用策略来限制可用的部署区域。

  • 定义一个常见的工程条件，以捕获所有已利用的 Azure 服务的安全可靠配置定义，确保此条件映射到 Azure Policy 分配以强制实施合规性。

    • 例如，应用 Azure Policy 以强制对所有相关服务使用可用性区域，确保区域内部署配置可靠。

任务关键型参考实现包含一系列以安全性和可靠性为中心的策略，用于定义和强制执行示例通用工程标准。

  • 使用 Azure Policy 监视相对于常见工程条件的服务配置偏移。

对于在专用管理组下具有多个生产订阅的任务关键型方案，请在管理组范围内确定分配的优先级。

  • 在可行时使用内置策略，以最大限度地减少维护自定义策略定义的操作开销。

  • 如果需要自定义策略定义，请确保定义部署在合适的管理组范围，以便允许跨包含的环境订阅重复使用，从而允许在生产和较低环境中重复使用策略。

    • 将应用程序路线图与 Azure 路线图保持一致时，请使用可用的Microsoft资源来探索关键自定义定义是否可以合并为内置定义。

注意

在 Azure 登陆区域中部署时，请考虑在中间公司根管理组范围内部署自定义 Azure Policy 定义，以便在更广泛的 Azure 资产中的所有应用程序中重复使用。 在登陆区域环境中，默认情况下，某些集中式安全策略将在更高的管理组范围内应用，以在整个 Azure 资产中强制实施安全合规性。 例如，应应用 Azure 策略以通过 VM 扩展自动部署软件配置，并强制实施合规的基线 VM 配置。

  • 使用 Azure Policy 在整个应用程序中强制实施一致的标记架构。
    • 确定所需的 Azure 标记，并使用追加策略模式来强制使用这些标记。

如果应用程序订阅了Microsoft任务关键型支持，请确保应用的标记架构提供有意义的上下文，以便通过深入的应用程序理解丰富支持体验。

  • 将 Microsoft Entra 活动日志导出到应用程序使用的全局 Log Analytics 工作区。
    • 确保将 Azure 活动日志存档到全局存储帐户中，以及用于长期保留的操作数据。

在 Azure 登陆区域中，Microsoft Entra 活动日志也将引入到集中式平台 Log Analytics 工作区中。 在这种情况下，如果全局 Log Analytics 工作区中仍需要Microsoft Entra ID，则需要对其进行评估。

  • 将安全信息和事件管理与 Microsoft Defender for Cloud（以前称为 Azure 安全中心）集成。

使用 虚拟机 时的 IaaS 特定注意事项

在需要使用 IaaS 虚拟机的情况下，必须考虑一些细节。

设计注意事项

  • 部署后不会自动更新映像。
  • 不会自动安装更新以运行 VM。
  • 映像和单个 VM 通常不是现装强化的。

设计建议

  • 不允许通过公共 Internet 直接访问虚拟机，方法是提供对 SSH、RDP 或其他协议的访问权限。 始终使用 Azure Bastion 和 jumpboxes，对一小部分用户具有有限访问权限。
  • 使用网络安全组、（Azure）防火墙或应用程序网关（级别 7）来筛选和限制出口流量，从而限制直接 Internet 连接。
  • 对于多层应用程序，请考虑使用不同的子网，并使用网络安全组来限制两者之间的访问。
  • 尽可能确定使用公钥身份验证的优先级。 将机密存储在 Azure 密钥库等安全位置。
  • 使用身份验证和访问控制保护 VM。
  • 应用与任务关键型应用程序方案所述的相同安全做法。

遵循并应用上述任务关键型应用程序方案的安全做法（如果适用），以及 Azure 中 IaaS 工作负荷的安全最佳做法。

下一步

查看任务关键型应用程序方案的操作过程的最佳做法。

操作过程