Cloudflare 在 2023 年 1 月 24 日發生的事件

2023 年 1 月 24 日，因為管理服務權杖的發布代碼發生錯誤，導致數個 Cloudflare 服務有 121 分鐘的時間無法使用。此事件導致多種 Cloudflare 產品降級，包括我們的 Workers 平台、Zero Trust 解決方案，以及內容傳遞網路 (CDN) 中的控制平面功能等方面。

Cloudflare 提供一項服務權杖功能，允許自動化服務對其他服務進行驗證。例如，客戶可使用服務權杖來確保在資料中心執行的應用程式與公有雲端提供者的資源之間進行互動。在發行版本中，我們打算引入對管理員顯示權杖最後使用時間的功能，讓使用者能夠安全地清除未使用的權杖。這項變更無意中覆寫了其他有關服務權杖的中繼資料，並使得受影響帳戶的權杖在事件發生期間失效。

此發行版本之所以影響其他服務，是因為 Cloudflare 在 Cloudflare 上運作。服務權杖會影響帳戶驗證的能力，而其中兩個受影響的帳戶為多個 Cloudflare 服務提供支援。這些帳戶的服務權杖遭到覆寫後，在這些帳戶上執行的服務就開始出現要求無效和其他非預期的錯誤。

雖然只有一小部分客戶和終端使用者直接受到此事件的影響，而且其他客戶可能遇到了服務降級，對 Cloudflare 網路與服務的整體影響並不嚴重。儘管如此，我們知道這對受影響的客戶而言是相當不愉快的體驗。我們正在記錄所發生的錯誤，以便您瞭解發生的原因，以及我們為防止此情況再次發生而採取的措施。

使用者登入應用程式或身分識別提供者時，通常會輸入一組使用者名稱和一組密碼。密碼可讓該使用者證明他們擁有該使用者名稱的控制權，而且該服務應允許他們繼續至下一步。可以加上額外的驗證功能，例如硬體金鑰或裝置狀態，但工作流程會包括人員對服務證明其身分的真偽。

不過，人員並非唯一需要對服務進行驗證的使用者。應用程式經常需要與其他應用程式通訊。舉例來說，想像您建置了一款應用程式，會向使用者顯示有關其近期旅行計畫的資訊。

航空公司會在自有系統中保留有關航班及其飛行時間的詳細資料。他們並不想將個人行程的詳細資料公開到網際網路上，也無意邀請您的應用程式進入他們的私有網路。同樣地，旅館希望確保他們只對有效、經核准的第三方服務傳送客房預訂的詳細資料。

您的應用程式需要受信任的方式來對這些外部系統進行驗證。服務權杖可作為您服務的使用者名稱和密碼，以解決此問題。就像使用者名稱與密碼一樣，服務權杖由兩個部分組成：用戶端 ID 和用戶端密碼。ID 和密碼都必須與驗證要求一起傳送。系統也會對權杖指派一個期限，在該期限之後，權杖就會失效且必須替換。您可以對應用程式授予一組服務權杖，且如果您所需的上游系統對其進行驗證，您的服務就可以取得航空公司與旅館資訊，並在聯合報告中將該資訊呈現給終端使用者。

管理員建立 Cloudflare 服務權杖時，我們會產生一組配對的用戶端 ID 和用戶端密碼。接著，客戶可設定其要求的服務，以便在他們需要取得受保護的資源時將這兩個值以 HTTP 標頭的方式傳送。要求的服務可在任何環境中執行，包括在 Cloudflare 的網路中以 Worker 形式執行，或在公有雲端提供者這類的單獨位置中執行。客戶需要在 Cloudflare 的反向代理後方部署相應的受保護資源。我們的網路會檢查每個與已設定服務繫結之要求的 HTTP 標頭。如果存在，Cloudflare 就會驗證其真偽，並阻擋該要求或允許該要求繼續。我們也會記錄驗證事件。

所有時間戳記均為 UTC

2023 年 1 月 24 日下午 4:55，Access 工程團隊啟動了發佈工作，無意中開始覆寫服務權杖中繼資料，因此導致此次事件。

2023 年 1 月 24 日下午 5:05，Access 工程團隊中有一位成員注意到一個不相關的問題，並將發行版本復原，因而停止了對服務權杖中繼資料的任何進一步覆寫。

在服務權杖本身更新之前，服務權杖值不會在 Cloudflare 的網路中更新（更多詳細資料請見下方）。這對於中繼資料遭到覆寫的服務權杖造成了交錯的影響。

2023 年 1 月 24 日下午 5:50，Cloudflare WARP 的第一個無效服務權杖同步到我們的全球網路。開始對 WARP 和 Zero Trust 使用者造成影響。

WARP 裝置狀態上傳下降至零，引發內部警示

2023 年 1 月 24 日下午 6:12，因為 WARP 裝置狀態成功上傳的大幅下降，宣佈發生事件。

