Dienstzugriff mit IAM autorisieren

Bereitstellen von Anwendungen auf AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Der Schlüssel im Commit

Ein langlebiger Zugriffsschlüssel wird in ein Repo committet
Ein Scanner-Bot findet ihn und treibt die Kosten hoch
Rollen und Least Privilege verhindern das

Ein AWS-Zugriffsschlüssel, der versehentlich in einem Commit geleakt wurde und als Sicherheitsrisiko markiert ist

IAM-Principals: Benutzer, Rollen und Richtlinien

IAM-Dreispalten-Diagramm: Principal (Benutzer, Dienst oder Rolle) links, Policy-Dokument mit Allow/Deny-Aktionen in der Mitte, IAM-Rolle mit kurzlebigen temporären Anmeldedaten rechts

Principal: wer stellt die Anfrage
Policy: ein JSON-Dokument, das Berechtigungen erteilt
Role: ein Berechtigungssatz, den eine Entität annehmen kann
Rollen werden angenommen; Benutzer haben langlebige Anmeldedaten

Programmatic credentials richtig umgesetzt

Lambda: eine Ausführungsrolle gewährt Berechtigungen
EC2: ein Instance Profile liefert Rollenanmeldedaten
ECS: Task-Rollen begrenzen Berechtigungen pro Task
Keine langlebigen Zugriffsschlüssel in Code oder Config

Drei AWS-Compute-Services nutzen Rollen ohne langlebige Schlüssel: Lambda mit Ausführungsrolle, EC2 mit Instance Profile und ECS mit Task-Rolle, jeweils mit automatischem Credential-Rotation

AssumeRole und STS

STS AssumeRole: temporäre Anmeldedaten für eine Rolle erhalten
Wird für Cross-Account-Zugriff genutzt
Die Trust-Policy steuert, wer die Rolle annehmen darf
Anmeldedaten sind kurzlebig und laufen automatisch ab

STS AssumeRole Cross-Account-Flow: Aufrufer in Account A fordert Anmeldedaten bei STS an, Trust-Policy der Rolle in Account B erlaubt es, STS gibt kurzlebige Anmeldedaten zurück, die automatisch ablaufen

Least Privilege und Policy-Struktur

Eine Policy-Anweisung hat drei Pflichtteile (Effect, Action und Resource) plus eine optionale Condition:

{
  "Effect": "Allow",
  "Action": "dynamodb:PutItem",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders",
  "Condition": {
    "Bool": { "aws:SecureTransport": "true" }
  }
}

Wo IAM aufhört und dein Code beginnt

IAM: die Service-Ebene

Autorisiert AWS-API-Aufrufe: darf diese Rolle diese Operation ausführen?
Erzwingt keine mandanten- oder datensatzbezogenen Regeln

Dein Code: die Datenebene

Prüft den authentifizierten Benutzer gegen die angeforderten Daten
Beides nutzen: IAM schützt den Service, dein Code die Daten

Least-Privilege-Ausführungsrolle in der Praxis

Minimale Lambda-Ausführungsrolle: einzelne DynamoDB-PutItem-Berechtigung nur für eine Tabellen-ARN gewährt, ohne Wildcards bei Aktion oder Ressource

Eine Lambda muss in eine DynamoDB-Tabelle schreiben
Gewähre dynamodb:PutItem nur auf die ARN dieser Tabelle
Keine Wildcards bei Aktion oder Ressource
Mehr nur hinzufügen, wenn ein echter Aufruf verweigert wird

Lass uns üben!

Bereitstellen von Anwendungen auf AWS