33. Quản lý user, quyền và database

1. Vì sao quản lý user và quyền database thường bị làm sai?

Trong rất nhiều hệ thống đang vận hành, việc quản lý database diễn ra theo cách:

• Tạo user một lần, dùng mãi

• Website mới → dùng lại user cũ

• Quyền cấp “cho đủ dùng”, không bao giờ rà soát

• Không ai nhớ user nào dùng cho site nào

Hệ quả:

• Khi có sự cố, không biết user nào gây ra

• Khi bàn giao, không ai dám xóa user

• Khi bị lộ thông tin, phạm vi ảnh hưởng rất rộng

Nguyên nhân cốt lõi:

Không có mô hình quản lý user – quyền – database rõ ràng ngay từ đầu.

2. Mô hình quản lý database chuẩn cho production

Trong loạt bài này, chúng ta áp dụng mô hình:

1 website / ứng dụng
→ 1 database
→ 1 user database
→ quyền tối thiểu

Không ngoại lệ, trừ khi có lý do kỹ thuật rất rõ ràng.

3. Quy ước đặt tên database và user (rất quan trọng)

3.1. Vì sao cần quy ước đặt tên?

Quy ước tốt giúp:

• Nhìn tên là biết dùng cho đâu

• Dễ audit

• Dễ xóa khi không còn sử dụng

• Tránh nhầm lẫn giữa các môi trường

3.2. Quy ước khuyến nghị

Ví dụ với website cntt.it:

• Database:

   

  cntt_it_db 

• User:

   

  cntt_it_user 

Với staging:

• Database:

   

  cntt_it_stg_db 

• User:

   

  cntt_it_stg_user 

Nguyên tắc:

Tên phải phản ánh: site + môi trường + vai trò.

4. Tạo database và user theo chuẩn production

4.1. Tạo database

4.2. Tạo user riêng

• Password:

  • Dài

  • Không dùng lại

  • Không đặt giống user khác

4.3. Cấp quyền tối thiểu

Không cấp:

• SUPER

• PROCESS

• FILE

• GRANT OPTION

Nguyên tắc:

Ứng dụng không được có quyền quản trị database.

5. Quản lý nhiều website trên cùng database server

5.1. Không dùng chung database cho nhiều site

Dù “có vẻ tiện”, nhưng:

• Dễ lộ dữ liệu chéo

• Backup/restore khó

• Một site lỗi có thể làm ảnh hưởng site khác

Chỉ dùng chung database khi:

• Ứng dụng được thiết kế multi-tenant

• Có kiểm soát chặt chẽ ở tầng ứng dụng

5.2. Không dùng chung user cho nhiều database

Sai lầm rất phổ biến:

Hệ quả:

• Nếu lộ user → lộ toàn bộ dữ liệu

• Không thể cô lập sự cố

6. Rà soát và audit user database định kỳ

6.1. Liệt kê toàn bộ user

Câu hỏi cần trả lời:

• User này dùng cho site nào?

• Có còn sử dụng không?

• Có quyền vượt mức cần thiết không?

6.2. Kiểm tra quyền của từng user

Nếu thấy:

• Quyền không nhớ cấp

• Quyền vượt nhu cầu hiện tại

→ Cần rà soát lại ngay.

7. Xóa user và database không còn sử dụng

7.1. Nguyên tắc trước khi xóa

Trước khi xóa:

• Xác nhận website đã ngừng

• Có backup

• Không xóa “nghi ngờ”

7.2. Xóa user

7.3. Xóa database

Nguyên tắc:

Xóa có kiểm soát còn an toàn hơn giữ lại không ai dám động.

8. Phân tách môi trường: live – staging – test

Không dùng chung:

• Database

• User

• Password

Giữa:

• Production

• Staging

• Test

Ngay cả khi:

• Chạy cùng server

Nguyên tắc:

Sai sót ở staging không được phép ảnh hưởng production.

9. Ghi chép và tài liệu hóa (thường bị bỏ qua)

Nên có bảng quản lý nội bộ:

Việc này giúp:

• Bàn giao dễ

• Audit nhanh

• Không “mò” khi có sự cố

10. Những sai lầm phổ biến khi quản lý user & database

• Không đặt quy ước tên

• Dùng user root

• Một user cho nhiều site

• Không audit định kỳ

• Không dám xóa user cũ

Những sai lầm này:

Làm database ngày càng khó kiểm soát theo thời gian.

11. Checklist quản lý user & database cho production

•  Mỗi website có DB riêng

•  Mỗi DB có user riêng

•  Quyền user ở mức tối thiểu

•  Có quy ước đặt tên rõ ràng

•  Audit user & quyền định kỳ

•  Ghi chép đầy đủ

12. Bài tiếp theo

Trong Bài 34, chúng ta sẽ bước sang nội dung rất quan trọng:

Backup và phục hồi database an toàn cho production

Bài này sẽ giúp:

• Không mất dữ liệu khi có sự cố

• Backup không ảnh hưởng hiệu năng

• Phục hồi có kiểm soát, không hoảng loạn