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

有关监视和威胁检测的建议

  • 项目

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

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

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

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

定义

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

关键设计策略

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

可以从各种角度进行监视：

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

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

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

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

    爆炸半径或影响范围可能明显不同，具体取决于发生这些情况中的哪一种。

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

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

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

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

捕获数据以保留活动的跟踪

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

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

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

应用程序用户流

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

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

重要

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

标识和访问监视

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

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

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

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

网络监视

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

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

存在入站连接请求的访问日志。 这些日志记录启动请求的源 IP 地址、请求类型 (GET、POST) 以及请求的所有其他信息。

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

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

权衡： 记录所有网络活动可能会导致大量数据。 来自第 3 层的每个请求都可以记录在流日志中，包括跨子网边界的每个事务。 遗憾的是，无法仅捕获不良事件，因为只能在不良事件发生后才能识别它们。 就要捕获的事件类型和存储时间做出战略决策。 如果不小心，管理数据可能会让人不知所措。 存储该数据的成本也有一个权衡。

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

捕获系统更改

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

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

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

监视 资源配置中的偏移。 记录对现有资源的任何更改。 此外，跟踪未作为资源群推出一部分而完成的更改。 日志必须捕获更改的详细信息以及更改的确切发生时间。

从修补的角度来看，全面了解系统是否是最新且安全的。 监视例行更新过程 ，以验证它们是否按计划完成。 未完成的安全修补过程应被视为漏洞。 还应维护记录修补程序级别和任何其他必需详细信息的清单。

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

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

重要

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

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

存储、聚合和分析数据

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

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

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

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

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

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

权衡：SIEM 系统可能成本高昂、复杂，并且需要专业技能。 但是，如果没有，可能需要自行关联数据。 此过程可能非常耗时且复杂。

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

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

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

检测滥用行为

主动进行威胁检测 ，并警惕滥用迹象，例如对 SSH 组件或 RDP 终结点的标识暴力攻击。 尽管外部威胁可能会产生大量干扰，尤其是当应用程序暴露在 Internet 中时， 内部威胁通常是一个更大的问题。 应立即调查来自受信任网络源的意外暴力攻击或意外配置错误。

跟上强化实践。 监视不能替代主动强化环境。 较大的表面区域容易受到更多攻击。 像练习一样多地加强控制。 例如，检测和禁用未使用的帐户、删除未使用的端口以及使用 Web 应用程序防火墙。 有关强化技术的详细信息，请参阅 有关安全强化的建议。

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

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

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

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

Azure 简化

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

注意

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

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

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

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

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

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

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

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

要了解详情，请参阅什么是 Microsoft Sentinel 一文。

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

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

尽管在功能上存在一些重叠，但 Defender 和 Microsoft Sentinel 协同工作。 此协作通过帮助确保全面的威胁检测和响应来增强整体安全状况。

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

网络

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

标识

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

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

Azure Pipelines

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

安全清单

请参阅完整的建议集。

安全清单