IAM 與 Lake Formation 細粒度存取控制

IAM 與 Lake Formation 細粒度存取控制是 DEA-C01 社群心得中引用最多的考試錯誤。這是因為這兩個層級看起來做著相同的事情，但實際上它們以非顯而易見的方式組合在一起，甚至讓經驗豐富的資料工程師也措手不及。在 DEA-C01 考試中，領域 4 任務 4.2 大約在每五題中就有一題設定了此類考點：如果考生認為「Lake Formation 授予權限就夠了」或「IAM S3 政策就夠了」或「Lake Formation 的拒絕 (deny) 會覆蓋 IAM 的允許 (allow)」，那麼在涉及欄位層級存取、跨帳戶共享或資料列層級篩選的高風險情境題中，就很可能會選錯答案。

本指南從資料工程師 / MLOps 的視角釐清 IAM 與 Lake Formation：各層級控制什麼、它們如何組合、兩層模型在生產環境中的坑點，以及如何在不留下安全漏洞的情況下設計細粒度存取。涵蓋內容包括用於資料服務的 IAM 身分與政策、Lake Formation 許可模型（資料庫、資料表、欄位、資料列、儲存格）、資料篩選器、LF-TBAC 基於標籤的存取控制、已註冊位置、通過 RAM 和資源連結進行跨帳戶共享、用於資料存儲的 IAM Access Analyzer，以及圍繞兩層強制執行模型設計的典型考試陷阱。

身分驗證 (Authentication) vs 授權 (Authorization) — 兩個不同的問題

在討論 IAM 或 Lake Formation 之前，請先區分這兩個概念。

身分驗證 — 你是誰

身分驗證用於核實身分：是誰發起了這個請求？DEA-C01 考生需要了解三種身分類型：IAM 使用者（帶有密碼或存取金鑰）、IAM 角色（由服務或聯合身分取用）以及 IAM Identity Center（前稱 SSO）使用者。身分驗證在授權執行之前回答「此調用者真的是行銷團隊的 Alice 嗎？」。

授權 — 你能做什麼

授權回答「既然我們知道是 Alice，她可以讀取客戶資料表嗎？」。授權是 IAM 政策與 Lake Formation 許可共同存在的地方，也是兩層組合產生著名的 DEA-C01 陷阱的地方。

DEA-C01 如何測試各項

任務 4.1 測試身分驗證機制：聯合身分設定、用於 Glue 和 Redshift 等服務的 IAM 角色、用於分析師 SSO 的 IAM Identity Center。任務 4.2 測試授權：IAM 政策、Lake Formation 授予、S3 儲存桶政策、KMS 金鑰政策以及它們如何組合。兩層陷阱完全屬於任務 4.2 的範疇。

用於資料服務的 IAM 身分類型

DEA-C01 考試預期考生能熟練掌握與資料工程相關的 IAM 身分類型。

IAM 使用者與長期存取金鑰

IAM 使用者具有用於主控台存取的密碼和用於程式化存取的存取金鑰。AWS 指導原則：儘量減少 IAM 使用者，轉而使用 IAM Identity Center 和取用角色 (assumed roles)。DEA-C01 陷阱：建議為分析師建立 IAM 使用者的情境通常是錯誤的；正確答案是使用具有角色取用的 IAM Identity Center。

用於服務的 IAM 角色

Glue 工作、EMR 叢集、Redshift 叢集、Athena 工作群組和 Lambda 函數都會取用 IAM 角色，以便代表它們存取 AWS 資源。例如，Glue ETL 工作角色需要對 S3 來源儲存桶、Glue 目錄和 CloudWatch 日誌的權限。角色的信任政策會指定哪個服務可以取用它（例如 glue.amazonaws.com）。

用於聯合身分使用者的 IAM 角色

通過 SAML、OIDC 或 IAM Identity Center 驗證的分析師和工程師會在工作階段期間臨時取用角色。角色的信任政策指定哪個 IdP 可以取用它。聯合身分存取是生產環境中人類使用者的正確模式。

