AZ-500认证核心：Azure Monitor与Log Analytics日志分析实战技巧

第一章：日志分析的核心概念

Azure Monitor 是实现 AZ-500 认证中日志分析功能的核心服务，它通过集中收集、存储和查询来自 Azure 资源、操作系统及应用程序的日志数据，帮助安全工程师识别潜在威胁并监控系统健康状态。其核心组件包括 Log Analytics 工作区，该工作区作为日志数据的存储与查询引擎，支持使用 Kusto 查询语言（KQL）进行高效的数据检索与分析。

日志数据来源

Azure 平台生成多种类型的安全相关日志，主要包括：

• Azure Activity Log：记录订阅级别的控制平面操作。
• Azure Security Center 日志：提供威胁检测与合规性评估结果。
• VM Diagnostic Logs：捕获虚拟机内部的操作系统事件。
• Network Watcher Flow Logs：记录网络安全组的流量信息。

Kusto 查询语言基础示例

以下代码展示了如何使用 KQL 查询过去 24 小时内发生的登录失败事件：

// 查询 SecurityEvent 表中 EventID 为 4625 的登录失败记录
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| project TimeGenerated, Computer, User, IpAddress
| order by TimeGenerated desc

上述查询逻辑首先筛选出代表登录失败的安全事件（EventID 4625），然后过滤最近 24 小时的数据，最终输出关键字段并按时间倒序排列，便于快速定位异常行为。

典型日志分析流程

阶段	操作	工具/服务
数据采集	启用诊断设置，将资源日志发送到 Log Analytics	Azure Monitor Agent， Diagnostic Settings
数据存储	日志写入指定的 Log Analytics 工作区	Log Analytics Workspace
查询分析	使用 KQL 进行交互式查询与告警规则创建	Kusto Explorer， Azure Portal Logs

graph TD
    A[数据源] --> B[数据采集代理]
    B --> C[Log Analytics 工作区]
    C --> D[KQL 查询]
    D --> E[可视化仪表板或告警]

第二章：Azure Monitor与日志查询基础

2.1 Azure Monitor架构解析与数据源配置

Azure Monitor 作为微软云平台的核心监控服务，采用分层架构实现对资源的全面观测。其主要由数据采集层、处理引擎与存储层、分析查询层以及告警与可视化组件构成。

核心组件与数据流向
数据从各类资源（如虚拟机、应用、日志）通过代理或服务集成自动上报至 Azure Monitor 后端。所有数据统一存储于 Log Analytics 工作区的时序数据库中。

常用数据源配置示例
以启用虚拟机诊断日志为例，可通过 ARM 模板片段配置：

{
  "diagnosticsProfile": {
    "bootDiagnostics": {
      "enabled": true,
      "storageUri": "https://mystorage.blob.core.windows.net/"
    }
  }
}

上述配置启用启动诊断并将日志输出至指定 Blob 存储，便于故障排查。参数 enabled 控制功能开关，storageUri 指定持久化位置。

支持的数据类型概览

• 指标（Metrics）：高频采集的数值型性能数据。
• 日志（Logs）：结构化文本记录，支持 KQL 查询。
• 活动日志（Activity Log）：反映平台操作与状态变更。

2.2 Kusto查询语言基础语法实战

数据筛选与投影
KQL的核心在于高效的数据检索。使用 where 进行条件过滤，project 选择特定字段。

// 查询过去一小时内HTTP状态码为500的请求
Logs
| where TimeGenerated > ago(1h)
| where Status == 500
| project TimeGenerated, OperationName, DurationMs

上述语句中，ago(1h) 表示当前时间前推1小时；project 仅输出指定列，提升性能和可读性。

聚合与排序
通过 summarize 实现数据聚合，常配合 by 分组统计。

函数	用途
count()	统计行数
avg(DurationMs)	计算平均耗时

2.3 常用日志表解析

在 Azure Monitor 中，安全日志数据主要存储于多个专用表中，其中 SecurityEvent、AzureActivity 和 CommonSecurityLog 最为关键。

