Amazon SageMaker Lakehouse giờ đây hỗ trợ kiểm soát truy cập dựa trên thuộc tính (Attribute-based access control – ABAC)

Tác giả: Sandeep Adwankar and Srividya Parthasarathy 

Ngày đăng: 24 tháng 4 năm 2025 

Danh mục: Amazon Athena, Amazon Redshift, Amazon SageMaker Lakehouse, Analytics, Announcements, AWS Glue, AWS Identity and Access Management (IAM), AWS Lake Formation, Technical How-to 

Amazon SageMaker Lakehouse hiện đã hỗ trợ kiểm soát truy cập dựa trên thuộc tính (ABAC) với AWS Lake Formation, thông qua việc sử dụng các AWS Identity and Access Management principals và session tag để đơn giản hóa việc truy cập dữ liệu, tạo quyền (grant) và bảo trì. Với ABAC, bạn có thể quản lý các thuộc tính kinh doanh gắn với danh tính người dùng, cho phép tạo các chính sách truy cập động (dynamic policies) linh hoạt theo tình huống cụ thể.

SageMaker Lakehouse là một lakehouse dữ liệu hợp nhất, mở và bảo mật, nay đã hỗ trợ ABAC để cung cấp quyền truy cập hợp nhất đến các bucket Amazon S3 đa dụng, Amazon S3 Tables, kho dữ liệu Amazon Redshift, và nguồn dữ liệu như Amazon DynamoDB hoặc PostgreSQL. Bạn có thể truy vấn, phân tích, và kết hợp dữ liệu bằng việc sử dụng Redshift, Amazon Athena, Amazon EMRAWS Glue. Bạn có thể bảo mật và quản lý dữ liệu tập trung trong lakehouse bằng cách định nghĩa các quyền truy cập chi tiết (fine-grained permissions) với Lake Formation, các quyền này được áp dụng thống nhất trên tất cả các công cụ phân tích và học máy (Machine Learning). Ngoài việc hỗ trợ kiểm soát truy cập dựa trên vai trò (role-based) và dựa trên thẻ (tag-based), Lake Formation còn mở rộng hỗ trợ sang truy cập dựa trên thuộc tính để đơn giản hóa quản lý truy cập dữ liệu cho SageMaker Lakehouse, với những lợi ích như:

  • Linh hoạt (Flexibility) – Các chính sách ABAC rất linh hoạt và có thể được cập nhật để phù hợp với những thay đổi mà doanh nghiệp cần. Thay vì tạo ra những quy tắc với vai trò cố định, các hệ thống ABAC cho phép thay đổi quy tắc truy cập chỉ bằng cách thay đổi các thuộc tính của người dùng hoặc tài nguyên.
  • Hiệu quả (Efficiency) – Việc quản lý số lượng vai trò và chính sách ít hơn giúp đơn giản hóa vận hành và giảm tải cho quản trị viên.
  • Khả năng mở rộng (Scalability) – Hệ thống ABAC có khả năng mở rộng tốt cho các doanh nghiệp lớn, vì chúng có thể quản lý một số lượng lớn người dùng và tài nguyên mà không cần tạo thêm nhiều vai trò.

Tổng quan về kiểm soát truy cập dựa trên thuộc tính

Trước đây, trong SageMaker Lakehouse thì Lake Formation sẽ gán quyền truy cập đến tài nguyên dựa trên định danh của người dùng gửi yêu cầu. Khách hàng của chúng tôi đã yêu cầu khả năng thể hiện đầy đủ mức độ phức tạp cần thiết cho các quy tắc kiểm soát truy cập trong tổ chức. Các chính sách ABAC cho phép tạo ra các quy tắc truy cập linh hoạt và chi tiết hơn, phản ánh tốt hơn các nhu cầu trong thực tế. Các tổ chức bây giờ có thể gán quyền trên một tài nguyên dựa trên thuộc tính của người dùng và được điều khiển theo ngữ cảnh. Điều này cho phép quản trị viên cấp quyền truy cập vào một tài nguyên kèm theo các điều kiện xác định cặp khóa–giá trị của thuộc tính người dùng. Các thực thể IAM (IAM principals) có cặp khóa–giá trị trong IAM hoặc phiên làm việc (session tags) phù hợp sẽ được cấp quyền truy cập vào tài nguyên.

