API-Zugangsdaten rotieren, ohne eine Datei-Integration zu unterbrechen

Was die Rotation von Zugangsdaten bedeutet und wann sie nötig ist

API-Zugangsdaten zu rotieren bedeutet, das von einer Integration verwendete Geheimnis zu ersetzen und zu prüfen, ob die autorisierten Prozesse mit dem neuen Wert funktionieren. Das kann eine geplante Änderung sein, eine Reaktion auf eine mögliche Offenlegung oder eine Maßnahme nach dem Ausscheiden einer Person mit Zugriff. Lege in jedem Fall Anlass und Umfang fest: Welche Zugangsdaten werden geändert, welche Systeme verwenden sie und wer koordiniert den Vorgang? Die Rotation allein ist keine umfassende Überprüfung der Berechtigungen.

Wenn eine Person keinen Zugriff mehr haben soll, ist es eine separate Maßnahme, ihre Berechtigungen zu widerrufen oder anzupassen. Das kann auch dann nötig sein, wenn sich die Zugangsdaten einer Anwendung nicht ändern. Umgekehrt stellt das Ersetzen eines Schlüssels nicht sicher, dass unnötige persönliche Zugriffe entfernt wurden. Halte beide Ziele im Plan getrennt. Bei Verdacht auf eine Offenlegung solltest du die Nutzung des betroffenen Geheimnisses vorrangig einschränken und dem Reaktionsverfahren deiner Organisation und des Anbieters folgen, statt auf ein reguläres Wartungsfenster zu warten.

• Geplante Änderung: Lege Verantwortliche, Umfang und Ausführungszeitraum fest.
• Verdacht auf Offenlegung: Behandle das Geheimnis als potenziell kompromittiert und kopiere es nicht in Abstimmungskanäle.
• Ausscheiden einer Person: Überprüfe auch individuelle Berechtigungen, nicht nur die technischen Zugangsdaten.

Alle Verbraucher ermitteln, bevor du das Geheimnis änderst

Beginne mit der aktuellen Dokumentation der konkreten API. Prüfe den Authentifizierungstyp, die Ausstellung und den Widerruf der Zugangsdaten, die damit verknüpfbaren Berechtigungen sowie die erwarteten Antworten bei ungültigen Zugangsdaten. Übertrage nicht einfach das Verfahren eines anderen Dienstes: Manche Anbieter stellen eine spezielle Rotationsoption oder ein zeitlich begrenztes Verfahren bereit. Das belegt jedoch nicht, dass deine API dieselbe Funktion bietet. Bei Apification können Integrationen REST API, OpenAPI, Webhooks, iframe und JavaScript verwenden. Prüfe in der jeweils geltenden Dokumentation, welche Methode für deine Integration zutrifft.

Ermittle anschließend alle Verbraucher des Geheimnisses. Das Inventar sollte Anwendungen und Umgebungen – zum Beispiel Test und Produktion – ebenso umfassen wie Worker, geplante Aufgaben, Import- oder Exportprozesse und Dienste, die außerhalb der üblichen Arbeitszeiten laufen. Suche auch nach doppelten Konfigurationen und alten Bereitstellungskopien. Ein unvollständiges Verzeichnis zeigt sich oft durch sporadische Fehler: Die Hauptanwendung funktioniert, aber eine nächtliche Aufgabe verwendet noch den alten Wert.

• Notiere für jeden Verbraucher die verantwortliche Person, die Umgebung, den Speicherort der Konfiguration und die Ausführungshäufigkeit.
• Berücksichtige Hintergrundprozesse und Replikate, die weiterhin aktiv sein könnten.
• Speichere den Wert der Zugangsdaten nicht im Inventar.

Ausstellung, Verteilung und eine mögliche Übergangsphase vorbereiten

Kläre vor der Änderung, wer neue Zugangsdaten ausstellen darf und wer die bisherigen entfernen kann. Lege fest, wie das Geheimnis geschützt verteilt wird, wie die Instanzen aktualisiert werden und wer die einzelnen Schritte überprüft. Nutze die von deiner Organisation bereits genehmigten Verfahren zur Verwaltung von Geheimnissen und zur Bereitstellung. Behandle E-Mail, Tickets oder Quellcode nicht als Speicher für Zugangsdaten. Falls es kein festgelegtes Verfahren gibt, vereinbare eines, bevor du das Geheimnis erzeugst oder verschiebst.

