Skip to main content
Style:
Size:

Part 2: Human Workloads (The Meatbags)

Chapter 3: Onboarding, Offboarding, and the Chaos In Between

If you want to know how strong a company’s actual security posture is, do not ask to see their firewall rules. Ask to see what happens on an employee's first day (Joiner), when they change roles (Mover), and their last day (Leaver).

Human identities are fundamentally messy. Humans get promoted, transfer departments, go on sabbatical, and occasionally quit in a blaze of glory. In the IAM world, this lifecycle is called JML: Joiner, Mover, Leaver. When this administrative and technical process breaks down, your multi-million-dollar network security architecture falls apart from the inside out.


1. The Joiner Phase (Day 1 Delays & Authorization Models)

We have all experienced a bad Joiner process. You show up on Monday morning, eager to work, and by Thursday afternoon you still do not have access to your email, the VPN, cloud accounts, or the code repository.

Why does this happen? Because HR and IT speak two entirely different languages. HR knows you as "Employee #4592, Senior Marketing Strategist." The Network and Cloud teams only know that a specific identity is trying to access an S3 bucket or internal database on Port 5432, and they need to evaluate if it is allowed.

  • Process (The Goal): Automated provisioning. When HR enters a new hire into an authoritative HRIS (like Workday, BambooHR, or SuccessFactors), it should trigger an automated workflow via SCIM (System for Cross-domain Identity Management) to create the cloud identity, assign base group memberships, and provision necessary SaaS applications.
  • Technology (The Bridge): Identity Governance and Administration (IGA) platforms translate HR attributes into fine-grained permissions.
  • Control (Beyond Basic RBAC): To provision access safely, organizations historically relied on Role-Based Access Control (RBAC). While RBAC works for coarse baseline access (e.g., "All Marketers get Slack"), relying solely on RBAC in complex cloud and AI environments inevitably leads to Role Explosion—where an organization ends up with more roles than employees.

Modern Authorization: Moving Beyond Static RBAC

Modern IAM architectures layer dynamic authorization models over RBAC:

  • ABAC (Attribute-Based Access Control): Evaluates real-time attributes of the subject (department, clearance level), resource (classification), and environment (time, IP risk, device health).
  • ReBAC (Relationship-Based Access Control): Pioneered by Google's Zanzibar model, ReBAC models permissions as a graph of relationships (e.g., "Alice can edit document X because Alice is a member of Team Y which owns Project Z"). This is foundational for collaborative cloud platforms and RAG knowledge bases.
  • PBAC (Policy-Based Access Control): Expresses access logic as declarative code (e.g., Rego in Open Policy Agent, AWS Cedar), decoupling policy definitions from application logic.

Interactive Simulator: Role-Based Access Control (RBAC) Builder

Test how assigning roles dynamically updates effective permissions and triggers Separation of Duties (SoD) warnings:

RBAC Matrix Simulator

Assign roles to test identity privileges and detect toxic Separation of Duties (SoD) violations.

Role Assignment

Select roles assigned to user 'Bob':

Effective Permissions (3)
Corporate Email
Granted via: Standard Employee
Read/WriteLow
Intranet Portal
Granted via: Standard Employee
Read OnlyLow
Basic VPN
Granted via: Standard Employee
AllowedMedium

2. The Mover Phase (The Danger of "Privilege Creep")

This is, without a doubt, one of the most persistent attack vectors in enterprise security.

Imagine Bob is hired as a Junior Developer. Two years later, he transfers to IT Support. Two years after that, he is promoted to Network Administrator.

In a broken JML process, when Bob moves to a new department, IT simply adds his new permissions without removing his old ones. Over six years, Bob accumulates the keys to the entire kingdom. He can write production code, approve his own IT tickets, and change the core firewall routing rules. This phenomenon is called Privilege Creep.

  • Impact: If Bob's account is compromised, the attacker doesn't just get a Network Admin account; they get an over-privileged hybrid identity spanning three departments.
  • Control (Continuous Certification): Rather than relying on sluggish annual audits, modern security implements Continuous Review (Continuous Certification).
  • Process (Event-Triggered Attestation): The exact moment HR records a department, title, or reporting line change, an event-driven certification workflow is triggered. Bob's previous access is flagged for immediate revocation unless explicitly re-justified by his new manager within a strict SLA.

3. The Leaver Phase (The Orphaned Account Problem)

When someone resigns or is terminated, HR knows immediately. But if IAM offboarding is manual, disconnected, or incomplete, the network remains exposed for weeks or months.

An active account belonging to someone who no longer works at the company is an Orphaned Account. Because the former employee is gone, nobody is monitoring it for anomalous logins or credential reuse.

The Modern Offboarding Checklist: Beyond Passwords

Killing an Active Directory account and VPN access is only the first step. True Zero Trust offboarding requires comprehensive revocation:

  1. SCIM Deprovisioning: Automatically propagate deactivation calls across all integrated SaaS platforms (GitHub, Salesforce, AWS, Snowflake).
  2. Continuous Access Evaluation (CAEP / SSF): Push real-time session-revoked event tokens to active sessions, cutting off active stateless JWTs across cloud resource servers immediately.
  3. Orphaned OAuth App Revocation: Terminate all user-granted third-party OAuth app authorizations and offline refresh tokens.
  4. Non-Human Identity (NHI) Reclamation: Scan for and revoke any Personal Access Tokens (PATs), SSH keys, cloud IAM access keys, or API keys generated by the employee. Reassign sponsorship of any service accounts owned by the user.

Consultant's Corner: Solving the "Rubber Stamp" Problem

When implementing Access Reviews, you will immediately run into a human problem: managers are busy. If you send a department head a spreadsheet containing 5,000 rows of cryptic security groups, they will not read it. They will just click "Approve All," defeating the entire security control.

How to fix it: Elevate Context & UI/UX. Do not present raw technical strings. Your IAM tooling must translate permissions into business context:

  • Legacy: "Approve membership for AD_GRP_FIN_772_RW?"
  • Modern: "Approve Write Access to Q3 Executive Financial Forecasts for Alice (Last used: 84 days ago)?"

By combining business context, last-active timestamps, and automated anomaly suggestions, managers can make informed decisions in seconds.


💡 Scenario & Solution: The Offboarded Developer's Ghost API Key & Third-Party OAuth App

The Scenario: A senior backend engineer is terminated. IT promptly disables their Google Workspace and Microsoft Entra ID accounts. Three weeks later, proprietary customer database records appear for sale on a dark web forum. Forensics reveal the ex-employee used two vectors:

  1. A personal OAuth application ("Workflow Productivity Booster") that the engineer had authorized via Google Sign-In six months prior, which had offline drive.readonly refresh tokens.
  2. A long-lived Personal Access Token (PAT) with full repository write privileges created in GitHub Enterprise tied to the engineer's personal machine.

Why It Happened: The offboarding process only disabled the central IdP password and SSO. It completely overlooked user-delegated OAuth grants and personal non-human machine credentials.

The Architecture Solution:

  1. Centralized OAuth App Governance: Implement IdP policies requiring Admin Consent for third-party OAuth apps, blocking individual users from granting broad offline scopes.
  2. Automated Token Reclamation on Leaver Event: Configure the JML pipeline to trigger automated API calls to SaaS providers (GitHub, GitLab, AWS IAM) to invalidate all PATs, API keys, and active sessions owned by the terminated employee's principal ID.
  3. NHI Inventory & Sponsorship Tracking: Ensure all machine credentials are registered in an Identity Governance database with automated lifecycle links to the human sponsor.