5 rủi ro nghiêm trọng nếu phần mềm quản lý phân quyền chưa đúng

Khi xây dựng phần mềm quản lý online, nhiều người thường dành phần lớn sự quan tâm cho các chức năng như quản lý khách hàng, hợp đồng, công việc, dự án, nhân sự, công nợ, thu chi hay hệ thống báo cáo. Tuy nhiên, có một thành phần ít được nhìn thấy nhưng lại ảnh hưởng trực tiếp đến mức độ an toàn và hiệu quả của toàn bộ hệ thống: phân quyền người dùng.

Phân quyền không đơn giản là quy định nhân viên được vào menu nào và không được vào menu nào.

Một hệ thống phân quyền tốt phải trả lời được rất nhiều câu hỏi: Ai được xem dữ liệu? Được xem dữ liệu của ai? Ai được thêm, sửa hoặc xóa? Ai có quyền duyệt? Sau khi duyệt còn được sửa hay không? Trưởng phòng có được xem dữ liệu phòng khác không? Admin hệ thống có được quyền phê duyệt nghiệp vụ không?

Nếu những vấn đề này không được thiết kế chính xác, doanh nghiệp có thể đối mặt với những rủi ro nghiêm trọng hơn rất nhiều so với việc phần mềm thiếu một vài chức năng.

Dưới đây là 5 rủi ro lớn khi phần mềm quản lý phân quyền chưa đúng mà doanh nghiệp cần đặc biệt lưu ý.

1. Rò rỉ dữ liệu nội bộ và thông tin quan trọng của doanh nghiệp

Đây có lẽ là rủi ro dễ nhận thấy nhất.

Một phần mềm quản lý doanh nghiệp có thể lưu trữ lượng dữ liệu rất lớn: danh sách khách hàng, thông tin liên hệ, hợp đồng, giá bán, công nợ, chi phí, báo cáo doanh thu, lợi nhuận, lương thưởng, tài liệu dự án, hồ sơ nhân viên...

Không phải nhân viên nào cũng cần được tiếp cận toàn bộ những dữ liệu này.

Ví dụ, nhân viên kinh doanh có thể cần xem khách hàng mình đang phụ trách nhưng không cần xem toàn bộ danh sách khách hàng của tất cả phòng kinh doanh.

Nhân viên kỹ thuật cần xem thông tin dự án để thực hiện công việc nhưng không nhất thiết phải xem lợi nhuận của từng hợp đồng.

Kế toán có thể cần xem doanh thu, công nợ và thanh toán nhưng không nhất thiết được chỉnh sửa nội dung nghiệp vụ của dự án.

Nếu phần mềm chỉ có cách phân quyền đơn giản là "được vào module" hoặc "không được vào module", người dùng có thể nhìn thấy nhiều dữ liệu hơn mức cần thiết.

Rủi ro càng lớn khi phần mềm có chức năng xuất Excel.

Một nhân viên chỉ cần vài thao tác có thể tải xuống hàng nghìn khách hàng hoặc toàn bộ dữ liệu kinh doanh.

Vì vậy, phân quyền cần được thực hiện không chỉ ở cấp chức năng mà còn phải xuống cấp dữ liệu.

Ví dụ:

Nhân viên → dữ liệu cá nhân

Trưởng nhóm → dữ liệu của nhóm

Trưởng phòng → dữ liệu của phòng

Ban giám đốc → dữ liệu toàn doanh nghiệp

Đây chính là nguyên tắc rất quan trọng: đúng người – đúng dữ liệu.

2. Người không có thẩm quyền vẫn có thể sửa, xóa hoặc phê duyệt

Rủi ro thứ hai thậm chí có thể nghiêm trọng hơn việc nhìn thấy dữ liệu.

Đó là người dùng thực hiện được những thao tác mà họ không có thẩm quyền thực hiện.

Ví dụ, nhân viên được xem hợp đồng là hợp lý. Nhưng nếu nhân viên đó đồng thời có thể thay đổi giá trị hợp đồng thì vấn đề hoàn toàn khác.

Tương tự:

Nhân viên có thể tạo đề nghị thanh toán nhưng không được tự duyệt đề nghị của mình.

Kế toán có thể kiểm tra chứng từ nhưng quyết định phê duyệt khoản chi có thể thuộc về giám đốc.

Người thực hiện dự án có thể cập nhật tiến độ nhưng không nhất thiết có quyền xác nhận toàn bộ dự án đã hoàn thành.

Do đó, một chức năng trong phần mềm có thể cần được chia thành nhiều quyền nhỏ:

Xem – Thêm – Sửa – Xóa – Duyệt – In – Xuất dữ liệu – Tải file.

