企業導入生成式 AI 時,資安討論往往集中在「模型會不會被越獄」「Prompt 會不會被注入」——但在我實際協助金融、製造業客戶的顧問經驗裡,真正造成事故的破口,多數不在模型層,而在平台層:一組權限過寬的 Service Account、一個沒有邊界控制的 Vertex AI 專案、一把寫死在程式碼裡的 API Key。這 30 天,我想用 Google Cloud 原生的安全服務把企業導入 Google AI 服務所需的安全防線,一層一層建起來。
Day 1|系列開場:為什麼談企業 AI 安全防線要從 GCP Security 談起 一個被問爛、卻問錯方向的問題 過去一年,只要跟企業客戶聊 AI 安全,十...
「Google 有幫我顧安全」是一句危險的半真話 雲端運算的共同責任模型(Shared Responsibility Model)大家並不陌生:IaaS 層 G...
為什麼要從 Org Policy 開始,而不是先談 IAM 很多團隊導入 AI 專案時,第一件事是開一個新的 GCP 專案、建幾個 Service Accoun...
先更正一個常見的稱呼誤用 在正式進入對照之前,有個名詞要先講清楚:數位發展部這套框架的正式名稱是《人工智慧風險分類框架》——是「分類」,不是「分級」。這個用字差...
為什麼要用「角色」而不是「技術層」來切能力缺口 多數 AI 安全框架(包含昨天談的 MODA 框架、明天要談的 OWASP LLM Top 10)都是用「風險類...
2025 版跟你熟悉的舊版不一樣,其實2026版剛剛出了^^ 如果你對 OWASP LLM Top 10 的印象還停留在「Prompt Injection、In...
一個 Service Account 幾乎能做完所有事的真實案例 Day2 提過一個場景:某企業的 Gemini API 客服機器人,串接用的 Service...
長效金鑰是資安團隊最不想承認的未爆彈 一組 Service Account JSON 金鑰檔,預設沒有過期時間。它可能被下載到某個工程師的筆電、貼進某個 CI/...
如果外部系統根本不需要金鑰檔呢 前兩篇的討論,都是「假設你必須用金鑰檔,該怎麼把風險降到最低」。但更根本的解法是:讓外部工作負載(CI/CD pipeline、...
稽核軌跡的最後一哩:誰動了你的資料,包含 Google 自己 前面幾篇都在講「企業內部的身份怎麼被稽核」,但還有一塊常被忽略的拼圖:**當你的 AI workl...