Offengelegte Secrets widerrufen und rotieren

Sobald bestätigt ist, dass Zugangsdaten offengelegt wurden, zählt die Geschwindigkeit – aber auch die richtige Reihenfolge. Wenn Sie einen Schlüssel abrupt deaktivieren, können Sie die Produktion beeinträchtigen, sofern Sie nicht zuvor verstehen, wovon er abhängt.

Das Ziel besteht darin, den Angreifer auszusperren und gleichzeitig legitime Workloads weiterlaufen zu lassen – idealerweise in einer einzigen eingeübten Abfolge.

Der erste Schritt bei einem offengelegten Access Key besteht darin, ihn zu deaktivieren, nicht ihn zu löschen. Wenn Sie den Schlüsselstatus auf Inactive setzen, funktioniert er sofort nicht mehr.

Wenn Sie ihn zunächst behalten (inaktiv), bleibt er für die forensische Korrelation in CloudTrail erhalten. Löschen Sie ihn erst, wenn die Untersuchung abgeschlossen ist.

Für legitime Verwendungen bedeutet Rotation, einen neuen Access Key auszustellen, jede Stelle zu aktualisieren, an der der alte verwendet wurde, und anschließend den kompromittierten Schlüssel zu deaktivieren.

Diese Reihenfolge verhindert einen Ausfall: Die neuen Zugangsdaten sind aktiv, bevor die alten deaktiviert werden. Überprüfen Sie immer zuerst, dass die Anwendung mit dem neuen Schlüssel funktioniert.

Durch die Deaktivierung eines langfristigen Schlüssels werden temporäre Zugangsdaten, die damit möglicherweise bereits erstellt wurden, nicht ungültig. Verwenden Sie für Rollen die IAM-Funktion revoke sessions. Sie fügt eine Deny-Richtlinie hinzu, die auf einem Zeitpunkt für den Ablauf der Token-Ausstellung basiert.

Dadurch werden alle aktiven Sitzungen ungültig, die älter als dieser Zeitpunkt sind, und die Tür für Zugangsdaten in den Händen des Angreifers wird zugeschlagen.

Ermitteln Sie vor der Rotation, wo sich das Secret befindet. CloudTrail zeigt, welche Dienste und IPs den Schlüssel verwendet haben.

Ein Secret, das an vielen Stellen fest im Code hinterlegt ist, zeigt genau, warum Hardcodierung gefährlich ist. Durch die Erfassung jedes Nutzers stellen Sie sicher, dass die Rotation kein vergessenes System beschädigt und keine Kopie des Secrets weiterhin verwendet wird.

AWS Secrets Manager speichert Secrets wie Datenbankpasswörter und API-Schlüssel und kann sie mithilfe einer Lambda-Funktion automatisch nach einem Zeitplan rotieren.

Durch die automatische Rotation ist ein offengelegtes Secret nur kurze Zeit nutzbar. Anwendungen rufen zur Laufzeit den aktuellen Wert ab, statt eine veraltete, fest codierte Kopie zu speichern.

Eine offengelegte Zugangsinformation kann häufig weitere Zugangsdaten zugänglich machen. Wenn ein Angreifer einen Schlüssel verwendet hat, um eine Datenbank zu lesen, sind möglicherweise auch die darin enthaltenen Datenbankpasswörter kompromittiert.

Rotieren Sie daher auch nachgelagerte Secrets. Gehen Sie die gesamte Kette durch: Jedes Secret, auf das der Angreifer möglicherweise zugreifen konnte, muss als offengelegt betrachtet und ersetzt werden.

Wenn AWS eine Offenlegung erkennt, kann der Dienst AWSCompromisedKeyQuarantineV2 an den Benutzer anhängen. Dadurch werden risikoreiche Aktionen verweigert, während Sie weiterhin untersuchen können.

Entfernen Sie die Richtlinie nicht einfach und gehen Sie weiter. Betrachten Sie sie als Hinweis darauf, dass Sie die eigentliche Behebung – Deaktivierung, Rotation und Überprüfung – noch durchführen müssen.

Rotation verhindert zukünftigen Missbrauch, macht aber bereits entstandenen Schaden nicht rückgängig. Verwenden Sie CloudTrail, um jede Aktion aufzulisten, die mit den kompromittierten Zugangsdaten ausgeführt wurde.

Machen Sie bösartige Änderungen rückgängig: Löschen Sie nicht autorisierte IAM-Benutzer, entfernen Sie Hintertürschlüssel und beseitigen Sie Ressourcen, die der Angreifer erstellt hat. Eindämmung und Bereinigung sind getrennte, notwendige Schritte.

Verringern Sie nach der Wiederherstellung das künftige Risiko. Ersetzen Sie langfristige Schlüssel durch temporäre rollenbasierte Zugangsdaten, aktivieren Sie die automatische Rotation von Secrets und integrieren Sie die Suche nach Secrets in Ihre CI/CD-Pipeline.

Die wirksamste Lösung ist architektonischer Natur: Wenn es kein statisches Secret gibt, das offengelegt werden kann, gibt es für einen Angreifer nichts zu finden.

Die Behebung ist erst abgeschlossen, wenn sie dokumentiert wurde. Halten Sie fest, welche Zugangsdaten rotiert wurden, was der Angreifer getan hat und welche Änderungen zurückgesetzt wurden.

Informieren Sie die im Runbook aufgeführten Beteiligten. Wenn regulierte Daten offengelegt wurden, erfüllen Sie Ihre Pflichten zur Meldung von Datenschutzverletzungen. Eine klare Dokumentation macht aus dem Vorfall eine Lernerfahrung und erfüllt spätere Audit-Anforderungen.

Wählen Sie die richtige erste Maßnahme.

Um ein durchgesickertes Zugangstoken zu behandeln, deaktivieren Sie den Zugriffsschlüssel (und bewahren Sie ihn für die forensische Analyse auf), wechseln Sie ohne Ausfall zu einem neuen Schlüssel und widerrufen Sie aktive Rollensitzungen, damit bereits ausgegebene temporäre Zugangsdaten ungültig werden. Ermitteln Sie zunächst alle Verbraucher, wechseln Sie nachgelagerte Secrets, auf die der Angreifer möglicherweise zugreifen konnte, und machen Sie bösartige Änderungen anhand von CloudTrail rückgängig. Verwenden Sie Secrets Manager für die automatische Rotation und wechseln Sie zu temporären, rollenbasierten Zugangsdaten, um solche Vorfälle künftig zu verhindern.