SageMaker Role Manager 與最小權限模式

SageMaker Role Manager 與最小權限模式，是 MLA-C01 考試中區分「把 AmazonSageMakerFullAccess 掛給每個人」的工程師，與「能設計通過安全審計之角色範疇 IAM」工程師的分水嶺。Domain 4 Task 4.3 測驗你能否為 ML Engineer 與 Data Scientist 和 MLOps Engineer 各自選出正確的角色模板、是否理解 Activity Group 如何組合成角色政策、何時 AWS 受管政策就已足夠、何時必須手工撰寫自訂政策，以及如何用 IAM 條件鍵、ABAC 標籤策略、Service Control Policy 將最小權限從原則落實為可執行的護欄。社群的痛點訊號明確且一致：K21 Academy 回報 SageMaker Role Manager 特定的 IAM 最小權限模式普遍未被充分研讀；來自 Sourabh Sinha 的正式考試心得亦確認包含 Role Manager 的安全性題目出現頻率超出預期。

本指南以 MLA-C01 ML Engineer 視角設計——著重實務 IAM 架構而非 IAM 理論。內容涵蓋 SageMaker Role Manager 的實際產出、四個內建角色與組成它們的 Activity Group、AWS 受管政策與正式環境需求之間的落差、可擴展至多個團隊的 ABAC 標籤藍圖、將成本護欄與安全護欄化為可執行程式碼的 IAM 條件鍵、鎖定整個 ML 帳戶至核准組態的 Service Control Policy，以及 SageMaker Role Manager 產出的角色無法運作時的除錯決策樹。每個 callout 都指向官方 AWS 來源，確保 SageMaker Role Manager 與最小權限模式的權威參考只需一鍵即達。

SageMaker Role Manager 是什麼？

SageMaker Role Manager 是 AWS 內建於 SageMaker 主控台的工具，透過以角色（Persona）為基礎的模板產生 IAM 執行角色，而非要求工程師手工撰寫 IAM 政策 JSON。你選擇 Persona（ML Engineer、Data Scientist、MLOps Engineer、Business Analyst），選擇符合該 Persona 工作流程的 Activity Group，選擇性地套用 IAM 條件與標籤，Role Manager 即產出含有緊縮範疇 Inline Policy 的角色。其輸出是最小權限的起點，而非最終答案——但它是一個結構良好的基準，遠優於手工撰寫的政策，也大幅優於 AmazonSageMakerFullAccess。

SageMaker Role Manager 存在的原因

在 SageMaker Role Manager 出現之前，真實組織中常發生兩件事：第一，團隊把 AmazonSageMakerFullAccess 掛給所有人——該政策過於寬泛（對每個 Bucket 授予 s3:*、對 * 授予 iam:PassRole），但手工撰寫自訂政策很痛苦。第二，資安團隊在真空中手工撰寫自訂政策，往往產出在第一個新工作流程出現時就故障的角色。SageMaker Role Manager 解決了這兩個問題：它給平台團隊一個清楚對應到職能的結構化起點，也給資安團隊一套詞彙（Persona、Activity Group）來推論 ML 角色「應當」被允許做什麼。

SageMaker Role Manager 在主控台的位置

前往 SageMaker AI → Admin configurations → Role Manager。流程分四步：選擇 Persona、設定權限與條件、設定網路存取、審查並建立。輸出是帳戶中含有 Inline Policy 與信任政策的 IAM 角色，信任政策指向 SageMaker 服務主體。角色建立後即與任何其他 IAM 角色行為相同——你可以附加受管政策、編輯 Inline Policy、附加 Permission Boundary，並用 IAM Access Analyzer 稽核它。

Role Manager 不能取代的事

SageMaker Role Manager 不設定目標側的資源層級權限——它不寫 S3 Bucket Policy、KMS 金鑰政策或 VPC Endpoint Policy，它只產出主體側的 IAM。最小權限模式要真正運作，資源側政策（Bucket Policy、Key Policy、Endpoint Policy）必須與角色的 IAM 允許範疇一致。SageMaker Role Manager 與最小權限模式是一套系統，而非單一工具。

白話文解釋 SageMaker Role Manager 與最小權限

