适用于 Azure Front Door 的 Azure 安全基线

此安全基线将 Azure 安全基准 2.0 版中的指导应用于 Azure Front Door。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容按照 Azure 安全基准定义的安全控制措施和适用于 Azure Front Door 的相关指导进行分组。

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

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

注意

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

网络安全

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

NS-4:保护应用程序和服务不受外部网络攻击

指导:使用 Azure PowerShell 创建地区筛选策略并将该策略与现有的 Azure Front Door 前端主机相关联。 此地区筛选策略会阻止来自外部网络的请求,例如来自除美国之外的其他国家或地区的请求。

责任:客户

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

Azure Policy 内置定义 - Microsoft.Network:

名称
(Azure 门户)
说明 效果 版本
(GitHub)
所有 Internet 流量都应通过所部署的 Azure 防火墙进行路由 Microsoft Defender for Cloud 已确认,你的某些子网未使用下一代防火墙进行保护。 通过使用 Azure 防火墙或受支持的下一代防火墙限制对子网的访问,保护子网免受潜在威胁的危害 AuditIfNotExists、Disabled 3.0.0-preview
应启用 Azure DDoS 防护标准 应为属于应用程序网关且具有公共 IP 子网的所有虚拟网络启用 DDoS 保护标准。 AuditIfNotExists、Disabled 3.0.0
子网应与网络安全组关联 使用网络安全组 (NSG) 限制对 VM 的访问,以此防范子网遭受潜在威胁。 NSG 包含一系列访问控制列表 (ACL) 规则,这些规则可以允许或拒绝流向子网的网络流量。 AuditIfNotExists、Disabled 3.0.0
应为应用程序网关启用 Web 应用程序防火墙 (WAF) 将 Azure Web 应用程序防火墙 (WAF) 部署在面向公众的 Web 应用程序的前面,以便对传入流量进行额外检查。 Web 应用程序防火墙 (WAF) 为 Web 应用程序提供集中保护,使其免受常见攻击和漏洞的侵害,例如 SQL 注入、跨站脚本以及本地和远程文件执行。 还可以通过自定义规则,按国家/地区、IP 地址范围和其他 http(s) 参数限制对 Web 应用程序的访问。 Audit、Deny、Disabled 1.0.1
应为 Azure Front Door 服务启用 Web 应用程序防火墙 (WAF) 将 Azure Web 应用程序防火墙 (WAF) 部署在面向公众的 Web 应用程序的前面,以便对传入流量进行额外检查。 Web 应用程序防火墙 (WAF) 为 Web 应用程序提供集中保护,使其免受常见攻击和漏洞的侵害,例如 SQL 注入、跨站脚本以及本地和远程文件执行。 还可以通过自定义规则,按国家/地区、IP 地址范围和其他 http(s) 参数限制对 Web 应用程序的访问。 Audit、Deny、Disabled 1.0.1

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

指导:使用虚拟网络服务标记,在为 Azure Front Door 产品/服务资源配置的网络安全组上定义网络访问控制。 创建安全规则时,可以使用服务标记代替特定 IP 地址。 通过在规则的相应源或目标字段中指定服务标记名称(AzureFrontDoor.Frontend、AzureFrontDoor.Backend 或 AzureFrontDoor.FirstParty),可允许或拒绝相应服务的流量。

Microsoft 会管理服务标记包含的地址前缀,并会在地址发生更改时自动更新服务标记。

责任:客户

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

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

责任:Microsoft

特权访问

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

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

指导:安全的独立工作站对于确保敏感角色(如管理员、开发人员和关键服务操作员)的安全至关重要。

使用高度安全的用户工作站和 Azure Bastion 执行管理任务。 选择 Azure Active Directory (Azure AD)、Microsoft Defender 高级威胁防护 (ATP) 和 Microsoft Intune 来部署安全的托管用户工作站,以便执行管理任务。 必须通过集中管理安全的工作站来强制实施安全配置,包括强身份验证、软件和硬件基线、受限的逻辑和网络访问。

责任:客户

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

指导:Azure Front Door 已与 Azure 基于角色的访问控制 (Azure RBAC) 集成,以管理其资源。 使用 Azure RBAC,可通过角色分配来管理 Azure 资源访问。 可以将这些角色分配给用户、组服务主体和托管标识。 某些资源具有预定义的内置角色,可以通过工具(例如 Azure CLI、Azure PowerShell 或 Azure 门户)来清点或查询这些角色。

