以下四個用例是數據存儲體系常見的應用模式,但絕不是僅有的用例。
1. 存儲和運用數據
用戶希望將數據存儲在安全的方位,但不希望存儲服務供給商能夠看到他存儲的任何數據,也就是說只要用戶自己能夠看到并運用數據。
2. 查找數據
跟著時間的推移,用戶將會存儲很多數據。用戶需求查找數據,但不希望服務供給商知道用戶要存儲或查找的內容。
3. 與一個或多個實體同享數據
用戶一般會和其它人或服務等多個實體同享其數據。在第一次保存數據時,或在今后的運用過程中,用戶能夠決議頒發其它實體拜訪其存儲區中數據的權限。只要在該用戶明確贊同的情況下,他的存儲空間和數據才答應別人拜訪。
用戶希望能夠隨時撤消他人的拜訪權限,且在同享數據時,能夠設置第三方拜訪其數據的有效期限。
4. 將同一數據存儲在多個地方
用戶需求體系具備跨多個存儲方位備份其數據的能力,以防數據丟掉。這些方位能夠由不同的存儲供給商托管,而且能夠通過不同的協議拜訪。這些方位或許是用戶的手機,也或許是云存儲。別的,這些方位應該能夠互相同步。因而,無論用戶怎么創立或更新數據,這些方位上的數據都是最新的,而且能夠在不需求用戶幫忙的情況下自動進行同步。
二、需求分析
從上述四個中心用例中,咱們能夠提取出對存儲體系的一些需求。
1. 隱私和多方加密
該體系的主要方針之一是保證實體數據的隱私,以防未經授權的人(包含存儲供給商)拜訪該數據。
為此,有必要在數據(通過網絡)傳輸和(在存儲體系上)保存時對數據進行加密。
因為數據能夠與多個實體同享,因而加密機制還有必要支撐將加密數據同享給多方,答應多方拜訪。
2. 同享與授權
該體系有必要供給一種授權機制,以答應在一個或多個實體之間同享加密信息。
在體系中,能夠指定一種強制性授權計劃,也可有其它替代性授權計劃。這些授權計劃包含 OAuth2.0、Web 拜訪操控和 ZCAPs 等。
3. 身份標識
該體系應與身份標識無關。通常來說,URN 或 URL 方法的標識符是首選。假定體系要以某種方法運用去中心化身份(DID),但以硬編碼完成 DID 不是一種很好的模式。
4. 版別辦理和副本
一般來說,咱們希望體系能夠連續備份信息。基于該原因,體系需支撐至少一個強制性的版別辦理戰略和一個強制性的副本戰略,一起還答應其他版別辦理和副本戰略。
5. 元數據和查找
體系一般會存儲很多數據,用戶需求能對數據進行高效且可選擇性的檢索。為此,加密查找機制是體系的必要功用。
關于客戶端來說,重要的是能夠將元數據與數據相關聯,以便能夠對數據進行查找。一起,因為數據和元數據的隱私性需求得到保證,因而元數據有必要加密存儲。別的,服務供給商有必要能夠以不透明且保護隱私的方法執行那些查找,而不能查看元數據。
6. 通訊協議
因為該體系需求能夠和各種業務環境兼容,因而有必要至少強制運用一種通信協議。但有一點也很重要,規劃也應答應體系運用其它協議,如HTTP、gRPC、藍牙和其它一些在線協議。
三、規劃方針
本節詳細介紹了建造加密數據倉庫的一些指導準則和規劃方針。
1. 分層和模塊化架構
運用分層架構方法,能夠保證體系根底功用非常簡單完成,一起答應將更雜亂的功用層疊加在較低層之上。
例如,體系第1層或許包含一些強制性的最基本功用;第2層或許包含對大多數部署來說非常有用的功用;而第3層或許包含一小部分生態項目所需的高級功用;到了第4層,或許會包含極其雜亂的功用,而這些功用只要很小一部分生態項目需求。
2. 優先考慮隱私問題
加密數據倉庫的建造首先要保護實體的隱私。在探究完成新功用時,請始終將對隱私的影響納入考慮。對隱私發生負面影響的新功用將通過嚴格審查,以確認新功用是否值得完成。
3. 將完成雜亂性推給客戶端
體系服務器應聚焦于加密數據存儲和檢索功用的完成。服務器對數據了解得越多,存儲數據的實體面臨的隱私風險就越大,一起服務供給商就會對托管數據負有更多的職責。將雜亂性推給客戶端能夠使服務供給商供給穩定的服務器端完成,而客戶端也可進行一些創新。