三個具體類比讓 SageMaker Role Manager 與最小權限模式更容易記憶。

類比一 — 醫院員工識別證系統

想像一家有四種人員角色的醫院——主治醫師、護理師、檢驗技師、醫療行政。醫院不會把能開所有門的萬能感應卡發給每位員工。取而代之，人資部門運行一套識別證核發系統，規定「職稱是主治醫師，你的識別證開放手術室、外科病房儲藥間、醫師休息室——僅此而已。」這套識別證核發系統就是 SageMaker Role Manager。Persona 是四個內建模板；Activity Group 是模組化單元——「執行手術」、「管理管制藥品」、「查閱病歷」——每個 Persona 以不同組合取得對應授權。護理師和主治醫師都有「查閱病歷」，但只有主治醫師有「執行手術」；醫療行政兩者都沒有。新員工報到時，人資選擇 Persona 與 Activity Group，也可加上額外條件（「識別證僅在早七點到晚七點有效」），識別證就印有且僅有那些權限。SageMaker Role Manager 與最小權限模式對 ML 團隊的運作方式完全相同。

類比二 — 鎖匠的主鑰匙系統

想像一棟辦公大樓，鎖匠負責管理主鑰匙。有一把大樓萬能鑰匙（AmazonSageMakerFullAccess），能開所有門——鎖匠最不想拿出來，因為拿到的人什麼都能做。有四把部門主鑰匙（四個內建 Persona），只開一個部門的門——IT、財務、行銷、法務——但無法開其他部門。有樓層主鑰匙（含手選 Activity Group 的自訂 Persona），只開某一樓的特定門。還有職能專屬鑰匙（IAM 條件限制角色），只在上班時間有效、只在持有者的徽章在大樓內才有效，且只能開核准清單上的門。成熟的 ML 平台透過 SageMaker Role Manager 核發職能專屬鑰匙，把大樓萬能鑰匙當成緊急備用物品鎖在保險箱裡。最小權限的旅程，就是逐個 Persona 地把每個團隊從萬能鑰匙推進到職能專屬鑰匙。

類比三 — 餐廳廚房各工作站

想像一家正式料理餐廳的廚房，分為甜點站、燒烤站、炒鍋站、冷盤站、洗碗站。每個站有各自的工具、食材與火源。主廚監管所有人，但不親自發放刀具組——餐廳使用一套工作站設備政策：甜點師傅取得擀麵棍和甜點噴槍，但沒有主廚刀；燒烤師傅取得夾子和主廚刀，但沒有甜點噴槍；洗碗工拿到海綿和洗碗槽使用權，但沒有任何烹飪設備。設備存取依工作站（Persona）對應，不依個人。新廚師輪調到甜點站時繼承甜點套件；轉到燒烤站時交回甜點套件、領取燒烤套件。廚房運行高效，因為工具符合工作，沒有人拿著不該有的工具。SageMaker Role Manager 是設備政策；Activity Group 是個別工具套件；Persona 是工作站。

四個內建 SageMaker Role Manager Persona

SageMaker Role Manager 內附四個預定義 Persona，對應四種常見 ML 團隊職能。MLA-C01 必須熟記它們。

Persona 1 — ML Engineer

ML Engineer Persona 範疇最廣。涵蓋訓練任務（Training Job）、處理任務（Processing Job）、模型建立、Endpoint 建立與部署，以及 Pipeline 編排。角色可從核准的 S3 Bucket 讀取訓練資料、將模型成品寫入核准的 Bucket、在 Model Registry 登錄模型，以及部署到 Endpoint。ML Engineer Persona 最接近「出貨到正式環境」的角色，在許多團隊中也是 SageMaker Pipelines 執行角色所採用的 Persona。

Persona 2 — Data Scientist

Data Scientist Persona 僅限於實驗範疇。涵蓋 SageMaker Studio 存取、Notebook 使用、Training Job、Processing Job 及 Feature Store 讀取——但不包含 Endpoint 部署、Model Registry 審核，或正式環境 CI/CD 操作。這個區分是刻意的——Data Scientist 實驗，ML Engineer 出貨。需要部署到正式環境的 Data Scientist，必須使用需明確審核的獨立高權限角色。

