鐵人檔案
企業導入生成式 AI 時，資安討論往往集中在「模型會不會被越獄」「Prompt 會不會被注入」——但在我實際協助金融、製造業客戶的顧問經驗裡，真正造成事故的破口，多數不在模型層，而在平台層：一組權限過寬的 Service Account、一個沒有邊界控制的 Vertex AI 專案、一把寫死在程式碼裡的 API Key。這 30 天，我想用 Google Cloud 原生的安全服務把企業導入 Google AI 服務所需的安全防線，一層一層建起來。
一個容易被忽略的版本差異：預設值變了 這篇是本週唯一直接碰模型層的內容，跟前面四篇的平台層控制形成「平台 + 模型」雙層防線。開始之前有個重要的版本差異要先講清...
這週在講同一件事的五種切面 Week 2 五篇看似講不同主題，其實都在回答同一個問題：「這個身份，能做多少事、能做多久、有沒有人在看？」 Day7：能做多少事...
IAM 設對了，資料還是可能走錯路 Week 2 把身份層的防線建好了：誰能用哪個 Service Account、金鑰怎麼管、憑證怎麼不落地。但身份層防線防的...
對外的 AI API，等於多了一個新的攻擊面 當企業把 Gemini API 或自建的 Vertex AI Endpoint 包裝成對外服務（例如客服機器人、公...
先更正一個名稱：Cloud DLP 已經不是官方叫法 如果你的簡報或文件裡還在用「Cloud DLP」當作主要名稱，需要更新一下：這項服務已經整合進 Sensi...
這篇要處理的是「另一種金鑰」 Day8 談的是 Service Account 的長效憑證管理，這篇要處理的是另一類同樣常被隨意存放的敏感資訊：API Key、...
前面幾篇都在防「資料靜止時」與「資料傳輸時」，那「資料運算時」呢 Day15、Day16 談的加密與去識別化，保護的是資料靜止（at rest）與傳輸（in t...
這週建立的是一道「資料能不能去、能不能被看懂」的防線 如果說 Week 2 回答的是「這個身份能做多少事」，Week 3 回答的是完全不同的兩個問題：「資料能不...
Model Card 上的安全分數，是誰測的 Google 發布 Gemma 系列模型時，會附上 model card 與安全 benchmark——但這些數字...
掃出弱點之後，下一步是攔截 Day19 的 garak 掃描告訴你「哪裡有洞」，但掃描本身不會幫你補洞。企業要落地的下一步，是在模型與應用程式之間，加上一層 r...
