适用于 Azure Policy 的 Azure 安全基线

此安全基线对 Azure Policy 应用 Azure 安全基准 2.0 版中的指南。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容按“合规性域”进行分组,“安全控件”由 Azure 安全基准定义,且相关指南适用于 Azure Policy 。

可以使用 Microsoft Defender for Cloud 监视此安全基线及其建议。 Azure Policy定义将在 Microsoft Defender for Cloud 仪表板的“法规符合性”部分列出。

当某个部分具有相关的Azure Policy定义时,它们将列在此基线中,以帮助衡量 Azure 安全基准控件和建议的符合性。 某些建议可能需要付费的 Microsoft Defender 计划才能启用某些安全方案。

注意

已排除不适用于 Azure Policy 中心的控件以及建议逐字使用全局指导的控件。 若要查看 Azure Policy 如何完全映射到 Azure 安全基准,请参阅完整的 Azure Policy 安全基准映射文件

网络安全

有关详细信息,请参阅 Azure 安全基线: 网络安全性

NS-7:安全域名服务 (DNS)

指导:Azure Policy 不公开其基础 DNS 配置,这些设置由 Microsoft 维护。

责任:Microsoft

标识管理

有关详细信息,请参阅 Azure 安全基准:标识管理

IM-1:将 Azure Active Directory 标准化为中央标识和身份验证系统

指导:Azure Policy 使用 Azure Active Directory (Azure AD) 作为默认标识和访问管理服务。 你应该使 Azure AD 标准化,以便控制组织在以下资源中的标识和访问管理:

责任:客户

IM-2:安全且自动地管理应用程序标识

指导:Azure Policy 对服务或自动化之类的非人工帐户使用 Azure 托管标识,建议使用 Azure 托管标识功能,而不是创建更加强大的人工帐户来访问或执行资源。 Azure Policy 可以通过预定义的访问授权规则以原生方式向支持 Azure AD 身份验证的 Azure 服务/资源进行身份验证,而无需使用在源代码或配置文件中硬编码的凭据。 Azure 策略可以为基于修正的策略分配创建托管标识。 如果是在门户中创建分配,Azure 策略将向托管标识授予策略定义中的角色。 如果是通过 SDK 创建分配,则客户负责向托管标识授予所需角色。

责任:客户

IM-3:使用 Azure AD 单一登录 (SSO) 进行应用程序访问

指导:Azure Policy 使用 Azure Active Directory (Azure AD) 来提供对 Azure 资源、云应用程序和本地应用程序的标识和访问管理。 此内容包括企业标识(例如员工)以及外部标识(如合作伙伴和供应商)。 Azure AD 允许单一登录 (SSO) 使用任何同步的公司 Active Directory 标识通过 Azure 门户管理 Azure Policy 服务。 将所有用户、应用程序和设备连接到 Azure AD,实现无缝的安全访问和更好的可见性和控制。

责任:客户

IM-7:消除意外的凭据透露

指导:Azure 策略定义可能包含敏感信息或机密信息。 建议审核 JSON 定义中的凭据

或机密。

责任:客户

特权访问

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

PA-1:保护和限制具有较高权限的用户

指导:Azure AD 最重要的内置角色是全局管理员和特权角色管理员,因为分配到这两种角色的用户可以委托管理员角色:

  • 全局管理员/公司管理员:具有此角色的用户有权访问 Azure AD 中的所有管理功能以及使用 Azure AD 标识的服务。- 特权角色管理员:具有此角色的用户可以管理 Azure AD 中的角色分配,也可以在 Azure AD (PIM) Privileged Identity Management 中管理角色分配。 另外,此角色还允许管理 PIM 和管理单元的所有方面。注意:如果使用的是分配了某些特权的自定义角色,则可能有其他关键角色需要进行管理。 你可能还希望将类似的控制应用到关键业务资产的管理员帐户。你应限制高特权帐户或角色的数量,并提升这些帐户的保护级别。 直接或间接拥有此特权的用户可以读取和修改 Azure 环境中的每个资源。可以使用 Azure AD PIM,启用对 Azure 资源和 Azure AD 的实时 (JIT) 特权访问。 JIT 仅在用户需要执行特权任务时授予临时权限。 当 Azure AD 组织中存在可疑或不安全的活动时,PIM 还会生成安全警报。

  • Azure AD 中的管理角色权限

  • 使用 Azure Privileged Identity Management 安全警报

  • 确保 Azure AD 中混合部署和云部署的特权访问安全性

责任:客户

PA-3:定期审查和协调用户访问权限