Frage den Anbieter ausdrücklich, ob während einer Übergangsphase zwei Zugangsdaten gleichzeitig gültig sein können, wie lange diese Überschneidung dauert und wie jedes davon widerrufen wird. Setze das nicht voraus: Die verfügbaren Informationen belegen nicht, dass Apification gleichzeitige Zugangsdaten, eine automatische Rotation oder eine Übergangsfrist unterstützt. Wenn die API keinen parallelen Übergang ermöglicht, plane ein abgestimmtes Zeitfenster, bestimme die dokumentierte Reihenfolge der Schritte und vereinbare, wie sich die Auswirkungen bei einem Fehler begrenzen lassen.

• Bestätige vor der Ausführung das aktuelle Verfahren anhand der offiziellen Dokumentation.
• Stelle sicher, dass die Verantwortlichen für Anwendung, Betrieb und API während der Änderung erreichbar sind.
• Erzeuge keine Zugangsdaten, ohne eine verantwortliche Person und einen bekannten Verbraucher dafür festzulegen.

Die Konfiguration kontrolliert aktualisieren

Sobald der Anbieter die Zugangsdaten ausgestellt hat und das Verfahren feststeht, aktualisiere die geschützte Konfiguration über den vorgesehenen Mechanismus. Vermeide es, die Zugangsdaten in ein Repository, ungeschützte gemeinsam genutzte Dateien oder Befehle aufzunehmen, die im Terminalverlauf gespeichert werden, oder sie in Debug-Protokolle zu schreiben. Prüfe außerdem, dass Fehlermeldungen keine Header, Parameter oder vertraulichen Werte ausgeben. Halte in Änderungs-Tickets den Status und die Uhrzeit jedes Schritts fest – niemals das Geheimnis oder Screenshots, aus denen es hervorgehen könnte.

Stelle die Änderung schrittweise bereit, sofern Architektur und Authentifizierungsmethode dies zulassen: zuerst für einen begrenzten Verbraucher, dann für die übrigen und zuletzt für die seltener ausgeführten Prozesse. Beobachte das Ergebnis jeder Phase, bevor du fortfährst. Wenn keine schrittweise Aktualisierung möglich ist, koordiniere die Änderung als einen zusammenhängenden Vorgang und teile mit, welche Dienste vorübergehend ausfallen könnten. Verwechsle eine vollständige Bereitstellung nicht mit einer Überprüfung: Ein Prozess kann korrekt starten und bei einer konkreten Dateioperation trotzdem scheitern.

• Aktualisiere alle vorgesehenen Umgebungen und bestätige, welche Instanzen die Konfiguration erhalten haben.
• Veröffentliche das Geheimnis nicht in Code, Protokollen, Unterhaltungen oder Supportanfragen.
• Setze die Änderung nicht fort, wenn ungeklärte Fehler auftreten oder eine Instanz noch eine ältere Konfiguration verwendet.

Den tatsächlichen Dateiablauf testen

Lege vor Beginn einen kleinen, repräsentativen Test fest. Prüfe zunächst, ob sich der Verbraucher authentifiziert und ob die API-Antwort der erwarteten Operation entspricht. Überprüfe anschließend die erforderlichen Mindestberechtigungen und führe einen begrenzten Lese- oder Schreibvorgang aus, je nachdem, was die Integration tut. Kontrolliere das Dateiergebnis und die Fehlerbehandlung; es reicht nicht, nur festzustellen, dass eine Anfrage eine Antwort erhalten hat. Verwende geeignete Testdaten und überschreibe keine echten Inhalte ohne Genehmigung.

Wiederhole die Prüfung für Verbraucher, die nicht denselben Ausführungszyklus wie die Hauptanwendung haben. Berücksichtige gegebenenfalls geplante Aufgaben, Worker und durch Webhooks ausgelöste Prozesse. Apification bietet Integrationen über API und Webhooks; seine Automatisierungsdienste umfassen Wiederholungsversuche, Verlauf und Statistiken. Diese Funktionen können bei der Überprüfung der Aktivität einer Integration helfen, ersetzen aber weder den Authentifizierungstest noch bestätigen sie allein, dass alle Verbraucher aktualisiert wurden. Halte beobachtbare Ergebnisse und den genauen Umfang des Tests fest.

• Authentifizierung: Die vorgesehenen Verbraucher werden mit den neuen Zugangsdaten akzeptiert.
• Autorisierung: Die Integration behält nur die für ihre Aufgabe erforderlichen Berechtigungen.
• Datei: Der vorgesehene Lese-, Schreib- oder Umwandlungsvorgang wird abgeschlossen und das Ergebnis lässt sich überprüfen.
• Asynchrone Prozesse: Es bleiben keine fehlgeschlagenen oder ausstehenden Aufgaben ungeprüft.

