編輯導(dǎo)語：什么是IAM？可能很多同學(xué)都還不太了解這個產(chǎn)品吧。作者在本文中詳細(xì)介紹了IAM的定義以及核心功能，供大家在設(shè)計賬號體系、權(quán)限體系時有所參考。

有一次，領(lǐng)導(dǎo)對我說：“去對接一下IAM吧，看一下他們能不能滿足我們的需求?！?/p>

我表面淡定應(yīng)對，心里納悶：“I am是啥？我知道I’m a boy?！?/p>

后來逐漸接觸IAM的產(chǎn)品工作，發(fā)現(xiàn)IAM不僅是一種產(chǎn)品，也是大部分產(chǎn)品（特別是B端產(chǎn)品、云產(chǎn)品）中常見的基礎(chǔ)功能。

希望這篇文章可以幫你了解IAM，在設(shè)計賬號體系、權(quán)限體系時有所參考。

如有紕漏，歡迎指正。

一、場景

在介紹IAM是什么之前，請先回想一下你是否遇到過這些場景。

1. 作為員工/用戶

• 多套賬號密碼：在CRM中是老楊/密碼1234，在OA中是小楊/密碼9527，由于賬號過多，經(jīng)常忘記賬號、密碼，或者干脆設(shè)置同樣的或簡單的密碼。
• 反復(fù)注冊登錄：在不同系統(tǒng)/APP中需要反復(fù)地輸入賬號密碼登錄，或者反復(fù)注冊、申請審批。

2. 作為企業(yè)管理員

• 管理員工的賬號/權(quán)限費時費力：無法統(tǒng)一管理員工在公司內(nèi)不同系統(tǒng)的賬號/權(quán)限，導(dǎo)致員工缺少賬號或擁有過多賬號/權(quán)限；員工入職、轉(zhuǎn)崗、離職時需要手動開通/收回員工的賬號。
• 無法追蹤員工的行為：員工的活動分散在企業(yè)內(nèi)各個系統(tǒng)中，無法及時發(fā)現(xiàn)、統(tǒng)計員工的行為軌跡，制止風(fēng)險行為。

3. 作為開發(fā)者

• 反復(fù)造輪子：針對賬號體系、注冊登錄、第三方登錄、用戶自主服務(wù)等常規(guī)和基礎(chǔ)的功能需要反復(fù)開發(fā)。
• 用戶數(shù)據(jù)難打通：即使在公司內(nèi)部，也容易出現(xiàn)不同系統(tǒng)之間賬號體系的設(shè)計、口徑不一致的情況，導(dǎo)致系統(tǒng)之間的用戶數(shù)據(jù)難以打通。

IAM可以很好地解決上述的問題，舉個例子：

老王入職新公司，用企業(yè)微信掃碼加入公司，填寫相關(guān)資料，加入了后端組。

老王打開電腦，輸入應(yīng)用門戶的地址，使用賬號密碼或掃碼登錄，在工作臺中就可以看到阿里云、企業(yè)微信、Gitlab、禪道、OA等各種平時需要用到的應(yīng)用。

點擊應(yīng)用圖標(biāo)即可自動登錄進(jìn)入應(yīng)用，使用已被自動授權(quán)的功能。

管理人員可以在管理后臺統(tǒng)計員工的登錄情況、使用情況。

二、定義

IAM是 Identity and Access Management 的縮寫，即身份與訪問管理，或稱為身份管理與訪問控制。

IAM主要為了達(dá)到一個目的：讓恰當(dāng)?shù)娜嘶蛭?，有恰?dāng)?shù)臋?quán)限，訪問恰當(dāng)?shù)馁Y源。其中“人或物”稱為主體（Subject），“資源”稱為客體（Object）。

傳統(tǒng)的IAM一般包含如下幾部分，常被稱為“4A”或“5A”。

• 賬號（Account）
• 認(rèn)證（Authentication）
• 權(quán)限（Authorization）
• 應(yīng)用（Application）
• 審計（Audit）

從使用場景上劃分，IAM主要有有三大類。

1. EIAM

EIAM是 Employee Identity and Access Management 的縮寫，指管理企業(yè)內(nèi)部員工的IAM，主要解決員工使用的便捷性和企業(yè)管理的安全性相關(guān)問題。

在產(chǎn)品形態(tài)上，EIAM有以下特點：

• 需要集成企業(yè)的云應(yīng)用、本地應(yīng)用
• 需要集成不同的身份源
• SSO和MFA很常用
• 不同企業(yè)所需的訪問控制力度不同