2023 年 1 月 24 日下午 6:19：Cloudflare API 的第一個無效服務權杖同步到我們的全球網路。**開始對 Cache Purge、Cache Reserve、Images 和 R2 造成影響。**對這些產品觸發了警示，因此確認了事件的更大範圍。

2023 年 1 月 24 日下午 6:21，在初步調查中發現了遭到覆寫的服務權杖。

2023 年 1 月 24 日下午 6:28，事件提升至包括所有受影響的產品。

2023 年 1 月 24 日下午 6:51，確認並實作了初步的解決方案，將 Cloudflare WARP 帳戶的服務權杖回復為其原始值，對 WARP 和 Zero Trust 造成影響。對 WARP 和 Zero Trust 的影響結束。

2023 年 1 月 24 日下午 6:56，在 Cloudflare API 帳戶上實作了相同的解決方案，對 Cache Purge、Cache Reserve、Images 和 R2 造成影響。對 Cache Purge、Cache Reserve、Images 和 R2 的影響結束。

2023 年 1 月 24 日下午 7:00，對錯誤覆寫了 Cloudflare API 帳戶的 Cloudflare API 帳戶進行更新。**對 Cache Purge、Cache Reserve、Images 和 R2 重新開始造成影響。**對內部 Cloudflare 帳戶的所有內部變更隨即遭到鎖定，直到事件解決為止。

2023 年 1 月 24 日下午 7:07，將 Cloudflare API 更新，使其包括正確的服務權杖值。對 Cache Purge、Cache Reserve、Images 和 R2 的影響結束。

2023 年 1 月 24 日下午 7:51，所有受影響的帳戶都從資料庫備份中還原其服務權杖。事件結束。

Access 團隊當時正在推出對服務權杖的新變更，即增加了「最後顯示時間」欄位。這是一種熱門的功能要求，有助於識別哪些服務權杖正在活躍使用中。

「最後顯示時間」值透過掃描帳戶登入事件 Kafka 佇列中的所有新登入事件所衍生。如果偵測到使用服務權杖的登入事件，就會對相應服務權杖的最後顯示值啟動更新。

為了更新服務權杖的「最後顯示時間」值，進行了讀取寫入交易，以收集有關相應服務權杖的資訊。為了安全起見，服務權杖讀取要求會編寫「用戶端密鑰」值。接著，對服務權杖的「最後顯示時間」更新從讀取中使用了該資訊，但不包括「用戶端密鑰」，且在寫入中使用空的「用戶端密鑰」更新了該服務權杖。

以下是正確和不正確的服務權杖值範例：

Access 服務權杖值範例

服務權杖「用戶端密碼」資料庫確實有一個「非空值」檢查，但是在此情況下，空的文字字串並未觸發為空值。

{
  "1a4ddc9e-a1234-4acc-a623-7e775e579c87": {
    "client_id": "6b12308372690a99277e970a3039343c.access",
    "client_secret": "<hashed-value>", <-- what you would expect
    "expires_at": 1698331351
  },
  "23ade6c6-a123-4747-818a-cd7c20c83d15": {
    "client_id": "1ab44976dbbbdadc6d3e16453c096b00.access",
    "client_secret": "", <--- this is the problem
    "expires_at": 1670621577
  }
}

因為此錯誤，所有在「最後顯示時間」功能發佈的 10 分鐘期間使用過服務權杖進行驗證的 Cloudflare 帳戶，其「用戶端密碼」值都被設定為空的字串。接著便需要修改服務權杖，以便將空的「用戶端密碼」用於進行驗證。總共有 4 個帳戶處於此狀態，而且全部都是 Cloudflare 的內部帳戶。

在臨時解決方案中，我們能夠為服務權杖遭到覆寫的帳戶還原正確的服務權杖值。這阻止了對受影響 Cloudflare 服務所造成的直接衝擊。

接著，資料庫團隊能夠實作解決方案，從較舊的資料庫副本中還原所有受影響帳戶的服務權杖。這樣就結束了此事件所造成的任何影響。

服務權杖會影響帳戶驗證的能力。其中兩個受影響的帳戶為多項 Cloudflare 服務提供支援。這些帳戶的服務權杖遭到覆寫後，在這些帳戶上執行的服務就開始出現要求無效和其他非預期的錯誤。

Cloudflare 提供了一種行動和桌面正向代理，Cloudflare WARP（我們的「1.1.1.1」應用程式），任何使用者都可以在裝置上安裝，以提升其網際網路流量的隱私權。任何人都無需 Cloudflare 帳戶即可安裝此服務，而且我們不會保留將活動對應至使用者的記錄。

使用者透過 WARP 連線時，Cloudflare 會依賴在裝置上接收和驗證金鑰的服務來驗證註冊情形。在另一方面，該服務會與其他系統通訊，以告知我們的網路為新註冊的裝置提供網路的存取權限。

在此事件發生期間，註冊服務無法與我們網路中用於驗證裝置的系統通訊。因此，使用者無法再註冊新的裝置及/或在新的裝置上安裝應用程式，而且在升級至新版本應用程式方面遇到了問題（這也會觸發重新註冊）。

