Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Rileva implementazioni e configurazioni Lambda non conformi con AWS Config

Oltre alla valutazione proattiva, AWS Config puoi anche rilevare in modo reattivo le implementazioni e le configurazioni delle risorse che non sono conformi alle politiche 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 AWS Config rileva una funzione che non utilizza una versione di livello approvata, contrassegna la funzione come risorsa non conforme. Facoltativamente, è possibile AWS Config configurare la riparazione automatica della risorsa specificando un'azione di riparazione utilizzando un documento di automazione. AWS Systems Manager Ad esempio, è possibile scrivere un documento di automazione in Python utilizzando AWS SDK for Python (Boto3), che aggiorna la funzione non conforme in modo che punti alla versione del livello approvata. Pertanto, AWS Config funge sia da controllo investigativo che correttivo, automatizzando la gestione della conformità.

Suddividiamo questo processo in tre importanti fasi di implementazione:

Fase 1: identificazione delle risorse di accesso

Inizia eseguendo l'attivazione AWS Config su tutti i tuoi account e configurandola per registrare le funzioni Lambda AWS . Ciò consente di AWS Config 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 set speciale di parametri configurato con la AWS Config regola. 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 data AWS Config using Athena and Amazon QuickSight sul 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 AWS Config dati aggregati in tutta l'organizzazione, puoi quindi creare una dashboard utilizzando Amazon QuickSight. Importando i risultati di Athena in QuickSight Amazon, puoi visualizzare in che misura le tue funzioni Lambda aderiscono alla regola della versione del 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 for Python (Boto3). Lo script richiama l'azione UpdateFunctionConfigurationAPI per ogni funzione Lambda, aggiornando la configurazione della funzione con il nuovo livello ARN. 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.