第八章:技术团队如何设计安全结构
技术团队的人,其实是互联网公司里面最脆弱的一环。
因为技术代码或数据库要是蒙受灾难,将会给公司带来重创。
然而,成员会离职,团队成员会变心,新成员会犯低级错误,技术团队掌握的信息会被窃取,。
如何设计一个相对安全的技术团队组织架构,其实是捍卫公司资产最重要的工作。
我们在前面几章提过。团队里面犯的低级错误,就是将数据库与第三方的密码,直接 hard code 写在代码库里面,还进了「版本控制」。
所以首先要做的是:
检查代码里面有没有含任何密码,将代码与密码分离,并且将相关 history 清掉。
不同环境的代码使用不同环境的密码。
一个互联网团队,一定会使用非常多第三方服务的密码。
这些服务的原始密码可能存在团队成员里面的微信,对话记录等等等。
离职难以清理以及更换。
比较好的方式
是强制技术团队回收,统一使用 1Password 企业版管理。根据不同存取的权限,开放不同服务的密码。有团队成员离职直接 reset 一遍。
严令禁止团队成员使用任何形式的 im 传递,以及写在公司 wiki 之上。
我较常听到的案例,往往不是企业本身的架构被打进去。而是企业成员使用的第三方服务,因为没有保护,所以被入侵。
包括 Slack、Github、Trello、Jenkins、Gmail 等等。
所以如果你有这些协作工具,记得一开始预设就要开启全员的 2FA。
虽然 2019 年了,但是很多团队还是属于手工部署(FTP / git pull )。这其实是很危险的事。
因为上传或透过人直接连到机器操作是很危险的事。
现在都有很多自动化部署工具,只要一个指令就能自动部署。
另外关于自动部署这件事,要做到:
代码能够自动化部署,重起服务
作业系统配置与部署也可以自动化
而且甚至部署这件事,不是程序员可以直接部署,而是架构师级别以上才能部署,或者是有专属的 Release Manager 负责部署。
部署本身有自动部署系统,能够纪录是谁部署,还可以做权限风控系统。
交易所类似公司钱包这一类服务。要动用资产必须多重签名与管控。
也可以使用企业钱包签核。在冷热钱包当中加一道温钱包。
温钱包的作用有几:
降低直接操作冷钱包的机会。
快速调度资金
可用风控系统管理。
并且关于金额的变动,系统必须自动稽核。
且所以款项放行每一笔必须要有 Log。而且电话确认。避免公司里面有 middle man 攻击。
企业最怕的是成员离职将公司重要机密带走。离职当日,一律直接扣留笔电,失效所有帐号与存取权限。
另外入职前必须请律师拟好就业合同,保密合同,离职合同。请他们签署。利用法律先行约束行为。
离职员工多半是 70% 以上多半是不满意现状而离开的。你不能假设这些同事不作恶。
所以得先小人后君子。
这本书里面我讲的绝大多数内容,到后期都需要人专职去负责。
首先,我在这里再度重复「风控」的定义。风控包含:风险管理与风险控制。
风险管理,它是指如何在项目或者企业在一定的风险的环境里,把风险减至最低的管理过程。它的基本程序包括风险识别、风险估测、风险评价、风险控制和风险管理效果评价等环节。
风险控制是指风险管理者采取各种措施和方法,消灭或减少风险事件发生的各种可能性,或者减少风险事件发生时造成的损失。
如果你的企业很值钱,没有风控部门绝对会给你带来很大的损失。
第二,如果你的企业非常值钱,你还得再做一件事。
聘请厉害的法律顾问,还有企业里面聘请企业法务(需有律师执照)。
这是为什么呢?当你在初创企业时,你会假设人性本善。但是随著你的事业越做越大,处理的事情越来越复杂。
你会发现,所有经手的事,真的得先小人后君子。甚至你得预设,不能相信外部任何人。
否则公司随便遇到一个碰瓷事件,就会闹得很严重。而这些闹事者的心态就是,我闹你的成本很小。但你的损失成本会很大。
所以一定得从结构上设计成,让这些恶意闹事的人,作恶也需要很大成本还有很大代价。
宁愿你不要用到这些事后处理措施,也得从源头直接控制防御。
而这些法律文件与架构,都需要专业的律师访问企业以及针对实际情形撰写设计调整。
而便宜的律师,专业的律师,光是出文件的速度与准度就有天差地别。
可以的话,更是强烈建议有一个 inhouse 的律师在公司里面协助,可以协助企业冷静的做出正确的决策。
这里总结一下你现在可以主动做的事:
你们的部署架构能自动化吗?
你们的密码是如何管理的?
你们的权限分层管理有系统吗?
你们公司技术同事上岗与离职的程序是如何的?有从业上的合约设计吗?
你们公司有法律顾问吗?你是出于省钱还是设计架构聘需要聘用律师?
第九章:运营团队如何设计安全结构
上一章我们讲的技术团队,是属于代码与数据库层面的。
另外一个层面,是运营团队的。比如说在币所里面,能够进 Admin 的会是客服与风控部门。
Admin 后台里面可以调阅的信息很多。
包括钱包数量、币种、交易记录、对话记录、KYC 纪录、过去 IP 登入记录、风控等级等等等等。
这里有几个思路可以去设计:
合理存取范围
合理存取量
读 与 写的合理范围
谁存取过什么信息
信息该如何保管
因为后台能够看到很多东西。所谓合理存取范围,应该是一个客服能够看到什么?
比如说客服就不应该可以看到「所有的客户列表」。
而是只能查询「单一用户」
而客服通常是帮忙处理交易纠纷。所以能够看的应该是交易记录,对话记录,KYC 纪录。
其馀操作不允许
客户进线量,每天是有固定的。比如说一个客服一天顶多处理一百个客户。如果一个客服调阅 100 笔+的资料,这件事可能就是有问题的。
不是当天生意火爆,就是在下载资料。应该档掉。
正常情况下,在公共网段能够存取的应该只有「读」服务,也就是只能读,不能写。所以客服不能有「改资料」的行为。
改资料一律得进技术部审批,由程序员操作。
另外这些操作必须有迹可寻,也就是如果放款拨款,不能是加馀额,而是从某某帐号划拨放款到某某帐号。而这些划拨记录都会是有 Log 的。
同理,谁读过什么资料,谁做过什么动作,后台应该要有纪录。这是 by design 的设计,后台每个操作,在设计与 code review 时,就必须要加上 Log Trigger。
这样在事件发生时,可以即时定位还原到发生了什么状况。
站上有很多用户 KYC 的资料。这些 KYC 的信息
得打上浮水印,并销毁原档
独立加密服务器管理
站上存取需要批准放行,并不可随意调阅
最后,你还得防一个不太可能出现的情况是:
高权限的帐号被入侵。风控主任、CTO、CEO 理当会拥有最大的权限。
但如果它们的帐号也被冒充呢?
所以关键操作,必须要有双人确认放行。确保单个帐号就能产生极大的破坏。
这里总结一下你现在可以主动做的事:
你公司的业务最小可行管理范围是什么?可以设计出最小可行可读角色吗?
有没有对于整套权限的分层管理架构?
后台任何操作动作,都需要上 Log
安全设计是否有进 code review 过程?
敏感资料需要双人确认存取。