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

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

  • 项目

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

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

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

重要

本文是 Azure Well-Architected 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从 什么是任务关键型工作负载开始？

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

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

与零信任模型对齐

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

设计注意事项

评估应用程序的安全状况时，请首先将这些问题作为每项考虑的基础。

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

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

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

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

  • 发生故障时的身份验证和授权连续性。

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

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

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

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

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

  • 保护软件供应链。

    • 是否可以在已利用的包依赖项中跟踪) (CVE 的常见漏洞和风险？
    • 是否有更新包依赖项的自动化过程？

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

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

  • 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。

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

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

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

威胁建模

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

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

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

注意

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

设计注意事项

STRIDE 提供了一个轻型风险框架，用于跨关键威胁途径评估安全威胁。

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

设计建议

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

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

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

网络入侵防护

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

设计注意事项

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

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

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

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

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

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

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

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

  • 可以在 Azure DevOps 中使用具有相应Microsoft Entra服务主体的服务Connections，通过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 防火墙 Premium 或网络虚拟设备 (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 秒) 。

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

  • 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角色。

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

  • 使用密钥保管库证书来管理证书采购和签名。

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

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

  • 监视密钥、证书和密钥用法。

    • 定义 Azure Monitor 中意外使用情况的 警报 。

策略驱动的治理

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

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

设计注意事项

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

注意

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

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

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

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

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

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

  • 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 Mission-Critical 支持，请确保应用的标记架构提供有意义的上下文，以通过深入的应用程序理解来丰富支持体验。

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

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

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

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

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

设计注意事项

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

设计建议

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

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

后续步骤

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

操作过程