Thay vì tạo ra vai trò riêng biệt cho mỗi sự truy cập của từng thành viên trong team cho một dự án, bạn có thể thiết lập chính sách ABAC để gán quyền truy cập dựa trên thuộc tính của thành viên và vai trò của người dùng, .giảm số lượng vai trò cần tạo và quản lý. Ví dụ, nếu không có ABAC, một công ty có vai trò “quản lý khách hàng” (account manager) phụ trách 5 khu vực địa lý khác nhau sẽ phải tạo 5 vai trò IAM riêng biệt, mỗi vai trò chỉ được cấp quyền truy cập dữ liệu cho một khu vực cụ thể. Với ABAC, công ty chỉ cần gán thuộc tính “khu vực” (territory) dưới dạng cặp khóa–giá trị vào thẻ của người dùng (principal tag), và cấp quyền truy cập dữ liệu dựa trên thuộc tính đó. Nếu giá trị thuộc tính của người dùng thay đổi, quyền truy cập vào tập dữ liệu tương ứng sẽ tự động bị vô hiệu hóa mà không cần chỉnh sửa gì thêm. 

Với ABAC, bạn có thể sử dụng các thuộc tính như phòng ban hoặc quốc gia và sử dụng thẻ IAM hoặc phiên để xác định quyền truy cập vào dữ liệu, giúp việc tạo và duy trì quyền truy cập dữ liệu trở nên đơn giản hơn. Quản trị viên có thể định nghĩa quyền truy cập chi tiết với ABAC để giới hạn quyền truy cập vào cơ sở dữ liệu, bảng, hàng, cột hoặc ô bảng.

Trong bài đăng này, sẽ trình bày cách bắt đầu sử dụng ABAC trong SageMaker Lakehouse và sử dụng với nhiều dịch vụ phân tích khác nhau.

Tổng quan giải pháp

Để minh họa giải pháp, chúng ta sẽ xem xét một công ty giả định có tên là Example Retail Corp. Ban lãnh đạo của công ty Example Retail muốn phân tích dữ liệu bán hàng lưu trữ trong Amazon S3 để xác định các sản phẩm đang được ưa chuộng, hiểu rõ hành vi khách hàng và phát hiện xu hướng – từ đó hỗ trợ ra quyết định tốt hơn và tăng lợi nhuận.

Phòng Kinh doanh (Sales) thành lập một nhóm chuyên phân tích dữ liệu bán hàng với các yêu cầu truy cập dữ liệu như sau:

  • Tất cả các nhà phân tích dữ liệu (data analysts) trong phòng Sales tại US chỉ được truy cập dữ liệu bán hàng tại các khu vực thuộc US.
  • Tất cả các nhà phân tích BI (BI analysts) trong phòng Sales được truy cập toàn bộ dữ liệu (không chỉ dữ liệu bán hàng), nhưng chỉ trong các khu vực thuộc US.
  • Tất cả các nhà khoa học dữ liệu trong phòng Sales chỉ được truy cập vào dữ liệu bán hàng tại tất cả các khu vực.
  • Bất kỳ ai bên ngoài phòng ban Sales đều không được truy cập dữ liệu.

Đối với bài đăng này, chúng ta xem xét cơ sở dữ liệu salesdb, chứa bảng  store_sales có thông tin chi tiết về doanh số của cửa hàng. Bảng store_sales có lược đồ sau:

Để minh họa cho trường hợp sử dụng phân tích doanh số bán hàng, chúng ta sẽ xem xét các nhân vật đại diện (personas) sau đây từ công ty Example Retail Corp:

  • Ava là quản trị viên dữ liệu tại Example Retail Corp, chịu trách nhiệm hỗ trợ các thành viên trong nhóm với các chính sách phân quyền dữ liệu cụ thể.
  • Alice là nhà phân tích dữ liệu (data analyst), cần có quyền truy cập vào dữ liệu bán hàng tại các cửa hàng ở Mỹ để thực hiện phân tích doanh số sản phẩm.
  • Bob là nhà phân tích BI (BI analyst), cần có quyền truy cập vào toàn bộ dữ liệu (không chỉ dữ liệu bán hàng) tại các cửa hàng ở Mỹ để tạo báo cáo.
  • Charlie là nhà khoa học dữ liệu (data scientist), cần có khả năng truy cập vào dữ liệu cụ thể về bán hàng ở tất cả các khu vực để khám phá và tìm kiếm các mô hình nhằm phục vụ phân tích xu hướng.

