任何系統(tǒng)都少不了用戶登錄模塊。一個安全、方便的登錄模塊可以成為系統(tǒng)與用戶交互的良好開端。本文結(jié)合筆者的實際工作經(jīng)驗，以及相關(guān)知識的學(xué)習(xí)，旨在對登錄模塊的一般原理和設(shè)計方法進(jìn)行一個系統(tǒng)性的闡述和總結(jié)，希望能夠拋磚引玉，進(jìn)一步深化自己對這一模塊的認(rèn)知。

一、生活中的登錄場景

我們?nèi)粘Ｉ钪幸呀?jīng)習(xí)慣了這樣的場景：訪問一個系統(tǒng)，系統(tǒng)會要求我們輸入用戶名、密碼（或者驗證碼等方式），如果正確，我們就登錄進(jìn)入這個系統(tǒng)了。接著系統(tǒng)會顯示跟我們有關(guān)的信息，比如我們登錄淘寶，就可以看到自己的購物車信息、歷史購物記錄等。

在這個簡單的場景里，登錄模塊做了哪些處理呢？如何確保操作賬號的人是賬號真正的持有人呢？為什么只能看到自己的購物記錄而不能看到別人的呢？要回答這些問題，可以借助4A統(tǒng)一安全管理平臺解決方案這個框架來幫助我們思考。

二、4A安全管理框架——系統(tǒng)安全管理的最佳實踐

在系統(tǒng)構(gòu)成的虛擬世界里，用戶相關(guān)的全部資源都以數(shù)字形式存在。登錄模塊是現(xiàn)實中的人進(jìn)入虛擬世界的“門戶”，其本質(zhì)目的是實現(xiàn)安全管理，讓擁有正確“鑰匙”的人“進(jìn)門”，并阻擋“非法入侵”。1995年，國際網(wǎng)安界最早提出了4A(認(rèn)證Authentication、授權(quán)Authorization、記賬Accounting、審計Audit)的概念，后為國內(nèi)運(yùn)營商所發(fā)展，形成了4A (賬號Account、認(rèn)證Authentication、授權(quán)Authorization、審計Audit)統(tǒng)一安全管理平臺解決方案這一最佳實踐：

1. 賬號

賬號可以看作是我們在這個虛擬世界里的一間房子，房子里放著所有我們在這個虛擬世界的資產(chǎn)，比如“身份證”（個人信息）、“存折”（銀行卡信息）等。我們希望自己在虛擬世界中的資產(chǎn)得到保護(hù)，也希望離開這個虛擬世界后這些資產(chǎn)得到妥善的處置。隨著歐盟的《GDPR》，我國的《數(shù)據(jù)安全法》、《個人信息保護(hù)法》等法規(guī)的出臺，作為系統(tǒng)設(shè)計者，不單要考慮賬號的注冊場景，賬號的刪除場景也同樣重要，一個設(shè)計良好的系統(tǒng)需要有完善的賬號生命周期管理機(jī)制。

2. 認(rèn)證

認(rèn)證是門上的鎖，沒有鎖的門別人是可以自由出入的，有了鎖就可以確保只有我們自己才有鑰匙可以進(jìn)入。鎖的形式多種多樣，比如上面例子中提到的用戶名+密碼。鎖非常關(guān)鍵，很多黑產(chǎn)的攻擊目標(biāo)就是這個環(huán)節(jié)，圍繞認(rèn)證的網(wǎng)絡(luò)安全技術(shù)也在不斷發(fā)展，比如多因素認(rèn)證、登錄加密、異地登錄識別、設(shè)備更換識別、密碼最大錯誤次數(shù)鎖定、自動登出、多端登錄提醒等。

3. 授權(quán)

授權(quán)就是定義每個人的房子里裝哪些數(shù)據(jù)資產(chǎn)，我們的“身份證”不會放在別人房子里，別人的“存折”也不會放在我們的房子里，我們對自己房子里的資產(chǎn)擁有控制權(quán)限。C端場景下，通常用戶的權(quán)限是統(tǒng)一的，有些產(chǎn)品有VIP的設(shè)定，其權(quán)限和普通用戶不同，但也是有限的幾類，因此權(quán)限管理相對簡單。B端系統(tǒng)一般都是為了滿足特定的管理目的而存在，管理職責(zé)因人而異，無法統(tǒng)一，自然權(quán)限管理就相對復(fù)雜。在設(shè)計B端系統(tǒng)前，應(yīng)該先確定關(guān)鍵用戶，了解他們的工作職責(zé)，從而對系統(tǒng)應(yīng)該實現(xiàn)怎樣顆粒度的權(quán)限管理形成認(rèn)知。

4. 審計

