# Phân quyền người dùng trong phần mềm quản lý doanh nghiệp

> Một tình huống khá thường gặp: nhân viên mới vào kho được cấp tài khoản cũ của người vừa nghỉ, vì người quản trị muốn xong việc cho nhanh. Vài tuần sau, thủ

URL: https://mona.software/phan-quyen-nguoi-dung-phan-mem-quan-ly-doanh-nghiep/
Ngày đăng: 2026-10-14T09:39:27+07:00
Cập nhật: 2026-10-14T09:39:34+07:00
Tác giả: monamedia

Một tình huống khá thường gặp: nhân viên mới vào kho được cấp tài khoản cũ của người vừa nghỉ, vì người quản trị muốn xong việc cho nhanh. Vài tuần sau, thủ kho mở được bảng lương, nhân viên bán hàng sửa được giá trong đơn của chi nhánh khác, và khi số liệu lệch thì không ai biết dữ liệu đổi lúc nào, do ai. Giả định để minh hoạ: một đơn 5 triệu đồng bị sửa xuống 500 nghìn đồng, và 3 tháng sau mới có người thấy. Phần mềm không hỏng. Lỗi nằm ở phân quyền.

Phân quyền tốt trả lời được bốn câu cho từng thao tác: ai đang làm, được làm gì, trên phạm vi dữ liệu nào, và thao tác đó để lại dấu vết gì. Cách phổ biến nhất để trả lời câu đầu là phân quyền theo vai trò: gán quyền cho vai trò, rồi gán vai trò cho người. Bài này đi qua cách làm đó, các loại quyền thường gặp trong một hệ quản trị, và phần nhật ký kiểm toán mà nhiều đội bỏ qua cho tới khi cần tra lại.

