mcpField
S
sentinel

sentinel

github.com/vinayaklatthe安全17980 次安装1 天前更新
代码仓库

关于 sentinel

此技能为安全运营团队提供 Microsoft Sentinel 的规划与配置指导，用于集中采集安全日志、构建检测和自动化响应。内容包括数据分层、成本控制、KQL 狩猎及 Logic Apps playbook。

主要功能

  1. 01规划日志采集层级与成本
  2. 02设计 Log Analytics 工作区
  3. 03连接 Microsoft 与第三方数据源
  4. 04配置分析规则与事件分组
  5. 05使用 KQL 狩猎并启用 UEBA
  6. 06通过规则和 playbook 自动响应

适用场景

  1. 01为新租户选择优先数据连接器
  2. 02优化高流量日志的存储层级
  3. 03编写并调整安全检测规则
  4. 04构建告警分诊与响应 playbook

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill sentinel

安装后在 Claude Code 中输入/sentinel确认已加载。

详细介绍

Microsoft Sentinel

Microsoft Sentinel 是基于 Log Analytics 工作区构建的云原生 SIEM + SOAR，通过 Microsoft Defender 门户交付，是统一 SecOps 平台的一部分。它从 Microsoft 和第三方来源摄取日志，使用 KQL 运行计划检测和近实时检测，将警报关联为事件，并通过 Logic Apps playbook 编排响应。

适用场景

集中管理来自 Microsoft 和第三方来源的安全日志，构建检测，在数据中搜寻，并自动化响应。当你需要跨云、本地环境和 SaaS 的统一 SIEM 时，请使用 Sentinel，而不只是用于 Microsoft 365。

当目标仅仅是关联 M365 警报时，请勿使用此技能（请使用 defender-xdr）；如果要将现有 Sentinel 工作区接入统一 Defender 门户，请勿使用此技能（请使用 unified-secops-platform）。

将日志源路由到合适的摄取层

先选择层级，再选择连接器。与其他因素相比，层级选择对成本的影响最大。

如果日志是……发送到默认保留期成本模式
用于检测的高保真安全日志（登录、审计、EDR）Analytics免费保留 90 天，之后收费按 GB 付费（承诺层级）
冗长但偶尔查询的日志（CDN、自定义应用、防火墙信息）Basic logs保留 30 天，不支持分析规则约为 Analytics 的 1/5
高容量、低保真、仅用于搜索的日志（NetFlow、DNS、代理）Auxiliary logs热存储 30 天 + 长期存储 12 个月约为 Analytics 的 1/8
用于合规或罕见调查的长期存档Azure Data Explorer (ADX)数年ADX 群集成本
仅 Microsoft 365 / Defender XDR 警报通过 M365 Defender 连接器免费接入不适用免费

**经验法则（2026 年定价）：**如果某个表的平均数据量 > 50 GB/天，且分析规则不会查询该表，则它不应归入 Analytics 层。将 DNS 或代理日志移至 Auxiliary，通常可将 Sentinel 费用降低 30%–50%。

