Viele halten einen festen Zugangsschlüssel in der Konfigurationsdatei für eine ganz normale Lösung. Dabei ist genau das der schwerwiegendste Fehler beim Cloud-Zugriff.

Viele denken, der Schlüssel gehöre in die Konfiguration wie einst ein Datenbankpasswort. Plausibel, weil der Access Key (ein dauerhaftes Schlüsselpaar für den Zugriff per Programm) bequem ist: einmal eintragen, die Anwendung läuft.

Tatsächlich gilt: Ein geleakter fester Schlüssel bleibt gültig, bis jemand ihn widerruft. IAM (Identity and Access Management) regelt zwar, wer welche Handlungen auf welchen Ressourcen ausführen darf – ein hinterlegter Schlüssel umgeht jede kurzlebige Kontrolle. Stattdessen vergeben IAM-Rollen temporäre Anmeldeinformationen über den Dienst STS (Security Token Service, der kurzlebige Zugangsdaten ausstellt). Anwendungen auf EC2, ECS oder Lambda erhalten ihre Rechte über zugewiesene Rollen, nicht über fest hinterlegte Schlüssel.

Der Irrtum entsteht, weil die Rollen-Lösung unsichtbar arbeitet: Temporäre Zugangsdaten kommen automatisch über die Instanzmetadaten-Adresse. Der feste Schlüssel steht sichtbar da und funktioniert – bis er in einem Repository landet.

Ein typischer Fall: Eine Anwendung auf einem EC2-Server braucht Lesezugriff auf einen S3-Datenspeicher. Statt einen Schlüssel zu hinterlegen, hängt man der Instanz eine Rolle mit genau dieser Leseberechtigung an. Langlebige Schlüssel, die unvermeidbar bleiben, werden rotiert und möglichst durch Rollen oder Identity Center ersetzt.

Woran man es erkennt: In Konfigurationsdateien oder Umgebungsvariablen stehen dauerhafte Schlüsselpaare, deren letzte Prüfung niemand kennt.

Feste Schlüssel sind nicht der praktische Standard, sondern ein stehendes Restrisiko. Rollen geben kurzlebige Zugangsdaten – und was kurzlebig ist, ist nach dem Ablauf wertlos.

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