在云时代，安全能力可以弹性扩展，但成本也可能随之悄然攀升。本章将直面安全运营的核心挑战之一，为您揭示如何在保障甚至提升安全效能的同时，通过精细化的策略与架构设计，实现对 Microsoft Sentinel 成本的可预测、可控制管理。

经过前九章的构建，您的安全运营中心已功能齐备。然而，在云原生环境中，每一项能力都对应着资源消耗和成本。未经管理的日志洪流、低效的查询、僵化的架构，都可能使您的安全预算迅速承压。本章将提供一套完整的“降本增效”组合拳，从数据生命周期、查询效率到宏观架构，助您打造一个既强大又经济的安全运营中枢。

在 Sentinel 中，成本主要由数据引入（每条日志的摄取）和数据保留（日志的存储时长）驱动。优化必须从数据“入口”一直管到“出口”。

Sentinel 基于 Azure Monitor Log Analytics，提供灵活的保留期设置，这是平衡合规、运营需求与成本的最有效工具。

• 标准（交互式）保留期：

• 数据在此期间可被快速查询。默认30天，建议延长至90天。这是威胁调查、UEBA基线学习和大部分检测规则运行的活跃窗口。延长至此范围对成本影响相对较小，但能显著提升运营能力。

• 存档保留期：

• 对于需要满足长期合规性要求（如7年）的数据，可将其在标准保留期后自动转入存档层。存档数据的存储成本显著降低，但检索时会有延迟和额外的事务成本。仅对需要满足法规审计、极少进行主动查询的数据启用存档。

• 表级保留策略（关键控制点）：

• 并非所有日志表都需要相同的保留期。您必须为每类数据制定策略。
• 操作步骤：在 Sentinel 工作区设置中，进入“表”视图，您可以逐一配置。
• 配置示例：

• SecurityEvent， SigninLogs， AuditLogs：保留 180天（满足常见合规与深度调查）。
• AzureActivity， CommonSecurityLog（防火墙）：保留 90天（活跃分析期）。
• DeviceProcessEvents（来自Defender for Endpoint）：保留 30天（通常更详细，可通过聚合规则提取关键指标）。
• 特定应用调试日志（AppServiceConsoleLogs）：保留 7天。

在数据被摄取前进行筛选，是成本控制最有效的一环。

• 利用数据收集规则进行源端过滤：

• 配置 Azure Monitor Agent 时，绝对不要盲目选择“所有事件”或“所有日志”。
• Windows 安全事件：精心选择关键事件ID。例如，收集 4688（进程创建）、4624/4625（登录）、4657（注册表修改）、4663（文件访问）等，而非全部安全事件。
• Syslog (Linux)：筛选设施和严重级别，例如只收集 auth， authpriv设施的 warning及以上级别日志。

• 避免重复引入：

• 检查是否有多个代理或诊断设置将同一台虚拟机或Azure服务的日志发送到同一个工作区。
• 确保第三方设备日志（如防火墙）只通过一种方式（CEF via AMA 或 代理）引入，避免同时配置Syslog和CEF接收器造成重复。

• 评估并优化自定义日志：

• 对于通过 HTTP 数据收集器 API 或自定义代理引入的应用程序日志，定期审查其价值和数据量。考虑是否可以对日志进行结构化或聚合后再发送，以减少数据量但保留核心信息。

低效的 KQL 查询不仅响应慢，更会消耗大量计算资源，在按查询量计费的情境下推高成本。优化查询是提升分析师体验和控制隐性成本的关键。

• 始终优先进行时间范围筛选：

// 优秀实践：首先限制时间范围 _Im_NetworkSession | where TimeGenerated > ago(1h) // 第一时间筛选 | where SrcIpAddr == ‘10.0.0.1’

// 避免的做法：在全表扫描后才筛选 _Im_NetworkSession | where SrcIpAddr == ‘10.0.0.1’ // 先在全表执行此过滤，效率低下 | where TimeGenerated > ago(1h)

• 使用精确的where条件，避免模糊匹配：

• 优先使用 ==， has， in。谨慎使用 contains， 特别是对长字符串字段。

• 尽早使用project或project-away：

• 在查询的早期阶段，只保留后续步骤真正需要的字段，减少在管道中流动的数据量。

GPT plus 代充 只需 145SecurityAlert | where TimeGenerated > ago(7d) | project AlertName, CompromisedEntity, TimeGenerated, Severity // 只选择必要字段 | summarize Count=count() by AlertName, Severity

• 利用汇总与聚合表：