Persona 3 — MLOps Engineer

MLOps Engineer Persona 是以維運為核心的角色。涵蓋模型部署、Endpoint 更新操作、部署防護設定、A/B 測試組態、Model Registry 審核工作流程、監控排程管理，以及 CloudWatch 警示設定。它不自動包含 Training Job 建立——MLOps Engineer 操作正式環境機群，不撰寫模型。

Persona 4 — Business Analyst

Business Analyst Persona 以唯讀為主。涵蓋 SageMaker Canvas（無程式碼 ML）、讀取儀表板、查詢 Model Monitor 報告，以及透過 Endpoint 消費模型預測——但不包含訓練、部署或對正式環境資源的任何寫入。此 Persona 適合需要 ML 洞察但不碰 ML 平台的利害關係人。

Activity Group — Role Manager 權限的建構基礎

每個 Persona 由 Activity Group 組成——對應特定 ML 工作流程的模組化權限集。

Activity Group 是什麼

Activity Group 是一組具名的 IAM Action 集合，加上使這些 Action 安全的資源範疇與條件鍵。例如：「執行 Training Job」、「管理 Model Registry 審核」、「部署 Endpoint」、「讀取 Feature Store 線上存放區」、「寫入 Feature Store 離線存放區」。每個 Activity Group 對應一個不同的工作流程步驟。

Activity Group 如何組合

ML Engineer Persona 啟用訓練、處理、模型建立、Endpoint 建立、Pipeline 執行和 Model Registry 寫入的 Activity Group。Data Scientist Persona 啟用訓練、處理、Studio 存取和 Feature Store 讀取的 Activity Group——但不包含 Endpoint 建立。透過選擇 Activity Group，平台管理員可在不撰寫 IAM JSON 的情況下建立自訂 Persona。

自訂 Persona

四個內建 Persona 是起點。SageMaker Role Manager 允許手選 Activity Group 定義自訂 Persona。典型的自訂 Persona 模式：針對初級工程師的「ML Engineer 去除正式部署」，或針對資深可靠性工程師的「MLOps Engineer 加上緊急訓練任務啟動」。

Activity Group 與原始 IAM 陳述式

每個 Activity Group 最終會渲染成含有 Action、Resource 和 Condition 區塊的 IAM 政策陳述式。輸出角色的 Inline Policy 是可讀的 IAM，而非不透明的後設資料——你可以稽核渲染後的政策，並在產生後編輯它。許多團隊使用 SageMaker Role Manager 啟動一個角色，然後將渲染後的政策以 CloudFormation 或 Terraform 版本控制。

AWS 受管政策 vs SageMaker Role Manager 輸出 vs 自訂政策

理解政策層次對 SageMaker Role Manager 與最小權限模式至關重要。

AmazonSageMakerFullAccess — 反模式

AmazonSageMakerFullAccess 是主控台精靈附加的 AWS 受管政策。它對名稱包含 sagemaker 的每個 Bucket 授予 s3:*（攻擊者可透過命名含 sagemaker 前綴的 Bucket 加以操控），對 * 授予 iam:PassRole（任何角色），以及大量 SageMaker Action。它可用於原型開發，但絕不適用於正式環境。MLA-C01 考題會設計「正確答案是以範疇化政策取代 AmazonSageMakerFullAccess」的情境。

AWS 受管服務特定政策

AmazonSageMakerCanvasFullAccess、AmazonSageMakerPipelinesIntegrations、AmazonSageMakerFeatureStoreAccess——這些是針對特定 SageMaker 功能的較窄 AWS 受管政策。它們仍是 AWS 受管的，因此 AWS 新增 Action 時會自動更新。就最小權限而言，優先選用它們而非 FullAccess 超級政策，但要注意它們可能授予超出你特定工作負載所需的權限。

SageMaker Role Manager 輸出

Role Manager 產生的角色 Inline Policy 介於 AWS 受管與完全自訂之間。它由 AWS 工程團隊針對特定 Persona 和 Activity Group 調校。通常比 AmazonSageMakerFullAccess 嚴格許多。對大多數正式環境團隊來說，這是正確的起點。

