Sicherheitsüberlegungen für S3 Object Lambda-Zugriffspunkte - Amazon Simple Storage Service

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 verlangt, dass der gesamte Zugriff von authentifizierten Prinzipalen (kein anonymer Zugriff) und über HTTPS erfolgt.

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 die bereitgestellte vorsignierte URL auf Amazon S3 zugreift.

Konfigurieren von IAM-Richtlinien

S3 Access Points 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 Konfigurieren 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- oder HEAD-Anforderung).

  • Um zu verhindern, dass der Verschlüsselungsschlüssel protokolliert wird, lehnt S3 GET- und HEAD-Anforderungen für Objekte ab, die mit vom Kunden bereitgestellte Schlüssel über serverseitige Verschlüsselung (SSE-C) verschlüsselt wurden. 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 Anforderung aufgerufen wird, generiert S3 eine vorsignierte URL zu Ihrem Objekt in Ihrem Namen über den unterstützenden Zugriffspunkt. Ihre Lambda-Funktion erhält diese URL als Eingabe, wenn die Funktion aufgerufen wird.

Sie können Ihre Lambda-Funktion so einstellen, dass diese vorsignierte URL zum Abrufen des ursprünglichen Objekts verwendet wird, 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 einen begrenzten Satz 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. Entsprechend müssen Sie beim Aufrufen anderer API-Operationen über einen Object Lambda Access Point über die erforderlichen s3:*-Berechtigungen verfügen.

Ohne diese Berechtigungen schlagen Anforderungen zum Aufrufen von Lambda oder Delegieren an S3 als „HTTP 403 Verboten“-Fehler 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 der Virtual Private Cloud (VPC) und beziehen sich auf die Routingtabelle der VPC-Endpunkte. Da der Object-Lambda-Zugangspunkt keine Gateway-VPC unterstützt, fehlen dessen IP-Bereiche. Die fehlenden Bereiche gehören zu Amazon S3, werden jedoch von Gateway-VPC-Endpunkten nicht unterstützt. Weitere Informationen zu describe-managed-prefix-lists finden Sie DescribeManagedPrefixListsin der Amazon EC2 API-Referenz und AWS IP-Adressbereiche in der Allgemeine AWS-Referenz.

Unterstützung von CORS in Object Lambda Access Point

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 Cross-Origin Resource Sharing (CORS) verwenden.