• 对于仪表板中需要频繁计算的指标（如“过去24小时事件总数”），可以创建一个计划查询规则，定期（如每小时）将原始数据聚合成小型的汇总表。仪表板直接查询这个小型汇总表，性能可提升百倍。
• 通过 Azure 数据资源管理器 的物化视图功能（预览），可以自动维护这种聚合视图。

• 避免在where子句中对字段进行转换：

• 在字段上使用函数会阻止使用索引。

// 不佳：对字段进行转换 | where tolower(AccountName) == ‘admin’

// 较佳：如果可能，调整数据引入时的规范化 // 或使用大小写不敏感操作符（如果支持） | where AccountName =~ ‘admin’

• 优化跨工作区查询：

• 跨工作区查询 (workspace(‘workspace-id’).TableName) 性能开销较大。应尽量减少查询频率和数据量。考虑将需要频繁关联的数据集中到“收集工作区”。

对于大型或复杂组织，单一的 Sentinel 工作区可能无法满足数据主权、成本分摊或管理隔离的需求。此时，需要采用多工作区架构。

• “收集与区域”工作区模式：

• 收集工作区：一个中心工作区，用于全局性的、跨区域的安全分析和事件管理。它不直接连接数据源，而是通过跨工作区查询从区域工作区读取数据。
• 区域工作区：多个位于不同地理区域（如欧洲、北美、亚太）的工作区，直接连接该区域内的数据源，遵守数据驻留法规。
• 优势：满足数据主权，实现全局统一分析视图，区域团队可管理本地数据。

• “运营与安全”分离模式：

• SOC 工作区：专门用于安全监控，连接所有安全相关数据源，运行安全分析规则。
• IT 运维工作区：连接服务器性能日志、应用遥测等，由运维团队使用。
• 优势：实现职责分离，成本独立核算，并可通过资源上下文 RBAC 或表级 RBAC 在两个工作区间安全地共享特定数据。

在跨国企业或 MSSP 场景中，您可能需要管理多个客户或子公司的 Azure 租户（每个租户有自己的 Sentinel）。

• 使用 Azure Lighthouse：

• Azure Lighthouse 允许服务提供商或企业 IT 中心团队，在一个统一的 Azure 门户视图中，跨多个客户租户或下级租户进行管理。
• 您可以将安全操作团队的角色（如 Microsoft Sentinel 读者/参与者）委托到客户租户的 Sentinel 工作区，而无需在客户租户中创建本地账户，实现了集中监控和响应。

• 构建分层 SOC 模型：

• 查看所有租户的高严重性事件。
• 部署标准化的检测规则和 Playbook 模板。
• 进行跨租户的威胁狩猎和关联分析（通过跨工作区查询）。
• 提供专业的事件响应支持。

• 使用内容中心与解决方案：将自定义的高质量分析规则、狩猎查询、工作簿和 Playbook 打包为私有内容解决方案，通过内容中心一键部署到多个工作区，确保安全策略的一致性。
• 基础设施即代码：使用 Bicep 或 Terraform 模板来定义和部署 Sentinel 工作区、数据连接器甚至分析规则。这使得环境复制、版本控制和规模化部署成为可能，是管理复杂架构的基石。

成本控制与架构优化不是一次性的项目，而应成为安全运营的持续纪律。它要求我们在安全效能、运营效率与财务成本之间做出智慧的权衡。

本章行动清单：

1. ✅ 执行成本分析：在 Azure 门户中，导航到您的 Log Analytics 工作区，查看“使用情况和预估成本”。分析过去30天数据引入量最大的表。针对前三名，制定优化计划（是调整保留期，还是优化收集过滤？）。
2. ✅ 实施一项表级保留策略：立即将您的一个非关键日志表（例如 Syslog或某个自定义应用日志表）的保留期从默认值调整为更符合其实际价值的期限（如从90天改为30天）。
3. ✅ 优化一条现有检测规则：选择一条运行频率较高或查询较复杂的自定义分析规则，审查其 KQL 查询。确保其首先使用时间筛选（TimeGenerated > ago(…)），并检查是否可以通过更精确的 where条件或提前使用 project来提升效率。
4. ✅ 规划您的架构演进：在白板上画出您当前 Sentinel 工作区与数据源的关系图。思考未来6个月，如果业务扩展到新区域或需要为独立部门提供隔离的视图，当前架构是否支持？本章的哪种多工作区模式更适合您？

通过实施这些策略，您将确保您的 Microsoft Sentinel 投资能够持续、高效地服务于组织的安全目标，而不会成为不可控的财务负担。在下一篇实战章节中，我们将综合运用所有知识，应对一个真实的复杂威胁。