Phân quyền, audit trail và kiểm soát truy cập dữ liệu trong nhà máy số hóa

I. Bốn chiều của quyền truy cập

1. Chủ thể - ai?

Công nhân/người vận hành.
Kỹ thuật viên.
Trưởng ca/quản đốc.
Trưởng bảo trì/sản xuất/chất lượng.
Kế hoạch/kho/mua hàng.
IT/system admin.
Nhà thầu hoặc vendor support.
Ban giám đốc/auditor.

Tài khoản nên gắn với cá nhân. Tài khoản dùng chung làm mất khả năng truy vết.

2. Hành động - được làm gì?

Xem.
Tạo.
Sửa.
Xác nhận/duyệt.
Đóng/hủy.
Xuất dữ liệu.
Xóa hoặc archive.
Quản lý master data.
Quản lý người dùng/quyền.
Chạy báo cáo hoặc truy vấn AI.

Quyền xem không đồng nghĩa quyền xuất; quyền sửa không đồng nghĩa quyền duyệt.

3. Đối tượng dữ liệu - trên dữ liệu nào?

Work order, PM, sự cố.
Kế hoạch/lệnh sản xuất.
Sản lượng, downtime, OEE.
Lỗi, CAPA và hồ sơ chất lượng.
Tài liệu kỹ thuật/SOP.
Phụ tùng, chi phí và dữ liệu tài chính.
Prompt, response và knowledge base AI.

4. Phạm vi - ở đâu?

Nhà máy.
Khu vực/dây chuyền.
Bộ phận.
Nhóm thiết bị.
Sản phẩm/khách hàng.
Ca/kíp.
Dự án hoặc thời gian hiệu lực.

Mô hình quyền cần kết hợp cả bốn chiều thay vì gán role quá rộng.

II. RBAC, ABAC và least privilege

RBAC - role-based access control

Quyền được gán theo role chuẩn: operator, technician, supervisor, manager, admin. RBAC dễ quản lý và phù hợp phần lớn tình huống.

ABAC - attribute-based access control

Quyền phụ thuộc thuộc tính như nhà máy, dây chuyền, ca, loại thiết bị hoặc độ nhạy cảm. ABAC hữu ích khi cùng role nhưng phạm vi khác nhau.

Least privilege

Mỗi người chỉ có quyền tối thiểu để làm công việc. Quyền cao được cấp có thời hạn và ghi log khi cần.

Một mô hình thực tế thường dùng RBAC cho chức năng và attribute/scope cho dữ liệu.

III. Segregation of duties - tách quyền xung đột

Một số hành động không nên do cùng một người thực hiện từ đầu đến cuối:

Tạo và phê duyệt thay đổi master data critical.
Tạo yêu cầu mua và phê duyệt chi phí.
Chỉnh sửa dữ liệu chất lượng và tự xác nhận audit.
Cấp quyền admin và tự review quyền của chính mình.
Thay đổi SOP và phê duyệt hiệu lực.
Chỉnh cấu hình AI/knowledge base và tự chấp nhận kết quả kiểm thử.

Mức tách quyền phải theo rủi ro; không nên làm workflow quá nặng cho mọi trường hợp.

IV. Ma trận quyền gợi ý cho CMMS

Vai trò	Tạo yêu cầu	Nhận/cập nhật WO	Đóng WO	Sửa master asset	Xem chi phí	Quản lý user
Operator	Có	Không	Xác nhận	Không	Không	Không
Technician	Có	Theo giao việc	Đề nghị đóng	Không	Hạn chế	Không
Supervisor	Có	Có	Có	Đề nghị	Có	Không
Maintenance manager	Có	Có	Có	Phê duyệt	Có	Không
Data steward	Không	Không	Không	Có theo workflow	Hạn chế	Không
System admin	Không mặc định	Không mặc định	Không	Kỹ thuật	Không mặc định	Có

Bảng phải điều chỉnh theo quy trình. System admin không nên tự động có quyền nghiệp vụ chỉ vì quản trị kỹ thuật.

V. Ma trận quyền gợi ý cho MES/dashboard

Operator: nhập/xác nhận sản lượng và lý do dừng cho máy/ca được giao.
Trưởng ca: điều chỉnh trong cửa sổ thời gian và phạm vi dây chuyền; duyệt sự kiện quan trọng.
Production manager: xem nhiều dây chuyền, phê duyệt thay đổi lớn, khóa kỳ báo cáo.
Quality: cập nhật disposition và lỗi, không sửa sản lượng tùy ý.
Maintenance: xem downtime thiết bị và liên kết work order, không sửa kế hoạch sản xuất.
Ban giám đốc: view-only tổng hợp.

Quyền sửa sau khi ca đã khóa cần workflow, lý do và audit trail.

VI. Audit trail phải ghi những gì?

Một audit record tối thiểu:

User/service account.
Timestamp và timezone.
Hành động.
Đối tượng/record ID.
Giá trị trước và sau.
Nguồn truy cập: web, mobile, API, batch.
IP/device/session nếu phù hợp.
Lý do thay đổi hoặc ticket/approval.
Hệ thống/phiên bản.
Kết quả thành công/thất bại.

Với AI, có thể cần log model version, nguồn tài liệu, prompt, response, feedback và action downstream.

VII. Audit trail không phải chỉ để “có log”

Log phải:

Không dễ bị người dùng nghiệp vụ sửa/xóa.
Có retention phù hợp yêu cầu vận hành/audit.
Tìm kiếm và xuất được trong thời gian hợp lý.
Liên kết với record nghiệp vụ.
Có kiểm soát ai được xem log.
Có cảnh báo cho hành vi bất thường quan trọng.

