ITValue注
姚凱：歐喜投資（中國）有限公司IT總監。在長期的企業信息化過程中，先后成功上線了Oracle OnDemand、Salesforce，Office 365，并實施了基于阿里云和AWS雙機熱備的系統。
本文是姚凱先生在ITValue【深V課堂】之中國好SaaS培訓課第一期上的分享，主要探討了企業在采用saas應用時會有哪些安全問題的擔憂？以及應對這些風險有哪些“秘笈”。
對于saas初創者來說，如何更好地配合企業降低風險，防患于未然，也是成功“撩”到大企業的重要一環。

精彩觀點：
1、對于SaaS而言，企業安全防衛的基本原則就是“defence in depth”，通俗來說就是各司其職、層層防御。

2、整個SaaS的設計，會涉及到數據安全、以及用戶和權限管理這兩個方面的問題。

3、所有面向企業的SaaS服務，都需要和企業內部的域用戶的帳號進行一個集成，所以對于SaaS廠商來說，軟件在開發過程中必須符合這樣一些域集成的標準。

4、企業對于它的所有數據負有最終的安全治理管理的責任，也是整個的監管的直接對象，因此如果繞開企業直接拿SaaS后臺的數據來用，可能會讓企業處于一個比較危險的處境。

在過去一個月中，我們聽到了不少安全事件，涉及到的都是一些比較大的公司，如雅虎確認的帳戶泄露，百度云的帳戶泄露，還有像上周的DDos攻擊導致美國東海岸的整個服務中斷等。

談及SaaS中的安全，有些SaaS供應商可能會講，SaaS服務在個人應用領域中已經有了很多年的歷史，沒有人特別地提出安全的問題。再說對于企業來說，采用一些外包的托管服務也算歷史悠久，也沒特別強調過安全，為什么在說到企業級SaaS應用的時候，很多企業都嚴陣以待，認為安全是一個關鍵因素呢？

今天要分享的，就是對于一個企業來說，在SaaS應用中會考慮到哪些安全問題？以及有哪些可能化解的策略。

SaaS應用的安全問題有哪些？

首先來看一下SaaS應用中的安全責任。



比較一下，如果一個企業采用SaaS模式，會和其之前采取的服務托管模式在責任上有什么區別？
首先，對于SaaS服務，整個軟件的所有者是SaaS供應商，而對于托管服務來說，軟件的所有者是企業，企業采購了軟件，把它部署到托管服務器上。
第二，一個SaaS軟件可能有很多企業共用，而對于托管服務來說，所托管的軟件是由這個企業單獨使用的。

第三點是關于軟件的變更。對于SaaS來說，SaaS軟件的升級、補丁都是由SaaS廠商來提供，而對于企業托管服務來說，整個變更、發起都是由企業發起，由企業決定是否去做相應的變更。

最后，對于軟件的維護，維護本身對于SaaS而言是由SaaS廠商來執行。而對于托管服務來說，托管方要根據企業明確的指令和要求來進行。

由此可以發現，對于一個企業，就軟件的整體環境管理來說，如果使用SaaS模式，則企業的管理能力是很弱的。企業可能只知道用的是某一個軟件，但并不知道這個軟件托管在哪一個數據中心，采用的哪個平臺。但對于托管服務來說，托管的軟件放在怎樣的一個環境，什么地方，它的備份等等一系列的問題，企業都了如指掌。也就是說，企業對SaaS軟件的控制力是比較弱的，而對于托管服務的控制力相對比較強。

其次就是我們目前有不同的云平臺模式，那對于云平臺模式而言，企業在整個的安全架構上的責任是如何界定的？



如上圖，隨著整個云平臺模式從Iaas、Paas向SaaS的遷移，企業的整體責任逐步地變成只負責數據安全和安全治理，而對于服務商來說，他們的責任從物理安全、基礎架構、延伸到平臺，那對于整個應用安全是由雙方共享的。但是，不管企業采用什么樣的模式，整個的安全治理或者說供應商怎樣才能達到企業的安全目標，這一點是企業的責任，對于整個托管在SaaS平臺上的數據，也是企業負最終責任。

當然在實際過程中，很多的SaaS平臺自己并不負責基礎架構，所以事實上，他會把他的平臺基礎架構又轉嫁到第三方的云平臺，如PaaS平臺或者是Iaas平臺上。這樣就會存在一個很大的差距。

一方面對于企業來說，他的整個安全責任及對于數據安全的最終責任并沒有減弱，但實際上其對使用的SaaS的安全性能和管控力卻在下降。那么企業勢必會出現一些焦慮，怎么去彌補這種焦慮呢？

