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?

Privilegierte Accounts lassen sich nach Tier klassifizieren. Tier 0 umfasst die kritischsten Konten, deren Kompromittierung vollständige Kontrolle über alles bedeutet: Domain Administrator, Enterprise Administrator, Schema Administrator, Azure/Entra ID Global Administrator, Root-Accounts auf Linux/Unix, AWS Root Account, Cloud Platform Administrator und PKI/CA-Administrator.

Tier 1 sind Server-Administratoren: lokale Administratoren auf Servern, Datenbankadministratoren (DBA, SA), Backup-Administratoren, Netzwerk-Administratoren (Firewall, Switches) und CI/CD-Pipeline-Admins die Production-Deployments durchführen.

Tier 2 sind Workstation-Administratoren: lokale Administratoren auf Workstations, Helpdesk mit Admin-Rechten und SCCM/Intune-Administratoren.

Service Accounts bilden eine Sonderklasse: Sie laufen rund um die Uhr ohne interaktive Nutzung, sind oft mit hohen Privilegien ausgestattet (Backups, Monitoring) und häufig überprivilegiert. Ein PAM-Vault bringt auch Service Accounts unter Kontrolle.

Shared Accounts sollten abgeschafft werden. Wenn zehn Administratoren denselben "root"-Account nutzen, gibt es keine Zurechenbarkeit. Eine PAM-Lösung ersetzt dies durch persönliche Accounts mit Checkout-System für Shared Passwords.

Das Durchschnittsunternehmen hat drei- bis viermal mehr privilegierte Accounts als Mitarbeiter - viele davon unbekannt (ehemalige Mitarbeiter, vergessene Service Accounts). Die Discovery dieser Accounts ist der erste Schritt bei der PAM-Einführung.

PAM-Kernkonzepte

Password Vaulting ist die Kern-Funktion: Alle privilegierten Passwörter werden verschlüsselt im Vault gespeichert. Benutzer sehen Passwörter nie im Klartext; nach jeder Session werden sie automatisch rotiert. Der Vault nutzt Hardware-Security-Module (HSM) oder starke Verschlüsselung. Rotation-Strategien umfassen On-Demand (nach jeder Nutzung), Scheduled (täglich/wöchentlich) und Event-based (nach einem Sicherheitsvorfall sofort).

Privileged Session Management (PSM): Alle Admin-Sessions werden über einen PAM-Proxy geleitet. Session-Recording erstellt eine vollständige Aufzeichnung (Video und Keystroke). Realtime-Monitoring erlaubt einem Supervisor, Sessions zu übernehmen oder zu beenden. Credential Injection bedeutet, dass der Admin das Passwort nie sieht - es wird direkt injiziert.

Just-in-Time Access (JIT) zielt auf Zero Standing Privilege: Keine dauerhaften Admin-Rechte, stattdessen Beantragung → Genehmigung → Aktivierung → automatischer Entzug. Zeitfenster von 1-8 Stunden je nach Aufgabe. Genehmigung im Vier-Augen-Prinzip oder automatisch für bekannte Workflows.

Privileged Account Discovery scannt die Infrastruktur nach unbekannten privilegierten Accounts und deckt Accounts in Domain Admins, lokale Admins und Service Accounts auf - über AD, Unix, Cloud, Datenbanken und Netzwerkgeräte hinweg.

Privileged Threat Analytics (PTA) analysiert das Verhalten privilegierter Nutzer und erkennt Anomalien (Admin-Aktivität um 2 Uhr morgens) durch UEBA mit SIEM-Integration.

Die Zielarchitektur ist Zero Standing Privilege: Heute haben Domain Admins permanente Rechte. Im Übergang werden PAM und JIT eingeführt (temporäre Rechte). Das Ziel ist, dass keine dauerhaften privilegierten Konten existieren und alle Admins normale User mit JIT-Eskalation sind.

PAM-Produkte im Vergleich

CyberArk Privileged Access Manager ist seit über 10 Jahren Marktführer im Gartner Magic Quadrant. Stärken: Enterprise Password Vault (EVP) als Vault-Architektur, vollständige RDP/SSH-Session-Aufzeichnung via PSM, CyberArk Identity mit IDAAS/MFA/SSO, Threat Analytics für anomale Nutzungsmuster, Conjur für Kubernetes-Secrets-Management und OT/ICS-Unterstützung. Schwächen: komplex zu implementieren und betreiben, sehr teuer (Enterprise-Lizenzierung im sechsstelligen Jahresbereich), aufwändiges Account-Onboarding. Geeignet für Enterprise-Umgebungen ab 1.000 Mitarbeitern, KRITIS und Finanzsektor.