審計相當(dāng)于房子里的監(jiān)控裝置。即使鎖再好，也不可避免被攻破，房子里裝了監(jiān)控，我們就可以在一些非法入侵事件發(fā)生之后去查看當(dāng)時的情況，挽回?fù)p失或者避免損失擴(kuò)大。所以我們需要對登錄、密碼修改等敏感操作生成日志，并對這些日志進(jìn)行定期審閱。

通過上面的分析，我們就知道一個系統(tǒng)的登錄模塊需要包含的主要功能就是賬號管理、認(rèn)證管理、權(quán)限管理、日志管理幾部分，下面就來介紹具體如何設(shè)計。

三、登錄模塊的設(shè)計要點(diǎn)

1. 賬號與密碼

設(shè)計賬號表，最關(guān)鍵的問題是主鍵的選擇（就是以什么作為一個賬號的唯一標(biāo)識）。在一個系統(tǒng)內(nèi)，用戶名、郵箱、手機(jī)號都是唯一的，理論上都可以作為主鍵，但實際上并不好用。

假如把用戶名作為主鍵，下游的業(yè)務(wù)數(shù)據(jù)表中可能記錄了用戶名，例如一個電商平臺記錄一筆訂單的創(chuàng)建人為用戶名。這樣的話修改用戶名的場景就難以實現(xiàn)了，因為用戶名一旦更改，用戶將無法找回自己以前創(chuàng)建的訂單。手機(jī)號、郵箱也存在同樣的問題。

更好的做法是系統(tǒng)按照某種規(guī)則自動生成一串唯一字符作為一個賬號的唯一標(biāo)識，即賬號表的主鍵，我們命名為UserId。

由于其沒有任何業(yè)務(wù)意義，不存在修改的場景，因此可以保持穩(wěn)定。用戶名、手機(jī)號、郵箱等信息作為賬號相關(guān)的屬性，變更的場景就容易實現(xiàn)了。同時需要注意，在開發(fā)各類業(yè)務(wù)場景時，當(dāng)需要記錄操作人身份時，應(yīng)該統(tǒng)一使用UserId。

大多數(shù)系統(tǒng)都提供了用戶名+密碼這一登錄方式，管理密碼最主要考慮的是安全問題。密碼不可明文存儲，否則當(dāng)數(shù)據(jù)庫被人惡意訪問時，所有用戶的密碼都會被泄露。解決密碼存儲安全性問題，比較常用的方式是加鹽哈希。

滿足創(chuàng)建賬號、設(shè)置密碼、用戶名+密碼登錄這些基本功能，賬號表至少需要包含以下字段：

注：本文提到的表單字段僅為業(yè)務(wù)邏輯類字段，并非數(shù)據(jù)庫建表實際字段。開發(fā)過程中一般都需要添加代碼邏輯所必須的字段，如邏輯主鍵、創(chuàng)建時間、創(chuàng)建人、更新時間、更新人等，上文提及的加鹽哈希需要額外存儲密碼鹽值，為了保持登錄會話可能需要添加字段保存token等，這些用于技術(shù)實現(xiàn)所必須的字段不在本文的討論范圍內(nèi)。

用戶注冊、密碼登錄流程示例如下：

2. 手機(jī)號/郵箱登錄

對于用戶來說，記憶密碼是不方便的，而且也存在安全隱患。手機(jī)號+驗證碼登錄操作簡單，用戶接受度高，是國內(nèi)普遍采用的注冊、登錄方式。在海外市場中，郵箱+驗證碼也是很常見的。為了實現(xiàn)手機(jī)號/郵箱的綁定/換綁、驗證碼登錄功能，我們需要擴(kuò)展賬號表字段，至少需要添加手機(jī)號、郵箱2個字段：

手機(jī)號/郵箱的綁定/換綁、驗證碼登錄流程基本相同，可以合并表示，具體見下圖：

3. 第三方登錄

為了簡化用戶注冊流程，降低用戶的注冊成本，不少應(yīng)用都提供了第三方登錄方式，國內(nèi)常見的有通過微信、QQ、微博等賬號登錄，海外常見的有通過Google、Facebook、Twitter等賬號登錄。例如下面這個登錄頁，底部提供了3種第三方登錄方式：

第三方登錄使用的主流授權(quán)流程是OAuth，各大第三方平臺的開發(fā)者文檔都有接入方式的詳細(xì)說明。為了實現(xiàn)第三方登錄，我們需要進(jìn)一步擴(kuò)展賬號表字段。考慮到第三方平臺有多個，可能會陸續(xù)接入，為了方便系統(tǒng)擴(kuò)展，應(yīng)該添加第三方平臺類型字段，表示登錄來源。用戶通過第三方平臺登錄后，第三方平臺會返回表示用戶身份的唯一ID，我們需要將這個ID和自建系統(tǒng)的UserId進(jìn)行關(guān)聯(lián)，因此也需要一個字段記錄。具體如下：

