【51CTO.com原創稿件】去年中，大表哥為了圖便宜，給自己的初創公司找了個一站式的大數據存儲與分析類型的云服務提供商。而且由于巨大折扣的誘惑，他在未驗證對方資質和過往案例真實性的情況下，草簽了三年期的數據合作協議。事與愿違，還沒提供服務幾個月，該公司就因“老板跑路”的原因突然關張，接口人也隨即失聯。令人扼腕的非但是一直被放置在該云平臺的那些業務數據已無法取回和繼續使用，更頭疼的是在行業圈子里已陸續出現了號稱來自表哥公司的一些“假作真時真亦假”的被泄露的信息與數據。我們一家人過年聚會時，他提及此事，大家無不慨嘆現在商業合作的小船說翻就翻，動輒就跟你來個“皮皮蝦，我們走”這樣式的斷舍離，更別提什么“三生三世”那樣的愉快玩耍了。為了東山再起且避免前車之鑒，我自告奮勇地準備幫他擬定一份通用的數據合作服務提供商的安全管理規范，以自身保護和對未來新的服務商形成約束。

經過一周的精心準備，我在上班的第一天就把草擬好的《服務提供商數據安全管理規范》發給了表哥，讓他“按圖索驥”。與此同時，本著職業敏感度和作為信息安全界的一個老兵，我覺得自己同樣有責任在此分享給各位小伙伴，供大家批判式的借鑒，當然也免得大家去“重復地造輪子”。

首先需要和大家達成共識的是：眾所周知，數據合作服務，一般是公司之間以簽訂合同的方式，將所擁有的數據信息委托或轉交給專門進行數據加工、處理、轉發、存儲、維護等服務的提供商。顯然，我們需要對提供商提供的服務進行安全性監督與評估，采取安全措施對訪問實施控制，出現問題應遵照既定的管理規范，及時處理和報告，以確保其提供的服務符合本司的內部控制要求。

從小愛看武俠小說的我會經常在工作中總結一些“套路”，這次我就借用六脈神劍的噱頭，畫了上面這張關系圖。而下面則是我用來具體跟大家分享和羅列的規范表格。細心的小伙伴可能已經發現，我特意將各個“要劃的重點”的部分都用黑體顯示了出來，以方便大家在實際使用和逐條參照的時候，能迅速地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”的尷尬哦。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】