Nguồn dùng trong bài gồm [tiêu chuẩn RBAC của NIST](https://csrc.nist.gov/projects/role-based-access-control), [hướng dẫn Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) và [hướng dẫn Logging](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) của OWASP, và tài liệu phân quyền của Frappe Framework, một khung phần mềm có sẵn cơ chế xác thực người dùng và phân quyền theo vai trò. Mọi tên khái niệm và giới hạn được nêu đều lấy từ các trang này, kiểm ngày 14/10/2026. Phần thiết lập theo thứ tự và các ví dụ rủi ro là cách làm của người viết, không phải điều nguồn nói, và bài ghi rõ chỗ như vậy.

## Ai được xem, sửa và duyệt cái gì

Câu hỏi này nghe đơn giản, nhưng trong phần mềm quản lý nó chạm đến từng bảng dữ liệu. Một đơn hàng có ít nhất bốn thao tác khác nhau: xem, sửa, chốt, và xuất ra file. Nhân viên bán hàng có thể cần cả bốn trên đơn của mình, nhưng chỉ cần xem trên đơn của chi nhánh khác. Kế toán cần duyệt chi phí, nhưng không cần sửa danh mục giá. Nếu phần mềm chỉ có hai trạng thái, được vào hoặc không được vào, người quản trị buộc phải chọn giữa cấp quá nhiều và cấp quá ít.

Cách làm rõ ràng hơn là lập một ma trận. Hàng là chức năng hoặc loại dữ liệu, cột là vai trò, mỗi ô ghi các thao tác được phép. Ma trận này phục vụ hai việc. Đội kỹ thuật dùng nó để cấu hình đúng, còn người nghiệm thu dùng nó để đối chiếu. Không có ma trận, quyền thường được thêm rải rác mỗi khi có yêu cầu, và sau một năm không ai nhớ vì sao một người lại có quyền đó.

## Phân quyền theo vai trò là gì và vì sao không gán theo từng người

NIST mô tả RBAC bằng các phần tử cơ bản: người dùng, vai trò, quyền, thao tác và đối tượng. Theo trang dự án RBAC của NIST, mỗi người dùng được gán một hoặc nhiều vai trò, và mỗi vai trò được gán một hoặc nhiều quyền được phép với người giữ vai trò đó. Trang cũng ghi mô hình này được Viện Tiêu chuẩn Quốc gia Hoa Kỳ (ANSI) chấp nhận thành tiêu chuẩn ANSI/INCITS 359-2004, rồi sửa thành INCITS 359-2012.

![Trang Role Based Access Control của NIST mô tả phân quyền theo vai trò](https://mona.software/wp-content/uploads/2026/10/nist-rbac-phan-quyen-theo-vai-tro-mona.webp)

Trang dự án RBAC của NIST, chụp ngày 14/10/2026 tại csrc.nist.gov. Trang này được đánh dấu là dự án lưu trữ, nội dung không còn cập nhật.

Vì trang NIST đã lưu trữ, bài chỉ dùng nó cho định nghĩa cơ bản, không dùng cho chi tiết triển khai hiện đại. Phần còn lại của bài dựa vào hướng dẫn của OWASP và tài liệu của Frappe.

Gán quyền theo vai trò giúp việc đổi người không kéo theo việc sửa quyền. Khi kế toán công nợ nghỉ, người mới nhận vai trò đó và có đúng phạm vi của người cũ, không hơn. Gán theo từng người thì phải sao chép và chỉnh từng tài khoản, và sai sót thường nằm ở đó: người mới giữ nguyên quyền của người cũ mà không ai nhớ đã cấp. Vai trò cũng cho người rà soát một danh sách ngắn để biết toàn bộ hệ thống đang cho phép những gì.

Vai trò vẫn có giới hạn. OWASP khuyến nghị cân nhắc ABAC (phân quyền theo thuộc tính) và ReBAC (theo quan hệ) cho các quy tắc chi tiết, nhiều điều kiện, vì RBAC thuần túy khó diễn đạt những quy tắc như vậy. Trong phần mềm quản lý doanh nghiệp, vai trò kết hợp với phạm vi dữ liệu thường đủ cho phần lớn nhu cầu, phần còn lại là ngoại lệ có chủ đích và cần được ghi thành văn bản.

![Màn hình thống kê trong phần mềm MONA làm cho The IELTS Workshop](https://mona.software/wp-content/themes/monatheme/home-v2/assets/img/cs/ielts-thongke.webp)

Phần mềm cho việc này

Quy trình đang chạy mà phần mềm có sẵn không làm được?

MONA khảo sát nghiệp vụ trước dòng code đầu tiên.

[Viết phần mềm theo yêu cầu](https://mona.software/viet-phan-mem-theo-yeu-cau/)[Xem case study](https://mona.software/#case-study)

## Các loại quyền trong một phần mềm quản lý

Frappe Framework liệt kê quyền theo từng loại dữ liệu (DocType) và gán cho từng vai trò. Bảng dưới đây dùng đúng tên quyền trong tài liệu của Frappe. Cột cuối là rủi ro khi cấp nhầm, theo kinh nghiệm của người viết chứ không phải nguồn.

| Quyền (tên trong Frappe) | Cho phép làm gì | Rủi ro khi cấp nhầm |
| --- | --- | --- |
| Read | Xem bản ghi | Lộ thông tin cho người không cần biết |
| Write | Sửa bản ghi | Đổi giá, số lượng, trạng thái mà không ai duyệt |
| Create | Tạo bản ghi mới | Tạo đơn ảo hoặc phiếu nhập trùng |
| Delete | Xóa bản ghi | Mất dấu vết nếu không có nhật ký |
| Submit | Chốt chứng từ | Chứng từ đã chốt được hạch toán hoặc đối chiếu |
| Cancel | Hủy chứng từ đã chốt | Làm lệch số liệu đã báo cáo |
| Amend | Sửa lại chứng từ đã hủy | Đưa lại số liệu đã bị hủy vào sổ |
| Report | Mở báo cáo | Thấy tổng hợp của cả công ty |
| Export | Xuất ra Excel hoặc CSV | Dữ liệu rời khỏi hệ thống |
| Print | In hoặc tạo PDF | Bản giấy hoặc file PDF lưu ngoài tầm kiểm soát |
| Email | Gửi email từ chứng từ | Gửi nhầm người nhận bên ngoài |
| Share | Chia sẻ bản ghi cho người khác | Người không có vai trò vẫn xem được |

Điểm cần để ý là các quyền không gộp chung. Frappe có quyền riêng cho xem, xuất và in. Có tùy chọn “If the user is owner” để giới hạn quyền chỉ với bản ghi do chính người đó tạo. Permission Level chia các trường trong một tài liệu thành nhóm, mỗi nhóm có thể gán vai trò khác nhau, và mọi trường mặc định nằm ở mức 0.

![Trang Users and Permissions của Frappe liệt kê quyền theo vai trò và theo DocType](https://mona.software/wp-content/uploads/2026/10/frappe-users-and-permissions-mona.webp)

Mục Users and Permissions trong tài liệu Frappe Framework, chụp ngày 14/10/2026 tại docs.frappe.io. Trang liệt kê DocType Permissions, Permission Level, Role Permission Manager và User Permissions.

Lớp thứ hai là phạm vi dữ liệu. Frappe gọi là User Permissions: giới hạn bản ghi theo giá trị của một trường liên kết. Tài liệu của Frappe lấy ví dụ người dùng chỉ thấy bài viết có tác giả là chính họ. Trong phần mềm doanh nghiệp, cơ chế này thường dùng để tách chi nhánh, kho hoặc phòng ban. Một vai trò “nhân viên bán hàng” có thể được tạo đơn, còn phạm vi giới hạn ở chi nhánh của người đó. Trong một hệ ERP gộp bán hàng, kho và kế toán về một dữ liệu, lớp này quyết định người bán hàng chi nhánh A không thấy công nợ của chi nhánh B. Bài [hệ thống ERP nối bán hàng, kho và kế toán](https://mona.software/he-thong-erp/) trình bày cách các phân hệ đó chia dữ liệu với nhau.

## Thiết lập phân quyền theo thứ tự nào

Thứ tự dưới đây là cách người viết hay dùng khi dựng một hệ mới. Mỗi bước tạo ra thứ mà bước sau cần.

1. Liệt kê chức năng và loại dữ liệu. Với mỗi chức năng, ghi rõ nó đọc, ghi, chốt và xuất dữ liệu nào.
2. Đặt tên vai trò theo việc thật, ví dụ thủ kho, kế toán công nợ, quản lý chi nhánh. Tên theo việc thường ổn định hơn tên theo chức danh khi tổ chức thay đổi.
3. Với mỗi vai trò, bắt đầu từ không có quyền nào, rồi chỉ cấp những thao tác cần thiết. OWASP khuyến nghị từ chối mặc định: nếu không có quy tắc nào cho phép, yêu cầu bị từ chối.
4. Tách quyền xem khỏi quyền xuất, in, gửi email và chia sẻ. Đây là các điểm dữ liệu rời khỏi hệ thống, cần một dòng quyền riêng.
5. Gán phạm vi dữ liệu theo chi nhánh, kho hoặc phòng ban cho từng người dùng.
6. Kiểm quyền ở máy chủ cho mọi yêu cầu, kể cả yêu cầu từ API và từ ứng dụng khác. Việc ẩn nút trên giao diện không thay thế bước này.
7. Bật nhật ký cho việc thay đổi quyền, thao tác xuất dữ liệu và các lần yêu cầu bị từ chối. Phần này được nói kỹ ở mục sau.

Khi cấu hình xong, nghiệm thu bằng kịch bản thay vì bằng cảm giác. Đăng nhập từng vai trò, thử từng thao tác nằm ngoài phạm vi, rồi xác nhận hệ thống từ chối và có ghi lại. Một kịch bản thử vượt quyền cho ra kết quả rõ hơn một trang mô tả quyền. Các cửa kiểm tra bảo mật cần qua trước khi nghiệm thu được bàn trong bài [các cửa kiểm tra bảo mật trước nghiệm thu](https://mona.software/kiem-tra-bao-mat-truoc-nghiem-thu-owasp/).

## Quyền xem khác quyền xuất dữ liệu ở đâu

Người xem một báo cáo chỉ đọc số liệu trên màn hình. Người xuất ra Excel hay CSV thì mang được toàn bộ dữ liệu đó ra ngoài, và từ lúc ấy phần mềm không còn kiểm soát nó. Cùng một người có thể được xem danh sách khách hàng để tra cứu, nhưng không được xuất, vì xuất là bước làm dữ liệu rời khỏi hệ thống.

OWASP đưa việc xuất dữ liệu vào nhóm thao tác cần được truy vết, cùng với thêm, sửa và xóa. Vì vậy quyền xuất cần được cấp hẹp và có ghi nhận. Một kịch bản hay bị bỏ sót là nhân viên bán hàng xuất danh sách khách của cả công ty ngay trước khi nghỉ việc. Nếu không có nhật ký xuất, không ai biết việc đó đã xảy ra. Mốc giữ nhật ký 90 ngày trong ví dụ này là giả định để minh hoạ, không phải yêu cầu của nguồn nào. Khi dữ liệu có thông tin cá nhân, quyền xuất còn chạm đến quy định riêng, bài [yêu cầu của Nghị định 356/2025 với phần mềm doanh nghiệp](https://mona.software/nghi-dinh-356-2025-du-lieu-ca-nhan-phan-mem/) đi qua phần đó.

## Nhật ký kiểm toán cần ghi những gì

OWASP tách hai loại nhật ký. Nhật ký bảo mật ghi các sự kiện như đăng nhập thành công hoặc thất bại, lỗi kiểm soát truy cập và hoạt động bất thường. Audit trail ghi việc thêm, sửa, xóa và xuất dữ liệu. Hai loại có mục đích khác nhau, cần tách riêng và cấp quyền đọc riêng.

Theo hướng dẫn Logging của OWASP, mỗi sự kiện cần trả lời được bốn câu. Khi nào: thời điểm ghi và thời điểm sự kiện xảy ra. Ở đâu: ứng dụng, máy chủ, dịch vụ. Ai: địa chỉ nguồn và định danh người dùng đã xác thực. Cái gì: loại sự kiện, mức độ và mô tả. Hành động định làm, đối tượng và kết quả thành công, thất bại hay bị trì hoãn là các trường tùy chọn, và cần được cân nhắc.

Người quản trị cần thêm giá trị cũ và giá trị mới khi một bản ghi bị sửa. Đây là cách làm thực tế của người viết, không phải yêu cầu có trong các nguồn trên. Nếu nhật ký chỉ ghi “A đã sửa đơn 1024 lúc 10:12”, người rà soát không biết số tiền đổi từ bao nhiêu sang bao nhiêu. Giả định: đơn 1024 đổi từ 4.500.000 đồng thành 450.000 đồng, và chỉ có hai con số đó trong nhật ký mới đủ để biết sai ở đâu. Ghi cả hai giá trị giúp trả lời đúng câu hỏi khi cần: sai ở đâu và bắt đầu từ lúc nào. Bài [nhật ký lưu vết trong phần mềm kế toán](https://mona.software/so-ke-toan-song-song-phan-mem-luu-vet/) bàn thêm về yêu cầu lưu vết trong phần mềm kế toán.

![Bàn làm việc văn phòng với laptop đặt cạnh màn hình lớn trên mặt bàn trắng](https://mona.software/wp-content/uploads/2026/10/van-phong-laptop-man-hinh-ban-lam-viec-mona.webp)

Bàn làm việc văn phòng với laptop và màn hình lớn, nơi nhân viên mở phần mềm mỗi ngày. Ảnh: rawpixel, CC0, nguồn https://www.rawpixel.com/image/6113616/photo-image-public-domain-logo-laptop, qua Openverse.

OWASP cũng khuyến nghị đừng ghi quá nhiều lẫn quá ít, và loại mật khẩu, session ID hay token trước khi ghi. Quyền đọc nhật ký phải hạn chế và được rà định kỳ, vì người sửa được nhật ký thì nhật ký không còn là bằng chứng đáng tin. Chính OWASP cũng yêu cầu mọi truy cập vào nhật ký phải được ghi lại và giám sát.

## Kiểm quyền ở máy chủ, không chỉ trên giao diện

OWASP nhấn mạnh việc kiểm quyền phải làm ở phía máy chủ, cổng API hoặc hàm xử lý, không chỉ ở phía trình duyệt. Quy tắc này áp dụng cho mọi yêu cầu. Kiểm đúng trên phần lớn yêu cầu là chưa đủ, vì một đường gọi bị bỏ sót là đủ để lộ dữ liệu.

![Trang Authorization Cheat Sheet của OWASP với danh sách khuyến nghị kiểm soát truy cập](https://mona.software/wp-content/uploads/2026/10/owasp-authorization-cheat-sheet-mona.webp)

Mục lục trang Authorization Cheat Sheet của OWASP, chụp ngày 14/10/2026 tại cheatsheetseries.owasp.org. Danh sách mục lục có các khuyến nghị như từ chối mặc định, kiểm quyền ở mọi yêu cầu và kiểm quyền ở máy chủ.

Mã định danh trong đường dẫn cũng cần được xử lý cẩn thận. OWASP nói rõ rằng che giấu ID là chưa đủ, và khuyến nghị kiểm quyền trên từng đối tượng cụ thể ở mỗi lần truy cập. Cách này chặn được lỗi tham chiếu trực tiếp không an toàn (IDOR), khi người dùng đổi một số trong đường dẫn để xem đơn của người khác. Khi kiểm quyền thất bại, hệ thống cần xử lý tập trung ở một nơi và không để lộ chi tiết nội bộ trong thông báo lỗi.

## Khi nào nên nhờ đội phát triển phần mềm làm phân quyền

Phân quyền dựng sẵn của một hệ đóng gói đủ cho nhiều doanh nghiệp. Khi quy tắc gắn với nghiệp vụ riêng, ví dụ duyệt chi phí theo hạn mức của từng phòng, hoặc chỉ cho xuất báo cáo sau khi đã chốt sổ, thì cần viết thêm logic. Việc đó thuộc về đội phát triển, không để người dùng cuối tự chỉnh trong giao diện.

MONA nhận viết phần mềm quản lý nội bộ theo yêu cầu. Phân quyền là một phần của phạm vi đó, gồm ma trận vai trò, phạm vi dữ liệu, nhật ký và kịch bản nghiệm thu. Doanh nghiệp đang tìm hướng làm có thể xem [dịch vụ viết phần mềm theo yêu cầu của MONA](https://mona.software/viet-phan-mem-theo-yeu-cau/), hoặc gọi hotline 1900 636 648 để trao đổi về quy trình hiện tại. Nếu đang so sánh các phần mềm có sẵn, bài [lựa chọn phần mềm quản trị doanh nghiệp](https://mona.software/lua-chon-phan-mem-quan-tri-doanh-nghiep/) đi qua những tiêu chí tương tự.

## Hỏi đáp

### Vai trò khác gì với quyền?

Quyền là một thao tác trên một loại dữ liệu, ví dụ sửa đơn hàng hoặc xuất báo cáo tồn kho. Vai trò là tập hợp các quyền gắn với một công việc, ví dụ thủ kho. Tài liệu của Frappe mô tả vai trò là thứ quy định người dùng được làm gì trên một DocType, và quyền được gán cho vai trò, sau đó người dùng nhận vai trò. Khi công việc thay đổi, chỉ cần sửa vai trò một lần.

### Tài khoản dùng chung có ổn không?

Không. Tài khoản dùng chung làm mất khả năng truy vết, vì nhật ký chỉ ghi được một tên và không biết ai thực sự làm việc đó. OWASP đưa việc dùng tài khoản mặc định, tài khoản dùng chung hay tài khoản break-glass vào nhóm sự kiện cần ghi log. Mỗi người một tài khoản là điều kiện để nhật ký có nghĩa.

### Nhật ký kiểm toán khác nhật ký lỗi hệ thống thế nào?

Nhật ký lỗi hệ thống ghi việc phần mềm gặp sự cố kỹ thuật, ví dụ một dịch vụ bị ngắt. Nhật ký kiểm toán ghi việc con người làm với dữ liệu: ai sửa, ai xuất, ai xóa, lúc nào. OWASP tách hai loại này vì mục đích khác nhau. Khi cần tra một con số lệch, nhật ký kiểm toán là nơi đúng để tìm, còn nhật ký lỗi chỉ cho biết hệ thống có trục trặc hay không.

### AI Agent có nên được cấp quyền riêng không?

Có, và cấp hẹp hơn người tạo ra nó. Một AI Agent gọi API phần mềm thì cần tài khoản và vai trò riêng, để nhật ký ghi được đó là agent chứ không phải người. Phần này là suy luận từ các nguyên tắc của OWASP, không phải điều các nguồn trong bài nói trực tiếp. Bài [cách cho AI Agent dùng phần mềm nội bộ qua MCP server](https://mona.software/mcp-server-la-gi/) trình bày thêm về cách đặt ranh giới đó.

### Ẩn nút trên giao diện có đủ để chặn người không có quyền không?

Không. Ẩn nút chỉ ngăn người dùng bình thường bấm nhầm. Người biết địa chỉ API vẫn gọi được trực tiếp nếu máy chủ không kiểm quyền. OWASP yêu cầu kiểm quyền ở máy chủ, cổng API hoặc hàm xử lý, và kiểm lại cho từng yêu cầu. Giao diện chỉ là lớp tiện lợi cho người dùng bình thường.

## Đọc thêm

- [Chuyển dữ liệu từ Excel sang phần mềm quản lý](https://mona.software/chuyen-du-lieu-excel-sang-phan-mem-quan-ly/)
- [Sao lưu và khôi phục dữ liệu phần mềm doanh nghiệp](https://mona.software/sao-luu-khoi-phuc-du-lieu-phan-mem-doanh-nghiep/)
- [Nghiệm thu phần mềm UAT bằng kịch bản kiểm thử](https://mona.software/nghiem-thu-phan-mem-uat-kich-ban-kiem-thu/)

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

### Vai trò khác gì với quyền?

Quyền là một thao tác trên một loại dữ liệu, ví dụ sửa đơn hàng hoặc xuất báo cáo tồn kho. Vai trò là tập hợp các quyền gắn với một công việc, ví dụ thủ kho. Tài liệu của Frappe mô tả vai trò là thứ quy định người dùng được làm gì trên một DocType, và quyền được gán cho vai trò, sau đó người dùng nhận vai trò. Khi công việc thay đổi, chỉ cần sửa vai trò một lần.

### Tài khoản dùng chung có ổn không?

Không. Tài khoản dùng chung làm mất khả năng truy vết, vì nhật ký chỉ ghi được một tên và không biết ai thực sự làm việc đó. OWASP đưa việc dùng tài khoản mặc định, tài khoản dùng chung hay tài khoản break-glass vào nhóm sự kiện cần ghi log. Mỗi người một tài khoản là điều kiện để nhật ký có nghĩa.

### Nhật ký kiểm toán khác nhật ký lỗi hệ thống thế nào?

Nhật ký lỗi hệ thống ghi việc phần mềm gặp sự cố kỹ thuật, ví dụ một dịch vụ bị ngắt. Nhật ký kiểm toán ghi việc con người làm với dữ liệu: ai sửa, ai xuất, ai xóa, lúc nào. OWASP tách hai loại này vì mục đích khác nhau. Khi cần tra một con số lệch, nhật ký kiểm toán là nơi đúng để tìm, còn nhật ký lỗi chỉ cho biết hệ thống có trục trặc hay không.

### AI Agent có nên được cấp quyền riêng không?

Có, và cấp hẹp hơn người tạo ra nó. Một AI Agent gọi API phần mềm thì cần tài khoản và vai trò riêng, để nhật ký ghi được đó là agent chứ không phải người. Phần này là suy luận từ các nguyên tắc của OWASP, không phải điều các nguồn trong bài nói trực tiếp. Bài cách cho AI Agent dùng phần mềm nội bộ qua MCP server trình bày thêm về cách đặt ranh giới đó.

### Ẩn nút trên giao diện có đủ để chặn người không có quyền không?

Không. Ẩn nút chỉ ngăn người dùng bình thường bấm nhầm. Người biết địa chỉ API vẫn gọi được trực tiếp nếu máy chủ không kiểm quyền. OWASP yêu cầu kiểm quyền ở máy chủ, cổng API hoặc hàm xử lý, và kiểm lại cho từng yêu cầu. Giao diện chỉ là lớp tiện lợi cho người dùng bình thường.