服务总线的 Azure 安全基线

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

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

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

注意

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

网络安全

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

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

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

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

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

  • 安全套接字层 (SSL) 和传输层安全性 (TLS) 版本 1 (TLSv1)。
  • 服务器消息块 (SMB) 版本 1 (SMBv1)。
  • LAN Manager (LM) 和 NT LAN Manager (NTLM) 版本 1 (NTLMv1)。
  • wDigest。
  • 未签名的轻型目录访问协议 (LDAP) 绑定。
  • Kerberos 中的弱密码。

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

责任:Microsoft

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

指南:使用 Azure 专用链接,无需通过 Internet 即可从虚拟网络对服务总线进行专用访问。

专用访问是 Azure 服务提供的针对身份验证和流量安全性的另一项深度防护措施。

使用 Azure 虚拟网络服务终结点提供对服务总线的安全访问。 此访问经过 Azure 主干网络上的优化路由,无需经过 Internet。

责任:客户

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

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

责任:客户

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

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

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

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

责任:客户

标识管理

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

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

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

  • Microsoft Cloud 资源,例如:

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

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

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

责任:客户

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

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

是否要使用证书凭据配置服务主体,并回退到客户端密码? 然后使用 Azure AD 在资源级别创建权限受限的服务主体。 在这两种情况下,都可以将 Key Vault 与 Azure 托管标识一起使用。 运行时环境(例如 Azure 函数)可以从密钥保管库中检索凭据。

责任:客户

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

指南:服务总线使用 Azure AD 向以下各项提供标识和访问管理:

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

此管理适用于企业标识,例如员工。 它也适用于外部标识,包括:

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

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

  • 用户
  • 应用程序
  • 设备

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

责任:客户

特权访问

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

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

指南:不适用;服务总线不使用管理帐户。

责任:客户

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

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

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

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

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

Azure AD 报告提供日志来帮助发现过时的帐户。 若要协助评审过程,还可使用 Azure AD Privileged Identity Management (PIM) 创建访问评审报表工作流。

还可以配置 Azure AD PIM 来实现以下操作:

  • 创建过多管理员帐户时发出警报。
  • 标识过期或配置不当的管理员帐户。

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

责任:客户

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

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

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

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

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

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

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

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

责任:客户

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

指南:服务总线通过与 Azure RBAC 集成来管理其资源。 凭借 Azure RBAC,可通过角色分配来管理 Azure 资源访问。 将这些角色分配给:

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

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

  • Azure CLI
  • Azure PowerShell
  • Azure 门户

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

使用内置角色授予权限。 仅在必要时创建自定义角色。

责任:客户

数据保护

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

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

指南:监视是否存在未经授权将数据传输到企业监管和控制范围以外位置的行为。 这种做法通常涉及监视那些可能意味着未经授权的数据外泄的异常活动(大型或异常传输)。

Microsoft Defender for Storage 和 Microsoft Defender for SQL 在信息传输异常时可发出警报,这些异常传输可能指示未经授权传输了敏感信息。

Azure 信息保护提供的监视功能针对已分类并标记的信息。

如果需要符合数据丢失防护 (DLP) 规范,可以使用基于主机的 DLP 解决方案。 此解决方案强制实施检测性的或预防性控制,以防止数据外泄。

责任:客户

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

指南:为了对访问控制进行补充,服务总线会加密静态数据。 这种做法可防止使用加密的“带外”攻击(例如访问基础存储)。 这样,攻击者就无法轻易读取或修改数据。

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

责任:客户

资产管理

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

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

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

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

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

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

责任:客户

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

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

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

  • 资源
  • 资源组
  • 订阅

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

使用 Azure 虚拟机清单自动收集有关虚拟机上的软件的信息。 Azure 门户提供的项包括:

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

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

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

责任:客户

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

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

责任:客户

日志记录和威胁检测

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

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

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

将服务总线中的所有日志转发到可用于设置自定义威胁检测的 SIEM。 监视不同类型的 Azure 资产,以发现潜在的威胁和异常情况。 专注于获取高质量的警报,这样可以减少误报,便于分析人员进行分类整理。 可从日志数据、代理或其他数据探寻警报来源。

责任:客户

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

指导: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 资源日志
  • NSG 流日志
  • Azure 防火墙日志
  • Web 应用程序防火墙 (WAF) 日志

安全分析支持:

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

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

服务总线会记录它为客户访问处理的所有网络流量。 在已部署的产品/服务资源中启用网络流功能。

服务总线不生成或处理 DNS 查询日志。

责任:客户

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

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

为服务总线启用 Azure 资源日志。 若要启用资源日志和日志数据收集,请使用 Microsoft Defender for Cloud 和 Azure Policy。 调查安全事件和进行取证练习时,这些日志可能至关重要。

服务总线还会为本地管理员帐户生成安全审核日志。 启用这些本地管理员审核日志。

责任:客户

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

Azure Policy 内置定义 - Microsoft.ServiceBus:

名称
(Azure 门户)
说明 效果 版本
(GitHub)
应启用服务总线中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0

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

指导:集中记录存储和分析来实现关联。 对于每个日志源,请确保分配:

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

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

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

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

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

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

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

责任:客户

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

指南:是否有存储帐户或 Log Analytics 工作区用于存储服务总线日志? 然后,根据组织的合规性法规设置日志保留期。

责任:客户

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

指南:不适用;服务总线不支持配置你自己的时间同步源。

服务总线服务依赖于 Microsoft 时间同步源。 它未公开给客户进行配置。

责任:Microsoft

安全状况和漏洞管理

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

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

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

  • Azure 资源管理器模板(ARM 模板)
  • Azure RBAC 控制
  • 策略

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

责任:客户

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

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

  • 虚拟机
  • 容器
  • 其他计算资源

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

责任:客户

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

指南:不适用;此建议适用于计算资源。

责任:客户

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

指南:Microsoft 对支持服务总线的基础系统执行漏洞管理。

责任:Microsoft

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

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

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

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

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

责任:客户

终结点安全性

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

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

指南:Microsoft Antimalware 在支持 Azure 服务(例如,Azure 应用服务)的基础主机上处于启用状态。 它不涉及客户内容。

责任:Microsoft

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

指南:快速一致地更新反恶意软件签名。

要确保所有终结点都具有最新的签名,请遵循 Microsoft Defender for Cloud 中的建议(“计算和应用”)。

对于 Windows,Microsoft Antimalware 将默认自动安装最新的签名和引擎更新。 如果你在 Linux 环境中工作,请使用第三方反恶意软件解决方案。

有关详细信息,请参阅以下资源:

责任:Microsoft

备份和恢复

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

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

指导:配置 Azure 服务总线的异地灾难恢复。 当整个 Azure 区域或数据中心(如果未使用可用性区域)遭遇停机时,会发生什么情况? 数据处理必须继续在另一个区域或数据中心运行。 异地灾难恢复和异地复制对于任何企业而言都是至关重要的功能。 Azure 服务总线支持命名空间级别的异地灾难恢复和异地复制。

责任:客户

BR-2:加密备份数据

指南:服务总线提供了通过 Azure 存储服务加密 (Azure SSE) 对静态数据进行加密的功能。 服务总线依赖于存储来存储数据。 默认情况下,使用存储来存储的所有数据都使用 Microsoft 管理的密钥进行加密。 如果使用 Key Vault 存储客户管理的密钥,请定期对密钥进行自动备份。

请确保通过 PowerShell 命令 Backup-AzKeyVaultSecret 定期自动备份 Key Vault 机密。

责任:共享

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

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

责任:客户

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

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

责任:客户

后续步骤