监测和威胁检测建议
适用于此 Power Platform Well-Architected 安全检查表建议：
| 东南：08 | 实施全面监视策略，其依赖于可以与平台集成的现代威胁检测机制。 机制应可靠地对会审发出警报，并将信号发送到现有 SecOps 进程。 |
|---|
本指南介绍监视和威胁检测建议。 监视从根本上讲是一个获取已发生事件信息的过程。 安全监视是一种在工作负荷的不同高度（身份、流、应用程序、操作）捕获信息以了解可疑活动的做法。 目标是预测事件并从过去的事件中吸取教训。 监视数据为事件后分析所发生的情况提供了基础，可帮助事件响应和取证调查。
监控是一种卓越运营方法，适用于所有 Power Platform Well-Architected 支柱。 本指南仅从安全角度提供建议。 监视的一般概念在设计和创建监视系统的建议中进行了介绍。
定义
| 术语 | 定义 |
|---|---|
| 审核日志 | 系统中活动的记录。 |
| 安全信息和事件管理 (SIEM) | 一种基于从多个来源聚合的数据使用内置威胁检测和情报功能的方法。 |
| 威胁检测 | 一种通过使用收集、分析和相关的数据来检测与预期操作的偏差的策略。 |
| 威胁情报 | 一种通过检查模式来解释威胁检测数据以检测可疑活动或威胁的策略。 |
| 威胁预防 | 在工作负荷中置于不同高度以保护其资产的安全控件。 |
关键设计策略
安全监视的主要目的是威胁检测。 主要目标是防止潜在的安全漏洞并维护一个安全的环境。 但是，认识到并非所有威胁都可以被预先阻止同样重要。 在这种情况下，监视也可以作为一种机制来确定尽管做出预防努力，但仍发生安全事件的原因。
可以从不同角度进行监视：
在不同高度进行监视。 从不同高度进行监视是获取有关用户流、数据访问、身份、网络甚至操作系统的信息的过程。 这些方面中的每一个都可以提供独特的见解，可以帮助您确定与根据安全基准确立的预期行为的偏差。 相反，随着时间的推移，持续监视系统和应用程序可以帮助建立基准态势。 例如，您通常每小时可能会在身份系统中看到大约 1,000 次登录尝试。 如果您的监视在短时间内检测到 50,000 次登录尝试的峰值，攻击者可能会试图获取您的系统的访问权限。
在各种影响范围内监视。 监视应用程序和平台至关重要。 假设应用程序用户意外获得升级的权限或发生安全漏洞。 如果用户执行超出其指定范围的操作，影响可能仅限于其他用户可以执行的操作。
但是，如果一个内部实体危及数据库，潜在损害的程度是不确定的。
爆炸半径或影响范围可能会有很大不同，这取决于出现的具体场景。
使用专用监视工具。 投资专用工具至关重要，这些工具可以连续扫描可能表明存在攻击的异常行为。 这些工具中的大多数都具有威胁情报功能，可以根据大量数据和已知威胁执行预测分析。 大多数工具都不是无状态的，会在安全上下文中包含对遥测的深入了解。
这些工具需要与平台集成，或者至少具有平台感知能力，以从平台获取深度信号并以高保真度进行预测。 他们必须能够及时生成警报，并具有足够的信息进行适当的分类。 使用过多不同的工具会导致复杂性。
对事件响应使用监视。 聚合数据（转化为可操作情报）支持对事件做出快速有效的反应。 监视可帮助执行事件后活动。 目标是收集足够的数据来分析和了解发生了什么。 监视过程将捕获有关过去事件的信息，以增强反应能力并有可能对未来事件进行预测。
以下各节提供了此入上述监视角度的建议做法。
捕获数据以跟踪活动
目标是维护从安全角度来看具有重大意义的事件的综合审核线索。 记录是捕获访问模式的最常见方式。 必须对应用程序和平台执行记录。
对于审核线索，您需要确立与操作相关联的内容、时间和人员您需要确定执行操作的特定时间框架。 在威胁建模中进行此评估。 要抵消抵赖威胁，您应该建立强大的记录和审核系统，以获取活动和事务记录。
以下各节介绍工作负荷的一些常见高度的用例。
工作负荷用户流
您的工作负荷应设计为在事件发生时提供运行时可见性。 确定工作负荷中的关键点，并为这些点建立记录。 确认用户权限的任何升级、用户执行的操作，以及用户是否访问了安全数据存储中的敏感信息很重要。 跟踪用户和用户会话的活动。
为了便于进行此跟踪，应通过结构化记录对代码进行检测。 这样做可以轻松、统一地查询和筛选日志。
重要提示
您需要强制进行负责的记录来维护系统的机密性和完整性。 机密和敏感数据不能显示在日志中。 捕获此日志数据时，注意泄露个人数据和其他合规要求。
身份和访问监视
保留应用程序的访问模式和对平台资源的修改的完整记录。 具有强大的活动日志和威胁检测机制，尤其是针对身份相关活动，因为攻击者经常会试图操纵身份来获得未经授权的访问。
使用所有可用数据点实现完整的记录。 例如，包括客户端 IP 地址，以区分常规用户活动和来自意外位置的潜在威胁。 所有记录事件都应由服务器加上时间戳。
记录所有资源访问活动，捕获谁在做什么以及何时执行。 特权提升的实例是一个重要的数据点，应该记录。 还必须记录与应用程序创建或删除帐户相关的操作。 此建议还可延伸到应用程序机密。 监视谁访问机密以及何时轮换。
记录成功的操作很重要，但从安全角度看，记录失败也是必要的。 记录任何违规行为，如用户尝试操作但遇到授权失败、尝试访问不存在的资源以及其他看似可疑的操作。
网络监视
您的细分设计应该在边界处启用监视点，来监视与它们交叉的内容并记录数据。 例如，监视具有生成流日志的网络安全组的子网。 还应监视显示允许或拒绝的流的防火墙日志。
有入站连接请求的访问日志。 这些日志记录发起请求的源 IP 地址、请求类型（GET、POST）以及作为请求一部分的所有其他信息。
捕获 DNS 流是很多组织的一项重要要求。 例如，DNS 日志可以帮助确定哪个用户或设备发起了特定 DNS 查询。 通过将 DNS 活动与用户/设备身份验证日志相关联，可以跟踪各个客户端的活动。 这种责任通常延伸到工作负荷团队，尤其是当他们部署任何让 DNS 请求成为其操作一部分的项目时。 DNS 流量分析是平台安全可观测性的一个关键方面。
监视意外的 DNS 请求或被定向到已知命令和控制终结点的 DNS 请求非常重要。
权衡： 记录所有网络活动可能会导致大量数据。 不幸的是，不可能只捕获不良事件，因为它们只能在不良事件发生后才能识别。 对要捕获的事件类型和事件存储时间做出战略性决定。 如果您不认真，管理数据可能会让人不知所措。 存储该数据的成本也需要权衡。
捕获系统更改
要保持系统的完整性，您应该有准确的最新系统状态记录。 如果有更改，您可以使用此记录及时解决出现的任何问题。
构建流程也应该发出遥测。 了解事件的安全性上下文是关键。 了解是什么触发了构建过程，是谁触发，以及何时触发，可以提供有价值的见解。
跟踪何时创建资源以及何时停用。 此信息必须从平台提取。 此信息为资源管理和责任提供宝贵的见解。
监视资源配置的偏移。 记录对现有资源的更改。 还应跟踪未完成的作为向资源组推出工作一部分的更改。 日志必须捕获更改的细节以及更改发生的确切时间。
从修补角度全面了解系统是否是最新且安全的。 监控例行更新过程 以验证它们是否按计划完成。 未完成的安全修补过程应被视为漏洞。 您还应该维护一个清单，记录修补程序级别和任何其他所需的详细信息。
更改检测也适用于操作系统。 这涉及跟踪服务是添加还是关闭。 另外还包括对向系统添加新用户的监视。 有些工具是针对操作系统设计的。 它们可以帮助进行无上下文监视，因为它们不针对工作负荷的功能。 例如，文件完整性监视是一项关键工具，让您能够跟踪系统文件中的更改。
您应该为这些更改设置警报，特别是在您不希望它们经常发生时。
重要提示
当您向生产环境推出时，确保将警报配置为捕捉在应用程序资源和构建过程中检测到的异常活动。
在测试计划中，作为优先测试案例包括记录和警报验证。
存储、聚合和分析数据
从这些监视活动收集的数据必须存储在数据接收器中，在那里可以对数据进行彻底的检查、规范化和关联。 安全数据应保存在系统自己的数据存储之外。 监视接收器必须比数据源更持久，无论是本地化的还是集中的。 接收器不能是短期的，因为接收器是入侵检测系统的源。
网络日志可能很冗长，占用存储。 探索存储系统中的不同层。 日志会随着时间的推移自然地转换到较旧的存储。 此方法很有助益，因为旧的流日志通常不会被主动使用，只会按需选择。 此方法可确保高效的存储管理，同时还确保您可以在需要时访问历史数据。
工作负荷流通常是多个记录源的组合。 必须跨所有这些源智能地分析监视数据。 例如，您的防火墙只会阻止到达的流量。 如果您有网络安全组已经阻止了某些流量，该流量对防火墙不可见。 要重新构建事件序列，您需要聚合流中所有组件的数据，然后聚合所有流的数据。 此数据在您尝试了解发生了什么情况的事件后响应场景中特别有用。 准确的计时至关重要。 出于安全目的，所有系统都需要使用网络时间源，以始终保持同步。
使用关联日志进行集中的威胁检测
您可以使用类似安全信息和事件管理 (SIEM) 的系统来将安全数据整合到一个中心位置，在那里可以在各项服务之间建立关联。 这些系统具有内置的威胁检测机制。 它们可以连接到外部源来获取威胁情报数据。 例如，Microsoft 发布您可以使用的威胁情报数据。 您也可以从其他提供商购买威胁情报源，如 Anomali 和 FireEye。 这些源可以提供有价值的见解，并增强您的安全态势。 有关 Microsoft 的威胁见解，请参阅安全内情。
SIEM 系统可以基于相关和规范化的数据生成警报。 这些警报是事件响应过程中的重要资源。
SIEM 系统通常由组织的中央团队管理。 如果您的组织没有，考虑支持使用它。 它可以减轻手动日志分析和关联的负担，从而实现更高效、更有效的安全管理。
Microsoft 提供了一些具有成本效益的选项。 很多 Microsoft Defender 产品提供 SIEM 系统的警报功能，但没有数据聚合功能。
通过组合几个小型工具，您可以模拟 SIEM 系统的一些功能。 但是，您需要知道，这些临时解决方案可能无法执行相关性分析。 这些替代方法可能很有用，但可能无法完全取代专用 SIEM 系统的功能。
检测滥用
积极主动地进行威胁检测 ，并警惕滥用迹象，例如对 SSH 组件或 RDP 终结点的身份暴力攻击。 虽然外部威胁可能会产生大量干扰，特别是当应用程序暴露在 Internet 上时，但内部威胁往往是一个更令人担忧的问题。 例如，应立即调查来自可信网络来源的意外暴力攻击或无意的错误配置。
坚持您的强化做法。 监视不能代替主动强化您的环境。 更大的公开区域容易受到更多的攻击。 应像重视实践那样加强控制。 例如，检测和禁用未使用的帐户，使用 IP 防火墙，阻止数据丢失防护策略不需要的终结点。
基于签名的检测 可以详细检查系统。 它包括查找可能表明潜在攻击的迹象或活动之间的相关性。 检测机制可以识别指示特定类型的攻击的某些特征。 但可能并不总是能够直接检测到攻击的指挥和控制机制。 不过，通常存在与特定命令和控制过程相关联的提示或模式。 例如，从请求的角度，攻击可能由特定的流量指示，或可能经常访问具有特定结尾的域。
检测异常用户访问模式，以可以确定和调查与预期模式的偏差。 这涉及将当前用户行为与过去的行为进行比较，来发现异常情况。 虽然手动执行此任务可能不可行，但您可以使用威胁情报工具来执行。 投资用户和实体行为分析 (UEBA) 工具，从监视数据收集用户行为并进行分析。 这些工具通常可以执行预测分析，将可疑行为映射到潜在的攻击类型。
在部署前和部署后阶段检测威胁。 在预部署阶段，将漏洞扫描纳入管道，并根据结果采取必要操作。 部署后，继续执行漏洞扫描。 您可以使用像 Microsoft Defender for Containers 这样的工具来扫描容器映像。 将结果包括在收集的数据中。 有关安全开发做法的信息，请参阅有关安全部署做法的建议。
Power Platform 推进
以下各节介绍了可用于监测和检测 Power Platform 中的威胁的机制。
Microsoft Sentinel
适用于 Microsoft Power Platform 的 Microsoft Sentinel 解决方案允许客户检测各个可疑活动，包括：
- 从未经授权的地理区域执行 Power Apps
- Power Apps 的可疑数据销毁
- Power Apps 批量删除
- 通过 Power Apps 进行的网络钓鱼攻击
- 离职员工的 Power Automate 流活动
- 添加到环境的 Microsoft Power Platform 连接器
- 更新或删除 Microsoft Power Platform 数据丢失防护策略
有关详细信息，请参阅适用于 Microsoft Power Platform 的 Microsoft Sentinel 解决方案概述。
Microsoft Purview 活动记录
Power Apps、Power Automate、连接器、数据丢失防护和 Power Platform 管理活动记录从 Microsoft Purview 合规门户跟踪和查看。
有关详细信息，请参阅：
- Power Apps 活动日志记录
- Power Automate 活动日志记录
- Copilot Studio 活动日志记录
- Power Pages 活动日志记录
- Power Platform 连接器活动日志记录
- 数据丢失防护活动日志记录
- Power Platform 管理操作活动日志记录
- Microsoft Dataverse 和模型驱动应用活动日志记录
Dataverse 审核
对具有 Dataverse 数据库的环境中的客户记录所做的数据库审核日志更改。 Dataverse 审核还记录用户通过应用或通过环境中的 SDK 进行的访问。 此审核在环境级别启用，需要对各个表和列进行额外配置。 有关详细信息，请参阅管理 Dataverse 审核。
使用 Application Insights 分析遥测
Application Insights 是 Azure Monitor 的一项功能，该功能在企业enterprise landscape范围内广泛用于监控和诊断。 将把已经从特定租户或环境收集的数据推送到您自己的 Application Insights 环境。 这些数据由 Application Insights 存储到 Azure Monitor 日志中，并显示在左窗格中“调查”下的“性能”和“失败”面板中。 这些数据将导出到 Application Insights 定义的标准架构中您的 Application Insights 环境内。 支持、开发人员和管理人员可以使用此功能会审和解决问题。
您还可以：
- 设置 Application Insights 环境以接收有关 Dataverse 平台捕获的诊断和性能的遥测。
- 订阅接收有关应用程序对您的 Dataverse 数据库和模型驱动应用执行的操作的遥测。 遥测提供可用于诊断和解决与错误和性能有关的问题的信息。
- 设置 Power Automate 云端流以与 Application Insights 集成。
- 将事件和活动从 Power Apps 画布应用写入 Application Insights。
有关详细信息，请参阅与 Application Insights 集成概述。
身份
监视潜在泄漏身份的身份相关风险事件，并补救这些风险。 通过以下方式查看报告的风险事件：
使用身份保护风险检测 API 成员通过 Microsoft Graph 获得对安全检测的编程访问。 有关详细信息，请参阅 riskDetection 和 riskyUser。
Microsoft Entra ID 使用自适应机器学习算法、启发式方法和已知的泄露凭据（用户名和密码对）来检测与您的用户帐户相关的可疑操作。 这些用户名和密码对通过监视公共和暗网，同时与安全研究人员、执法部门、Microsoft 安全团队等进行合作来呈现。
Azure Pipelines
DevOps 主张通过持续集成和持续交付 (CI/CD) 对工作负荷进行更改管理。 应确保在管道中添加安全验证。 按照保护 Azure Pipelines 中所述的指南操作。
相关信息
安全清单
请参考整套建议。