HashiCorp Vault 成功案例｜Booking.com 混合雲遷移

Hashicorp Vault 成功案例 2025 年 9 月 17 日

Booking.com 的營運規模龐大，為數百萬名旅客提供服務，其複雜的基礎架構橫跨裸機伺服器、AWS、GCP 與阿里雲。

四年前，當 Dan Popescu 擔任 Booking.com 資深網站可靠性工程師、加入金鑰管理團隊時，這家旅遊巨頭已經深入進行混合雲遷移，而這個過程也帶來了獨特的資安挑戰。

在近期 HashiDays 演講中，Dan 分享了他的團隊如何轉變 Booking.com 的金鑰管理方式，將 HashiCorp Vault 擴展至能夠在 100 多個 Kubernetes 叢集上，每秒處理 500 多個請求。

其團隊的使命是：「提供統一的金鑰管理解決方案，打造自助式體驗，使跨雲平台的金鑰共享與生命週期管理既無縫又安全。」

Booking.com 混合雲旅程四大資安亮點

混合雲環境中最大的資安風險，是跨互聯系統缺乏一致的控管。

Booking.com 希望在公有雲服務與內部基礎架構之間建立身份與金鑰管理的橋樑，讓開發人員無需為每個環境重新設計安全工具鏈與工作流程。

Booking.com 將 Vault 定位為多雲環境與裸機基礎架構之間的資安通訊橋樑。當開發人員在內部服務目錄中建立資源時，Vault 會自動上線雲端資源並配置認證。

無論應用程式運行在裸機、AWS、GCP 或內部 OpenStack 叢集，開發人員都能獲得一致的存取模式，避免各環境自訂解決方案常出現的資安錯誤，這解決了混合雲中維持資安標準同時提升開發生產力的挑戰。

初期，Booking.com 發現驗證分散帶來重大資安風險。因爲他們需要管理數百個掛載點以及 Kubernetes 叢集中的數千個身份實體 —— 而每個應用程式部署在 100 個叢集上，就需要 100 個獨立掛載點和 200 個設定變更。

這種複雜性讓資安監控幾乎不可能，擴展也極具風險！

突破來自 JWT 驗證遷移，透過利用所有 Kubernetes 叢集提供的 JWK/JWS 端點，他們整合到單一掛載點，包含來自所有環境的公鑰，並建立了 JWS 管理器，自動偵測叢集並每五分鐘更新驗證金鑰。

現在新增叢集只需少量設定變更，而不是數百個。

簡化的驗證結構降低了錯誤配置的風險，並提升跨所有環境的存取模式可視性。這也讓安全事件回應更快速，因為只需監控和稽核單一驗證系統。

在制定金鑰管理策略時，Booking.com 也必須考量成本與效能。「我們在處理數百萬筆金鑰，跨數百個帳號有 30,000 個 AWS 角色，以及 6,500 個 Snowflake 角色。」Dan 提到。

2025 年，Booking.com 計畫使用 Vault 的金鑰同步功能，為金鑰管理系統增加彈性，同時保留 Vault 作為金鑰管理單一真實來源的優勢。透過金鑰同步，團隊可以在特定 AWS 使用案例中，使用像 AWS Secrets Manager 這類的其他金鑰管理工具，來維持較小的系統足跡。

與其無限制地採用雲端原生工具，他們要求團隊針對特定區域明確申請特定金鑰。Vault 仍然是單一真實來源，但團隊可透過 AWS Secrets Manager 存取適合雲端原生工作負載的金鑰，以提升效能。

集中化的金鑰治理，同時保有戰術彈性。所有金鑰都經過 Vault 的政策引擎與稽核日誌，即使團隊使用雲端原生工具，也能確保一致的資安控管，避免資安碎片化，同時滿足特定使用需求！

太昂貴的資安解決方案往往會被放棄或妥協。而 Booking.com 的做法能夠同時兼顧資安與成本效益，對其營運規模而言至關重要。

他們的成本控管資安策略包括：

智慧 TTL 管理：最初部分 Vault 金鑰引擎沒有設定存活時間（TTL），導致金鑰累積，可能造成系統中斷。適當的 TTL 設定可避免資源浪費與高昂停機成本。
靜態使用者模式：對 Snowflake 與 CockroachDB，他們從動態配置改為靜態使用者並定期更換密碼，降低管理負擔。
選擇性雲端整合：利用 Vault 的同步功能，策略性地放置金鑰以兼顧成本與效能。

可持續的成本控管確保長期資安投入。可預測的支出讓資安改善能持續進行，而不受預算爭議影響，也避免團隊因成本壓力而規避工具使用。