AI 工作負載的 IAM 與 Amazon Bedrock 安全

IAM 與 Amazon Bedrock 安全，是指一套由 AWS Identity and Access Management 架構、Amazon Bedrock 資源政策、網路管控與加密設定共同組成的機制，用來決定誰可以呼叫基礎模型、可以呼叫哪些基礎模型、推論流量從哪條路徑傳遞，以及流入模型微調工作和知識庫的資料如何受到保護。在 Amazon Bedrock 上，身份與存取管理從來不是選項——每一次 InvokeModel、InvokeAgent、GetFoundationModel 和 CreateKnowledgeBase API 呼叫，都必須通過 AWS IAM 的評估、可選的 VPC Endpoints 政策篩選，以及可選的 AWS KMS 客戶自管金鑰靜態加密。若這四層中有任何一層設定錯誤，生成式 AI 工作負載就可能洩漏提示詞資料、因昂貴的基礎模型而造成超支，或者把私有微調資料暴露給不該存取的 principal（主體）。

在 AIF-C01 考試的第五領域「AI 解決方案的安全性、合規與治理」中，考題要求你能辨別 Amazon Bedrock 所開放的確切 IAM 動作、判斷何時應附加 Bedrock 資源型政策而非身份型 IAM Policy、理解 Bedrock VPC Endpoints 如何讓推論流量不經過公開網路，以及說明為何 AWS KMS 客戶自管金鑰更適合用於微調資料集和知識庫向量嵌入。本指南以白話文逐層拆解 IAM 與 Amazon Bedrock 安全的完整架構，搭配三個各具特色的類比，最後以 least privilege（最小權限原則）實戰手冊和 AIF-C01 專用 FAQ 收尾。

IAM 與 Amazon Bedrock 安全是什麼？

IAM 與 Amazon Bedrock 安全，是 AWS 責任共擔模型中屬於客戶端的那一層，負責管控對 Amazon Bedrock 基礎模型、代理程式（Agent）、知識庫和微調工作的存取。AWS 負責管理並保護 Amazon Bedrock 的底層服務平面——推論叢集、AWS 代管的模型權重、實體資料中心——但你必須決定哪些 IAM principal 可以呼叫 bedrock:InvokeModel、可以存取哪些基礎模型 ARN、流量是否走 VPC Endpoints，以及靜態資料是否以 AWS KMS 客戶自管金鑰保護。

每一個 Amazon Bedrock API 請求都要通過相同的三道關卡。第一道：AWS IAM 評估呼叫端 principal 所附加的身份型政策，以及目標模型、代理程式或知識庫上所附加的 Bedrock 資源型政策。第二道：若請求是透過 VPC Endpoints 抵達，端點政策會額外套用一層允許／拒絕過濾。第三道：當操作需要讀寫持久性資料——訓練檔案、自訂模型成品、知識庫向量嵌入、預置吞吐量（Provisioned Throughput）中繼資料——AWS KMS 會強制執行所選擇的金鑰政策。三道關卡中只要有一道失敗，請求就會被拒絕。這正是 IAM 與 Amazon Bedrock 安全在 AIF-C01「安全性、合規與治理」領域佔有高比重的原因。

IAM 與 Amazon Bedrock 安全為何在 AIF-C01 至關重要？

AIF-C01「AI 解決方案的安全性、合規與治理」領域佔考試比重 14%，而 IAM 與 Amazon Bedrock 安全相關題目主導了整個領域，因為它們與所有其他生成式 AI 主題都有交集。提示詞工程的題目，一旦 IAM Policy 封鎖了某個特定基礎模型，馬上就變成安全題。知識庫的題目，一旦用 AWS KMS 客戶自管金鑰加密嵌入向量，馬上就變成安全題。因此，精通 IAM 與 Amazon Bedrock 安全不只在第五領域有回報，在多個考試領域都能同時得分。

白話文解釋 IAM 與 Amazon Bedrock 安全

抽象的 IAM 政策，對應到具體的生活情境後更容易記憶。以下三個各自獨立的類比，合起來涵蓋 IAM 與 Amazon Bedrock 安全的所有核心概念。

類比一：大樓門禁卡與分級鑰匙系統