Delinea Secret Server (früher Thycotic) punktet durch einfacheres Setup, gutes Preis-Leistungs-Verhältnis, SaaS- und On-Premises-Optionen, Launchers für automatischen RDP/SSH-Start ohne Passwort-Sichtbarkeit und Compliance-Reports out-of-the-box. Privilege Manager bietet Least-Privilege auf Endpoints. Schwächen: weniger mächtig als CyberArk in komplexen Umgebungen, Threat Analytics weniger ausgereift. Geeignet für den Mittelstand mit 100-1.000 Mitarbeitern.

BeyondTrust Password Safe kombiniert Remote Access und PAM, bietet Privileged Remote Access für externe Dienstleister und automatisches Asset Discovery. Besonders geeignet für Managed Service Provider. Endpoint Privilege Management (EPM) entfernt lokale Admin-Rechte von Endpoints.

HashiCorp Vault ist Open Source (Community Edition kostenlos) mit Fokus auf Secrets Management für Anwendungen (API-Keys, DB-Credentials). Dynamic Secrets erstellen temporäre Credentials on demand:

vault read database/creds/my-role
# username:        v-root-abcd1234
# password:        A1a-XxYyZz...
# lease_duration:  1h  ← läuft automatisch ab

Kubernetes-Integration via Vault Agent Injector, Multi-Cloud-Unterstützung für AWS/Azure/GCP. Geeignet für DevOps- und Cloud-native-Umgebungen.

Microsoft Privileged Identity Management (PIM) ist in Azure AD / Entra ID integriert (kein separates Produkt). JIT-Aktivierung für Azure RBAC und Azure AD Rollen, Access Reviews für regelmäßige Überprüfungen. In Entra ID P2 enthalten (ca. 8 EUR/User/Monat). PIM-Konfiguration: Azure Portal → Entra ID → Privileged Identity Management → Roles → Global Administrator als "Eligible" statt "Permanent", Max Duration 4h, Require Justification und Require Approval aktivieren. Schwächen: nur für Azure/M365 (ohne Azure Arc kein On-Premises), kein PSM/Session-Recording.

Wallix Bastion ist ein EU-Anbieter mit DSGVO-Konformität und europäischer Entwicklung. PAM, Session Management und Access Control kombiniert - gut für Unternehmen mit EU-Datenschutz-Priorität.

PAM-Implementierung Schritt für Schritt

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) und Cloud (Root-Account, IAM-Admins, Service Principals). PowerShell-Befehle für die Discovery:

# Alle Domain Admins finden:
Get-ADGroupMember "Domain Admins" -Recursive | Select Name

# Service Accounts:
Get-ADServiceAccount -Filter *

Phase 2: Vault-Setup (Woche 2-4): PAM-Vault mit Hochverfügbarkeit für Produktion deployen, Vault-Verschlüsselung konfigurieren (HSM oder starke Keys), Break-Glass-Accounts definieren und IT-Admins in PAM einrichten.

Phase 3: Account-Onboarding (Woche 4-8): Domain Admins zuerst (höchstes Risiko), dann Server-Admins, Service Accounts (mit Passwort-Rotation), Datenbank-Admins, Netzwerkgeräte und Cloud-Accounts. Bei Service Accounts: erst prüfen welche Services den Account nutzen, dann Rotationsplan erstellen, erst alle Services updaten, dann rotieren. Für Windows-Service-Accounts empfehlen sich Group Managed Service Accounts (gMSA):

New-ADServiceAccount -Name "svc-webapp" -ManagedPasswordIntervalInDays 30
Install-ADServiceAccount svc-webapp

Phase 4: PSM und JIT aktivieren (Woche 8-12): PSM-Proxy für RDP/SSH konfigurieren, Session-Recording mit definiertem Speicherort aktivieren, JIT-Workflows definieren (wer genehmigt was) und Admins schulen - Change-Management ist entscheidend.

Tiered Administration Model

Das Microsoft Tiered Administration Model ist die Antwort auf Lateral Movement: Ein kompromittierter Helpdesk-Admin nutzt dieselben Credentials auf einem Server; dort liegen DA-Credentials - und schon ist die gesamte Domain kompromittiert. Die Lösung ist strikte Trennung der Tier-Credentials.