SecurityEvent 表
记录 Windows 系统级别的安全事件，如登录成功/失败、权限变更等。常见字段包括 EventID、Account 和 IpAddress。

SecurityEvent
| where EventID == 4625
| project TimeGenerated, Account, IpAddress

该查询筛选出所有登录失败事件（EventID 4625），用于检测暴力破解行为。

AzureActivity 与 CommonSecurityLog

• AzureActivity：追踪 Azure 资源的管理操作，适用于合规审计。
• CommonSecurityLog：解析来自防火墙、WAF 等设备的标准化日志，支持多厂商格式。

表名	数据来源	典型用途
SecurityEvent	Windows事件日志	终端行为分析
AzureActivity	Azure Resource Manager	操作审计
CommonSecurityLog	网络安全设备	威胁检测

2.4 使用Log Analytics实现安全事件可视化

通过集成 Azure Monitor 与 Log Analytics，可将分散的安全日志集中采集并结构化存储，为后续分析提供数据基础。

查询语言入门
使用 Kusto 查询语言（KQL）可高效检索日志数据。例如，以下查询用于识别登录失败的异常峰值：

SecurityEvent
| where EventID == 4625
| summarize FailedAttempts = count() by IPAddress， bin(TimeGenerated, 1h)
| where FailedAttempts > 10

该查询筛选事件 ID 为 4625（账户登录失败）的日志，按 IP 和每小时分组统计尝试次数，并过滤出高频失败记录，有助于发现暴力破解行为。

可视化仪表板构建
将关键查询结果固定到 Azure 仪表板，形成实时安全态势视图。支持图表类型包括柱状图、地图（基于 IP 地理位置）和趋势线，提升威胁感知效率。

2.5 查询优化技巧与性能调优实践

索引设计与查询执行计划分析
合理的索引策略是提升查询性能的核心。应优先为高频查询条件字段创建复合索引，并避免过度索引导致写入开销增加。使用 EXPLAIN 分析执行计划，识别全表扫描或索引失效问题。

EXPLAIN SELECT user_id, name
FROM users
WHERE status = ‘active’ AND created_at > ‘2023-01-01’;

该语句展示如何查看查询的执行路径。重点关注 type（访问类型）、key（使用的索引）和 rows（扫描行数）。理想情况下应为 ref 或 range，且 rows 值越小越好。

查询重写与批量处理优化

• 避免在 WHERE 子句中对字段进行函数计算，防止索引失效。
• 用批量 INSERT/UPDATE 替代多次单条操作，减少事务开销。
• 使用延迟关联（Deferred Join）优化分页查询性能。

第三章：安全中心日志与威胁检测分析

3.1 Azure Security Center警报生成机制剖析

Azure Security Center（现为 Microsoft Defender for Cloud）通过持续监控资源的安全状态，结合威胁情报与机器学习模型，自动生成安全警报。

警报触发条件
警报基于以下信号源生成：

• 网络流量异常（如非常规端口访问）。
• 系统日志中的恶意行为模式。
• 漏洞扫描结果与合规性偏离。

规则匹配示例

{
  "alertRuleId": "NetworkPortScan",
  "severity": "High",
  "description": "检测到从单一源IP发起的大规模端口扫描行为"
}

该规则监控 NSG 流日志，当某 IP 在 5 分钟内访问超过 20 个不同目标端口时触发。参数 severity 决定响应优先级。

数据处理流程
数据采集 → 规则引擎匹配 → 威胁置信度评分 → 警报生成 → 事件聚合

3.2 高级威胁防护日志的采集与分析方法

日志采集架构设计
现代高级威胁防护（APT）系统依赖分布式日志采集架构，通过代理在终端、网络边界和云端同步收集行为日志。常用方案包括使用 Filebeat 或 Fluentd 作为轻量级日志转发器，将数据汇聚至集中式存储。

典型日志格式与解析
安全设备输出的日志通常为 JSON 格式，包含时间戳、源 IP、目标 IP、威胁类型等字段。例如：