把 Amazon Bedrock 想像成一棟企業大樓的中控室。每個基礎模型（Anthropic Claude、Meta Llama、Amazon Titan、Cohere Command）是一間有門鎖的專業會議室。IAM Policy 是你的門禁卡的權限設定——卡片上清楚記載你可以刷開哪幾間會議室、在哪個時段、從哪個入口進入。如果你的門禁卡只開放「Claude 會議室，星期一到五，早九到晚六」，你就算半夜站在 Llama 會議室門口求情，感應器也不會有任何反應。

保險箱存放公司最機密的資料——微調訓練集、知識庫向量嵌入、自訂模型成品——保險箱的密碼就是 AWS KMS 客戶自管金鑰。只有名字登記在「授權使用名單（金鑰政策）」上的人才能開鎖，而名單的管理權在你，不在 AWS。VPC Endpoints 則是棟內的獨立電梯間：員工搭乘這部電梯傳遞文件，流程完全不經過大廳——外部人員根本看不到你在傳遞什麼。AWS CloudTrail 是全棟的門禁刷卡記錄系統，每一次開門、每一次開保險箱，都有時間戳記和人員姓名，且記錄無法竄改。

類比二：醫院藥局的管制藥品領藥流程

想像 Amazon Bedrock 是一座大型醫院的中央藥局，每種基礎模型是一種管制藥品，效果強大但不能隨便拿取。IAM Policy 是醫師處方箋——上面明確寫著：哪位患者（principal）、可以領哪種藥（模型 ARN）、劑量幾何（呼叫頻率）、從哪個藥局窗口（endpoint）領藥。沒有處方箋，藥師一律不給藥；處方箋寫「A 藥」，你也不可能換成「B 藥」拿走。

bedrock:InvokeModel 是實際取藥的動作，bedrock:GetFoundationModel 只是查看藥品說明書（查詢模型中繼資料），兩者完全不同。資源型政策是藥局在某個藥品儲存格上貼的告示：「此藥僅供第三院區的醫師憑處方領取」——限制從外部帳號取用自訂模型的存取來源。KMS 客戶自管金鑰是儲存珍貴配方（訓練資料、嵌入向量）的保險冰箱密碼，管理權只在你的組織手中，AWS 無法代為開鎖。

類比三：機場的行李安檢與 VIP 專屬通道

把生成式 AI 的推論請求想像成機場的行李運送流程。正常旅客（工作負載）把行李交給公開航站大廳的報到櫃台（公開 Bedrock API）——行李會在開放的大廳中接受多個安檢環節，外界人士可以觀察整個流程。VPC Endpoints（由 AWS PrivateLink 驅動） 則是航空公司的 VIP 專屬通道：行李從停機坪直接走內部輸送帶送上飛機，完全不經過公開大廳，外部人員看不到貨物內容也無法攔截。

IAM Policy 是這條 VIP 通道的憑證審查：只有持有特定識別碼的行李（來自特定 principal 的請求）才能進入通道，其他行李一律打回大廳。KMS 客戶自管金鑰是行李的防拆封鎖扣：就算行李在途中被摸到，沒有正確的解鎖工具也無法開箱。AWS CloudTrail 是機場的飛航黑盒子：每一次進出通道的記錄都按時間序列保存，任何異常都可以事後追蹤溯源。

Amazon Bedrock 的 IAM Action 全覽

Amazon Bedrock 開放了數十個 IAM action，但其中有一小部分在 AIF-C01 反覆出現。了解每個 API 呼叫對應哪個 action，以及每個 action 接受哪種 resource（資源）ARN 格式，是提升 IAM 與 Amazon Bedrock 安全得分最直接的槓桿。

推論類 action

• bedrock:InvokeModel — 對基礎模型執行同步推論。Resource ARN 格式：AWS 提供的模型用 arn:aws:bedrock:<region>::foundation-model/<model-id>；你的微調模型用 arn:aws:bedrock:<region>:<account>:custom-model/<base-model>/<custom-model-id>。這是 IAM 與 Amazon Bedrock 安全考題中最常被測驗的 IAM action。
• bedrock:InvokeModelWithResponseStream — 串流版本；授予 InvokeModel 不會自動授予串流版本。當應用程式需要串流時，least privilege（最小權限原則）政策應同時列出兩個 action。
• bedrock:InvokeAgent — 呼叫 Amazon Bedrock Agent，Agent 可代表你呼叫 action group 和知識庫。Resource ARN 格式：arn:aws:bedrock:<region>:<account>:agent-alias/<agent-id>/<alias-id>。
• bedrock:Retrieve 與 bedrock:RetrieveAndGenerate — 用於擷取增強生成（RAG）模式的知識庫擷取 action。

