Bảo mật API cấp doanh nghiệp cho hệ thống Perfex CRM của bạn

API thiếu bảo mật là rủi ro rò rỉ dữ liệu tiềm ẩn

Mở cổng kết nối API cho hệ thống CRM đồng nghĩa với việc bạn đang đưa dữ liệu doanh nghiệp lên internet. Thông tin khách hàng, số liệu tài chính, nhật ký nội bộ — tất cả đều có thể bị truy cập thông qua các yêu cầu gọi HTTP.

Hầu hết các mô-đun API cho CRM hiện nay đều xử lý bảo mật rất sơ sài: chỉ sử dụng một khóa API duy nhất, hoặc cùng lắm là tích hợp bộ giới hạn tần suất gọi cơ bản. Cơ chế này hoàn toàn không đủ an toàn để đưa vào vận hành thực tế khi mà các thông tin cá nhân của khách hàng luôn là mục tiêu hàng đầu của hacker.

Data Builder tiếp cận bài toán theo một hướng hoàn toàn khác. Đối với chúng tôi, bảo mật không phải là một tính năng được bổ sung sau này, mà chính là nền móng cốt lõi để xây dựng nên toàn bộ hệ thống API.

Quy trình Middleware Bảo mật 6 Giai đoạn

Mỗi yêu cầu gọi đến API đều phải đi qua **6 lớp bảo vệ nghiêm ngặt** trước khi chạm được tới dữ liệu của bạn. Mỗi lớp bảo vệ đều có quyền từ chối yêu cầu ngay lập tức:

Giai đoạn 1: Chốt chặn tấn công DDoS (DDoS Shield)

Lớp phòng thủ đầu tiên, hoạt động trước cả bước xác thực tài khoản:

• Giới hạn dung lượng yêu cầu (Body size limit): Từ chối ngay các yêu cầu có dung lượng vượt quá 256KB (trả về lỗi 413).
• Giới hạn IP toàn cục: Giới hạn tần suất gọi theo từng địa chỉ IP để chống các đợt tấn công dò quét brute-force.
• Phát hiện payload độc hại: Ngăn chặn các chuỗi JSON lồng nhau sâu hơn 10 cấp độ hoặc các tham số truy vấn có độ dài bất thường (trả về lỗi 400).
• Giới hạn thời gian thực thi: Tự động ngắt kết nối đối với các yêu cầu xử lý kéo dài quá 10 giây.

Giai đoạn 2: Lớp kiểm soát CORS (CORS Guard)

Quản lý truy cập chéo nguồn qua hai bước kiểm duyệt:

• Kiểm tra sơ bộ (Preflight OPTIONS): Thực thi cấu hình ở mức máy chủ — phản hồi nhanh mà không yêu cầu xác thực token (trình duyệt không gửi credentials ở bước preflight).
• Danh sách tên miền cho phép (CORS Whitelist): Giới hạn cụ thể tên miền được phép gọi API cho từng token riêng biệt.

Giai đoạn 3: Cổng xác thực mã hóa (Auth Gate)

Xác thực Token ứng dụng các tiêu chuẩn mật mã học tốt nhất:

• Mã hóa lưu trữ SHA-256: Plaintext token **không bao giờ** được lưu trực tiếp trong database, ngăn ngừa rò rỉ ngay cả khi bị hack database.
• Chống tấn công timing-attack: Sử dụng hàm so khớp an toàn hash_equals() thay vì toán tử so sánh thông thường ===.
• Ký chữ ký HMAC-SHA256 (Tùy chọn): Xác thực tính toàn vẹn của yêu cầu thông qua chữ ký số bao quát các thông số phương thức, đường dẫn, truy vấn, nội dung gửi lên và mốc thời gian.
• Chống tấn công phát lại (Anti-replay): Sử dụng tiêu đề X-Timestamp giới hạn hiệu lực yêu cầu trong vòng 300 giây.

Giai đoạn 4: Bộ giới hạn tần suất gọi (Rate Limiter)

Giới hạn số lượt gọi API chi tiết trên từng token:

• Sử dụng bộ đếm thời gian cố định (fixed-window counter) với thao tác ghi UPSERT nguyên tử (chống ghi đè đồng thời).
• Cơ chế khóa an toàn (Fail-closed): Nếu cơ sở dữ liệu quản lý rate limit gặp sự cố, hệ thống sẽ tự động từ chối mọi yêu cầu gọi đến (lỗi 503) thay vì mở cửa cho qua.
• Trả về đầy đủ các tiêu đề HTTP chuẩn: X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After.