2. CIAM

CIAM是 Customer Identity and Access Management 的縮寫，指管理企業(yè)外部客戶/用戶的IAM，主要解決用戶數(shù)據(jù)的打通和開發(fā)成本與標(biāo)準(zhǔn)化相關(guān)問題。

在產(chǎn)品形態(tài)上，CIAM有以下特點：

• 在用戶端常見到的是單點登錄和授權(quán)登錄
• 提供通用的組件給開發(fā)者直接使用
• 更強調(diào)高性能和高可用

3. 云廠商IAM

云廠商的IAM，有時稱為RAM（Resource and Access Management），指管理企業(yè)云資源的IAM，主要用于管理云資源的訪問控制。

在產(chǎn)品形態(tài)上，云廠商IAM有以下特點：

• 強調(diào)授權(quán)的靈活性和企業(yè)管理的安全性
• 支持多種類型的賬號進(jìn)行認(rèn)證或被調(diào)用
• 一般只關(guān)注管理自家的云資源

本文主要以較常見的EIAM為例來介紹IAM。

三、賬號（Account）

賬號是用戶在系統(tǒng)中的數(shù)字化載體，用于標(biāo)識用戶并訪問受保護(hù)的資源。一般每個系統(tǒng)都會有賬號，且不同系統(tǒng)的賬號數(shù)據(jù)結(jié)構(gòu)各異。

針對賬號模塊，IAM需要解決如下幾個問題：

• 哪些賬號/字段代表了用戶？這些賬號散落在哪里？（身份源）
• 我（IAM）如何將這些賬號拿過來？（上游賬號同步）
• 我（IAM）如何關(guān)聯(lián)、映射、使用這些賬號數(shù)據(jù)？（統(tǒng)一身份源）
• 哪些系統(tǒng)需要用到這些賬號？我怎么把賬號給它們？（下游賬號同步）

1. 子模塊&協(xié)議

賬號模塊一般會包含如下子模塊和協(xié)議。

（1）子模塊

• 賬號管理：包括賬號的增刪改查、啟用禁用、重置密碼、解鎖賬號等。
• 組織/用戶組管理：用于將用戶和權(quán)限關(guān)聯(lián)起來，減少分配權(quán)限的操作。
• 賬號生命周期管理：管理員工的入職、升職、調(diào)崗、離職等整個生命周期。
• 身份源集成同步：從上游應(yīng)用中獲取賬號數(shù)據(jù)，將賬號、字段進(jìn)行關(guān)聯(lián)、映射和轉(zhuǎn)換，作為用戶唯一標(biāo)準(zhǔn)的數(shù)據(jù)同步給下游應(yīng)用。

（2）協(xié)議

• AD/LDAP：LDAP（Lightweight Directory Access Protocol，輕型目錄訪問協(xié)議），是一種用于維護(hù)樹形目錄信息和提供訪問控制的協(xié)議，通常所說的AD/LDAP指的是Windows的AD和Linux的OpenLDAP，是一種樹形的數(shù)據(jù)庫，在企業(yè)內(nèi)部常被用于管理用戶數(shù)據(jù)和用戶認(rèn)證。
• SCIM：SCIM（System for Cross-domain Identity Management，跨域身份管理），是一種簡化同步和管理身份數(shù)據(jù)的協(xié)議，常用于公有云應(yīng)用。

2. 三戶模型

個人習(xí)慣將Account視為“賬號”。本文中“賬號”指的是三戶模型中的“用戶”，“用戶”指的是三戶模型中的“客戶”。

“三戶”的定義下如，供參考：

（1）客戶

指自然人或者法人。法人一般被稱之為企業(yè)客戶。如無特指，一般客戶指個人客戶。這個對象的業(yè)務(wù)主鍵是證件號（如，身份證）

（2）用戶

指通過注冊的方式進(jìn)入系統(tǒng)，使用系統(tǒng)提供的服務(wù)的實體，也稱為登錄賬戶，即用戶在系統(tǒng)中登錄憑證和個人信息。對應(yīng)的，法人客戶在系統(tǒng)中注冊后，被稱之為商戶。

（3）賬戶

這里特指支付賬戶，指用戶在支付系統(tǒng)中用于交易的資金所有者權(quán)益的憑證。

客戶是體現(xiàn)了社會域的信息，用戶體現(xiàn)了業(yè)務(wù)域的信息，帳戶體現(xiàn)的是資金域的信息。