方法

  1. 估算用量并选择承诺层级 — 使用 30 天样本运行 Sentinel 定价计算器（使用 Usage | summarize sum(Quantity) by bin(TimeGenerated, 1d), DataType）。 承诺层级从 100 GB/天起步，与按需付费相比，每 GB 费率降低约 50%。 验证：承诺前，实际每日摄取量应稳定在估算值的 ±20% 以内。

  2. 工作区设计 — 默认每个租户使用单一的集中式 Log Analytics 工作区。 使用 Azure RBAC + 表级 RBAC 来限定访问范围，而不是拆分工作区。将工作区放在数据主要生成的区域，以降低出口流量和延迟。 验证：主要检测不需要跨工作区查询；如果需要，说明工作区拆分过度。

  3. 按优先级连接数据源 — 覆盖约 80% M365 租户的前 5 个连接器：Entra ID（登录 + 审计）、Office 365（Exchange + SharePoint）、Defender XDR（警报 + 高级搜寻原始数据）、Azure Activity、Microsoft Threat Intelligence。 对于第三方数据源：Codeless Connector Platform > AMA/syslog/CEF > Logstash。 验证：union withsource=Tbl * | summarize count() by Tbl, bin(TimeGenerated, 1h) 显示持续摄取，没有长时间无数据的情况。

  4. 启用解决方案，而非原始规则 — 从 Content Hub 安装（Entra 解决方案、MDE 解决方案等）。一次安装即可获得连接器、解析器、工作簿、搜寻查询和分析规则。调整模板；不要从头编写。

  5. 分析规则 — 先广泛启用，快速调整 — 为已安装的解决方案启用所有内置模板，并采用近乎实时或计划模式。预计第一周会有 10–20 条误报规则；应调整实体映射和阈值，而不是禁用规则。通过事件分组设置，将相关警报归并为事件。

  6. 搜寻和 UEBA — 在 Entra + 本地 AD 数据上启用 UEBA（IdentityInfo、BehaviorAnalytics 表）。每周使用内置搜寻查询；将有用的搜寻转为计划规则。

  7. 自动化 — 使用自动化规则进行分诊（分配、标记、关闭嘈杂的真阳性警报），并使用 Logic Apps playbook 进行响应（通知 Teams、使用 TI 丰富信息、隔离设备、禁用用户）。将每条规则映射到 MITRE ATT&CK，以便报告覆盖情况。

  8. 每月审查成本 — 检查 Usage 表，找出用量最高的表；将价值较低的表移至 Basic/Auxiliary；有计划地设置表级保留期。注意连接器配置错误（例如未关闭调试日志）。

防护措施

  • 承诺前先估算。 承诺层级按每日最低用量计费；超额承诺 30% 比按需付费更贵。先按需付费 30 天，再承诺。
  • 避免重复摄取。 除非特定检测同时需要，否则不要同时摄取 Defender XDR 原始事件和高级搜寻数据——这会导致重复付费。
  • 使用表级 RBAC，而不是多个工作区。 拆分工作区会使连接器成本翻倍、破坏跨源检测，并使事件响应更复杂。
  • 按表设置保留期。 默认的 90 天适用于所有 Analytics 表；低频使用的表（例如 AzureActivity）可缩短至 30 天，热门表（SigninLogs）可延长至 1 年。
  • 不要禁用嘈杂的规则——应调整它。 禁用规则会移除检测能力。应先调整实体映射、阈值或范围。
  • 辅助日志不能用于驱动计划分析规则。 如果检测依赖某个表，不要将其移至 Auxiliary。

常见反模式

  • “每个业务部门单独使用一个工作区以实现隔离”——成本翻倍，也会破坏关联分析。应改用基于资源上下文的 RBAC。
  • “第一天就承诺每天摄取 500 GB”——所选层级会锁定 31 天。务必先运行 PAYG 基线。
  • “先摄取所有数据，以备不时之需”——Sentinel 费用会随 GB 数量线性增长。逐表决定层级是影响成本的最大杠杆。
  • “我们禁用了产生过多告警的检测规则”——这样做移除了覆盖范围，而不是优化规则。应使用按实体设置的排除项或调整阈值。
  • “所有分析规则都按 5 分钟的计划运行”——这会消耗查询单元并产生重复告警。应使计划与检测窗口匹配（身份验证攻击为 5 分钟，横向移动为 1 小时）。
  • “每条规则都配置剧本”——大多数规则需要的是分流自动化，而不是响应自动化。仅为高置信度检测配置响应剧本。

示例提示词

  • 估算 Entra ID、Defender XDR 和 Azure 防火墙每天摄取 200 GB 时 Sentinel 的月度费用。
  • 我应该按业务部门拆分 Sentinel 工作区，还是使用表级 RBAC？
  • 将 DNS 和代理日志从 Analytics 移到 Auxiliary 会有什么影响？
  • 为新的 M365 租户，我应该先启用哪些连接器？
  • 编写一条近实时分析规则，用于检测不可能的旅行登录。
  • 构建一个剧本：当 MDE 标记勒索软件行为时，隔离设备并通知 Teams。
  • 审核我的工作区，列出摄取量最高的 10 个表，以及哪些表可以降低层级或缩短保留期。

Microsoft Learn

评论

支持 Markdown