Kết Nối Database

Level: L7 — MCP, API & Connectors (Bài 9/11 theo thứ tự sản xuất — · Đối tượng: Người đã học bài 65-71 — đã kết nối 2 tích hợp thật

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Giải thích cách 1 database có thể được lộ ra thành API tự động, không cần viết code trung gian.
Giải thích Row Level Security (RLS) là gì và vì sao nó là 1 tầng bảo mật khác hẳn OAuth scope (bài 74).
Nhận diện đây là bài có rủi ro quyền ghi cao nhất trong nhóm 4 bài tích hợp (70-73) — vì sao.
Thiết kế 1 kết nối Database ngoài cho Notes App để lưu log tích hợp.

2. Khái niệm cốt lõi

Bước 1 — Concept: bài 55 (L6) dạy Database là 1 trong 4 lớp kiến trúc nội bộ — bạn tự thiết kế, tự kiểm soát hoàn toàn. Bài này dạy tình huống khác: kết nối tới 1 database tách biệt (ví dụ: 1 project Supabase riêng, dùng để lưu log các lần Notes App đồng bộ với Google/ Notion/CRM) — 1 hệ thống có API riêng, cần xác thực riêng, giống hệt các tích hợp khác trong Level 7.

Bước 2/3 — Real implementation (Supabase làm ví dụ, áp dụng chuẩn REST đã học): Supabase tự động sinh 1 REST API trực tiếp từ schema database — “khi bạn cập nhật database, thay đổi lập tức có thể truy cập qua API” [S111]. Mỗi bảng (table) trở thành 1 endpoint gọi được ngay, không cần viết code trung gian riêng — khác các bài 70-72 (mỗi bài cần hiểu mô hình dữ liệu của 1 sản phẩm SaaS cụ thể), ở đây bạn chạm trực tiếp vào cấu trúc database thật.

Row Level Security (RLS) — điểm đặc thù quan trọng nhất bài này [S111]: là mô hình bảo mật có sẵn của Postgres, giới hạn quyền truy cập dữ liệu ở từng dòng (row), không chỉ ở cấp bảng/API. “Vì database được lộ ra qua endpoint HTTP, RLS đảm bảo dù ai đó có được credential API, họ chỉ truy cập được đúng những dòng dữ liệu quyền của họ cho phép” [S111] — tạo ra 1 ranh giới bảo mật ở tầng database, khác hẳn OAuth scope (bài 74, kiểm soát “được gọi API nào”) hay Notion capability (bài 71, kiểm soát “được làm gì với 1 trang”).

3. Tại sao nội dung này quan trọng

Trong 4 bài tích hợp (70-73), đây là bài có rủi ro quyền ghi cao nhất — 1 API key có quyền ghi vào database có thể thay đổi trực tiếp dữ liệu gốc, không qua bất kỳ lớp kiểm tra nghiệp vụ nào (khác Notion/CRM, nơi API vẫn đi qua logic riêng của sản phẩm đó trước khi chạm dữ liệu). Đây là lý do RLS tồn tại — và là lý do bài này quan trọng nhất để hiểu trước khi tổng hợp rủi ro ở bài 75.

4. Cơ chế hoạt động

Luồng kết nối Notes App với Database ngoài (Supabase, lưu log tích hợp):

Tạo 1 project Supabase riêng (tách biệt khỏi database nội bộ của Notes App nếu có) — ví dụ: 1 bảng sync_logs ghi lại mỗi lần Notes App đồng bộ với Google/Notion/CRM.
Thiết lập RLS cho bảng đó — ví dụ: chỉ cho phép ghi (insert), không cho phép đọc/sửa/xóa từ API key dùng cho việc ghi log.
Lấy API key từ Dashboard, lưu qua biến môi trường (bài 63, L6).
Notes App gọi API (method POST, đúng bài 65) tới endpoint bảng sync_logs mỗi khi hoàn thành 1 lần đồng bộ.

5. Mental model

Tiếp nối ẩn dụ mạng lưới nhà cung cấp: nếu Google/Notion/CRM (70-72) là những “nhà cung cấp” có nhân viên tiếp tân riêng kiểm tra đơn hàng trước khi vào kho (logic nghiệp vụ của sản phẩm), thì kết nối trực tiếp tới Database giống việc bạn có chìa khóa đi thẳng vào kho hàng, không qua tiếp tân. RLS giống việc kho hàng tự chia thành nhiều ngăn có khóa riêng — kể cả bạn có chìa khóa vào kho, bạn chỉ mở được đúng ngăn quyền bạn cho phép, không phải toàn bộ kho.

6. Hướng dẫn từng bước

Checklist kết nối Database ngoài an toàn (tổng hợp của người viết, dựa trên S111 + bài 74):

Xác định chính xác bảng/dữ liệu cần truy cập — không dùng chung 1 API key cho toàn bộ database nếu chỉ cần 1 bảng.
Thiết lập RLS cho từng bảng trước khi lộ ra qua API — không lộ API rồi mới nghĩ tới bảo mật sau.
Phân biệt quyền đọc và quyền ghi rõ ràng — với Notes App chỉ cần ghi log, không cần đọc lại toàn bộ bảng.
Lưu API key qua biến môi trường, không hardcode (bài 62/63, L6).
Kiểm tra: nếu API key này bị lộ, RLS đã cấu hình có giới hạn đủ thiệt hại tối đa không?

7. Ví dụ thực tế

Vendor example cụ thể: bảng sync_logs trong Supabase có RLS chỉ cho phép insert (thêm dòng mới), không cho select/update/delete qua API key dùng cho Notes App — nghĩa là kể cả nếu key này bị lộ, kẻ tấn công chỉ có thể thêm dữ liệu rác vào log, không thể đọc, sửa, hay xóa log đã có — thiệt hại bị giới hạn rõ ràng nhờ RLS, đúng minh họa cho nguyên tắc least privilege ở tầng database.

8. Prompt/template/workflow

Khung thiết kế kết nối Database (tái sử dụng):

Bảng cần truy cập: [tên bảng]
Quyền cần: [chỉ đọc / chỉ ghi / đọc và ghi]
Chính sách RLS tương ứng: [mô tả ai/điều kiện gì được phép làm gì với
từng dòng]
API key lưu ở: [biến môi trường, tên biến]

9. Visual hoặc diagram cần thiết

Hình 7.9 — Database trực tiếp (kho nhiều ngăn khoá riêng) vs Google/Notion/CRM (cửa hàng có tiếp tân).

10. Bài tập thực hành

Thiết kế 1 bảng sync_logs cho Notes App theo khung mục 8.
Viết ra chính sách RLS cụ thể: dòng nào được insert, ai/điều kiện gì được đọc lại (nếu có).
Giải thích bằng lời của bạn: vì sao RLS là “tầng bảo mật thứ 2,” khác với việc chỉ dựa vào OAuth scope (bài 74) hay giới hạn ở tầng ứng dụng.

11. Checklist

Giải thích được cách database có thể tự động lộ ra thành API.
Giải thích được RLS là gì và vì sao nó khác OAuth scope.
Nhận diện được đây là bài rủi ro quyền ghi cao nhất trong nhóm 70-73.
Thiết kế được 1 kết nối Database ngoài an toàn cho dự án tích lũy.

12. Lỗi thường gặp

(Suy luận từ nguyên tắc [S111] + bài 65/74, không phải quan sát độc lập.)

Lộ API có quyền ghi/xóa toàn bộ database mà không cấu hình RLS trước — rủi ro nghiêm trọng nhất trong cả nhóm 70-73.
Nghĩ RLS và OAuth scope là cùng 1 thứ — RLS kiểm soát ở tầng database (từng dòng dữ liệu), OAuth scope kiểm soát ở tầng API (được gọi endpoint nào) — 2 tầng riêng biệt, cần cả hai.
Dùng chung 1 API key có quyền cao cho mọi tác vụ thay vì tạo key riêng, quyền hạn chế cho từng mục đích cụ thể.

13. Giới hạn & khi nào KHÔNG nên áp dụng

Bài này dùng Supabase làm ví dụ minh họa — không phải mọi database đều có cơ chế tự động sinh API + RLS như Postgres/Supabase; database khác có thể cần 1 lớp API trung gian tự viết (đã học nguyên lý ở bài 65).
Không dạy thiết kế schema database — đó là kỹ năng riêng, vượt phạm vi Level 7 (tập trung vào kết nối/tích hợp, không phải thiết kế dữ liệu).
Với dữ liệu cực kỳ nhạy cảm (tài chính, y tế), RLS là điều kiện cần chứ không đủ — cần thêm mã hóa, audit log, và có thể cần chuyên gia bảo mật database chuyên sâu hơn phạm vi bài này.

14. An toàn & quản trị (Safety/Governance)

Đây là bài có rủi ro cao nhất trong nhóm 70-73 — không phải nhận định chủ quan, mà có căn cứ kỹ thuật rõ ràng: không giống Google/Notion/CRM (nơi API luôn đi qua 1 lớp logic nghiệp vụ của chính sản phẩm đó trước khi chạm dữ liệu), kết nối Database trực tiếp có thể bỏ qua mọi lớp kiểm tra trung gian nếu không cấu hình đúng. RLS là lớp phòng vệ bắt buộc, không phải tùy chọn, khi lộ bất kỳ database nào ra ngoài qua API — đây là nội dung sẽ dẫn thẳng vào phần tổng hợp rủi ro ở bài 75.

15. Best practices

Luôn cấu hình RLS trước khi lộ 1 bảng ra qua API, không làm sau.
Tạo API key riêng, quyền hạn chế cho từng mục đích — không dùng chung 1 key “toàn quyền” cho mọi tác vụ.
Ưu tiên quyền insert-only cho các tác vụ chỉ cần ghi log, không cấp quyền đọc/sửa/xóa nếu không thực sự cần.
Định kỳ rà soát chính sách RLS khi schema database thay đổi.

16. Nội dung nâng cao (không bắt buộc)

Ngoài RLS, Postgres (nền tảng Supabase dùng) còn có khái niệm Roles và Grants — hệ thống phân quyền truyền thống ở cấp database, tồn tại từ trước khi có REST API tự động — RLS thực chất xây trên nền hệ thống quyền này, không thay thế nó. Vượt phạm vi người mới bắt đầu của Level 7, nhưng đáng biết nếu sau này cần cấu hình quyền phức tạp hơn cho nhiều loại người dùng khác nhau truy cập cùng 1 database.

17. Nguồn tham khảo

[S111] REST API, Supabase Docs — supabase.com/docs — cơ chế tự động sinh API, xác thực qua API key, Row Level Security.
Dẫn chiếu (không trích dẫn mới): bài 55 (Database như 1 lớp kiến trúc nội bộ, L6 — đối chiếu ranh giới); bài 65 (REST); bài 62/63 (secrets, biến môi trường, L6); bài 74 (Authentication, đối chiếu với OAuth scope).

18. Ngày kiểm chứng

Nội dung kiểm chứng qua nguồn Tier 1 (S111) ngày 2026-07-13. Cơ chế RLS là tính năng nền tảng ổn định của Postgres; chi tiết cụ thể cách cấu hình trên giao diện Supabase có thể đổi theo thời gian — khuyến nghị re-verify trước khi triển khai thật.