Ava quyết định sử dụng SageMaker Lakehouse để thống nhất dữ liệu trên nhiều nguồn dữ liệu khác nhau trong khi thiết lập kiểm soát truy cập chi tiết bằng ABAC. Alice rất hào hứng về quyết định rằng cô ấy có thể dùng Athena để tạo báo cáo hàng ngày bằng chuyên môn của cô ấy. Bob hiện tại biết rằng anh ấy có thể nhanh chóng xây dựng Amazon QuickSight dashboards với những truy vấn được tối ưu hóa bằng trình tối ưu hóa dựa trên chi phí của Redshift. Charlie, là một cộng tác viên mã nguồn mở của Apache Spark, anh ấy rất vui mừng khi có thể xây dựng quy trình xử lý dựa trên Spark với Amazon EMR để xây dựng các mô hình dự báo ML.

Ava định nghĩa các thuộc tính người dùng dưới dạng các tags IAM tĩnh; các thuộc tính này có thể bao gồm các thuộc tính được lưu trữ trong nhà cung cấp danh tính (IdP) hoặc được truyền động dưới dạng session tag để thể hiện siêu dữ liệu của người dùng. Các thẻ này được gán cho người dùng hoặc vai trò IAM và có thể được sử dụng để xác định hoặc hạn chế quyền truy cập vào các tài nguyên hoặc dữ liệu cụ thể. Để biết thêm chi tiết, hãy tham khảo Tags for AWS Identity and Access Management resources và  Pass session tags in AWS STS

Trong bài viết này, Ava gán cho người dùng các thẻ IAM tĩnh (static IAM tags) để thể hiện các thuộc tính người dùng, bao gồm: phòng ban, khu vực được phân công, và vai trò hiện tại.

Bảng sau đây tóm tắt các thẻ đại diện cho thuộc tính người dùng và việc gắn thẻ cho từng người dùng:

Sau đó, Ava thiết lập các chính sách kiểm soát truy cập trong Lake Formation, nhằm cấp hoặc hạn chế quyền truy cập vào một số tài nguyên nhất định dựa trên các tiêu chí đã được xác định trước (các thuộc tính người dùng được định nghĩa bằng thẻ IAM). Cách tiếp cận này cho phép tạo ra các chính sách bảo mật linh hoạt và nhận biết theo ngữ cảnh, nơi mà quyền truy cập có thể được điều chỉnh linh hoạt bằng cách thay đổi thuộc tính của người dùng, mà không cần sửa lại quy tắc trong chính sách.

Bảng dưới đây tóm tắt các chính sách được áp dụng trong phòng Sales:

Sơ đồ sau đây minh họa kiến ​​trúc:

Việc triển khai giải pháp này bao gồm các bước chính sau.
Tại Example Retail, Ava – với vai trò là quản trị viên dữ liệu – thực hiện các bước sau:

  1. Xác định các thuộc tính người dùng (user attributes) và gán chúng cho principal (người dùng hoặc vai trò IAM).
  2. Cấp quyền truy cập vào tài nguyên (cơ sở dữ liệu và bảng) cho principal dựa trên các thuộc tính người dùng đã gán.
  3. Xác minh quyền truy cập bằng cách truy vấn dữ liệu thông qua các dịch vụ phân tích khác nhau.

Điều kiện tiên quyết

