上个月公司迎来了一次突发的合规检查，说实话，刚开始大家都挺紧张的。我们做的是企业数据管理平台，客户多是金融和医疗行业的，合规这块儿马虎不得。这次检查不是走形式，而是实打实地翻文档、查流程、看系统日志。
问题出在权限设置上
检查组第一个问题就点到了我们一个子系统的权限配置。这个系统原本是给内部运营用的，后来业务扩展，部分功能开放给了合作方。但我们没及时调整权限模型，导致某些合作方账号能访问到本不该看到的操作日志。
这个问题其实早有苗头。三个月前运维同事就在群里提过“某个接口调用量异常”，但当时以为是爬虫，没深挖。现在回头看，就是权限粒度太粗导致的越权访问。
补救措施马上跟上
发现问题后，技术团队当天晚上就拉了会。我们重新梳理了RBAC模型，把角色从原来的5个细化到12个，并加上了数据级别的访问控制。比如财务类操作日志，只允许审计角色和特定管理员查看。
代码层面也做了调整，核心是加强中间件的拦截逻辑：
if (!user.hasPermission(resource, action)) {
log.warn("用户 " + userId + " 尝试越权访问 " + resource);
throw new AccessDeniedException("权限不足");
}文档也不能落下
检查组很看重有没有成文的合规流程。我们平时开发节奏快，很多操作靠口头约定，这次吃了亏。比如数据导出审批，之前是微信上打个招呼就办了，现在必须走OA流程，留痕可查。
我们连夜补了三份文档：《数据访问审批规范》《第三方接入安全要求》《日志留存与审计机制》。虽然有点亡羊补牢的意思，但检查组对响应速度还是认可的。
日常习惯得改一改
事后复盘，最大的收获不是通过了检查，而是意识到合规不是“应付检查”那几天的事。现在我们每周五下午固定做一次配置巡检，自动化脚本跑一遍权限、日志、加密状态，有问题直接钉钉告警。
还有个小变化：以前开发完功能，测试通过就上线。现在多了一个环节——合规自检表，十几条勾选项，包括“是否记录操作日志”“敏感字段是否脱敏”等等，产品经理不签字，运维就不给发布。
说实话，这些事做起来有点麻烦，但想想万一数据泄露，代价更大。现在客户来参观，看到我们这一套流程，反而更放心了。