中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

企業在初期發展時，是以線下業務為主。但之后的發展，隨著線上產品做得越深，權限管理也會更復雜，因此在開始的時候就應該著手準備。下面是筆者整理分享的關于RBAC權限設計的理論知識內容，大家一起往下看看吧！

在企業快速發展的初期，通常以線下業務為核心戰略目標。隨著公司的快速發展，線上產品做的越來越深，導致權限管理的復雜性增加，特別是在大型組織中。

管理大量用戶的權限可能會變得混亂，難以維護。等到后期需求堆疊困難時候，才想到權限梳理的問題。所以在產品初期就應該有權限分配的意識。

一、傳統權限

企業攻城拔寨的早期階段，IT產品業務線較為單一，研發部小步快跑迎合業務往往最初的產品需求。而且公司高層變動較大，每當新來一個leader都臨時賦予給他最高或部分權限。所以傳統權限分配或都是直接授予用戶，而不涉及角色的概念。在這種模型下，每個用戶被賦予特定的權限，而不考慮用戶是否屬于某個角色或組。

這里拿西游記舉個例子，可以看出唐僧和孫悟空對應的“經文”是系統直接授予的。這時候，如果再來一個豬八戒那我們需要再次對“經文”勾選查看或者編輯權限。

但是當我們的取經隊伍足夠大的時候，再去一個個按照人名去勾選權限維護起來肯定是困難的，那我們該如何更有效的管理我們的取經隊伍？這時引入RBAC模型，它可以更輕松地處理用戶的權限。

二、RBAC模型是什么？

RBAC是指”基于角色的訪問控制”（Role-Based Access Control）。它是一種訪問控制的安全模型，通過將權限分配給角色，然后將角色分配給用戶，來管理系統中的用戶訪問。RBAC的核心思想是將用戶的權限與其角色關聯，而不是直接將權限授予用戶。

1. 用戶（User）：系統的最終使用者，可以被分配一個或多個角色。
2. 角色（Role）：定義了一組相關權限的命名集合。用戶可以被分配到一個或多個角色。
3. 權限（Permission）：描述了可以執行的操作或訪問的資源。權限與角色相關聯，用戶通過分配到角色而獲得相應的權限。
4. 訪問控制矩陣（Access Control Matrix）：顯示了用戶、角色和權限之間的關系，以及誰可以執行什么操作的表格。

接著上面的案例，當我們的系統加入豬八戒和沙悟凈這兩個人物時，按照傳統的權限分配模式，我們需要分別對每個人授予權限，那如果使用RBAC模型，我們將系統中加入角色。這時候只需要把“孫悟空”“豬八戒”“沙悟凈”賦予徒弟這個角色后，后續修改徒弟的權限，即可修改給所有的徒弟。

相比之下，RBAC引入了角色的概念，將權限與角色相關聯，然后將角色分配給用戶。這種方式使得權限管理更為靈活和可維護，因為只需要管理角色的權限，而不是每個用戶的權限。這對于大型組織或復雜系統來說是一種更有效的權限管理方法。

三、多角色權限

當一個人具有多個角色時，RBAC允許用戶同時擁有多個角色。這樣的設計使得系統更加靈活，能夠更好地適應組織結構和復雜的訪問需求。在RBAC中，用戶和角色之間的關系可以是多對一或多對多，具體取決于系統的設計需求和安全策略。

1. 多對一（Many-to-One）：多個用戶映射到同一個角色。這表示多個用戶共享相同的角色，但每個用戶在系統中只屬于一個角色。
2. 多對多（Many-to-Many）：一個用戶可以映射到多個角色，同時一個角色可以包含多個用戶。這表示用戶和角色之間存在更為靈活的關系，一個用戶可以在系統中屬于多個角色，而一個角色也可以包含多個用戶。

四、多角色權限處理方式

在RBAC中，有兩種常見的處理多角色的方式：

1. 合并權限： 用戶被賦予所有角色的權限。這意味著用戶將擁有他所屬的每個角色的權限。
2. 最小化權限： 用戶只被賦予他所屬的所有角色共同的權限。這種方式確保用戶只能執行他所有角色共同具有的權限，而不是所有角色的權限總和。

例如，如果“蜈蚣精”同時具有“飛天怪”和“潛水怪”兩個角色，而這兩個角色分別具有不同的權限。這時候若使用合并權限的邏輯，則“蜈蚣精”同時擁有“飛天”“地面”“潛水”三個技能，若使用最小化權限邏輯，則“蜈蚣精”只有“地面”技能。

因此如何選擇合適的方法取決于系統的安全需求和設計目標。在某些情況下，可能需要靈活性更大，因此采用合并權限的方式。在其他情況下，為了確保最小的權限原則，可能會選擇最小化權限的方式。

五、模型分類

