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'évolutivité et la flexibilité d'une AWS Lambda plate-forme 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 nécessite que tous les accès soient effectués par des mandataires authentifiés (pas d’accès anonyme) et via 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, veillez à ce que votre fonction Lambda accède à Amazon S3 via l’URL pré-signée fournie.
Configuration des politiques IAM
Les points d'accès S3 prennent en charge les politiques de ressources AWS Identity and Access Management (IAM) 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 politiques IAM 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 la journalisation de la clé de chiffrement, S3 rejette les requêtes
GETetHEADpour les objets chiffrés côté serveur avec des clés fournies par le client (SSE-C). 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 une URL pré-signée sur votre objet en votre nom via le point d’accès de prise en charge. Votre fonction Lambda reçoit cette URL en entrée quand la fonction est invoquée.
Vous pouvez définir votre fonction Lambda pour utiliser cette URL pré-signée pour récupérer l’objet d’origine, au lieu d’invoquer S3 directement. Ce modèle vous permet d’appliquer de meilleures limites de sécurité à vos objets. Vous pouvez limiter l’accès direct des objets à un ensemble limité de rôles ou d’utilisateurs IAM par le biais de compartiments S3 ou de points d’accès S3. 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 invoquez 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 invoquez d’autres opérations d’API via un point d’accès Object Lambda, vous devez disposer des autorisations s3:* requises.
Sans ces autorisations, les demandes d’invocation de Lambda et de délégation à S3 échouent avec des erreurs HTTP 403 (Interdit). 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 sous-réseaux describe-managed-prefix-lists prennent en charge les points de terminaison de cloud privé virtuel (VPC) de la passerelle et sont liés à la table de routage des points de terminaison du VPC. Comme le point d’accès Object Lambda ne prend pas en charge le VPC de passerelle, ses plages IP sont manquantes. Les plages manquantes appartiennent à Amazon S3, mais ne sont pas prises en charge par les points de terminaison de VPC de la passerelle. Pour plus d'informationsdescribe-managed-prefix-lists, consultez DescribeManagedPrefixListsla référence des EC2 API Amazon et les plages d'adresses AWS IP dans le Références générales AWS.
Prise en charge du CORS du point d’accès Object Lambda
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 des ressources entre origines multiples (CORS).
