資料主權如何改變雲端原生基礎架構設計
發布於 2026 年 7 月 3 日 作者：Dana Cazacu，VEXXHOST 行銷經理
核心問題不在於你的伺服器放在哪裡，而是誰可能被迫交出伺服器上的資料。
多年來，雲端服務供應商都把主權視為地理問題。選一個區域、選一個國家，把資料留在本地。
但像美國《CLOUD Act》這類法律改變了這個等式。資料存取權跟隨的是企業控制權，而不是實體位置。一家超大型雲端服務商（hyperscaler）即使在法蘭克福營運基礎架構，仍然受其母公司所屬法律管轄。選擇區域是一種地理控制；主權則是管轄權問題。
這項差異正越來越深刻地影響基礎架構決策。
歐盟於 2026 年 6 月提出的《雲端與 AI 發展法案》（Cloud and AI Development Act, CADA），為公部門雲端採購引入四層級的主權框架。加拿大聯邦政府現在會依據加拿大資料駐留與管轄控制情況，對雲端供應商評分。許多國家現在都有資料在地化、資料主權或資料駐留要求，而監管框架也日益從資料駐留延伸到營運控制、供應鏈透明度、可攜性與韌性等問題。
歐盟《資料法》促進互通性，並降低更換供應商的障礙。《AI 法案》則針對 AI 系統的可追溯性、治理與問責提出要求。NIS2 與 DORA 更加重視供應鏈依賴、營運韌性與集中風險。類似的討論也正在全球各管轄區浮現。
整體來看，這些發展指向一個未來：對基礎架構的控制，不再只是技術偏好，而是越來越成為監管期待。
這項轉變常被框定為隱私議題。事實上，它越來越是一個韌性議題。能防範外國法律干預的同一套架構，也能降低制裁、貿易爭端、服務暫停、授權條款變更、供應商退出，以及其他形式外部依賴所帶來的風險。
對平台工程師來說，挑戰很直接：要如何在不犧牲自動化、可攜性與營運效率的前提下，滿足主權要求？畢竟這些正是雲端基礎設施一開始吸引人的原因。
正式環境中逐漸浮現的模式
在歐洲，受監管企業越來越常用開源元件組合出主權平台，而不是向超大型雲端服務商購買作為高階功能的主權能力。
這個模式正變得越來越熟悉。Kubernetes 提供編排與政策層。GitOps 提供跨法域的營運一致性。OpenStack 則供應底層基礎設施。三者合在一起，讓組織能透過架構，而不是合約，來落實主權要求。
這些不是概念驗證部署。國家鐵路營運商、大型銀行與歐洲電信業者，已經在主權環境中使用 Kubernetes、GitOps 與政策驅動的自動化，以大規模方式營運受監管工作負載。
這個模式相當一致：用 Kubernetes 做治理與編排，用 OpenStack 建立主權基礎設施，用政策即程式碼（policy as code）執行要求，並用宣告式維運確保可重複性。
Kubernetes 作為主權控制平面
建構主權基礎設施是一項挑戰。要一致地營運它，則是另一項挑戰。
多數合規計畫仍高度仰賴文件、審查與人工流程。這些做法可行，但要擴展到數百或數千個工作負載時，效果並不特別好。Kubernetes 改變了這一點，因為它讓主權要求可以直接由平台執行。
准入控制器（Admission Controllers）可以在 Pod 被排程之前，就先強制執行工作負載的放置規則。節點親和性規則確保工作負載只會落在正確法域內、已核准的基礎設施上。命名空間隔離則在租戶、環境或區域之間建立清楚邊界。政策引擎會依據主權要求評估每一個 API 請求，並在不合規的資源進入正式環境之前予以拒絕。
政策即程式碼（policy as code）則是在營運層面延伸同樣的方法。主權政策存放在 Git 中，經過同儕審查，透過 CI 管線測試，並在部署時自動強制執行。OPA/Gatekeeper 與 Kyverno 等工具，讓組織能把司法管轄區的要求直接編碼進叢集裡。其結果是持續性的強制執行，而不是週期性的驗證。每一次政策變更都可追溯。每一次部署決策都可稽核。
到了這個階段，主權不再是一套流程，而成為一種平台能力。
但 Kubernetes 底下仍然仰賴一層基礎設施。運算、網路、儲存與身分識別，都必須來自某個地方。如果這個基礎綁定在由你司法管轄區之外的組織所營運的平台上，Kubernetes 層所強制執行的部分保障，就會變得更難維持。
這正是 OpenStack 進場的位置。
OpenStack 提供 Kubernetes 所仰賴的基礎設施服務，同時讓組織能在自己的司法管轄區內營運這些服務。透過 Ironic 進行裸機佈建，可以移除工作負載與硬體之間對專有虛擬化管理程序的需求。Keystone 讓身分管理維持自託管。Neutron 提供由營運者掌控的網路隔離。Ceph 則在你擁有並營運的基礎設施上提供分散式儲存。
OpenStack 可以完全部署在受控環境內。不需要授權伺服器。不需要強制遙測服務。日常營運不需要外部相依項。
讓這套架構可行的，是兩者的組合。Kubernetes 提供政策與強制執行層。OpenStack 提供其下方的基礎設施根基。兩者合在一起，讓主權要求能以程式碼實作、自動強制執行，並在整個技術堆疊中接受稽核。
困難之處：營運
主權往往意味著每個司法管轄區都要有各自獨立的環境。每一次升級、憑證輪替、RBAC 變更、安全修補與容量規劃，現在都不是在單一叢集上發生，而是橫跨多個叢集。
GitOps 正是讓這件事在營運上可管理的關鍵。
Git 儲存庫包含共用設定，以及各司法管轄區專屬的疊加設定。每個叢集內執行的 GitOps 控制器會持續對照該期望狀態進行調和。不需要集中式控制平面。每個叢集都會在本地自行拉取並套用自己的設定。
營運上的好處很明顯，但法遵上的好處同樣重要。每一次變更都經過審查、版本控管，並且可供稽核。當有人詢問某個叢集在特定時間點執行了什麼，答案已經在 commit 歷史裡。
同樣的原則也適用於軟體供應鏈。SBOM（軟體物料清單）、映像簽章與准入政策，有助於確保只有通過驗證的工作負載能進入正式環境。
對於追求更高層次主權的組織來說，可視性不能停在作業系統。韌體、管理控制器與硬體元件位於軟體堆疊之下，而且往往對主機本身具有廣泛的存取權限。這也是為什麼 HBOM（硬體物料清單）與韌體驗證，也正在成為主權討論的一部分。
接下來會發生什麼
基礎設施建置已經展開。CADA 目標是在未來幾年大幅擴充歐洲的資料中心容量，但光有硬體並不會創造主權。平台層和其底下的基礎設施同樣重要。
AI 讓這個現實變得更加清楚。隨著監管機關更加重視模型如何訓練、治理與稽核，訓練基礎設施也越來越常被用與資料本身相同的主權視角來評估。
聯邦學習就是這種變化如何改變架構的一個例子。訓練不是把資料移到中央位置，而是在資料原本所在的地方進行。主權 Kubernetes 叢集負責本地訓練，只有彙總後的模型更新會在不同司法管轄區之間移動。原本用於法遵的相同政策、命名空間邊界與治理控制，會成為分散式 AI 系統的基礎。
對平台團隊來說，問題已經不再是主權要求是否會到來。它們已經在影響採購決策、基礎設施設計與營運模式。
好消息是，這些基礎構件其實已經存在。Kubernetes 提供編排與政策框架。OpenStack 提供基礎設施的根基。GitOps、政策引擎、軟體供應鏈安全與身分識別，則補齊了整體圖像。
多年來，雲端基礎設施一直以集中化作為最佳化方向。主權則把方向推向另一端：更多區域控制、更高透明度，以及更強的營運主導權。
問題已不再是主權是否會影響基礎設施設計。
問題是，主權究竟會停留在組織的文件紀錄中，還是能成為平台可實際強制執行的能力。
本文討論的許多技術，都是以開放方式開發與營運。歡迎到 GitHub 探索 VEXXHOST 的開源工作與貢獻：https://github.com/vexxhost。