Azure Active Directory 域服务的 Azure 安全基线

此安全基线将 Azure 安全基准版本 2.0 中的指导应用到 Azure Active Directory 域服务。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容按照 Azure 安全基准定义的安全控制措施和适用于 Azure Active Directory 域服务的相关指导进行分组。

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

注意

已排除不适用于 Azure Active Directory 域服务的控制以及建议逐字使用全局指导的控制。 若要了解 Azure Active Directory 域服务如何完全映射到 Azure 安全基准,请参阅完整的 Azure Active Directory 域服务安全基线映射文件

网络安全

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

NS-1:实现内部流量的安全性

指导:部署 Azure Active Directory 域服务 (Azure AD DS) 资源时,请创建一个虚拟网络或使用现有的虚拟网络。 对于所有 Azure 虚拟网络,请遵循与业务风险相符的企业分段原则。 是否有可能会为组织带来更高风险的系统? 将该系统隔离在其自身的虚拟网络中。 然后使用网络安全组 (NSG) 或 Azure 防火墙来充分保护该系统。

使用 Microsoft Defender for Cloud 的自适应网络强化功能,建议限制端口和源 IP 的 NSG 配置。 将外部网络流量规则纳入这些 NSG 配置。

基于应用程序和企业分段策略,根据 NSG 规则限制或允许内部资源之间的流量传递。 是否有定义明确的特定应用程序,例如第 3 层应用? 如果是,可以设置一个高度安全的默认拒绝规则。

Azure AD DS 为其他应用程序和工作负载提供身份验证和管理服务。 网络连接是关键。 确保正确配置了虚拟网络资源。 否则,应用程序和工作负载将无法与 Azure AD DS 提供的功能通信和使用这些功能。 计划虚拟网络要求,使 Azure AD DS 可根据需要为应用程序和工作负载提供服务。

使用 Microsoft Sentinel 可发现是否使用旧的不安全协议,例如:

  • SSL/TLSv1
  • SMBv1
  • LM/NTLMv1
  • wDigest
  • 未签名的 LDAP 绑定
  • Kerberos 中的弱密码

SMBv1 已禁用,且无法重新启用。 客户可以在 Kerberos 中配置 SSL/TLSv1、NTLMv1 等协议和弱密码。 某些应用程序和服务可能仍需要这些协议。

无效的 NSG 规则是导致 Azure AD DS 网络错误的最常见原因。 虚拟网络的 NSG 必须允许访问特定的端口和协议。 如果这些端口被阻止,Azure 平台将无法监视或更新托管域。 Azure AD 目录和 Azure AD DS 之间的同步也会受到影响。 将默认端口保持打开状态,以避免服务中断。

责任:客户

NS-2:将专用网络连接在一起

指导:在场地租用环境中,使用 Azure ExpressRoute 或 Azure 虚拟专用网 (VPN) 在 Azure 数据中心与本地基础结构之间创建专用连接。 ExpressRoute 连接不经过公共 Internet。 相较于典型的 Internet 连接,ExpressRoute 连接提供:

  • 可靠性更强
  • 速度更快
  • 延迟性更低

对于点到站点 VPN 和站点到站点 VPN,可以将本地设备或网络连接到虚拟网络。 使用这些 VPN 选项和 Azure ExpressRoute 的任意组合。

若要将 Azure 中的两个或更多虚拟网络连接在一起,请使用虚拟网络对等互连。 对等虚拟网络之间的网络流量是专用的。 该流量保留在 Azure 主干网络上。

责任:客户

NS-6:简化网络安全规则

指导:使用 Azure 虚拟网络服务标记,在 NSG 或 Azure 防火墙上定义网络访问控制。 为 Azure AD DS 资源配置这些控制。 创建安全规则时,请使用服务标记代替特定 IP 地址。 通过在相应的源或目标规则中使用服务标记名称,允许或拒绝相应服务的流量。 Microsoft 管理服务标记包含的地址前缀。 当地址发生变化时,它会自动更新服务标记。

是否有使用基于资源管理器的虚拟网络的托管域? 如果是,请使用“AzureActiveDirectoryDomainServices”服务标记来限制对此端口的入站访问。

是否有使用基于经典模型的虚拟网络的旧式托管域? 如果是,请仅限从以下源 IP 地址对此端口进行入站访问:

  • 13.74.249.156

  • 23.101.0.70

  • 52.161.13.95

  • 52.179.126.223

  • 52.180.183.8

  • 52.187.117.83

  • 52.225.184.198

  • 104.40.87.209

  • 104.40.156.18

有关详细信息,请阅读以下文章:

责任:客户

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

指南:遵循 DNS 安全的最佳做法来缓解常见攻击,例如:

  • 无关联 DNS
  • DNS 放大攻击
  • DNS 中毒和欺骗

