核心思路是让每次读写可验证、可追溯、可拦截，异常参数越界即阻断；共享范围须绑定身份与场景，采用rbac+abac混合模型；敏感字段默认加密存储、按需解密并审计；禁止全局共享配置，各模块单独声明白名单；异常参数需覆盖全链路多层捕获；读写边界硬隔离；关键字段启用乐观锁，输出数据附加sm2签名与时间戳，日志记录参数指纹而非明文。

核心思路不是“堵住所有入口”，而是让每一次读写都可验证、可追溯、可拦截——异常参数一旦越界，系统立即识别并阻断，而非事后审计。

共享范围必须绑定身份与场景

不能只设“允许谁看”，还要明确“在什么操作下能看”。比如财务报表数据，对审计人员开放只读权限，但仅限于登录内网+UKey认证+时间窗口（工作日9:00–17:00）三重叠加时才生效。脱离任一条件，API返回空值或伪造的脱敏占位符，而非报错，避免暴露接口逻辑。

• 用RBAC+ABAC混合模型：角色决定基础权限，属性（IP、设备指纹、请求上下文）动态调整访问粒度
• 敏感字段（如身份证号、银行卡号）默认加密存储，调用时按需解密，且解密行为强制记录到独立审计链
• 禁止“全局共享配置”：每个业务模块必须单独声明其数据共享白名单，未声明即默认拒绝

异常参数需多层捕获，不止于输入校验

参数篡改常发生在传输中或中间件劫持，单靠前端/接口层校验远远不够。要覆盖“传入→解析→组装→落库→响应”全链路。

• 请求层：校验签名（如HMAC-SHA256），密钥由服务端动态下发，时效≤5分钟
• 业务层：对关键参数（如金额、状态码、用户ID）做二次一致性校验，例如订单创建时比对session中的UID与body中提交的UID是否一致
• 存储层：写入前计算整行数据哈希（SM3），存入扩展字段；读取后重新计算并比对，不一致则触发告警并拒绝返回

读写边界必须硬隔离，不可绕过

读操作和写操作不能共用同一套连接池或缓存策略。尤其要防止“读接口被恶意构造为写行为”，例如通过JSONP回调注入、SQL注释绕过等手段。

• 数据库连接池物理分离：读库只配SELECT权限，写库禁用SELECT FOR UPDATE以外的所有查询类语句
• 缓存层加读写标记：Redis Key命名强制带_r（read）或_w（write）后缀，代理层拦截非法跨标访问
• ORM框架禁用原生SQL拼接，所有参数必须走预编译占位符；动态表名/字段名需经白名单字典校验

杜绝篡改的关键是让篡改“无意义”

与其花大力气防住每一次修改，不如让篡改后的数据天然失效。这需要设计上就放弃“信任输入”，转向“验证结果”。

• 关键业务字段（如余额、积分）启用乐观锁：更新时必须携带version字段，版本不匹配直接失败
• 所有对外输出的结构化数据，附加数字签名（SM2）和时间戳，接收方验签失败即丢弃
• 日志不记录原始参数，而记录参数指纹（如SHA-256摘要）+操作人+设备指纹+网络路径，确保日志本身不可伪造