互聯網系統應用安全控制

在 Web 應用開發中,安全一直是非常重要的一個方面。面向互聯網公網的接口服務,如果不加防護會導致數據泄露和商業風險。應用的安全性包括用戶認證(Authentication)和用戶授權(Authorization)兩個部分。用戶認證指的是驗證某個用戶是否爲系統中的合法主體,也就是說用戶能否訪問該系統。用戶認證一般要求用戶提供用戶名和密碼。系統通過校驗用戶名和密碼來完成認證過程。用戶授權指的是驗證某個用戶是否有權限執行某個操作。簡單來說,認證是指系統需要確認你是誰?而授權是指在通過認證之後,你能幹什麼?

核心概念

用戶認證關鍵對象

  • Subject:主題,可以使用戶,也可能是程序,都要去訪問系統的資源,系統需要對subject進行身份認證。
  • Principal:身份信息,通常是唯一的,一個主題還有多個身份信息,單都有一個主身份信息(Primary Principal)。
  • Credential:憑證信息,可以是密碼、證書、指紋。

用戶授權關鍵對象

  • who:主題,即上文的subject
  • what:資源,resource,subject必須具備資源的訪問權限纔可訪問資源。
  • how:權限/許可permission,針對資源的權限或許可,subject具有permission訪問資源,如何訪問需要定義permission。

常見的實現標準

Http常用認證方式

  • Http Basic認證:用戶名密碼按照格式“用戶名:密碼”通過Base-64編碼,通過Authorization header傳遞到服務端,服務端解碼成爲“用戶名:密碼”格式進行認證。
  • Http Digest認證:當客戶端第一次請求服務端資源時,服務端會返回一個隨機數(nonce), 然後客戶端會通過多次MD5加密來計算出來response的值 (response=MD5(HA1:nonce:HA2)), 其中HA1=MD5(username:realm:password), HA2=MD5(method:digestURI). 當服務端拿到這個response,那麼它會從DB取出用戶名密碼來做同樣的操作來看計算出來的response是否一致,如果一致,則表明認證通過。
  • Cookies & Session:在第一次登陸請求中傳遞用戶名密碼,服務端在校驗結束後生成一個session-id,並將這個session-id和用戶關聯,然後通過http response的cookie header返回給客戶端,客戶端只需要存儲這個cookie並在後續的請求都帶上這個cookie就可以。
  • JWT(Json web token):一種安全標準(RFC 7519)。服務器認證以後,生成一個 JSON 對象,發回給用戶,用戶與服務端通信的時候,都要發回這個 JSON 對象。服務器完全只靠這個合法簽名的對象認定用戶身份。

互聯網常用授權理論

  • ACL: 控制訪問列表(Access Control List) 。ACL是面向"資源"的訪問控制模型,機制是圍繞"資源"展開的。在ACL中,包含用戶(User)、資源(Resource)、資源操作(Operation)三個關鍵要素。每一項資源,都配有一個列表,記錄哪些用戶可以對這項資源執行哪些操作。當系統試圖訪問這項資源時,會檢查這個列表中是否有關於當前用戶的操作權限。
  • RBAC: 基於角色的訪問控制(Role-BasedAccess Control)。RBAC認爲授權實際就是 who,what,how 三者之間的關係,即 who 對 what 進行 how 的操作。
  • OAuth2:OAuth是一個關於授權(authorization)的開放網絡標準,目前的版本是2.0版。

基於角色的訪問控制

RBAC認爲權限的過程可以抽象概括爲:判斷“Who是否可以對What進行How的訪問操作(Operator)”這個邏輯表達式的值是否爲True的求解過程。即將權限問題轉換爲Who、What、How的問題。who、what、how構成了訪問權限三元組。

RBAC的核心模型圖如下:
在這裏插入圖片描述
RBAC的關注點在於 Role 和 User, Permission 的關係。稱爲 User assignment(UA) 和 Permission assignment(PA)。關係的左右兩邊都是 Many-to-Many 關係。就是 user 可以有多個 role,role 可以包括多個 user。User 通過成爲 Role 而得到這些 Role 的 Permission,Role 隔離了 User 和 Permission 的邏輯關係。
實體關係圖如下:
在這裏插入圖片描述

  • 用戶(user):人、機器、網絡等,進行資源或服務訪問的實施主體
  • 角色(role):一個工作職能,被授予角色的用戶將具有相應的權威和責任
  • 會話(session):從用戶到其激活的角色集合的一個映射
  • 權限(permission):對受RBAC保護的一個或多個對象執行某個操作的許可
  • 操作(operation):一個程序可執行的映像,被調用時爲用戶執行某些功能
  • 客體(object):需要進行訪問控制的系統資源,例如:文件、打印機、數據庫記錄等

