Ein Entwickler hat versehentlich einen AWS-Zugriffsschlüssel in ein ÖFFENTLICHES GitHub-Repo gepusht. Was ist die richtige Reihenfolge der Reaktion?

Ein geleaktes Cloud-Anmeldeinformation ist ein Vorfall, bei dem die Uhr tickt. Automatisierte Bots scrapen kontinuierlich die öffentlichen GitHub-Events, und exponierte AWS-Schlüssel werden häufig genutzt, um innerhalb von Minuten nach dem Push Krypto-Mining-Flotten hochzufahren. Der Instinkt des Kandidaten muss Eindämmung vor Bereinigung sein.

Warum zuerst widerrufen und rotieren

Sobald ein Geheimnis in einem öffentlichen Commit landet, musst du es als kompromittiert betrachten — es lässt sich nicht beweisen, dass kein Bot es abgegriffen hat. Das Widerrufen (Deaktivieren/Löschen) und Rotieren des Zugriffsschlüssels schneidet jeden Angreifer ab, der ihn bereits besitzt. Erst wenn der aktive Schlüssel tot ist, wird untersucht: CloudTrail abrufen, um zu sehen, was der Schlüssel getan hat, nach unerwarteten API-Aufrufen, neuen IAM-Benutzern, gestarteten Instanzen oder Datenzugriffen suchen, dann das Geheimnis aus der git-Historie entfernen (etwa mit git filter-repo) und alle benachrichtigen, die das Repo geforkt haben.

Warum die Ablenker falsch sind

• Den Commit löschen. Das ist die klassische schwache Antwort. Einmal in ein öffentliches Repo gepusht, wurde der Commit wahrscheinlich bereits geklont, geforkt, von Scannern indexiert und von GitHubs eigener Event-API gecacht. Das Umschreiben der Historie macht das Geheimnis nicht ungeleakt — und vermittelt ein falsches Sicherheitsgefühl, während ein aktiver Schlüssel gültig bleibt.
• Das Repo privat machen und den Schlüssel weiter verwenden. Der Schlüssel war bereits öffentlich; das Umschalten der Repo-Sichtbarkeit ändert nichts an den bereits gezogenen Kopien. Einen geleakten Schlüssel weiterzuverwenden heißt, die Haustür offenstehen zu lassen.
• Die Schlüsseldatei in die .gitignore aufnehmen. .gitignore verhindert nur, dass zukünftige, nicht getrackte Dateien gestaget werden. Es hat null Wirkung auf ein bereits committetes und gepushtes Geheimnis.

Was der Interviewer ergründet

Er will sehen, dass du deine Maßnahmen nach Reduktion des Schadensradius ordnest: das Anmeldeinformation killen, dann untersuchen, dann bereinigen. Er will auch das situative Bewusstsein, dass öffentliche Exposition irreversibel ist, sodass die einzige sichere Annahme die vollständige Kompromittierung ist. Bonuspunkte für das Erwähnen kompensierender Kontrollen — Secret-Scanning vor dem Commit, kurzlebige Anmeldeinformationen über IAM-Rollen oder OIDC, und GitHub Push Protection — damit das nie wieder passiert.