适用于 Azure Lighthouse 的 Azure 安全基线

此安全基线将 Azure 安全基准版本 2.0 中的指南应用于 Azure Lighthouse。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容是按安全控制进行分组的,这些控制根据适用于 Azure Lighthouse 的 Azure 安全基准和相关指南定义。

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

注意

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

网络安全

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

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

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

责任:Microsoft

标识管理

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

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

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

  • Microsoft 云资源,如 Azure 门户、Azure 存储、Azure 虚拟机(Linux 和 Windows)、Azure Key Vault、PaaS 和 SaaS 应用程序。
  • 你的组织的资源,例如 Azure 上的应用程序,或公司网络资源。

使用 Azure Lighthouse,管理租户中的指定用户拥有 Azure 内置角色,该角色用户能够访问客户租户中的委托订阅和/或资源组。 所有的内置角色目前都受支持(所有者或任何具有 DataActions 权限的内置角色除外)。 仅在向托管标识分配角色时才支持使用用户访问管理员角色。 不支持自定义角色和经典订阅管理员角色。

责任:客户

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

指导:Azure 托管标识可以向支持 Azure Active Directory (Azure AD) 身份验证的 Azure 服务和资源进行身份验证。 身份验证是通过预定义的访问授权规则启用的,避免了在源代码或配置文件中使用硬编码的凭据。 使用 Azure Lighthouse,在客户的订阅中具有“用户访问管理员”角色的用户可以在该客户的租户中创建托管标识。 虽然 Azure Lighthouse 通常不支持此角色,但可以将此角色用在此特定方案中,允许具有此权限的用户将一个或多个特定的内置角色分配到托管标识。

对于不支持托管标识的服务,则请使用 Azure AD 在资源级别创建权限受限的服务主体。 Azure Lighthouse 允许服务主体根据自己在加入过程中获得的角色来访问客户资源。 建议使用证书凭据配置服务主体,并回退到客户端机密。 在这两种情况下,都可以将 Azure Key Vault 与 Azure 托管标识结合使用,以便运行时环境(例如 Azure 函数)可以从密钥保管库中检索凭据。

责任:客户

特权访问

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

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

指导:限制具有较高权限的用户帐户的数量,并提升这些帐户的保护级别。 启用和使用 Azure Lighthouse 不需要全局管理员帐户。

若要访问租户级别的活动日志数据,必须为某个帐户在根范围 (/) 分配“监视读取者”Azure 内置角色。 由于根范围的“监视读取者”角色是广泛的访问级别,因此建议将此角色分配到服务主体帐户,而不是分配到单个用户或组。 这种分配必须由具有“全局管理员”角色(带有其他提升的访问权限)的用户执行。 此提升的访问权限应该在马上要进行角色分配之前才添加,然后在分配完成时删除。

责任:客户

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

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

客户可以在 Azure 门户中通过 Azure Lighthouse 来查看向管理租户中的用户授予的访问权限级别。 他们可以随时撤销此访问权限。

此外,Azure Privileged Identity Management 还可配置为在创建过多管理员帐户时发出警报,并识别过时或配置不正确的管理员帐户。

请注意:有些 Azure 服务支持不通过 Azure AD 进行管理的本地用户和角色。 你需要单独管理这些用户。

责任:客户

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

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

责任:客户

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

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

Azure Lighthouse 允许使用 Azure 内置角色来访问委托的客户资源。 在大多数情况下,需要将这些角色分配到组或服务主体,而不是分配到许多单独的用户帐户。 这样,便可添加或删除单位用户的访问权限,而无需在访问要求更改时更新和重新发布计划。

若要将客户资源委托到管理租户,必须由客户租户中的非来宾帐户完成部署,该帐户对于正在加入的订阅(或包含正在加入的资源组的订阅)拥有“所有者”内置角色。

责任:客户

资产管理

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

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

指导:确保在 Azure 租户和订阅中向安全团队授予安全读取者权限,方便他们使用 Microsoft Defender for Cloud 监视安全风险。

根据安全团队责任划分方式的不同,监视安全风险可能是中心安全团队或本地团队的责任。 也就是说,安全见解和风险必须始终在组织内集中聚合。

安全读取者权限可以广泛应用于整个租户(根管理组),也可以限制到管理组或特定订阅。

注意:若要了解工作负载和服务,可能需要更多权限。

责任:客户

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

指导:客户的安全团队可以查看活动日志,以了解使用 Azure Lighthouse 的服务提供商执行的活动。

如果服务提供商希望允许其安全团队查看委托的客户资源,该安全团队的授权应包括读取者内置角色。

责任:客户

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

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

责任:客户

日志记录和威胁检测

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

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

指导:通过 Azure Lighthouse,可以监视客户的 Azure 资源,以了解潜在威胁和异常情况。 专注于获取高质量警报以减少误报,便于分析人员进行分类整理。 警报可能源自日志数据、代理或其他数据。

使用 Microsoft Defender for Cloud 内置的威胁检测功能,该功能基于监视 Azure 服务遥测和分析服务日志。 数据是使用 Log Analytics 代理收集的,该代理从系统中读取各种与安全相关的配置和事件日志,然后将数据复制到工作区进行分析。

另外,请使用 Microsoft Sentinel 来构建分析规则,这些规则会在客户的环境中搜寻符合特定条件的威胁。 它们会在条件匹配时生成事件,以便你能够调查每个事件。 Microsoft Sentinel 还可以导入第三方威胁情报,从而增强威胁检测功能。

