Vai trò và quyền được giải thích cùng ví dụ rõ ràng, giúp bạn quyết định Chủ sở hữu, Quản lý, Nhân viên và Khách hàng có thể thấy gì và ngăn rò rỉ dữ liệu.
Một “rò rỉ dữ liệu” tại nơi làm việc thường trông rất tẻ nhạt. Một nhân viên hỗ trợ mở hồ sơ khách hàng và thấy toàn bộ lịch sử thanh toán. Một khách hàng đăng nhập và thấy ghi chú nội bộ như “Giảm 20% nếu họ than phiền” hoặc chi phí thực tế và biên độ lợi nhuận trên hóa đơn. Không ai bị đánh cắp mật khẩu. Ứng dụng đơn giản là hiển thị sai thông tin.
Phần lớn rò rỉ xảy ra do vô tình. Quyền được thêm vào muộn, một màn hình mới được phát hành vội, hoặc ai đó sao chép một vai trò cũ "đủ tốt" cho thử nghiệm. Rồi một thay đổi nhỏ, như thêm một trường mới vào bảng, lặng lẽ trở nên hiển thị cho mọi người.
Đó là lý do tại sao vai trò và quyền nên là phần quan trọng của ứng dụng, không phải ô kiểm làm gấp. Hầu hết doanh nghiệp nhỏ kết thúc với bốn loại vai trò giống nhau: Chủ sở hữu, Quản lý, Nhân viên và Khách hàng.
Mục tiêu đơn giản: mỗi người chỉ nên thấy những gì họ cần để làm việc, và không hơn. Điều đó bao gồm dữ liệu phía sau, không chỉ các màn hình bạn nghĩ tới.
Nếu bạn xây dựng nhanh trên nền tảng no-code như AppMaster, điều này càng quan trọng hơn. Tốc độ là tốt, nhưng cũng dễ vô tình phơi bày ghi chú riêng tư, quy tắc giá, hoặc hồ sơ khách hàng khác nếu quyền truy cập không được thiết kế từ đầu.
Vai trò và quyền là các quy tắc quyết định ai làm gì trong ứng dụng.
Một mức truy cập là kết quả thực tế của những quy tắc đó. Hai người cùng là “Nhân viên” có thể có mức truy cập khác nhau vì người này có thể duyệt hoàn tiền trong khi người kia không thể.
Một cách tin cậy để tránh sai sót là bắt đầu với quyền thấp nhất, rồi chỉ thêm những gì người đó cần cho công việc hàng ngày. Nếu ai đó không bao giờ chỉnh sửa hóa đơn, đừng cho họ quyền chỉnh sửa "phòng khi cần". Thêm quyền dễ hơn nhiều so với hoàn tác một rò rỉ dữ liệu.
Hầu hết quyền gói gọn vào vài hành động: xem, tạo, sửa, xóa, và một vài hành động rủi ro cao hơn như xuất hoặc phê duyệt.
Phạm vi trả lời câu hỏi khác: “Họ có thể làm điều đó với những bản ghi nào?” Ai đó có thể được phép xem hóa đơn, nhưng chỉ là hóa đơn của họ, không phải của mọi người.
Các mẫu phạm vi thường gặp:
Một đại diện bán hàng có thể tạo và xem báo giá của chính họ, nhưng không thể xuất danh sách khách hàng đầy đủ. Một quản lý bán hàng có thể xem báo giá của cả đội và phê duyệt chiết khấu. Chủ sở hữu có thể xem mọi thứ và xuất báo cáo cho kế toán.
Hầu hết ứng dụng kết thúc với cùng bốn nhóm người. Chi tiết thay đổi, nhưng mô hình thì không. Nếu bạn bắt đầu với vai trò và quyền rõ ràng, bạn tránh được nhiều khoảnh khắc lúng túng “tại sao họ thấy được điều đó?” sau này.
Chủ sở hữu thường cần thấy toàn bộ hoạt động của doanh nghiệp. Điều này thường bao gồm thanh toán, cài đặt bảo mật (như quy tắc mật khẩu và MFA), và lịch sử kiểm toán để họ có thể xem ai thay đổi gì và khi nào.
Quản lý cần điều hành đội mà không phải là quản trị viên toàn phần. Họ thường cần giám sát (xem mọi thứ trong phòng ban), phê duyệt hành động (chiết khấu, hoàn tiền, nghỉ phép, thay đổi nội dung) và đọc báo cáo. Họ có thể cần một vài hành động quản trị hạn chế, như mời nhân viên hoặc đặt lại mật khẩu, nhưng không truy cập thanh toán hay cài đặt bảo mật toàn cầu.
Nhân viên nên làm công việc hàng ngày nhanh chóng, với rủi ro tối thiểu. Mặc định an toàn là “chỉ những gì tôi được phân công.” Nhân viên hỗ trợ chỉ thấy ticket của họ, người điều phối chỉ thấy lộ trình hôm nay, và nhân viên bán hàng chỉ thấy khách tiềm năng của họ. Xuất và tải hàng loạt nên tắt mặc định và chỉ bật khi thực sự cần.
Khách hàng chỉ nên thấy dữ liệu của chính họ, ngay cả khi nhiều người dùng chung một tài khoản. Cho phép họ thực hiện hành động giới hạn (tạo yêu cầu, thanh toán hóa đơn, cập nhật hồ sơ), nhưng ẩn ghi chú nội bộ, bình luận nhân viên và trạng thái nội bộ.
Một bộ mặc định hoạt động với nhiều doanh nghiệp:
Nhiều nhóm đặt vai trò và quyền theo màn hình: “Nhân viên có thể mở trang Đơn hàng, khách thì không.” Điều đó hữu ích, nhưng bỏ sót rủi ro thực sự. Cùng một dữ liệu xuất hiện trong tìm kiếm, bình luận, thông báo, bản xuất và tệp đính kèm.
Hãy bắt đầu bằng cách liệt kê các khu vực dữ liệu, không phải menu. Các khu vực tác động lớn thường bao gồm liên hệ khách hàng, đơn hàng và trạng thái giao hàng, hóa đơn và trạng thái thanh toán, lương và ghi chú nhân sự, và ghi chú nội bộ hoặc phân tích.
Rồi quyết định mỗi vai trò có thể làm gì với từng loại dữ liệu: xem, tạo, sửa, xóa, phê duyệt và chia sẻ. Ở đây quy tắc ở mức trường (field-level) quan trọng. Cùng một đối tượng thường cần một chế độ xem công khai và một chế độ xem nội bộ.
Ví dụ: một Đơn hàng có thể gồm tên khách hàng, địa chỉ giao hàng, giá, biên nội bộ và ghi chú nội bộ như “Khách hay phàn nàn, giảm giá.” Khách hàng chỉ nên thấy địa chỉ và trạng thái, nhưng không bao giờ thấy biên nội bộ hay ghi chú. Quản lý có thể thấy tất cả trường và có quyền phê duyệt chiết khấu. Nhân viên chỉ thấy các trường họ cần để giao hàng, nhưng không thấy chi tiết tài chính.
Tệp và tệp đính kèm cần cảnh giác hơn. Hợp đồng, giấy tờ tùy thân, biên lai và ảnh chụp màn hình thường chứa thông tin nhạy cảm hơn các trường form. Xử lý chúng như một quyền riêng: ai được tải lên, ai được tải xuống, ai được xem bản xem trước. Cũng quyết định liệu tệp đính kèm kế thừa quyền từ bản ghi cha (như hóa đơn) hay có quy tắc riêng.
Cuối cùng, đừng coi xuất và hành động hàng loạt là “đã bao gồm” chỉ vì ai đó có thể xem danh sách. Hãy làm cho chúng rõ ràng: xuất CSV/PDF, tải xuống tệp hàng loạt, thay đổi trạng thái hàng loạt (phê duyệt, hủy, hoàn tiền), nhắn tin hàng loạt (email/SMS/Telegram), và hành động admin như phân công lại bản ghi.
Hãy tưởng tượng một doanh nghiệp dịch vụ nhỏ: chủ sở hữu bán dự án, quản lý giám sát công việc, nhân viên làm việc thực tế, và khách hàng duyệt báo giá và thanh toán hóa đơn. Cách nhanh nhất để tránh sai sót là thống nhất vai trò và quyền trước khi ai đó đăng nhập.
Bắt đầu với thông tin tiền bạc. Giá có thể hiển thị với nhiều người hơn so với biên lợi nhuận. Một quy tắc phổ biến: nhân viên thấy mức cần thu, nhưng không thấy lý do chọn mức giá đó. Kỹ thuật viên có thể cần dòng mục để giải thích hóa đơn, nhưng họ không cần biết biên nội bộ, chi phí nhà cung cấp hay chiết khấu đặc biệt bạn dùng để thắng thầu.
Dữ liệu khách hàng là điểm nóng nữa. Nhiều đội muốn nhiều người có thể xem thông tin liên hệ (để gọi đúng người), nhưng chỉ một vài người được chỉnh sửa. Nếu không, bạn sẽ gặp tình trạng ghi đè vô tình như email thanh toán bị thay bằng email cá nhân, và hóa đơn không đến được kế toán.
Một cấu hình đơn giản hiệu quả cho nhiều đội:
Khóa các hành động rủi ro cao. Đánh dấu hóa đơn là đã thanh toán, thực hiện hoàn tiền, hoặc thay đổi phương thức thanh toán nên giới hạn cho chủ sở hữu (hoặc vai trò tài chính đáng tin cậy).
Một bộ phận hỗ trợ trông có vẻ đơn giản: khách hàng gửi tin, đội trả lời và ticket đóng lại. Vấn đề bắt đầu khi cùng một chế độ xem ticket được dùng cho mọi người. Một cài đặt sai, và khách hàng có thể thấy ghi chú nội bộ, tag, hoặc thậm chí chỉ số hiệu suất nhân viên.
Hãy tưởng tượng một doanh nghiệp thương mại điện tử nhỏ với hộp thư hỗ trợ chung. Một ticket bao gồm tin nhắn khách, chi tiết đơn hàng, trạng thái giao hàng và ghi chú nội bộ như “có thể gian lận, kiểm tra ID” hoặc “VIP, ưu tiên.” Bối cảnh nội bộ hữu ích cho đội, nhưng không bao giờ nên hiển thị với khách hàng.
Một tách biệt rõ ràng giữ dữ liệu nhạy cảm an toàn:
PII của khách là cái bẫy tiếp theo. Hỗ trợ thường cần số điện thoại hoặc địa chỉ, nhưng không phải trên mọi ticket. Quy tắc tốt là: chỉ hiển thị trường nhạy cảm khi quy trình cần. Ví dụ, hiện địa chỉ chỉ sau khi nhân viên chọn “vấn đề giao hàng,” và ẩn lại khi ticket đóng.
Giữ các chỉ số nội bộ tách biệt khỏi trải nghiệm khách. Những thứ như “thời gian phản hồi đầu tiên,” “điểm nhân viên,” hoặc “chuyển cho pháp lý” thuộc về chế độ xem nhân viên và quản lý mà thôi.
Hãy tưởng tượng kho và đội thực hiện giao hàng cả ngày. Một người lập tuyến, người khác đóng gói, và tài xế hoàn thành điểm dừng. Nếu ứng dụng hiển thị sai chi tiết cho sai người, không chỉ là điều khó xử — nó có thể phơi bày địa chỉ khách, giá cả hoặc ghi chú nội bộ.
Bắt đầu bằng việc tách rõ những gì mỗi nhóm cần hàng ngày.
Nhân viên (người chọn hàng và tài xế) thường cần một giao diện chặt, tập trung vào nhiệm vụ. Tài xế nên mở app và chỉ thấy công việc được phân công hôm nay, thứ tự điểm dừng, thông tin liên hệ cho điểm dừng và hướng dẫn giao hàng. Họ không nên duyệt danh sách khách hàng đầy đủ hoặc xem công việc của tài xế khác. Nếu họ cover ca, quản lý có thể phân công lại thay vì cho quyền rộng.
Quản lý cần bức tranh vận hành rộng hơn. Họ nên thấy lịch trình của tất cả đội, số lượng tồn kho và những gì đang sai (giao hàng trễ, giao thất bại, hàng hư, mất chữ ký). Họ cũng cần công cụ để giải quyết ngoại lệ: phân công lại điểm dừng, tách lộ trình hoặc phê duyệt điều chỉnh tồn kho.
Khách hàng cần giao diện nhỏ nhất: chỉ trạng thái giao hàng của họ. Họ có thể theo dõi ETA, xem bằng chứng giao hàng và nhận cập nhật như “đang giao” hoặc “trễ.” Họ không bao giờ thấy khách hàng khác, bản đồ lộ trình cả ngày hoặc ghi chú ngoại lệ nội bộ.
Một cách đơn giản để thực thi quyền là giới hạn dữ liệu theo phân công và theo tài khoản khách hàng. Ví dụ, một bản ghi Công việc Giao hàng chỉ đọc được bởi (1) nhân viên được phân công, (2) quản lý và (3) khách hàng gắn với đơn hàng đó.
Bắt đầu bằng cách đặt tên nhóm người dùng bằng ngôn ngữ đơn giản. “Chủ sở hữu”, “Quản lý”, “Nhân viên” và “Khách hàng” là một khởi đầu tốt, nhưng chỉ khi chúng phù hợp với cách doanh nghiệp bạn hoạt động. Với mỗi nhóm, viết ra một câu ngắn mô tả thành công, ví dụ “Quản lý có thể phân công công việc và xem hiệu suất đội mà không thấy lương.”
Tiếp theo, ánh xạ hành động tới khu vực dữ liệu. Đừng nghĩ theo màn hình trước. Nghĩ theo dữ liệu tồn tại và người dùng có thể làm gì với nó. Một lưới đơn giản trên giấy là đủ:
Rồi kiểm tra bản nháp bằng các tác vụ thực tế, không đoán mò. Đi qua các luồng phổ biến như “tạo đơn”, “giải quyết ticket” và “tải báo cáo”. Nếu một tác vụ buộc bạn phải cho quyền rộng, có lẽ bạn thiếu một quyền cụ thể (ví dụ “xem tổng” mà không cho “xuất”).
Thêm phê duyệt khi tiền hoặc thay đổi nhạy cảm xảy ra. Nhân viên có thể soạn hóa đơn, nhưng chỉ quản lý mới phê duyệt hoặc gửi. Nhân viên có thể sửa địa chỉ giao hàng, nhưng thay đổi thông tin ngân hàng cần phê duyệt của chủ sở hữu.
Phần lớn rò rỉ trong đội nhỏ không phải do tấn công. Chúng xảy ra khi ứng dụng vô tình cho ai đó nhiều quyền hơn công việc yêu cầu. Vai trò và quyền thất bại khi được đặt một lần rồi không bao giờ xem lại.
Một mẫu phổ biến là cho ai đó quyền admin toàn phần "chỉ để cài đặt." Sự vội vàng qua đi, nhưng quyền đó vẫn còn. Vài tuần sau, người đó xuất toàn bộ danh sách khách hàng để “giúp báo cáo” và dữ liệu riêng tư nằm trong bảng tính.
Những sai lầm lặp lại:
Các cửa sau là khó phát hiện nhất. Bạn có thể chặn nhân viên xem màn hình hợp đồng, nhưng vẫn gửi cho họ PDF như tệp đính kèm. Hoặc bố cục di động có thể hiển thị trường thừa đã bị ẩn trên desktop.
Một sửa chữa thực tế là coi xuất và tải về là quyền riêng, không phải quyền “xem” bình thường. Nếu một vai trò cần danh sách, cho họ một chế độ xem lọc thay vì xuất toàn bộ.
Trước khi mời người dùng thật, giả sử ai đó sẽ bấm nhầm, chia sẻ màn hình hoặc tải file họ không nên có. Một vài kiểm tra lúc này có thể tránh dọn dẹp đau đầu sau.
Bắt đầu với mặc định. Khi tạo người dùng mới, họ nên nằm ở vai trò thấp nhất tự động, không có quyền với tiền, xuất hay cài đặt admin. Nếu ai đó cần hơn, đó phải là thay đổi có chủ ý.
Tiếp theo, kiểm tra trải nghiệm khách như người lạ. Khách chỉ nên thấy bản ghi của họ, ngay cả khi họ đổi URL, tìm kiếm hoặc lọc. Một kiểm tra nhanh là đăng nhập bằng Khách A và thử tìm Khách B bằng tên, số hóa đơn hoặc ID ticket.
Năm kiểm tra nhanh bắt được phần lớn rò rỉ:
Làm bài test “vô tình.” Yêu cầu đồng đội hoàn thành một tác vụ thực bằng tài khoản nhân viên, rồi thử cùng tác vụ bằng tài khoản khách. Nếu khách thấy giá nội bộ, tải danh sách khách đầy đủ hoặc kích hoạt hoàn tiền, quyền của bạn quá rộng.
Một yêu cầu phổ biến bắt đầu như sau: khách muốn một cổng để “kiểm tra trạng thái,” nhưng nhân viên của bạn đã dùng cùng hệ thống để điều hành công việc. Nếu không có vai trò và quyền rõ ràng, cổng có thể phơi bày ghi chú nội bộ, đơn hàng của khách khác hoặc giá chỉ dành cho nhân viên.
Hãy tưởng tượng một công ty in ấn tùy chỉnh. Một đơn đi từ báo giá đến sản xuất, giao hàng và hóa đơn, tất cả trong một app.
Đây là những gì mỗi vai trò nên thấy trong luồng đó:
Hai trường hợp biên thường phá vỡ mô hình.
Đầu tiên, một quản lý tạm thời cover đội khác. Đừng chuyển họ thành Chủ sở hữu. Thay vào đó, thêm một phạm vi giới hạn theo thời gian, ví dụ truy cập đơn Team B trong 7 ngày. Khi cover kết thúc, quyền hết hạn.
Thứ hai, một khách VIP yêu cầu “xem nhiều hơn.” Cho họ thêm ngữ cảnh mà không cho thêm dữ liệu. Hiển thị timeline mở rộng hoặc luồng tin nhắn riêng, nhưng giữ ghi chú nội bộ (như “khách chậm thanh toán” hoặc “in lại do lỗi của chúng tôi”) chỉ cho nhân viên.
Trách nhiệm thay đổi, nên coi truy cập như thứ cần xem xét định kỳ, không phải đặt xong bỏ đó. Khi ai đó đổi vai trò, tránh tích dồn quyền. Bỏ quyền không cần nữa, rồi thêm ít nhất quyền cần thiết cho công việc mới.
Bắt đầu nhỏ. Chọn một luồng quan trọng nhất, như “tạo hóa đơn và nhận thanh toán” hoặc “ghi ticket hỗ trợ và trả lời.” Định nghĩa vai trò và quyền cho luồng đó trước, rồi mở rộng.
Ghi quy tắc vào một bảng đơn giản và coi nó như tài liệu sống: vai trò, họ có thể làm gì, họ không thể làm gì, và bất kỳ giới hạn nào (như “chỉ bản ghi của họ” hoặc “chỉ địa điểm của họ”). Khi ai đó hỏi “Nhân viên có thấy số điện thoại khách không?”, bảng đó phải trả lời trong giây lát.
Một triển khai thực tế:
Nếu bạn xây dựng trên AppMaster (appmaster.io), sẽ giúp nếu lập kế hoạch vai trò cùng lúc với mô hình dữ liệu và logic nghiệp vụ để cùng quy tắc áp dụng nhất quán trên web app, mobile app và các endpoint API.
Nếu bạn muốn, hãy viết bảng truy cập đầu tiên ngay hôm nay và thử nó cho một luồng. Bước đơn giản đó ngăn hầu hết các rò rỉ dữ liệu vô tình.
What’s the simplest way to start defining roles and permissions?Bắt đầu bằng việc liệt kê dữ liệu bạn lưu (khách hàng, đơn hàng, hóa đơn, ghi chú nội bộ, tệp), rồi quyết định ai nên xem, tạo, chỉnh sửa, xóa, phê duyệt và xuất từng loại. Bắt đầu với quyền thấp nhất và chỉ thêm những quyền cần thiết cho công việc hàng ngày.
What’s the difference between permissions and scope?Quyền xác định những hành động ai có thể làm, còn phạm vi (scope) xác định những bản ghi hành động đó áp dụng. Ví dụ, một nhân viên có thể được phép xem hóa đơn, nhưng chỉ những hóa đơn được phân công cho họ hoặc liên quan đến địa điểm của họ.
Do I really need four roles (Owner, Manager, Staff, Client)?“Chủ sở hữu, Quản lý, Nhân viên, Khách hàng” phù hợp với hầu hết doanh nghiệp nhỏ vì nó phản ánh cách phân chia công việc và rủi ro. Nếu đội bạn phức tạp hơn, giữ cấu trúc này và thêm vài vai trò chuyên dụng (ví dụ Finance hoặc Contractor) thay vì biến mọi người thành admin.
What should clients be able to see in a client portal?Mặc định an toàn: khách hàng chỉ xem và thao tác trên bản ghi của họ, nhưng không thấy ghi chú nội bộ, trạng thái nội bộ, biên độ lợi nhuận hay tag chỉ dành cho nhân viên. Nếu khách hàng muốn thấy nhiều hơn, cung cấp thêm ngữ cảnh trạng thái (ví dụ timeline) chứ không phơi bày thêm trường dữ liệu nhạy cảm.
How do I stop staff from seeing margin or sensitive pricing details?Tách "cần biết để thu phí" và "tại sao giá như vậy." Nhân viên thường cần các dòng mục hóa đơn và trạng thái, nhưng không nên thấy biên độ lợi nhuận, chi phí nhà cung cấp, lịch sử chiết khấu hay quyền điều khiển thanh toán như đánh dấu đã thanh toán.
Why are exports and bulk downloads such a big permission risk?Xem xuất khẩu là quyền rủi ro cao hơn, không phải là quyền mặc định khi xem danh sách. Nhiều rò rỉ vô tình xảy ra khi ai đó tải toàn bộ danh sách khách hàng hoặc lịch sử hóa đơn ra bảng tính mà không nhận ra nội dung nhạy cảm bên trong.
Why isn’t “restrict the screen” enough to prevent data leaks?Màn hình chỉ là một nơi dữ liệu xuất hiện; nó còn có thể hiện trong kết quả tìm kiếm, thông báo, PDF, bố cục di động, tệp đính kèm và phản hồi API. Nguyên tắc tốt là bảo vệ tầng dữ liệu và khả năng hiển thị trường trước, rồi xây màn hình dựa trên đó.
How should I handle permissions for files and attachments?Để file đính kèm theo những quy tắc riêng vì chúng thường chứa thông tin nhạy cảm hơn trường trên form. Quyết định ai được tải lên, xem trước và tải xuống file, và liệu quyền truy cập file có kế thừa từ bản ghi cha (ví dụ hóa đơn) hay cần quyền riêng.
How do I prevent customers from seeing internal notes in a support desk?Xây hai chế độ xem cho cùng một ticket: chế độ an toàn cho khách hàng không có ghi chú nội bộ, tag hay số liệu nhân viên, và chế độ nội bộ có đầy đủ ngữ cảnh. Cũng chỉ hiển thị các trường khách hàng nhạy cảm khi quy trình yêu cầu, để nhân viên không thấy địa chỉ hay ID trên mọi ticket.
What are quick permission tests I should run before inviting real users?Tạo tài khoản demo cho từng vai trò và chạy các tác vụ thực tế từ đầu đến cuối, bao gồm các trường hợp biên như tìm kiếm, lọc, mở tệp đính kèm và tạo tài liệu. Thử luôn tình huống “Khách hàng A cố gắng tìm Khách hàng B” bằng tên, ID và URL để xác nhận phạm vi được thực thi ở mọi nơi.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
