Identity Governance and Administration (IGA): Joiner-Mover-Leaver und Zugriffszertifizierung

Identity Governance and Administration (IGA) solves a fundamental problem: permissions accumulate over time. Employees are granted access, change roles, and leave the company—but permissions are rarely revoked systematically. The result: employees have access to systems they no longer need. IGA automates the permission lifecycle and enforces the principle of least privilege.

IGA vs. IAM vs. PAM

Definition of terms:

IAM (Identity and Access Management):
  → Broadest term: Authentication + Authorization
  → Includes: SSO, MFA, Directory Services (AD, LDAP)
  → Focus: "Who are you? What are you allowed to do?"
  → Tools: Azure AD/Entra ID, Okta, Ping Identity

PAM (Privileged Access Management):
  → Focus on privileged accounts (Admin, Root, service accounts)
  → Password vaults, session recording, just-in-time access
  → Tools: CyberArk, BeyondTrust, Delinea

IGA (Identity Governance and Administration):
  → Governance layer above IAM
  → Focus: "Who is ALLOWED to do what? Is this still valid? Who approved it?"
  → Lifecycle management: Joiner → Mover → Leaver
  → Compliance: Access certifications, SoD enforcement, audit trails
  → Tools: SailPoint, Saviynt, Microsoft Entra Identity Governance, One Identity

Interaction:
  HR system → IGA (Joiner process) → IAM (create account) + PAM (Privileged Access)
  HR system → IGA (Leaver process) → IAM + PAM (deactivate immediately!)

Joiner-Mover-Leaver Process

JML (Joiner-Mover-Leaver) - Core process of IGA:

JOINER (New Employee):
  Trigger:  HR system creates new employee record
  Process:
    1. IGA receives HR event (API, CSV, SCIM push)
    2. Identity is created: displayName, department, jobTitle, manager
    3. Role Assignment: based on role/department (Role Mining!)
       Example: "Junior Developer, IT" → Standard access:
         □ Azure AD Account
         □ Email Account (Exchange)
         □ Jira (Developer permission)
         □ GitHub Org (selected repos)
         □ VPN access
    4. Approval workflow: Manager confirms (for non-standard access)
    5. Account creation in target systems (via Connector/SCIM)
    6. Welcome email with credentials
    7. Audit: All actions logged with timestamps

  Level of automation:
    Standard access:   Fully automated (no manual steps)
    Special access:     Approval workflow (Manager → System Owner)
    Privileged access: PAM process (separate approval!)

MOVER (transfer, promotion, department change):
  Trigger:  HR update: department, job title, supervisor changes
  Process:
    1. IGA receives HR change event
    2. Calculate new role assignment
    3. Delta analysis: what is added? What needs to be removed?
    4. New permissions: automatically or via workflow
    5. CRITICAL: Revoke old permissions (SoD check!)
       → Employee should ONLY have the new role, NOT the old one!
    6. Transition Period: 30-day overlap if necessary (business decision)
    7. Audit Trail: all changes documented

  Typical problem without IGA:
    Person moves from Finance to IT:
    → Retains Finance access (not revoked)
    → Receives IT access (new)
    → After 3 years: 5 role changes = 5 sets of accumulated permissions
    → "Permission creep" or "privilege creep" – highly dangerous!

LEAVER (Termination, Departure):
  Trigger:  HR Event: Termination Date or immediately upon termination
  Process (critical – fast!):
    T-30 days:  Preparation (Asset List, Knowledge Transfer)
    T-0 (last day of work):
      □ Account deactivation (ALL systems!): < 1 hour after separation
      □ Reset passwords for all known accounts
      □ Remove MFA tokens
      □ Terminate active sessions (SSO session invalidation!)
      □ Revoke VPN certificates
      □ Deactivate API keys and service accounts
      □ Change passwords for shared accounts (if accessible)
    T+7 days:   Archive account (do not delete! Audit!)
    T+90 days:  Permanently delete account (after retention period)

  Immediate leaver (termination without notice, security incident):
    → Emergency deactivation in < 15 minutes
    → IGA workflow: "Emergency Termination" with confirmation by CISO/HR
    → In parallel: force all sessions to end + revoke all tokens

  SLAs for leavers:
    Standard:           < 24 hours (next business day)
    High-risk position: < 1 hour (immediately after HR confirmation)
    Security incident:  < 15 minutes (manual trigger by CISO)

