3、日志检索准入门禁概念：准入策略、日志格式校验、敏感信息脱敏、合规审计
在可观测性体系中，日志检索并非无限制开放。未经管控的日志接入会导致数据格式混乱、敏感信息泄露、存储成本失控以及合规风险。本章引入“日志检索准入门禁”概念，在日志数据进入检索系统之前建立一道标准化、可审计的屏障。准入门禁的核心由四个模块构成：准入策略、日志格式校验、敏感信息脱敏与合规审计。
核心原则：准入门禁不是拒绝日志，而是确保每一条进入检索系统的日志都满足格式规范、安全约束与合规要求。拒绝脏数据，保护敏感字段，记录每一次准入决策。
3.1 准入策略：谁、什么、如何进入
准入策略是准入门禁的第一道关卡，定义了日志数据进入检索系统的规则集合。策略通常基于以下三个维度进行判定：
- 来源身份（Who）：日志产生的主机名、容器名、命名空间、服务名、集群标识。只有白名单内的来源才允许提交日志。
- 日志类型（What）：访问日志、应用日志、系统日志、安全日志等。不同类型可配置不同的校验与脱敏规则。
- 提交方式（How）：通过 Filebeat、Fluentd、Promtail、OTel Collector 等 Agent 提交，或通过 HTTP API 直接写入。不同通道可设置不同的速率限制与认证要求。
| 策略维度 | 典型字段 | 准入动作 |
|---|---|---|
| 来源身份 | hostname, namespace, service_name | 白名单放行 / 黑名单拒绝 |
| 日志类型 | log_type, level, component | 按类型路由到不同校验管道 |
| 提交方式 | agent_version, protocol, | 速率限制 / 认证校验 / TLS 检查 |
实践建议：准入策略应支持热加载，避免每次策略变更都需要重启日志采集管道。推荐将策略存储在 etcd 或 Consul 中，由准入控制器定期同步。
3.2 日志格式校验：拒绝脏数据
日志格式校验确保每一条日志都符合预定义的 schema 要求。常见的校验项包括：
- 必填字段检查：timestamp、level、message、service.name 等字段必须存在且非空。
- 字段类型校验：timestamp 必须是 ISO 8601 格式或 Unix 时间戳；level 必须在 debug/info/warn/error/fatal 范围内。
- 字段长度限制：message 字段最大长度（如 10KB），避免单条日志过大导致存储与检索性能问题。
- JSON 语法校验：如果日志以 JSON 格式提交，必须解析为合法 JSON 对象，不允许出现截断或格式错误。
# 示例：Prometheus 风格的日志格式校验规则（伪代码）
rules:
- field: timestamp
required: true
type: datetime
format: "2006-01-02T15:04:05Z07:00"
- field: level
required: true
type: enum
values: ["debug", "info", "warn", "error", "fatal"]
- field: message
required: true
type: string
max_length: 10240
- field: service.name
required: true
type: string
pattern: "^[a-z0-9-]+$"
注意：格式校验失败不应直接丢弃日志，而应将日志路由到“格式异常队列”进行人工或自动修复，同时记录失败原因用于后续告警。完全丢弃可能导致问题排查时丢失关键线索。
3.3 敏感信息脱敏：保护数据安全
日志中经常包含用户隐私、密钥、、身份证号、银行卡号等敏感信息。准入门禁必须在日志写入检索系统之前完成脱敏处理。脱敏策略通常包括：
| 敏感类型 | 匹配模式 | 脱敏方式 | 示例 |
|---|---|---|---|
| 密码 / | password=.*?(&|$) | 替换为 ****** | password=abc123 → password=****** |
| 身份证号 | \d{17}[\dXx] | 保留前4后4，中间掩码 | 110101199001011234 → 1101********1234 |
| 手机号 | 1[3-9]\d{9} | 保留前3后4，中间掩码 | 13800138000 → 138****8000 |
| 信用卡号 | \d{16} | 保留前6后4，中间掩码 | 6222021234567890 → 622202****7890 |
脱敏应在日志采集端（Agent 侧）或准入门禁服务端完成，确保敏感信息不会以明文形式进入存储层。脱敏规则应支持正则表达式与自定义函数扩展。
# 脱敏配置示例（YAML）
masking:
- name: "password"
pattern: '(password|secret|)=([^&]+)'
replacement: '$1=******'
- name: "id_card"
pattern: '(\d{4})\d{13}(\d{4})'
replacement: '$1************$2'
- name: "phone"
pattern: '(1[3-9]\d{2})\d{4}(\d{4})'
replacement: '$1****$2'3.4 合规审计：可追溯的准入记录
合规审计是准入门禁的最后一环，确保每一次准入决策、格式校验结果、脱敏操作都有据可查。审计日志需要记录以下关键信息：
- 时间戳：准入决策发生的精确时间。
- 来源标识：提交日志的主机、服务、Agent 信息。
- 决策结果：通过 / 拒绝 / 格式异常 / 脱敏触发。
- 原始日志摘要：对原始日志进行 hash（SHA256），不存储明文，用于事后比对。
- 脱敏字段列表：记录哪些字段被脱敏，脱敏规则版本号。
- 操作人/系统：如果是手动调整准入策略，记录操作者身份。
| 审计字段 | 说明 | 示例值 |
|---|---|---|
| audit_id | 全局唯一审计 ID | aud-20250321-001234 |
| timestamp | 决策时间（纳秒精度） | 2025-03-21T14:30:00.123456789Z |
| source | 日志来源标识 | namespace=prod, service=api-gateway |
| decision | 准入决策结果 | PASS / REJECT / MASKED |
| log_hash | 原始日志 SHA256 | a1b2c3d4e5f6... |
| masked_fields | 被脱敏的字段列表 | ["password", "id_card"] |
合规要求：审计日志本身也需要保护，建议写入独立的、仅追加的存储（如 WAL 或不可变日志流），并设置合理的保留周期（通常 1-3 年）。审计日志的访问权限应严格限制，仅允许合规与安全团队读取。
通过准入策略、格式校验、敏感信息脱敏与合规审计四个模块的协同工作，日志检索准入门禁能够有效提升日志数据的质量、安全性与可追溯性，为后续的检索、分析与告警奠定坚实基础。