Giai đoạn 5: Xác thực phạm vi quyền hạn (Scope Verifier)

Phân quyền chi tiết ở mức độ sâu:

• Phân quyền theo bảng dữ liệu: Ma trận quyền Đọc/Tạo/Sửa/Xóa (CRUD) chi tiết trên từng bảng cơ sở dữ liệu.
• Giới hạn theo khung nhìn: Token có thể được cấu hình chỉ cho phép đọc dữ liệu từ một bộ lọc màn hình (saved view) cụ thể.
• Giới hạn dải IP (CIDR matching): Khóa cứng token chỉ cho phép sử dụng trong một dải địa chỉ IP nội bộ hoặc chỉ định.

Giai đoạn 6: Nhật ký hoạt động (Request Logger)

Ghi nhận đầy đủ lịch sử hoạt động phục vụ kiểm toán dữ liệu:

• Quy trình ghi log 2 giai đoạn: Ghi nhận thời điểm yêu cầu gửi đến và cập nhật kết quả (mã phản hồi, thời gian xử lý) sau khi controller hoàn thành.
• Ẩn thông tin nhạy cảm: Các trường thông tin chứa token, tiêu đề Authorization hay chữ ký signature đều được tự động bóc tách và xóa sạch khỏi log lưu trữ thông qua lớp Log_redactor.

Các tiêu đề bảo mật chuẩn OWASP

Mọi kết quả API trả về — bao gồm cả phản hồi thành công, báo lỗi hay bị từ chối từ lớp middleware — đều được đính kèm các tiêu đề bảo mật tiêu chuẩn:

Các tiêu đề này được áp dụng tự động thông qua một hàm xử lý tập trung duy nhất _set_standard_headers(), đảm bảo tính đồng bộ tuyệt đối.

Cơ chế bảo vệ 6 lớp dành cho các bảng nhạy cảm

Các bảng dữ liệu hệ thống tối quan trọng (như tblstaff, tblcontacts, tbloptions, tbldata_builder_api_tokens) được bảo vệ bằng **6 rào chắn độc lập**:

1. Đăng ký tập trung: Hàm ResourceNameResolver::isSensitiveTable() quản lý danh mục duy nhất các bảng nhạy cảm.
2. Kiểm duyệt tạo Token: Hệ thống tự động gán thuộc tính ghi về false đối với mọi người dùng không phải là Super-Admin khi tạo token.
3. Bypass phiên làm việc Admin: Các tài khoản admin thông thường (không phải ID 1) chỉ nhận được token giả lập chỉ đọc khi chạy thử trên API Explorer.
4. Middleware kiểm duyệt Runtime: Trả về lỗi 403 ngay lập tức nếu phát hiện thao tác ghi trái phép gửi đến bảng nhạy cảm.
5. Kiểm tra chéo tại Controller: Hàm _enforce_write_scope() xác thực lại một lần nữa ngay trước khi chạy câu lệnh SQL.
6. Cấu trúc Schema GraphQL: Các trường mutation chỉnh sửa dữ liệu của bảng nhạy cảm sẽ bị **ẩn hoàn toàn** khỏi schema (nhà phát triển không thể tìm thấy trường này) nếu token không được cấp quyền.

Ngav cả khi một lớp bảo vệ gặp lỗi do sơ suất cấu hình, 5 lớp bảo vệ còn lại vẫn hoạt động để bảo vệ an toàn dữ liệu của bạn.

Bảo mật tối đa, không thỏa hiệp

Kiến trúc bảo mật của Data Builder không phải là các tính năng thiết lập cho có. Đó là một **hệ thống bảo mật cấp doanh nghiệp thực thụ** được thiết kế dành cho các tổ chức coi trọng việc an toàn dữ liệu.

6 giai đoạn middleware. Tiêu đề chuẩn OWASP. Chữ ký HMAC số. Bảo vệ thông tin cá nhân. Phòng thủ chiều sâu.

Hệ thống API của bạn chỉ an toàn bằng mắt xích yếu nhất của nó. Với Data Builder, chúng tôi không có mắt xích yếu nào.