深入了解Geo Key Manager v2：重構分布式系統(tǒng)的訪問控制

2022年12月，我們宣布推出新版Geo Key Manager封閉測試。我們希望幫助客戶安全、靈活地按地理位置控制私鑰分發(fā)，Geo Key Manager v2(GeoV2)便是我們?yōu)榇送瞥龅牡谝淮a(chǎn)品。第一版系統(tǒng)（即Geo Key Manager v1）是在2017年作為一個研究項目推出的，但隨著客戶需求的變化，以及我們自身規(guī)模的擴大，我們意識到，我們需要大力改進才能提升用戶體驗。

我們在使用Geo Key Manager v1(GeoV1)時，面臨幾項主要挑戰(zhàn)，其中一項是訪問控制策略不靈活?？蛻粜枰S富的數(shù)據(jù)本地化，這往往是因監(jiān)管問題所致。目前，能夠迅速限制訪問敏感關鍵資料的需求正在不斷增加。Geo Key Manager v1的底層密碼技術是基于身份的廣播加密和基于身份的撤銷，模擬基于屬性的加密(ABE)的一個功能子集。換成一個成熟的ABE方案后，解決了我們訪問控制策略不靈活的問題，為我們的系統(tǒng)提供了一個更安全的基礎。

我們以前的方案在一開始就凍結參與的數(shù)據(jù)中心和策略集，從而限制了未來的靈活性，而使用ABE，系統(tǒng)很容易適應未來的需求。實例化后增加額外的數(shù)據(jù)中心提升了性能，我們充分利用這一優(yōu)勢，極大地簡化了屬性和策略變更的處理過程。此外，GeoV1還面臨一些復雜的性能問題，導致較高的尾部延遲和痛苦的手動密鑰輪換過程。GeoV2解決了GeoV1存在的這些挑戰(zhàn)和限制。

雖然本文重點討論的是我們的地理密鑰管理解決方案，但這些經(jīng)驗也可應用于其他訪問控制需求。傳統(tǒng)上，訪問控制解決方案是使用一個高度可用的中央機構來控制對資源的訪問。ABE則能夠避免這種單點故障，大家很快便可見證。據(jù)我們所知，目前沒有基于ABE的大型訪問控制系統(tǒng)，希望我們的討論可以啟發(fā)工程師，鼓勵他們考慮使用ABE作為訪問控制的替代方案，盡量減少對中心化機構的依賴。為了促進采納這一方案，我們在我們的開源加密庫CIRCL中加入了我們的ABE實現(xiàn)方式。

一些不夠令人滿意的嘗試

在討論GeoV2之前，我們先來探討一下我們要解決的問題。

例如：一家大型歐洲銀行希望只將他們的TLS私鑰存儲在歐盟內部。這家銀行是Cloudflare的客戶，即我們代表該銀行執(zhí)行TLS握手。我們需要為他們終止TLS，以便我們對DDoS攻擊提供最佳防護，通過緩存提高性能，支持web應用程序防火墻等。

為了終止TLS，我們需要訪問它們的TLS私鑰1。處理API流量的控制平面將客戶上傳的私鑰與全球所有機器共有的主公鑰加密。然后，它將密鑰放入全球分布式KV存儲Quicksilver。這意味著世界上每個數(shù)據(jù)中心的每臺機器都有這個客戶的TLS私鑰的本地副本。因此，每個數(shù)據(jù)中心的每臺機器都有每位客戶的私鑰的副本。

客戶上傳他們的TLS證書和私鑰，并存儲在數(shù)據(jù)中心

然而，這家銀行希望其密鑰僅存儲在歐盟的數(shù)據(jù)中心。為實現(xiàn)這一目的，我們有三種方案。

第一種方案是確保只有歐盟的數(shù)據(jù)中心可以接收密鑰并終止握手。所有其他機器將TLS請求代理到歐盟的服務器進行處理。這就需要只給每臺機器提供Quicksilver中存儲的整個密鑰集的一個子集，而Cloudflare多年來的核心設計決策就是假設整個數(shù)據(jù)集都復制在每臺機器上，這是需要解決的挑戰(zhàn)。

