Die sichere Rotation von Credentials besteht nicht nur darin, einen neuen Schlüssel zu erzeugen. Jedes Secret stellt eine technische Abhängigkeit, einen Satz von Berechtigungen, einen Eigentümer sowie einen oder mehrere Nutzungspunkte dar. Werden diese Beziehungen nicht berücksichtigt, können Authentifizierungsfehler, unvollständige Integrationen oder Zugriffe entstehen, die länger als vorgesehen aktiv bleiben.
Das operative Ziel besteht darin, ein Credential zu ersetzen und dabei Unterbrechungen zu reduzieren, wenn der Anbieter den zeitweisen Parallelbetrieb von Credentials erlaubt. Dies ist keine allgemeingültige Zusicherung: Einige Aussteller unterstützen nur ein aktives Credential, oder Anwendungen erfordern möglicherweise einen Neustart, ein erneutes Deployment oder ein Änderungsfenster. Die Kontinuität hängt daher von den verifizierten Fähigkeiten des Anbieters und der Architektur jedes Verbrauchers ab.
Ein Credential ist eine Abhängigkeit mit Kontext
Dokumentieren Sie vor der Rotation, was das Secret autorisiert und wer davon abhängt. Ein API-Key, ein OAuth-Token, ein Service-Passwort, ein Zertifikat oder ein privater Schlüssel haben unterschiedliche Erneuerungs- und Widerrufsmechanismen. Alle Fälle lediglich als Umgebungsvariable zu behandeln, führt zu unzureichenden Plänen.
- Ausstellende Identität: Konto, registrierte Anwendung, Service Principal oder technischer Benutzer, der das Credential ausgestellt hat oder kontrolliert.
- Berechtigungen und Geltungsbereich: zugängliche Ressourcen, zulässige Vorgänge, Einschränkungen nach IP-Adresse, Audience, Scope oder Projekt.
- Verbraucher: Anwendungen, geplante Jobs, Konnektoren, Pipelines, Skripte und autorisierte externe Anbieter.
- Nutzungspunkt: Code, Konfigurationsverwaltung, Deployment-System, Automatisierungsmaschine oder manueller Prozess.
- Eigentümer: Team, das für die Genehmigung der Änderung, deren Tests und eine Rückabwicklung verantwortlich ist.
Das Ergebnis muss ein nachvollziehbares Inventar sein. Eine Liste von Werten genügt nicht: Speichern Sie aus Sicherheitsgründen Kennungen, logische Pfade und Verantwortliche, nicht das Secret im Klartext.
Vor der Änderung inventarisieren und klassifizieren
Suchen Sie in aktuellen und historischen Repositories, Konfigurationsdateien, Umgebungsvariablen, Deployment-Manifesten, CI/CD-Skripten, Automatisierungen, Dokumentationen, Tickets, Passwortmanagern und Konfigurationen von Team-Tools nach Secrets. Berücksichtigen Sie lokale Kopien, Vorlagen und Protokolle, die Header oder sensible Parameter erfasst haben könnten.
Klassifizieren Sie jeden Fund anhand von Kriterien, die eine Entscheidung über die Reihenfolge der Maßnahmen ermöglichen:
- Kritikalität: Auswirkungen auf Daten, Verfügbarkeit, Abrechnung, Administration oder Dritte.
- Offenlegung: öffentliches oder privates Repository, Chat, Protokoll, Gerät, Anbieter oder Person mit Zugriff.
- Rotationsfähigkeit: zwei parallel aktive Credentials, ein einzelnes aktives Credential, feste Ablaufzeit, sofortiger Widerruf oder verzögerte Verteilung.
- Abhängigkeit: Anzahl der Verbraucher, Ausführungszeitplan und Fehlertoleranz.
- Wiederherstellung: Möglichkeit, zum vorherigen Credential zurückzukehren, sowie die Bedingungen, unter denen diese Rückabwicklung gültig wäre.
Ein Credential mit administrativen Berechtigungen und ungewisser Offenlegung erfordert in der Regel eine vorrangige Reaktion. Ein anderes mit geringen Berechtigungen, isolierter Nutzung und nahe bevorstehendem Ablauf kann hingegen einen geplanten Austausch zulassen. Die Priorisierung muss zusammen mit den verfügbaren Nachweisen und den Personen dokumentiert werden, die das Restrisiko akzeptieren.
Den Austausch mit minimierter Unterbrechung planen
Wenn der Aussteller zwei parallel aktive Credentials zulässt, besteht das bevorzugte Muster darin, ein neues Credential zu erstellen, Verbraucher kontrolliert zu aktualisieren, zu validieren und das vorherige Credential zu widerrufen. Beschränken Sie die Berechtigungen der neuen Identität auf das erforderliche Minimum und wenden Sie, wenn möglich, Einschränkungen an, die der vorgesehenen Nutzung entsprechen.
- Definieren Sie Geltungsbereich, Verantwortliche, Zeitplan, Metriken und Erfolgskriterium.
- Stellen Sie das neue Credential aus, ohne die Berechtigungen gegenüber dem vorherigen zu erweitern, außer bei genehmigter Begründung.
- Stellen Sie es über den bereits autorisierten Konfigurationsmechanismus für jede Umgebung bereit und vermeiden Sie, es in Code, Tickets oder Nachrichten zu kopieren.
- Aktualisieren Sie einen Verbraucher oder eine Umgebung mit geringerem Risiko und führen Sie repräsentative Tests aus.
- Führen Sie das Deployment schrittweise bei den übrigen Verbrauchern durch und beobachten Sie Authentifizierung, Autorisierung, Latenz und funktionale Fehler.
- Widerrufen oder deaktivieren Sie das alte Credential gemäß dem Plan und prüfen Sie, dass die bekannten Abhängigkeiten weiterhin funktionieren.
Wenn nur ein aktives Credential vorhanden sein kann, bereiten Sie ein Änderungsfenster, Benachrichtigungen an Verbraucher, einen vorherigen Test mit einer gleichwertigen Identität – sofern vorhanden – und ein Wiederherstellungsverfahren vor. In diesem Szenario wäre es falsch, Unterbrechungsfreiheit zu versprechen: Das realistische Ziel besteht darin, Dauer, Auswirkungen und Verantwortlichkeiten einzugrenzen.
Ein Rückabwicklungsplan bedeutet nicht, das vorherige Secret unbegrenzt aufzubewahren. Legen Sie fest, wann es verwendet werden darf, wer dies autorisiert und wie lange. Bei Verdacht auf Offenlegung kann seine erneute Aktivierung das Risiko wieder einführen, das die Rotation ausgelöst hat.
Die Änderung validieren und die Entfernung mit begrenzten Nachweisen bestätigen
Die Validierung kombiniert gezielte Tests und Beobachtung. Testen Sie die kritischen Vorgänge jedes Verbrauchers: Authentifizierung, Lesen, Schreiben, asynchrone Prozesse, Token-Erneuerungen und Fehlerabläufe. Prüfen Sie außerdem, dass das neue Credential keine weitergehenden Berechtigungen als erforderlich besitzt.
Korrelieren Sie Deployments, Credential-Kennungen, sofern verfügbar, sowie Authentifizierungs- oder Auditprotokolle des Ausstellers. Untersuchen Sie Anstiege bei Antworten mit 401 und 403, Wiederholungsversuche, fehlgeschlagene Jobs und Volumenrückgänge, die auf einen vergessenen Verbraucher hinweisen können.
Das Ausbleiben von Ereignissen, die einem alten Credential zugeordnet sind, beweist für sich allein nicht, dass es nicht mehr verwendet wird. Es liefert lediglich Nachweise innerhalb der tatsächlichen Abdeckung der Protokolle, der auditierten Identitäten und Quellen, des beobachteten Zeitraums und der verfügbaren Aufbewahrung. Dokumentieren Sie diese Einschränkungen ausdrücklich. Die Entfernung gilt als operativ gestützt, wenn das Credential beim Aussteller widerrufen oder deaktiviert ist, die inventarisierten Verbraucher mit dem neuen Credential funktionieren und die verfügbare Beobachtung während des definierten Zeitraums keine zusätzlichen Abhängigkeiten erkennen lässt.
Getrennte Umgebungen und Zugriffe von Personen
Entwicklung, Tests und Produktion benötigen getrennte Identitäten oder Credentials. Ein Produktions-Secret zur Fehlerbehebung gemeinsam zu nutzen, beschleunigt zwar eine einzelne Aufgabe, beseitigt jedoch die Nachvollziehbarkeit und erweitert Berechtigungen. Die Trennung ist keine automatische Garantie: Sie muss von unterschiedlichen Berechtigungen, festgelegten Eigentümern und für die Umgebung geeigneten Bereitstellungsmechanismen begleitet werden.
Vermeiden Sie auch Credentials, die von mehreren Personen gemeinsam verwendet werden. Wenn ein menschlicher Zugriff unvermeidbar ist, bevorzugen Sie namentlich zugeordnete Identitäten, zeitlich begrenzte Berechtigungen und auditierbare Protokolle gemäß den Richtlinien der Organisation. Prüfen Sie Zugriffe durch Support, Beratung und Dritte auf demselben Niveau wie interne Zugriffe.
Architekturbeispiel: veröffentlichte Integration und Apification
Betrachten Sie eine hypothetische Architektur, in der eine Integration über Apification veröffentlicht wird, damit externe Verbraucher eine API aufrufen können. Dieses Design schreibt der Plattform keine konkreten Funktionen zu: Vor der Umsetzung muss das Team in der anwendbaren Dokumentation prüfen, welche Komponenten, Authentifizierungsmechanismen, Konfigurationen und Protokolle tatsächlich verfügbar sind.
Die empfohlene Trennung besteht aus vier Teilen: dem API-Verbraucher, dem veröffentlichten Integrationsendpunkt, einer vom Team kontrollierten Integrationslogik-Komponente und dem durch ein Credential geschützten Drittsystem. Der Verbraucher übermittelt dem veröffentlichten Endpunkt nur autorisierte Geschäftsparameter; er erhält weder das Credential des Drittsystems noch stellt er es bereit. Die Integrationslogik validiert die Anfrage, transformiert die erforderlichen Daten und führt den ausgehenden Aufruf an den Dritten aus.
Das Secret wird ausschließlich aus einem von der Organisation ausgewählten und verwalteten Secret-Bereitstellungsmechanismus in die Laufzeitumgebung dieser Logik eingebracht. Dies kann eine vom Deployment bereitgestellte Laufzeitvariable oder eine authentifizierte Abfrage eines Secret-Managers sein; die konkrete Option muss anhand der bestätigten Fähigkeiten der Umgebung bewertet werden. Die Logik liest das Secret zur Laufzeit, erstellt die Authentifizierung gegenüber dem Drittsystem und gibt an den veröffentlichten Endpunkt nur eine gefilterte Antwort zurück. So bleibt der Verbraucher vom Credential und von der ausgehenden Integration getrennt.
Für die Rotation wird zunächst das für die Logik verfügbare Secret aktualisiert, ein kontrollierter Aufruf getestet und die Authentifizierung gegenüber dem Drittsystem beobachtet. Wenn Schlüssel parallel aktiv sein können, kann die Logik auf den neuen Schlüssel wechseln, bevor der vorherige widerrufen wird. Protokollieren Sie keine Autorisierungs-Header, sensiblen Bodies oder Konfigurationswerte. Prüfen Sie außerdem, dass die Berechtigungen des veröffentlichten Endpunkts verhindern, dass ein Verbraucher die Integration als allgemeinen Zugriff auf das Drittsystem verwendet.
Reaktion auf eine Offenlegung und dauerhafte Kontrollen
Bewahren Sie bei einer Offenlegung minimale, nützliche Nachweise, identifizieren Sie das Secret, seinen Geltungsbereich und die offengelegten Orte und bewerten Sie das Risiko, es aktiv zu halten. Die Entscheidung zwischen zeitweisem Parallelbetrieb, sofortigem Widerruf oder einer zeitweisen Einschränkung von Berechtigungen muss auf einer dokumentierten Bewertung von Auswirkungen und Offenlegung beruhen. Ein möglicherweise kompromittiertes Credential bleibt während jedes Zeitraums des Parallelbetriebs ein Risiko.
Stellen Sie anschließend gegebenenfalls einen Ersatz aus, aktualisieren Sie Verbraucher, prüfen Sie Protokolle innerhalb ihrer verfügbaren Abdeckung und entfernen Sie den Wert aus den offengelegten Speicherorten. Gehen Sie nicht davon aus, dass das Löschen einer Datei oder Nachricht Kopien, Klone, Caches oder vorherige Zugriffe beseitigt. Leiten Sie Maßnahmen zur Behebung der Ursache ein: Erkennung von Secrets in Änderungen, Konfigurationsprüfungen, Ablaufzeiten, Inventarisierung von Eigentümern und ein erprobtes Rotationsverfahren.
Checkliste für eine sichere Rotation
- Hat jedes Secret einen dokumentierten Eigentümer, Aussteller, Berechtigungen, Verbraucher und Umgebungen?
- Wurde bestätigt, ob der Anbieter den Parallelbetrieb und den Widerruf von Credentials zulässt?
- Verfügt das neue Credential nur über die mindestens erforderlichen Berechtigungen?
- Werden Verbraucher schrittweise mit Funktionstests und beobachtbaren Signalen aktualisiert?
- Bleibt das Secret aus Code, Dokumentation, Protokollen und API-Antworten heraus?
- Berücksichtigt der Widerruf das Offenlegungsrisiko und nicht nur die operative Bequemlichkeit?
- Geben die Schlussfolgerungen zur Entfernung die Abdeckung und Grenzen der beobachteten Nachweise an?
- Gibt es Kontrollen zur Erkennung eines erneuten Auftretens und eine verantwortliche Person für die Pflege des Prozesses?