Mục tiêu học tập
- Hiểu LF-TBAC (tag-based access control) và vì sao scale hơn named-resource
- Cấu hình row-level và cell-level security bằng data filters
- Nắm cross-account sharing qua Lake Formation + AWS RAM
- Ghép Lake Formation vào kiến trúc data mesh nhiều account
1. Ôn lại nhanh (tuần 1)
Lake Formation = tầng permission database/table/column/row/cell trên Glue Catalog + S3 registered locations; engine (Athena, Redshift Spectrum, Glue, EMR) nhận vended credentials theo quyền được cấp. Nhớ thu hồi IAMAllowedPrincipals để LF thực sự enforce.
2. LF-Tags — Tag-Based Access Control (LF-TBAC)
Vấn đề với named-resource
Grant từng bảng cho từng team: 100 bảng × 20 team = hàng nghìn grant, bảng mới phải grant lại — không scale.
Mô hình LF-tags
1. Định nghĩa tag: domain = {sales, hr, finance}
sensitivity = {public, confidential, pii}
2. Gắn tag lên resource: database/table/column
(cột email → sensitivity=pii; bảng orders → domain=sales)
3. Grant theo BIỂU THỨC tag:
GRANT SELECT WHERE domain=sales AND sensitivity IN (public, confidential)
TO role SalesAnalyst
- Bảng/cột mới gắn đúng tag là tự động nằm trong/ngoài quyền — không grant lại
- Tag kế thừa: database → table → column (override được ở mức thấp hơn)
- Đây là đáp án cho: "hundreds of tables, many teams, scalable permission management"
3. Row-level và cell-level security — Data Filters
Data filter trên một bảng gồm:
- Row filter: biểu thức WHERE (vd
country = 'VN') - Column include/exclude: giới hạn cột
- Kết hợp cả hai = cell-level security
Grant SELECT với data filter cho principal — Athena/Spectrum/EMR/Glue enforce tự động. "Mỗi country team chỉ thấy row nước mình, ẩn cột PII" → data filter.
4. Cross-account sharing
Cơ chế
- Chia sẻ metadata + quyền dữ liệu, không copy dữ liệu; S3 vẫn ở account A
- AWS RAM là cơ chế vận chuyển share (tự động khi grant external account)
- Resource link: bảng "shortcut" trong catalog của B trỏ tới bảng share — cần cho query engine thấy trong database local
- Hỗ trợ cả named-resource lẫn LF-tag based cross-account (grant theo tag expression cho account/OU — scale cho data mesh)
- Version settings: cross-account version 3+ (mới nhất) bỏ yêu cầu một số bước cũ — chỉ cần nhớ "dùng version mới"
So với các cách chia sẻ khác
| Cách | Dữ liệu | Phù hợp |
|---|---|---|
| LF cross-account | Không copy, quyền fine-grained | Data lake S3/Glue nhiều account |
| Redshift data sharing | Không copy, live | Giữa các warehouse Redshift |
| Bucket policy cross-account | Object-level thô | File đơn giản, không cần table semantics |
| Copy/replicate | Copy | Khi cần bản độc lập (latency, sovereignty) |
5. Data mesh với Lake Formation (mức nhận biết)
- Mỗi domain team một account (producer), catalog + governance tập trung ở account trung tâm; consumer subscribe
- DataZone/SageMaker Catalog đứng trên Lake Formation làm lớp business (publish/subscribe/approval — tuần 6)
- Exam: thấy "central governance, multiple producer/consumer accounts, fine-grained" → Lake Formation (+ RAM, resource links, LF-tags)
Câu hỏi ôn tập
-
Tổ chức có 500 bảng, 30 team, bảng mới thêm hàng tuần. Quản lý quyền thế nào để không grant thủ công từng bảng?
Xem đáp án
LF-TBAC: định nghĩa LF-tags (
domain,sensitivity...), gắn tag khi tạo bảng (tự động hóa trong pipeline), grant cho mỗi team theo tag expression một lần duy nhất. Bảng mới gắn tag đúng là quyền tự áp — không grant lại. Named-resource grants cho 500×30 tổ hợp là không quản nổi. -
Yêu cầu: analyst khu vực chỉ thấy row
region = 'APAC'và không thấy cộtsalary. Cấu hình gì?Xem đáp án
Lake Formation data filter trên bảng: row filter
region = 'APAC'+ column excludesalary, rồi grant SELECT với filter đó cho role của analyst. Kết hợp row + column = cell-level security; mọi engine tích hợp LF (Athena, Spectrum, EMR, Glue) enforce nhất quán. -
Account B cần query bảng của data lake account A qua Athena. Các bước chính?
Xem đáp án
(1) A: Lake Formation grant (SELECT) trên bảng/database — hoặc theo LF-tag — cho account B (RAM share tự tạo); (2) B: accept RAM share; (3) B: tạo resource link trong catalog local trỏ tới shared database/table; (4) B: grant quyền trên resource link + shared resource cho user/role nội bộ; (5) query bằng Athena. Dữ liệu không copy — vẫn nằm S3 của A.
-
Khác nhau giữa chia sẻ bằng Lake Formation cross-account và bucket policy cross-account?
Xem đáp án
Bucket policy: quyền mức object/prefix, engine bên B phải tự hiểu layout, không column/row-level, khó audit theo bảng. Lake Formation: chia sẻ theo ngữ nghĩa table với quyền column/row/cell, catalog metadata đi kèm, thu hồi tập trung, engine analytics dùng ngay. Data lake có cấu trúc bảng → LF là chuẩn; chia sẻ file thô đơn lẻ → bucket policy đủ.
-
Đã grant LF cross-account nhưng analyst bên B chạy Athena báo không thấy bảng. Nghi ngờ gì đầu tiên?
Xem đáp án
(1) Chưa tạo resource link trong catalog B (bảng share không tự hiện trong database local); (2) chưa accept RAM share; (3) analyst chưa được grant nội bộ trên resource link (DESCRIBE) và shared table (SELECT); (4) settings cross-account version cũ/thiếu. Lỗi "không thấy bảng" thường là resource link; lỗi "AccessDenied khi query" thường là grant nội bộ thiếu.
Bài tập thực hành
- Tạo 2 LF-tags (
domain,sensitivity), gắn lên database/bảng lab và grant theo tag expression cho một role test - Tạo data filter: row
country='VN'+ exclude một cột, query bằng Athena dưới role đó - Vẽ sơ đồ cross-account sharing flow (grant → RAM → resource link → query)
- Đọc Lake Formation best practices
Tài liệu tham khảo chính thức
- Lake Formation tag-based access control
- Data filters — row and cell-level security
- Cross-account data sharing in Lake Formation
- AWS RAM
Tiếp theo: Macie, Secrets Manager và bảo vệ dữ liệu nhạy cảm