适用于 Azure Monitor 的 Azure 安全基线

此安全基线将 Azure 安全基准版本 2.0 中的指导应用于 Azure Monitor。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容按“安全控件”分组,此类控件按适用于 Azure Monitor 的 Azure 安全基准和相关的指南定义。

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

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

注意

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

网络安全

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

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

指导:部署 Microsoft Azure Monitor 资源时,需创建或使用现有虚拟网络。 确保所有 Azure 虚拟网络都遵循与业务风险相匹配的企业分段原则。 是否有可能会为组织带来更高风险的系统? 那就在自己的虚拟网络中隔离该系统,并使用网络安全组 (NSG) 或 Azure 防火墙,充分保护系统的安全。

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

配置 Monitor 以使用传输层安全性 (TLS) 1.2。 可以通过 Azure 资源管理器模板(ARM 模板)在部署 Monitor 资源时设置此配置。 通过 Azure Policy 强制实施配置。 但如果禁用旧协议,则可能会影响服务或应用程序的后向兼容性。

若要与 Log Analytics 工作区和 Application Insights 组件通信,网络中的传出流量需要访问终结点列表。 通常,通过端口 443 或端口 80 进行通信。 某些 Application Insights 功能(如可用性测试)需要允许入站流量进入你的网络。

责任:客户

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

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

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

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

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

在对等互连你的网络后,建议使用专用链接以私密方式与 Monitor 资源通信。 请参阅“设计专用链接设置”,以规划如何将其应用于网络拓扑。

责任:客户

NS-3:建立对 Azure 服务的专用网络访问

指导:启用专用链接,以便通过虚拟网络中的专用终结点访问 Azure 服务型软件 (SaaS) 服务(如 Monitor)和 Azure 托管的客户/合作伙伴服务。 虚拟网络与服务之间的流量将通过 Microsoft 主干网络,因此不会从公共 Internet 泄露。

下面是管理访问权限的一些提示:

  • 若要允许流量到达 Monitor,请使用“AzureMonitor”服务标记以允许入站和出站流量通过 NSG。
  • 若要允许“可用性监视”测试流量到达 Monitor,请使用“ApplicationInsightsAvailability”服务标记以允许所有入站流量通过 NSG。
  • 若要允许警报通知到达客户终结点,请使用“ActionGroup”服务标记以允许入站流量通过 NSG。

使用虚拟网络规则,可以将 Monitor 设置为仅接收来自虚拟网络中所选子网的通信。

是否有计算机无法直接连接到 Internet? 那就使用 Log Analytics 网关,该网关可以将数据发送到 Monitor 中的 Log Analytics 工作区。 此做法意味着无需将这些计算机连接到 Internet。

责任:客户

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

指导:Monitor 可以监视部署到你的网络的资源。 因此,你的网络必须允许传出流量到达 Monitor 终结点(如日志引入)。 建议在你的网络和 Monitor 资源之间使用专用链接。 如果不想使用专用链接,仍可将你网络的传出流量限定到 Monitor 终结点。 只需在 NSG 或 Azure 防火墙上使用 Azure 虚拟网络服务标记即可。

创建安全规则时,使用服务标记来替代特定 IP 地址。 通过在相应规则的源或目标字段中指定服务标记名称,可允许或拒绝相应服务的流量。 Microsoft 管理服务标记包含的地址前缀。 当地址发生变化时,它会自动更新服务标记。

责任:客户

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

指导:遵循域名系统 (DNS) 安全的最佳做法,以防范常见攻击,例如:

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

Monitor 通常不需要你配置 DNS 或以特定方式进行管理。 但如果使用 Monitor 专用链接,则必须更新 DNS。 然后 DNS 区域才将 Monitor 终结点映射到专用 IP 地址。

将 Azure DNS 用作权威 DNS 服务时,防止 DNS 区域和记录遭受意外或恶意修改。 使用 Azure 基于角色的访问控制 (Azure RBAC) 和资源锁来应用保护。

责任:客户

标识管理

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

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

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

  • Microsoft Cloud 资源,例如:
    • Azure 门户
    • Azure 存储
    • Azure 虚拟机(Linux 和 Windows)
    • Azure Key Vault
    • 平台即服务 (PaaS)
    • 软件即服务 (SaaS) 应用程序
  • 你的组织的资源,例如 Azure 上的应用程序,或公司网络资源。

