Trả lời nhanh: Ma trận phân quyền dữ liệu là bảng nối nhóm dữ liệu với vai trò người dùng, ghi rõ ai được xem, sửa, chia sẻ, duyệt hoặc quản trị, cùng người sở hữu dữ liệu và ngày rà soát. Hãy lập ma trận theo vai trò và nhóm, không cấp thủ công cho từng nhân viên. Trưởng bộ phận xác nhận nhu cầu nghiệp vụ; IT cấu hình và kiểm thử; doanh nghiệp giữ quyền phê duyệt. Mẫu dưới đây là ví dụ để bắt đầu, không phải chính sách mặc định cho mọi công ty.
Bài này tập trung vào thiết kế quyền trước khi triển khai hoặc chuẩn hóa lại hệ thống. Nếu bạn đang chọn nơi lưu dữ liệu, đọc NAS, file server hay SharePoint. Nếu cần dịch vụ khảo sát và bàn giao trọn dự án, xem xây dựng hệ thống CNTT doanh nghiệp.
Vì sao quyền theo phòng ban vẫn dễ sai?
Tên phòng ban không đủ để quyết định quyền. Kế toán có người nhập chứng từ, người duyệt thanh toán và người chỉ xem báo cáo. Nhân sự có hồ sơ cá nhân cần hạn chế hơn tài liệu tuyển dụng. Sales cần dữ liệu khách hàng được giao nhưng không nhất thiết xem lương hoặc hợp đồng của mọi nhóm. Một người có thể kiêm vai trò hoặc tham gia dự án liên phòng ban. Nếu cấp quyền bằng tin nhắn và thư mục cá nhân, quyền cũ thường không được thu hồi khi họ đổi vai trò.
Ma trận tốt bắt đầu từ mục đích kinh doanh của từng vùng dữ liệu. Mỗi vùng cần một owner chịu trách nhiệm nội dung, người duyệt truy cập và người vận hành kỹ thuật. Quyền admin hệ thống không đồng nghĩa với quyền quyết định ai được xem dữ liệu. CISA khuyến nghị nguyên tắc quyền tối thiểu; Microsoft khuyến nghị quản trị quyền Windows qua nhóm và quản trị team site SharePoint qua nhóm Microsoft 365/Teams khi phù hợp.
Mẫu ma trận tối thiểu có thể dùng ngay
Trước khi điền, chia dữ liệu thành vùng có owner rõ: hồ sơ nhân sự, chứng từ kế toán, hợp đồng khách hàng, tài liệu vận hành và tài liệu dự án. Cột bên dưới mô tả quyền nghiệp vụ, không phải danh sách ACL kỹ thuật. Sử dụng R = xem, E = sửa/tạo, A = duyệt hoặc quản trị nội dung, — = không có quyền. Quyền chia sẻ ra ngoài nên là một cột chính sách riêng thay vì ngầm hiểu từ quyền sửa.
| Vùng dữ liệu (ví dụ) | Owner / người duyệt | Nhóm HR | Nhóm Kế toán | Nhóm Sales | IT vận hành |
|---|---|---|---|---|---|
| Hồ sơ nhân sự | Trưởng HR | R/E; A theo vai trò | — hoặc R giới hạn theo quy trình | — | Quản trị kỹ thuật, truy cập nội dung theo phê duyệt |
| Chứng từ kế toán | Kế toán trưởng | — | R/E; A theo vai trò | — | Quản trị kỹ thuật, truy cập nội dung theo phê duyệt |
| Hợp đồng khách hàng | Trưởng kinh doanh | — | R theo nhu cầu được duyệt | R/E theo nhóm phụ trách | Quản trị kỹ thuật, truy cập nội dung theo phê duyệt |
| Tài liệu vận hành chung | Trưởng vận hành | R | R | R | R/E chỉ với tài liệu IT được giao |
Không áp nguyên bảng mẫu này lên dữ liệu thật. Mỗi quyền phải được owner chốt theo nhiệm vụ, loại dữ liệu nhạy cảm và quy trình pháp lý của doanh nghiệp. Ví dụ ‘R giới hạn’ cần chỉ rõ thư mục, báo cáo hoặc trường dữ liệu nào được phép xem. Nếu phần mềm nghiệp vụ có quyền ở cấp bản ghi, ma trận thư mục không thay được cấu hình trong ứng dụng.
Thêm sáu cột để ma trận trở thành công cụ vận hành
1. Vùng dữ liệu và nơi lưu: tên nghiệp vụ, đường dẫn NAS/file server hoặc site/library SharePoint, ứng dụng liên quan và bản dữ liệu gốc. Tránh cùng một bộ hồ sơ có nhiều nơi được gọi là bản chính.
2. Owner và người duyệt: người chịu trách nhiệm nội dung có thể khác với quản trị viên IT. Ghi đầu mối thay thế khi owner vắng mặt; yêu cầu quyền đặc biệt phải có lý do và thời hạn.
3. Nhóm/vai trò: dùng tên nhóm nhất quán, mô tả nhiệm vụ và người quản lý nhóm. Tránh cấp trực tiếp cho từng user rồi mất dấu. Với Windows, Microsoft nêu rõ quyền cá nhân dễ quản hơn khi đặt vào tài khoản nhóm; với SharePoint team site, nhóm Microsoft 365 thường là điểm quản trị chính.
4. Mức quyền: phân biệt xem, sửa, xóa, chia sẻ ngoài, duyệt và quyền admin. Quyền ‘sửa’ ở một sản phẩm có thể bao gồm xóa hoặc thay đổi nhiều hơn dự kiến; kiểm tra mức quyền thực tế thay vì suy từ tên.
5. Hiệu lực và ngoại lệ: ghi ngày bắt đầu/kết thúc, đối tác ngoài công ty, dự án tạm thời và cách gia hạn. Không dùng liên kết công khai hoặc tài khoản chung thay cho một ngoại lệ có phê duyệt.
6. Bằng chứng và chu kỳ rà: lưu ticket/phê duyệt, người thực hiện, ngày kiểm thử, kết quả và lần rà tiếp theo. Chu kỳ nên theo rủi ro; khi nhân sự đổi vai trò hoặc nghỉ việc thì rà ngay, không chờ lịch định kỳ.
Quy trình triển khai từ bảng đến quyền thực tế
Bước 1 – Kiểm kê: liệt kê nơi lưu, nhóm dữ liệu, owner, tài khoản đặc quyền, quyền hiện hành, nhóm chia sẻ ngoài và dữ liệu không rõ chủ. Không thay đổi hàng loạt khi chưa có bản xuất hiện trạng và phương án quay lại.
Bước 2 – Phê duyệt: trưởng bộ phận và owner dữ liệu xác nhận từng vùng quyền. HR cung cấp vai trò, ngày hiệu lực và biến động nhân sự; IT nêu rủi ro kỹ thuật, tài khoản phụ thuộc và trường hợp quyền xung đột.
Bước 3 – Tạo nhóm: ánh xạ vai trò nghiệp vụ sang nhóm kỹ thuật. Trên file server cần xem cả share permission và NTFS; trên NAS cần xem nhóm và ACL của thiết bị; trên SharePoint xem site, thư viện, nhóm Members/Visitors/Owners và liên kết chia sẻ. Hạn chế quyền đơn lẻ ở cấp file vì dễ khó kiểm toán.
Bước 4 – Pilot: thử với tài khoản đại diện cho từng vai trò, gồm một tài khoản không có quyền và một tài khoản đã nghỉ/đổi vị trí trong môi trường thử phù hợp. Kiểm tra xem, sửa, xóa, đồng bộ, chia sẻ ngoài và ứng dụng dùng file. Đừng chỉ đăng nhập bằng admin rồi kết luận quyền đã đúng.
Bước 5 – Nghiệm thu và vận hành: ghi kết quả test, ngoại lệ còn mở, owner ký xác nhận và hướng dẫn cách xin/thu hồi quyền. Liên kết với checklist nhân viên mới/nghỉ việc để quyền không trôi khỏi thiết kế ban đầu.
Khác biệt giữa NAS, file server và SharePoint
Trên NAS hoặc file server, thư mục cha và quyền kế thừa có thể quyết định phần lớn quyền hiệu lực. Windows còn có hai lớp share và NTFS cần hiểu cùng nhau. Khi một người thuộc nhiều nhóm, quyền cuối cùng có thể khác dự định của người lập bảng; phải test thực tế. Trên SharePoint, team site gắn với Microsoft 365 group; Owners, Members và Visitors có phạm vi khác nhau. Microsoft lưu ý quyền site/team nên quản lý qua nhóm liên kết hoặc Teams, còn nhu cầu chỉ đọc có thể cần Visitors. Ngoại lệ cấp ở thư viện, thư mục hoặc file nên được ghi riêng để không biến ma trận thành bản đồ không thể theo dõi.
Không đồng nhất ‘quyền truy cập’ với ‘bảo vệ dữ liệu’. Bản sao lưu, chính sách lưu giữ, MFA, kiểm soát thiết bị và nhật ký thay đổi là các lớp khác. Đặc biệt, IT có thể cần quyền vận hành hệ thống nhưng không nên mặc nhiên đọc mọi hồ sơ nhân sự hay tài chính.
Ba tình huống cần kiểm lại ngay
Nhân viên chuyển phòng: thu hồi nhóm cũ trước hoặc cùng lúc cấp nhóm mới theo lịch được duyệt. Rà quyền trực tiếp, link chia sẻ và nhóm dự án tạm, không chỉ đổi chức danh trong HR.
Đối tác hết hợp đồng: xác nhận owner dữ liệu đã nhận bàn giao, vô hiệu tài khoản/guest, thu hồi link và kiểm thiết bị hoặc khóa truy cập còn dùng. Lưu ticket và mốc hoàn tất.
Dự án kết thúc: chốt phiên bản tài liệu chính, owner lưu trữ, quyền đọc sau dự án và thời hạn giữ; ngừng nhóm quyền sửa hoặc chia sẻ rộng. Đừng xóa dữ liệu khi chưa có chính sách lưu giữ và phê duyệt.
Câu hỏi thường gặp
Doanh nghiệp nhỏ có cần ma trận không? Có, nhưng có thể bắt đầu bằng vài vùng dữ liệu quan trọng và 4-6 vai trò, sau đó mở rộng. Một bảng ngắn có owner và người duyệt tốt hơn danh sách quyền không ai chịu trách nhiệm.
IT có thể tự duyệt quyền không? IT có thể thực hiện và tư vấn rủi ro, nhưng owner dữ liệu hoặc người được doanh nghiệp ủy quyền cần duyệt mục đích truy cập. Quyền admin khẩn cấp cần quy trình riêng và log.
Phải rà quyền bao lâu một lần? Tùy mức rủi ro và biến động nhân sự. Rà ngay sau thay đổi vai trò/nghỉ việc và định kỳ theo lịch đã thống nhất; vùng nhạy cảm có thể cần rà thường xuyên hơn.
Ma trận có thay backup hay DLP không? Không. Nó giúp giới hạn và giải thích quyền; backup và kiểm soát thất thoát dữ liệu là các biện pháp bổ sung.
Nguồn kỹ thuật
Microsoft Learn: Windows access control; Microsoft Learn: SharePoint modern permissions; Microsoft Learn: SharePoint permission levels; CISA: least privilege and SMB guidance.
