微服務架構下訪問控制模型的設計與實現

朱永強 方 意 宮學慶

(華東師范大學計算機與軟件工程學院 上海 200062)

0 引 言

訪問控制是根據系統設定的訪問權限授予認證通過的訪問用戶的過程，它作為信息系統的核心內容之一，直接影響著一個系統的安全與效率。隨著互聯網技術的快速迭代，微服務架構[1]以其靈活拓展、獨立部署等優點在互聯網應用中被廣泛采用。一些流行的微服務框架比如Spring Cloud、Dubbo、HSF等在互聯網公司的主要業務中扮演舉足輕重的角色。與此同時，訪問控制在微服務架構的信息系統中會變得更加復雜，因此研究該問題有較為重大的意義。

如圖1(a)表示的是單體系統訪問控制流程，單體系統的訪問控制通常采用集中式的管理方式。第1步通過權限控制模塊識別用戶的身份信息，并進行身份認證；第2步根據已制定的訪問規則來約束訪問行為；第3步訪問相應的功能的業務模塊。單體系統的訪問控制模塊跟業務模塊在同一進程中，通過維護有狀態的用戶登錄信息進行訪問控制，如Session等技術。圖1(b)表示的是微服務架構下的訪問控制方式。它將傳統的單體系統根據業務內容被拆分成若干個不同的微服務實例，訪問控制模塊可以單獨成為一個服務，也可以拆分到在各個業務服務中。相比較單體系統的訪問控制方式痛點如下:

(1) 當訪問者不僅僅是用戶，還包括其他服務的調用時，單體系統架構下訪問控制的管理方式就不再滿足需求。要考慮訪問入口適用的場景，會出現用戶與服務間的鑒權、服務與服務間的鑒權等多種場景。

(2) 微服務架構下的訪問請求一般是無狀態的，導致用戶的每次請求都需要進行訪問控制，這樣使得訪問控制模塊的訪問壓力變大。

(3) 微服務架構下的系統需要管理一些特有的資源信息，比如對服務實例信息的管理。該管理方式是在傳統負載均衡技術的基礎上可以增加對服務實例訪問的管理，對不同訪問請求設定提供服務的實例信息，從而提高系統管理的靈活性。

訪問控制模型是用來表示訪問者與訪問資源間的關系，這種關系是訪問中遵守的規則與策略。RBAC(Role-Based Access Control)是目前信息系統中廣泛認可的訪問控制模型，目前在微服務架構下基于RBAC訪問控制模型還沒有較為成熟的方案。微服務架構下，傳統的權限管理模型不能滿足微服務場景的需求，體現在對不同服務提供的Restful接口、服務實例信息、服務間調用權限等信息的管理。此外，用戶權限管理數據庫與資源數據庫是分庫存儲設計，因此在進行權限的校驗操作時需要對權限管理過程進行控制。

基于上述痛點，本文將在RBAC模型的基礎上提出微服務下的權限管理模型MSAM。該模型可以提供一套微服務架構下包含服務間權限管理、服務實例信息管理等的細粒度權限管理機制。此外，下文還將介紹通過集中式權限數據庫與分布式權限數據庫兩種方式來討論基于微服務架構的訪問控制設計方案。

1 訪問控制模型及實現

本節研究并分析了RBAC模型及其衍生模型，并從庫表設計、訪問模塊、認證與鑒權框架等方面介紹了相關的實現方案。

1.1 RBAC模型

RBAC模型最初是由D. Ferraiolo 和R. Kuhn提出[2]，引入了角色的概念并給出了基本的語義。其主要觀點是將權限信息賦予給角色來管理，通過給用戶分配不同的角色，從而實現將權限對用戶的分配。

近年來RBAC模型的發展中，研究較為全面且公認的是美國國家標準與技術研究院于2001年制定出的NIST RBAC模型[3]，其中后者是對前者的抽象與概括。NIST RBAC模型分為4個層次，從基本到復雜依次為基本模型Flat RBAC、角色分級模型Hierarchical RBAC、角色限制模型Constrained RBAC和均衡對稱模型Symmetric RBAC等4個等級，這4個等級的功能是遞增的。