在组织的云安全做法中,将保护 Azure AD 列为高优先级事项。 Azure AD 提供标识安全分数。 此分数可帮助你根据 Microsoft 的最佳做法建议评估标识安全状况。 使用此分数估量配置与最佳做法建议的匹配程度。 然后改进安全状况。

注意:Azure AD 支持外部标识。 没有 Microsoft 帐户的用户可以使用其外部标识登录其应用程序和资源。

责任:客户

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

指导:Monitor 支持使用托管标识来获取其 Azure 资源。 若要访问其他资源,不需要创建服务主体,只需将托管标识用于 Monitor。 Monitor 可以对支持 Azure AD 身份验证的 Azure 服务和资源进行本机身份验证。 通过预定义的访问授权规则进行身份验证。 它不使用在源代码或配置文件中硬编码的凭据。

责任:客户

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

指导:Monitor 使用 Azure AD 对以下各项提供标识和访问管理:

  • Azure 资源
  • 云应用程序
  • 本地应用程序

标识和访问管理包括企业标识,例如员工。 还包括外部标识,例如:

  • 合作伙伴
  • 供应商
  • 供应商

凭借此安排,单一登录 (SSO) 可管理对组织数据和资源的访问并进行安全保护。 SSO 在本地和云中都适用。 为了实现无缝、安全的访问,并提高可见性和控制能力,请将以下所有对象连接到 Azure AD:

  • 用户
  • 应用程序
  • 设备

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

责任:客户

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

指导:使用 ARM 模板部署 Monitor,此模板可以包含用代码定义的机密。 若要以代码模板形式在 Monitor 基础结构中标识凭据,请实现凭据扫描程序。 凭据扫描程序还会建议你将发现的凭据转移到更安全的位置,例如密钥保管库。

对于 GitHub,可以使用本机机密扫描功能。 此功能可标识代码中的凭据或其他形式的机密。

责任:客户

特权访问

有关详细信息,请参阅 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 还会生成安全警报。

责任:客户

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

指导:为确保用户帐户及其访问权限有效,Monitor 定期使用 Azure AD 帐户执行以下操作:

  • 管理其资源。
  • 审查用户帐户。
  • 访问权限分配。

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

  • 组成员身份
  • 对企业应用程序的访问权限
  • 角色分配

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

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

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

责任:客户

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

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

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

使用高度安全的用户工作站或 Azure Bastion 执行管理任务。 若要部署安全的托管用户工作站,请使用以下一项或多项:

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

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

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

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

责任:客户

数据保护

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

DP-2:保护敏感数据

指导:通过使用以下工具限制访问来保护敏感数据:

  • Azure RBAC
  • 基于网络的访问控制
  • Azure Monitor 基于表的 RBAC 控制。

为确保访问控制的一致性,请将所有类型的访问控制与企业分段策略保持一致。 还要根据敏感数据或业务关键型数据和系统的位置确定企业分段策略。

Microsoft 将 Microsoft 托管的基础平台中的所有客户内容视为敏感内容。 它可保护客户数据,以防丢失和泄露。 为了始终确保 Azure 中客户数据的安全,Microsoft 实施了一些默认的数据保护控制机制和功能。

责任:客户

DP-3:监视未经授权的敏感数据传输

指导:不适用;Microsoft 将 Microsoft 托管的基础平台中的所有客户内容视为敏感内容。 Microsoft 会竭尽全力保护客户数据,以防丢失和泄露。 为了确保 Azure 中的客户数据保持安全,Microsoft 实施和维护一套可靠的数据保护控制和功能。

责任:共享

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

指导:若要对访问控制进行补充,可使用加密保护传输中的数据免受“带外”攻击(如流量捕获)。 这样,攻击者就无法轻易读取或修改数据。

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

虽然此功能对于专用网络上的流量来说是可选的,但对于外部和公共网络上的流量是至关重要。 对于 HTTP 流量,请确保连接到 Azure 资源的客户端可以协商 TLS 1.2 版或更高版本。 对于远程管理,不是使用未加密的协议,而是使用以下协议之一:

  • 安全外壳 (SSH)(对于 Linux)
  • 远程桌面协议 (RDP) 和 TLS(对于 Windows)

禁用弱密码,以及以下过时的版本和协议:

  • 安全套接字层(Secure Sockets Layer,SSL)

  • TLS

  • SSH

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

责任:客户

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

