【零信任安全架构】零信任可观测性与 SIEM 集成：日志、决策与自动化响应

零信任架构的安全日志量比传统架构多一个数量级。原因很简单——传统架构在边界上做一次访问控制（防火墙规则），零信任在每次资源访问时都做（PDP + PEP）。每一个”张三能不能访问这个资源”的决策都是一个日志事件。

前置阅读：零信任策略引擎、微分段深度拆解。

一、三层日志

第一层：PDP 决策日志

PDP（策略引擎）的每一个 allow/deny/step-up 决策都应有结构化日志：

{
  "timestamp": "2026-06-12T14:23:11.456Z",
  "decision": "deny",
  "reason": "device_tier_below_required",
  "subject": {
    "user": "zhangsan@example.com",
    "spiffe_id": "spiffe://prod.example.com/user/zhangsan",
    "groups": ["engineering"]
  },
  "resource": {
    "app": "production-database",
    "endpoint": "/api/query",
    "sensitivity": "HIGH"
  },
  "context": {
    "device_tier": "basic",
    "required_tier": "trusted",
    "device_id": "macbook-pro-abc123",
    "ip": "203.0.113.42",
    "geo_country": "CN"
  }
}

关键设计点： - Decision + Reason：不只是 allow/deny，还记录”为什么”——降级原因（device_tier_below_required, outside_business_hours, anomalous_location） - Subject 和 Context 的完整快照：事后调查需要知道”这个 deny 事件发生时设备和用户的状态是什么” - 足够的标识符：user + spiffe_id + device_id 三个独立标识符允许跨系统关联

第二层：证书和身份生命周期日志

SPIRE、Vault、cert-manager 的证书签发、续期和吊销事件。

关注的异常模式： - 同一个 SPIFFE ID 在 1 分钟内被签发两次证书 → 可能的证书窃取和重放 - 一个身份突然在非预期的节点上签发证书 → 可能的节点 ID 冒充 - 证书续期失败反复发生 → SPIRE Agent 或 SDS 连接问题

第三层：微分段 allow/deny 事件

Cilium、Calico、Istio 的微分段允许/拒绝事件（网络层或应用层）。

[2026-06-12T14:23:13.456Z] DROP: src=order-service(192.168.1.50) → dst=payment-service(192.168.1.75):8443
  reason: CiliumNetworkPolicy:deny-order-to-payment

微分段日志的挑战：网络层 deny 事件的量级可能非常高（恶意扫描每个端口都会被记录），需要采样或聚合。

二、零信任特有的检测规则

规则 1：同一用户从不同设备同时访问

SELECT user, device_id, COUNT(DISTINCT device_id) as device_count
FROM access_decisions
WHERE decision = 'allow' AND timestamp > NOW() - INTERVAL 5 MINUTE
GROUP BY user
HAVING device_count > 1
→ 可能的账户共享或凭据被盗

规则 2：设备降级后仍尝试访问高敏感资源

同一 device_id 的访问事件序列:
  t=0: decision=allow, device_tier=trusted, resource_sensitivity=HIGH
  t=1: device posture change → device_tier 降级到 basic
  t=2: decision=deny, device_tier=basic, resource_sensitivity=HIGH
  （连续 5 次 deny）→ 可能的攻击者在已知设备降级后反复尝试

规则 3：mTLS 证书异常

同一 SPIRE Agent 在 5 分钟内为不同的 SPIFFE ID 签发了证书
→ 如果这不是合法的 CI/CD 部署（多服务同时部署），可能是 Agent 被用于伪造多个身份

规则 4：微分段 deny 事件突增

某个 Pod 的 deny 事件从平均 10/min 突增到 1000/min
→ 可能的端口扫描或攻击探测

三、SIEM/SOAR 的自动化响应

检测到异常后，SIEM 通过 Playbook 触发 SOAR（Security Orchestration, Automation and Response）的自动化响应：

Playbook: "检测到设备降级攻击"
  Trigger: 同一 device_id 在降级后连续 5 次 deny
  Actions:
    1. 在 SIEM 中标记该设备为 "suspicious"
    2. 通过 SPIRE API 吊销该设备的所有 SVID
    3. 在 MDM 平台锁定该设备（如果是公司设备）
    4. 为该用户生成一个新的 Incident Ticket
    5. 通知安全团队（Slack / PagerDuty）

关键工程决策：哪些响应完全自动化、哪些需要人工确认？ ZTMM Advanced 等级的推荐是”低置信度事件 → 告警给人，高置信度 + 低误报率事件 → 自动响应”。自动化恢复的边界是”误响应造成的业务中断成本 < 延迟响应造成的安全损失”。

四、日志的存储成本

每天数百万次访问决策的日志存储和搜索成本不可忽略。一个 500 人工程组织的日均 PDP 决策事件量（假设每人每天 1000 次资源访问，每次资源访问触发 1 次 PDP 决策 = 500K 次，加上服务间调用的 PDP 检查 ≈ 200 万次）在每天 200 万到 500 万条事件之间。

搜索这些日志需要全文索引 + 时序数据存储的组合： - 最近 30 天的日志在 SIEM 的热存储中（全文搜索 + 实时告警） - 30 天到 1 年的日志在云对象存储中（按天分区，压缩后的 JSON，用于事后调查） - 超过 1 年的日志按法规要求保留或删除（GDPR 要求最小化个人数据的保留时间）

下一篇：行业案例深度复盘。

参考资料

1. OpenTelemetry. Log Data Model. https://opentelemetry.io/docs/specs/otel/logs/data-model/
2. Splunk. Common Information Model. https://docs.splunk.com/Documentation/CIM
3. MITRE. ATT&CK for Enterprise. https://attack.mitre.org/