Iam Specialist

IAM Specialist

When to Use

• Design workforce and machine identity lifecycle — joiner/mover/leaver, contractors, service principals
• Model RBAC, ABAC, or PBAC entitlements, roles, and permission sets with least privilege
• Run access reviews and recertification — campaigns, risk-based sampling, manager attestation
• Architect SSO federation — SAML, OIDC, SCIM provisioning, app onboarding patterns
• Implement privileged access — PAM vaulting, JIT elevation, session recording, break-glass policy
• Author cloud IAM roles, policies, permission boundaries, trust relationships (AWS/GCP/Azure)
• Govern service accounts and secrets — naming, rotation, no human keys, workload identity
• Define separation of duties matrices and toxic-combination detection
• Align IAM controls to audit and risk narratives (with GRC partners)

When NOT to Use

• Multi-BU landing zone, CCoE, EA, or executive cloud governance → enterprise-cloud-architect
• Org SCPs, CSPM, network segmentation, KMS program, detective controls → cloud-security-engineer
• Access ticket fulfillment, key rotation runbooks, patching, restores → cloud-system-administrator
• VPC/RDS/serverless build without IAM as primary deliverable → cloud-engineer
• SIEM/EDR deployment, WAF, broad security tooling → information-security-engineer
• SOC 2 evidence pipelines and automated control checks → compliance-engineer
• CI OIDC and pipeline scan gates only → devsecops
• Inherent/residual risk scoring and risk register → security-risk-analyst
• Authorized exploitation or pentest validation → penetration-tester
• Legal interpretation, employment policy, or contract redlines → commercial-counsel

Related skills

Core Workflows

1. Scope and governance model

Identity domains, RACI, and boundaries vs cloud security and ops.

See `references/iam_specialist_scope.md`.

2. Identity lifecycle and access governance

Joiner/mover/leaver, provisioning, reviews, and exceptions.

See `references/identity_lifecycle_and_governance.md`.

3. Entitlements and authorization models

RBAC/ABAC/PBAC design, role engineering, and SoD.

See `references/rbac_abac_and_entitlements.md`.

4. Federation and SSO protocols

SAML, OIDC, SCIM, and SaaS onboarding.

See `references/federation_sso_and_protocols.md`.

5. Privileged access and PAM

JIT, vaulting, break-glass, and session controls.

See `references/privileged_access_and_pam.md`.

6. Cloud IAM and least privilege

Cross-cloud IAM patterns, policy review, and machine identity.

See `references/cloud_iam_and_least_privilege.md`.

Outputs

• Entitlement catalog — roles, permissions, owners, review cadence
• Access review campaign — scope, attestations, remediation tracker
• Federation design — trust, claims, MFA, provisioning flow
• PAM policy — elevation paths, approval, monitoring, break-glass
• Cloud IAM policy set — least-privilege JSON with trust boundaries documented
• SoD matrix — incompatible duties, compensating controls, exceptions
• Service account standards — creation, rotation, audit queries

Principles

• Identity is the perimeter — authenticate strongly; authorize minimally
• No standing privilege — prefer JIT and time-bound elevation for admin
• Prove every grant — reviews, logs, and SoD checks on sensitive entitlements
• Humans ≠ machines — separate lifecycle, credentials, and audit trails
• Federation fails closed — misconfigured trust denies access; monitor sync errors
• Break-glass is rare, logged, and reviewed — not a daily admin shortcut

Cloud IAM and least privilege

Table of contents

1. Cross-cloud concepts 2. AWS IAM 3. GCP IAM 4. Azure RBAC 5. Machine identity and secrets 6. Policy review workflow

Cross-cloud concepts

Apply uniformly:

cloud-security-engineer owns org guardrails and CSPM; iam-specialist owns role/permission design and reviews.

AWS IAM

1. Human access — IAM Identity Center (SSO) to permission sets; no console IAM users 2. Roles — sts:AssumeRole with externalId for third parties; session tags for ABAC 3. Policies — prefer managed AWS job functions as baseline; trim with policy simulator 4. Permission boundaries — on all custom roles; prevent privilege escalation 5. Service control policies — deny root, restrict regions, require MFA for sensitive APIs 6. Access keys — ban on humans; rotate service keys; prefer IAM Roles Anywhere / IRSA

Review: iam:PassRole, *:*, kms:Grant, lambda:UpdateFunctionCode on broad principals.

GCP IAM

1. Hierarchy — org → folder → project; inherit deny policies carefully 2. Groups — Google Groups as principal; avoid user-specific bindings 3. Custom roles — minimal permission set; test with Policy Analyzer 4. Service accounts — one workload per SA; disable key creation org-wide if possible 5. Workload Identity Federation — GitHub/GitLab/CircleCI to GCP without keys 6. Privileged Access Manager — JIT for sensitive roles

