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.
# Sécurité dans AWS Lambda
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit cette notion par les termes sécurité *du* cloud et sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est responsable de la protection de l'infrastructure qui fonctionne Services AWS dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l’efficacité de notre sécurité dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour en savoir plus sur les programmes de conformité qui s'appliquent à AWS Lambda, consultez [Services AWS la section Portée par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** : votre responsabilité est déterminée par le service AWS que vous utilisez. Vous êtes également responsable d'autres facteurs, y compris la sensibilité de vos données, les exigences de votre entreprise,et la législation et la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l'utilisation de Lambda. Les rubriques suivantes vous montrent comment configurer Lambda pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à en utiliser d'autres Services AWS qui vous aident à surveiller et à sécuriser vos ressources Lambda.
Pour plus d'informations sur l'application de principes de sécurité aux applications Lambda, Consultez [Sécurité](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops) dans Serverless Land.
**Topics**
+ [Protection des données dans AWS Lambda](security-dataprotection.md)
+ [Utilisation de rôles liés à un service pour Lambda](using-service-linked-roles.md)
+ [Identity and Access Management pour AWS Lambda](security-iam.md)
+ [Création d’une stratégie de gouvernance pour les couches et les fonctions Lambda](governance-concepts.md)
+ [Validation de la conformité pour AWS Lambda](security-compliance.md)
+ [Résilience dans AWS Lambda](security-resilience.md)
+ [Sécurité de l'infrastructure dans AWS Lambda](security-infrastructure.md)
+ [Sécurisation des charges de travail avec des points de terminaison publics](security-public-endpoints.md)
+ [Utilisation de la signature de code pour vérifier l’intégrité du code avec Lambda](configuration-codesigning.md)
# Protection des données dans AWS Lambda
Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) AWS s’applique à la protection des données dans AWS Lambda. Comme décrit dans ce modèle, AWS est responsable de la protection de l’infrastructure globale sur laquelle l’ensemble du AWS Cloud s’exécute. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog Modèle de responsabilité partagée [AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécurité AWS*.
À des fins de protection des données, nous vous recommandons de protéger les informations d’identification Compte AWS et de configurer les comptes utilisateur individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ Utilisez les certificats SSL/TLS pour communiquer avec les ressources AWS. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez une API (Interface de programmation) et la journalisation des activités des utilisateurs avec AWS CloudTrail. Pour plus d’informations sur l’utilisation des sentiers CloudTrail pour capturer des activités AWS, consultez la section [Utilisation des sentiers CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *Guide de l’utilisateur AWS CloudTrail*.
+ Utilisez des solutions de chiffrement AWS, ainsi que tous les contrôles de sécurité par défaut au sein des Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules de chiffrement validés FIPS (Federal Information Processing Standard) 140-3 lorsque vous accédez à AWS via une interface de ligne de commande ou une API (interface de programmation), utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela s’applique aussi lorsque vous utilisez Lambda ou d’autres Services AWS à l’aide de la console, de l’API, de l’AWS CLI ou des kits SDK AWS. Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
**Topics**
+ [Chiffrement en transit](#security-privacy-intransit)
+ [Chiffrement des données au repos pour AWS Lambda](security-encryption-at-rest.md)
## Chiffrement en transit
Les points de terminaison d’API Lambda ne prennent en charge que des connexions sécurisées sur HTTPS. Lorsque vous gérez des ressources Lambda avec l’AWS Management Console, le kit SDK AWS ou l’API Lambda, toutes les communications sont chiffrées à l’aide du protocole TLS (Transport Layer Security). Pour obtenir la liste complète des points de terminaison d’API, consultez [Régions et points de terminaisonAWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) dans Références générales AWS.
Lorsque vous [connectez votre fonction à un système de fichiers](configuration-filesystem.md), Lambda utilise le chiffrement pendant le transit pour toutes les connexions. Pour en savoir plus, consultez [Chiffrement des données dans Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) que vous trouverez dans le *guide de l’utilisateur Amazon Elastic File System*.
Lorsque vous utilisez [variables d’environnement](configuration-envvars.md), vous pouvez activer les assistants de chiffrement de la console afin qu’ils utilisent le chiffrement côté client pour protéger les variables d’environnement en transit. Pour de plus amples informations, consultez [Sécurisation de variables d’environnement Lambda](configuration-envvars-encryption.md).
# Chiffrement des données au repos pour AWS Lambda
Lambda fournit toujours un chiffrement au repos pour les ressources suivantes à l’aide d’une clé [Clé détenue par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) ou [Clé gérée par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) :
+ Variables d’environnement
+ Les fichiers que vous chargez sur Lambda, y compris les packages de déploiement et les archives de couches
+ Les objets de critères de filtre de mappage des sources d’événements
Vous pouvez éventuellement configurer Lambda de manière à utiliser une clé gérée par le client afin de chiffrer vos [variables d’environnement](configuration-envvars-encryption.md), vos [packages de déploiement .zip](encrypt-zip-package.md) et vos [objets de critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption).
Amazon CloudWatch Logs et AWS X-Ray chiffrent également les données par défaut, et peuvent être configurés de façon à utiliser une clé gérée par le client. Pour plus d’informations, consultez [Chiffrement des données de journaux dans CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) et [Protection des données dans AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html).
## Surveillance de vos clés de chiffrement pour Lambda
Lorsque vous utilisez une clé AWS KMS gérée par le client avec Lambda, vous pouvez utiliser [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Les exemples suivants sont des événements CloudTrail pour des appels `Decrypt`, `DescribeKey` et `GenerateDataKey` passés par Lambda pour accéder à des données chiffrées par votre clé gérée par le client.
------
#### [ Decrypt ]
Si vous avez utilisé une clé AWS KMS gérée par le client pour chiffrer votre objet de [critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption), Lambda envoie une requête `Decrypt` en votre nom lorsque vous essayez d’y accéder en texte brut (par exemple, à partir d’un appel `ListEventSourceMappings`). L’exemple d’événement suivant enregistre l’opération `Decrypt` :
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
Si vous avez utilisé une clé AWS KMS gérée par le client pour chiffrer votre objet de [critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption), Lambda envoie une requête `DescribeKey` en votre nom lorsque vous essayez d’y accéder (par exemple, à partir d’un appel `GetEventSourceMapping`). L’exemple d’événement suivant enregistre l’opération `DescribeKey` :
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
Lorsque vous utilisez une clé AWS KMS gérée par le client pour chiffrer votre objet de [critères de filtre](invocation-eventfiltering.md#filter-criteria-encryption) dans un appel `CreateEventSourceMapping` ou `UpdateEventSourceMapping`, Lambda envoie une requête `GenerateDataKey` en votre nom pour générer une clé de données afin de chiffrer les critères de filtre ([chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). L’exemple d’événement suivant enregistre l’opération `GenerateDataKey` :
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# Utilisation de rôles liés à un service pour Lambda
[Lambda utilise des rôles liés à un Gestion des identités et des accès AWS service (IAM).](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Un rôle lié à un service est un type unique de rôle IAM directement lié à Lambda. Les rôles liés à un service sont prédéfinis par Lambda et incluent les autorisations dont le service a besoin pour appeler d'autres AWS services en votre nom.
Lambda définit les autorisations associées à ses rôles liés aux services, et seule Lambda peut assumer ses rôles. Les autorisations définies comprennent la politique de confiance et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer un rôle lié à un service uniquement après la suppression préalable de ses ressources connexes. Cela protège vos ressources Lambda car vous ne pouvez pas supprimer par inadvertance l'autorisation d'accès aux ressources.
Pour plus d'informations sur les autres services qui prennent en charge les rôles liés à un service, consultez la section [AWS Services qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services dont la valeur est **Oui** dans la colonne Rôles liés à un **service**. Sélectionnez un **Oui** ayant un lien pour consulter la documentation du rôle lié à un service, pour ce service.
## Autorisations de rôle liées à un service pour Lambda
Lambda utilise le rôle lié au service nommé. **AWSServiceRoleForLambda** Le rôle lié à un service approuve les services suivants pour endosser le rôle :
+ `lambda.amazonaws.com`
La politique d'autorisation de rôle nommée AWSLambda ServiceRolePolicy permet à Lambda d'effectuer les actions suivantes sur les ressources spécifiées :
+ Action : `ec2:TerminateInstances` activée `arn:aws:ec2:*:*:instance/*` à la condition `ec2:ManagedResourceOperator` égale `scaler.lambda.amazonaws.com`
+ Action : `ec2:DescribeInstanceStatus` et `ec2:DescribeInstances` sur `*`
Vous devez configurer les autorisations de manière à permettre à vos utilisateurs, groupes ou rôles de créer, modifier ou supprimer un rôle lié à un service. Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
Pour les mises à jour des politiques gérées, consultez la section Politiques [gérées par Lambda](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates).
## Création d'un rôle lié à un service pour Lambda
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un fournisseur de capacité Lambda dans l'API AWS Management Console, le ou l' AWS API AWS CLI, Lambda crée le rôle lié au service pour vous.
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez un fournisseur de capacité Lambda, Lambda crée à nouveau le rôle lié au service pour vous.
Vous pouvez également utiliser la console IAM pour créer un rôle lié à un service avec le **AWSServiceRoleForLambda**cas d'utilisation. Dans l'API AWS CLI ou dans l' AWS API, créez un rôle lié à un service avec le nom du `lambda.amazonaws.com` service. Pour plus d’informations, consultez [Création d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) dans le *Guide de l’utilisateur IAM*. Si vous supprimez ce rôle lié à un service, vous pouvez utiliser ce même processus pour créer le rôle à nouveau.
## Modification d'un rôle lié à un service pour Lambda
Lambda ne vous permet pas de modifier le rôle lié à un AWSService RoleForLambda service. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Supprimer un rôle lié à un service pour Lambda
Si vous n’avez plus besoin d’utiliser une fonctionnalité ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Cependant, vous devez nettoyer les ressources de votre rôle lié à un service avant de pouvoir les supprimer manuellement.
**Note**
Si le service Lambda utilise le rôle lorsque vous essayez de supprimer les ressources, la suppression risque d'échouer. Si cela se produit, patientez quelques minutes et réessayez.
**Pour supprimer les ressources Lambda utilisées par AWSService RoleForLambda**
1. Supprimez tous les fournisseurs de capacité Lambda de votre compte. Vous pouvez le faire à l'aide de la console Lambda, de la CLI ou de l'API.
1. Vérifiez qu'aucun fournisseur de capacité Lambda n'est présent dans votre compte avant de tenter de supprimer le rôle lié à un service.
**Pour supprimer manuellement le rôle lié au service à l’aide d’IAM**
Utilisez la console IAM, le AWS CLI, ou l' AWS API pour supprimer le rôle lié au AWSService RoleForLambda service. Pour plus d’informations, consultez la section [Suppression d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Régions prises en charge pour les rôles liés à un service Lambda
Lambda ne prend pas en charge l'utilisation de rôles liés à un service dans toutes les régions où le service est disponible. AWSServiceRoleForLambda est pris en charge dans les régions suivantes.
| Nom de la région | Identité de la région | Support dans Lambda |
| --- | --- | --- |
| USA Est (Virginie du Nord) | us-east-1 | Oui |
| USA Est (Ohio) | us-east-2 | Oui |
| USA Ouest (Californie du Nord) | us-west-1 | Oui |
| USA Ouest (Oregon) | us-west-2 | Oui |
| Afrique (Le Cap) | af-south-1 | Non |
| Asie-Pacifique (Hong Kong) | ap-east-1 | Oui |
| Asie-Pacifique (Jakarta) | ap-southeast-3 | Oui |
| Asie-Pacifique (Bangkok) | ap-southeast-7 | Oui |
| Asie-Pacifique (Mumbai) | ap-south-1 | Oui |
| Asie-Pacifique (Osaka) | ap-northeast-3 | Non |
| Asie-Pacifique (Séoul) | ap-northeast-2 | Non |
| Asie-Pacifique (Singapour) | ap-southeast-1 | Oui |
| Asie-Pacifique (Sydney) | ap-southeast-2 | Oui |
| Asie-Pacifique (Tokyo) | ap-northeast-1 | Oui |
| Canada (Centre) | ca-central-1 | Non |
| Europe (Francfort) | eu-central-1 | Oui |
| Europe (Irlande) | eu-west-1 | Oui |
| Europe (Londres) | eu-west-2 | Oui |
| Europe (Milan) | eu-south-1 | Non |
| Europe (Paris) | eu-west-3 | Non |
| Europe (Stockholm) | eu-north-1 | Non |
| Moyen-Orient (Bahreïn) | me-south-1 | Non |
| Moyen-Orient (EAU) | me-central-1 | Non |
| Amérique du Sud (São Paulo) | sa-east-1 | Non |
| AWS GovCloud (USA Est) | us-gov-east-1 | Non |
| AWS GovCloud (US-Ouest) | us-gov-west-1 | Non |
# Identity and Access Management pour AWS Lambda
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs IAM contrôlent les personnes qui s’*authentifient* (sont connectées) et sont *autorisées* (disposent d’autorisations) à utiliser des ressources . IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment AWS Lambda fonctionne avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md)
+ [AWS politiques gérées pour AWS Lambda](security-iam-awsmanpol.md)
+ [Résolution des problèmes AWS Lambda d'identité et d'accès](security_iam_troubleshoot.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes AWS Lambda d'identité et d'accès](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Comment AWS Lambda fonctionne avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md))
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### Compte AWS utilisateur root
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération AWS CLI ou AWS API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources.
Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Comment AWS Lambda fonctionne avec IAM
Avant d’utiliser IAM pour gérer l’accès à Lambda, découvrez les fonctions IAM que vous pouvez utiliser avec Lambda.
| Fonctionnalité IAM | Support Lambda |
| --- | --- |
| [Politiques basées sur l’identité](#security_iam_service-with-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies) | Oui |
| [Actions de politique](#security_iam_service-with-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#security_iam_service-with-iam-id-based-policies-resources) | Oui |
| [Clés de condition de politique (spécifiques au service)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Oui |
| [ACLs](#security_iam_service-with-iam-acls) | Non |
| [ABAC (identifications dans les politiques)](#security_iam_service-with-iam-tags) | Partielle |
| [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Transfert des sessions d’accès (FAS)](#security_iam_service-with-iam-principal-permissions) | Non |
| [Rôles de service](#security_iam_service-with-iam-roles-service) | Oui |
| [Rôles liés à un service](#security_iam_service-with-iam-roles-service-linked) | Partielle |
*Pour obtenir une vue d'ensemble de la façon dont Lambda et les autres AWS services fonctionnent avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM dans le guide de l'utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
## Politiques basées sur l’identité pour Lambda
**Prend en charge les politiques basées sur l’identité :** oui
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de politiques basées sur l’identité pour Lambda
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## Politiques basées sur les ressources dans Lambda
**Prend en charge les politiques basées sur les ressources** : oui
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
Vous pouvez attacher une politique basée sur les ressources à une fonction ou une couche Lambda. Cette politique désigne les principaux autorisés à effectuer des actions sur la fonction ou la couche.
Pour savoir comment attacher une politique basée sur les ressources à une fonction ou une couche, consultez [Voir les politiques IAM basées sur les ressources dans Lambda](access-control-resource-based.md).
## Actions de politique pour Lambda
**Prend en charge les actions de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Pour afficher la liste des actions Lambda, consultez [Actions définies par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) dans la *Référence de l’autorisation de service*.
Les actions de politique dans Lambda utilisent le préfixe suivant avant l’action :
```
lambda
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## Ressources de politique pour Lambda
**Prend en charge les ressources de politique :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
Pour consulter la liste des types de ressources Lambda et leurs caractéristiques ARNs, consultez la section [Types de ressources définis par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) dans la référence *d'autorisation de service*. Pour savoir grâce à quelles actions vous pouvez spécifier l’ARN de chaque ressource, consultez [Actions définies par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## Clés de condition de politique pour Lambda
**Prend en charge les clés de condition de politique spécifiques au service :** oui
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Pour afficher la liste des clés de condition Lambda, consultez [Clés de condition pour AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) dans la *Référence de l’autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez la section [Actions définies par AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Pour voir des exemples de politiques Lambda basées sur l’identité, consultez [Exemples de politiques basées sur l'identité pour AWS Lambda](security_iam_id-based-policy-examples.md).
## ACLs à Lambda
**Supports ACLs :** Non
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## ABAC avec Lambda
**Prend en charge ABAC (identifications dans les politiques) :** partiellement
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs nommés balise. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur le balisage des ressources Lambda, consultez [Utilisation du contrôle d’accès basé sur les attributs dans Lambda](attribute-based-access-control.md).
## Utilisation des informations d’identification temporaires avec Lambda
**Prend en charge les informations d’identification temporaires :** oui
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Transmission des sessions d’accès pour Lambda
**Prend en charge les sessions d’accès direct (FAS)** : oui
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour Lambda
**Prend en charge les rôles de service :** oui
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
Dans Lambda, un rôle de service est appelé [rôle d’exécution](lambda-intro-execution-role.md).
**Avertissement**
La modification des autorisations d’un rôle d’exécution peut altérer la fonction Lambda.
## Rôles liés à un service pour Lambda
**Prend en charge les rôles liés à un service :** partiellement
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Lambda n’a pas de rôles liés au service, contrairement à Lambda@Edge. *Pour plus d'informations, consultez la section [Rôles liés aux services pour Lambda @Edge dans](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) le manuel Amazon Developer Guide. CloudFront *
Pour plus d’informations sur la création ou la gestion des rôles liés à un service, consultez [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Recherchez un service dans le tableau qui inclut un `Yes` dans la colonne **Rôle lié à un service**. Choisissez le lien **Oui** pour consulter la documentation du rôle lié à ce service.
# Exemples de politiques basées sur l'identité pour AWS Lambda
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ou à modifier des ressources Lambda. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, consultez [Création de politiques IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
Pour plus de détails sur les actions et les types de ressources définis par Lambda, y compris le format de ARNs pour chacun des types de ressources, voir [Actions, ressources et clés de condition AWS Lambda dans la référence](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) *d'autorisation de service*.
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console Lambda](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
## Bonnes pratiques en matière de politiques
Les stratégies basées sur l’identité déterminent si une personne peut créer, consulter ou supprimer des ressources Lambda dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :
+ **Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations** à vos utilisateurs et à vos charges de travail, utilisez les *politiques AWS gérées* qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez les autorisations de moindre privilège** : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées *autorisations de moindre privilège*. Pour plus d’informations sur l’utilisation d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez des conditions dans les politiques IAM pour restreindre davantage l’accès** : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dans le *Guide de l’utilisateur IAM*.
+ **Exiger l'authentification multifactorielle (MFA**) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur les bonnes pratiques dans IAM, consultez [Bonnes pratiques de sécurité dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console Lambda
Pour accéder à la AWS Lambda console, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher des informations détaillées sur les ressources Lambda de votre. Compte AWS Si vous créez une politique basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette politique.
Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API qu’ils tentent d’effectuer.
Pour obtenir un exemple de stratégie qui accorde un accès minimal pour le développement de fonctions, veuillez consulter [Octroi aux utilisateurs de l’accès à une fonction Lambda](permissions-user-function.md). Outre Lambda APIs, la console Lambda utilise d'autres services pour afficher la configuration des déclencheurs et vous permettre d'ajouter de nouveaux déclencheurs. Si vos utilisateurs utilisent Lambda avec d’autres services, ils ont également besoin d’accéder à ces services. Pour plus d’informations sur la configuration d’autres services avec Lambda, consultez [Invoquer Lambda avec des événements provenant d'autres services AWS](lambda-services.md).
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS politiques gérées pour AWS Lambda
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
Pour plus d’informations, consultez [Politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *Guide de l’utilisateur IAM*.
**Topics**
+ [AWS politique gérée : AWSLambda\$1FullAccess](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [AWS politique gérée : AWSLambda\$1ReadOnlyAccess](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [AWS politique gérée : AWSLambda BasicExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [AWS politique gérée : AWSLambda BasicDurableExecutionRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [AWS stratégie gérée : AWSLambda Dynamo Role DBExecution](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [AWS politique gérée : AWSLambda ENIManagement Accès](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [AWS politique gérée : AWSLambdaInvocation-DynamoDB](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [AWS politique gérée : AWSLambda KinesisExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [AWS politique gérée : AWSLambda MSKExecution rôle](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [AWS politique gérée : AWSLambda rôle](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [AWS politique gérée : AWSLambda SQSQueue ExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [AWS politique gérée : AWSLambda VPCAccess ExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [AWS politique gérée : AWSLambda Géré EC2 ResourceOperator](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [AWS politique gérée : AWSLambda ServiceRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [Mises à jour Lambda des politiques gérées AWS](#lambda-security-iam-awsmanpol-updates)
## AWS politique gérée : AWSLambda\$1FullAccess
Cette stratégie accorde un accès complet aux actions Lambda. Il accorde également des autorisations à d'autres AWS services utilisés pour développer et gérer les ressources Lambda.
Vous pouvez attacher la stratégie `AWSLambda_FullAccess` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `lambda` : donne aux principaux un accès complet à Lambda.
+ `cloudformation`— Permet aux directeurs de décrire les AWS CloudFormation piles et de répertorier les ressources qu'elles contiennent.
+ `cloudwatch`— Permet aux principaux de répertorier les CloudWatch métriques Amazon et d'obtenir des données métriques.
+ `ec2`— Permet aux principaux de décrire les groupes de sécurité, les sous-réseaux et. VPCs
+ `iam` : permet aux principaux d’obtenir les stratégies, les versions des stratégies, les rôles, les stratégies de rôle, les stratégies de rôles associées et la liste des rôles. Cette stratégie permet également aux principaux de transmettre des rôles à Lambda. L’autorisation `PassRole` est utilisée lorsque vous attribuez un rôle d’exécution à une fonction. L'`CreateServiceLinkedRole`autorisation est utilisée lors de la création d'un rôle lié à un service.
+ `kms`— Permet aux principaux de répertorier les alias et de décrire la clé pour le chiffrement des volumes.
+ `logs` : permet aux principaux de décrire les flux de journaux, d’obtenir les événements du journal, de filtrer les événements du journal et de démarrer et arrêter dsessions Live Tail.
+ `states`— Permet aux directeurs de décrire et de répertorier les machines AWS Step Functions d'état.
+ `tag` : permet aux principaux d’obtenir des ressources en fonction de leurs balises.
+ `xray`— Permet aux principaux d'obtenir des résumés de AWS X-Ray traces et de récupérer une liste de traces spécifiée par ID.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda\$1ReadOnlyAccess
Cette politique accorde un accès en lecture seule aux ressources Lambda et aux autres AWS services utilisés pour développer et gérer les ressources Lambda.
Vous pouvez attacher la stratégie `AWSLambda_ReadOnlyAccess` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `lambda` : permet aux principaux d’obtenir et de répertorier toutes les ressources.
+ `cloudformation`— Permet aux directeurs de décrire et de répertorier les AWS CloudFormation piles et de répertorier les ressources qu'elles contiennent.
+ `cloudwatch`— Permet aux principaux de répertorier les CloudWatch métriques Amazon et d'obtenir des données métriques.
+ `ec2`— Permet aux principaux de décrire les groupes de sécurité, les sous-réseaux et. VPCs
+ `iam` : permet aux principaux d’obtenir les stratégies, les versions des stratégies, les rôles, les stratégies de rôle, les stratégies de rôles associées et la liste des rôles.
+ `kms` : permet aux principaux de répertorier les alias.
+ `logs` : permet aux principaux de décrire les flux de journaux, d’obtenir les événements du journal, de filtrer les événements du journal et de démarrer et arrêter dsessions Live Tail.
+ `states`— Permet aux directeurs de décrire et de répertorier les machines AWS Step Functions d'état.
+ `tag` : permet aux principaux d’obtenir des ressources en fonction de leurs balises.
+ `xray`— Permet aux principaux d'obtenir des résumés de AWS X-Ray traces et de récupérer une liste de traces spécifiée par ID.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda BasicExecutionRole
Cette politique accorde des autorisations pour télécharger des CloudWatch journaux dans Logs.
Vous pouvez attacher la stratégie `AWSLambdaBasicExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda BasicDurableExecutionRolePolicy
Cette politique fournit des autorisations d'écriture aux CloudWatch journaux et read/write des autorisations d'exécution durable APIs utilisées par les fonctions durables Lambda. Cette politique fournit les autorisations essentielles requises pour les fonctions durables Lambda, qui utilisent l'exécution durable pour maintenir la progression et maintenir l'état d'un appel de fonction APIs à l'autre.
Vous pouvez attacher la stratégie `AWSLambdaBasicDurableExecutionRolePolicy` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `logs`— Permet aux principaux de créer des groupes de journaux et des flux de journaux, et d'écrire les événements des journaux dans les CloudWatch journaux.
+ `lambda`— Permet aux principaux de vérifier l'état d'exécution durable et de récupérer l'état d'exécution durable pour les fonctions durables Lambda.
Pour plus de détails sur cette politique, y compris la dernière version du document sur la politique JSON, consultez [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) dans le *Guide de référence de la politique gérée par AWS *.
## AWS stratégie gérée : AWSLambda Dynamo Role DBExecution
Cette politique accorde des autorisations pour lire les enregistrements d'un flux Amazon DynamoDB et pour écrire dans Logs. CloudWatch
Vous pouvez attacher la stratégie `AWSLambdaDynamoDBExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaDynamo DBExecution Role](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) dans le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda ENIManagement Accès
Cette stratégie accorde les autorisations nécessaires pour créer, décrire et supprimer des interfaces réseau Elastic utilisées par une fonction Lambda compatible VPC.
Vous pouvez attacher la stratégie `AWSLambdaENIManagementAccess` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) dans le *guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambdaInvocation-DynamoDB
Cette stratégie accorde un accès en lecture à Amazon DynamoDB Streams.
Vous pouvez attacher la stratégie `AWSLambdaInvocation-DynamoDB` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda KinesisExecutionRole
Cette politique accorde l'autorisation de lire les événements d'un flux de données Amazon Kinesis et d'écrire dans Logs. CloudWatch
Vous pouvez attacher la stratégie `AWSLambdaKinesisExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda MSKExecution rôle
Cette politique autorise la lecture et l'accès aux enregistrements d'un cluster Amazon Managed Streaming for Apache Kafka, la gestion des interfaces réseau élastiques et l'écriture dans les CloudWatch journaux.
Vous pouvez attacher la stratégie `AWSLambdaMSKExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, voir [AWSLambdaMSKExecutionRôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) dans le *guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda rôle
Cette stratégie accorde des autorisations pour invoquer les fonctions Lambda.
Vous pouvez attacher la stratégie `AWSLambdaRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, voir [AWSLambdaRôle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) dans le *guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda SQSQueue ExecutionRole
Cette politique accorde des autorisations pour lire et supprimer des messages d'une file d'attente Amazon Simple Queue Service, et accorde des autorisations d'écriture aux CloudWatch journaux.
Vous pouvez attacher la stratégie `AWSLambdaSQSQueueExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda VPCAccess ExecutionRole
Cette politique accorde des autorisations pour gérer des interfaces réseau élastiques au sein d'un Amazon Virtual Private Cloud et pour écrire dans CloudWatch Logs.
Vous pouvez attacher la stratégie `AWSLambdaVPCAccessExecutionRole` à vos utilisateurs, groupes et rôles.
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, consultez [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)le *Guide de référence des politiques AWS gérées*.
## AWS politique gérée : AWSLambda Géré EC2 ResourceOperator
Cette politique permet la gestion automatisée des instances Amazon Elastic Compute Cloud pour les fournisseurs de capacité Lambda. Il accorde des autorisations au service Lambda Scaler pour effectuer des opérations sur le cycle de vie des instances en votre nom.
Vous pouvez attacher la stratégie `AWSLambdaManagedEC2ResourceOperator` à vos utilisateurs, groupes et rôles.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `ec2:RunInstances`— Permet à Lambda de lancer de nouvelles instances Amazon EC2 à condition que ec2 ManagedResourceOperator : soit égal à scaler.lambda.amazonaws.com et limite l'utilisation des AMI aux images appartenant à Amazon uniquement.
+ `ec2:DescribeInstances`et `ec2:DescribeInstanceStatus` — Permet à Lambda de surveiller l'état de l'instance et de récupérer les informations relatives à l'instance.
+ `ec2:CreateTags`— Permet à Lambda de baliser les ressources Amazon EC2 à des fins de gestion et d'identification.
+ `ec2:DescribeAvailabilityZones`— Permet à Lambda de visualiser les zones disponibles pour les décisions de placement des instances.
+ `ec2:DescribeCapacityReservations`— Permet à Lambda de vérifier les réservations de capacité pour un placement optimal des instances.
+ `ec2:DescribeInstanceTypes`et `ec2:DescribeInstanceTypeOfferings` — Permet à Lambda de passer en revue les types d'instances disponibles et leurs offres.
+ `ec2:DescribeSubnets`— Permet à Lambda d'examiner les configurations de sous-réseau pour la planification du réseau.
+ `ec2:DescribeSecurityGroups`— Permet à Lambda de récupérer les informations du groupe de sécurité pour la configuration de l'interface réseau.
+ `ec2:CreateNetworkInterface`— Permet à Lambda de créer des interfaces réseau et de gérer les associations de sous-réseaux et de groupes de sécurité.
+ `ec2:AttachNetworkInterface`[— Permet à Lambda d'associer des interfaces réseau aux instances Amazon EC2 avec la condition `ec2:ManagedResourceOperator` égale à scaler.lambda.amazonaws.com.](http://scaler.lambda.amazonaws.com/)
Pour plus d'informations sur cette politique, y compris le document de politique JSON et les versions de politique, voir [AWSLambdaManaged EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : AWSLambda ServiceRolePolicy
Cette politique est attachée au rôle lié au service nommé pour permettre à Lambda AWSService RoleForLambda de mettre fin aux instances gérées dans le cadre des fournisseurs de capacité Lambda.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `ec2:TerminateInstances`— Permet à Lambda de mettre fin aux instances EC2 à la condition que ec2 : soit égal à scaler.lambda.amazonaws.com. ManagedResourceOperator
+ `ec2:DescribeInstanceStatus`et `ec2:DescribeInstances` — Permet à Lambda de décrire les instances EC2.
Pour plus d'informations sur cette politique, consultez la section [Utilisation de rôles liés à un service pour Lambda](using-service-linked-roles.md).
## Mises à jour Lambda des politiques gérées AWS
| Modifier | Description | Date |
| --- | --- | --- |
| [AWSLambdaGéré EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) — Nouvelle politique | Lambda a ajouté une nouvelle politique gérée pour permettre la gestion automatisée des instances Amazon EC2 pour les fournisseurs de capacité Lambda, permettant ainsi au service de scaler d'effectuer des opérations sur le cycle de vie des instances. | 30 novembre 2025 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) : nouvelle politique | Lambda a ajouté une nouvelle politique gérée pour le rôle lié au service afin de permettre à Lambda de mettre fin aux instances gérées dans le cadre des fournisseurs de capacité Lambda. | 30 novembre 2025 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Modification | Lambda a mis à jour la `AWSLambda_FullAccess` politique pour autoriser les actions `kms:DescribeKey` et`iam:CreateServiceLinkedRole`. | 30 novembre 2025 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)— Nouvelle politique gérée | Lambda a publié une nouvelle politique gérée `AWSLambdaBasicDurableExecutionRolePolicy` qui fournit des autorisations d'écriture aux CloudWatch journaux et des read/write autorisations d'exécution durable APIs utilisées par les fonctions durables Lambda. | 1er décembre 2025 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)et [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Modifier | Lambda a mis à jour les politiques `AWSLambda_ReadOnlyAccess` et `AWSLambda_FullAccess` pour autoriser les actions `logs:StartLiveTail` et `logs:StopLiveTail`. | 17 mars 2025 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)— Modification | Lambda a mis à jour la politique `AWSLambdaVPCAccessExecutionRole` pour autoriser l’action `ec2:DescribeSubnets`. | 5 janvier 2024 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Modification | Lambda a mis à jour la `AWSLambda_ReadOnlyAccess` politique pour autoriser les principaux à répertorier les piles. CloudFormation | 27 juillet 2023 |
| AWS Lambda a commencé à suivre les modifications | AWS Lambda a commencé à suivre les modifications apportées AWS à ses politiques gérées. | 27 juillet 2023 |
# Résolution des problèmes AWS Lambda d'identité et d'accès
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Lambda et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Lambda](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite permettre à des personnes extérieures à moi d'accéder Compte AWS à mes ressources Lambda](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans Lambda
Si vous recevez une erreur qui indique que vous n’êtes pas autorisé à effectuer une action, vos politiques doivent être mises à jour afin de vous permettre d’effectuer l’action.
L’exemple d’erreur suivant se produit quand l’utilisateur IAM `mateojackson` tente d’utiliser la console pour afficher des informations détaillées sur une ressource `my-example-widget` fictive, mais ne dispose pas des autorisations `lambda:GetWidget` fictives.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
Dans ce cas, la politique qui s’applique à l’utilisateur `mateojackson` doit être mise à jour pour autoriser l’accès à la ressource `my-example-widget` à l’aide de l’action `lambda:GetWidget`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez une erreur selon laquelle vous n’êtes pas autorisé à exécuter l’action `iam:PassRole`, vos politiques doivent être mises à jour pour vous permettre de transmettre un rôle à Lambda.
Certains vous Services AWS permettent de transmettre un rôle existant à ce service au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L’exemple d’erreur suivant se produit quand un utilisateur IAM nommé `marymajor` tente d’utiliser la console pour exécuter une action dans Lambda. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite permettre à des personnes extérieures à moi d'accéder Compte AWS à mes ressources Lambda
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Lambda prend en charge ces fonctions, consultez [Comment AWS Lambda fonctionne avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
# Création d’une stratégie de gouvernance pour les couches et les fonctions Lambda
Pour créer et déployer des applications cloud natives sans serveur, vous devez garantir agilité et rapidité de mise sur le marché grâce à une gouvernance et à des barrières de protection appropriés. Vous définissez des priorités au niveau de l'entreprise, en mettant peut-être l'accent sur l'agilité comme priorité absolue, ou en insistant sur l'aversion au risque par le biais de la gouvernance, de barrières de protection et de contrôles. En réalité, vous n'aurez pas une stratégie « l'un ou l'autre », mais une stratégie « et » qui équilibre à la fois agilité et barrières de protection dans le cycle de vie de votre développement logiciel. Quelle que soit la place de ces exigences dans le cycle de vie de votre entreprise, les capacités de gouvernance sont susceptibles de devenir une exigence de mise en œuvre dans vos processus et chaînes d'outils.
Voici quelques exemples de contrôles de gouvernance qu'une organisation peut mettre en œuvre pour Lambda :
+ Les fonctions Lambda ne doivent pas être publiquement accessibles.
+ Les fonctions Lambda doivent être associées à un VPC.
+ Les fonctions Lambda ne doivent pas utiliser d'environnements d'exécution obsolètes.
+ Les fonctions Lambda doivent être étiquetées avec un ensemble de balises obligatoires.
+ Les couches Lambda ne doivent pas être accessibles en dehors de l'organisation.
+ Les fonctions Lambda associées à un groupe de sécurité doivent avoir des balises correspondantes entre la fonction et le groupe de sécurité.
+ Les fonctions Lambda associées à une couche doivent utiliser une version approuvée
+ Les variables d'environnement Lambda doivent être chiffrées au repos avec une clé gérée par le client.
Le schéma suivant est un exemple de stratégie de gouvernance approfondie qui met en œuvre des contrôles et des politiques tout au long du processus de développement et de déploiement du logiciel :
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-concepts.png)
Les rubriques suivantes expliquent comment implémenter des contrôles pour développer et déployer des fonctions Lambda dans votre organisation, à la fois pour la start-up et pour l'entreprise. Votre organisation possède peut-être déjà des outils en place. Les rubriques suivantes adoptent une approche modulaire de ces contrôles, afin que vous puissiez sélectionner les composants dont vous avez réellement besoin.
**Topics**
+ [Contrôles proactifs pour Lambda avec AWS CloudFormation Guard](governance-cloudformation-guard.md)
+ [Mettez en œuvre des contrôles préventifs pour Lambda avec AWS Config](governance-config.md)
+ [Détectez les déploiements et les configurations Lambda non conformes avec AWS Config](governance-config-detection.md)
+ [Signature de code Lambda avec AWS Signer](governance-code-signing.md)
+ [Automatisation des évaluations de sécurité pour Lambda avec Amazon Inspector](governance-code-scanning.md)
+ [Mettre en œuvre l'observabilité pour la sécurité et la conformité Lambda](governance-observability.md)
# Contrôles proactifs pour Lambda avec AWS CloudFormation Guard
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) est un outil d'évaluation des politiques en tant que code open source à usage général. Cela peut être utilisé à des fins de gouvernance préventive et de conformité en validant les modèles d'infrastructure en tant que code (IaC) et les compositions de services par rapport aux règles de politique. Ces règles peuvent être personnalisées en fonction des exigences de votre équipe ou de votre organisation. Pour les fonctions Lambda, les règles Guard peuvent être utilisées pour contrôler la création de ressources et les mises à jour de configuration en définissant les paramètres de propriété requis lors de la création ou de la mise à jour d'une fonction Lambda.
Les administrateurs de conformité définissent la liste des contrôles et des politiques de gouvernance nécessaires au déploiement et à la mise à jour des fonctions Lambda. Les administrateurs de plateforme mettent en œuvre les contrôles dans les pipelines CI/CD, sous forme de webhooks de validation préalable à la validation avec des référentiels de code, et fournissent aux développeurs des outils en ligne de commande pour valider les modèles et le code sur les postes de travail locaux. Les développeurs créent du code, valident les modèles à l'aide d'outils de ligne de commande, puis valident le code dans des référentiels, qui sont ensuite automatiquement validés via les pipelines CI/CD avant le déploiement dans un environnement AWS.
Guard vous permet d'[écrire vos règles](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) et d'implémenter vos contrôles dans un langage spécifique au domaine comme suit.
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-cloudformation-guard.png)
Supposons, par exemple, que vous souhaitiez vous assurer que les développeurs choisissent uniquement les derniers environnements d'exécution. Vous pouvez spécifier deux politiques différentes, l'une pour identifier les [environnements d'exécution](lambda-runtimes.md) déjà obsolètes et l'autre pour identifier les environnements d'exécution qui le seront bientôt. Pour cela, vous pouvez écrire le fichier `etc/rules.guard` suivant :
```
let lambda_functions = Resources.*[
Type == "AWS::Lambda::Function"
]
rule lambda_already_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <>
}
}
}
}
rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty {
%lambda_functions {
Properties {
when Runtime exists {
Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <>
}
}
}
}
```
Supposons maintenant que vous écriviez le modèle `iac/lambda.yaml` CloudFormation suivant qui définit une fonction Lambda :
```
Fn:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.7
CodeUri: src
Handler: fn.handler
Role: !GetAtt FnRole.Arn
Layers:
- arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35
```
Après avoir [installé](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) l'utilitaire Guard, validez votre modèle :
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
Le résultat se présente comme suit :
```
lambda.yaml Status = FAIL
FAILED rules
rules.guard/lambda_soon_to_be_deprecated_runtime
---
Evaluating data lambda.yaml against rules rules.guard
Number of non-compliant resources 1
Resource = Fn {
Type = AWS::Lambda::Function
Rule = lambda_soon_to_be_deprecated_runtime {
ALL {
Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] {
ComparisonError {
Message = Lambda function is using a runtime that is targeted for deprecation.
Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])]
}
PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15]
Operator = NOT IN
Value = "python3.7"
ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]]
Code:
86. Fn:
87. Type: AWS::Lambda::Function
88. Properties:
89. Runtime: python3.7
90. CodeUri: src
91. Handler: fn.handler
}
}
}
}
```
Guard permet à vos développeurs de savoir depuis leur poste de travail local qu'ils doivent mettre à jour le modèle afin d'utiliser un environnement d'exécution autorisé par l'organisation. Cela se produit avant la validation dans un référentiel de code et avant l'échec des vérifications dans un pipeline CI/CD. Vos développeurs reçoivent ainsi des informations sur la manière de développer des modèles conformes et de consacrer leur temps à l'écriture de code apportant une valeur commerciale. Ce contrôle peut être appliqué sur le poste de travail du développeur local, dans un webhook de validation préalable à la validation et/ou dans le pipeline CI/CD avant le déploiement.
## Mises en garde
Si vous utilisez des modèles AWS Serverless Application Model (AWS SAM) pour définir des fonctions Lambda, sachez que vous devez mettre à jour la règle Guard pour rechercher le type de ressource `AWS::Serverless::Function` comme suit.
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
Guard s'attend également à ce que les propriétés soient incluses dans la définition de la ressource. Dans le même temps, les modèles AWS SAM permettent de spécifier les propriétés dans une section [Globals](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) distincte. Les propriétés définies dans la section Globals ne sont pas validées par vos règles Guard.
Comme indiqué dans la [documentation](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) de dépannage de Guard, sachez que Guard ne prend pas en charge les formulaires intrinsèques abrégés tels que `!GetAtt` ou `!Sub` et nécessite plutôt l'utilisation des formulaires étendus : `Fn::GetAtt` et. `Fn::Sub` (L'[exemple précédent](#guard-iac-yaml) n'évaluant pas la propriété Role, la forme abrégée intrinsèque a été utilisée pour des raisons de simplicité.)
# Mettez en œuvre des contrôles préventifs pour Lambda avec AWS Config
Il est essentiel de garantir la conformité de vos applications sans serveur le plus tôt possible dans le processus de développement. Dans cette rubrique, nous expliquons comment mettre en œuvre des contrôles préventifs à l'aide de [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). Cela vous permet de mettre en œuvre des contrôles de conformité plus tôt dans le processus de développement et de mettre en œuvre les mêmes contrôles dans vos CI/CD pipelines. Cela permet également de standardiser vos contrôles dans un référentiel de règles géré de manière centralisée afin que vous puissiez appliquer vos contrôles de manière cohérente sur l'ensemble de vos AWS comptes.
Supposons, par exemple, que vos administrateurs de conformité aient défini une exigence garantissant que toutes les fonctions Lambda incluent AWS X-Ray le traçage. Grâce AWS Config au mode proactif, vous pouvez effectuer des contrôles de conformité sur les ressources de vos fonctions Lambda avant le déploiement, ce qui réduit le risque de déploiement de fonctions Lambda mal configurées et fait gagner du temps aux développeurs en leur fournissant plus rapidement des informations sur l'infrastructure sous forme de modèles de code. Voici une visualisation du flux pour les contrôles préventifs avec AWS Config :
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-1.png)
Envisagez d'exiger que le suivi soit activé pour toutes les fonctions Lambda. En réponse, l'équipe de la plateforme identifie la nécessité d'une AWS Config règle spécifique pour s'exécuter de manière proactive sur tous les comptes. Cette règle signale toute fonction Lambda dont la configuration de suivi X-Ray n'est pas configurée comme une ressource non conforme. L'équipe développe une règle, l'intègre dans un pack de [conformité et déploie le pack](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) de conformité sur tous les comptes afin de garantir que tous les AWS comptes de l'organisation appliquent ces contrôles de manière uniforme. Vous pouvez écrire la règle dans la syntaxe AWS CloudFormation Guard 2.x.x, qui prend la forme suivante :
```
rule name when condition { assertion }
```
Voici un exemple de règle Guard qui vérifie que le suivi est activé pour les fonctions Lambda :
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
[L'équipe de la plateforme prend des mesures supplémentaires en imposant que chaque AWS CloudFormation déploiement invoque un hook de pré-création/mise à jour.](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html) Elle assume l'entière responsabilité du développement de ce hook et de la configuration du pipeline, du renforcement du contrôle centralisé des règles de conformité et du maintien de leur application cohérente dans tous les déploiements. Pour développer, empaqueter et enregistrer un hook, consultez la documentation [AWS CloudFormation Developing Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html) in the CloudFormation Command Line Interface (CFN-CLI). Vous pouvez utiliser la [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) pour créer le projet hook :
```
cfn init
```
Cette commande vous demande des informations de base sur votre projet hook et crée un projet contenant les fichiers suivants :
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
En tant que développeur de hooks, vous devez ajouter le type de ressource cible souhaité dans le fichier `.json` de configuration. Dans la configuration ci-dessous, un hook est configuré pour s'exécuter avant qu'une fonction Lambda ne soit créée à l'aide de. CloudFormation Vous pouvez également ajouter des gestionnaires `preUpdate` et des actions `preDelete` similaires.
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
Vous devez également vous assurer que le CloudFormation hook dispose des autorisations appropriées pour appeler le AWS Config APIs. Vous pouvez le faire en mettant à jour le fichier de définition de rôle nommé `hook-role.yaml`. Le fichier de définition du rôle possède par défaut la politique de confiance suivante, qui permet CloudFormation d'assumer le rôle.
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
Pour permettre à ce hook d'appeler config APIs, vous devez ajouter les autorisations suivantes à la déclaration Policy. Ensuite, vous soumettez le projet hook à l'aide de la `cfn submit` commande, où vous CloudFormation créez un rôle avec les autorisations requises.
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
Ensuite, vous devez écrire une fonction Lambda dans un `src/handler.py` fichier. Dans ce fichier, vous trouverez les méthodes nommées `preCreate`, `preUpdate` et `preDelete` déjà créées lorsque vous avez lancé le projet. Votre objectif est d'écrire une fonction commune et réutilisable qui appelle l' AWS Config `StartResourceEvaluation`API en mode proactif à l'aide du AWS SDK pour Python (Boto3). Cet appel d'API prend les propriétés des ressources en entrée et évalue la ressource par rapport à la définition de la règle.
```
def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent:
LOG.info("Fetching proactive data")
config_client = boto3.client('config')
resource_specs = {
'ResourceId': 'MyFunction',
'ResourceType': resource_type,
'ResourceConfiguration': json.dumps(function_properties),
'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA'
}
LOG.info("Resource Specifications:", resource_specs)
eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60)
ResourceEvaluationId = eval_response.ResourceEvaluationId
compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId)
LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType)
if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType:
return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant)
else:
return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.")
```
Vous pouvez maintenant appeler la fonction commune depuis le gestionnaire pour le hook de pré-création. Voici un exemple de gestionnaire :
```
@hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION)
def pre_create_handler(
session: Optional[SessionProxy],
request: HookHandlerRequest,
callback_context: MutableMapping[str, Any],
type_configuration: TypeConfigurationModel
) -> ProgressEvent:
LOG.info("Starting execution of the hook")
target_name = request.hookContext.targetName
LOG.info("Target Name:", target_name)
if "AWS::Lambda::Function" == target_name:
return validate_lambda_tracing_config(target_name,
request.hookContext.targetModel.get("resourceProperties")
)
else:
raise exceptions.InvalidRequest(f"Unknown target type: {target_name}")
```
Après cette étape, vous pouvez enregistrer le hook et le configurer pour écouter tous les événements de création de AWS Lambda fonctions.
Un développeur prépare le modèle d'infrastructure en tant que code (IaC) pour un microservice sans serveur à l'aide de Lambda. Cette préparation inclut le respect des normes internes, suivi de tests locaux et de validation du modèle dans le référentiel. Voici un exemple de modèle IaC :
```
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
Handler: index.handler
Role: !GetAtt LambdaExecutionRole.Arn
FunctionName: MyLambdaFunction
Code:
ZipFile: |
import json
def handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello World!')
}
Runtime: python3.14
TracingConfig:
Mode: PassThrough
MemorySize: 256
Timeout: 10
```
Dans le cadre du CI/CD processus, lorsque le CloudFormation modèle est déployé, le CloudFormation service invoque le hook de pré-création/mise à jour juste avant le provisionnement du type de ressource. `AWS::Lambda::Function` Le hook utilise des AWS Config règles exécutées en mode proactif pour vérifier que la configuration de la fonction Lambda inclut la configuration de suivi obligatoire. La réponse du hook détermine l'étape suivante. S'il est conforme, le hook signale le succès et CloudFormation procède à la mise à disposition des ressources. Dans le cas contraire, le déploiement de la CloudFormation pile échoue, le pipeline s'arrête immédiatement et le système enregistre les détails pour un examen ultérieur. Les notifications de conformité sont envoyées vers les parties prenantes concernées.
Vous pouvez trouver les success/fail informations relatives au hook dans la CloudFormation console :
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-2.png)
Si les journaux sont activés pour votre CloudFormation hook, vous pouvez capturer le résultat de l'évaluation du hook. Voici un exemple de journal pour un hook dont le statut a échoué, indiquant que X-Ray n'est pas activé sur la fonction Lambda :
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-3.png)
Si le développeur choisit de modifier le modèle IaC pour mettre à jour la valeur `TracingConfig Mode`sur `Active` et le redéployer, le hook s'exécute correctement et la pile poursuit la création de la ressource Lambda.
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-4.png)
Ainsi, vous pouvez mettre en œuvre des contrôles préventifs en mode proactif lors du développement et du déploiement de ressources sans serveur dans vos AWS comptes. AWS Config En intégrant des AWS Config règles dans le CI/CD pipeline, vous pouvez identifier et éventuellement bloquer les déploiements de ressources non conformes, tels que les fonctions Lambda dépourvues de configuration de suivi active. Cela garantit que seules les ressources conformes aux dernières politiques de gouvernance sont déployées dans vos AWS environnements.
# Détectez les déploiements et les configurations Lambda non conformes avec AWS Config
Outre l'[évaluation proactive](governance-config.md), AWS Config vous pouvez également détecter de manière réactive les déploiements de ressources et les configurations non conformes à vos politiques de gouvernance. Cela est important car les politiques de gouvernance évoluent au fur et à mesure que votre organisation apprend et met en œuvre de nouvelles meilleures pratiques.
Imaginons un scénario dans lequel vous définissez une toute nouvelle politique lors du déploiement ou de la mise à jour des fonctions Lambda : toutes les fonctions Lambda doivent toujours utiliser une version de couche Lambda spécifique et approuvée. Vous pouvez configurer AWS Config pour surveiller les fonctions nouvelles ou mises à jour pour les configurations de couches. S'il AWS Config détecte une fonction qui n'utilise pas une version de couche approuvée, il signale la fonction comme une ressource non conforme. Vous pouvez éventuellement configurer AWS Config pour corriger automatiquement la ressource en spécifiant une action de correction à l'aide d'un document d' AWS Systems Manager automatisation. Par exemple, vous pouvez écrire un document d'automatisation en Python à l'aide de AWS SDK pour Python (Boto3), qui met à jour la fonction non conforme pour qu'elle pointe vers la version de couche approuvée. Ainsi, il AWS Config sert à la fois de détection et de contrôle correctif, automatisant la gestion de la conformité.
Décomposons ce processus en trois phases de mise en œuvre importantes :
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-detective-1.png)
## Phase 1 : identification des ressources d'accès
Commencez par l'activer AWS Config sur tous vos comptes et par le configurer pour enregistrer les fonctions AWS Lambda. Cela permet d' AWS Config observer quand les fonctions Lambda sont créées ou mises à jour. Vous pouvez ensuite configurer [des règles de stratégie personnalisées](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) pour vérifier les violations de politique spécifiques, en utilisant la syntaxe AWS CloudFormation Guard . Les règles de garde prennent la forme générale suivante :
```
rule name when condition { assertion }
```
Vous trouverez ci-dessous un exemple de règle qui vérifie qu'une couche n'est pas définie sur une ancienne version de couche :
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
Découvrons la syntaxe et la structure des règles :
+ **Nom de la règle :** le nom de la règle est `desiredlayer` dans l'exemple fourni.
+ **Condition :** cette clause spécifie la condition dans laquelle la règle doit être vérifiée. Dans l'exemple fourni, la condition est `configuration.layers !empty`. Cela signifie que la ressource ne doit être évaluée que lorsque la propriété `layers` de la configuration n'est pas vide.
+ **Assertion :** après la clause `when`, une assertion détermine ce que la règle vérifie. L'assertion `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` vérifie si l'une des couches Lambda ne correspond ARNs pas à la `OldLayerArn` valeur. S'ils ne correspondent pas, l'assertion est vraie et la règle est acceptée ; sinon, elle échoue.
`CONFIG_RULE_PARAMETERS`est un ensemble spécial de paramètres configuré avec la AWS Config règle. Dans ce cas, `OldLayerArn` est un paramètre dans `CONFIG_RULE_PARAMETERS`. Cela permet aux utilisateurs de fournir une valeur d'ARN spécifique qu'ils considèrent comme ancienne ou obsolète, puis la règle vérifie si des fonctions Lambda utilisent cet ancien ARN.
## Phase 2 : Visualisation et conception
AWS Config collecte les données de configuration et les stocke dans des compartiments Amazon Simple Storage Service (Amazon S3). Vous pouvez utiliser [Amazon Athena](https://aws.amazon.com/athena/) pour interroger ces données directement depuis vos compartiments S3. Avec Athena, vous pouvez agréger ces données au niveau de l'organisation, en générant une vue globale de la configuration de vos ressources sur l'ensemble de vos comptes. Pour configurer l'agrégation des données de configuration des ressources, consultez [Visualiser les AWS Config données à l'aide d'Athena et d'Amazon](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) Quick sur AWS le blog Cloud Operations and Management.
Voici un exemple de requête Athena pour identifier toutes les fonctions Lambda à l'aide d'un ARN de couche particulier :
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.version') AS version
FROM
unnested
WHERE
lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%'
```
Voici les résultats de la requête :
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-detective-2.png)
Une fois les AWS Config données agrégées au sein de l'organisation, vous pouvez créer un tableau de bord à l'aide d'[Amazon Quick](https://aws.amazon.com/quicksight/). En important vos résultats Athena dans Quick, vous pouvez visualiser dans quelle mesure vos fonctions Lambda respectent la règle de version de la couche. Ce tableau de bord peut mettre en évidence les ressources conformes et non conformes, ce qui vous aide à déterminer votre politique d'application, comme indiqué dans la [section suivante](#governance-config-detective-implement). L'image suivante est un exemple de tableau de bord qui indique la distribution des versions de couches appliquées aux fonctions au sein de l'organisation.
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-config-detective-3.png)
## Phase 3 : mettre en œuvre et appliquer
Vous pouvez désormais éventuellement associer la règle de version de couche que vous avez créée lors de la [phase 1](#governance-config-detective-identify) à une action de correction via un document d'automatisation de Systems Manager, que vous créez sous forme de script Python écrit avec AWS SDK pour Python (Boto3). Le script appelle l'action [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)API pour chaque fonction Lambda, en mettant à jour la configuration de la fonction avec le nouvel ARN de couche. Vous pouvez également demander au script de soumettre une pull request au référentiel de code pour mettre à jour l'ARN de la couche. De cette façon, les futurs déploiements de code sont également mis à jour avec le bon ARN de couche.
# Signature de code Lambda avec AWS Signer
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) est un service de signature de code entièrement géré qui vous permet de valider votre code par le biais d'une signature numérique afin de confirmer que le code n'a pas été modifié et qu'il provient d'un diffuseur de publication. AWS Signer peut être utilisé conjointement avec AWS Lambda pour vérifier que les fonctions et les couches ne sont pas modifiées avant le déploiement dans vos environnements AWS. Cela protège votre organisation contre les acteurs malveillants susceptibles d'avoir obtenu des informations d'identification pour créer de nouvelles fonctions ou mettre à jour des fonctions existantes.
Pour configurer la signature de code pour vos fonctions Lambda, commencez par créer un compartiment S3 avec la gestion des versions activée. Ensuite, créez un profil de signature avec AWS Signer, spécifiez Lambda comme plate-forme, puis spécifiez une période de jours pendant laquelle le profil de signature est valide. Exemple :
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
Utilisez ensuite le profil de signature et créez une configuration de signature avec Lambda. Vous devez spécifier ce qu'il convient de faire lorsque la configuration de signature détecte un artefact qui ne correspond pas à la signature numérique attendue : avertir (mais autoriser le déploiement) ou appliquer (et bloquer le déploiement). L'exemple ci-dessous est configuré pour appliquer et bloquer les déploiements.
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
AWS Signer est à présent configuré avec Lambda pour bloquer les déploiements non fiables. Supposons que vous avez terminé de coder une demande de fonctionnalité et que vous êtes maintenant prêt à déployer la fonction. La première étape consiste à compresser le code avec les dépendances appropriées, puis à signer l'artefact à l'aide du profil de signature que vous avez créé. Vous pouvez le faire en téléchargeant l'artefact zip dans le compartiment S3, puis en lançant une tâche de signature.
```
aws signer start-signing-job \
--source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \
--destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \
--profile-name your-signer-id
```
Vous obtenez un résultat comme suit, où le `jobId` est l'objet créé dans le compartiment et le préfixe de destination et `jobOwner` l'identifiant Compte AWS à 12 chiffres où le travail a été exécuté.
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
Vous pouvez désormais déployer votre fonction à l'aide de l'objet S3 signé et de la configuration de signature de code que vous avez créée.
```
Fn:
Type: AWS::Serverless::Function
Properties:
CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip
Handler: fn.handler
Role: !GetAtt FnRole.Arn
CodeSigningConfigArn: !Ref pSigningConfigArn
```
Vous pouvez également tester le déploiement d'une fonction avec l'artefact zip source non signé d'origine. Le déploiement devrait échouer avec le message d'erreur suivant : .
```
Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned.
```
Si vous créez et déployez vos fonctions à l'aide de AWS Serverless Application Model (AWS SAM), la commande package gère le téléchargement de l'artefact zip vers S3, lance également le travail de signature et obtient l'artefact signé. Pour ce faire, vous pouvez utiliser la commande avec les paramètres suivants :
```
sam package -t your-template.yaml \
--output-template-file your-output.yaml \
--s3-bucket your-versioned-bucket \
--s3-prefix your-prefix \
--signing-profiles your-signer-id
```
AWS Signer vous permet de vérifier que le déploiement des artefacts ZIP déployés dans vos comptes est fiable. Vous pouvez inclure le processus ci-dessus dans vos pipelines CI/CD et exiger que toutes les fonctions soient associées à une configuration de signature de code en utilisant les techniques décrites dans les rubriques précédentes. En utilisant la signature de code dans vos déploiements de fonctions Lambda, vous empêchez les acteurs malveillants susceptibles d'avoir obtenu des informations d'identification pour créer ou mettre à jour des fonctions d'injecter du code malveillant dans vos fonctions.
# Automatisation des évaluations de sécurité pour Lambda avec Amazon Inspector
[Amazon Inspector](https://aws.amazon.com/inspector/) est un service de gestion des vulnérabilités qui analyse continuellement les charges de travail pour détecter les vulnérabilités logicielles connues et l'exposition involontaire au réseau. Amazon Inspector crée une constatation qui décrit la vulnérabilité, identifie la ressource affectée, évalue la gravité de la vulnérabilité et fournit des conseils pour y remédier.
Le support d'Amazon Inspector fournit une évaluation automatique et continue des vulnérabilités de sécurité pour les fonctions et les couches Lambda. Amazon Inspector propose deux types de scan pour Lambda :
+ **Analyse standard Lambda (par défaut) :** analyse les dépendances des applications au sein d'une fonction Lambda et de ses couches pour détecter les [vulnérabilités des packages](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package).
+ **Analyse du code Lambda :** analyse le code d'application personnalisé dans vos fonctions et couches pour détecter les [vulnérabilités du code](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code). Vous pouvez activer l’analyse standard Lambda ou activer l’analyse standard Lambda conjointement avec l’analyse du code Lambda.
Pour activer Amazon Inspector, accédez à la [console Amazon Inspector](https://console.aws.amazon.com/inspector/), développez la section **Paramètres** et choisissez **Gestion des comptes**. Dans l'onglet **Comptes**, choisissez **Activer**, puis sélectionnez l'une des options d’analyse.
Vous pouvez activer Amazon Inspector pour plusieurs comptes et déléguer les autorisations de gestion d'Amazon Inspector pour l'organisation à des comptes spécifiques lors de la configuration d'Amazon Inspector. Lors de l'activation, vous devez accorder des autorisations à Amazon Inspector en créant le rôle :`AWSServiceRoleForAmazonInspector2`. La console Amazon Inspector vous permet de créer ce rôle à l'aide d'une option en un clic.
Pour l'analyse standard Lambda, Amazon Inspector lance des analyses de vulnérabilité des fonctions Lambda dans les situations suivantes :
+ Dès qu'Amazon Inspector découvre une fonction Lambda existante.
+ Lorsque vous déployez une fonction Lambda.
+ Lorsque vous déployez une mise à jour du code d'application ou des dépendances d'une fonction Lambda existante ou de ses couches.
+ Chaque fois qu'Amazon Inspector ajoute un nouvel élément Common Vulnerabilities and Exposures (CVE) à sa base de données, et que ce CVE est pertinent pour votre fonction.
Pour l’analyse du code Lambda, Amazon Inspector évalue le code d'application de votre fonction Lambda à l'aide d'un raisonnement automatisé et d'un machine learning qui analyse le code de votre application pour vérifier sa conformité globale en matière de sécurité. Si Amazon Inspector détecte une vulnérabilité dans le code d'application de votre fonction Lambda, Amazon Inspector produit une recherche détaillée de **vulnérabilité dans le code**. Pour obtenir la liste des détections possibles, consultez la bibliothèque de détecteurs [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/detector-library/).
Pour consulter les résultats, rendez-vous sur la [console Amazon Inspector](https://console.aws.amazon.com/inspector/). Dans le menu **Résultats**, choisissez **Par fonction Lambda** pour afficher les résultats de l’analyse de sécurité effectuée sur les fonctions Lambda.
Pour exclure une fonction Lambda de l’analyse standard, balisez la fonction avec la paire clé-valeur suivante :
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
Pour exclure une fonction Lambda des analyses du code, balisez la fonction avec la paire clé-valeur suivante :
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
Par exemple, comme le montre l'image suivante, Amazon Inspector détecte automatiquement les vulnérabilités et classe les résultats de type **Vulnérabilité de code**, ce qui indique que la vulnérabilité se trouve dans le code de la fonction, et non dans l'une des bibliothèques dépendantes du code. Vous pouvez vérifier ces informations pour une fonction spécifique ou pour plusieurs fonctions à la fois.
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-code-scanning-1.png)
Vous pouvez approfondir chacun de ces résultats et découvrir comment remédier au problème.
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-code-scanning-2.png)
Lorsque vous travaillez avec vos fonctions Lambda, assurez-vous de respecter les conventions de dénomination de vos fonctions Lambda. Pour de plus amples informations, consultez [Utilisation des variables d’environnement Lambda](configuration-envvars.md).
Vous êtes responsable des suggestions de correction que vous acceptez. Passez toujours en revue les suggestions de correction avant de les accepter. Vous devrez peut-être apporter des modifications aux suggestions de correction pour vous assurer que votre code répond à vos attentes.
# Mettre en œuvre l'observabilité pour la sécurité et la conformité Lambda
AWS Config est un outil utile pour rechercher et corriger les ressources AWS sans serveur non conformes. Chaque modification que vous apportez à vos ressources sans serveur est enregistrée dans AWS Config. Vous AWS Config permet également de stocker des données de capture instantanée de configuration sur S3. Vous pouvez utiliser Amazon Athena et Amazon Quick pour créer des tableaux de bord et consulter les données. AWS Config Dans [Détectez les déploiements et les configurations Lambda non conformes avec AWS Config](governance-config-detection.md), nous avons discuté de la manière dont nous pouvons visualiser une certaine configuration, comme les couches Lambda. Cette rubrique développe ces concepts.
## Visibilité sur les configurations Lambda
Vous pouvez utiliser des requêtes pour extraire des configurations importantes telles que l' Compte AWS ID, la région, la configuration de AWS X-Ray suivi, la configuration VPC, la taille de la mémoire, le temps d'exécution et les balises. Voici un exemple de requête que vous pouvez utiliser pour extraire ces informations d'Athena :
```
WITH unnested AS (
SELECT
item.awsaccountid AS account_id,
item.awsregion AS region,
item.configuration AS lambda_configuration,
item.resourceid AS resourceid,
item.resourcename AS resourcename,
item.configuration AS configuration,
json_parse(item.configuration) AS lambda_json
FROM
default.aws_config_configuration_snapshot,
UNNEST(configurationitems) as t(item)
WHERE
"dt" = 'latest'
AND item.resourcetype = 'AWS::Lambda::Function'
)
SELECT DISTINCT
account_id,
tags,
region as Region,
resourcename as FunctionName,
json_extract_scalar(lambda_json, '$.memorySize') AS memory_size,
json_extract_scalar(lambda_json, '$.timeout') AS timeout,
json_extract_scalar(lambda_json, '$.runtime') AS version
json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig
json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig
FROM
unnested
```
Vous pouvez utiliser la requête pour créer un tableau de bord rapide et visualiser les données. Pour agréger les données de configuration des AWS ressources, créer des tables dans Athena et créer des tableaux de bord rapides à partir des données d'Athena, consultez la section Visualisation des données à [l'aide d' AWS Config Athena et d'Amazon Quick sur le blog Cloud Operations and](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) Management. AWS Notamment, cette requête récupère également les informations de balise pour les fonctions. Cela permet de mieux comprendre vos charges de travail et vos environnements, en particulier si vous utilisez des balises personnalisées.
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-observability-1.png)
Pour plus d'informations sur les actions que vous pouvez entreprendre, consultez la section [Prise en compte des constatations relatives à l'observabilité](#governance-observability-addressing) plus loin dans cette rubrique.
## Visibilité sur la conformité à Lambda
Avec les données générées par AWS Config, vous pouvez créer des tableaux de bord au niveau de l'organisation pour surveiller la conformité. Cela permet un suivi et une surveillance cohérents de :
+ Packs de conformité par score de conformité
+ Règles en fonction des ressources non conformes
+ Statut de conformité
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-observability-2.png)
Vérifiez chaque règle pour identifier les ressources non conformes à cette règle. Par exemple, si votre organisation impose que toutes les fonctions Lambda soient associées à un VPC et si vous avez déployé une AWS Config règle pour identifier la conformité, vous pouvez sélectionner la `lambda-inside-vpc` règle dans la liste ci-dessus.
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-observability-3.png)
Pour plus d'informations sur les actions que vous pouvez entreprendre, consultez la section [Prise en compte des constatations relatives à l'observabilité](#governance-observability-addressing) ci-dessous.
## Visibilité des limites des fonctions Lambda à l'aide de Security Hub CSPM
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-observability-4.png)
Pour garantir que les AWS services tels que Lambda sont utilisés en toute sécurité, nous avons AWS introduit les meilleures pratiques de sécurité fondamentales v1.0.0. Cet ensemble de bonnes pratiques fournit des directives claires pour sécuriser les ressources et les données dans l' AWS environnement, en soulignant l'importance de maintenir une posture de sécurité solide. Il AWS Security Hub CSPM complète cela en proposant un centre de sécurité et de conformité unifié. Il regroupe, organise et hiérarchise les résultats de sécurité provenant de plusieurs AWS services tels qu'Amazon Inspector AWS Identity and Access Management Access Analyzer et Amazon. GuardDuty
Si Security Hub CSPM, Amazon Inspector, IAM Access Analyzer sont GuardDuty activés au sein de votre organisation, AWS Security Hub CSPM agrège automatiquement les résultats de ces services. Prenons par exemple Amazon Inspector. Security Hub CSPM vous permet d'identifier efficacement les vulnérabilités du code et des packages dans les fonctions Lambda. Dans la console Security Hub CSPM, accédez à la section inférieure intitulée **Dernières découvertes en matière d' AWS **intégrations. Ici, vous pouvez consulter et analyser les résultats provenant de divers AWS services intégrés.
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-observability-5.png)
Pour voir les détails, cliquez sur le lien **Voir les résultats** dans la deuxième colonne. Cela affiche une liste des résultats filtrés par produit, comme Amazon Inspector. Pour limiter votre recherche aux fonctions Lambda, définissez `ResourceType` sur `AwsLambdaFunction`. Cela affiche les résultats d'Amazon Inspector relatifs aux fonctions Lambda.
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/governance-observability-6.png)
En GuardDuty effet, vous pouvez identifier les modèles de trafic réseau suspects. De telles anomalies peuvent suggérer l'existence d'un code potentiellement malveillant dans votre fonction Lambda.
Avec IAM Access Analyzer, vous pouvez vérifier les politiques, en particulier celles comportant des instructions de condition qui accordent l'accès aux fonctions à des entités externes. De plus, IAM Access Analyzer évalue les autorisations définies lors de l'utilisation de l'[AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)opération dans l'API Lambda avec un. `EventSourceToken`
## Prise en compte des constatations relatives à l'observabilité
Compte tenu du large éventail de configurations possibles pour les fonctions Lambda et de leurs exigences distinctes, une solution d'automatisation standardisée pour la correction peut ne pas convenir à toutes les situations. De plus, les modifications sont mises en œuvre différemment selon les environnements. Si vous rencontrez une configuration qui ne semble pas conforme, tenez compte des directives suivantes :
1. **Stratégie de balisage**
Nous vous recommandons de mettre en œuvre une stratégie de balisage complète. Chaque fonction Lambda doit être étiquetée avec des informations clés telles que :
+ **Propriétaire :** personne ou équipe responsable de la fonction.
+ **Environnement :** production, mise en scène, développement ou bac à sable.
+ **Application :** le contexte plus large auquel appartient cette fonction, le cas échéant.
1. **Sensibilisation des propriétaires**
Au lieu d'automatiser les modifications majeures (comme l'ajustement de la configuration du VPC), contactez de manière proactive les propriétaires des fonctions non conformes (identifiées par le tag du propriétaire) en leur laissant suffisamment de temps pour :
+ Ajuster les configurations non conformes sur les fonctions Lambda.
+ Fournir une explication et demander une exception, ou affiner les normes de conformité.
1. **Gestion d'une base de gestion des configurations (CMDB)**
Bien que les balises puissent fournir un contexte immédiat, le maintien d'une CMDB centralisée peut fournir des informations plus approfondies. Il peut contenir des informations plus détaillées sur chaque fonction Lambda, ses dépendances et d'autres métadonnées critiques. Une CMDB est une ressource inestimable pour les audits, les contrôles de conformité et l'identification des responsables des fonctions.
Le paysage de l'infrastructure sans serveur étant en constante évolution, il est essentiel d'adopter une position proactive en matière de surveillance. Grâce à des outils tels que AWS Config Security Hub CSPM et Amazon Inspector, les anomalies potentielles ou les configurations non conformes peuvent être rapidement identifiées. Cependant, les outils ne peuvent à eux seuls garantir une conformité totale ou des configurations optimales. Il est essentiel d'associer ces outils à des processus bien documentés et aux meilleures pratiques.
+ **Boucle de rétroaction :** une fois les étapes de correction entreprises, assurez-vous qu'il existe une boucle de rétroaction. Cela implique de revoir régulièrement les ressources non conformes pour vérifier si elles ont été mises à jour ou si elles présentent toujours les mêmes problèmes.
+ **Documentation :** documentez toujours les observations, les mesures prises et les exceptions accordées. Une documentation appropriée aide non seulement lors des audits, mais contribue également à améliorer le processus afin d'améliorer la conformité et la sécurité à l'avenir.
+ **Formation et sensibilisation :** assurez-vous que toutes les parties prenantes, en particulier les responsables des fonctions Lambda, sont régulièrement formées et informées des meilleures pratiques, des politiques organisationnelles et des mandats de conformité. Des ateliers, des webinaires ou des sessions de formation réguliers peuvent contribuer dans une large mesure à garantir que tout le monde est sur la même longueur d'onde en matière de sécurité et de conformité.
En conclusion, alors que les outils et les technologies fournissent des capacités robustes pour détecter et signaler les problèmes potentiels, l'élément humain (compréhension, communication, formation et documentation) reste essentiel. Ensemble, ils forment une puissante combinaison qui garantit que vos fonctions Lambda et votre infrastructure globale restent conformes, sécurisées et optimisées pour répondre aux besoins de votre entreprise.
# Validation de la conformité pour AWS Lambda
Les auditeurs tiers évaluent la sécurité et la conformité de AWS Lambda dans le cadre de plusieurs programmes de conformité AWS. Il s'agit notamment des certifications SOC, PCI, FedRAMP, HIPAA et autres.
Pour obtenir la liste des services AWS concernés par des programmes de conformité spécifiques, consultez [Services AWS concernés par les programmes de conformité](https://aws.amazon.com/compliance/services-in-scope/). Pour obtenir des informations générales, veuillez consulter [Programmes de conformité AWS](https://aws.amazon.com/compliance/programs/).
Vous pouvez télécharger les rapports de l'audit externe avec AWS Artifact. Pour plus d'informations, consultez [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Votre responsabilité de conformité lors de l'utilisation de Lambda est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise, ainsi que par la législation et la réglementation applicables. Vous pouvez mettre en œuvre des contrôles de gouvernance pour garantir que les fonctions Lambda de votre entreprise répondent à vos exigences de conformité. Pour de plus amples informations, consultez [Création d’une stratégie de gouvernance pour les couches et les fonctions Lambda](governance-concepts.md).
# Résilience dans AWS Lambda
L’infrastructure mondiale d’AWS repose sur les Régions AWS et les zones de disponibilité AWS. Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, reliées par un réseau à latence faible, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour de plus amples informations sur les régions et les zones de disponibilité AWS, veuillez consulter [Infrastructure mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Outre l’infrastructure globale d’AWS, Lambda propose plusieurs fonctions qui contribuent à la prise en charge de vos besoins en matière de résilience et de sauvegarde des données.
+ **Gestion des versions** – Vous pouvez utiliser la gestion des versions dans Lambda pour enregistrer le code et la configuration de votre fonction à mesure que vous la développez. Avec les alias, vous pouvez utiliser la gestion des versions pour effectuer des déploiements bleu/vert et de roulement. Pour plus d’informations, consultez [Gestion des versions d’une fonction Lambda](configuration-versions.md).
+ **Mise à l’échelle** – Lorsque votre fonction reçoit une demande tandis qu’elle traite une demande précédente, Lambda lance une autre instance de votre fonction pour gérer la charge accrue. Lambda adapte automatiquement son échelle pour gérer 1 000 exécutions simultanées par région, un [quota](gettingstarted-limits.md) qui peut être augmenté si nécessaire. Pour en savoir plus, consultez [Présentation de la mise à l’échelle de fonction Lambda](lambda-concurrency.md).
+ **Haute disponibilité** – Lambda exécute votre fonction dans plusieurs zones de disponibilité afin de vous assurer qu’elle est disponible pour traiter les événements en cas d’interruption de service dans une seule zone. Si vous configurez votre fonction pour vous connecter à un cloud privé virtuel (VPC) de votre compte, spécifiez les sous-réseaux dans plusieurs zones de disponibilité, pour une garantie de haute disponibilité. Pour plus d’informations, consultez [Octroi aux fonctions Lambda d’un accès aux ressources d’un Amazon VPC](configuration-vpc.md).
+ **Simultanéité réservée** – Pour vous assurer que votre fonction peut toujours adapter son échelle afin de gérer des demandes supplémentaires, vous pouvez réserver de la simultanéité. La définition de la simultanéité réservée pour une fonction permet de s’assurer qu’elle peut être mise à l’échelle, sans le dépasser, un certain nombre spécifié d’appels simultanés. Cela garantit que vous ne perdez pas les demandes en raison d’autres fonctions utilisant toute la simultanéité disponible. Pour plus d’informations, consultez [Configuration de la simultanéité réservée pour une fonction](configuration-concurrency.md).
+ **Nouvelles tentatives** – Pour les appels asynchrones et un sous-ensemble d’appels déclenchés par d’autres services, en cas d’erreur, Lambda effectue automatiquement de nouvelles tentatives espacées. Les autres clients et les Services AWS qui invoquent des fonctions de manière synchrone sont responsables de l’exécution des nouvelles tentatives. Pour en savoir plus, consultez [Présentation du comportement des nouvelles tentatives dans Lambda](invocation-retries.md).
+ **Files d’attente de lettres mortes** – Pour les appels asynchrones, vous pouvez configurer Lambda de façon à envoyer à une file d’attente de lettres mortes les demandes qui ont échoué à toutes les tentatives. Une file d’attente de lettres mortes est une rubrique Amazon SNS ou une file d’attente Amazon SQS qui reçoit des événements en vue de leur dépannage ou d’un nouveau traitement. Pour en savoir plus, consultez [Ajout d’une file d’attente de lettres mortes](invocation-async-retain-records.md#invocation-dlq).
# Sécurité de l'infrastructure dans AWS Lambda
En tant que service géré, AWS Lambda est protégé par les procédures de sécurité du réseau mondial AWS. Pour plus d’informations sur les services de sécurité AWS et la manière dont AWS protège l’infrastructure, consultez la section [Sécurité du cloud AWS](https://aws.amazon.com/security/). Pour concevoir votre environnement AWS en utilisant les meilleures pratiques en matière de sécurité de l’infrastructure, consultez la section [Protection de l’infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le *Security Pillar AWS Well‐Architected Framework* (Pilier de sécurité de l’infrastructure Well‐Architected Framework).
Vous utilisez les appels d'API publiés par AWS pour accéder à Lambda via le réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
# Sécurisation des charges de travail avec des points de terminaison publics
Pour les charges de travail accessibles au public, AWS fournit un certain nombre de fonctionnalités et de services qui peuvent aider à atténuer certains risques. Cette section aborde l’authentification et l’autorisation des utilisateurs de l’application ainsi que la protection des points de terminaison d’API.
## Authentification et autorisation
L’authentification est liée à l’identité et l’autorisation concerne les actions. Utilisez l’authentification pour contrôler qui peut invoquer une fonction Lambda, puis utilisez l’autorisation pour contrôler qui peut faire quoi. Pour de nombreuses applications, IAM est suffisant pour gérer les deux mécanismes de contrôle.
Pour les applications utilisant des utilisateurs externes, telles que les applications Web ou mobiles, il est courant d’utiliser des [jetons Web JSON](https://jwt.io/introduction/) (JWT) pour gérer l’authentification et l’autorisation. Contrairement à la gestion traditionnelle des mots de passe basée sur le serveur, les JWT sont transmis par le client à chaque demande. Ils constituent un moyen cryptographiquement sécurisé de vérifier l’identité et les demandes à l’aide des données transmises par le client. Pour les applications basées sur Lambda, cela vous permet de sécuriser chaque appel vers chaque point de terminaison d’API sans avoir recours à un serveur central pour l’authentification.
Vous pouvez [implémenter des JWT avec Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), un service de répertoire d’utilisateurs capable de gérer l’enregistrement, l’authentification, la récupération des comptes et d’autres opérations courantes de gestion des comptes. Le [cadre Amplify](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) fournit des bibliothèques pour simplifier l’intégration de ce service dans votre application frontale. Vous pouvez également envisager des services partenaires tiers comme [Auth0](https://auth0.com/).
Compte tenu du rôle critique d’un service de fournisseur d’identité en matière de sécurité, il est important d’utiliser des outils professionnels pour protéger votre application. Il n’est pas recommandé de créer vos propres services pour gérer l’authentification ou l’autorisation. Toute vulnérabilité dans les bibliothèques personnalisées peut avoir des répercussions importantes sur la sécurité de votre charge de travail et de ses données.
## Protection des points de terminaison d’API
Pour les applications sans serveur, la méthode préférée pour servir publiquement une application dorsale consiste à utiliser Amazon API Gateway. Cela peut vous aider à protéger une API contre les utilisateurs malveillants ou les pics de trafic.
API Gateway propose deux types de points de terminaison pour les développeurs sans serveur : les [API REST](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) et les [API HTTP](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). Les deux prennent en charge l’[autorisation avec AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), IAM ou Amazon Cognito. Lorsque vous utilisez IAM ou Amazon Cognito, les demandes entrantes sont évaluées et si elles ne contiennent pas le jeton requis ou si elles contiennent une authentification non valide, la demande est rejetée. Ces demandes ne vous sont pas facturées et elles ne sont pas prises en compte dans le calcul des quotas de limitation.
N’importe qui peut accéder aux routes d’API non authentifiées sur l’Internet public. Il est donc recommandé de limiter l’utilisation d’API non authentifiées. Si vous devez utiliser des API non authentifiées, il est important de les protéger contre les risques courants, tels que les attaques par [déni de service](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS). [ Appliquer AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) à ces API peut aider à protéger votre application contre les attaques par injection SQL et par scripts inter-site (XSS). API Gateway implémente également la [limitation](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) au niveau du compte AWS et par client lorsque des clés d’API sont utilisées.
Dans de nombreux cas, les fonctionnalités fournies par une API non authentifiée peuvent être obtenues par une autre approche. Par exemple, une application Web peut fournir une liste des magasins de détail clients à partir d’une table DynamoDB aux utilisateurs non connectés. Cette demande peut provenir d’une application Web frontale ou de toute autre source qui appelle le point de terminaison de l’URL. Ce schéma compare trois solutions :
![\[figure d’opérations de sécurité 5\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/security-ops-figure-5.png)
1. Cette API non authentifiée peut être appelée par quiconque sur Internet. Lors d’une attaque par déni de service, il est possible d’épuiser les limites de limitation des API, de simultanéité Lambda ou de capacité de lecture allouée par DynamoDB sur une table sous-jacente.
1. Une distribution CloudFront devant le point de terminaison de l’API avec une configuration de la [durée de vie](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) appropriée absorberait la majeure partie du trafic lors d’une attaque DoS, sans modifier la solution sous-jacente pour récupérer les données.
1. Sinon, pour les données statiques qui changent rarement, la distribution CloudFront peut servir les données d’un compartiment Amazon S3.
# Utilisation de la signature de code pour vérifier l’intégrité du code avec Lambda
La signature de code permet de s’assurer que seul du code approuvé est déployé dans vos fonctions Lambda. À l'aide de AWS Signer, vous pouvez créer des packages de code signés numériquement pour vos fonctions. Lorsque vous [ajoutez une configuration de signature de code à une fonction](configuration-codesigning-create.md), Lambda vérifie que tous les nouveaux déploiements de code sont signés par une source approuvée. Étant donné que les contrôles de validation de signature de code s’exécutent au moment du déploiement, l’exécution de la fonction n’est aucunement affectée.
**Important**
Les configurations de signature de code empêchent uniquement les nouveaux déploiements de code non signé. Si vous ajoutez une configuration de signature de code à une fonction existante contenant du code non signé, ce code continue de s’exécuter jusqu’à ce que vous déployiez un nouveau package de code.
Lorsque vous activez la signature de code pour une fonction, toutes les [couches](chapter-layers.md) que vous ajoutez à la fonction doivent également être signées par un profil de signature autorisé.
Il n'y a aucun frais supplémentaire pour l'utilisation AWS Signer ou la signature de code pour AWS Lambda.
## Validation de signature
Lambda effectue les contrôles de validation suivants lorsque vous déployez un package de code signé vers votre fonction :
1. **Intégrité** : vérifie que le package de code n’a pas été modifié depuis sa signature. Lambda compare le hachage du package au hachage de la signature.
1. **Expiration** : affirme que la signature du package de code n’a pas expiré.
1. **Incompatibilité** : affirme que le package de code est signé avec un profil de signature autorisé
1. **Révocation** : affirme que la signature du package de code n’a pas été révoquée.
Lorsque vous créez une configuration de signature de code, vous pouvez utiliser le [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment)paramètre pour spécifier la manière dont Lambda doit réagir en cas d'échec des contrôles d'expiration, d'incompatibilité ou de révocation. Vous pouvez choisir l’une de ces actions :
+ `Warn` : il s’agit du paramètre par défaut. Lambda autorise le déploiement du package de code, mais émet un avertissement. Lambda émet une nouvelle CloudWatch métrique Amazon (`SignatureValidationErrors`) et enregistre également l'avertissement dans le CloudTrail journal.
+ `Enforce` : Lambda émet un avertissement (identique à celui de l’action `Warn`) et bloque le déploiement du package de code.
**Topics**
+ [Validation de signature](#config-codesigning-valid)
+ [Création de configurations de signature de code pour Lambda](configuration-codesigning-create.md)
+ [Configuration des politiques IAM pour les configurations de signature de code Lambda](config-codesigning-policies.md)
+ [Utilisation des balises dans les configurations de signature de code](tags-csc.md)
# Création de configurations de signature de code pour Lambda
Afin d'activer la signature de code pour une fonction, vous créez une *configuration de signature de code* et l'attachez à la fonction. Une configuration de signature de code définit une liste de profils de signature autorisés et l'action de stratégie à privilégier en cas d'échec de l'un des contrôles de validation.
**Note**
Les fonctions définies en tant qu'images de conteneur ne prennent pas en charge la signature de code.
**Topics**
+ [Conditions préalables à la configuration](#config-codesigning-prereqs)
+ [Création de configurations de signature de code](#config-codesigning-config-console)
+ [Activation de la signature de code pour une fonction](#config-codesigning-function-console)
## Conditions préalables à la configuration
Avant de pouvoir configurer la signature de code pour une fonction Lambda, utilisez le Signataire AWS pour effectuer les opérations suivantes :
+ Créer un ou plusieurs [profils de signature](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html).
+ Utiliser un profil de signature afin de [créer un package de code signé pour votre fonction](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html).
## Création de configurations de signature de code
Une configuration de signature de code définit une liste des profils de signature autorisés et la stratégie de validation de signature.
**Pour créer une configuration de signature de code (console)**
1. Ouvrez la [page des configurations de signature de code](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) de la console Lambda.
1. Choisissez **Create configuration (Créer une configuration)**.
1. Pour **Description**, saisissez un nom descriptif pour la configuration.
1. Sous **Signing profiles (Profils de signature)**, ajoutez jusqu'à 20 profils de signature à la configuration.
1. Pour **Signing profile version ARN (ARN de la version du profil de signature)**, sélectionnez l'Amazon Resource Name (ARN) de la version du profil, ou saisissez l'ARN.
1. Pour ajouter un profil de signature supplémentaire, sélectionnez **Add signing profiles (Ajouter des profils de signature)**.
1. Sous **Signature validation policy (Stratégie de validation de signature)**, sélectionnez **Warn (Avertissement)** ou **Enforce (Application)**.
1. Choisissez **Create configuration (Créer une configuration)**.
## Activation de la signature de code pour une fonction
Afin d’activer la signature de code pour une fonction, ajoutez une configuration de signature de code à la fonction.
**Important**
Les configurations de signature de code empêchent uniquement les nouveaux déploiements de code non signé. Si vous ajoutez une configuration de signature de code à une fonction existante contenant du code non signé, ce code continue de s’exécuter jusqu’à ce que vous déployiez un nouveau package de code.
**Pour associer une configuration de signature de code à une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction pour laquelle vous souhaitez activer la signature de code.
1. Ouvrez l’onglet **Configuration**.
1. Faites défiler vers le bas et choisissez **Signature de code**.
1. Choisissez **Modifier**.
1. Sous **Edit code signing (Modifier la signature de code)**, sélectionnez une configuration de signature de code pour cette fonction.
1. Choisissez **Enregistrer**.
# Configuration des politiques IAM pour les configurations de signature de code Lambda
Pour accorder à un utilisateur l’autorisation d’accéder aux opérations d’API de signature de code Lambda, attachez une ou plusieurs instructions de stratégie à la stratégie utilisateur. Pour plus d'informations sur les stratégies utilisateur, consultez [Politiques IAM basées sur l’identité pour Lambda](access-control-identity-based.md).
L'exemple d'instruction de stratégie suivant autorise la création, la mise à jour et la récupération de configurations de signature de code.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
Les administrateurs peuvent utiliser la clé de condition `CodeSigningConfigArn` pour spécifier les configurations de signature de code que les développeurs doivent utiliser pour créer ou mettre à jour vos fonctions.
L'exemple de déclaration de stratégie suivant accorde l'autorisation de créer une fonction. La déclaration de stratégie comprend une condition `lambda:CodeSigningConfigArn` pour spécifier la configuration de signature de code autorisée. Lambda bloque les demandes `CreateFunction` d'API si le [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn)paramètre est absent ou ne correspond pas à la valeur de la condition.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# Utilisation des balises dans les configurations de signature de code
Vous pouvez étiqueter les configurations de signature de code pour organiser et gérer vos ressources. Les balises sont des paires clé-valeur de forme libre associées à vos ressources prises en charge par l’ensemble des ressources Services AWS. Pour plus d'informations sur les cas d'utilisation des balises, consultez la section [Stratégies de balisage courantes dans le guide des AWS](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) *ressources de balisage et de l'éditeur de balises*.
Vous pouvez utiliser l' AWS Lambda API pour afficher et mettre à jour les balises. Vous pouvez également afficher et mettre à jour les balises tout en gérant une configuration de signature de code spécifique dans la console Lambda.
**Topics**
+ [Autorisations requises pour l’utilisation des balises](#csc-tags-required-permissions)
+ [Utilisation des balises avec la console Lambda](#tags-csc-console)
+ [Utilisation de balises avec le AWS CLI](#tags-csc-cli)
## Autorisations requises pour l’utilisation des balises
Pour autoriser une identité Gestion des identités et des accès AWS (IAM) – utilisateur, groupe ou rôle – à afficher ou marquer les ressources, accordez-lui les autorisations correspondantes :
+ **lambda : ListTags** —Lorsqu' une ressource possède des balises, accordez cette autorisation à tous ceux qui ont besoin de `ListTags` l'utiliser. Pour les fonctions balisées, cette autorisation est également nécessaire pour `GetFunction`.
+ **lambda : TagResource** —Accordez cette autorisation à toute personne ayant besoin d'appeler `TagResource` ou d'exécuter un tag lors de la création.
Vous pouvez éventuellement envisager d'accorder également l'UntagResourceautorisation **lambda :** pour autoriser les `UntagResource` appels à la ressource.
Pour de plus amples informations, veuillez consulter [Politiques IAM basées sur l’identité pour Lambda](access-control-identity-based.md).
## Utilisation des balises avec la console Lambda
Vous pouvez utiliser la console Lambda pour créer des configurations de signature de code qui comportent des balises, pour ajouter des balises aux configurations de signature de code existantes et pour filtrer des configurations de signature de code par balise.
**Ajout d’une balise lors de la création d’une configuration de signature de code**
1. Ouvrez la page [Configurations de signature de code](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) dans la console Lambda.
1. Dans l’en-tête du volet de contenu, choisissez **Créer une configuration**.
1. Dans la section située en haut du volet de contenu, configurez votre signature de code. Pour plus d’informations sur la configuration des configurations de signature de code, consultez [Utilisation de la signature de code pour vérifier l’intégrité du code avec Lambda](configuration-codesigning.md).
1. Dans la section **Balises**, choisissez **Ajouter une balise**.
1. Dans le champ **Clé**, saisissez la clé de votre balise. Pour plus d'informations sur les restrictions relatives au balisage, consultez la section [Limites et exigences relatives au nommage des balises](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) dans le Guide des * AWS ressources de balisage et de l'éditeur de balises*.
1. Choisissez **Créer une configuration**.
**Pour ajouter une balise à une configuration de signature de code existante**
1. Ouvrez la page [Configurations de signature de code](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) dans la console Lambda.
1. Sélectionnez le nom de votre configuration de signature de code.
1. Dans les onglets situés sous le volet **Détails**, sélectionnez **Balises**.
1. Choisissez **Gérer les balises**.
1. Choisissez **Add new tag** (Ajouter une nouvelle balise).
1. Dans le champ **Clé**, saisissez la clé de votre balise. Pour plus d'informations sur les restrictions relatives au balisage, consultez la section [Limites et exigences relatives au nommage des balises](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) dans le Guide des * AWS ressources de balisage et de l'éditeur de balises*.
1. Choisissez **Enregistrer**.
**Pour filtrer les configurations de signature de code par balise**
1. Ouvrez la page [Configurations de signature de code](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) dans la console Lambda.
1. Cliquez sur la barre de recherche.
1. Dans la liste déroulante, sélectionnez votre balise sous le sous-titre **Balises**.
1. Sélectionnez **Utiliser : « tag-name »** pour afficher toutes les configurations de signature de code étiquetées avec cette touche, ou choisissez un **Opérateur** pour affiner le filtrage en fonction de la valeur.
1. Sélectionnez votre valeur de balise pour appliquer un filtre combinant la clé et la valeur de la balise.
La zone de recherche prend également en charge la recherche de clés de balise. Saisissez le nom d’une clé pour la rechercher dans la liste.
## Utilisation de balises avec le AWS CLI
Vous pouvez ajouter et supprimer des balises sur les ressources Lambda existantes, configurations de signature de code incluses, avec l’API Lambda. Il est également possible d’ajouter des balises lors de la création d’une configuration de signature de code, vous permettant ainsi de conserver une ressource étiquetée tout au long de son cycle de vie.
### Mise à jour des balises avec la balise Lambda APIs
Vous pouvez ajouter et supprimer des balises pour les ressources Lambda prises en charge par le biais des opérations [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)et de l'[UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API.
Vous pouvez appeler ces opérations par l’intermédiaire de l’ AWS CLI. Pour ajouter des balises à une ressource existante, utilisez la commande `tag-resource`. Cet exemple ajoute deux balises, l'une avec la clé *Department* et l'autre avec la clé*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Pour supprimer des balises, utilisez la commande `untag-resource`. Cet exemple supprime la balise contenant la clé*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Ajout de balises lors de la création d’une configuration de signature de code
Pour créer une nouvelle configuration de signature de code Lambda avec des balises, utilisez l'opération [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html)API. Spécifiez le paramètre `Tags`. Vous pouvez appeler cette opération à l'aide de la `create-code-signing-config` AWS CLI commande et de l'`--tags`option. Pour plus d'informations sur la commande CLI, consultez [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)la *référence des AWS CLI commandes*.
Avant d’utiliser le paramètre `Tags` avec `CreateCodeSigningConfig`, vérifiez que votre rôle dispose de l’autorisation d’étiqueter les ressources en plus des autorisations habituelles nécessaires à cette opération. Pour plus d’informations sur les autorisations requises pour l’étiquetage, consultez [Autorisations requises pour l’utilisation des balises](#csc-tags-required-permissions).
### Afficher les tags avec le tag Lambda APIs
Pour afficher les balises associées à une ressource Lambda spécifique, utilisez l’opération d’API `ListTags`. Pour de plus amples informations, veuillez consulter [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Vous pouvez appeler cette opération à l'aide de la `list-tags` AWS CLI commande en fournissant un ARN (Amazon Resource Name).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtrage de ressources par balise
Vous pouvez utiliser l'opération AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API pour filtrer vos ressources par balises. L’opération `GetResources` reçoit jusqu’à 10 filtres, chaque filtre contenant une clé de balise et jusqu’à 10 valeurs de balise. Vous fournissez `GetResources`avec un `ResourceType` pour filtrer par certains types de ressources.
Vous pouvez appeler cette opération à l'aide de la `get-resources` AWS CLI commande. Pour des exemples d’utilisation de `get-resources`, consultez [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) dans la *Référence des commandes de l’AWS CLI*.