Cloudflare 提供一個全方位的 Zero Trust 解決方案，無論裝置上是否有代理，都能讓客戶進行部署。有些使用案例只有在裝置上使用 Cloudflare 代理時才能使用。該代理是同一個 Cloudflare WARP 解決方案的企業版本，在代理需要傳送和接收裝置狀態時都遇到了相同的降級情形。這在 Cloudflare Zero Trust 中影響到三個使用案例。

首先，與消費者產品類似，新的裝置無法註冊，且現有裝置無法撤銷。管理員也無法修正已註冊裝置的設定。在所有情況下，系統都會對使用者顯示錯誤。

其次，許多使用 Cloudflare 的 Zero Trust 解決方案來取代現有私有網路的客戶，可能會新增一些規則，透過使用工作階段期間原則來持續驗證使用者的身分。這些規則的目的是強制使用者重新驗證，以避免過時的工作階段持續存取內部系統。裝置上的代理會依據來自 Cloudflare 控制平面的訊號來提示使用者重新驗證。在事件發生期間，訊號並未送出，使用者也無法成功重新驗證。

最後，依靠裝置狀態規則的客戶也受到了影響。裝置狀態規則允許使用 Access 或 Gateway 原則的客戶依靠 WARP 代理來持續強制實施規則，使裝置服務企業法規遵循。

代理會將這些訊號傳送至負責維護裝置狀態的 Cloudflare 服務。Cloudflare 的 Zero Trust 存取控制產品會使用服務權杖來接收此訊號，並與其他規則一起對其進行評估，以決定使用者是否可以存取特定的資源。在此事件中，這些規則預設為封鎖動作；也就是說，由這些原則修改的流量對使用者會呈現出不連貫的情形。在某些情況下，這代表所有從裝置傳送至網際網路的流量完全遭到封鎖，導致使用者無法存取任何內容。

Cloudflare Gateway 每 5 分鐘就會為使用者快取一次裝置狀態，以套用 Gateway 原則。裝置狀態快取後，Gateway 就可以套用原則，而不需要在每次要求時驗證裝置狀態。視所比對的 Gateway 原則類型而定，使用者會遇到兩種不同的結果。如果與網路原則相符，使用者就會遇到連線遭捨棄的問題；如果是 HTTP 原則，就會顯示 5XX 錯誤頁面。在事件解決之前，我們每分鐘最高遇到基準線上超過 50,000 個 5XX 錯誤，且發生超過 1050 萬個狀態讀取錯誤。

Gateway 每分鐘的 5XX 錯誤

Gateway 裝置狀態錯誤總數

Cloudflare R2 Storage 可讓開發人員儲存大量非結構化資料，且無需支付與典型雲端儲存服務相關聯的昂貴輸出頻寬費用。

在此事件期間，R2 服務無法對 Cloudflare 基礎架構的其他部分進行輸出 API 要求。因此，R2 使用者對 R2 提出要求時，遇到的要求失敗率更高。

許多 Cloudflare 產品也依賴 R2 進行資料儲存，因此也受到影響。例如，Cache Reserve 使用者在此期間受到影響，而且不在主要快取中的任何項目遭遇原始負載增加的情況。在此事件期間，對 Cache Reserve 服務的大部分讀取和寫入操作都受到影響，導致 Cache Reserve 的輸入和輸出失敗。但是，Cache Reserve 發生 R2 錯誤時，會回復到客戶原點，因此使用者流量服務在此期間仍然能夠運作。

Cloudflare 的內容傳遞網路 (CDN) 會將網際網路資產的內容快取到我們在世界各地之資料中心的網路上，以縮短使用者要求為取得回應所需傳輸的距離。在某些情況下，客戶會希望清除我們快取的內容，並將其取代為其他資料。

Cloudflare 控制平面是管理員與我們網路互動之處，它會使用服務權杖來驗證和實現快取清除服務。在此事件期間，許多清除要求都在服務權杖失效時失敗了。我們看到的平均影響情況是，每秒 20 個清除要求失敗，且每秒最多發生 70 個要求。

我們非常嚴正看待此類事件，也認知到該事件所帶來的影響。我們已確認可採取幾項步驟，以因應日後發生類似問題的風險。因為此事件，我們將實作以下補救計畫：

**測試：**Access 工程團隊將新增單元測試，在推出任何新功能之前，自動捕捉任何與服務權杖覆寫類似的問題。

**警示：**Access 團隊將實作自動化警示，以因應失敗的服務權杖驗證請求大幅增加，進而在造成全面影響之前找出問題。

**程序︰**Access 團隊已確立程序改善，以便加快特定資料庫表格的回復速度。

**實作：**所有相關的資料庫欄位都將更新，以納入在現有「非空值檢查」之上對空白字串的檢查。

此事件對多種 Cloudflare 服務的客戶造成影響，我們感到相當抱歉。我們將積極進行這些實作，確保今後的穩定性得到提升，並確保這類問題不會再發生。