【场景面试题】六、API、身份、权限与安全治理（51～60）

文章目录六、API、身份、权限与安全治理516051. 如何设计一个高可用 API 网关既能统一鉴权、限流又不成为瓶颈具体示例52. 登录态和 Token 系统怎么设计才能兼顾安全、性能和多端登录具体示例53. RBAC 和 ABAC 权限模型怎么选如何做到对象级权限不漏判具体示例54. 多租户 SaaS 系统如何设计数据隔离、配额和故障隔离具体示例55. 如何设计不可篡改的审计日志系统具体示例56. 敏感数据如何加密、脱敏和最小化暴露具体示例57. 注册和登录防刷系统怎么设计具体示例58. 内容审核系统如何设计支持文本、图片、视频的实时和异步审核具体示例59. 开放平台回调和 Webhook 怎么设计保证安全、可重试、可追踪具体示例60. API 版本升级如何做到兼容旧客户端具体示例六、API、身份、权限与安全治理516051. 如何设计一个高可用 API 网关既能统一鉴权、限流又不成为瓶颈场景与难点。API 网关处在所有流量入口既要做路由、鉴权、签名校验、限流、灰度和观测又不能把业务逻辑塞太多导致入口变重。先问清楚是内部微服务网关、开放平台网关还是移动端 BFF峰值 QPS、租户数量、认证方式、是否跨机房都不同。方案。网关本身保持无状态多副本部署配置从控制面下发到本地缓存请求路径只做轻量判断复杂风控和业务规则下沉到后端服务。路由表、限流规则、证书和灰度规则都要版本化发布时先灰度网关实例。限流分全局、租户、用户、接口和下游资源几层避免一个大客户打满共享资源。ClientAPI GatewayAuth/SignatureRate Limit/QuotaRoute CanaryService AService BControl PlaneMetrics/Trace/Access Log具体示例具体设定。开放平台有 2 万个开发者峰值 20 万 QPS每个 app_id 有独立 QPS 配额部分新接口只给 5% 开发者灰度。落地例子。网关校验app_id timestamp nonce signature通过后查本地规则缓存quota:app_id:api做令牌桶路由规则api/v2/order/query - order.service.v2。控制面发布新规则时生成gateway_config_version20260712_01网关拉取成功后再切换版本。面试可讲。网关要轻控制面要强。请求路径不能依赖远程配置查询网关故障时要能使用最后一个正确版本继续服务同时保留一键回滚。52. 登录态和 Token 系统怎么设计才能兼顾安全、性能和多端登录场景与难点。登录系统看起来只是发 token实际要处理多端登录、踢下线、刷新、盗用、设备风控和权限变更。要先明确 token 是纯自包含 JWT还是服务端 session是否要求立即失效移动端、Web、开放 API 的生命周期也不同。方案。常见做法是短期 access token 长期 refresh token。access token 用于高频鉴权过期时间短refresh token 服务端保存哈希和设备信息支持吊销。权限强变更、改密、注销账号时更新session_version请求鉴权时校验 token 中版本是否过期。高风险操作要求二次验证。具体示例具体设定。用户在手机、Web、平板同时登录改密码后希望所有旧设备 1 分钟内失效。落地例子。access token 有效期 15 分钟refresh token 有效期 30 天用户表有session_version8。改密后把版本增到 9同时把用户活跃 refresh token 标记 revoked。网关本地缓存用户版本 30 秒旧 access token 最多在缓存窗口内有效。面试可讲。JWT 不是天然可吊销服务端 session 也不是天然高性能。面试要说清“是否需要立即失效”再决定短 token、版本号、黑名单和缓存窗口。53. RBAC 和 ABAC 权限模型怎么选如何做到对象级权限不漏判场景与难点。后台系统常用 RBAC但内容、订单、商家、项目空间这些资源经常需要对象级权限例如“只能看自己店铺的订单”。如果只在菜单层做权限接口和数据层很容易漏。方案。粗粒度用 RBAC 管功能点角色、权限点、用户角色关系细粒度用 ABAC/数据权限表达资源范围例如tenant_id、shop_id、owner_id、region。权限判断要在服务端统一中间件或查询构造器里完成不能依赖前端隐藏按钮。关键接口记录鉴权决策日志便于审计。具体示例具体设定。运营 A 只能看华东大区订单商家 B 只能看自己店铺订单超级管理员能看全量。落地例子。RBAC 判断 A 是否有order.read权限ABAC 再生成数据范围region in (east)。商家请求则追加shop_id in user_authorized_shops。订单查询最终条件必须包含数据范围不允许裸查select * from order where status...。面试可讲。RBAC 解决“能不能做某类动作”ABAC 解决“能对哪些对象做”。真正危险的是只做菜单权限不做接口和数据过滤。54. 多租户 SaaS 系统如何设计数据隔离、配额和故障隔离场景与难点。多租户不是表里加个tenant_id就结束。还要考虑大租户拖垮小租户、数据误串、配置隔离、定制化、账单和合规导出。先问租户规模是否差异巨大是否有金融/政企等强隔离要求。方案。小租户可以共享库表并强制所有表带tenant_id大租户或高合规租户独立库、独立缓存命名空间甚至独立集群。所有入口都要解析租户上下文查询构造器自动注入tenant_id。配额按租户维度限制 QPS、存储、任务并发和导出量监控和告警也按租户拆分。具体示例具体设定。1000 个商家共用营销平台其中 5 个头部商家贡献 60% 流量。落地例子。普通商家共享campaign_{shard}表主键包含tenant_id头部商家迁到独立逻辑槽和独立 Redis 前缀。批量导出任务按租户令牌桶限速避免头部商家一次导出拖慢全平台。比如一个策略平台按团队进行隔离团体内体量不大共用default DB库而数据量大的团队单独做环境隔离使用隔离的新建的DB库。面试可讲。多租户要同时讲数据隔离和资源隔离。只加tenant_id能防一部分误查但不能解决热点租户、配额和合规问题。55. 如何设计不可篡改的审计日志系统场景与难点。审计日志用于追责不能被业务方随意改但审计写入又不能拖慢主链路。需要明确记录哪些动作登录、权限变更、资金操作、配置发布、数据导出、人工审批等。方案。审计日志与业务库解耦主链路写本地 outbox 或异步事件审计服务消费后写 append-only 存储。日志包含 actor、action、resource、before/after、request_id、client_ip、trace_id 和签名摘要。为了防篡改可按批次计算 hash chain定期把批次摘要写到独立存储。具体示例具体设定。运营把某活动白名单从 1 万人改成 100 万人事后需要查是谁、什么时候、从什么值改成什么值。落地例子。配置服务提交时写audit_event(actionconfig.update, resourceactivity:123, before_hash, after_hash, operator, approval_id)。审计服务按分钟生成batch_hash hash(prev_batch_hash events_hash)写到只追加表和对象存储。对一些敏感数据如用户数据导出操作要做权限管理还需要做留痕即记录什么人在什么时候按什么查询条件导出了哪些数据面试可讲。审计日志要和业务写解耦但不能丢。核心是 append-only、独立权限、可检索、可校验而不是简单打一行应用日志。56. 敏感数据如何加密、脱敏和最小化暴露场景与难点。手机号、身份证、银行卡、地址等敏感数据既要能查、能展示又要防止数据库泄露、日志泄露和内部越权。先区分可逆加密、不可逆哈希、展示脱敏和检索需求。方案。存储层对敏感字段做 envelope encryption数据密钥加密字段主密钥托管在 KMS。需要等值查询的字段保存规范化哈希列例如phone_hash展示时只返回脱敏值。日志、埋点、错误栈统一做敏感字段过滤。内部工具按审批临时解密并全量审计。具体示例具体设定。客服要通过手机号后四位辅助定位用户但不能看到完整手机号。落地例子。表里保存phone_cipher和phone_hash查询手机号时先算 hash 点查客服页默认展示138****1234。只有通过工单审批的用户才能调用解密接口接口返回也带水印和审计记录。面试可讲。加密解决数据库泄露风险脱敏解决展示风险哈希解决查询问题。不要把完整敏感信息打进日志这是面试官很爱追的坑。57. 注册和登录防刷系统怎么设计场景与难点。注册登录是黑产入口攻击者会用代理 IP、设备农场、撞库和短信轰炸。系统要在安全和转化率之间取平衡不能简单把所有异常都拦掉。方案。风控链路分实时规则、模型评分和事后处置。实时特征包括 IP 段、设备指纹、账号年龄、失败次数、地理跳变、短信发送频率、行为轨迹。低风险放行中风险加验证码或二次验证高风险拒绝并进入黑名单。短信、邮件等成本通道必须有独立限额。具体示例具体设定。某 IP 段 1 分钟内注册 500 个账号并频繁请求短信验证码。落地例子。风控服务按ip_prefix device_id phone_hash做滑动窗口计数。超过阈值后注册接口返回验证码挑战短信服务对同手机号 1 分钟 1 次、1 小时 5 次限额。风控结果写事件流离线训练更新设备风险分。面试可讲。防刷不是一个验证码组件而是实时特征、分级处置、成本通道限额和离线反馈闭环。58. 内容审核系统如何设计支持文本、图片、视频的实时和异步审核场景与难点。内容审核要兼顾时效、准确率和误伤。评论可能要求秒级返回视频可以先上传后异步转码审核不同内容类型、地区和业务线策略不同。方案。主链路先做轻量规则和模型打分命中高危直接拦截低危放行中间态进入人工或异步复审。文本走敏感词、语义模型图片走 OCR、图像模型视频抽帧、音频 ASR、封面和标题一起审核。审核结果版本化内容展示前读权威审核状态。具体示例具体设定。用户发评论要求 200ms 内返回发视频允许几分钟后可见。落地例子。评论先过敏感词和小模型结果为PASS/BLOCK/REVIEW。视频上传完成后生成审核任务抽帧 1 fps、ASR 转文字、封面识别最终写media_audit(status, reason, version)。推荐和搜索只索引PASS内容。面试可讲。不同内容要不同审核路径。审核状态必须是展示前的权威条件不能只依赖搜索或推荐侧异步删除。59. 开放平台回调和 Webhook 怎么设计保证安全、可重试、可追踪场景与难点。Webhook 是把事件推给第三方第三方服务不稳定、网络不可控还可能有人伪造请求。需要保证至少一次送达、可验证来源、可查询投递记录。方案。事件生成后进入投递任务表和 MQ按开发者 app_id 隔离队列和并发。请求带签名、时间戳、nonce随机数加盐 和 event_id第三方返回 2xx 才算成功。失败按退避重试超过阈值暂停该订阅并告警。开发者控制台可查看事件、状态、响应码和下次重试时间。具体示例具体设定。商家订阅订单支付成功事件自己的回调服务偶尔 500。落地例子。事件order.paid生成event_idevt_123投递时签名HMAC(secret, timestamp body)。如果商家返回 500系统 1min、5min、30min、2h 退避重试商家修复后可在控制台手动重放指定事件。面试可讲。Webhook 天然至少一次第三方必须幂等。平台侧要讲签名、防重放、退避、死信、重放和可观测性。60. API 版本升级如何做到兼容旧客户端场景与难点。移动端和第三方客户端升级不可控服务端不能随意删字段、改语义或改变错误码。版本治理要覆盖 API、事件、配置和 SDK。方案。API 采用向后兼容原则新增字段可选旧字段保留弃用期枚举只能新增不能改变含义。重大语义变化走/v2或能力协商。服务端按客户端版本、灰度标识和 feature flag 返回兼容结构。接口契约用 IDL/OpenAPI 管理变更前做兼容性检查。具体示例具体设定。订单接口要把status3从“已完成”拆成“已签收”和“售后中”但老 App 只认识 3。落地例子。新接口增加sub_status老字段status3继续表示完成大类。新 App 展示细分状态老 App 仍按完成展示。等低版本占比低于阈值后再考虑迁移。面试可讲。兼容不是多保留一个字段而是保证旧客户端语义不变。要主动提契约测试、灰度和弃用周期。