本文作者將從產(chǎn)品的角度對SaaS產(chǎn)品設(shè)計時可能會涉及到的安全性問題進(jìn)行大致的闡述，enjoy~

對于SaaS應(yīng)用，由于如下原因：

1. SaaS服務(wù)和數(shù)據(jù)部署在云端而不是用戶本地機(jī)房，可能存在不可控問題；
2. SaaS基于多租戶架構(gòu)，多個租戶共用一套實例，可能存在數(shù)據(jù)安全性問題；
3. 租戶基于網(wǎng)絡(luò)進(jìn)行訪問，可能存在網(wǎng)絡(luò)劫持等不確定性因素。

因此，潛在用戶在考量是否采用SaaS服務(wù)時，系統(tǒng)安全性及穩(wěn)定性必將成為一個重點考量的方向。

下面將從產(chǎn)品的角度對SaaS產(chǎn)品設(shè)計時可能會涉及到的安全性問題進(jìn)行大致的闡述，首先介紹的是如何實現(xiàn)應(yīng)用的安全性

應(yīng)用安全確保租戶在使用SaaS時能享有高可用性和高可靠性。為了實現(xiàn)應(yīng)用安全，SaaS系統(tǒng)需要在身份認(rèn)證，權(quán)限管理，日志管理等方面采取必要的措施。

身份認(rèn)證

身份認(rèn)證確保只有經(jīng)過系統(tǒng)合法授權(quán)的用戶才能操作和使用系統(tǒng)，是保證整個系統(tǒng)應(yīng)用安全的基礎(chǔ)。通常在系統(tǒng)設(shè)計時可選用三種常見的身份認(rèn)證模式，分別是集中式認(rèn)證，非集中式認(rèn)證，混合式認(rèn)證。

三種認(rèn)證方式對比結(jié)果如下：

集中式身份認(rèn)證

集中式身份認(rèn)證的前提是通過部署一個統(tǒng)一的身份認(rèn)證中心，該身份認(rèn)證中心主要負(fù)責(zé)對登錄SaaS用戶的身份進(jìn)行認(rèn)證和維護(hù)，對應(yīng)的圖示如下：

雖然采用集中式身份認(rèn)證方案可以很好的保證登錄用戶的安全性。但是，該方案需要租戶在SaaS應(yīng)用的身份認(rèn)證中心維護(hù)自己的身份，這樣必將導(dǎo)致租戶信息不能與其他系統(tǒng)一起使用，更不能實現(xiàn)單點登錄。

非集中式身份認(rèn)證中心

非集中式身份認(rèn)證中心就是每個租戶采用自己獨(dú)有的身份認(rèn)證系統(tǒng)，各租戶通過SaaS系統(tǒng)發(fā)布的安全令牌，也就是Token進(jìn)行通信。SaaS系統(tǒng)的身份認(rèn)證中心通過接受解析接受到的Token來獲取對應(yīng)用戶的信息。

非集中式身份認(rèn)證最大程度保證系統(tǒng)的靈活性，通過租戶現(xiàn)有的身份認(rèn)證中心，能夠?qū)崿F(xiàn)租戶身份的統(tǒng)一維護(hù)，便于實現(xiàn)租戶各個系統(tǒng)之間的單點登錄。但這種認(rèn)證方式依賴各租戶自身的身份認(rèn)證系統(tǒng)，十分容易導(dǎo)致SaaS應(yīng)用的身份認(rèn)證系統(tǒng)出現(xiàn)安全性問題。

混合式身份認(rèn)證

不管是集中式身份認(rèn)證抑或是非集中式身份認(rèn)證，在實際生產(chǎn)環(huán)境中，這兩種身份認(rèn)證方式都會被會被廣泛的使用到。而且對于SaaS應(yīng)用而言，需要服務(wù)的客戶千差萬別，很對中小型租戶并沒有專門的身份認(rèn)證中心，要求SaaS本身提供身份認(rèn)證服務(wù)；而對于大型公司而言，已有成型的身份認(rèn)證系統(tǒng)。所以跟進(jìn)上述情況，在設(shè)計SaaS產(chǎn)品是，既要提供集中式的身份認(rèn)證模式，已滿足中小型租戶的使用需求，又要提供非集中式的身份認(rèn)證模式供大型客戶使用。也就是提供混合型身份認(rèn)證模式滿足各類型用戶需求。

權(quán)限管理

權(quán)限管理就是對訪問SaaS系統(tǒng)的租戶進(jìn)行訪問權(quán)限的控制，確保只有擁有對應(yīng)權(quán)限的用戶才能操作對應(yīng)的功能，下面將分別從權(quán)限模型，權(quán)限分配模式，權(quán)限校驗三個方向?qū)aaS應(yīng)用的權(quán)限管理做詳細(xì)的介紹

權(quán)限模型

不管是傳統(tǒng)模式，還是SaaS模式，廣泛采用的權(quán)限模式就是RBAC模型。標(biāo)準(zhǔn)RBAC模型包含四種，分別是基礎(chǔ)模型RBAC0、角色分級模型RBAC1、角色限制模型RBAC2和統(tǒng)一模式RBAC3。

