5.2Access management & privileged access

Running a service safely rests on properly controlling "who can access which systems, and to what extent." Handing out too many privileges enlarges the damage from insider misuse and incidents, while being too restrictive halts work and harms the SLA. Moreover, if granted privileges are left unattended, leaver and transferee accounts persist and become a breeding ground for misuse. This section covers the principle of least privilege, the lifecycle of granting privileges (provisioning) and periodically reviewing them (recertification), privileged access management for especially powerful rights, and the authentication that verifies identity-framed as an operator's judgment.

5.2.1Least privilege and the access-rights lifecycle

• Least privilege grants each user and each service only the minimum privileges needed to do their job. Excessive privileges needlessly widen the blast radius of insider misuse, mistaken operations, and account takeover. Role-based access control (RBAC), which assigns privileges in bulk by role, is a representative method that makes least privilege easier to operate.
• Access rights have a lifecycle. Provisioning (granting) means granting the needed privileges, with approval, upon joining, transfer, or project onboarding. Recertification (access review) means periodically re-examining "whether that privilege is still truly needed" and revoking those no longer required (for leavers, transferees, ended projects). Neglecting prompt revocation (deprovisioning) on departure or transfer turns dangling accounts into a serious risk.

5.2.2Privileged access management and authentication

• Privileged access management (PAM) is the operation of managing powerful rights-administrator privileges such as root/Administrator-strictly and separately from ordinary user IDs. Controls such as granting only temporarily when needed (just-in-time) rather than permanently, requiring approval to check out, recording operation logs/session recording for an audit trail, and using them in an individually attributable form rather than shared prevent misuse and untraceability of powerful rights.
• Authentication verifies "that you are who you claim to be" before allowing access. Multi-factor authentication (MFA), combining factors such as knowledge (password), possession (a token/phone), and biometrics, makes a compromise hard to break through on a leaked password alone. Requiring MFA is standard for privileged IDs and internet-facing authentication. It also matters operationally that authentication (verifying identity) and authorization (access rights), which decides what that identity is allowed, are distinct concepts.

Suppose an internal audit at a service operations organization finds that the ID of a former operator who transferred to another department six months ago is still active and still holds administrator privileges on the production database. Fortunately there is no sign of misuse, but this is a serious finding showing that recertification (periodic access review) and deprovisioning on transfer were not functioning. The service manager first revokes this ID's privileges immediately as an individual response, but that alone lets the same kind of neglect recur. So they decide to remediate the operational process itself. First, from a least privilege viewpoint, they reorganize each ID's privileges by role (RBAC) and trim broad privileges not needed for the job. Second, they build quarterly recertification into the operating procedure, so that for each privilege the privilege holder's manager approves "whether it is still needed," and any privilege not approved is automatically revoked. Third, they link HR transfer/departure information with access management so that deprovisioning runs promptly, triggered by a transfer or departure. Furthermore, they migrate powerful privileges-such as production-DB administrator rights-to privileged access management, where they are no longer granted permanently but checked out only for the needed task, with approval, and operations are recorded for an audit trail. What matters here is not to stop at the individual response of "delete the ID you noticed," but to treat the root cause of why the neglect happened (the absence of recertification and transfer linkage) in a problem-management manner and remediate it as a permanent operating process. The judgment required of a service manager is that access management is not set-and-forget but the very operation of continuously cycling grant, review, and revocation.

5.2.3Section summary

• Grant only the minimum needed via least privilege (RBAC, etc.) to narrow the blast radius of insider misuse and incidents
• Manage access rights over a lifecycle-continuously cycle provisioning (granting), periodic recertification (review), and prompt deprovisioning on transfer/departure
• Handle powerful rights such as administrator privileges via privileged access management, checking them out only when needed with approval and an audit trail, and use MFA for authentication (authentication and authorization are distinct)