Passkey, MFA và phân quyền theo dòng dữ liệu (RLS): bảo vệ tài khoản và dữ liệu của ứng dụng nội bộ

Ứng dụng nội bộ như CRM, công cụ báo cáo hay trang quản trị thường giữ dữ liệu khách hàng, nhưng bảo vệ chúng bằng 2 thứ mỏng: 1 mật khẩu ở cửa vào và vài dòng cấu hình ở cửa dữ liệu.

Bài đối chiếu đến ngày 21/10/2026, dựa trên NIST SP 800-63B-4, đặc tả W3C WebAuthn Level 3, trang passkey của FIDO Alliance, tài liệu PostgreSQL 18 và Supabase. Phần luật Việt Nam đọc qua 1 bản sao trên trang tin bên thứ ba.

Bài trả lời 3 câu hỏi: kiểu đăng nhập nào chống được lừa đảo, phân quyền theo dòng (Row Level Security, RLS) làm gì và hay sai ở đâu, và nên làm gì trong 4 tuần. Click Star đã có bài riêng về phân tích dữ liệu bằng AI, luật dữ liệu cá nhân, cơ sở dữ liệu vận hành và Supabase Select; bài này không lặp lại các chủ đề đó.

Điểm chính

• NIST SP 800-63B-4 (chính thức tháng 7/2025) nói mã người dùng tự nhập, kể cả OTP, không chống được lừa đảo. Mã gửi qua SMS hoặc cuộc gọi là phương án bị hạn chế, tổ chức phải có lựa chọn thay thế.
• Passkey là cặp khóa mã hóa gắn với đúng tên miền của dịch vụ, nên trang giả không dùng lại được. WebAuthn Level 3 là Khuyến nghị của W3C từ 25/8/2026.
• Theo tài liệu Supabase đọc ngày 21/10/2026, passkey vẫn là tính năng thử nghiệm. Nên thêm passkey theo giai đoạn, không bỏ ngay cách đăng nhập hiện có.
• Với PostgreSQL, bảng đã bật RLS mà chưa có chính sách thì không dòng nào được thấy hay sửa (trừ chủ bảng và vai trò bỏ qua RLS). Khóa bí mật của Supabase bỏ qua RLS, nên chỉ được nằm ở máy chủ.
• 3 lỗi hay gặp: quên bật RLS, chính sách dựa trên dữ liệu người dùng tự sửa được, và khóa dịch vụ nằm trong mã chạy ở trình duyệt.
• Chính sách phải có bộ kiểm thử tự động và nhật ký truy cập. Lộ trình 4 tuần ở cuối bài xếp việc theo thứ tự rủi ro.

Vì sao ứng dụng nội bộ cần cả 2 lớp bảo vệ

Lớp đăng nhập quyết định ai được vào, lớp dữ liệu quyết định người đã vào được thấy gì. Thiếu RLS thì 1 tài khoản hợp lệ hoặc 1 lỗi trong mã đọc được dữ liệu của người khác. Đăng nhập yếu thì kẻ lấy được mật khẩu thừa hưởng đúng quyền của nạn nhân.

Mật khẩu, MFA và OTP qua SMS yếu ở đâu

Mật khẩu vẫn cần, nhưng quy tắc đã đổi. Theo NIST SP 800-63B-4 (phần 3.1.1, đọc 21/10/2026), mật khẩu dùng 1 mình tối thiểu 15 ký tự, còn khi nằm trong xác thực nhiều yếu tố thì tối thiểu 8. NIST cấm bắt buộc ký tự đặc biệt hay đổi định kỳ, và yêu cầu chặn mật khẩu đã lộ.

MFA là thêm 1 bằng chứng ngoài mật khẩu, nhưng không phải MFA nào cũng chống lừa đảo. NIST định nghĩa chống lừa đảo (phishing resistance) là giữ bí mật xác thực khỏi kẻ mạo danh mà không dựa vào sự cảnh giác của người dùng, và nói mã nhập bằng tay như OTP không đạt.

Lý do: gõ mã vào trang giả thì kẻ gian nhận mã ngay và dùng khi còn hiệu lực.