目前常用的辦法就是SaaS廠商通過一定的安全認證來滿足客戶對于安全的要求。通過提供一個第三方的認證說明，證明其安全達到了一定的程度，是一個可信任的平臺，企業可以放心使用。



上圖是目前比較常用的一些安全認證方法，分別是TUV的認證，CSA的認證，還有歐盟的一些認證，在這些認證中，國內比較熟悉的可能就是最右邊的ISO27001認證。ISO27001是一個比較通用的認證，但是它有一些缺陷。ISO27001本身并不是針對第三方的獨立服務做的一個認證，對于風險管理、云數據安全、云接口安全、互操作性和可移植性等方面并沒有一些對應考核的標準，而且，27001更多是一次性的認證。

或者更準確的來說，27001是一個靜態的認證，它只是表明企業在提供云服務時，管理流程達到了一些認證的要求，但是在日常操作中是否嚴格遵循了這樣一些原則卻并沒有一個持續性的檢驗。而且，對于風險的評估，以及對于一個SaaS來說，它對于特定平臺的要求這部分都沒有進行適合的考量。可以說，ISO27001只是一個基礎。如果沒有27001，企業對于整個SaaS平臺的安全就沒有信心，但是有了27001并不表示企業整個的SaaS安全就是必然可信的，所以這里引入另外一個概念叫做SOC。

在此要強調一下SOC。這是一個叫“SSAE16”具體審核的報告格式要求。SSAE16是美國注冊會計師協會制定的叫鑒證業務準則公告第16號，是負責企業的信息安全的審計報告。
SOC具體有三種：SOC1是關于財務報表，SOC2和SOC3內容基本接近，都是關于第三方服務企業的安全策略、安全控制的文檔以及日常操作的一個審計報告。

SOC2和SOC3略有不同。相較而言，SOC3更像是一個通用的報告，隱含了涉及到的所有具體的客戶信息，它更多的是SaaS廠商安全能力的一個證據，又或者說是作為潛在的市場營銷的一個證明。那么SOC2里面會包含著針對特定客戶的信息，服務情況、問題、審計結果等，很少會提供給第三方。

需要指出的是，對于SOC來說，目前大部分審計公司至少四大審計公司都是可以提供的。

保證SaaS安全的兩大“護法”

隨著云的引入，企業安全邊界發生了很大變化，風險暴露也更多。在傳統企業里，一般以防火墻為邊界，防火墻以內是企業來管，防火墻以外是外部的供應商來負責。那么隨著SaaS還有移動化的引入，這個邊界越來越模糊，怎樣才能保證達到一定的安全等級？又能通過哪些途徑來實現？

通常來講，如果做完軟件之后發現有安全問題再來打補丁，會有一定的效果，但還遠遠不夠。最好的安全是未雨綢繆。對于SaaS而言，企業安全防衛的基本原則就是“defence in depth”，通俗來說就是各司其職、層層防御。之所以要各司其職，是因為對于客戶來說，SaaS供應商有一個數據保管的責任，另一方面對于他所使用的第三方服務來說，他也有一個保證服務品質的問題。

所以整個的SaaS設計，會涉及到數據安全、以及用戶和權限管理這兩個方面的問題。
對于數據來說，會存在三個狀態，第一個是保存的數據，也就是在服務器上保存的、通常是以數據庫的形式存儲的數據；第二個是傳輸中的數據；第三個是客戶端正在被使用的數據。

對于保存的數據來說，首先要明確的就是要對數據進行分類識別，敏感數據的識別可能是基于一些既定的規章。一些常見的行業規則，比如支付需要遵循的是PCIDSS的一些要求。對于一些醫療數據，國內沒有強制性的要求，但是國外，像美國就有HIPAA標準的要求。更多的是基于SaaS服務所涉及到的一些數據，尤其是一些敏感數據，比如HR數據，工資肯定是一個高度機密的信息，再比如客戶體檢信息，也是機密性的。那對于其它的信息如采購供應鏈，企業采購價格、供應商等都可能會是一些保密信息。

因此在整個的SaaS架構設計中，最基本的要求就是客戶數據的隔離，通常有三種做法。第一種是每個客戶會有一個獨立的數據庫，第二種是每個客戶有一個獨立的schema，第三種是每個客戶有一個獨立的ID，數據通過ID來進行區分。這三種架構各有優略，最多的還是通過客戶的ID形式來區分，這樣能保證整個云架構的彈性。在這種情況下，企業對于數據的一個要求就是加密，這就保證了每位客戶的數據是不可見的，尤其是一些機密的數據，更需要加密。

