Cấu hình quyền truy cập với GRANT và REVOKE

Hãy tưởng tượng dữ liệu của bạn giống như một pháo đài, và mỗi cư dân trong pháo đài đều có quyền riêng: có người chỉ được đi dạo trong sân, có người giữ chìa khóa kho báu, còn có người ngồi trong phòng ngai vàng và điều khiển mọi thứ. Trong database của tụi mình, vai trò này được thực hiện bởi các lệnh GRANT và REVOKE. Chính tụi nó quyết định ai được đi đâu và làm gì.

Lệnh GRANT, đúng như tên gọi, cho phép cấp quyền truy cập vào resource (ví dụ: database, table, schema) cho các role nhất định. Nó giống như "vé mời dự tiệc", bạn quyết định ai được đọc, ghi hay phá đồ đạc.

Lệnh REVOKE thì ngược lại, nó thu hồi quyền đã cấp trước đó. Kiểu như: "Ê, tiệc hết rồi, trả chìa khóa ở cửa ra nhé".

Cấp quyền với GRANT

Bắt đầu từ tầng cao nhất — database. Để user có thể kết nối vào database, bạn phải cấp quyền connect. Dùng lệnh này nè:

GRANT CONNECT ON DATABASE database_name TO role_name;

Ví dụ, nếu có database university và role student, mình cho phép sinh viên kết nối bằng câu lệnh sau:

GRANT CONNECT ON DATABASE university TO student;

Nhưng chỉ kết nối thôi chưa đủ để làm mọi thứ đâu. Nếu muốn user tạo object trong database, phải cấp thêm quyền tạo:

GRANT CREATE ON DATABASE university TO student;

Có thể kiểm tra quyền trên database bằng lệnh:

\l+ university

Thu hồi quyền với REVOKE

Nếu sinh viên bỗng dưng có dấu hiệu khả nghi (ví dụ tạo quá nhiều table hơn dự kiến), bạn có thể thu hồi quyền tạo bằng lệnh:

REVOKE CREATE ON DATABASE university FROM student;

Sau đó, sinh viên chỉ còn được kết nối, không còn "sáng tạo" lung tung nữa.

Cấu hình quyền truy cập ở cấp schema

Schema về cơ bản là "phòng" trong database, nơi chứa table, view và các object khác. Để user làm việc với object trong schema, bạn có thể cấu hình quyền đọc, ghi hoặc tạo object.

Cấp quyền cho schema

Giả sử có schema public (mặc định có trong mỗi database). Bạn có thể cho user xem nội dung schema như sau:

GRANT USAGE ON SCHEMA public TO student;

Nhưng chỉ USAGE thôi thì chưa đủ để làm việc với table. Nếu muốn user tạo object mới, thêm quyền này:

GRANT CREATE ON SCHEMA public TO student;

Như vậy, sinh viên vừa được đọc vừa được tạo table trong schema public.

Thu hồi quyền trên schema

Nếu sinh viên bắt đầu spam schema bằng mấy table tên kiểu bad_idea_01, bạn có thể hạn chế quyền của họ:

REVOKE CREATE ON SCHEMA public FROM student;

Bây giờ sinh viên không thể thêm table mới nữa. Trật tự đã được lập lại!

Cấu hình quyền truy cập ở cấp table

Table chắc là object phổ biến nhất trong database rồi. Cùng xem cách cấu hình quyền cho table nhé. Có ba nhóm quyền chính: đọc, ghi và sửa đổi.

Quyền đọc

Để cho user đọc nội dung table, dùng lệnh:

GRANT SELECT ON TABLE table_name TO role_name;

Ví dụ, để sinh viên đọc dữ liệu từ table courses:

GRANT SELECT ON TABLE courses TO student;

Bây giờ user student có thể chạy lệnh SELECT trên table courses.

Quyền ghi

Nếu muốn user chèn dòng mới vào table, cấu hình như sau:

GRANT INSERT ON TABLE table_name TO role_name;

Ví dụ:

GRANT INSERT ON TABLE courses TO student;

Giờ sinh viên có thể thêm khóa học mới vào table. Nhưng khoan... mình chắc đây là ý hay chứ?

Quyền sửa đổi và xóa

Nếu user cần update dòng hiện có hoặc xóa chúng, phải cấp quyền UPDATE và DELETE tương ứng.

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

Lưu ý: đừng lạm dụng quyền này nhé. Nếu cho sinh viên quyền xóa dữ liệu, họ có thể vô tình (hoặc cố ý) phá hỏng mọi thứ.

Ví dụ: tạo role với quyền hạn chế

Giả sử bạn muốn tạo role cho giảng viên, họ chỉ được đọc dữ liệu về sinh viên và khóa học, không được xóa record. Làm như này nè:

1. Tạo role:

CREATE ROLE teacher;

2. Cấp quyền đọc cho table students và courses:

GRANT SELECT ON TABLE students, courses TO teacher;

3. Hạn chế quyền xóa:

REVOKE DELETE ON TABLE students, courses FROM teacher;

Vậy là giảng viên chỉ có đúng quyền cần thiết, không dư thừa.

Kết hợp GRANT và REVOKE để cấu hình linh hoạt

Giả sử có role intern cần hạn chế quyền. Họ chỉ được truy cập dữ liệu khóa học, tuyệt đối không được đụng vào dữ liệu sinh viên. Làm như này nhé:

1. Chỉ cho phép truy cập table courses:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. Đảm bảo role intern không có quyền trên table students:

REVOKE ALL ON TABLE students FROM intern;

Kết hợp này giúp bạn cấu hình quyền truy cập cực kỳ chính xác.

Ví dụ thực tế trong dự án

Cơ chế quản lý quyền này rất hay được dùng trong dự án thực tế. Ví dụ:

1. Trong shop online, quyền trên table user và đơn hàng được chia cho các role "admin", "operator" và "guest".
2. Trong hệ thống trường đại học, admin có thể thêm/sửa khóa học, còn sinh viên chỉ được xem.
3. Trong hệ thống ngân hàng, quyền truy cập tài khoản khách hàng được phân chia giữa nhân viên các phòng ban khác nhau.