EJCyber/Azure-Cloud-Security-Monitoring-and-Threat-Visibility

# 使用 Microsoft Sentinel 进行 Azure 云安全监控与威胁可见性 ### 在现有的云端管理端点环境中，将 Microsoft Sentinel 部署为面向生产的 SIEM，包含自定义检测工程、事件调查、自动化响应和端点健康报告。 ## 概述 本项目是包含三个项目的 Microsoft 云作品集系列中的第三个，也是最后一个项目。项目 1 和项目 2 为云优先的组织建立了身份治理和端点管理基础。项目 3 则在该基础之上构建了安全监控和可见性层。 该项目部署了连接到 Microsoft Entra ID 和 Microsoft Defender for Endpoint 的 Microsoft Sentinel，设计了一个包含自定义 KQL 分析规则的分层检测规则集，验证了真实事件的生成与调查，通过 Logic App Playbook 自动化了告警响应，并通过 Microsoft Graph PowerShell 提供了可操作的端点健康报告。 该环境并不是一个独立的实验室。它扩展了在前两个项目中构建的相同的 Azure 租户、Entra ID 结构以及由 Intune 管理的端点，使其成为一个连续的、面向生产环境的基础设施案例，而不是一系列互不关联的练习。 ## 核心成果 - 在现有的面向生产的 Azure 环境中，在 Log Analytics Workspace 上部署了 Microsoft Sentinel - 配置了 Entra ID 和 Microsoft Defender XDR 数据连接器，并进行了有针对性的日志表选择 - 设计了五项分析检测规则，其中包括一项针对非美国地理位置登录活动的自定义 KQL 规则 - 针对租户账户的模拟暴力破解活动，生成并调查了真实的 Sentinel 事件 - 构建并验证了一个 Logic App Playbook，该 Playbook 会在创建新事件时自动发送包含完整事件上下文的告警通知 - 配置了一个 Sentinel 自动化规则，将该 Playbook 与暴力破解检测规则关联起来 - 部署了一个 Microsoft Entra ID Sign-in logs 工作簿，提供登录趋势分析、失败明细和地理可见性 - 通过 Microsoft Graph PowerShell 构建了 `Get-CloudEndpointInventory.ps1`，提供跨所有受管端点的自动化设备合规性、OS 版本以及僵尸设备报告 ## 业务场景 项目 1 和项目 2 中的组织已经建立了其身份治理基线，并在员工队伍中部署了受管且合规的端点。现在，管理层要求具备操作可见性和安全检测能力。他们需要回答的问题如下： - 针对我们的租户账户是否存在未经授权或可疑的登录尝试？ - 我们的受管设备是否合规、最新且处于活跃签入状态？ - 如果发生安全事件，我们能知道吗？并且我们有文档化的响应流程吗？ 本项目通过涵盖身份信号、端点健康、检测工程和自动化响应的分层监控架构，满足了这三项要求。 ## 项目架构 ``` ┌─────────────────────────────────────────────────────────────────┐ │ Microsoft Entra ID Tenant │ │ mannylabsacctgmail.onmicrosoft.com │ │ │ │ Sign-in Logs ──────────────────────────────────────────────┐ │ │ Audit Logs ───────────────────────────────────────────────┤ │ │ Non-Interactive Sign-in Logs ──────────────────────────────┤ │ └─────────────────────────────────────────────────────────────┼───┘ │ ┌─────────────────────────────────────────────────────────────┼───┐ │ Microsoft Defender for Endpoint │ │ │ │ │ │ vm-p2-winclient01 (casey.quinn) ─────── DeviceInfo ─────────┤ │ │ vm-p2-winclient02 (alex.rivers) ────── DeviceLogonEvents ──┤ │ │ AlertInfo ──────────┤ │ │ AlertEvidence ──────┤ │ └─────────────────────────────────────────────────────────────┼───┘ │ ┌─────────────────────────▼──┐ │ Log Analytics Workspace │ │ law-p3-sentinel-westus2 │ │ West US 2 │ └─────────────────────────┬──┘ │ ┌─────────────────────────▼──┐ │ Microsoft Sentinel │ │ │ │ Analytics Rules (5) │ │ Workbooks │ │ Incidents Queue │ │ Automation Rules │ └─────────────────────────┬──┘ │ ┌───────────────────────────────▼──┐ │ Azure Logic App Playbook │ │ la-p3-sentinel-brute-force- │ │ response │ │ │ │ Trigger: Incident created │ │ Action: Send email notification │ │ Recipient: Admin (Gmail) │ └──────────────────────────────────┘ ``` **Resource Group：** rg-p2-infra-endpoint-westus2 **区域：** West US 2 **许可：** Microsoft 365 Business Premium + Azure Subscription（Sentinel 免费试用版） ## 支持文档 本项目的详细支持文档可在 `docs/` 文件夹中找到： - [架构图](docs/architecture-diagram.md) - [分析规则](docs/analytics-rules.md) - [数据连接器配置](docs/data-connector-configuration.md) - [事件调查工作流](docs/incident-investigation-workflow.md) - [Playbook 设计](docs/playbook-design.md) - [工作簿设计](docs/workbook-design.md) ## 阶段 0 — 生产前验证 在部署任何新资源之前，对现有的项目 2 环境进行了验证，以确认其仍处于已知的良好状态。这反映了管理生产变更窗口的方式——在引入新层之前先验证基线。 **已验证：** - 资源组 rg-p2-infra-endpoint-westus2 保持完整，包含所有 10 个资源（VM、NIC、磁盘、NSG、VNet） - vm-p2-winclient01：正在运行，Azure VM Agent 就绪 - vm-p2-winclient02：正在运行，Azure VM Agent 就绪（代理需要重启才能恢复——已作为发现记录在案） - 两台设备均作为企业设备注册到 Intune，受管且合规 - 主要用户分配保持不变：casey.quinn 和 alex.rivers - M365 Business Premium 许可处于活动状态 | 设备 | 合规性 | OS 版本 | 上次签入时间 | 主要用户 | |---|---|---|---|---| | vm-p2-winclient01 | Compliant | 10.0.26200.4946 | 04/03/2026 | casey.quinn | | vm-p2-winclient02 | Compliant | 10.0.26200.8037 | 04/03/2026 | alex.rivers | ## 阶段 1 — Log Analytics Workspace 和 Sentinel 部署 **Log Analytics Workspace** 部署了一个专用的 Log Analytics Workspace 作为所有 Sentinel 数据引入的后端。所有日志源、分析规则评估和工作簿查询都针对此工作区运行。 - **名称：** law-p3-sentinel-westus2 - **资源组：** rg-p2-infra-endpoint-westus2 - **区域：** West US 2 - **保留期：** 31 天（默认） - **成本：** Microsoft Sentinel 免费试用已激活——每天最多免费包含 10 GB **Microsoft Sentinel** Microsoft Sentinel 通过 Azure 门户直接在 Log Analytics Workspace 之上启用。Sentinel 作为该工作区之上的分析和检测层运行，而不是作为独立的资源。 激活时，确认免费试用有效期至 2026 年 5 月 11 日，涵盖了项目周期内的 Sentinel 和 Log Analytics 数据引入成本。 ## 阶段 2 — 数据连接器配置 数据连接器在信号源和 Sentinel 工作区之间建立了流水线。通过 Content Hub 安装了两个解决方案，并配置了有针对性的日志表选择，以平衡可见性和引入成本。 ### Microsoft Entra ID 连接器 **Content Hub 解决方案：** Microsoft Entra ID（Featured，v3.3.9） **包含内容：** 1 个数据连接器，3 个工作簿，73 个分析规则模板，11 个 Playbook **状态：** 已连接 **已启用日志表：** - Sign-in Logs —— 所有交互式身份验证事件，包括成功、失败和 MFA 结果 - Audit Logs —— 身份管理活动，包括账户更改、组修改和角色分配 - Non-Interactive User Sign-in Logs —— 后台和服务身份验证事件 Sign-in Logs 需要 Entra ID P1 或 P2 许可。Microsoft 365 Business Premium 包含 Entra ID P1，确认了兼容性。 ### Microsoft Defender XDR 连接器 **Content Hub 解决方案：** Microsoft Defender XDR（Featured，v3.0.13） **包含内容：** 1 个数据连接器，3 个工作簿，40 个分析规则，326 个 Hunting Queries **状态：** 已连接 **已启用日志表：** | 表 | 描述 | |---|---| | DeviceInfo | 包含 OS 信息的计算机清单 | | DeviceNetworkInfo | 受管计算机的网络属性 | | DeviceLogonEvents | 端点上的登录和身份验证事件 | | DeviceProcessEvents | 用于行为检测的进程创建事件 | | AlertInfo | 来自所有 Defender 产品的告警元数据 | | AlertEvidence | 与告警关联的文件、IP、用户和设备 | **注意：** Incidents and Alerts 配置部分显示了一条警告，指示该工作区已加入 Unified Security Operations Platform。这是已知的 Microsoft 迁移期间行为，因为 Sentinel 正在过渡到 security.microsoft.com 的统一 Defender 门户。无论此警告如何，事件表流式传输均已确认功能正常。 ## 阶段 3 — 检测工程 启用并配置了五项分析规则，以检测与环境相关的现实威胁场景。规则的选择基于可用的数据源、预期的信号量以及与业务场景的一致性。 ### 检测规则摘要 | 规则 | 严重性 | 类型 | MITRE 技术 | 源 | |---|---|---|---|---| | 尝试登录已禁用的账户 | Medium | 模板 | T1078 — Valid Accounts | Entra ID | | 用户账户的异常登录位置 | Medium | 模板 | T1078 — Valid Accounts | Entra ID | | 针对 Microsoft Entra ID 的密码喷洒攻击 | Medium | 模板 | T1110 — Brute Force | Entra ID | | 针对 Azure Portal 的暴力破解攻击 | Medium | 模板 | T1110 — Brute Force | Entra ID | | 检测到来自非美国位置的登录 | High | 自定义 KQL | T1078 — Valid Accounts | Entra ID | 所有规则均配置为 1 小时的评估频率和 1 小时的回溯窗口。所有规则均启用了事件创建功能。 ### 自定义 KQL 规则 — 检测到来自非美国位置的登录 从头开始编写了一项自定义分析规则，以强制执行组织的地理访问基线。该组织中的所有 75 个用户均位于美国。任何源自美国以外的成功身份验证都被视为可疑行为，需要立即进行调查。 ``` SigninLogs | where TimeGenerated > ago(1h) | where ResultType == 0 | extend Country = tostring(LocationDetails.countryOrRegion) | where isnotempty(Country) | where Country != "US" | project TimeGenerated, UserPrincipalName, Country, City = tostring(LocationDetails.city), State = tostring(LocationDetails.state), IPAddress, AppDisplayName, DeviceDetail = tostring(DeviceDetail.operatingSystem), ConditionalAccessStatus ``` **规则配置：** - 严重性：High - 事件分组：为每个事件触发一次告警（每次登录的独立可见性） - 告警分组：已启用 —— 在 1 小时窗口内按匹配实体进行分组 - 实体映射：账户（UPN）、IP 地址、CloudApplication ### 分层地理位置检测设计 在真实环境中，仅依靠单一的基于地理的规则是不够的。阻止非美国登录可以应对外部威胁，但无法捕捉源自国内的可疑活动——包括不可能的旅行场景、VPN 滥用或看似合法但来自意外美国地点的登录。 检测策略采用了两个互补的层次： 1. **检测到来自非美国位置的登录** —— 标记任何源自美国以外的成功身份验证。无论账户处于何种状态，都能捕捉到来自外部的访问。 2. **用户账户的异常登录位置** —— 使用通过 `series_decompose_anomalies` 实现的时间序列异常检测，建立每个用户、每个应用程序的正常登录位置基线，并标记具有统计显著性的偏差。这可以捕捉美国到美国的可疑模式——例如用户突然从不同的州或地区登录——而无需了解员工所在的地理位置。 这些规则共同创建了单凭任何一条规则都无法提供的重叠覆盖。 ### 已评估但未启用的模板 在此阶段还评估了两个额外的模板： - **从一个 IP 成功登录但从另一个 IP 失败** —— 需要 User and Entity Behavior Analytics (UEBA) 表（IdentityInfo、BehaviorAnalytics），但未在本项目范围内配置 - **用户拒绝 MFA** —— 同样依赖于 UEBA 表 由于在没有启用 UEBA 的情况下无法通过验证，两者均被排除。UEBA 配置被记录为未来的增强功能。 ## 阶段 4 — 事件调查 ### 模拟暴力破解攻击 为了生成用于调查的真实事件数据，从单个外部 IP 地址针对租户账户 casey.quinn@mannylabsacctgmail.onmicrosoft.com 执行了受控的暴力破解模拟。 **攻击序列：** - 多次失败的身份验证尝试，ResultType 为 50126（凭据无效） - 触发账户锁定，ResultType 为 50053（账户被锁定——失败次数过多） - 所有尝试均源自 IP 142.154.214.146 - 所有尝试均以 Azure Portal 作为目标应用程序 **确认事件捕获的 KQL 验证查询：** ``` SigninLogs | where TimeGenerated > ago(4h) | where AppDisplayName has "Azure Portal" | where ResultType !in ("0", "50140") | summarize FailureCount = count(), StartTime = min(TimeGenerated), EndTime = max(TimeGenerated), IPAddresses = make_set(IPAddress) by UserPrincipalName, IPAddress | where FailureCount >= 5 ``` ### 事件分类 **针对 Azure Portal 的暴力破解攻击**分析规则在其评估周期内生成了 Incident #2。分类发现： | 字段 | 值 | |---|---| | 事件标题 | Brute force attack against Azure Portal | | 严重性 | Medium | | 状态 | New | | MITRE 策略 | Credential Access — T1110 Brute Force | | 检测源 | Microsoft Sentinel | | 创建时间 | 4/14/2026 2:08 PM | | 实体 | IP: 142.154.214.146 / 账户: casey.quinn | **调查发现：** - 所有攻击尝试均来自单一源 IP —— 与自动化暴力破解工具或脚本化凭据攻击一致 - 攻击 IP 没有成功的身份验证 —— 攻击未导致系统被入侵 - 确认账户被锁定 —— Entra ID 智能锁定在超过阈值后启动 - 调查后，该账户被重新启用并验证为干净 **调查图**确认了实体关系：事件节点直接链接到源 IP 地址和目标账户，为攻击范围提供了即时的可视上下文。 ## 阶段 5 — 端点资产清单和健康报告 `Get-CloudEndpointInventory.ps1` 将项目 2 中的 Graph PowerShell 自动化扩展成了一个完整的操作资产清单和健康报告工具。该脚本旨在回答系统管理员周一早上的问题：在不打开门户的情况下，环境中每台受管设备的当前健康状态如何。 ### 脚本功能 - 使用受限权限（DeviceManagementManagedDevices.Read.All）连接到 Microsoft Graph - 检索所有由 Intune 管理的设备，包含合规性状态、OS 版本上次签入时间、主要用户、注册日期、制造商、型号和序列号 - 使用经过 UTC 校正的时间戳计算自上次签入以来的天数 - 标记超过可配置僵尸阈值（默认：14 天）的设备 - 输出带有颜色编码健康指示器的格式化控制台摘要 - 导出带有时间戳的 CSV 报告，用于存档或团队分发 ### 示例输出 ``` [*] Connecting to Microsoft Graph... [+] Connected to Microsoft Graph [*] Retrieving managed devices from Intune... [+] Retrieved 2 managed device(s) [*] Building inventory report... ===== ENDPOINT INVENTORY SUMMARY ===== Total Devices : 2 Compliant : 2 Non-Compliant : 0 Stale (>14 days) : 0 Current Check-In : 2 ======================================= DeviceName ComplianceState DaysSinceCheckIn StaleStatus OSVersion ---------- --------------- ---------------- ----------- --------- vm-p2-winclient02 Compliant 0.10 Current 10.0.26200.8037 vm-p2-winclient Compliant 0.10 Current 10.0.26200.4946 DeviceName PrimaryUser ---------- ----------- vm-p2-winclient02 alex.rivers@mannylabsacctgmail.onmicrosoft.com vm-p2-winclient01 casey.quinn@mannylabsacctgmail.onmicrosoft.com [+] Report exported to: C:\Users\Emmanuel\Desktop\CloudEndpointInventory_20260413_161211.csv [+] Disconnected from Microsoft Graph ``` ## 阶段 6 — 安全工作簿与可视化 **Microsoft Entra ID Sign-in logs** 工作簿从 Content Hub 部署，并作为 `WB-P3-SignIn-Analysis` 保存到工作区。该工作簿提供了一个用于分析整个租户登录活动的操作仪表板。 ### 工作簿面板 **登录分析 —— 随时间变化的趋势** 时间序列图表，追踪 14 天窗口内每个用户的登录量。针对 casey.quinn 的暴力破解模拟活动清楚地显示为偏离基线的峰值，证明了该工作簿作为可视化检测补充的价值。 **汇总指标** - 总登录次数：498 - 成功次数：439 - 失败次数：51 - 待用户操作：8 **按位置列出的登录** 身份验证事件的地理细分。失败计数以橙色突出显示，展示了基于美国登录基线的 51 起失败事件。 **按设备列出的登录** 平台和浏览器细分，确认了受管端点群体中的设备类型分布。 **登录故障排除 —— 错误代码细分** | 错误代码 | 描述 | 计数 | |---|---|---| | 50126 | 验证凭据时出错 —— 用户名或密码无效 | 38 | | 50053 | 账户被锁定 —— 失败尝试过多 | 12 | | 50089 | 身份验证失败 —— 流令牌过期 | 1 | 该面板直接展示了暴力破解攻击序列——密码错误升级为账户锁定——在工作簿内提供了直观的取证证据。 ### 地理可视化说明 Sign-ins by Location 地图可视化需要来自多个地理位置的登录活动才能绘制数据点。由于所有租户用户均位于美国，且环境未暴露在更广泛的互联网中，因此地图面板在本项目中未填充数据。**检测到来自非美国位置的登录**分析规则配置为在发生此类活动时发出告警。有关实践中的地理威胁可视化参考，请参阅支持作品集中的 [Azure Honeypot 与威胁监控实验室](https://github.com/EJCyber/Home-SOC-Lab)，其中来自全球 IP 范围的入站攻击流量使用 Sentinel 工作簿绘制在了世界地图上。 ## 阶段 7 — 自动化响应 Playbook 构建了一个 Azure Logic App Playbook，并将其与 Microsoft Sentinel 关联，以便在触发暴力破解检测时提供自动化事件通知。 ### Playbook 架构 **Logic App：** la-p3-sentinel-brute-force-response **计划：** Consumption（按执行付费） **资源组：** rg-p2-infra-endpoint-westus2 **区域：** West US 2 **工作流：** 1. 触发器：已创建 Microsoft Sentinel 事件 2. 操作：发送电子邮件（Office 365 Outlook V2）至 manny.labs.acct@gmail.com **电子邮件 payload（根据事件 schema 填充动态字段）：** - 事件标题 - 严重性 - 状态 - 创建时间（UTC） - 描述 - 事件 URL（指向 Sentinel 调查的直接链接） ### 自动化规则 在 Sentinel 中配置了一个自动化规则，用于将 Playbook 关联到检测规则： **规则名称：** AR-BruteForce-EmailResponse **触发器：** 当创建事件时 **条件：** 分析规则名称包含“Brute force attack against Azure Portal” **操作：** 运行 Playbook —— la-p3-sentinel-brute-force-response **过期时间：** 无限期 **状态：** 已启用 ### 验证 自动化流水线进行了端到端的验证。事件创建后，Logic App 成功触发（运行持续时间：2.01 秒），并向管理员收件箱发送了包含完整事件上下文的电子邮件通知。该邮件确认了动态字段的正确填充，包括事件标题、严重性、状态、时间戳、描述以及直接的 Sentinel 调查 URL。 ## 经验教训 **分析规则计划程序行为** 分析规则不会在创建后立即生成事件。规则至少需要一个完整的评估周期才能执行，并且门户中的规则运行记录还有 90 分钟的报告延迟。正确的验证方法是通过直接的 KQL 查询确认 Log Analytics Workspace 中是否存在事件，而不是等待事件生成。这可以防止在初始部署期间得出有关连接器或规则错误的错误结论。 **KQL 规则验证和调整** 最初引用 UEBA 表（IdentityInfo、BehaviorAnalytics）的分析规则模板在未启用 UEBA 时将无法通过验证。模板依赖关系并不总是在 Content Hub 描述中清晰地显示出来。在激活之前，针对实时工作区数据测试规则逻辑至关重要——Logs 查询界面是执行此验证步骤的正确工具。 **Microsoft Sentinel 门户迁移** Microsoft 正在积极将 Sentinel 的主要界面从 Azure 门户迁移到 security.microsoft.com 的统一 Defender 门户。在本项目中，由于这种迁移的重定向行为，Sentinel Content Hub 在 Azure 门户中经历了间歇性的渲染故障。Azure 门户仍然具有完整的功能，但在某些情况下需要最新的浏览器会话和直接的 URL 导航。这是一种临时的架构过渡状态，在针对此时间段编写的任何部署文档中都应予以注明。 **Defender XDR 连接器事件警告** Microsoft Defender XDR 连接器显示了一条警告：“Incidents and alerts configuration is disabled”，原因是加入了 Unified Security Operations Platform。这不会影响事件表的流式传输。无论事件配置状态如何，原始日志表（DeviceInfo、DeviceLogonEvents、AlertInfo 等）都会继续流入工作区。 **Azure VM Agent 恢复** vm-p2-winclient02 在阶段 0 开始时呈现出“Not Ready”的代理状态。重启 VM 解决了该问题，代理在重启后报告为 Ready。此行为与 VM 长时间不活动后的代理心跳超时一致，并不表示存在持续的配置问题。 **数据连接器诊断设置传播** 在配置 Entra ID 数据连接器后，状态显示为“Disconnected”大约 2 分钟，然后更新为“Connected”。这种传播延迟是正常的，反映了在 Entra ID 中创建 Diagnostic Setting 以及第一批日志到达工作区所需的时间。在此窗口过去之前进行过早的故障排除会产生误报。 **实验室环境登录数据缺口** 在具有合成用户且没有互联网暴露的实验室环境中，登录日志的引入完全取决于管理员的活动。夜间不活动期间会在 SigninLogs 中产生数据缺口，可能会导致分析规则评估不返回任何结果。这是预期行为，而不是连接器故障。在调查连接器健康状况之前，请通过直接的 KQL 查询确认数据是否存在。 ## 使用的技术 | 技术 | 作用 | |---|---| | Microsoft Sentinel | SIEM —— 检测、调查、自动化 | | Azure Log Analytics Workspace | 日志引入和查询后端 | | Microsoft Entra ID | 身份信号源 —— 登录和审计日志 | | Microsoft Defender for Endpoint | 端点信号源 —— 设备和告警遥测 | | Microsoft Defender XDR | 统一的 XDR 连接器，用于跨产品信号关联 | | Microsoft Intune | 端点合规性和管理平面 | | Azure Logic Apps (Consumption) | 自动化响应 Playbook 执行 | | Microsoft Graph PowerShell (v2.36.1) | 端点资产清单和健康报告自动化 | | KQL (Kusto Query Language) | 检测规则逻辑、调查查询、工作簿可视化 | | Azure Virtual Machines (Windows 11 Pro) | 生成遥测数据的受管端点 | | Microsoft 365 Business Premium | 许可基础（Entra ID P1、Intune、Defender） | ## 项目结构 ``` azure-cloud-security-monitoring/ ├── README.md ├── scripts/ │ └── Get-CloudEndpointInventory.ps1 ├── docs/ │ ├── architecture-diagram.md │ ├── analytics-rules.md │ ├── data-connector-configuration.md │ ├── incident-investigation-workflow.md │ ├── playbook-design.md │ └── workbook-design.md └── evidence/ ├── phase0-environment-validation/ ├── phase1-sentinel-deployment/ ├── phase2-data-connectors/ ├── phase3-analytics-rules/ ├── phase4-incident-investigation/ ├── phase5-endpoint-inventory/ ├── phase6-workbook/ └── phase7-playbook/ ``` 本项目完成了由三部分组成的 Microsoft 云作品集，重点关注身份、端点和安全运营。 ## 作者 **Emmanuel Johnson** IT 专业人员，在 Microsoft 365 管理、身份和访问管理、端点管理以及涉及 Azure、Microsoft Sentinel、Microsoft Entra ID 和 Microsoft Intune 的云安全项目方面具有丰富的实战经验。 联系方式：[LinkedIn](https://www.linkedin.com/in/emmanuel-a-johnson) · 作品集：[GitHub](https://github.com/EJCyber) · 电子邮件：[emmanuel@ejohnsoncyber.com](mailto:emmanuel@ejohnsoncyber.com) 本项目是展示 Microsoft Azure 中面向生产的云基础设施、身份治理、端点管理和安全运营的三部曲作品集系列中的第三个。 [查看项目 1 —— Azure 身份治理](https://github.com/EJCyber/azure-identity-governance) · [查看项目 2 —— Azure 云端点管理](https://github.com/EJCyber/azure-cloud-endpoint-management)

标签：KQL, Libemu, Microsoft Sentinel, PB级数据处理, SIEM, 云安全监控, 安全运维, 自动化响应, 静态分析