指导:为了对访问控制进行补充,Monitor 可对静态数据加密。 此行为可使用加密防止“带外”攻击(如访问基础存储)。 这有助于确保攻击者无法轻易读取或修改数据。

默认情况下,Azure 为静态数据提供加密。 对于高度敏感的数据,可以在所有可用的 Azure 资源上实施额外的静态加密。 默认情况下,Azure 会管理加密密钥。 而且还为某些 Azure 服务提供管理自己的密钥(客户管理的密钥)的选项。

责任:客户

资产管理

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

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

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

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

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

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

责任:客户

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

指导:向安全团队授予对 Azure 上不断更新的资产清单(例如 Monitor)的访问权限。 安全团队通常需要此清单来评估其组织遇到新兴风险的可能性。 此清单还有助于持续提高安全性。 创建 Azure AD 组,以包含组织的授权安全团队。 然后向该组分配对所有 Monitor 资源的读取访问权限。 若要简化此过程,可在订阅中分配单个高级角色。

若要按逻辑组织分类,请将标记应用于 Azure:

  • 资源
  • 资源组
  • 订阅

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

Monitor 不允许在其资源上运行应用程序或安装软件。

责任:客户

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

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

责任:客户

日志记录和威胁检测

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

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

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

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

  • 日志数据
  • 代理
  • 其他数据

针对这些日志的警报会触发敏感日志查询、日志清除或删除操作。

责任:客户

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

指导:Azure Active Directory (Azure AD) 提供以下用户日志:

  • 登录。登录报告提供有关托管应用程序的使用情况和用户登录活动的信息。

  • 审核日志。 审核日志为各种功能在 Azure AD 中所做的所有更改提供可跟踪性。 示例包括对 Azure AD 中任何资源所做的更改,例如添加或删除:

    • 用户
    • “应用”
    • 角色
    • 策略
  • 风险登录。风险登录指可能由非用户帐户合法所有者的人员进行的登录尝试。

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

可以在 Azure AD 报告中查看这些日志。 对于更复杂的监视和分析用例,可以将日志与以下项集成:

  • 监视
  • Microsoft Sentinel
  • 其他 SIEM/监视工具

Microsoft Defender for Cloud 还可以触发有关某些可疑活动的警报。 这些活动包括身份验证尝试失败次数过多或使用订阅中已弃用的帐户。 除了基本的安全运行监视以外,Microsoft Defender for Cloud 的威胁防护模块还可以从以下资源中收集更多深层安全警报:

  • 单独的 Azure 计算资源(虚拟机、容器和应用服务)。
  • 数据资源(SQL DB 和存储)。
  • Azure 服务层。

通过此功能可查看各个资源中的帐户异常情况。

责任:客户

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

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

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

应用安全分析支持:

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

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

Monitor 不会生成或处理需要启用的 DNS 查询日志。

责任:客户

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

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

Monitor 操作组目前不生成 Azure 资源日志。

责任:客户

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

Azure Policy 内置定义 - microsoft.insights

名称
(Azure 门户)
说明 效果 版本
(GitHub)
应启用 Azure Data Lake Store 中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用 Azure 流分析中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用 Batch 帐户中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用 Data Lake Analytics 中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用事件中心内的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用 IoT 中心内的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 3.0.1
应启用 Key Vault 中的资源日志 对启用资源日志进行审核。 使用此策略可在发生安全事件或网络受到安全威胁时重新创建用于调查的活动线索 AuditIfNotExists、Disabled 5.0.0
应启用逻辑应用中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用搜索服务中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0
应启用服务总线中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0

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

指导:集中记录存储和分析来实现关联。 对于每个日志源,分配以下内容:

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

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

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

在 Monitor 中,使用 Log Analytics 工作区进行查询和分析。 将存储帐户用于长期存储和存档存储。

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

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

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

责任:客户

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

指导:是否有存储帐户或 Log Analytics 工作区用于存储 Monitor 日志? 那就根据组织的合规性法规设置日志保留期。

在 Monitor 中,可根据组织的合规性法规设置 Log Analytics 工作区保留期。 对于长期存储和存档存储,使用以下组件之一:

  • Azure 存储帐户
  • Azure Data Lake Storage 帐户
  • Log Analytics 工作区

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

责任:客户

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

指导:Monitor 不支持配置你自己的时间同步源。 Monitor 服务依赖于客户无法配置的 Microsoft 时间同步源。

