Site Recovery 的 Azure 安全基线

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

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

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

注意

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

网络安全

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

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

指导:Microsoft Azure Site Recovery 不支持直接部署到虚拟网络中。 无法将某些网络功能应用于产品/服务的资源,例如:

  • 网络安全组 (NSG)。
  • 路由表。
  • 其他网络相关设备,例如 Azure 防火墙。

对于需要与 Site Recovery 通信的 Azure 虚拟机,允许对端口 443 进行出站访问以访问某些区域内的完全限定的域名 (FQDN),或者允许在使用服务标记时对端口 443 进行出站访问。

责任:客户

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

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

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

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

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

责任:客户

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

指导:使用 Azure 专用链接,无需通过 Internet 即可从虚拟网络对恢复服务保管库进行专用访问。 专用访问是另一种深度防御措施,可与 Azure 服务提供的身份验证和流量安全性措施搭配使用。Site Recovery 无法配置虚拟网络服务终结点。 它是一个多租户平台即服务, (PaaS) 服务。

责任:客户

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

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

责任:客户

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

指导:Site Recovery 不会公开其基础 DNS 配置。 Microsoft 会维护这些设置。

责任:Microsoft

标识管理

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

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

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

  • Microsoft Cloud 资源,例如:

    • Azure 门户
    • 基础结构即服务 (IaaS)
    • PaaS
    • 软件即服务 (SaaS) 应用程序
  • 组织的资源,例如 Azure 上的应用程序或公司网络资源。在组织的云安全实践中,将保护 Azure AD 列为高优先级。 Azure AD 提供标识安全分数,让你可以根据 Microsoft 的最佳做法建议来评估标识安全状况。 使用此分数估量配置与最佳做法建议的匹配程度。 然后改进安全状况。注意:Azure AD 支持外部标识。 没有 Microsoft 帐户的用户可以使用其外部标识登录其应用程序和资源。 Site Recovery 提供三个用于控制 Site Recovery 管理操作的内置角色:

  • SiteRecovery 参与者

  • SiteRecovery 操作员

  • SiteRecovery 读取者

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

责任:客户

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

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

责任:客户

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

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

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

可以使用 Azure AD 对 Site Recovery 进行身份验证的标识包括:

  • 企业标识,例如员工。
  • 外部标识,例如:
    • 合作伙伴
    • 供应商
    • 供应商

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

  • 用户
  • 应用程序
  • 设备

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

责任:客户

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

指南:若要确定用于 Site Recovery 的 Azure 资源管理器模板中的凭据,请实施 Azure DevOps 凭据扫描程序。 凭据扫描程序还会建议将发现的凭据转移到更安全的位置,例如 Azure Key Vault。 对于 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:定期审查和协调用户访问权限

指导:Site Recovery 使用 Azure AD 帐户和 Azure RBAC 来向其资源授权。 请定期审查帐户和访问角色分配,确保用户帐户及其访问权限有效。 使用 Azure AD 和访问评审来审查:

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

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

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

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

责任:客户

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

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

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

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

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

可以使用以下方法集中管理受保护的工作站以强制执行安全配置:

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

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

责任:客户

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

指导:Site Recovery 通过与 Azure RBAC 集成来管理其资源。 凭借 Azure RBAC,可通过角色分配来管理 Azure 资源访问。 将这些角色分配给:

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

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

  • Azure CLI
  • Azure PowerShell
  • Azure 门户

始终将通过 Azure RBAC 分配给资源的特权限制为角色所需的特权。 此做法是对 Azure AD PIM 的 JIT 方法的补充,应定期进行审查。

Site Recovery 与 Azure RBAC 集成,以允许使用内置和自定义角色,使你可以管理对资源的访问权限。 使用内置角色授予权限。 仅在必要时创建自定义角色。

责任:客户

数据保护

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

DP-1:对敏感数据进行发现、分类和标记

指导:Site Recovery 不提供对数据进行分类的功能。 可以自行整理数据,方法如下:

  • 使用不同的恢复服务保管库。
  • 根据内容将标记附加到这些保管库。

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

责任:客户

DP-2:保护敏感数据

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

  • Azure RBAC。
  • 基于网络的访问控件。
  • Azure 服务中的特定控件,例如 SQL 和其他数据库中的加密控件。 为确保访问控制的一致性,请将所有类型的访问控制与企业分段策略保持一致。 还要根据敏感数据或业务关键型数据和系统的位置确定企业分段策略。

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

责任:共享

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

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

Site Recovery 支持通过传输层安全性 (TLS) v1.2 或更高版本来加密传输中数据。

虽然加密对于专用网络上的流量来说是可选的,但它对于外部和公共网络上的流量至关重要。 对于 HTTP 流量,请确保连接到 Azure 资源的任何客户端都可以协商 TLS 1.2 版或更高版本。 对于远程管理,请使用适用于 Linux 的安全外壳 (SSH),而不是未加密的协议。 也可以使用适用于 Windows 的远程桌面协议 (RDP) 和 TLS。 随后将其禁用:

  • 已过时版本:
    • 安全套接字层(Secure Sockets Layer,SSL)
    • TLS
    • SSH
  • 弱密码

默认情况下,Azure 为在 Azure 数据中心之间传输的数据提供加密。

责任:客户

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

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

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