指导:Azure Policy 使用 Azure Active Directory (Azure AD) 帐户来定期管理其资源、审阅用户帐户和访问权限分配,以确保帐户及其访问权限有效。 可使用 Azure AD 和访问评审来审查组成员身份、对企业应用程序的访问权限和角色分配。 Azure AD 报告提供日志来帮助发现过时的帐户。 还可使用 Azure AD Privileged Identity Management (PIM) 来创建访问评审报告工作流以促进审查流程。

此外,还可以配置 Azure AD PIM,以便在创建过多的管理员帐户时向你发出警报,并标识过时或配置不当的管理员帐户。注意:某些 Azure 服务支持不通过 Azure AD 进行管理的本地用户和角色。 你需要单独管理这些用户。

责任:客户

PA-6:使用特权访问工作站

指导:受保护的独立工作站对于敏感角色(如管理员、开发人员和关键服务操作员)的安全性至关重要。 使用高度安全的用户工作站和/或 Azure Bastion 执行管理任务。 使用 Azure Active Directory (Azure AD)、Microsoft Defender 高级威胁防护 (ATP) 和/或 Microsoft Intune 来部署安全的托管用户工作站,以便执行管理任务。 可集中管理受保护的工作站,强制实施安全配置,包括强身份验证、软件和硬件基线,以及受限制的逻辑和网络访问。

责任:客户

PA-7:遵循 Just Enough Administration(最小特权原则)

指导:Azure Policy 通过与 Azure 基于角色的访问控制 (RBAC) 集成来管理其资源。 使用 Azure RBAC,可通过角色分配来管理 Azure 资源访问。 可以将这些角色分配给用户、组服务主体和托管标识。 某些资源具有预定义的内置角色,可以通过工具(例如 Azure CLI、Azure PowerShell 或 Azure 门户)来清点或查询这些角色。 通过 Azure RBAC 分配给资源的特权应始终限制为角色所需的特权。 这是对 Azure AD Privileged Identity Management (PIM) 的实时 (JIT) 方法的补充,应定期进行审查。

请使用内置角色来分配权限,仅在必要时创建自定义角色。

责任:客户

数据保护

有关详细信息,请参阅 Azure 安全基线: 数据保护

DP-4:加密传输中的敏感信息

指导:Azure Policy 支持使用 TLS 1.2 或更高版本加密传输中数据。 默认情况下,Azure 为在 Azure 数据中心之间传输的数据提供加密。

责任:Microsoft

Microsoft Defender for Cloud 监视:Azure 安全基准是 Microsoft Defender for Cloud 的默认策略计划,也是构筑各项 Microsoft Defender for Cloud 建议的基础。 Microsoft Defender for Cloud 会自动启用与此控制相关的 Azure Policy 定义。 与此控制相关的警报可能需要相关服务的 Microsoft Defender 计划。

Azure Policy 内置定义 - Microsoft.GuestConfiguration

名称
(Azure 门户)
说明 效果 版本
(GitHub)
应将 Windows Web 服务器配置为使用安全通信协议 为了保护通过 Internet 进行通信的信息的隐私,Web 服务器应使用最新版本的行业标准加密协议,即传输层安全性 (TLS)。 TLS 使用安全证书对计算机之间的连接进行加密来保护网络上的通信。 AuditIfNotExists、Disabled 3.0.0

DP-5:加密静态敏感数据

指导:Microsoft 加密服务默认使用加密保护静态数据,以防“带外”攻击(例如访问基础存储)。 这有助于确保攻击者无法轻松读取或修改数据。

责任:Microsoft

资产管理

有关详细信息,请参阅 Azure 安全基准:资产管理

AM-2:确保安全团队有权访问资产清单和元数据

指导:确保安全团队有权访问 Azure 上持续更新的资产清单,如 Azure Policy。 安全团队通常需要此清单,以评估其组织遇到新兴风险的可能性,并据此不断提高安全性。 创建一个 Azure Active Directory (Azure AD) 组以包含组织的授权安全团队,并向他们分配对所有 Azure Policy 资源的读取权限,这可以通过在订阅中分配单个高级角色来简化。

Azure 策略不使用标记,也不允许客户将资源标签应用或使用为元数据,以便按分类有条理地整理资源。

Azure 策略支持具有 DeployIfNotExists 效果的基于资源管理器的资源部署。 它还支持 Azure Resource Graph 查询,并由自定义表提供支持。

Azure Policy 不允许在其资源上运行应用程序或安装软件。 描述产品/服务中允许或支持此功能的任何其他功能(如果适用)。

