Bài 10: Vấn đề Bảo mật trong Kafka — Tấm khiên bảo vệ hạ tầng

Hệ thống bảo mật của Kafka được thiết kế chặt chẽ dựa trên 3 lớp bảo vệ (3 chữ A): Encryption, Authentication và Authorization.

1. Encryption (Mã hóa đường truyền) — Chống nghe lén

Bình thường, dữ liệu đi từ Producer đến Broker (và từ Broker đến Consumer) ở dạng văn bản thuần túy (plaintext). Bất kỳ ai can thiệp vào đường truyền mạng nội bộ đều có thể đọc được gói tin.

• Cách giải quyết: Kafka sử dụng SSL/TLS (giống như giao thức https khi bạn lướt web) để mã hóa toàn bộ luồng dữ liệu.
• Kết quả: Dù hacker có chặn bắt được gói tin giữa đường, chúng cũng chỉ thấy một mớ ký tự mã hóa lộn xộn không thể đọc được.

2. Authentication (Xác thực danh tính) — Ai đang gõ cửa?

Mã hóa đường truyền chỉ giúp dữ liệu đi an toàn, nhưng không ngăn được việc một kẻ xấu cố ý kết nối vào hệ thống. Authentication trả lời câu hỏi: "Anh là ai và ai cấp phép cho anh vào đây?".

Kafka hỗ trợ nhiều cơ chế xác thực, phổ biến nhất ở các hệ thống Backend là:

• SASL/PLAIN hoặc SASL/SCRAM: Xác thực bằng Username và Password. Khá giống với cách kết nối vào MySQL hay Redis. (Luôn phải đi kèm SSL/TLS để mật khẩu không bị lộ).
• mTLS (Mutual TLS): Xác thực hai chiều bằng Chứng chỉ số (Certificate). Broker kiểm tra chứng chỉ của ứng dụng gửi đến, và ứng dụng cũng kiểm tra ngược lại chứng chỉ của Broker xem có phải máy chủ "chính chủ" không. Đây là tiêu chuẩn cực kỳ an toàn cho liên lạc giữa các server nội bộ.

3. Authorization (Phân quyền bằng ACLs) — Được phép làm gì?

Xác thực xong không có nghĩa là bạn được làm "vua". Giả sử một hệ thống có 100 Topic khác nhau, bạn không thể cho phép tất cả các dịch vụ đọc/ghi tùy ý.

Đây là lúc ACLs (Access Control Lists - Danh sách kiểm soát truy cập) phát huy tác dụng. Cơ chế ACL của Kafka hoạt động theo công thức:

[Ai] được phép/bị cấm [Làm hành động gì] trên [Tài nguyên nào] từ [IP nào].

Ví dụ thực tế: Trong kiến trúc hệ thống soát vé, bạn có một Topic quan trọng tên là production_afc_transactions (lưu trữ giao dịch quẹt thẻ). Bạn có thể thiết lập cấu hình ACLs như sau:

• Dịch vụ TVM (Máy bán vé): Chỉ có quyền WRITE (Gửi dữ liệu) vào Topic này. Cấm tuyệt đối quyền READ.
• Dịch vụ Đối soát (Clearing/Settlement): Chỉ có quyền READ (Lấy dữ liệu) từ Topic này. Cấm tuyệt đối quyền WRITE để tránh việc dịch vụ này vô tình (hoặc cố ý) đẩy giao dịch ảo vào hệ thống.
• Lập trình viên: Máy tính cá nhân (IP không nằm trong whitelist) sẽ bị DENY (Từ chối) mọi quyền truy cập, ngăn chặn việc ai đó lỡ tay đẩy dữ liệu test vào môi trường thực.

Tóm tắt chiến lược bảo mật cho Backend Developer: Khi triển khai Kafka lên môi trường Production, bạn bắt buộc phải:

1. Bật SSL/TLS để mã hóa đường truyền.
2. Tạo tài khoản riêng biệt (SASL/SCRAM) cho từng cụm dịch vụ Producer và Consumer.
3. Viết các quy tắc ACLs chi tiết, cấp quyền theo nguyên tắc "Đặc quyền tối thiểu" (Least Privilege) — ai cần cái gì thì cấp đúng cái đó, không thừa không thiếu.

Chuỗi bài lý thuyết từ nền tảng kiến trúc đến bảo mật và tối ưu đã hoàn thiện