核心接口必须加白名单鉴权，优先锁定身份认证、关键业务动作和模型服务三类高危接口；推荐网关层实现，辅以应用层和数据库层防护；白名单需支持热更新、默认安全及应急熔断，并与jwt双因子校验结合。
核心接口一旦暴露在公网，没有白名单鉴权，就等于把大门钥匙挂在门口。真正的防护不是“防不住再说”，而是从请求源头开始拦截——只放行明确信任的调用方，其余一律拒绝。
明确哪些接口必须加白名单
不是所有接口都需要同等强度防护。优先锁定三类高危接口：
- 涉及身份认证、用户数据读写（如 /api/v1/user/profile）
- 触发关键业务动作（如 /api/v1/sms/send、/api/v1/transfer）
- 模型服务类敏感能力接口（如实时口罩检测的 POST /detect）
这些接口一旦被未授权调用，可能直接导致资损、数据泄露或服务瘫痪。其他普通查询类接口可暂不强制，但建议后续统一纳入管理。
选择适合的白名单实现层级
防护越靠近网络边缘，拦截越早、越高效。按优先级推荐：
- 网关层（首选）：在 Nginx、Kong 或云厂商 API 网关配置 IP 白名单，用 allow/deny 规则直接拒绝非法请求，不触达后端服务
- 应用层（补充）：用 Spring AOP 注解（如 @RestrictToInternalIp）或 Flask 装饰器，在代码中校验 request.remote_addr，支持通配符（192.168.）和 CIDR（10.0.0.0/8）
- 数据库/中间件层（兜底）：如 Redis 或 MySQL 配置仅允许指定内网 IP 连接，防止绕过应用层直接访问
白名单配置必须包含动态与容灾机制
静态写死的 IP 列表在生产环境极易失效。务必支持：
- 热更新：通过数据库配置表（如 sys_config）、配置中心（Nacos/Apollo）或环境变量加载白名单，修改后无需重启服务
- 默认安全：预置常见可信段（127.0.0.1、10./8、172.16–31./12、192.168./16），开箱即用
- 应急熔断：当检测到高频异常请求时，自动临时收紧白名单范围，或切换至 JWT+IP 双因子验证
配合 JWT 实现双因子可信校验
单靠 IP 白名单存在局限——内网 IP 可能被横向渗透滥用。建议对高敏接口启用组合策略：
- 请求头同时携带有效 JWT（含用户身份、角色、有效期）和合法源 IP
- 服务端先验 IP 是否在白名单，再验 JWT 签名与权限 scope
- 例如：口罩检测接口要求 scope=“detect:internal” 且 client_ip 匹配 192.168.5.
这样即使 IP 被仿冒，无合法令牌也无法调用；即使令牌泄露，非白名单 IP 仍被拦截。