讀到現在你應該對RBAC已經有了初步的認識，甚至可以適配一些業務場景。但是在真實的工作中，往往業務比我們想象的要復雜，那么我們需要有更進階的模型方式去處理我們的業務，首先RBAC一共有4種模型，分別是RBAC0（基礎模型）、RBAC1（基礎模型）、RBAC2（角色限制模型）、RBAC3（統一模型）。

1. RBAC0（基礎模型）

最基本的 RBAC 實現，包括角色、用戶和權限的概念。在這個級別上，訪問控制比較簡單，可能不包括角色的層次結構或其他復雜的功能。

就比如我們剛剛的舉例：角色：徒弟；權限：查看經文，編輯經文。

2. RBAC1（繼承模型）

引入了高級用戶的概念，如角色的層次結構、繼承權限等。高級用戶可能具有比普通用戶更多的權限，例如刪除其他用戶的文章。同時，管理員仍然擁有更高級別的權限。

角色：師傅；權限：可以查看并編輯徒弟的經文，但是徒弟只能編輯和查看自己的。同時可以刪除自己和徒弟的經文。

3. RBAC2（角色限制模型）

他是RBAC 模型的演進，通過引入更多的約束和規則，以滿足實際業務中對角色分配的特定需求。這里的約束關系主要包含靜態分離和動態分析，靜態分離是指互斥的角色不能同時賦予同一個用戶；動態分離指用戶不能同時操作兩個互斥的角色進行登錄。

1）動態分離

動態分離是指在用戶操作階段，確保用戶不能同時操作兩個互斥的角色，即用戶不能同時登錄并執行涉及到互斥角色的操作。

例：即使我現在又是師傅又是徒弟，但是我在系統操作的時候，我不能同時操作兩個角色。比如我是師傅時候我就不能降妖除魔，防止潛在的業務沖突

2）靜態分離

靜態分離是指在角色分配的靜態配置階段就確保某些角色是互斥的，不能同時賦予同一個用戶。這樣的限制可以通過在 RBAC 模型中定義互斥關系或者強制性的角色分離規則來實現。

例：在西游記中定義師傅和徒弟角色為互斥的，系統在進行角色分配時會檢查這一規則，確保一個用戶不能同時擁有師傅和徒弟角色。

3）動態分離和靜態主要有三種約束形式

a、互斥角色：互斥關系角色指的是在某些情況下，兩個或多個角色是互斥的，即它們不能同時分配給同一個用戶。這是一種靜態的限制，通常在角色分配的靜態配置階段就確定。

b、基數約束：基數約束涉及到限制用戶能夠擁有的角色數量，或者某個角色在系統中的實例數。這種約束可以是靜態的，也可以是動態的，取決于在哪個階段進行約束的檢查。

c、先決條件約束：先決條件角色是指在分配某個角色之前，用戶必須先擁有另一個或一組先決條件角色。這種機制可以用于確保用戶在獲得某個高級別角色之前必須具備一定的背景或權限。

4. RBAC3（統一模型）

很多人說 RBAC3=RBAC1+RBAC2，雖然在某些方面有相似之處，但它們并不是簡單的加法關系。RBAC3 通常被認為是對 RBAC 模型的更進一步的增強。RBAC1 引入了角色的層次結構和權限繼承的概念，增加了靈活性和簡化了權限管理。RBAC2 在 RBAC1 的基礎上引入了動態任務權限的概念，使得權限的分配更加靈活和動態。RBAC3 進一步提高了安全性和靈活性，引入了更高級的審計功能、自定義安全策略、高級用戶管理等。

例：

• 角色：徒弟（悟空）。權限： 查看經文，編輯經文。
• 角色：師傅（三藏）。權限： 除了查看經文，編輯經文。增加了刪除經文。
• 角色：仙班（玉帝）。權限： 除了師傅的權限外，還能創建創建經文，評估徒弟表現。
• 角色：教主（如來）。權限： 除了仙班的權限外，還能調整創建經文平臺的設置、審計平臺活動。
• 特殊情況下的動態調整： 在某些特殊情況下，可以靈活地調整權限，例如允許一個關卡有兩位首領。
• 角色分配先決條件：想成為如來，必須先是師傅。

六、用戶組

現在我們已經了解了RBAC模型的概念，但是對于更復雜的企業來說維護起來的工作量還是及其龐大和繁瑣的。

針對這種情況，往往我們可以將相同權限的角色進行合并成用戶組。這樣可以簡化權限管理。同時也可以讓用戶組織更為清晰。這時候我們再看第一個案例，那么孫悟空、豬八戒、沙悟凈就是一個取經團隊，也就是用戶組。

七、總結

不管使用哪種模型，只有適合當下的業務才是最好的。畢竟在公司發展的不同階段，所投入的研發資源不同，產品的定位也會隨著戰略的調整而調整。當然在初期產品規劃的時候還是要有全局觀，防止后面業務調整的時候所造成較大的修改成本。