MSP-FAQ: Menschlichen und maschinellen Zugriff mandantenübergreifend trennen

MSPs, die Technikerzugriffe und Automatisierung über Dutzende Kunden-Mandanten hinweg koordinieren, stehen vor einer spezifischen Ausprägung eines wachsenden Branchenproblems: Nicht-menschliche Identitäten – Servicekonten, API-Schlüssel, Automatisierungs-Tokens – müssen anders gesteuert werden als die Menschen, die sie anlegen.

Warum NHIs eine getrennte Governance brauchen

Das Projekt Non-Human Identity Top 10 von OWASP stellt fest, dass Maschinenidentitäten nicht intrinsisch an eine Person gebunden sind und dass gängige menschliche Sicherheitskontrollen wie MFA sich nicht sauber auf sie übertragen lassen. Die Diskrepanz betrifft vor allem den Lebenszyklus: Wenn ein Techniker geht, wird sein Konto meist innerhalb von Stunden deaktiviert, doch die von ihm angelegten Servicekonten und API-Schlüssel können mit vollen Berechtigungen weiterlaufen, sofern sie niemand ausdrücklich findet und widerruft. Da nicht-menschliche Identitäten in modernen Umgebungen die menschlichen Konten deutlich übersteigen können, lässt ein MSP, der beide gleich behandelt, faktisch seine größte Identitätspopulation unverwaltet.

Kurzlebig statt dauerhaft

Die durchgängige Empfehlung von OWASP und der Cloud Security Alliance lautet, langlebige Geheimnisse durch kurzlebige, automatisch ablaufende Tokens zu ersetzen, statt Zugangsdaten zu verwenden, die nach der Ausstellung unbegrenzt funktionieren. Ein geleaktes langlebiges Token gibt einem Angreifer unbegrenzt Zeit; ein Token, das nach Minuten bis Stunden abläuft, begrenzt den Schaden selbst im Fall eines Lecks.

Was das im Mandantenmodell eines MSP bedeutet

• Getrennte Identitätsanbieter oder Service-Prinzipale für menschliche Techniker und Automatisierung verwenden.
• Ein Break-Glass-Zugang eines Technikers darf niemals zugleich als Service-Zugang einer Pipeline dienen.
• Maschinen-Tokens an einen einzelnen Kunden-Tenant binden – niemals einen dauerhaften Schlüssel ausstellen, der alle Tenants umfasst.
• Token-Lebensdauern in Minuten bis Stunden bemessen und bei jedem Personal- oder Automatisierungswechsel rotieren.
• Die Identitätsklasse (menschlich oder nicht-menschlich) zusammen mit der Tenant-ID in jedem Zugriffsprotokoll erfassen.

Die Lösung ist kein einzelnes Werkzeug, sondern eine Governance-Gewohnheit: Automatisierung als eigene Identitätspopulation behandeln, mit eigenem Least-Privilege-Scope pro Tenant, statt als Erweiterung des Technikers, der sie eingerichtet hat.

Quellen: OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.