mcpField
A
azure-monitor-security

azure-monitor-security

github.com/vinayaklatthe安全17843 次安装19 周前更新
代码仓库

关于 azure-monitor-security

面向负责 Microsoft Sentinel 及安全遥测的团队，指导设计和调整 Log Analytics 工作区。内容涵盖数据分层、保留、DCR、访问控制与成本管理。

主要功能

  1. 01规划工作区拓扑
  2. 02按表选择数据层级
  3. 03设计 DCR 与摄取转换
  4. 04设置保留与归档策略
  5. 05控制成本并配置 RBAC

适用场景

  1. 01规划 Sentinel 工作区架构
  2. 02将 MMA 迁移到 AMA
  3. 03优化安全日志摄取成本
  4. 04配置表级访问权限

安装

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

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

安装后在 Claude Code 中输入/azure-monitor-security确认已加载。

详细介绍

安全领域的 Azure Monitor 和 Log Analytics

Microsoft Sentinel 运行在 Log Analytics 工作区上。Defender for Cloud、Defender XDR 威胁搜寻表、活动日志和诊断设置也会流入该工作区。工作区策略决定了安全遥测能否同时做到完整、合规且经济实惠——还是只能做到其中两项。

本技能涵盖工作区设计中的安全相关决策：分层、保留期、DCR、RBAC 和成本。

适用场景

设计或重构支撑 Sentinel 和更广泛安全遥测体系的 Log Analytics 工作区。

请勿将本技能用于 Sentinel 检测规则编写 （sentinel-detection-engineering）、App Insights 埋点 （appinsights-instrumentation）或非安全领域的可观测性。

日志表层级 — 按表选择

层级查询延迟最长保留期用例
Analytics亚秒级730 天交互式保留检测、威胁搜寻、仪表板
Basic数秒（KQL 有限制）30 天交互式保留 + 归档量大、仅在需要时搜索的日志
Auxiliary较慢 / 异步12 个月交互式保留低频访问的合规归档数据源
Archive（任何层级）通过搜索作业检索最长 12 年长期证据、法规保留

Microsoft 一直在重命名和调整这些层级——提交前，请确认所在区域当前的名称和定价。

方法

  1. 工作区拓扑。

    • 默认：每个租户设置一个 Sentinel 工作区，用于安全信号，便于关联分析。
    • 区域性／主权要求：在数据驻留或数据主权有要求时使用独立工作区。
    • 多工作区 Sentinel：仅在业务原因（并购边界、MSSP 模式）迫使采用时使用。跨工作区查询可行，但会增加复杂性。
    • 不要按团队拆分；这会割裂关联分析。

  2. 所有新部署都使用 Azure Monitor Agent（AMA）。 Microsoft Monitoring Agent（MMA / Log Analytics agent）已退役。可通过 Defender for Cloud 自动预配和 Sentinel 解决方案迁移。

  3. 按数据类别定义 DCR。

    • 每个数据源系列设置一个 DCR（Windows 安全事件、Linux Syslog、自定义日志）。
    • 使用 transformKql 在引入时删除嘈杂的列或整个事件 ID。引入前减少 30% 的数据，比引入后再调整效果更好。
    • 根据检测 KQL 验证转换，不要删除 Sentinel 分析规则所依赖的列。

  4. 按表选择层级。

    • Analytics：SecurityEvent（已筛选）、SigninLogs、AuditLogs、DeviceLogonEvents（Defender XDR）、由 Sentinel 驱动的检测数据源。
    • Basic：聊天频繁的资源所产生的 AzureDiagnostics、NSG 流日志、Web 服务器访问日志（仅在事件搜索时需要的情况）。
    • Auxiliary：长保留期合规数据源（例如，原始防火墙日志保留 12 个月）。 层级选择会显著影响引入和保留成本。

  5. 保留和存档。

    • 交互式保留期：默认 90 天；可延长以匹配检测回溯窗口（通常为 180–730 天）。
    • 合规和 IR 回放使用存档（冷数据）（某些场景最长可保留 12 年）。
    • 需要时通过搜索作业重新载入存档数据。

  6. 成本控制。

    • 在工作区启用承诺层级（100 GB/天 → 5,000 GB/天），可将每 GB 价格降低约 15–30%。
    • 找出并限制主要数据源（DNS、NSG 流、Linux Syslog）；它们通常占成本的 80%。
    • 将每日上限作为安全措施（超过上限后会丢弃数据；触发时发出警报）。
    • 每月检查：主要表、主要资源、引入趋势。

  7. 如果数据分类要求，可在工作区使用客户管理的密钥（CMK）。请规划专用群集要求和运维复杂性。

  8. RBAC。

    • 工作区级别：Log Analytics Reader、Log Analytics Contributor。
    • 表级 RBAC：将分析员的访问权限限定到特定表（例如，仅内部风险团队可查看 HR 邮箱审核数据）。
    • Sentinel：使用独立的 Sentinel Reader / Responder / Contributor 角色。
    • 不要为 SOC 分析员分配工作区 Owner 角色。

  9. 跨工作区和跨租户。

    • 对于 MSSP 式多租户，使用Sentinel 工作区管理器（各区域的预览版／正式版）。
    • 通过 union 执行跨工作区查询，支持联合环境。

