Privileged Access Management (PAM): Privilegierte Konten schützen

Privilegierte Accounts sind das wertvollste Angriffsziel in jeder IT-Umgebung. Ein kompromittierter Domain Admin bedeutet vollständige Kontrolle über alle Windows-Systeme, alle Passwörter, alle Daten. Laut CyberArk sind privilegierte Credentials in über 80 Prozent aller erfolgreichen Cyberangriffe involviert. Privileged Access Management (PAM) ist der Rahmen, um diese kritischen Konten zu schützen - durch Vaulting, Session Recording, Just-in-Time-Zugang und kontinuierliches Monitoring.

Was ist ein privilegierter Account?

Klassifikation privilegierter Accounts:

Tier 0 - Kritischste Konten:
  → Domain Administrator (Windows)
  → Enterprise Administrator
  → Schema Administrator
  → Azure/Entra ID Global Administrator
  → Root-Account (Linux/Unix-Systeme)
  → AWS Root Account
  → Cloud Platform Administrator
  → PKI/CA-Administrator
  Kompromittierung = vollständige Kontrolle über alles!

Tier 1 - Server-Administratoren:
  → Lokale Administratoren auf Servern
  → Datenbankadministratoren (DBA, SA)
  → Backup-Administratoren
  → Netzwerk-Administratoren (Firewall, Switches)
  → CI/CD Pipeline-Admins (betreiben Produktions-Deploy)

Tier 2 - Workstation-Administratoren:
  → Lokale Administratoren auf Workstations
  → Helpdesk mit Admin-Rechten
  → SCCM/Intune-Administratoren

Service Accounts (Sonderklasse):
  → Laufen rund um die Uhr, niemals interaktiv
  → Oft mit hohen Privilegien (Backups, Monitoring)
  → Häufig überprivilegiert ("einfacher" damals so konfiguriert)
  → PAM-Vault: auch Service Accounts unter Kontrolle!

Shared Accounts (abzuschaffen!):
  → "root" wird von 10 Administratoren genutzt → keine Zurechenbarkeit
  → PAM-Lösung: persönliche Accounts + Checkout-System für Shared Passwords

Zahl der privilegierten Accounts:
  → Durchschnittliches Unternehmen: 3-4× mehr priv. Accounts als Mitarbeiter
  → Viele unbekannt (ehemalige Mitarbeiter, vergessene Service Accounts)
  → Discovery: erster PAM-Schritt!

PAM-Kernkonzepte

Was PAM leistet:

Password Vaulting (Kern-Funktion):
  → Alle privilegierten Passwörter: im Vault gespeichert (verschlüsselt)
  → Benutzer sehen Passwörter NIE im Klartext
  → Passwörter werden nach jeder Session automatisch rotiert
  → Vault: Hardware-Security-Module (HSM) oder starke Verschlüsselung

  Rotation-Strategien:
  → On-Demand: nach jeder Nutzung rotieren
  → Scheduled: täglich/wöchentlich
  → Event-based: nach Sicherheitsvorfall sofort!

Privileged Session Management (PSM):
  → Alle Admin-Sessions: über PAM-Proxy geleitet
  → Session-Recording: vollständige Aufzeichnung (Video + Keystroke)
  → Realtime-Monitoring: Supervisor kann Session übernehmen/beenden
  → Audit-Trail: jede Aktion nachvollziehbar
  → Credential Injection: Admin sieht KEIN Passwort (direkt injiziert!)

Just-in-Time Access (JIT):
  → Zero Standing Privilege: keine dauerhaften Admin-Rechte
  → Zugriff wird beantragt → genehmigt → aktiviert → automatisch entzogen
  → Zeitfenster: 1-8 Stunden (je nach Aufgabe)
  → Genehmigung: 4-Augen-Prinzip oder automatisch für bekannte Workflows

Privileged Account Discovery:
  → Scannt Infrastruktur nach unbekannten privilegierten Accounts
  → Erkennt: Accounts in Domain Admins, lokale Admins, Service Accounts
  → Integration: AD, Unix, Cloud, Datenbanken, Netzwerk-Geräte
  → Onboarding: gefundene Accounts in Vault aufnehmen

