通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

用于监视和威胁检测的体系结构策略

适用于此 Azure Well-Architected Framework 安全清单建议：

SE：10 实施依赖于可与平台集成的现代威胁检测机制的整体监视策略。 机制应可靠地对会审发出警报，并将信号发送到现有的 SecOps 进程。

本指南介绍监视和威胁检测的建议。 监视本质上是 获取有关已发生的事件的信息的过程。 安全监视是在工作负荷的不同高度（基础结构、应用程序、作）捕获信息， 以了解可疑活动。 目标是预测事件并从过去的事件中学习。 监视数据提供了事件后分析的基础，以帮助事件响应和取证调查。

监视是跨所有 Well-Architected 框架支柱应用的卓越运营方法。 本指南仅从安全角度提供建议。 有关监视的一般概念（如代码检测、数据收集和分析）已脱离本指南的范围。 有关核心监视概念的信息，请参阅 有关设计和构建可观测性框架的建议。

定义

术语 Definition
审核日志 系统中的活动记录。
安全信息和事件管理（SIEM） 基于从多个源聚合的数据使用内置威胁检测和智能功能的方法。
威胁检测 使用收集、分析和关联数据检测与预期作的偏差的策略。
威胁情报 通过检查模式来解释威胁检测数据以检测可疑活动或威胁的策略。
威胁防护 放置在不同高度的工作负荷中的安全控制，以保护其资产。

安全监视的主要目的是 威胁检测。 主要目标是防止潜在的安全漏洞和维护安全环境。 但是，认识到并非所有威胁都可以抢占性地阻止，这同样重要。 在这种情况下，监视还充当一种机制，用于确定尽管预防工作已发生的安全事件的原因。

可以从各种角度来监视：

  • 在不同高度进行监视。 从 各种高度 观察是获取有关用户流、数据访问、标识、网络甚至作系统的信息的过程。 每个区域都提供了独特的见解，可帮助你识别与针对安全基线建立的预期行为之间的偏差。 相反，随着时间的推移，持续监视系统和应用程序有助于 建立基线状态。 例如，通常每小时可能会在标识系统中看到大约 1,000 次登录尝试。 如果监视在短时间内检测到 50,000 次登录尝试高峰，攻击者可能会尝试访问系统。

  • 在各种影响范围内进行监视。 观察应用程序和平台至关重要。 假设应用程序用户意外升级特权或发生安全漏洞。 如果用户执行超出其指定范围的作，则影响可能仅限于其他用户可以执行的作。

    但是，如果内部实体入侵数据库，则潜在的损害程度不确定。

    如果 Azure 资源端发生泄漏，则影响可能是全局的，从而影响与资源交互的所有实体。

    爆炸半径或影响范围可能大相径庭，具体取决于这些情况中的哪一种。

  • 使用专用监视工具。 投资 专用工具 至关重要，这些工具可以持续扫描可能指示攻击的异常行为。 其中大多数工具具有 威胁情报功能 ，这些功能可以根据大量数据和已知威胁执行预测分析。 大多数工具不是无状态的，并且融入了对安全上下文中遥测的深入理解。

    这些工具需要与平台集成或至少平台感知，才能从平台获取深度信号，并通过高保真度进行预测。 他们必须能够及时生成警报，并有足够的信息进行适当的会审。 使用过多的多样化工具可能会导致复杂性。

  • 对事件响应使用监视。 聚合数据转换为可作的智能， 可快速有效地对事件做出反应 。 监视 有助于执行事件后活动。 目标是收集足够的数据来分析和了解所发生的事情。 监视过程捕获有关过去事件的信息，以增强反应能力并可能预测将来的事件。

以下部分提供了包含上述监视透视的建议做法。

捕获数据以保留活动线索

目标是从安全角度维护 事件的综合审核线索 。 日志记录是捕获访问模式的最常见方法。 必须为应用程序和平台执行日志记录。

对于审核线索，需要确定与作关联的内容、时间和人员。 需要确定执行作时的特定时间范围。 在威胁建模中进行此评估。 若要应对否认性威胁，应建立强大的日志记录和审核系统，以记录活动和事务。

以下部分介绍工作负载的某些常见高度的用例。

应用程序用户流

应用程序应设计为在事件发生时提供运行时可见性。 确定应用程序中的关键点，并为这些点建立日志记录。 例如，当用户登录到应用程序时，捕获用户的标识、源位置和其他相关信息。 请务必确认用户权限的任何升级、用户执行的作以及用户是否访问安全数据存储中的敏感信息。 跟踪用户和用户会话的活动。

