iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
自我挑戰組

《30 天用 GCP Security 打造企業級 AI 安全防線》 系列

企業導入生成式 AI 時,資安討論往往集中在「模型會不會被越獄」「Prompt 會不會被注入」——但在我實際協助金融、製造業客戶的顧問經驗裡,真正造成事故的破口,多數不在模型層,而在平台層:一組權限過寬的 Service Account、一個沒有邊界控制的 Vertex AI 專案、一把寫死在程式碼裡的 API Key。這 30 天,我想用 Google Cloud 原生的安全服務把企業導入 Google AI 服務所需的安全防線,一層一層建起來。

參賽天數 22 天 | 共 22 篇文章 | 1 人訂閱 訂閱系列文 RSS系列文
DAY 1

Day 1|系列開場:為什麼談企業 AI 安全防線要從 GCP Security 談起

Day 1|系列開場:為什麼談企業 AI 安全防線要從 GCP Security 談起 一個被問爛、卻問錯方向的問題 過去一年,只要跟企業客戶聊 AI 安全,十...

2026-08-01 ‧ 由 Fngi 分享
DAY 2

Day 2|GCP 共同責任模型與 AI Workload 的責任邊界

「Google 有幫我顧安全」是一句危險的半真話 雲端運算的共同責任模型(Shared Responsibility Model)大家並不陌生:IaaS 層 G...

2026-08-02 ‧ 由 Fngi 分享
DAY 3

Day 3|Organization Policy:為 AI 專案設計護欄

為什麼要從 Org Policy 開始,而不是先談 IAM 很多團隊導入 AI 專案時,第一件事是開一個新的 GCP 專案、建幾個 Service Accoun...

2026-08-03 ‧ 由 Fngi 分享
DAY 4

Day 4|MODA 風險分類框架 × GCP 原生控制對照

先更正一個常見的稱呼誤用 在正式進入對照之前,有個名詞要先講清楚:數位發展部這套框架的正式名稱是《人工智慧風險分類框架》——是「分類」,不是「分級」。這個用字差...

2026-08-04 ‧ 由 Fngi 分享
DAY 5

Day 5|12 項能力缺口:企業導入 AI 前該補的安全課

為什麼要用「角色」而不是「技術層」來切能力缺口 多數 AI 安全框架(包含昨天談的 MODA 框架、明天要談的 OWASP LLM Top 10)都是用「風險類...

2026-08-05 ‧ 由 Fngi 分享
DAY 6

Day 6|OWASP LLM Top 10 對照 GCP Security 控制項

2025 版跟你熟悉的舊版不一樣,其實2026版剛剛出了^^ 如果你對 OWASP LLM Top 10 的印象還停留在「Prompt Injection、In...

2026-08-06 ‧ 由 Fngi 分享
DAY 7

Day 7|IAM 與 Vertex AI 權限最小化設計

一個 Service Account 幾乎能做完所有事的真實案例 Day2 提過一個場景:某企業的 Gemini API 客服機器人,串接用的 Service...

2026-08-07 ‧ 由 Fngi 分享
DAY 8

Day 8|Service Account 金鑰管理與輪替最佳實踐

長效金鑰是資安團隊最不想承認的未爆彈 一組 Service Account JSON 金鑰檔,預設沒有過期時間。它可能被下載到某個工程師的筆電、貼進某個 CI/...

2026-08-08 ‧ 由 Fngi 分享
DAY 9

Day 9|Workload Identity Federation:告別長效憑證

如果外部系統根本不需要金鑰檔呢 前兩篇的討論,都是「假設你必須用金鑰檔,該怎麼把風險降到最低」。但更根本的解法是:讓外部工作負載(CI/CD pipeline、...

2026-08-09 ‧ 由 Fngi 分享
DAY 10

Day 10|Access Transparency 與 AI 稽核軌跡

稽核軌跡的最後一哩:誰動了你的資料,包含 Google 自己 前面幾篇都在講「企業內部的身份怎麼被稽核」,但還有一塊常被忽略的拼圖:**當你的 AI workl...

2026-08-10 ‧ 由 Fngi 分享