四、認(rèn)證（Authentication）

廣義的認(rèn)證是一種信用保證形式，指第三方公證機構(gòu)對組織/個人的身份、能力、資質(zhì)等的認(rèn)可。

狹義的認(rèn)證指的是證明“主體是誰”。IAM中的認(rèn)證指的是狹義的認(rèn)證，常見于主體申請訪問資源時。

1. 認(rèn)證場景

IAM中有三個主要的場景：

1. 未認(rèn)證的主體需要認(rèn)證——登錄
2. 已認(rèn)證的主體跳轉(zhuǎn)到其他應(yīng)用時自動認(rèn)證——SSO，單點登錄
3. 已認(rèn)證的主體訪問敏感資源時需要二次認(rèn)證——MFA，多因素認(rèn)證

2. 認(rèn)證方式

認(rèn)證方式是主體證明“我是我”的手段，主要有“所知、所有、所是”三大類認(rèn)證方式。

（1）所知

主體所知道的信息，比如密碼、密保問題等。

（2）所有

主體所擁有的物品，比如短信驗證碼、數(shù)字證書、OTP等。

（3）所是

主體所擁有的生物特征，比如人臉、指紋、簽名等。

認(rèn)證方式和MFA息息相關(guān)，MFA（Multi-Factor Authentication，多因素認(rèn)證）是指使用兩種以上的認(rèn)證來進(jìn)行身份驗證，以提高賬號的安全性。

3. 認(rèn)證協(xié)議

認(rèn)證協(xié)議主要用于在用戶、業(yè)務(wù)系統(tǒng)、身份認(rèn)證服務(wù)之間傳遞用戶信息，告訴業(yè)務(wù)系統(tǒng)“此用戶是誰”。

主流的認(rèn)證協(xié)議/實現(xiàn)單點登錄的方案有Cookie、JWT、SAML、CAS、OIDC等，網(wǎng)上有很多資料，暫不贅述。

認(rèn)證協(xié)議通常和單點登錄息息相關(guān)，單點登錄（Single Sign On，SSO）是指在多個應(yīng)用系統(tǒng)中，用戶只需要登錄一次就可以訪問所有相互信任的應(yīng)用系統(tǒng)。

4. 認(rèn)證源

認(rèn)證源指的是用戶在登錄當(dāng)前系統(tǒng)時，由第三方提供認(rèn)證服務(wù)，系統(tǒng)信任第三方的認(rèn)證結(jié)果。例如使用微信登錄某APP，就是將微信作為認(rèn)證源。

IAM一般會根據(jù)場景提供AD/LDAP、企業(yè)微信/釘釘、OA等不同的認(rèn)證源方案。

五、授權(quán)（Authorization）

授權(quán)是將權(quán)力交付給用戶或機構(gòu)代為行使，此時使用戶或機構(gòu)獲得訪問資源的權(quán)限。

1. “授權(quán)”范圍

我們以RBAC模型為例，授權(quán)其實要做三件事：

1. 將操作和對象（也稱資源）打包為權(quán)限，即圖中的權(quán)限（PRMS，Pemission），包括操作（OPS，Operations）和對象（OBS，Objects）。
2. 將權(quán)限分配給主體（狹義的授權(quán)），即圖中的Permission Assignment和User Assignment。
3. 當(dāng)主體訪問資源時鑒權(quán)，鑒別用戶的身份和判斷權(quán)限。

RBAC模型

2. 權(quán)限分類

權(quán)限其實就是將操作和對象打包起來。根據(jù)不同場景、不同要求可以有不同的方案。

個人習(xí)慣將權(quán)限分為以下四種，控制的力度和精細(xì)度逐漸增加：

（1）應(yīng)用權(quán)限

控制主體能否訪問某個應(yīng)用，擁有權(quán)限就可以訪問應(yīng)用的所有內(nèi)容，是最粗粒度的訪問控制。

（2）頁面權(quán)限

控制頁面層面的元素是否可見，包括頁面、菜單、按鈕等。做好頁面權(quán)限一般可以滿足企業(yè)內(nèi)部大部分的需求。

（3）操作權(quán)限

控制主體能否執(zhí)行某個操作，例如可改新增、修改、刪除等，一般和一個接口對應(yīng)，在主體請求接口時判斷。頁面權(quán)限和操作權(quán)限也被統(tǒng)稱為功能權(quán)限。

（4）數(shù)據(jù)權(quán)限