Privileged Threat Analytics (PTA):
  → Verhaltensanalyse privilegierter Nutzer
  → Anomalie-Erkennung: Admin um 2 Uhr morgens?
  → UEBA für Privileged Accounts
  → Integration mit SIEM

Zero Standing Privilege (ZSP) - Zielarchitektur:
  Heute:       Domain Admins mit permanenten Rechten
  Übergang:    PAM + JIT (temporäre Rechte)
  Ziel (ZSP):  Keine dauerhaften privilegierten Konten
               → Alle Admins: normale User + JIT-Eskalation

PAM-Produkte im Vergleich

Enterprise PAM-Lösungen:

CyberArk Privileged Access Manager (Marktführer):
  Stärken:
  → Marktführer (Gartner Magic Quadrant Leader seit 10+ Jahren)
  → Vault-Architektur: Enterprise Password Vault (EVP)
  → PSM: vollständige RDP/SSH-Session-Aufzeichnung
  → CyberArk Identity: IDAAS + MFA + SSO integriert
  → Threat Analytics: anomale Nutzungsmuster erkennen
  → Kubernetes: Conjur (Secrets Management für Container)
  → OT/ICS-Unterstützung, Enterprise-Support

  Schwächen:
  → Komplex zu implementieren und betreiben
  → Sehr teuer (Enterprise-Lizenzierung, 6-stellig/Jahr)
  → Onboarding von Accounts: aufwändig

  Eignet sich für: Enterprise (1.000+ Mitarbeiter), KRITIS, Finanz

Delinea Secret Server (früher Thycotic):
  Stärken:
  → Einfacheres Setup als CyberArk
  → Gutes Preis-Leistungs-Verhältnis
  → SaaS-Option (Secret Server Cloud) + On-Premises
  → Launchers: automatischer RDP/SSH-Start ohne Passwort-Sichtbarkeit
  → Reporting: Compliance-Reports out-of-the-box
  → Privilege Manager: Least Privilege auf Endpoints (Application Control)

  Schwächen:
  → Weniger mächtig als CyberArk bei komplexen Umgebungen
  → Threat Analytics weniger ausgereift

  Eignet sich für: Mittelstand (100-1.000 Mitarbeiter)

BeyondTrust Password Safe:
  Stärken:
  → Remote Access + PAM kombiniert
  → Privileged Remote Access: für externe Dienstleister
  → Asset Discovery: automatisches Erkennen privilegierter Konten
  → Gut für Managed Service Provider
  → Endpoint Privilege Management (EPM): lokale Admin-Rechte entfernen

  Schwächen:
  → Teuer für reine PAM-Nutzung

HashiCorp Vault (Open Source / Enterprise):
  Stärken:
  → Open Source (Community Edition kostenlos!)
  → Fokus: Secrets Management für Anwendungen (API-Keys, DB-Credentials)
  → Dynamic Secrets: temporäre Credentials on demand
  → Kubernetes Integration: Vault Agent Injector
  → Multi-Cloud: AWS/Azure/GCP Secrets Engine

  # Dynamic Secrets Beispiel:
  vault read database/creds/my-role
  # Key                Value
  # username           v-root-abcd1234
  # password           A1a-XxYyZz...
  # lease_duration     1h   ← automatisch abläuft!

  Eignet sich für: DevOps, Cloud-native, Entwicklungsumgebungen

Microsoft Privileged Identity Management (PIM):
  Stärken:
  → In Azure AD / Entra ID integriert (kein separates Produkt)
  → JIT-Aktivierung für Azure RBAC + Azure AD Rollen
  → Access Reviews: regelmäßige Überprüfung
  → PIM in Entra ID P2 enthalten (ca. 8 EUR/User/Monat)

  PIM konfigurieren:
  Azure Portal → Entra ID → Privileged Identity Management → Roles
  → Global Administrator: Eligible statt Permanent!
    → Max Duration: 4h
    → Require Justification: On
    → Require Approval: On → Approver: CISO

  Schwächen:
  → Nur für Azure/M365 (kein On-Premises ohne Azure Arc)
  → Kein PSM / Session-Recording

Wallix Bastion (EU-Anbieter):
  → DSGVO-konform, in Europa entwickelt
  → PAM + Session Management + Access Control
  → Gut für: Unternehmen mit EU-Datenschutz-Priorität