责任:客户

AM-3:仅使用已批准的 Azure 服务

指导:请使用 Azure Policy 来审核和限制用户可以在你的环境中预配哪些服务。 使用 Azure Resource Graph 查询和发现订阅中的资源。 你也可以使用 Azure Monitor 来创建规则,以便在检测到未经批准的服务时触发警报。

责任:客户

日志记录和威胁检测

有关详细信息,请参阅 Azure 安全基准:日志记录和威胁检测

LT-1:为 Azure 资源启用威胁检测

指导:Azure Policy 不会提供本机功能来监视与其资源相关的安全威胁。

将 Azure Policy 中的所有日志转发到可用于设置自定义威胁检测的 SIEM。 确保正在监视不同类型的 Azure 资产,以发现潜在的威胁和异常情况。 专注于获取高质量警报以减少误报,便于分析人员进行分类整理。 警报可能源自日志数据、代理或其他数据。

责任:客户

LT-2:启用 Azure 标识和访问管理的威胁检测

指导:Azure Active Directory (Azure AD) 提供以下用户日志,这些日志可在 Azure AD 报告中查看,也可与 Azure Monitor、Microsoft Sentinel 或其他 SIEM/监视工具集成,以用于更复杂的监视和分析用例:

  • 登录 - 在登录报告中,可了解托管应用程序的使用情况和用户登录活动。

  • 审核日志 - 通过日志为 Azure AD 中的各种功能所做的所有更改提供可跟踪性。 审核日志的示例包括对 Azure AD 中的任何资源所做的更改,例如添加或删除用户、应用、组、角色和策略。

  • 风险登录 - 风险登录是指可能由非用户帐户合法拥有者进行的登录尝试。

  • 已标记为存在风险的用户 - 风险用户是指可能已泄露的用户帐户。

Microsoft Defender for Cloud 还可针对某些可疑活动发出警报,例如,失败的身份验证尝试次数过多或使用了订阅中的已弃用帐户。 除了基本的安全卫生监视以外,Microsoft Defender for Cloud 的威胁防护模块还可从各个 Azure 计算资源(虚拟机、容器、应用服务)、数据资源(SQL 数据库和存储)和 Azure 服务层收集更深入的安全警报。 通过此功能,可查看各个资源内的帐户异常情况。

责任:客户

LT-4:为 Azure 资源启用日志记录

指导:自动可用的活动日志包含针对 Azure Policy 资源的所有写入操作(PUT、POST、DELETE),但读取操作 (GET) 除外。 活动日志可用于在进行故障排除时查找错误,或监视组织中的用户如何对资源进行修改。

Azure Policy 当前不生成 Azure 资源日志。

责任:客户

LT-5:集中管理和分析安全日志

指导:集中记录存储和分析来实现关联。 对于每个日志源,请确保已分配数据所有者、访问指南、存储位置、用于处理和访问数据的工具以及数据保留要求。

确保正在将 Azure 活动日志集成到中央日志记录。 通过 Azure Monitor 引入日志,以聚合终结点设备、网络资源和其他安全系统生成的安全数据。 在 Azure Monitor 中,使用 Log Analytics 工作区来查询和执行分析,并使用 Azure 存储帐户进行长期和存档存储。此外,启用 Microsoft Sentinel 或第三方 SIEM,并将数据集成到其中。很多组织选择将 Microsoft Sentinel 用于经常使用的“热”数据,并 Azure 存储用于不太频繁使用的“冷”数据。

责任:客户

LT-6:配置日志存储保留期

指导:确保用于存储 Azure Policy 日志的所有存储帐户或 Log Analytics 工作区都根据组织的合规性规定设置了日志保留期。

责任:客户

LT-7:使用批准的时间同步源

指导:Azure Policy 不支持配置你自己的时间同步源。

Azure Policy 服务依赖于 Microsoft 时间同步源,不会向客户公开以允许其进行配置。

责任:Microsoft

安全状况和漏洞管理

有关详细信息,请参阅 Azure 安全基准:安全状况和漏洞管理

PV-8:执行定期攻击模拟

指导:根据需要,对 Azure 资源进行渗透测试或红队活动,并确保修正所有关键安全发现。

请遵循 Microsoft 云渗透测试互动规则,确保你的渗透测试不违反 Microsoft 政策。 使用 Microsoft 红队演练策略和执行,以及针对 Microsoft 托管云基础结构、服务和应用程序执行现场渗透测试。

责任:客户

后续步骤