■ 南開大學 梁爾民

如今幾乎每個云應用都要求用戶注冊或認證，用以保證區(qū)別于其他用戶，這是確保用戶能夠保存應用中所做工作內(nèi)容的必要選項。

但是，云應用要求用戶認證還因為HTTP協(xié)議是一種無狀態(tài)的協(xié)議，所以Web應用就必須構建一種機制來維持其狀態(tài)，這種機制可以使用戶的會話與正在使用該應用的其他任何人相互分離。

云身份管理對于安全從業(yè)者來說有兩方面需要重視。

首先，幾乎每個應用都需要管理云中的身份，應用程序必須跟蹤用戶是誰，并且能夠授權、認證用戶，還要能夠安全地區(qū)分每一個不同用戶；其次，云身份管理很重要，如果對其漠不關心，將帶來嚴重的后果。

由于這兩個動因，近年來出現(xiàn)了大量的與認證有關的安全問題，有很多例子讓我們歷歷在目。幸運的是，如今高校有很多選擇可以減輕云身份管理和安全威脅。

云身份管理的“認證即服務”

如今，受益于相關技術工具和服務的發(fā)展，可以緩解某些云中的身份管理問題。這些工具和服務將作為服務的動態(tài)屬性應用到用戶身份管理中，而這些挑戰(zhàn)也應用到計算和應用的其它方面。不管是被稱為“身份即服務”還是所謂的“認證即服務”，其觀念都是一樣的：為高校或其他單位部署相關應用的外部服務供應商承擔著認證和注冊用戶的責任，并且還要管理用戶的信息。

為了更易于進行云身份管理，這些服務使用了諸如SAML（安全斷言標記語言）等經(jīng)過實踐檢驗的有效標準。這就可以使應用程序?qū)嵤C制留給供應商來編寫。

SAML是一種支持安全聲明的標準，其實質(zhì)是一種包含關于用戶認證狀態(tài)信息的XML數(shù)據(jù)結構。從歷史上看，SAML被用于支持諸如單點登錄的應用程序。SAML可以使一方聲明為另一方，例如，為委托人（通常為一個用戶）提供驗證的一家服務提供商。服務提供商可以解析這種安全聲明，并且可以確保用戶可以在其它地點認證，因而無需重復認證。

OAuth是IETF（互聯(lián)網(wǎng)工程任務組）維護的一個開放標準，它一般通過REST API支持授權數(shù)據(jù)交換。OAuth可以實現(xiàn)由一方創(chuàng)建而由另一方解釋的訪問令牌，通常使用HTTP Secure作為數(shù)據(jù)交換通道，由此就可以實現(xiàn)在兩個無狀態(tài)組件之間交換認證狀態(tài)的信息。

外包云身份管理的好處

將賬戶管理的細節(jié)委派給服務供應商，意味著公司不再在應用程序中跟蹤記錄相關數(shù)據(jù)，其安全上的好處是將高校管理員從跟蹤口令的職責中解放出來。高校還可以更輕松地支持多重認證，并且可以享受一種益處：將身份交由專家們進行更好的分析。

將云身份管理進行外包還有開發(fā)上的好處。首先，開發(fā)人員可以編寫更少的代碼，這就給了開發(fā)人員更多的時間，有利于更快地部署未來的應用擴展或是新的應用服務。

外包云身份的管理還可以給用戶帶來便利，當然，這要依賴于具體的使用情況。例如，如果高校用的是用戶們與之有關系的身份供應商，那么，供應商可以允許用戶用現(xiàn)有的賬戶和憑據(jù)登錄。當然，主要的問題在于有可能發(fā)生單點失效：如果服務提供商“宕機”或無法訪問，誰還能登錄進入應用呢？

云身份管理的實施應考慮哪些問題

通過“認證即服務”或“身份即服務”等方式實現(xiàn)云身份管理的好處，無論對于安全從業(yè)者還是開發(fā)人員都是非常明顯的。那么，該如何實施呢？在評估“認證即服務”時，我們需要考慮幾個因素：

重要的是要記住“認證即服務”的使用背景。高校領導層應當確認是否現(xiàn)在或?qū)硇枰c已有的應用相集成，還要確認已有的用戶賬戶，如活動目錄，是否需要與SSO系統(tǒng)集成。

雖然這種建議看起來并不具有重要意義，但很多高校并沒有為這些專門的應用情形找到理由，將其放在一個把多種產(chǎn)品整合在一起的地位，或者有一種更為糟糕的情況，就是購買了多種擁有相同功能的冗余產(chǎn)品。借助外包的身份管理，如果高校用戶需要與非REST應用（例如本地的桌面或中間件）實現(xiàn)集成，那么對于包括SAML、OAuth或OpenID Connect在內(nèi)的各種集成選項的訪問可能有不少益處。

其次，要考慮云或本地實施的組織問題。例如，如果高校需要與一個面向外部的Web應用整合在一起，云的實施還是有優(yōu)勢的，這是由于本地的基礎架構并不會成為單點故障。也就是說，如果有一個現(xiàn)有的本地用戶存儲或目錄，高校就要理解有些外部應用（那些并不駐留在公司基礎架構中的應用）的需要，從而獲得對實施過程的訪問以發(fā)揮功能。

最后，高校必須關注功能，用以支持所需要的認證類型和現(xiàn)有的用戶賬戶目錄。例如，最好要根據(jù)具體情境和使用情況，增加第二級或是第三級的認證因子，如令牌或生物特征。要認真考慮賬戶信息整合到什么地方，并且要考慮這種整合可能面臨的挑戰(zhàn)。

例如，活動目錄的標準方法是非常容易整合的，這種做法與那些為現(xiàn)有應用程序定制開發(fā)的用戶數(shù)據(jù)庫完全相反。

高校用戶應和以往一樣，在與供應商合作之前，要進行需求收集、架構規(guī)劃以及與整合有關的詳細調(diào)查。從長遠來看，這會給高校節(jié)省大量的寶貴時間。