將客戶密鑰限制在歐盟數(shù)據(jù)中心內

第二種方案是將密鑰存儲在核心數(shù)據(jù)中心而非Quicksilver。這樣我們便能每次都執(zhí)行適當?shù)脑L問控制策略，確保只有某些機器可以訪問某些密鑰。但這違背了構建全球網(wǎng)絡的初衷：減少延遲，避免核心發(fā)生單點故障。

將密鑰存儲在核心數(shù)據(jù)中心

但核心數(shù)據(jù)中心需要運行復雜的業(yè)務邏輯來執(zhí)行策略

第三種方案是使用公鑰加密。每個數(shù)據(jù)中心都有自己的密鑰對，而不是一個主密鑰對。該核心將客戶的私鑰和允許使用該私鑰的每個數(shù)據(jù)中心的密鑰加密。在這個例子中，只有歐盟的機器能夠訪問該密鑰。假設有500個數(shù)據(jù)中心，每個數(shù)據(jù)中心有50臺機器。假設這500個數(shù)據(jù)中心中，有200個位于歐盟。以前100個1kB的密鑰共需消耗100 x 500 x 50 x 1 kB（全球），現(xiàn)在將變成200倍，在最糟糕的情況下甚至可能消耗500倍。因此，每臺機器存儲密鑰所需的空間又增加了一個全新的因素——以前，存儲空間就是客戶密鑰注冊數(shù)量的函數(shù)；現(xiàn)在，存儲空間雖然也是客戶密鑰數(shù)量的函數(shù)，但還要乘以數(shù)據(jù)中心的數(shù)量。

為每個數(shù)據(jù)中心分配唯一的密鑰

并將客戶密鑰與歐盟數(shù)據(jù)中心的密鑰封裝起來

遺憾的是，這三種方案都有各自的缺點。它們要么需要改變Cloudflare架構的基本假設，放棄使用高度分布式網(wǎng)絡的優(yōu)勢，要么需要成倍地增加該功能使用的存儲空間。

通過再次深入研究第三種方案后發(fā)現(xiàn)，為什么不為每個數(shù)據(jù)中心創(chuàng)建兩個密鑰對，而只創(chuàng)建一個唯一密鑰對呢？一對為所有歐盟數(shù)據(jù)中心共有，另一對為所有非歐盟數(shù)據(jù)中心共有。這樣一來，核心就只需要對客戶的密鑰進行兩次加密，而不是為每個歐盟數(shù)據(jù)中心分別加密。對歐盟的這家銀行來說，這是一個很好的解決方案，但一旦我們開始添加額外的策略，它就不能擴展了。試想：紐約市的一個數(shù)據(jù)中心可能有一個策略的密鑰“country:US”，另一個策略的密鑰“country:US or region:EU”，另一個策略的密鑰“not country:RU”，以此類推......您已經(jīng)發(fā)現(xiàn)，這實在太復雜了。而且，每次配置新的數(shù)據(jù)中心時，都必須重新評估所有策略，并分配適當?shù)拿荑€。

每個策略一個密鑰與策略否定

Geo Key Manager v1：基于身份的加密和廣播加密

1978年發(fā)明了RSA，拉開了現(xiàn)代公鑰密碼學時代的序幕，但任何人只要使用過GPG或參與過證書機構就知道，管理連接密鑰和用戶身份的公鑰基礎設施非常困難。1984年，Shamir提出，有沒有可能創(chuàng)建一個公鑰加密系統(tǒng)，這個公鑰可以是任何字符串。他提出這個問題是為了簡化電子郵件管理。Alice可以不使用Bob的公鑰將發(fā)送給Bob的電子郵件加密，而是對Bob的身份bob institution.org加密。最終，在2001年，Boneh和Franklin想出了有效的實現(xiàn)方式。

