32. Cấu hình bảo mật database

1. Vì sao database cần được bảo mật ở mức cấu hình?

Trong nhiều hệ thống, database được bảo mật theo kiểu:

• “Đã đặt password rồi”

• “Không mở port ra Internet”

• “Chỉ có backend kết nối”

Những điều này là cần nhưng chưa đủ.

Thực tế cho thấy:

• Rất nhiều sự cố rò rỉ dữ liệu không đến từ Internet

• Mà đến từ:

  • User cấp quyền quá rộng

  • Cấu hình mặc định không được siết

  • File cấu hình backend bị lộ

  • Lỗi ứng dụng khai thác được DB

Nguyên tắc:

Database production phải được giả định là mục tiêu tấn công cuối cùng.

2. Nguyên tắc bảo mật database trong production

Trong loạt bài này, cấu hình bảo mật database tuân theo:

1. Không expose database

2. Quyền tối thiểu cho từng user

3. Tách user theo website / ứng dụng

4. Không lưu thông tin nhạy cảm bừa bãi

5. Có khả năng kiểm soát và truy vết

Nguyên tắc cốt lõi:

Database không tin bất kỳ thành phần nào, kể cả backend.

3. Kiểm soát truy cập network tới database

3.1. bind-address – lớp bảo mật đầu tiên

Đã cấu hình ở bài trước, nhưng cần nhắc lại vì rất quan trọng.

Trong file cấu hình MariaDB:

Đảm bảo:

Điều này đảm bảo:

• Database chỉ chấp nhận kết nối local

• Kể cả khi firewall bị cấu hình sai, DB vẫn không lộ

3.2. Không mở port database trên firewall

Không bao giờ mở:

• 3306/tcp ra Internet

Nếu cần DB cho hệ thống khác:

• Dùng VPN

• Dùng private network

• Không dùng public IP

Nguyên tắc:

Database không dành cho Internet.

4. Quản lý user database theo nguyên tắc tối thiểu

4.1. Không dùng user root cho ứng dụng

User root:

• Chỉ dùng cho quản trị

• Không xuất hiện trong file cấu hình web

Nếu phát hiện:

Ứng dụng đang dùng user root
→ Cần xử lý ngay.

4.2. Mỗi website / ứng dụng một user riêng

Ví dụ:

• site1_user

• cms_blog_user

• api_backend_user

Không dùng:

• Một user cho nhiều database

• Một user cho toàn hệ thống

5. Cấp quyền database đúng mức cần thiết

5.1. Quyền phổ biến cho website

Thông thường, website cần:

Cấp quyền:

Không cấp:

• SUPER

• FILE

• GRANT OPTION

Nguyên tắc:

Ứng dụng chỉ được làm việc trong “sân” của nó.

5.2. Kiểm tra quyền user

Đây là bước:

• Rất hay bị bỏ qua

• Nhưng cực kỳ quan trọng khi audit bảo mật

6. Bảo vệ thông tin đăng nhập database

6.1. Không hard-code thông tin nhạy cảm

Không:

• Ghi user/password DB trong code

• Commit file cấu hình chứa password lên Git

Nên:

• Dùng file config riêng

• Giới hạn quyền đọc file

6.2. Quyền file cấu hình backend

Ví dụ file config:

Thiết lập quyền:

Nguyên tắc:

Chỉ backend mới được đọc thông tin DB.

7. Giới hạn quyền thao tác nguy hiểm

7.1. Vô hiệu LOCAL INFILE (khuyến nghị)

Trong MariaDB:

Nếu bật (ON), có thể tắt trong config:

Giảm rủi ro:

• Import file trái phép

• Khai thác lỗ hổng ứng dụng

8. Log và theo dõi truy cập database

8.1. Error log – bắt buộc bật

MariaDB mặc định ghi error log.
Kiểm tra vị trí:

Theo dõi khi:

• Có lỗi truy vấn

• DB crash

• Restart bất thường

8.2. Không bật general log thường xuyên

general_log:

• Ghi mọi query

• Rất tốn tài nguyên

Chỉ bật:

• Khi debug ngắn hạn

• Và tắt ngay sau đó

Nguyên tắc:

Không đánh đổi hiệu năng production để “xem cho rõ”.

9. Bảo mật ở mức cấu trúc dữ liệu

9.1. Tránh lưu dữ liệu nhạy cảm dạng plaintext

Không lưu:

• Password

• Token

• Thông tin nhạy cảm

Nếu buộc phải lưu:

• Hash

• Mã hóa

Nguyên tắc:

Database bị lộ không được đồng nghĩa với dữ liệu bị lộ.

10. Những sai lầm bảo mật database thường gặp

• Dùng user root cho website

• Mở port DB ra Internet

• Một user cho nhiều site

• Cấp quyền quá rộng

• Không kiểm tra quyền định kỳ

Những sai lầm này:

Không gây lỗi ngay, nhưng gây hậu quả rất lớn khi bị khai thác.

11. Checklist bảo mật database cho production

•  bind-address = 127.0.0.1

•  Không mở port DB ra Internet

•  Không dùng user root cho ứng dụng

•  Mỗi website có user riêng

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

•  File config DB được bảo vệ

12. Bài tiếp theo

Trong Bài 33, chúng ta sẽ hoàn thiện mảng vận hành dữ liệu:

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

Bài này sẽ hướng dẫn:

• Chiến lược backup phù hợp production

• Backup không ảnh hưởng hệ thống

• Phục hồi an toàn khi có sự cố