适用于 Azure Data Box 的 Azure 安全基线

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

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

注意

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

网络安全

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

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

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

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

默认情况下,Data Box 使用 TLS 1.2。 如果任何系统尚未启用 TLS 1.2,Data Box 允许通过本地 UI 启用 TLS 1.1/1.0。

支持使用虚拟网络的存储帐户。 是否要允许 Data Box 使用受保护的存储帐户? 然后,在存储帐户网络的防火墙设置中启用受信任的服务。

责任:客户

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

指导:按照 DNS 安全最佳做法操作。 这些做法可缓解常见攻击,例如:

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

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

Data Box 建议自带证书。 如果选择使用设备生成的默认证书,则需要按照本文档中所述的准则操作。

添加有关客户可以管理的 DNS 配置的参考。

责任:客户

标识管理

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

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

指导:Data Box 将本地身份验证用于:

  • 通过设备解锁密钥控制设备访问。

  • SMB 凭据,用于将数据复制到和复制出设备。

  • Azure 存储帐户密钥,以通过 REST API 访问 Data Box。

  • 用于 NFS 访问的 IP 地址配置。

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

责任:客户

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

指导:Azure Data Box 建议使用 Azure Active Directory (Azure AD) 在资源级别创建权限受限的服务主体。 使用证书凭据配置服务主体,然后回退到客户端机密。 在这两种情况下,都可以将 Azure Key Vault 与 Azure 托管标识结合使用,以便运行时环境(例如 Azure 函数)可以从密钥保管库中检索凭据。

凭借 Data Box,可以使用自己的密钥进行加密。 还可以对设备和共享项目使用自己的密码。

责任:共享

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

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

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

此管理包括:

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

凭借标识和访问管理,单一登录 (SSO) 可管理对组织数据和资源的访问并进行安全保护。 该访问同时适用于本地和云。 将所有用户、应用程序和设备连接到 Azure AD。 Azure AD 提供无缝、安全的访问,且可见性和控制能力更强。

Data Box 使用 Azure AD 对订阅进行身份验证,以创建 Data Box 资源。

责任:客户

特权访问

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

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

指导:默认情况下,没有高特权用户。 在极少数情况下,可能需要打开支持会话(使用较高的特权)。 此支持会话需要与 Microsoft 支持人员协调。

客户无需使用和管理 Azure AD 高特权帐户,例如 Data Box 的本地级管理员帐户。

责任:共享

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

指导:要创建和管理 Data Box 资源,客户需要使用基于 Azure AD 的订阅登录。

可以使用以下内置角色:

  • Data Box 读取者。 此角色对作用域定义的订单具有只读访问权限。 此角色只能查看订单详细信息。 无法访问与存储帐户相关的其他详细信息。 也无法编辑订单详细信息,例如地址。

  • Data Box 参与者。 如果客户已对存储帐户具有写入权限,则此角色可以创建将数据转移到该帐户的订单。 如果客户没有对某个存储帐户的访问权限,则无法创建将数据复制到该帐户的 Data Box 订单。 此角色不定义任何与存储帐户相关的权限。 它不会授予对存储帐户的访问权限。

  • Data Box 资源创建和管理

  • Data Box 的内置 RBAC 角色

责任:共享

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

指导:Azure Data Box 通过与 Azure RBAC 集成来管理其资源。

首次创建 Data Box 订单时,可以控制谁能够访问订单。 在不同作用域内设置 Azure 角色,以控制对 Data Box 订单的访问。

可为 Azure Data Box 服务定义的两个内置角色为:

  • Data Box 读取者。 此角色对作用域定义的订单具有只读访问权限。 此角色只能查看订单详细信息。 无法访问与存储帐户相关的任何其他详细信息。 也无法编辑订单详细信息,例如地址。

  • Data Box 参与者。 如果客户已对存储帐户具有写入权限,则此角色可以创建将数据转移到该帐户的订单。 如果客户没有对某个存储帐户的访问权限,则无法创建将数据复制到该帐户的 Data Box 订单。 此角色不定义任何与存储帐户相关的权限。 也不会授予对存储帐户的访问权限。

  • Data Box 资源的内置 RBAC 角色

责任:共享

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

指导:在 Microsoft 需要访问客户数据的支持方案中,Azure Data Box 支持客户密码箱。 可通过客户密码箱提供的界面查看以及批准或拒绝客户数据访问请求。

