上篇我們提到了更多的是IAM是一項系統工程，需要具備完善的基礎實現才能滿足企業完整的管理訴求。而分析三家海外企業也只是停留在更加表層的功能層面。
本篇我們將延續上篇云IAM實踐的話題，對比和分析國內BAT的實踐和對比。從而嘗試總結出云IAM的通用特征和設計邏輯，并回答開篇提到的幾個問題。
國內BAT三家云IAM的實踐對比和分析賬號系統關于是否需要有自身云賬號的路線差異
阿里云和騰訊云都有自身的賬號系統，而百度云沒有。
阿里以電商平臺、支付平臺為依托，淘寶賬號、支付寶賬號，包括B2B的1688，近些年崛起的釘釘賬號等都是較強賬號系統，且在阿里云OneID后拉通。雖然有這么多強賬號系統，阿里還是獨立設計了阿里云自身的賬號體系，雖然從頁面風格和提示看，推斷很可能是復用了淘寶賬號的框架，但其本質的獨立性依然存在，其他賬號對云賬號而言都是內部的“第三方登錄”。阿里云的登錄入口一開始是阿里云自身賬號的登錄密碼，于去年的新版默認改成了支付寶和釘釘的掃碼登錄，可以看出阿里主推支付寶、釘釘賬號的目標。(為確保不影響習慣使用阿里云賬號的老用戶，還專門在瀏覽器層面做了記住上一次登錄方式的體驗設計，從這一小點就可以看出阿里云對用戶體驗的重視度)
騰訊云也有自身的賬號系統，但是主推的還是微信賬號，社交場景下的流量之王，為國內用戶的導流和登錄都提供了極大的登錄便利性。其賬號系統的結構還是以騰訊云本身的賬號系統為依托，把微信/企業微信/QQ/微信公眾號當作是第三方登錄的賬號，但注冊和使用騰訊云賬號本身反而作為了其他賬號存在，其推廣微信/企業微信的目的非常明確。
三家中最「奇怪」的模型當屬百度了，百度云沒有自身的賬號體系，而是同時借助了百度已有的兩套：分別是ToC的百度賬號，和ToB的商業賬號。模型上一個百度云的賬戶只能二選一綁定其中一個，與阿里云和騰訊云的做法有很大的差別，這個模型帶來的典型問題就是，用戶在不知道自己登錄的什么賬號時(對于百度賬號或是百度商業賬號這樣的弱賬號系統，用戶在使用時很難區分)，很容易犯錯。百度云同時也不支持來自任何其他第三方賬號的登錄，這點也是常被用戶詬病的點。至于為什么會形成這樣雙賬號又不想關、不支持三方登錄的原因，自覺另開一個篇幅專門做解析和介紹。
“強”“弱”賬號系統
賬號對一個系統而言既是至關重要的模塊，又是一個無關痛癢的模塊。賬號是用戶體驗系統的第一環節，好的賬號系統可以讓用戶從注冊到注銷的過程都無比流暢，不受困擾，但與此同時，用戶也很難把它作為一個重要的產品感知，因為在絕大多數場景下，賬號提供的只是基礎服務，而不直接解決用戶的問題。
在云計算行業中，賬號系統的強弱對解決客戶問題來說沒有必然的影響，更多的是用戶體驗上的差異，而且，對于企業用戶而言，賬號系統的安全合規性，遠大于賬號的使用體驗。
就BAT三家云而言，上一節已經就其是否有自身的賬號系統，以及登錄賬號與云賬戶的關系模型進行了闡述。這一節，我想探討的是同樣使用了消費互聯網時代誕生的賬號系統，這三家的賬號系統強弱如何？以及什么是一個“強”賬號系統，什么是“弱”賬號系統？是什么決定了賬號系統的強弱？賬號系統的強弱影響了什么？
在電商、移動支付和社交的場景下，用戶登錄賬號是必要的一步，而在搜索場景下，連接用戶和信息的搜索引擎，是無法強制用戶去登錄賬號的，這也是我會把淘寶、支付寶、微信等賬號稱為強賬號系統，而百度賬號稱為弱賬號系統的原因：場景決定了賬號系統的強弱。
賬號系統的強弱，直接影響了登錄用戶對云計算的第一道體驗，尤其是對于中小企業的使用，賬號的個人屬性大于企業的角色，更偏向于使用公共的已有賬號去管理自己的云資源。反觀更注重安全和合規性的大企業，則更看重企業級的賬號系統，以規避公共賬號帶來的個人屬性和風險。
賬號系統的本質是連接。這幾年以來，釘釘和企業微信以席卷之勢幾乎橫掃了中國市場，伴隨著大量企業使用這兩個企業級的IM工具，其賬號自然也成了日常辦公的必選項，用其連接云計算，自然是最好的選擇。以阿里為例，阿里云近期發布的“云釘一體”的戰略，下連阿里云的基礎設施，上承客戶的各種應用，而其中釘釘賬號與云賬號的連接扮演了最基礎也是客戶體驗最關鍵的一環。自此，阿里云使用淘寶和支付寶賬號連接了廣大的個人開發者，使用釘釘賬號連接了企業用戶，在個人市場，騰訊使用微信完成了億萬人與人之間的連接，在企業市場，阿里正在完成企業用戶與基礎設施、企業用戶與應用之間的連接。
云IAM的Copy to China
國內云計算訪問控制的特色也是延續互聯網一貫套路：Copy to China。從阿里云開始，看其訪問控制的功能和模型，妥妥就是國內的AWS IAM，這是換了個名字叫RAM。跟進的騰訊云和百度云，名字換成了CAM、多用戶訪問控制，特性和模型上卻是換湯不換藥，就連“權限策略”“角色”這類概念都是照搬不誤，最多也就是產品表現層的不同，使用互聯網擅長的漂亮UI進行了重新包裝。
拋開批評這種全盤的“復制”的表層行為，我們去看下更深層次的原因以及復制的好處，作為行業鼻祖的AWS，事實上把自己做成了云計算行業的事實標準，其產品和實踐都是經歷過實際客戶和項目考驗的，在一個全新的行業領域，學習頭部的策略既安全且高效，這也是互聯網的通常套路：先復制，再創新。復制的另一個好處是低遷移成本，產品大神俞軍定義過一個用戶價值公式：「用戶價值 = 新體驗 – 舊體驗 – 遷移成本」。放到云IAM的場景下來看，假如一個客戶原來使用的AWS，現在因為國產化替代的原因，需要遷移到國內的阿里云，新體驗和舊體驗基本一致，在表現層阿里體驗比AWS可能更好一些，因為功能框架基本一致，在遷移成本這一項基本為零，遷移動作本身是個大動作，尤其是對于企業云基礎設施的更換，能夠在遷移中讓用戶價值大于零，就是一個成功的產品，所以復制有時候并不見得是全是壞事。
從云IAM推及整個行業，在互聯網領域的應用創新能力，中國當得上是全球第一，但在更偏向企業軟件服務的云計算行業而言，想要達到海外企業的創新力，國內的互聯網公司還有不小的差距。曾經一位AWS資深架構師對我們說過：AWS從來不看競品，只關注客戶本身。除了“后不見來者”的客觀因素和企業文化的影響，也反應了海外科技巨頭同國內科技企業理念上的巨大區別：圍繞客戶價值，企業在不斷地尋求差異化。所以AWS、Azure、GCP為代表的云IAM各具特色，而國內的三家都更像是AWS的小徒弟。國內整體企業服務環境的不成熟，也是導致了我們只能走先學習，再創新的曲線道路。
沒學全的地方
AWS的權限粒度定義之精細，整個云計算行業沒有一家可以企及。國內的云服務權限基本都只有只讀、完全控制2種，當然這個本身也不全是云IAM的原因，IAM作為基礎平臺提供是平臺化的接入能力，和規范的權限定義標準，具體服務的權限控制粒度需要服務本身抽象和定義，細粒度的權限涉及服務接口的改造，工作量不小，所以也常常是先粗放后精細的模式，若無客戶需求驅動精細的管理云計算 身份認證與訪問控制技術，業務團隊也不愿意投入去做這方面的改造。
授權的可視化(權限編輯器)，國內僅百度云一家可以與AWS的能力匹配。云計算本身服務的主要用戶(注意購買服務的“客戶”與實際使用服務的“用戶”區別)往往是企業內IT人員，往往具備一定的技術能力，所以AWS IAM一開始僅支持使用權限策略語法(基于XACML規范定義的JSON文本)來做IAM用戶的訪問控制，而在國內，大多數企業的IT用戶更愿意可視化地去配置權限，而不是按照廠商定義的語法規則去書寫權限策略，所以AWS后來也支持了權限編輯器的模式，而國內阿里云在可視化授權這塊功能上，僅有幾個常用的產品提供了支持，騰訊云則是所有服務都不支持可視化，只有百度云一家支持全量云服務的可視化授權操作。
AWS的策略分析器。因為ABAC策略描述方式和存儲的限制，不像RBAC，ABAC往往很難列舉出一個用戶擁有的所有服務的權限范圍，同時，隨著用戶策略疊加的因素，哪些策略被使用，那些未被使用，需要得到管控以符合最小權限原則。AWS的策略分析器用于解決以上問題，而國內的幾家都沒有跟進。細粒度的權限管控和用戶的便捷性是沖突的，所以國內企業還未在權限粒度上有所要求，也許這也是國內和海外企業的區別所在。
本土化創新
“先復制，后創新”是國內互聯網最擅長，本節將介紹BAT三家在學習完AWS后云計算 身份認證與訪問控制技術，本土化創新的部分。
阿里云的OAuth應用管理。通過OAuth 2.0協議，把阿里云RAM用戶體系可作為企業應用的統一認證源，推測這個功能僅用于滿足少量大客戶的專屬場景。在賬號體系中，也是高頻打低頻，誰更常用則更適合做統一的認證源。就云計算本身，開發者直接使用云控制臺的頻率是不高的，雖然阿里的這種做法有悖常理，但也不失為一類問題的解決方案。
阿里云和百度云的用戶聯合登錄。在聯合登錄這件事上，業界標準是通過SAML 2.0的方式來實現，企業級的軟件系統往往都有提供。在AWS的實踐中，聯合登錄當前僅以更安全的角色身份來做SP的映射，而阿里云和百度云在此基礎上，擴展了對其用戶的聯合登錄，而百度云做的更徹底的是，將此能力進一步擴展到了企業組織的跨賬戶層級上，以更加靈活地結構和方式來支持企業級的聯合登錄。
AWS開創了云計算的先河，同時也基本形成了云計算行業中的事實標準，后來者除了學習模仿外，對國內企業服務市場做本土化的持續服務和創新，是云廠商當前也是未來應當做的。在IAM這樣一個成熟領域范疇內創新是很難的，僅有的本土化創新都是難能可貴。國內外的企業發展差距無法在短時間內彌補，但我堅信，在不久的將來，國內的云計算行業也必然會走出一條屬于自己的道路。就像互聯網誕生于海外，卻在中國土地上大放異彩，國人的應用創新和模式創新能力之強是我們的底氣所在。
云IAM的最佳實踐探討
結合上下篇的分析，我們可以嘗試去總結出對于云IAM最佳實踐的高價設計，按照身份管理和訪問控制兩大類來闡述。
身份管理
云IAM需擁有自身的賬號系統
正如從傳統IT時代走過來的微軟、互聯網時代的阿里/騰訊，賬號體系設計的最佳實踐，云計算行業與其他軟件的并無不同，可以參考其他賬號系統設計類的文章。集成企業已有賬號系統作為第三方登錄，以保持自身賬號的獨立性和可擴展性，可以省去不少后期用戶理解和協作的困難。如果原企業擁有面向廣大C端用戶的“強”賬號體系，建議直接引導客戶使用強賬號系統注冊和登錄。
考慮身份多樣性需求，設計多種用戶類型
主賬號、普通賬號、臨時角色、服務賬號、聯合登錄(外部用戶)、消息接收人、用戶組等，根據不同的賬號場景需求設計不同的用戶類型，但需要注意的是，設計時考慮“奧卡姆剃刀”，如無必要，不要過度設計，以免用戶難以理解什么時候應該使用什么賬號。
提供更多種類的MFA，讓用戶選擇平衡其安全性和便捷性
MFA是保障賬號和數據安全的最佳實踐之一，而短信、手機OTP軟件目前已經成為了各大云廠商的MFA標配，海外客戶、國內外金融行業對于安全合規要求較高，在手機之外，通常還會有硬件MFA的需求，而且安全是采購一個云廠商的底線。因此，云IAM需要充分考慮擴展MFA的多樣性，為客戶提供更豐富和更加安全的選項。
如有條件和能力，提供自適應的身份驗證能力
云賬戶內的訪問行為通常會以日志形式沉淀，輔助以用戶的環境屬性(設備、IP、時間等)，足夠用于進行訪問行為風險性的分析，有能力的云廠商可以結合機器學習的能力，訓練用戶的行為風險模型，對每次用戶訪問行為進行風險評分，結合多種類和安全層次的MFA，實現自適應的身份驗證。這塊能力比較依賴云上的集中日志服務，如果沒有這么一個服務，如需去收集分散在各服務的訪問日志，會是一件非常麻煩的事。
訪問控制選擇擴展性更高的ABAC模型
對于云服務的授權模型選擇模型，靈活和擴展性更高的ABAC較經典的RBAC更加合適。盡管ABAC在實現和用戶理解上都有一定的門檻，但對計劃為云上大量多類型服務提供訪問控制的廠商而言，在設計之初便需要考慮未來的權限擴展性。
權限策略的描述方式參考XACML，成熟行業跟隨行業標準設計產品，新興行業摸著石頭過河，也是應有之義。
結合資源管理服務，定義并利用資源層級結構的繼承/互斥等特性，為客戶提供更加靈活和強大的訪問控制服務
AWS、Azure、GCP三家都有其資源的集中管理服務，通過集中收攏用戶和API對云上資源的訪問，也很容易實現對用戶進行集中的訪問控制，對于資源層級結構的組織和利用，也只是能力擴展的問題。資源的樹狀層級結構，通常用于匹配企業內的組織架構，實現分部門、分項目、分團隊的資源權限劃分，人員權限隔離等。而對于員工上下級的權限關系，則可通過繼承/互斥等機制的設計來滿足。因此，希望加強對面向云資源的訪問控制管理，集中的資源管理器不可或缺。
云IAM的未來
在《The Top IAM In 2020》中，給出了未來IAM的幾個趨勢，新興技術相關涵蓋了分布式身份(DID)、更加模塊化/靈活的認證方式(保障安全的前提下盡量減少用戶的不安全感)、無密碼&FIDO2&生物認證等在B2C場景中的應用趨勢、JIT、PIM特權管理范圍的擴展、自助化的行業IAM等。云IAM亦可在其中找到自身的發展方向。
總結
本篇是云計算中的身份管理與訪問控制(IAM)的結束篇，在本篇中主要對比了國內BAT所提供的云IAM服務的實踐和分析，并根據上下篇的國內外云IAM實踐，探討和總結了云IAM的最佳實踐高價設計以及云IAM的未來發展趨勢。
正如上篇提到的，在領域內的定義中，更多的把IAM定義為一種技術框架，而本文則是站在產品的角度，嘗試對云IAM進行重新定義：
一種用于滿足安全身份管理、資源訪問控制的機制和服務。文中并未涉及任何具體實現層面的探討，一方面是作者是產品從業者，非技術出身的水平限制，另一方面，限于本職原因，對于產品的具體實現也不便公開。讀到此處的朋友如有興趣，可以私信交流。
作者聲明：IAM是個很小眾的領域，也是一個專業性很強的領域，由于作者本人的水平所限，文中所屬難免有理解不夠深刻和疏漏之處，歡迎各位更資深的朋友給出批評和指正。
參考[1][1]%E7%94%A8%E6%88%B7%E4%BD%93%E9%AA%8C%E7%9A%84%E8%A6%81%E7%B4%A0/?=%E7%94%A8%E6%88%B7%E4%BD%93%E9%AA%8C%E8%A6%81%E7%B4%A0&=[2][4][5]%E5%A5%A5%E5%8D%A1%E5%A7%86%E5%89%83%E5%88%80[6][7]+Top+++IAM+In+2020/-/E-