为了方便进行此跟踪，应 通过结构化日志记录检测代码。 这样就可以轻松统一地查询和筛选日志。

重要

你需要强制实施负责任的日志记录，以保持系统的机密性和完整性。 机密和敏感数据不得显示在日志中。 在捕获此日志数据时，请注意泄露个人数据和其他符合性要求。

标识和访问监视

维护 应用程序访问模式的彻底记录，并修改平台资源。 具有可靠的活动日志和威胁检测机制，尤其是与标识相关的活动，因为攻击者通常会尝试作标识以获取未经授权的访问。

使用所有可用数据点实现全面的日志记录。 例如，包括客户端 IP 地址，以区分常规用户活动和来自意外位置的潜在威胁。 所有日志记录事件都应由服务器时间戳。

记录所有资源访问活动，捕获谁正在执行哪些作以及何时执行该活动。 特权升级的实例是应记录的重要数据点。 还必须记录与应用程序创建或删除帐户相关的作。 此建议扩展到应用程序机密。 监视谁访问机密以及何时轮换机密。

尽管日志记录成功作很重要，但 从安全角度来说，记录失败是必要的。 记录任何冲突，例如用户尝试作但遇到授权失败、对不存在的资源的访问尝试以及看似可疑的其他作。

网络监控

通过监视网络数据包及其源、目标和结构，可以在网络级别查看访问模式。

分段设计应 使边界上的观察点 能够监视交叉点并记录该数据。 例如，监视具有生成流日志的网络安全组的子网。 此外，监视显示允许或拒绝的流的防火墙日志。

入站连接请求有访问日志。 这些日志记录启动请求的源 IP 地址、请求类型（GET、POST）和属于请求的所有其他信息。

捕获 DNS 流是许多组织的重要要求。 例如， DNS 日志可以帮助识别哪个用户或设备启动了特定的 DNS 查询。 通过将 DNS 活动与用户/设备身份验证日志相关联，可以跟踪单个客户端的活动。 此责任通常扩展到工作负荷团队，尤其是在他们部署任何发出 DNS 请求部分作的内容时。 DNS 流量分析是平台安全可观测性的关键方面。

监视定向到已知命令和控制终结点的意外 DNS 请求或 DNS 请求非常重要。

权衡： 记录所有网络活动可能会导致大量数据。 第 3 层的每个请求都可以记录在流日志中，包括跨子网边界的每个事务。 遗憾的是，无法仅捕获不良事件，因为它们只能在发生后进行标识。 制定有关要捕获的事件类型以及存储它们的时长的战略决策。 如果你不小心，则管理数据可能非常困难。 存储该数据的成本也有一个权衡。

由于权衡，应考虑工作负荷的网络监视的好处是否足以证明成本合理。 如果 Web 应用程序解决方案的请求量很高，并且系统广泛使用托管的 Azure 资源，则成本可能超过优势。 另一方面，如果你有一个解决方案，旨在将虚拟机用于各种端口和应用程序，那么捕获和分析网络日志可能很重要。

捕获系统更改

若要维护系统的完整性，应具有系统状态的准确 up-to日期记录。 如果有更改，可以使用此记录及时解决出现任何问题。

生成进程还应发出遥测数据。 了解事件的安全上下文是关键。 了解触发生成过程、触发生成过程以及触发时间可以提供有价值的见解。

跟踪 何时创建资源以及资源停用时间。 必须从平台中提取此信息。 此信息为资源管理和责任提供了宝贵的见解。

监视 资源配置中的偏移。 记录对现有资源的任何更改。 此外，请跟踪在资源群推出过程中未完成的更改。 日志必须捕获更改的具体内容及其发生的确切时间。

从修补的角度，全面了解系统是否 up-to日期和时间。 监视例程更新过程 ，以验证它们是否按计划完成。 未完成的安全修补过程应被视为漏洞。 还应维护一个清单，用于记录修补级别和任何其他所需详细信息。

更改检测也适用于作系统。 这涉及到跟踪是添加还是关闭服务。 它还包括监视向系统添加新用户。 有一些旨在面向作系统的工具。 它们有助于实现无上下文监视，因为它们不针对工作负荷的功能。 例如，文件完整性监视是一个关键工具，可用于跟踪系统文件中的更改。

应为这些更改设置警报，特别是如果不希望经常发生这些更改。

重要

部署到生产环境时，请确保警报配置为捕获在应用程序资源和生成过程中检测到的异常活动。

在测试计划中， 包括将日志记录和警报 验证作为优先测试用例。

存储、聚合和分析数据

