如何做好統一身份認證賬號管理及整合？

統一身份認證是整個 IT 架構的最基本的組成部分，而賬號則是實現統一身份認證的基礎。做好賬號的規劃和設計直接決定著企業整個資訊系統建設的便利與難易程度，決定著能否敏捷和快速賦能，決定著數字化轉型的投入和效率。

使用者賬號是使用者身份的一種表示。傳統統一身份認證系統往往作為外圍系統來整合各個應用系統，而不是作為核心基礎系統被其他應用系統來整合。所以傳統統一身份認證系統的建設存在眾多的問題，使設計實現複雜化，管理複雜化，整合複雜化。

我們今天將詳細討論下統一身份認證賬號設計的幾個相關問題：

一、 賬號基礎資料來源及管理

賬號( Account )是統一身份認證系統中 4A 管理中的一個要素。賬號資料來源於哪裡是建設統一身份認證平臺時首先要確認的問題。賬號通常可以簡單分為內部員工賬號和外部客戶 / 使用者賬號。內部賬號也可能包括工勤賬號、外包賬號、合作伙伴賬號等。外部客戶 / 使用者賬號則通常是業務客戶或使用者的賬號。內部和外部賬號通常是兩個領域的賬號管理需求，需要分別進行處理。因此統一身份認證平臺需要支援“多租戶”能力，以區分不同領域賬號管理或安全隔離要求。

內部賬號通常可以基於公司的 AD 或人力資源系統賬號為基礎，構建統一賬號管理能力。外部賬號則可以基於 CRM 系統賬號為基礎構建外部使用者統一賬號認證管理能力。在統一身份認證平臺內，表示使用者身份的賬號一定是唯一的。公司內部賬號往往是基於 AD 或 LDAP 的，統一身份認證平臺的賬號體系一旦建立起來，就可以替換掉 AD 或 LDAP ，不用再去整合 AD 或 LDAP 。身份認證賬號一定是處於最底層的，其他系統都要基於賬號體系來構建登入認證的。

由於系統建設不可能一步到位，所以可能存在很多系統還是基於 AD 或 LDAP 進行賬號管理的，這就需要統一身份認證平臺提供臨時中間層，支援 LDAP 整合介面，以替換那些用到 AD 或 LDAP 的系統的配置。

賬號和使用者是兩個獨立的物件。賬號在統一身份認證平臺來維護，而使用者則往往在人力資源管理系統維護。在統一身份認證平臺內部，賬號可以關聯多種身份標識，以支援不同的認證方式或多因子認證。而人力資源管理系統等應用系統，則按照系統整合統一身份認證平臺的方式來實現。

二、 使用者管理

賬號管理可以很簡單，不包含使用者其他資訊，只代表某個使用者的身份。就像人的身份證號一樣。不過使用者的資訊通常是很多的，比如姓名、年齡等基本資訊，還有教育背景、工作經歷、社會關係、培訓經歷、榮譽證書等資訊。這些資訊通常在人力資源系統裡面進行維護管理。從平臺融合微服務架構設計來說，統一身份認證平臺可以不需要考慮使用者資訊的管理和維護。使用者管理可以單獨成為一個獨立的元件模組或微服務元件，可以放在人力資源系統、 CRM 系統等來維護。透過使用者賬號和使用者資訊關聯起來，先在統一身份認證平臺建立賬號，然後其他應用使用這個賬號進行資料結構、資料表設計和實現管理。

所有的使用者在統一身份認證平臺首先要根據規則生成賬號，比如員工賬號、外包賬號、供應商賬號等，然後賬號作為外來鍵來關聯使用者其他相關資訊。

(一) 賬號、使用者和使用者身份標識

使用者管理一定要首先為使用者建立賬號。存量系統中使用者都有賬號 /ID 標識，但由於每個系統每個應用都是一套獨立的賬號體系，形成資料孤島，帶來眾多的資料治理和資料使用問題，因此，透過構建統一的賬號體系來解決這些問題，減少重複建設，提升數字化效率。為使用者建立賬號後併為使用者繫結該賬號，則使用者就可以使用該賬號來標識自己的身份。賬號是使用者身份的一種標識。在統一身份認證平臺中，還會儲存其它使用者身份標識，比如人臉識別影像資訊用於人臉識別認證，指紋資訊用於指紋認證，虹膜資訊用於虹膜認證，手機號用於簡訊驗證碼認證等。這些身份標識都可以唯一標識一個使用者。

(二) 賬號和身份繫結

賬號可以是獨立的，使用者是獨立的物件，但使用者身份是和使用者相關聯的。首先要把賬號分配給使用者，然後採集使用者身份標識資訊，比如指紋、人臉、手機號等，把賬號和使用者身份標識對應起來，從而提供了統一的身份認證能力。使用者可以選擇登入認證方式來認證登入。

三、 應用系統賬號整合

每個應用系統幾乎都有一套自己的賬號、許可權體系。而且 IT 這麼多年的建設，每家公司都有大大小小几十套上百套系統。所以賬號、許可權、日誌等可能就重複建設了幾十次上百次。要建設統一身份認證體系，不得不整合這些大大小小的系統。那麼該怎麼整合?