PAM-Implementierung Schritt für Schritt

PAM Rollout - Reihenfolge:

Phase 1: Discovery (Woche 1-2)
  → Alle privilegierten Accounts identifizieren:
    - Windows: Domain Admins, Local Admins, Service Accounts
    - Linux: root, sudo-Gruppen
    - Datenbanken: DBA-Accounts, SA-User
    - Netzwerk: Enable-Passwörter, Management-Accounts
    - Cloud: Root-Account, IAM-Admins, Service Principals
  → Tool: CyberArk Discovery Manager, oder PowerShell:

  # Alle lokalen Admins in AD-Domäne finden:
  Get-ADGroupMember "Domain Admins" -Recursive | Select Name
  # Service Accounts:
  Get-ADServiceAccount -Filter *

Phase 2: Vault-Setup (Woche 2-4)
  → PAM-Vault deployen (HA für Produktion!)
  → Vault-Verschlüsselung konfigurieren (HSM oder starke Keys)
  → Break-Glass-Accounts definieren (s.u.)
  → Admin-Onboarding: IT-Admins in PAM einrichten

Phase 3: Account-Onboarding (Woche 4-8)
  → Domain Admins zuerst (höchstes Risiko!)
  → Dann: Server-Admins
  → Dann: Service Accounts (Passwort-Rotation!)
  → Dann: Datenbank-Admins
  → Dann: Netzwerk-Geräte
  → Dann: Cloud-Accounts

  Wichtig bei Service Accounts:
  → Service-Account-Passwort in Vault
  → Automatische Rotation aktivieren
  → Prüfen: welche Services nutzen diesen Account?
  → Rotation-Plan: erst alle Services updaten, dann rotieren!

  # Für Windows-Service-Accounts: Group Managed Service Accounts (gMSA)
  # Passwort wird von AD automatisch rotiert (kein PAM nötig!)
  New-ADServiceAccount -Name "svc-webapp" -ManagedPasswordIntervalInDays 30
  Install-ADServiceAccount svc-webapp

Phase 4: PSM + JIT aktivieren (Woche 8-12)
  → PSM-Proxy für RDP/SSH konfigurieren
  → Session-Recording aktivieren + Speicherort definieren
  → JIT-Workflows definieren (wer genehmigt was?)
  → Schulung: Admins müssen PAM nutzen (Change-Management!)

Tiered Administration Model

Microsoft Tiered Administration Model:

Warum notwendig:
  → Angreifer nutzt lateral movement: kompromittiert Workstation → Helpdesk-Admin
    nutzt gleichen Credential auf Server → Server kompromittiert →
    DA-Credentials auf Server gespeichert → Domain Admin kompromittiert
  → Lösung: Strikte Trennung der Tier-Credentials

Tier 0 (Wald und Domäne):
  → Systeme: Domain Controller, PKI, ADFS, Azure AD Connect
  → Accounts: Domain Admins, PKI-Admins
  → Admin-Workstation: Tier-0-PAW (Privileged Access Workstation)
    → Separater, gehärteter Laptop AUSSCHLIESSLICH für Tier-0-Aufgaben
    → Kein Internet, kein E-Mail, kein Office auf dieser Maschine!
  → Logon Restriction: Tier-0-Accounts dürfen NICHT auf Tier-1/2-Systeme!
    GPO: Computer Configuration → Security Settings → User Rights:
    "Deny log on locally" für alle Tier-1/2-Systeme für DA-Accounts

Tier 1 (Server):
  → Systeme: Mitglieds-Server, VMs, Datenbanken
  → Accounts: Server-Administratoren (KEIN Domain Admin!)
  → Admin-Workstation: Tier-1-PAW oder Jump Server
  → Logon Restriction: Tier-1-Accounts nicht auf Workstations

Tier 2 (Workstations):
  → Systeme: User-Workstations, Laptops
  → Accounts: Helpdesk, Standard-Admins
  → Admin-Workstation: eigene Helpdesk-Workstation
  → Logon Restriction: dürfen nicht auf Server/DCs