某個主體(subject)對某個客體(object)需要實施某種操作(operation),系統對這種操作的限制就是權限控制。在一個安全的系統中,通過認證來確認主體的身份。客體是一種資源,是主體發起請求的對象。主體所能做什麼,就是權限,權限可以細分爲不同的能力,例如:在Linux文件系統中,將權限分爲 讀、寫、執行 三種能力。

適用於RBAC模型的開源框架

Apache Shiro

Shiro是一個強大而靈活的開源安全框架,能夠非常清晰的處理認證、授權、管理會話以及密碼加密。Shiro在保持強大功能的同時,還在簡單性和靈活性方面擁有巨大優勢。Shiro對角色的簡單的籤權(訪問控制),支持細粒度的籤權;不跟任何的框架或者容器捆綁,可以獨立運行。
在這裏插入圖片描述

Spring Security

Spring Security提供了一套 Web 應用安全性的完整解決方案。在用戶認證方面,Spring Security 框架支持主流的認證方式,包括 HTTP 基本認證、HTTP 表單驗證、HTTP 摘要認證、OpenID 和 LDAP 等。在用戶授權方面,Spring Security 提供了基於角色的訪問控制和訪問控制列表(Access Control List,ACL),可以對應用中的領域對象進行細粒度的控制。

Apache Shiro VS Spring Security

除了不能脫離Spring,shiro的功能Spring Security都有。而且Spring Security對Oauth、OpenID也有支持,Shiro則需要自己手動實現。但Apache Shiro的學習難度要底很多,如果對Apache Shiro 和 Spring Security都不熟的團隊,建議直接上手shiro。

OAuth2.0

OAuth 是一個在不提供用戶名和密碼的情況下,授權第三方應用訪問 Web 資源的安全協議。例如一個 OAuth 場景:用戶將照片存儲在Google,然後在"雲沖印"的網站,將照片衝印出來。那麼,"雲沖印"網站需要獲得用戶的授權來讀取Google上的用戶照片。

OAuth在"客戶端"與"服務提供商"之間,設置了一個授權層(authorization layer)。“客戶端"不能直接登錄"服務提供商”,只能登錄授權層,以此將用戶與客戶端區分開來。"客戶端"登錄授權層所用的令牌(token),與用戶的密碼不同。用戶可以在登錄的時候,指定授權層令牌的權限範圍和有效期。

OAuth 的一些名詞:

  • Third-party application:第三方應用程序,又稱 “Client” 客戶端
  • HTTP Service:HTTP服務提供商,上例中的Google
  • Resource Owner:資源所有者,就是用戶
  • User Agent:用戶代理,就是瀏覽器
  • Authorization server:認證服務器,即服務商提供商專門處理認證的服務器
  • Resource server:資源服務器,即服務提供商存放用戶生成的資源的服務器

客戶端必須得到用戶的授權(authorization grant),才能獲得令牌(access token)。OAuth 2.0定義了四種授權方式。

  • 授權碼模式(authorization code)
  • 簡化模式(implicit)
  • 密碼模式(resource owner password credentials)
  • 客戶端模式(client credentials)

拍拍貸架構師楊波給了一個流程圖來幫助判斷什麼樣的場景下需要採用哪種OAuth2的workflow:
在這裏插入圖片描述

Spring Cloud Security

Spring Cloud Security提供了一組用於構建安全應用程序和服務的簡單框架。基於Spring Boot和Spring Security OAuth2,我們可以快速創建實現常見模式的系統,如單點登錄、令牌刷新和令牌交換。

Spring Security VS Spring Cloud Security

Spring Security解決的是單體服務的授權認證問題,Spring Cloud Security解決的是分佈式架構系統間授權問題。在使用Spring Cloud Security OAuth2.0的微服務體系內部,依然需要使用Spring Security實現資源服務內的訪問權限控制。

參考文檔
權限管理——用戶認證和用戶授權
https://blog.csdn.net/xdd19910505/article/details/51926540
微服務架構學習筆記之一認證和授權
https://www.jianshu.com/p/8867ea3cd9f7
JSON Web Token 入門教程
http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
RBAC模型初探
http://blog.sciencenet.cn/blog-2946501-974635.html
理解OAuth 2.0
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
權限控制和OAuth
http://www.cnblogs.com/butterfly100/p/8698425.html
互聯網業務安全之通用安全風險模型
http://www.cnblogs.com/alisecurity/p/5780648.html

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章