Role Management and Role Mining

Role Concept in IGA:

Business Roles (What does the person do?):
  → "Junior Developer", "HR Manager", "Finance Director"
  → Abstract business functions (no technical details)
  → Defined and maintained by HR
  → Example: "Sales Manager DACH"

IT Roles / Technical Roles (What do they need to do this?):
  → "CRM Power User", "AD Domain User", "SharePoint Contributor"
  → Technical permissions corresponding to the business role
  → Maintained by IT
  → Mapping: 1 business role = multiple IT roles

Entitlement (Technical Permission):
  → Specific permission in a system
  → "Jira Group: developers-backend"
  → "AD Group: SG-FILE-SHARE-Marketing-RW"
  → "Salesforce Profile: Standard User"

Role Mining - Automatic Role Detection:
  Problem: Companies often lack structured roles → evolved historically
  Solution: Analyze existing permissions → similar users = same role

  # SailPoint Role Mining (conceptual):
  1. Export: all users + their entitlements
  2. Clustering: similarity analysis (k-means, hierarchical)
  3. Candidate roles: "75% of developers have exactly these 12 entitlements"
  4. Review: IT + HR validate the role
  5. Import: Role created in IGA and members assigned

  Typical role hierarchy:
  Base role (all):     Email, SharePoint Read, Basic VPN
  IT department:          +AWS Console Read, +Confluence, +Jira
  Backend developer:     +GitHub Teams-Backend, +k8s Namespace Dev
  Senior Developer:      +AWS Console Write (DEV only), +Code Review Approval
  Tech Lead:             +Production ReadOnly, +Architecture Confluence
  IT Admin:              +AD Admin Tier 1, +ITSM Full, +Cloud Management

Segregation of Duties (SoD)

SoD - Separation of duties for fraud prevention:

Why SoD?
  → Dual-control principle in IT systems
  → No one should be able to create AND approve a payment (financial risk)
  → No one should be able to create an account AND perform an audit (control risk)
  → SOX, ISO 27001, NIS2: all require SoD for critical processes

Examples of SoD conflicts:
  CRITICAL:
    "Accountant can create vendor accounts" + "Accountant can approve payments"
    → Fraud risk: fake invoices to their own company!

    "IT admin can create AD accounts" + "IT admin is their own auditor"
    → Control gap: can cover their tracks

  MEDIUM:
    "Purchaser can create purchase orders" + "Purchaser can approve purchase orders"
    → Purchaser can approve their own purchase orders without oversight

  LOW:
    "Developer can write code" + "Developer can deploy code to production"
    → Change management can be bypassed (risky without other controls)

Create SoD rule set:
  Format: "Authorization A" CONFLICTS WITH "Authorization B"

  IGA configuration (YAML format):
  sod_rules:
    - id: "SOD-001"
      name: "Finance: Creation and Approval"
      severity: critical
      conflicting_entitlements:
        - "SAP-FI-Vendor-Creation"
        - "SAP-FI-Payment-Approval"
      mitigating_control: "Dual control by Finance Manager"

    - id: "SOD-002"
      name: "IT: Account Creation and Audit"
      severity: high
      conflicting_entitlements:
        - "AD-User-Administration"
        - "SIEM-Audit-Log-Access"

SoD Enforcement:
  Preventive: IGA prevents assignment if a conflict arises
  Detective:  Periodic SoD report for existing conflicts
  Compensating: Document mitigating controls (if conflict is unavoidable)

Procedure:
  1. Build a role matrix (all roles × all roles)
  2. Identify critical processes (Finance, IT Admin, HR)
  3. Define conflict rules (with business input!)
  4. Existing violations: remediate or implement mitigating controls
  5. Ongoing enforcement: preventive measures in the workflow

Access Review

Periodic review of all permissions - ISO 27001 A.9.2.5 + SOX:

What is reviewed?
  Regularly (quarterly/annually):
    □ All users and their current permissions
    □ Privileged accounts (admin, service accounts): quarterly
    □ Regular employees: annually
    □ External parties (contractors): at contract expiration + annually

