Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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

Neben der proaktiven Bewertung AWS Config kann auch reaktiv Ressourcenbereitstellungen und -konfigurationen erkannt werden, 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 eine Funktion AWS Config erkannt wird, die keine genehmigte Layer-Version verwendet, wird die Funktion als nicht konforme Ressource gekennzeichnet. Sie können optional so konfigurieren AWS Config , dass die Ressource automatisch repariert wird, indem Sie mithilfe eines Automatisierungsdokuments eine Behebungsaktion angeben. AWS Systems Manager Sie könnten beispielsweise ein Automatisierungsdokument in Python mit dem schreiben AWS SDK for Python (Boto3), wodurch die nicht konforme Funktion aktualisiert wird, sodass sie auf die genehmigte Layer-Version verweist. Es 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 alle Ihre Konten und konfigurieren Sie es so, dass AWS Lambda-Funktionen aufgezeichnet werden. Auf diese Weise kann AWS Config beobachtet werden, wann 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_PARAMETERSist ein spezieller Satz von Parametern, der mit der 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 sammelt Konfigurationsdaten und speichert diese Daten 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 Visualisieren von AWS Config Daten mit Athena und QuickSight Amazon im AWS Cloud Operations and Management-Blog.

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:

Wenn die AWS Config Daten unternehmensweit aggregiert sind, können Sie dann mit Amazon QuickSight ein Dashboard erstellen. Durch den Import Ihrer Athena-Ergebnisse in Amazon können Sie visualisieren QuickSight, wie gut Ihre Lambda-Funktionen der Layer-Versionsregel 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 for Python (Boto3) erstellt haben, mit einer Behebungsaktion verknüpfen. Das Skript ruft die UpdateFunctionKonfigurations-API-Aktion für jede Lambda-Funktion 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.