賬號安全無小事，近些年持續不斷爆出的安全事件，有很多低級錯誤其實都是擁有一個健壯的賬號體系可以避免的；多次聽聞後曾寫一寫賬號安全相關的東西，但直到這一次才真正動筆，我將試着從整體上進行梳理，說說賬號安全是怎麼一回事，既算是對自己的一次小結，也算是分享的淺薄的認知。

一、你的賬號安全嗎？

對於這個問題，我們還是先來回顧一下這一個個活生生的例子：

※ 2018年3月，華住旗下酒店（漢庭、桔子、全季、宜必思）1.3億入住信息泄露，看似一起程序員泄露密碼引起的血案，實則是賬號體系的不健全導致。對於如此敏感的操作，假如有更多樣的用戶認證手段（密碼+token，密碼+短信），也許就能避免；又或者有更完善的權限控制體系（限制用戶能訪問的區域），也許不至於泄露如此多的數據......

※ 2017年3月，網爆淘寶電商出售“58同城簡歷數據”，因其多個接口沒做好權限控制，被組合後拉取走批量用戶信息；或許因某種特殊原因，部分接口需要放寬權限；但做好敏感接口的監控，是不是可以及時發現並減少被拉取的數據量......

........

歷史總是用慘痛的經歷讓我們明白一些道理，假如擁有一個健全的賬號安全體系，許許多多的安全事故或許就不會發生、或者泄露的數據沒那麼多，影響沒那麼大。

那麼，怎樣的賬號體系才相對比較安全呢？

二、設計一個相對安全的賬號體系

以我的有限的經歷來看，假如我是賬號的使用者，當我在訪問某個系統時，一個安全的賬號體系，至少需要解決三個問題，即：

解決了這三個問題，我的一舉一動系統就都能掌握，也能夠控制。首先，只有知道我是誰，才能確定我能做什麼；其次，限制我能做什麼不能做什麼，是從根本上去除安全隱患；最後，一個系統不可能是完美的，即使設計完美，實現上也可能會有偏差，而瞭解我在做什麼，是確認現有策略是否有效，是一個查漏補缺的措施。

這三個問題，用計算機的術語來說，可以表述成三個A，即

那麼，如何實現這三個A呢？我們分別來看下：

三、認證 -- 我是誰

1、認證解決了什麼問題

認證所要解決的問題，正是“我是誰”的問題，或者說是確認用戶的身份。

只有確認用戶身份後，才能根據用戶的身份確認其能否訪問某個域或某個服務。而認證的過程就是“如何證明你媽就是你媽”的過程。

那麼，我們要怎麼對用戶做認證呢，這還得從認證的發展史說起。

2、認證發展的三個階段

用戶認證的方式多種多樣，從其演變過程來看，大致上可以分爲三類，即

2.1、What you know -- 我知道A的某些私密信息，證明我是A

（1）靜態密碼類

上面這種密碼認證的方式，相信大家再熟悉不過了，而這也是最傳統的用戶身份認證方式，通過擁有我的正確密碼，就確認訪問者就是我。相似的方法，還有如下圖我們常見的安全問題等固定密碼類問題。

這類驗證方式從PC時代QQ經常被盜就突顯出其安全性的不足，既依賴於用戶對私密信息的保護，一旦泄露，即可被冒充；另一方面，也依賴於用戶私密信息的複雜度，太過簡單或常見，容易被字典攻擊破解；還要求用戶多個密碼不能相同，否則一個泄露，其他的也將被撞庫擊破。

總之，過分依賴用戶安全意識的系統，絕不是一個安全的賬號系統。

（2）動態密碼類問題

這類問題的答案雖然是變化的，但其歸根到底，還是通過我知道什麼，而證明我是誰；例如，以下兩個場景

A、到中國移動換SIM卡，客戶要求我提供最近三次和誰通話的記錄

B、登錄淘寶時，曾經彈框要求我選擇最近購買的東西，或我的常用收貨地址

這種方式，要求用戶填寫是在考驗用戶記性和耐心，易用性極差；提供選項讓用戶選擇時，被蒙對的概率又比較大，作爲輔助驗證方式還好，作爲主要驗證方式則安全性極差，且泄露用戶隱私的風險容易被忽視，在國內用戶隱私保護意識還比較差，可能還行得通，在歐美估計就呵呵了。