责任:客户

资产管理

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

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

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

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

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

注意:若要了解工作负荷和服务,可能需要其他权限。

责任:客户

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

指导:确保安全团队可以访问 Azure 上不断更新的资产清单,如 Site Recovery。 安全团队通常需要此清单来评估其组织遇到新兴风险的可能性。 清单也是持续进行安全改进的一种输入。 创建 Azure AD 组,以包含组织的授权安全团队。 向团队分配对所有 Azure 应用程序配置资源的读取访问权限。 可以使用订阅中的单个高级角色分配来简化这些操作。

要有条理地分类整理这些资源,请将标记应用于:

  • Azure 资源
  • 资源组
  • 订阅

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

责任:客户

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

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

责任:客户

日志记录和威胁检测

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

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

指导:使用 Microsoft Defender for Cloud 的内置威胁检测功能。 为 Site Recovery 资源启用 Microsoft Defender。 Microsoft Defender for Site Recovery 提供另一层安全智能。 它会检测以非寻常和可能有害方式访问或恶意利用 Site Recovery 资源的企图。

Site Recovery 会生成活动和资源日志。 使用这些日志,可以审核针对 Azure 资源的操作并检测威胁。 将 Site Recovery 中的所有日志转发到可用于设置自定义威胁检测的 SIEM。 监视不同类型的 Azure 资产,以发现潜在的威胁和异常情况。 专注于获取高质量警报以减少误报,便于分析人员进行分类整理。 可从日志数据、代理或其他数据探寻警报来源。

责任:客户

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

指导:Azure AD 提供以下用户日志:

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

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

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

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

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

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

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

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

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

责任:客户

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

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

为 Site Recovery 启用 Azure 资源日志。 使用 Microsoft Defender for Cloud 和 Azure Policy 启用资源日志和日志数据收集功能。 这些日志可能对之后调查安全事件和执行取证演练至关重要。

责任:客户

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

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

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

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

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

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

另外,启用 Microsoft Sentinel 或第三方 SIEM,并在其中加入数据。 许多组织选择将 Microsoft Sentinel 用于“热”数据(频繁使用的数据)。 然后,这些组织可能选择将 Azure 存储用于不太常用的“冷”数据。

责任:客户

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

指导:对于用于存储 Site Recovery 日志的存储帐户或 Log Analytics 工作区,请根据组织的合规性法规设置日志保留期。

在 Azure Monitor 中,根据组织的合规性规则设置 Log Analytics 工作区保持期。 使用以下项中的帐户进行长期存储和存档存储:

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

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

责任:客户

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

指导:Site Recovery 不支持配置你自己的时间同步源。 Site Recovery 服务依赖于 Microsoft 时间同步源。 它并未向客户公开,以供其进行配置。

责任:Microsoft

安全状况和漏洞管理

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

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

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

若要监视和强制实施恢复服务保管库的安全配置,请分配内置和自定义 Azure Policy 定义。 内置定义是否不符合要求? 然后,使用“Microsoft.RecoveryServices”命名空间中的 Azure Policy 别名。 通过使用这些别名,可以创建自定义策略来审核或强制实施恢复服务保管库的配置。

使用单个 Azure 蓝图定义自动部署和配置服务及应用程序环境,包括:

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

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

责任:客户

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

指导:Site Recovery 允许你使用 Azure Policy 监视和强制实施其配置。 配置包括以下项的设置:

  • 保管库,包括使用保管库的专用终结点。
  • Azure 工作负荷上的灾难恢复 (DR) 产品/服务。
  • 诊断部署。

监视和强制实施恢复服务保管库的安全配置。 分配内置和自定义 Azure Policy 定义。 内置定义是否不符合要求? 然后,在“Microsoft.RecoveryServices”命名空间中使用 Azure Policy 别名创建自定义策略,以审核或强制实施恢复服务保管库的配置。

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

  • 虚拟机
  • 容器
  • 其他

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

责任:客户

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

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

责任:Microsoft

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

指导:Site Recovery 无法自动支持软件修正。 对于支持 Azure 备份的基础平台,Microsoft 会处理:

  • 漏洞
  • 个评估
  • 修正

责任:Microsoft

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

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

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

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

责任:客户

备份和恢复

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

BR-2:加密备份数据

指导:Site Recovery 支持静态加密工作负荷数据。 对于云工作负荷,默认使用存储服务加密和 Microsoft 托管密钥静态加密数据。 为满足法规要求,Site Recovery 还提供选项用于管理你自己的密钥(客户管理的密钥)。

责任:客户

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

Azure Policy 内置定义 - Microsoft.RecoveryServices

名称
(Azure 门户)
说明 效果 版本
(GitHub)
应为虚拟机启用 Azure 备份 启用 Azure 备份,确保对 Azure 虚拟机提供保护。 Azure 备份是一种安全且经济高效的 Azure 数据保护解决方案。 AuditIfNotExists、Disabled 2.0.0

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

指导:Site Recovery 能够恢复计算工作负荷。 但它不支持备份其自身的任何数据。 客户可以使用客户管理的密钥来加密其存储的数据。 使用客户管理的密钥时,请确保你可以还原这些密钥。 此外,还可以使用存储密钥的每个 Key Vault 来启用软删除。

责任:客户

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

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

责任:客户

后续步骤