Erkennen Sie nicht konforme Lambda-Bereitstellungen und -Konfigurationen mit AWS Config

Neben der proaktiven Evaluierung kann AWS Config auch im Nachhinein Ressourcenbereitstellungen und -konfigurationen erkennen, die nicht Ihren Governance-Richtlinien entsprechen. Das ist wichtig, weil sich Governance-Richtlinien ändern können, wenn Ihr Unternehmen sich weiterentwickelt und neue Best-Practices eingeführt werden.

Angenommen, Sie legen bei der Bereitstellung oder Aktualisierung von Lambda-Funktionen eine brandneue Richtlinie fest: Alle Lambda-Funktionen müssen immer eine bestimmte, genehmigte Lambda-Layer-Version verwenden. Sie können AWS Config konfigurieren, um neue oder aktualisierte Funktionen für Layer-Konfigurationen zu überwachen. Wenn AWS Config auf eine Funktion stößt, die keine genehmigte Layer-Version verwendet, wird die Funktion als nicht konforme Ressource gekennzeichnet. Sie können AWS Config optional so konfigurieren, dass die Ressource automatisch repariert wird, indem Sie mithilfe eines AWS Systems Manager-Automatisierungsdokuments eine Behebungsaktion angeben. Sie könnten ein Automatisierungsdokument in Python mit AWS SDK für Python (Boto3) schreiben, das die nicht konforme Funktion aktualisiert, sodass sie auf die genehmigte Layer-Version verweist. AWS Config dient somit sowohl als detektive als auch als korrektive Kontrolle und automatisiert das Compliance-Management.

Wir brechen diesen Prozess in drei zentrale Implementierungsphasen auf:

Phase 1: Identifizieren der Zugriffsressourcen

Aktivieren Sie zunächst AWS Config für alle Ihre Konten und konfigurieren Sie es so, dass AWS-Lambda-Funktionen aufgezeichnet werden. AWS Config kann so erkennen, wenn Lambda-Funktionen erstellt oder aktualisiert werden. Anschließend können Sie benutzerdefinierte Richtlinienregeln konfigurieren, um nach bestimmten Richtlinienverstößen zu suchen, die AWS CloudFormation Guard-Syntax verwenden. Guard-Regeln haben die folgende allgemeine Form:

rule name when condition { assertion }

Im Folgenden finden Sie eine Beispielregel, mit der überprüft wird, ob ein Layer auf eine alte Layer-Version eingestellt ist:

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

Sehen wir uns die Syntax und den Regelaufbau etwas genauer an:

CONFIG_RULE_PARAMETERS ist ein spezieller Parametersatz, mit dem die AWS Config-Regel konfiguriert wird. In diesem Fall ist OldLayerArn ein Parameter in CONFIG_RULE_PARAMETERS. Benutzer können so einen bestimmten ARN-Wert als veraltet oder abgelaufen festlegen. Anschließend überprüft die Regel, ob Lambda-Funktionen diesen alten ARN verwenden.

Phase 2: Visualisierung und Entwicklung

AWS Config erfasst Konfigurationsdaten und speichert sie in Amazon Simple Storage Service (Amazon S3)-Buckets. Sie können Amazon Athena verwenden, um diese Daten direkt aus Ihren S3-Buckets abzufragen. Mit Athena können Sie diese Daten auf Organisationsebene aggregieren und sich einen ganzheitlichen Überblick über die Ressourcenkonfigurationen in all Ihren Konten verschaffen. Informationen zum Einrichten der Aggregation von Ressourcenkonfigurationsdaten finden Sie unter Visualizing AWS Config data using Athena and Amazon Quick Suite im Blog „ AWS Cloud Operations & Management“.

Im Folgenden finden Sie ein Beispiel für eine Athena-Abfrage zur Identifizierung aller Lambda-Funktionen, die einen bestimmten Layer-ARN verwenden:

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

Hier sind die Ergebnisse der Abfrage:

Nachdem die AWS Config-Daten unternehmensweit aggregiert wurden, können Sie mit Amazon Quick Suite ein Dashboard erstellen. Sie importieren die Ergebnisse aus Athena in Quick Suite und können dann visualisieren, wie gut Ihre Lambda-Funktionen der Ebenenversionsregel entsprechen. Im Dashboard können Sie konforme und nicht konforme Ressourcen hervorheben und dementsprechend Durchsetzungsrichtlinien festlegen, wie im nächsten Abschnitt beschrieben. Die folgende Abbildung zeigt ein Beispiel-Dashboard, in dem die Verteilung der Layer-Versionen auf Funktionen innerhalb der Organisation aufgeschlüsselt ist.

Phase 3: Implementierung und Durchsetzung

Sie können Ihre Layer-Versionsregel, die Sie in Phase 1 erstellt haben, jetzt optional über ein Systems-Manager-Automatisierungsdokument, das Sie als Python-Skript mit AWS SDK für Python (Boto3) erstellt haben, mit einer Behebungsaktion verknüpfen. Das Skript ruft für jede Lambda-Funktion die API-Aktion UpdateFunctionConfiguration auf und aktualisiert die Funktionskonfiguration mit dem neuen Layer-ARN. Alternativ können Sie das Skript so schreiben, dass eine Pull-Anfrage an das Code-Repository gesendet wird, um den Layer-ARN zu aktualisieren. Auf diese Weise werden künftige Codebereitstellungen ebenfalls mit dem richtigen Layer-ARN aktualisiert.