Bảo mật ERP: RBAC, SoD, audit log và privileged access

Bảo mật ERP không chỉ là đặt mật khẩu mạnh cho tài khoản quản trị. ERP chứa dữ liệu tài chính, khách hàng, nhà cung cấp, tồn kho, nhân sự và các giao dịch có thể tạo tác động trực tiếp tới tiền, hàng và quyền phê duyệt. Vì vậy mô hình bảo mật phải bao phủ identity, role, segregation of duties, privileged access, audit log, integration credential, change control và recovery.

Một control tốt phải gắn với business process. Ví dụ, người tạo vendor không nên mặc định có quyền sửa thông tin thanh toán và thực hiện payment nếu doanh nghiệp yêu cầu tách nhiệm vụ. Nếu đang thiết kế toàn bộ kiến trúc ERP, xem các module ERP và quy trình triển khai ERP để đặt security vào đúng workstream.

1. Bắt đầu từ identity và least privilege

Mỗi user chỉ nên có quyền cần thiết để thực hiện công việc được giao. Role nên phản ánh chức năng thực tế thay vì cấp quyền theo yêu cầu ad-hoc từng người. Với quyền nhạy cảm, cần quy trình phê duyệt, thời hạn nếu là temporary access và owner chịu trách nhiệm review.

• Named account thay vì tài khoản dùng chung.
• Role-based access theo job function.
• Least privilege cho transaction, report và data domain.
• Joiner–Mover–Leaver process khi nhân sự vào, đổi vai trò hoặc nghỉ việc.
• Access review định kỳ theo business owner.
• Temporary/emergency access có thời hạn và audit.

2. Segregation of Duties: tách quyền để giảm xung đột

Segregation of Duties (SoD) nhằm tránh một người có thể tự thực hiện trọn chuỗi giao dịch nhạy cảm mà không có kiểm soát độc lập. Ma trận SoD cần được xây theo risk của doanh nghiệp, không copy một danh sách conflict cố định cho mọi ERP.

Sơ đồ SoD: quyền đi qua gate nào trước khi được cấp?

Ví dụ: một user đã có quyền tạo vendor mà xin thêm quyền sửa bank và payment thì phải đi qua SoD review. Nếu business buộc phải cho phép, compensating control phải có owner, evidence và thời hạn review — không chỉ “ghi chú ngoại lệ”.

Ví dụ conflict	Rủi ro	Control có thể dùng
Tạo vendor + sửa bank + payment	Thanh toán sai/gian lận	Tách role + approval + audit
Tạo PO + nhận hàng + duyệt invoice	Không có kiểm soát độc lập	Role split + threshold approval
Tạo journal + approve/post	Điều chỉnh tài chính không được review	Workflow + reviewer độc lập
Tạo user + tự cấp privileged role	Privilege escalation	Admin governance + approval

3. MFA và privileged access

Tài khoản admin, finance approver, integration administrator và các role có quyền thay đổi cấu hình nên được bảo vệ mạnh hơn user thông thường. MFA, session policy, conditional access hoặc privileged access workflow có thể được áp dụng tùy nền tảng và kiến trúc.

Không nên duy trì tài khoản admin cá nhân dùng cho công việc hằng ngày. Tách tài khoản privileged khỏi tài khoản thông thường giúp giảm phạm vi rủi ro và tạo audit trail rõ hơn.

4. Security cho integration và service account

ERP thường kết nối CRM, WMS, MES, ngân hàng, eCommerce và BI. Service account/API credential cần được quản trị như privileged identity: quyền tối thiểu, secret rotation, tách môi trường, logging và owner rõ.

• Không hard-code secret trong source code hoặc tài liệu dùng chung.
• Không dùng tài khoản cá nhân cho integration production.
• Scope token/API theo đúng operation cần thiết.
• Rotate/revoke credential khi partner hoặc nhân sự thay đổi.
• Theo dõi error/retry bất thường và failed authentication.

Xem tích hợp ERP để nối security với system of record, retry, monitoring và reconciliation.

5. Audit log phải phục vụ investigation

