A county clerk’s office grants application rights user-by-user instead of by job function for clerks versus auditors. Which identity strategy should replace that practice?
Select an answer to reveal the explanation.
Short Explanation
Hand-crafting every clerk’s permissions is like cutting a new house key for each shift—messy and error-prone. Put people in clerk and auditor roles (or groups) and hang the rights on the role. Forever one-offs, shared god-rights, or “just sit at that desk” do not scale and invite mistakes.
Full Explanation
Identification and authorization design for municipal applications should map job functions to reusable groups or roles rather than handcrafting rights user by user. Define clerk and auditor roles (or directory groups) that carry the permissions those duties require, then assign people to roles. Role-based packaging improves consistency, least privilege, access reviews, and joiner–mover–leaver revocation compared with ad-hoc per-user grants that drift and hide privilege accumulation.
Continuing unique one-off permissions forever does not scale, complicates audits, and almost guarantees entitlement errors when staff change desks. Assigning all clerks and auditors the same unrestricted domain-admin-equivalent inside the app collapses separation of duties and over-privileges routine work. Disabling authorization checks and relying on informal desk assignments removes technical enforcement and assumes physical presence equals entitlement—false in shared offices and remote work.
Exam caveat: RBAC/group-based authorization is the scalable IAM pattern CISSP contrasts with discretionary one-offs and privilege sprawl. Operational check: invent clerk vs auditor roles with least-privilege permission sets, migrate users off one-off grants, review role membership regularly, and keep authorization checks enforced in the application.