Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Considérations sur la sécurité pour les points d'accès S3 Object Lambda
Avec Amazon S3 Object Lambda, vous pouvez effectuer des transformations personnalisées sur les données lorsqu'elles quittent Amazon S3 en utilisant l'échelle et la flexibilité d'une plate-forme AWS Lambda de calcul. S3 et Lambda restent sécurisés par défaut, mais une attention particulière de l'auteur de fonction Lambda est nécessaire pour maintenir cette sécurité. S3 Object Lambda exige que tous les accès soient effectués par des personnes authentifiées (aucun accès anonyme) et plus encore. HTTPS
Pour limiter les risques de sécurité, nous vous recommandons de respecter les points suivants :
-
Étendez le rôle d'exécution Lambda au plus petit ensemble d'autorisations possible.
-
Dans la mesure du possible, assurez-vous que votre fonction Lambda accède à Amazon S3 via le présigné fourni. URL
Configuration des IAM politiques
Les points d'accès S3 prennent en charge AWS Identity and Access Management (IAM) les politiques de ressources qui vous permettent de contrôler l'utilisation du point d'accès par ressource, par utilisateur ou selon d'autres conditions. Pour de plus amples informations, veuillez consulter Configuration des IAM politiques pour les points d'accès Object Lambda.
Comportement de chiffrement
Étant donné que les points d'accès Object Lambda utilisent à la fois Amazon S3 et qu' AWS Lambda il existe des différences de comportement de chiffrement. Pour plus d’informations sur le comportement de chiffrement S3 par défaut, consultez Définition du comportement de chiffrement côté serveur par défaut pour les compartiments Amazon S3.
-
Lorsque vous utilisez le chiffrement côté serveur S3 avec des points d'accès Object Lambda, l'objet est déchiffré avant d'être envoyé à Lambda. Une fois l'objet envoyé à Lambda, il est traité sous sa forme déchiffrée (dans le cas d'une requête
GETouHEAD). -
Pour empêcher l'enregistrement de la clé de chiffrement, S3 rejette
GETetHEADdemande les objets chiffrés en utilisant le chiffrement côté serveur avec des clés fournies par le client (-C). SSE Toutefois, la fonction Lambda peut encore récupérer ces objets si elle a accès à la clé fournie par le client. -
Lorsque vous utilisez le chiffrement côté client S3 avec des points d'accès Object Lambda, veillez à ce que Lambda ait accès à la clé de chiffrement pour pouvoir déchiffrer et rechiffrer l'objet.
Sécurité des points d'accès
S3 Object Lambda utilise deux points d'accès, un point d'accès Object Lambda et un point d'accès S3 standard, appelé point d'accès de prise en charge. Lorsque vous effectuez une demande auprès d'un point d'accès Object Lambda, S3 appelle Lambda en votre nom ou délègue la demande au point d'accès de prise en charge, en fonction de la configuration S3 Object Lambda. Lorsque Lambda est invoqué pour une demande, S3 génère un présigné URL pour votre objet en votre nom via le point d'accès de support. Votre fonction Lambda le reçoit en entrée URL lorsque la fonction est invoquée.
Vous pouvez configurer votre fonction Lambda pour qu'elle utilise ce présigné URL pour récupérer l'objet d'origine, au lieu d'appeler directement S3. Ce modèle vous permet d'appliquer de meilleures limites de sécurité à vos objets. Vous pouvez limiter l'accès direct aux objets via des compartiments S3 ou des points d'accès S3 à un ensemble limité de IAM rôles ou d'utilisateurs. Cette approche protège également vos fonctions Lambda face au problème de l'adjoint confus, dans le cadre duquel une fonction mal configurée, dotée d'autorisations différentes de l'appelant, pourrait autoriser ou refuser l'accès aux objets alors qu'elle ne le devrait pas.
Accès public au point d'accès Object Lambda
S3 Object Lambda n'autorise pas un accès anonyme ou public, car Amazon S3 doit autoriser votre identité pour effectuer une demande S3 Object Lambda quelconque. Lorsque vous appelez des demandes via un point d'accès Object Lambda, vous devez avoir l'autorisation lambda:InvokeFunction pour la fonction Lambda configurée. De même, lorsque vous appelez d'autres API opérations via un point d'accès Object Lambda, vous devez disposer des s3:* autorisations requises.
Sans ces autorisations, les demandes d'appel de Lambda ou de délégation à S3 échoueront avec HTTP 403 erreurs (interdites). Tous les accès doivent être effectués par des mandants authentifiés. Si vous avez besoin d'un accès public, vous pouvez utiliser Lambda@Edge comme alternative. Pour plus d'informations, consultez la section Personnalisation en périphérie avec Lambda @Edge dans le manuel CloudFront Amazon Developer Guide.
Adresses IP des points d'accès Object Lambda
Les describe-managed-prefix-lists sous-réseaux prennent en charge les points de terminaison du cloud privé virtuel (VPC) de passerelle et sont liés à la table de routage des points de VPC terminaison. Étant donné que le point d'accès Object Lambda ne prend pas en charge la passerelle, VPC ses plages d'adresses IP sont manquantes. Les plages manquantes appartiennent à Amazon S3, mais ne sont pas prises en charge par les VPC points de terminaison de la passerelle. Pour plus d'informations surdescribe-managed-prefix-lists, consultez DescribeManagedPrefixListsla EC2APIréférence Amazon et les plages d'adresses AWS IP dans le Références générales AWS.
Support du point d'accès Object Lambda CORS
Quand S3 Object Lambda reçoit une demande d'un navigateur ou que la demande inclut un en-tête Origin, S3 Object Lambda ajoute toujours un champ d'en-tête “AllowedOrigins":"*".
Pour plus d’informations, consultez Utilisation du partage de ressources entre origines () CORS.
