Sicherheitsüberlegungen für S3 Object Lambda-Zugriffspunkte
Anmerkung
Ab dem 7. November 2025 wird S3 Object Lambda nur für Bestandskunden verfügbar sein, die den Service derzeit nutzen, sowie für ausgewählte AWS-Partnernetzwerk (APN)-Partner. Wenn Sie den Service nutzen möchten, melden Sie sich bitte vor dem 7. November 2025 an. Weitere Informationen zu Features, die S3 Object Lambda ähneln, finden Sie hier – Änderung der Verfügbarkeit von Amazon S3 Object Lambda.
Mit S3 Object Lambda können Sie benutzerdefinierte Transformationen an Daten durchführen, da Amazon S3 unter Verwendung der Skalierung und Flexibilität von AWS Lambda als Rechenplattform verwendet wird. 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-Zugriffspunkte unterstützen AWS Identity and Access Management (IAM)-Ressourcenrichtlinien, mit denen Sie die Verwendung des Zugriffspunkts nach Ressource, Benutzer 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 AWS Lambda verwenden, 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 S3
GET- undHEAD-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 Anpassen an Edge mit Lambda@Edge im Entwicklerhandbuch für Amazon CloudFront.
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 unter DescribeManagedPrefixLists in der API-Referenz zu Amazon EC2 und unter 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.