唯讀與探索類 action

• bedrock:GetFoundationModel — 傳回特定基礎模型的中繼資料（上下文視窗、模態、授權），不執行推論。
• bedrock:ListFoundationModels — 列出呼叫端帳號在目前 Region 可存取的模型。
• bedrock:GetModelInvocationLoggingConfiguration — 讀取帳號層級的呼叫記錄設定。

微調與知識庫類 action

• bedrock:CreateModelCustomizationJob — 啟動微調或持續預訓練工作。此 action 需要存取 Amazon S3 的訓練資料，以及一個 Amazon Bedrock 可以假冒（assume）的 IAM service role。
• bedrock:CreateKnowledgeBase — 建立新知識庫及相關向量存放設定。
• bedrock:AssociateAgentKnowledgeBase — 將知識庫附加到代理程式。
• bedrock:CreateProvisionedModelThroughput — 為基礎或自訂模型佈建專屬吞吐量。

鎖定 Bedrock Action 的身份型 IAM Policy

IAM 與 Amazon Bedrock 安全的預設模式是身份型 IAM Policy，附加在需要呼叫 Amazon Bedrock 的 principal 上——通常是由 AWS Lambda 函數、Amazon ECS 任務、透過 IRSA 的 Amazon EKS Pod，或 Amazon EC2 執行個體設定檔所假冒的 IAM Role。

最精簡的 InvokeModel 政策

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeClaudeSonnetOnly",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0"
    }
  ]
}

這份政策只授予一個基礎模型、一個 Region、附加到的那個 principal。它刻意省略了 bedrock:*、Resource: "*" 和 GetFoundationModel。如果應用程式之後需要在下拉選單列出可用模型，請另外新增 bedrock:ListFoundationModels 陳述句（statement），而不是擴大原有的推論授權範圍。

加上模型 ARN 條件（Condition）

IAM condition（條件）讓你能表達更精細的規則。Bedrock 的條件鍵 bedrock:FoundationModelId，以及全域條件鍵 aws:RequestedRegion、aws:SourceVpce、aws:PrincipalTag，可以組合成強大的防護欄。

{
  "Effect": "Allow",
  "Action": "bedrock:InvokeModel",
  "Resource": "arn:aws:bedrock:*::foundation-model/*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    },
    "ForAllValues:StringLike": {
      "bedrock:FoundationModelId": [
        "anthropic.claude-3-*",
        "amazon.titan-*"
      ]
    },
    "StringEquals": {
      "aws:SourceVpce": "vpce-0123456789abcdef0"
    }
  }
}

這份政策現在要求三個條件同時成立：呼叫必須指向美國東部（維吉尼亞北部）或美國西部（奧勒岡）Region；基礎模型必須符合 Anthropic Claude 3 系列或任何 Amazon Titan 模型；且呼叫必須來自特定的 Bedrock VPC Interface Endpoint。三個條件缺少任何一個，請求就會被拒絕。

將 InvokeAgent 與 InvokeModel 分開授予

授予 bedrock:InvokeAgent 不會自動授予 bedrock:InvokeModel，反之亦然。Amazon Bedrock Agent 會使用代理程式自身的 service role 在內部呼叫基礎模型，因此呼叫端的 principal 只需要 bedrock:InvokeAgent 加上代理程式別名（alias）的 ARN。這種分離方式讓呼叫端 principal 的影響範圍維持在最小——即使前端 Lambda 函數遭到入侵，攻擊者也無法直接呼叫代理程式核准清單以外的任何基礎模型。

CreateKnowledgeBase 與 service role 模式

bedrock:CreateKnowledgeBase 需要三件事同時成立：呼叫端的身份型 IAM Policy 必須允許 bedrock:CreateKnowledgeBase；呼叫端必須對知識庫執行期間所使用的 Bedrock service role 擁有 iam:PassRole 權限；而那個 Bedrock service role 本身也必須具備存取底層 Amazon S3 資料來源、Amazon OpenSearch Serverless collection（或其他向量存放區），以及任何涉及的 AWS KMS 客戶自管金鑰的權限。

Bedrock 資源型政策

Bedrock 資源型政策附加在 Bedrock resource（資源）本身——自訂模型、預置吞吐量單元或代理程式——而非附加在呼叫端 principal 上。資源型政策是 Amazon Bedrock 實現跨帳號模型存取的機制，讓外部帳號無需在模型擁有帳號中假冒角色。

