前言

隨著云計算、大數據等技術在企業大規模的推廣使用，持續集成持續部署的業務交付模式以及移動辦公的接入方式深刻地影響了信息安全建設思路，如何能夠更動態更智能更安全地保護企業的數字資產的同時不損失效率和體驗？Google分享的零信任安全架構實踐的相關論文給我們提供了一個非常好的思路，事實上，全面身份化即對網絡參與的各個實體（人、服務、設備等）在統一的框架下進行全生命周期管理，而構筑全新的身份安全體系是零信任安全架構的基石。分布式設計模式和實踐（如微服務，容器編排和云計算）已經讓我們的生產環境變得越來越動態和異構，我們認為傳統的安全實踐（例如僅僅基于四層網絡控制策略的訪問控制）在這種復雜性下難以擴展，急需一套全新的IAM（身份和訪問控制管理）框架。而云IAM就是能夠支持在萬物互聯背景下的全面身份化以及多租戶、多帳號體系、多用戶渠道、云原生支持等特性的一整套解決方案，這對于將安全防護從網絡層訪問控制升級到應用層動態訪問控制起到至關重要的作用，也將有效助力零信任安全架構的建設。下文將重點講述我們對云IAM的理解、方案設計以及部分重點模塊的解析。

業務發展帶來的安全風險

首先介紹我們的業務背景，因為安全從本質上來說就是為業務服務的。中通目前是國內業務量最大的快遞公司，2017年快遞業務量達到62.2億件，居全球第一，并且已經保持了兩年的行業龍頭地位，今年剛剛過去的雙十一期間的業務量又刷新了記錄。另外，2016年中通登錄美國紐交所，成為了當年IPO規模最大的中概股。目前中通全網有三十多萬員工，網絡合作伙伴9400多個，服務網點將近三萬個，覆蓋了全國絕大部分區縣和鄉鎮。在強勁的快遞主業的帶動下，中通還積極拓展整個電商產業上下游生態鏈的業務，如中通快運、中通云倉、中通國際、中通商業、中通金融、中快傳媒等，并且已經建成了多元發展的集團型企業。

那么在業務如此急速發展的情況下，對我們的IT特別是對信息安全帶來了哪些挑戰和風險呢？第一是需要上線大量各類應用系統，自研的、外購的、本地部署的、公有云部署的等等，對眾多的異構系統如何做好安全管控的集成是非常大的挑戰，另外在大促活動時，如雙十一期間也需要所有安全組件可以水平靈活擴展。第二，從整個集團來看，整體組織架構非常復雜，人員和設備的數量巨大并且變動頻繁，如何做好安全管控也是難題。第三，由于業務的需要，敏感數據需要參與到系統流程中去進行流轉，安全保護的難度直線上升。第四，作為電商業務的重要一環，需要和各個生態合作伙伴進行數據對接，并在開放平臺提供了大量API，安全管控難度較大。那面對這些安全挑戰和風險，有什么比較好的應對方案呢？

解決方案

幸運的是，Google分享的零信任安全架構實踐給我們提供了一個非常好的問題解決思路的參考，可以在很大程度上解決上述問題，經過我們初步研究后發現，IAM平臺是零信任安全架構的核心基礎。圖1中橙色的模塊都可以算作IAM的范疇，如單點登錄、設備庫、用戶和組數據和證書簽發等模塊，甚至接入代理也可以作為訪問控制管理的一個組件。然而傳統的IAM方案已經無法滿足我們的需求，因此打造一個強大靈活的下一代IAM平臺勢在必行。

圖1：零信任安全架構（Google BeyondCorp）及其中的IAM組件

結合我們面臨的實際問題以及零信任安全架構的需求，我們對下一代IAM的設計提出了如下三個目標：

• 全面身份化支持，使用通用安全身份框架SPIFFE，將客觀世界的對象抽象成邏輯上具備不同屬性的身份，如人員、設備、應用、API等，實現支持萬物互聯的身份認證技術，為訪問控制奠定基礎。

• 云原生支持，真正打通本地/云/辦公等網絡邊界，全面從網絡層訪問控制升級為應用層動態智能深度檢測和控制，同時使用容器、微服務、服務網格、服務編排等技術，實現靈活的水平擴展和異構系統互操作支持，以及端到端全鏈路的雙向認證和傳輸加密。

• 復雜組織的支持，針對中通這種具有幾十萬人橫跨多個業務單元、面向不同終端客戶的商業組織，需要滿足跨租戶、跨帳號體系、跨端、跨用戶渠道、跨應用、跨生態的需求，以及應用和身份數據分離的聯邦和多協議的支持，并且能在資源層面對所有操作進行分類分級及自動化審計。

