Einführung in AWS-Sicherheit

AWS-Sicherheit für Entwickler:innen nutzen

Rahul Singh

Technical Product Manager

Kursvoraussetzungen

Grundkenntnisse in AWS-Sicherheit
Verständnis von Cloud-Computing-Konzepten
AWS-Sicherheits- und Kostenmanagement-Konzepte

Kurs-Titelkarte „AWS Security and Cost Management Concepts"

Kursziele

Identität: wer ruft an
Autorisierung: was darf erreicht werden
Secrets und Verschlüsselung: Daten schützen
Nachweise: was danach passiert ist

Vier nummerierte Bänder entlang einer Achse, je eines pro Kursbereich. Band 1, Identity, Kapitel 1. Band 2, Authorization, Kapitel 2. Band 3, Secrets and encryption, Kapitel 2 und 3. Band 4, Evidence, Kapitel 3. Ein oranger Pfeil links, mit „dieses Video", zeigt auf Band 1.

Dein Code wird über eine Pipeline ausgeliefert

Ein Links-nach-rechts-Fluss. Schritt 1: ein Kasten „Your pipeline" mit den Stufen Build, Test, Deploy. Schritt 2: ein Pfeil „git push" von einem Kasten „You". Schritt 3: ein orangefarbenes Badge unter der Pipeline, „its own identity". Ein Pfeil führt weiter zu einem Kasten „AWS".

Zuerst ein Begriff

Eine Pipeline automatisiert Build, Test und Deployment deines Codes
Sie läuft auf deinen Push, ohne Menschen im Loop

Ein Deploy scheitert — aus dem falschen Grund

Bei einer Code-Änderung: Wessen Berechtigungen werden wirklich geprüft?

Du pushst eine Änderung

Schritt 1 eines vertikalen Flusses. Ein Kasten „You", der eine Code-Änderung pusht.

Ein Deploy scheitert — aus dem falschen Grund

Bei einer Code-Änderung: Wessen Berechtigungen werden wirklich geprüft?

Du pushst eine Änderung
Deine Pipeline läuft

Ein vertikaler Fluss. Schritt 1: You pusht eine Code-Änderung. Pfeil nach unten zu Schritt 2: deine Pipeline führt das Deploy aus.

Ein Deploy scheitert — aus dem falschen Grund

Bei einer Code-Änderung: Wessen Berechtigungen werden wirklich geprüft?

Du pushst eine Änderung
Deine Pipeline läuft
Das Deploy stoppt: AccessDenied

Erster Impuls: „Ich prüfe mal meine eigenen Berechtigungen."

Ein vertikaler Fluss. Schritt 1: You pusht eine Code-Änderung. Schritt 2: deine Pipeline führt das Deploy aus. Schritt 3: AWS bewertet die Anfrage und gibt AccessDenied zurück.

Was wirklich passiert ist

Schritt 1 eines Links-nach-rechts-Flusses. Ein Kasten „You", dessen Beteiligung hier endet.

Du pushst. Deine Beteiligung endet hier

Was wirklich passiert ist

Ein Links-nach-rechts-Fluss. Ein Kasten „You", Pfeil zu „Your pipeline". Ein Badge „deploy-role" hängt unter der Pipeline.

Du pushst. Deine Beteiligung endet hier
Die Pipeline deployed und läuft unter einer Rolle, die euer Team erstellt hat

Was wirklich passiert ist

Ein Links-nach-rechts-Fluss von You zu Your pipeline zu AWS. Ein Badge „deploy-role" hängt unter der Pipeline, und eine gestrichelte, mit „checks" beschriftete Pfeillinie führt von AWS zurück zu diesem Badge, nicht zu You.

Du pushst. Deine Beteiligung endet hier
Die Pipeline deployed und läuft unter einer Rolle, die euer Team erstellt hat
AWS bewertet diese Rolle

Actor und Principal

Actor

Wer die Arbeit angestoßen hat.

Hier: du.

Ein Personen-Icon als Symbol für den Actor, der die Arbeit anstößt.

Actor und Principal

Actor

Wer die Arbeit angestoßen hat.

Hier: du.

Principal

Die Identität, die AWS bei Eingang der Anfrage bewertet.

Hier: die Rolle der Pipeline.

Ein Personen-Icon als Symbol für den Actor, der die Arbeit anstößt.

Ein Icon als Symbol für den Principal.

Actor und Principal

Actor

Wer die Arbeit angestoßen hat.

Hier: du.

Principal

Die Identität, die AWS bei Eingang der Anfrage bewertet.

Hier: die Rolle der Pipeline.

Lambda: Ausführungsrolle. ECS: Task-Rolle. Neuer Name, gleicher Principal
Ausnahme: ein langlebiger Schlüssel in deinem Terminal, dann ist der IAM-User der Principal

Ein Personen-Icon als Symbol für den Actor, der die Arbeit anstößt.

Ein Icon, das zeigt, dass AWS den Principal statt des Actors prüft.

Gleiches Deploy, zwei Rollen

Rolle A (Die Form von AdministratorAccess)

Jeden Bucket lesen
Jeden Key verwenden
Jede Funktion aktualisieren

Rolle B

Einen Bucket lesen
Einen Key verwenden
Eine Funktion aktualisieren

Prefix: ein ordnerähnlicher Pfad in einem Bucket

Ein Bild mit einer All-Access-Rolle mit Zugriff auf sechs verschiedene Richtlinien.

Ein Bild mit einer eng gefassten Rolle mit Zugriff auf nur eine Richtlinie.

Schadensradius

Breite Rolle

Bei Kompromittierung: erreicht jeden Bucket, jedes Prefix und jedes Objekt im Account.

Schmale Rolle

Bei Kompromittierung: erreicht ein Prefix in einem Bucket. Nicht mehr.

Konzentrische Ringe, die eine breite Rolle zeigen, die jeden Teil des gesamten Accounts erreicht.

Konzentrische Ringe, die zeigen, dass eine schmale Rolle nur die innersten Objekt- und Prefix-Ringe erreicht; andere Teile bleiben unberührt.

Prinzip der geringsten Rechte, praktisch

Eine Rolle soll genau das tun, was ihr Auftrag erfordert, und kaum mehr.

AWS-verwaltet, z. B. AmazonS3ReadOnlyAccess: jeder Bucket. Customer-managed: deine, bis hinunter zu einem Prefix
Umfang und Lebensdauer: kurzlebige Anmeldedaten statt langlebiger Schlüssel
AWS sichert die Infrastruktur
Wie breit deine Rollen sind, entscheidest du — und das liegt in deinem Repository

Beispiel: eine Rolle zum Lesen des Reports-Buckets Zwei Allows. Sonst nichts gewährt.

Nichts zu IAM, dem Dienst, der entscheidet, wer was darf

Die Berechtigungsliste einer Rolle mit drei überflüssigen Rechten rot durchgestrichen und zwei erforderlichen Rechten grün markiert.

Lass uns üben!

AWS-Sicherheit für Entwickler:innen nutzen