N4ncys/sentinel

# 云安全监控与事件响应 ### Azure 安全工程作品集 — 项目 4 ## 概述 一个基于 Microsoft Sentinel 构建的集中式安全监控平台， 完全使用 Terraform 以代码形式进行配置。该项目展示了 端到端的安全运营能力——从日志摄取和 检测工程到自动化事件响应和攻击模拟。 ## 技术栈 | 类别 | 技术 | |---|---| | 云平台 | Microsoft Azure | | SIEM | Microsoft Sentinel | | 日志存储 | Azure Log Analytics | | 基础设施即代码 | Terraform | | 查询语言 | KQL (Kusto Query Language) | | 自动化响应 | Azure Logic Apps | | 网络安全 | Azure Bastion, Network Security Groups | | 身份与访问 | Azure Managed Identity, RBAC | | 操作系统 | Ubuntu 22.04 LTS | | 脚本 | Bash | ## 架构 ``` sentinel/ ├── modules/ │ ├── siem/ # Log Analytics Workspace + Microsoft Sentinel │ ├── target-env/ # Monitored resources (Key Vault, Storage, Activity Log) │ ├── attacker-vm/ # Red team VM accessed via Azure Bastion │ ├── detection-rules/ # KQL analytics rules deployed as code │ └── playbooks/ # Logic App automation rules ├── kql/ # Raw KQL detection queries └── scripts/ # Attack simulation scripts ``` 三个隔离的资源组反映了真实的企业安全边界。 安全团队拥有第一个资源组，具有严格的 RBAC——工作负载 团队无法触及它。攻击者资源组是完全隔离的，因此 如果虚拟机受损，爆炸半径也能被控制住。 | 资源组 | 用途 | |---|---| | `rg-soc-*-security` | Sentinel, Log Analytics, Logic Apps — 防御方 | | `rg-soc-*-target` | Key Vault, 存储账户 — 被监控的工作负载 | | `rg-soc-*-attacker` | 带有 Azure Bastion 的攻击者 VM — 红队侧 | 所有三个资源组均已部署并可在 Azure 门户中查看： ## 组件 ### SIEM — Microsoft Sentinel Log Analytics Workspace 充当存储引擎——流入的每一条日志 都会被写入这里的表中。Microsoft Sentinel 位于其之上， 增加了检测、调查和响应功能。可以把 LAW 想象成文件柜，而 Sentinel 是坐在它前面的分析师。 - 具有 90 天保留期的 Log Analytics Workspace - 在工作区上启用 Microsoft Sentinel - Microsoft Defender for Cloud 数据连接器 ### 目标环境 目标环境的存在纯粹是为了生成真实的安全信号。 Key Vault 审计日志通过诊断设置启用，这会将每一个 秘密访问事件直接传输到 Sentinel。Azure Activity Log 诊断 设置捕获所有控制平面操作——角色分配、资源 删除、策略更改——跨越整个订阅。 - 启用了审计日志的 Azure Key Vault - Azure 存储账户 - 将 Key Vault 审计日志路由到 Sentinel 的诊断设置 - 将控制平面事件路由到 Sentinel 的 Azure Activity Log 诊断设置 ### 攻击者 VM 攻击者 VM 没有公共 IP——它只能通过 Azure Bastion 访问，后者提供基于浏览器的安全 SSH，而无需向 互联网暴露任何端口。这反映了真实企业如何在 零信任网络模型下提供安全的 VM 访问。NSG 仅允许来自 Bastion 子网的入站流量。 - Ubuntu 22.04 LTS VM (`Standard_D2s_v3`) - 无公共 IP——仅通过 Azure Bastion 访问 - NSG 仅限制来自 Bastion 子网的入站流量 - 安装了 Azure Monitor 代理以进行日志收集 ### 检测规则 (KQL) 四条自定义分析规则通过 Terraform 以代码形式部署，每条映射 到特定的 MITRE ATT&CK 技术。将检测规则存储在版本 控制中意味着它们是可审计、可审查和可复制的——一个 不懂 Terraform 的 SOC 分析师仍然可以阅读和编辑 `kql/` 目录中的原始 KQL 文件。 | 规则 | MITRE 技术 | 严重性 | 数据源 | |---|---|---|---| | Key Vault 大规模秘密访问 | T1555 — Credentials from Password Stores | 高 | AzureDiagnostics | | 通过角色分配进行权限提升 | T1078 / T1098 — Valid Accounts / Account Manipulation | 高 | AzureActivity | | 针对 Azure 管理层面的暴力破解 | T1110 — Brute Force | 中 | AzureActivity | | 异常资源删除 | T1485 — Data Destruction | 高 | AzureActivity | 所有四条规则在 Sentinel 中均处于活动状态，MITRE 技术在 分析仪表板中可见： ### 自动化响应 — Logic App Playbook 当 Sentinel 引发事件时，自动化规则会触发 Logic App playbook，发送包含事件详细信息的电子邮件通知。 Logic App 使用具有作用域角色分配的托管身份—— 工作流中未存储任何秘密或凭据。 - 由 Sentinel 事件触发的 Logic App - 发送包含事件详细信息的电子邮件通知 - 自动化规则将 playbook 链接到所有事件 - 具有作用域角色分配的托管身份 ## 攻击模拟与检测结果 每次模拟均使用 Azure CLI 从本地机器运行，针对 `rg-soc-*-target` 资源组中的资源。脚本位于 `scripts/` 目录中，并记录了 MITRE ATT&CK 映射。 ### ✅ T1555 — Key Vault 大规模秘密访问 模拟在 27 秒内从 Key Vault 访问了 `dummy-secret` 10 次， 远高于 5 分钟内 5 次访问的检测阈值。 27 秒内 10 次访问无疑是自动化的凭据窃取， 而非人工手动检查秘密。 **阈值：** 5 分钟内 5 次或更多次秘密访问 **结果：** 在 Sentinel 中创建了 6 个事件，每 5 分钟在回溯窗口上触发一次 Key Vault 审计日志实时流入 Sentinel，确认 诊断设置工作正常： ### ✅ T1078 / T1098 — 通过角色分配进行权限提升 模拟在目标资源组上创建了 Reader 角色分配 并立即删除了它。任何角色分配写入操作都会触发 检测——在实际攻击中，对手会为自己分配一个 更高权限的角色，例如 Owner 或 Contributor。 **阈值：** 任何角色分配写入操作 **结果：** 在 Sentinel 中创建了 1 个事件 两个检测在 Sentinel 事件视图中均可见，连同其 严重性、MITRE 战术类别和时间戳： 深入查看 Key Vault 事件会显示警报详情、时间线和 SOC 分析师可用的调查选项： ### 📋 T1110 — 针对 Azure 管理层面的暴力破解 检测规则已部署，KQL 查询已针对实时 AzureActivity 日志进行了验证。实时模拟需要在 10 分钟窗口内持续的 API 失败——最好使用 专用攻击框架（如 Atomic Red Team）来演示。检测逻辑是合理的，并且会针对 针对 Azure 管理层面的真实暴力破解活动触发。 **阈值：** 10 分钟内 5 次或更多次管理失败 **状态：** 规则已部署并处于活动状态——模拟需要专用工具 ## 前置条件 - 具有 Owner 角色的 Azure 订阅 - Terraform >= 1.7.0 - 已通过身份验证的 Azure CLI (`az login`) ## 部署 ``` # Clone the repo git clone cd sentinel # Configure variables cp terraform.tfvars.example terraform.tfvars # Edit terraform.tfvars with your values # Deploy terraform init terraform apply ``` ## 部署后步骤 1. 在门户中的 Log Analytics Workspace 上启用 Microsoft Sentinel 2. 在 Sentinel → Data Connectors 下验证数据连接器是否处于活动状态 3. 在 Sentinel → Analytics 下确认分析规则是否已启用 4. 从 `scripts/` 目录运行攻击模拟以验证检测 ## 已知限制与设计决策 - **未使用 Entra ID 连接器** — 需要 Azure AD Premium P2 许可证。 已替换为 Azure Activity Log，它为 控制平面攻击检测提供了等效的信号。 - **未使用 MDE 连接器** — 需要 Microsoft Defender for Endpoint 许可证。 攻击者 VM 上的 Azure Monitor 代理转而提供端点遥测数据。 - **通过门户加入 Sentinel** — `SecurityInsights` 资源被 要求手动在门户中启用的管理组策略阻止。 - **暴力破解模拟** — Azure CLI 失败不会持续生成 Activity Log 条目。生产部署将使用 Atomic Red Team 进行 可靠模拟。 ## 演示的安全控制 | 控制 | 实现 | |---|---| | 零信任网络访问 | Azure Bastion — 攻击者 VM 上无公共 IP | | 最小权限 | 具有作用域角色分配的托管身份 | | 日志集中化 | 诊断设置将所有日志路由到单个 LAW | | 检测即代码 | 在 Terraform 中进行版本控制的 KQL 规则 | | 自动化响应 | 由 Sentinel 自动化规则触发的 Logic App playbook | | MITRE ATT&CK 对齐 | 所有检测均映射到特定技术 | ## 资源 - [Microsoft Sentinel 文档](https://docs.microsoft.com/azure/sentinel) - [KQL 参考](https://docs.microsoft.com/azure/data-explorer/kql-quick-reference) - [MITRE ATT&CK 云矩阵](https://attack.mitre.org/matrices/enterprise/cloud/) - [Terraform AzureRM Provider](https://registry.terraform.io/providers/hashicorp/azurerm/latest)

标签：AMSI绕过, Azure, Azure Bastion, Cloudflare, DevSecOps, ECS, KQL, Log Analytics, Logic Apps, Microsoft Sentinel, MITRE ATT&CK, RBAC, SOAR, StruQ, Terraform, 上游代理, 威胁检测, 安全工程, 应用安全, 攻击模拟, 数据展示, 检测规则, 红队, 网络安全, 网络资产发现, 自动化响应, 隐私保护, 驱动签名利用