Detecte las implementaciones y configuraciones de Lambda que no cumplan con AWS Config

Además de realizar una evaluación proactiva, 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:

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 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:

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 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 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:

Con los datos de AWS Config agregados en toda la organización, puede crear un panel con Amazon QuickSight. Al importar los resultados de Athena a QuickSight, 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. 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.

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