Quản trị phân quyền CRUD theo từng bảng dữ liệu trong Perfex CRM

Last updated on Jul 10, 2026 4:37 AM

Mối nguy hiểm từ quyền ghi dữ liệu toàn cục (Global Write Access)

Khi kết nối các ứng dụng bên ngoài — như Zapier, ứng dụng di động hoặc cổng thông tin tùy biến — với CRM của bạn, rủi ro bảo mật phổ biến nhất là việc cấp quyền quá mức. Nhiều hệ thống REST API chỉ cung cấp lựa chọn nhị phân đơn giản cho API tokens: Chỉ đọc (Read-Only) hoặc Đọc/Ghi (Read/Write).

Nếu bạn chỉ cần một công cụ tự động hóa để tạo mới Lead, bạn bắt buộc phải cấp cho nó quyền ghi toàn cục. Nhưng điều gì sẽ xảy ra nếu công cụ đó bị rò rỉ thông tin hoặc cấu hình sai? Ngay lập tức, nó có quyền chỉnh sửa Hóa đơn, xóa Khách hàng hoặc thay đổi thông tin Nhân viên.

Điều này vi phạm nghiêm trọng Nguyên tắc Đặc quyền Tối thiểu (Principle of Least Privilege).

Cơ chế phân quyền chi tiết theo từng bảng trong Data Builder

Để giải quyết triệt để vấn đề này, Data Builder cho Perfex CRM thay thế nút bật quyền ghi toàn cục đầy rủi ro bằng một Ma trận Phân quyền CRUD chi tiết theo từng bảng dữ liệu.

Mỗi API Token khởi tạo trong Data Builder giờ đây sở hữu một tập hợp quyền riêng được ánh xạ trực tiếp đến từng bảng database cụ thể. Bạn có thể kiểm soát chính xác token được thực hiện các lệnh:

READ (Lấy dữ liệu - GET)
CREATE (Tạo mới - POST)
UPDATE (Cập nhật - PUT)
DELETE (Xóa - DELETE)

Các kịch bản ứng dụng mẫu:

1. Webhook tạo Lead tự động (Make.com)

Cấu hình Token: Chỉ cấp quyền CREATE trên bảng tblleads.
Kết quả: Tích hợp có thể thêm mới lead từ landing page của bạn nhưng hoàn toàn không thể đọc, cập nhật hoặc xóa các lead hiện có, cũng như không thể can thiệp đến thông tin hóa đơn hay thanh toán.

2. Ứng dụng Cổng thông tin Khách hàng (Client Portal)

Cấu hình Token: Cấp quyền READ trên các bảng tblclients, tblinvoices, và tblprojects. Cấp quyền UPDATE trên bảng tblclients (để khách hàng tự cập nhật thông tin cá nhân).
Kết quả: Cổng thông tin truy xuất dữ liệu cần thiết và cập nhật thông tin khách hàng an toàn, nhưng hoàn toàn không thể xóa hóa đơn hay tự ý tạo dự án mới.

3. Đồng bộ phần mềm kế toán bên thứ ba

Cấu hình Token: Cấp quyền READ trên bảng tblinvoices và tblpayments. Cấp quyền CREATE trên bảng tblexpenses.
Kết quả: Phần mềm kế toán kéo thông tin hóa đơn về và đẩy các khoản chi phí phát sinh mới sang mà không ảnh hưởng tới dữ liệu nhân sự hay các yêu cầu hỗ trợ (tickets).

Cơ chế Bảo vệ 6 Lớp dành cho các bảng nhạy cảm (Sensitive Table Protection)

Điều gì xảy ra nếu quản trị viên vô tình cấp quyền DELETE trên bảng nhân sự tblstaff cho một API token?

Data Builder hiểu rằng sai sót của con người là khó tránh khỏi. Do đó, hệ thống tích hợp sẵn **Cơ chế Bảo vệ 6 Lớp** dành riêng cho các bảng hệ thống tối quan trọng (tblstaff, tblcontacts, tbloptions, tbldata_builder_api_tokens).

Ngay cả khi một token được tích chọn quyền ghi trên giao diện, cổng API vẫn thực thi các rào chắn bảo vệ:

ResourceNameResolver — Lớp đăng ký tập trung danh mục các bảng nhạy cảm.
Bộ điều khiển Api_tokens — Kiểm duyệt phía máy chủ bắt buộc gán thuộc tính ghi (CUD) về false trên các bảng nhạy cảm đối với bất kỳ người dùng nào ngoại trừ Super Admin (tài khoản ID = 1).
AdminSessionBypassMiddleware — Giới hạn các thao tác ghi đối với các phiên làm việc của quản trị viên khác ID 1.
ScopeVerifierMiddleware — Từ chối mọi yêu cầu POST/PUT/DELETE gửi đến các bảng được bảo vệ bằng mã lỗi 403 Forbidden.
Kiểm tra chéo tại Resource Controller — Xác thực lớp cuối cùng trước khi thực thi câu lệnh SQL.
Loại bỏ khỏi Schema GraphQL — Các trường Mutation của các bảng nhạy cảm bị loại bỏ hoàn toàn khỏi cấu trúc schema GraphQL.

Bảo mật theo thiết kế mặc định

Khi xây dựng quy trình làm việc dựa trên API, sự tin cậy cần được định nghĩa rõ ràng và giới hạn phạm vi. Bằng cách khai thác tính năng phân quyền theo bảng của Data Builder, bạn có thể tự tin kết nối Perfex CRM với các công cụ bên ngoài mà vẫn đảm bảo dữ liệu nhạy cảm được cô lập và bảo vệ tối đa.