Ein AWS Access Key besteht aus zwei Zeichenketten, mit denen ein Programm als IAM-Benutzer handeln kann: der Access Key ID, die den Schlüssel identifiziert, und dem Secret Access Key, der ihn beweist. Gesucht wird das Paar unter drei Namen, „access key and secret key“, „secret access key“ und schlicht „AWS secret key“. Gemeint ist immer dasselbe Paar. Es steht in CLI-Konfigurationen, in CI-Pipelines und viel zu oft in einer Slack-Nachricht.
Dieser Leitfaden erklärt, was die beiden Hälften sind, wie Sie sie erstellen und konfigurieren, wie Sie ohne Ausfall rotieren und was zu tun ist, wenn einer geleakt wird. Und er beantwortet die Frage, die jedes Mal kommt, wenn jemand neu im Entwicklerteam ist oder ein externer Dienstleister anfängt: Wie gibt man einer Person einen Secret Key, ohne ihn in eine E-Mail zu schreiben?
Access Key ID und Secret Access Key im Vergleich
| Access Key ID | Secret Access Key | |
|---|---|---|
| Sieht aus wie | AKIAIOSFODNN7EXAMPLE (20 Zeichen) | 40 Zeichen aus Groß- und Kleinbuchstaben und Sonderzeichen |
| Aufgabe | Zeigt an, welcher Schlüssel die Anfrage signiert | Signiert die Anfrage und beweist den Besitz |
| Geheim? | Nein, behandeln Sie sie wie einen Benutzernamen | Ja, behandeln Sie ihn wie ein Passwort |
| Später sichtbar? | Ja, in der IAM-Konsole | Nach der Erstellung nie wieder |
Langfristige Schlüssel beginnen mit AKIA. Temporäre Zugangsdaten aus STS, zu denen auch ein Session-Token gehört, beginnen mit ASIA und laufen von selbst ab. Wenn Sie einen ASIA-Schlüssel in einer Konfigurationsdatei finden, funktioniert er nach wenigen Stunden nicht mehr. Das ist so gewollt.
Keine der beiden Hälften vergibt Berechtigungen. Der Schlüssel authentifiziert sich als IAM-Benutzer, und die Richtlinien, die diesem Benutzer zugeordnet sind, legen fest, was diese Identität darf. Ein geleakter Schlüssel eines Benutzers mit reinen Leserechten ist ein Problem. Ein geleakter Schlüssel eines Administrators ist ein Sicherheitsvorfall.
Wann Sie überhaupt einen langfristigen Schlüssel brauchen
Ehrlich gesagt: seltener, als viele denken.
- Workloads auf AWS (EC2, Lambda, ECS, EKS) sollten IAM-Rollen nutzen. Das SDK holt sich automatisch kurzlebige Zugangsdaten, und es gibt nichts, was rotiert werden muss oder geleakt werden kann.
- Menschen sollten sich über IAM Identity Center oder föderiertes SSO anmelden und temporäre Zugangsdaten mit
aws sso loginbeziehen. - CI-Systeme wie GitHub Actions können über OIDC eine Rolle übernehmen, ganz ohne gespeicherten Schlüssel.
- Langfristige Schlüssel bleiben für die Fälle, in denen nichts davon geht: ein Tool auf einem Laptop ohne SSO-Unterstützung, ein Drittanbieterdienst, der nur statische Schlüssel akzeptiert, ein alter Job, den Sie noch nicht migriert haben.
Wenn Sie doch einen brauchen, erstellen Sie ihn für einen eigenen IAM-Benutzer mit der engsten Richtlinie, die für die Aufgabe reicht. Niemals für das Administratorkonto eines Menschen.
Einen Schlüssel erstellen und konfigurieren
Öffnen Sie in der IAM-Konsole den Benutzer, wählen Sie „Security credentials“ und dann „Create access key“. Wählen Sie den Anwendungsfall, nach dem AWS fragt, lesen Sie die vorgeschlagene Alternative und fahren Sie fort. Der Secret Key wird genau einmal angezeigt. Speichern Sie ihn direkt in Ihrem Secret Store oder Passwortmanager, oder laden Sie die CSV-Datei herunter und löschen Sie sie nach dem Import. Jeder IAM-Benutzer kann höchstens zwei Schlüssel gleichzeitig haben. Genau das macht die Rotation möglich.
Konfigurieren Sie auf einem Rechner ein benanntes Profil statt des Standardprofils:
aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1
Das schreibt ~/.aws/credentials und ~/.aws/config. Beschränken Sie die Datei mit chmod 600 auf Ihren Benutzer. Für Container und CI übergeben Sie AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY als Secrets aus dem Speicher der Plattform, nicht als normale Variablen in einer YAML-Datei. Und übergeben Sie sie nie auf der Kommandozeile, wo sie im Shell-Verlauf landen.
Rotieren, ohne etwas kaputtzumachen
Die Rotation läuft in vier Schritten ab, und sie funktioniert nur dank der Grenze von zwei Schlüsseln.
- Erstellen Sie den zweiten Schlüssel für denselben Benutzer.
- Stellen Sie alles, was den Schlüssel nutzt, auf den neuen um: Konfigurationen, CI-Secrets, den Eintrag im Secrets Manager. Die IAM-Konsole zeigt für jeden Schlüssel, wann er zuletzt verwendet wurde. Daran sehen Sie, ob Sie einen übersehen haben.
- Deaktivieren Sie den alten Schlüssel. Warten Sie einen Tag oder einen Deploy-Zyklus. Wenn etwas ausfällt, aktivieren Sie ihn wieder, korrigieren die betroffene Stelle und versuchen es erneut.
- Löschen Sie den alten Schlüssel, sobald ihn nichts mehr verwendet.
Rotieren Sie Schlüssel, die es geben muss, nach festem Zeitplan, und alle Schlüssel bei bestimmten Ereignissen: wenn jemand das Team verlässt, ein Dienstleister wechselt, ein Laptop verloren geht oder ein Leak vermutet wird. AWS Config und IAM Access Analyzer können Schlüssel markieren, die älter sind, als Ihre Richtlinie erlaubt.
Wenn ein Schlüssel offengelegt wurde
Ein Schlüssel, der in einem Repository, einem Log, einem Ticket oder einem Chat aufgetaucht ist, gilt als kompromittiert, auch wenn er eine Minute später gelöscht wurde. Scanner finden gepushte Secrets in Sekunden.
- Deaktivieren Sie den Schlüssel sofort in IAM. Warten Sie nicht erst auf den Ersatz, es sei denn, der Ausfall wäre schlimmer als die Offenlegung.
- Erstellen Sie einen Ersatz und stellen Sie alles um, was den alten Schlüssel nutzt.
- Durchsuchen Sie CloudTrail nach jeder Aktion, die seit der Offenlegung mit dieser Access Key ID ausgeführt wurde. Achten Sie auf neue IAM-Benutzer oder Schlüssel, neue Instanzen, geänderte Bucket-Richtlinien und ungewohnte Regionen.
- Prüfen Sie die Rechnung und den Cost Explorer auf Kostenspitzen, die nach Krypto-Mining aussehen.
- Entfernen Sie den Secret Key aus Code, Logs und der Git-Historie. Erkennt AWS ein öffentliches Leak, hängt es unter Umständen selbst die Richtlinie
AWSCompromisedKeyQuarantinean den Benutzer. Lassen Sie sie bestehen, bis die Bereinigung abgeschlossen ist. - Löschen Sie den alten Schlüssel. Finden Sie dann heraus, wie er dorthin gelangt ist, und schließen Sie diesen Weg.
Einen AWS Secret Key sicher an eine Person weitergeben
Manchmal muss der Schlüssel bei einem Menschen ankommen: bei einem externen Dienstleister, der ihn für ein Deployment-Tool braucht, bei jemandem, der in ein Projekt einsteigt, bevor SSO eingerichtet ist, oder bei einem Anbieter, dessen Integration den Schlüssel in das eigene Dashboard eingefügt haben will. E-Mail, Slack und Tickets bewahren Kopien auf, und ein Secret aus 40 Zeichen bleibt dort jahrelang lesbar.
Die sichere Routine dauert eine Minute:
- Erstellen Sie einen Schlüssel für diese Person auf einem eigenen IAM-Benutzer, mit genau der Richtlinie, die ihre Aufgabe erfordert, und nicht mehr. Geben Sie keinen Schlüssel weiter, den noch etwas anderes nutzt.
- Fügen Sie nur den Secret Access Key in einen Einmal-Link für Geheimnisse ein. Er wird in Ihrem Browser verschlüsselt, bevor er gespeichert wird. Die gespeicherte Kopie wird beim ersten Öffnen des Links gelöscht, und öffnet niemand den Link, läuft er nach einer Stunde, einem Tag oder einer Woche ab.
- Senden Sie den Link mit einer Zeile Kontext. Schicken Sie Access Key ID, Region und Profilnamen in einer separaten Nachricht. Für sich genommen ist keine dieser Angaben geheim.
- Setzen Sie mit einem Pro-Konto eine Passphrase für alles, was über reine Leserechte hinausgeht, und geben Sie sie per SMS oder am Telefon weiter.
- Lassen Sie sich bestätigen, dass der Link geöffnet wurde. Meldet der Link, dass er schon angesehen wurde, und die Person hat ihn nicht geöffnet, deaktivieren Sie den Schlüssel und fangen Sie von vorn an.
- Deaktivieren Sie den Schlüssel, wenn die Zusammenarbeit endet, und löschen Sie ihn danach.
Der Leitfaden zu API-Schlüsseln zeigt dasselbe Muster für andere Anbieter, und sicheres Teilen von Links für Entwickler erklärt, wie Sie die Übergabe beim Onboarding per Skript erledigen.