纵深防御安全 是做什么的?
概述
安全是分层的,假定任何单层都可能失效,并授予能够工作的最小权限。攻击者总能找到你忽略的那一层——依赖单一墙的系统,当那面墙有一个 bug 就会倒塌;而重叠的最小权限控制能够在任何一个控制失效时幸存下来。
原则(通用)
- 在构建任何处理不受信任输入、密钥或用户数据的内容之前,先进行威胁建模。 对每个新的攻击面执行一次轻量级的 STRIDE 检查(欺骗、篡改、抵赖、信息泄露、拒绝服务、权限提升)。记录模型和缓解措施(参见
recording-decisions)。 - 纵深防御。 没有单一控制是“唯一的”安全措施。认证、授权、输入验证和数据层执行各自都假定其他控制可能被绕过。
- 处处遵循最小权限原则——角色、令牌、服务账户、数据库授权。默认无权限;授予最少权限;撤销未使用的权限。
- 密钥永远不应存在于代码、镜像或已提交的配置中。 它们应在运行时来自密钥存储,可轮换,且作用域仅限于需要它们的负载。
- 在信任边界验证所有输入; 将每个外部系统的输出视为不受信任的数据,而不是指令。
- 依赖供应链是一个攻击面。 锁定文件已提交并进行完整性检查;依赖项已扫描并更新;基础镜像已固定并扫描。
- 敏感操作应被审计——谁在何时做了什么——以便可以重建滥用和错误行为。
快速参考
| 攻击面 | 首要问题 |
|---|---|
| 接受用户输入的新端点 | STRIDE 模型是什么?验证在哪里?可工作的最小角色是什么? |
| 任何涉及密钥的内容 | 它是否在密钥存储中(而不是代码/镜像)?作用域是否合理?是否可轮换? |
| 新的依赖项 | 锁定文件是否已固定?已扫描?是否得到了良好支持? |
| 特权变更操作 | 是否已审计?执行者是否在数据层(而不仅仅是应用层)被授权? |
技术栈机制
RLS 作为最终执行层,GraphQL 深度/成本限制作为 DoS 控制,Key Vault 用于密钥管理,CI 中的 pnpm audit/Trivy——参见 postgres-postgraphile-rls-and-sql 和 cloud-delivery-aks。
强制执行: CI 中的依赖审计 + 镜像扫描 + 密钥扫描(阻塞性);威胁模型和审计覆盖率由评审者判断。
完整理由:参见汇编文件第 X 条和第 XIV 条,捆绑在 engineering-constitution/references/engineering-constitution.md 中。