从这些监视活动收集的数据必须存储在数据接收器中，以便对其进行彻底 检查、规范化和关联。 安全数据应保留在系统自己的数据存储之外。 监视接收器（无论是本地化还是中心）必须超过数据源。 接收器 不能是临时 的，因为接收器是入侵检测系统的源。

网络日志可以详细处理并占用存储。 探索存储系统中的不同层。 日志可以随着时间推移自然地转换为较冷的存储。 此方法非常有用，因为旧的流日志通常不会主动使用，并且只需按需使用。 此方法可确保高效的存储管理，同时确保在需要时可以访问历史数据。

工作负荷的流通常是多个日志记录源的组合。 必须 跨所有这些源智能分析监视数据。 例如，防火墙将仅阻止到达它的流量。 如果网络安全组已阻止某些流量，该流量对防火墙不可见。 若要重新构造事件序列，需要聚合来自流中的所有组件的数据，然后聚合来自所有流的数据。 当你尝试了解所发生的事情时，此数据在事件后响应方案中特别有用。 准确的守时至关重要。 出于安全考虑，所有系统都需要使用网络时间源，以便它们始终处于同步状态。

使用相关日志进行集中式威胁检测

可以使用安全信息和事件管理（SIEM）等系统 将安全数据合并到一个中心位置 ，在该位置可以跨各种服务关联安全数据。 这些系统具有 内置的威胁检测 机制。 他们可以 连接到外部源 以获取威胁情报数据。 例如，Microsoft发布可以使用的威胁情报数据。 还可以从其他提供商（如 Anomali 和 FireEye）购买威胁情报源。 这些源可以提供有价值的见解并增强安全态势。 有关Microsoft的威胁见解，请参阅 安全预览体验成员。

SIEM 系统可以根据相关和规范化数据 生成警报 。 这些警报是事件响应过程中的重要资源。

权衡：SIEM 系统可能昂贵、复杂且需要专业技能。 但是，如果没有，可能需要自行关联数据。 这可以是一个耗时且复杂的过程。

SIEM 系统通常由组织的中心团队管理。 如果你的组织没有组织，请考虑倡导它。 它可以减轻手动日志分析和相关性的负担，以便更有效地进行安全管理。

Microsoft提供了一些经济高效的选项。 许多 Microsoft Defender 产品提供 SIEM 系统的警报功能，但没有数据聚合功能。

通过组合多个较小的工具，可以模拟 SIEM 系统的一些功能。 但是，需要知道这些临时解决方案可能无法执行相关分析。 这些替代方法可能很有用，但它们可能无法完全取代专用 SIEM 系统的功能。

检测滥用

主动应对威胁检测， 并警惕滥用迹象，例如对 SSH 组件或 RDP 终结点的标识暴力攻击。 尽管外部威胁可能会产生很多干扰，尤其是在应用程序暴露在 Internet 上时， 内部威胁往往更令人担忧。 例如，应立即调查来自受信任网络源的意外暴力攻击或无意中的错误配置。

跟上强化做法。 监视不能替代主动强化环境。 较大的外围应用容易受到更多攻击。 尽可能加强控制。 例如，检测和禁用未使用的帐户、删除未使用的端口并使用 Web 应用程序防火墙。 有关强化技术的详细信息，请参阅 有关安全强化的建议。

基于签名的检测 可以详细检查系统。 它涉及查找可能表示潜在攻击的活动之间的迹象或相关性。 检测机制可以识别指示特定攻击类型的某些特征。 可能无法始终直接检测攻击的命令和控制机制。 但是，通常存在与特定命令和控制过程关联的提示或模式。 例如，从请求的角度来看，攻击可能由特定流速率指示，或者可能会经常访问具有特定结束的域。

检测 异常用户访问模式 ，以便识别和调查与预期模式的偏差。 这涉及到将当前用户行为与过去的行为进行比较，以发现异常。 虽然手动执行此任务可能不可行，但可以使用威胁情报工具来执行此作。 投资 用户和实体行为分析（UEBA）工具 ，这些工具从监视数据中收集用户行为并对其进行分析。 这些工具通常可以执行预测分析，将可疑行为映射到潜在的攻击类型。

在部署前和部署后阶段检测威胁。 在预部署阶段，将漏洞扫描合并到管道中，并根据结果采取必要的作。 部署后，继续执行漏洞扫描。 可以使用用于扫描容器映像的 Microsoft Defender for Containers 等工具。 将结果包含在收集的数据中。 有关安全开发做法的信息，请参阅 有关使用安全部署做法的建议。