防护措施

  • 默认的 90 天保留期很少足以支持安全调查。 APT 驻留时间的中位数超过这一期限。主要检测数据源应规划保留 180–730 天。
  • 不要为了“安全起见”就把所有数据都引入 Analytics 层。 成本会急剧上升；对“存储并在需要时搜索”的数据使用 Basic。
  • 转换功能强大，但也有风险。 今天删除一列，明天就可能导致检测失效。对 DCR 使用源代码管理，并审查变更。
  • 将每日上限作为成本控制措施会丢弃数据，包括安全数据。 应配合警报使用；绝不要将安全表的上限设在历史峰值以下。
  • 不要在 2025 年及以后部署 MMA。 请使用 AMA。现有 MMA 工作负载需要制定迁移计划。
  • 工作区使用 CMK 需要专用群集和 ≥500 GB/天的承诺。 这会大幅增加运维和成本。
  • 多工作区 Sentinel 会让威胁搜寻更困难。 应基于业务原因证明其合理性，而不是团队偏好。
  • 存档数据通过搜索作业召回，而非原生查询。 这会改变 IR 的 SLA 预期。
  • 诊断设置按资源配置；要实现订阅级扩展，应使用策略。 通过 Azure Policy 强制执行。

常见反模式

  • “每个团队都需要自己的工作区，因为他们想要‘自己的数据’”——关联分析会中断， 成本会暴涨。
  • “所有内容都使用分析层”——对于需要按需查询的表，成本是 Basic 的 5 倍。
  • “将 NSG 流日志以完整保真度永久发送到 Sentinel”——这是成本的主要驱动因素。进行采样、 转换，或使用 Basic 层。
  • “将保留期设为 30 天以降低成本”——第 6 周才发现的事件将没有数据可查。
  • “每日上限低于正常数据量”——数据会悄无声息地丢失，检测也会遗漏。
  • “在 50 个订阅中通过门户手动编辑 DCR”——配置漂移，且无法审计。使用 Bicep + Azure Policy。
  • “将 Sentinel 和 Defender XDR 放在两个独立工作区中”——跨产品搜寻会很麻烦。将其统一。
  • “没有数据量依据，却为了 CMK 升级到专用群集”——可能带来意外成本。

示例提示词

  • 为拥有 100,000 名员工、受欧盟和亚太地区数据主权限制的多区域 Sentinel 部署设计 Log Analytics 工作区策略。
  • 通过 Defender for Cloud 自动预配，将 6,000 台服务器从 MMA 迁移到 AMA；找出切换期间检测覆盖方面的缺口。
  • 编写 DCR，从 SecurityEvent 和 Syslog 中删除高噪声列，预计减少 35% 的数据引入量。
  • 为 Sentinel + DfC 工作负载制定层级计划：哪些表使用 Analytics、Basic 或 Auxiliary，并设置保留期。
  • 优化成本：找出我们每天处理 12 TB 数据的工作区中成本最高的 10 个驱动因素，并提出针对性削减方案。
  • 配置表级 RBAC，让内部风险分析师可以查看 EmailEvents，但不能查看 DeviceProcessEvents。
  • 为安全工作区部署客户管理的密钥——专用群集、密钥轮换和恢复运行手册。
  • 制定每日上限和数据引入警报策略，在保护预算的同时避免丢弃检测关键表的数据。

Microsoft Learn

评论

支持 Markdown