資源型政策的適用範圍

Amazon Bedrock 主要在自訂模型（基礎模型的微調版本）上支援資源型政策。當帳號 A 微調了一個模型並想讓帳號 B 呼叫時，帳號 A 在自訂模型 ARN 上附加一份資源型政策，允許帳號 B 的特定 principal 執行 bedrock:InvokeModel。帳號 B 仍然需要一份身份型 IAM Policy 允許對同一個自訂模型 ARN 執行 bedrock:InvokeModel——跨帳號存取永遠需要兩側都完成握手。

範例：允許夥伴帳號呼叫自訂模型

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPartnerAccountInvoke",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222233334444:role/PartnerInferenceRole"
      },
      "Action": "bedrock:InvokeModel",
      "Resource": "arn:aws:bedrock:us-east-1:111122223333:custom-model/anthropic.claude-3-haiku-20240307-v1:0/my-custom-model-id",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-0abcdef1234567890"
        }
      }
    }
  ]
}

這份資源型政策只授予一個外部 IAM Role 呼叫一個自訂模型的權限，且只能透過一個特定的 Bedrock VPC Interface Endpoint。搭配帳號 B 中映射相同 Resource 的身份型 IAM Policy，跨帳號模型存取的完整模式就此形成。

何時用資源型政策，何時用 assume-role 模式

• 資源型政策 — 當外部帳號的唯一需求是直接呼叫自訂模型，且不想管理額外的 STS session 時，最為合適。營運負擔較低。
• Assume-role 模式 — 當外部帳號需要更廣泛的存取（列出、呼叫、更新標籤、監控指標），或你想用單一 IAM Role 統一管控所有操作時，最為合適。

用 Bedrock VPC Endpoints 實現網路隔離

預設情況下，Amazon Bedrock API 透過公開端點存取（runtime 用 bedrock.<region>.amazonaws.com；推論用 bedrock-runtime.<region>.amazonaws.com）。「公開」在這裡的意思是透過公共 DNS 解析——即使是沒有公開 IP 的 Amazon EC2 執行個體，流量仍會經過 NAT gateway 才能抵達公開端點。對於受法規管制的工作負載而言，這個額外的跳點是不可接受的。

Bedrock VPC Interface Endpoint 的作用

Amazon Bedrock VPC Interface Endpoint，由 AWS PrivateLink 驅動，在你的 VPC 內部為 Bedrock runtime API 和 Bedrock agent runtime API 建立私有 IP 位址。VPC 內部 principal 發出的請求解析到這些私有 IP，流量通過 AWS 骨幹網路傳輸，完全不會經過公開網路或 NAT gateway。兩個獨立的端點服務名稱涵蓋常見的使用場景：

• com.amazonaws.<region>.bedrock-runtime — 用於 InvokeModel 和 InvokeModelWithResponseStream。
• com.amazonaws.<region>.bedrock-agent-runtime — 用於 InvokeAgent、Retrieve 和 RetrieveAndGenerate。

端點政策作為額外的防護欄

VPC Interface Endpoint 本身攜帶端點政策，這是一份 IAM 語法文件，在身份型政策和資源型政策之外額外進行評估。一個常見的強化模式是：端點政策只允許該 VPC 核准的特定基礎模型 ARN，如此一來，即使 VPC 內部某個 principal 遭到入侵，且其身份型政策設定過於寬鬆，也無法呼叫任何未核准的模型。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "bedrock:InvokeModel",
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-text-express-v1"
      ]
    }
  ]
}

讓推論流量完全不走公開網路

搭配兩個輔助管控措施，才能真正讓推論流量保持私有。第一，在身份型 IAM Policy 上附加 aws:SourceVpce 或 aws:SourceVpc 這類 IAM condition，讓來自預期 VPC 或端點以外的呼叫，即使持有有效憑證也會被拒絕。第二，移除承載生成式 AI 工作負載的子網路對外的 NAT gateway 出口路由——若設定錯誤的 principal 試圖連線公開 Bedrock 端點，封包將無路可走。

用 AWS KMS 客戶自管金鑰加密

Amazon Bedrock 預設使用 AWS KMS 的 AWS 受管金鑰對所有靜態持久性資料加密。對於低敏感度工作負載這已足夠，但對於受法規管制的資料——私有微調語料庫、從機密文件衍生的嵌入向量、預置吞吐量關聯設定——AWS 最佳實踐和 AIF-C01 考試指引都指向 AWS KMS 客戶自管金鑰（CMK）。