完全自訂 Inline Policy

對受監管工作負載——HIPAA、PCI-DSS、FedRAMP——可能需要從 SageMaker API 權限參考手工撰寫完全自訂 Inline Policy。自訂政策在 IaC 中版本控制、經同儕審查，並透過 IAM Access Analyzer 持續稽核。這是金牌標準，但需要工程投入。

ABAC — SageMaker 的標籤型存取控制

使用資源標籤的屬性型存取控制（ABAC）是 SageMaker Role Manager 與最小權限模式大規模運作的第二支柱。

ABAC 解決的問題

50 位 ML Engineer 的團隊無法擁有 50 個手工撰寫的 IAM 角色。維護是不可能的。新增一個新專案將需要更新每個角色。ABAC 透過在 API 呼叫時檢查資源標籤的單一角色政策來解決這個問題——「如果 Job 的 Project 標籤符合你的 Project 主體標籤，你才可以呼叫 CreateTrainingJob。」一個角色服務所有 Engineer；標籤匹配強制執行專案層級隔離。

主體標籤 vs 資源標籤

主體標籤附加到 IAM 主體（角色、使用者、聯合身分）。資源標籤附加到 AWS 資源（Training Job、Endpoint、模型）。含有條件 aws:RequestTag/Project = aws:PrincipalTag/Project 的 SageMaker IAM 政策，要求任何新的 Training Job 都帶有符合呼叫者主體標籤的 Project 標籤。同一條件套用於資源——aws:ResourceTag/Project = aws:PrincipalTag/Project——將讀取/更新操作限制為符合呼叫者專案的資源。

標籤強制執行模式

ABAC 要運作，每個 SageMaker 資源在建立時必須帶有正確標籤。兩個強制層：（1）IAM 政策在沒有 Project 標籤時拒絕 CreateTrainingJob——"Condition": {"Null": {"aws:RequestTag/Project": "true"}} 產生拒絕。（2）AWS Config 在建立後偵測未標籤資源並觸發 SSM 修復。雙層確保沒有資源逃脫標籤。

ABAC vs RBAC 取捨

ABAC 擴展性極佳——一個政策服務多個主體——但需要嚴格的標籤紀律。RBAC（每個專案一個角色，手工撰寫）對小型團隊較簡單，但超過 10 個專案後無法擴展。SageMaker Role Manager 與最小權限模式大規模使用 ABAC；RBAC 是新平台的啟動模式。

SageMaker 的 IAM 條件鍵

條件鍵是將 SageMaker Role Manager 與最小權限模式從權限概念轉化為硬性護欄的槓桿。

sagemaker:InstanceTypes

限制 CreateTrainingJob 和 CreateEndpointConfig 可請求的 EC2 執行個體類型。範例拒絕條件："Condition": {"ForAnyValue:StringNotEquals": {"sagemaker:InstanceTypes": ["ml.m5.large", "ml.m5.xlarge", "ml.p3.2xlarge"]}}。這會封鎖昂貴的執行個體類型，例如 ml.p4d.24xlarge，除非明確核准。成本護欄與安全護欄合而為一。

sagemaker:VolumeKmsKey

要求 Training Job 和 Endpoint 組態為 EBS 加密指定客戶自管 KMS 金鑰。範例拒絕條件："Condition": {"Null": {"sagemaker:VolumeKmsKey": "true"}} 拒絕省略金鑰的 Job。結合核准金鑰的 aws:ARN 允許清單可實現完整控制。

sagemaker:NetworkIsolation

強制對每個 Training Job 開啟網路隔離模式。範例拒絕條件："Condition": {"BoolIfExists": {"sagemaker:NetworkIsolation": "false"}}。與 sagemaker:VpcSubnets 配對以要求 VPC 組態，與 sagemaker:VpcSecurityGroupIds 配對以要求核准安全群組。

sagemaker:RootAccess

控制 SageMaker Notebook Instance 是否允許使用者的 Root 存取。透過條件設為 Disabled 可防止使用者安裝任意套件或修改執行個體。

sagemaker:OutputKmsKey

強制模型成品輸出使用客戶自管 KMS 金鑰。與 VolumeKmsKey 合併使用，確保訓練 Pipeline 中所有靜態資料都由客戶加密。