SMS còn thêm điểm yếu riêng. NIST (phần 3.1.3.3 và 3.2.9) xếp việc gửi mã qua mạng điện thoại là phương án bị hạn chế: tổ chức phải cung cấp ít nhất 1 lựa chọn không bị hạn chế, báo rủi ro cho người dùng và có kế hoạch chuyển đổi. Supabase cũng cảnh báo MFA qua điện thoại dễ bị tấn công hoán đổi SIM (đọc 21/10/2026).

Mã từ ứng dụng xác thực (TOTP) hơn SMS vì không đi qua mạng điện thoại, nhưng vẫn là mã nhập tay nên chưa chống lừa đảo theo định nghĩa trên (Click Star suy ra).

Passkey là gì và hoạt động thế nào

Theo FIDO Alliance, passkey là cặp khóa mã hóa gắn với tài khoản trên 1 trang web hoặc ứng dụng, xây trên chuẩn FIDO2 (gồm WebAuthn và CTAP). Người dùng xác nhận bằng vân tay, khuôn mặt hoặc PIN của thiết bị; dữ liệu sinh trắc học ở lại thiết bị.

Khi đăng ký, thiết bị giữ khóa riêng và gửi khóa công khai cho máy chủ. Khi đăng nhập, máy chủ gửi 1 thử thách ngẫu nhiên, thiết bị ký bằng khóa riêng sau khi người dùng mở khóa, và máy chủ kiểm chữ ký.

Khả năng chống lừa đảo đến từ phạm vi của khóa. Đặc tả W3C WebAuthn Level 3 (Khuyến nghị ngày 25/8/2026, đọc 21/10/2026) nói mỗi thông tin xác thực gắn với 1 bên tin cậy, xác định bằng RP ID, và chỉ dùng được với đúng thực thể đã đăng ký.

Trang giả ở tên miền khác không nhận được chữ ký hợp lệ, và người dùng không cần tự phát hiện trang giả.

Passkey có 2 dạng: đồng bộ (sao lưu qua nhà cung cấp như trình quản lý mật khẩu của hệ điều hành) và gắn thiết bị (nằm trên 1 khóa bảo mật, không rời nó).

NIST không cho phép passkey đồng bộ ở mức AAL3 vì khóa có thể được xuất ra. Click Star đánh giá loại đồng bộ vẫn là lựa chọn thực tế cho ứng dụng nội bộ thông thường.

Từ mức AAL2 (trong 3 mức của NIST), bên xác thực phải cung cấp ít nhất 1 lựa chọn chống lừa đảo. NIST là chuẩn cho chính phủ Mỹ, Click Star dùng như khung kỹ thuật, không như nghĩa vụ pháp lý.

Triển khai passkey và khôi phục tài khoản

Với Supabase, passkey có API trong supabase-js từ phiên bản 2.105.0, nhưng tài liệu (đọc 21/10/2026) ghi rõ đây là tính năng thử nghiệm, giao diện có thể đổi không báo trước.

Cần quyết định trước khi người dùng đăng ký: RP ID phải ổn định vì đổi RP ID làm mọi passkey đã có mất tác dụng, tối đa 5 nguồn (origin), và người dùng SSO hay ẩn danh chưa đăng ký được.

Tài liệu Supabase không nói phiên passkey được tính là aal1 hay aal2; hãy tự đọc claim aal trong token trước khi dùng nó làm điều kiện.

Khôi phục quyết định thành bại. NIST (phần 4.2) nêu 4 nhóm: mã khôi phục đã lưu, mã được gửi, người liên hệ khôi phục và xác minh danh tính lại. Mã đã lưu phải có ít nhất 64 bit ngẫu nhiên, lưu dạng băm và hủy sau khi dùng; mã được gửi chỉ có hiệu lực 10 phút qua tin nhắn và 24 giờ qua email.

Click Star đề xuất: mỗi người đăng ký ít nhất 2 passkey (ví dụ điện thoại và khóa bảo mật), khôi phục cần người quản lý xác nhận và để lại nhật ký.

Phân quyền theo dòng (RLS) là gì

