Database Firewall Kiến trúc của Database Firewall và các thành phần cốt lõi

Kiến trúc Database Firewall​

1. Tổng quan​

1.1. Định nghĩa​

Database Firewall (DBF) là một lớp bảo vệ chuyên biệt. Một cơ chế bảo mật chuyên dụng được đặt phía trước hệ quản trị cơ sở dữ liệu (DBMS) để giám sát và theo dõi mọi kết nối tới CSDL.
Database Firewall hoạt động như một proxy trung gian, chặn và phân tích từng câu lệnh SQL trước khi để nó chạm tới engine xử lý, nhằm ngăn chặn các truy vấn độc hại như SQL injection, tràn bộ đệm (buffer overflow) và tấn công từ chối dịch vụ (DoS).

1.2. Phân biệt với các lớp phòng thủ khác​

Nếu tường lửa mạng trả lời câu hỏi "ai được kết nối tới đâu", thì Database Firewall trả lời câu hỏi "kết nối đó được phép làm gì với dữ liệu" khác biệt căn bản so với tường lửa mạng truyền thống, vốn chỉ lọc theo IP/cổng mà không đọc được nội dung câu lệnh.
Database Firewall cũng không thay thế WAF (tường lửa ứng dụng web, lọc request/response HTTP) hay IPS/IDS mạng (dựa trên chữ ký gói tin). DBF lấp đúng khoảng trống mà hai lớp kia không thấy tới: câu SQL thực sự được DBMS thực thi, kể cả khi nó đến từ một kết nối nội bộ, một job nền.

1.3. Phân biệt DAM và DPE​

Hai thuật ngữ hay bị dùng lẫn: DAM (Database Activity Monitoring) chỉ theo dõi và cảnh báo, không chặn. DPE (Database Policy Enforcement) vừa giám sát vừa có thể chặn. DBF là sản phẩm/kiến trúc có thể vận hành ở một trong hai chế độ này, tuỳ cách triển khai

2. Kiến trúc tổng thể​

2.1. Ba mặt phẳng kiến trúc​

View attachment 21507
Giống nhiều hệ thống hạ tầng mạng/bảo mật hiện đại, DBF tách chức năng thành ba mặt phẳng độc lập về mặt vận hành, dù đôi khi được đóng gói chung trong một appliance:

• Data plane (mặt phẳng dữ liệu): nơi từng gói tin, từng câu lệnh SQL thực sự đi qua. Đây là phần nhạy cảm nhất về độ trễ: mọi xử lý ở đây phải diễn ra gần với tốc độ đường truyền (line-rate).
• Control plane (mặt phẳng điều khiển): nơi quyết định chính sách được tính toán theo thời gian thực: nhận cấu trúc câu lệnh đã phân tích từ data plane, đối chiếu với tập luật, trả về quyết định allow/block/alert. Có thể tách vật lý khỏi data plane (ví dụ Collector của Guardium tách khỏi S-TAP) để không làm nghẽn đường truyền chính.
• Management plane (mặt phẳng quản lý): nơi con người tương tác: soạn chính sách, xem báo cáo tuân thủ, cấu hình hệ thống. Mặt phẳng này không nằm trên đường đi của bất kỳ giao dịch nào nên có thể chấp nhận độ trễ cao hơn nhiều mà không ảnh hưởng hiệu năng ứng dụng.

2.2. Đường ống xử lý​

View attachment 21508
Để hình dung rõ hơn, xét ví dụ: một kẻ tấn công gửi câu lệnh SELECT * FROM users WHERE username='admin' OR '1'='1'. Câu lệnh này sẽ đi qua đường ống xử lý gồm 5 bước sau:

• Query Interceptor (Bộ chặn truy vấn): bắt giữ câu lệnh này ngay khi nó vừa rời khỏi client, trước khi kịp chạm tới database.
• Traffic Analyzer (Bộ phân tích lưu lượng): đọc và phân tích cấu trúc câu lệnh, nhận ra OR '1'='1' là điều kiện luôn đúng (dấu hiệu SQL injection kinh điển).
• Policy Engine (Bộ thực thi chính sách): đối chiếu với bộ quy tắc đã cấu hình và ra quyết định: chặn.
• Chuyển tiếp: câu lệnh nguy hiểm không được gửi tới Database Engine; chỉ câu lệnh an toàn mới đi tiếp.
• Ghi log: sự kiện chặn được ghi chi tiết (thời gian, IP nguồn, nội dung) và gửi về Management Server.

2.3. Bộ phân tích "hiểu" câu lệnh SQL như thế nào​

Đây là phần cốt lõi quyết định một DBFW thông minh hay chỉ là bộ lọc thô sơ. Traffic Analyzer không so khớp từng ký tự, mà xử lý câu lệnh qua 3 bước:

• Tách cấu trúc câu lệnh: nhận diện đâu là từ khoá (SELECT, WHERE...), đâu là tên bảng, đâu là giá trị dữ liệu người dùng nhập vào.
• Chuẩn hoá: thay mọi giá trị cụ thể bằng ký hiệu chung. Ví dụ hai câu sau tuy khác nhau về chữ nhưng có cùng "khuôn dạng":

