3.4Access Management and Authorization (Least Privilege, RBAC, Privileged Account Management, Log Management)

The phrase "access management" is often used loosely, but in practice the starting point is distinguishing three separate stages: identification, authentication, and authorization. "Who do you claim to be" (identification), "are you really that person" (authentication), and "what is that person allowed to do" (authorization) are each realized by different mechanisms — and critically, even if authentication is defeated, the design of authorization can still limit the damage. This section organizes access-management controls around these three stages: how permissions are narrowed, and how visibility is kept appropriately limited.

3.4.1Identification, authentication, and authorization

• Identification is the step where a user claims "who they are" (e.g. entering a user ID). Authentication is the step of confirming that the claimant "really is that person" (e.g. verification via password, biometrics, or multi-factor authentication). Identification is a claim; authentication is proof — that is the distinction.
• Authorization is the step of deciding "what, and how far," an already-authenticated user is permitted to do (e.g. allowing read access to a file but not write access). Even after authentication succeeds, the scope of what can actually be accessed is limited by authorization settings. These three stages form a sequence, but the key point is that each should be designed and audited independently.
• A concrete example: entering an employee ID number is identification; verifying that person via a fingerprint is authentication; and being granted read-only (not approval) access to the accounting system, because the account holds an accounting-department role, is authorization. This connects to a layered mindset: even if authentication is defeated, a properly narrowed authorization scope can still limit the damage.

3.4.2Least privilege, RBAC, privileged account management, account lifecycle, and log management

• The principle of least privilege grants a user only the minimum permissions needed to do their job. The need-to-know principle goes further: access is limited not just by whether a permission exists, but by whether that information is actually needed for the person's work (even with a permission, information is withheld if it is not job-relevant). It is important to recognize that "granting broad access just in case" operationally increases risk.
• RBAC (Role-Based Access Control) manages permissions indirectly by assigning permissions to a "role" rather than to an individual user, and placing users into that role. On a transfer or resignation, you only need to change or remove the role assignment — there is no need to inventory each individual permission one by one — giving both consistency and operational efficiency.
• A privileged account (administrator account) has powerful capabilities, such as changing system settings or manipulating other users' accounts. Because the damage from misuse is severe compared with an ordinary user account, strict controls (privileged account management) are essential: requiring per-use request and approval rather than standing access, strictly logging usage per individual, and never sharing a single account among multiple people.
• The account lifecycle is the process of granting access at onboarding, reviewing it at a role change, and disabling/deleting it at leave or resignation. In particular, a delay in disabling a departed employee's account becomes fertile ground for unauthorized access, so prompt reconciliation tied to HR data is important. Log management and monitoring preserve authentication/authorization records (who accessed what, and when) in a form resistant to tampering, and support after-the-fact traceability and early fraud detection through periodic review and anomaly detection (e.g. access at an unusual time of day).

Trace an insider-misuse incident at a company to see the design philosophy behind access management. It emerged that a former employee's account had remained enabled for over a month after resignation, due to a gap in the link to the HR system. While employed, this person belonged to the accounting department and had access to the accounting system; after leaving, they used the account's identifier (user ID) and password to pass authentication and log into the accounting system without authorization. However, investigation found the actual damage was limited. The reason: under RBAC, this account was assigned the role of "accounting department — general staff," and that role's authorization was designed to allow only viewing accounting data, not powerful operations like approvals or fund transfers. Critical operations such as approval authority or moving funds were only possible through a separate class of account equivalent to a privileged account, and that privileged account required per-use request and approval from a supervisor — so the departed employee's account could not perform them. Following this incident, the company adopted two remediation measures. First, it tightened the account lifecycle, linking account deactivation to the HR system's resignation process so that all accounts are automatically disabled on the effective date of resignation. Second, it strengthened log management and monitoring, introducing a system that automatically detects and alerts on anomalous access patterns, such as logins outside normal business hours or on holidays, enabling earlier detection of unauthorized logins like this one. As this case shows, the essence of access management in practice is to not rely on authentication (identity verification) alone, but to narrow authorization to the minimum needed for each role, and layer that with a disciplined account lifecycle and log monitoring.

3.4.3Section summary

• Identification = claiming who you are; authentication = proving it; authorization = deciding the permitted scope. Design and audit each independently
• Narrow access via least privilege and need-to-know. RBAC assigns permissions to a role and places users in that role
• Privileged accounts require per-use request and per-individual logging. Disable departed employees' accounts promptly, and detect anomalies early via log monitoring