Kết Nối Database
Kết Nối Database
Database bên ngoài có thể tự động lộ ra thành REST API (không cần code trung gian) — nhưng đây là rủi ro quyền ghi cao nhất trong nhóm 70-73. Row Level Security (RLS) là tầng bảo mật ở từng dòng dữ liệu, khác hẳn OAuth scope.
Nắm vững nguyên lý và khái niệm nền tảng trước khi đi vào công cụ thực tế.
Áp dụng quy trình từng bước, case study thực chiến và template mẫu có sẵn.
Kiểm tra checklist hoàn thành, né tránh các sai lầm kinh điển để vận hành bền vững.
Nắm vững các khái niệm nền tảng, cơ chế hoạt động và mô hình tư duy cốt lõi.
1. Mục tiêu học tập
Sau bài này, bạn có thể:
2. Khái niệm cốt lõi
Vấn đề cần giải quyết: 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.
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”. 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: 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” — 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_logsghi 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_logsmỗ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.
Quy trình thực thi từng bước, case study cụ thể và bộ prompt/template áp dụng ngay.
6. Hướng dẫn từng bước
Checklist kết nối Database ngoài an toàn:
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
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ớitừ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
10. Bài tập thực hành
- Thiết kế 1 bảng
sync_logscho 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.
Checklist kiểm tra mức độ sẵn sàng, nhận diện các bẫy sai lầm và nguyên tắc vàng vận hành.
11. Checklist
12. Lỗi thường gặp
(Suy luận từ nguyên tắc + bài 65/74, không phải quan sát độc lập.)
15. Best practices
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.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.
⚠️ 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.
📚 17. Nguồn tham khảo
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); 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).