2.4. Kiểm tra hai chiều: không chỉ request, còn cả response​

Một Database Firewall không chỉ kiểm tra câu lệnh gửi đi mà còn kiểm tra tập kết quả trả về. Ba lý do khiến chiều phản hồi (response path) quan trọng không kém chiều yêu cầu (request path):

• Phát hiện trích xuất dữ liệu bất thường: một câu SELECT * hoàn toàn hợp lệ về cú pháp vẫn có thể là dấu hiệu tấn công nếu số dòng hoặc số byte trả về vượt xa baseline hành vi của tài khoản đó.
• Che dữ liệu động (dynamic data masking): thay vì chặn cả câu lệnh, DBF có thể để câu lệnh chạy nhưng che các cột nhạy cảm (ví dụ số thẻ tín dụng) trong tập kết quả trước khi trả về, tuỳ theo vai trò của người truy vấn.
• Ngăn rò rỉ thông tin qua thông báo lỗi: lỗi gốc từ hệ quản trị cơ sở dữ liệu (DBMS) thường lộ tên bảng, tên cột, hoặc phiên bản engine; DBF có thể thay bằng thông báo lỗi trung tính trước khi trả về client.

3. Các thành phần cốt lõi​

4. Cơ chế bảo vệ nhiều lớp​

Một DBFW tốt không dựa vào một cách duy nhất để phát hiện tấn công, mà chồng nhiều lớp lên nhau:

• Lớp 1 (So khớp mẫu tấn công - signature-based): đối chiếu với cơ sở dữ liệu các mẫu tấn công đã biết, giống phần mềm diệt virus so khớp với danh sách virus đã biết. Nhanh, chính xác cao với tấn công quen thuộc, nhưng bó tay trước kiểu tấn công mới.
• Lớp 2 (Danh sách trắng - allow-list): chỉ cho phép chạy những câu lệnh đã được duyệt từ trước. Đây là cách chặt chẽ nhất kể cả tấn công chưa từng xuất hiện cũng bị chặn vì nó không nằm trong danh sách được duyệt. Đánh đổi là cần thời gian "học" trước để biết ứng dụng thường chạy những câu lệnh nào.
• Lớp 3 (Phát hiện hành vi bất thường - anomaly detection): gắn cờ khi có dấu hiệu lệch khỏi thói quen thông thường, ví dụ một tài khoản vốn chỉ đọc vài chục dòng dữ liệu mỗi ngày bỗng tải về hàng trăm nghìn dòng cùng lúc.

5. Chính sách và thứ tự đánh giá luật​

Khi một câu lệnh khớp với nhiều luật cùng lúc, DBFW không đánh giá ngẫu nhiên mà theo một trật tự cố định, nguyên tắc chung là first-match-wins (luật nào khớp trước thì luật đó quyết định):

• Ngữ cảnh phiên: địa chỉ IP, tài khoản DB, tài khoản hệ điều hành, chương trình client đang dùng.
• Chữ ký SQL: câu lệnh có nằm trong danh sách trắng/đen đã học hay không.
• Đối tượng cơ sở dữ liệu: loại lệnh (DML/DDL/DCL) và bảng/view bị tác động.
• Luật mặc định: áp dụng cho mọi trường hợp không khớp luật nào ở trên; chính luật này quyết định hệ thống đang vận hành theo kiểu allow-list hay deny-list.

Hiểu đúng thứ tự này quan trọng vì một luật đặt sai vị trí (ví dụ đặt "luật mặc định" lên trước) có thể vô hiệu hoá toàn bộ các luật chi tiết phía sau.

6. Các mô hình triển khai​

6.1. Theo vị trí đặt hệ thống:​

• Network-based: DBFW chỉ nhận một bản sao lưu lượng (port mirroring), không đứng trên đường đi thật. Nhẹ, không làm chậm hệ thống nhưng không đọc được kết nối đã mã hoá và không thể chặn, chỉ cảnh báo sau khi việc đã rồi.
• Host-based: một agent (tiến trình nhỏ) cài trực tiếp lên máy chủ database, quan sát được cả những kết nối cục bộ ngay trên máy chủ mà cách trên bỏ sót đổi lại chiếm thêm tài nguyên CPU/RAM.
• Memory/kernel sensor: một sensor gắn trực tiếp vào tiến trình của database, liên tục đọc vùng nhớ dùng chung của DBMS (ví dụ System Global Area của Oracle) để lấy câu lệnh SQL ngay khi nó được thực thi. Đây là kỹ thuật bao phủ tốt nhất — thấy được cả traffic từ mạng, từ host, lẫn những đường vòng ("cửa sau") mà hai kỹ thuật trên bỏ sót. Đánh đổi: cần driver/sensor tương thích sâu với từng phiên bản DBMS cụ thể.
• Log-based / native audit: trích xuất thông tin từ nhật ký giao dịch hoặc audit trail sẵn có của chính DBMS. Không cần thay đổi cấu trúc mạng, nhưng vì xử lý sau khi câu lệnh đã chạy xong nên không thể chặn, chỉ phục vụ giám sát và điều tra sau sự cố.

