# 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.