ML 帳戶的 Service Control Policy

SCP 是組織層級的護欄，為帳戶層級 IAM 提供最終保障。

為何 ML 帳戶需要 SCP

帳戶層級的 IAM 政策可以被帳戶中擁有 iam:* 的任何人編輯。SCP 則不行——只有組織管理帳戶才能修改它們。對於強制性控制（訓練資料不得存放於公開 S3 Bucket、受監管 OU 中的 Training Job 不得使用網際網路模式、執行個體類型不得超過核准規格），SCP 是唯一即使帳戶層級管理員憑證遭入侵後仍能存活的強制機制。

ML 常見 SCP 模式

模式一——「拒絕所有在非核准區域的 SageMaker 動作」——將 ML 限制在 us-east-1 和 us-west-2 以滿足資料主權要求。模式二——「拒絕沒有 VPC 組態和 KMS 金鑰的 CreateTrainingJob」——強制執行完整的 IAM、KMS、VPC 堆疊。模式三——「拒絕非安全帳戶主體的 iam:CreatePolicy 和 iam:AttachRolePolicy」——防止團隊自行提升角色權限。模式四——「拒絕 kms:DisableKey 和 kms:ScheduleKeyDeletion」——保護訓練資料金鑰不被意外刪除。

SCP 適用於角色，不只使用者

SCP 適用於帳戶中所有 IAM 主體，包含服務連結角色、執行角色和跨帳戶假設的角色。SageMaker 訓練執行角色與人類 IAM 使用者一樣會碰到 SCP 邊界。如果 SCP 拒絕某個 Action，無論 Inline Policy 如何授權，角色都無法執行它。

SCP 與 Confused Deputy

SCP 不防護資源政策層面的 Confused Deputy——帳戶 A 的 Bucket Policy 允許帳戶 B 的角色，並不會通過帳戶 A 的管理帳戶 SCP。對於 Confused Deputy 防護，在資源政策上使用 aws:SourceArn 和 aws:SourceAccount 條件。SCP 與 Confused Deputy 條件是互補的，而非可相互取代的。

跨帳戶 ML 工作流程與角色鏈結

SageMaker Role Manager 與最小權限模式必須延伸至帳戶邊界之外。

三帳戶 ML 模式

成熟的 ML 組織擁有三個帳戶：Data（S3 中的策劃資料集）、Modelling（SageMaker 訓練與實驗）、Production（Endpoint 與 Model Registry）。每個帳戶有各自的 Role Manager Persona。跨帳戶流程使用角色鏈結——Modelling 帳戶的訓練角色假設 Data 帳戶的讀取角色來取得資料；Production 帳戶的部署角色假設 Modelling 帳戶的模型拉取角色來取得成品。

跨帳戶 Model Registry

Production 從 Modelling 帳戶的 Model Registry 部署。Production 帳戶的部署角色需要跨帳戶的 sagemaker:DescribeModelPackage 和 sagemaker:CreateModel 權限。Modelling 帳戶的 Model Registry 有一個資源政策，授予 Production 帳戶角色主體讀取已核准套件的權限。結合模型成品 Bucket 的 KMS 金鑰共用，這是標準的多帳戶部署模式。

跨帳戶 ML 中的 Confused Deputy

由 Production 假設的 Modelling 帳戶角色，其信任政策中必須包含 aws:SourceAccount 條件——否則，任何恰好知道角色 ARN 的其他 AWS 客戶都可能嘗試假設它。MLA-C01 考題設計信任政策缺少 SourceAccount 的情境，問「安全漏洞是什麼」——答案是 Confused Deputy。

稽核與漂移偵測 — SageMaker 的 IAM Access Analyzer

定義角色只是工作的一半。持續驗證它們仍維持最小權限是另一半。

IAM Access Analyzer 的外部存取偵測

Access Analyzer 持續監控 IAM 資源政策（S3 Bucket Policy、KMS 金鑰政策、IAM 角色信任政策），偵測意外的外部存取。對 SageMaker 工作負載，它會標記透過 Bucket Policy 與其他帳戶共用的 S3 Bucket、透過金鑰政策授予的 KMS 金鑰，以及透過信任政策允許外部帳戶主體假設的 IAM 角色。調查結果會出現在 Security Hub 中供集中審查。

