根據 InfoQ 於 2026 年 10 月 26 日由 Leela Kumili 發表的報導，ReadyOn 公開了其 Harmony 勞動力智慧平台在 Amazon Elastic Kubernetes Service（EKS，AWS 的託管 Kubernetes 服務）上的四層租戶隔離架構。Harmony 處理企業客戶的薪資資料、組織階層與營運分析，這些資料一旦跨租戶外洩，影響的不只是隱私，還可能牽動薪資正確性、權限邊界與企業內部治理。因此，ReadyOn 沒有把多租戶安全寄託在單一控制點，而是把隔離拆成 Kubernetes、運算、網路與資料四個層次，並將控制項對照到一套十階段的多租戶威脅模型，用來分段檢查攻擊者可能如何從一個租戶移動到另一個租戶；其中特別關注受損租戶工作負載的橫向移動，也就是攻擊者從某個遭入侵的 Pod 或服務轉向其他系統與租戶的路徑。報導指出，該公司至今的對抗演練尚未產生成功的跨租戶路徑。
背景：共享叢集改變威脅模型
多租戶 SaaS 的經濟效益來自共用基礎設施，但共享也讓威脅模型變得不同。Sparq 的 Principal AWS Engineer William Antonio G 在 LinkedIn 討論這套架構時指出，單一租戶叢集的強化雖然仍有許多細節，但至少是已有大量文件可循的課題；一旦加入多租戶，威脅模型會從根本上改變。這是因為攻擊面不再只是外部攻擊者能否打進來，還包括某個租戶的 Pod、服務帳戶或資料庫連線被控制後，能否穿過共用資源影響另一租戶。史丹佛大學商學研究所（Stanford Graduate School of Business）教授 Mohammad Akbarpour 也在 LinkedIn 評論中提到，更廣泛的挑戰是在推進 AI 能力的同時，讓不可存取的資料與工作流程邊界難以跨越。對 ReadyOn 而言，Harmony 涉及薪資與組織資料，隔離設計必須能回答跨租戶存取是否真的被阻斷，而不只是文件上看起來有區隔。
四層隔離的實際做法
第一層是 Kubernetes 命名空間隔離。ReadyOn 為每個租戶建立專用 namespace，並在其中套用角色型存取控制（RBAC，限制誰能對哪些 Kubernetes 資源執行哪些動作）、資源配額（resource quotas，避免單一租戶耗盡共用資源）、准入控制（admission controls，在資源建立前檢查是否符合規則）以及預設拒絕的網路策略（default deny network policies，未明確允許的流量一律阻擋）。這些資源由 Argo CD ApplicationSets 從 Git 中的設定產生；Argo CD 是 GitOps 持續部署工具，ApplicationSets 讓同一組範本套用到多個租戶，並在有人手動變更時自動調和回預期狀態。換句話說，命名空間不只是分類標籤，而是權限、配額與網路規則的共同邊界。
第二層是運算隔離。ReadyOn 使用 Karpenter 為每個租戶配置專用節點池。Karpenter 是 AWS 環境中用來依工作負載需求建立與調整 Kubernetes 節點的元件；專用節點池的意義在於，租戶的工作負載不必與其他租戶共享底層主機。這裡的關鍵是雙重 taint 策略：節點上帶有兩種標記，一種用來識別租戶，另一種識別工作負載類型；Pod 必須同時容忍這兩種 taint 才能被調度。Taint 是節點用來拒絕不合條件 Pod 的機制，toleration 則是 Pod 宣告自己能接受該標記。ReadyOn 另外用准入控制器檢查 Pod 要求的 toleration 是否與其命名空間所屬租戶一致，避免有人透過錯誤的調度設定把工作負載放到不該去的節點池。這層補上了單純 namespace 無法處理的共用節點風險；AWS 文件也提醒，命名空間、RBAC、配額與網路策略提供的是邏輯隔離，並不能阻止工作負載共用底層節點，若需要更強的分隔，應搭配節點選擇器、親和性規則或 taint 與 toleration。
第三層把執行點往下移到 Kubernetes 之外。ReadyOn 為每個租戶設定 Amazon VPC（Virtual Private Cloud，虛擬私有雲）安全群組，限制資料庫連線只能來自對應的租戶節點池；Kubernetes 網路策略則在命名空間之間維持預設拒絕。EKS 的 API 端點是私有的，存取需經過 VPN、OpenID Connect（一種身分驗證協定，用來確認使用者或服務的身分）與多因素驗證。這樣設計的用意是讓網路控制不只依賴 Kubernetes 物件；即使某個環節的 Pod 網路策略沒有完全覆蓋，VPC 層的安全群組仍能對資料庫連線形成第二道限制。
第四層是資料隔離。ReadyOn 沒有在共用資料庫裡只靠資料列層級過濾來區分租戶，而是為每個租戶使用專用的 Amazon Aurora 叢集。Aurora 是 AWS 的關聯式資料庫服務；專用叢集讓租戶資料在資料庫叢集與儲存資源上分開，降低共用資料庫查詢漏掉過濾條件時直接暴露他人資料的風險。ReadyOn 也使用租戶範圍的 AWS Secrets Manager 路徑、透過 IAM Roles for Service Accounts 取得的短期憑證，以及專用的可觀測性後端。Secrets Manager 用來管理資料庫密碼等敏感設定；把路徑按租戶切開，可避免某租戶的憑證被另一租戶的流程誤用。IAM Roles for Service Accounts 則讓 Kubernetes 服務帳戶取得短期 AWS 憑證，減少長期金鑰留在叢集裡的風險。可觀測性後端用來收集日誌、指標與追蹤，讓不同租戶的觀察資料不要混在一起。
技術脈絡與影響
這套架構的重點不是宣稱任何一層可以單獨完成隔離，而是把控制項視為重疊防禦。ReadyOn 仍保留共享的 EKS 環境，但把租戶邊界延伸到 Kubernetes 之外的調度、AWS 網路與專用資料基礎設施。這樣的取捨有其現實意義：如果每個租戶都建立獨立叢集，營運成本與管理複雜度會大幅上升；反過來，若只靠 namespace 與 RBAC，又難以處理共用節點、網路繞道與資料庫查詢失誤。四層模型試圖在共享 EKS 環境與隔離強度之間取得平衡，讓每個跨租戶路徑至少需要突破多個不同性質的控制點。
可觀測性、成本與限制
不過，分層防禦也帶來新的驗證問題。Juan Pablo Gaviria 在 LinkedIn 評論這套架構時指出，追蹤資料需要把工作負載身分與資料庫、網路層的執行結果串接起來，才能暴露控制項之間的缺口；他並直言，隔離深度若沒有對應的可觀測性深度，與虛假信心沒有太大差別。這個提醒很實際：安全團隊不能只確認策略存在，還要能回答某個租戶的 Pod 是否真的無法連到另一個租戶的 Aurora、某次被拒絕的連線是由哪一層擋下、以及手動變更是否已被 GitOps 調和。ReadyOn 配置了專用可觀測性後端，但報導沒有進一步說明追蹤欄位如何串接每個租戶的工作負載身分與網路、資料庫事件，因此可觀測性是否足以支撐完整的隔離驗證，仍是實務上需要持續檢查的部分。
另一個限制是成本與營運負擔。每個租戶擁有專用節點池、專用 Aurora 叢集與專用可觀測性後端，意味著資源利用率可能低於完全共用模型，租戶數量增加時，節點池管理、配額設定、憑證路徑與監控後端的數量也會同步增加。Karpenter 可以依需求調整節點，但專用池與雙重 taint 的組合仍需精確治理；Argo CD 的自動調和能降低設定漂移，卻也要求 Git 中的設定本身具備嚴格審查。對抗演練至今沒有找到成功跨租戶路徑，是重要的信心來源，但這是一個持續驗證的結果，不是一次設計就能永久保證的結論。對處理薪資與組織資料的平台而言，四層隔離提供了一個可討論的具體範本：先承認共享基礎設施會改變威脅模型，再用命名空間、運算調度、網路安全群組與專用資料庫把跨租戶路徑逐層收窄，最後以可觀測性確認這些控制真的在運作。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。