上一章我们讲的技术团队，是属于代码与数据库层面的。
另外一个层面，是运营团队的。比如说在币所里面，能够进 Admin 的会是客服与风控部门。
Admin 后台里面可以调阅的信息很多。
包括钱包数量、币种、交易记录、对话记录、KYC 纪录、过去 IP 登入记录、风控等级等等等等。
这里有几个思路可以去设计：
- 合理存取范围
- 合理存取量
- 读 与 写的合理范围
- 谁存取过什么信息
- 信息该如何保管
因为后台能够看到很多东西。所谓合理存取范围，应该是一个客服能够看到什么？
比如说客服就不应该可以看到「所有的客户列表」。
而是只能查询「单一用户」
而客服通常是帮忙处理交易纠纷。所以能够看的应该是交易记录，对话记录，KYC 纪录。
其馀操作不允许
客户进线量，每天是有固定的。比如说一个客服一天顶多处理一百个客户。如果一个客服调阅 100 笔+的资料，这件事可能就是有问题的。
不是当天生意火爆，就是在下载资料。应该档掉。
正常情况下，在公共网段能够存取的应该只有「读」服务，也就是只能读，不能写。所以客服不能有「改资料」的行为。
改资料一律得进技术部审批，由程序员操作。
另外这些操作必须有迹可寻，也就是如果放款拨款，不能是加馀额，而是从某某帐号划拨放款到某某帐号。而这些划拨记录都会是有 Log 的。
同理，谁读过什么资料，谁做过什么动作，后台应该要有纪录。这是 by design 的设计，后台每个操作，在设计与 code review 时，就必须要加上 Log Trigger。
这样在事件发生时，可以即时定位还原到发生了什么状况。
站上有很多用户 KYC 的资料。这些 KYC 的信息
- 得打上浮水印，并销毁原档
- 独立加密服务器管理
- 站上存取需要批准放行，并不可随意调阅
最后，你还得防一个不太可能出现的情况是：
高权限的帐号被入侵。风控主任、CTO、CEO 理当会拥有最大的权限。
但如果它们的帐号也被冒充呢？
所以关键操作，必须要有双人确认放行。确保单个帐号就能产生极大的破坏。
这里总结一下你现在可以主动做的事：
- 你公司的业务最小可行管理范围是什么？可以设计出最小可行可读角色吗？
- 有没有对于整套权限的分层管理架构？
- 后台任何操作动作，都需要上 Log
- 安全设计是否有进 code review 过程？
- 敏感资料需要双人确认存取。