對于整個的這個加密結構來說，一種理想的做法就是在創建一個客戶時，賦予他一個唯一的密鑰，因此在整個的客戶數據保存時，都以這樣的一個密鑰來進行加密，客戶只有通過這樣一個密鑰，解密出來才能得到真實的數據。必要時，這個密鑰甚至對于SaaS的管理員都是不可見的，只能通過一個計算好的加密后的數據，來對數據庫中的數據進行維護，而不是直接對原始數據來進行維護。當然加密會不可避免地帶來一些效率的損失，因此只有對一些極其關鍵的數據才使用。

同樣的對于整個數據庫服務器來說，需要進行固化，包括對于訪問權限的維護，刪除不必要的帳戶，修改缺省帳戶的密碼，以及禁用一些特權帳戶，這包括關閉不必要的服務和端口，以及對于數據庫服務器的訪問只能通過特定的IP來訪問等方法，減少風險敞口。

其次是關于數據的傳輸，目前SaaS數據的傳輸大多都是在公網進行，是不可控的，因此通過加密的途徑來數據傳輸是一個基本的條件，通常的業內標準就是通過SSL和TLS來進行訪問。

那么在使用SSL或者TLS的時候，大家需要注意關注目前暴露出來的一些漏洞，比如說SSL，會有心臟出血和水牢漏洞，需要進行及時彌補。另外在傳輸過程中，建議采用MAC消息認證碼的算法。對于發送的信息進行認證，在服務器端對于收到的信息通過MAC碼進行認證，保證信息是從一個合法的渠道發送過來的，數據沒有被篡改過。

第三是在數據使用過程中，第一個需要注意的是權限管理。不同的人需要有不同的訪問權限，看到不同的信息，越是SaaS企業服務的客戶規模越大，這一點就越重要。第二點是在客戶端的數據顯示的時候，除非必要，否則不要去顯示不必要的一些信息。第三點，也就是說對于一些敏感信息可以通過星號的形式來進行隱藏。

目前很多SaaS軟件習慣的注冊模式就是通過手機號來登陸，這在企業用戶中基本是不可行的。因為對于企業用戶來說，一般都有一個統一的管理員來管理企業內部用戶，手機號并不是企業內部管理員所熟悉的一個管理方式，因此所有面向企業的SaaS服務，都需要和企業內部的域用戶的帳號進行一個集成，目前業內有一些通用的標準。所以對于SaaS廠商來說，軟件在開發過程中必須符合這樣一些域集成的標準。大家可以參考比方說SAML，OpenID 等等一些規則來定義這一塊的功能。

第二點就是隨著移動化的普及，很多時候SaaS軟件是在手機終端上使用的，因此單純的只是一個域帳號的集成可能還不夠，在此推薦采用兩重認證，比方說你可以通過一些挑戰性的問題，或者說把SaaS的一個帳號和我的手機IMEI碼進行綁定，來保證安全。與此同時需要保證當手機丟失的時候，管理員可以遠程對于這個手機上的SaaS信息進行擦除。

最后是關于整個SaaS使用中的一些隱私保護，這個隱私并不是指的個人隱私，更多指的是所服務企業的一些關鍵信息。

正如第一部分所提到的，企業對于它的所有數據負有最終的安全治理管理的責任，也是整個的監管的直接對象，因此如果繞開企業直接拿SaaS后臺的數據來用，可能會讓企業處于一個比較危險的處境。

所以很多時候，在對企業提供SaaS服務的時候，除非企業有一個明確的授權，否則這些數據是不可以被SaaS廠商用做其他用途的。一般在SaaS導入前，企業需要和SaaS廠商簽署保密協議，所有的數據需要由SaaS廠商進行相應保密，不能用于商業用途。

如果有些SaaS廠商希望通過這樣一種SaaS模式提供一個大數據服務，個人建議這些SaaS廠商要對自己的商業模式進行一個仔細考量，這些數據對于企業來說愿不愿意公開？可以公開到什么程度等等，都需要有一個全面的評估。
Q&Ａ
1
Q：企業和saas去交互的時候，數據是如何保證安全的啊。是使用一些加密算法在里面嗎？比如RSA.AES這些。
姚凱：這就是前面說的，對于關鍵數據的分類，識別，加密和對于傳輸的驗證，提供多渠道來保護。這個主要是效率和安全的平衡，以及對于密鑰的分配，盡可能保證用戶的數據只有用戶可以解密并正確訪問。
２

Q：區塊鏈會是這個問題在未來的一個解決方案嗎？
姚凱：目前應該不是一個合適的方案。SaaS數據量會大很多。但看到有人提出對于用戶的私有密鑰是否可以采用區塊鏈的方法保存，這個方法值得進一步研究。