Đặc biệt, quyền phê duyệt phải gắn với thẩm quyền nghiệp vụ chứ không đơn thuần là cấp độ tài khoản trong phần mềm.

Một trường hợp rất đáng lưu ý là tài khoản Admin.

Nhiều hệ thống mặc định:

Admin = có toàn bộ quyền.

Điều này đúng với một số quyền quản trị kỹ thuật nhưng chưa chắc đúng đối với nghiệp vụ.

Admin có thể được quyền tạo tài khoản, cấu hình hệ thống, phân quyền và xử lý các vấn đề kỹ thuật. Nhưng điều đó không có nghĩa Admin được phép phê duyệt hợp đồng, duyệt chi phí hoặc thay giám đốc xác nhận một hồ sơ nghiệp vụ.

Quản trị hệ thống và thẩm quyền nghiệp vụ là hai khái niệm khác nhau.

Nếu phần mềm không phân biệt được điều này, quy trình quản trị của doanh nghiệp có thể bị phá vỡ.

3. Dữ liệu bị thay đổi nhưng không xác định được trách nhiệm

Một vấn đề thường chỉ được phát hiện sau khi doanh nghiệp đã sử dụng phần mềm một thời gian là:

"Dữ liệu này ai sửa?"

Ví dụ, một hợp đồng ban đầu có giá trị 350 triệu đồng nhưng vài ngày sau trên hệ thống lại còn 300 triệu đồng.

Một công nợ đang ở trạng thái chưa thanh toán bỗng chuyển thành đã thanh toán.

Ngày hoàn thành của dự án bị thay đổi.

Một tài liệu quan trọng bị xóa.

Nếu nhiều người cùng có quyền sửa và hệ thống không có cơ chế ghi nhận lịch sử thì rất khó xác định điều gì đã xảy ra.

Đây là lý do phân quyền cần đi cùng nhật ký hoạt động – Activity Log.

Một hệ thống quản lý tốt có thể ghi nhận:

Ai → làm gì → lúc nào → trên dữ liệu nào.

Ví dụ:

09:25 – Nguyễn Văn A thay đổi giá trị hợp đồng HD025 từ 350.000.000 thành 300.000.000 đồng.

Đối với dữ liệu quan trọng, phần mềm có thể lưu cả giá trị trước và sau khi thay đổi.

Khi đó, nếu phát sinh sai lệch, người quản lý có thể kiểm tra lịch sử thay vì phải hỏi từng người.

Activity Log còn có một tác dụng rất quan trọng khác: tạo ra trách nhiệm của người sử dụng.

Khi nhân viên biết rằng các thao tác quan trọng đều được hệ thống ghi nhận, việc cập nhật dữ liệu cũng sẽ được thực hiện cẩn thận hơn.

4. Quy trình nội bộ bị phá vỡ dù phần mềm vẫn hoạt động bình thường

Đây là một rủi ro khá đặc biệt bởi phần mềm có thể không hề báo lỗi.

Không HTTP 500.

Không lỗi database.

Không có thông báo bất thường.

Mọi chức năng đều chạy.

Nhưng quy trình quản lý lại đang sai.

Giả sử doanh nghiệp quy định một khoản chi phải trải qua quy trình:

Nhân viên đề xuất → Trưởng phòng xác nhận → Kế toán kiểm tra → Giám đốc duyệt.

Nếu phần mềm cho phép kế toán bỏ qua trưởng phòng và duyệt trực tiếp, về mặt kỹ thuật phần mềm vẫn hoạt động.

Nhưng quy trình quản trị đã bị phá vỡ.

Hoặc một hồ sơ dự án cần trưởng bộ phận chuyên môn duyệt. Nếu Admin cũng có nút "Duyệt" chỉ vì Admin có full quyền thì hệ thống đang tạo ra một con đường vượt qua quy trình.

Điều nguy hiểm là những lỗi kiểu này thường không dễ phát hiện trong giai đoạn kiểm thử.

Người phát triển phần mềm có thể kiểm tra rằng nút hoạt động, dữ liệu được lưu và trạng thái thay đổi thành công.

Nhưng câu hỏi quan trọng hơn phải là:

Người đang bấm nút này có thực sự là người được phép bấm hay không?

Do đó, khi xây dựng phần mềm quản lý theo nhu cầu, việc tìm hiểu quy trình thực tế của doanh nghiệp đặc biệt quan trọng.

Không thể thiết kế phân quyền chỉ dựa vào tên chức vụ.

Cần hiểu ai tạo, ai kiểm tra, ai duyệt, trường hợp nào được sửa, khi nào khóa dữ liệu và trường hợp nào cần chuyển lên cấp cao hơn.