Tier 0 (Wald und Domäne): Systeme sind Domain Controller, PKI, ADFS und Azure AD Connect. Accounts sind Domain Admins und PKI-Admins. Die Admin-Workstation ist eine physisch dedizierte Tier-0-PAW - ein separater, gehärteter Laptop ausschließlich für Tier-0-Aufgaben, ohne Internet, E-Mail und Office. Logon Restriction via GPO: Tier-0-Accounts dürfen nicht auf Tier-1/2-Systemen eingeloggt werden (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): Mitglieds-Server, VMs, Datenbanken. Server-Administratoren ohne Domain-Admin-Rechte. Admin-Workstation ist ein Tier-1-PAW oder Jump Server. Tier-1-Accounts dürfen nicht auf Workstations eingeloggt werden.

Tier 2 (Workstations): User-Workstations und Laptops. Helpdesk und Standard-Admins. Dürfen nicht auf Server oder DCs zugreifen.

LAPS (Local Admin Password Solution) für Tier 1 und 2: Einzigartiger lokaler Admin-Account pro System, automatisch verwaltetes Passwort ohne manuelle Rotation. Windows LAPS ist in Windows 11 22H2 und Server 2022 integriert und über PAM-Vault abrufbar. Intune-Konfiguration: 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.

Authentication Policy Silos (ab Windows Server 2012 R2): Tier-0-Accounts dürfen nur auf Tier-0-Computern authentifizieren. Ein Tier-0-Account auf einem normalen PC wird verweigert.

Just-in-Time Access in der Praxis

Ansatz 1: Ephemeral Accounts (temporäre Konten): Der Admin-Account wird on-demand erstellt und nach Ablauf automatisch gelöscht. CyberArk bietet Just-in-Time Access mit Dynamic Provisioning. Workflow: Admin beantragt JIT-Zugang mit Begründung → PAM erstellt temporären Account (z.B. john.doe.jit.20260304@firma.de) → Account wird in Server-Admin-Gruppe aufgenommen → Admin verbindet sich per PSM (Session wird aufgezeichnet) → nach 2 Stunden automatische Deaktivierung und Gruppenentfernung.

Ansatz 2: Privilege Elevation (bestehender Account, temporäre Erhöhung): Microsoft PIM für Azure-Berechtigungen, PAM-Vault für On-Premises. PIM-Workflow: Admin aktiviert "Server Administrator" in PIM mit Justification, Notifikation an CISO/Manager, nach Genehmigung wird Account für 2 Stunden in die Gruppe aufgenommen, danach automatisch entfernt. PowerShell-Aktivierung:

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. JEA Session Configuration File:

# 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!

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

CyberArk PAM - Enterprise-Architektur

CyberArk besteht aus vier Kernkomponenten: Digital Vault (zentraler verschlüsselter Credential-Store), Central Policy Manager (CPM, automatische Passwort-Rotation), Privileged Session Manager (PSM, Session-Proxy) und Password Vault Web Access (PVWA, Web-UI für Administratoren).

Das Safe-Konzept strukturiert Credentials in Containern - "DomainAdmins" für alle DA-Credentials, "DatabaseAccounts" für alle DB-Credentials - mit granularen Zugriffsrechten auf Safe-Ebene. Account-Anlage via CyberArk REST API:

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"
  }
}

Der CPM verbindet sich zum System, ändert das Passwort und speichert es im Vault - täglich, wöchentlich oder nach jeder Nutzung (Sofort-Rotation nach Check-out). Dual Control erfordert die Freigabe durch zwei Personen.

PSM zeichnet Sessions als RDP-Video (Windows), Keystroke- und Terminal-Recording (Linux/SSH) sowie SQL-Datenbank-Sessions auf. Session-Recordings sind durchsuchbar: "Welcher Admin hat DROP TABLE ausgeführt?" - das Transkript und die Zeitleiste liefern den Beweis. Compliance-Reports zeigen alle Zugriffe auf PCI-DSS-Systeme im letzten Quartal.

Session-Recording und Forensik

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

Forensik-Szenario: Datenbankdaten wurden gelöscht. Untersuchung via PAM-Session-Recordings: PAM-Logs zeigen, wer im Zeitfenster DB-Zugriff hatte. Das Session-Recording der DBA-Session von 03:15 Uhr wird geöffnet. Im Video führt der DBA den Befehl DELETE FROM customers; aus. Der Keystroke-Log dokumentiert den exakten SQL-Befehl. Ergebnis: Insider-Threat identifiziert, Beweis gesichert.