2.2、What you have -- 我擁有A的某個關鍵東西，證明我是A

這種認證方式比較常見，且越來越多樣化，從遠古時代的密碼卡，到時下最流行的手機短信驗證碼都屬於這種，從當下來說，用戶比較熟悉的有如下三種認證方式:

機短信驗證，是移動互聯網時代最流行的驗證方式，也是實名制大方針下，採用最普遍的驗證方式；其通過將驗證碼發送到我的手機，再通過反饋回來的短信驗證碼來確認訪問者就是我，其背後的假設就是誰擁有我的手機，誰就是我。

在手機短信驗證方式流行之前，郵箱註冊的方式比較普遍，時至今日，還有很多的系統通過郵箱進行驗證，如GitHub等，郵箱驗證的方式也有兩種，一種是發送激活鏈接、另一種是發送郵箱驗證碼，其表現形式不同，但判斷的邏輯都是一樣的，即誰擁有我的郵箱，誰就是我。

再來說說token，其實有軟硬token之分，一個依賴於硬件，一個依賴於軟件，硬token通過和我的身份做一對一綁定，實現直接關聯，而軟token則通過其他認證方式確認我的身份後，將我和該軟件做了綁定，間接的打通了軟token和我的身份關聯；但其原理都是一樣的，將計算好的token信息在我的關聯設備上展示，誰擁有這個token信息，即可證明誰是我。

......

這類認證方式，雖然表現形式多種多樣，但其和第一類的問題類似，需要用戶保護好擁有的東西，手機/郵箱被盜、借用、偷用等都可以冒用身份。

2.3、Who you are -- 通過提取我的生物特徵，證明我是A

隨着科技的發展，生物認證的方式得以越來越普及，用戶認證的方式也變得越來也豐富，常見的生物認證方式包括但不限於以下幾種：

指紋和人臉，技術相對比較成熟（指紋發展更早，變化更少，相對更成熟），現在已經有越來越多的應用在使用這兩種認證方式，指紋解鎖、人臉開門/考勤大家應該見怪不怪了；而聲紋和虹膜，目前應該還不夠成熟，應用的場景不多，更多見於影視劇作品中；DNA則更多地受限於應用成本高昂。

生物認證的方式，不要求訪問者提供信息，而是從訪問者身上採集信息，通過對訪問者信息的分析，以及和存儲用戶信息的比對，假定訪問者就是相似度最高且滿足設定閥值的已有用戶。

順便提一下，目前，在國內，關於用戶身份生物認證方案這塊，應用比較多的，就是阿里引領的IFAA聯盟方案，已經微信開源的SOTER騰訊生物認證平臺。

但生物認證相對前兩張方式，用戶不需要保存什麼信息，似乎更安全；但生物認證大部分本身就不是一個百分百確認的問題，而是一個相識度判斷的問題，帶來了一定的不確定性，需要結合其他信息進行確認才能說更安全。其作爲單一認證方式進行大規模的應用還顯得任重而道遠。

3、認證應該怎麼做

科技發展到今天，依然找不到一種完美的認證方式。但並不代表就沒有好的解決方案，我們能做的依然可以有很多；至少，我們可以通過以下兩種方式提供更安全的用戶認證方式：

3.1、多因子認證

多因子認證，顧名思義就是採用兩種及以上的方式對用戶的身份進行認證；其背後的邏輯是用戶同時泄露兩種及以上的私密信息，相對於泄露一種來說，其概率要小得多，故同時驗證多種信息的安全度更高，且採用認證的方式越多，賬號的安全性相對來說越高。

但認證方式不是越多越好，其對立面是用戶的體驗將變得更差；所以，還是那句話，具體情況具體分析，如果一種方式足矣滿足需求，那就沒必要使用多因子認證方式；在多因子認證裏，爲了取得安全性和用戶體驗的平衡，一般採用兩種即可；在多因子認證裏，設備也常常作爲一種隱藏的輔助認證信息，用於提高用戶的體驗。

如在常用設備上，可採用“設備+密碼”或“設備+指紋”進行認證，對用戶來說，感受到的是隻有一種認證方式；而在非常用設備上，則可採用“密碼+短信”的認證方式，雖驗證兩次，但頻率較低，用戶體驗不會有太大損失。