Implementierung mit LAPS (Local Admin Password Solution):
  → Für Tier-1/2: einzigartiger lokaler Admin-Account pro System
  → Passwort automatisch verwaltet (keine manuelle Rotation!)
  → Windows LAPS: in Windows 11 22H2 und Server 2022 integriert
  → PAM-Integration: LAPS-Passwörter über PAM-Vault abrufbar

  LAPS aktivieren (Intune):
  Endpoint Security → Account Protection → LAPS:
    Back up Directory: Azure AD
    Password Complexity: Large Letters + Small Letters + Numbers + Special Characters
    Password Length: 32
    Password Age: 7 days
    Administrator Account Name: (leer = Standard-Konto)

Authentication Policy Silos (Windows 2012R2+):
  → Tier-0-Accounts: dürfen NUR auf Tier-0-Computern authentifizieren
  → Wenn Tier-0-Account auf normalem PC eingeloggt: VERWEIGERT!

Just-in-Time Access in der Praxis

JIT-Implementierung - drei Ansätze:

Ansatz 1: Ephemeral Accounts (temporäre Konten):
  → Admin-Account wird on-demand erstellt
  → Automatisch gelöscht nach Ablauf
  → CyberArk: Just-in-Time Access + Dynamic Provisioning

  Workflow:
  1. Admin beantragt JIT-Zugang (Reason: "Patch KB5017308 deployen")
  2. PAM erstellt temporären Account: john.doe.jit.20260304@firma.de
  3. Account wird in Server-Admin-Gruppe aufgenommen
  4. Admin verbindet sich per PSM (Session wird aufgezeichnet)
  5. Nach 2h: Account automatisch deaktiviert und Gruppe entfernt

Ansatz 2: Privilege Elevation (bestehender Account, temporäre Erhöhung):
  → Normaler Account → temporäres Hinzufügen zu privilegierter Gruppe
  → Microsoft PIM für Azure-Berechtigungen
  → PAM-Vault für On-Premises

  PIM Workflow:
  1. Admin aktiviert "Server Administrator" in PIM
  2. Justification: "Monthly Patch-Deployment Server-01"
  3. Notifikation an CISO/Manager
  4. Nach Genehmigung: Account in Gruppe aufgenommen (2h)
  5. Session Monitor in PIM: wann aktiv?
  6. Nach 2h: automatisch aus Gruppe entfernt

  # Aktivierung via PowerShell:
  Open-AzureADMSPrivilegedRoleAssignmentRequest `
    -ProviderId "aadRoles" `
    -ResourceId "<TenantId>" `
    -RoleDefinitionId "<GlobalAdminRoleId>" `
    -SubjectId "<UserId>" `
    -Type "UserAdd" `
    -AssignmentState "Active" `
    -Schedule @{StartDateTime=(Get-Date); EndDateTime=(Get-Date).AddHours(4)} `
    -Reason "Konfigurationsänderung für Ticket #12345"

Ansatz 3: Just-Enough-Administration (JEA):
  → PowerShell-Remoting mit eingeschränkten Befehlen
  → Kein "full Admin" mehr - nur notwendige Cmdlets!
  → Konfiguration: JEA Session Configuration Files

  JEA Konfiguration (PowerShell):
  # SessionConfiguration.pssc
  SchemaVersion = '2.0.0.0'
  Author = 'IT-Security'
  Description = 'Limited Admin for Patch Management'
  SessionType = 'RestrictedRemoteServer'
  ModulesToImport = @('PSWindowsUpdate')
  VisibleCmdlets = @(
    'Get-WindowsUpdate',
    'Install-WindowsUpdate',
    'Get-Service',
    'Restart-Service'
  )
  RunAsVirtualAccount = $true  # Läuft mit lokalem Admin, aber isoliert!

  JEA registrieren:
  Register-PSSessionConfiguration -Path .\SessionConfiguration.pssc
    -Name 'PatchManagement' -Force
  # Nutzung: Enter-PSSession -ComputerName server -ConfigurationName PatchManagement

JIT auf Linux (sudo mit zeitbegrenzten Sessions):
  # Mit tlog (Session Recording) + sudo:
  # /etc/sudoers.d/jit:
  %jit-admins ALL=(ALL) NOPASSWD: /usr/bin/tlog-rec-session
  # Nur spezifische Befehle erlaubt, alle Sessions recorded

CyberArk PAM - Enterprise-Architektur

CyberArk Architektur und Konfiguration:

