多雲 AI 安全概覽
多雲 AI 部署的安全風險：跨雲攻擊面、憑證管理挑戰、不一致的安全控制，以及 AWS、Azure 與 GCP AI 服務間的治理缺口。
多雲 AI 安全概覽
組織越來越多地將 AI 工作負載部署於多個雲端供應商——在 GCP 的 TPU 基礎設施上訓練、透過 Azure OpenAI 服務以整合 Microsoft 生態系，以及在 AWS Bedrock 上執行推論以存取特定模型。此多雲方法使攻擊面倍增，因為每個雲端有不同的安全模型、IAM 系統與監控能力。雲端之間的接縫——憑證在此交換、資料在此傳輸、模型在此移植——正是最可被利用之漏洞藏匿之處。
為何多雲 AI 常見
組織採用多雲 AI 的理由有幾項，每項都產生獨特的安全挑戰：
| 驅動因子 | 範例 | 安全挑戰 |
|---|---|---|
| 模型可用性 | Bedrock 上的 Claude、Azure 上的 GPT-4、GCP 上的 Gemini | 三個供應商的憑證與存取控制 |
| 同類最佳基礎設施 | 在 GCP TPU 上訓練、在 AWS 上服務 | 雲端間的模型工件傳輸 |
| 合規與駐留要求 | 按地區／雲端的不同資料駐留要求 | 跨司法管轄區與供應商的資料治理 |
| 供應商風險緩解 | 避免單一供應商鎖定 | 不一致的安全政策 |
| 併購整合 | 被併購公司使用不同雲端 | 倉促的跨雲整合 |
| 團隊偏好 | 資料科學團隊偏好 GCP、平台團隊偏好 AWS | 影子 AI 部署 |
跨雲攻擊面
憑證橋接
多雲 AI 需要每個供應商的憑證。這些憑證必須跨供應商儲存、管理與輪換，產生多個暴露點：
| 憑證流動 | 運作方式 | 攻擊向量 |
|---|---|---|
| Azure Key Vault 中的 AWS 金鑰 | Azure 工作負載以儲存於 Key Vault 的 IAM 金鑰存取 AWS Bedrock | 入侵 Key Vault 以取得 AWS 憑證 |
| AWS Secrets Manager 中的 GCP SA 金鑰 | AWS 工作負載以 GCP SA 金鑰存取 Vertex AI | 入侵 Secrets Manager 以取得 GCP 存取 |
| GCP 上的 Azure SP 憑證 | GCP 工作負載以 SP 客戶端密鑰存取 Azure OpenAI | 在 GCP Secret Manager 中找到 SP 憑證 |
| OIDC 聯邦 | 雲原生身分聯邦（AWS IAM 身分供應商、Azure 聯邦憑證） | 聯邦配置漏洞 |
資料傳輸通道
AI 資料透過數個通道在雲端之間流動：
模型工件傳輸
在一個雲端訓練的模型被匯出並部署於另一個雲端。工件透過儲存（S3、Blob、GCS）、直接下載或模型登錄處傳輸。傳輸期間，工件可能儲存於存取控制較弱的中間位置。
訓練資料同步
訓練資料跨雲端複製以進行多雲訓練或災難復原。資料同步工具（rclone、雲原生同步、自訂 ETL）可能在傳輸期間暴露資料。
推論代理
一個雲端上的應用將推論請求代理到另一個雲端的 AI 服務。這些代理配置常包含內嵌憑證，且可能未強制執行與直接 API 存取相同的存取控制。
嵌入與向量同步
向量資料庫或嵌入儲存可能跨雲端複製以最佳化延遲。投毒來源會傳播到所有副本。
不一致的安全政策
每個雲端有不同的安全能力與預設值：
| 安全控制 | AWS | Azure | GCP |
|---|---|---|---|
| AI 特定 IAM | 帶條件鍵的資源層級政策 | 帶範圍的 RBAC 角色 | 帶組織政策的 SA 基礎 |
| 內容過濾 | Bedrock Guardrails（可配置） | Azure Content Safety（可配置） | Vertex AI 安全設定 |
| 網路隔離 | VPC、PrivateLink | VNet、Private Endpoints | VPC、VPC SC |
| 稽核日誌 | CloudTrail（資料事件選用） | Diagnostic Settings（選用） | Cloud Audit Logs（資料存取選用） |
| 威脅偵測 | GuardDuty（AI 涵蓋有限） | Defender for AI | SCC AI 發現（有限） |
在一個雲端套用強安全的組織，可能在另一雲端留下缺口，因為每個雲端的安全工具不同且需要不同專業。
治理缺口
可見性挑戰
沒有單一工具能對多雲 AI 部署提供統一可見性：
- 資產清查缺口：每個雲端有其服務目錄；沒有所有 AI 資產的統一視圖
- 權限蔓延：跨三個供應商的 IAM 政策難以一致稽核
- 成本追蹤：跨供應商的 AI 成本在獨立的計費系統中追蹤
- 合規監控：每個雲端有不同的合規工具與稽核格式
影子 AI
多雲環境使影子 AI 更可能：
- 資料科學家在個人雲端帳號上實驗
- 團隊將模型部署在組織未正式批准的雲端
- 免費等級或試用帳號在沒有安全監督下用於 AI 開發
- 第三方 SaaS AI 工具作為雲端環境之間的橋樑
政策執行
在一個雲端可執行的安全政策可能在另一雲端沒有對應：
| 政策 | AWS 執行 | Azure 執行 | GCP 執行 |
|---|---|---|---|
| 「所有 AI 模型必須有內容過濾」 | Bedrock Guardrails | Azure Content Safety | 自託管模型需要自訂實作 |
| 「AI 端點必須是 VPC 內部」 | VPC PrivateLink | Private Endpoints | VPC SC |
| 「不得有 AI 服務帳號金鑰」 | IAM 最佳實務、角色無金鑰 | Managed Identity | 透過組織政策的 SA 金鑰限制 |
| 「所有 AI 調用須記錄」 | CloudTrail 資料事件 | Diagnostic Settings | 資料存取稽核日誌 |
紅隊評估方法
多雲 AI 評估階段
- 發現：列舉所有雲端供應商的 AI 服務。尋找安全團隊可能不知道的服務。
- 憑證對應：識別所有雲端之間的憑證橋接，並測試是否有暴露。
- 資料流分析：描繪模型、訓練資料與嵌入如何在雲端之間移動。
- 政策缺口分析：比較供應商之間的安全控制，識別不一致之處。
- 跨雲攻擊模擬：執行跨供應商的攻擊情境（見 跨雲攻擊）。
- 控制比較：評估每個供應商對 AI 的安全控制（見 比較矩陣）。
相關主題
- 跨雲攻擊 -- 跨供應商的具體攻擊情境
- 安全控制比較 -- 供應商並排比較
- AWS AI 服務 -- AWS 特定 AI 安全
- Azure AI 服務 -- Azure 特定 AI 安全
- GCP AI 服務 -- GCP 特定 AI 安全
一個組織在 GCP Vertex AI 上訓練模型，並將其部署到 AWS SageMaker 端點。此架構的主要憑證相關風險為何？
為何多雲 AI 被描述為具有「平方的」攻擊面，而不是「兩倍的」攻擊面？
參考資料
- Cloud Security Alliance AI Safety -- 多雲 AI 安全指引
- NIST AI Risk Management Framework -- AI 風險評估方法論