跨帳戶 IAM 角色

如果信任政策允許，帳戶 A 中的角色可以被帳戶 B 中的委託人 (principal) 取用。跨帳戶模式對於集中式資料湖架構至關重要，在這種架構中，資料湖位於一個帳戶，而取用者位於許多其他帳戶。

服務相關角色 (Service-Linked Roles)

某些 AWS 服務會自動建立自己的服務相關角色（如 Lake Formation、Macie、OpenSearch）。這些角色具有 AWS 託管的權限，不應被修改。

用於資料工程的 IAM 政策

IAM 政策是 JSON 文件，用於允許或拒絕對資源的操作。DEA-C01 考試預期考生熟悉政策結構和常見的條件鍵。

基於身分的政策 vs 基於資源的政策

基於身分 (Identity-based) 的政策附加到 IAM 使用者、群組或角色，定義該身分可以做什麼。基於資源 (Resource-based) 的政策附加到資源（S3 儲存桶政策、KMS 金鑰政策、Glue Catalog 資源政策、Lambda 權限），定義誰可以存取該資源。兩者在存取時都會被評估。

政策評估邏輯

如果任何政策明確允許 (Allow) 且沒有任何政策明確拒絕 (Deny)，則請求被允許。明確拒絕始終勝出。在單個帳戶內，基於身分或基於資源的政策中任一方允許即足夠（除非受到組織 SCP、權限界限或工作階段政策的限制）。

資料工程常見條件鍵

