Identity and access management, least privilege and RBAC

Why identity is the new perimeter

Years ago, companies protected a "castle" network with a firewall around it. Today staff work from home, apps live in the cloud and partners log in from outside. The thing that decides whether someone gets in is their identity: their account and what it is allowed to do. Many breaches start with a stolen account, not a broken firewall.

Four steps: identify, authenticate, authorise, account

People often mix up authentication (proving identity) and authorisation (permissions). A useful memory trick: authentication is the gate guard checking your ID card; authorisation is which floors your card opens.

Least privilege

Least privilege means every person, program and service account gets the minimum access needed to do its job, and no more. If an account is stolen or misused, the damage is limited to what that account could do.

• A support agent can view orders but not issue refunds over ₹5,000.
• A backup program can read files but not delete them.
• An intern gets read-only access to the test database, not production.
• Admin rights are given just-in-time for a task and removed after (sometimes called privileged access management, PAM).

Role-based access control (RBAC)

Giving permissions person by person becomes a mess in a company of 500. RBAC groups permissions into roles that match jobs, like "cashier", "branch manager" or "auditor". People are given roles; roles carry permissions. When someone changes job, you change their role, and their permissions follow.

ROLES = {
    "cashier": {"view_account", "deposit", "withdraw"},
    "manager": {"view_account", "deposit", "withdraw", "approve_loan"},
    "auditor": {"view_account", "view_logs"},
}
USERS = {"asha": ["cashier"], "vikram": ["manager"], "neha": ["auditor"]}

def can(user, action):
    return any(action in ROLES[role] for role in USERS.get(user, []))

print(can("asha", "withdraw"), can("asha", "approve_loan"), can("neha", "view_logs"))

Other models exist. Attribute-based access control (ABAC) uses attributes such as department, location or time of day ("finance staff, from office network, on working days"). Many real systems combine RBAC with a few ABAC rules.

The joiner, mover, leaver process

• Joiner: a new employee gets accounts and roles on day one, approved by their manager.
• Mover: someone changes team; old access is removed when new access is added. If not, they collect more and more access over the years (privilege creep).
• Leaver: all access is disabled on the last day. Ex-employees with live accounts are a classic incident.

Regular access reviews, for example every quarter, ask managers to confirm that each person still needs each access.

Single sign-on and federation

Single sign-on (SSO) lets people log in once to an identity provider (such as Microsoft Entra ID, Okta or Google Workspace) and then use many apps. Standards like SAML and OpenID Connect carry the proof of login to each app. SSO means one place to enforce MFA and one switch to turn off a leaver.

Common mistakes

• Shared accounts ("finance@company" used by six people). Nobody is accountable. Give each person an account.
• Service accounts with domain admin rights and passwords that never change.
• Granting "temporary" admin access and never removing it.
• Checking permissions only in the app's menus, not on the server.