IAM Access Analyzer 未使用存取

Analyzer 的「未使用存取」功能標記 90 天內未被使用的 IAM 權限。對 SageMaker Role Manager 與最小權限模式而言，這是稽核迴圈——產生角色、觀察一季後哪些權限仍未被使用，然後修剪它們。輸出是隨時間逐漸收緊的角色。

自訂政策檢查

對於部署前驗證，IAM Access Analyzer 政策檢查可針對自訂需求評估提案政策——「任何政策不得對 * 允許 s3:*」、「任何政策不得授予沒有資源約束的 iam:PassRole」。在部署 CloudFormation 或 Terraform 之前，在 CI/CD 中執行這些檢查。

成本護欄即最小權限

成本是安全關切。一個可以啟動 ml.p5.48xlarge 執行個體的角色，有製造五位數費用峰值的能力。

執行個體類型允許清單

sagemaker:InstanceTypes 條件鍵限制角色可請求的執行個體類型。大多數團隊：CPU 使用 ml.m5.large、ml.m5.xlarge、ml.m5.2xlarge；入門 GPU 使用 ml.g4dn.xlarge；正式訓練使用 ml.p3.2xlarge。超過這個範疇的需要獨立的審核工作流程和獨立的高權限角色。

最大執行時間條件

sagemaker:MaxRuntimeInSeconds 條件限制 Training Job 的執行時長。常見模式：一般用途角色上限 24 小時，基礎模型微調角色上限 168 小時（7 天）。失控的訓練任務會自動停止。

Spot vs 隨需條件

sagemaker:UseSpot 條件可以要求注重成本的團隊使用 Spot 訓練。含有 "Bool": {"sagemaker:UseSpot": "true"} 的角色完全無法建立隨需 Training Job。

SageMaker Role Manager 與最小權限的常考陷阱

陷阱 1 — Role Manager 會更新現有角色

錯誤。它只產生新角色。

陷阱 2 — AWS 受管政策總是比手工撰寫的更嚴格

錯誤。通常更寬泛，尤其是 AmazonSageMakerFullAccess。

陷阱 3 — 當角色有正確權限時 ABAC 標籤是可選的

錯誤。ABAC 需要標籤來強制執行——沒有標籤，政策會因條件運算子不同而崩潰為全允許或全拒絕。

陷阱 4 — SCP 會覆蓋像 Bucket Policy 這樣的資源側政策

錯誤。SCP 適用於成員帳戶中的主體，不適用於其他帳戶中的資源政策。Confused Deputy 防護仍需要資源政策上的 aws:SourceArn。

陷阱 5 — sagemaker:InstanceTypes 適用於 Endpoint 呼叫

錯誤。它適用於 CreateTrainingJob 和 CreateEndpointConfig——啟動時的決策。InvokeEndpoint 繼承 Endpoint 現有的執行個體類型。

陷阱 6 — Permission Boundary 取代 Inline Policy

錯誤。Permission Boundary 上限為最大有效權限。角色仍需要授予實際權限的 Inline 或附加政策；Boundary 只是限制這些授予的廣度。

陷阱 7 — IAM Access Analyzer 偵測 Inline Policy 內的漂移

部分正確。Access Analyzer 偵測外部存取暴露和未使用權限，而非政策語法漂移。對於漂移，使用 AWS Config 受管規則或外部 IaC 漂移偵測。

陷阱 8 — 每個 Persona 恰好對應一個 Activity Group

錯誤。每個 Persona 由多個 Activity Group 組成。Data Scientist Persona 同時啟用訓練、處理、Studio 和 Feature Store 讀取群組。

陷阱 9 — 跨帳戶角色信任不需要 aws:SourceAccount

錯誤。沒有 SourceAccount，就存在 Confused Deputy 漏洞。

陷阱 10 — 每個團隊一個角色是最小權限模式

錯誤。每個職能一個角色——透過 ABAC 標籤進行專案隔離——才是可擴展的模式。所有專案的所有 ML Engineer 共用一個角色，以專案標籤強制執行隔離。

