Eine Zapier- oder Make-Automatisierung auf einen neuen Geokodierungs-Host migrieren
No-Code-Automatisierungen mit einem Geokodierungsschritt brauchen einen anderen Migrationsansatz als eigener Code. So gehen Sie bei diesem Wechsel vor.
Alte API-Schlüssel nach einer Migration sicher stilllegen
Den API-Schlüssel eines alten Anbieters stillzulegen, wirkt wie ein kleiner, fast schon administrativer Schritt am Ende einer Migration, doch ein falsches Timing kostet in beide Richtungen echtes Geld. Legen Sie ihn zu früh still, bevor jedes abhängige System tatsächlich umgezogen ist, bricht etwas, das den alten Schlüssel noch aufruft, unerwartet zusammen. Legen Sie ihn zu spät oder nie still, liegt ein ungenutztes, aber noch gültiges Zugangsdatum als Sicherheitsrisiko herum, das niemand aktiv im Blick hat.
Der sicherste Ablauf behandelt die Stilllegung von Schlüsseln als eigenes kleines Projekt mit festgelegter Reihenfolge, nicht als Nebensache, die ans Ende der eigentlichen Migrationsarbeit angehängt wird:
- Bestätigen Sie zuerst, dass über den alten Schlüssel kein Traffic mehr läuft, statt nur zu glauben, dass die Migration abgeschlossen ist. Die meisten Anbieter bieten eine gewisse Einsicht in die Nutzung eines Schlüssels; prüfen Sie diese direkt, statt anzunehmen, dass ein abgehakter Punkt auf der Migrations-Checkliste bedeutet, dass der alte Schlüssel in der Praxis tatsächlich verstummt ist.
- Lassen Sie den alten Schlüssel für ein festgelegtes Beobachtungsfenster gültig, aber ungenutzt, nachdem Sie die Migration für abgeschlossen halten, statt ihn in dem Moment zu deaktivieren, in dem der neue Anbieter live geht. Dieses Fenster, typischerweise einige Wochen je nach Ihren Traffic-Mustern und Release-Zyklen, fängt jede vergessene Aufrufstelle, jedes verzögerte Update einer mobilen App oder jeden selten laufenden Batch-Job ab, der noch auf die alten Zugangsdaten verweist.
- Deaktivieren Sie den alten Schlüssel zuerst, statt ihn zu löschen, sofern Ihr Anbieter diese Unterscheidung unterstützt. Ein deaktivierter Schlüssel, der als Datensatz noch existiert, lässt sich leichter kurzzeitig reaktivieren, wenn etwas Unerwartetes auftaucht, als ein vollständig gelöschter. Das gibt Ihnen während des Beobachtungsfensters einen Sicherheitspuffer, ohne es unbegrenzt zu verlängern.
- Löschen oder widerrufen Sie den alten Schlüssel vollständig an einem konkret festgelegten Datum und dokumentieren Sie, dass dies geschehen ist. Ein auf unbestimmte Zeit deaktivierter Schlüssel ist immer noch eine Angriffsfläche, die jemand reaktivieren könnte, falls das Konto selbst einmal kompromittiert wird; ein tatsächlich stillgelegtes Zugangsdatum sollte irgendwann endgültig entfernt werden und nicht in einem dauerhaften Schwebezustand verbleiben.
- Prüfen Sie, wo der alte Schlüssel gespeichert war, einschließlich Konfigurationsmanagementsystemen, Secrets-Managern, Dateien mit Umgebungsvariablen sowie jeglicher Dokumentation oder Onboarding-Materialien, die darauf verweisen könnten. Ein stillgelegter Schlüssel, der irgendwo noch als „der API-Schlüssel“ notiert ist, sorgt bei demjenigen, der diese Dokumentation als Nächstes liest, für Verwirrung, lange nachdem der Schlüssel selbst nicht mehr funktioniert.
Bei einer Migration zu My Geocode lässt sich der neue Schlüssel vom ersten Tag an eingrenzen und überwachen, mithilfe der Kontingent-Header in jeder Antwort, X-Quota-Used, X-Key-IPs-Used und weiteren, dokumentiert unter /docs/rate-limits/. So lässt sich einfach bestätigen, dass der neue Schlüssel tatsächlich den erwarteten Traffic trägt, bevor die Uhr für die Stilllegung des alten zu laufen beginnt. Die Stilllegung von Zugangsdaten so bewusst anzugehen, bedeutet ein wenig zusätzlichen Prozess für eine spürbare Verringerung sowohl des Betriebsrisikos als auch verbleibender Sicherheitslücken.