# Seguridad en AWS Lambda
La seguridad en la nube de AWS es la máxima prioridad. Como cliente de AWS, se beneficia de una arquitectura de red y un centro de datos que se han diseñado para satisfacer los requisitos de seguridad de las organizaciones más exigentes.
La seguridad es una responsabilidad compartida entre AWS y el usuario. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) la describe como seguridad *de* la nube y seguridad *en* la nube:
+ **Seguridad de la nube**: AWS es responsable de proteger la infraestructura que ejecuta Servicios de AWS en la nube de AWS. Además, AWS proporciona servicios que puede utilizar de forma segura. Auditores independientes prueban y verifican periódicamente la eficacia de nuestra seguridad en el marco de los [programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/). Para obtener más información acerca de los programas de conformidad que se aplican a AWS Lambda, consulte [Servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/).
+ **Seguridad en la nube**: su responsabilidad se determina según el servicio de AWSque utiliza. También es responsable de otros factores, incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y la normativa aplicables.
Esta documentación le ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando se utiliza Lambda. En los siguientes temas, se le mostrará cómo configurar Lambda para satisfacer sus objetivos de seguridad y conformidad. También aprenderá a utilizar otros Servicios de AWS que ayuden a monitorear y proteger los recursos de Lambda.
Para obtener más información acerca de cómo aplicar los principios de seguridad a las aplicaciones de Lambda, consulte [Security](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops) en Serverless Land.
**Topics**
+ [
# Protección de los datos en AWS Lambda
](security-dataprotection.md)
+ [
# Uso de roles vinculados a servicios en Lambda
](using-service-linked-roles.md)
+ [
# Administración de identidades y accesos para AWS Lambda
](security-iam.md)
+ [
# Cree una estrategia de gobiernanza para las funciones y capas de Lambda
](governance-concepts.md)
+ [
# Validación de conformidad en AWS Lambda
](security-compliance.md)
+ [
# Resiliencia en AWS Lambda
](security-resilience.md)
+ [
# Seguridad de la infraestructura en () AWS Lambda
](security-infrastructure.md)
+ [
# Protección de las cargas de trabajo con puntos de conexión públicos
](security-public-endpoints.md)
+ [
# Uso de la firma de código para verificar la integridad del código con Lambda
](configuration-codesigning.md)
# Protección de los datos en AWS Lambda
El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) de AWS se aplica a la protección de datos de AWS Lambda. Como se describe en este modelo, AWS es responsable de proteger la infraestructura global que ejecuta toda la Nube de AWS. Usted es responsable de mantener el control sobre el contenido alojado en esta infraestructura. Usted también es responsable de las tareas de administración y configuración de seguridad para los Servicios de AWS que utiliza. Para obtener más información sobre la privacidad de los datos, consulte las [Preguntas frecuentes sobre la privacidad de datos](https://aws.amazon.com/compliance/data-privacy-faq/). Para obtener información sobre la protección de datos en Europa, consulte la publicación de blog sobre el [Modelo de responsabilidad compartida de AWS y GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) en el * Blog de seguridad de AWS*.
Con fines de protección de datos, recomendamos proteger las credenciales de la Cuenta de AWS y configurar cuentas de usuario individuales con AWS IAM Identity Center o AWS Identity and Access Management (IAM). De esta manera, solo se otorgan a cada usuario los permisos necesarios para cumplir sus obligaciones laborales. También recomendamos proteger sus datos de la siguiente manera:
+ Utilice la autenticación multifactor (MFA) en cada cuenta.
+ Utilice SSL/TLS para comunicarse con los recursos de AWS. Se recomienda el uso de TLS 1.2 y recomendamos TLS 1.3.
+ Configure los registros de API y de actividad de los usuarios con AWS CloudTrail. Para obtener información sobre cómo utilizar registros de seguimiento de CloudTrail para capturar actividades de AWS, consulte [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) en la *Guía del usuario de AWS CloudTrail*.
+ Utilice las soluciones de cifrado de AWS, junto con todos los controles de seguridad predeterminados dentro de los servicios de Servicios de AWS.
+ Utilice servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger los datos confidenciales almacenados en Amazon S3.
+ Si necesita módulos criptográficos validados FIPS 140-3 al acceder a AWS a través de una interfaz de línea de comandos o una API, utilice un punto de conexión de FIPS. Para obtener más información sobre los puntos de conexión de FIPS disponibles, consulte [Estándar de procesamiento de la información federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Se recomienda encarecidamente no introducir nunca información confidencial o sensible, como, por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de formato libre, tales como el campo **Nombre**. Incluye las situaciones en las que debe trabajar con Lambda u otros Servicios de AWS a través de la consola, la API, la AWS CLI o los SDK de AWS. Cualquier dato que ingrese en etiquetas o campos de formato libre utilizados para nombres se puede emplear para los registros de facturación o diagnóstico. Si proporciona una URL a un servidor externo, recomendamos encarecidamente que no incluya información de credenciales en la URL a fin de validar la solicitud para ese servidor.
**Topics**
+ [
## Cifrado en tránsito
](#security-privacy-intransit)
+ [
# Cifrado de datos en reposo en AWS Lambda
](security-encryption-at-rest.md)
## Cifrado en tránsito
Los puntos de enlace de API de Lambda solo admiten conexiones seguras a través de HTTPS. Al administrar recursos de Lambda con la Consola de administración de AWS, el AWS SDK o la API de Lambda, todas las comunicaciones se cifran con Transport Layer Security (TLS). Para obtener una lista completa de puntos de enlace de API, consulte [Regiones y puntos de enlace de AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html) en la Referencia general de AWS.
Cuando [conecta su función a un sistema de archivos](configuration-filesystem.md), Lambda utiliza el cifrado en tránsito para todas las conexiones. Para obtener más información, consulte [Cifrado de datos en Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) en la *Guía del usuario de Amazon Elastic File System*.
Cuando utilice [variables de entorno](configuration-envvars.md), puede permitir que las funciones auxiliares de cifrado de la consola utilicen el cifrado del lado del cliente para proteger las variables de entorno en tránsito. Para obtener más información, consulte [Asegurar las variables de entorno Lambda](configuration-envvars-encryption.md).
# Cifrado de datos en reposo en AWS Lambda
Lambda siempre proporciona cifrado en reposo para los siguientes recursos mediante una [Clave propiedad de AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) o una [Clave administrada de AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk):
+ Variables de entorno
+ Archivos que carga en Lambda, incluidos los paquetes de implementación y los archivos de capas
+ Asignación de orígenes de eventos, objetos de criterios de filtrado
Si lo desea, puede configurar Lambda para que utilice una clave administrada por el cliente para cifrar las [variables de entorno](configuration-envvars-encryption.md), los [paquetes de implementación .zip](encrypt-zip-package.md) y los [objetos de criterios de filtrado](invocation-eventfiltering.md#filter-criteria-encryption).
Amazon CloudWatch Logs y AWS X-Ray también cifran los datos de manera predeterminada y se pueden configurar para utilizar una clave administrada por el cliente. Para obtener más información, consulte [Encrypt log data in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) y [Data protection in AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html).
## Supervisión de las claves de cifrado para Lambda
Cuando utiliza una clave administrada por el cliente de AWS KMS con Lambda, puede utilizar [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). Los ejemplos siguientes son eventos de CloudTrail para llamadas a `Decrypt`, `DescribeKey` y `GenerateDataKey` que hace Lambda para acceder a los datos cifrados mediante la clave administrada por el cliente.
------
#### [ Decrypt ]
Si usó una clave administrada por el cliente de AWS KMS para cifrar el objeto de [criterios de filtro](invocation-eventfiltering.md#filter-criteria-encryption), Lambda envía una solicitud `Decrypt` en su nombre cuando intenta acceder a él en texto sin formato (por ejemplo, desde una llamada a `ListEventSourceMappings`). El siguiente evento de ejemplo registra la operación `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 usó una clave administrada por el cliente de AWS KMS para cifrar el objeto de [criterios de filtro](invocation-eventfiltering.md#filter-criteria-encryption), Lambda envía una solicitud `DescribeKey` en su nombre cuando intenta acceder a él (por ejemplo, desde una llamada a `GetEventSourceMapping`). El siguiente evento de ejemplo registra la operación `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 ]
Cuando utiliza una clave administrada por el cliente de AWS KMS para cifrar el objeto de [criterios de filtro](invocation-eventfiltering.md#filter-criteria-encryption) en una llamada a `CreateEventSourceMapping` o `UpdateEventSourceMapping`, Lambda envía una solicitud `GenerateDataKey` en su nombre para generar una clave de datos para cifrar los criterios de filtro ([cifrado de sobre](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). El siguiente evento de ejemplo registra la operación `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"
}
```
------
# Uso de roles vinculados a servicios en Lambda
Lambda utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) de AWS Identity and Access Management (IAM). Un rol vinculado a servicios es un tipo único de rol de IAM que está vinculado directamente a Lambda. Los roles vinculados a servicios están predefinidos por Lambda e incluyen los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre.
Lambda define los permisos de sus roles vinculados a servicios, y solo Lambda puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda adjuntar a ninguna otra entidad de IAM.
Solo es posible eliminar un rol vinculado a un servicio después de eliminar sus recursos relacionados. De esta forma, se protegen los recursos de Lambda, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Sí** en la columna **Roles vinculados a servicios**. Elija una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
## Permisos de roles vinculados a servicios para Lambda
Lambda utiliza el rol vinculado a servicios denominado **AWSServiceRoleForLambda**. El rol vinculado al servicio depende de los siguientes servicios para asumir el rol:
+ `lambda.amazonaws.com`
La política de permisos del rol se denomina AWSLambdaServiceRolePolicy y permite que Lambda complete las siguientes acciones en los recursos especificados:
+ Acción: `ec2:TerminateInstances` en `arn:aws:ec2:*:*:instance/*` con la condición de que `ec2:ManagedResourceOperator` sea igual a `scaler.lambda.amazonaws.com`.
+ Acción: `ec2:DescribeInstanceStatus` y `ec2:DescribeInstances` en `*`
Debe configurar los permisos para permitir a sus usuarios, grupos o funciones, crear, editar o eliminar la descripción de un rol vinculado al servicio. Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*.
Para conocer las actualizaciones de políticas administradas, consulte [Políticas administradas de Lambda](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates).
## Creación de un rol vinculado a servicios en Lambda
No necesita crear manualmente un rol vinculado a servicios. Cuando crea un proveedor de capacidad de Lambda en la Consola de administración de AWS, la AWS CLI o la API de AWS, Lambda crea el rol vinculado a servicios en su nombre.
Si elimina este rol vinculado a servicios y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Cuando crea un proveedor de capacidad de Lambda, Lambda vuelve a crear el rol vinculado a servicios en su nombre.
También puede usar la consola de IAM para crear un rol vinculado a servicios con el caso de uso **AWSServiceRoleForLambda**. En la AWS CLI o la API de AWS, cree un rol vinculado al servicio con el nombre de servicio `lambda.amazonaws.com`. Para obtener más información, consulte [Creación de un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) en la *Guía del usuario de IAM*. Si elimina este rol vinculado al servicio, puede utilizar este mismo proceso para volver a crear el rol.
## Modificación de un rol vinculado a servicios en Lambda
Lambda no permite editar el rol vinculado a servicios AWSServiceRoleForLambda. Después de crear un rol vinculado al servicio, no podrá cambiar el nombre del rol, ya que varias entidades podrían hacer referencia al rol. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editar un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*.
## Eliminación de roles vinculados a servicios en Lambda
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. Así no tendrá una entidad no utilizada que no se supervise ni mantenga de forma activa. Sin embargo, debe limpiar los recursos de su rol vinculado al servicio antes de eliminarlo manualmente.
**nota**
Si el servicio de Lambda está utilizando el rol cuando intenta eliminar los recursos, la eliminación podría producir un error. En tal caso, espere unos minutos e intente de nuevo la operación.
**Cómo eliminar recursos de Lambda utilizados por AWSServiceRoleForLambda**
1. Elimine todos los proveedores de capacidad de Lambda de su cuenta. Puede hacerlo con la consola de Lambda, la CLI o la API.
1. Compruebe que no quede ningún proveedor de capacidad de Lambda en su cuenta antes de intentar eliminar el rol vinculado a servicios.
**Eliminación manual del rol vinculado a servicios mediante IAM**
Utilice la consola de IAM, la AWS CLI o la API de AWS para eliminar el rol vinculado a servicios AWSServiceRoleForLambda. Para obtener más información, consulte [Eliminación de un rol vinculado a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*.
## Regiones admitidas para los roles vinculados a servicios de Lambda
Lambda no admite el uso de roles vinculados a servicios en todas las regiones en las que el servicio está disponible. AWSServiceRoleForLambda se admite en las siguientes regiones.
| Nombre de la región | Identidad de la región | Compatibilidad en Lambda |
| --- | --- | --- |
| Este de EE. UU. (Norte de Virginia) | us-east-1 | Sí |
| Este de EE. UU. (Ohio) | us-east-2 | Sí |
| Oeste de EE. UU. (Norte de California) | us-west-1 | Sí |
| Oeste de EE. UU. (Oregón) | us-west-2 | Sí |
| África (Ciudad del Cabo) | af-south-1 | No |
| Asia-Pacífico (Hong Kong) | ap-east-1 | Sí |
| Asia-Pacífico (Yakarta) | ap-southeast-3 | Sí |
| Asia-Pacífico (Bangkok) | ap-southeast-7 | Sí |
| Asia-Pacífico (Mumbai) | ap-south-1 | Sí |
| Asia-Pacífico (Osaka) | ap-northeast-3 | No |
| Asia-Pacífico (Seúl) | ap-northeast-2 | No |
| Asia-Pacífico (Singapur) | ap-southeast-1 | Sí |
| Asia-Pacífico (Sídney) | ap-southeast-2 | Sí |
| Asia-Pacífico (Tokio) | ap-northeast-1 | Sí |
| Canadá (centro) | ca-central-1 | No |
| Europa (Fráncfort) | eu-central-1 | Sí |
| Europa (Irlanda) | eu-west-1 | Sí |
| Europa (Londres) | eu-west-2 | Sí |
| Europa (Milán) | eu-south-1 | No |
| Europa (París) | eu-west-3 | No |
| Europa (Estocolmo) | eu-north-1 | No |
| Medio Oriente (Baréin) | me-south-1 | No |
| Medio Oriente (EAU) | me-central-1 | No |
| América del Sur (São Paulo) | sa-east-1 | No |
| AWS GovCloud (Este de EE. UU.) | us-gov-east-1 | No |
| AWS GovCloud (Oeste de EE. UU.) | us-gov-west-1 | No |
# Administración de identidades y accesos para AWS Lambda
AWS Identity and Access Management (IAM) es un Servicio de AWS que ayuda a los administradores a controlar de forma segura el acceso a los recursos de AWS. Los administradores de IAM controlan quién está *autenticado* (ha iniciado sesión) y *autorizado* (tiene permisos) para utilizar recursos de Lambda. IAM es un Servicio de AWS que se puede utilizar sin cargo adicional.
**Topics**
+ [
## Público
](#security_iam_audience)
+ [
## Autenticación con identidades
](#security_iam_authentication)
+ [
## Administración del acceso con políticas
](#security_iam_access-manage)
+ [
# Cómo AWS Lambda funciona con IAM
](security_iam_service-with-iam.md)
+ [
# Ejemplos de políticas basadas en identidades de AWS Lambda
](security_iam_id-based-policy-examples.md)
+ [
# AWS Políticas administradas de para AWS Lambda
](security-iam-awsmanpol.md)
+ [
# Solución de problemas de identidades de AWS Lambda y accesos
](security_iam_troubleshoot.md)
## Público
La forma de utilizar AWS Identity and Access Management (IAM) varía en función del rol:
+ **Usuario del servicio:** solicite permisos al administrador si no puede acceder a las características (consulte [Solución de problemas de identidades de AWS Lambda y accesos](security_iam_troubleshoot.md)).
+ **Administrador del servicio:** determine el acceso de los usuarios y envíe las solicitudes de permiso (consulte [Cómo AWS Lambda funciona con IAM](security_iam_service-with-iam.md)).
+ **Administrador de IAM**: escribe las políticas para administrar el acceso (consulte [Ejemplos de políticas basadas en identidades de AWS Lambda](security_iam_id-based-policy-examples.md)).
## Autenticación con identidades
La autenticación es la manera de iniciar sesión en AWS mediante credenciales de identidad. Debe autenticarse como el Usuario raíz de la cuenta de AWS, como un usuario de IAM o asumiendo un rol de IAM.
Se puede iniciar sesión como una identidad federada con las credenciales de un origen de identidad, como AWS IAM Identity Center (IAM Identity Center), la autenticación de inicio de sesión único o las credenciales de Google/Facebook. Para obtener más información sobre el inicio de sesión, consulte [Cómo iniciar sesión en la Cuenta de AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) en la *Guía del usuario de AWS Sign-In*.
Para el acceso mediante programación, AWS proporciona un SDK y una CLI para firmar criptográficamente las solicitudes. Para obtener más información, consulte [AWS Signature Version 4 para solicitudes de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) en la *Guía del usuario de IAM*.
### Usuario raíz de la Cuenta de AWS
Cuando se crea una Cuenta de AWS, se comienza con una identidad de inicio de sesión denominada *usuario raíz* de la Cuenta de AWS que tiene acceso completo a todos los Servicios de AWS y recursos. Se recomiendaencarecidamente que no utilice el usuario raíz para las tareas diarias. Para ver las tareas que requieren credenciales de usuario raíz, consulte [Tareas que requieren credenciales de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) en la *Guía del usuario de IAM*.
### Identidad federada
Como práctica recomendada, exija a los usuarios humanos que utilicen la federación con un proveedor de identidades para acceder a Servicios de AWS con credenciales temporales.
Una *identidad federada* es un usuario del directorio empresarial, proveedor de identidad web o Directory Service que accede a los Servicios de AWS mediante credenciales de un origen de identidad. Las identidades federadas asumen roles que proporcionan credenciales temporales.
Para una administración de acceso centralizada, se recomienda AWS IAM Identity Center. Para obtener más información, consulte [¿Qué es el Centro de identidades de IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) en la *Guía del usuario de AWS IAM Identity Center*.
### Usuarios y grupos de IAM
Un *[usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* es una identidad con permisos específicos para una sola persona o aplicación. Recomendamos el uso de credenciales temporales en lugar de usuarios de IAM con credenciales de larga duración. Para obtener más información, consulte [Exigir que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS con credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la *Guía del usuario de IAM*.
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica un conjunto de usuarios de IAM y facilita la administración de los permisos para grupos grandes de usuarios. Para obtener más información, consulte [Casos de uso para usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) en la *Guía del usuario de IAM*.
### Roles de IAM
Un *[Rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* es una identidad con permisos específicos que proporciona credenciales temporales. Se puede asumir un rol [cambiando de un usuario a un rol de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o llamando a una operación de la API de la AWS CLI o AWS. Para obtener más información, consulte [Métodos para asumir un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) en la *Guía del usuario de IAM*.
Los roles de IAM son útiles para el acceso de usuario federado, los permisos de usuario de IAM temporales, el acceso entre cuentas, el acceso entre servicios y las aplicaciones que se ejecutan en Amazon EC2. Para obtener más información, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
## Administración del acceso con políticas
Para controlar el acceso en AWS, se crean políticas y se adjuntan a identidades o recursos de AWS. Una política define los permisos cuando se asocia a una identidad o un recurso. AWS evalúa estas políticas cuando una entidad principal realiza una solicitud. La mayoría de las políticas se almacenan en AWS como documentos JSON. Para obtener más información sobre los documentos de políticas de JSON, consulte [Información general de políticas de JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*.
Mediante las políticas, los administradores especifican quién tiene acceso a qué, definiendo qué **entidad principal** puede realizar **acciones** sobre qué **recursos** y en qué **condiciones**.
De forma predeterminada, los usuarios y los roles no tienen permisos. Un administrador de IAM crea políticas de IAM y las agrega a roles, que los usuarios pueden asumir posteriormente. Las políticas de IAM definen permisos independientemente del método que se utilice para realizar la operación.
### Políticas basadas en identidades
Las políticas basadas en identidad son documentos de política de permisos JSON que asocia a una identidad (usuario, grupo o rol). Estas políticas controlan qué acciones pueden realizar las identidades, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Las políticas basadas en identidad pueden ser *políticas insertadas* (incrustadas directamente en una sola identidad) o *políticas administradas* (políticas independientes asociadas a varias identidades). Para obtener información sobre cómo elegir entre políticas administradas e insertadas, consulte [Selección entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) en la *Guía del usuario de IAM*.
### Políticas basadas en recursos
Las políticas basadas en recursos son documentos de políticas JSON que se asocian a un recurso. Los ejemplos incluyen las *Políticas de confianza de roles* de IAM y las *Políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos.
Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No se pueden utilizar políticas de IAM administradas por AWS en una política basada en recursos.
### Otros tipos de políticas
AWS admite tipos de políticas adicionales que pueden establecer el máximo de permisos concedidos por los tipos de políticas más frecuentes:
+ **Límites de permisos:** establecen los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Para obtener más información, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.
+ **Políticas de control de servicios (SCP):** especifican los permisos máximos para una organización o unidad organizativa en AWS Organizations. Para obtener más información, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS Organizations*.
+ **Políticas de control de recursos (RCP):** definen los permisos máximos disponibles para los recursos de las cuentas. Para obtener más información, consulte [Políticas de control de recursos (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) en la *Guía del usuario de AWS Organizations*.
+ **Políticas de sesión:** políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal para un rol o un usuario federado. Para obtener más información, consulte [Políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) en la *Guía del usuario de IAM*.
### Varios tipos de políticas
Cuando se aplican varios tipos de políticas a una solicitud, los permisos resultantes son más complicados de entender. Para obtener información acerca de cómo AWS decide si permitir o no una solicitud cuando hay varios tipos de políticas implicados, consulte [Lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) en la *Guía del usuario de IAM*.
# Cómo AWS Lambda funciona con IAM
Antes de utilizar IAM para administrar el acceso a Lambda, conozca qué características de IAM se pueden utilizar con Lambda.
| Característica de IAM | Soporte de Lambda |
| --- | --- |
| [Políticas basadas en identidades](#security_iam_service-with-iam-id-based-policies) | Sí |
| [Políticas basadas en recursos](#security_iam_service-with-iam-resource-based-policies) | Sí |
| [Acciones de políticas](#security_iam_service-with-iam-id-based-policies-actions) | Sí |
| [Recursos de políticas](#security_iam_service-with-iam-id-based-policies-resources) | Sí |
| [Claves de condición de política (específicas del servicio)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sí |
| [ACL](#security_iam_service-with-iam-acls) | No |
| [ABAC (etiquetas en políticas)](#security_iam_service-with-iam-tags) | Parcial |
| [Credenciales temporales](#security_iam_service-with-iam-roles-tempcreds) | Sí |
| [Sesiones de acceso directo (FAS)](#security_iam_service-with-iam-principal-permissions) | No |
| [Roles de servicio](#security_iam_service-with-iam-roles-service) | Sí |
| [Roles vinculados a servicios](#security_iam_service-with-iam-roles-service-linked) | Parcial |
Para obtener una perspectiva general sobre cómo funcionan Lambda y otros servicios de AWS con la mayoría de las características de IAM, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*.
## Políticas basadas en identidad para Lambda
**Compatibilidad con las políticas basadas en identidad:** sí
Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar a una identidad, como un usuario de IAM, un grupo de usuarios o un rol. Estas políticas controlan qué acciones pueden realizar los usuarios y los roles, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Con las políticas basadas en identidades de IAM, puede especificar las acciones y los recursos permitidos o denegados, así como las condiciones en las que se permiten o deniegan las acciones. Para obtener más información sobre los elementos que puede utilizar en una política de JSON, consulte [Referencia de los elementos de la política de JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) en la *Guía del usuario de IAM*.
### Ejemplos de políticas basadas en identidad para Lambda
Para ver ejemplos de políticas basadas en identidad de Lambda, consulte [Ejemplos de políticas basadas en identidades de AWS Lambda](security_iam_id-based-policy-examples.md).
## Políticas basadas en recursos de Lambda
**Compatibilidad con las políticas basadas en recursos:** sí
Las políticas basadas en recursos son documentos de política JSON que se asocian a un recurso. Los ejemplos de políticas basadas en recursos son las *políticas de confianza de roles* de IAM y las *políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Para el recurso al que se asocia la política, la política define qué acciones puede realizar una entidad principal especificada en ese recurso y en qué condiciones. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos. Las entidades principales pueden incluir cuentas, usuarios, roles, usuarios federados o Servicios de AWS.
Para habilitar el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como la entidad principal de una política en función de recursos. Para obtener más información, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
Puede asociar una política basada en recursos a una capa o función de Lambda. Esta política define qué entidades principales pueden llevar a cabo acciones en la capa o en la función.
Para obtener información sobre cómo asociar una política basada en recursos a una capa o función, consulte [Ver políticas de IAM basadas en recursos en Lambda](access-control-resource-based.md).
## Acciones de políticas de Lambda
**Compatibilidad con las acciones de políticas:** sí
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Action` de una política JSON describe las acciones que puede utilizar para conceder o denegar el acceso en una política. Incluya acciones en una política para conceder permisos y así llevar a cabo la operación asociada.
Para ver una lista de las acciones de Lambda, consulte [Acciones definidas por AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) en la *Referencia de autorizaciones de servicio*.
Las acciones de políticas de Lambda utilizan el siguiente prefijo antes de la acción:
```
lambda
```
Para especificar varias acciones en una única instrucción, sepárelas con comas.
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Para ver ejemplos de políticas basadas en identidad de Lambda, consulte [Ejemplos de políticas basadas en identidades de AWS Lambda](security_iam_id-based-policy-examples.md).
## Recursos de políticas de Lambda
**Compatibilidad con los recursos de políticas:** sí
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Resource` de la política JSON especifica el objeto u objetos a los que se aplica la acción. Como práctica recomendada, especifique un recurso utilizando el [Nombre de recurso de Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). En el caso de las acciones que no admiten permisos por recurso, utilice un carácter comodín (\$1) para indicar que la instrucción se aplica a todos los recursos.
```
"Resource": "*"
```
Para ver una lista de los tipos de recursos de Lambda y sus ARN, consulte [Tipos de recursos definidos por AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) en la *Referencia de autorizaciones de servicio*. Para obtener información sobre las acciones con las que puede especificar el ARN de cada recurso, consulte [Acciones definidas por AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Para ver ejemplos de políticas basadas en identidad de Lambda, consulte [Ejemplos de políticas basadas en identidades de AWS Lambda](security_iam_id-based-policy-examples.md).
## Claves de condición de política para Lambda
**Compatibilidad con claves de condición de políticas específicas del servicio:** sí
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Condition` especifica cuándo se ejecutan las instrucciones en función de criterios definidos. Puede crear expresiones condicionales que utilizan [operadores de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tales como igual o menor que, para que la condición de la política coincida con los valores de la solicitud. Para ver todas las claves de condición globales de AWS, consulte [Claves de contexto de condición globales de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*.
Para ver una lista de las claves de condición de Lambda, consulte [Claves de condición para AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) en la *Referencia de autorizaciones de servicio*. Para obtener más información sobre las acciones y los recursos con los que puede utilizar una clave de condición, consulte [Acciones definidas por AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Para ver ejemplos de políticas basadas en identidad de Lambda, consulte [Ejemplos de políticas basadas en identidades de AWS Lambda](security_iam_id-based-policy-examples.md).
## ACL en Lambda
**Compatibilidad con ACL**: no
Las listas de control de acceso (ACL) controlan qué entidades principales (miembros de cuentas, usuarios o roles) tienen permisos para acceder a un recurso. Las ACL son similares a las políticas basadas en recursos, aunque no utilizan el formato de documento de políticas JSON.
## ABAC con Lambda
**Compatibilidad con ABAC (etiquetas en las políticas):** parcial
El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos denominados etiquetas. Puede asociar etiquetas a entidades de IAM y recursos de AWS y, a continuación, diseñar políticas de ABAC para permitir operaciones cuando la etiqueta de la entidad principal coincida con la etiqueta del recurso.
Para controlar el acceso en función de etiquetas, debe proporcionar información de las etiquetas en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política utilizando las claves de condición `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Si un servicio admite las tres claves de condición para cada tipo de recurso, el valor es **Sí** para el servicio. Si un servicio admite las tres claves de condición solo para algunos tipos de recursos, el valor es **Parcial**.
*Para obtener más información sobre ABAC, consulte [Definición de permisos con la autorización de ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) en la Guía del usuario de IAM*. Para ver un tutorial con los pasos para configurar ABAC, consulte [Uso del control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) en la *Guía del usuario de IAM*.
Para obtener más información acerca del etiquetado de recursos de Lambda, consulte [Control de acceso basado en atributos para Lambda](attribute-based-access-control.md).
## Uso de credenciales temporales con Lambda
**Compatibilidad con credenciales temporales:** sí
Las credenciales temporales proporcionan acceso a corto plazo a los recursos de AWS y se crean automáticamente cuando se utiliza la federación o se cambia de rol. AWS recomienda generar credenciales temporales de forma dinámica en lugar de usar claves de acceso a largo plazo. Para obtener más información, consulte [Credenciales de seguridad temporales en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) y [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*.
## Sesiones de acceso directo para Lambda
**Compatibilidad con las sesiones de acceso directo (FAS):** no
Las sesiones de acceso directo (FAS) utilizan los permisos de la entidad principal para llamar a un Servicio de AWS, combinados con el Servicio de AWS solicitante para realizar solicitudes a servicios posteriores. Para obtener información sobre las políticas a la hora de realizar solicitudes de FAS, consulte [Sesiones de acceso directo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Roles de servicio de Lambda
**Compatible con roles de servicio:** sí
Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que asume un servicio para realizar acciones en su nombre. Un administrador de IAM puede crear, modificar y eliminar un rol de servicio desde IAM. Para obtener más información, consulte [Crear un rol para delegar permisos a un Servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*.
En Lambda, un rol de servicio se conoce como un rol de [ejecución](lambda-intro-execution-role.md).
**aviso**
Cambiar los permisos de un rol de ejecución podría interrumpir la funcionalidad de Lambda.
## Roles vinculados a servicios para Lambda
**Compatibilidad con roles vinculados al servicio:** parcial
Un rol vinculado a servicios es un tipo de rol de servicio que está vinculado a un Servicio de AWS. El servicio puede asumir el rol para realizar una acción en su nombre. Los roles vinculados a servicios aparecen en la Cuenta de AWS y son propiedad del servicio. Un administrador de IAM puede ver, pero no editar, los permisos de los roles vinculados a servicios.
Lambda no tiene roles vinculados a servicios, pero Lambda@Edge sí. Para obtener más información, consulte [Uso de roles vinculados a servicios de en la Guía para desarrolladores de Lambda@Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) en la *Guía para desarrolladores de Amazon CloudFront*.
Para más información sobre cómo crear o administrar roles vinculados a servicios, consulta [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Busque un servicio en la tabla que incluya `Yes` en la columna **Rol vinculado a un servicio**. Seleccione el vínculo **Sí** para ver la documentación acerca del rol vinculado a servicios para ese servicio.
# Ejemplos de políticas basadas en identidades de AWS Lambda
De forma predeterminada, los usuarios y roles no tienen permiso para crear ni modificar los recursos de Lambda. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan.
Para obtener información acerca de cómo crear una política basada en identidades de IAM mediante el uso de estos documentos de políticas JSON de ejemplo, consulte [Creación de políticas de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) en la *Guía del usuario de IAM*.
A fin de obtener más información sobre las acciones y los tipos de recursos definidos por Lambda, incluido el formato de los ARN para cada tipo de recurso, consulte [Acciones, recursos y claves de condición para AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) en la *Referencia de autorizaciones de servicio*.
**Topics**
+ [
## Prácticas recomendadas sobre las políticas
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Uso de la consola de Lambda
](#security_iam_id-based-policy-examples-console)
+ [
## Cómo permitir a los usuarios consultar sus propios permisos
](#security_iam_id-based-policy-examples-view-own-permissions)
## Prácticas recomendadas sobre las políticas
Las políticas basadas en identidades determinan si alguien puede crear, acceder o eliminar los recursos de Lambda de la cuenta. Estas acciones pueden generar costos adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience a utilizar las políticas administradas de AWS y avance hacia permisos de privilegios mínimos**. Para empezar a conceder permisos a los usuarios y cargas de trabajo, utilice las *políticas administradas de AWS* que otorgan permisos para muchos casos de uso comunes. Están disponibles en su Cuenta de AWS. Se recomienda definir políticas administradas por el cliente de AWS específicas para sus casos de uso a fin de reducir aún más los permisos. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*.
+ **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
+ **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puede usar condiciones para conceder acceso a acciones de servicios si se emplean a través de un Servicio de AWS determinado como, por ejemplo, CloudFormation. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
+ **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Validación de políticas con el Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía del usuario de IAM*.
+ **Solicite la autenticación multifactor (MFA)**: si se encuentra en una situación en la que necesite usuarios raíz o de IAM en su Cuenta de AWS, active la MFA para obtener una mayor seguridad. Para exigir la MFA cuando se invoquen las operaciones de la API, añada condiciones de MFA a sus políticas. Para más información, consulte [Acceso seguro a la API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.
## Uso de la consola de Lambda
Para acceder a la consola de AWS Lambda, debe tener un conjunto mínimo de permisos. Estos permisos deben permitir que registre y consulte los detalles acerca de los recursos de Lambda en su cuenta de Cuenta de AWS. Si crea una política basada en identidades que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para las entidades (usuarios o roles) que tengan esa política.
No es necesario conceder permisos mínimos para la consola a los usuarios que solo realizan llamadas a la AWS CLI o a la API de AWS. En su lugar, permita el acceso únicamente a las acciones que coincidan con la operación de API que intentan realizar.
Para obtener un ejemplo de política que concede un acceso mínimo para el desarrollo de funciones, consulte [Concesión de acceso a una función de Lambda a los usuarios](permissions-user-function.md). Además de las API de Lambda, la consola de Lambda utiliza otros servicios para mostrar la configuración de activación y permitir agregar nuevos desencadenadores. Si sus usuarios usan Lambda con otros servicios, también necesitan acceso a esos servicios. Para obtener más información sobre cómo configurar otros servicios con Lambda, consulte [Invocar Lambda con eventos de otros servicios de AWS](lambda-services.md).
## Cómo permitir a los usuarios consultar sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye permisos para llevar a cabo esta acción en la consola o mediante programación con la AWS CLI o la API de 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 Políticas administradas de para AWS Lambda
Una política administrada de AWS es una política independiente que AWS crea y administra. Las políticas administradas de AWS se diseñan para ofrecer permisos para muchos casos de uso comunes, por lo que puede empezar a asignar permisos a los usuarios, grupos y roles.
Considere que es posible que las políticas administradas por AWS no concedan permisos de privilegio mínimo para los casos de uso concretos, ya que están disponibles para que las utilicen todos los clientes de AWS. Se recomienda definir [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) específicas para sus casos de uso a fin de reducir aún más los permisos.
No puede cambiar los permisos definidos en las políticas administradas AWS. Si AWS actualiza los permisos definidos en una política administrada de AWS, la actualización afecta a todas las identidades de entidades principales (usuarios, grupos y roles) a las que está asociada la política. Lo más probable es que AWS actualice una política administrada de AWS cuando se lance un nuevo Servicio de AWS o las operaciones de la API nuevas estén disponibles para los servicios existentes.
Para obtener más información, consulte [Políticas administradas de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) en la *Guía del usuario de IAM*.
**Topics**
+ [
## Política administrada de AWS: AWSLambda\$1FullAccess
](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [
## Política administrada de AWS: AWSLambda\$1ReadOnlyAccess
](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [
## Política administrada de AWS: AWSLambdaBasicExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [
## Política administrada de AWS: AWSLambdaBasicDurableExecutionRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [
## Política administrada de AWS: AWSLambdaDynamoDBExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [
## Política administrada de AWS: AWSLambdaENIManagementAccess
](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [
## Política administrada de AWS: AWSLambdaInvocation-DynamoDB
](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [
## Política administrada de AWS: AWSLambdaKinesisExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [
## Política administrada de AWS: AWSLambdaMSKExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [
## Política administrada de AWS: AWSLambdaRole
](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [
## Política administrada de AWS: AWSLambdaSQSQueueExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [
## Política administrada de AWS: AWSLambdaVPCAccessExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [
## Política administrada de AWS: AWSLambdaManagedEC2ResourceOperator
](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [
## Política administrada de AWS: AWSLambdaServiceRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [
## Actualizaciones de Lambda en las políticas administradas de AWS
](#lambda-security-iam-awsmanpol-updates)
## Política administrada de AWS: AWSLambda\$1FullAccess
Esta política concede acceso completo a las acciones de Lambda. También concede permisos a otros servicios de AWS que se utilizan para desarrollar y mantener los recursos de Lambda.
Puede asociar la política `AWSLambda_FullAccess` a sus usuarios, grupos y roles.
**Detalles de los permisos**
Esta política incluye los permisos siguientes:
+ `lambda`: permite a las entidades principales obtener acceso completo a Lambda.
+ `cloudformation`: permite a las entidades principales describir las pilas de AWS CloudFormation y enumerar los recursos de esas pilas.
+ `cloudwatch`: permite a las entidades principales enumerar las métricas de Amazon CloudWatch y obtener datos de las métricas.
+ `ec2`: permite a las entidades principales describir los grupos de seguridad, las subredes y las VPC.
+ `iam`: permite a las entidades principales obtener las políticas, las versiones de las políticas, los roles, las políticas de roles, las políticas de roles asociadas y la lista de roles. Esta política también permite a las entidades principales transferir roles a Lambda. El permiso `PassRole` se usa al asignar un rol de ejecución a una función. El permiso de `CreateServiceLinkedRole` se utiliza cuando se crea un rol vinculado a servicios.
+ `kms`: permite que las entidades principales enumeren alias y describan claves para el cifrado del volumen.
+ `logs`: permite que las entidades principales describan los flujos de registro, obtengan y filtren eventos de registro e inicien y detengan sesiones de Live Tail.
+ `states`: permite a las entidades principales describir y enumerar las máquinas de estado de AWS Step Functions.
+ `tag`: permite a las entidades principales obtener recursos en función de sus etiquetas.
+ `xray`: permite a las entidades principales obtener resúmenes de registros de seguimiento de AWS X-Ray y recuperar una lista de los registros de seguimiento especificados por ID.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambda\$1ReadOnlyAccess
Esta política concede acceso de solo lectura a los recursos de Lambda y a otros servicios de AWS que se utilizan para desarrollar y mantener los recursos de Lambda.
Puede asociar la política `AWSLambda_ReadOnlyAccess` a sus usuarios, grupos y roles.
**Detalles de los permisos**
Esta política incluye los permisos siguientes:
+ `lambda`: permite a las entidades principales obtener y enumerar todos los recursos.
+ `cloudformation`: permite a las entidades principales describir y enumerar las pilas de AWS CloudFormation y enumerar los recursos de esas pilas.
+ `cloudwatch`: permite a las entidades principales enumerar las métricas de Amazon CloudWatch y obtener datos de las métricas.
+ `ec2`: permite a las entidades principales describir los grupos de seguridad, las subredes y las VPC.
+ `iam`: permite a las entidades principales obtener las políticas, las versiones de las políticas, los roles, las políticas de roles, las políticas de roles asociadas y la lista de roles.
+ `kms`: permite a las entidades principales enumerar los alias.
+ `logs`: permite que las entidades principales describan los flujos de registro, obtengan y filtren eventos de registro e inicien y detengan sesiones de Live Tail.
+ `states`: permite a las entidades principales describir y enumerar las máquinas de estado de AWS Step Functions.
+ `tag`: permite a las entidades principales obtener recursos en función de sus etiquetas.
+ `xray`: permite a las entidades principales obtener resúmenes de registros de seguimiento de AWS X-Ray y recuperar una lista de los registros de seguimiento especificados por ID.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaBasicExecutionRole
Esta política concede permisos para cargar registros en Registros de CloudWatch.
Puede asociar la política `AWSLambdaBasicExecutionRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaBasicDurableExecutionRolePolicy
Esta política proporciona permisos de escritura a Registros de CloudWatch y permisos de lectura/escritura a las API de ejecución duradera que utilizan las funciones duraderas de Lambda. Esta política proporciona los permisos esenciales necesarios para las funciones duraderas de Lambda, que utilizan API de ejecución duradera para conservar el progreso y mantener el estado en todas las invocaciones de funciones.
Puede asociar la política `AWSLambdaBasicDurableExecutionRolePolicy` a sus usuarios, grupos y roles.
**Detalles de los permisos**
Esta política incluye los permisos siguientes:
+ `logs`: permite que las entidades principales creen grupos de registros, registren flujos y escriban eventos de registro en Registros de CloudWatch.
+ `lambda`: permite que las entidades principales comprueben el estado de la ejecución duradera y recuperen el estado de la ejecución duradera para las funciones duraderas de Lambda.
Para ver más detalles sobre la política, incluida la versión más reciente del documento de política JSON, consulte [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) en la *Guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaDynamoDBExecutionRole
Esta política concede permisos para leer registros de un flujo de Amazon DynamoDB y escribir en Registros de CloudWatch.
Puede asociar la política `AWSLambdaDynamoDBExecutionRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaENIManagementAccess
Esta política concede permisos para crear, describir y eliminar las interfaces de red elásticas que utiliza una función de Lambda habilitada para VPC.
Puede asociar la política `AWSLambdaENIManagementAccess` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaInvocation-DynamoDB
Esta política concede acceso de lectura a Amazon DynamoDB Streams.
Puede asociar la política `AWSLambdaInvocation-DynamoDB` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaKinesisExecutionRole
Esta política concede permisos para leer eventos de un flujo de datos de Amazon Kinesis y escribir en Registros de CloudWatch.
Puede asociar la política `AWSLambdaKinesisExecutionRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaMSKExecutionRole
Esta política concede permisos para leer registros y acceder a ellos desde un clúster de Amazon Managed Streaming para Apache Kafka, administrar interfaces de red elásticas y escribir en Registros de CloudWatch.
Puede asociar la política `AWSLambdaMSKExecutionRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaRole
Esta política concede permisos para invocar funciones de Lambda.
Puede asociar la política `AWSLambdaRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaSQSQueueExecutionRole
Esta política concede permisos para leer y eliminar mensajes de una cola de Amazon Simple Queue Service y concede permisos de escritura en Registros de CloudWatch.
Puede asociar la política `AWSLambdaSQSQueueExecutionRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaVPCAccessExecutionRole
Esta política concede permisos para administrar las interfaces de red elásticas de una instancia de Amazon Virtual Private Cloud y escribir en Registros de CloudWatch.
Puede asociar la política `AWSLambdaVPCAccessExecutionRole` a sus usuarios, grupos y roles.
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html) en la *guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaManagedEC2ResourceOperator
Esta política permite la administración automatizada de instancias de Amazon Elastic Compute Cloud para los proveedores de capacidad de Lambda. Otorga permisos al servicio de escalador de Lambda para realizar operaciones del ciclo de vida de la instancia en su nombre.
Puede asociar la política `AWSLambdaManagedEC2ResourceOperator` a sus usuarios, grupos y roles.
**Detalles de los permisos**
Esta política incluye los permisos siguientes:
+ `ec2:RunInstances`: permite que Lambda lance nuevas instancias de Amazon EC2 con la condición de que ec2:ManagedResourceOperator sea igual a scaler.lambda.amazonaws.com y restrinja el uso de la AMI únicamente a las imágenes propiedad de Amazon.
+ `ec2:DescribeInstances` y `ec2:DescribeInstanceStatus`: permiten que Lambda supervise el estado de la instancia y recupere la información de la instancia.
+ `ec2:CreateTags`: permite que Lambda etiquete los recursos de Amazon EC2 con fines de administración e identificación.
+ `ec2:DescribeAvailabilityZones`: permite que Lambda vea las zonas disponibles para tomar decisiones sobre la ubicación de las instancias.
+ `ec2:DescribeCapacityReservations`: permite que Lambda compruebe las reservas de capacidad para una ubicación óptima de las instancias.
+ `ec2:DescribeInstanceTypes` y `ec2:DescribeInstanceTypeOfferings`: permiten que Lambda revise los tipos de instancias disponibles y sus ofertas.
+ `ec2:DescribeSubnets`: permite que Lambda examine las configuraciones de subred para planificar la red.
+ `ec2:DescribeSecurityGroups`: permite que Lambda recupere la información del grupo de seguridad para la configuración de la interfaz de red.
+ `ec2:CreateNetworkInterface`: permite que Lambda cree interfaces de red y administre las asociaciones de subredes y grupos de seguridad.
+ `ec2:AttachNetworkInterface`: permite que Lambda conecte interfaces de red a instancias de Amazon EC2 con la condición de que `ec2:ManagedResourceOperator` sea igual a [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/).
Para obtener más información sobre esta política, incluido el documento de política JSON y las versiones de la política, consulte [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) en la *Guía de referencia de políticas administradas de AWS*.
## Política administrada de AWS: AWSLambdaServiceRolePolicy
Esta política está adjunta al rol vinculado a servicios denominado AWSServiceRoleForLambda para permitir que Lambda cancele las instancias administradas como parte de los proveedores de capacidad de Lambda.
**Detalles de los permisos**
Esta política incluye los permisos siguientes:
+ `ec2:TerminateInstances`: permite que Lambda cancele las instancias de EC2 con la condición de que ec2:ManagedResourceOperator sea igual a scaler.lambda.amazonaws.com.
+ `ec2:DescribeInstanceStatus` y `ec2:DescribeInstances`: permiten que Lambda describa las instancias de EC2.
Para obtener más información sobre esta política, consulte [Uso de roles vinculados a servicios con Lambda](using-service-linked-roles.md).
## Actualizaciones de Lambda en las políticas administradas de AWS
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html): nueva política | Lambda agregó una política administrada que habilita la administración automatizada de instancias de Amazon EC2 para los proveedores de capacidad de Lambda, lo que permite que el servicio de escalador realice operaciones del ciclo de vida de las instancias. | 30 de noviembre de 2025 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html): nueva política | Lambda agregó una nueva política administrada para el rol vinculado a servicios para permitir que Lambda cancele las instancias administradas como parte de los proveedores de capacidad de Lambda. | 30 de noviembre de 2025 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html): cambio | Lambda actualizó la política de `AWSLambda_FullAccess` para permitir las acciones `kms:DescribeKey` y `iam:CreateServiceLinkedRole`. | 30 de noviembre de 2025 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html): nueva política administrada | Lambda publicó una nueva política administrada `AWSLambdaBasicDurableExecutionRolePolicy` que proporciona permisos de escritura a Registros de CloudWatch y permisos de lectura/escritura a las API de ejecución duradera que utilizan las funciones duraderas de Lambda. | 1 de diciembre de 2025 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) y [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html): cambio | Lambda actualizó las políticas `AWSLambda_ReadOnlyAccess` y `AWSLambda_FullAccess` para permitir las acciones `logs:StartLiveTail` y `logs:StopLiveTail`. | 17 de marzo de 2025 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html): cambio | Lambda actualizó la política `AWSLambdaVPCAccessExecutionRole` para permitir la acción `ec2:DescribeSubnets`. | 5 de enero de 2024 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html): cambio | Lambda actualizó la política `AWSLambda_ReadOnlyAccess` para permitir que las entidades principales enumeren las pilas de CloudFormation. | 27 de julio de 2023 |
| AWS Lambda comenzó el seguimiento de los cambios | AWS Lambda comenzó el seguimiento de los cambios de las políticas administradas de AWS. | 27 de julio de 2023 |
# Solución de problemas de identidades de AWS Lambda y accesos
Utilice la siguiente información para diagnosticar y solucionar los problemas comunes que es posible que surjan cuando se trabaja con Lambda e IAM.
**Topics**
+ [
## No tengo autorización para realizar una acción en Lambda
](#security_iam_troubleshoot-no-permissions)
+ [
## No tengo autorización para realizar la operación iam:PassRole
](#security_iam_troubleshoot-passrole)
+ [
## Quiero permitir a personas externas a mi Cuenta de AWS el acceso a mis recursos de Lambda
](#security_iam_troubleshoot-cross-account-access)
## No tengo autorización para realizar una acción en Lambda
Si recibe un error que indica que no tiene autorización para realizar una acción, las políticas se deben actualizar para permitirle realizar la acción.
En el siguiente ejemplo, el error se produce cuando el usuario de IAM `mateojackson` intenta utilizar la consola para consultar los detalles acerca de un recurso ficticio `my-example-widget`, pero no tiene los permisos ficticios `lambda:GetWidget`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
En este caso, la política del usuario `mateojackson` debe actualizarse para permitir el acceso al recurso `my-example-widget` mediante la acción `lambda:GetWidget`.
Si necesita ayuda, contacte con su administrador de AWS. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## No tengo autorización para realizar la operación iam:PassRole
Si recibe un error que indica que no tiene autorización para realizar la acción `iam:PassRole`, las políticas deben actualizarse a fin de permitirle pasar un rol a Lambda.
Algunos Servicios de AWS le permiten transferir un rol existente a dicho servicio en lugar de crear un nuevo rol de servicio o uno vinculado al servicio. Para ello, debe tener permisos para transferir el rol al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado `marymajor` intenta utilizar la consola para realizar una acción en Lambda. Sin embargo, la acción requiere que el servicio cuente con permisos que otorguen un rol de servicio. Mary no tiene permisos para transferir el rol al servicio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
En este caso, las políticas de Mary se deben actualizar para permitirle realizar la acción `iam:PassRole`.
Si necesita ayuda, póngase en contacto con su administrador de AWS. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## Quiero permitir a personas externas a mi Cuenta de AWS el acceso a mis recursos de Lambda
Se puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan utilizar para acceder a sus recursos. Se puede especificar una persona de confianza para que asuma el rol. En el caso de los servicios que admitan las políticas basadas en recursos o las listas de control de acceso (ACL), puede utilizar dichas políticas para conceder a las personas acceso a sus recursos.
Para obtener más información, consulte lo siguiente:
+ Para obtener información acerca de si Lambda admite estas características, consulte [Cómo AWS Lambda funciona con IAM](security_iam_service-with-iam.md).
+ Para obtener información acerca de cómo proporcionar acceso a los recursos de las Cuentas de AWS de su propiedad, consulte [Acceso para un usuario de IAM en otra Cuenta de AWS propia](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) en la *Guía del usuario de IAM*.
+ Para obtener información acerca de cómo proporcionar acceso a sus recursos a Cuentas de AWS de terceros, consulte [Proporcionar acceso a Cuentas de AWS que son propiedad de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) en la *Guía del usuario de IAM*.
+ Para obtener información sobre cómo proporcionar acceso mediante una federación de identidades, consulte [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) en la *Guía del usuario de IAM*.
+ Para conocer sobre la diferencia entre las políticas basadas en roles y en recursos para el acceso entre cuentas, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
# Cree una estrategia de gobiernanza para las funciones y capas de Lambda
Para crear e implementar aplicaciones nativas en la nube y sin servidor, debe permitir la agilidad y la velocidad de comercialización con la gobernanza y las barreras de protección adecuadas. Establece prioridades a nivel empresarial, tal vez haciendo hincapié en la agilidad como la máxima prioridad, o bien haciendo hincapié en la aversión al riesgo mediante la gobernanza, las barreras de protección y los controles. La realidad es que no tendrá una estrategia “lo uno o lo otro”, sino una estrategia de “y” que equilibre la agilidad y las barreras de protección en su ciclo de vida de desarrollo de software. Independientemente del lugar en el que se encuentren estos requisitos en el ciclo de vida de su empresa, es probable que las capacidades de gobernanza se conviertan en un requisito de implementación en sus procesos y cadenas de herramientas.
Estos son algunos ejemplos de controles de gobernanza que una organización podría implementar para Lambda:
+ Las funciones de Lambda no deben ser accesibles públicamente.
+ Las funciones de Lambda se deben adjuntar a una VPC.
+ Las funciones de Lambda no deberían utilizar tiempos de ejecución obsoletos.
+ Las funciones de Lambda se deben etiquetar con un conjunto de etiquetas obligatorias.
+ No se debe poder acceder a las capas Lambda fuera de la organización.
+ Las funciones de Lambda con un grupo de seguridad adjunto deben tener etiquetas coincidentes entre la función y el grupo de seguridad.
+ Las funciones de Lambda con una capa adjunta deben utilizar una versión aprobada.
+ Las variables de entorno de Lambda deben estar cifradas en reposo con una clave administrada por el cliente.
El siguiente diagrama es un ejemplo de una estrategia de gobernanza exhaustiva que implementa controles y políticas a lo largo del proceso de desarrollo e implementación del software:
![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-concepts.png)
En los temas siguientes se explica cómo implementar controles para desarrollar e implementar funciones de Lambda en su organización, tanto para startup como para la empresa. Es posible que su organización ya tenga las herramientas para hacerlo. En los temas siguientes se adopta un enfoque modular hacia estos controles, de modo que pueda seleccionar los componentes que realmente necesita.
**Topics**
+ [
# Controles proactivos para Lambda con AWS CloudFormation Guard
](governance-cloudformation-guard.md)
+ [
# Implemente controles preventivos para Lambda con AWS Config
](governance-config.md)
+ [
# Detecte las implementaciones y configuraciones de Lambda que no cumplan con AWS Config
](governance-config-detection.md)
+ [
# Firma de código de Lambda con AWS Signer
](governance-code-signing.md)
+ [
# Automatice las evaluaciones de seguridad para Lambda con Amazon Inspector
](governance-code-scanning.md)
+ [
# Implementación de la observabilidad para la seguridad y la conformidad de Lambda
](governance-observability.md)
# Controles proactivos para Lambda con AWS CloudFormation Guard
[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) es una herramienta de evaluación de políticas como código, de uso general y de código abierto. Se puede utilizar para la gobernanza y el cumplimiento preventivos mediante la validación del cumplimiento con las políticas de las plantillas de infraestructura como código (IaC) y las composiciones de los servicios. Estas reglas se pueden personalizar en función de los requisitos de su equipo o de la organización. En el caso de las funciones Lambda, las reglas de Guard se pueden utilizar para controlar la creación de recursos y las actualizaciones de configuración mediante la definición de los ajustes de propiedades necesarios al crear o actualizar una función de Lambda.
Los administradores de conformidad definen la lista de controles y políticas de gobernanza que se requieren para implementar y actualizar las funciones de Lambda. Los administradores de la plataforma implementan los controles en los canales de CI/CD, como webhooks de validación previa a la confirmación con repositorios de código, y proporcionan a los desarrolladores herramientas de línea de comandos para validar las plantillas y el código en las estaciones de trabajo locales. Los desarrolladores crean el código, validan las plantillas con herramientas de línea de comandos y, a continuación, envían el código a los repositorios, que luego se validan automáticamente mediante los canales de CI/CD antes de la implementación en un entorno de AWS.
Guard le permite [escribir sus reglas](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) e implementar sus controles con un lenguaje específico del dominio, como se muestra a continuación.
![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-cloudformation-guard.png)
Por ejemplo, imagine que quiere asegurarse de que los desarrolladores elijan solo los tiempos de ejecución más recientes. Puede especificar dos políticas diferentes, una para identificar los [tiempos de ejecución](lambda-runtimes.md) que ya están en desuso y otra para identificar los tiempos de ejecución que caducarán pronto. Para ello, puede escribir el siguiente archivo de `etc/rules.guard`:
```
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"] <>
}
}
}
}
```
Ahora imagine que escribe la siguiente plantilla de CloudFormation de `iac/lambda.yaml` que define una función de 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
```
Tras [instalar](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) la utilidad Guard, valide la plantilla:
```
cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml
```
El resultado tendrá este aspecto:
```
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 les permite a los desarrolladores comprobar desde sus estaciones de trabajo locales que necesitan actualizar la plantilla para utilizar un tiempo de ejecución permitido por la organización. Esto ocurre antes de iniciar sesión en un repositorio de código y no pasar las comprobaciones realizadas en los canales de CI/CD. Como resultado, los desarrolladores reciben esta información sobre cómo desarrollar plantillas compatibles y dedicar su tiempo a escribir código que aporte valor empresarial. Este control se puede aplicar en la estación de trabajo del desarrollador local, en un webhook de validación previo a la confirmación, o en el canal de CI/CD antes de la implementación.
## Advertencias
Si utiliza plantillas de AWS Serverless Application Model (AWS SAM) para definir funciones de Lambda, tenga en cuenta que debe actualizar la regla de Guard para buscar el tipo de recurso `AWS::Serverless::Function` de la siguiente manera.
```
let lambda_functions = Resources.*[
Type == "AWS::Serverless::Function"
]
```
Guard también espera que las propiedades se incluyan en la definición del recurso. Mientras tanto, las plantillas de AWS SAM permiten especificar las propiedades en una sección [Global](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html) independiente. Las propiedades que se definen en la sección Global no se validan con sus reglas de Guard.
Como se indica en la [documentación](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) de solución de problemas de Guard, tenga en cuenta que Guard no admite tipos intrínsecos abreviados, como `!GetAtt` o `!Sub`. Por el contrario, requiere el uso de formas expandidas, como `Fn::GetAtt` y `Fn::Sub`. (El [ejemplo anterior](#guard-iac-yaml) no evalúa la propiedad Role, por lo que se utilizó el tipo intrínseco abreviado por simplicidad).
# Implemente controles preventivos para Lambda con AWS Config
Es esencial garantizar lo antes posible la conformidad en sus aplicaciones sin servidor durante el proceso de desarrollo. En este tema, abordamos cómo implementar controles preventivos mediante [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). Esto le permite implementar las comprobaciones de conformidad en una fase más temprana del proceso de desarrollo e implementar los mismos controles en sus canalizaciones de CI/CD. Esto también estandariza los controles en un repositorio de reglas administrado de forma centralizada para que pueda aplicarlos de forma coherente en todas sus cuentas de AWS.
Por ejemplo, supongamos que los administradores de conformidad definieron un requisito para garantizar que todas las funciones de Lambda incluyan el seguimiento de AWS X-Ray. Con el modo proactivo de AWS Config, puede realizar comprobaciones de conformidad en los recursos de las funciones de Lambda antes de la implementación, lo que reduce el riesgo de implementar funciones de Lambda mal configuradas y les ahorra tiempo a los desarrolladores al proporcionarles comentarios más rápidos sobre la infraestructura en forma de plantillas de código. La siguiente es una visualización del flujo de los controles preventivos con AWS Config:
![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-1.png)
Recuerde el requisito de que todas las funciones de Lambda deben tener habilitado el rastreo. En respuesta, el equipo de la plataforma identifica la necesidad de que una regla específica de AWS Config se ejecute de forma proactiva en todas las cuentas. Esta regla marca cualquier función de Lambda que carezca de una configuración de rastreo de X-Ray configurada como un recurso no conforme. El equipo desarrolla una regla, la empaqueta en un [paquete de conformidad](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) y lo implementa en todas las cuentas de AWS para garantizar que todas las cuentas de la organización apliquen estos controles de manera uniforme. Puede escribir la regla en la sintaxis AWS CloudFormation Guard 2.x.x, que adopta la siguiente forma:
```
rule name when condition { assertion }
```
A continuación, se muestra un ejemplo de regla de protección que comprueba que las funciones de Lambda tengan activado el rastreo:
```
rule lambda_tracing_check {
when configuration.tracingConfig exists {
configuration.tracingConfig.mode == "Active"
}
}
```
El equipo de la plataforma toma medidas adicionales al exigir que cada implementación de AWS CloudFormation invoque un [enlace](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html) de creación previa o actualización. Asumen toda la responsabilidad de desarrollar este enlace y configurar la canalización, reforzar el control centralizado de las reglas de conformidad y mantener su aplicación uniforme en todas las implementaciones. Para desarrollar, empaquetar y registrar un enlace, consulte [Desarrollo de enlaces de AWS CloudFormation](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html) en la documentación de la interfaz de línea de comandos de CloudFormation (CFN-CLI). Puede usar la [CLI de CloudFormation](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) para crear el proyecto del enlace:
```
cfn init
```
Este comando le solicita información básica sobre el proyecto del enlace y crea un proyecto que incluye los siguientes archivos:
```
README.md
.json
rpdk.log
src/handler.py
template.yml
hook-role.yaml
```
Como desarrollador de enlaces, debe agregar el tipo de recurso de destino deseado en el archivo de configuración de `.json`. En la siguiente configuración, se configura un enlace para que se ejecute antes de crear cualquier función de Lambda mediante CloudFormation. También puede agregar controladores similares para las acciones de `preUpdate` y `preDelete`.
```
"handlers": {
"preCreate": {
"targetNames": [
"AWS::Lambda::Function"
],
"permissions": []
}
}
```
También debe asegurarse de que el enlace de CloudFormation tenga los permisos adecuados para llamar a las API de AWS Config. Para ello, actualice el archivo de definición de roles denominado `hook-role.yaml`. De forma predeterminada, el archivo de definición de roles posee la siguiente política de confianza, que le permite a CloudFormation asumir ese rol.
```
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- hooks.cloudformation.amazonaws.com
- resources.cloudformation.amazonaws.com
```
Para permitir que este enlace llame a las API de configuración, debe agregar los siguientes permisos a la instrucción de política. A continuación, envía el proyecto del enlace mediante el comando `cfn submit`, y CloudFormation crea un rol para usted con los permisos necesarios.
```
Policies:
- PolicyName: HookTypePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- "config:Describe*"
- "config:Get*"
- "config:List*"
- "config:SelectResourceConfig"
Resource: "*
```
Luego debe escribir una función de Lambda en un archivo `src/handler.py`. En este archivo, encontrará los métodos denominados `preCreate`, `preUpdate` y `preDelete`, que ya se crearon al iniciar el proyecto. Su objetivo es escribir una función común y reutilizable que llame a la API de AWS Config `StartResourceEvaluation` en modo proactivo mediante AWS SDK para Python (Boto3). Esta llamada a la API toma las propiedades del recurso como entrada y evalúa el recurso en función de la definición de la regla.
```
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.")
```
Ahora puede llamar a la función común desde el controlador del enlace de creación previa. El siguiente es un ejemplo del controlador:
```
@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}")
```
Luego de este paso, puede registrar el enlace y configurarlo para que escuche todos los eventos de creación de las funciones de AWS Lambda.
Un desarrollador prepara la plantilla de infraestructura como código (IaC) para un microservicio sin servidor mediante Lambda. Esta preparación incluye el cumplimiento de los estándares internos, y está seguida de pruebas locales y el envío de la plantilla al repositorio. A continuación, se muestra una plantilla de IaC de ejemplo:
```
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
```
Como parte del proceso de CI/CD, cuando se implementa la plantilla de CloudFormation, el servicio de CloudFormation invoca el enlace de creación previa o actualización justo antes de aprovisionar el tipo de recurso de `AWS::Lambda::Function`. El enlace utiliza reglas de AWS Config que se ejecutan en modo proactivo para comprobar si la configuración de la función de Lambda incluye la configuración de rastreo obligatoria. La respuesta del enlace determina el siguiente paso. Si es compatible, el enlace indica que se ha realizado correctamente y CloudFormation procede a aprovisionar los recursos. De lo contrario, se produce un error en la implementación de la pila de CloudFormation, la canalización se detiene inmediatamente y el sistema registra los detalles para su posterior revisión. Las notificaciones de conformidad se envían a las partes interesadas pertinentes.
Puede encontrar la información sobre el éxito o el error del enlace en la consola de CloudFormation:
![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-2.png)
Si tiene los registros habilitados para su enlace de CloudFormation, puede capturar el resultado de la evaluación del enlace. Este es un ejemplo de registro de un enlace con un estado de error, que indica que la función de Lambda no tiene activado X-Ray:
![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-3.png)
Si el desarrollador decide cambiar la IaC para actualizar el valor `TracingConfig Mode` a `Active` y volver a implementarlo, el enlace se ejecuta correctamente y la pila continúa con la creación del recurso de Lambda.
![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-4.png)
De esta forma, puede implementar controles preventivos con AWS Config en modo proactivo al desarrollar e implementar recursos sin servidor en sus cuentas de AWS. Al integrar las reglas de AWS Config en la canalización de CI/CD, puede identificar y, opcionalmente, bloquear las implementaciones de recursos no conformes, como las funciones de Lambda que carecen de una configuración de rastreo activo. Esto garantiza que en sus entornos de AWS solo se implementen los recursos que cumplen con las políticas de gobernanza más recientes.
# Detecte las implementaciones y configuraciones de Lambda que no cumplan con AWS Config
Además de realizar una [evaluación proactiva](governance-config.md), AWS Config también puede detectar de forma reactiva las implementaciones y configuraciones de recursos que no cumplen con sus políticas de gobernanza. Esto es importante porque las políticas de gobernanza evolucionan a medida que la organización aprende e implementa nuevas prácticas recomendadas.
Contemple un escenario en el que establezca una política completamente nueva al implementar o actualizar las funciones de Lambda: todas las funciones de Lambda deben utilizar siempre una versión de capa de Lambda específica y aprobada. Puede configurar AWS Config para supervisar las funciones nuevas o actualizadas para las configuraciones de capa. Si AWS Config detecta una función que no utiliza una versión de capa aprobada, la marca como un recurso no conforme. Si lo desea, puede configurar AWS Config para corregir automáticamente el recurso a través de la especificación de una acción de corrección mediante un documento de automatización de AWS Systems Manager. Por ejemplo, puede escribir un documento de automatización en Python mediante AWS SDK para Python (Boto3), que actualiza la función no conforme para que apunte a la versión de capa aprobada. Por lo tanto, AWS Config sirve como control de detección y de corrección, ya que automatiza la administración de la conformidad.
A continuación, desglosaremos este proceso en tres importantes fases de implementación:
![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-detective-1.png)
## Fase 1: identificación de los recursos de acceso
Comience por activar y configurar AWS Config en todas sus cuentas para que registre las funciones de Lambda de AWS. Esto le permite a AWS Config observar cuándo se crean o actualizan las funciones de Lambda. Luego puede configurar las [reglas de políticas personalizadas](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) para comprobar si existen infracciones específicas a las políticas, que utilizan la sintaxis AWS CloudFormation Guard. Las reglas de protección adoptan la siguiente forma general:
```
rule name when condition { assertion }
```
A continuación, se muestra un ejemplo de regla que comprueba que una capa no esté configurada en una versión de capa anterior:
```
rule desiredlayer when configuration.layers !empty {
some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}
```
Para entender la sintaxis y la estructura de la regla:
+ **Nombre de la regla:** el nombre de la regla en el ejemplo proporcionado es `desiredlayer`.
+ **Condición:** esta cláusula especifica la condición en la que se debe comprobar la regla. En el ejemplo proporcionado, la condición es `configuration.layers !empty`. Esto significa que el recurso debe evaluarse solo cuando la propiedad `layers` de la configuración no esté vacía.
+ **Aserción:** luego de la cláusula `when`, una aserción determina lo que comprueba la regla. La aserción `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` comprueba si alguno de los ARN de la capa de Lambda no coincide con el valor `OldLayerArn`. Si no coinciden, la aserción es verdadera y la regla se aprueba; de lo contrario, falla.
`CONFIG_RULE_PARAMETERS` es un conjunto especial de parámetros que se configura con la regla AWS Config. En este caso, `OldLayerArn` es un parámetro dentro de `CONFIG_RULE_PARAMETERS`. Esto les permite a los usuarios proporcionar un valor de ARN específico que consideren antiguo u obsoleto y, a continuación, la regla comprueba si alguna función de Lambda utiliza este ARN antiguo.
## Fase 2: visualización y diseño
AWS Config recopila datos de configuración y los almacena en buckets de Amazon Simple Storage Service (Amazon S3). Puede utilizar [Amazon Athena](https://aws.amazon.com/athena/) para consultar estos datos directamente desde sus buckets de S3. Con Athena, puede agregar estos datos a nivel organizacional y generar una visión holística de las configuraciones de sus recursos en todas sus cuentas. Para configurar la agregación de los datos de configuración de recursos, consulte [Visualización de datos de AWS Config con Athena y Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) en el blog de Operaciones y administración de la nube de AWS.
El siguiente es un ejemplo de consulta de Athena para identificar todas las funciones de Lambda mediante un ARN de capa determinado:
```
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%'
```
Estos son los resultados de la consulta:
![\[Query results in Athena console.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-detective-2.png)
Con los datos de AWS Config agregados en toda la organización, puede crear un panel con [Amazon Quick](https://aws.amazon.com/quicksight/). Al importar los resultados de Athena a Quick, puede visualizar en qué medida sus funciones de Lambda cumplen la regla de versión de capa. Este panel puede destacar los recursos conformes y no conformes, lo que lo ayuda a determinar su política de cumplimiento, tal como se describe en la [siguiente sección](#governance-config-detective-implement). La siguiente imagen es un panel de ejemplo que informa sobre la distribución de las versiones de las capas aplicadas a las funciones de la organización.
![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-config-detective-3.png)
## Fase 3: implementación y aplicación
Ahora, si lo desea, puede vincular la regla de la versión de capa que creó en la [fase 1](#governance-config-detective-identify) con una acción de corrección mediante un documento de automatización de Systems Manager, que puede crear como un script de Python escrito con AWS SDK para Python (Boto3). El script llama a la acción de la API [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) para cada función de Lambda y actualiza la configuración de la función con el ARN de la nueva capa. Como alternativa, puede hacer que el script envíe una solicitud de extracción al repositorio del código para actualizar el ARN de la capa. De esta forma, las futuras implementaciones de código también se actualizarán con el ARN de capa correcto.
# Firma de código de Lambda con AWS Signer
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) es un servicio de firma de código totalmente gestionado que le permite validar el código con una firma digital para confirmar que el código está inalterado y que proviene de un publicador de confianza. AWS Signer se puede utilizar junto a AWS Lambda con el fin de comprobar que las funciones y las capas permanecen inalteradas antes de implementarlas en sus entornos de AWS. Esto protege a su organización de actores malintencionados que podrían haber obtenido credenciales para crear funciones nuevas o actualizar las existentes.
A fin de configurar la firma de código para las funciones de Lambda, comience por crear un bucket de S3 con el control de versiones activado. Después, cree un perfil de firma con AWS Signer, especifique Lambda como plataforma y, a continuación, especifique un período de días en el que el perfil de firma es válido. Ejemplo:
```
Signer:
Type: AWS::Signer::SigningProfile
Properties:
PlatformId: AWSLambda-SHA384-ECDSA
SignatureValidityPeriod:
Type: DAYS
Value: !Ref pValidDays
```
A continuación, utilice el perfil de firma y cree una configuración de firma con Lambda. Debe especificar qué hacer cuando la configuración de firma detecte un artefacto que no coincide con la firma digital que esperaba: avisar (pero permitir la implementación) o imponer (y bloquear la implementación). El siguiente ejemplo está configurado para imponer y bloquear las implementaciones.
```
SigningConfig:
Type: AWS::Lambda::CodeSigningConfig
Properties:
AllowedPublishers:
SigningProfileVersionArns:
- !GetAtt Signer.ProfileVersionArn
CodeSigningPolicies:
UntrustedArtifactOnDeployment: Enforce
```
Ahora configuró AWS Signer con Lambda para bloquear las implementaciones que no son de confianza. Imagine que terminó de escribir una solicitud de característica y ahora está listo para implementar la función. El primer paso es comprimir el código con las dependencias adecuadas y, a continuación, firmar el artefacto con el perfil de firma que creó. Para ello, puede cargar el artefacto zip en el bucket de S3 y, luego, iniciar un trabajo de firma.
```
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
```
El resultado es el siguiente: `jobId` es el objeto que se crea en el bucket y prefijo de destino y `jobOwner` es el identificador de 12 dígitos de la Cuenta de AWS en la que se ejecutó el trabajo.
```
{
"jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388",
"jobOwner": "111122223333"
}
```
Y ahora puede implementar su función mediante el objeto S3 firmado y la configuración de firma de código que creó.
```
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
```
También puede probar la implementación de una función con el artefacto zip fuente sin firmar original. La implementación debería fallar con el siguiente mensaje:
```
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 está creando e implementando sus funciones mediante AWS Serverless Application Model (AWS SAM), el comando package se encarga de cargar el artefacto zip en S3 y también inicia el trabajo de firma y obtiene el artefacto firmado. Puede hacerlo con el comando y los parámetros que siguen:
```
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 lo ayuda a comprobar que los artefactos zip que se implementan en sus cuentas son fiables y se pueden implementar de manera segura. Puede incluir el proceso anterior en sus canales de CI/CD y exigir que todas las funciones tengan una configuración de firma de código adjunta mediante las técnicas descritas en los temas anteriores. Si usa la firma de código en las implementaciones de funciones de Lambda, evita que actores malintencionados, que podrían haber obtenido credenciales para crear o actualizar funciones, inyecten código malicioso en sus funciones.
# Automatice las evaluaciones de seguridad para Lambda con Amazon Inspector
[Amazon Inspector](https://aws.amazon.com/inspector/) es un servicio de administración de vulnerabilidades que analiza de forma continua las cargas de trabajo en busca de vulnerabilidades de software y exposiciones de red no deseadas. Amazon Inspector crea un resultado en el que se describe la vulnerabilidad, se identifica el recurso afectado, se califica la gravedad de la vulnerabilidad y se proporcionan indicaciones para su corrección.
El soporte de Amazon Inspector proporciona evaluaciones de vulnerabilidades de seguridad continuas y automatizadas para las capas y funciones de Lambda. Amazon Inspector ofrece dos tipos de análisis para Lambda:
+ **Análisis estándar de Lambda (predeterminado):** examina las dependencias de aplicaciones en una función de Lambda y sus capas en busca de [vulnerabilidades de paquetes](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package).
+ **Análisis de código de Lambda**: analiza el código personalizado de la aplicación en las funciones y sus capas en busca de [vulnerabilidades de código](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code). Puede activar solo el análisis estándar de Lambda o activar este junto al análisis de código de Lambda.
Para activar Amazon Inspector, diríjase a la [consola de Amazon Inspector](https://console.aws.amazon.com/inspector/), expanda la sección **Configuración** y seleccione **Administración de cuentas**. En la pestaña **Cuentas**, seleccione **Activar** y, a continuación, seleccione una de las opciones de análisis.
Puede activar Amazon Inspector para varias cuentas y otorgar permisos para gestionar Amazon Inspector para la organización en cuentas específicas mientras configura Amazon Inspector. Mientras se habilita, debe otorgar permisos a Amazon Inspector creando el rol: `AWSServiceRoleForAmazonInspector2`. La consola de Amazon Inspector le permite crear este rol con una opción de un solo clic.
Para el análisis estándar de Lambda, Amazon Inspector inicia análisis de funciones de Lambda en busca de vulnerabilidades en las siguientes situaciones:
+ En cuanto Amazon Inspector detecta una función de Lambda.
+ Al implementar una nueva función de Lambda.
+ cuando implementa una actualización en el código de la aplicación o las dependencias de una función de Lambda o sus capas,
+ siempre que Amazon Inspector añade un nuevo elemento de vulnerabilidades y riesgos comunes (CVE) a su base de datos y ese elemento de CVE es relevante para la función.
Para el análisis de código de Lambda, Amazon Inspector evalúa el código de la aplicación de la función de Lambda mediante razonamiento automatizado y machine learning de conformidad con los estándares generales de seguridad. Si Amazon Inspector detecta una vulnerabilidad en el código de la aplicación de la función de Lambda, Amazon Inspector genera un resultado detallado del **Vulnerabilidad de código**. Para consultar una lista de posibles detecciones, vaya a la [Biblioteca de detectores de Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/detector-library/).
Para ver los resultados, vaya a la [Consola de Amazon Inspector](https://console.aws.amazon.com/inspector/). En el menú **Resultados**, seleccione **Por función de Lambda** para ver los resultados del análisis de seguridad que se realizaron en las funciones de Lambda.
Para excluir una función de Lambda del análisis estándar, etiquete la función con el siguiente par clave-valor:
+ `Key:InspectorExclusion`
+ `Value:LambdaStandardScanning`
Para excluir una función de Lambda de los análisis de código, etiquete la función con el siguiente par de clave y valor:
+ `Key:InspectorCodeExclusion`
+ `Value:``LambdaCodeScanning`
Por ejemplo, como se muestra en la siguiente imagen, Amazon Inspector detecta automáticamente las vulnerabilidades y clasifica los resultados del tipo **Code Vulnerability**, lo que indica que la vulnerabilidad está en el código de la función y no en una de las bibliotecas dependientes del código. Puede comprobar estos detalles para una función específica o para varias funciones a la vez.
![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-code-scanning-1.png)
Puede profundizar en cada uno de estos resultados y aprender cómo solucionar el problema.
![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-code-scanning-2.png)
Mientras trabaja con las funciones de Lambda, asegúrese de cumplir con las convenciones de nomenclatura de las funciones de Lambda. Para obtener más información, consulte [Trabajar con variables de entorno de Lambda](configuration-envvars.md).
El usuario se hace responsable de las sugerencias de corrección que acepta. Revise las sugerencias de corrección antes de aceptarlas. Es posible que deba modificar dichas sugerencias para garantizar que el código lleve a cabo las acciones previstas.
# Implementación de la observabilidad para la seguridad y la conformidad de Lambda
AWS Config es una herramienta útil para encontrar y corregir recursos sin servidor no conformes de AWS. Todos los cambios que realice en sus recursos sin servidor se registran en AWS Config. Además, AWS Config le permite almacenar los datos de las instantáneas de configuración en S3. Puede utilizar Amazon Athena y Amazon Quick para crear paneles y ver datos de AWS Config. En [Detecte las implementaciones y configuraciones de Lambda que no cumplan con AWS Config](governance-config-detection.md), analizamos cómo es posible visualizar una configuración determinada como capas Lambda. En este tema se amplían estos conceptos.
## Visibilidad de las configuraciones de Lambda
Puede usar consultas para obtener configuraciones importantes como el ID de Cuenta de AWS, la región, la configuración de rastreo de AWS X-Ray, la configuración de VPC, el tamaño de la memoria, el tiempo de ejecución y las etiquetas. Este es un ejemplo de consulta que puede utilizar para obtener esta información de 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
```
Puede utilizar la consulta para crear un panel en Quick y visualizar los datos. Para agregar datos de configuración de recursos de AWS, crear tablas en Athena y crear paneles de QuickSight a partir de los datos de Athena, consulte [Visualizar datos de AWS Config³ con Athena y Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) en el blog de Operaciones y adminstración de la nube de AWS. Cabe destacar que esta consulta también recupera la información de las etiquetas para las funciones. Esto permite obtener información más detallada sobre sus cargas de trabajo y entornos, especialmente si emplea etiquetas personalizadas.
![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-observability-1.png)
Para obtener más información sobre las acciones que puede realizar, consulte la sección [Cómo abordar los resultados de observabilidad](#governance-observability-addressing) que aparece más adelante.
## Visibilidad de la conformidad de Lambda
Con los datos generados por AWS Config, puede crear paneles de control a nivel de organización para supervisar la conformidad. Esto permite un seguimiento y monitoreo constantes de:
+ Paquetes de conformidad por puntuación de conformidad
+ Reglas por recursos no conformes
+ Compliance status (Estado de conformidad)
![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-observability-2.png)
Compruebe cada regla para identificar los recursos no conformes con esa regla. Por ejemplo, si su organización exige que todas las funciones de Lambda estén asociadas a una VPC y si ha implementado una regla de AWS Config para identificar la conformidad, puede seleccionar la regla de `lambda-inside-vpc` en la lista anterior.
![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-observability-3.png)
Para obtener más información sobre las acciones que puede realizar, consulte la sección [Cómo abordar los resultados de observabilidad](#governance-observability-addressing) que aparece más adelante.
## Visibilidad de los límites de las funciones de Lambda mediante la CSPM de Security Hub
![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-observability-4.png)
Para garantizar que los servicios de AWS, incluyendo Lambda, se utilicen de forma segura, AWS incorporó las Prácticas recomendadas de seguridad fundamentales v1.0.0. Este conjunto de prácticas recomendadas proporciona directrices claras para proteger los recursos y los datos en el entorno de AWS, y hace hincapié en la importancia de mantener una postura de seguridad sólida. AWS Security Hub CSPM complementa esto al ofrecer un centro unificado de seguridad y conformidad. Reúne, organiza y prioriza los resultados de seguridad de varios servicios de AWS, como Amazon Inspector, AWS Identity and Access Management Access Analyzer y Amazon GuardDuty.
Si tiene habilitados CSPM de Security Hub, Amazon Inspector, IAM Access Analyzer y GuardDuty en su organización de AWS, la CSPM de Security Hub agrega automáticamente los resultados de estos servicios. Por ejemplo, a continuación analizaremos Amazon Inspector. Con la CSPM de Security Hub, puede identificar de manera eficiente las vulnerabilidades de código y paquete en las funciones de Lambda. En la consola de la CSPM de Security Hub, diríjase a la sección inferior denominada **Últimos resultados de las integraciones de AWS**. Allí puede ver y analizar los resultados obtenidos de varios servicios integrados de AWS.
![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-observability-5.png)
Para ver los detalles, seleccione el enlace **Ver los resultados** en la segunda columna. Se mostrará una lista de resultados filtrados por producto, como Amazon Inspector. Para limitar la búsqueda a las funciones de Lambda, establezca `ResourceType` en `AwsLambdaFunction`. Se mostrarán los resultados de Amazon Inspector relacionados con las funciones de Lambda.
![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/governance-observability-6.png)
En el caso de GuardDuty, puede identificar patrones de tráfico de red sospechosos. Estas anomalías pueden sugerir la existencia de código potencialmente malicioso en la función de Lambda.
Con IAM Access Analyzer, puede comprobar las políticas, especialmente las que contienen declaraciones de condiciones que permiten que las funciones accedan a entidades externas. Además, IAM Access Analyzer evalúa los permisos establecidos al utilizar la operación [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) en la API de Lambda junto con un `EventSourceToken`.
## Cómo abordar los resultados de observabilidad
Dada la amplia gama de configuraciones posibles para las funciones de Lambda y sus diferentes requisitos, es posible que una solución de automatización estandarizada para la corrección no se adapte a todas las situaciones. Además, los cambios se implementan de manera diferente en cada entorno. Si encuentra alguna configuración que parece no cumplir con los requisitos, tenga en cuenta las siguientes pautas:
1. **Estrategia de etiquetado**
Recomendamos implementar una estrategia de etiquetado integral. Cada función de Lambda debe etiquetarse con información clave, tal como:
+ **Propietario:** la persona o el equipo responsable de la función.
+ **Entorno:** producción, staging, desarrollo o entorno aislado.
+ **Aplicación:** el contexto más amplio al que pertenece esta función, si corresponde.
1. **Contacto con los propietarios**
En lugar de automatizar los cambios importantes (como el ajuste de la configuración de la VPC), póngase en contacto de forma proactiva con los propietarios de las funciones no conformes (identificadas con la etiqueta de propietario), quienes, de esta manera, tendrán tiempo suficiente para:
+ Ajustar las configuraciones no conformes en las funciones de Lambda.
+ Proporcionar una explicación y solicitar una excepción, o perfeccionar los estándares de conformidad.
1. **Mantenimiento de una base de datos de la administración de la configuración (CMDB)**.
Si bien las etiquetas pueden proporcionar un contexto inmediato, el mantenimiento de una CMDB centralizada puede proporcionar información más detallada. Puede contener información más minuciosa sobre cada función de Lambda, sus dependencias y otros metadatos importantes. Una CMDB es un recurso indispensable para realizar auditorías, comprobar la conformidad e identificar a los propietarios de las funciones.
A medida que el panorama de la infraestructura sin servidor comienza a evolucionar continuamente, es esencial adoptar una postura proactiva con respecto al monitoreo. Con herramientas como AWS Config, CSPM de Security Hub y Amazon Inspector, se pueden identificar rápidamente posibles anomalías o configuraciones no conformes. Sin embargo, las herramientas por sí solas no pueden garantizar el cumplimiento total ni las configuraciones óptimas. Es crucial combinar estas herramientas con prácticas recomendadas y procesos bien documentados.
+ **Bucle de retroalimentación:** una vez que se hayan tomado las medidas correctivas, asegúrese de que haya un bucle de retroalimentación. Esto implica revisitar periódicamente los recursos no conformes para verificar si se han actualizado o si siguen funcionando con los mismos problemas.
+ **Documentación:** documente siempre las observaciones, las medidas adoptadas y las excepciones concedidas. La documentación adecuada no solo ayuda durante las auditorías, sino que también ayuda a mejorar el proceso para mejorar la conformidad y la seguridad en el futuro.
+ **Capacitación y concientización:** asegúrese de que todas las partes interesadas, especialmente los propietarios de las funciones de Lambda, reciban capacitación periódica y conozcan las prácticas recomendadas, las políticas organizacionales y los mandatos de conformidad. Los talleres, las sesiones de formación y los seminarios web periódicos pueden contribuir en gran medida a garantizar que todos estén de acuerdo en lo que respecta a la seguridad y la conformidad.
En conclusión, si bien las herramientas y las tecnologías ofrecen capacidades sólidas para detectar y marcar posibles problemas, el elemento humano (comprensión, comunicación, formación y documentación) sigue siendo fundamental. Se combinan para formar un conjunto poderoso y así garantizar que sus funciones de Lambda y su infraestructura más amplia sigan cumpliendo con las normas, sean seguras y estén optimizadas para las necesidades de su empresa.
# Validación de conformidad en AWS Lambda
Auditores externos evalúan la seguridad y la conformidad de AWS Lambda como parte de varios programas de conformidad de AWS. Estos incluyen SOC, PCI, FedRAMP, HIPAA y otros.
Para obtener una lista de AWS servicios en el ámbito de programas de cumplimiento específicos, consulte los [AWS servicios en ámbito por programa de cumplimiento](https://aws.amazon.com/compliance/services-in-scope/). Para obtener información general, consulte [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/).
Puede descargar los informes de auditoría de terceros con AWS Artifact. Para obtener más información, consulte [Descarga de informes en AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Su responsabilidad de conformidad cuando usa Lambda se determina en función de la confidencialidad de los datos, los objetivos de conformidad de su empresa, la legislación y los reglamentos aplicables. Puede implementar controles de gobierno para garantizar que las funciones de Lambda de su empresa cumplan con los requisitos de conformidad. Para obtener más información, consulte [Cree una estrategia de gobiernanza para las funciones y capas de Lambda](governance-concepts.md).
# Resiliencia en AWS Lambda
La infraestructura global de AWS se compone de regiones de AWS y zonas de disponibilidad de AWS. Las regiones proporcionan varias zonas de disponibilidad físicamente independientes y aisladas que se encuentran conectadas mediante redes con un alto nivel de rendimiento y redundancia, además de baja latencia. Con las zonas de disponibilidad, puedes diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.
Para obtener más información sobre las zonas de disponibilidad y las regiones de AWS, consulta [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Además de la infraestructura global de AWS, Lambda ofrece varias características que le ayudan con sus necesidades de resiliencia y copia de seguridad de los datos.
+ **Control de versiones**: Puede utilizar el control de versiones en Lambda para guardar el código de la función y la configuración a medida que realice el desarrollo. Junto con los alias, puede utilizar el control de versiones para realizar implementaciones continuas y blue/green. Para obtener más información, consulte [Administrar las versiones de la función de Lambda](configuration-versions.md).
+ **Escalado**: cuando la función recibe una solicitud mientras se procesa una solicitud anterior, Lambda lanza otra instancia de su función para administrar el aumento de la carga. Lambda se escala automáticamente para manejar 1000 ejecuciones simultáneas por región, una [cuota](gettingstarted-limits.md) que se pueden aumentar si es necesario. Para obtener más información, consulte [Comprender el escalado de la función de Lambda](lambda-concurrency.md).
+ **Alta disponibilidad**: Lambda ejecuta la función en varias zonas de disponibilidad para asegurarse de que está disponible para procesar eventos en caso de una interrupción del servicio en una sola zona. Si configura la función para conectarse a una nube privada virtual (VPC) en su cuenta, especifique subredes en varias zonas de disponibilidad para garantizar una alta disponibilidad. Para obtener más información, consulte [Otorgamiento a las funciones de Lambda de acceso a los recursos de una Amazon VPC](configuration-vpc.md).
+ **Simultaneidad reservada**: para asegurarse de que la función siempre puede escalarse para gestionar solicitudes adicionales, puede reservar la simultaneidad para ella. Configurar la simultaneidad reservada para una función garantiza que se puede escalar, pero no superar, un determinado número de invocaciones simultáneas. De este modo, se asegura de que no pierde las solicitudes debido a otras funciones que consumen toda la simultaneidad disponible. Para obtener más información, consulte [Configurar la simultaneidad reservada para una función](configuration-concurrency.md).
+ **Reintentos**: en invocaciones asíncronas y un subconjunto de invocaciones activadas por otros servicios, Lambda reintenta automáticamente en error con retrasos entre los reintentos. Otros clientes y los Servicios de AWS que invocan funciones de forma sincrónica son responsables de realizar los reintentos. Para obtener más información, consulte [Comprender el comportamiento de reintento en Lambda](invocation-retries.md).
+ **Cola de mensajes fallidos**: en invocaciones asíncronas, puede configurar Lambda para enviar solicitudes a una cola de mensajes fallidos si fallan todos los reintentos. Una cola de mensajes fallidos es un tema de Amazon SNS o una cola de Amazon SQS que recibe eventos para la resolución de problemas o para reprocesamiento. Para obtener más información, consulte [Cómo agregar una cola de mensajes fallidos](invocation-async-retain-records.md#invocation-dlq).
# Seguridad de la infraestructura en () AWS Lambda
Como se trata de un servicio administrado, AWS Lambda está protegido por la seguridad de red global de AWS. Para obtener información sobre los servicios de seguridad de AWS y cómo AWSprotege la infraestructura, consulte [Seguridad en la nube de AWS](https://aws.amazon.com/security/). Para diseñar su entorno de AWS con las prácticas recomendadas de seguridad de la infraestructura, consulte [Protección de la infraestructura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) en *Portal de seguridad de AWS Well‐Architected Framework*.
Puede utilizar llamadas a la API publicadas en AWS para obtener acceso a Lambda a través de la red. Los clientes deben admitir lo siguiente:
+ Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
# Protección de las cargas de trabajo con puntos de conexión públicos
En el caso de las cargas de trabajo a las que se puede acceder públicamente, AWS ofrece una serie de características y servicios que pueden ayudar a mitigar determinados riesgos. En esta sección, se describe la autenticación y la autorización de los usuarios de las aplicaciones y la protección de los puntos de conexión de las API.
## Autenticación y autorización
La autenticación se refiere a la identidad y la autorización se refiere a las acciones. Utilice la autenticación para controlar quién puede invocar una función de Lambda y, a continuación, utilice la autorización para controlar lo que puede hacer. Para muchas aplicaciones, IAM es suficiente para administrar ambos mecanismos de control.
En el caso de las aplicaciones con usuarios externos, como las aplicaciones web o móviles, es habitual utilizar los [tokens web de JSON](https://jwt.io/introduction/) (JWT) para administrar la autenticación y la autorización. A diferencia de la administración de contraseñas tradicional basada en servidores, los JWT se transmiten desde el cliente en cada solicitud. Son una forma criptográficamente segura de verificar la identidad y las reclamaciones con los datos transmitidos por el cliente. Para las aplicaciones basadas en Lambda, esto permite proteger todas las llamadas a cada punto de conexión de la API sin depender de un servidor central para la autenticación.
Puede [implementar JWT con Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), un servicio de directorio de usuarios que puede gestionar el registro, la autenticación, la recuperación de cuentas y otras operaciones comunes de administración de cuentas. [Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) proporciona bibliotecas para simplificar la integración de este servicio en su aplicación frontend. También puede considerar el uso de servicios de socios externos, como [Auth0](https://auth0.com/).
Dado el rol fundamental de seguridad que desempeña un servicio de proveedor de identidad, es importante utilizar herramientas profesionales para proteger la aplicación. No se recomienda que diseñe sus propios servicios para gestionar la autenticación o la autorización. Cualquier vulnerabilidad en las bibliotecas personalizadas puede tener implicaciones importantes para la seguridad de la carga de trabajo y sus datos.
## Protección de puntos de conexión de la API
En el caso de las aplicaciones sin servidor, la forma preferida de dar servicio público a una aplicación de backend es mediante Amazon API Gateway. Esto puede ayudarlo a proteger una API de los usuarios malintencionados o de los picos de tráfico.
API Gateway ofrece dos tipos de puntos de conexión para desarrolladores sin servidor: [API de REST](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) y [API de HTTP](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). Ambas son compatibles con la [autorización mediante AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), IAM o Amazon Cognito. Cuando se utiliza IAM o Amazon Cognito, se evalúan las solicitudes entrantes y, si les falta un token obligatorio o contienen una autenticación no válida, se rechaza la solicitud. No se cobrará por estas solicitudes ni se tendrán en cuenta a efectos de ninguna cuota por limitación.
Cualquier usuario de la Internet pública puede acceder a las rutas de API no autenticadas, por lo que se recomienda limitar el uso de las API no autenticadas. Si debe usar API no autenticadas, es importante protegerlas contra los riesgos comunes, como los [ataques de denegación de servicio](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS). [ Aplicar AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) a estas API puede ayudar a proteger la aplicación frente ataques de inyección de código SQL y scripting entre sitios (XSS). API Gateway también implementa la [limitación](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) en la cuenta de AWS y por cliente cuando se utilizan claves de API.
En muchos casos, la funcionalidad que proporciona una API no autenticada se puede lograr con un enfoque alternativo. Por ejemplo, una aplicación web puede proporcionar una lista de tiendas minoristas de clientes desde una tabla de DynamoDB a los usuarios que no hayan iniciado sesión. Esta solicitud puede provenir de una aplicación web frontend o de cualquier otro origen que llame al punto de conexión de la URL. En este diagrama se comparan tres soluciones:
![\[operaciones de seguridad (figura 5)\]](http://docs.aws.amazon.com/es_es/lambda/latest/dg/images/security-ops-figure-5.png)
1. Cualquier persona en Internet puede llamar a esta API sin autenticar. En un ataque de denegación de servicio, es posible agotar los límites de limitación de las API, la simultaneidad de Lambda o la capacidad de lectura aprovisionada por DynamoDB en una tabla subyacente.
1. Una distribución de CloudFront frente al punto de conexión de la API con una configuración de [tiempo de vida](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) adecuada absorbería la mayor parte del tráfico de un ataque de DoS, sin cambiar la solución subyacente para obtener los datos.
1. Como alternativa, para los datos estáticos que rara vez cambian, la distribución de CloudFront podría servir los datos desde un bucket de Amazon S3.
# Uso de la firma de código para verificar la integridad del código con Lambda
La firma de código ayuda a garantizar que solo se implemente código de confianza en sus funciones de Lambda. Con AWS Signer, puede crear paquetes de códigos firmados digitalmente para sus funciones. Al [añadir una configuración de firma de código a una función](configuration-codesigning-create.md), Lambda comprueba que todas las nuevas implementaciones de código estén firmadas por una fuente de confianza. Dado que las comprobaciones de validación de firma de código se ejecutan en tiempo de implementación, no hay impacto en la ejecución de funciones.
**importante**
Las configuraciones de firma de código solo impiden nuevas implementaciones de código sin firmar. Si agrega una configuración de firma de código a una función existente que tiene código sin firmar, ese código seguirá ejecutándose hasta que implemente un nuevo paquete de códigos.
Cuando habilita la firma de código para una función, todas las [capas](chapter-layers.md) que se agregan a la función también deben estar firmadas por uno de los perfiles de firma permitidos.
No hay ningún cargo adicional por usar AWS Signer o la firma de código para AWS Lambda.
## Validación de firmas
Lambda realiza las siguientes comprobaciones de validación cuando implementa un paquete de código firmado en su función:
1. **Integridad**: valida que el paquete de código no se ha modificado desde que se firmó. Lambda compara el hash del paquete con el hash de la firma.
1. **Caducidad**: valida que la firma del paquete de código no ha caducado.
1. **Discrepancia**: valida que el paquete de código está firmado con uno de los perfiles de firma permitidos.
1. **Revocación**: valida que la firma del paquete de código no se ha revocado.
Al crear una configuración de firma de código, puede usar el parámetro [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) para especificar cómo debe responder Lambda en caso de que las comprobaciones de caducidad, discrepancias o revocación fallen. Puede elegir uno de estas acciones:
+ `Warn`: esta es la configuración predeterminada. Lambda permite la implementación del paquete de código, pero emite una advertencia. Lambda emite una nueva métrica de Amazon CloudWatch (`SignatureValidationErrors`) y también almacena la advertencia en el registro de CloudTrail.
+ `Enforce`: Lambda emite una advertencia (lo mismo que para la acción `Warn`) y bloquea la implementación del paquete de código.
**Topics**
+ [
## Validación de firmas
](#config-codesigning-valid)
+ [
# Creación de configuraciones de firma de código para Lambda
](configuration-codesigning-create.md)
+ [
# Configuración de las políticas de IAM para configuraciones de firma de código de Lambda
](config-codesigning-policies.md)
+ [
# Uso de etiquetas en configuraciones de firma de código
](tags-csc.md)
# Creación de configuraciones de firma de código para Lambda
Para habilitar la firma de código para una función, debe crear una *configuración de firma de código* y adjuntarla a la función. Una configuración de firma de código define una lista de perfiles de firma permitidos y la acción de directiva que se debe realizar si falla alguna de las comprobaciones de validación.
**nota**
Las funciones definidas como imágenes de contenedor no admiten la firma de código.
**Topics**
+ [
## Requisitos previos de configuración
](#config-codesigning-prereqs)
+ [
## Creación de configuraciones de firma de código
](#config-codesigning-config-console)
+ [
## Habilitar la firma de código para una función
](#config-codesigning-function-console)
## Requisitos previos de configuración
Antes de configurar la firma de código para una función de Lambda, utilice AWS Signer para hacer lo siguiente:
+ Cree uno o varios [perfiles de firma](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html).
+ Utilice un perfil de firma para [crear un paquete de código firmado para su función](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html).
## Creación de configuraciones de firma de código
Una configuración de firma de código define una lista de perfiles de firma permitidos y la directiva de validación de firmas.
**Para crear una configuración de firma de código (consola)**
1. Abra la página [Configuraciones de firma de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) de la consola de Lambda.
1. Seleccione **Crear configuración**.
1. En **Descripción**, introduzca un nombre descriptivo para la configuración.
1. En **Perfiles de firma**, agregue hasta 20 perfiles de firma a la configuración.
1. Para **Firmar versión de perfil ARN**, elija el Nombre de recurso de Amazon (ARN) de una versión de perfil o introduzca el ARN.
1. Para agregar un perfil de firma adicional, elija **Agregar perfiles de firma**.
1. En **Política de validación de firmas**, seleccione **Advertir** o **Aplicar**.
1. Seleccione **Crear configuración**.
## Habilitar la firma de código para una función
Para habilitar la firma de código para una función, agregue una configuración de firma de código con la función.
**importante**
Las configuraciones de firma de código solo impiden nuevas implementaciones de código sin firmar. Si agrega una configuración de firma de código a una función existente que tiene código sin firmar, ese código seguirá ejecutándose hasta que implemente un nuevo paquete de códigos.
**Para asociar una configuración de firma de código con una función (consola)**
1. Abra la página de [Funciones](https://console.aws.amazon.com/lambda/home#/functions) en la consola de Lambda.
1. Elija la función para la que desea habilitar la firma de código.
1. Haga clic en la pestaña **Configuration** (Configuración).
1. Desplácese hacia abajo y seleccione **Firma de código**.
1. Elija **Edit (Edición de)**.
1. En **Editar firma de código**, elija una configuración de firma de código para esta función.
1. Seleccione **Save**.
# Configuración de las políticas de IAM para configuraciones de firma de código de Lambda
Para conceder permiso a un usuario para acceder a las operaciones de la API de firma de código de Lambda, adjunte una o varias instrucciones de política a la política de usuario. Para obtener más información sobre las políticas de usuario, consulte [Políticas de IAM basadas en identidad para Lambda](access-control-identity-based.md).
En la siguiente declaración de directiva de ejemplo se concede permiso para crear, actualizar y recuperar configuraciones de firma de código.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
Los administradores pueden usar la clave de `CodeSigningConfigArn` condición para especificar las configuraciones de firma de código que los desarrolladores deben utilizar para crear o actualizar sus funciones.
En la siguiente declaración de política de ejemplo se concede permiso para crear una función. La declaración de política incluye una condición `lambda:CodeSigningConfigArn` para especificar la configuración de firma de código permitida. Lambda bloquea las solicitudes a la API `CreateFunction` si el parámetro [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) no está o no coincide con el valor de la condición.
------
#### [ 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"
}
}
}
]
}
```
------
# Uso de etiquetas en configuraciones de firma de código
Puede etiquetar configuraciones de firma de código para organizar y administrar sus recursos. Las etiquetas son pares de clave-valor de formato libre que se asocian a los recursos y que son compatibles con todos los Servicios de AWS. Para obtener más información sobre los casos de uso de las etiquetas, consulte [Estrategias de etiquetado habituales](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) en la *Guía del editor de etiquetas y recursos de etiquetado de AWS*.
Puede utilizar la API de AWS Lambda para ver y actualizar etiquetas. También puede ver y actualizar las etiquetas mientras administra una configuración de firma de código específica en la consola de Lambda.
**Topics**
+ [
## Permisos necesarios para trabajar con etiquetas
](#csc-tags-required-permissions)
+ [
## Uso de etiquetas con la consola de Lambda
](#tags-csc-console)
+ [
## Uso de etiquetas con la AWS CLI
](#tags-csc-cli)
## Permisos necesarios para trabajar con etiquetas
Para permitir que una identidad de AWS Identity and Access Management (IAM) (usuario, grupo o rol) lea o establezca etiquetas en un recurso, conceda los permisos correspondientes:
+ **lambda:ListTags**: cuando un recurso tiene etiquetas, conceda este permiso a cualquier persona que necesite llamar a `ListTags` en este. En el caso de las funciones etiquetadas, este permiso también es necesario para `GetFunction`.
+ **lambda:TagResource**: conceda este permiso a cualquier persona que necesite llamar a `TagResource` o efectuar una etiqueta en la creación.
Si lo desea, considere conceder el permiso **lambda:UntagResource** y permitir las llamadas `UntagResource` al recurso.
Para obtener más información, consulte [Políticas de IAM basadas en identidad para Lambda](access-control-identity-based.md).
## Uso de etiquetas con la consola de Lambda
Puede utilizar la consola de Lambda para crear configuraciones de firma de código que tengan etiquetas, agregar etiquetas a configuraciones de firma de código existentes y filtrar configuraciones de firma de código por etiqueta.
**Adición de una etiqueta al crear una configuración de firma de código**
1. Abra [Configuraciones de la firma de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) en la consola de Lambda.
1. En el encabezado del panel de contenido, seleccione **Crear la configuración**.
1. En la sección de la parte superior del panel de contenido, defina la configuración de firma de código. Para obtener más información sobre cómo definir las configuraciones de firma de código, consulte [Uso de la firma de código para verificar la integridad del código con Lambda](configuration-codesigning.md).
1. En la sección **Etiquetas**, elija **Agregar nueva etiqueta**.
1. En el campo **Clave**, ingrese la clave de la etiqueta. Para obtener información sobre las restricciones de etiquetado, consulte [Límites y requisitos de denominación de etiquetas](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) en la *Guía del editor de etiquetas y recursos de etiquetado de AWS*.
1. Seleccione **Crear configuración**.
**Adición de una etiqueta a una configuración de firma de código existente**
1. Abra [Configuraciones de la firma de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) en la consola de Lambda.
1. Elija el nombre de la configuración de firma de código.
1. En las pestañas situadas debajo del panel **Detalle**, seleccione **Etiquetas**.
1. Elija **Manage tags** (Administrar etiquetas).
1. Elija **Add new tag** (Agregar nueva etiqueta).
1. En el campo **Clave**, ingrese la clave de la etiqueta. Para obtener información sobre las restricciones de etiquetado, consulte [Límites y requisitos de denominación de etiquetas](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) en la *Guía del editor de etiquetas y recursos de etiquetado de AWS*.
1. Seleccione **Save**.
**Filtrado de las configuraciones de firma de código por etiqueta**
1. Abra [Configuraciones de la firma de código](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) en la consola de Lambda.
1. Seleccione la barra de búsqueda.
1. En la lista desplegable, seleccione la etiqueta situada debajo del subtítulo **Etiquetas**.
1. Seleccione **Usar: "nombre-etiqueta"** para ver todas las configuraciones de firma de código etiquetadas con esta clave o elija un **operador** para filtrar aún más por valor.
1. Seleccione el valor de la etiqueta para filtrarla por una combinación de clave y valor de la etiqueta.
El cuadro de búsqueda también permite buscar claves de etiqueta. Escriba el nombre de una clave para encontrarla en la lista.
## Uso de etiquetas con la AWS CLI
Puede agregar y eliminar etiquetas en los recursos de Lambda existentes, incluidas las configuraciones de firma de código, con la API de Lambda. También puede agregar etiquetas al crear una configuración de firma de código, lo que le permite mantener un recurso etiquetado durante todo su ciclo de vida.
### Actualización de etiquetas con las API de etiquetas de Lambda
Puede agregar y eliminar etiquetas para los recursos de Lambda compatibles mediante las operaciones de API [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) y [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html).
También puede llamar a estas operaciones mediante la AWS CLI. Para agregar etiquetas a un recurso existente, utilice el comando `tag-resource`. En este ejemplo se agregan dos etiquetas, una con la clave *Department* y otra con la clave *CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Para eliminar etiquetas, utilice el comando `untag-resource`. En este ejemplo, se elimina la etiqueta con la clave *Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Adición de etiquetas al crear una configuración de firma de código
Para crear una nueva configuración de firma de código de Lambda con etiquetas, utilice la operación de la API [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html). Especifique el parámetro `Tags`. Puede llamar a esta operación con el comando `create-code-signing-config` de la AWS CLI y la opción `--tags`. Para obtener más información sobre el comando de la CLI, consulte [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html) en la *Referencia de comandos de la AWS CLI*.
Antes de usar el parámetro `Tags` con `CreateCodeSigningConfig`, asegúrese de que su rol tenga permiso para etiquetar los recursos junto con los permisos habituales necesarios para esta operación. Para obtener más información sobre permisos de etiquetado, consulte [Permisos necesarios para trabajar con etiquetas](#csc-tags-required-permissions).
### Visualización de etiquetas con las API de etiquetas de Lambda
Para ver las etiquetas que se aplican a un recurso de Lambda específico, utilice la operación de la API `ListTags`. Para obtener más información, consulte [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Puede llamar a esta operación con el comando `list-tags` de la AWS CLI si proporciona un ARN (nombre de recurso de Amazon).
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtrado de recursos por etiqueta
Puede utilizar la operación de la API de AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) para filtrar los recursos por etiquetas. La operación `GetResources` recibe hasta 10 filtros y cada uno contiene una clave de etiqueta y hasta 10 valores de etiqueta. Usted proporciona `GetResources` con un `ResourceType` para filtrar por tipos de recurso específicos.
Puede llamar a esta operación mediante el comando `get-resources` de la AWS CLI. Para ver ejemplos de uso de `get-resources`, consulte [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) en la *Referencia de comandos de la AWS CLI*.