当前企业运营环节采用外包形式已经越来越普遍了，外包形式能为企业降本增效，但在安全环节，外包往往会成为薄弱的一环。外包团队究竟会为企业带来哪些安全风险？我们又该如何应对外包所带来的问题？本期话题讨论我们以外包开发中的安全风险与应对解决方案为主，就相关问题展开了讨论。

大家认为，对于需要外包开发的项目，整套流程中可能会存在哪些安全风险？比如存在高危漏洞，或者是一些敏感信息泄露？具体应该如何避免？

A1：

我觉得主要是源码，有人会把源码传到自己的代码仓库。

A2：

其实就是代码泄露吧（人为带走或上传敏感代码至Github等平台），机器沦陷成为跳板。如何避免的话，开发工作在虚拟桌面种进行，内部建设Git平台，Github巡检监测，通过准入系统与网络设备设置访问控制策略，上审计，全流量威胁感知。

A3：

外包开发主要的风险在于安全漏洞和信息泄露风险。对于安全级别较高的企业（例如银行），会要求：

1.外包商进驻甲方场地，使用甲方的开发环境和基础设施，内部统一管理源代码；

2.对需求和架构进行安全评审；

3.使用自动化工具进行代码质量检查和代码审计，定期进行Code Review；

4.和外包商签订保密协议，在合同中明确SLA指标；

5.做好互联网源代码、敏感信息泄露等监测。

A4：

银行这一块，可以参考年初发的《中国银保监会办公厅关于印发银行保险机构信息科技外包风险监管办法的通知》。

A5：

风险方面我这说三点：

1.信息泄露和测试不完全做一个测试报告直接上线生产，导致生产事故；

2.开发人员完全不在意信息安全，没有相关意识，依赖甲方安全重度参与做风险控制；

3.甲方安全整个周期介入太晚，其实已经很难有所作为。

A6：

外包开发的项目，到处都是风险，因为项目质量、人员管控、信息扩散范围均不可控，处处皆风险。

外包风险不可控，如果不是成本考量，可能更愿意选择自研，相对而言人员外包比项目外包更可控。

A7：

我现在遇到的主要是外包开发水平太差，写的程序性能和稳定性不行，所以涉及到敏感信息的项目不会采用外包。安全风险的话，项目整体会单独一个区域放置，避免跟非外包项目有任何网络和权限上的交互，避免问题扩散。开发流程上很难控制外包，只能在部署层面上做一些要求和控制。相比较而言，能让外包如实的将代码（包括提交记录历史）提交到我方提供的代码库就很不容易了。

A8：

个人认为最需要关注的安全风险有是人员风险和数据(泄露)风险。人员风险来自于人员安全意识的稂莠不齐，没有良好的保密意识和工作习惯，以及随外包公司的多项目交叉开展带来数据泄露风险；数据泄露风险来自于人员风险延伸的人员异动(入、转、调、离)、代码不规范、功能逻辑理解偏差等。

避免上述风险的方法：与外包公司和外包人员签订严格的合约，约束项目人员的异动，加强需求沟通和代码评审，做好安全测试和上线检测流程。

Q：那具体而言，在选择外包服务商时可以从哪些方面进行审计来确保其安全基线？比如攻防演练期间如何控制外包风险？

A1：

驻场类：外包安全培训、签安全保密协议、权限管控、源代码检查、敏感信息泄露、终端口令安全、终端病毒防护等；

非驻场类：参考物理安全、网络安全、数据安全、应用安全、权限安全、终端安全和运维安全等。

A2：

除了合同约束，也要依照企业自身安全管理需求，对人员、操作、数据流转、组件(服务)资产、工作流程、文档、代码存储及备份、BYOD等进行审计。攻防演练期间无需特意控制外包风险，做好（上述）日常管理就好。

Q：外包是否已成为很多甲方企业做安全的惯性思维？如果外包过程中出了安全事件，权责该怎么划分？落实到合同中应该注意些什么？

A1：

安全外包用于一线监控的多，落实到合同中就是保密协议跟服务质量约束。

A2：

我们公司安全不让外包人员参与，供应商如果碰了我们的策略，老大给我们就要上课了。不过每年有攻防演练服务，供应商外部打一下，系统上线安全检查也是自己人测。

A3：

这个不好评判，不同的企业对外包的需求不同，谈不上惯性思维。更多的应该关注成本、专业程度以及业务适配性。

如果外包过程中除了安全事件，权责的划分应依照合同条款和具体情况进行判定：例如，触碰审计红线、沟通偏差导致的误操作等。

落实到合同条款中，应尽可能将权责进行明确和细化，避免出现模棱两可的描述。可参考云服务中的《责任共担模型》。

Q：在直接购买安全服务与搞安全外包中，影响企业选择的因素有哪些？

A1：

选择的因素很多，如：服务商的资质、口碑、企业擅长的产品及技术能力、售后、响应速度。

A2：

其实主要就是看时间、成本、效能、风险。

A3：

安全外包更多看跟现有业务的契合度吧，再就是性价比。

话题二：对于服务器密码管理。一般海量服务器是怎么做？密码记录在哪里？用户一般是普通权限。进系统自己切Root?怎么做定期更改密码？

A1：

服务器上收到堡垒机管理，扫描器、HIDS做登陆扫描挖掘弱密码。

A2：

堡垒机外还会存一份密码吗？

A3：

保险柜。堡垒机的密码加密后可以备份，需要特权账号恢复，极度重要特权账号可以使用保密打印机，打印后交由档案部门保险柜。

A4：

90天打印一次？密码要求90天改一次，不90天打印一次怎搞。

A5：

从来没有规定这么要求过，现在这种说法过时了。我以前做等保，也这样跟客户说，自从做了甲方才感觉这么要求真傻。

A6：

等保要求对口令定期更新，之后制度落实不就是XX天改一次么。

A7：

密码并不一定要定期更换，如果够保密、够复杂、不泄露，可以不修改。

A8：

堡垒机上有普通用户和Root的账号给用户自己选吗?关键是不允许Root登陆，用户要通过普通账号登陆。然后切换Root. 把Root密码给用户还是Sudo配置随便切？

A9：

堡垒机就是控制账号权限的，有什么需求一定要Root吗？实在需要就设置高危操作审核。

A10：

密码要全部符合要求也蛮烦的。90天改密码，不能历史密码，默认Root要禁用，账号要按角色分配，密码复杂度要用户无法记忆。

A11：

以前安全保护措施少，为了防止密码泄漏，最有成本的方式就是要求用户定期更改。

——————————————————

本期精彩观点到此结束啦~此外，FreeBuf会定期开展不同的精彩话题讨论，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！

加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！