Giới thiệu

Trong thời đại công nghệ số hiện nay, việc bảo mật dữ liệu ngày càng trở nên quan trọng hơn bao giờ hết. Các vi phạm dữ liệu đang gia tăng nhanh chóng, gây ra nhiều hệ lụy cho doanh nghiệp và người dùng. Một giải pháp hiệu quả để bảo vệ dữ liệu là triển khai các chính sách bảo mật cấp hàng dòng (Row-Level Security - RLS) trong Supabase SQL.

Bài viết này sẽ hướng dẫn bạn cách triển khai RLS trong Supabase, cách xây dựng các chính sách bảo mật, và các trường hợp sử dụng nâng cao.

Nội dung

• Hiểu về RLS
• Cơ sở dữ liệu ví dụ: Ứng dụng chia sẻ công thức
• Sử dụng RLS trong Supabase
• Các thành phần cơ bản của chính sách SQL cho RLS
• Tạo chính sách SELECT
• Tạo chính sách INSERT/UPDATE
• Chính sách RLS nâng cao cho các trường hợp sử dụng thực tế
• Kiểm tra và xác thực việc triển khai RLS
• Khắc phục sự cố thường gặp
• Kết luận

Hiểu về RLS

RLS là một tính năng của hệ quản trị cơ sở dữ liệu Postgres, cho phép bạn xác định các chính sách truy cập cho các loại truy vấn khác nhau trên một bảng. Mỗi khi một truy vấn được thực thi trên bảng đó, các chính sách này sẽ được áp dụng. Việc sử dụng RLS giúp bạn tăng cường bảo mật dữ liệu bằng cách tạo ra nhiều lớp bảo vệ.

Cơ sở dữ liệu ví dụ: Ứng dụng chia sẻ công thức

Bài viết này sử dụng một ứng dụng chia sẻ công thức nấu ăn làm ví dụ để khám phá cách tạo ra các chính sách khác nhau. Các bảng comments và recipes đều tham chiếu tới bảng users qua trường user_id. Trường này sẽ được sử dụng trong các chính sách để đảm bảo người dùng đúng được cấp quyền truy cập để sửa đổi hoặc xóa công thức và bình luận.

Sử dụng RLS trong Supabase

Khi bạn tạo một bảng thông qua bảng điều khiển Supabase, RLS sẽ được kích hoạt theo mặc định. Tuy nhiên, nếu bạn không xây dựng ứng dụng của mình thông qua ClickOps, bạn sẽ tạo bảng bằng câu lệnh SQL. Ví dụ dưới đây tạo một bảng có tên recipes và kích hoạt RLS:

-- Tạo bảng recipes
CREATE TABLE recipes (
    ...
);

-- Kích hoạt RLS cho bảng recipes
ALTER TABLE recipes ENABLE ROW LEVEL SECURITY;

Khi bạn đã kích hoạt RLS nhưng chưa tạo các chính sách áp dụng, nó sẽ cho phép tất cả người dùng đã xác thực truy cập đầy đủ vào cơ sở dữ liệu và chặn tất cả quyền truy cập từ người dùng ẩn danh. Điều này giúp ngăn ngừa rò rỉ dữ liệu một cách vô tình.

Các thành phần cơ bản của chính sách SQL cho RLS

Nếu bạn muốn tiến xa hơn việc chặn quyền truy cập của người dùng ẩn danh, bạn cần định nghĩa một số chính sách.

Có năm phần trong một chính sách RLS mà bạn sẽ sử dụng để cấu hình quyền truy cập cho cơ sở dữ liệu của mình:

• Tên
• Bảng
• Lệnh
• Vai trò
• Điều kiện

Tên

Tên chính sách được sử dụng để tham chiếu đến chính sách sau khi nó được tạo. Nên tạo một quy ước đặt tên để sử dụng cho tất cả các chính sách và mô tả rõ ràng về chức năng của chính sách đó.

Bảng

Đã đến lúc bạn cần chỉ định chính sách cho một bảng cụ thể bằng cách sử dụng từ khóa ON:

ON recipes

Lệnh

Bạn cũng cần xác định các thao tác mà chính sách này áp dụng. Bạn có thể chỉ định các thao tác chuẩn như SELECT, INSERT, UPDATE, hoặc DELETE.

Vai trò

Supabase cung cấp hai vai trò mặc định: anon và authenticated. Chính sách mới sẽ được áp dụng cho vai trò PUBLIC của Postgres.

Điều kiện

Mỗi phần của câu lệnh CREATE POLICY trước đó đều nhằm xác định khi nào chính sách sẽ được áp dụng. Bước tiếp theo là định nghĩa chính sách thực tế với một số điều kiện.

Tạo chính sách SELECT

Bây giờ bạn có thể kết hợp tất cả để tạo một chính sách thực sự. Ứng dụng ví dụ cần cho phép người dùng đã xác thực xem các công thức mà họ đã tạo.

CREATE POLICY "Cho phép người dùng đã xác thực xem công thức của họ" ON recipes
    FOR SELECT
    TO authenticated
    USING (user_id = (SELECT auth.uid()))

Tạo chính sách INSERT/UPDATE

Người dùng của bạn có thể xem tất cả các công thức của họ, nhưng bạn cũng cần một chính sách để ngăn họ truy cập hoặc sửa đổi dữ liệu mà họ không nên có quyền truy cập.

CREATE POLICY "Cho phép người dùng đã xác thực tạo công thức" ON recipes
    FOR INSERT
    TO authenticated
    WITH CHECK (user_id = (SELECT auth.uid()))

Chính sách RLS nâng cao cho các trường hợp sử dụng thực tế

Nếu bạn có một ứng dụng đa khách hàng, bạn cần hạn chế quyền truy cập vào dữ liệu của khách hàng khác. Để làm điều này, bạn cần tạo các bản ghi cho từng khách hàng và liên kết mỗi người dùng với một khách hàng cụ thể.

Kiểm tra và xác thực việc triển khai RLS

Để kiểm tra hiệu suất và xác thực việc triển khai RLS của bạn, bạn có thể sử dụng lệnh EXPLAIN ANALYZE của Postgres để xem cách thức các chính sách RLS được thực thi.

Khắc phục sự cố thường gặp

Nếu bạn gặp sự cố khi chạy truy vấn trong Supabase console nhưng lại không nhận được kết quả dự kiến, đó có thể là một lỗi cấu hình RLS.

Kết luận

Chính sách RLS được viết tốt có thể ngăn ngừa rò rỉ dữ liệu, bảo vệ người dùng của bạn. Sau khi đọc bài viết này, bạn sẽ hiểu cách xây dựng những chính sách này, các trường hợp sử dụng nâng cao, và cách viết các bài kiểm tra để đảm bảo chúng hoạt động như mong đợi.