3.2、多級認證

多級認證是指在一個系統中，當用戶訪問部分敏感的域服務時，對用戶進行二次及以上的用戶身份認證；可採用不同的用戶身份認證方式，也可採用同一種認證方式，但採用密碼時，一般要求設置成不同的密碼，才能進行有效的防護。

其背後的邏輯，是設置多重保護後，即使上一層的認證被欺騙通過，本次認證也被欺騙通過的難度要相對更大一些，所以，可以更好的保護用戶更重要的信息或資產不被盜用，減少用戶損失，提升賬號安全性。

舉個大家可能遇到的場景，當我登錄京東時，首先要進行身份認證（密碼/短信等），而當我準備買單使用京東里的財產（如京券、京豆）時，需要輸入我的支付密碼才能使用我的資產；這裏使用資產相對於選購物品等操作更爲敏感，所以，使用了二次密碼，可以更好的保護我的資產。

四、授權 -- 我能做什麼

1、授權解決了什麼問題

前面的認證解決了用戶身份的問題，從而使得系統可以區分不同的用戶，對於不同的用戶使其能訪問不同的服務，而要做到這一點不是你定一個規則讓用戶去遵循，靠用戶的自覺性去實現在網絡時間裏顯然是行不通的，必須有一套明確的權限控制策略；而授權要實現的正是“我允許你做什麼你才能做什麼，我禁止你做什麼你就不能做什麼”的能力，具體來說，就是實現以下三點：

2、幾種常見的權限控制策略

常見的權限控制策略，有三種

2.1、OBAC--基於對象的訪問控制

OBAC，全稱Object-based Access Control，是從受限資源的角度出發，對系統中的訪問主體和受控對象進行一維的權限管理。

採用OBAC模型的權限控制策略，常見的有兩種

（1）DAC: Discretionary Access Control 自主訪問控制

這種策略比較簡單，就是每個資源都有一個可以訪問它的用戶列表（ACL），當用戶訪問這個資源時，檢查一下用戶是否在列表中，不在則拒絕其訪問。

優點：可以滿足各類用戶訪問各種資源的需求。

缺點：權限控制分散，無法將大批資源同時賦予某個用戶訪問權限；也無法進行集中管理。

（2）Mandatory Access Control 強制訪問控制

這種策略的實現方式是，管理員創建一組Level，將每個資源綁定一個Level，每個用戶也綁定特定的level，每個用戶只能訪問所綁定level及其以下的level的資源，不能訪問高於綁定level的資源。

優點：權限集中管理，維護簡單。

缺點：用戶需要訪問更高級別level的某個資源時無法完美解決，因爲提高level後，無法控制其不訪問其他的level。

2.2、RBAC--基於角色的訪問控制

RBAC，全稱Role-based Access Control，是從用戶的角度出發，將不同資源的訪問權限分配給不同的角色，再將不同的用戶通過扮演不同的角色，獲取不同的權限。

這種權限控制一般需要對用戶角色進行分級管理，比較經典的是三級權限管理體系，即

（1）超級管理員：可以分配模塊管理員角色及其對應的權限

（2）模塊管理員：可以分配該模塊下的普通角色及其對應的權限

（3）各類普通角色：每種角色只擁有有限的訪問權限

適用場景：

A、用戶並非資源所有者，但需要訪問該資源

B、訪問控制基於職責（對應角色）而非誰是資源所有者

缺點：管理員的需要維護用戶和角色的關係，資源和角色的關係；當用戶數量龐大或資源數量龐大時，需要不停的增刪不同角色的不同權限，或者變更不同用戶的不同角色，運維任務將變得十分繁重。

2.3、ABAC--基於屬性的訪問控制

ABAC，全稱Attribute-Based Access Control，是通過主體屬性、客體屬性、環境屬性等三重屬性作爲授權的基礎實現訪問控制，可以實現複雜場景的權限控制，各種屬性舉例如下：

（1）主體屬性：身份、角色、職位等

（2）客體屬性：數據、文件、服務等

（3）環境屬性：時間、操作、狀態等

優點：通過調整主體、客體、環境三個屬性，實現不同粒度的權限控制

缺點：由於權限不夠直觀，規則複雜且多時，維護起來非常麻煩。

3、什麼樣的權限控制策略是好的策略