责任:客户

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

指导:通过 Azure Lighthouse,可以使用 Microsoft Defender for Cloud 来针对你管理的客户租户中的某些可疑活动发出警报,例如,失败的身份验证尝试次数过多和使用了订阅中的已弃用帐户。

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 Lighthouse 资源的所有写入操作(PUT、POST、DELETE),但读取操作 (GET) 除外。 活动日志可用于在进行故障排除时查找错误,或监视组织中的用户如何对资源进行修改。

利用 Azure Lighthouse,可以在自己管理的客户租户间以可缩放的方式来使用 Azure Monitor 日志。 请直接在客户租户中创建 Log Analytics 工作区,以便客户数据保留在他们的租户中,而不是导出到你的租户中。 这样也便于集中监视 Log Analytics 支持的任何资源或服务,从而更灵活地选择所监视的数据类型。

已为 Azure Lighthouse 委托了订阅的客户可以查看 Azure 活动日志数据,以了解所有执行的操作。 这样,客户就能够全面了解服务提供商正在执行的操作,以及用户自己的 Azure Active Directory (Azure AD) 租户中的用户完成的操作。

责任:共享

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

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

确保正在将 Azure 活动日志集成到中央日志记录。 通过 Azure Monitor 引入日志,以聚合终结点设备、网络资源和其他安全系统生成的安全数据。 在 Azure Monitor 中,使用 Log Analytics 工作区来查询和执行分析,并使用 Azure 存储帐户进行长期存档存储。

另外,请启用 Microsoft Sentinel 或第三方 SIEM,并在其中加入数据。

利用 Azure Lighthouse,可以在自己管理的客户租户间以可缩放的方式来使用 Azure Monitor 日志。 请直接在客户租户中创建 Log Analytics 工作区,以便客户数据保留在他们的租户中,而不是导出到你的租户中。 这样也便于集中监视 Log Analytics 支持的任何资源或服务,从而更灵活地选择所监视的数据类型。

已为 Azure Lighthouse 委托了订阅的客户可以查看 Azure 活动日志数据,以了解所有执行的操作。 这样,客户就能够全面了解服务提供商正在执行的操作,以及用户自己的 Azure Active Directory (Azure AD) 租户中的用户完成的操作。

许多组织选择将 Microsoft Sentinel 用于“热”数据(频繁使用的数据),将 Azure 存储用于“冷”数据(不太频繁使用的数据)。

责任:客户

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

指导:Azure Lighthouse 目前不会生成任何与安全相关的日志。 需要查看服务提供商活动的客户可以根据符合性、法规和业务等方面的需求配置日志保留。

在 Azure Monitor 中,可根据组织的合规性规则设置 Log Analytics 工作区保持期。 将 Azure 存储、Data Lake 或 Log Analytics 工作区帐户用于长期存储和存档存储。

责任:客户

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

指导:Azure Lighthouse 不支持配置自己的时间同步源。 Azure Lighthouse 服务依赖于 Microsoft 时间同步源,不会向客户公开以允许其进行配置。

责任:Microsoft

安全状况和漏洞管理

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

PV-1:为所有 Azure 服务建立安全配置

指导:Azure Lighthouse 支持 Microsoft Defender for Cloud 提供的以下特定于服务的策略,用于审核和强制实施 Azure 资源的配置。 这可以在 Microsoft Defender for Cloud 或 Azure Policy 计划中进行配置。

  • 允许管理租户 ID 通过 Azure Lighthouse 加入

  • 审核是否将作用域委派给管理租户

可以使用 Azure 蓝图,在单个蓝图定义中自动部署和配置服务和应用程序环境,包括 Azure 资源管理器模板、Azure RBAC 控制措施和策略。

责任:客户

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

指导:Azure Lighthouse 支持 Microsoft Defender for Cloud 提供的以下特定于服务的策略,用于审核和强制实施 Azure 资源的配置。 这可以在 Microsoft Defender for Cloud 或 Azure Policy 计划中进行配置。

责任:客户

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

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

责任:客户

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

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

责任:Microsoft

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

指导:根据需要,对 Azure 资源进行渗透测试或红队活动,并确保修正所有关键安全发现。 请遵循 Microsoft 云渗透测试互动规则,确保你的渗透测试不违反 Microsoft 政策。 使用 Microsoft 红队演练策略和执行,以及针对 Microsoft 托管云基础结构、服务和应用程序执行现场渗透测试。

责任:共享

终结点安全性

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

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

指导:Azure Lighthouse 不会部署任何面向客户的计算资源,这些资源需要终结点检测和响应 (EDR) 保护。 Azure Lighthouse 服务的基本基础结构由 Microsoft 处理。

责任:Microsoft

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

指导:Azure Lighthouse 不会部署任何面向客户的计算资源,这些资源可以使用反恶意软件解决方案进行配置。 Azure Lighthouse 服务的基本基础结构由 Microsoft 处理,其中包括管理任何已安装的反恶意软件。

责任:Microsoft

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

指导:Azure Lighthouse 不会部署任何面向客户的计算资源,这些资源可以使用反恶意软件解决方案进行配置。 Azure Lighthouse 服务的基本基础结构由 Microsoft 处理,其中包括管理任何已安装的反恶意软件。

责任:Microsoft

后续步骤