1993年，F(xiàn)iat和Naor首次提出了廣播加密。您可以向所有人發(fā)送相同的加密信息，但只有擁有正確密鑰的人才能解密?；氐轿覀兊牡谌N方案，與其用每個歐盟數(shù)據(jù)中心的密鑰來封裝客戶的密鑰，我們可以使用廣播加密來創(chuàng)建單個客戶密鑰加密，只有歐盟的數(shù)據(jù)中心可以解密。這樣就解決了存儲問題。

Geo Key Manager v1結合使用基于身份的廣播加密和基于身份的撤銷來實現(xiàn)訪問控制。簡而言之就是為每個區(qū)域和每個數(shù)據(jù)中心位置指定一組身份。然后，每臺機器都會為其所在地區(qū)和位置頒發(fā)一個基于身份的私鑰。然后就可以用三個集來控制對客戶密鑰的訪問：要加密的地區(qū)集、這些地區(qū)內要排除的位置集，以及這些地區(qū)外要包括的位置集。例如，通過將客戶的密鑰加密，可以在除幾個特定位置外的所有地區(qū)以及這些地區(qū)以外的幾個指定位置使用密鑰。本文詳細討論了這一方法的所有實質內容。

遺憾的是，這個方案不能充分響應客戶的需求；在最初的加密設置中，使用的參數(shù)（例如地區(qū)、數(shù)據(jù)中心及其屬性的列表）都嵌入在系統(tǒng)中，難以變更。更糟糕的是，由于英國脫歐，因此還要將英國排除在歐盟地區(qū)之外，或根據(jù)客戶需要的最新合規(guī)標準支持一個新的地區(qū)。此外，由于使用預先確定的靜態(tài)位置列表，難以快速撤銷機器訪問。亦或，無法為設置之后新配備的數(shù)據(jù)中心分配解密密鑰，使其無法加快請求速度。這些限制促使我們在Geo Key Manager中使用基于屬性的加密(ABE)。

基于屬性的加密

2004年，Amit Sahai和Brent Waters提出了一個基于訪問策略的新型密碼系統(tǒng)，稱為基于屬性的加密(ABE)。從本質上講，消息的加密是針對訪問策略而非身份。用戶獲發(fā)私鑰是由其自身屬性決定的，只有當用戶的屬性與策略相符時，才能解密消息。與傳統(tǒng)加密方法相比，這可實現(xiàn)更加靈活精細的訪問控制。

公鑰加密大事記

該策略可以附加到密鑰或密文上，得到ABE的兩個變體：基于密鑰策略屬性的加密(KP-ABE)和基于密文策略屬性的加密(CP-ABE)。兩者之間存在權衡取舍，但功能相當，因為它們互為對偶。我們來重點討論CP-ABE，它與現(xiàn)實世界中的訪問控制更相近。試想在一家醫(yī)院，醫(yī)生的屬性是“role:doctor”和“region:US”，而護士的屬性是“role:nurse”和“region:EU”。如果文件的加密策略是“role:doctor or region:EU”，則醫(yī)生和護士均可解密該文件。換而言之，ABE就像一把神奇的鎖，只有具備相應屬性的人才能打開。

根據(jù)不同的屬性，可以有許多不同的ABE方案。我們選擇的方案必須滿足幾個要求：

否定我們希望能夠支持由AND、OR和NOT組成的布爾公式，即非單調的布爾公式。雖然幾乎每個方案都會處理AND和OR，但能處理NOT的比較少見。而否定可更輕松屏蔽某些國家/地區(qū)或機器。

重復屬性例如策略“organization:executive or(organization:weapons and clearance:top-secret)”。在該策略中，屬性“organization”重復了兩次。如果支持重復，制定策略時便更容易表達，靈活性也更高，這極具意義。

