当前内部工具平台已有200+工具，承载着研发、测试、客服、运营不同角色人员的日常工作需求。对于平台的内容安全，不容忽视。
1、做好权限控制
权限最小化原则，保障在用户需求范围内授予工具权限
单一的工具是最小的不可拆分的单元，虽然可以直接给人员配置需要的工具权限，但这种过于灵活意味着管理成本巨大。因此将不同业务、不同类型的工具打包为一个“工具包”，配置一个与之对应的子权限。再根据不同同学的需求，直接授予子权限，或组合多个子权限配置一个新的权限。
另外，在用户申请权限的时候，根据用户所在组织或上级，动态展示不同的可申请权限，避免申请非相关权限。
权限回收机制
- 转离岗人员及时回收；
- 设置有效期，到期前通知用户，用户不处理则认为不再需要工具权限。对于敏感程度高的权限，可以设置较短的有效期；低敏感工具，如线下测试工具，可以设置较长的有效期；
2、做好操作审计
- 全量请求记录：工具网关在接口入口处记录接口请求内容、操作人、时间等信息（我这边采用的MongoDB），全量请求记录存储半年以上；
- 高敏高危工具：像给用户退款、赠送等工具，需要持久记录，客服时常会有查询谁操作了xxx工具的需求；这个功能是在网关转发逻辑处实现的，只需要在页面配置上勾选一下即可（后面有时间再写一篇如何实现工具平台灵活配置的）；
3、做好接口安全
工具网关
- 接口的权限校验：不能只对页面进行权限控制，工具页面对应的接口也需要有权限控制；
- 隐藏下游实际请求：防止F12抓包查看到请求的实际接口；
- 向下游请求加标记：工具网关发起的下游请求，自动在header中添加了特殊标记，含操作用户、操作时间、用户权限、sign，以及用于反查动态key的请求id（每一个请求都会生成一个随机的动态key用于生成sign）；
- 测试工具校验白名单账号：白名单服务详见：juejin.cn/post/742765…
工具服务
对于无法直接请求业务服务的操作，使用工具服务来封装逻辑，对外网关暴露接口
- 校验请求来源为工具网关服务；
- 校验网关sign；
- 测试工具接口校验白名单；
- 接口根据配置校验用户权限；