Review Process:
  1. IGA generates campaign ("Q1 2026 Access Review")
  2. Manager/Certifier receives list of direct reports
  3. Per employee: List of all permissions
  4. Certifier decides: APPROVE / REVOKE / DELEGATE
  5. Dispute: Revoke triggered → Permission revoked
  6. No response: Reminders → Escalation → Auto-revoke
  7. Report: Certification rate, revoked entitlements, duration

Best practices:
  → Keep campaigns manageable (fatigue effect → everyone clicks "Approve")
  → Risk-based: Review high-risk access more frequently
  → Display context: "This person has had this access for 847 days
     and last used it 450 days ago" → informed decision
  → Automated Recommendations: IGA recommends "Revoke" in case of inactivity

Certifier Types:
  Manager Review:      Supervisor certifies direct reports
  Application Owner:   System owner certifies all users of their system
  Role Owner:          Role owner reviews all role members
  Self-Certification:  User confirms their own permissions (weakest form!)

Audit Trail (ISO 27001):
  Every decision is logged:
  "2026-03-01T10:30:00Z | certifier=john.doe | user=jane.smith |
   entitlement=SAP-MM-Admin | decision=REVOKE | reason=Left department"

IGA Products Compared

Market Overview (as of 2026):

SailPoint Identity Security Cloud:
  → Market leader (Gartner Magic Quadrant Leader since 2015)
  → AI-based role mining and anomaly detection
  → IdentityNow (SaaS) or IdentityIQ (on-premise)
  → Strengths: Most extensive connector library (250+ apps)
  → Weaknesses: Complex, expensive (enterprise pricing)
  → Suitable for: Enterprises with 1,000+ employees

Saviynt Enterprise Identity Cloud:
  → Combination of IGA + PAM + CIEM (Cloud IGA)
  → Cloud-native, good Azure/AWS integration
  → CIEM: Cloud Infrastructure Entitlement Management
  → Suitable for: Cloud-first companies

Microsoft Entra Identity Governance:
  → Part of Microsoft 365 E5 / Entra ID P2
  → Access reviews, entitlement management, lifecycle workflows
  → Strengths: natively integrated into the M365 ecosystem (no extra connector)
  → Weaknesses: limited to Microsoft-centric environments
  → Suitable for: Microsoft-heavy enterprises

One Identity (Quest):
  → Strength: Active Directory integration
  → Manager (on-premise AD), Starling (SaaS), Safeguard (PAM)
  → Suitable for: Windows-heavy environments, mid-sized businesses

Omada Identity:
  → European provider (Danish), GDPR-compliant
  → Strength: Compliance management and SoD enforcement
  → Suitable for: Compliance-intensive industries (finance, healthcare)

Build vs. Buy:
  DIY (AD + PowerShell):  Only for very small environments (<100 users)
  Entra Identity Gov:     100–5,000 users, Microsoft environment
  One Identity / Omada:   500–5,000 users, mid-market
  SailPoint / Saviynt:    5,000+ users, enterprise

IGA implementation timeline:
  Phase 1 (Foundation): 3–4 months (connectors, basic processes)
  Phase 2 (Automation): 4–6 months (JML automation, roles)
  Phase 3 (Governance): 6–12 months (certifications, SoD, reporting)
  → Typically: 12–18 months to full IGA maturity

IGA and Compliance

Regulatory requirements addressed by IGA:

ISO 27001:2022:
  A.5.18: Access rights (provisioning + revocation)
  A.8.2:  Privileged access rights (quarterly review)
  A.5.19: Access by suppliers/third parties
  → IGA provides an audit trail for all decisions

SOX (Sarbanes-Oxley) – finance-related systems:
  → SoD enforcement mandatory for financial processes
  → Periodic access reviews documented
  → Quarterly user access review as a SOX control

GDPR Art. 25 (Privacy by Design):
  → Least privilege = data protection principle
  → IGA enforces least privilege
  → Record of processing activities: Who has access to personal data?
  → Access review answers: "Do all of them have this access permission?"

NIS2 Art. 21 (Technical Measures):
  → "Access control and user management" explicitly mentioned
  → IGA as proof of structured access control

BSI IT-Grundschutz ORP.4:
  → Identity and authorization management as a separate module
  → Requirements: complete JML documentation, regular reviews