aws:SourceVpc（僅允許來自特定 VPC）、aws:SourceIp（僅允許來自特定 IP 範圍）、aws:RequestTag/*（要求在建立資源時帶有特定標籤）、s3:prefix（僅允許存取特定的 S3 前綴）、kms:ViaService（僅當通過 S3 等特定服務使用時才允許 KMS）、aws:PrincipalTag/*（基於委託人標籤的 ABAC 模式）。

權限界限 (Permission Boundaries)

權限界限是一個託管政策，定義了角色可以擁有的最大權限。用於約束被委派的管理員 — 「你可以建立角色，但角色的權限不能超過此界限」。DEA-C01 在將 IAM 管理權委派給資料工程團隊而不給予 root 權限的情境中會用到此考點。

Lake Formation — 集中式資料湖控管

Lake Formation 是基於 Glue 資料目錄構建的 AWS 服務，用於集中管理資料湖權限。

Lake Formation 在 IAM 之外增加了什麼

IAM 在 API 層級控制對 AWS 資源的存取 — glue:GetTable、s3:GetObject。Lake Formation 在資料庫、資料表、欄位、資料列和儲存格層級增加了細粒度資料許可 — Lake Formation 允許您在包含 100 個欄位的資料表中僅對其中 3 個欄位授予 SELECT 權限，而分析師看不到其他 97 個欄位。IAM 無法原生表達欄位層級的授予（您必須編寫具有欄位名稱條件的複雜政策）；Lake Formation 將欄位層級權限作為一等公民處理。

Lake Formation 許可階層

從粗到細：目錄 (Catalog)（所有資料庫）、資料庫 (Database)（資料庫中的所有資料表）、資料表 (Table)（單個資料表）、欄位 (Column)（欄位的子集）、資料列 (Row)（資料列上的篩選表達式）、儲存格 (Cell)（欄位 + 資料列篩選器的組合）。許可授予向下流動 — 資料庫層級的 SELECT 適用於所有資料表；資料表層級的 SELECT 適用於所有欄位，除非受到限制。

授予與撤銷權限

Lake Formation 使用 SQL 中熟悉的 GRANT 和 REVOKE 模型：GRANT SELECT ON DATABASE marketing TO ROLE analyst-role，GRANT SELECT (customer_id, order_total) ON TABLE marketing.orders TO ROLE analyst-role。這些授予權限存儲在 Lake Formation 的許可存儲中，並在每次 Athena、Redshift、EMR 或 Glue 存取時進行評估。

資料湖管理員 (Data Lake Administrators)

Lake Formation 資料湖管理員對 Lake Formation 許可具有完整控制權，並可以向他人授予存取權。採用 Lake Formation 時的首要任務是指定一名或多名資料湖管理員；不要使用 AWS root 帳戶。

IAMAllowedPrincipals — 向後相容模式

預設情況下，新的 Glue 資料庫會被授予 IAMAllowedPrincipals 權限，這意味著 Lake Formation 會將權限檢查委派給 IAM。這是向後相容模式，允許現有的基於 IAM 的流水線繼續運作。要啟用 Lake Formation 強制執行權限，請撤銷 IAMAllowedPrincipals 並授予顯式的 Lake Formation 許可。DEA-C01 陷阱：設定了 Lake Formation 但忘記撤銷 IAMAllowedPrincipals 的考生會發現 IAM 權限仍然有效，且 Lake Formation 的細粒度授予並未按預期執行。

兩層模型 — Lake Formation 加上 S3 儲存桶政策

最常被引用的 DEA-C01 陷阱集中在 Lake Formation 和 S3 儲存桶政策如何組合。

為什麼存在兩層

Lake Formation 管理目錄層級的存取（資料庫、資料表、欄位）。S3 儲存桶政策管理物件層級的存取（哪些 IAM 委託人可以讀取或寫入物件）。當 Athena、Redshift Spectrum 或 EMR 查詢由 S3 資料支援的 Glue 資料表時，兩層都必須允許存取 — Lake Formation 必須授予對資料表的 SELECT 權限，且底層 S3 儲存桶政策或 IAM 政策必須允許對資料檔案執行 s3:GetObject。

已註冊位置 (Registered Locations)

Lake Formation 引入了「已註冊位置」的概念 — 代表取用者受 Lake Formation 管理的 S3 路徑。當一個路徑被註冊時，Lake Formation 會向查詢引擎（Athena、Redshift Spectrum）簽發臨時憑證，允許它們代表使用者讀取底層 S3 物件，此時 S3 儲存桶政策會被繞過，轉而執行 Lake Formation 的權限管控。當路徑「未註冊」時，則需要直接配置 S3 儲存桶政策或 IAM S3 權限。

註冊位置的決策

當您希望 Lake Formation 成為該資料存取決策的單一事實來源時，請將 S3 位置註冊到 Lake Formation 下。當您希望使用基於 IAM 的存取（傳統模式）時，請保留 S3 位置為未註冊狀態。DEA-C01 陷阱：混合使用已註冊和未註冊位置的情境會產生複雜的權限流 — 正確答案幾乎總是涉及將所有資料湖 S3 路徑註冊到 Lake Formation 下。

組合政策的效果

如果 Lake Formation 授予了 SELECT 但 S3 儲存桶政策拒絕（或未允許）— 存取將失敗。如果 S3 允許但 Lake Formation 拒絕 — 同樣失敗。兩者都必須允許。這就是 AWS 為資料湖推薦的分層防禦深度模型。

欄位層級、資料列層級與儲存格層級安全

Lake Formation 的細粒度許可功能是 DEA-C01 測試的核心特性。

欄位層級安全 (Column-Level Security)

對特定欄位授予 SELECT 權限：GRANT SELECT (customer_id, order_total, order_date) ON TABLE orders TO ROLE analyst。分析師只能看到這三個欄位；引用其他欄位的查詢將返回錯誤。實現方式是在查詢時使用 Lake Formation 資料篩選器 — 目錄僅將允許的欄位返回給查詢引擎。

通過資料篩選器實現資料列層級安全 (Row-Level Security)

Lake Formation 資料篩選器用於表達資料表上的資料列篩選條件。例如，在 orders 資料表上設定表達式為 region = 'US-WEST' 的資料篩選器，將分析師限制在美國西部地區的資料列。將其與欄位授予結合使用可實現儲存格層級安全：「分析師僅能看到 customer_id 和 order_total 欄位，且僅限美國西部地區的資料列」。

資料篩選器結構

資料篩選器包含名稱、目標資料表、選用的欄位包含列表以及資料列篩選表達式。可以為不同的角色將多個篩選器套用於同一個資料表。資料列篩選表達式支持欄位引用、比較運算子、AND/OR 邏輯以及 SQL 函數子集。

儲存格層級安全 (Cell-Level Security, CLS)

儲存格層級安全是欄位層級和資料列層級篩選器的結合 — 分析師只能看到特定的儲存格（行 × 列）。這是 GDPR/HIPAA 的典型模式：允許分析師查看客戶訂單總額但不能看到信用卡號，且僅限於已同意進行數據分析的客戶。

查詢引擎如何遵循篩選器

Athena、Redshift Spectrum、EMR（整合了 Lake Formation）以及 Glue 都會在查詢時諮詢 Lake Formation，並在掃描層套用欄位投影和資料列篩選 — 使用者看不見的欄位位元組永遠不會返回給查詢，且不符合篩選表達式的資料列會在彙總之前被捨棄。考試會測試所有這些引擎是否遵循 Lake Formation 篩選器；而在 EC2 上運行的獨立 Spark 則不會。

Lake Formation 基於標籤的存取控制 (LF-TBAC)

LF-TBAC 是基於屬性的存取模式，可以擴展到大型目錄而無需為每張資料表單獨授予權限。

LF-TBAC 的作用

為資源（資料庫、資料表、欄位）和委託人（IAM 角色）打上標籤，然後根據標籤匹配編寫授予規則：「任何具有 Department=Marketing 標籤的委託人都可以 SELECT 任何帶有 Department=Marketing 標籤的資源」。授予權限的數量是 O(角色 × 標籤類別)，而不是 O(角色 × 資料表) — 這對於擁有數千張資料表的目錄來說是巨大的簡化。

LF-Tags

LF-Tags 是在 Lake Formation 中管理的鍵值對。常見模式：Sensitivity=Public/Internal/Confidential/Restricted、Department=Engineering/Marketing/Finance、Region=US/EU/APAC、DataClass=PII/PHI/Financial。

政策標籤 vs 資源標籤

LF-Tags 套用於目錄資源（資料庫、資料表、欄位）。委託人標籤（IAM 角色上的標籤）通過 Lake Formation 授予規則與 LF-Tags 進行匹配。授予規則可能會說：「具有 Sensitivity=Internal 標籤的委託人可以 SELECT 具有 Sensitivity=Internal 且 Department=Marketing 標籤的資源」。

何時使用 LF-TBAC

當情境題提到「跨 50 個團隊的 5000 張資料表」或「易於擴展的許可模型」時，LF-TBAC 是正確答案。錯誤的干擾項包括「為各個資料表單獨授予權限」（不可擴展）或「使用 IAM 基於標籤的政策」（無法實現欄位層級存取）。

經驗法則

對於 100 張資料表以下或團隊結構穩定的目錄，指定資源的授予方式更簡單。對於超過 1000 張資料表或團隊結構快速變化的目錄，LF-TBAC 是正確模式。

跨帳戶資料共享 — RAM 與資源連結

跨帳戶資料湖模式是領域 4 的必考內容。

為什麼需要跨帳戶

多帳戶架構可以隔離工作負載、縮小爆炸半徑並分開計費。資料湖通常位於一個中心的「資料」帳戶，而取用者帳戶（行銷、財務、機器學習）需要讀取存取權而無需複製資料。

AWS Resource Access Manager (RAM)

RAM 是用於跨帳戶共享資源的 AWS 服務。Lake Formation 使用 RAM 與取用者帳戶共享資料庫或資料表。生產者帳戶建立一個包含 Glue 目錄資料庫或資料表的 RAM 共享；取用者帳戶接受邀請。

資源連結 (Resource Links)

在取用者帳戶中，會建立一個指向生產者帳戶中共享資料庫或資料表的「資源連結」。取用者像查詢本地資料表一樣通過資源連結進行查詢；在後台，Lake Formation 會將目錄調用轉發到生產者帳戶並套用生產者的授予權限。

跨帳戶許可流

生產者帳戶：資料湖管理員將資料表的 SELECT 權限授予取用者帳戶的委託人（帳戶 ID 或 IAM 角色 ARN）。建立 RAM 共享。取用者帳戶：接受共享，建立資源連結，並向自己的使用者授予資源連結的 SELECT 權限。生產者的授予和取用者的授予同時生效 — 跨帳戶的分層防禦。

S3 跨帳戶考量

生產者帳戶中的 S3 儲存桶必須允許來自取用者帳戶委託人的存取，或者（首選）將路徑註冊到 Lake Formation 並使用憑證簽發功能。最簡單的生產模式：將路徑註冊到 Lake Formation，將儲存桶政策僅鎖定為 Lake Formation 服務委託人，並由 Lake Formation 處理跨帳戶存取。

用於資料存儲的 IAM Access Analyzer

IAM Access Analyzer 可檢測 S3 儲存桶、KMS 金鑰、IAM 角色和 Glue 目錄中意外的跨帳戶存取。

檢測內容

通過資源政策擁有存取權限的外部委託人（其他帳戶、聯合身分使用者、公開存取）。Analyzer 持續評估政策並標記發現項 (findings)。

Glue 目錄覆蓋

Access Analyzer 會檢查 Glue 目錄資源政策中的跨帳戶存取。如果某個 Glue 目錄資料庫共享給了不應擁有存取權的另一個帳戶，Access Analyzer 會將其標記。

S3 覆蓋

Access Analyzer 會標記具有公開讀取存取權或授予了意外跨帳戶存取之 ACL 的 S3 儲存桶。這對於一個配置錯誤的儲存桶就可能洩漏整個目錄的資料湖來說至關重要。

與 Security Hub 整合

Access Analyzer 的發現項會與 Config 和 GuardDuty 的發現項一起饋送到 Security Hub。DEA-C01 考試將此作為「對跨帳戶資料存取進行持續稽核」或「自動檢測意外公開 S3 儲存桶」的正確答案。

白話文解釋 IAM 與 Lake Formation 細粒度存取

三個具體的類比可以讓這兩層模型變得直觀。

類比 1 — 同時具備大樓保全與部門鎖的辦公大樓

IAM 就像辦公大樓的主保全櫃檯：每位員工都需要大樓識別證才能進入，識別證在大門口檢查（身分驗證），在電梯處也會檢查（授權可以進入哪些樓層）。大樓保全知道你是誰以及你可以訪問哪些樓層。Lake Formation 就像部門層級的鎖：即使你到達了行銷部門樓層，檔案櫃也是單獨上鎖的 — 機密客戶檔案需要額外的部門核發金鑰（欄位層級授予），且歐洲客戶的檔案櫃需要地區金鑰（資料列層級篩選器）。DEA-C01 的陷阱在於認為「我有大樓識別證，所以我可以看每個檔案」 — 錯誤，檔案櫃的鎖是分開的。正確的思維模型是兩層：大樓保全 (IAM) 處理「你是否能進入資料湖」，部門鎖 (Lake Formation) 處理「具體哪些資料表、欄位和資料列你可以讀取」。兩層都必須允許存取；任一項拒絕都足以阻斷請求。跨帳戶共享就像是另一棟大樓的姐妹辦公室 — 你的母大樓識別證被認可，姐妹大樓核發訪客證，且檔案櫃金鑰被單獨授予。

類比 2 — 擁有借閱證與限閱書架的圖書館

IAM 就像你在服務台獲得的借閱證：它識別你的身分並讓你借閱普通館藏的書籍。Lake Formation 就像閉架區或珍本書區的權限：即使有借閱證，沒有研究員證也無法進入珍本書閱覽室（資料表層級授予），沒有特別許可也無法影印特定頁面（欄位層級授予），且沒有釋出證明也無法查看 1990 年之前的捐贈者限制材料（資料列層級篩選器）。LF-TBAC 就像學術學科標籤 — 書籍和研究員證都帶有「歷史系」或「生物系」標籤，規則是「歷史系標籤的研究員可以閱讀歷史系標籤書架上的書」。通過 RAM 進行跨帳戶共享就像館際互借：你的母館同意將一本書借給另一家圖書館，另一家圖書館向其讀者核發臨時借書證，存取流程涉及兩家圖書館的政策。DEA-C01 的陷阱是忘記了僅靠借閱證 (IAM) 並不能解鎖珍本書區 (Lake Formation 授予) — 兩層都是必要的。

類比 3 — 擁有銀行金庫門與保險箱鑰匙的保險箱

IAM 就像銀行金庫大門：只有通過身分驗證且持有效證件的客戶才能進入金庫區域。Lake Formation 就像各個保險箱的鑰匙：即使在金庫內，每位客戶的保險箱也需要單獨的鑰匙，且銀行備有哪位客戶可以開啟哪個保險箱的主紀錄。欄位層級安全就像保險箱內有多個內部隔層，每個隔層都有自己的密碼 — 你可以存取「文件」隔層但不能存取「珠寶」隔層。資料列層級篩選器就像定時鎖定的隔層，僅在特定條件下開啟。儲存格層級安全則是綜合效果：特定隔層僅在特定時間可供存取。已註冊位置就像是銀行集中管理的保險箱 — 你去銀行，出示客戶身分證件，銀行核發正確保險箱的金鑰；保險箱的實際鎖定機制是由銀行控制的。未註冊位置就像銀行舊機房的保險箱，客戶必須既在金庫門口出示身分證件，又出示自己的個人保險箱鑰匙 — 這就是兩層 Lake Formation + IAM/S3 模型所正式化的雙重控制模式。

IAM 與 Lake Formation 的常見考試陷阱

請務必記住這五個陷阱。

陷阱 1 — IAMAllowedPrincipals 仍被授予

情境：「設定了 Lake Formation，但欄位層級授予並未生效。」錯誤：添加更多 Lake Formation 授予。正確：從資料庫中撤銷 IAMAllowedPrincipals，以便 Lake Formation 強制執行真正啟動。

陷阱 2 — 儲存桶政策允許但 Lake Formation 拒絕

情境：「分析師擁有 S3 GetObject 權限，但 Athena 查詢在資料表上返回存取被拒。」錯誤：擴大 S3 政策。正確：授予 Lake Formation 對該資料表的 SELECT 權限；兩層模型缺一不可。

陷阱 3 — 使用 IAM 基於標籤的政策進行欄位層級存取

情境：「需要對包含 1000 張資料表的目錄進行欄位層級存取，並通過標籤進行擴展。」錯誤：使用帶有 PrincipalTag 條件的 IAM ABAC。正確：使用 Lake Formation LF-TBAC。IAM 原生無法表達欄位層級的授予。

陷阱 4 — 跨帳戶共享但沒有資源連結

情境：「取用者帳戶直接通過名稱查詢共享資料庫。」錯誤：直接查詢 producer_account.database.table。正確：在取用者帳戶中建立資源連結，並通過連結進行查詢。

陷阱 5 — Lake Formation 加密資料

情境題暗示 Lake Formation 會對靜態資料進行加密。錯誤 — Lake Formation 管理存取，KMS 加密資料。兩者互補但不同。對於「加密資料」的問題，始終尋找 KMS 或 S3 加密設定作為答案。

Lake Formation 許可參考 — 權威清單

DEA-C01 考試預期考生熟悉許可動詞。

資料庫層級許可

• CREATE_TABLE、DROP、ALTER、DESCRIBE
• CREATE_TABLE_READ_WRITE（建立和管理資料表的完整存取權）

資料表層級許可

• SELECT（讀取）、INSERT（寫入）、DELETE（刪除行）
• DESCRIBE（查看中繼資料）、ALTER（修改結構描述）、DROP（刪除資料表）
• ALL（對資料表的超級使用者存取權）

可授予的許可 (Grantable Permissions)

• WITH GRANT OPTION — 接收者可以將許可重新授予他人
• 用於將管理權委派給資料專員 (data stewards)

資料篩選器許可

• SELECT 上的欄位包含列表
• SELECT 上的資料列篩選表達式
• 結合成儲存格層級存取模式

跨帳戶許可

• 授予 AWS 帳戶 ID 或特定的 IAM 角色 ARN
• 接收者必須在其帳戶中接受 RAM 共享

常見問題 (FAQ) — IAM 與 Lake Formation 細粒度存取熱門問題

Q1 — 我應該在什麼時候使用 IAM 或是 Lake Formation 進行資料湖存取控制？

使用 IAM 進行 AWS API 層級的存取 — 誰可以調用 glue:GetTable、athena:StartQueryExecution、s3:PutObject。使用 Lake Formation 進行資料層級的存取 — 誰可以從哪個資料庫、資料表、欄位以及哪些資料列執行 SELECT。這兩層是組合使用的：IAM 驗證調用者並授權 API 調用，Lake Formation 授權資料存取。對於新的資料湖，採用 Lake Formation 作為主要的資料許可模型（撤銷 IAMAllowedPrincipals，進行顯式授予）。對於基於僅限 IAM 構建的傳統流水線，通過按資料庫啟用 Lake Formation 並僅在驗證 Lake Formation 授予完整後才撤銷 IAMAllowedPrincipals 來逐步遷移。DEA-C01 考試在情境細節中會有考點 — 「欄位層級存取」始終是 Lake Formation；「Glue ETL 工作的 API 層級存取」則是 IAM。

Q2 — 我該如何在不複製資料表的情況下，對敏感的 PII 資料表授予欄位層級存取權？

在 Lake Formation 中：GRANT SELECT (customer_id, order_total, order_date) ON TABLE orders TO ROLE analyst-role。分析師只能 SELECT 這三個欄位；引用其他欄位的查詢將返回存取被拒錯誤。查詢引擎（Athena、Redshift Spectrum、EMR）在掃描層僅投影允許的欄位，因此分析師甚至在查詢計劃或錯誤訊息中也永遠看不到 PII 欄位。對於資料列層級篩選，添加一個帶有 region = 'US-WEST' 之類表達式的 Lake Formation 資料篩選器。對於儲存格層級安全，在同一個資料篩選器中結合欄位包含列表和資料列篩選器。DEA-C01 考試將此作為「不複製資料的細粒度存取」的權威答案。

Q3 — 中心化資料湖與取用者帳戶之間的跨帳戶資料共享是如何運作的？

生產者帳戶（資料湖）建立一個 Lake Formation 授予，以取用者帳戶 ID 或 IAM 角色 ARN 作為接收者，然後建立一個包含 Glue 目錄資料庫或資料表的 RAM 共享。取用者帳戶接受 RAM 共享，在自己的目錄中建立一個指向共享資料庫的資源連結，向自己的使用者授予資源連結的 SELECT 權限，並從 Athena/Redshift/EMR 查詢該資源連結。生產者帳戶中的 S3 儲存桶必須允許通過儲存桶政策進行跨帳戶存取，或者（首選）將路徑註冊到 Lake Formation 下並使用憑證簽發功能。DEA-C01 考試會設定多帳戶情境 — 正確答案始終涉及 RAM 共享 + 資源連結 + 雙方的 Lake Formation 授予。

Q4 — 什麼是 IAMAllowedPrincipals，為什麼它很重要？

IAMAllowedPrincipals 是 Glue 資料庫上的一個向後相容性設定，當它被授予時，會使 Lake Formation 將該資料庫的權限檢查委派給 IAM。在 Glue 主控台中建立的新資料庫預設會授予 IAMAllowedPrincipals。只要 IAMAllowedPrincipals 被授予，您的 Lake Formation 欄位層級或資料列層級授予就不會生效 — IAM 對 Glue 目錄和 S3 的權限將佔主導地位。要啟用 Lake Formation 強制執行，請從資料庫（和資料表）中撤銷 IAMAllowedPrincipals，並向需要存取的角色授予顯式的 Lake Formation 許可。這是「為什麼 Lake Formation 無效」最常被引用的疑難排解問題。DEA-C01 考試直接設定了這個陷阱 — 「Lake Formation 授予未生效」的答案幾乎總是「撤銷 IAMAllowedPrincipals」。

Q5 — 我應該在什麼時候使用 LF-TBAC 或是指定資源的授予方式？

當目錄包含數百或數千張資料表、當團隊頻繁變動或當許可模型可以用屬性（部門、敏感度、區域、資料類別）表達時，請使用 LF-TBAC。LF-TBAC 的擴展規模為 O(角色 × 標籤類別)，而指定資源的授予擴展規模則為 O(角色 × 資料表)。對於較小的目錄（約 50 張資料表以下），如果「向特定角色授予特定資料表的 SELECT 權限」的簡單性超過了屬性的操作優勢，或者對於不符合標籤分類的單次權限授予，請使用指定資源的方式。DEA-C01 考試將 LF-TBAC 作為企業級規模情境的正確答案；對於小規模且集中的情境，指定資源的授予即已足夠。

Q6 — Lake Formation 會加密資料嗎？

不會。Lake Formation 管理資料的「存取」；它不會對靜態或傳輸中的資料進行加密。靜態資料通過儲存桶上的 S3 伺服器端加密 (SSE-S3, SSE-KMS)、Redshift 叢集加密（配合 KMS）以及 Glue 工作安全配置（用於中間結果）進行加密。傳輸中的資料由連接上的 TLS 保護。Lake Formation 和 KMS 是互補的 — Lake Formation 決定「Alice 可以讀取 A 欄和 B 欄」，KMS 決定「位元組在靜態時由金鑰 K 加密，只有對 K 擁有 kms:Decrypt 權限的角色才能讀取它們」。DEA-C01 考試將「Lake Formation 加密」作為錯誤答案干擾項；正確的加密答案始終涉及 KMS 或服務原生加密。

Q7 — 我該如何疑難排解 Lake Formation 管理資料表上的「存取被拒 (access denied)」錯誤？

按順序檢查四個層次。第 1 層 — IAM：調用角色是否擁有 glue:GetTable、glue:GetPartitions、athena:StartQueryExecution（或等效項）權限？如果沒有，查詢甚至無法到達 Lake Formation。第 2 層 — Lake Formation：資料庫上是否撤銷了 IAMAllowedPrincipals？是否向角色授予了對資料表或特定欄位的 SELECT 權限？是否有資料篩選器排除了該角色的資料列？第 3 層 — S3：底層 S3 路徑是否註冊在 Lake Formation 下？如果是，查詢引擎應從 Lake Formation 獲取憑證。如果不是，角色需要直接通過 IAM 或儲存桶政策獲得 s3:GetObject 權限。第 4 層 — KMS：如果資料使用 SSE-KMS 加密，角色（或 Lake Formation 服務角色）是否對金鑰擁有 kms:Decrypt 權限？按順序檢查這四層，可以解決 95% 的 Lake Formation 存取被拒問題。

延伸閱讀 — AWS 官方文件

權威的 AWS 來源包括《AWS Lake Formation 開發人員指南》（許可模型、已註冊位置、資料篩選器、LF-TBAC、跨帳戶共享）、《IAM 使用者指南》（基於身分與資源的政策、條件鍵、權限界限）、關於 Lake Formation 模式的 AWS 大數據部落格系列，以及涵蓋治理與存取控制的《AWS Well-Architected 資料分析視角 (Data Analytics Lens)》。Skill Builder 的 DEA-C01 考試準備標準課程中有專門針對領域 4 身分驗證與授權的模組。AWS Samples GitHub 存儲庫包含了使用 Lake Formation 的跨帳戶資料湖端對端範例架構。為了深入了解，可以閱讀 AWS 安全部落格發布的關於 FINRA 和 Capital One 等公司資料湖存取模式的案例研究，這些案例說明了現實世界中 Lake Formation 的部署情況。