1.2 RBAC的衍生模型及實現

1.2.1 拓展型權限管理模型E-RBAC

E-RBAC(Extended Role-Based Access Control)[4]模型是在RBAC模型的基礎上增加了用戶授權的機制。如圖2所示，E-RBAC模型通過用戶和角色組合授權的方法，使得權限控制的方式變得更加靈活。

圖2 E-RBAC模型圖

該模型在庫表設計中用戶信息表與角色信息表為同一張數據庫表，并在該表中設置“是否角色”的字段用來區分數據表中的元組是用戶還是角色的元組。該模型考慮了對數據庫空間的合理使用，與傳統的RBAC模型比較，優勢在于一方面將用戶信息與角色信息放置在同一張表中管理，通過屬性字段來加以區分，減少了數據庫模式設計；另一方面提出了增加用戶與權限進行關聯的設計，使用用戶和角色混合授權。

但隨著用戶信息的增加，這種設計方式會導致數據庫表字段出現大量的空值，不利于數據庫表的維護與處理。另外，這種設計形式會增加額外判斷條件的處理，影響訪問控制的效率。

1.2.2 USAM通用權限管理模型

USAM(Universal Scheme of Authority Management)模型[5]提出了一種管理功能權限和數據權限更加有效的方式。如圖3所示，該模型在傳統RBAC的功能權限的基礎上根據實際業務場景增加了數據權限的管理。該模型拓展了RBAC基本模型，包含用戶、角色、組織表、資源、功能權限、數據類型、數據對象、操作類型等8個實體。

圖3 USAM模型圖

該模型相比傳統RBAC模型的優勢在于一方面將權限信息拆分為資源信息與操作類型信息，使得權限信息更加細化，方便用戶對權限信息的管理；另一方面在用戶、角色、權限實體中增加了用戶與角色間對權限屏蔽關系的設計，可以靈活修改需要屏蔽的角色權限。

該模型的缺點在于對角色權限出現重復的情況未進行分析說明，這種情況下權限屏蔽操作的維護信息較難處理。此外，數據權限的管理過于復雜，影響系統處理效率。

這兩種RBAC的衍生模型雖然在傳統的權限管理系統都能實現訪問控制模型的功能，但是在微服務場景下仍會出現對服務間權限功能以及數據權限不滿足等問題。所以在微服務場景下需要提出相應的訪問控制模型來實現對應場景的訪問控制方案。

1.3 微服務架構下的訪問控制方案

1.3.1 單點登錄

在微服務場景下，訪問請求往往是無狀態的，這就意味著每次請求需要進行權限校驗，但是系統需要單個身份認證的訪問入口。單點登錄(SSO)[6]使得每個提供資源的服務都必須與認證服務交互，這會產生大量的網絡開銷，在微應用的個數增多時，這種方案的弊端會尤為明顯。

1.3.2 分布式Session方案

分布式Session[7]方案原理是將用戶認證的信息存儲在共享內存中，通常由用戶Session實現方式是簡單的分布式哈希映射。當用戶登錄微服務系統后，用戶信息可以從共享存儲中獲取，下一次請求中以Session ID的方式請求，便可獲取用戶信息。該方案是支持高可用且可擴展，缺點在于共享存儲需要一定保護機制，需要建立安全的鏈接進行訪問，這便提高了系統復雜性。

1.3.3 令牌與API網關結合

隨著微服務、Docker等技術的興起，基于令牌的認證方式已經越來越流行。相比較傳統Session中的Session ID，Token不僅僅是一個key，它包含了用戶的身份信息，通過驗證令牌就可以完成身份校驗。像微博、QQ等服務的API很多都是使用該方式進行認證的。

