Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Sicherheitsüberlegungen für S3 Object Lambda-Zugriffspunkte
Mit Amazon S3 Object Lambda können Sie benutzerdefinierte Transformationen an Daten durchführen, wenn diese Amazon S3 verlassen, indem Sie den Umfang und die Flexibilität von AWS Lambda als Rechenplattform nutzen. S3 und Lambda bleiben standardmäßig sicher, aber besondere Rücksicht vom Lambda-Funktionsautor ist erforderlich, um diese Sicherheit zu gewährleisten. S3 Object Lambda erfordert, dass der gesamte Zugriff über authentifizierte Prinzipale (kein anonymer Zugriff) und mehr erfolgt. HTTPS
Es wird Folgendes empfohlen, um Sicherheitsrisiken zu minimieren:
-
Beschränken Sie die Lambda-Ausführungsrolle auf den geringsten Satz von Berechtigungen.
-
Stellen Sie nach Möglichkeit sicher, dass Ihre Lambda-Funktion über das bereitgestellte Presigned auf Amazon S3 zugreift. URL
Richtlinien konfigurieren IAM
S3-Zugriffspunkte unterstützen Ressourcenrichtlinien AWS Identity and Access Management (IAM), mit denen Sie die Nutzung des Access Points nach Ressourcen, Benutzern oder anderen Bedingungen steuern können. Weitere Informationen finden Sie unter Konfiguration von IAM Richtlinien für Object Lambda Access Points.
Verhalten der Verschlüsselung
Da Object Lambda Access Points sowohl Amazon S3 als auch verwenden AWS Lambda, gibt es Unterschiede im Verschlüsselungsverhalten. Weitere Informationen zum standardmäßigen S3-Verschlüsselungsverhalten finden Sie unter Einstellen des Verhaltens der serverseitigen Verschlüsselung für Amazon S3-Buckets.
-
Wenn Sie die serverseitige Verschlüsselung in S3 mit Object Lambda Access Points verwenden, wird das Objekt entschlüsselt, bevor es an Lambda gesendet wird. Nachdem das Objekt an Lambda gesendet wurde, wird es unverschlüsselt verarbeitet (im Fall einer
GET- oderHEAD-Anforderung). -
Um zu verhindern, dass der Verschlüsselungsschlüssel protokolliert wird, lehnt
GETS3HEADAnfragen nach Objekten ab, die mithilfe einer serverseitigen Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln (-C) verschlüsselt wurden. SSE Die Lambda-Funktion kann diese Objekte jedoch weiterhin abrufen, sofern sie Zugriff auf den vom Client bereitgestellten Schlüssel hat. -
Wenn Sie die clientseitige Verschlüsselung in S3 mit Object Lambda Access Points verwenden, stellen Sie sicher, dass Lambda Zugriff auf den Verschlüsselungsschlüssel hat, damit es das Objekt entschlüsseln und erneut verschlüsseln kann.
Sicherheit für Zugriffspunkte
S3 Object Lambda verwendet zwei Zugriffspunkte, einen Object Lambda Access Point und einen standardmäßigen S3-Zugriffspunkt, der als unterstützender Zugriffspunkt bezeichnet wird. Wenn Sie eine Anforderung an einen Object Lambda Access Point ausführen, ruft S3 entweder Lambda in Ihrem Namen auf oder delegiert die Anforderung an den unterstützenden Zugriffspunkt, abhängig von der Konfiguration von S3 Object Lambda. Wenn Lambda für eine Anfrage aufgerufen wird, generiert S3 in Ihrem Namen über URL den unterstützenden Access Point ein Ihrem Objekt vorsigniertes Objekt. Ihre Lambda-Funktion erhält dies URL als Eingabe, wenn die Funktion aufgerufen wird.
Sie können Ihre Lambda-Funktion so einstellen, dass sie dieses vorsignierte Objekt verwendet, URL um das ursprüngliche Objekt abzurufen, anstatt S3 direkt aufzurufen. Mit diesem Modell können Sie bessere Sicherheitsgrenzen auf Ihre Objekte anwenden. Sie können den direkten Objektzugriff über S3-Buckets oder S3-Zugriffspunkte auf eine begrenzte Anzahl von IAM Rollen oder Benutzern beschränken. Dieser Ansatz schützt Ihre Lambda-Funktionen auch davor, dem Problem des verwirrten Stellvertreters ausgesetzt zu sein, bei dem eine falsch konfigurierte Funktion mit anderen Berechtigungen als Ihr Aufrufer den Zugriff auf Objekte zulassen oder verweigern könnte, wenn dies nicht der Fall ist.
Öffentlicher Zugriff auf Objekt-Lambda-Zugriffspunkt
S3 Object Lambda erlaubt keinen anonymen oder öffentlichen Zugriff, da Amazon S3 Ihre Identität autorisieren muss, um eine S3-Object-Lambda-Anforderung abzuschließen. Wenn Sie Anforderungen über einen Object Lambda Access Point aufrufen, benötigen Sie die Berechtigung lambda:InvokeFunction für die konfigurierte Lambda-Funktion. Ebenso müssen Sie über die erforderlichen s3:* Berechtigungen verfügen, wenn Sie andere API Operationen über einen Object Lambda Access Point aufrufen.
Ohne diese Berechtigungen schlagen Anfragen zum Aufrufen von Lambda oder zum Delegieren an S3 mit HTTP 403-Fehlern (verboten) fehl. Jeder Zugriff muss von authentifizierten Prinzipalen erfolgen. Wenn Sie einen öffentlichen Zugang benötigen, können Sie Lambda@Edge als mögliche Alternative verwenden. Weitere Informationen finden Sie unter Customizing at the Edge with Lambda @Edge im Amazon CloudFront Developer Guide.
IP-Adressen von Object Lambda Access Points
Die describe-managed-prefix-lists Subnetze unterstützen Gateway-Endpunkte für virtuelle private Clouds (VPC) und beziehen sich auf die Routing-Tabelle der Endpunkte. VPC Da Object Lambda Access Point kein Gateway unterstützt, fehlen VPC seine IP-Bereiche. Die fehlenden Bereiche gehören zu Amazon S3, werden aber von VPC Gateway-Endpunkten nicht unterstützt. Weitere Informationen zu describe-managed-prefix-lists finden Sie DescribeManagedPrefixListsin der EC2APIAmazon-Referenz und AWS IP-Adressbereiche in der Allgemeine AWS-Referenz.
Unterstützung für Object Lambda Access Point CORS
Wenn S3 Object Lambda eine Anforderung von einem Browser empfängt oder die Anforderung einen Origin-Header enthält, fügt S3 Object Lambda immer das Header-Feld “AllowedOrigins":"*" hinzu.
Weitere Informationen finden Sie unter Verwendung von ursprungsübergreifendem Ressourcenaustausch () CORS.
