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

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

2、整個SaaS的設(shè)計，會涉及到數(shù)據(jù)安全、以及用戶和權(quán)限管理這兩個方面的問題。

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

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

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

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

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

SaaS應(yīng)用的安全問題有哪些？

首先來看一下SaaS應(yīng)用中的安全責(zé)任。



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

第三點是關(guān)于軟件的變更。對于SaaS來說，SaaS軟件的升級、補丁都是由SaaS廠商來提供，而對于企業(yè)托管服務(wù)來說，整個變更、發(fā)起都是由企業(yè)發(fā)起，由企業(yè)決定是否去做相應(yīng)的變更。

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

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

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



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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

其次是關(guān)于數(shù)據(jù)的傳輸，目前SaaS數(shù)據(jù)的傳輸大多都是在公網(wǎng)進行，是不可控的，因此通過加密的途徑來數(shù)據(jù)傳輸是一個基本的條件，通常的業(yè)內(nèi)標準就是通過SSL和TLS來進行訪問。

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

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

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

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

最后是關(guān)于整個SaaS使用中的一些隱私保護，這個隱私并不是指的個人隱私，更多指的是所服務(wù)企業(yè)的一些關(guān)鍵信息。

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

所以很多時候，在對企業(yè)提供SaaS服務(wù)的時候，除非企業(yè)有一個明確的授權(quán)，否則這些數(shù)據(jù)是不可以被SaaS廠商用做其他用途的。一般在SaaS導(dǎo)入前，企業(yè)需要和SaaS廠商簽署保密協(xié)議，所有的數(shù)據(jù)需要由SaaS廠商進行相應(yīng)保密，不能用于商業(yè)用途。

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

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