Review: roles/owner, roles/editor, iam.serviceAccountKeys.create, setIamPolicy on folders.

Azure RBAC

1. Entra ID — PIM for privileged roles; conditional access for admins 2. Management groups — policy inheritance; deny assignments for guardrails 3. Custom roles — actions/notActions explicit; avoid broad * on data actions 4. Managed identities — system-assigned per workload where possible 5. Subscription RBAC — separate prod/non-prod; no standing Owner in prod 6. Key Vault — RBAC + purge protection; access via MI not users

Review: User Access Administrator, Role Based Access Control Administrator at root scope.

Machine identity and secrets

1. Inventory — all service accounts, API keys, SP secrets, certificates 2. Naming — svc-<app>-<env>-<purpose>; owner and expiry in tags 3. Rotation — automated where supported; max 90-day manual keys 4. Secrets stores — Vault, Secrets Manager, Key Vault — no secrets in repos 5. CI/CD — OIDC to cloud (devsecops for pipeline wiring) 6. Cross-cloud — federated identity over duplicated long-lived keys

Policy review workflow

For each new role or policy change:

1. Document intent — who, what resource, which actions, duration 2. Run simulator / analyzer — effective permissions on sample resources 3. Check SoD matrix and external exposure (public trust policies) 4. Peer review by security or platform 5. Deploy via IaC; tag with owner and ticket 6. Schedule recertification in next access review campaign

Export effective policy JSON and approval record for auditors.

Federation, SSO, and protocols

Table of contents

1. Protocol choice 2. SAML patterns 3. OIDC patterns 4. SCIM provisioning 5. SaaS onboarding checklist

Protocol choice

IdP as hub: workforce authenticates once; federate to apps; enforce MFA at IdP.

SAML patterns

1. Metadata exchange — sign and encrypt assertions per vendor matrix 2. NameID — stable identifier (email or employee ID); avoid display name 3. Attribute mapping — least claims; map groups to app roles explicitly 4. Audience and Recipient — validate strictly; reject unsolicited responses 5. Certificate rotation — dual metadata publish before expiry 6. Single logout — implement only if app supports; else document session limits

Test: IdP-initiated and SP-initiated flows; invalid signature must fail closed.

OIDC patterns

1. Authorization code + PKCE — required for public clients 2. Client types — confidential server apps vs public SPA/mobile 3. Scopes — openid profile email minimum; add API scopes narrowly 4. Token lifetimes — short access tokens; refresh rotation; revoke on logout 5. Claims — map groups via groups or custom claim with size limits 6. Multi-tenant SaaS — issuer per tenant; validate iss and aud

Integrate step-up MFA for sensitive apps via conditional access at IdP.

SCIM provisioning

1. Source — IdP or IAM tool pushes users/groups 2. Match key — userName / externalId stable across systems 3. Deactivate — map active: false to suspend; do not delete audit history 4. Group push — map entitlement roles to SCIM groups 5. Error handling — alert on sync failures; reconcile daily

Run joiner and leaver tests in sandbox before production cutover.

SaaS onboarding checklist

• [ ] SSO protocol (SAML/OIDC) and MFA requirement documented
• [ ] SCIM or manual provisioning with SLA
• [ ] Entitlement roles defined in catalog
• [ ] SoD rules evaluated for app permissions
• [ ] Admin roles limited; break-glass documented
• [ ] Audit logs exported (who accessed, admin actions)
• [ ] Offboarding tested — user cannot authenticate post-disable
• [ ] Data residency and subprocessors recorded for GRC

Hand off ongoing ticket-based access to operations runbooks where appropriate (cloud-system-administrator for cloud consoles only).

IAM specialist scope

Table of contents

1. Role boundary 2. Identity domains 3. RACI 4. Deliverables

Role boundary

Do not draft employment law, HR disciplinary policy, or provide legal attestations.

Identity domains

Cover explicitly in scope memos:

Document authoritative source of truth per domain (IdP, HRIS, cloud directory).

RACI

Deliverables

Minimum artifacts for a mature IAM program:

1. Identity governance charter (approved) 2. Entitlement catalog with owners and review cadence 3. Access review playbook and campaign templates 4. Federation standards (SAML/OIDC/SCIM) 5. PAM and break-glass policy 6. Cloud IAM baseline and exception register 7. SoD matrix for high-risk functions 8. Service account and secrets hygiene standard

Identity lifecycle and governance

Table of contents

1. Lifecycle events 2. Provisioning and deprovisioning 3. Access reviews 4. Exceptions and emergency access

Lifecycle events

Map every identity type to HR or authoritative triggers:

SLAs (example targets):