根據以上設計目標，我們的整體設計方案的功能全景視圖見圖2，盡可能地解耦和拆分模塊并作獨立部署，將身份相關基礎數據抽離出來單獨做成身份中心，結合認證中心、權限中心、應用中心、資源中心、證書中心、管理控制臺以及開放API、SDK和APP等構成一套體系，然后可以靈活地與各類應用在不同的層級進行對接。這樣做的好處就是，不管企業的應用部署到哪里，都可以共享一套強大靈活的身份和訪問控制的安全管理基礎設施，解決了異構系統集成安全管控問題以及人員設備、敏感數據和API的安全管控問題。

圖2：云IAM功能全景視圖

云IAM的總體工作流程如圖3所示，首先是用戶和設備的認證流程，通過單點登錄代理將認證請求轉發到對應認證協議的處理模塊，認證處理模塊根據請求上下文連接到對應的身份提供商IDP，經過一系列的交互成功認證后下發訪問token。接下來用戶攜帶相關訪問token發起相關資源的操作請求，在接入代理和接入控制引擎層面會去認證中心校驗token的合法性、拉取授權、鑒權以及相關的風控操作，如果通過校驗滿足訪問控制策略，則提交到相關應用的API執行，當然在返回數據包中還需要進行再次校驗是否滿足安全策略，以及進行相應的審計日志記錄。云IAM平臺本質上是以更靈活及更細粒度的方式來管控資源的操作。傳統的業務流程就是身份實體首先進行身份認證，認證通過后發起資源操作請求，收到操作請求后根據授權信息進行鑒權，通過則放行操作。那我們新的設計大量地參考了aws的設計理念，更靈活及更細粒度是體現在權限模型、授權方式以及API和資源的嚴格定義上。無疑aws老板貝索斯是非常有遠見的，很多年前就定下了服務化的架構原則，要么服務化要么滾蛋。事實上這一點至關重要，如果不能把資源以及操作資源的API定義清晰和有效隔離，那么將無法實現功能強大的權限控制策略。

圖3：云IAM總體工作流程

重點模塊的設計

1.身份空間

我們知道身份是任何安全基礎架構的基本概念，那么把身份相關的操作串聯起來就形成了身份空間，如圖4所示。其中包括身份生命周期的管理，主要是客觀身份實體和邏輯對象的實時映射，如果要能支持萬物互聯的認證需求，那么就需要將除了人員以外的更多的實體納入進來，邏輯對象映射到可操作系統的身份實體，如身份到帳號是個一對多的映射關系，給身份實體賦予了相關權限才能對資源進行操作。這里有一個開源的通用身份認證框架SPIFFE，大家有興趣可以了解和參考它的設計。

圖4：身份空間的設計

2.帳號體系

云IAM平臺需要支持多租戶模式，如圖5所示。每個租戶下面會支持設置多個帳號體系如辦公的、2b和2c的，每個帳號體系下面可以建立各種形式的帳號組如根據組織架構自動建立的、根據角色建立的等，帳號組里實際上會有各類帳號組成如人員身份的、機器人身份的、設備身份的等。

圖5：帳號體系的設計

3.復雜組織架構

根據我們的實際需求，還需要支持集團性質租戶的復雜組織架構，如圖6所示。集團下轄成千上萬的分公司和子公司，公司下面除了掛部門也可以掛公司，同一個帳號可以在不同公司間進行自由切換，同時伴隨部門和角色權限的變換等。值得一提的是，我們還設計了組織架構類型的帳號群組，系統自動創建，除了可以輔助人員入職時自動授權外還可以自動加入內部協作IM工具的溝通群組，幫助業務提升協同辦公效率。

圖6：復雜組織架構

4.系統集成

作為一個云原生設計的IAM平臺，必然需要支持和各類異構系統進行安全訪問控制的集成以及互操作，如圖7所示。第三方應用或者租戶可以很方便地接入IAM平臺，用戶可以無縫使用平臺上的應用，這個場景下IAM平臺通過配置直接使用第三方的身份數據源IDP。對應的，IAM平臺上用戶也可以無縫使用第三方的應用，這時相當于在第三方本地建立了一個IAM上云端的IDP緩存，當然這個集成的過程需要符合一些規范的認證協議和數據同步接口，如OIDC、OAuth2、SAML2、SCIM、REST等。

圖7：支持系統集成的設計

5.授權

