Identity & Access Management (IAM): Identitäten sicher verwalten

Identities are the new perimeter. In a world without fixed network boundaries—the cloud, remote work, BYOD—the question "Who are you?" is more important than "Where are you coming from?" Identity & Access Management (IAM) encompasses all processes and technologies for the secure management of digital identities and their access rights.

The Identity Lifecycle

Every identity goes through a lifecycle—incomplete management at any stage creates security gaps:

Request → Approval → Provisioning → Usage → Review → Deprovisioning
     ↑                                           ↓
  Joiner                                      Mover
  (new employee)                    (department transfer)
                                                ↓
                                             Leaver
                                       (employee leaves)

Common Lifecycle Errors

Joiner: Account created, but default password not changed; overly broad permissions granted (“activate everything first, then see”).

Mover: Employee changes departments, old permissions remain active (permission accumulation). After 5 years: User has permissions from 4 different departments.

Leaver: Employee resignation → IT finds out a week later → Account was active for 7 days without a legitimate user. Insider threat risk.

Solution: HR integration – IAM system is automatically triggered by the HR event.

Access Models: RBAC vs. ABAC vs. PBAC

RBAC - Role-Based Access Control

The standard in most companies. Users are assigned roles; roles have permissions.

User Hans → Role: "Accounting"
Role "Accounting" → Permissions:
  ✓ ERP module "Accounts Payable" (Read + Write)
  ✓ ERP module "Accounts Receivable" (Read)
  ✗ HR system (no access)
  ✗ AD administration (no access)

Strengths: Easy to understand and manage. Weakness: Role explosion (too many roles), context-independent.

ABAC - Attribute-Based Access Control

Access decisions are based on attributes of the user, the resource, and the context.

# Example: A doctor may only read a patient record if:
# - User.Role = "Doctor"
# - User.Department = PatientRecord.Department
# - PatientRecord.Status ≠ "Archived"
# - Current date falls within the treatment period

def can_access(user, resource, context):
    return (
        user.role == "doctor" and
        user.department == resource.department and
        resource.status != "archived" and
        context.date in resource.treatment_period
    )

Strengths: Very fine-grained, context-sensitive. Weakness: Complex to implement and debug.

Zero-Trust PBAC - Policy-Based Access Control

Modern approach: Every access request is checked against policies, including device status:

User request → Policy engine checks:
  ✓ Identity (MFA passed?)
  ✓ Device compliance (EDR active, patch level up to date?)
  ✓ Network location (VPN? Trusted network?)
  ✓ Behavior (Anomaly compared to baseline?)
  ✓ Resource sensitivity (Classification?)
  → Access granted / denied / with step-up authentication

Single Sign-On (SSO) and Federated Identity

SSO enables a single login for multiple applications—without separate passwords.

Protocols

SAML 2.0 (XML-based, enterprise standard):

Browser → App → "Who are you?" → Identity Provider (IdP)
Browser → IdP → Login → SAML Assertion → App
App trusts IdP assertion → Access granted

OpenID Connect (OIDC) + OAuth 2.0 (JSON/JWT-based, modern web/mobile apps):

App → "Log in with Google/Microsoft"
User → Google → Consent → ID Token (JWT)
App → Validate token → Extract user info → Session

FIDO2/Passkeys (passwordless):

User → Browser → Fingerprint on device
Browser → Cryptographic assertion to app
App → No password required

Identity Providers in the Enterprise

IdP	Strengths
Microsoft Entra ID (Azure AD)	M365 integration, Conditional Access
Okta	Multi-app, SCIM integration, Vendor-neutral
Google Workspace	Google ecosystem
Keycloak	Open source, self-hosted, GDPR-compliant
Active Directory + ADFS	On-premises, legacy environments

Privileged Access Management (PAM)

PAM is IAM for particularly critical accounts—administrators, service accounts, and emergency access.

Vault Concept

Scenario: Admin needs root access to production database:

1. Opens PAM portal (with MFA)
2. Requests access (ticket number, reason, duration)
3. PAM retrieves password from encrypted vault
4. Admin receives temporary one-time credential (valid for 4 hours)
5. Session is fully recorded (video + keylog)
6. After 4 hours: Credential automatically rotated
7. Admin cannot "keep" or share the credential

Just-in-Time (JIT) Privileges

Normal:     Hans = Standard User, NO Admin Rights

When needed: Hans requests "Domain Admin" for AD task
Approved:  Ticket from IT management (four-eyes principle)
Active:      Hans = Domain Admin for exactly 2 hours
Afterward:     Automatic revocation, rotation of all used credentials

Identity Attacks and Protective Measures

Credential Stuffing

Attacker tests billions of stolen login credentials (from data breaches) against various services.

Data breach at Service A → Credentials on "haveibeenpwned.com"
Attacker buys/finds dump: user@example.com : Password123
Tests against: banking.de, paypal.de, amazon.de, linkedin.com
Successful if: User uses the same password across multiple services

Protection:

• Multi-factor authentication (completely prevents credential stuffing)
• Breached password detection (API to HIBP or PwnedPasswords)
• Rate limiting + CAPTCHA on login endpoints
• Anomaly detection: Login from an unusual country/time

Adversary-in-the-Middle (AiTM) Phishing

Bypasses TOTP-based MFA by stealing session cookies in real time.

Phishing email → User opens link → "Microsoft Login" (Evilginx2 proxy)
User enters password → Proxy forwards to real Microsoft
Microsoft sends MFA push notification → User confirms (no warning)
Proxy steals session cookie → Attacker gains access without their own credentials

Only effective protection: FIDO2/Passkeys or phishing-resistant MFA (FIDO2 is domain-bound—does NOT work on phishing domains).

Pass-the-Token / Token Theft

Malware on the endpoint extracts OAuth/OIDC tokens from browser storage
→ Attacker uses tokens directly for API calls (no login required)
→ Tokens often valid for 1 hour or longer

Protection: Continuous Access Evaluation (CAE) – token invalidation upon real-time anomaly detection.

Kerberoasting (Active Directory)

Service accounts with SPNs: their tickets can be cracked offline.

Protection: Managed Service Accounts (gMSA) with automatically rotated 240-character passwords.

Identity Security Roadmap

Immediately (0–30 days)

1. Enable MFA for all employees (authenticator app, no SMS)
2. Implement a password manager (no more shared credentials)
3. Inventory privileged accounts (how many domain admins are there really?)

Short-term (1–3 months)

4. Implement SSO (one login, full visibility)
5. Conditional Access Policies (Device Compliance + MFA)
6. Migrate all service accounts to gMSA

Medium-term (3–12 months)

7. Implement a PAM solution (CyberArk/BeyondTrust for Enterprise, Azure AD PIM for Microsoft)
8. JIT privileges for all admin activities
9. Identity governance: regular access reviews
10. FIDO2/Passkeys for high-value accounts

Compliance Requirements

NIS2 Art. 21: MFA explicitly required for privileged access and all remote access.

ISO 27001 A.5.15-A.5.18: Access control, user authentication, rights of privileged accounts, secret authentication information.

BSI ORP.4: Identity and authorization management – lifecycle, roles, privileges.

PCI DSS 8.2–8.6: Strong authentication, account management, privilege control.