责任:Microsoft

安全状况和漏洞管理

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

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

指导:是否需要审核和强制执行 Azure 资源配置? Monitor 支持 Microsoft Defender for Cloud 中提供的以下特定于服务的策略。 可以在 Microsoft Defender for Cloud 或 Azure Policy 计划中配置这些策略。

  • 应在 Azure 云服务(外延支持)角色实例上安装 Log Analytics 代理。 你的订阅应启用 Log Analytics 代理自动预配。
  • 应使用默认工作区启用 Microsoft Defender for Cloud 在订阅中自动预配 Log Analytics 代理。
  • 应使用自定义工作区启用 Microsoft Defender for Cloud 在订阅中自动预配 Log Analytics 代理。
  • Log Analytics 代理应安装在虚拟机规模集上,用于 Microsoft Defender for Cloud 监视。
  • Log Analytics 代理应安装在虚拟机上,用于 Microsoft Defender for Cloud 监视。
  • 应在计算机上解决 Log Analytics 代理运行状况问题。
  • 应为 Microsoft Defender for Cloud 数据部署导出到 Log Analytics 工作区功能。

Monitor 通过引入和存储提供更多安全数据策略:

  • 启用专用链接的 Application Insights 组件应当使用适用于探查器和调试程序的“自带存储”(BYOS) 帐户。
  • 工作簿应保存到你控制的存储帐户。
  • 应将 Monitor 中已保存的查询保存在客户存储帐户中以进行日志加密。
  • 保存有活动日志的容器的存储帐户必须通过创建自己的密钥 (BYOK) 保护措施进行加密。
  • Azure Monitor 日志群集应使用客户管理的密钥进行加密。
  • 应创建启用了基础结构加密(双重加密)的 Azure Monitor 日志群集。

使用 Azure 蓝图通过单个蓝图定义自动部署和配置服务和应用程序环境。 这些服务和环境包括:

  • ARM 模板
  • Azure RBAC 控制
  • 策略

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

责任:客户

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

指导:使用 Microsoft Defender for Cloud 监视配置基线。 使用 Azure Policy 中的“Deny”和“DeployIfNotExists”策略定义在 Azure 计算资源中强制执行安全配置,这些资源包括:

  • 虚拟机
  • 容器
  • 其他

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

责任:客户

PV-4:为计算资源维护安全配置

指导:不适用;此项指导适用于计算资源。

责任:客户

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

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

责任:Microsoft

PV-7:快速自动修正软件漏洞

指导:客户可以通过安装代理在 Azure 和非 Azure 虚拟机中启用 Azure Monitor。 若要修正操作系统中运行的代理中所有可能的漏洞,请定期升级代理。

Microsoft 建议始终在扩展部署中选择自动更新。 用户无法选择退出带有安全或关键 bug 修补程序的修补程序更新。

默认情况下,在 Azure 虚拟机中配置适用于 Windows 和 Linux 的 Log Analytics 代理,以便升级。 然后,可以快速部署包含安全或关键 bug 修补程序的任何更新。

责任:客户

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

指导:根据需要,对 Azure 资源执行渗透测试或红队活动。 确保修正发现的所有关键安全问题。 为确保渗透测试不违反 Microsoft 策略,需遵循 Microsoft Cloud 渗透测试参与规则。 使用 Microsoft 策略并针对 Microsoft 管理的以下各项执行红队演练和现场渗透测试:

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

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

责任:客户

备份和恢复

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

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

指导:使用 Azure 资源管理器,通过 JavaScript 对象表示法 (JSON) 模板导出 Monitor 和相关资源。 可以使用此 ARM 模板来备份 Monitor 和相关配置。 使用 Azure 自动化自动运行备份脚本。

Monitor 会对所有客户数据进行内部备份。 除了存储在 Log Analytics 工作区的日志数据以外,客户不必执行任何操作。 可以使用导出功能备份此数据,其中包括将数据存储在 Log Analytics 工作区的 Application Insights 内容。

责任:客户

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

指导:确保你可以定期还原 Azure 资源管理器支持的模板文件。 测试备份的客户管理的密钥是否还原。

责任:客户

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

指导:采用适当的措施来防止密钥丢失和恢复丢失的密钥。 为防止意外或恶意删除密钥,需在 Key Vault 中启用软删除和清除保护。

责任:客户

后续步骤