SageMaker Role Manager 與最小權限的關鍵數字與必記事實

SageMaker Role Manager

• 四個內建 Persona：ML Engineer、Data Scientist、MLOps Engineer、Business Analyst
• Activity Group 組合成 Persona；自訂 Persona 直接挑選 Activity Group
• 輸出是帳戶中含有 Inline Policy 的 IAM 角色
• 不修改現有角色；只建立新角色

IAM 條件鍵

• sagemaker:InstanceTypes — 限制執行個體類型
• sagemaker:VolumeKmsKey — 要求客戶自管 EBS KMS
• sagemaker:OutputKmsKey — 要求客戶自管輸出 KMS
• sagemaker:NetworkIsolation — 強制網路隔離
• sagemaker:VpcSubnets 和 sagemaker:VpcSecurityGroupIds — 要求 VPC 組態
• sagemaker:RootAccess — 控制 Notebook Root 存取
• sagemaker:MaxRuntimeInSeconds — 上限 Training Job 執行時長

ABAC

• aws:PrincipalTag/Project = aws:RequestTag/Project 在建立時強制執行專案標籤
• aws:PrincipalTag/Project = aws:ResourceTag/Project 在讀取/更新時強制執行專案標籤
• 端到端 ABAC 需要兩個層次

SCP

• 適用於成員帳戶中的所有主體（使用者、角色、服務連結角色）
• 只能從組織管理帳戶修改
• 不適用於其他帳戶中的資源政策

AWS 受管政策

• AmazonSageMakerFullAccess：僅用於原型開發，絕不用於正式環境
• AmazonSageMakerCanvasFullAccess：Canvas 專用
• AmazonSageMakerPipelinesIntegrations：Pipelines 專用

FAQ — SageMaker Role Manager 與最小權限熱門問題

Q1 — 跨 6 個專案的 30 位 ML Engineer 團隊需要 SageMaker 存取。我應該建立幾個角色？

一個角色，搭配 ABAC。該角色具有 ML Engineer Persona 的 Inline Policy，加上在每個 CreateTrainingJob、CreateEndpointConfig 和類似操作上要求 aws:RequestTag/Project = aws:PrincipalTag/Project 的條件鍵。每位 Engineer 的聯合身分攜帶對應其專案分配的 Project 主體標籤。新 Engineer 加入只需新增主體標籤；專案調動只是標籤變更，不是角色變更。另一種選擇——30 個手工角色或 6 個專案角色——無法擴展。

Q2 — SageMaker Role Manager 產生了角色，但 Training Job 在存取輸入 S3 Bucket 時失敗，出現 AccessDenied。Role Manager 遺漏了什麼？

Role Manager 產生主體側的 IAM，不產生資源側政策。訓練角色需要 s3:GetObject（Role Manager 針對你設定的 Bucket 提供了），但輸入 Bucket 上的 S3 Bucket Policy 也必須授予角色主體存取——Role Manager 不編輯 Bucket Policy。交叉檢查三個地方：角色的 Inline Policy 列出 Bucket ARN、Bucket Policy 列出角色 ARN，以及（如果 Bucket 是 KMS 加密的）KMS 金鑰政策列出角色主體。缺少三者中的任何一個都會在 Job 啟動時產生 AccessDenied。

Q3 — 如何強制執行組織中所有 SageMaker Training Job 都不能使用 ml.p4d.24xlarge 或更大的執行個體？

在組織根層級建立 SCP，對 sagemaker:CreateTrainingJob 加上 Deny 陳述式，條件為 sagemaker:InstanceTypes 包含任何不允許的類型："Condition": {"ForAnyValue:StringEquals": {"sagemaker:InstanceTypes": ["ml.p4d.24xlarge", "ml.p4de.24xlarge", "ml.p5.48xlarge"]}}。SCP 適用於所有帳戶的所有主體，且能在成員帳戶的任何 Inline Policy 變更下存活。對於例外工作流程，在 Modelling 帳戶中建立 SCP 透過主體 ARN 豁免的獨立高權限角色，並要求手動審核才能假設該角色。

