Warum auch kostenloser Support echte Antworten verdient
Ein Support, der nur zahlenden Kunden durchdachte Antworten gibt, sagt kostenlosen Nutzern, dass ihre Fragen keine ordentliche Lösung wert sind.
Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der nie abläuft, ist genau auf die Weise bequem, die es leicht macht, seine Existenz zu vergessen. Er wird einmal erzeugt, in eine Konfigurationsdatei oder eine Umgebungsvariable eingetragen und funktioniert dann einfach weiter, auf unbestimmte Zeit, ohne dass jemand prüft, ob er das sollte. Jahre später hat die Person, die ihn erzeugt hat, das Unternehmen vielleicht verlassen, das Projekt, für das er angelegt wurde, ist vielleicht eingestellt, und der Schlüssel selbst liegt vielleicht auf einem vergessenen Server, in einem geleakten Repository oder in einem alten Backup, immer noch voll gültig, weil das System ihn nie aufgefordert hat nachzuweisen, dass er noch gebraucht wird.
Das ist ein reales, unterschätztes Sicherheitsproblem und kein hypothetisches. Schlüssel gelangen über eingecheckte Konfigurationsdateien nach außen, über Logs, die versehentlich einen Anfrage-Header erfasst haben, über alte Backups, die das Projekt überdauern, zu dem sie gehörten. Ein Schlüssel, der nie abläuft, bedeutet, dass jeder dieser Leckwege auf unbestimmte Zeit gefährlich bleibt, ohne einen natürlichen Punkt, an dem sich die Gefährdung von selbst schließt. Ein Schlüssel, der regelmäßig rotiert oder überprüft wird, begrenzt zumindest, wie lange ein bestimmtes Leck ausnutzbar bleibt, selbst wenn das Leck selbst nie entdeckt wurde.
Wir glauben nicht, dass die Lösung darin besteht, Ablaufdaten zu erzwingen, die Integrationen ohne Vorwarnung lahmlegen. Das tauscht ein Problem gegen ein anderes, ebenso frustrierendes ein: einen Schlüssel, der mitten im Produktivbetrieb nicht mehr funktioniert, wegen einer Rotationsrichtlinie, die niemand klar kommuniziert hat. Die Lösung sind Transparenz und Kontrolle, die Rotation zu einer bewussten, informierten Entscheidung machen, statt zu etwas, das entweder nie geschieht oder als ungeplante Überraschung kommt. Kontingent-Header in jeder Antwort, einschließlich der Anzahl der belegten IP-Plätze eines Schlüssels, liefern ein laufendes Signal dafür, ob das Nutzungsmuster eines Schlüssels noch dem entspricht, wofür er ursprünglich ausgegeben wurde. Genau diese Art von Information sollte eine regelmäßige Überprüfung auslösen: „Muss dieser Schlüssel noch existieren?“
Die verbreitete Branchengewohnheit, einen Schlüssel als dauerhafte, einmal installierte Zugangsberechtigung zu behandeln, rührt daher, dass die Bequemlichkeit bei der ersten Integration über die gesamte Lebensdauer dieser Zugangsberechtigung gestellt wird. Es ist am ersten Tag tatsächlich einfacher, einen Schlüssel zu erzeugen, den man nie wieder anfassen muss. Diese Bequemlichkeit fällt am Anfang an, und die Kosten, ein alter, unüberwachter, nie rotierter Schlüssel, der irgendwo als dauerhaftes Risiko liegt, werden auf einen künftigen Vorfall verschoben, an den am ersten Tag niemand denkt.
Wir halten es für die gesündere Voreinstellung, einen Schlüssel weniger als feste Installation und mehr als Zugangsberechtigung mit einer fortlaufenden Beziehung zum Konto zu behandeln: in Echtzeit sichtbar durch die Anfragen, die er stellt, regelmäßig überprüfbar und ohne Aufhebens widerrufbar, wenn ein Projekt, zu dem er gehörte, tatsächlich beendet ist. Nichts davon erfordert, irgendjemandem ein Ablaufdatum aufzuzwingen. Es erfordert, dass man leicht genug sehen kann, was ein Schlüssel tatsächlich tut, damit es nicht mehr der Weg des geringsten Widerstands ist, einen alten Schlüssel ewig liegen zu lassen.