Bewährte Methoden für die sichere Verwaltung von Anmeldeinformationen mit der AWS CLI

AWS CLI-Anmeldeinformationen können echte Cloud-Ressourcen erstellen, löschen und offenlegen, daher ist ein durchgesickerter Zugriffsschlüssel kein kleiner Fehler. Die sicherste Einrichtung gibt Menschen kurzlebige Anmeldeinformationen über das IAM Identity Center und gibt Workloads temporäre Anmeldeinformationen über Rollen.

Diese Best Practices für die sichere Verwaltung von Anmeldeinformationen mit der AWS CLI erklären, wo die CLI nach Anmeldeinformationen sucht, wann Profile verwendet werden sollten und wie langlebige statische Schlüssel in Skripten vermieden werden können.

Verständnis der Reihenfolge des Ladens von AWS CLI-Anmeldeinformationen

Die AWS CLI löst Anmeldeinformationen über eine Anbieterkette auf. Die genaue Kette kann je nach CLI-Version und Konfiguration variieren, aber die praktische Reihenfolge, die Sie am häufigsten debuggen werden, ist:

Umgebungsvariablen: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und optional AWS_SESSION_TOKEN.
Assume-Role- und Web-Identity-Konfiguration: Profile, die der CLI mitteilen, AWS STS für temporäre Anmeldeinformationen aufzurufen.
IAM Identity Center-Anmeldeinformationen: Profile, die durch aws configure sso oder aws configure sso-session erstellt wurden.
Gemeinsame Anmeldeinformationsdatei: Normalerweise ~/.aws/credentials.
Gemeinsame Konfigurationsdatei: Normalerweise ~/.aws/config, einschließlich credential_process-Einträgen.
Container-Anmeldeinformationen: ECS-Aufgabenrollen und kompatible Container-Anmeldeinformationsendpunkte.
EC2-Instanzprofil-Anmeldeinformationen: Temporäre Anmeldeinformationen vom Instance Metadata Service (IMDS).

Die AWS CLI verwendet keine --access-key-id- oder --secret-access-key-Befehlszeilenflags für normale Befehle. Wenn Sie diese in einem Skript sehen, wird wahrscheinlich das Verhalten der AWS CLI mit einem anderen Tool oder SDK verwechselt.

1. Sichern von Anmeldeinformationen in Konfigurationsdateien (`~/.aws/credentials`)

Die gemeinsame Anmeldeinformationsdatei, normalerweise ~/.aws/credentials, ist praktisch, sollte aber ein Fallback für Fälle sein, in denen Sie IAM Identity Center oder Rollen nicht verwenden können. Wenn Sie dort statische Schlüssel speichern müssen, schützen Sie die Datei und halten Sie die Berechtigungen eng.

Dateischutz und Berechtigungen

Es ist wichtig, den Lesezugriff auf diese Datei einzuschränken. Auf Linux/macOS-Systemen setzen Sie die Berechtigungen so, dass nur der Eigentümer die Datei lesen oder schreiben kann:

chmod 600 ~/.aws/credentials

Verwendung von Profilen zur Trennung

Die Verwendung unterschiedlicher Profile ermöglicht es Ihnen, Anmeldeinformationen für verschiedene Umgebungen (z. B. Entwicklung, Staging, Produktion) oder verschiedene Konten zu trennen. Dies verhindert versehentliche umgebungsübergreifende Aktionen.

Beispiel ~/.aws/credentials:

[default]
aws_access_key_id = AKIAEXAMPLE000000000
aws_secret_access_key = exampleSecretAccessKeyDoNotUse

[production-user]
aws_access_key_id = AKIAEXAMPLE111111111
aws_secret_access_key = anotherExampleSecretDoNotUse

Bei Verwendung eines benannten Profils müssen Sie es mit dem Flag --profile angeben:

aws s3 ls --profile production-user

2. Nutzung von Umgebungsvariablen

Umgebungsvariablen stellen dem aktuellen Prozess und seinen Unterprozessen Anmeldeinformationen zur Verfügung, ohne AWS-Konfigurationsdateien zu bearbeiten. Sie sind nützlich für temporäre Sitzungen und CI-Jobs, können aber dennoch durch Prozessumgebungen, Debug-Protokolle oder nachlässige Shell-Historie durchsickern.

Setzen Sie die folgenden Variablen in Ihrer Shell-Sitzung:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export AWS_SESSION_TOKEN="temporary-session-token-if-using-sts"
export AWS_DEFAULT_REGION="us-east-1"

Wichtiger Hinweis zur Priorität: Über Umgebungsvariablen gesetzte Anmeldeinformationen überschreiben immer die in der Datei ~/.aws/credentials gefundenen, da sie in der Anmeldeinformations-Ladekette weiter oben erscheinen.

