Hallo und willkommen zurück.
Im heutigen Video werden wir über die Ursprungs-Zugangsidentität in der Cloud Front sprechen.
Eine der Herausforderungen bei einer Cloud-basierten Architektur ist, dass die Sicherheitsmaßnahmen, die Sie
auf Cloud-Ebene anwenden, leicht umgangen werden können, wenn ein Angreifer die Anfrage direkt an den Ursprung
sendet.
Sie befinden sich zum Beispiel auf der Ebene der Wolkenfront.
Sie haben einen bestimmten Geobeschränkungsfilter angewendet, der Anfragen aus Land A und Land B
blockiert. Wenn also ein Nutzer aus Land A oder B eine Anfrage an den Cloud-Freund sendet, wird diese
Anfrage automatisch blockiert.
Der Angreifer kann nun die Anfrage nicht an die Cloud-Front senden, denn er weiß, dass Sie eine Cloud für
die Verteilung haben und dass es einen Ursprung geben muss, an den der Cloud-Freund
die Anfrage senden muss.
Anstatt die Anfrage an die Cloud-Front zu senden, beschließt der Angreifer also, eine Anfrage direkt an
den Ursprung, d. h. den S3-Bucket, zu senden.
Und da die Anfrage direkt an den S3-Bucket gesendet wird, werden alle Einschränkungen, die Sie auf der Cloud-Frontebene
vorgenommen haben, einfach umgangen.
Und das ist etwas, was Sie in Produktionsumgebungen nicht wirklich wollen.
Um dies zu überwinden, können Sie eine Funktion nutzen, die als Cloud Print, Origin, Access Identity bezeichnet
wird und sicherstellt, dass der S3-Bucket, den Sie haben, nur die Anfrage von der Cloud Front erhält, falls ein Angreifer
versucht, eine Anfrage direkt an den S3-Bucket zu senden, wird diese Anfrage abgelehnt.
Im Bucket haben Sie also auch eine Richtlinie, die besagt, dass nur Verbindungen aus der Cloud von einer Verteilung mit einer bestimmten
ID der Verteilung, die Sie in Ihrer Umgebung haben, zugelassen werden.
Das ist also der grobe Überblick.
Um dies besser zu verstehen, schauen wir uns eine kurze Demo an.
Für die heutige Demo habe ich eine verfügbare Cloud-Distribution, die wiederum mit dem
Ursprung des S3-Buckets verbunden ist.
Der Name des Eimers ist CFPB's assets Bucket.
Dies ist hier sehr ähnlich.
CPU-Laboreimer für Vermögenswerte.
Ähnlich wie bei den sehr spezifischen Bucket-Policies auf S3-Ebene.
Schauen wir uns auch das schnell an.
Wenn ich also zu den Berechtigungen gehe, gehen wir ein Stück nach unten.
Sie sehen, dass es eine spezielle Eimerpolitik gibt.
Lassen Sie mich näher erläutern, was diese spezielle Eimerpolitik bewirkt.
Er erlaubt Anfragen vom Cloud-Frontdienst.
Wenn es also vom Cloud-Service erlaubt ist und die Aktion "get object" lautet, haben Sie hier
den Bucket und darin eine Bedingung, die besagt, dass die Quelle diese sein muss.
Und was bedeutet das?
Sie haben die Idee der Cloud für die Verteilung.
Es endet also mit v v un.
Wenn man sich die Cloud Distribution ID noch einmal ansieht, endet sie mit v v un.
Es spielt also keine Rolle, wie viele Cloud-Distributionen Sie in einem Konto haben.
Nur die Cloud-Run-Distribution, die mit dieser spezifischen ID übereinstimmt, darf die Anforderung "get object"
an den S3-Bucket senden.
Dies ist also ein sehr umfassender Überblick über die Origin Access Identität.
Auch hier handelt es sich um eine einfache Funktion, die jedoch für Produktionsumgebungen sehr nützlich ist.
Damit endet unser heutiges Video.