安全防御所選密文攻擊大多數(shù)方案的呈現(xiàn)形式都是，只有當攻擊者未選擇要解密的消息時才安全(CPA)。有標準方法可將這類方案轉換成“即使有攻擊者操縱密文也安全”的方案(CCA)，但它不會自動轉換。我們在所選方案中應用了著名的Boneh-Katz轉換，讓該方案能夠應對此類攻擊，提供安全防護。我們即將發(fā)文提供證據(jù)，證明端到端方案的安全性。

否定特別值得進一步討論。一個滿足條件的屬性被否定時，其名稱必須保持不變，但其值必須不同。就像數(shù)據(jù)中心說：“我有一個國家，但絕對不是XX”，而不是“我沒有國家”。這似乎與直覺相悖，但也因此，解密時無需檢查每個屬性的值，還可以安全地逐步推出屬性?；谶@些標準，我們最終選擇了Tomida等(2021)提出的方案。

要實現(xiàn)如此復雜的加密方案可能極具挑戰(zhàn)。作為傳統(tǒng)公鑰密碼學基礎的離散日志假設并不足以滿足ABE的安全要求。ABE方案必須確保密文和基于屬性的秘鑰的安全，而傳統(tǒng)的公鑰密碼學只對密文施加安全限制，而密鑰只是一個整數(shù)。為了實現(xiàn)這一點，大多數(shù)ABE方案均使用雙線性配對（一種數(shù)學運算）來構建。

我們進行配對操作的速度決定了實現(xiàn)的基準性能。在解密過程中，配對特別高效，并用于結合基于屬性的密鑰與密文來恢復明文。為此，我們依托我們的開源密碼套件庫CIRCL高度優(yōu)化的配對實現(xiàn)，我們在之前的博客中詳細討論了這一點。此外，各種密鑰、屬性和嵌入訪問結構的密文使用矩陣和矢量來表達。我們編寫了線性代數(shù)例程來處理矩陣運算，例如乘法、轉置、逆運算，這些都是根據(jù)需要來操作結構。我們還增加了序列化、廣泛的測試和基準分析。最終，我們實現(xiàn)了對CCA2安全方案的轉換。

除核心密碼學之外，我們還必須決定如何表達和聲明策略。最終我們決定為API使用字符串。雖然對程序來說，字符串可能沒有結構那么方便，但我們方案的用戶無論如何都要實現(xiàn)一個解析器。我們?yōu)樗麄儗崿F(xiàn)解析器似乎是獲得更穩(wěn)定的接口的好方法。這意味著，我們的策略語言的前端是由布爾表達式組成的字符串，例如“country:JP or(not region:EU)”，后端則是一個由線和門組成單調布爾線路。單調布爾線路僅包括AND門和OR門。為了處理NOT門，我們?yōu)榫€分配了正值或負值。每個NOT門都可以直接放在線上，因為德摩根定律允許將“not(X and Y)”等公式轉換為“not X or not Y”，析取也是如此。

該API演示如下。中央機構運行Setup來生成主公鑰和主密鑰。訪問策略允許的任何人都可以使用主公鑰將消息加密。中央機構持有的主密鑰則用于根據(jù)用戶的屬性為其生成密鑰。屬性本身可以帶外提供。在我們的案例中，我們依靠機器配置數(shù)據(jù)庫來提供和驗證屬性。這些基于屬性的密鑰通過TLS等方式安全分配給用戶，并用于解密密文。該API還包括檢查解密能力和從密文中提取策略的輔助函數(shù)，可以提高可用性。