Compliance-Anforderungen für Session-Recording: PCI-DSS fordert die Aufzeichnung aller Zugriffe auf die Cardholder Data Environment (CDE), SOX verlangt die Dokumentation aller Finanzsystem-Admin-Zugriffe, HIPAA schreibt das Protokollieren aller PHI-System-Zugriffe vor, ISO 27001 Kontrolle A.9.4 adressiert die Protokollierung von Systemadministrator-Aktivitäten.

Break-Glass-Konten

Wenn das PAM-System ausfällt, besteht kein Zugriff auf Admin-Passwörter. Notfall-Szenarien: Server kompromittiert und PAM-System ebenfalls betroffen, Stromausfall, Netzwerkpartition.

Das Break-Glass-Konto-Konzept sieht 1-2 Konten mit höchsten Privilegien außerhalb des PAM vor. Das Passwort liegt in einem physisch gesicherten Umschlag (Tresor). Kein digitaler Zugriff auf das Break-Glass-Passwort außer im Notfall.

Implementierung: Das Konto (z.B. bga01@company.com) erhält ein offline generiertes Passwort mit 60+ Zeichen. Speicherung im physischen Tresor (Raum A, dokumentiertes Schloss) und verschlüsselt auf USB-Stick an einem anderen Ort. Zugriff ausschließlich durch CISO und IT-Leiter gemeinsam (Vier-Augen-Prinzip). Jede Nutzung löst einen sofortigen Alert an alle IT-Führungskräfte aus.

Best Practices: MFA-Methode und Authenticator-Backup-Codes dokumentieren, Konto nicht ablaufen lassen (Ausnahme von der Passwort-Policy), kein regulärer Mail-Empfang auf diesem Konto, jeden Einsatz begründen und dokumentieren, Passwort-Rotation nach jeder tatsächlichen Nutzung.

DSGVO-konforme Session-Aufzeichnung

Session-Recording auf Unternehmens-Systemen und die Überwachung privilegierter Accounts (IT-Admins) zur Sicherheit und Compliance ist grundsätzlich erlaubt.

Betriebsratsrelevanz: § 87 BetrVG gibt dem Betriebsrat ein Mitbestimmungsrecht. Eine Betriebsvereinbarung (BV) muss abgeschlossen werden und regeln, was aufgezeichnet wird, wie lange Recordings gespeichert werden und wer Zugriff hat.

DSGVO-Konformität: Die Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse) oder eine Betriebsvereinbarung (kollektivrechtliche Einwilligung). Zweckbindung ist strikt einzuhalten: Session-Recordings dienen der Sicherheit, nicht der Leistungsüberwachung. Empfohlene Löschfrist: 90 Tage, außer bei Incident-bezogenen Recordings (längere Aufbewahrung zulässig). Kein verdecktes Monitoring von Mitarbeitern (§ 201a StGB). Admins müssen transparent informiert werden: System-Banner beim Login ("Authorized use only, sessions monitored") und schriftliche Information.

PAM und SIEM/SOAR Integration

Kritische PAM-Events für die SIEM-Korrelation: unerwarteter Check-out außerhalb der Geschäftszeiten, Failed Check-out auf nicht mehr existente Accounts (orphaned credential), Admin-Sessions länger als 4 Stunden, sensible Befehle (rm -rf, DROP TABLE, net user /domain) im Session-Log, mehrfache JIT-Verlängerungen (Umgehungsversuch?), gleichzeitige Nutzung desselben privilegierten Accounts aus verschiedenen Quellen.

Splunk-Alert für Credential-Checkout außerhalb der Geschäftszeiten:

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 für verdächtigen Checkout: Trigger ist ein PAM-Alert "Credential Checkout at 03:00". Automatisch: Slack/Teams-Nachricht an CISO, aktuelle Session anzeigen (ist Admin gerade verbunden?), bei fehlendem Change-Window Session sofort beenden, Ticket "Unerwarteter Privileged Access" erstellen. Manuell: L2-Analyst bewertet ob es sich um ein vergessenes Change-Window handelt - andernfalls Incident Response einleiten.

KQL in Microsoft Sentinel (Admin-Login nicht von bekannter 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