我瞭解到的幾乎都是把資料複製一份匯入到統一認證平臺。可能大家都習慣了資料導來導去，但這是我最反對的，最深惡痛絕的。那麼多資料孤島、資料不一致、資料混亂等問題就是這樣造成的。很多人往往為了一時的便利根本不考慮其他，後期你不得不付出數倍數十倍的代價來解決這個問題。就像說句謊言，你不得不用十句百句來圓謊。

在討論正確的處理方法之前，我們需要明確在建設統一身份認證平臺時許可權分層的問題。認識並理解使用者訪問許可權的層級是認證體系建設的關鍵之一。

(一) 許可權分層

首先統一身份認證平臺使用者登入後，看到的是他能訪問的應用系統列表，比如一個人可以訪問 OA 、 CRM ，另外一個人可以訪問 OA 、 HR 系統。這是第一層的許可權訪問控制。

其次，使用者進入特定的應用系統之後，有操作不同應用功能的許可權。比如一個人能訪問 OA 系統的報表功能，另外一個人可以訪問 OA 系統除報表外的其他功能。不同的人在某個應用系統中的角色是不一樣的，角色對應的許可權也就不一樣了。

(二) 新上線應用

對於新研發上線的應用，在研發之初就要使用統一身份認證平臺的賬號和許可權體系，透過統一身份認證平臺提供的標準化介面來整合。這樣，所有的應用最終將融合為一個系統，每個應用相當於一個當前系統的一個元件模組。

(三) 存量應用系統

統一身份認證平臺的賬號首先解決的是使用者登入認證的問題。登入之後訪問存量系統時，由於賬號可能存在不一致，這就需要在統一身份認證平臺內支援賬號對映能力，自動轉換為可訪問系統的內部賬號。這樣不用更改存量系統，只實現統一身份認證和單點登入能力。

四、 賬號管理問題

在建設統一身份認證平臺時，我們不得不面對公共賬號、多賬號、賬號委託等問題。比如郵件系統的公共賬號、多賬號問題，業務系統的賬號委託問題等，這些問題都可以結合授權機制來處理。

(一) 賬號委託問題處理

在傳統的應用系統中經常會遇到賬號委託的問題，從身份認證和審計的角度來說是不合理的。賬號委託是把賬號直接賦予某個人來使用這個賬號，就像我可以拿著你的身份證去辦理一些事情，是以你的身份來辦理的，所以可能其他人並不知道是我操作的，從審計角度來說，就是你的行為，而不是我的行為。所以這是有問題的。

正確的做法是透過授權管理機制來實現。你可以把你的許可權授權給我，我就有許可權操作你能操作的業務功能。從審計角度來看，這是我的行為，也可以看到你授權給我了，所以我能代表你來做這些業務，如果有什麼意外或不正確，可以透過審計記錄很容易定位到操作人。

功能實現並不難，難在思想和思維。一說要改變這些不正確的設計，很多人就會有很多藉口，要麼推託業務要求，要麼推託改起來太複雜等等，其實也就是不願意改，怕改出問題。這樣就要求在數字化轉型提升應用效率的時候需要有全域性規劃、頂層設計，透過開發人員自覺來完善幾乎是不可能的。

(二) 公共賬號問題

郵件系統等會涉及群組賬號，比如以某個部門或者團隊來發布通知。但必須明白，公共賬號是不可以透過統一身份認證來登入的。公共賬號只和某個應用系統相關，是特定的需求，有特定的適用範圍，超過了這個範圍就是無效的。因此公共賬號在統一認證平臺是不儲存的。如果某些應用用到公共賬號，則可以在這些應用中來建立和維護，作為某個人的附屬賬號透過授權機制來進行管理和維護。也就是公共賬號可以在這個應用系統內部授權給某個人來使用，一旦超出了這個應用系統範圍則是無效的;同時也可以在需要的時候回收許可權。

(三) 多賬號問題

既然有公共賬號，難免就需要有人來維護或代表這些公共賬號處理一些事情。但就像前面我們討論的公共賬號問題，一定是有範圍限定的。在統一身份認證平臺內，一個使用者的賬號是唯一的。只有具體到某個應用系統內，才會有多賬號問題，多賬號也就只限定在這個應用系統內。在統一身份認證平臺內部賬號對映管理時，可為該應用系統對映多個“內部賬號”(或可稱為“二級賬號”)，使用者訪問該應用系統時則可選擇用哪個“內部賬號”登入。

(四) 管理賬號/運維賬號問題

應用初始管理賬號和運維賬號也是需要考慮的。通常我們設定應用系統初始 admin 賬號，用 admin 來初始化應用系統。一旦透過角色許可權設定管理員使用者， admin 賬號就需要被停用。在統一身份認證平臺，是不能對映使用者到應用 admin 賬號的， Admin 只是做初始化。後期的管理和運維都要用統一身份認證平臺的賬號，對應到具體的有身份的人。這樣才符合認證審計的要求。

很多人不理解建設統一身份認證平臺的初衷，僅僅把它當作一個系統實現單點登入、雙因子認證等，更沒有認真考慮賬號管理等問題，而忽略了其潛在的價值。就像我們前面提到的，統一身份認證平臺是實現平臺融合的最基礎元件，只有設計好整個賬號體系，才能為後續的應用建設帶來敏捷和效率。