• Joiner productive access: ≤ 1 business day for standard roles
• Leaver disable: ≤ 4 hours for termination; ≤ 24 hours for voluntary notice end
• Privileged revoke on leave: immediate

Provisioning and deprovisioning

1. Source of truth — HRIS or contractor system drives workforce; CMDB or service catalog for apps 2. Birthright access — default groups by job code; no manual “copy user” as standard 3. Request-based access — catalog with approval, SoD check, time limit where needed 4. Provisioning transport — SCIM to SaaS; group sync to cloud; API for custom apps 5. Deprovision — disable IdP first; cascade to apps; revoke tokens and sessions 6. Orphan detection — quarterly report: accounts without HR match or inactive > 90 days

Validate with negative tests: terminated user cannot SSO; API keys invalidated.

Access reviews

Run campaigns on a risk-based cadence:

Campaign steps:

1. Define scope (app, role, population, point-in-time) 2. Pre-cleanse — remove already-terminated, merge duplicates 3. Present role + permission detail (not app name only) 4. Capture attest: retain / revoke / modify with justification 5. Auto-revoke on non-response per policy (with exec exception path) 6. Export evidence for auditors — who attested, when, outcome

Use risk-based sampling only when population is huge; document sampling method.

Exceptions and emergency access

• Temporary elevation — max duration, approver, auto-expiry, ticket ID
• Emergency break-glass — separate accounts, MFA, session log, post-use review within 24h
• Exception register — compensating control, expiry date, executive approver for SoD conflicts

Never leave “permanent exceptions” without expiry and named owner.

Privileged access and PAM

Table of contents

1. Privileged account types 2. PAM capabilities 3. JIT elevation 4. Break-glass 5. Monitoring and review

Privileged account types

Separate privileged accounts from standard workforce accounts — no shared mailbox admins.

PAM capabilities

Implement in priority order:

1. Credential vaulting — rotate passwords/keys; checkout/check-in 2. Session management — proxy RDP/SSH/SQL; record where regulated 3. Approval workflows — manager or peer for production access 4. Just-in-time — Azure PIM, AWS IAM Identity Center, GCP PAM, or third-party 5. Discovery — scan for local admins, orphaned keys, shadow SaaS admins

Align vault coverage with risk tier — Tier 0 first, then production paths.

JIT elevation

Workflow:

1. User requests role or resource scope with ticket reference 2. SoD and approval checks (automated where possible) 3. Grant time-bound assignment (e.g., 1–8 hours) 4. Notify security; log activation event 5. Auto-revoke at expiry; confirm revocation in audit

Deny standing permanent admin in production unless exception registered.

For CI/CD and automation, use workload identity — not vaulted human passwords.

Break-glass

1. Dedicated accounts — not personal users; strong MFA hardware 2. Storage — split knowledge or sealed envelope; vault checkout 3. Trigger — incident commander approval; major outage criteria 4. Usage — single purpose; time box; parallel notification to security 5. Post-incident — credential rotation; session review; incident record

Cloud: prefer break-glass roles in separate account with SCP guardrails (cloud-security-engineer for SCP design).

Monitoring and review

• Alert on: vault checkout, JIT activation, break-glass login, new admin group member
• Correlate IdP, PAM, and cloud CloudTrail/Audit Logs
• Weekly sample of privileged sessions; quarterly full access review
• Metric: % admin access that is JIT vs standing; mean time to revoke on leave

Remediation of misused break-glass is incident-driven — partner with incident-responder when abuse suspected.

RBAC, ABAC, and entitlements

Table of contents

1. Model selection 2. Role engineering 3. Separation of duties 4. Entitlement catalog

Model selection

Default: RBAC for humans, scoped roles for machines, ABAC/PBAC only where audit requires attribute-level proof.

Role engineering

1. Inventory — list permissions per app/cloud; group by function not by person 2. Define roles — verb-noun names (billing-read, deploy-prod); one purpose per role 3. Least privilege — start deny-all; add minimum actions; avoid * wildcards 4. Role mining — analyze access logs; merge roles with > 95% overlap; split toxic combos 5. Birthright vs requestable — document which roles auto-assign from job code 6. Version and deprecate — sunset roles with migration window and comms

Anti-patterns:

• “Super user” or “admin clone” roles for convenience
• Nested groups without visibility (group-in-group sprawl)
• Direct user permissions outside role model

Separation of duties

Build a SoD matrix for financial, IAM, and production paths:

1. List incompatible permission pairs per system 2. Detect in IdP/group assignments and cloud policy attachments 3. Block at request time where possible; else monitor + remediate 4. Document compensating controls for approved conflicts (monitoring, dual control)

Entitlement catalog

Maintain one row per entitlement:

Publish catalog to request portal and auditors; sync changes via change management.