Log quá nhiều nhưng không thể truy vấn hoặc không có owner cũng ít giá trị.

VIII. Vòng đời tài khoản: joiner, mover, leaver

Joiner - người mới

Quyền cấp theo role template và phạm vi, có phê duyệt. Không copy nguyên quyền từ người khác mà không kiểm tra.

Mover - đổi bộ phận/ca/vai trò

Quyền cũ phải được thu hồi, không chỉ thêm quyền mới. Đây là nguồn privilege creep phổ biến.

Leaver - nghỉ việc hoặc nhà thầu kết thúc

Tài khoản, token, API key và thiết bị phải bị thu hồi đúng thời điểm. Dữ liệu/lịch sử công việc vẫn được giữ theo policy nhưng không gắn với tài khoản hoạt động.

Cần review định kỳ các tài khoản không sử dụng, tài khoản dịch vụ và quyền admin.

IX. Quyền tạm thời và break-glass

Trong sự cố, có thể cần quyền cao tạm thời. Nên có:

Lý do và approver.
Thời gian hết hạn tự động.
MFA tăng cường.
Logging chi tiết.
Review sau sử dụng.

Tài khoản break-glass phải được bảo vệ và kiểm thử, không dùng như admin hằng ngày.

X. Access review định kỳ

Tần suất có thể theo rủi ro: hàng quý cho quyền cao, 6-12 tháng cho quyền thông thường. Review nên hỏi:

Người này còn đúng bộ phận/vai trò không?
Có quyền dư do chuyển công việc không?
Có tài khoản dormant không?
Service account có quyền quá rộng không?
Nhà thầu còn cần truy cập không?
Quyền export/download có hợp lý không?
Role có xung đột SoD không?

Process owner nên xác nhận quyền nghiệp vụ; IT hỗ trợ trích danh sách và thực thi.

XI. Kiểm soát truy cập cho AI Copilot

Ngoài quyền mở ứng dụng, cần:

Chỉ truy xuất tài liệu/record theo quyền người dùng.
Tách knowledge base theo nhà máy/bộ phận khi cần.
Hạn chế người quản trị xem prompt nhạy cảm.
Ghi log nguồn được dùng trong câu trả lời.
Không cho AI gọi tool hoặc tạo work order ngoài quyền.
Yêu cầu phê duyệt cho hành động rủi ro.
Thu hồi quyền tài liệu phải có hiệu lực với AI index.

Một AI trả lời vượt quyền là lỗi authorization, không chỉ là lỗi chất lượng.

XII. Hỗ trợ audit khách hàng

Khi khách hàng hoặc auditor yêu cầu bằng chứng, hệ thống nên giúp trả lời:

Ai tạo/sửa/duyệt record?
Thay đổi lúc nào và vì sao?
Phiên bản SOP nào có hiệu lực?
Quyền người dùng tại thời điểm đó là gì?
Dữ liệu có bị sửa sau khi khóa kỳ không?
Work order, CAPA hoặc checklist có đủ bằng chứng không?
Log có thể xuất và đối chiếu không?

Cần thử một audit scenario trước go-live thay vì chờ đến kỳ audit thật.

XIII. Cách triển khai theo bảy bước

Inventory vai trò và dữ liệu.
Phân loại rủi ro hành động.
Thiết kế role chuẩn và scope.
Xác định SoD và approval.
Cấu hình audit trail/retention.
Test persona, negative test và quyền sau chuyển vai trò.
Thiết lập access review và incident process.

Negative test rất quan trọng: chứng minh người dùng không thể xem/sửa dữ liệu ngoài quyền.

XIV. Những sai lầm thường gặp

Tài khoản dùng chung theo ca.
Mọi quản lý đều có quyền admin.
System admin có toàn bộ quyền nghiệp vụ không kiểm soát.
Chỉ test người dùng làm được, không test người dùng bị chặn đúng.
Không thu hồi quyền cũ khi chuyển bộ phận.
Log không ghi giá trị trước-sau.
Log có nhưng người dùng admin có thể xóa.
Không quản lý quyền API/service account.
AI Copilot không áp dụng quyền tài liệu.

XV. Checklist nghiệm thu

Role và scope đã được process owner phê duyệt chưa?
Mỗi role có mô tả quyền tạo/xem/sửa/duyệt/xuất chưa?
Tài khoản dùng chung đã được loại bỏ hoặc kiểm soát chưa?
SoD cho dữ liệu critical đã được xác định chưa?
Audit trail có user, thời gian, trước-sau và nguồn không?
Retention và quyền xem log đã rõ chưa?
Joiner-mover-leaver có SLA không?
Quyền tạm thời có expiry không?
Negative test đã pass chưa?
Access review đã có owner và lịch chưa?

XVI. Câu hỏi thường gặp

Audit trail khác lịch sử chỉnh sửa thông thường thế nào?

Audit trail có tính truy vết và kiểm soát cao hơn: ghi ai, khi nào, hành động, giá trị trước-sau và không dễ bị sửa/xóa. Lịch sử đơn giản có thể chỉ hiển thị phiên bản.

Có nên cho trưởng bộ phận quyền admin không?

Không mặc định. Họ cần quyền nghiệp vụ rộng trong phạm vi, nhưng quyền hệ thống/admin nên tách nếu có thể để giảm rủi ro và xung đột.

Có cần log mọi lần xem dữ liệu không?

Tùy độ nhạy cảm và yêu cầu. Với dữ liệu critical hoặc tài liệu hạn chế, access log có thể cần thiết. Với dữ liệu thông thường, có thể ưu tiên log thay đổi và export.