Để làm theo các bước trong bài đăng này, bạn phải hoàn thành các điều kiện tiên quyết sau:

  1. Tài khoản AWS được truy cập những dịch vụ sau:
    • Amazon S3
    • AWS Lake Formation and AWS Glue Data Catalog
    • Amazon Redshift
    • Amazon Athena
    • Amazon EMR
    • AWS Identity and Access Management (IAM)
  1. Thiết lập người dùng quản trị (admin user) cho Ava. Hướng dẫn xem Create a user with administrative access.
  2. Thiết lập S3 bucket để tải lên script – uploading script.
  3. Thiết lập quản trị viên data lake (data lake administrator), xem Create a data lake administrator.
  4. Tạo một người dùng IAM tên là Alice và gán quyền truy cập Athena, xem Data analyst permissions.
  5. Tạo một người dùng IAM Bob và gán quyền truy cập đến Redshift.
  6. Tạo người dùng IAM Charlie và gán quyền truy cập EMR Serverless.
  7. Tạo vai trò thực thi tác vụ (job runtime role): scientist_role và được dùng bởi Charlie. Xem hướng dẫn tại: Job runtime roles for Amazon EMR Serverless
  8. Thiết lập ứng dụng EMR Serverless có bật Lake Formation. Xem hướng dẫn tại: Using EMR Serverless with AWS Lake Formation for fine-grained access control
  9. Có một cơ sở dữ liệu AWS Glue hoặc bảng và Amazon Simple Storage Service (Amazon) S3 bucket để lưu dữ liệu. Đối với bài đăng này, chúng tôi sử dụng salesdb làm cơ sở dữ liệu, store_sales làm bảng và dữ liệu được lưu trữ trong bucket S3.

Xác định thuộc tính cho các IAM principal Alice, Bob, và Charlie

Ava hoàn thành các bước sau để xác định thuộc tính cho IAM principal:

  1. Đăng nhập với tư cách người dùng admin và điều hướng đến IAM console.
  2. Chọn Users trong phần Access management ở thanh điều hướng và tìm kiếm người dùng Alice.
  3. Chọn người dùng và chọn tab Tags.
  4. Chọn Add new tag và cung cấp các cặp khóa-giá trị sau:
    • Key: Department và value: sales
    • Key: Region và value: US
    • Key: Role và value: Analyst
  5. Chọn Save changes.
  6. Lặp lại các bước trên cho người dùng Bob và cung cấp các cặp khóa sau:
    • Key: Department và value: sales
    • Key: Region và value: US
    • Key: Role và value: BIAnalyst
  7. Lặp lại quy trình cho IAM role ‘scientist_role’ (đây là role mà người dùng Charlie sẽ sử dụng)
    • Key: Department và value: sales
    • Key: Region và value: ALL
    • Key: Role và value: Scientist

Cấp quyền cho Alice, Bob, Charlie bằng ABAC

Ava hiện cấp quyền cơ sở dữ liệu và bảng cho người dùng bằng ABAC.

Cấp quyền cho cơ sở dữ liệu

Hoàn thành các bước sau:

  1. Ava đăng nhập với tư cách là data lake admin và điều hướng đến Lake Formation console.
  2. Trên thanh điều hướng, dưới phần Permissions, chọn Data lake permissions.
  3. Chọn Grant.
  4. Trong trang Grant permissions, chọn Principals by attribute.
  5. Chỉ định các thuộc tính sau:
    • Key: Department  và value: sales
    • Key: Role và value: Analyst,Scientist
  6. Xem lại biểu thức chính sách được tạo ra.
  7. Đối với Permission scope, chọn This account.
  8. Tiếp theo, chọn các tài nguyên catalog để cấp quyền:
    • Đối với Catalogs, nhập ID tài khoản.
    • Đối với Databases, nhập salesdb.
  9. Với Database permissions, chọn Describe.
  10.  Chọn Grant.

Ava hiện xác minh quyền cơ sở dữ liệu bằng cách điều hướng đến Databases tab bên dưới Data Catalog và tìm kiếm CSDL salesdb. Chọn salesdb và chọn View under Actions.

Cấp quyền truy cập tables cho Alice

