Identität, Ressource und Grenze

AWS-Sicherheit für Entwickler:innen nutzen

Rahul Singh

Technical Product Manager

Welche Richtlinie entscheidet?

Die Änderung, die nichts ändert

  • Kapitel 1: explizit verweigern oder kein Allow
  • Hier: eine dritte Ursache

Eine Anfrage trifft auf drei Richtlinienprüfungen, mit einem Fragezeichen an der Stelle der Entscheidung.

AWS-Sicherheit für Entwickler:innen nutzen

Welche Richtlinie entscheidet?

Bis zu drei Ebenen

  1. Identitätsrichtlinie auf dem Aufrufer
  2. Ressourcenrichtlinie auf der Ressource
  3. Grenze oben, zieht nur ab

Im eigenen Account reicht eine erlaubende Richtlinie

Von jeder getroffenen Ebene verweigert

Eine Anfrage fließt von oben nach unten durch drei Prüfungen in Reihenfolge: Identitätsrichtlinie, Ressourcenrichtlinie und Berechtigungsgrenze, bevor sie erlaubt wird.

AWS-Sicherheit für Entwickler:innen nutzen

Zwei Orte, an denen eine Richtlinie leben kann

Identitätsbasierte Richtlinie

  • Am Aufrufer angehängt
  • Was diese Identität darf
  • Ein Ausweis, den du trägst

Oben trägt eine Rolle eine identitätsbasierte Richtlinie, darunter ist Platz für die Ressourcenseite derselben Anfrage.

AWS-Sicherheit für Entwickler:innen nutzen

Zwei Orte, an denen eine Richtlinie leben kann

Identitätsbasierte Richtlinie

  • Am Aufrufer angehängt
  • Was diese Identität darf
  • Ein Ausweis, den du trägst

Ressourcenbasierte Richtlinie

  • An der Ressource angehängt
  • Wer sie anfassen darf
  • Nötig für aufrufende Fremd-Accounts

Oben trägt eine Rolle eine identitätsbasierte Richtlinie, unten trägt ein S3-Bucket eine ressourcenbasierte Richtlinie, und dazwischen verläuft eine Anfrage.

AWS-Sicherheit für Entwickler:innen nutzen

Für dich verwaltet – oder von dir

Zwei Arten identitätsbasierter Richtlinien

  • Von AWS verwaltet: gehört AWS
  • Vom Kunden verwaltet: gehört dir

Zwei Karten vergleichen eine von AWS verwaltete Richtlinie (gehört AWS, standardmäßig breit) mit einer kundenverwalteten Richtlinie (gehört dir, auf die Aufgabe zugeschnitten).

AWS-Sicherheit für Entwickler:innen nutzen

Für dich verwaltet – oder von dir

Zwei Arten identitätsbasierter Richtlinien

  • Von AWS verwaltet: gehört AWS
  • Vom Kunden verwaltet: gehört dir

 

Bequemlichkeit oder Präzision

  • Von AWS verwaltet: schnell vorankommen
  • Vom Kunden verwaltet: Least Privilege

Zwei Karten vergleichen eine von AWS verwaltete Richtlinie (gehört AWS, standardmäßig breit) mit einer kundenverwalteten Richtlinie (gehört dir, auf die Aufgabe zugeschnitten).

AWS-Sicherheit für Entwickler:innen nutzen

Eine Grenze deckelt, was eine Richtlinie gewährt

Warum ein Account eine anfügt

  • Devs erstellen Rollen, niemand eskaliert

Berechtigungsgrenze

  • Eine Obergrenze für gewährte Rechte
  • Effektiv: erlaubt von beiden

Drei von einer Identitätsrichtlinie gewährte Berechtigungen passieren eine Berechtigungsgrenze, die nur S3-Aktionen erlaubt; die Berechtigung iam:CreateUser wird gestoppt, die anderen zwei gehen in die effektiven Berechtigungen über.

AWS-Sicherheit für Entwickler:innen nutzen

Eine Grenze deckelt, was eine Richtlinie gewährt

Warum ein Account eine anfügt

  • Devs erstellen Rollen, niemand eskaliert

