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.
Contrôles CSPM Security Hub pour AWS Lambda
Ces AWS Security Hub CSPM contrôles évaluent le AWS Lambda service et les ressources. Les commandes ne sont peut-être pas disponibles dans tous Régions AWS. Pour de plus amples informations, veuillez consulter Disponibilité des contrôles par région.
[Lambda.1] Les politiques relatives à la fonction Lambda devraient interdire l'accès public
Exigences associées : NIST.800-53.r5 AC-21, NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3 (7) NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4 (21),, NIST.800-53.r5 AC-6 NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7 (11), NIST.800-53.r5 SC-7 (16), NIST.800-53.r5 SC-7 (20), NIST.800-53.r5 SC-7 (21), NIST.800-53.r5 SC-7 (3), NIST.800-53.r5 SC-7 (4), NIST.800-53.r5 SC-7 (9), PCI DSS v3.2. 1/12.1.1, PCI DSS v3.2. 1/13.1.1, PCI DSS v3.2. 1/13.2.2, PCI DSS v3.2. 1/13.4.4, PCI DSS v3.2. 1/72.1.1, PCI DSS v4.0. 1/72.1.1
Catégorie : Protéger - Configuration réseau sécurisée
Gravité : Critique
Type de ressource : AWS::Lambda::Function
Règle AWS Config : lambda-function-public-access-prohibited
Type de calendrier : Déclenché par un changement
Paramètres : Aucun
Ce contrôle vérifie si la politique basée sur les ressources de la fonction Lambda interdit l'accès public en dehors de votre compte. Le contrôle échoue si l'accès public est autorisé. Le contrôle échoue également si une fonction Lambda est invoquée depuis Amazon S3 et que la politique n'inclut aucune condition visant à limiter l'accès public, telle queAWS:SourceAccount. Nous vous recommandons d'utiliser d'autres conditions S3 AWS:SourceAccount en plus de la politique de votre bucket pour un accès plus précis.
Note
Ce contrôle n'évalue pas les conditions de politique qui utilisent des caractères génériques ou des variables. Pour produire un PASSED résultat, les conditions de la politique de la fonction Lambda ne doivent utiliser que des valeurs fixes, c'est-à-dire des valeurs qui ne contiennent pas de caractères génériques ni de variables de stratégie. Pour plus d'informations sur les variables de politique, consultez la section Variables et balises dans le Guide de Gestion des identités et des accès AWS l'utilisateur.
La fonction Lambda ne doit pas être accessible au public, car cela peut permettre un accès involontaire au code de votre fonction.
Correction
Pour résoudre ce problème, vous devez mettre à jour la politique basée sur les ressources de votre fonction afin de supprimer des autorisations ou d'ajouter la condition. AWS:SourceAccount Vous pouvez uniquement mettre à jour la politique basée sur les ressources à partir de l'API Lambda ou. AWS CLI
Pour commencer, passez en revue la politique basée sur les ressources sur la console Lambda. Identifiez la déclaration de politique dont les valeurs de Principal champ rendent la politique publique, par exemple "*" ou{ "AWS": "*" }.
Vous ne pouvez pas modifier la politique depuis la console. Pour supprimer les autorisations de la fonction, exécutez la remove-permission commande depuis le AWS CLI.
$ aws lambda remove-permission --function-name<function-name>--statement-id<statement-id>
<function-name><statement-id>Sid) de l'instruction que vous souhaitez supprimer.
[Lambda.2] Les fonctions Lambda doivent utiliser des environnements d'exécution pris en charge
Exigences associées : NIST.800-53.r5 CA-9 (1), NIST.800-53.r5 CM-2 NIST.800-53.r5 SI-2, NIST.800-53.r5 SI-2 (2), NIST.800-53.r5 SI-2 (4), NIST.800-53.r5 SI-2 (5), PCI DSS v4.0. 1/123.4
Catégorie : Protéger - Développement sécurisé
Gravité : Moyenne
Type de ressource : AWS::Lambda::Function
Règle AWS Config : lambda-function-settings-check
Type de calendrier : Déclenché par un changement
Paramètres :
-
runtime:dotnet10, dotnet8, java25, java21, java17, java11, java8.al2, java17.al2023, java11.al2023, java8.al2023, nodejs24.x, nodejs22.x, python3.14, python3.13, python3.12, python3.11, python3.10, ruby4.0, ruby3.4, ruby3.3(non personnalisable)
Ce contrôle vérifie si les paramètres d'exécution des AWS Lambda fonctions correspondent aux valeurs attendues définies pour les environnements d'exécution pris en charge dans chaque langue. Le contrôle échoue si la fonction Lambda n'utilise pas un environnement d'exécution pris en charge, comme indiqué dans la section Paramètres. Security Hub CSPM ignore les fonctions dont le type de package est. Image
Les environnements d'exécution Lambda sont conçus autour d'une combinaison de systèmes d'exploitation, de langages de programmation et de bibliothèques logicielles qui font l'objet de mises à jour de maintenance et de sécurité. Lorsqu'un composant d'exécution n'est plus pris en charge pour les mises à jour de sécurité, Lambda le rend obsolète. Même si vous ne pouvez pas créer de fonctions utilisant le runtime obsolète, la fonction est toujours disponible pour traiter les événements d'invocation. Nous vous recommandons de vous assurer que vos fonctions Lambda sont à jour et qu'elles n'utilisent pas d'environnements d'exécution obsolètes. Pour obtenir la liste des environnements d'exécution pris en charge, consultez la section Runtimes Lambda dans le Guide du AWS Lambda développeur.
Correction
Pour plus d'informations sur les environnements d'exécution et les calendriers de dépréciation pris en charge, consultez la politique de dépréciation des environnements d'exécution dans le Guide du développeur. AWS Lambda Lorsque vous migrez vos environnements d'exécution vers la dernière version, suivez la syntaxe et les conseils des éditeurs de la langue. Nous vous recommandons également d'appliquer des mises à jour d'exécution afin de réduire le risque d'impact sur vos charges de travail dans les rares cas d'incompatibilité entre les versions d'exécution.
[Lambda.3] Les fonctions Lambda doivent se trouver dans un VPC
Exigences associées : PCI DSS v3.2. 1/12.1.1, PCI DSS v3.2. 1/13.1.1, PCI DSS v3.2. 1/13.2.2, PCI DSS v3.2. 1/1.3.4, NIST.800-53.r5 AC-21 NIST.800-53.r5 AC-3, NIST.800-53.r5 AC-3 (7) NIST.800-53.r5 AC-4, NIST.800-53.r5 AC-4 (21), NIST.800-53.r5 AC-6, NIST.800-53.r5 SC-7 (11) NIST.800-53.r5 SC-7, NIST.800-53.r5 SC-7 (16), NIST.800-53.r5 SC-7 (20), NIST.800-53.r5 SC-7 (21), NIST.800-53.r5 SC-7 (3), NIST.800-53.r5 SC-7 (4), NIST.800-53.r5 SC-7 (9)
Catégorie : Protéger - Configuration réseau sécurisée
Gravité : Faible
Type de ressource : AWS::Lambda::Function
AWS Config règle : lambda-inside-vpc
Type de calendrier : Déclenché par un changement
Paramètres : Aucun
Ce contrôle vérifie si une fonction Lambda est déployée dans un cloud privé virtuel (VPC). Le contrôle échoue si la fonction Lambda n'est pas déployée dans un VPC. Security Hub CSPM n'évalue pas la configuration de routage du sous-réseau VPC pour déterminer l'accessibilité publique. Les résultats des ressources Lambda @Edge peuvent échouer.
Le déploiement de ressources dans un VPC renforce la sécurité et le contrôle des configurations réseau. De tels déploiements offrent également une évolutivité et une tolérance aux pannes élevée dans plusieurs zones de disponibilité. Vous pouvez personnaliser les déploiements de VPC pour répondre aux diverses exigences des applications.
Correction
Pour configurer une fonction existante afin de se connecter à des sous-réseaux privés de votre VPC, consultez la section Configuration de l'accès au VPC dans le Guide du AWS Lambda développeur. Nous vous recommandons de choisir au moins deux sous-réseaux privés pour une haute disponibilité et au moins un groupe de sécurité répondant aux exigences de connectivité de la fonction.
[Lambda.5] Les fonctions Lambda du VPC doivent fonctionner dans plusieurs zones de disponibilité
Exigences connexes : NIST.800-53.r5 CP-10, NIST.800-53.r5 CP-6 (2) NIST.800-53.r5 SC-36, NIST.800-53.r5 SC-5 (2), NIST.800-53.r5 SI-13 (5)
Catégorie : Restaurer > Résilience > Haute disponibilité
Gravité : Moyenne
Type de ressource : AWS::Lambda::Function
Règle AWS Config : lambda-vpc-multi-az-check
Type de calendrier : Déclenché par un changement
Paramètres :
| Paramètre | Description | Type | Valeurs personnalisées autorisées | Valeur par défaut de Security Hub CSPM |
|---|---|---|---|---|
|
|
Nombre minimum de zones de disponibilité |
Enum |
|
|
Ce contrôle vérifie si une AWS Lambda fonction qui se connecte à un cloud privé virtuel (VPC) fonctionne dans au moins le nombre spécifié de zones de disponibilité (AZ). Le contrôle échoue si la fonction ne fonctionne pas dans au moins le nombre spécifié d'AZ. À moins que vous ne fournissiez une valeur de paramètre personnalisée pour le nombre minimum d'AZ, Security Hub CSPM utilise une valeur par défaut de deux AZ.
Le déploiement de ressources sur plusieurs zones de disponibilité constitue une AWS bonne pratique pour garantir une haute disponibilité au sein de votre architecture. La disponibilité est un pilier essentiel du modèle de sécurité de la triade de confidentialité, d'intégrité et de disponibilité. Toutes les fonctions Lambda qui se connectent à un VPC doivent disposer d'un déploiement multi-AZ afin de garantir qu'une seule zone de défaillance n'entraîne pas une interruption totale des opérations.
Correction
Si vous configurez votre fonction pour vous connecter à un VPC de votre compte, spécifiez des sous-réseaux dans plusieurs zones de zone de disponibilité pour garantir une haute disponibilité. Pour obtenir des instructions, consultez la section Configuration de l'accès au VPC dans le Guide du AWS Lambda développeur.
Lambda exécute automatiquement d'autres fonctions dans plusieurs zones de disponibilité afin de s'assurer qu'il est disponible pour traiter les événements en cas d'interruption de service dans une seule zone.
[Lambda.6] Les fonctions Lambda doivent être balisées
Catégorie : Identifier > Inventaire > Marquage
Gravité : Faible
Type de ressource : AWS::Lambda::Function
AWS Config règle : tagged-lambda-function (règle CSPM personnalisée de Security Hub)
Type de calendrier : Déclenché par un changement
Paramètres :
| Paramètre | Description | Type | Valeurs personnalisées autorisées | Valeur par défaut de Security Hub CSPM |
|---|---|---|---|---|
requiredTagKeys
|
Liste des clés de balise non système que la ressource évaluée doit contenir. Les touches des tags distinguent les majuscules et minuscules. | StringList (maximum de 6 articles) | 1 à 6 clés de tag qui répondent aux AWS exigences. |
No default value
|
Ce contrôle vérifie si une AWS Lambda fonction possède des balises avec les touches spécifiques définies dans le paramètrerequiredTagKeys. Le contrôle échoue si la fonction ne possède aucune clé de balise ou si elle ne possède pas toutes les clés spécifiées dans le paramètrerequiredTagKeys. Si le paramètre requiredTagKeys n'est pas fourni, le contrôle vérifie uniquement l'existence d'une clé de balise et échoue si la fonction n'est balisée avec aucune touche. Les balises système, qui sont automatiquement appliquées et commencent paraws:, sont ignorées.
Une balise est une étiquette que vous attribuez à une AWS ressource. Elle se compose d'une clé et d'une valeur facultative. Vous pouvez créer des balises pour classer vos ressources par objectif, propriétaire, environnement ou selon d’autres critères. Les balises peuvent vous aider à identifier, organiser, rechercher et filtrer les ressources. Le balisage vous permet également de suivre les actions et les notifications des propriétaires de ressources responsables. Lorsque vous utilisez le balisage, vous pouvez implémenter le contrôle d'accès basé sur les attributs (ABAC) en tant que stratégie d'autorisation, qui définit les autorisations en fonction des balises. Vous pouvez associer des balises à des entités IAM (utilisateurs ou rôles) et à AWS des ressources. Vous pouvez créer une politique ABAC unique ou un ensemble distinct de politiques pour vos responsables IAM. Vous pouvez concevoir ces politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de ressource. Pour plus d'informations, voir À quoi sert l'ABAC ? AWSdans le guide de l'utilisateur IAM.
Note
N'ajoutez pas d'informations personnelles identifiables (PII) ou d'autres informations confidentielles ou sensibles dans les balises. Les balises sont accessibles à de nombreuses personnes Services AWS, y compris AWS Billing. Pour en savoir plus sur les meilleures pratiques en matière de balisage, voir Marquer vos AWS ressources dans le. Références générales AWS
Correction
Pour ajouter des balises à une fonction Lambda, consultez la section Utilisation de balises sur les fonctions Lambda dans le Guide du AWS Lambda développeur.
[Lambda.7] Les fonctions Lambda doivent avoir AWS X-Ray traçage actif activé
Exigences connexes : NIST.800-53.r5 CA-7
Catégorie : Identifier - Journalisation
Gravité : Faible
Type de ressource : AWS::Lambda::Function
Règle AWS Config : lambda-function-xray-enabled
Type de calendrier : Déclenché par un changement
Paramètres : Aucun
Ce contrôle vérifie si le traçage actif avec AWS X-Ray est activé pour une AWS Lambda fonction. Le contrôle échoue si le suivi actif avec X-Ray est désactivé pour la fonction Lambda.
AWS X-Ray peut fournir des fonctionnalités de suivi et de surveillance pour les AWS Lambda fonctions, ce qui permet de gagner du temps et d'économiser des efforts lors du débogage et de l'utilisation des fonctions Lambda. Il peut vous aider à diagnostiquer les erreurs et à identifier les goulots d'étranglement, les ralentissements et les délais d'attente en réduisant la latence des fonctions Lambda. Cela peut également aider à respecter les exigences de confidentialité et de conformité des données. Si vous activez le traçage actif pour une fonction Lambda, cela X-Ray fournit une vue globale du flux de données et du traitement au sein de la fonction Lambda, ce qui peut vous aider à identifier les failles de sécurité potentielles ou les pratiques de traitement des données non conformes. Cette visibilité peut vous aider à préserver l'intégrité, la confidentialité et la conformité des données aux réglementations pertinentes.
Note
AWS X-Ray le traçage n'est actuellement pas pris en charge pour les fonctions Lambda avec Amazon Managed Streaming pour Apache Kafka (Amazon MSK), Apache Kafka autogéré, Amazon MQ avec ActiveMQ et RabbitMQ, ou les mappages de sources d'événements Amazon DocumentDB.
Correction
Pour plus d'informations sur l'activation du suivi actif pour une AWS Lambda fonction, voir Visualiser les appels de fonctions Lambda AWS X-Ray à l'aide du guide du AWS Lambda développeur.
