Trino SQL Bài học 44: Quản trị bảo mật và phân quyền truy cập (GRANT, REVOKE)

Mục tiêu bài học:

• Hiểu cơ chế ủy quyền và kiểm soát truy cập (Access Control) trong kiến trúc của Trino.

• Nắm vững cú pháp GRANT để cấp quyền và REVOKE để thu hồi quyền.

• Chuyển đổi tư duy từ việc cấp quyền cá nhân sang mô hình Phân quyền theo vai trò (RBAC - Role-Based Access Control).

• Nhận diện rủi ro bảo mật tàng hình từ mệnh đề WITH GRANT OPTION.

1. Triết lý Bảo mật: Không ai được tin tưởng tuyệt đối (Zero Trust)

Trong một hệ thống Data Lake của doanh nghiệp, hàng nghìn nhân viên từ các phòng ban khác nhau sẽ cùng truy cập vào Trino. Nếu một Data Analyst vô tình chạy lệnh DROP TABLE hoặc DELETE dữ liệu kế toán, hậu quả sẽ vô cùng thảm khốc.

Do đó, các hệ thống Dữ liệu luôn tuân theo Nguyên tắc Đặc quyền Tối thiểu (Principle of Least Privilege): Một tài khoản chỉ được cấp chính xác những quyền mà họ cần để làm việc, không thừa không thiếu.

Đặc thù của Trino: Trino sở hữu hệ thống kiểm soát truy cập tích hợp (Built-in Access Control). Tuy nhiên, trên môi trường Production, các công ty thường dùng Trino kết hợp với các hệ thống quản trị bảo mật tập trung của Hadoop/Data Lake như Apache Ranger hoặc AWS Lake Formation. Lệnh GRANT/REVOKE bạn gõ trên Trino sẽ được đẩy xuống các hệ thống này để thực thi.

2. GRANT: Ban phát quyền lực

Lệnh GRANT dùng để trao một hoặc nhiều đặc quyền (Privileges) trên một đối tượng cụ thể (Table, Schema) cho một người dùng (User) hoặc một vai trò (Role).

Các đặc quyền cơ bản: SELECT (Đọc), INSERT (Thêm), DELETE (Xóa), UPDATE (Sửa), và ALL PRIVILEGES (Toàn quyền).

Cú pháp tổng quát:

SQL

GRANT [quyền] ON [đối_tượng] TO [người_dùng_hoặc_nhóm];

Ví dụ thực tế:

• Chỉ cho phép đọc dữ liệu (Dành cho Data Analyst):

  SQL

  GRANT SELECT ON iceberg.sales.orders TO user_alice;
  
  

• Cho phép cả đọc và ghi (Dành cho Data Engineer / ETL Jobs):

  SQL

  GRANT SELECT, INSERT, UPDATE ON iceberg.sales.orders TO user_etl_pipeline;
  
  

• Giao toàn quyền quản trị một bảng:

  SQL

  GRANT ALL PRIVILEGES ON iceberg.sales.orders TO user_bob;
  
  

3. Quản trị nâng cao với Mô hình RBAC (Role-Based Access Control)

Nếu công ty có 50 Data Analyst, việc bạn gõ lệnh GRANT SELECT 50 lần cho 50 User (và phải gõ lại mỗi khi có nhân viên mới) là một quy trình vận hành thảm họa.

Mô hình RBAC (Phân quyền theo vai trò) giải quyết triệt để vấn đề này. Thay vì gán quyền cho Người, bạn gán quyền cho một "Cái ghế" (Role). Ai ngồi vào ghế đó sẽ tự động có quyền.

Quy trình chuẩn kỹ sư:

1. Tạo một vai trò (Tạo ghế):

   SQL

   CREATE ROLE data_analyst;
   
   

2. Cấp quyền cho vai trò đó (Gán quyền cho ghế): Bạn có thể cấp quyền cho toàn bộ Schema (thay vì cấp từng bảng).

   SQL

   GRANT SELECT ON SCHEMA iceberg.sales TO ROLE data_analyst;
   
   

3. Trao vai trò cho nhân viên (Mời người ngồi vào ghế):

   SQL

   GRANT data_analyst TO user_alice;
   GRANT data_analyst TO user_charlie;
   
   

Khi Alice nghỉ việc, bạn chỉ cần gỡ Role data_analyst khỏi Alice là hệ thống tự động khóa mọi truy cập của cô ấy.

4. REVOKE: Thu hồi quyền lực

Bất cứ quyền gì đã ban phát bằng GRANT đều có thể lấy lại bằng REVOKE. Cú pháp đảo ngược hoàn toàn.

SQL

-- Thu hồi quyền INSERT trên bảng orders của tài khoản ETL
REVOKE INSERT ON iceberg.sales.orders FROM user_etl_pipeline;

-- Gỡ bỏ vai trò data_analyst khỏi user_charlie (Anh ta chuyển sang phòng ban khác)
REVOKE data_analyst FROM user_charlie;

Lưu ý: Việc thu hồi quyền có hiệu lực gần như ngay lập tức. Nếu người dùng đang chạy dở một câu truy vấn dài, nó có thể bị đánh sập giữa chừng do mất quyền (Tùy thuộc cấu hình hệ thống).

5. Góc nhìn Kỹ sư: Hiểm họa mang tên "WITH GRANT OPTION"

Khi bạn dùng GRANT, có một mệnh đề tùy chọn cực kỳ quyền lực nhưng cũng cực kỳ nguy hiểm.

SQL

GRANT SELECT ON iceberg.sales.orders TO user_bob WITH GRANT OPTION;

Khi bạn đính kèm WITH GRANT OPTION, bạn không chỉ cho Bob quyền SELECT, mà bạn còn cho Bob quyền được phép đem quyền SELECT đó đi phát lại cho những người khác.

Chuỗi lây nhiễm (Privilege Escalation): Admin cấp cho Bob (WITH GRANT). Bob vui tay cấp cho Alice (WITH GRANT). Alice nghỉ việc nhưng trước khi đi lại cấp cho một tài khoản Ảo. Đến khi xảy ra sự cố rò rỉ dữ liệu, Admin sẽ mất phương hướng trong việc truy vết xem ai thực sự đang nắm quyền đọc bảng dữ liệu đó.

Best Practice bảo mật:

Tuyệt đối KHÔNG BAO GIỜ sử dụng WITH GRANT OPTION trên môi trường Production trừ khi bạn đang cấp quyền cho một tài khoản Service Account có nhiệm vụ làm "Sub-Admin" tự động hóa phân quyền. Quyền sinh quyền sát phải luôn được tập trung tại một đầu mối duy nhất (Data Steward hoặc Admin).