RLS là cơ chế của PostgreSQL giới hạn dòng nào 1 người dùng đọc hoặc sửa được. Theo tài liệu PostgreSQL 18 (mục 5.9, đọc 21/10/2026), RLS chỉ có hiệu lực sau khi bật bằng ALTER TABLE, và nếu đã bật mà chưa có chính sách nào thì không dòng nào được thấy hay sửa.

Mỗi chính sách có 2 biểu thức: USING quyết định dòng hiện có nào hiển thị hoặc bị tác động, WITH CHECK quyết định dòng nào được tạo hay ghi vào. Vai trò BYPASSRLS luôn bỏ qua RLS; chủ bảng bỏ qua trừ khi dùng FORCE ROW LEVEL SECURITY.

Trên Supabase, yêu cầu từ trình duyệt chạy dưới vai trò anon (chưa đăng nhập) hoặc authenticated. Hàm auth.uid() trả về mã người dùng đang gọi, và null khi chưa đăng nhập, nên chính sách "mã người dùng bằng cột user_id" tự loại người chưa đăng nhập (tài liệu Supabase, đọc 21/10/2026).

Các lỗi thường gặp với RLS và Supabase

Quên bật RLS. Công cụ kiểm tra của Supabase (đọc 21/10/2026) có mục 0013 "Table publicly accessible" ở mức ERROR: bảng trong schema public mà RLS tắt thì ai có địa chỉ dự án cũng đọc, sửa, xóa được dòng.

Hậu quả công khai là CVE-2025-48757. Theo trang Tenable (công bố 30/5/2025, CVSS 9,3), chính sách RLS không đủ ở các trang do Lovable tạo cho phép người chưa xác thực đọc hoặc ghi bảng tùy ý; bên cung cấp phản đối vì mỗi khách hàng tự chịu trách nhiệm dữ liệu của mình.

Dùng khóa dịch vụ ở phía trình duyệt. Theo tài liệu khóa API của Supabase (đọc 21/10/2026), khóa bí mật chạy với vai trò service_role có thuộc tính BYPASSRLS nên bỏ qua mọi chính sách. Tài liệu cấm đặt nó trong trình duyệt hay mã công khai, và cấm đặt tên biến có tiền tố như NEXT_PUBLIC_ vì trình đóng gói gửi nó xuống máy khách.

Chính sách dựa trên dữ liệu người dùng tự sửa được. Mục 0015 của Supabase (mức ERROR) cảnh báo chính sách đọc user_metadata, vì người dùng sửa được trường này. Dữ liệu phân quyền phải nằm ở app_metadata hoặc bảng vai trò riêng.

Cách kiểm thử chính sách và ghi nhật ký truy cập

Kiểm thử RLS phải kiểm cả điều được phép lẫn điều bị cấm. Theo tài liệu Supabase (đọc 21/10/2026), bộ thử viết bằng pgTAP, chạy bằng lệnh supabase test db.

Cách đặt khẳng định có bẫy. Thiếu quyền hoặc vi phạm WITH CHECK thì bắt lỗi mã 42501. Thao tác bị USING lọc mất dòng thì trả về rỗng chứ không báo lỗi, nên phải đọc lại dòng gốc. Đừng dùng lives_ok cho việc ghi được phép, vì nó vẫn qua khi không dòng nào khớp.

Về nhật ký, Supabase Auth ghi đăng nhập, đổi mật khẩu và xác minh MFA kèm thời điểm, mã người dùng và địa chỉ IP. Muốn truy vấn bằng SQL phải bật ghi vào cơ sở dữ liệu; tài liệu không nêu thời gian lưu giữ.

Với dữ liệu, tiện ích pgaudit ghi hoạt động theo phiên hoặc theo đối tượng. Tài liệu cảnh báo ghi quá rộng che mất sự kiện quan trọng, và ghi cả dòng trả về có thể làm lộ giá trị nhạy cảm.

Gắn với yêu cầu an toàn thông tin của luật dữ liệu cá nhân

Click Star đọc Luật số 91/2025/QH15 (thông qua 26/6/2025, hiệu lực 1/1/2026) qua 1 bản sao trên ketoananpha.vn, không qua cổng chính thức. Hãy đối chiếu văn bản gốc; đây không phải tư vấn pháp lý.