Kernkomponenten:
  Digital Vault:                    Zentraler verschlüsselter Credential-Store
  Central Policy Manager (CPM):     Automatische Passwort-Rotation
  Privileged Session Manager (PSM): Session-Proxy
  Password Vault Web Access (PVWA): Web-UI für Administratoren

Safe-Konzept (Organisationsstruktur):
  Safes = Ordner/Container für Credentials
  → Safe "DomainAdmins": alle DA-Credentials
  → Safe "DatabaseAccounts": alle DB-Credentials
  → Zugriffsrechte: granular auf Safe-Ebene

  # CyberArk REST API - Account erstellen:
  POST /api/Accounts
  {
    "safeName": "DomainAdmins",
    "platformId": "WinDomain",
    "name": "da-maxmustermann-prod",
    "address": "corp.example.com",
    "userName": "da-maxmustermann",
    "secretType": "password",
    "secret": "initialpassword",
    "platformAccountProperties": {
      "LogonDomain": "CORP"
    }
  }

CPM-Rotation (automatische Passwort-Rotation):
  → CPM verbindet sich zum System, ändert Passwort, speichert in Vault
  → Intervall: täglich, wöchentlich
  → Automatische Rotation nach Check-out (Sofort-Rotation nach Nutzung!)
  → Dual Control: zwei Personen müssen Passwort freigeben

PSM-Session (Protokolltypen):
  → RDP (Windows): Video-Recording von Windows-Admin-Sessions
  → SSH (Linux): Keystroke + Terminal-Recording
  → SQL Plus / SQL Server Management Studio: DB-Admin-Sessions
  → Web-Applikationen: via Browser-Extensions

Session-Recording forensisch nutzen:
  → CyberArk Vault: alle Recordings durchsuchbar
  → Transkript-Suche: "welcher Admin hat DROP TABLE ausgeführt?"
  → Zeitleiste: wann wurde welches System zugegriffen?
  → Compliance-Report: alle Zugriffe auf PCI-DSS-Systeme im letzten Quartal

Session-Recording und Forensik

Audit-Trail: Session-Recording analysieren:

Was aufgezeichnet wird:
  → Keystroke-Logging: jede Taste, jeder Befehl
  → Terminal-Output: alle Ausgaben
  → Dateitransfers (via SCP/SFTP)
  → RDP: Video-Stream + Clipboard-Aktivitäten
  → Zeitstempel für jeden Event

Forensik-Szenario:
  Vorfall: Datenbankdaten wurden gelöscht
  Untersuchung via PAM-Session-Recordings:
  1. PAM-Logs: wer hatte in diesem Zeitfenster DB-Zugriff?
  2. Session-Recording: DBA's Session von 03:15 Uhr öffnen
  3. Video: DBA verbindet, führt aus: "DELETE FROM customers;"
  4. Keystroke-Log: exakter SQL-Befehl dokumentiert
  5. Ergebnis: Insider-Threat identifiziert, Beweis gesichert

Session-Recording Compliance:
  → PCI-DSS: alle Zugriffe auf CDE (Cardholder Data Environment) aufzeichnen
  → SOX: alle Finanzsystem-Admin-Zugriffe dokumentieren
  → HIPAA: alle PHI-System-Zugriffe protokollieren
  → ISO 27001: A.9.4 - Protokollierung von Systemadministrator-Aktivitäten

Break-Glass-Konten

Notfallzugriff wenn PAM nicht erreichbar:

Das Problem:
  → PAM-System ausfällt → kein Zugriff auf Admin-Passwörter
  → Notfall: Server kompromittiert, PAM-System auch?
  → Stromausfall / Netzwerkpartition

