</>Học Dev
Bài học

Tuần 7 - Ngày 2: Lake Formation nâng cao — LF-tags và Cross-account

Tuần 7 – Ngày 2

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
BngordersTeamVNthy:idcountryemailtotalidcountrytotal1VNa@x.vn1001VN1002USb@y.us200(rowUSblc,3VNc@z.vn300ctemailbn)

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ế

ACCOUNTA(producerdatalake)ACCOUNTB(consumer)LakeFormationgrantNhnsharequaAWSRAM(table/databasehocLF-tagexpression)acceptresourcesharechoaccountB/OU/organizationToRESOURCELINKtrongcatalogB(contrtisharedtable)GrantnibBchoanalystAthena/RedshiftSpectrumquery
  • 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áchDữ liệuPhù hợp
LF cross-accountKhông copy, quyền fine-grainedData lake S3/Glue nhiều account
Redshift data sharingKhông copy, liveGiữa các warehouse Redshift
Bucket policy cross-accountObject-level thôFile đơn giản, không cần table semantics
Copy/replicateCopyKhi 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

  1. 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.

  2. Yêu cầu: analyst khu vực chỉ thấy row region = 'APAC' và không thấy cột salary. Cấu hình gì?

    Xem đáp án

    Lake Formation data filter trên bảng: row filter region = 'APAC' + column exclude salary, 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.

  3. 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.

  4. 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 đủ.

  5. Đã 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


Tiếp theo: Macie, Secrets Manager và bảo vệ dữ liệu nhạy cảm