層級化安全正在衰亡 分層數字化身份與深度身份是未來
責編：gltian ｜2018-09-28 13:20:09在過去，有句話叫作：“層級化安全”的安全模式幫助公司企業規劃如何保護公司所有觸點的安全，每一層抵御一種威脅。然后，層次化安全進化到更為全面的“深度防御”，其深層哲學思想在于：整體縱覽比各部分累加更好。這是個不錯的模型，數字身份領域或許也可以復制一把。
身份數據分層是什么？
“身份”這個詞容易喚起一種情感上的反應。因為身份指向的就是我們本身。但數字身份的實際使用卻并非真就是關于個人本身的。數字身份代表的是某人在網上做某事(隨用例不同有時候也涉及線下的事)；在消費領域就是人和數據。身份本身沒有問題，是我們呈現數據以完成任務的方式有問題。如今，這一可能代表著個人可識別信息(PII)的某些或很多方面的數據，最好就是遵從“有必要知悉”原則加以使用。從這個前提出發，便是開啟了將隱私當做職權范圍的設計過程。
總得有渠道供人用數據完成任務或者對數據進行操作，“身份分層”的思想由此產生。這一架構性概念是讓消費級身份訪問管理(IAM)不僅僅是個市場營銷工具的關鍵。
身份數據分層能讓PII在用戶的控制下按一系列規則流轉。
身份生態系統有哪幾層？
不妨以類比的方式闡述“層次化身份數據”的概念。電網以提供變壓和切換的層次化網絡，在不同電力資源與消費者間實現匹配。這種網絡可按需轉換或傳輸正確的電力類型(高壓、低壓、交流、直流)。
消費者身份與訪問管理(CIAM)系統中的數據往往要經過復雜的通路，流經不同的服務，在每個服務中完成不同的工作——同樣需要匹配，就像電網一樣。個人數據可以以類似的方式流經由多層組件構成的生態系統，其中每個組件都提供不同的條件、各異的用例且與一系列服務交互。但是，與電網不同的是，人類，尤其是熟悉互聯網的消費者，需要數據處理方式的高度靈活性和真正絕佳的用戶體驗。也就是說，CIAM要有在用戶職權范圍內的不同服務間無縫流轉數據的能力。
目前公認的數據共享型身份生態系統設計方法，是通過平臺架構來構建，必須提供身份才可以響應依賴方的需求。比如，“告訴我你的年齡，我才可以根據我這版的 SAML 2 協議決定能不能給你一杯威士忌?！币驗榧s束過多，這種平臺架構的功能相當有限。想要對此類系統做出變動調整也非常困難。添加額外的依賴方需要非常的聯合及業務模式。甚至修改/添加新通信協議這種事，都能把事情變得一團糟。這種方法需要打破重組，而救星就是分層。
身份數據分層就是將數據置于問題的核心。這里的“層”賦予了系統改變的途徑。你所擁有的不再是硬連接的服務，而是自由流動的管道結構，數據能動態流經系統各個組件。
四條規則
分層的目的，在于能夠在需要的時候抽取身份數據服務生態系統中的東西，能創造性地靈活運用技術而不受平臺的限制。
設計層次化身份數據系統需要遵循幾條基本規則，參考如下。
1. 不可知論
有時候要求列表中的“必須”就是真的是“必須符合”。但使用某方面不可知的工具，比如數據庫類型不定的工具，或者有多種協議選項的工具，可以令你與時俱進，隨時根據情況做出調整。系統中盡可能多點兒不可知，你的生態系統才不會很快過時，你才有多種選擇可供使用。技術發展越來越快，為適應更靈活的協議或更健壯的身份驗證方法而從頭設計實現一套系統，是迫不得已的情況下才會去做的事。
2. API主導
打造靈活生態系統的關鍵必備條件，是使用不可知程度高的API。能填補空白的API可助你打造身份數據管道層。用API方法構建這些系統，能獲得設計面向未來的數據服務所需的靈活性。
3. 以用戶為中心
GDPR之類數據隱私立法的核心思想之一就是以用戶為中心，若在安全設計中應用這種思想，便能更好地連接各個安全層。用戶自然清楚自己想要對自己的數據做些什么，他們只是需要一種層次化的方法來方便自己實施這些數據操作。
4. 規則與限制
設計自由流動的無縫身份數據生態系統很好，但若沒有在恰當的地方應用合適的規則和限制，那這種設計必定胎死腹中，毫無應用價值。在各層上施加控制可以確保你能應用各種安全及隱私控制措施。
團隊協作
以層次化方法設計身份生態系統，并不意味著不能擁有類似“數據存儲”之類的關鍵組件，反而能讓你自由暢想這些組件的各種創新性應用方式。你的“數據存儲”會變成“數據管道”，不必拘泥于存儲功能，而是充當驅動各實體間數據流的中間人。
整個系統就像一個真正的生態系統那樣協同運作，不再單單是各部分的疊加——各個組件間松散耦合，在系統規則和用戶控制下協同工作。為構建“個人數據驅動引擎”，我們需得讓系統像精細調諧的團隊一樣運行，每個成員組件都是整體拼圖中深度整合卻又靈活自由的一塊。