Audit log có giá trị khi có thể trả lời ai làm gì, khi nào, từ đâu và record thay đổi thế nào. Không nên bật log mọi thứ nhưng không có retention, alert hoặc người review.

• Login và failed login đáng chú ý.
• Thay đổi role/permission.
• Thay đổi master data nhạy cảm.
• Override approval hoặc workflow.
• Configuration và integration credential change.
• Privileged activity và emergency access.

6. Master data cũng là security control

Vendor bank account, customer credit term, item valuation field hoặc finance structure có thể tạo rủi ro lớn nếu ai cũng sửa được. Governance cần quy định requester, approver, field validation và audit trail. Xem Master Data ERP để tách ownership và workflow theo data domain.

7. Patch, configuration và change control

Bảo mật ERP không chỉ nằm ở user access. Nền tảng, database, middleware, integration runtime và custom extension đều có lifecycle. Change cần được test trong môi trường phù hợp, có rollback plan và tránh sửa production trực tiếp ngoài quy trình.

Với cloud ERP, nhà cung cấp có thể chịu nhiều trách nhiệm hạ tầng hơn nhưng doanh nghiệp vẫn chịu trách nhiệm cho identity, role, configuration, integration và data usage theo shared-responsibility model thực tế. Xem Cloud ERP vs On-premise.

8. Backup, recovery và security incident

Security plan phải tính cả tình huống dữ liệu bị xóa, mã hóa, cấu hình sai hoặc hệ thống gián đoạn. Backup chỉ có ý nghĩa khi restore đã được test và recovery objective phù hợp với business impact. Phần này được mở rộng tại Backup & Disaster Recovery ERP.

Security testing trước go-live

• Positive test: role được phép làm đúng task.
• Negative test: role không được phép bị chặn đúng.
• SoD conflict review theo role thực tế.
• Privileged/admin account review.
• Service account/API permission review.
• Audit log và alert cho event trọng yếu.
• Offboarding/revoke access scenario.

Security/permission testing nên nằm trong kiểm thử ERP & UAT, nhưng business owner và security/IT cần cùng xác nhận vì quyền hợp lệ về kỹ thuật chưa chắc phù hợp với kiểm soát nghiệp vụ.

Checklist bảo mật ERP

• Role model và owner đã được phê duyệt.
• Least privilege và SoD conflict đã review.
• MFA/privileged access áp dụng theo risk và capability.
• Joiner–Mover–Leaver process đã hoạt động.
• Service account và secret có owner/rotation.
• Audit log cho event trọng yếu có retention và review.
• Master data nhạy cảm có approval.
• Change/patch/custom có test và rollback.
• Backup/restore và incident escalation đã được xác minh.
• Access review tiếp tục sau go-live.

Kết luận

Bảo mật ERP hiệu quả là một operating model liên tục, không phải checklist dùng một lần trước go-live. Identity, SoD, privileged access, integration, master data, audit và recovery phải có owner và evidence. Khi mua giải pháp hoặc chọn partner, đưa các yêu cầu này vào RFP ERP thay vì chỉ hỏi vendor “hệ thống có bảo mật không?”.

Nguồn kiểm chứng cho control bảo mật ERP

• NIST SP 800-53 Rev. 5 — catalog control chính thức bao phủ access control, audit/accountability và các control quản trị rủi ro dùng để thiết kế least privilege, privileged access và logging.
• Microsoft Dynamics 365 security controls — xác nhận security trong online services là shared responsibility và mô tả trách nhiệm của customer trong bảo vệ dữ liệu, identity và cấu hình.

Nguồn được kiểm tra ngày 09/08/2026. Các control framework được dùng làm bằng chứng thiết kế; ma trận SoD cụ thể vẫn phải dựa trên risk và quy trình của doanh nghiệp.

Khi security cần gắn với vận hành Odoo

Bài này tiếp tục sở hữu intent bảo mật ERP vendor-neutral. Khi hệ thống đang vận hành là Odoo và cần quản trị access review, custom/integration risk, release, incident và security hardening theo vòng đời, xem dịch vụ hỗ trợ Odoo.