SaaS系統(tǒng)-應(yīng)用安全
本文作者將從產(chǎn)品的角度對SaaS產(chǎn)品設(shè)計時可能會涉及到的安全性問題進(jìn)行大致的闡述,enjoy~
對于SaaS應(yīng)用,由于如下原因:
- SaaS服務(wù)和數(shù)據(jù)部署在云端而不是用戶本地機(jī)房,可能存在不可控問題;
- SaaS基于多租戶架構(gòu),多個租戶共用一套實例,可能存在數(shù)據(jù)安全性問題;
- 租戶基于網(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)通用角色。
角色許可分配涉及到兩個方面:
- 系統(tǒng)通用角色許可的分配,由系統(tǒng)管理員創(chuàng)建通用角色時統(tǒng)一分配;
- 租戶自定義角色許可的分配。由租戶管理員分配。
由于角色許可分配涉及具體操作權(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é)議
RBAC
是指Role based還是Rulebased?我一直分不清
老哥,最近怎么不更新了啊
脫敏
??
有話不說憋得慌。支持
支持