在權限模型方面，我們采用RBAC用于粗粒度訪問控制，如控制某一類人可以查看哪些模塊，采用ABAC進行細粒度訪問控制，如控制某個人員對模塊內部的訪問權限。在授權方式上支持更多更加靈活的方式，如基于身份的策略、基于資源的策略、獨立的訪問策略以及設置權限邊界等。一個典型的權限配置過程包括定義資源、定義每個資源操作的API、定義訪問實體、定義角色權限或者訪問策略等。 那么授權的本質是什么呢？主要是回答這個問題：“誰能不能在什么樣的上下文中對什么樣的資源做什么樣的操作”，為此我們設計了一個簡易的自定義DSL來描述這個資源操作請求。如{"appid":"eihxiidhh23s","user":"jack","action":"getArticleID","resource":"resources:articles:zto","context":{"remoteIP":"192.168.0.5","trustScore":“90"}}，其中的trustScore是我們重點設計的元素，放入到上下文中，和零信任架構中的風控引擎以及具體的訪問控制策略結合起來形成一個動態智能的深度鑒權。

 6.微服務安全架構

為了實現整個平臺的靈活擴展和部署，我們參考了ISTIO 微服務架構。ISTIO的安全架構設計得非常漂亮，示意圖也非常清晰，如圖8。首先是內部微服務通過集成證書中心實現了微服務之間的雙向認證和傳輸加密，再結合用戶側的傳輸層加密可以實現端到端全流程的雙向認證及傳輸加密，當然要做到這一點是非常有挑戰的，我們還在努力中。通過控制平面的pilot組件以及服務名稱管理和證書還可以實現各個微服務間的安全隔離和訪問控制，另外pilot結合數據平面的邊車節點也可以實現訪問策略的執行。

圖8：ISTIO微服務安全架構

7.證書簽發、輪換和吊銷

基于傳統PKI，為了匹配性能及擴展性方面的需求，設計了證書中心，主要涉及證書簽發、證書按規則輪換以及證書吊銷三部分的功能，工作流程如圖9。新的終端設備或者新的服務上線，都需要自動提交證書申請到證書服務集群，由證書服務集群代理向CA發起請求，拿到證書后轉發到申請者。證書輪換由證書申請者按照一定的規則自動重復申請流程即可，證書吊銷申請和證書吊銷查詢服務也統一由證書服務集群代理，通過接口實時查詢是否吊銷，實現即時吊銷的功能。

圖9：證書中心工作流程

8.自動化審計

云IAM平臺中另外一個重要的功能點就是安全審計，主要是跟蹤記錄誰在什么時間什么地點以什么樣的方式做了什么，聚焦在及時發現和處理異常。我們在這一塊的創新點在于自動化審計，首先對所有資源進行分類，然后對所有資源和操作對進行分級，最后根據分類分級和權限以及與其它系統集成自動過濾大部分異常，可以節省大量的人工審計工作。安全審計交付物通常有三方面：主動及時匯報和確認異常以推動策略實施及問題解決；確保審計對象得到合理準確的處理和合規；對企業內審計對象進行關聯性分析并得到綜合性的報告。

9.移動端APP

我們的云IAM平臺還設計開發了配套的移動端APP，主要包括了安全認證模塊、IM模塊、應用發布模塊以及工具模塊等，如圖10所示。移動端APP幫助我們得以停用傳統的靜態密碼認證方式，配合進行實人認證以及執行風控校驗的指定動作等，極大地提升了整個平臺的安全性，增加了用戶交互方式同時也優化了用戶體驗。

圖10：移動端APP

總結和展望

目前我們已經落地了部分模塊和功能，如認證中心SSO模塊支持多種認證方式（密碼/短信/TOTP/推送/掃碼/刷臉/會話代理等）；身份中心借助人臉識別、OCR、活體檢測等人工智能技術實現了實人認證功能，可以將人員、證件、帳號以及設備進行綁定；權限中心支持跨應用的集中統一權限管理，目前已經接入了幾百個應用；我們通過IAM和第三方廠家網絡準入軟硬件的對接，實現了精細化的安全訪問控制；可以較好地支持聯邦認證，通過我們的IAM平臺和阿里云郵箱的LDAP進行集成，實現無縫的用戶體驗；平臺可以較好地支持認證互操作，可以分別在釘釘和我們的移動端APP上集成自有應用以及第三方應用。

未來我們將落地更多的模塊及在云IAM平臺上集成更多的安全組件，如零信任安全架構相關的組件以及一些SDL組件或者工具等。另外我們還將積極擁抱開源技術和開源文化，積極采用開源技術并且制定開源計劃回饋社區，未來將逐步開源一些經過我們實踐檢驗過的成熟的安全組件，希望能幫助到有需要的安全團隊。

參考資料：

1.Google的beyondcorp安全解決方案：https://cloud.google.com/beyondcorp/

2. AWS的IAM安全解決方案：https://aws.amazon.com/iam/

3. 通用安全身份框架SPIFFE：https://spiffe.io/

4. 服務網格開源項目ISTIO：https://istio.io/