Break-Glass-Konto Konzept:
  → 1-2 Konten mit höchsten Privilegien AUSSERHALB des PAM
  → Passwort: in physisch gesichertem Umschlag (Tresor!)
  → KEIN digitaler Zugriff auf Break-Glass-Passwort (außer Notfall)

  Implementierung:
  Konto:     bga01@company.com (Break-Glass Account 1)
  Passwort:  60+ Zeichen, komplex, offline generiert
  Speicher:  Physischer Tresor (Raum A, Schloss-Nr. X)
             PLUS: verschlüsselt auf USB-Stick (anderer Ort)
  Zugriff:   Nur durch CISO + IT-Leiter gemeinsam (4-Augen!)
  Überwachung: Jede Nutzung → sofortiger Alert an alle IT-Führungskräfte

  Monitoring:
  → Azure Sentinel Alert: bga01 eingeloggt → SOFORT P1 Incident!
  → Regelmäßiges Test-Login (jährlich): prüfen ob Konto funktioniert
  → Passwort-Rotation: nach jeder tatsächlichen Nutzung

  Break-Glass-Account Best Practices:
  ✓ MFA-Methode dokumentiert (Authenticator-Backup-Codes!)
  ✓ Konto nicht ablaufen lassen (Ausnahme von Passwort-Policy)
  ✓ Kein regulärer Mail-Empfang (nicht für normales Arbeiten!)
  ✓ Audit-Trail: jede Nutzung begründet und dokumentiert

DSGVO-konforme Session-Aufzeichnung

Rechtliche Grenzen bei Session-Monitoring:

Was erlaubt ist:
  ✓ Session-Recording auf Unternehmens-Systemen
  ✓ Überwachung privilegierter Accounts (IT-Admins!)
  ✓ Protokollierung zur Sicherheit und Compliance

Was betriebsratsrelevant ist:
  → §87 BetrVG: Betriebsrat hat Mitbestimmungsrecht!
  → Betriebsvereinbarung MUSS abgeschlossen werden
  → Inhalt der BV: was wird aufgezeichnet, wie lange gespeichert, wer hat Zugriff

DSGVO-Konformität:
  → Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse)
  → oder: Betriebsvereinbarung (= kollektivrechtliche Einwilligung)
  → Zweckbindung: nur für Sicherheit, nicht für Leistungsüberwachung
  → Löschfristen: Session-Recordings nach 90 Tagen löschen (empfohlen)
  → Ausnahme: Incident-bezogene Recordings → länger aufbewahren

Transparenz:
  → Admins werden informiert: "Sessions werden aufgezeichnet"
  → System-Banner beim Login: "Authorized use only, sessions monitored"
  → Kein verdecktes Monitoring von Mitarbeitern (§201a StGB!)

PAM und SIEM/SOAR Integration

PAM-Events im SIEM:

Wichtige PAM-Events für SIEM-Korrelation:
  □ Unerwarteter Check-out: Admin holt Credentials außerhalb Geschäftszeiten
  □ Failed Check-out: Account existiert nicht mehr (orphaned credential!)
  □ Session Duration: Admin-Session länger als 4h (ungewöhnlich!)
  □ Sensitive Commands: rm -rf, DROP TABLE, net user /domain in Session-Log
  □ JIT-Ablauf ignoriert: Admin verlängert JIT-Zugang mehrfach (Umgehung?)
  □ Concurrent Sessions: gleichzeitige Nutzung desselben priv. Accounts

SIEM-Alert: Credential-Checkout außerhalb Geschäftszeiten:
  # Splunk:
  index=pam eventtype=credential_checkout
  | eval hour=strftime(_time, "%H")
  | where (hour < 6 OR hour >= 20)
  | table _time, user, target_account, target_system, reason
  | eval alert_title = "PAM Checkout outside business hours"

SOAR-Playbook: Verdächtiger Checkout:
  Trigger: PAM-Alert "Credential Checkout at 03:00"
  Automatisch:
    1. Slack/Teams-Nachricht an CISO: "Privilegierter Checkout um 3:00 Uhr"
    2. Aktuelle Session anzeigen (ist Admin gerade verbunden?)
    3. Wenn keine bekannte Change-Window: Session sofort beenden!
    4. Ticket erstellen: "Unerwarteter Privileged Access"
  Manuell:
    → L2 Analyst bewertet: War es geplant? (z.B. Change-Window vergessen?)
    → Wenn unbekannt: Incident Response einleiten

KQL in Microsoft Sentinel (Admin-Login nicht von PAW):
  SecurityEvent
  | where EventID == 4624
  | where Account contains "admin" or Account contains "svc"
  | where Computer !in (known_paw_hostnames)
  | where LogonType in (3, 10)  // Network + RemoteInteractive
  | project TimeGenerated, Account, Computer, IpAddress