• RBAC0：RBAC的基礎(chǔ)，定義了用戶、角色、會話、操作、操作指引的基礎(chǔ)概念及關(guān)系。
• RBAC1：在RBAC0的基礎(chǔ)上強(qiáng)調(diào)角色間的繼承關(guān)系。
• RBAC2：在RBAC0的基礎(chǔ)上強(qiáng)調(diào)角色間的限制，包含，約束關(guān)系。
• RBAC3：強(qiáng)調(diào)繼承，也強(qiáng)調(diào)角色間的約束。

RBAC0基礎(chǔ)模型的基本原理圖：

RBAC0模型在SaaS系統(tǒng)中同樣強(qiáng)調(diào)用戶、會話、角色、操作、資源等基本概念。但相對傳統(tǒng)應(yīng)用所有資源都是全局屬性的模式，SaaS系統(tǒng)有著更多的不同性和更高的復(fù)雜性。對于SaaS系統(tǒng)而言，用戶是租戶所特有的；角色既有全局的，也有租戶自身的，而租戶的角色是需要隔離的。

權(quán)限分配

從上面的權(quán)限模型中可以看出，權(quán)限分配主要涉及角色管理、用戶到角色、角色許可分配。

角色在SaaS系統(tǒng)權(quán)限分配中發(fā)揮著重要的作用。對于SaaS系統(tǒng)而言，角色既有全局角色，也有租戶相關(guān)的角色。全局角色包含系統(tǒng)管理員和各租戶都會使用到的通用角色，系統(tǒng)管理員主要對系統(tǒng)和租戶進(jìn)行維護(hù)及管理。通用角色主要是為了簡化租戶的操作而統(tǒng)一定義的系統(tǒng)操作角色。租戶相關(guān)的角色也可以進(jìn)一步分為租戶管理員和租戶自定義的業(yè)務(wù)角色。

SaaS系統(tǒng)中的用戶到角色主要由租戶自己操作，對應(yīng)的租戶可根據(jù)自己的實際業(yè)務(wù)需求自定義相關(guān)的角色，也可以直接采用系統(tǒng)通用角色。

角色許可分配涉及到兩個方面：

1. 系統(tǒng)通用角色許可的分配，由系統(tǒng)管理員創(chuàng)建通用角色時統(tǒng)一分配；
2. 租戶自定義角色許可的分配。由租戶管理員分配。

由于角色許可分配涉及具體操作權(quán)限的分配，相關(guān)實現(xiàn)方式可查看老鬼前幾篇文章。

權(quán)限校驗

權(quán)限校驗主要實現(xiàn)驗證對應(yīng)請求用戶是否具有操作權(quán)限。首先校驗租戶是否購買相應(yīng)的功能，如果購買了，再來校驗該用戶是否被授予使用權(quán)限。需要注意的是權(quán)限校驗?zāi)K作為一個通用模塊，在實際應(yīng)用中會被反復(fù)調(diào)用。所以在實現(xiàn)時，需要盡最大的努力保證高性能，高并發(fā)。

日志記錄

SaaS系統(tǒng)獲取用戶信任是需要解決的核心問題，試想一下如果用戶在系統(tǒng)中做了一些錯誤操作導(dǎo)致重要數(shù)據(jù)丟失或出錯了，這個時候用戶可能會懷疑這些錯誤是系統(tǒng)導(dǎo)致的，或者是其他租戶的操作造成的。這種懷疑將會導(dǎo)致用戶對系統(tǒng)安全性的不信任，不信任的產(chǎn)生將會產(chǎn)生致命的結(jié)果。所以，對于完整的SaaS系統(tǒng)，其在設(shè)計之初，就需要考慮到安全性問題，通過日志的形式規(guī)避這種可能存在的風(fēng)險。

日志記錄就是要對用戶在系統(tǒng)的操作行為和操作數(shù)據(jù)進(jìn)行記錄，以便對用戶在系統(tǒng)中進(jìn)行的操作進(jìn)行查證，確保用戶的行為不可偽造，不可銷毀，不可否認(rèn)。

日志具體記錄包含兩部分：行為日志記錄和數(shù)據(jù)日志記錄。

• 行為日志記錄：行為日志記錄就是記錄用戶在系統(tǒng)中訪問的每一個頁面，在頁面中所做的每一個行為都被記錄下來，記錄用戶的身份和行為的時刻。例如：租戶A的用戶A1在2018：08：04-15：00訪問了重要客戶列表，做了刪除客戶操作。
• 數(shù)據(jù)日志記錄：數(shù)據(jù)日志記錄，就是要對用戶在系統(tǒng)中所操作的數(shù)據(jù)進(jìn)行記錄，記錄數(shù)據(jù)的變更過程和變更歷史。這在多人操作同一個數(shù)據(jù)的系統(tǒng)顯得尤為重要。

本文由 @老鬼 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Pexels，基于 CC0 協(xié)議