第13章：IDaaS 审计与合规 — 等保、ISO 27001 与异常检测实践 | IDaaS Book

13.1 审计的价值#

身份审计不仅仅是"记录日志"，它是安全运营的三大支柱之一：

         安全三角
       ┌──────────┐
认证 ──┤          ├── 授权
       │   审计    │
       └──────────┘

审计回答：谁，在何时，从哪里，做了什么，结果如何？

这对应了身份安全的最后一道防线——如果认证和授权都失效，审计日志是事后追溯的唯一依据。

13.2 审计事件分类#

IDaaS 系统应记录的事件类型：

认证事件#

授权事件#

管理事件#

13.3 审计日志设计#

日志结构#

标准化的审计日志应包含：

{
  "timestamp": "2024-01-01T08:00:00.000Z",
  "event_type": "authentication.success",
  "severity": "info",
  "source_system": "keycloak",
  "user": {
    "id": "user-12345",
    "username": "zhangsan",
    "email": "[email protected]"
  },
  "actor": {                    // 操作者（可能是管理员，可能与 user 不同）
    "id": "admin-1",
    "username": "admin",
    "ip": "10.0.1.15",
    "user_agent": "Mozilla/5.0...",
    "geo": {
      "country": "CN",
      "city": "Beijing"
    }
  },
  "target": {                   // 操作目标
    "type": "user",
    "id": "user-67890"
  },
  "action": {
    "type": "login",
    "result": "success",
    "auth_method": "password+mfa_otp"
  },
  "session_id": "session-abc123",
  "request_id": "req-xyz789",
  "client_id": "my-app",
  "realm": "corp",
  "details": "登录成功，MFA 验证通过"
}

关键设计原则#

1. 不可篡改：保留在安全的存储中（只追加，不修改），防内部人员篡改。
2. 完整性：使用哈希链或签名确保日志的完整性。
3. 标准化格式：所有事件使用统一的 Schema（可参考 OpenTelemetry 日志模型）。
4. 关联性：使用 request_id、session_id 将多个事件关联到同一个用户操作链。
5. 不记录敏感信息：密码、Token、生物特征绝不能出现在日志中。
6. 时区标准化：所有时间戳使用 UTC。

日志存储#

日志保留策略#

13.4 合规框架#

等保 2.0（中国）#

等级保护 2.0 对身份管理的要求（以下为三级及以上要求）：

• 身份鉴别（安全计算环境 L3）：应支持两种或两种以上组合的鉴别技术
• 访问控制：访问控制策略应基于安全标记，粒度应达到主体为用户级或进程级，客体为文件、数据库表/记录、字段级
• 安全审计：应对用户登录、修改、删除、用户权限变更等操作进行审计
• 审计记录：包括事件日期、时间、用户、事件类型、事件是否成功及其他审计相关的内容
• 日志留存：三级及以上要求审计日志留存不少于 6 个月，且记录应受保护，避免未预期的删除、修改或覆盖

等保 3.0 / 关键信息基础设施保护#

《关键信息基础设施安全保护条例》（2021 年 9 月 1 日施行）在等保 2.0 基础上叠加对关键信息基础设施（CII）运营者的增强要求：更严格的身份鉴别与审计、每年至少一次安全整改/检查、数据出境合规等。IDaaS 在为关基行业服务时需同时满足等保 2.0 与关基增强要求。

ISO/IEC 27001:2022#

ISO/IEC 27001:2022 附录 A 已将旧版 14 个领域（A.5–A.18）重构为 4 大类共 93 个控制，旧版 A.9"访问控制"已不存在。与身份和访问管理相关的关键控制（2022 版编号）：

• A.5.15 访问控制、A.5.16 身份管理、A.5.17 认证信息、A.5.18 访问权限管理
• A.8.2 特权访问、A.8.3 信息访问限制
• 用户访问管理应包含正式的注册和注销流程，访问权限应定期审查，特权访问权限应严格管控

SOC 2#

SOC 2 基于 AICPA 信任服务标准（TSP），核心为 Security 类别下的 Common Criteria：

• CC6 逻辑与物理访问控制（CC6.1–CC6.3 涵盖逻辑访问、用户注册与权限管理）
• CC7 系统运行与监控
• CC8 变更管理
• 报告分 Type I（控制设计有效性，时点）与 Type II（控制运营有效性，期间）

GDPR / 个人信息保护法#

• 数据处理的最小化（只收集必要的身份数据）
• 数据主体的权利（访问权、更正权、删除权）
• GDPR Art.30 处理活动记录（RoPA）；中国《个人信息保护法》第 55 条个人信息处理者义务/影响评估

13.5 异常检测与告警#

需要告警的场景#

异常检测技术#

• 基于规则：固定阈值（如登录失败 > 5 次）
• 基于统计：基于历史数据的统计偏差（如登录时间异常、登录地点异常）
• 基于 ML：无监督学习检测异常模式

13.6 审计即代码#

建议将审计配置作为代码管理：

# audit-policy.yaml
audit:
  events:
    authentication:
      success: true
      failure: true
      logout: true
    authorization:
      grant: true
      revoke: true
      deny: true
    admin:
      user_create: true
      user_delete: true
      user_disable: true
      role_change: true
      policy_change: true
  
  retention:
    default_days: 90
    admin_events_days: 365
    security_events_days: 365
  
  alerts:
    - name: brute_force_attempt
      condition: auth_failure.count > 5 in 5m per user
      severity: medium
      channel: ["email", "slack"]
    
    - name: impossible_travel
      condition: login from two countries within 1 hour
      severity: high
      channel: ["email", "pagerduty"]

13.7 实际运营建议#

1. 从第一天就开始收集审计日志，而不是等到需要时才补。
2. 定期演练：模拟安全事件，确保运维团队能从日志中快速找到关键信息。
3. 自动化：通过 SIEM 工具或自定义脚本自动检测异常。
4. 保留原始日志：即使做了聚合和加工，也要保留原始日志。
5. 保护日志：日志系统本身的访问权限要严格控制。

13.8 小结#

审计是 IDaaS 安全链条的"事后"环节，但其价值在于"事前"威慑和"事中"发现。好的审计不只是记录发生了什么，而应该能主动发现异常、支撑合规检查、在安全事件发生时快速提供溯源依据。不要等到安全事故发生后才后悔没有好好记录审计日志。