经过一周的精心准备，我在上班的第一天就把草拟好的《服务提供商数据安全管理规范》发给了表哥，让他“按图索骥”。与此同时，本着职业敏感度和作为信息安全界的一个老兵，我觉得自己同样有责任在此分享给各位小伙伴，供大家批判式的借鉴，当然也免得大家去“重复地造轮子”。

首先需要和大家达成共识的是：众所周知，数据合作服务，一般是公司之间以签订合同的方式，将所拥有的数据信息委托或转交给专门进行数据加工、处理、转发、存储、维护等服务的提供商。显然，我们需要对提供商提供的服务进行安全性监督与评估，采取安全措施对访问实施控制，出现问题应遵照既定的管理规范，及时处理和报告，以确保其提供的服务符合本司的内部控制要求。

从小爱看武侠小说的我会经常在工作中总结一些“套路”，这次我就借用六脉神剑的噱头，画了上面这张关系图。而下面则是我用来具体跟大家分享和罗列的规范表格。细心的小伙伴可能已经发现，我特意将各个“要划的重点”的部分都用黑体显示了出来，以方便大家在实际使用和逐条参照的时候，能迅速地get到要点哦。

I. 安全管理总则

1. 提供商应有适当的安全策略和标准用以管理本司所流转过来的数据并确保整个过程遵守该信息安全管理规范。该策略和标准应由提供商以不长于一年的周期频率进行评审和更新。本司有权在本协议有效期的任何时候获得该策略的副本。

2. 提供商应允许本司或者一个互相认可的第三方对提供商的安全规程和该信息安全需求规范的践行情况，进行安全评估或审计。如果审计揭示出任何材料的缺陷，提供商应根据双方互认的修复计划，采取适当的纠正措施来解决缺陷问题。

3. 提供商应当维护各种安全事件响应流程的文档。对于任何可能对本司数据的机密性、完整性和可用性(CIA)，产生可识别的或是合理的不利影响的活动或事件，都应该在不超过24小时之内通知本司。

4. 当存储、处理或传送本司的数据时，提供商接受本司的管理或是来自监管机构对其业务行为的审计。

5. 在事先通知的条件下，提供商应当允许本司或者一个互相认可的第三方远程运行非侵入性的网络安全扫描器，以审查Web服务器的安全状况指标。提供商应根据双方互认的修复计划，采取适当的纠正措施来解决所查出的问题。

II. 人员安全

6. 提供商承诺培训所有访问本司数据的员工和分包商，其培训记录应供本司按需检查，而其操作流程与控制应遵从本协议。培训范围包括技能、安全意识、职业操守等方面。

7. 提供商在将其任何员工或分包商分配到本司并访问本司数据之前，都应进行背景调查，其调查记录应供本司按需检查。

8. 在未事先征得本司书面同意的情况下，提供商不得更换派遣员工或分包商，不得变更服务内容。

9. 提供商在对访问本司数据的员工和分包商进行访问授权时，应遵循职责分离、须知与最小权限的原则。

III. 物理安全

10. 提供商应当对保存有本司数据的所有物理区域予以限制访问、控制和监控，也包括其派遣人员利用本司数据提供服务，和处理或存储本司数据的设备所在区域。

11. 提供商应保留所有访问安全区域人员的授权和登录过程。该流程的最低要求包括(但不限于)：

· 访问安全区域，包括其身份、日期和时间的详细报告

· 定期测试物理安全的整体过程

· 必须有已授权公司的人员的伴随，否则限制外部服务人员进入安全区域

· 在安全区域的入口点，系统能够监控和登录警报，并提供视频监控。

· 维留至少六个月之内的有关安全领域的审计日志

IV. 系统安全

12. 提供商应维持其系统访问控制的机制，以防止对本司数据的未经授权访问，并仅限于被识别和分配的人员予以适当的访问。

13. 能够访问本司数据的提供商人员必须用一个单独的账号来进行访问验证。而该帐号应不同于企业给其分配的标准网络登录帐号。

14. 提供商应确保其用于访问本司数据的账号的密码复杂性符合如下要求：

· 不能使用缺省设置的密码。

· 长度大于 8个字符，且包括大写、小写、数字和特殊字符中的任何3个。

· 不能将密码写下来，也不能通过电子邮件相互传输。

· 如果密码泄漏，应及时通知我司，并必须立即更改。

· 如果需要特殊用户的口令(如administrator)，要禁止通过该用户进行交互式的登录。

15. 如果提供商需要远程访问本司的服务或数据，双因素认证的访问方式是必需的。

16. 如满足以下情况，提供商的人员对我司服务或数据的访问权限将在二十四小时内被吊销：需要访问的时间到期、员工合同到期、双方合作协议到期且未续约。

17. 提供商应该有对于不再有权访问本司数据的账号予以删除的书面流程。书面流程交由本司备案和管理。提供商应该定期(如每月)或按需向本司提供添加和删除具有访问本司数据权限的账号的报告详细说明。

18. 提供商应当实施审计跟踪以监控对本司数据的访问，并保留该审计日志至少六个月，且能按需提供。

