第八、九章：技术及运营团队如何设计安全结构

第八章：技术团队如何设计安全结构
技术团队的人，其实是互联网公司里面最脆弱的一环。

因为技术代码或数据库要是蒙受灾难，将会给公司带来重创。

然而，成员会离职，团队成员会变心，新成员会犯低级错误，技术团队掌握的信息会被窃取，。

如何设计一个相对安全的技术团队组织架构，其实是捍卫公司资产最重要的工作。

代码与密码分离

我们在前面几章提过。团队里面犯的低级错误，就是将数据库与第三方的密码，直接 hard code 写在代码库里面，还进了「版本控制」。

所以首先要做的是：
检查代码里面有没有含任何密码，将代码与密码分离，并且将相关 history 清掉。

1. 不同环境的代码使用不同环境的密码。

密码使用集中工具管理

一个互联网团队，一定会使用非常多第三方服务的密码。

这些服务的原始密码可能存在团队成员里面的微信，对话记录等等等。

离职难以清理以及更换。

比较好的方式

1. 是强制技术团队回收，统一使用 1Password 企业版管理。根据不同存取的权限，开放不同服务的密码。有团队成员离职直接 reset 一遍。

2. 严令禁止团队成员使用任何形式的 im 传递，以及写在公司 wiki 之上。

存取公司使用的服务一律启用团队成员 2FA

我较常听到的案例，往往不是企业本身的架构被打进去。而是企业成员使用的第三方服务，因为没有保护，所以被入侵。

包括 Slack、Github、Trello、Jenkins、Gmail 等等。

所以如果你有这些协作工具，记得一开始预设就要开启全员的 2FA。

自动化部署

虽然 2019 年了，但是很多团队还是属于手工部署（FTP / git pull ）。这其实是很危险的事。

因为上传或透过人直接连到机器操作是很危险的事。

现在都有很多自动化部署工具，只要一个指令就能自动部署。

另外关于自动部署这件事，要做到：

• 代码能够自动化部署，重起服务

• 作业系统配置与部署也可以自动化

而且甚至部署这件事，不是程序员可以直接部署，而是架构师级别以上才能部署，或者是有专属的 Release Manager 负责部署。

部署本身有自动部署系统，能够纪录是谁部署，还可以做权限风控系统。

企业资产保管

交易所类似公司钱包这一类服务。要动用资产必须多重签名与管控。

也可以使用企业钱包签核。在冷热钱包当中加一道温钱包。

温钱包的作用有几：

1. 降低直接操作冷钱包的机会。

2. 快速调度资金

3. 可用风控系统管理。

并且关于金额的变动，系统必须自动稽核。

且所以款项放行每一笔必须要有 Log。而且电话确认。避免公司里面有 middle man 攻击。

离职一键注销

企业最怕的是成员离职将公司重要机密带走。离职当日，一律直接扣留笔电，失效所有帐号与存取权限。

另外入职前必须请律师拟好就业合同，保密合同，离职合同。请他们签署。利用法律先行约束行为。

离职员工多半是 70% 以上多半是不满意现状而离开的。你不能假设这些同事不作恶。

所以得先小人后君子。

成立风控部门与有常驻法律顾问

这本书里面我讲的绝大多数内容，到后期都需要人专职去负责。

首先，我在这里再度重复「风控」的定义。风控包含：风险管理与风险控制。

• 风险管理，它是指如何在项目或者企业在一定的风险的环境里，把风险减至最低的管理过程。它的基本程序包括风险识别、风险估测、风险评价、风险控制和风险管理效果评价等环节。

• 风险控制是指风险管理者采取各种措施和方法,消灭或减少风险事件发生的各种可能性,或者减少风险事件发生时造成的损失。

如果你的企业很值钱，没有风控部门绝对会给你带来很大的损失。

第二，如果你的企业非常值钱，你还得再做一件事。

聘请厉害的法律顾问，还有企业里面聘请企业法务（需有律师执照）。

