Der Schlüssel in der Konfigurationsdatei funktioniert monatelang, ohne dass jemand ihn prüft. Genau das ist das Problem.

Das Symptom kennt jeder Erstkontakt mit der Cloud: Ein Skript braucht Zugriff, also kopiert man einen festen Zugangsschlüssel (Access Key, ein dauerhaftes Schlüsselpaar aus ID und geheimem Schlüssel) in eine Datei. Es läuft, man vergisst es. Der Schlüssel bleibt wirksam, bis jemand ihn manuell sperrt.

Dahinter steht der Unterschied zwischen dauerhaften und temporären Anmeldedaten. Eine IAM-Rolle ist keine Person, sondern eine Identität, die man vorübergehend annimmt. STS (Security Token Service), der Dienst für kurzlebige Anmeldedaten, stellt dabei einen Zugangsschlüssel, ein Sitzungstoken und einen geheimen Schlüssel aus. Diese gelten nur begrenzt, oft in Stunden bis maximal etwa zwölf Stunden, und laufen danach von selbst ab.

Ein Beispiel aus dem Betrieb: Eine Anwendung auf einem EC2-Server (Amazons virtuelle Maschinen) braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel in die Konfiguration zu schreiben, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Die Anwendung bezieht ihre temporären Daten automatisch über die Instanzmetadaten-Adresse, ganz ohne hinterlegtes Geheimnis.

So prüft man es: Grep im Projekt nach Access-Key-ID-Mustern, typischerweise zwanzigstellige Zeichenketten. Findet sich einer in einer Datei, ersetzt man ihn durch eine Rolle und sperrt den Schlüssel.

Der zentrale Sicherheitsgewinn liegt im Verfall: Ein geleakter fester Schlüssel bleibt unbegrenzt nutzbar, abgelaufene temporäre Daten sind wertlos. Eine Rolle heißt nicht dauerhaftes Passwort, sondern verliehenes Recht auf Zeit.

📌 IAM-Rolle · Temporäre Anmeldedaten · Schlüssel-Rotation

📚 Cloud von Grund auf · Tag 3 von 30
#aws #CloudSecurity #devops