編輯導語：什麼是IAM？可能很多同學都還不太了解這個產品吧。作者在本文中詳細介紹了IAM的定義以及核心功能，供大家在設計賬號體系、許可權體系時有所參考。
有一次，領導對我說：「去對接一下IAM吧，看一下他們能不能滿足我們的需求。」
我表面淡定應對，心裡納悶：「I am是啥？我知道I’m a boy。」
後來逐漸接觸IAM的產品工作，發現IAM不僅是一種產品，也是大部分產品（特別是B端產品、雲產品）中常見的基礎功能。
希望這篇文章可以幫你了解IAM，在設計賬號體系、許可權體系時有所參考。
如有紕漏，歡迎指正。
一、場景
在介紹IAM是什麼之前，請先回想一下你是否遇到過這些場景。
1. 作為員工/用戶
- 多套賬號密碼：在CRM中是老楊/密碼1234，在OA中是小楊/密碼9527，由於賬號過多，經常忘記賬號、密碼，或者乾脆設置同樣的或簡單的密碼。
- 反覆註冊登錄：在不同系統/APP中需要反覆地輸入賬號密碼登錄，或者反覆註冊、申請審批。
2. 作為企業管理員
- 管理員工的賬號/許可權費時費力：無法統一管理員工在公司內不同系統的賬號/許可權，導致員工缺少賬號或擁有過多賬號/許可權；員工入職、轉崗、離職時需要手動開通/收回員工的賬號。
- 無法追蹤員工的行為：員工的活動分散在企業內各個系統中，無法及時發現、統計員工的行為軌跡，制止風險行為。
3. 作為開發者
- 反覆造輪子：針對賬號體系、註冊登錄、第三方登錄、用戶自主服務等常規和基礎的功能需要反覆開發。
- 用戶數據難打通：即使在公司內部，也容易出現不同系統之間賬號體系的設計、口徑不一致的情況，導致系統之間的用戶數據難以打通。
IAM可以很好地解決上述的問題，舉個例子：
老王入職新公司，用企業微信掃碼加入公司，填寫相關資料，加入了後端組。
老王打開電腦，輸入應用門戶的地址，使用賬號密碼或掃碼登錄，在工作台中就可以看到阿里雲、企業微信、Gitlab、禪道、OA等各種平時需要用到的應用。
點擊應用圖標即可自動登錄進入應用，使用已被自動授權的功能。
管理人員可以在管理後台統計員工的登錄情況、使用情況。
二、定義
IAM是 Identity and Access Management 的縮寫，即身份與訪問管理，或稱為身份管理與訪問控制。
IAM主要為了達到一個目的：讓恰當的人或物，有恰當的許可權，訪問恰當的資源。其中「人或物」稱為主體（Subject），「資源」稱為客體（Object）。
傳統的IAM一般包含如下幾部分，常被稱為「4A」或「5A」。
- 賬號（Account）
- 認證（Authentication）
- 許可權（Authorization）
- 應用（Application）
- 審計（Audit）
從使用場景上劃分，IAM主要有有三大類。
1. EIAM
EIAM是 Employee Identity and Access Management 的縮寫，指管理企業內部員工的IAM，主要解決員工使用的便捷性和企業管理的安全性相關問題。
在產品形態上，EIAM有以下特點：
- 需要集成企業的雲應用、本地應用
- 需要集成不同的身份源
- SSO和MFA很常用
- 不同企業所需的訪問控制力度不同
2. CIAM
CIAM是 Customer Identity and Access Management 的縮寫，指管理企業外部客戶/用戶的IAM，主要解決用戶數據的打通和開發成本與標準化相關問題。
在產品形態上，CIAM有以下特點：
- 在用戶端常見到的是單點登錄和授權登錄
- 提供通用的組件給開發者直接使用
- 更強調高性能和高可用
3. 雲廠商IAM
雲廠商的IAM，有時稱為RAM（Resource and Access Management），指管理企業雲資源的IAM，主要用於管理雲資源的訪問控制。
在產品形態上，雲廠商IAM有以下特點：
- 強調授權的靈活性和企業管理的安全性
- 支持多種類型的賬號進行認證或被調用
- 一般只關注管理自家的雲資源
本文主要以較常見的EIAM為例來介紹IAM。
三、賬號（Account）
賬號是用戶在系統中的數字化載體，用於標識用戶並訪問受保護的資源。一般每個系統都會有賬號，且不同系統的賬號數據結構各異。
針對賬號模塊，IAM需要解決如下幾個問題：
- 哪些賬號/欄位代表了用戶？這些賬號散落在哪裡？（身份源）
- 我（IAM）如何將這些賬號拿過來？（上游賬號同步）
- 我（IAM）如何關聯、映射、使用這些賬號數據？（統一身份源）
- 哪些系統需要用到這些賬號？我怎麼把賬號給它們？（下游賬號同步）
1. 子模塊&協議
賬號模塊一般會包含如下子模塊和協議。
（1）子模塊
- 賬號管理：包括賬號的增刪改查、啟用禁用、重置密碼、解鎖賬號等。
- 組織/用戶組管理：用於將用戶和許可權關聯起來，減少分配許可權的操作。
- 賬號生命周期管理：管理員工的入職、升職、調崗、離職等整個生命周期。
- 身份源集成同步：從上游應用中獲取賬號數據，將賬號、欄位進行關聯、映射和轉換，作為用戶唯一標準的數據同步給下游應用。
（2）協議
- AD/LDAP：LDAP（Lightweight Directory Access Protocol，輕型目錄訪問協議），是一種用於維護樹形目錄信息和提供訪問控制的協議，通常所說的AD/LDAP指的是Windows的AD和Linux的OpenLDAP，是一種樹形的資料庫，在企業內部常被用於管理用戶數據和用戶認證。
- SCIM：SCIM（System for Cross-domain Identity Management，跨域身份管理），是一種簡化同步和管理身份數據的協議，常用於公有雲應用。
2. 三戶模型
個人習慣將Account視為「賬號」。本文中「賬號」指的是三戶模型中的「用戶」，「用戶」指的是三戶模型中的「客戶」。
「三戶」的定義下如，供參考：
（1）客戶
指自然人或者法人。法人一般被稱之為企業客戶。如無特指，一般客戶指個人客戶。這個對象的業務主鍵是證件號（如，身份證）
（2）用戶
指通過註冊的方式進入系統，使用系統提供的服務的實體，也稱為登錄賬戶，即用戶在系統中登錄憑證和個人信息。對應的，法人客戶在系統中註冊后，被稱之為商戶。
（3）賬戶
這裡特指支付賬戶，指用戶在支付系統中用於交易的資金所有者權益的憑證。
客戶是體現了社會域的信息，用戶體現了業務域的信息，帳戶體現的是資金域的信息。
四、認證（Authentication）
廣義的認證是一種信用保證形式，指第三方公證機構對組織/個人的身份、能力、資質等的認可。
狹義的認證指的是證明「主體是誰」。IAM中的認證指的是狹義的認證，常見於主體申請訪問資源時。
1. 認證場景
IAM中有三個主要的場景：
- 未認證的主體需要認證——登錄
- 已認證的主體跳轉到其他應用時自動認證——SSO，單點登錄
- 已認證的主體訪問敏感資源時需要二次認證——MFA，多因素認證
2. 認證方式
認證方式是主體證明「我是我」的手段，主要有「所知、所有、所是」三大類認證方式。
（1）所知
主體所知道的信息，比如密碼、密保問題等。
（2）所有
主體所擁有的物品，比如簡訊驗證碼、數字證書、OTP等。
（3）所是
主體所擁有的生物特徵，比如人臉、指紋、簽名等。
認證方式和MFA息息相關，MFA（Multi-Factor Authentication，多因素認證）是指使用兩種以上的認證來進行身份驗證，以提高賬號的安全性。
3. 認證協議
認證協議主要用於在用戶、業務系統、身份認證服務之間傳遞用戶信息，告訴業務系統「此用戶是誰」。
主流的認證協議/實現單點登錄的方案有Cookie、JWT、SAML、CAS、OIDC等，網上有很多資料，暫不贅述。
認證協議通常和單點登錄息息相關，單點登錄（Single Sign On，SSO）是指在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
4. 認證源
認證源指的是用戶在登錄當前系統時，由第三方提供認證服務，系統信任第三方的認證結果。例如使用微信登錄某APP，就是將微信作為認證源。
IAM一般會根據場景提供AD/LDAP、企業微信/釘釘、OA等不同的認證源方案。
五、授權（Authorization）
授權是將權力交付給用戶或機構代為行使，此時使用戶或機構獲得訪問資源的許可權。
1. 「授權」範圍
我們以RBAC模型為例，授權其實要做三件事：
- 將操作和對象（也稱資源）打包為許可權，即圖中的許可權（PRMS，Pemission），包括操作（OPS，Operations）和對象（OBS，Objects）。
- 將許可權分配給主體（狹義的授權），即圖中的Permission Assignment和User Assignment。
- 當主體訪問資源時鑒權，鑒別用戶的身份和判斷許可權。
RBAC模型
2. 許可權分類
許可權其實就是將操作和對象打包起來。根據不同場景、不同要求可以有不同的方案。
個人習慣將許可權分為以下四種，控制的力度和精細度逐漸增加：
（1）應用許可權
控制主體能否訪問某個應用，擁有許可權就可以訪問應用的所有內容，是最粗粒度的訪問控制。
（2）頁面許可權
控制頁面層面的元素是否可見，包括頁面、菜單、按鈕等。做好頁面許可權一般可以滿足企業內部大部分的需求。
（3）操作許可權
控制主體能否執行某個操作，例如可改新增、修改、刪除等，一般和一個介面對應，在主體請求介面時判斷。頁面許可權和操作許可權也被統稱為功能許可權。
（4）數據許可權
控制數據的查詢和展示，不同主體看到的數據不同，包括行許可權和列許可權。如果說功能許可權是控制「能不能」，數據許可權則是控制「有多少」。
3. 許可權模型
談到授權，談得最多的是許可權模型。但需要注意，許可權模型只是對許可權進行分配的思路和方案，解決「如何將某些許可權分配給某些主體」的問題，不是「授權」的全部。
具體使用哪種許可權模型，需要根據場景和需求來定，不要拘泥於許可權模型而忽略實際業務。
下面介紹常見的幾種許可權模型：
- ACL（Access Control Lists，訪問控制列表），通過將主體（用戶或用戶組）直接和許可權（包含操作和資源）關聯成列表，控制主體能訪問哪些資源。
- DAC（Discretionary Access Control，自主訪問控制），可以通過ACL或ACM來實現，特點是擁有許可權的主體可以將自身的許可權賦予給其他主體或收回，常見於操作系統。
- MAC（Mandatory Access Control，強制訪問控制），通過對主體和客體進行安全標記（密級），來判斷主體能否對客體進行相關操作，常見於軍工行業。
- RBAC（Role Based Access Control，基於角色的訪問控制），通過引入「角色」的概念，將主體和許可權之間的關係解耦，是常見、成熟、有效的許可權模型。
- ABAC（Attribute Based Access Control，基於屬性的訪問控制），通過動態計算一個或一組屬性是否滿足某種條件來進行授權判斷，常用於公有雲，不同場景下形態各異。
4. 鑒權
IAM中的「授權模塊」還包括「鑒權」的部分，與「分配許可權」（Assignment，也常稱為授權）相對應。
鑒權是驗證主體是否擁有訪問客體的許可權，完整的鑒權應該包括身份認證和許可權決策兩部分。
大多數情況下完成身份認證即完成了鑒權，這部分屬於「認證」模塊（英語中Authentication也有鑒權的意思）。
但在比較複雜的場景，比如使用ABAC、零信任時，當主體訪問資源時，決策點PDP需要根據屬性或策略規則動態計算主體是否擁有足夠的許可權，並依據計算結果放行或攔截訪問，此部分也應當屬於鑒權。
ABAC策略判斷流程
六、應用
狹義的應用只是業務系統在IAM中的映射，即APP ID和APP Secret。
廣義的應用是上文中賬號、認證、授權的交互對象和載體，一般作為客體來使用。
1. 預集成應用
由於應用之間的規範、協議各有差異，IAM往往會預集成一部分應用，提前對接好其賬號、認證、授權等模塊，方便客戶開箱即用。
針對普通用戶，IAM一般會提供統一的應用門戶（儀錶盤），顯示企業內自己所擁有許可權的所有應用，也可以手動添加自己的應用，方便用戶日常使用。
okta中的用戶儀錶盤
七、審計
審計日誌需要記錄用戶的所有操作，需要記錄主體、操作、客體、類型、時間、地點、結果等內容。
根據不同的維度可以劃分為不同的操作日誌，如操作日誌和登錄/登出日誌、用戶日誌和管理員日誌、業務系統日誌和IAM系統日誌等。
審計相關的功能，不同規模、不同行業要求不同，通常國外比國內更嚴格、更強調合規。
八、結語
本文介紹了IAM的定義和核心功能，更像是一張地圖，希望為你在設計賬號體系、賬號體系時提供一些思路。