publicKey, masterSecretKey := cpabe.Setup()policy := cpabe.Policy{}policy.FromString("country: US or region: EU")ciphertext := publicKey.Encrypt(policy, 【】byte("secret message"))attrsParisDC := cpabe.Attributes{}attrsParisDC.FromMap(map【string】string{"country": "FR", "region": "EU"}secretKeyParisDC := masterSecretKey.KeyGen(attrsParisDC)plaintext := secretKeyParisDC.Decrypt(ciphertext)assertEquals(plaintext, "secret message")

回到我們原來的例子。這一次，中央機構持有主密鑰。每個數(shù)據(jù)中心的每臺機器都向中央機構提交其屬性集，中央權威機構經(jīng)驗證后，為該特定機器生成一個獨特的基于屬性的密鑰。機器首次啟動時，如果必須輪換密鑰，或如果一個屬性發(fā)生了變化，就會頒發(fā)密鑰，但絕不會在TLS握手的關鍵過程中頒發(fā)。這個解決方案還能防止串通，即兩臺不具備相應屬性的機器不能通過結合它們的密鑰來將不能單獨解密的密鑰解密。例如，一臺具有屬性“country:US”和另一臺具有屬性“security:high”的機器，它們不能串通起來將策略“country:US and security:high”解密。

最重要的是，這個解決方案可以無縫擴展，響應機器變更。如果增加了一臺新機器，中央機構可以簡單地為其頒發(fā)一個密鑰，因為該方案不必在設置時預先確定參與者，這一點與以前基于的身份廣播方案不同。

密鑰分發(fā)

客戶可以在上傳TLS證書時指定策略，中央機構將根據(jù)指定的策略使用主公鑰將其私鑰加密。加密后的客戶密鑰將寫入Quicksilver，然后分發(fā)到所有數(shù)據(jù)中心。在實踐中，這里有一層間接性，我們將在后面的章節(jié)中繼續(xù)討論。

使用主公鑰加密

用戶訪問客戶的網(wǎng)站時，首先收到請求的數(shù)據(jù)中心的TLS終止服務會從Quicksilver獲取客戶的加密私鑰。如果服務的屬性與策略不符，則解密失敗，請求將被代理到最近的、與策略相符的數(shù)據(jù)中心。無論哪個數(shù)據(jù)中心，只要能成功將密鑰解密，就會執(zhí)行簽名，完成TLS握手。

使用基于屬性的密鑰解密（簡化版）

下表總結了上述各解決方案的優(yōu)缺點：

性能特征

我們受ECRYPT啟發(fā)，總結了一些測量來描繪方案的性能。我們將屬性“size”設置為50，這遠高于大多數(shù)應用程序的需要，但可以作為基準測試的最壞情況參考。我們在配備英特爾酷睿i7-10610U CPU 1.80GHz的筆記本電腦上進行測量，并將結果與2048位安全的RSA、X25519和我們以前的方案進行比較。

不同的基于屬性的加密方案優(yōu)化了不同的性能特征。有些可能可快速生成密鑰，而另一些可能優(yōu)先考慮快速解密。在我們的案例中，我們只關心快速解密，因為只有這個環(huán)節(jié)位于請求的關鍵路徑上。其他事情都發(fā)生在帶外，而帶外開銷是可以接受的。

基于屬性的訪問控制(ABAC)簡介

我們使用基于屬性的加密來實現(xiàn)所謂的基于屬性的訪問控制(ABAC)。

ABAC源自更熟悉的基于角色的訪問控制(RBAC)。為了理解ABAC的重要性，我們簡單討論一下它的起源。1970年，美國國防部推出了自主訪問控制(DAC)。DAC是Unix文件系統(tǒng)的實現(xiàn)方式。但是，如果您想限制再共享，只有DAC是不夠的，因為資源的所有者可能在中央管理員不同意的情況下授權其他用戶訪問資源。為了解決這一問題，美國國防部推出了強制訪問控制(MAC)。DRM就是一個很好MAC示例。即使文件擁有者也無權與他人分享。

RBAC是對MAC某些方面的實現(xiàn)。ABAC是RBAC的延伸。2017年，NIST確定了RBAC的標準，以應對越來越多不受角色限制的用戶特征，例如時間、用戶代理等。

然而，RBAC/ABAC只是一種規(guī)范。雖然它們傳統(tǒng)上是用一個中央機構來控制對某些資源的訪問，但并非必須如此。基于屬性的加密是在分布式系統(tǒng)中實現(xiàn)ABAC的優(yōu)良機制。

密鑰輪換

雖然可能很容易把所有問題都歸咎于DNS，但在這場競賽中，更換密鑰也是強有力的競爭對手。由于Geo Key Manager v1的密鑰輪換過程非常依賴人工操作，且容易出錯，所以我們打算在不影響可用性的情況下進行強大而簡單的密鑰輪換，這是Geo Key Manager v2明確的設計目標之一。

為了方便密鑰輪換，改善性能，我們?yōu)榭蛻舻拿荑€封裝（加密）過程引入了一層間接性。客戶上傳他們的TLS私鑰時，我們不用主公鑰加密，而是生成一個X25519密鑰對，即策略密鑰。然后，中央機構將這個新產(chǎn)生的策略密鑰對的公共部分及其相關的策略標簽添加到一個數(shù)據(jù)庫中，然后再根據(jù)相關訪問策略，使用主公鑰將策略密鑰對的私有部分加密?？蛻舻乃借€便通過公共策略密鑰得以加密，并保存在Quicksilver中。