Hoàn tất các bước sau để tạo bộ lọc dữ liệu nhằm xem các cột doanh số cụ thể trong các bản ghi store_sales có country=US:

  1. Trên Lake Formation console, chọn Data filters dưới Data Catalog trong thanh điều hướng.
  2. Chọn Create new filter.
  3. Đặt tên bộ lọc dữ liệu là us_sales_salesonlydata
  4. Đối với Target catalog, nhập ID tài khoản.
  5. Đối với Target database, chọn salesdb.
  6. Đối với Target table, chọn store_sales.
  7. Đối với quyền truy cập cấp độ cột, hãy chọn Include columns: store_id, item_code, transaction_date, product_name, country, sales_price, và quantity.
  8. Đối với quyền truy cập cấp độ hàng, chọn Filter rows và nhập bộ lọc hàng country=’US’.
  9. Chọn Create data filter.
  1. Trên trang Grant permissions, chọn Principals by attribute.
  2. Chỉ định các thuộc tính:
    • Key: Department và value: sales
    • Key: Role với value: Analyst
    • Key: Region và value: US
  3. Xem lại biểu thức chính sách được tạo ra.
  4. Với Permission scope, chọn This account.
  5. Chọn các tài nguyên catalog để cấp quyền:
    • Catalogs: Account ID
    • Databases: salesdb
    • Table: store_sales
    • Data filters: us_sales
  6. Với Data filter permissions, chọn Select.
  7. Chọn Grant.

Cấp quyền truy cập tables cho Bob

Thực hiện các bước sau để tạo bộ lọc dữ liệu (data filter) cho phép chỉ xem các bản ghi trong bảng store_sales với country=US:

  1. Trong bảng điều khiển Lake Formation, chọn Data filters trong phần Data Catalog ở thanh điều hướng bên trái.
  2. Chọn Create new filter.
  3. Nhập tên bộ lọc là us_sales.
  4. Ở mục Target catalog, nhập ID tài khoản AWS.
  5. Ở mục Target database, chọn salesdb.
  6. Ở mục Target table, chọn store_sales.
  7. Phần Column-level access, giữ nguyên mặc định là Access to all columns (Truy cập tất cả các cột).
  8.  phần Row-level access, nhập bộ lọc hàng country=’US’.
  9. Chọn Create data filter.

Thực hiện các bước sau để cấp quyền truy cập bảng cho Bob:

  1. Trên trang Grant permissions, chọn Principals by attribute.
  2. Xác định các thuộc tính như sau:
  • Key: Department và value: sales
  • Key: Role với value: BIAnalyst
  • Key: Region và value: US
  1. Xem lại biểu thức chính sách được tạo ra.
  2. Với Permission scope, chọn This account.
  3. Chọn các tài nguyên trong Catalog mà bạn muốn cấp quyền truy cập:
    • Catalogs: Account ID
    • Databases: salesdb
    • Table: store_sales
  4. Với Data filter permissions, chọn Select.
  5. Chọn Grant.

Cấp quyền truy cập tables cho Charlie

Thực hiện các bước sau:

  1. Trên trang Grant permissions (Cấp quyền), chọn Principals by attribute 
  2. Chỉ định các thuộc tính (attributes) phù hợp với Charlie 
  1. Key: Department và value: sales
  2. Key: Role với value: Scientist
  3. Key: Region và value: ALL
  1. Với Permission scope, chọn This account.
  2. Chọn các tài nguyên trong Catalog mà bạn muốn cấp quyền truy cập:
    1. Catalogs: Account ID
    2. Databases: salesdb
    3. Table: store_sales
  3. Với Table permissions, chọn Select.
  4. Với Data permissions, hãy chỉ định các cột sau: store_id, transaction_date, product_name, country, sales_price, quantity.
  5. Chọn Grant.

Alice hiện kiểm tra quyền truy cập bảng bằng cách điều hướng đến thẻ Tables trong mục Data Catalog, sau đó tìm kiếm bảng dữ liệu store_sales. Chọn store_sales và chọn View dưới phần Actions. Các ảnh chụp màn hình sau đây hiển thị thông tin chi tiết cho cả hai nhóm quyền:

Phân tích dữ liệu sử dụng Athena để xây dựng báo cáo bán hàng hàng ngày

Alice, nhà phân tích dữ liệu đăng nhập vào bảng điều khiển Athena và chạy truy vấn sau:

select * from "salesdb"."store_sales" limit 5

Alice có các thuộc tính người dùng như Department=sales, Role=Analyst, Region=US, và sự kết hợp thuộc tính này cho phép cô ấy truy cập vào dữ liệu bán hàng tại US theo cột bán hàng cụ thể, mà không truy cập vào dữ liệu khách hàng như được hiển thị trong ảnh chụp màn hình sau.

