https://yennj12.js.org/yennj12_blog_V4/tags/kms/Recent content in KMS on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 26 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part9-security-compliance-data-governance-zh/Sun, 26 Jul 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-system-on-native-aws-part9-security-compliance-data-governance-zh/大部分團隊做 AI 的資安是「上線後補」:先把系統做出來,等法遵來問「資料會不會流到外面」「病歷有沒有加密」「誰存取過這些資料」時,才發現整套架構要重來。 在受管制的產業,順序是反的:資安與合規是上線的門票,不是上線後的裝飾。資料能不能不經過公網、金鑰是不是你自己掌握、個資有沒有去識別化、每一次存取有沒有留痕、模型會不會被誘導洩漏敏感資料——這些不通過,系統再聰明也不能上線。 好消息是,在 AWS 上這些大多是「設定」而非「重寫」:PrivateLink 讓 Bedrock 呼叫永不觸網、KMS 讓你掌握金鑰、SCP 從組織層畫紅線、Macie 自動掃出散落的個資。 這是 Part 9:把橫跨前面所有系統的資安、合規、資料治理維度,一次講透——並且用 CDK 把它們變成基礎設施的一部分,而不是文件裡的承諾。 一、情境與痛點:合規是門票,不是裝飾 前面八篇的系統,只要換一個場景就全部進入「受管制」狀態: RAG 問答的文件是病歷(HIPAA)、IDP 處理的是含個資的合約(GDPR/個資法)、推薦與風控碰的是金流與消費行為(PCI DSS)。 這些場景下,一個看似無害的設計會變成合規事故:把 prompt 送去區域外的模型端點(資料跨境)、向量庫沒加密(靜態資料未保護)、log 裡印出完整 prompt 含身分證號(PII 外洩)、沒人知道誰在何時存取了哪份病歷(稽核缺口)。 企業 AI 的資安可以拆成五個必須同時成立的問題: 問題 對應控制 沒做的後果 ────────────────────────────────────────────────────────────────────── ① 資料會不會流到公網? PrivateLink / VPC endpoint 資料跨網,合規直接不過 ② 資料有沒有全程加密? KMS 客戶金鑰(CMK)+ TLS 靜態/傳輸未加密,稽核失敗 ③ 個資有沒有被找出並保護? Macie + Comprehend PII 散落的個資 = 未爆彈 ④ 誰能存取什麼資料? Lake Formation + IAM 細粒度 權限過大 = 內部威脅 ⑤ 每次存取有沒有留痕?