利用平台提供的检测机制和措施。 例如，Azure 防火墙可以分析流量并阻止与不受信任的目标的连接。 Azure 还提供检测和保护分布式拒绝服务 （DDoS） 攻击的方法。

Azure 便利化

Azure Monitor 在整个环境中提供可观测性。 无需配置，即可从大多数 Azure 资源自动获取平台指标、活动日志和诊断日志。 活动日志提供详细的诊断和审核信息。

注释

平台日志不能无限期可用。 你需要保留它们，以便稍后查看它们以进行审核或脱机分析。 将 Azure 存储帐户用于长期/存档存储。 在 Azure Monitor 中，指定为资源启用诊断设置时的保留期。

根据预定义的或自定义指标和日志设置警报，以在检测到特定的安全相关事件或异常时获取通知。

有关详细信息，请参阅 Azure Monitor 文档。

Microsoft Defender for Cloud 提供用于威胁检测的内置功能。 它对收集的数据进行作并分析日志。 因为它知道生成的日志类型，因此可以使用内置规则做出明智的决策。 例如，它会检查可能遭到入侵的 IP 地址列表并生成警报。

为 Azure 资源启用内置威胁防护服务。 例如，启用 Microsoft Defender for Azure 资源（例如虚拟机、数据库和容器）来检测和保护已知威胁。

Defender for Cloud 提供云工作负载保护平台（CWPP）功能，用于对所有工作负荷资源进行威胁检测。

有关详细信息，请参阅 什么是 Microsoft Defender for Cloud？。

Defender 生成的警报还可以馈送到 SIEM 系统中。 Microsoft Sentinel 是本机产品/服务。 它使用 AI 和机器学习实时检测和响应安全威胁。 它提供安全数据的集中视图，有助于主动进行威胁搜寻和调查。

有关详细信息，请参阅 什么是Microsoft Sentinel？。

Microsoft Sentinel 还可以使用来自各种来源的威胁情报源。 有关详细信息，请参阅 Microsoft Sentinel 中的威胁情报集成。

Microsoft Sentinel 可以从监视数据分析用户行为。 有关详细信息，请参阅 Microsoft Sentinel 中使用用户和实体行为分析（UEBA）识别高级威胁。

尽管功能存在一些重叠，但 Defender 和 Microsoft Sentinel 协同工作。 此协作有助于确保全面的威胁检测和响应，从而增强整体安全态势。

利用 Azure 业务连续性中心 来识别业务连续性资产中的差距，并防范勒索软件攻击、恶意活动和恶意管理员事件等威胁。 有关详细信息，请参阅 什么是 Azure 业务连续性中心？。

网络

查看来自网络设备的所有日志，包括原始流量。

  • 虚拟网络流日志。 查看 流日志 和诊断日志。

  • Azure 网络观察程序。 利用 数据包捕获 功能设置警报，并获取对数据包级别的实时性能信息的访问权限。

    数据包捕获跟踪传入和传出虚拟机的流量。 可以使用它基于定义的网络异常运行主动捕获，包括有关网络入侵的信息。

    有关示例，请参阅 通过使用警报和 Azure Functions 以及数据包捕获，主动监视网络。

  • 使用 流量分析 来分析和丰富虚拟网络流日志，并深入了解流量流。 借助内置查询，可以深入了解通过 Azure 基础结构向 Internet 公开的受阻流量、恶意流和活动端口。 使用流量分析支持零信任安全性，方法是启用分段、对流量流的可见性，以及检测异常或未经授权的活动。

  • 使用 AI 提供支持的安全功能来改进威胁检测。 Azure Web 应用防火墙与 Microsoft 安全 Copilot 集成 为来自 Azure Front Door 和 Azure 应用程序网关的 Web 应用防火墙事件提供 AI 驱动的威胁分析和响应功能。 Azure 防火墙还与 Security Copilot 集成 以调查由入侵检测和防护系统（IDPS）功能截获的恶意流量。

身份

监视与标识相关的风险事件，以发现可能泄露的标识并修正这些风险。 通过以下方式查看报告的风险事件：

Microsoft Entra ID 使用自适应机器学习算法、启发式和已知泄露凭据（用户名和密码对）来检测与用户帐户相关的可疑作。 这些用户名和密码对通过监视公共和黑暗网络以及与安全研究人员、执法部门、Microsoft的安全团队和其他人员合作，浮出水面。

Azure Pipelines

DevOps 主张通过持续集成和持续交付（CI/CD）对工作负荷进行变更管理。 请务必在管道中添加安全验证。 按照 保护 Azure Pipelines 中所述的指导进行作。

安全清单

请参阅完整的建议集。

安全清单