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. # Erstellen Sie eine Governance-Strategie für Lambda-Funktionen und -Layer Bei der Entwicklung und Bereitstellung cloudnativer Serverless-Anwendungen müssen Sie durch angemessene Governance- und Schutzmaßnahmen für Agilität und eine schnelle Markteinführung sorgen. Dazu legen Sie auf Unternehmensebene Prioritäten fest, wobei Sie entweder die Agilität oder durch geeignete Governance, Schutzmaßnahmen und Kontrollen die Risikovermeidung an erste Stelle setzen. Normalerweise werden Sie keine so klare Grenze ziehen, sondern beide Aspekte – Agilität und Sicherheit – in Ihrem Softwareentwicklungszyklus abbilden möchten. Ganz gleich, wo im Lebenszyklus Ihres Unternehmens diese Anforderungen stehen, Sie werden mit hoher Wahrscheinlichkeit Governance-Funktionen in Ihre Prozesse und Toolchains implementieren müssen. Hier sind einige Beispiele für Governance-Kontrollen, die ein Unternehmen für Lambda implementieren könnte: + Lambda-Funktionen dürfen nicht öffentlich zugänglich sein. + Lambda-Funktionen müssen mit einer VPC verbunden sein. + Lambda-Funktionen sollten keine veralteten Laufzeiten verwenden. + Lambda-Funktionen müssen mit einer Reihe erforderlicher Tags markiert werden. + Lambda-Layer dürfen außerhalb der Organisation nicht zugänglich sein. + Wenn Lambda-Funktionen mit einer Sicherheitsgruppe verbunden sind, müssen beide übereinstimmende Tags haben. + Lambda-Funktionen mit einem verbundenen Layer müssen eine genehmigte Version verwenden + Lambda-Umgebungsvariablen müssen im Ruhezustand mit einem vom Kunden verwalteten Schlüssel verschlüsselt sein. Das folgende Diagramm ist ein Beispiel für eine umfassende Governance-Strategie, bei der Kontrollen und Richtlinien während des gesamten Softwareentwicklungs- und Bereitstellungsprozesses implementiert werden: ![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-concepts.png) In den folgenden Themen wird erklärt, wie Sie Kontrollen für die Entwicklung und Bereitstellung von Lambda-Funktionen in Ihrem Unternehmen implementieren. Die Ausführungen gelten für Startups und große Unternehmen gleichermaßen. Möglicherweise verfügt Ihr Unternehmen bereits über geeignete Tools. In den folgenden Themen wird ein modularer Ansatz für diese Kontrollen verfolgt, damit Sie die Komponenten auswählen können, die Sie tatsächlich benötigen. **Topics** + [Proaktive Kontrollen für Lambda mit AWS CloudFormation Guard](governance-cloudformation-guard.md) + [Implementieren Sie präventive Kontrollen für Lambda mit AWS Config](governance-config.md) + [Erkennen Sie nicht konforme Lambda-Bereitstellungen und -Konfigurationen mit AWS Config](governance-config-detection.md) + [Lambda-Codesignatur mit AWS Signer](governance-code-signing.md) + [Automatisieren Sie Sicherheitsbewertungen für Lambda mit Amazon Inspector](governance-code-scanning.md) + [Implementieren von Beobachtbarkeit für Lambda-Sicherheit und -Compliance](governance-observability.md) # Proaktive Kontrollen für Lambda mit AWS CloudFormation Guard [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) ist ein allgemein verwendbares Open-Source-Tool zur Policy-as-Code-Evaluierung. Es kann für präventive Governance und Compliance verwendet werden, indem Infrastructure as Code (IaC)-Vorlagen und Servicezusammenstellungen anhand von Richtlinienregeln validiert werden. Diese Regeln können an die Anforderungen Ihres Teams oder Ihrer Organisation angepasst werden. Für Lambda-Funktionen können die Guard-Regeln verwendet werden, um die Ressourcenerstellung und Konfigurationsupdates zu steuern. Dazu werden die erforderlichen Eigenschaftseinstellungen definiert, die beim Erstellen oder Aktualisieren einer Lambda-Funktion erforderlich sind. Compliance-Administratoren definieren die Liste der Kontrollen und Governance-Richtlinien, die für die Bereitstellung und Aktualisierung von Lambda-Funktionen erforderlich sind. Plattformadministratoren implementieren die Kontrollen in CI/CD-Pipelines als Pre-Commit-Validierungs-Webhooks mit Code-Repositorys und stellen Entwicklern Befehlszeilentools zur Validierung von Vorlagen und Code auf lokalen Workstations zur Verfügung. Entwickler schreiben Code, validieren Vorlagen mit Befehlszeilentools und übertragen dann den Code in Repositorys, die vor der Bereitstellung in einer AWS-Umgebung automatisch über die CI/CD-Pipelines validiert werden. Guard ermöglicht es Ihnen wie folgt, [Regeln zu schreiben](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html) und Kontrollen in einer domainspezifischen Sprache zu implementieren. ![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-cloudformation-guard.png) Angenommen, Sie möchten, dass Entwickler nur die neuesten Laufzeiten verwenden. Sie könnten zwei verschiedene Richtlinien erstellen. Eine, um [Laufzeiten](lambda-runtimes.md) zu bestimmen, die bereits veraltet sind, und eine andere, um Laufzeiten zu bestimmen, die demnächst veraltet sein werden. Dazu könnten Sie die folgende `etc/rules.guard`-Datei schreiben: ``` let lambda_functions = Resources.*[ Type == "AWS::Lambda::Function" ] rule lambda_already_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <> } } } } rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <> } } } } ``` Nehmen wir nun an, Sie schreiben die folgende `iac/lambda.yaml`-CloudFormation-Vorlage, die eine Lambda-Funktion definiert: ``` Fn: Type: AWS::Lambda::Function Properties: Runtime: python3.7 CodeUri: src Handler: fn.handler Role: !GetAtt FnRole.Arn Layers: - arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35 ``` Nach der [Installation](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) des Guard-Dienstprogramms überprüfen Sie die Vorlage: ``` cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml ``` Das Ergebnis sieht folgendermaßen aus: ``` lambda.yaml Status = FAIL FAILED rules rules.guard/lambda_soon_to_be_deprecated_runtime --- Evaluating data lambda.yaml against rules rules.guard Number of non-compliant resources 1 Resource = Fn { Type = AWS::Lambda::Function Rule = lambda_soon_to_be_deprecated_runtime { ALL { Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] { ComparisonError { Message = Lambda function is using a runtime that is targeted for deprecation. Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])] } PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15] Operator = NOT IN Value = "python3.7" ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]] Code: 86. Fn: 87. Type: AWS::Lambda::Function 88. Properties: 89. Runtime: python3.7 90. CodeUri: src 91. Handler: fn.handler } } } } ``` Guard zeigt Entwicklern auf ihren lokalen Workstations, dass sie die Vorlage aktualisieren müssen, um eine Laufzeit zu verwenden, die von der Organisation zugelassen ist. Dies geschieht, bevor ein Commit in ein Code-Repository übernommen wird und anschließend Prüfungen innerhalb einer CI/CD-Pipeline fehlschlagen. Ihre Entwickler erhalten direktes Feedback, wie sie konforme Vorlagen entwickeln und können ihre Zeit darauf verwenden, Code zu schreiben, der geschäftlichen Nutzen bietet. Diese Kontrolle kann vor der Bereitstellung auf der lokalen Entwickler-Workstation, in einem Pre-Commit-Validierungs-Webhook und/oder in der CI/CD-Pipeline angewendet werden. ## Einschränkungen Wenn Sie AWS Serverless Application Model-(AWS SAM)-Vorlagen verwenden, um Lambda-Funktionen zu definieren, beachten Sie, dass Sie die Guard-Regel aktualisieren müssen, um nach dem Ressourcentyp `AWS::Serverless::Function` wie folgt zu suchen. ``` let lambda_functions = Resources.*[ Type == "AWS::Serverless::Function" ] ``` Guard erwartet außerdem, dass die Eigenschaften in der Ressourcendefinition enthalten sind. AWS SAM-Vorlagen ermöglichen die Angabe von Eigenschaften in einem separaten [Globals](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html)-Abschnitt. Eigenschaften, die im Globals-Abschnitt definiert sind, werden nicht mit Ihren Guard-Regeln validiert. Beachten Sie, dass Guard, wie in der [Dokumentation zur Fehlerbehebung](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html) bei Guard beschrieben, keine intrinsischen Kurzformen wie `!GetAtt` oder `!Sub` unterstützt, sondern stattdessen die Verwendung der erweiterten Formen erfordert: `Fn::GetAtt` und `Fn::Sub`. (Im [vorherigen Beispiel](#guard-iac-yaml) wird die Role-Eigenschaft nicht ausgewertet, daher wurde der Einfachheit halber die intrinsische Kurzform verwendet.) # Implementieren Sie präventive Kontrollen für Lambda mit AWS Config Es ist wichtig, so früh wie möglich im Entwicklungsprozess die Konformität Ihrer Serverless-Anwendungen sicherzustellen. In diesem Thema behandeln wir die Implementierung präventiver Kontrollen mithilfe von [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). Auf diese Weise können Sie Konformitätsprüfungen zu einem früheren Zeitpunkt im Entwicklungsprozess implementieren und dieselben Kontrollen in Ihren Pipelines implementieren. CI/CD Dadurch werden auch Ihre Kontrollen in einem zentral verwalteten Regelspeicher standardisiert, sodass Sie Ihre Kontrollen konsistent auf alle Konten anwenden können. AWS Nehmen wir beispielsweise an, Ihre Compliance-Administratoren haben eine Anforderung definiert, um sicherzustellen, dass alle Lambda-Funktionen die AWS X-Ray Ablaufverfolgung beinhalten. Mit dem AWS Config proaktiven Modus können Sie vor der Bereitstellung Konformitätsprüfungen Ihrer Lambda-Funktionsressourcen durchführen, wodurch das Risiko der Bereitstellung falsch konfigurierter Lambda-Funktionen verringert und Entwicklern Zeit gespart wird, indem sie ihnen schnelleres Feedback zur Infrastruktur als Codevorlagen geben. Im Folgenden wird der Ablauf präventiver Kontrollen visualisiert mit: AWS Config ![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-1.png) Nehmen wir an, es wird festgelegt, dass für alle Lambda-Funktionen die Ablaufverfolgung aktiviert sein muss. Als Reaktion darauf stellt das Plattformteam fest, dass eine bestimmte AWS Config Regel proaktiv für alle Konten ausgeführt werden muss. Diese Regel kennzeichnet jede Lambda-Funktion, für die keine X-Ray-Ablaufverfolgung konfiguriert ist, als nicht konforme Ressource. Das Team entwickelt eine Regel, verpackt sie in ein [Konformitätspaket und stellt das Konformitätspaket](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) für alle Konten bereit, um sicherzustellen, dass alle AWS Konten in der Organisation diese Kontrollen einheitlich anwenden. Sie können die Regel in der AWS CloudFormation Guard 2.x.x-Syntax schreiben, die folgende Form hat: ``` rule name when condition { assertion } ``` Im Folgenden finden Sie ein Beispiel für eine Guard-Regel, die überprüft, ob für Lambda-Funktionen die Ablaufverfolgung aktiviert ist: ``` rule lambda_tracing_check { when configuration.tracingConfig exists { configuration.tracingConfig.mode == "Active" } } ``` [Das Plattformteam ergreift weitere Maßnahmen und schreibt vor, dass bei jeder AWS CloudFormation Bereitstellung ein Pre-Create/Update-Hook aufgerufen wird.](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html) Das Team übernimmt die volle Verantwortung für die Entwicklung dieses Hooks und die Konfiguration der Pipeline, mit dem Ziel, die zentrale Kontrolle der Compliance-Regeln zu stärken und ihre konsistente Anwendung in allen Implementierungen sicherzustellen. Informationen zur Entwicklung, Paketierung und Registrierung eines [AWS CloudFormation Hooks finden Sie in der Dokumentation zur CloudFormation Befehlszeilenschnittstelle (CFN-CLI) unter Developing Hooks](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html). Sie können die [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) verwenden, um das Hook-Projekt zu erstellen: ``` cfn init ``` Der Befehl fragt Sie nach einigen grundlegenden Informationen zu Ihrem Hook-Projekt und erstellt ein Projekt mit den folgenden Dateien: ``` README.md .json rpdk.log src/handler.py template.yml hook-role.yaml ``` Der Hook-Entwickler fügt der Konfigurationsdatei `.json` den gewünschten Zielressourcentyp hinzu. In der folgenden Konfiguration ist ein Hook so konfiguriert, dass er ausgeführt wird, bevor eine Lambda-Funktion mit CloudFormation erstellt wird. Sie können ähnliche Handler auch für die Aktionen `preUpdate` und `preDelete` hinzufügen. ``` "handlers": { "preCreate": { "targetNames": [ "AWS::Lambda::Function" ], "permissions": [] } } ``` Sie müssen auch sicherstellen, dass der CloudFormation Hook über die entsprechenden Berechtigungen zum Aufrufen von verfügt. AWS Config APIs Aktualisieren Sie dazu die Rollendefinitionsdatei `hook-role.yaml`. Die Rollendefinitionsdatei hat standardmäßig die folgende Vertrauensrichtlinie, die es ermöglicht, die Rolle CloudFormation zu übernehmen. ``` AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - hooks.cloudformation.amazonaws.com - resources.cloudformation.amazonaws.com ``` Damit dieser Hook die Konfiguration aufrufen kann APIs, müssen Sie der Policy-Anweisung die folgenden Berechtigungen hinzufügen. Anschließend reichen Sie das Hook-Projekt mit dem `cfn submit` Befehl ein, der eine Rolle mit den erforderlichen Berechtigungen für Sie CloudFormation erstellt. ``` Policies: - PolicyName: HookTypePolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - "config:Describe*" - "config:Get*" - "config:List*" - "config:SelectResourceConfig" Resource: "* ``` Als Nächstes müssen Sie eine Lambda-Funktion in eine `src/handler.py`-Datei schreiben. In dieser Datei finden Sie Methoden mit dem Namen und `preCreate`, `preUpdate` und `preDelete`, die bereits bei der Initiierung des Projekts erstellt wurden. Sie möchten eine allgemeine, wiederverwendbare Funktion schreiben, die die AWS Config `StartResourceEvaluation` API im proaktiven Modus aufruft, indem Sie den verwenden AWS SDK für Python (Boto3). Dieser API-Aufruf verwendet Ressourceneigenschaften als Eingabe und vergleicht die Ressource mit der Regeldefinition. ``` def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent: LOG.info("Fetching proactive data") config_client = boto3.client('config') resource_specs = { 'ResourceId': 'MyFunction', 'ResourceType': resource_type, 'ResourceConfiguration': json.dumps(function_properties), 'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA' } LOG.info("Resource Specifications:", resource_specs) eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60) ResourceEvaluationId = eval_response.ResourceEvaluationId compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId) LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType) if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType: return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant) else: return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.") ``` Jetzt können Sie die allgemeine Funktion vom Handler für den Pre-Create-Hook aus aufrufen. Ein Beispiel für den Handler: ``` @hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION) def pre_create_handler( session: Optional[SessionProxy], request: HookHandlerRequest, callback_context: MutableMapping[str, Any], type_configuration: TypeConfigurationModel ) -> ProgressEvent: LOG.info("Starting execution of the hook") target_name = request.hookContext.targetName LOG.info("Target Name:", target_name) if "AWS::Lambda::Function" == target_name: return validate_lambda_tracing_config(target_name, request.hookContext.targetModel.get("resourceProperties") ) else: raise exceptions.InvalidRequest(f"Unknown target type: {target_name}") ``` Nach diesem Schritt können Sie den Hook registrieren und ihn so konfigurieren, dass er alle Ereignisse bei der AWS Lambda Funktionserstellung abhört. Ein Entwickler bereitet die IaC-Vorlage (Infrastructure as Code) für einen Serverless-Microservice mithilfe von Lambda vor. Diese Vorbereitung umfasst die Einhaltung interner Standards, gefolgt von lokalen Tests und dem Commit der Vorlage in das Repository. Hier ist ein Beispiel für eine IaC-Vorlage: ``` MyLambdaFunction: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: MyLambdaFunction Code: ZipFile: | import json def handler(event, context): return { 'statusCode': 200, 'body': json.dumps('Hello World!') } Runtime: python3.14 TracingConfig: Mode: PassThrough MemorySize: 256 Timeout: 10 ``` Im Rahmen des CI/CD Prozesses ruft der CloudFormation Dienst bei der Bereitstellung der CloudFormation Vorlage den Hook vor der Erstellung und Aktualisierung unmittelbar vor der Bereitstellung des Ressourcentyps auf. `AWS::Lambda::Function` Der Hook verwendet AWS Config Regeln, die im proaktiven Modus ausgeführt werden, um zu überprüfen, ob die Lambda-Funktionskonfiguration die vorgeschriebene Ablaufverfolgungskonfiguration enthält. Die Antwort des Hooks bestimmt den nächsten Schritt. Bei Einhaltung der Vorschriften signalisiert der Hook den Erfolg und CloudFormation fährt mit der Bereitstellung der Ressourcen fort. Wenn nicht, schlägt die CloudFormation Stack-Bereitstellung fehl, die Pipeline wird sofort gestoppt und das System zeichnet die Details zur späteren Überprüfung auf. An die relevanten Stakeholder werden Compliance-Benachrichtigungen gesendet. Sie finden die success/fail Hook-Informationen in der CloudFormation Konsole: ![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-2.png) Wenn Sie Logs für Ihren CloudFormation Hook aktiviert haben, können Sie das Ergebnis der Hook-Auswertung erfassen. Hier ist ein Beispielprotokoll für einen Hook mit dem Status „Fehlgeschlagen“, was darauf hinweist, dass für die Lambda-Funktion X-Ray nicht aktiviert ist: ![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-3.png) Hat der Entwickler entschieden, die IaC so zu ändern, dass der Wert `TracingConfig Mode` in `Active` aktualisiert wird und die Bereitstellung erneut erfolgt, wird der Hook erfolgreich ausgeführt und der Stack fährt mit der Erstellung der Lambda-Ressource fort. ![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-4.png) Auf diese Weise können Sie präventive Kontrollen AWS Config im proaktiven Modus implementieren, wenn Sie serverlose Ressourcen in Ihren AWS Konten entwickeln und bereitstellen. Durch die Integration von AWS Config Regeln in die CI/CD Pipeline können Sie nicht konforme Ressourcenbereitstellungen identifizieren und optional blockieren, z. B. Lambda-Funktionen, denen eine aktive Ablaufverfolgungskonfiguration fehlt. Dadurch wird sichergestellt, dass nur Ressourcen in Ihren Umgebungen eingesetzt werden, die den neuesten Governance-Richtlinien entsprechen. AWS # Erkennen Sie nicht konforme Lambda-Bereitstellungen und -Konfigurationen mit AWS Config Neben der [proaktiven Bewertung](governance-config.md) 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 für 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: ![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-detective-1.png) ## 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](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html) 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: + **Regelname:** Der Name der Regel im Beispiel lautet `desiredlayer`. + **Bedingung:** Diese Klausel gibt die Bedingung an, unter der die Regel überprüft werden soll. Im angegebenen Beispiel lautet die Bedingung `configuration.layers !empty`. Das bedeutet, dass die Ressource nur ausgewertet werden sollte, wenn die `layers`-Eigenschaft in der Konfiguration nicht leer ist. + **Assertion:** Nach der `when`-Klausel bestimmt die Assertion, was die Regel überprüft. Die Assertion `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` prüft, ob eine der Lambda-Schichten ARNs nicht mit dem `OldLayerArn` Wert übereinstimmt. Wenn es keine Übereinstimmung gibt, ist die Assertion wahr und die Regel gilt als bestanden. Andernfalls schlägt sie fehl. `CONFIG_RULE_PARAMETERS`ist 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](https://aws.amazon.com/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 Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) 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: ![\[Query results in Athena console.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-detective-2.png) Wenn die AWS Config Daten unternehmensweit aggregiert sind, können Sie dann mit [Amazon Quick](https://aws.amazon.com/quicksight/) ein Dashboard erstellen. Indem Sie Ihre Athena-Ergebnisse in Quick importieren, können Sie visualisieren, 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](#governance-config-detective-implement) beschrieben. Die folgende Abbildung zeigt ein Beispiel-Dashboard, in dem die Verteilung der Layer-Versionen auf Funktionen innerhalb der Organisation aufgeschlüsselt ist. ![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-config-detective-3.png) ## Phase 3: Implementierung und Durchsetzung Sie können Ihre Layer-Versionsregel, die Sie in [Phase 1](#governance-config-detective-identify) 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 die [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)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. # Lambda-Codesignatur mit AWS Signer [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) ist ein vollständig verwalteter Codesignaturdienst, mit dem Sie Ihren Code anhand einer digitalen Signatur validieren können, um sicherzustellen, dass er unverändert ist und von einem vertrauenswürdigen Publisher stammt. AWS Signer kann in Verbindung mit AWS Lambda verwendet werden, um vor der Implementierung in Ihren AWS-Umgebungen zu prüfen, ob Funktionen und Layer unverändert sind. Ihr Unternehmen bleibt so vor böswilligen Akteuren geschützt, die sich möglicherweise Zugangsdaten verschafft haben, um neue Funktionen zu entwickeln oder bestehende Funktionen zu verändern. Um die Codesignatur für Ihre Lambda-Funktionen einzurichten, erstellen Sie zunächst einen S3-Bucket mit aktivierter Versionierung. Erstellen Sie anschließend ein Signaturprofil mit AWS Signer, geben Sie Lambda als Plattform und die Gültigkeitsdauer des Signaturprofils in Tagen an. Beispiel: ``` Signer: Type: AWS::Signer::SigningProfile Properties: PlatformId: AWSLambda-SHA384-ECDSA SignatureValidityPeriod: Type: DAYS Value: !Ref pValidDays ``` Verwenden Sie dann das Signaturprofil und erstellen Sie eine Signaturkonfiguration mit Lambda. Legen Sie fest, was geschehen soll, wenn in der Signaturkonfiguration ein Artefakt erkannt wird, das nicht mit der erwarteten digitalen Signatur übereinstimmt: warnen (aber die Bereitstellung zulassen) oder erzwingen (und die Bereitstellung blockieren). Das folgende Beispiel ist für Erzwingen und Bereitstellungen blockieren konfiguriert. ``` SigningConfig: Type: AWS::Lambda::CodeSigningConfig Properties: AllowedPublishers: SigningProfileVersionArns: - !GetAtt Signer.ProfileVersionArn CodeSigningPolicies: UntrustedArtifactOnDeployment: Enforce ``` Sie haben AWS Signer mit Lambda jetzt so konfiguriert, dass nicht vertrauenswürdige Bereitstellungen blockiert werden. Nehmen wir an, Sie haben eine Feature-Anfrage fertig programmiert und sind nun bereit, die Funktion bereitzustellen. Der erste Schritt besteht darin, den Code mit den entsprechenden Abhängigkeiten zu komprimieren und dann das Artefakt mit dem von Ihnen erstellten Signaturprofil zu signieren. Sie können dies tun, indem Sie das ZIP-Artefakt in den S3-Bucket hochladen und dann einen Signaturauftrag starten. ``` aws signer start-signing-job \ --source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \ --destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \ --profile-name your-signer-id ``` Das Ergebnis ist eine Ausgabe wie die folgende, wobei `jobId` das Objekt ist, das im Ziel-Bucket und Präfix erstellt wurde, und `jobOwner` die 12-stellige AWS-Konto-ID, unter der der Auftrag ausgeführt wurde. ``` { "jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388", "jobOwner": "111122223333" } ``` Jetzt können Sie Ihre Funktion mithilfe des signierten S3-Objekts und der von Ihnen erstellten Codesignatur-Konfiguration bereitstellen. ``` Fn: Type: AWS::Serverless::Function Properties: CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip Handler: fn.handler Role: !GetAtt FnRole.Arn CodeSigningConfigArn: !Ref pSigningConfigArn ``` Sie können eine Funktionsbereitstellung alternativ mit dem ursprünglichen unsignierten Quell-ZIP-Artefakt testen. Die Bereitstellung sollte mit der folgenden Fehlermeldung fehlschlagen: ``` Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned. ``` Wenn Sie Ihre Funktionen mithilfe von AWS Serverless Application Model (AWS SAM) erstellen und bereitstellen, übernimmt der Paketbefehl das Hochladen des ZIP-Artefakts auf S3 und startet auch den Signaturauftrag und ruft das signierte Artefakt ab. Verwenden Sie dazu den folgenden Befehl mit diesen Parametern: ``` sam package -t your-template.yaml \ --output-template-file your-output.yaml \ --s3-bucket your-versioned-bucket \ --s3-prefix your-prefix \ --signing-profiles your-signer-id ``` Mit AWS Signer können Sie überprüfen, ob ZIP-Artefakte, die in Ihren Konten bereitgestellt werden, vertrauenswürdig sind. Sie können den oben genannten Prozess in Ihre CI/CD-Pipelines aufnehmen und verlangen, dass allen Funktionen eine Codesignatur-Konfiguration zugewiesen ist. Verwenden Sie dabei die in den vorherigen Themen beschriebenen Techniken. Durch die Verwendung einer Codesignatur bei der Bereitstellung von Lambda-Funktionen verhindern Sie, dass böswillige Akteure, die möglicherweise Anmeldeinformationen für die Erstellung oder Änderung von Funktionen erhalten haben, bösartigen Code in Ihre Funktionen einschleusen. # Automatisieren Sie Sicherheitsbewertungen für Lambda mit Amazon Inspector [Amazon Inspector](https://aws.amazon.com/inspector/) ist ein automatisierter Schwachstellen-Management-Service, der Workloads kontinuierlich auf bekannte Softwareschwachstellen und unbeabsichtigte Netzwerkfreigabe durchsucht. Amazon Inspector erstellt einen Bericht, der die Schwachstelle beschreibt, die betroffene Ressource identifiziert, den Schweregrad der Schwachstelle bewertet und Hilfestellung zur Behebung gibt. Amazon Inspector bietet eine kontinuierliche, automatisierte Schwachstellenanalyse für Lambda-Funktionen und -Layer. Amazon Inspector stellt zwei Scantypen für Lambda bereit: + **Lambda-Standardscan (Standard)**: Scannt Anwendungsabhängigkeiten innerhalb einer Lambda-Funktion und ihrer Layer auf [Paketschwachstellen](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package). + **Lambda-Codescan**: Scannt den benutzerdefinierten Anwendungscode in Funktionen und Layern auf [Code-Schwachstellen](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code). Sie können entweder den Lambda-Standardscan einzeln oder zusammen mit dem Lambda-Codescan aktivieren. Um Amazon Inspector zu aktivieren, navigieren Sie zur [Amazon-Inspector-Konsole](https://console.aws.amazon.com/inspector/), erweitern Sie den Bereich **Einstellungen** und wählen Sie **Kontoverwaltung**. Wählen Sie auf der Registerkarte **Konten** die Option **Aktivieren** und wählen Sie dann eine der Scanoptionen aus. Sie können Amazon Inspector für mehrere Konten aktivieren und bei der Einrichtung von Amazon Inspector die Berechtigungen zur Verwaltung von Amazon Inspector für die Organisation an bestimmte Konten delegieren. Während der Aktivierung müssen Sie Amazon Inspector Berechtigungen erteilen, indem Sie die folgende Rolle erstellen: `AWSServiceRoleForAmazonInspector2`. In der Amazon-Inspector-Konsole können Sie diese Rolle mit einem Klick erstellen. Beim Lambda-Standardscan initiiert Amazon Inspector Schwachstellenscans von Lambda-Funktionen in den folgenden Situationen: + Sobald Amazon Inspector eine bestehende Lambda-Funktion entdeckt. + Wenn Sie eine neue Lambda-Funktion bereitstellen. + Wenn Sie ein Update für den Anwendungscode oder die Abhängigkeiten einer vorhandenen Lambda-Funktion oder ihrer Layer bereitstellen. + Immer wenn Amazon Inspector seiner Datenbank ein neues CVE-Element (Common Vulnerabilities and Exposures) hinzufügt und dieses CVE für Ihre Funktion relevant ist. Beim Lambda-Codescan wertet Amazon Inspector Ihren Lambda-Funktionscode mithilfe von Automated Reasoning und Machine Learning aus. Dabei wird der Anwendungscode auf die allgemeine Einhaltung der Sicherheitsregeln hin analysiert. Wenn Amazon Inspector eine Sicherheitslücke in Ihrem Anwendungscode für Lambda-Funktionen entdeckt, erstellt Amazon Inspector einen detaillierten **Schwachstellenbericht für den Code**. Eine Liste möglicher Schwachstellen finden Sie in der [Amazon CodeGuru Detector Library](https://docs.aws.amazon.com/codeguru/detector-library/). Rufen Sie die [Amazon-Inspector-Konsole](https://console.aws.amazon.com/inspector/) auf, um die Berichte einzusehen. Wählen Sie im Menü **Funde** die Option **Nach Lambda-Funktion**, um die Ergebnisse der Sicherheitsscans anzuzeigen, die für Lambda-Funktionen durchgeführt wurden. Um eine Lambda-Funktion vom Standardscan auszuschließen, kennzeichnen Sie die Funktion mit dem folgenden Schlüssel-Wert-Paar: + `Key:InspectorExclusion` + `Value:LambdaStandardScanning` Um eine Lambda-Funktion von Codescans auszuschließen, kennzeichnen Sie die Funktion mit dem folgenden Schlüssel-Wert-Paar: + `Key:InspectorCodeExclusion` + `Value:``LambdaCodeScanning` Wie in der folgenden Abbildung dargestellt, erkennt Amazon Inspector Schwachstellen automatisch und kategorisiert die Funde beispielsweise als **Codeschwachstelle**. Das deutet darauf hin, dass sich die Schwachstelle im Funktionscode befindet und nicht in einer der codeabhängigen Bibliotheken. Sie können diese Details für eine bestimmte Funktion oder mehrere Funktionen gleichzeitig einsehen. ![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-code-scanning-1.png) Sie können jeden Befund eingehend untersuchen und erfahren, wie Sie das Problem beheben können. ![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-code-scanning-2.png) Achten Sie bei der Verwendung von Lambda-Funktionen darauf, dass Sie die Namenskonventionen einhalten. Weitere Informationen finden Sie unter [Arbeiten mit Lambda-Umgebungsvariablen](configuration-envvars.md). Sie sind für die Lösungsvorschläge verantwortlich, die Sie akzeptieren. Lesen Sie sich die Lösungsvorschläge immer durch, bevor Sie sie annehmen. Möglicherweise müssen Sie Anpassungen an den Lösungsvorschlägen vornehmen, damit Ihr Code am Ende auch das tut, was Sie beabsichtigt haben. # Implementieren von Beobachtbarkeit für Lambda-Sicherheit und -Compliance AWS Config ist ein nützliches Tool, um nicht konforme serverlose AWS Ressourcen zu finden und zu reparieren. Jede Änderung, die Sie an Ihren serverlosen Ressourcen vornehmen, wird in aufgezeichnet. AWS Config AWS Config Ermöglicht es Ihnen außerdem, Konfigurations-Snapshot-Daten auf S3 zu speichern. Sie können Amazon Athena und Amazon Quick verwenden, um Dashboards zu erstellen und Daten anzuzeigen AWS Config . In [Erkennen Sie nicht konforme Lambda-Bereitstellungen und -Konfigurationen mit AWS Config](governance-config-detection.md) haben wir besprochen, wie sich bestimmte Konfigurationen wie Lambda-Layer visualisieren lassen. Dieses Thema erweitert diese Konzepte. ## Abrufen von Informationen zu Lambda-Konfigurationen Sie können Abfragen verwenden, um wichtige Konfigurationen wie AWS-Konto ID, Region, AWS X-Ray Ablaufverfolgungskonfiguration, VPC-Konfiguration, Speichergröße, Laufzeit und Tags abzurufen. Hier ist eine Beispielabfrage, mit der Sie diese Informationen von Athena abrufen können: ``` 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 account_id, tags, 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, '$.runtime') AS version json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig FROM unnested ``` Sie können die Abfrage verwenden, um ein Schnell-Dashboard zu erstellen und die Daten zu visualisieren. Informationen zum Aggregieren von AWS Ressourcenkonfigurationsdaten, zum Erstellen von Tabellen in Athena und zum Erstellen von Schnell-Dashboards mit den Daten von Athena finden Sie unter [Visualisieren von AWS Config Daten mit Athena und Amazon Quick](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/) im Blog AWS Cloud Operations and Management. Diese Abfrage ruft auch Tag-Informationen für die Funktionen ab. Dies ermöglicht eine genauere Untersuchung Ihrer Workloads und Umgebungen, insbesondere wenn Sie benutzerdefinierte Tags verwenden. ![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-observability-1.png) Weitere Informationen über die Aktionen, die Sie ergreifen können, finden Sie im Abschnitt [Behandlung von Beobachtbarkeitsbefunden](#governance-observability-addressing) weiter unten in diesem Thema. ## Abrufen von Informationen zur Lambda-Konformität Mit den von generierten Daten können Sie Dashboards auf Organisationsebene erstellen AWS Config, um die Einhaltung der Vorschriften zu überwachen. Dies ermöglicht eine konsistente Nachverfolgung und Überwachung von: + Compliance-Paketen nach Konformitätsbewertung + Regeln von nicht konformen Ressourcen + Compliance status (Compliance-Status) ![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-observability-2.png) Überprüfen Sie jede Regel, um Ressourcen zu identifizieren, die für diese Regel nicht konform sind. Wenn Ihre Organisation beispielsweise vorschreibt, dass alle Lambda-Funktionen einer VPC zugeordnet werden müssen, und Sie eine AWS Config Regel zur Konformitätserkennung bereitgestellt haben, können Sie die `lambda-inside-vpc` Regel in der obigen Liste auswählen. ![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-observability-3.png) Weitere Informationen über die Aktionen, die Sie ergreifen können, finden Sie im Abschnitt [Behandlung von Beobachtbarkeitsbefunden](#governance-observability-addressing) weiter unten. ## Transparenz der Lambda-Funktionsgrenzen mithilfe von Security Hub CSPM ![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-observability-4.png) Um sicherzustellen, dass AWS Dienste wie Lambda sicher verwendet werden, AWS wurden die Foundational Security Best Practices v1.0.0 eingeführt. Diese Reihe von bewährten Methoden enthält klare Richtlinien für die Sicherung von Ressourcen und Daten in der AWS Umgebung und unterstreicht, wie wichtig es ist, ein solides Sicherheitsniveau aufrechtzuerhalten. Dies wird durch ein einheitliches Sicherheits- und Compliance-Center AWS Security Hub CSPM ergänzt. Es aggregiert, organisiert und priorisiert Sicherheitserkenntnisse aus verschiedenen AWS Diensten wie Amazon Inspector und Amazon. AWS Identity and Access Management Access Analyzer GuardDuty Wenn Sie Security Hub CSPM, Amazon Inspector und IAM Access Analyzer in Ihrem AWS Unternehmen GuardDuty aktiviert haben, aggregiert Security Hub CSPM automatisch die Ergebnisse dieser Services. Betrachten wir zum Beispiel Amazon Inspector. Mit Security Hub CSPM können Sie Code- und Paketschwachstellen in Lambda-Funktionen effizient identifizieren. Navigieren Sie in der Security Hub CSPM-Konsole zum unteren Abschnitt mit der Bezeichnung **Aktuelle Erkenntnisse aus AWS ** Integrationen. Hier können Sie Ergebnisse aus verschiedenen integrierten Diensten einsehen und analysieren. AWS ![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-observability-5.png) Für Details klicken Sie in der zweiten Spalte auf den Link **Befunde anzeigen**. Daraufhin wird eine nach Produkten gefilterte Liste mit Ergebnissen angezeigt, z. B. Amazon Inspector. Um Ihre Suche auf Lambda-Funktionen zu beschränken, setzen Sie `ResourceType` auf `AwsLambdaFunction`. Nun werden Ergebnisse von Amazon Inspector zu Lambda-Funktionen angezeigt. ![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/governance-observability-6.png) Denn GuardDuty Sie können verdächtige Muster im Netzwerkverkehr identifizieren. Solche Anomalien könnten auf die Existenz von potenziell bösartigem Code in Ihrer Lambda-Funktion hindeuten. Mit IAM Access Analyzer können Sie Richtlinien überprüfen, insbesondere solche mit Bedingungsanweisungen, die externen Entitäten Funktionszugriff gewähren. Darüber hinaus bewertet IAM Access Analyzer die Berechtigungen, die bei der Verwendung des [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)Vorgangs in der Lambda-API zusammen mit einem festgelegt wurden. `EventSourceToken` ## Behandlung von Beobachtbarkeitsbefunden Angesichts der vielfältigen Konfigurationen, die für Lambda-Funktionen möglich sind, und ihrer unterschiedlichen Anforderungen ist eine standardisierte Automatisierungslösung für die Problembehebung möglicherweise nicht für jede Situation geeignet. Darüber hinaus werden Änderungen in den verschiedenen Umgebungen unterschiedlich implementiert. Wenn Sie auf eine Konfiguration stoßen, die nicht konform zu sein scheint, beachten Sie die folgenden Richtlinien: 1. **Strategie zur Kennzeichnung** Wir empfehlen die Implementierung einer umfassenden Kennzeichnungsstrategie. Jede Lambda-Funktion sollte mit folgenden Schlüsselinformationen gekennzeichnet sein: + **Eigentümer:** Die Person oder das Team, die für die Funktion verantwortlich ist. + **Umgebung:** Produktion, Staging, Entwicklung oder Sandbox. + **Anwendung:** Der breitere Kontext, zu dem diese Funktion gehört, falls zutreffend. 1. **Kontakt zum Eigentümer** Anstatt notwendige Änderungen zu automatisieren (wie die Anpassung der VPC-Konfiguration), sollten Sie sich an die Eigentümer nicht konformer Funktionen (siehe Eigentümer-Tag) wenden und ihnen genügend Zeit geben, um entweder: + nicht konforme Konfigurationen für Lambda-Funktionen anzupassen + eine Erklärung bereitzustellen und eine Ausnahme anzufordern oder die Compliance-Standards anzupassen 1. **Fühen Sie eine Configuration Management Database (CMDB)** Tags können zwar unmittelbar Kontext liefern, eine zentralisierte CMDB kann jedoch genauere Informationen liefern. Die Datenbank kann detaillierte Informationen über jede Lambda-Funktion, ihre Abhängigkeiten und andere wichtige Metadaten enthalten. Eine CMDB ist eine unschätzbare Ressource für Audits, Konformitätsprüfungen und die Identifizierung der Eigentümer einer Funktion. Da sich Serverless-Infrastrukturen kontinuierlich weiterentwickeln, ist es wichtig, Überwachungsmaßnahmen proaktiv zu organisieren. Mit Tools wie AWS Config Security Hub CSPM und Amazon Inspector können potenzielle Anomalien oder nicht konforme Konfigurationen schnell identifiziert werden. Tools allein können jedoch keine vollständige Konformität oder optimale Konfigurationen gewährleisten. Es ist wichtig, diese Tools mit gut dokumentierten Prozessen und bewährten Verfahren zu kombinieren. + **Feedback-Schleife:** Sobald Korrekturmaßnahmen ergriffen werden, sollten Sie sicherstellen, dass es eine Feedback-Schleife gibt. Dabei werden nicht konforme Ressourcen regelmäßig überprüft, um zu ermitteln, ob sie aktualisiert wurden oder immer noch dieselben Probleme haben. + **Dokumentation:** Beobachtungen, Maßnahmen und alle gewährten Ausnahmen sollten immer dokumentiert werden. Eine ordnungsgemäße Dokumentation hilft nicht nur bei Audits, sondern trägt auch dazu bei, den Prozess zu verbessern, um die Compliance und Sicherheit dauerhaft zu stärken. + **Schulung und Sensibilisierung:** Alle Beteiligten, insbesondere die Eigentümer der Lambda-Funktionen, sollten regelmäßig geschult und über bewährte Verfahren, Unternehmensrichtlinien und Compliance-Vorschriften informiert werden. Regelmäßige Workshops, Webinare oder Schulungen können einen großen Beitrag dazu leisten, dass alle Beteiligten bezüglich Sicherheit und Compliance auf dem gleichen Stand sind. Zusammenfassend lässt sich sagen, dass Tools und Technologien zwar die Erkennung und Meldung von potenziellen Problemen unterstützen, der Faktor Mensch –Verständnis, Kommunikation, Schulung und Dokumentation – aber weiterhin von zentraler Bedeutung ist. Beides zusammen ergibt eine leistungsstarke Kombination, um sicherzustellen, dass Ihre Lambda-Funktionen und die größere Infrastruktur konform, sicher und für Ihre Geschäftsanforderungen optimiert sind.