用戶訪問客戶的網(wǎng)站時，收到請求的數(shù)據(jù)中心的TLS終端服務會獲取與客戶訪問策略相關的加密策略密鑰。如果機器的屬性與策略不符，則解密失敗，請求將被轉發(fā)到最近的、條件相符的數(shù)據(jù)中心。如果解密成功，則使用策略密鑰將客戶的私鑰解密，并完成握手。

然而，策略密鑰并不是為每位客戶的證書上傳而生成。如下圖所示，如果客戶請求的是系統(tǒng)中已經(jīng)存在的策略，因此也存在一個相關的策略密鑰，那么將重復使用該策略密鑰。由于大多數(shù)客戶使用相同的幾個策略，例如限制在某一個國家/地區(qū)，或限制在歐盟，與客戶密鑰相比，策略密鑰的數(shù)量要少幾個數(shù)量級。

策略密鑰

這種策略密鑰共享對密鑰輪換幫助極大。如果主密鑰被輪換（機器密鑰也隨之輪換），只需要將少數(shù)用于控制客戶密鑰訪問的策略密鑰重新加密，而不需要將每位客戶的密鑰重新加密。這降低了計算和帶寬要求。此外，在TLS終端服務中緩存策略密鑰，通過減少關鍵路徑中的頻繁解密需求來提高性能。

這與混合加密相似。在混合加密中，公鑰加密法用于建立一個共享的對稱密鑰，然后使用對稱密鑰加密數(shù)據(jù)。差別在于，策略密鑰不是對稱密鑰，而是X25519密鑰對——一個基于橢圓曲線的非對稱方案。雖然沒有AES等對稱方案那么快，但傳統(tǒng)的橢圓曲線加密技術比基于屬性的加密要快得多。這里還有一點優(yōu)勢：中央服務不需要通過訪問密鑰資料來將客戶密鑰加密。

穩(wěn)健的密鑰輪換的另一組成部分涉及維護多個密鑰版本。最新的密鑰生成用于加密，但最新和以前的版本可用于解密。我們使用一個狀態(tài)系統(tǒng)來管理密鑰轉換和安全刪除舊密鑰。我們還部署了廣泛監(jiān)測系統(tǒng)，如果任何機器沒有使用適當?shù)拿荑€生成，就會提醒我們。

大規(guī)模尾部延遲

Geo Key Manager存在高尾部延遲問題，這有時會影響可用性。Jeff Dean的文章The Tail at Scale（《大規(guī)模尾部延遲》）很有啟發(fā)性，說明以Cloudflare的規(guī)模，即使p99延遲升高也會造成損害。盡管我們對服務的服務器和客戶端組件進行了改造，但并沒有考慮p99延遲問題。這些改造（例如從Worker池切換到每個請求一個Goroutine）確實簡化了服務，因為刪除了數(shù)千行代碼。分布式跟蹤能夠確定延遲發(fā)生在客戶端發(fā)送請求和服務器接收請求之間，但我們無法進一步確定。去年我們甚至寫了一篇博客，介紹了我們的排查嘗試，但沒有得出具體的解決方案。

