Hard2bit
← Back to glossary Identity and access

Authorization

What is authorization

Authorization is the process of determining what actions an authenticated user, application or device can perform. It differs from authentication (who you are) but complements it: it defines granular permissions (what data you see, what systems you modify, what operations you execute). Implementation requires control models such as RBAC (role-based), ABAC (attribute-based), or ACL (access control lists). Weak authorization enables privilege escalation, sensitive data access and lateral movement post-compromise.

Why it matters

Correct authorization is a critical defensive line against excessive privileges: if a user is compromised, limited permissions contain damage. The least-privilege principle is the foundation of Zero Trust, network segmentation, and access control. Authorization audits frequently reveal: users with admin roles who do not need them, service accounts with excessive access, inherited permissions after job changes that were never revoked. Regulations mandate: ISO 27001 requires segregation of duties (SoD); NIS2 requires periodic access reviews to critical information; DORA requires governance of critical third-party cloud services. CISOs must automate permission audits, implement segregation of duties, and use contextual authorization (location, device, risk).

Key points

RBAC (Role-Based Access Control): users assigned to roles with predefined permissions. Simple but inflexible: if roles do not reflect actual responsibilities, it causes chaos or excessive permissions.

ABAC (Attribute-Based Access Control): access based on attributes (department, risk level, time of day, location). More granular and flexible; requires greater management complexity.

Least-privilege principle: users have only permissions absolutely necessary for their function. Requires discipline: review and revoke inherited permissions, quarterly audits, segregation of duties (SoD).

Temporary access: credentials with expiration, short-lived tokens, elevated access only when needed (just-in-time). Reduces exposure window if credential is compromised.

Example: Privilege escalation from weak authorization

An IT support employee has admin role across entire infrastructure inherited from previous position. Although their current role is only user support, admin access was never revoked. When the account is compromised by phishing, the attacker escalates to domain admin, creates permanent backdoor, and accesses customer SQL database. Later audit reveals 40% of employees have excessive permissions for their position. Solution: implement RBAC with specific roles (support=password reset only; dev=dev database access; admin=specific machines not all). Use Privileged Access Management (PAM) to elevate privileges only when necessary and log to audit. Review access quarterly and revoke unnecessary permissions.

Common mistakes

  • Assuming a compromised user can only cause damage with their current privilege level; if the user has access to admin tools or configurations, they can escalate.
  • Not segregating duties: same user who creates users in AD, can assign credentials, and access data. Three people must perform these steps to prevent fraud.
  • Inherited permissions: when an employee changes roles, they frequently retain old accumulated permissions. Annual audit is insufficient; it must be continuous and automatic.

Related services

This concept may be related to services such as:

Frequently asked questions

What is the difference between RBAC and ABAC

RBAC: user has a role (admin, editor, viewer) with fixed permissions. Simple but inflexible: it does not distinguish if access is from the office or from China at 3am. ABAC: access based on attributes like location, time, device, risk level. More secure but complex to manage: requires a policy-based decision engine.

Why is segregation of duties (SoD) important

It prevents fraud and errors: the same user who creates payments must not approve them; the same user who creates users must not modify logs. At minimum two people must perform critical transactions. ISO 27001 requires it; DORA requires it for critical financial services.

How do you audit authorization in a large enterprise

Use Identity Governance tools: access reports by user/role, access certification analysis (managers confirm employees should have their permissions), automatic SoD conflict detection. SIEM must alert on anomalous access (user accesses resource unusual for their role).