19. 提供商应该在存储本司数据处部署应用代理或状态检测防火墙以保护服务器。

20. 提供商应确保其被防火墙所保护的且存储着本司数据的服务器，仅开放443服务端口。如果需要，也可开放80端口以将来自http的用户重定向到https并执行域级别的验证。

21. 提供商应该适当的配置基于主机或网络的入侵检测和预防系统，具有用于检测、抑制、评估事件响应流程，以及能够通知我司有关任何未经授权的黑客攻击。

22. 提供商应确保在其访问和存储我司数据的服务器和工作站上安装杀毒软件，并持续更新之。

23. 提供商应当在其系统环境之内，按照原厂商所推荐的周期和重要性，对所有工作站和服务器部署软硬件更新补丁。

24. 提供商应该在Web服务器上使用SSL、TLS或相关加密技术以验证服务器的真实性，并保护登录的身份验证过程。提供商应使用TLS或等价的加密方法，来安全保护Web服务器的往来通信。

25. 如果提供商提供的是基于Web服务器各种服务，其应当确保只有数字签名的ActiveX控件可供客户端的IE浏览器下载使用。

26. 如果提供商提供的服务是在一个web服务器上，提供商应确保只有数字签名的Java applet可被下载到客户机的IE浏览器。

V. 数据安全

27. 提供商应将本司数据存储在其物理上不同于Web服务器的后端数据库服务器之上。Web服务器与后端数据库服务器应该在不同的网段，并用只允许授权的数据流往来于Web服务器和后端数据库服务器之间的防火墙予以分离。

28. 提供商应该加密所有存储在其主/备系统及其他位置的本司数据。提供商也应对在局域网、广域网络和互联网上通过有线/无线方式进行传输的本司数据予以加密和必要的完整性校验。提供商不应将本司数据置于任何用于开发或测试的系统或位置。

29. 提供商应对加密措施中使用的加密算法应保证不可逆，而对安全密钥的产生、分发、变更、撤销、恢复、归档与销毁都具有适当的流程。

30. 如果提供商在其数字或电子的便携存储设备(如笔记本电脑、智能手机、CD、软盘、移动硬盘、磁带和其它类似设备)上存储着任何属于本司的个人隐私数据，提供商多应使用128位或更高的加密方式，并将采取其它手段或措施来保护这些数据不被未经授权所使用、丢失或披露。在提供商的服务终止时，这些数据应当立即从各个存储媒体上被删除。提供商应当具有和履行相关策略来禁止将本司的数据流转到非提供商所有的其他设备之上。

31. 无论是在物理上还是逻辑上，提供商都应将本司的数据与其他客户的数据进行隔离、存储和备份,以在协议约定的时候退还或销毁本司数据。

32. 提供商应确保有能力在其系统中分离出本司指定部分的数据，并能删除之，且能根据不同的使用场景(如，应对电子发现等)进行管理数据。

33. 提供商应能提供一个访问检索的方法，以从其服务器和存储空间里获取本司的数据，用以在本协议终止时创建本司的内部备份。而且所提供的数据应为非专有的格式，以便转移到本司系统或其他提供商手中。

34. 提供商应确保定期(不得少于每周一次)对所掌握的本司数据进行完整的备份和适当频率的增量或差异备份。其备份数据应与本司的生产数据不应存储在同一物理位置上。

35. 提供商应采用性能可靠、不宜损坏的介质，如磁带、光盘等对我司的数据信息予以备份。在备份的物理介质应该用清晰的标识注明数据的来源/路径、备份类型与日期、以及恢复步骤/参考文档等，并被保管在安全环境内。

VI. 灾难恢复

36. 提供商应该为本司的数据、所提供服务和既定的服务水平协议(SLAs)提供一定程度的冗余性，以确保其系统的业务连续性。这其中也包括替代性与冗余性的网络接入方法。

37. 提供商应该持续维护一个灾难恢复计划，以提供在长时间服务停歇的情况下所必要采取的各种行动。其方案计划中，还应涉及到各种连续行动所需的资源，以及在操作中断时所涉及的既定SLAs条款。同时提供商应将此计划在我司备案。

38. 提供商应当在每次(不得少于每12个月一次)修订灾难恢复计划后予以各种行业标准方法的测试。同时提供商应将最近一次的灾难恢复计划测试结果在我司备案，并包括有恢复实际所用时间与既定时间的比较。

读完全部的规范内容之后，表哥已经出现了“眉间放一尺宽”的神情。我对他多强调了一点：这样的规范可以是在与服务提供商签约之前，成为对其进行考量的标准，并要求其进行点对点的答复;也可以在合同期内对其真实情况做定期进行评估，并且在出现重大安全问题或隐患时予以重新考察，提出改进意见，甚至可以籍此终止合作服务。

总之，大家要记住：规范是死的，执行人是活的。数据安全从来不是“一锤子买卖”，也不是一个人的战斗。所以大家在借鉴和履行的时候要抱着“差之毫厘，谬之千里”的态度，多增加一些脑回路，以免出现“where have all the flowers gone”的尴尬哦。