Phân quyền người dùng sao cho đúng việc?
Một nhân viên xuất được toàn bộ danh sách khách hàng là dấu hiệu quyền có thể quá rộng. Nhưng quyền quá hẹp cũng gây khó: người xử lý không mở được hồ sơ hoặc quản lý nghỉ phép làm đề nghị nằm chờ. Mục tiêu của phân quyền là cho người dùng làm đúng phần việc được giao và chặn những thao tác không được phép.
Đăng nhập và phân quyền là hai việc khác nhau. Đăng nhập xác nhận người đang dùng tài khoản; phân quyền quyết định người đó được xem dữ liệu nào và thực hiện việc gì. Bài viết dùng quy trình chi phí giả định gồm người đề nghị, quản lý và kế toán; doanh nghiệp phải xác nhận chính sách thực tế, không áp dụng nguyên ví dụ làm quy định nội bộ.
1. Xác định người dùng, thao tác và phạm vi dữ liệu
Bắt đầu từ hành động cụ thể: xem, tạo, sửa, gửi, duyệt, xóa hoặc xuất dữ liệu. Chỉ ghi “quyền nhân viên” hay “quyền trưởng nhóm” sẽ bỏ ngỏ nhiều khác biệt. Một trưởng nhóm có thể cần duyệt hồ sơ được giao nhưng không được xem mọi hồ sơ của công ty; một kế toán có thể cần số tiền mà không cần toàn bộ thông tin nhân sự.
Sau thao tác là phạm vi: hồ sơ của bản thân, nhóm, chi nhánh hay toàn doanh nghiệp. Trong ví dụ, người đề nghị xem đề nghị của mình; người quản lý xem phần thuộc trách nhiệm duyệt; kế toán tiếp nhận phạm vi được giao. Cần ghi cả các giới hạn như không tự duyệt đề nghị của mình, nếu doanh nghiệp chọn quy tắc đó.
Các quyền gần nhau vẫn cần tách rõ. Được xem một hồ sơ không có nghĩa được tải mọi tệp hay xuất hàng nghìn dòng để giữ ngoài hệ thống. Hãy hỏi dữ liệu sau khi xuất sẽ được dùng để làm gì và ai cần chức năng đó. Không nên cấp thêm quyền chỉ vì đó là cách nhanh nhất để giải quyết một yêu cầu hỗ trợ.
Những giới hạn này phải được mô tả bằng tình huống và người xác nhận, để đội phát triển không tự đặt chính sách thay doanh nghiệp. Bài Phân tích yêu cầu là gì? Bước đầu để phát triển đúng hướng hướng dẫn cách chuyển nhu cầu công việc thành yêu cầu có thể kiểm tra.
Một dòng mô tả quyền rõ có thể viết: “Kế toán được xem và ghi nhận thanh toán cho đề nghị đã duyệt thuộc đơn vị được giao; không được sửa người nhận tiền sau khi thanh toán.” Câu này gom vai trò, hành động, dữ liệu và điều kiện vào cùng một chỗ. Đây chỉ là ví dụ để các bên xác nhận, không phải quy tắc tài chính áp dụng sẵn.
2. Quy định quyền khi hồ sơ đổi trạng thái
Một người có thể được sửa đề nghị khi còn nháp nhưng không được sửa trực tiếp sau khi đã duyệt hoặc thanh toán. Vì vậy, quyền cần đi cùng trạng thái và cách xử lý tiếp theo. Nếu hồ sơ bị trả lại, hãy xác định phần nào được sửa, ai gửi lại và người duyệt có biết thông tin đã thay đổi không.
Nếu cần sửa dữ liệu đã được xác nhận, nên có đường xử lý được doanh nghiệp chấp thuận, chẳng hạn trả lại hoặc tạo điều chỉnh có lưu lịch sử. Không nên giải quyết bằng cách mở quyền quản trị cho mọi người. Người dùng cần biết kết quả cũ được giữ thế nào và ai có quyền xác nhận thay đổi để truy lại được quyết định.
3. Chuẩn bị cho ủy quyền và thay đổi nhân sự
Ủy quyền khi quản lý nghỉ phép phải có phạm vi và thời hạn, không phải chia sẻ tài khoản của người quản lý. Cần biết người thay có thể duyệt hồ sơ nào, có bị giới hạn với đề nghị của chính mình không và hết thời gian thì quyền được kết thúc thế nào. Lịch sử cần phân biệt người thực sự thao tác với người đã giao quyền.
Khi chuyển bộ phận hoặc nghỉ việc, phải rà quyền cũ cùng công việc còn dở. Hồ sơ đang chờ cần người nhận mới; báo cáo hoặc kết nối đứng tên cá nhân cũng phải được xử lý. Thu hồi tài khoản mà không chuyển việc có thể làm quy trình ngừng chạy, còn chỉ chuyển việc nhưng giữ quyền cũ có thể để lại truy cập không cần thiết.
Nhân sự kiêm nhiệm không nên tự động nhận toàn bộ quyền của mọi vai trò rồi bỏ qua các giới hạn. Nếu quy mô nhỏ khiến một người làm nhiều việc, doanh nghiệp cần xác định cách kiểm tra hoặc phê duyệt khác phù hợp. Phần mềm phải phản ánh cách kiểm soát đã được thống nhất, không tự giải quyết bằng một mẫu vai trò chung.
Khi đổi người hoặc đơn vị vận hành, danh sách quyền phải được chuyển giao cùng trách nhiệm và việc còn mở. Bài Bàn giao phần mềm sao cho đội mới tiếp quản được? giúp xác nhận đội nhận có đủ thông tin và khả năng tiếp quản, thay vì chỉ nhận một danh sách tài khoản.
Những yêu cầu cấp quyền khẩn cũng cần người chấp thuận và thời điểm xem lại. Nếu phải cấp tạm để xử lý một sự cố, ghi rõ mục đích, phạm vi và người theo dõi việc kết thúc quyền. Một quyền tạm được dùng thuận tiện không nên tự trở thành quyền thường xuyên mà người phụ trách không biết.
4. Kiểm tra giới hạn và duy trì quyền phù hợp
Bộ kiểm tra cần có cả thao tác được phép và bị từ chối, bằng tài khoản đại diện từng vai trò. Người được giao phải mở được hồ sơ của mình nhưng không mở được hồ sơ ngoài phạm vi, kể cả khi có đường dẫn trực tiếp. Nút bị ẩn trên màn hình chưa chứng minh các đường truy cập phía sau đều đã kiểm soát.
Thử lại sau khi đổi trạng thái, hết thời gian ủy quyền hoặc chuyển nhân sự. Đồng thời xem người không có quyền có nhận thông tin qua xuất báo cáo, thông báo hoặc tệp đính kèm không. Thử nghiệm phải trong phạm vi được cho phép và với dữ liệu phù hợp; không dùng hồ sơ thật của người khác để kiểm tra tùy tiện.
Các tình huống này nên trở thành phần kiểm tra khi nhận phần mềm hoặc thay đổi quy trình. Bài Nghiệm thu phần mềm: Doanh nghiệp cần kiểm tra gì? giúp chuẩn bị dữ liệu, kết quả mong đợi và cách ghi nhận khi một giới hạn chưa hoạt động đúng.
Sau triển khai, cần người duyệt việc cấp thêm quyền và lịch xem lại phù hợp với doanh nghiệp. Dấu vết sử dụng nên hỗ trợ truy lại người thao tác và sự thay đổi, nhưng không tự chứng minh quyết định đó hợp lệ. Khi trao đổi với Fenix, hãy bắt đầu từ một quy trình thực tế và các vai trò tham gia để xác định quyền cần thiết trước khi cấu hình.
Nếu người dùng liên tục phải nhờ người khác thao tác hộ, hãy xem lại quy trình và quyền được cấp thay vì chỉ nhắc họ tuân thủ. Có thể giới hạn đang đặt sai phạm vi hoặc bước thay thế chưa rõ. Cách sửa cần được người nghiệp vụ và kỹ thuật xác nhận, rồi thử lại cả việc được làm lẫn việc phải chặn để không đổi một vướng mắc thành rủi ro mới.