Berechtigungsgrenze

  • Eine Obergrenze für gewährte Rechte
  • Effektiv: erlaubt von beiden

Warum iam:CreateUser nichts bewirkte

  • Zieht nur ab, gewährt nie

Drei von einer Identitätsrichtlinie gewährte Berechtigungen passieren eine Berechtigungsgrenze, die nur S3-Aktionen erlaubt; die Berechtigung iam:CreateUser wird gestoppt, die anderen zwei gehen in die effektiven Berechtigungen über.

AWS-Sicherheit für Entwickler:innen nutzen

Eine Grenze deckelt, was eine Richtlinie gewährt

Warum ein Account eine anfügt

  • Devs erstellen Rollen, niemand eskaliert

Berechtigungsgrenze

  • Eine Obergrenze für gewährte Rechte
  • Effektiv: erlaubt von beiden

Warum iam:CreateUser nichts bewirkte

  • Zieht nur ab, gewährt nie

Sitzungsrichtlinie: eine AssumeRole-Sitzung

Drei von einer Identitätsrichtlinie gewährte Berechtigungen passieren eine Berechtigungsgrenze, die nur S3-Aktionen erlaubt; die Berechtigung iam:CreateUser wird gestoppt, die anderen zwei gehen in die effektiven Berechtigungen über.

AWS-Sicherheit für Entwickler:innen nutzen

Eine Bedingung verengt das Allow

Bedingungsschlüssel

  • Verengt ein Allow auf den Kontext der Anfrage

  • aws:SourceIp: das Herkunftsnetz

Eine Erlaubnis zum Lesen eines S3-Objekts passiert ein Bedingungsband mit Quellnetz-Schlüssel und Aufrufer-Tag-Schlüssel und teilt sich dann in einen erlaubten Pfad (Kontext passt) und einen verweigerten Pfad (Kontext passt nicht).

AWS-Sicherheit für Entwickler:innen nutzen

Eine Bedingung verengt das Allow

Bedingungsschlüssel

  • Verengt ein Allow auf den Kontext der Anfrage

  • aws:SourceIp: das Herkunftsnetz

  • aws:PrincipalTag: ein Tag am Aufrufer

ABAC: Attribut-basierte Zugriffskontrolle

  • Eine Richtlinie, viele Principals

Eine Erlaubnis zum Lesen eines S3-Objekts passiert ein Bedingungsband mit Quellnetz-Schlüssel und Aufrufer-Tag-Schlüssel und teilt sich dann in einen erlaubten Pfad (Kontext passt) und einen verweigerten Pfad (Kontext passt nicht).

AWS-Sicherheit für Entwickler:innen nutzen

Eine Tabelle, jeweils ein Mandant

Eine gemeinsame Tabelle

  • DynamoDB, ein Partition Key pro Mandant
  • Allein keine Isolation

Ein Aufrufer von Mandant A passiert eine führende-Schlüssel-Bedingung in eine gemeinsame DynamoDB-Tabelle; Zeilen von Mandant A werden zurückgegeben, B und C blockiert.

AWS-Sicherheit für Entwickler:innen nutzen

Eine Tabelle, jeweils ein Mandant

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Eine gemeinsame Tabelle

  • DynamoDB, ein Partition Key pro Mandant
  • Allein keine Isolation

Eine Bedingung verengt sie

  • ForAllValues: jeder angegebene Schlüssel muss passen
AWS-Sicherheit für Entwickler:innen nutzen

Eine Tabelle, jeweils ein Mandant

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

Eine gemeinsame Tabelle

  • DynamoDB, ein Partition Key pro Mandant
  • Allein keine Isolation

Eine Bedingung verengt sie

  • ForAllValues: jeder angegebene Schlüssel muss passen
Die Lücke: Nicht jede Anfrage nennt eine Partition
  • dynamodb:Scan liefert keine, daher kann nichts fehlschlagen
AWS-Sicherheit für Entwickler:innen nutzen

Lass uns üben!

AWS-Sicherheit für Entwickler:innen nutzen

Preparing Video For Download...