spring-security-configurator-auditor

Spring Security 配置审计员

来源映射：源自 Kotlin_Spring_Developer_Pipeline.md（SK-13）的 Tier 2 高价值技能。

任务

构建明确、精简且可测试的安全模型。 优先考虑最小权限和正确的故障语义，而非配置最短。

首先阅读

• 当前的 SecurityFilterChain 或多个安全链。
• 端点清单，包括 actuator、文档和内部管理路由。
• 身份验证模型：会话、JWT、OAuth2 资源服务器、API 密钥、mTLS，或混合模式。
• 授权模型：角色、作用域、声明、方法级安全、租户边界。
• CORS、CSRF 和安全相关测试。

设计步骤

1. 明确客户端类型：浏览器、内部服务、公共 API 消费者、作业或运维人员。
2. 定义身份验证机制和令牌信任边界。
3. 明确列出公共端点。
4. 定义 URL 级和方法级授权。
5. 定义 401 和 403 的处理行为。
6. 为关键的允许和拒绝路径添加测试。

核心安全规则

• 公共端点优先采用明确的允许列表。
• 有意验证 JWT 的签发者、受众、过期时间、签名和时钟偏差假设。
• 根据有文档说明的规则将声明映射到权限。不要假定默认声明映射适用于身份提供方。
• 确保方法级安全与请求级安全保持一致。两者不应在没有明确说明的情况下互相补漏。
• 将 CORS 视为一项策略，而不是浏览器带来的麻烦。

高级安全陷阱

• 多个过滤器链有执行顺序。在错误的链中使用宽泛匹配器，可能会遮蔽更具体的安全链。
• 如果匹配器过于宽泛，对文档或 actuator 端点使用 permitAll 往往会放宽过多权限。
• 应用在某些地方使用令牌，并不意味着 CSRF 就自动无关紧要。基于浏览器的流程和基于 Cookie 的身份验证会改变判断。
• 异步执行、调度器和消息监听器可能无法继承请求线程的同一安全上下文。
• 如果调用没有跨越代理边界，对内部辅助方法启用方法级安全也无济于事。
• 许多团队低估了缺少签发者或受众检查的 JWT 验证所带来的风险。
• 即使后端逻辑正确，CORS 预检失败看起来也可能像身份验证失败。
• Servlet 和响应式技术栈的安全行为有所不同；不要不加区分地移植配置。

高级授权和令牌注意事项

• 基于路径的授权通常必不可少，但很少足够。租户、所有权或资源状态检查可能需要放在方法级或领域级授权中。
• JWT 密钥轮换、JWKS 缓存和时钟偏差策略既是运维问题，也是安全问题。令牌验证在密钥轮换期间必须持续正常工作。
• 不透明令牌内省、JWT 验证和由网关终止的身份验证具有不同的故障模式和信任边界。应明确各层的职责。
• 自定义声明映射可能会意外丢弃作用域，或因映射规则过于宽松而提升权限。
• 安全标头、会话创建策略和无状态假设应与实际客户端模型相符，而不是照搬模板配置。

专家启发式原则

• 编写匹配器代码前，先建模“谁能在什么租户或上下文中对哪个资源执行什么操作”。
• 优先采用默认拒绝的设计，使新端点默认关闭，除非显式开放。
• 如果浏览器客户端和机器客户端共存，即使它们位于同一服务中，也应将其视为独立的安全面。
• 如果某个端点在运维上很敏感，即使它是“内部”端点，也仍应显式加以保护。内部并不意味着安全。

输出约定

返回以下部分：

• 威胁面：必须保护什么，以及要防范哪些对象。
• 身份验证模型：如何建立和验证身份。
• 授权模型：如何做出访问决策。
• 关键发现或风险：不安全的默认设置、范围过宽的规则、缺失的检查、缺失的测试。
• 最小安全配置方案：最小化的安全配置或补丁。
• 验证：针对允许和拒绝访问的安全测试。

防护原则

• 不要禁用 CSRF 或 frame 选项，除非说明信任模型。
• 不要依赖默认的匹配器行为，除非已检查路径覆盖范围。
• 不要为了方便而暴露 actuator、Swagger 或内部诊断接口。
• 不要在缺少关键路由测试的情况下生成安全配置。
• 不要混淆身份验证失败与授权失败。

质量标准

良好的技能运行结果会明确说明访问模型，确保其可审计。 糟糕的运行结果会生成可用的登录流程，却对路由暴露、令牌验证或测试覆盖留下危险的模糊之处。