Theo bản sao đó, điểm c khoản 1 Điều 37 yêu cầu bên kiểm soát dữ liệu thực hiện biện pháp quản lý và kỹ thuật phù hợp, rà soát khi cần.

Khoản 3 Điều 30 yêu cầu hệ thống dùng AI, dữ liệu lớn hay điện toán đám mây dùng xác thực, định danh phù hợp và phân quyền truy cập khi xử lý dữ liệu cá nhân. Luật không nêu tên passkey hay RLS.

Đăng nhập mạnh và RLS có đủ là "biện pháp phù hợp" hay không còn tùy mức rủi ro và hướng dẫn chi tiết. Click Star chưa đọc các điều kỹ thuật của Nghị định 356/2025/NĐ-CP (ngày 31/12/2025) nên không kết luận về chúng.

Đánh giá của Click Star. Với ứng dụng nội bộ có dữ liệu khách hàng, thứ tự hợp lý là RLS đúng trước, MFA cho tài khoản quản trị sau, rồi passkey. Lỗi RLS làm lộ dữ liệu hàng loạt mà không cần chiếm tài khoản nào, còn passkey chỉ bảo vệ từng tài khoản.

Passkey nên được thêm vào chứ chưa nên thay ngay, vì tính năng của Supabase còn thử nghiệm và quy trình khôi phục cần kiểm chứng.

Về lợi ích: Click Star có làm phần mềm theo yêu cầu và tích hợp hệ thống nên có lợi ích thương mại liên quan; mọi mục trong bài đều tự làm được theo tài liệu chính thức.

Lộ trình 4 tuần

• Tuần 1, kiểm kê: liệt kê mọi bảng mở ra API, bật RLS, chạy công cụ kiểm tra của Supabase để xử lý mục 0013 và 0015, và tìm khóa bí mật trong mã trình duyệt.
• Tuần 2, chính sách và kiểm thử: viết chính sách riêng cho từng thao tác, đặt chỉ mục cho cột lọc, thêm bộ pgTAP cho 3 bảng nhạy cảm nhất.
• Tuần 3, đăng nhập: bắt buộc MFA cho quản trị viên, thêm chính sách hạn chế đòi aal2 cho bảng nhạy cảm, thử passkey với 1 nhóm nhỏ và kiểm claim aal của phiên.
• Tuần 4, khôi phục và nhật ký: viết quy trình khôi phục, bắt mỗi người có ít nhất 2 cách đăng nhập, bật nhật ký Auth và pgaudit cho bảng nhạy cảm, đặt lịch rà soát hằng tháng.

Cách đo (khung của Click Star): số bảng mở ra API chưa có RLS (mục tiêu 0), số tài khoản quản trị chưa có cách đăng nhập chống lừa đảo, số bài kiểm thử RLS đang chạy, và thời gian khôi phục tài khoản.

Những sai lầm thường gặp

1. Bật RLS nhưng chưa viết chính sách, rồi chữa cháy bằng khóa dịch vụ.
2. Đặt khóa bí mật ở phía trình duyệt hoặc trong biến có tiền tố công khai.
3. Phân quyền dựa trên user_metadata, nơi người dùng tự sửa được.
4. Coi mã SMS hay mã ứng dụng là đã chống lừa đảo, dù chúng là mã nhập tay.
5. Triển khai passkey mà không có đường khôi phục, hoặc để khôi phục chỉ cần 1 bước.
6. Chỉ kiểm thử phần được phép, không kiểm người chưa đăng nhập và người ở dòng khác.

Điều chưa biết

Click Star chưa có số đo về tỷ lệ ứng dụng nội bộ ở Việt Nam thiếu RLS hay chỉ dùng mật khẩu đơn lẻ, cũng chưa có nguồn mở được về tỷ lệ chấp nhận passkey của người dùng Việt Nam.

Chưa rõ phiên passkey của Supabase được tính là aal1 hay aal2 và khi nào tính năng rời trạng thái thử nghiệm. Click Star chưa đọc phụ lục B của NIST về passkey đồng bộ.