Least Privilege (Prinzip der minimalen Rechtevergabe) - Definition & Erklärung

Least Privilege ist eines der fundamentalen Sicherheitsprinzipien - und gleichzeitig eines der am häufigsten verletzten. In der Praxis häufen Accounts über Jahre Berechtigungen an, Entwickler haben Produktionszugriff und Dienstkonten laufen als Domain Admin. Dieser Guide zeigt wie echtes Least Privilege aussieht.

Warum Least Privilege so wichtig ist

Ein konkretes Angriffsszenario verdeutlicht den Unterschied:

Ohne Least Privilege: Eine Phishing-Mail erreicht Buchhalterin Maria. Malware installiert sich auf ihrer Workstation. Da ihr Account Mitglied in „Domain Users” und „IT-Support” ist (jemand hat sie für ein Ticket hinzugefügt), bewegt sich die Malware lateral mit Marias Rechten. Sie erreicht den Fileserver mit Kundendaten, die Testumgebung mit Admin-Zugang und von dort die Produktion.

Mit Least Privilege: Dieselbe Phishing-Mail erreicht Maria. Malware installiert sich auf ihrer Workstation. Marias Account hat nur Zugriff auf das Buchhaltungs-Share. Die Malware kommt nicht weiter. Es bleibt ein isolierter Vorfall ohne großen Datenverlust.

Fazit: Least Privilege begrenzt den Blast Radius eines Angriffs drastisch.

Häufige Least-Privilege-Verletzungen

Die folgenden Probleme treten in fast jeder Active Directory-Umgebung auf:

1. Zu viele Domain Admins: In der Realität befinden sich 20 oder mehr Accounts in der „Domain Admins”-Gruppe. Es sollten maximal 3-5 dedizierte Admin-Accounts sein - niemals Standard-User-Accounts.

2. Service Accounts mit Domain Admin: Der Satz „Der SQL Server braucht Domain Admin-Rechte” ist falsch. SQL Server benötigt nur das Recht, seinen Dienst zu starten und zu stoppen sowie Zugriff auf seine eigenen Datenbanken.

3. „Domain Admin für ein Ticket”: „Ich mache dir kurz Admin, dann kannst du das selbst lösen” - die Rechte werden nie wieder entzogen. Das ist der Ursprung von Privilege Creep.

4. Entwickler-Rechte in Produktion: „Wir brauchen manchmal Zugriff auf die Produktionsdatenbank zum Debuggen” ist kein Argument für permanente Produktionsrechte. Die Lösung ist ein dedizierter Read-Only-Zugriff, zeitlich begrenzt und vollständig geloggt.

5. Lokaler Admin auf Workstations: Alle Nutzer als lokale Administratoren bedeutet, dass sich Malware selbst installieren kann. Die Lösung: Standard User-Konten plus LAPS (Local Administrator Password Solution) für lokale Admin-Passwörter.

Umsetzung in Active Directory

# Wer ist in Domain Admins? (Audit)
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object {$_.objectClass -eq "user"} |
    Select-Object Name, SamAccountName, @{N="LastLogon";E={(Get-ADUser $_.SamAccountName -Properties LastLogonDate).LastLogonDate}} |
    Sort-Object LastLogon

# Inaktive Domain Admins finden
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties LastLogonDate, Enabled |
    Where-Object {$_.LastLogonDate -lt (Get-Date).AddDays(-90) -or !$_.Enabled} |
    Select-Object Name, LastLogonDate, Enabled

# Accounts in zu vielen Gruppen (Privilege Creep)
Get-ADUser -Filter * -Properties MemberOf |
    Select-Object Name, @{N="GroupCount";E={$_.MemberOf.Count}} |
    Sort-Object GroupCount -Descending |
    Where-Object {$_.GroupCount -gt 10}  # > 10 Gruppen = Warnsignal

# Just-In-Time-Admin via PAM (Entra ID)
# In Azure AD: Privileged Identity Management (PIM)
# Admins müssen Rollen aktivieren → nur für begrenzte Zeit aktiv
# Alle Aktivierungen sind geloggt und genehmigungspflichtig

Least Privilege für Anwendungen

Datenbankbenutzer

-- PostgreSQL: Read-only App-Account
CREATE USER appuser WITH PASSWORD '...';
GRANT CONNECT ON DATABASE myapp TO appuser;
GRANT USAGE ON SCHEMA public TO appuser;
GRANT SELECT ON customers, orders, products TO appuser;
-- KEIN INSERT/UPDATE/DELETE außer nötig!

-- Write-only für Logs
CREATE USER logwriter WITH PASSWORD '...';
GRANT INSERT ON audit_log TO logwriter;
-- Kein SELECT (kann keine Logs lesen)

Cloud IAM (AWS)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/uploads/*"
    }
  ]
}

Keine Wildcards (*) bei Actions oder Resources - jede erlaubte Aktion wird explizit aufgeführt.

Kubernetes Service Accounts

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-processor
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payment-processor-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get"]  # Nur lesen, kein schreiben/löschen!
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
  resourceNames: ["payment-api-key"]  # NUR spezifisches Secret!

Zero Standing Privileges (ZSP)

Der Unterschied zu traditionellen Ansätzen

Traditionell (Standing Privileges): Der Admin hat immer Zugriff auf die Produktion - eine ständige Angriffsfläche. Wenn der Account kompromittiert wird, hat der Angreifer sofortigen Produktionszugriff.

Zero Standing Privileges: Der Admin hat keine permanenten Rechte. Wenn Zugriff benötigt wird, stellt er einen Antrag, der genehmigt wird und zeitlich befristet ist. Nach Ablauf werden die Rechte automatisch entzogen.

Tools für ZSP

Microsoft Entra PIM (Privileged Identity Management): Aktivierung von Admin-Rollen mit Zeitlimit, genehmigungspflichtig und mit MFA-Pflicht. Alle Aktivierungen werden vollständig geloggt.

CyberArk PAM (Privileged Access Manager): Session-Recording aller Admin-Sitzungen und Just-in-Time-Credentials für Windows und Linux.

HashiCorp Vault: Dynamic Secrets generieren Datenbank-Credentials on demand - sie laufen nach der Nutzung automatisch ab. Es gibt kein festes Datenbankpasswort mehr das gestohlen werden könnte.

AWS IAM Access Analyzer: Analysiert wer auf was zugreifen kann und identifiziert ungewöhnliche oder übermäßige Berechtigungen.

Least Privilege Roadmap

Kurzfristig (1-4 Wochen)

Domain Admins auf maximal 5 Konten reduzieren
Lokale Admin-Rechte auf Workstations entfernen und LAPS einrichten
Service Accounts ohne Domain-Admin-Rechte identifizieren
Inaktive Konten deaktivieren

Mittelfristig (1-3 Monate)

Role-Based Access Control (RBAC) implementieren
Privilege-Creep-Audit: alle Gruppenmitgliedschaften prüfen
Applikations-Datenbankkonten einschränken
Cloud-IAM-Audit durchführen: zu breite Policies identifizieren?

Langfristig (3-12 Monate)

PAM-Lösung für privilegierte Zugriffe einführen
Just-In-Time-Access für Admin-Tätigkeiten implementieren
Dynamic Secrets für Anwendungen (HashiCorp Vault)
Regelmäßiges Access-Review einführen (quartalsweise)
Zero-Trust-Network-Architecture implementieren