Q4 — 新的 MLOps Engineer 加入，需要部署 Endpoint，但我不想給他們訓練任務建立權限。應選哪個 Persona？

透過 Role Manager 產生的 MLOps Engineer Persona。它包含 Endpoint 建立、Endpoint 更新、部署防護、監控排程管理和 Model Registry 審核——但不包含 Training Job 建立、Processing Job 建立或模型撰寫。Persona 強制執行維運角色與撰寫角色的分離。如果 MLOps Engineer 偶爾需要緊急啟動訓練任務，建立一個含有 sagemaker:CreateTrainingJob 的獨立「MLOps 緊急」角色加上使用時的 CloudWatch 警示，並要求走緊急程序才能使用。

Q5 — 如何偵測正式環境中過度授權的 SageMaker 角色？

三個層次。第一，IAM Access Analyzer「未使用存取」識別過去 90 天未被使用的角色權限；修剪這些以收緊角色。第二，IAM Access Analyzer「外部存取」標記 S3 Bucket Policy、KMS 金鑰政策和角色信任政策中在帳戶或組織外部授予存取的情況——審查並收緊。第三，執行 AWS Config 受管規則 iam-policy-no-statements-with-admin-access 和自訂規則，檢查正式環境中 AmazonSageMakerFullAccess 的附加情況。將調查結果排程到 Security Hub 進行集中分類。

Q6 — 跨帳戶 SageMaker 訓練：Data 帳戶持有資料集，Modelling 帳戶執行訓練。如何設定主體與資源？

四個步驟。步驟一：在 Modelling 帳戶中，透過 Role Manager 產生一個 ML Engineer 執行角色，範疇限定於 Data 帳戶的 Bucket ARN 和 KMS 金鑰 ARN。步驟二：在 Data 帳戶中，新增 Bucket Policy 陳述式，允許 Modelling 帳戶執行角色主體對資料集前綴呼叫 s3:GetObject 和 s3:ListBucket，加上 aws:SourceAccount 和 aws:SourceArn 條件進行 Confused Deputy 防護。步驟三：在 Data 帳戶中，將 Modelling 帳戶角色主體新增到 KMS 金鑰政策，授予 kms:Decrypt 權限。步驟四：透過僅下載單一檔案後退出的試執行 Training Job 進行驗證。四步驟模式可泛化至任何規模的多帳戶 ML。

Q7 — IAM Access Analyzer 標記我的 SageMaker 執行角色具有外部存取。洩漏點在哪裡？

Access Analyzer 中的外部存取表示帳戶中的資源政策授予另一個帳戶或組織的主體存取權限。對 SageMaker 最常見的來源：（1）模型成品 Bucket 上的 S3 Bucket Policy 允許合作夥伴帳戶，（2）訓練資料金鑰上的 KMS 金鑰政策允許另一個帳戶，（3）允許另一個帳戶主體假設角色的 IAM 角色信任政策。開啟 Access Analyzer 調查結果查看特定資源和外部主體。如果外部存取是刻意的（計畫中的跨帳戶 ML Pipeline），帶著文件化理由抑制調查結果。如果是非刻意的，立即收緊資源政策並調查它是如何加入的——通常是透過粗心的萬用字元或過時的跨帳戶組態。

延伸閱讀 — SageMaker Role Manager 與最小權限的官方 AWS 文件

權威 AWS 來源包括：SageMaker 開發者指南的 Role Manager 章節（尤其是 Persona 和 Activity Group 部分）、SageMaker AWS 受管政策參考、SageMaker API 權限參考（用於政策撰寫的 Action 層級權限）、IAM 使用者指南的屬性型存取控制章節，以及 AWS Organizations Service Control Policy 指南。IAM Access Analyzer 文件涵蓋外部存取和未使用存取偵測。AWS re:Inforce 的 SageMaker 安全議程包含多場最小權限模式的深度探討。AWS 安全部落格有大量反映 MLA-C01 題目模式的 SageMaker IAM 強化文章。對於受監管產業的 SageMaker Role Manager 與最小權限模式，AWS 合規中心記錄了每個 Persona 和條件鍵滿足的 HIPAA、PCI-DSS、FedRAMP 和 SOC 2 控制項。