用戶在首次登錄系統身份信息校驗通過后，微服務授權服務會提供該用戶權限信息令牌。該令牌由身份驗證服務進行簽名，并且必須包含足夠的信息，以便可以在所有微服務中建立用戶身份。令牌會附加在每一次訪問請求中，在API網關進行令牌解析，權限校驗通過的請求會路由之指定提供服務去處理。

1.4 微服務架構下的訪問控制相關實現技術

1.4.1 認證協議

認證協議是處理系統驗證用戶身份的協議。OAuth[8]是目前主流的認證協議，OAuth 2.0是OAuth的新版本，更具有簡單易用性。系統開發者可以通過組織在資源擁有者和服務提供商之間的交互動作來代表用戶，也可以允許授權給第三方應用以獲得訪問的權限。同時為Web應用、桌面應用等場景下提供特定的認證流程。

1.4.2 認證機制

JWT(Json web token)[9]是一種基于JSON格式的訪問令牌標準，該標準適用于分布式系統中的單點登錄的場景中。JWT的聲明一般被用在系統訪問者和服務資源擁有者間傳遞認證的訪問者身份信息的載體，從而根據用戶信息對應的權限獲取資源服務器的資源。此外，JWT也可直接被用于通過加密進行認證，從而保證信息的安全性。

JWT的主要優勢在于使用無狀態、可擴展的方式處理應用中的用戶會話。服務端可以通過內嵌的的聲明信息，很容易地獲取用戶的會話信息，而不需要去訪問用戶或會話的數據庫，從而降低數據庫的訪問壓力。

1.4.3 鑒權框架

鑒權框架Spring Cloud Security[10]基于OAuth2 和OpenID協議的可配置的單點登錄機制，并且使用Token保障資源訪問安全。此外，該框架引入UAA鑒權服務[11]。UAA是一種權限控制的Web服務，該服務用于管理賬戶、客戶端和訪問控制的問題令牌(Issue Token)。UAA實現了OAuth2授權框架和通過運用基于JWT的Issue Token來實現對訪問控制中權限傳輸載體的功能。

UAA基于OAuth2[12]的認證協議實現，當用戶訪問應用時，生成并發放Token給目標客戶端。UAA認證服務包含如下幾個方面的內容: 1) 認證對象。如用戶、代理客戶端以及資源提供服務器。2) 認證類型。主要有授權碼模式、客戶端模式、密碼模式等類型。3) 認證權限，并作為一個參數附加到Access Token上，用于權限的查詢與鑒別。

2 微服務架構下的權限管理模型MSAM

本節中提出了微服務架構下權限模型MSAM，并與上文提到的兩種基于RBAC模型改進的權限模型進行對比。

2.1 模型設計

MSAM模型在RBAC模型的基礎上將權限分為了功能權限與數據權限，如圖4所示。功能權限表示訪問者對服務中提供的功能訪問的權限，數據權限表示訪問功能時擁有對哪些數據集信息以及服務實例的訪問權限。

圖4 MSAM模型圖

其中該模型將功能權限細化到服務層面，直接管理服務內的權限信息，比如服務A擁有服務B中接口1的權限，從而實現了對服務間調用場景的權限管理。該模型還在角色權限賦予的基礎上添加了用戶權限的賦予與屏蔽功能，用戶權限可以在角色權限的基礎上靈活變更。

此外，該模型將數據權限細化到數據集與服務實例信息層面，用于微服務架構下服務信息的管理。實現方式上通過將數據權限授予給組織，其中組織與實際的機構信息相關。數據權限還與用戶進行關聯，支持用戶根據需求靈活地添加或者屏蔽數據權限。

2.2 權限管理模型間對比