6.2. Theo cách can thiệp:​

7. Quy trình triển khai thực tế​

Một tổ chức không thể bật chế độ chặn ngay từ ngày đầu, làm vậy rất dễ chặn nhầm hoạt động hợp lệ. Trình tự hợp lý thường là:

• Giám sát trước (Monitoring Mode): chạy DBFW ở chế độ chỉ quan sát, ghi log toàn bộ traffic trong một khoảng thời gian đủ dài (thường vài tuần) để nắm được toàn cảnh bình thường của hệ thống.
• Xây dựng chính sách: dựa trên log thu thập được, tạo danh sách trắng cho các câu lệnh hợp lệ và bộ quy tắc cảnh báo cho các trường hợp đặc biệt.
• Rà soát thủ công: kiểm tra lại danh sách để đảm bảo không vô tình hợp thức hoá một hành vi độc hại nào đã lẫn vào trong lúc học.
• Chuyển dần sang chặn (Blocking Mode): bật chế độ chặn với từng nhóm nhỏ trước, theo dõi sát để tránh gây gián đoạn hệ thống thật.
• Duy trì và cập nhật: mỗi khi ứng dụng thay đổi (thêm tính năng mới), chính sách cũng cần được cập nhật theo.

8. Các mối đe dọa phổ biến được ngăn chặn​

• SQL Injection: chèn mã độc vào truy vấn để đánh cắp hoặc thao túng dữ liệu. Là mối đe doạ kinh điển và phổ biến nhất mà DBFW sinh ra để đối phó.
• Credential stuffing: dùng danh sách tài khoản/mật khẩu bị rò rỉ từ nơi khác để dò đăng nhập hàng loạt.
• Trích xuất dữ liệu quá mức (data exfiltration): một truy vấn bất thường cố tải toàn bộ hoặc phần lớn dữ liệu trong bảng, dấu hiệu của đánh cắp dữ liệu hàng loạt.
• Lạm quyền của người dùng nội bộ: một tài khoản hợp lệ (kể cả quản trị viên) truy cập dữ liệu ngoài phạm vi công việc bình thường, khó phát hiện hơn vì kẻ tấn công dùng đúng tài khoản hợp lệ.

9. Giải pháp phần mềm​

• Mã nguồn mở / chi phí thấp: ProxySQL và MariaDB MaxScale phù hợp học tập, thử nghiệm, hoặc hệ thống nhỏ dùng MySQL/MariaDB.
• Giải pháp doanh nghiệp: Imperva SecureSphere, IBM Security Guardium, Oracle Database Firewall đầy đủ tính năng, hỗ trợ nhiều loại database, có sẵn báo cáo tuân thủ, nhưng chi phí và độ phức tạp triển khai cao hơn.

Lấy Oracle Audit Vault and Database Firewall (AVDF) làm ví dụ cụ thể, kiến trúc gồm ba thành phần chính:
Mô hình này thể hiện đúng nguyên tắc ba mặt phẳng đã nêu ở trên: Database Firewall xử lý data/control plane, còn Audit Vault Server đảm nhiệm management plane.

10. Ưu điểm và hạn chế​

10.1. Ưu điểm:​

• Ngăn chặn SQL injection ngay ở lớp gần dữ liệu nhất, kể cả khi kẻ tấn công đi vòng qua ứng dụng.
• Ghi log chi tiết phục vụ điều tra sự cố và đáp ứng yêu cầu tuân thủ (audit).
• Có thể phát hiện cả hành vi lạm quyền từ chính người dùng nội bộ.

10.2. Hạn chế:​

• Không đọc được nội dung nếu kết nối đã mã hoá và DBFW không nắm khoá giải mã.
• Kết nối cục bộ (local/IPC): các kết nối qua Unix socket, shared memory, hoặc cơ chế bequeath ngay trên máy chủ CSDL không đi qua card mạng, mọi giải pháp chỉ dựa trên network-based đều bỏ sót đường này, đúng là đường mà một DBA hoặc kẻ tấn công đã chiếm được máy chủ sẽ đi.
• Logic ẩn trong stored procedure: DBFW chỉ thấy lệnh gọi thủ tục (ví dụ EXEC proc_x(?)), không thấy được các câu SQL được sinh ra bên trong thủ tục đó.
• Chế độ inline có thể trở thành điểm gây trễ hoặc điểm chết duy nhất (single point of failure) nếu không có phương án dự phòng. Khi triển khai inline, cách xử lý sự cố cần được quyết định rõ từ đầu:
  • Fail-open: nếu DBFW gặp sự cố, traffic vẫn được cho đi qua bình thường (ưu tiên tính sẵn sàng của hệ thống, chấp nhận tạm thời mất khả năng bảo vệ).
  • Fail-close: nếu DBFW gặp sự cố, mọi kết nối bị chặn hoàn toàn (ưu tiên an toàn dữ liệu, chấp nhận gián đoạn dịch vụ).
• Danh sách trắng cần thời gian "học" hệ thống trước khi bật chặn thật; học chưa đủ dễ chặn nhầm hoạt động hợp lệ.