5. Phần mềm càng mở rộng càng khó kiểm soát và có thể phải sửa lại toàn bộ

Khi doanh nghiệp mới có khoảng 5–10 người sử dụng, một hệ thống phân quyền đơn giản có thể vẫn hoạt động tương đối ổn.

Ví dụ chỉ có:

Admin – Manager – User.

Nhưng khi doanh nghiệp phát triển lên 50, 100 hoặc 500 người dùng, mô hình này rất dễ bộc lộ hạn chế.

Doanh nghiệp bắt đầu có nhiều phòng ban, nhóm, chi nhánh, dự án và cấp quản lý.

Một người có thể là nhân viên của phòng A nhưng lại là người quản lý Dự án B.

Một trưởng phòng được xem toàn bộ dữ liệu phòng mình nhưng không được xem dữ liệu phòng khác.

Một phó giám đốc có thể được giao phụ trách một số nhóm nghiệp vụ nhất định.

Nếu ngay từ đầu phần mềm viết quyền theo kiểu:

Nếu User = Admin thì cho phép.

Hoặc:

Nếu User = Manager thì cho phép.

Sau này mỗi trường hợp đặc biệt sẽ phải thêm một điều kiện mới.

Kết quả là hệ thống quyền ngày càng phức tạp, khó kiểm soát và rất dễ phát sinh lỗi.

Một kiến trúc tốt hơn nên tách rõ:

User – Role – Permission – Scope.

Trong đó:

User là người sử dụng.

Role là vai trò như nhân viên, trưởng phòng, kế toán, giám đốc...

Permission là quyền cụ thể: xem, thêm, sửa, xóa, duyệt...

Scope là phạm vi dữ liệu: cá nhân, nhóm, phòng ban, dự án hoặc toàn công ty.

Nhờ đó, khi doanh nghiệp mở rộng, hệ thống có thể bổ sung vai trò hoặc thay đổi quyền mà không phải sửa lại toàn bộ phần mềm.

Phân quyền nên được thiết kế ngay từ đầu, không phải làm xong phần mềm rồi mới bổ sung

Một sai lầm khá phổ biến khi xây dựng phần mềm quản lý là ưu tiên hoàn thiện tất cả chức năng trước rồi mới nghĩ:

"Sau này làm phân quyền."

Đây thường là cách làm khiến việc chỉnh sửa trở nên phức tạp.

Bởi phân quyền liên quan gần như toàn bộ hệ thống: giao diện, menu, API, database, truy vấn dữ liệu, chức năng thêm sửa xóa, quy trình duyệt, file đính kèm, báo cáo và xuất dữ liệu.

Nếu bổ sung quá muộn, rất nhiều chức năng đã xây dựng có thể phải chỉnh sửa lại.

Do đó, ngay từ giai đoạn thiết kế phần mềm cần xác định:

Ai sử dụng → sử dụng chức năng gì → thao tác gì → trên phạm vi dữ liệu nào → ai phê duyệt → hoạt động nào cần ghi log.

Khi những nguyên tắc này được xác định rõ, việc phát triển các module phía sau sẽ nhất quán và an toàn hơn.

Phân quyền sai có thể nguy hiểm hơn thiếu chức năng

Một phần mềm thiếu chức năng, người dùng thường nhận ra ngay và có thể yêu cầu bổ sung.

Nhưng phân quyền sai đôi khi tồn tại trong thời gian dài mà doanh nghiệp không nhận ra.

Nhân viên đang nhìn thấy dữ liệu không nên nhìn thấy.

Một tài khoản đang có quyền xuất toàn bộ khách hàng.

Một người có thể sửa dữ liệu sau khi đã được duyệt.

Admin có thể vô tình thực hiện quyền thuộc về giám đốc.

Những điều này không nhất thiết làm phần mềm báo lỗi nhưng lại tạo ra những lỗ hổng nghiêm trọng trong quản trị.

Vì vậy, đối với một phần mềm quản lý online chuyên nghiệp, phân quyền cần được xem là một phần của kiến trúc cốt lõi chứ không phải chức năng phụ.

Một hệ thống tốt cần hướng tới nguyên tắc:

Đúng người – Đúng chức năng – Đúng dữ liệu – Đúng thẩm quyền – Đúng trách nhiệm.

Khi làm được điều đó, phần mềm không chỉ giúp doanh nghiệp quản lý dữ liệu mà còn góp phần chuẩn hóa quy trình, bảo vệ thông tin, xác định trách nhiệm và xây dựng một hệ thống vận hành có khả năng mở rộng lâu dài.