Bedrock 哪些資產可以使用客戶自管金鑰

• 模型微調工作的輸入資料 — 上傳到 Amazon S3 的訓練和驗證資料，應已存放在以客戶自管金鑰加密的 bucket 中；Bedrock 透過 service role 的 kms:Decrypt 權限讀取這些物件。
• 自訂模型成品 — 微調工作的輸出結果。在微調工作中設定客戶自管金鑰，Bedrock 就會用該金鑰包裝產生的自訂模型權重。
• 知識庫嵌入向量 — 存放在 Amazon OpenSearch Serverless、Amazon Aurora PostgreSQL（pgvector）或其他支援存放區中的向量，應以客戶自管金鑰加密，且金鑰政策需與知識庫 service role 對齊。
• Agent session 狀態 — 對於保留狀態的 Amazon Bedrock Agent，session 資料可以用客戶自管金鑰加密。
• 預置吞吐量中繼資料 — 與預置吞吐量單元關聯的設定資料。

金鑰政策和 IAM Policy 同樣重要

客戶自管金鑰要能發揮作用，其金鑰政策必須正確授權 Bedrock service role 呼叫 kms:Decrypt、kms:GenerateDataKey 和 kms:DescribeKey。常見錯誤是在 IAM Policy 中授予 principal（IAM Role）存取，卻忘記在 KMS 金鑰政策中授予同一個 principal。沒有金鑰政策的授予，解密就會失敗，導致知識庫擷取或微調工作出錯。