BI Analyst sử dụng Redshift để xây dựng bảng thông tin bán hàng

Bob, BI Analyst, đăng nhập vào bảng điều khiển Redshift và chạy truy vấn sau:

select * from "salesdb"."store_sales" limit 10

Bob có các thuộc tính người dùng như Department=sales, Role=BIAnalyst, Region=US, và sự kết hợp thuộc tính này cho phép anh ta truy cập vào tất cả các cột bao gồm dữ liệu khách hàng cho dữ liệu bán hàng tại US.

Nhà khoa học dữ liệu sử dụng Amazon EMR để xử lý dữ liệu bán hàng

Cuối cùng, Charlie đăng nhập vào bảng điều khiển EMR và gửi một EMR job với vai trò thực thi (runtime role) là scientist_role. Charlie sử dụng tập lệnh sales_analysis.py đã được tải lên bucket S3. Anh ấy chọn ứng dụng EMR Serverless đã được tạo với Lake Formation được bật (enabled).

Charlie gửi lệnh chạy hàng loạt tác vụ bằng cách chọn các giá trị sau:

  • Name: sales_analysis_Charlie
  • Runtime_role: scientist_role
  • Script location: <s3_script_path>/sales_analysis.py
  • Đối với thuộc tính spark, cung cấp khóa là spark.emr-serverless.lakeformation.enabled và giá trị là true.
  • Trong phần Metastore configuration (Cấu hình Metastore), chọn Use AWS Glue Data Catalog as metastore (Sử dụng AWS Glue Data Catalog làm metastore). Charlie giữ nguyên các cấu hình còn lại theo mặc định.

Sau khi job chạy xong, Charlie có thể xem kết quả đầu ra bằng cách chọn stdout trong mục Driver log files (tệp nhật ký trình điều khiển).

Charlie sử dụng scientist_role với vai trò thực thi của job, kèm theo các thuộc tính Department=sales, Role=Scientist, Region=ALL, và sự kết hợp thuộc tính này cho phép anh ta truy cập vào các cột được chọn của tất cả dữ liệu bán hàng.

Dọn dẹp tài nguyên

Thực hiện các bước sau để xóa các tài nguyên đã tạo nhằm tránh phát sinh chi phí không mong muốn:

  • Xóa các IAM user đã tạo.
  • Xóa cơ sở dữ liệu và bảng AWS Glue đã tạo trong quá trình làm theo bài viết (nếu có).
  • Xóa các tài nguyên của Athena, Redshift và EMR đã sử dụng cho bài hướng dẫn này.

Kết luận

Trong bài viết này, chúng tôi đã minh họa cách bạn có thể sử dụng tính năng kiểm soát truy cập dựa trên thuộc tính của Amazon SageMaker Lakehouse, thông qua IAM principal và session tag, để đơn giản hóa việc truy cập dữ liệu, cấp quyền và bảo trì. Với mô hình ABAC, bạn có thể quản lý quyền truy cập dựa trên các thuộc tính nghiệp vụ động gắn liền với danh tính người dùng, và bảo mật dữ liệu trong Lakehouse bằng cách định nghĩa các quyền chi tiết (fine-grained permissions) trong Lake Formation. Những quyền này được thực thi nhất quán trên các công cụ phân tích và máy học (ML) khác nhau. Để tìm hiểu thêm, vui lòng tham khảo tài liệu chính thức: documentation. Chúng tôi khuyến khích bạn hãy thử sử dụng SageMaker Lakehouse với ABAC và chia sẻ phản hồi với chúng tôi. 

Về các tác giả

Sandeep Adwankar là Senior Product Manager tại AWS. Hiện đang làm việc tại khu vực Vịnh California, ông hợp tác với các khách hàng trên toàn cầu để chuyển đổi các yêu cầu kinh doanh và kỹ thuật thành các sản phẩm giúp doanh nghiệp cải thiện việc quản lý, bảo mật và truy cập dữ liệu.

Srividya Parthasarathy là Senior Big Data Architect trong nhóm AWS Lake Formation. Cô đam mê xây dựng các giải pháp data mesh và thường xuyên chia sẻ kiến thức với cộng đồng.