首先，權限控制的策略多樣多化，沒有絕對的好與壞之分；不同的應用場景，不同的安全需求，需要選擇不同的策略或多種策略的組合，一句話，滿足需求即可，不必過分追求。

如果沒有特定應用場景要求的話，以我淺薄的經歷來看，一個好的權限控制策略，至少需要滿足兩個原則。

最小權限原則（最早由 Saltzer 和 Schroeder 提出），是指每個程序和系統用戶都應該具有完成任務所必需的最小權限集合。

職責分離原則，是指不能將利益相關的兩個職位分配給同一個人，用運動場上的話說，就是你不能既當裁判員又當運動員！

五、審計 -- 我在做什麼

1、審計要解決什麼問題

審計更多時候是作爲一種安全的能力存在，不止服務於賬號體系，也服務於系統的方方面面，但一個較爲完善的賬號體系，又離不開審計帶來的安全能力的完善。

審計是一個連續不斷改進提高的過程。一方面，需要評估現行的安全策略、機制是否有效；另一方面也是對系統進行全盤的監控。從賬戶的角度出發，其要解決的問題，包括但不限於以下三類：

從實現形式上來看，大致分爲兩類，一類是實時的在線審計，另一類是事後的離線審計。

2、實時在線審計

實時審計就是對當前的會話進行實時監控，並對惡意請求進行實時攔截或告警，常見的方式包括但不限於以下幾種：

（1）各類黑庫過濾

黑IP庫、黑手機庫、黑IMEI庫、黑設備庫等等，只要是在黑庫中的請求，即可進行直接攔截或重點監控。

（2）聚集分析

賬號(UIN/手機號/郵箱/戶口所在地等)聚集、IP聚集（IP聚集/IP頻繁變更/區域聚集等）、設備(IMEI/GUID/MAC地址)聚集、時間段聚集等，只要有易於往常的明顯聚集出現，即惡意攻擊的可能性大大增加，可進行告警，人工介入分析；更嚴重的情況，也可進行攔截。

（3）波動分析

對來自某個業務的請求過大時，可進行限流限頻，防止其可能遭受的惡意攻擊影響到其他業務正常運行。

對訪問量大幅波動的情況，進行告警，人工介入，查看是否正常。

對訪問量超過閥值的情況，進行告警，人工介入，查看是否正常。

3、事後離線審計

事後分析既是一種補救的措施，也是一種補充的措施，相對於實時在線審計，離線審計可以在更大的時間範圍，做和實時審計相同或不同的分析，從而發現在線審計發現不了的問題，常見的方式包括但不限於以下幾種：

（1）構建各類黑庫

用更大量的數據去確認線上的可疑對象是否真的是惡意請求，從而建立起更準確的各類黑庫，反饋到線上，用於線上實時打擊。

（2）構建用戶畫像

除了直接拉入黑庫外，對其餘用戶進行歸類分析處理，以便後續對可疑用戶進行重點關注；對安全用戶減少關注，但仍需定時審計，以便更合理的利用計算機資源。

（3）改善系統安全

對於已發生的安全事件，可通過審計日誌，回溯事件，確認問題所在，用於改善系統安全能力。

六、小結

保護用戶的賬號安全，需要在背後做很多的工作；很多細節都來不及展開（後續有機會再寫），泛泛而談就已經寫了這麼多；賬號安全相關的知識肯定也不止我寫的這些，能力有限就寫到這吧。

最後，彙總一下前面提到的點，小結一下，如下圖：

七、後話

需要說明的是，本文探討的是怎樣構建一個相對安全的賬號體系；並不是說，所有的系統都要做到這種安全級別，對於一個沒有重要信息或資產，安全性要求也不高的系統，做下簡單認證，驗下登錄態足矣，浪費過多的資源，爲其搭建一個龐大複雜的賬號體系，反而是拿着牛刀來殺雞；還是那句話，滿足需求即可。

同樣地，做到這種安全級別也是不夠的，只能說，在當下相對安全而已；隨着科技的發展，安全手段在不斷增強；未知的安全威脅也在不斷增加，讓我們一起努力爲用戶構建一個更安全的賬號體系吧。

最後的最後，引用下電影《我是誰：沒有絕對安全的系統》的一句話給自己以及賬號安全體系的設計者們：

如何構建一個相對安全的賬號體系？