4. 威胁建模入门：STRIDE模型在多租户可观测性系统中的应用

威胁建模是安全架构设计的起点。对于多租户可观测性系统，数据流跨越租户边界、存储层与查询层，攻击面比单租户系统复杂得多。本章以微软 STRIDE 模型为框架，系统拆解可观测性管道中每一阶段的威胁，并给出对应的缓解策略。

4.1 STRIDE 模型回顾

STRIDE 是六类威胁的首字母缩写，覆盖了大多数软件系统的攻击面：

4.2 多租户可观测性系统的数据流与信任边界

下图展示了典型的多租户可观测性管道，包含三个主要信任边界：租户边界、管道边界和存储边界。每个边界都是 STRIDE 威胁的潜在切入点。

4.3 按 STRIDE 类别逐项分析威胁

4.3.1 Spoofing（欺骗）—— 身份伪造

在多租户系统中，攻击者可能伪造租户身份向 Collector 发送数据，或伪造查询用户身份获取其他租户的数据。

• 威胁场景：攻击者窃取租户 A 的 API Token，以租户 A 身份写入恶意日志，污染分析结果。
• 缓解措施：
  • 所有数据写入和查询请求必须携带强认证凭证（mTLS / OAuth2）。
  • Collector 层校验租户 ID 与凭证的绑定关系，拒绝不匹配的请求。

4.3.2 Tampering（篡改）—— 数据篡改

攻击者可能在传输过程中或存储层修改可观测性数据，导致告警误报或掩盖真实攻击。

• 威胁场景：中间人攻击篡改链路追踪中的 span 标签，注入虚假调用链。
• 缓解措施：
  • 端到端数据完整性校验（如对每条日志/指标计算 HMAC）。
  • 使用 TLS 加密传输通道，防止中间人篡改。
  • 存储层启用 WORM（Write Once Read Many）策略，防止事后篡改。

4.3.3 Repudiation（抵赖）—— 操作抵赖

租户或管理员可能否认执行过某些操作，例如删除审计日志或修改告警规则。

• 威胁场景：租户 B 通过 API 删除了自己的日志流，事后声称是系统故障。
• 缓解措施：
  • 所有管理操作和关键数据变更记录不可篡改的审计日志。
  • 审计日志独立存储，租户无权删除或修改。
  • 使用数字签名对审计事件进行签名，确保不可抵赖。

4.3.4 Information Disclosure（信息泄露）—— 跨租户数据泄露

这是多租户可观测性系统最严重的威胁之一。攻击者可能通过查询接口、错误信息或备份文件获取其他租户的敏感数据。

• 威胁场景：租户 A 通过修改查询参数中的租户 ID，获取租户 B 的指标数据。
• 缓解措施：
  • 查询网关强制实施租户数据隔离，查询结果自动过滤非授权数据。
  • 存储层使用租户级分区或标签索引，防止跨租户扫描。
  • 错误信息不暴露其他租户的存在或数据特征。

4.3.5 Denial of Service（拒绝服务）—— 资源耗尽

单个租户的恶意行为可能导致整个可观测性管道不可用，影响所有租户。

• 威胁场景：租户 C 每秒发送 100 万条指标，导致 Collector CPU 满载，其他租户数据丢失。
• 缓解措施：
  • Collector 层实施租户级限流和速率限制。
  • 消息队列使用租户隔离的 Topic 或分区，防止单个租户打满队列。
  • 存储层设置写入 QPS 上限和存储容量配额。

4.3.6 Elevation of Privilege（权限提升）—— 越权操作

低权限用户通过漏洞获得高权限操作能力，例如只读用户执行写操作或普通租户获得管理员权限。

• 威胁场景：只读用户通过 API 参数注入，调用删除告警规则的接口。
• 缓解措施：
  • 严格执行最小权限原则，API 端点按角色分级授权。
  • 所有写操作要求二次确认或 MFA 验证。
  • 定期进行权限审计，检测异常权限分配。

4.4 STRIDE 威胁缓解矩阵

下表汇总了每个 STRIDE 类别在多租户可观测性系统中的关键缓解措施：

4.5 威胁建模工作流

在实际项目中，建议按以下步骤开展威胁建模：

1. 绘制数据流图：标识所有组件、数据存储、信任边界和数据流方向。
2. 枚举 STRIDE 威胁：对每个数据流和存储节点，逐一检查六类威胁。
3. 评估风险等级：使用 DREAD 或 CVSS 评分，确定威胁的严重程度。
4. 设计缓解措施：为高风险威胁制定具体的技术或流程缓解方案。
5. 验证与迭代：通过渗透测试或代码审计验证缓解措施的有效性。

4.6 本章小结