最后，我們意識到，客戶端和服務器之間存在一層間接性。我們世界各地的數(shù)據(jù)中心規(guī)模相差很大。為了避免小型數(shù)據(jù)中心被連接淹沒，大型數(shù)據(jù)中心將使用Go net/rpc庫安排各臺中間機器將請求代理到其他數(shù)據(jù)中心。

一旦我們將中間服務器的轉發(fā)功能納入追蹤范圍，問題就一清二楚了。發(fā)出請求和處理請求之間有一個很長的延遲。然而，此代碼只是對一個內置庫函數(shù)的調用。它為什么要將請求延遲呢？

最終我們發(fā)現(xiàn)，將請求序列化時，有一個鎖無法解鎖。net/rpc包不支持流，但我們在gRPC出現(xiàn)之前編寫的面向數(shù)據(jù)包的自定義應用程序協(xié)議確實支持流。為了解決這一問題，我們執(zhí)行了一個請求，并等待序列化函數(shù)的響應。雖然這可快速完成代碼編寫，但它造成了性能瓶頸，因為每次只能轉發(fā)一個請求。

我們的解決方案是使用協(xié)調通道，讓多個請求執(zhí)行，同時等待響應。在我們推出之時，我們發(fā)現(xiàn)尾部延遲已大為降低。

在澳大利亞的遠程colo中修復RPC故障的結果

遺憾的是，我們無法將光速提高（至少目前如此）。客戶如果希望他們的密鑰只保存在美國，但他們的網(wǎng)站用戶卻在地球的另一面，那就不得不忍受一些延遲，因為需要進行越洋傳輸。但由于有會話票證，這些延遲只會影響新的連接。

正常運行時間也顯著增加。加密啟動之后才配置的數(shù)據(jù)中心現(xiàn)可加入系統(tǒng)，這也意味著不符合特定策略的數(shù)據(jù)中心會有更多符合條件的鄰居，可以將簽署請求轉發(fā)給這些鄰近的數(shù)據(jù)中心。這增加了系統(tǒng)冗余，對于沒有最佳互聯(lián)網(wǎng)連接的地區(qū)的數(shù)據(jù)中心特別有利。下圖表示在兩天時間中，全球每臺機器進行的成功探測。對于GeoV1，我們發(fā)現(xiàn)，限制在美國和歐盟地區(qū)的策略的網(wǎng)站一度降到98%以下；而對于GeoV2，正常運行時間可用性很少降到99.99%以下。

不同密鑰配置的正常運行時間（GeoV1在美國和歐盟

以及GeoV2在美國、歐盟和印度）

總結

親愛的讀者，感謝您堅持閱讀到這里。應用密碼學也經(jīng)歷了漫長的發(fā)展才走到今天，但只有少數(shù)研究成果能夠走出實驗室，獲得實際采用。彌合研究與現(xiàn)實的差距，有助于實現(xiàn)以創(chuàng)新方式保護敏感數(shù)據(jù)。過去幾年中，基于屬性的加密本身已經(jīng)變得更加高效、更具特色。希望本文能給您啟發(fā)，鼓勵您考慮使用ABE來解決自己的訪問控制需求，特別是如果您處理的是一個分布式系統(tǒng)，且不想依賴一個高度可用的中央機構。我們已經(jīng)在CIRCL中公開了我們的CP-ABE實現(xiàn)的開源代碼，并計劃撰文提供更多細節(jié)。

希望這一新的密碼學技術基礎將使Geo Key Manager產(chǎn)品大為改進。除存儲私鑰外，我們還計劃使用這種基于ABE的機制來存儲其他類型的數(shù)據(jù)。我們正在努力提高其操作便捷性，并進行通用化處理，供內部服務部門使用。

致謝

特別感謝Watson Ladd在Cloudflare任職期間為本項目做出的巨大貢獻。