Azure DNS 是否用作权威 DNS 服务? 如果是,请使用 Azure 基于角色的访问控制 (RBAC) 和资源锁来保护 DNS 区域和记录免受意外或恶意修改。

Azure AD DS 提供 Windows Server DNS。 有关详细信息,请参阅 Windows Server DNS 文档。

责任:客户

特权访问

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

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

指导:Azure AD 最关键的内置角色是全局管理员和特权角色管理员。 分配给这两个角色的用户可以委托管理员角色:

  • 全局管理员/公司管理员:具有此角色的用户可访问 Azure AD 中的所有管理功能,还可访问使用 Azure AD 标识的服务。

  • 特权角色管理员:具有此角色的用户可以管理 Azure AD 和 Azure AD Privileged Identity Management (PIM) 内的角色分配。 此外,该角色还可管理 PIM 和管理单元的各个方面。

注意:是否使用自定义角色? 是否为你分配了某些特权? 如果是,你可能需要管理其他关键角色。 你可能还要对关键业务资产的管理员帐户应用类似控制。

应限制高特权帐户或角色的数量,并提升这些帐户的保护级别。 具有此特权的用户可直接或间接读取和修改 Azure 环境中的每项资源。

使用 Azure AD PIM 启用对 Azure 资源和 Azure AD 的实时 (JIT) 特权访问。 JIT 仅在用户需要执行特权任务时才授予临时权限。 当 Azure AD 组织中存在可疑或不安全的活动时,PIM 还会生成安全警报。

Azure AD DS 中的特权用户是已加入 Azure AD 中“AAD DC 管理员”组的用户。 客户应限制此组中的用户数并审核此组的活动。

责任:客户

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

指导:Azure AD DS 已与 Azure RBAC 集成以管理其资源。 但是,该服务不支持 Azure AD DS 实例中任何基于角色的本地管理帐户。 Microsoft 为不拥有访问权限的客户管理基础域控制器。

使用 Azure AD 访问评审来评审:

  • 组成员身份。
  • 对企业应用程序的访问。
  • 用于部署和管理 Azure 资源的角色分配。

Azure AD 报告提供日志来帮助发现过时的帐户。 为加速评审过程,还可以使用 Azure AD PIM 创建访问评审报告工作流。

还可以配置 Azure PIM,以便在创建过多管理员帐户时发出警报。 识别已过期或配置不当的管理员帐户。

责任:共享

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

指导:受保护的独立工作站对于敏感角色的安全性至关重要,例如:

  • 管理员
  • 开发人员
  • 关键服务操作员

使用高度安全的用户工作站或 Azure Bastion 执行管理任务。 若要为管理任务部署安全且受管理的用户工作站,请使用:

  • Azure AD
  • Microsoft Defender 高级威胁防护 (ATP)
  • Microsoft Intune

可集中管理受保护的工作站以强制实施安全配置,其中包括:

  • 强身份验证
  • 软件和硬件基线
  • 受限制的逻辑和网络访问

有关详细信息,请阅读以下文章:

责任:客户

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

指导:Azure AD DS 已与 Azure RBAC 集成以管理其资源。 但是,该服务不支持 Azure AD DS 实例中任何基于角色的本地管理帐户。 Microsoft 为不拥有访问权限的客户管理基础域控制器。

借助 Azure RBAC,可以通过角色分配来管理 Azure 资源访问。 将这些角色分配给:

  • 用户
  • 服务主体
  • 托管标识

某些资源有预定义的内置角色。 可以通过工具盘点或查询这些角色,例如:

  • Azure CLI
  • Azure PowerShell
  • Azure 门户

始终将通过 Azure RBAC 分配给资源的特权限制为角色所需的特权。 此做法是对 Azure AD PIM 的 JIT 方法的补充,应定期进行评审。 使用内置角色授予权限。 仅在必要时创建自定义角色。

责任:共享

PA-8:选择 Microsoft 支持的审批流程

指导:Azure AD DS 不支持客户密码箱。 Microsoft 可以通过非密码箱方式与客户协作,以便获得批准来访问客户数据。

责任:客户

资产管理

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

AM-1:确保安全团队可以了解与资产相关的风险

指导:在 Azure 租户和订阅中授予安全团队安全读取者权限。 有了这些权限,安全团队可以使用 Microsoft Defender for Cloud 来监视安全风险。

根据安全团队责任划分方式的不同,可以由中心安全团队或本地团队负责监视安全风险。 始终在组织内集中聚合安全见解和风险。

可以将安全读取者权限广泛应用于整个租户(根管理组)。 或者,可以将那些权限范围限定为管理组或特定订阅。

注意:要查看工作负载和服务,可能需要其他权限。