MSAM模型與上文兩種基于RBAC模型改進的權限模型的功能對比分析如表1所示。MSAM模型基于微服務架構將權限信息分為功能權限與數據權限。功能權限新增了服務層面上的功能權限管理，服務信息中包含了服務實例信息與服務權限信息，相同的服務會擁有若干個服務實例與相同的服務權限。數據權限新增了服務實例與數據集兩個維度，某一條數據權限可以實現控制對不同服務實例的管理。數據集指的是某一功能權限對可訪問數據范圍的集合，比如，數據權限A包含了對服務甲中服務實例1、2、3的訪問權限，數據集包含了id值在[100，200]的數據范圍。此外，實際環境下數據權限往往與不同組織以及用戶相關，所以將數據權限與組織機構以及用戶關聯，用戶可以在組織機構的基礎上實現對數據權限的動態管理。

表1中資源數據指的是訪問者能夠調用某接口時訪問的數據。一般功能權限指的是對資源數據的操作功能。新增用戶特殊權限與屏蔽用戶特殊權限指的是用戶能否在角色的基礎上動態管理權限內容。微服務架構數據庫分庫設計指的是在實現權限信息時可支持分庫設計。微服務架構服務權限設計指的是支持微服務架構下一些特有的資源訪問功能，比如服務實例管理功能等信息。

3 MSAM模型的實現

3.1 表結構設計

用戶權限管理數據庫庫表設計如圖5所示，圖中給出了一些主要屬性。這個模型有若干實體表與關聯表，實體表中包含用戶表、角色表、功能權限表、權限信息表、組織表、資源表、服務實例表、數據信息表、服務信息表、服務權限表等。關聯表包括用戶角色關聯表、角色權限關聯表、用戶權限屏蔽關聯表、用戶權限新增關聯表、組織資源關聯表、用戶資源增加表、用戶資源屏蔽表、用戶組織關聯表等。下面從具體三方面介紹拓展的內容。

圖5 MSAM模型數據庫模式圖

3.1.1 功能權限控制的拓展

在權限復雜的管理系統中，角色的權限內容經常隨時間和業務發生變化，不同角色的權限往往會出現相互交叉的情況。為了在不變更角色權限信息的條件下適應這種變化，權限管理需要靈活的基于用戶的權限管理方式。如圖5(A)所示，在用戶表與權限表間增加用戶屏蔽權限關聯表和用戶增加權限關聯表，用于實現用戶靈活的權限管理。于是，通過定義用戶與權限表的關聯來實現動態權限管理，來滿足細粒度的權限管理場景。例如，用戶甲擁有角色A，但角色A未包含對接口a的訪問權限，此時只需要在用戶權限增加關聯表中新增該權限記錄即可。同理，需要去除某一權限時在用戶權限屏蔽關聯表中操作。此外，功能權限設計采用分層的方式，低級別權限采用前置權限的編號方法，高級別權限采用后置權限的編號方法。比如對某一接口的訪問權限的id是100開頭，而對此接口GET方法的權限id是10001，PUT方法的權限id是10002，從而實現了分層權限管理功能。

3.1.2 數據權限控制的拓展

通過定義資源表、組織機構表以及組織-資源關聯表等，實現添加數據權限管理功能。在大型組織機構內部，數據權限往往跟部門機構相關聯，本機構只有訪問本機構以及下屬機構的數據信息，所以設計將機構、資源表與用戶表相關聯，來實現動態管理數據權限信息。此外，在功能權限表中添加資源ids字段，表示該權限對應的數據資源內容，從而實現在訪問指定接口時不同種數據權限管理的功能。

針對微服務場景，如圖5(B)所示，數據資源在傳統信息系統之外增加對服務實例信息的管理，使得不同機構的不同用戶可以在同服務實例負載均衡功能之上實現靈活配置調用實例信息，提高服務調用的靈活性與可靠性。例如，用戶甲希望手動選擇處理某個調用的請求服務實例時，通過在請求信息中添加對應實例id，在該類型數據權限的管理模塊中予以控制。

3.1.3 服務間權限控制的拓展