这是为什么呢？当你在初创企业时，你会假设人性本善。但是随著你的事业越做越大，处理的事情越来越复杂。

你会发现，所有经手的事，真的得先小人后君子。甚至你得预设，不能相信外部任何人。

否则公司随便遇到一个碰瓷事件，就会闹得很严重。而这些闹事者的心态就是，我闹你的成本很小。但你的损失成本会很大。

所以一定得从结构上设计成，让这些恶意闹事的人，作恶也需要很大成本还有很大代价。

宁愿你不要用到这些事后处理措施，也得从源头直接控制防御。

而这些法律文件与架构，都需要专业的律师访问企业以及针对实际情形撰写设计调整。

而便宜的律师，专业的律师，光是出文件的速度与准度就有天差地别。

可以的话，更是强烈建议有一个 inhouse 的律师在公司里面协助，可以协助企业冷静的做出正确的决策。

总结：

这里总结一下你现在可以主动做的事：

1. 你们的部署架构能自动化吗？

2. 你们的密码是如何管理的？

3. 你们的权限分层管理有系统吗？

4. 你们公司技术同事上岗与离职的程序是如何的？有从业上的合约设计吗？

5. 你们公司有法律顾问吗？你是出于省钱还是设计架构聘需要聘用律师？

第九章：运营团队如何设计安全结构

上一章我们讲的技术团队，是属于代码与数据库层面的。

另外一个层面，是运营团队的。比如说在币所里面，能够进 Admin 的会是客服与风控部门。

Admin 后台里面可以调阅的信息很多。

包括钱包数量、币种、交易记录、对话记录、KYC 纪录、过去 IP 登入记录、风控等级等等等等。

这里有几个思路可以去设计：

• 合理存取范围

• 合理存取量

• 读 与 写的合理范围

• 谁存取过什么信息

• 信息该如何保管

合理存取范围

因为后台能够看到很多东西。所谓合理存取范围，应该是一个客服能够看到什么？

比如说客服就不应该可以看到「所有的客户列表」。

而是只能查询「单一用户」

而客服通常是帮忙处理交易纠纷。所以能够看的应该是交易记录，对话记录，KYC 纪录。

其馀操作不允许

合理存取量

客户进线量，每天是有固定的。比如说一个客服一天顶多处理一百个客户。如果一个客服调阅 100 笔+的资料，这件事可能就是有问题的。

不是当天生意火爆，就是在下载资料。应该档掉。

读与写的合理范围

正常情况下，在公共网段能够存取的应该只有「读」服务，也就是只能读，不能写。所以客服不能有「改资料」的行为。

改资料一律得进技术部审批，由程序员操作。

另外这些操作必须有迹可寻，也就是如果放款拨款，不能是加馀额，而是从某某帐号划拨放款到某某帐号。而这些划拨记录都会是有 Log 的。

谁存取过什么信息

同理，谁读过什么资料，谁做过什么动作，后台应该要有纪录。这是 by design 的设计，后台每个操作，在设计与 code review 时，就必须要加上 Log Trigger。

这样在事件发生时，可以即时定位还原到发生了什么状况。

信息该如何保管

站上有很多用户 KYC 的资料。这些 KYC 的信息

1. 得打上浮水印，并销毁原档

2. 独立加密服务器管理

3. 站上存取需要批准放行，并不可随意调阅

避免单点失灵

最后，你还得防一个不太可能出现的情况是：

高权限的帐号被入侵。风控主任、CTO、CEO 理当会拥有最大的权限。

但如果它们的帐号也被冒充呢？

所以关键操作，必须要有双人确认放行。确保单个帐号就能产生极大的破坏。

总结：

这里总结一下你现在可以主动做的事：

1. 你公司的业务最小可行管理范围是什么？可以设计出最小可行可读角色吗？

2. 有没有对于整套权限的分层管理架构？

3. 后台任何操作动作，都需要上 Log

4. 安全设计是否有进 code review 过程？

5. 敏感资料需要双人确认存取。