{
  "timestamp": "2025-04-05T10:23:45Z",
  "src_ip": "192.168.1.105",
  "dst_ip": "203.0.113.45",
  "threat_type": "C2_Communication",
  "severity": "high"
}

该结构便于 ELK 栈进行索引与检索，其中 threat_type 字段用于分类攻击模式，severity 支持优先级排序。

威胁行为关联分析
利用 SIEM 平台对多源日志执行关联规则匹配，识别隐蔽攻击链。常见策略包括：

• 横向移动检测：连续登录多个主机的异常行为。
• 数据外传模式识别：大流量传出至非业务 IP。
• 定时通信特征匹配：疑似 C2 信道的心跳机制。

3.3 实战：基于日志识别潜在横向移动行为

日志特征分析
在域环境中，攻击者完成初始入侵后常通过 SMB、WMI 或 PsExec 进行横向移动。典型行为包括异常时间登录、高频次失败登录后成功、非管理员账户触发远程服务创建等。Windows 安全日志 ID 4624（登录成功）、4648（显式凭证使用）、5140（网络共享访问）是关键检测源。

检测规则示例
使用 SIEM 查询语言编写检测逻辑：

SecurityEvent
| where EventID in (4624, 4648， 5140)
| where LogonType == 3 and AccountType == “User”
| summarize count() by SourceNetworkAddress, AccountName, LogonType
| where count_ > 5

该查询识别从同一源 IP 对多主机发起的远程登录行为，阈值设定为 5 次以上，可有效发现扫描式横向移动。

关联分析策略

• 将登录事件与进程创建事件关联。
• 标记短时间内跨多主机执行相同命令的账户。
• 结合用户权限组变化判断提权后扩散行为。

第四章：身份与网络层面的日志深度挖掘

4.1 Azure AD登录日志分析与异常登录识别

Azure AD 登录日志是监控身份安全的核心数据源，通过分析用户登录行为可及时发现潜在威胁。日志包含登录时间、IP 地址、设备信息、风险等级等关键字段，支持在 Azure 门户或 Microsoft Graph API 中查询。

关键登录属性示例

字段	说明
userDisplayName	登录用户显示名称
ipAddress	登录来源 IP，用于地理定位分析
status	登录成功或失败状态
riskLevel	系统评估的风险等级（低/中/高）

使用Kusto查询异常登录

let suspiciousIps = datatable(ip:string)
  [“192.168.1.100”, “203.0.113.5”];
SigninLogs
| where ipAddress in (suspiciousIps)
   or riskLevel == “high”
| project userDisplayName, ipAddress, location, status， riskLevel

该查询识别来自已知可疑 IP 或被标记为高风险的登录事件。project 子句提取关键字段便于审计分析，适用于自动化告警场景。

4.2 条件访问策略执行日志的解读与验证

解读条件访问策略执行日志是确保安全策略按预期生效的关键步骤。Azure AD 提供详细的登录日志，可用于验证用户访问请求是否被正确评估和执行。

日志核心字段解析
登录日志中的关键字段包括：

• ConditionalAccessStatus：显示策略应用状态（如“成功”或“失败”）。
• ConditionalAccessPolicies：列出评估的所有策略及其执行结果。
• GrantControls 和 SessionControls：标明强制执行的控制类型。

典型日志分析示例

{
  "conditionalAccessPolicies": [
    {
      "id": "d659b780-…",
      "displayName": "Require MFA for Admins",
      "enforcedGrantControls": ["Mfa"],
      "status": "success"
    }
  ],
  "conditionalAccessStatus": "success"
}

该日志表明策略 “Require MFA for Admins” 已成功执行，且多因素认证控制已强制实施。字段 status: success 表示用户满足所有条件并通过验证。

验证流程建议
通过 Azure Monitor 或 Microsoft Graph API 定期检索登录日志，结合用户角色与访问上下文进行交叉验证，确保策略覆盖无遗漏。

