Deine App auf EC2 authentifiziert sich bei AWS mit einem langlebigen Access Key, der in die AMI eingebacken ist. Was ist das bessere Muster?
Kurzantwort
Ein in ein Image eingebackener statischer Key leakt leicht und lebt ewig, daher besteht die Lösung darin, die langlebige Anmeldung vollständig zu eliminieren: Hänge eine IAM-Rolle über ein Instance Profile an, das temporäre, automatisch rotierte Anmeldedaten liefert, ohne dass etwas eingebacken ist. Manuelle Rotation alle 90 Tage lässt zwischen den Rotationen weiterhin ein langlebiges Geheimnis in der AMI. Den Key in eine Umgebungsvariable zu verschieben macht ihn weder weniger statisch noch weniger geleakt. Ihn dem Ops-Team zu mailen verteilt die Exposition auf Postfächer und Archive.
Diese Frage trennt Kandidaten, die Geheimnisse verwalten, von denen, die sie eliminieren. Ein langlebiger, in eine AMI eingebackener Key ist ein klassisches Anti-Muster, und die starke Antwort entfernt das Geheimnis, statt es zu hüten.
Warum Instanzrollen das bessere Muster sind
Wenn du eine IAM-Rolle über ein Instance Profile anhängst, holt sich die EC2-Instanz temporäre Anmeldedaten vom Instance-Metadata-Service. AWS rotiert sie automatisch, mehrmals täglich, und sie laufen von selbst ab. Es gibt keinen Key, der ins Image eingebacken wird, keinen Key, der in einem Snapshot leakt, und keinen Key, der von Hand rotiert werden muss. Wird die Instanz außer Betrieb genommen, werden die Anmeldedaten einfach nicht mehr ausgestellt. Das verringert sowohl die Wahrscheinlichkeit einer Exposition als auch die Lebensdauer jeder Exposition, die doch passiert.
Warum die Distraktoren schwächer sind
- Manuell alle 90 Tage rotieren. Rotation verkleinert das Fenster, aber zwischen den Rotationen hast du weiterhin ein langlebiges, eingebettetes Geheimnis. Wer die AMI, einen Snapshot oder die laufende Platte kopiert, erhält einen Key, der monatelang gültig sein kann. Außerdem hängt es daran, dass ein Mensch daran denkt.
- In einer Umgebungsvariablen speichern. Das ändert, wo der statische Key lebt, nicht die Tatsache, dass er statisch, eingebettet und leakbar ist. Umgebungsvariablen sind eher noch leichter auszulesen (Prozesslisten, Crash-Logs, Kindprozesse).
- An Ops mailen. Nun lebt das Geheimnis in Posteingängen, Gesendet-Ordnern und Mail-Archiven mehrerer Personen. Das vervielfacht die Expositionsfläche und gehört zum Schlimmsten, was man mit einer Anmeldung tun kann.
Worauf Interviewer achten
Der Instinkt, die langlebige Anmeldung zu entfernen statt sie zu schützen, plus das Verständnis der Mechanik: Instance Profile zur Rolle, temporäre Anmeldedaten aus den Metadaten, automatische Rotation. Pluspunkte für einen realistischen Migrationsplan – Rolle anhängen, das SDK auf die Standard-Credential-Auflösung umstellen, Funktion bestätigen, dann den alten Key widerrufen und löschen.
Wahrscheinliche Anschlussfragen
- Wie bezieht die Instanz die Rollen-Anmeldedaten konkret, und wie oft werden sie rotiert?
- Wie sieht dein Migrationsplan aus, um den eingebackenen Key ohne Ausfall zu entfernen?
- Wie würdest du erkennen, dass ein langlebiger Key geleakt ist oder von einem unerwarteten Ort genutzt wird?