Rilevare implementazioni e configurazioni Lambda non conformi con AWS Config

Oltre alla valutazione proattiva, AWS Config può anche rilevare in modo reattivo le implementazioni e le configurazioni di risorse non conformi alle policy di governance. Si tratta di una funzione importante, perché le policy di governance si evolvono man mano che l'organizzazione apprende e implementa nuove best practice.

Immagina uno scenario in cui imposti una nuova policy durante l'implementazione o l'aggiornamento delle funzioni Lambda: tutte le funzioni Lambda devono sempre utilizzare una versione di livello Lambda specifica e approvata. Puoi configurare AWS Config per monitorare le funzioni nuove o aggiornate per le configurazioni di livello. Se rileva una funzione che non utilizza una versione di livello approvata, AWS Config la contrassegna come risorsa non conforme. Come opzione, puoi configurare AWS Config affinché ripari in automatico la risorsa specificando un'azione di riparazione attraverso un documento di automazione AWS Systems Manager. Ad esempio, è possibile scrivere un documento di automazione in Python utilizzando AWS SDK per Python (Boto3), che aggiorna la funzione non conforme in modo che punti alla versione di livello approvata. Pertanto, AWS Config funge da controllo sia di rilevamento che di correzione e in tal modo automatizza la gestione della conformità.

Suddividiamo questo processo in tre importanti fasi di implementazione:

Fase 1: identificazione delle risorse di accesso

Comincia attivando AWS Config su tutti i tuoi account e configurando il registro affinché registri le funzioni AWS Lambda. Ciò consente a AWS Config di osservare quando le funzioni Lambda vengono create o aggiornate. Puoi quindi configurare regole di policy personalizzate per verificare la presenza di eventuali violazioni di policy specifiche, che utilizzano la sintassi AWS CloudFormation Guard. Le regole di Guard assumono la seguente forma generale:

rule name when condition { assertion }

Di seguito è riportato un esempio di regola che verifica che un livello non sia impostato su una versione di livello vecchia:

rule desiredlayer when configuration.layers !empty {
    some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn
}

Analizziamo la sintassi e la struttura della regola:

CONFIG_RULE_PARAMETERS è un insieme di parametri speciali configurato con la regola AWS Config. In questo caso, OldLayerArn è un parametro all'interno di CONFIG_RULE_PARAMETERS. Ciò consente agli utenti di fornire un valore di ARN specifico che ritengono vecchio o ritirato, quindi la regola verifica se alcune funzioni Lambda utilizzano l'ARN vecchio in questione.

Fase 2: visualizzazione e progettazione

AWS Config raccoglie i dati di configurazione e li archivia in bucket Amazon Simple Storage Service (Amazon S3). Puoi utilizzare Amazon Athena per inviare query a tali dati direttamente dai bucket S3. Con Athena, puoi aggregare questi dati a livello dell'organizzazione, generando una visione onnicomprensiva delle configurazioni delle risorse in tutti gli account. Per configurare l'aggregazione dei dati di configurazione delle risorse, consulta Visualizing AWS Config data using Athena and Amazon QuickSight nel blog AWS Cloud Operations and Management.

Di seguito è riportato un esempio di query Athena per identificare tutte le funzioni Lambda che utilizzano un particolare ARN di livello:

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%'

Ecco i risultati della query:

Con i dati di AWS Config aggregati in tutta l'organizzazione, puoi quindi creare una dashboard utilizzando Amazon QuickSight. Importando i risultati di Athena in Amazon QuickSight, puoi visualizzare in che misura le funzioni Lambda aderiscono alla regola della versione di livello. Questa dashboard può evidenziare le risorse conformi e non conformi. Ciò ti aiuta a determinare la policy di applicazione, come indicato nella sezione successiva. L'immagine seguente è un esempio di dashboard che riporta la distribuzione delle versioni di livello applicate alle funzioni all'interno dell'organizzazione.

Fase 3: implementazione e applicazione

Ora, come opzione, puoi abbinare la regola della versione di livello che hai creato nella fase 1 con un'azione di correzione attraverso un documento di automazione Systems Manager, creato come script Python scritto con AWS SDK per Python (Boto3). Lo script effettua una chiamata all'operazione API UpdateFunctionConfiguration per ogni funzione Lambda e aggiorna la configurazione della funzione con il nuovo ARN di livello. In alternativa, potresti fare in modo che lo script invii una richiesta pull al repository del codice per aggiornare l'ARN del livello. In questo modo anche le future implementazioni di codice vengono aggiornate con l'ARN di livello corretto.