4.3 NSG流日志与Azure Firewall日志关联分析

在复杂网络安全监控中，单独分析 NSG 流日志或 Azure Firewall 日志难以全面识别威胁。通过将两者日志统一接入 Azure Monitor 并利用 Log Analytics 进行关联，可实现更精准的流量行为画像。

日志数据整合流程

• 启用 NSG 流日志并发送至指定 Log Analytics 工作区。
• 配置 Azure Firewall 诊断设置，输出日志至同一工作区。
• 使用共同字段（如源/目标 IP、端口、时间戳）进行跨表查询。

联合查询示例

CommonSecurityLog
| where DeviceVendor == “Microsoft” and DeviceProduct == “AzureFirewall”
| project TimeGenerated, SrcIpAddr, DestIpAddr, DestPort, Action
| join (
    AzureNetworkAnalytics_CL
    | where SubType_s == “FlowLog”
    | project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, FlowStatus = FlowStatus_s
) on $left.SrcIpAddr == $right.SrcIP_s and $left.DestIpAddr == $right.DestIP_s
| project TimeGenerated, SrcIpAddr, DestIpAddr, DestPort, Action, FlowStatus

该 Kusto 查询通过 SrcIpAddr 与 DestIpAddr 关联双源日志，识别防火墙允许但 NSG 拒绝的异常流量模式，提升威胁检测精度。

4.4 实战：构建多维度安全事件关联分析视图

在现代安全运营中，孤立的安全告警难以反映真实攻击链。需整合网络流量、终端行为、身份认证与日志审计等多源数据，构建统一的关联分析视图。

数据融合建模
通过定义标准化事件模型，将异构数据映射为统一格式：

{
  "timestamp": "2023-10-01T08:23:10Z",
  "event_type": "authentication_failed",
  "src_ip": "192.168.1.105",
  "user": "admin",
  "sensor": "firewall-01"
}

该结构便于后续基于时间窗口和实体关系进行聚合分析。

关联规则设计
采用基于规则引擎的匹配策略，识别典型攻击模式，这也是安全渗透分析中的常见方法：

• 同一 IP 在 5 分钟内出现 3 次以上认证失败 → 触发暴力破解告警。
• 外部 IP 登录成功后立即访问数据库端口 → 标记为高风险会话。
• 用户在非工作时间从异地登录并执行特权命令 → 启动多因素验证挑战。

第五章：通过日志分析提升AZ-500考试实战能力

理解Azure Monitor与诊断日志的集成
在 AZ-500 考试中，日志分析是评估威胁响应和安全监控能力的核心部分。Azure Monitor 通过收集来自 Azure 资源、操作系统和应用程序的日志数据，为安全审计提供关键支持。启用诊断日志时，需将资源日志导出到 Log Analytics 工作区。例如，为网络安全性组（NSG）启用日志记录：

{
  "properties": {
    "workspaceId": "/subscriptions/xxx/resourcegroups/rg-log/providers/microsoft.operationalinsights/workspaces/log-workspace",
    "logs": [
      {
        "category": "NetworkSecurityGroupEvent",
        "enabled": true
      }
    ]
  }
}

利用Kusto查询语言检测异常行为
Log Analytics 使用 Kusto（KQL）进行高效日志查询。识别可疑登录尝试可通过以下查询实现：

SigninLogs
| where ResultType == “50140”
| where UserPrincipalName endswith “@contoso.com”
| project TimeGenerated, UserPrincipalName, IPAddress， Status
| sort by TimeGenerated desc

该查询可发现来自非常用位置的登录失败事件，是身份保护场景中的典型应用。

配置警报规则以实现主动防御
基于日志分析结果创建警报，有助于在实际攻击发生前采取措施。下表列出了常见安全场景及其对应的日志源与阈值设置：

安全场景	日志源	触发条件
多次登录失败	SigninLogs	5次失败/5分钟
NSG阻止大量入站连接	NetworkSecurityGroupEvent	超过1000次拒绝/小时

通过自动化响应，可显著提升防御效率。