责任:客户

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

指导:确保安全团队有权访问 Azure 上持续更新的资产清单,例如 Azure AD DS。 安全团队通常需要使用此清单来评估其组织遭遇新兴风险的可能性。 清单还可用作持续进行安全改进的一种输入。 创建 Azure AD 组,以包含组织的授权安全团队。 向他们分配对所有 Azure AD DS 资源的读取访问权限。 可以通过在订阅中分配单个高级角色来简化此任务。

要有条理地组织成分类,请将标记应用于:

  • Azure 资源
  • 资源组
  • 订阅

每个标记均由名称和值对组成。 例如,可以对生产中的所有资源应用名称“Environment”和值“Production”。

使用 Azure 虚拟机清单自动收集有关虚拟机上的软件的信息。 Azure 门户提供以下信息字段:

  • 软件名称
  • 版本
  • Publisher
  • 刷新时间

要访问安装日期和其他信息,请启用来宾级诊断。 然后,将 Windows 事件日志引入 Log Analytics 工作区。

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

责任:客户

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

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

责任:客户

日志记录和威胁检测

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

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

指导:使用 Microsoft Defender for Cloud 的内置威胁检测功能,为 Azure AD DS 资源启用 Microsoft Defender。 适用于 Azure AD DS 的 Microsoft Defender 提供额外的安全智能层。 它会检测企图访问或利用 Azure AD DS 资源的潜在有害的异常活动。

Azure AD DS 服务使用 Windows 恶意软件检测来自动检测恶意软件并予以修正。 如果检测到恶意软件,该服务会向 Azure 安全团队发送通知,以进一步进行分析。

责任:客户

LT-3:为 Azure 网络活动启用日志记录

指导:在安全分析中,启用并收集:

  • NSG 资源日志
  • NSG 流日志
  • Azure 防火墙日志
  • Web 应用程序防火墙 (WAF) 日志

这种日志收集有助于支持以下工作:

  • 事件调查
  • 威胁搜寻
  • 安全警报生成

将流日志发送到 Azure Monitor Log Analytics 工作区。 然后,使用流量分析提供见解。

Azure AD DS 不生成或处理 DNS 查询日志。

责任:客户

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

指导:活动日志包含 Azure AD DS 资源的所有写入操作(PUT、POST 和 DELETE)。 活动日志会自动提供,但不包括读取操作 (GET)。 进行故障排除时,可以使用活动日志来查找错误。 或者,可以使用日志来监视组织中的用户如何修改资源。

Azure AD DS 目前不会生成 Azure 资源日志。

通过 Azure AD DS 安全审核,Azure 可将安全事件流式传输到目标资源。 这些资源包括:

  • Azure 存储
  • Azure Log Analytics 工作区
  • Azure 事件中心

启用安全审核事件后,Azure AD DS 会将所选类别的所有已审核事件发送到目标资源。 目标资源审核对目录中所有用户帐户(包括管理员)进行的身份验证。

使用 Azure 事件中心,可将事件存档到 Azure 存储,并将事件流式传输到 SIEM 软件(或类似软件)。 或者,你可以在 Azure 门户中使用 Azure Log Analytics 工作区自行进行分析。

责任:共享

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

指导:若要启用关联,请集中化日志记录存储和分析。 对于每个日志源,请确保已分配:

  • 数据所有者
  • 访问指导
  • 存储位置
  • 用于处理和访问数据的工具
  • 数据保留要求

将 Azure 活动日志集成到中心日志记录中。 通过 Azure Monitor 引入日志来聚合以下对象生成的安全数据:

  • 终结点设备
  • 网络资源
  • 其他安全系统

在 Azure Monitor 中,使用 Log Analytics 工作区执行查询和分析。 然后,将 Azure 存储帐户用于长期存储和存档存储。 另外,启用 Microsoft Sentinel 或第三方 SIEM 并将数据加入其中。 许多组织选择将 Microsoft Sentinel 用于频繁使用的“热”数据。 然后,这些组织选择将 Azure 存储用于不太频繁使用的“冷”数据。

对于可能在 Azure AD DS 上运行的应用程序,将所有与安全相关的日志转发到 SIEM 进行集中管理。

通过 Azure AD DS 安全审核,Azure 可将安全事件流式传输到目标资源。 这些资源包括:

  • Azure 存储
  • Azure Log Analytics 工作区
  • Azure 事件中心

启用安全审核事件后,Azure AD DS 会将所选类别的所有已审核事件发送到目标资源。

使用 Azure 事件中心,可将事件存档到 Azure 存储,并将事件流式传输到 SIEM 软件(或类似软件)。 或者,你可以在 Azure 门户中使用 Azure Log Analytics 工作区自行进行分析。

责任:共享

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