责任:共享

数据保护

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

DP-2:保护敏感数据

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

  • Azure RBAC。
  • 基于网络的访问控件。
  • Azure 服务中的特定控件(例如加密)。

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

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

Data Box 对所有静态数据和所有传输中的数据进行加密。

责任:共享

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

指导:Data Box 支持 SMB 加密。 NFS 也受支持,但客户需要在使用此协议时预先加密其数据。

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

Azure Data Box 支持使用 TLS 1.2 版或更高版本加密传输中的数据。

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

  • SSL
  • TLS
  • SSH

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

责任:共享

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

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

默认情况下,Azure 为静态数据提供加密。 对于高度敏感的数据,可以在所有可用的 Azure 资源上实施额外的静态加密。 默认情况下,Azure 会管理加密密钥。 但还可通过它来为某些 Azure 服务管理自己的密钥(客户管理的密钥)以满足法规要求。

责任:共享

资产管理

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

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

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

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

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

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

责任:客户

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

指导:确保安全团队有权访问 Azure 上持续更新的资产清单,例如 Azure Data Box。 安全团队通常需要此清单来评估其组织遇到新兴风险的可能性。 这些团队还需要此清单作为持续进行安全改进的输入。

创建 Azure AD 组,以包含组织的授权安全团队。 然后分配组对所有 Azure Data Box 资源的读取权限。 可以通过在订阅中分配单个高级角色来简化此流程。

Azure Data Box 不使用标记。 客户无法应用或使用资源元数据的标记有条理地将它们组织成分类。

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

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

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

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

责任:客户

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

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

责任:客户

日志记录和威胁检测

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

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

指导:Azure Data Box 生成面向客户的资源日志,这些日志可用于威胁检测。

Azure Data Box 不会生成可用于威胁检测的日志。 无法将这些日志转发到 SIEM 工具进行监视和发出警报。

责任:共享

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

指导:Azure AD 提供以下用户日志,可以在 Azure AD 报告中查看。 对于更复杂的监视和分析用例,可以将它们与 Azure Monitor、Microsoft Sentinel 或其他 SIEM/监视工具集成。

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

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

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

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

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

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

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

责任:客户

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

指导:Azure Data Box 不用于部署到虚拟网络。

不能使用 NSG 来强制执行或传递进出 Azure Data Box 资源的流量。 出于此原因,不能为 Azure Data Box 配置 NSG 流日志记录。

Azure Data Box 会记录它为客户访问处理的所有网络流量。

Azure Data Box 不允许配置或向客户公开 DNS 日志记录。

责任:共享

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

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

Data Box 生成以下资源日志:

  • 复制日志
  • 审核日志
  • 按导入顺序的 BOM 文件
  • 按导出顺序的详细日志

Azure Data Box 还为本地管理帐户生成安全审核日志。

责任:共享

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

指导:Data Box 使用默认的 Microsoft NTP 服务器。 将 Azure Data Box 连接到可以访问默认 NTP 服务器的网络。 否则,如果断开连接,Azure Data Box 时间可能会偏移。

责任:共享

安全状况和漏洞管理

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

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

指导:Azure Data Box 不支持 Microsoft Defender for Cloud 中的特定策略。

可以设置 Azure 策略来为 Azure Data Box 启用双重加密。 或者,在为 Data Box 下订单时,请求为设备上的静态数据启用双重加密。

责任:客户

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

指导:Data Box 在订单的整个生存期内配置和锁定设备的所有安全设置。

责任:Microsoft

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

指导:不适用;Azure Data Box 不支持任何漏洞评估。

Microsoft 对 Azure Data Box 进行内部漏洞扫描。

责任:Microsoft

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

指导:Microsoft 管理所有第三方软件更新。

责任:Microsoft

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

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

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

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

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

责任:客户

终结点安全性

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

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

指导:Azure Data Box 已启用 Windows Defender。

责任:Microsoft

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

指导:Microsoft 启用 Windows Defender 并维护 Azure Data Box 上的更新。

责任:Microsoft

备份和恢复

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

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

指导:定期确保可以还原已备份的客户管理的密钥。

责任:客户

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

指导:采用适当的措施来防止密钥丢失和恢复丢失的密钥。 在 Azure 密钥保管库中启用软删除和清除保护。 此操作可保护密钥免遭意外或恶意删除。

责任:客户

后续步骤