控制數(shù)據(jù)的查詢和展示，不同主體看到的數(shù)據(jù)不同，包括行權(quán)限和列權(quán)限。如果說功能權(quán)限是控制“能不能”，數(shù)據(jù)權(quán)限則是控制“有多少”。

3. 權(quán)限模型

談到授權(quán)，談得最多的是權(quán)限模型。但需要注意，權(quán)限模型只是對權(quán)限進(jìn)行分配的思路和方案，解決“如何將某些權(quán)限分配給某些主體”的問題，不是“授權(quán)”的全部。

具體使用哪種權(quán)限模型，需要根據(jù)場景和需求來定，不要拘泥于權(quán)限模型而忽略實際業(yè)務(wù)。

下面介紹常見的幾種權(quán)限模型：

• ACL（Access Control Lists，訪問控制列表），通過將主體（用戶或用戶組）直接和權(quán)限（包含操作和資源）關(guān)聯(lián)成列表，控制主體能訪問哪些資源。
• DAC（Discretionary Access Control，自主訪問控制），可以通過ACL或ACM來實現(xiàn)，特點是擁有權(quán)限的主體可以將自身的權(quán)限賦予給其他主體或收回，常見于操作系統(tǒng)。
• MAC（Mandatory Access Control，強制訪問控制），通過對主體和客體進(jìn)行安全標(biāo)記（密級），來判斷主體能否對客體進(jìn)行相關(guān)操作，常見于軍工行業(yè)。
• RBAC（Role Based Access Control，基于角色的訪問控制），通過引入“角色”的概念，將主體和權(quán)限之間的關(guān)系解耦，是常見、成熟、有效的權(quán)限模型。
• ABAC（Attribute Based Access Control，基于屬性的訪問控制），通過動態(tài)計算一個或一組屬性是否滿足某種條件來進(jìn)行授權(quán)判斷，常用于公有云，不同場景下形態(tài)各異。

4. 鑒權(quán)

IAM中的“授權(quán)模塊”還包括“鑒權(quán)”的部分，與“分配權(quán)限”（Assignment，也常稱為授權(quán)）相對應(yīng)。

鑒權(quán)是驗證主體是否擁有訪問客體的權(quán)限，完整的鑒權(quán)應(yīng)該包括身份認(rèn)證和權(quán)限決策兩部分。

大多數(shù)情況下完成身份認(rèn)證即完成了鑒權(quán)，這部分屬于“認(rèn)證”模塊（英語中Authentication也有鑒權(quán)的意思）。

但在比較復(fù)雜的場景，比如使用ABAC、零信任時，當(dāng)主體訪問資源時，決策點PDP需要根據(jù)屬性或策略規(guī)則動態(tài)計算主體是否擁有足夠的權(quán)限，并依據(jù)計算結(jié)果放行或攔截訪問，此部分也應(yīng)當(dāng)屬于鑒權(quán)。

ABAC策略判斷流程

六、應(yīng)用

狹義的應(yīng)用只是業(yè)務(wù)系統(tǒng)在IAM中的映射，即APP ID和APP Secret。

廣義的應(yīng)用是上文中賬號、認(rèn)證、授權(quán)的交互對象和載體，一般作為客體來使用。

1. 預(yù)集成應(yīng)用

由于應(yīng)用之間的規(guī)范、協(xié)議各有差異，IAM往往會預(yù)集成一部分應(yīng)用，提前對接好其賬號、認(rèn)證、授權(quán)等模塊，方便客戶開箱即用。

針對普通用戶，IAM一般會提供統(tǒng)一的應(yīng)用門戶（儀表盤），顯示企業(yè)內(nèi)自己所擁有權(quán)限的所有應(yīng)用，也可以手動添加自己的應(yīng)用，方便用戶日常使用。

okta中的用戶儀表盤

七、審計

審計日志需要記錄用戶的所有操作，需要記錄主體、操作、客體、類型、時間、地點、結(jié)果等內(nèi)容。

根據(jù)不同的維度可以劃分為不同的操作日志，如操作日志和登錄/登出日志、用戶日志和管理員日志、業(yè)務(wù)系統(tǒng)日志和IAM系統(tǒng)日志等。

審計相關(guān)的功能，不同規(guī)模、不同行業(yè)要求不同，通常國外比國內(nèi)更嚴(yán)格、更強調(diào)合規(guī)。

八、結(jié)語

本文介紹了IAM的定義和核心功能，更像是一張地圖，希望為你在設(shè)計賬號體系、賬號體系時提供一些思路。

本文由 @Nix 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議