定義服務間調用權限管理模塊。服務間權限控制數據庫表設計如圖5(C)所示。通過定義服務信息表與服務權限表一對多的關聯關系進行服務間權限的管理。在微服務應用場景下，除了需要管理用戶訪問指定服務的接口權限，還需要對服務間調用做權限管理，從而保證服務間調用的安全性。

3.2 訪問控制實現方式

3.2.1 集中式訪問控制

基于微服務架構的信息系統一般對外需要一個訪問入口來實現訪問控制與路由轉發的網關功能。網關與權限管理服務關聯或者直接訪問權限數據庫，不同的訪問請求在網關處統一進行權限校驗，校驗通過會路由到指定的服務。

集中式訪問控制的關鍵在于有獨立于其他服務的訪問控制服務，該服務負責管理其他服務對外提供的接口內容的權限內容。如圖6所示，通過該服務校驗的請求可以路由到指定服務上去；未通過校驗，則返回客戶端沒有訪問權限。該種管理方式的優勢在于: 一方面訪問控制更加集中，有統一對外的權限校驗入口，可以將非法請求隔離在系統的外部；另一方面方便訪問控制，可以統一進行權限管理以及維護，提高管理效率。但同時在大量訪問請求進入系統時，鑒權服務需要承擔過大的處理壓力，容易出現性能瓶頸，甚至單點故障。

圖6 集中式訪問控制架構圖

這種方式適用于在微服務系統中服務實例相對較少的場景，在服務實例過多時統一的權限服務會承擔過大的訪問壓力，從而影響整個系統的性能。此外，由于權限統一管理，當不同服務的權限信息需要隨著業務改變時，需要對統一的權限服務進行修改，會出現權限管理數據庫的信息變更甚至權限服務的重新部署。所以這種實現方式適用于訪問權限相對比較固定的場景。

3.2.2 分布式訪問控制

微服務架構下分布式訪問控制的關鍵在于每個服務擁有獨立的訪問控制模塊，如圖7所示。針對瀏覽器或者其他服務發來的請求，通過路由到處理該請求的指定服務，并在服務內部進行權限校驗，來判斷該請求是否有訪問權限。此外，不同的服務可以訪問同一個權限數據庫，從而減輕維護成本。與集中式訪問控制方式對比，分布式權限管理將權限的校驗功能分布在每個功能的服務內部，可以提高權限管理的靈活性。

圖7 分布式訪問控制架構圖

這種方式更適用于服務實例龐雜且權限靈活多變的場景，不同的服務實例維護自己的權限信息，獨立進行訪問控制，在權限不要變更的情況下不會對其他服務產生影響。

3.3 訪問控制流程

微服務架構下信息管理系統完成鑒權過程主要分為用戶身份認證、用戶權限查詢匹配、校驗權限是否合法3個過程，下面詳細介紹項目中的權限校驗過程。

整體的流程如圖8所示: 首先用戶在登錄頁面通過輸入用戶名與密碼組合，如果提交的用戶密碼信息與后臺數據庫存儲的MD5加密過的密碼信息吻合，則視為身份認證通過。接下來授權服務通過計算該用戶角色的權限與用戶權限的并集獲取該用戶的權限信息。UAA服務根據用戶與權限信息生成該用戶Token信息，通過發放Token信息給客戶端從而實現訪問控制。

最后，瀏覽器將Token信息存至本地Cookie中，在下次請求中將Cookie中的Token信息放至HTTP請求的頭部。在鑒權服務獲取到Token信息后，獲取出此用戶的權限信息，并將請求的功能權限與數據信息進行比對，信息一致的請求路由至指定的服務，不一致則向客戶端回復沒有訪問權限。其中集中式權限管理是路由網關服務，分布式訪問控制是具體提供功能的服務。

圖8 權限校驗流程

4 結 語

本文基于微服務架構的信息管理系統改進了RBAC模型，形成了一套用戶鑒權模型MSAM的數據權限的控制，并且增加了服務間權限管理處理，可以滿足對權限管理要求的靈活性與拓展性。