对于使用 Azure RBAC 分配给资源的基于角色的权限,请按照最低特权模型操作,并确保它们基于业务需求。 这是对 Azure AD Privileged Identity Management (PIM) 的实时 (JIT) 方法的补充,应定期进行审查。

请使用内置角色来分配权限,仅根据业务要求创建自定义角色。

责任:共享

数据保护

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

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

指导:为了对访问控制进行补充,应该对传输中的数据使用加密技术防止“带外”攻击(例如流量捕获),以确保攻击者无法轻松读取或修改数据。

Front Door 支持 TLS 版本 1.0、1.1 和 1.2。 尚不支持 TLS 1.3。 在 2019 年 9 月之后创建的所有 Front Door 配置文件使用 TLS 1.2 作为默认的最低版本。

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

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

责任:共享

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

指导:默认情况下,Azure 提供静态数据加密。 对于高度敏感的数据,请选择可对所有可用的 Azure 资源实施额外的静态加密的选项。 默认情况下,Azure 会管理加密密钥,但它还为某些 Azure 服务提供管理你自己的密钥(客户管理的密钥)的选项。

实施第三方工具(如基于主机的数据丢失自动防护解决方案),以便对数据强制实施访问控制,即使数据是从系统复制也是如此。

责任:Microsoft

资产管理

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

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

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

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

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

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

责任:客户

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

指导:将标记应用到 Azure 资源、资源组和订阅,以便有条理地将它们组织成分类。 每个标记均由名称和值对组成。 例如,可以对生产中的所有资源应用名称“Environment”和值“Production”。

责任:客户

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

指导:请使用 Azure Policy 来审核和限制用户可以在你的环境中预配哪些服务。 使用 Azure Resource Graph 查询和发现订阅中的资源。

使用 Azure Monitor 来创建规则,以便在检测到未经批准的服务时触发警报。

责任:客户

日志记录和威胁检测

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

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

指导:Azure Front Door 不会提供任何本机功能来监视与其资源相关的安全威胁。 客户可将 Azure Front Door 生成的任何日志转发到可用于威胁检测的 SIEM。

确保监视不同类型的 Azure 资源,以发现潜在的威胁和异常情况。 警报可能源自日志数据、代理或其他数据。 专注于高质量的警报,以减少误报检测。

责任:Microsoft

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

指导:Azure Front Door 不用于部署到虚拟网络,因此客户无法启用网络安全组流日志记录、通过防火墙路由流量或执行数据包捕获。

Azure Front Door 会记录它为客户访问处理的所有网络流量。 启用网络流日志功能,并将这些日志配置为发送到存储帐户,以供长期保留和审核。

责任:共享

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

Azure Policy 内置定义 - Microsoft.Network:

名称
(Azure 门户)
说明 效果 版本
(GitHub)
应启用网络观察程序 网络观察程序是一个区域性服务,可用于在网络方案级别监视和诊断 Azure 内部以及传入和传出 Azure 的流量的状态。 使用方案级别监视可以诊断端到端网络级别视图的问题。 需要在存在虚拟网络的每个区域中创建一个网络观察程序资源组。 如果网络观察程序资源组在特定区域中不可用,则会启用警报。 AuditIfNotExists、Disabled 3.0.0

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

指导:自动可用的活动日志包含针对 Azure Front Door 资源的所有写入操作(PUT、POST、DELETE),但读取操作 (GET) 除外。 活动日志可用于在进行故障排除时查找错误,或监视组织中的用户如何对资源进行修改。

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

责任:共享

安全状况和漏洞管理

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

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

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

责任:共享

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

指导:不适用;Microsoft 在支持 Azure Front Door 的基础系统上执行漏洞管理

责任:Microsoft

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

指南:快速部署软件更新,以修正操作系统和应用程序中的软件漏洞。

使用通用风险评分程序(例如通用漏洞评分系统)或你所用的第三方扫描工具提供的默认风险评级来确定优先级。 哪些应用程序在安全方面呈现出高风险,哪些应用程序需要保障长时间正常运行,根据这些上下文来对环境进行量身定制。

责任:客户

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

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

责任:共享

后续步骤