{
  "Sid": "AllowBedrockServiceRoleToDecrypt",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/AmazonBedrockExecutionRoleForKnowledgeBase"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

客戶自管金鑰 vs AWS 受管金鑰

跨帳號模型存取模式

大型組織通常會設立一個共用機器學習資產的 AWS 帳號，以及多個供各產品團隊使用資產的獨立帳號。IAM 與 Amazon Bedrock 安全針對這種架構提供兩種模式。

模式 A：在自訂模型上附加資源型政策

帳號 A（提供者）微調自訂模型，並附加 Bedrock 資源型政策，點名帳號 B（消費者）中特定的 IAM principal。帳號 B 附加一份身份型 IAM Policy，同樣參照相同的自訂模型 ARN。來自帳號 B 的請求攜帶帳號 B 的憑證，直接到達自訂模型，兩份政策都會被評估——聯集允許規則要求兩份政策都授予，呼叫才能成功。

• 優點：設定簡單、無 STS session、營運成本低。
• 缺點：只適用於支援資源型政策的資源（主要是自訂模型）；無法擴展到所有 Bedrock API。

模式 B：跨帳號 IAM Role 搭配 sts:AssumeRole

帳號 A 建立一個 IAM Role，其信任政策允許帳號 B 的 principal 假冒它。該 Role 擁有一份 bedrock:InvokeModel 鎖定相關模型 ARN 的身份型 IAM Policy。帳號 B 的工作負載呼叫 sts:AssumeRole，取得短期憑證後，以這些憑證呼叫 Amazon Bedrock——呼叫看起來像是從帳號 A 發出的。

• 優點：適用於所有 Bedrock API；將可觀察性集中在帳號 A 的 AWS CloudTrail；可以利用 session tag 實現屬性型存取控制。
• 缺點：需要額外的 STS 跳點；消費者端要管理短期憑證。

搭配 Amazon Bedrock Agent 的混合模式

對於 Amazon Bedrock Agent，常見模式是在中央帳號部署代理程式，並設定可以指向消費者帳號資源的 action group。代理程式的 service role 透過 STS 假冒各消費者帳號的跨帳號 IAM Role。這樣既能讓生成式 AI 推理層集中管理且可稽核，又允許代理程式存取依法規必須存放在特定消費者帳號的資料。

生成式 AI 應用程式的 Least Privilege（最小權限原則）實戰手冊

一份具體的實戰手冊，能把分散的 IAM 與 Amazon Bedrock 安全概念轉化為可重複執行的查核清單。對任何新的生成式 AI 工作負載，請依序執行以下步驟。

步驟一 — 列出工作負載實際需要的基礎模型

列出應用程式依賴的確切基礎模型 ID（及版本）。不要「以防萬一」地多加模型——每多一個模型，影響範圍就擴大一些，潛在費用也跟著增加。如果產品負責人要求彈性，列出兩到三個核准的模型，而非整個目錄。

步驟二 — 為每個工作負載角色撰寫身份型 IAM Policy

針對每個邏輯工作負載（Web 層、背景工作、微調工作、知識庫擷取）建立一個 IAM Role，並附加只列出該角色所需 Bedrock action、鎖定步驟一模型 ARN 的身份型 IAM Policy。除了平時停用的緊急「break-glass」角色之外，避免在任何地方使用 bedrock:*。

步驟三 — 為昂貴或未核准的模型加上明確拒絕（deny）防護欄

加入一個明確拒絕特定高成本或政策限制基礎模型的 deny 陳述句。由於任何適用 IAM Policy 中的明確 deny 會覆蓋所有 allow，在 Permission Boundary 或 SCP 層設置單一 deny 陳述句就是耐用的成本管控槓桿。

步驟四 — 強制要求透過 VPC Interface Endpoint

在身份型 IAM Policy 中加入 aws:SourceVpce 或 aws:SourceVpc condition，使每次成功的呼叫都必須通過核准的 Bedrock VPC Interface Endpoint。搭配映射相同允許模型 ARN 清單的端點政策。

步驟五 — 以客戶自管金鑰加密持久性資料

為工作負載建立（或重用）一個 AWS KMS 客戶自管金鑰，在金鑰政策中授予 Bedrock service role kms:Decrypt 和 kms:GenerateDataKey，並讓所有相關的 Amazon S3 bucket、Amazon OpenSearch Serverless collection 和知識庫都指向該金鑰。

步驟六 — 開啟 Bedrock 呼叫記錄與 AWS CloudTrail 資料事件

在 Amazon Bedrock 中啟用模型呼叫記錄（將提示詞和完成內容寫入 Amazon CloudWatch Logs 或 Amazon S3，並以客戶自管金鑰加密），並確保帳號層級的 AWS CloudTrail trail 有擷取管理事件。這樣就能關閉稽核迴圈，讓每一次 InvokeModel、InvokeAgent、CreateKnowledgeBase 和 GetFoundationModel 都有跡可循。

步驟七 — 每季用 IAM Access Analyzer 定期審查

每季對生成式 AI 的 IAM Role 執行 AWS IAM Access Analyzer 的未使用存取分析，並剪除任何未被執行過的 action 或模型 ARN。Least privilege（最小權限原則）不是一次性的工作，而是定期的衛生維護任務。

AWS CloudTrail 稽核 Amazon Bedrock

AWS CloudTrail 是每一個 Amazon Bedrock API 呼叫的稽核記錄系統。在 IAM 與 Amazon Bedrock 安全中，CloudTrail 提供兩種截然不同的能力，請勿混淆。

管理事件 vs 資料事件

• 管理事件是控制平面的 API 呼叫——CreateKnowledgeBase、CreateAgent、CreateModelCustomizationJob、PutModelInvocationLoggingConfiguration、DeleteCustomModel。每個 AWS 帳號的預設 AWS CloudTrail trail 預設就會記錄管理事件。
• 資料事件是高流量的資料平面呼叫。對於 Amazon Bedrock，InvokeModel、InvokeModelWithResponseStream、InvokeAgent、Retrieve 和 RetrieveAndGenerate 都是資料事件，若想加以擷取，必須在 CloudTrail trail 中明確啟用。

模型呼叫記錄

除了 AWS CloudTrail 之外，Amazon Bedrock 還提供模型呼叫記錄，這是一個獨立的記錄功能，可擷取完整的提示詞、完整的模型回應及 token 用量指標。模型呼叫記錄可以寫入 Amazon CloudWatch Logs、Amazon S3 或兩者同時，且目的地本身應以 AWS KMS 客戶自管金鑰加密，確保含有敏感資料的提示詞全程受到保護。

偵測濫用行為

AWS CloudTrail 和模型呼叫記錄合力能發現的常見濫用模式包括：某個 principal 突然對頂級模型發出大量 InvokeModel 呼叫（而該 principal 平時只使用較便宜的模型）；大量 GetFoundationModel 呼叫針對數十個模型 ID（偵察行為）；來自非預期 principal 的 CreateModelCustomizationJob（透過微調進行資料外洩）；以及 AssumeRole 鏈最終連到 Bedrock 呼叫，且來源 IP 在核准的 VPC Interface Endpoint 範圍之外。

常見陷阱與考試易錯點

AIF-C01 的 IAM 與 Amazon Bedrock 安全考題反覆使用固定的幾種干擾選項模式，認識它們能為你節省考試時間。

陷阱一 — 混淆 InvokeModel 和 GetFoundationModel

InvokeModel 執行推論並產生費用。GetFoundationModel 傳回中繼資料且免費。如果場景說的是「在不執行推論的情況下讀取模型的上下文視窗」，要的是 GetFoundationModel，而非 InvokeModel。

陷阱二 — 以為 service role 用 bedrock:* 沒問題

擁有 bedrock:* 的 service role 讓知識庫、代理程式或微調工作有權呼叫任何基礎模型，包括昂貴的模型。請務必將 service role 縮限到它實際用於嵌入、摘要或生成的特定基礎模型 ARN。

陷阱三 — 忘記跨帳號讀取時的 KMS 授權

跨帳號存取以客戶自管金鑰加密的 Amazon S3 訓練資料集，要求消費者帳號也必須被允許在 KMS 金鑰政策中。允許 s3:GetObject 的 IAM Policy 還不夠——沒有金鑰政策層級的 kms:Decrypt，讀取就會失敗，且錯誤訊息看起來像是 S3 問題，實際上卻是 KMS 問題。

陷阱四 — 以為 VPC Interface Endpoint 代表加密

Bedrock VPC Interface Endpoint 改變的是網路路徑，而非加密方式。傳輸中的 payload 仍由 TLS 保護，靜態資料仍由 AWS KMS 保護——端點本身無法取代兩者其中任一。AIF-C01 喜歡從兩個方向各出一題考這個觀念。

陷阱五 — 在生產環境的生成式 AI 工作負載使用 IAM User

生產環境的 Amazon Bedrock 呼叫端應一律使用 IAM Role（Lambda execution role、ECS task role、EKS IRSA、EC2 instance profile，或透過 IAM Identity Center 的聯合身份角色）。在程式碼中嵌入 IAM User 長期存取金鑰，是 AIF-C01 考試預期你直接排除的經典反模式。

監控與可觀察性

可觀察性是 IAM 與 Amazon Bedrock 安全迴圈的最後一道關卡。以下四個訊號在每個生產環境的生成式 AI 工作負載中都值得建立儀表板。

Amazon CloudWatch 的 Bedrock 呼叫指標

Amazon Bedrock 會針對每個基礎模型發出 Amazon CloudWatch 指標，包括 Invocations、InvocationLatency、InputTokenCount、OutputTokenCount 和 InvocationClientErrors。InvocationClientErrors 突然飆升且錯誤碼為 AccessDeniedException，是 IAM Policy 修改破壞了工作負載，或有惡意呼叫者在探測 API 的第一個警示訊號。

IAM Access Analyzer 的發現結果

AWS IAM Access Analyzer 持續掃描資源型政策，當 Bedrock 自訂模型、代理程式，或存放訓練資料的 Amazon S3 bucket 可被信任邊界外部存取時，會浮出發現結果（finding）。發現結果應在數小時內分類處理；意外公開的微調資料集是嚴重的資料外洩事件。

AWS Config 規則

AWS Config 支援受管規則，可以檢查 Amazon Bedrock 微調工作和知識庫是否設定了客戶自管金鑰、每個使用 Bedrock 的 Region 是否存在 VPC Interface Endpoint，以及是否啟用了 Bedrock 的 AWS CloudTrail 資料事件。持續合規檢查能比季度稽核更快發現設定漂移。

成本異常偵測

非預期的 bedrock:InvokeModel 活動往往在出現在成本儀表板上，比安全儀表板更早。AWS Cost Anomaly Detection 設定一條針對 Amazon Bedrock 服務的規則，是一個低成本、高訊噪比的防護層，在真實案例中已成功在數分鐘而非數天內發現生成式 AI 工作負載的憑證遭到入侵。

常見問題 — AIF-C01 的 IAM 與 Amazon Bedrock 安全

Q1：呼叫 Amazon Bedrock 推論所需的最低 IAM 權限是什麼？

呼叫端 principal 至少需要對指定基礎模型 ARN 的 bedrock:InvokeModel 權限。若需要串流回應，還要加上 bedrock:InvokeModelWithResponseStream。純推論不需要其他 Bedrock action，且應避免使用 Resource: "*"，將權限鎖定在核准的基礎模型 ARN 上。

Q2：Bedrock VPC Interface Endpoint 會加密我的提示詞嗎？

不會。VPC Interface Endpoint 改變的是網路路徑，使 Amazon Bedrock 流量不需穿越公開網路——它不會在 TLS 既有的保護之外增加額外加密。傳輸中的提示詞無論使用公開端點或 Interface Endpoint，都由 TLS 1.2+ 保護。靜態資料的加密仍需要 AWS KMS 客戶自管金鑰。請把 VPC Interface Endpoint 視為網路管控，AWS KMS 視為加密管控。

Q3：何時用 Bedrock 資源型政策，何時用 assume-role 模式？

當唯一目標是讓外部 AWS 帳號呼叫特定自訂模型，且不想管理 STS session 時，使用資源型政策。當外部帳號需要多個 Bedrock API、你想讓跨帳號呼叫顯示在模型擁有帳號的 AWS CloudTrail 中，或需要用 session tag 驅動屬性型存取控制時，使用 assume-role 模式。兩者可以在同一套架構中並存。

Q4：為什麼 CreateKnowledgeBase 需要 iam:PassRole？

因為你建立的知識庫在執行期間是以 Bedrock service role 運作的——它需要讀取 Amazon S3 資料來源、寫入向量存放區，以及呼叫 kms:Decrypt。AWS IAM 只允許 principal 在明確被授予目標 service role ARN 的 iam:PassRole 時，才能把該 service role 指派給新資源。這是通用的 AWS IAM 安全機制，並非 Bedrock 特有的規則。

Q5：Amazon Bedrock 本身是免費的嗎？IAM、VPC Interface Endpoint 和 KMS 元件呢？

AWS IAM 免費。AWS KMS 按每個客戶自管金鑰每月收費，另加每一萬次 API 呼叫費用。VPC Interface Endpoints 按每個端點每小時收費，另加資料處理費用。Amazon Bedrock 本身按每個基礎模型每千個輸入和輸出 token 計費，另有預置吞吐量承諾費用。CloudTrail 管理事件免費；資料事件按每個事件收費。

Q6：我可以在整個組織範圍封鎖特定的基礎模型嗎？

可以。在 AWS Organizations 的**服務控制政策（SCP）**中附加一個明確 Deny，將 bedrock:InvokeModel 鎖定到不想要的基礎模型 ARN。由於 SCP 中的明確 deny 會覆蓋所有成員帳號中所有 allow，即使成員帳號的 IAM Policy 原本允許該模型，它也會變得無法存取。這是在大型組織中強制執行核准模型清單的最耐用管控措施。

Q7：如何稽核上個月呼叫了哪些基礎模型？

啟用 Amazon Bedrock 的 AWS CloudTrail 資料事件和／或 Amazon Bedrock 模型呼叫記錄。CloudTrail 資料事件提供結構化的 InvokeModel 記錄，適合用 Amazon Athena 查詢；模型呼叫記錄提供完整的提示詞和回應，適合特定稽核窗口的詳細審查。兩者互補——CloudTrail 大規模回答「誰、用哪個模型、何時」，呼叫記錄回答特定稽核窗口「說了什麼」。

Q8：對新工作負載而言，單一影響最大的 IAM 與 Amazon Bedrock 安全管控是什麼？

在工作負載 IAM Role 所附加的身份型 IAM Policy 中，將 bedrock:InvokeModel 鎖定到明確的基礎模型 ARN 清單。這一個改變同時強制執行核准的模型清單、防止推論費用失控，並與 AWS least privilege（最小權限原則）對齊。IAM 與 Amazon Bedrock 安全架構中所有其他管控措施——資源型政策、VPC Interface Endpoints、AWS KMS 客戶自管金鑰、AWS CloudTrail 資料事件——都建立在這個基礎之上。

延伸閱讀

• Amazon Bedrock — Identity and Access Management
• Amazon Bedrock — Identity-Based Policy Examples
• Amazon Bedrock — Actions, Resources, and Condition Keys
• Amazon Bedrock — VPC Interface Endpoints (AWS PrivateLink)
• Amazon Bedrock — Data Encryption with AWS KMS
• Amazon Bedrock — Logging API Calls with AWS CloudTrail
• AWS IAM — Policies and Permissions
• AWS KMS — Key Concepts
• AWS AIF-C01 Exam Guide (PDF)