由于登錄過程引入了第三方平臺，登錄流程更加復(fù)雜了，可以參考下面這個時序圖來理解整個第三方登錄的過程：

4. 權(quán)限管理

用戶成功登錄系統(tǒng)后，接下來就需要知道這個用戶可以訪問哪些資源、可以執(zhí)行哪些功能。例如在一個組織的HR系統(tǒng)內(nèi)，每個人只能看到本人及下屬的考勤記錄，這就是一種對數(shù)據(jù)的權(quán)限控制；又如系統(tǒng)管理員可以修改員工信息，普通用戶只能查看員工信息，這就是一種對操作的權(quán)限控制。

在訪問控制領(lǐng)域，廣泛采用的權(quán)限模型有RBAC（基于角色的訪問控制）和ABAC（基于屬性的訪問控制），二者也可以結(jié)合使用。RBAC是通過把一組權(quán)限封裝在一個角色中，再把角色授予用戶，以此來實現(xiàn)靈活的權(quán)限控制。

RBAC的優(yōu)點(diǎn)是操作簡單，并能滿足大部分場景下的訪問控制要求。在RBAC模型中，用戶與角色是一對多的關(guān)系。ABAC的控制規(guī)則是建立在一組“屬性”上的。比如可以定義一個規(guī)則，僅允許人力資源部門的員工在9:30至18:30之間查看員工簡歷，“人力資源部的員工”是用戶屬性，“9:30至18:30”是環(huán)境屬性。ABAC的優(yōu)點(diǎn)是具有更多維度的控制變量，從而實現(xiàn)叫RBAC顆粒度更細(xì)的訪問控制，但建立規(guī)則的過程也更加復(fù)雜。

本文以RBAC為例。在RBAC模型中，一個角色內(nèi)包括多個權(quán)限項，一個用戶可以有多個角色，結(jié)構(gòu)如下圖：

我們至少需要增加4張表來表示上述結(jié)構(gòu)：

首先是用戶角色表（user_role），用來表示用戶和角色的關(guān)聯(lián)關(guān)系，通過UserId與賬號表（user_account）進(jìn)行外鍵鏈接，用戶登錄后，可以在此表查找其擁有的角色。

然后是角色權(quán)限表（role_permission），用來表示角色和權(quán)限的關(guān)聯(lián)關(guān)系，通過RoleId與用戶角色表（user_role）進(jìn)行外鍵鏈接，找到用戶擁有的角色后，可以在此表查找這些角色內(nèi)包含的權(quán)限。

另外還需要角色表（role_info）和權(quán)限表（permission_info），用于記錄角色和權(quán)限的基本信息。

整體的數(shù)據(jù)結(jié)構(gòu)如下：

5. 日志

在內(nèi)部控制領(lǐng)域，控制分為預(yù)防性控制、檢查性控制、糾正性控制3類。賬號管理、認(rèn)證管理、權(quán)限管理都屬于預(yù)防性控制，即通過事先建立這些機(jī)制，可以保護(hù)用戶數(shù)字資產(chǎn)的安全。而日志管理則是一種檢查性控制，是一種事后的控制。當(dāng)我們需要排查、診斷系統(tǒng)問題，追溯入侵事件時，有日志的幫助，可以大大提高分析效率。

對于登錄模塊，最基礎(chǔ)的日志需要記錄賬號、登錄時間、登錄IP、登錄設(shè)備等信息。登錄后的操作日志，則需要根據(jù)不同的業(yè)務(wù)場景設(shè)計。為了平衡成本和收益，通常需要對敏感操作生成日志，而不是事無巨細(xì)地記錄。比如某個表單中含有關(guān)鍵的數(shù)據(jù)，可以對這個表單中的新增、刪除、編輯操作生成日志，編輯類操作還可以進(jìn)一步記錄編輯前、編輯后的信息。

6. 延伸思考

一般情況下，用戶注冊賬號之后，系統(tǒng)還需要收集用戶個人信息，例如頭像、性別、生日、興趣愛好、從事的行業(yè)、教育背景等，這些信息是否適合記錄在賬號表中呢？出于系統(tǒng)擴(kuò)展性考慮以及解耦的思想，筆者認(rèn)為另建一個用戶信息表存儲這些信息更好，雖然它和賬號表是一對一的關(guān)系。賬號表只負(fù)責(zé)賬號、登錄、認(rèn)證功能。當(dāng)然這個問題沒有標(biāo)準(zhǔn)答案，合理即可。