AWS Access Keys aufräumen als Reaktion auf ISMS: Umstieg auf rollenbasierte Authentifizierung

Dies ist ein Erfahrungsbericht darüber, wie im Zuge der Reaktion auf eine ISMS-Nachprüfung die im AWS-Konto angesammelten Access Keys überprüft und auf rollenbasierte Authentifizierung umgestellt wurden.

Hintergrund der Einführung

• In der IAM-Konsole zeigte sich, dass Access Keys an vielen Stellen verteilt waren (CI/CD, Deployment-Skripte, lokale Entwicklung usw.) und sich nur schwer nachverfolgen ließ, wo und wie sie verwendet wurden
• Access Keys bleiben ohne Ablaufdatum bestehen, und bei einer Kompromittierung werden die damit vergebenen Berechtigungen unverändert offengelegt, was ein hohes Risiko bedeutete
• Auch AWS empfiehlt statt langfristiger Anmeldedaten (Access Keys) die Nutzung temporärer Anmeldedaten (Rollen/STS)

Problem

• Da die Keys an verschiedenen Stellen kopiert und verwendet wurden, war die Frage „Wie weit reichen die Auswirkungen, wenn dieser Key kompromittiert wird?“ schwer zu beantworten
• Für eine Rotation mussten verteilte Konfigurationen gleichzeitig geändert werden, und weil bei einem IAM User Berechtigungen für mehrere Einsatzzwecke gebündelt waren, ließ sich das Prinzip der geringsten Rechte nur schwer anwenden
• Damals waren bei einem einzigen IAM User für CI/CD Berechtigungen für ECR/S3/SSM/ECS-Deployments und weitere Zwecke auf einmal konzentriert

Umgestellte Methode (Kurzfassung)

• Assume Role: Ein Verfahren, bei dem bei Bedarf temporär die Berechtigungen einer anderen Role übernommen werden
• OIDC Web Identity: Ein Verfahren, bei dem über die ID eines externen Systems wie GitHub Actions/EKS(=IRSA) eine Role ausgestellt wird
• Instance Profile: Ein Verfahren, bei dem einer EC2/Lambda direkt eine Role zugewiesen wird, sodass sie automatisch Berechtigungen erhält

Tatsächlicher Umstellungsprozess

• Schritt 1: Die Berechtigungen eines IAM Users mit weitreichenden Policies wurden in Roles nach Einsatzzweck aufgeteilt (ECR Push/Pull, ECS-Deployment, S3-Cache usw.)
• Schritt 2: OIDC auf GitHub Actions anwenden (Identity Provider registrieren → Repo-Bereich über Bedingungen in der Trust Policy einschränken → im Workflow configure-aws-credentials verwenden)

Wirkung

• Access Keys aus Code/Secrets entfernt; da auf temporären Tokens basierend, ist selbst bei einer Kompromittierung der Schadensumfang durch das Ablaufdatum begrenzt
• Der Aufwand für Key-Rotation entfällt, und die Nachverfolgbarkeit von Berechtigungen pro Workflow/Aufgabe wird klarer

Worauf zu achten ist

• Die Bedingungen in der Trust Policy nicht zu weit fassen, sondern auf den kleinstmöglichen Bereich beschränken (org/repo, wenn möglich bis hin zum Branch)
• Bestehende Access Keys nicht sofort löschen, sondern sie nach der Umstellung zunächst deaktivieren, eine Validierungsphase einplanen und erst dann löschen