Sicherheitswarnung: Seien Sie vorsichtig beim Exportieren von Umgebungsvariablen, insbesondere in gemeinsam genutzten Terminals oder Skripten, die protokolliert werden könnten. Entfernen Sie sie immer sofort nach der Verwendung:
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

3. IAM-Rollen für AWS-Workloads bevorzugen

Für Workloads, die auf der AWS-Infrastruktur ausgeführt werden, wie EC2, Lambda, ECS und EKS, vermeiden Sie statische Anmeldeinformationen. Verwenden Sie IAM-Rollen, damit AWS automatisch temporäre Anmeldeinformationen ausgibt.

Auf EC2 stellt ein Instanzprofil temporäre Anmeldeinformationen über IMDS bereit. Auf ECS stellen Aufgabenrollen Anmeldeinformationen über den Container-Anmeldeinformationsendpunkt bereit. Auf EKS verwenden IAM-Rollen für Servicekonten Web-Identity-Tokens. Die AWS CLI und SDKs wissen, wie diese Anbieter verwendet werden, ohne langlebige Schlüssel auf der Festplatte zu speichern.

Wie es funktioniert:

Eine EC2-Instanz wird mit einer zugehörigen IAM-Rolle über ein Instanzprofil gestartet.
Die auf dieser Instanz ausgeführte CLI fragt den Instance Metadata Service (IMDS) nach temporären Anmeldeinformationen ab.
Die CLI verwendet diese temporären Anmeldeinformationen für alle nachfolgenden API-Aufrufe.

Dies eliminiert das mit langlebigen Zugriffsschlüsseln verbundene Risiko vollständig.

4. Verwenden Sie IAM Identity Center für den menschlichen Zugriff

Für Ingenieure, die die AWS CLI von Laptops aus verwenden, ist IAM Identity Center normalerweise sicherer als IAM-Benutzerzugriffsschlüssel. Sie melden sich über einen Browser an, wählen ein Konto und eine Rolle aus, und die CLI verwendet zwischengespeicherte kurzlebige Anmeldeinformationen.

Konfigurieren Sie es mit:

aws configure sso

Melden Sie sich dann an, wenn Ihre Sitzung abläuft:

aws sso login --profile <profile-name>

IAM Identity Center hieß früher AWS SSO, daher sehen Sie möglicherweise immer noch sso in CLI-Befehlen und Konfigurationsschlüsseln.

5. Verwenden Sie `credential_process` für externe Broker

Sie können die CLI so konfigurieren, dass sie ein externes Tool aufruft, z. B. einen Vault-Agenten oder einen Unternehmens-Anmeldeinformationsbroker, um Anmeldeinformationen dynamisch abzurufen. Dies wird in ~/.aws/config angegeben:

Beispiel ~/.aws/config:

[profile my-vault-profile]
region = us-west-2
credential_process = /usr/local/bin/my-vault-cli get-aws-creds --profile my-vault-profile

Diese Methode ist entscheidend bei der Integration mit Secrets-Management-Tools wie HashiCorp Vault.

Zusammenfassung der Best Practices und Checkliste

Um die Sicherheit Ihrer AWS CLI-Operationen zu maximieren, halten Sie sich an diese Kernprinzipien:

Prinzip der geringsten Privilegien: Stellen Sie sicher, dass alle IAM-Benutzer und -Rollen nur die Berechtigungen haben, die für die Ausführung ihrer Aufgaben unbedingt erforderlich sind.
Rollen gegenüber Schlüsseln bevorzugen: Verwenden Sie immer IAM-Rollen (Instanzprofile), wenn Sie innerhalb der AWS-Infrastruktur arbeiten.
IAM Identity Center verwenden: Für die interaktive Nutzung durch Menschen verwenden Sie IAM Identity Center, um den Zugriff auf mehrere Konten zu verwalten.
Schlüssel niemals hartcodieren: Vermeiden Sie es, Zugriffsschlüssel direkt in Skripte, Quellcode oder die Befehls-Historie zu setzen.
Anmeldeinformationsdatei schützen: Beschränken Sie Dateisystemberechtigungen (chmod 600) auf ~/.aws/credentials.
Schlüssel regelmäßig rotieren: Wenn statische Schlüssel verwendet werden müssen, erzwingen Sie einen strengen Rotationsplan.

Ihr Standard sollten temporäre Anmeldeinformationen sein: IAM Identity Center für Personen, IAM-Rollen für Workloads und credential_process für vermittelten Unternehmenszugriff. Verwenden Sie statische Zugriffsschlüssel nur, wenn es keine bessere Option gibt, begrenzen Sie sie dann eng, rotieren Sie sie und entfernen Sie sie, sobald die Abhängigkeit verschwunden ist.