指导:是否使用任何存储帐户或 Log Analytics 工作区来存储 Azure AD DS 日志? 如果是,请根据组织的合规性条例设置日志保留期。

可将这些实体用作 Azure AD DS 安全审核的目标资源:

  • Azure 存储
  • Azure 事件中心
  • Azure Log Analytics 工作区

这些目标可以组合在一起。 例如,可以使用 Azure 存储来存档安全审核事件。 然后,还可以使用 Azure Log Analytics 工作区来分析和报告短期信息。

责任:共享

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

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

Azure AD DS 服务依赖于 Microsoft 时间同步源。 它并未向客户公开,以供其进行配置。

责任:Microsoft

安全状况和漏洞管理

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

PV-1:创建 Azure 服务的安全配置

指导:在一个蓝图定义中,使用 Azure 蓝图自动部署和配置服务与应用程序环境,包括:

  • Azure Resource Manager 模板
  • Azure RBAC 控制
  • 策略

为了帮助你根据业务需求进一步保护设置,Azure AD DS 提供了许多安全配置设置。

责任:客户

PV-2:为所有 Azure 服务维护安全配置

指导:使用 Azure AD DS,通过 PowerShell 设置并保留安全相关的配置。 运行 PowerShell 命令以确保禁用弱密码和 NTLM 密码哈希同步。使用 Azure Functions 或逻辑应用为这些配置创建重复性检查。 使用自动化流触发警报或通知。 这样,在关键设置未配置或发生更改时,事件响应团队将知道这种情况。

责任:客户

PV-3:为计算资源建立安全配置

指导:使用 Microsoft Defender for Cloud 和 Azure Policy 在所有计算资源(包括 VM、容器等)上创建安全配置。

默认情况下,Azure AD DS 允许使用 NTLM v1 和 TLS v1 等密码。 某些旧式应用程序可能需要这些密码。 但是,这些密码被视为弱密码,如果不需要它们,可将其禁用。 如果使用 Azure AD Connect 进行本地混合连接,还请禁用 NTLM 密码哈希的同步。

所有 Azure 服务通信(例如与 MSGraph 或 Azure 存储的通信)都是通过 SSL 进行的,并且需要 TLS 1.2。

责任:共享

PV-6:执行软件漏洞评估

指导:Microsoft 对支持 Azure AD DS 的基础系统执行漏洞管理。

责任:Microsoft

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

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

按照 Microsoft Cloud 渗透测试参与规则操作,以确保渗透测试不违反 Microsoft 策略。 使用 Microsoft 策略并针对 Microsoft 管理的以下各项执行红队演练和现场渗透测试:

  • 云基础结构
  • 服务
  • 应用程序

有关详细信息,请阅读以下文章:

责任:共享

终结点安全性

有关详细信息,请参阅 Azure 安全基线:终结点安全性

ES-1:使用终结点检测和响应 (EDR)

指导:Azure AD DS 没有任何需要终结点检测和响应 (EDR) 的面向客户的虚拟机或容器。 为了符合这种控制措施,Azure AD DS 不要求你配置任何其他设置或部署任何额外的服务。

责任:Microsoft

ES-2:使用集中管理的新式反恶意软件

指导:Azure AD DS 没有任何需要反恶意软件保护的面向客户的虚拟机或容器。 为了防范恶意软件的威胁,Azure AD DS 不要求你配置任何其他设置或部署任何额外的服务。

责任:Microsoft

ES-3:确保反恶意软件和签名已更新

指导:Azure AD DS 没有任何需要反恶意软件保护的面向客户的虚拟机或容器。 为了防范恶意软件的威胁,Azure AD DS 不要求你配置任何其他设置或部署任何额外的服务。

责任:Microsoft

备份和恢复

有关详细信息,请参阅 Azure 安全基准:备份和恢复

BR-1:确保定期执行自动备份

指导:每日备份将保留 7 天,每第三次创建的备份将保留 30 天。 备份频率按客户的 SKU 确定。

责任:共享

BR-2:加密备份数据

指导:每日备份将保留 7 天,每第三次创建的备份将保留 30 天。 备份频率按客户的 SKU 确定。 使用 Azure 磁盘加密来加密备份。

责任:共享

BR-3:验证所有备份,包括客户管理的密钥

指导:自动监视可确保每个租户具有最新备份。 是否会因为配置错误而阻止备份服务? 如果是,会向服务所有者发送警报。 Azure AD DS 不允许使用客户管理的密钥。

责任:Microsoft

BR-4:减少密钥丢失风险

指导:保持措施到位,以防止密钥丢失以及恢复丢失的密钥。 在 Azure Key Vault 中启用软删除和清除保护,以防止意外删除或恶意删除密钥。

责任:Microsoft

后续步骤