Die bisherigen Zugangsdaten erst nach Prüfung entfernen

Entferne die bisherigen Zugangsdaten nicht allein deshalb, weil der Hauptdienst antwortet. Vergleiche zuerst das Inventar mit den aktiven Instanzen und den während eines Beobachtungszeitraums ausgeführten Aufgaben. Der Zeitraum sollte zur Ausführungshäufigkeit der jeweiligen Verbraucher passen. Suche nach Anfragen, die weiterhin den alten Wert verwenden, sofern die API geeignete Protokolle bereitstellt, und prüfe, ob Worker vergessen wurden oder Bereitstellungen noch ausstehen. Wenn deine Einsicht nicht ausreicht, benenne diese Einschränkung und behaupte nicht, alle Verbraucher seien migriert.

Wenn die Nachweise und das dokumentierte Verfahren die Sicherheit bestätigen, widerrufe oder deaktiviere die bisherigen Zugangsdaten gemäß den Anweisungen des Anbieters. Halte Zeitpunkt und verantwortliche Person fest, aber nicht das Geheimnis. Bietet der Anbieter besondere Optionen an – etwa eine Rotationsfunktion oder eine zeitliche Begrenzung –, befolge seine aktuelle Dokumentation. Der Mechanismus einer Plattform ist keine allgemeingültige Regel. Die Rotation ändert Dateien nicht automatisch. Um Inhalte wiederherzustellen, kannst du bei Bedarf den Versionsverlauf von Cloud verwenden – als separate Maßnahme.

• Prüfe aktive Verbraucher und selten ausgeführte Prozesse, bevor du die Zugangsdaten widerrufst.
• Befolge das von der API dokumentierte Verfahren zum Entfernen der Zugangsdaten, statt zu improvisieren.
• Bestätige, dass die bisherigen Zugangsdaten nicht mehr benötigt werden, und halte die Entscheidung fest.

Wiederherstellung, häufige Fehler und Checkliste für das nächste Mal

Häufige Fehler sind vorhersehbar: ein zwischengespeichertes Geheimnis, ein vergessenes Replikat, eine geplante Aufgabe, die während des Tests nicht ausgeführt wurde, oder eine Bereitstellung, die nur einen Teil der Instanzen erreicht hat. Es kann auch passieren, dass die bisherigen Zugangsdaten widerrufen werden, bevor die Aktualisierung abgeschlossen ist. Lege im Voraus fest, wer die Bereitstellung stoppen darf, welche Anzeichen eine Pause erfordern und wie der Vorfall kommuniziert wird. Wird das Geheimnis als offengelegt betrachtet, stelle es nicht automatisch wieder her: Eine Wiederherstellung, die es erneut aktiviert, kann das Risiko wieder eröffnen.

Der Wiederherstellungsplan muss sich nach dem tatsächlichen Status der Zugangsdaten und dem Verfahren des Anbieters richten. Wenn die neuen Zugangsdaten nicht funktionieren, die bisherigen aber noch aktiv und nicht kompromittiert sind, kann die verantwortliche Person den Vorgang anhalten und das genehmigte Verfahren anwenden, um wieder einen betriebsfähigen Zustand herzustellen. Wurden die bisherigen Zugangsdaten offengelegt oder bereits widerrufen, setze nicht voraus, dass sie wiederhergestellt werden können. Fordere neue Zugangsdaten an oder befolge die Anweisungen des Dienstes. Dokumentiere zum Abschluss die Ursachen sowie die erledigten und offenen Schritte, ohne Geheimnisse oder sensible Daten zu speichern.

• Vorher: Dokumentation geprüft, Verbraucher erfasst, Verantwortliche erreichbar und Wiederherstellung abgestimmt.
• Währenddessen: geschützte Konfiguration, kontrollierte Bereitstellung, Dateitests und Überwachung asynchroner Prozesse.
• Danach: bisherige Zugangsdaten gemäß Verfahren entfernt, Ergebnis bestätigt und Notizen ohne Geheimnisse erstellt.
• Bei Unsicherheit: pausieren, nicht sensible Nachweise sichern und den Anbieter konsultieren, bevor Zugangsdaten widerrufen oder wiederhergestellt werden.

Häufige Fragen