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.
# Sicherheit in AWS Lambda
Cloud-Sicherheit AWS hat höchste Priorität. Als AWS Kunde profitieren Sie von einer Rechenzentrums- und Netzwerkarchitektur, die darauf ausgelegt sind, die Anforderungen der sicherheitssensibelsten Unternehmen zu erfüllen.
Sicherheit ist eine gemeinsame Verantwortung von Ihnen AWS und Ihnen. Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) beschreibt dies als Sicherheit *der* Cloud und Sicherheit *in* der Cloud:
+ **Sicherheit der Cloud** — AWS ist verantwortlich für den Schutz der Infrastruktur, die AWS-Services in der AWS Cloud läuft. AWS bietet Ihnen auch Dienste, die Sie sicher nutzen können. Auditoren von Drittanbietern testen und überprüfen die Effektivität unserer Sicherheitsmaßnahmen im Rahmen der [AWS -Compliance-Programme](https://aws.amazon.com/compliance/programs/) regelmäßig. Weitere Informationen zu den Compliance-Programmen, die für gelten AWS Lambda, finden Sie [AWS-Services unter Umfang nach Compliance-Programmen](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicherheit in der Cloud** – Ihr Verantwortungsumfang wird durch den AWS -Dienst bestimmt, den Sie verwenden. Sie sind auch für andere Faktoren verantwortlich, etwa für die Vertraulichkeit Ihrer Daten, für die Anforderungen Ihres Unternehmens und für die geltenden Gesetze und Vorschriften.
Diese Dokumentation erläutert, wie das Modell der geteilten Verantwortung bei der Verwendung von Lambda zum Tragen kommt. Die folgenden Themen veranschaulichen, wie Sie Lambda zur Erfüllung Ihrer Sicherheits- und Compliance-Ziele konfigurieren können. Sie lernen auch, wie Sie andere verwenden können AWS-Services , die Ihnen helfen, Ihre Lambda-Ressourcen zu überwachen und zu sichern.
Weitere Informationen zur Anwendung von Sicherheitsprinzipien auf Lambda-Anwendungen finden Sie bei Serverless Land unter [Sicherheit](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops).
**Topics**
+ [
# Datenschutz in AWS Lambda
](security-dataprotection.md)
+ [
# Verwenden von serviceverknüpften Rollen für Lambda
](using-service-linked-roles.md)
+ [
# Identity and Access Management für AWS Lambda
](security-iam.md)
+ [
# Erstellen Sie eine Governance-Strategie für Lambda-Funktionen und -Layer
](governance-concepts.md)
+ [
# Compliance-Validierung für AWS Lambda
](security-compliance.md)
+ [
# Ausfallsicherheit in AWS Lambda
](security-resilience.md)
+ [
# Sicherheit der Infrastruktur in AWS Lambda
](security-infrastructure.md)
+ [
# Sicherung von Workloads mit öffentlichen Endpunkten
](security-public-endpoints.md)
+ [
# Verwendung von Codesignatur zur Überprüfung der Codeintegrität mit Lambda
](configuration-codesigning.md)
# Datenschutz in AWS Lambda
Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) von AWS gilt für den Datenschutz in AWS Lambda. Wie in diesem Modell beschrieben, ist AWS verantwortlich für den Schutz der globalen Infrastruktur, in der die gesamte AWS Cloud ausgeführt wird. Sie sind dafür verantwortlich, die Kontrolle über Ihre in dieser Infrastruktur gehosteten Inhalte zu behalten. Sie sind auch für die Sicherheitskonfiguration und die Verwaltungsaufgaben für die von Ihnen verwendeten AWS-Services verantwortlich. Weitere Informationen zum Datenschutz finden Sie unter [Häufig gestellte Fragen zum Datenschutz](https://aws.amazon.com/compliance/data-privacy-faq/). Informationen zum Datenschutz in Europa finden Sie im Blog-Beitrag [AWS-Modell der geteilten Verantwortung und in der DSGVO](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) im *AWS-Sicherheitsblog*.
Aus Datenschutzgründen empfehlen wir, AWS-Konto-Anmeldeinformationen zu schützen und einzelne Benutzer mit AWS IAM Identity Center oder AWS Identity and Access Management (IAM) einzurichten. So erhält jeder Benutzer nur die Berechtigungen, die zum Durchführen seiner Aufgaben erforderlich sind. Außerdem empfehlen wir, die Daten mit folgenden Methoden schützen:
+ Verwenden Sie für jedes Konto die Multi-Faktor-Authentifizierung (MFA).
+ Verwenden Sie SSL/TLS für die Kommunikation mit AWS-Ressourcen. Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Richten Sie die API und die Protokollierung von Benutzeraktivitäten mit AWS CloudTrail ein. Informationen zur Verwendung von CloudTrail-Trails zur Erfassung von AWS-Aktivitäten finden Sie unter [Arbeiten mit CloudTrail-Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) im *AWS CloudTrail-Benutzerhandbuch*.
+ Verwenden Sie AWS-Verschlüsselungslösungen zusammen mit allen Standardsicherheitskontrollen in AWS-Services.
+ Verwenden Sie erweiterte verwaltete Sicherheitsservices wie Amazon Macie, die dabei helfen, in Amazon S3 gespeicherte persönliche Daten zu erkennen und zu schützen.
+ Wenn Sie für den Zugriff auf AWS über eine Befehlszeilenschnittstelle oder über eine API FIPS 140-3-validierte kryptografische Module benötigen, verwenden Sie einen FIPS-Endpunkt. Weitere Informationen über verfügbare FIPS-Endpunkte finden Sie unter [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Wir empfehlen dringend, in Freitextfeldern, z. B. im Feld **Name**, keine vertraulichen oder sensiblen Informationen wie die E-Mail-Adressen Ihrer Kunden einzugeben. Dies gilt auch, wenn Sie mit Lambda oder anderen AWS-Services über die Konsole, API, AWS CLI oder AWS-SDKs arbeiten. Alle Daten, die Sie in Tags oder Freitextfelder eingeben, die für Namen verwendet werden, können für Abrechnungs- oder Diagnoseprotokolle verwendet werden. Wenn Sie eine URL für einen externen Server bereitstellen, empfehlen wir dringend, keine Anmeldeinformationen zur Validierung Ihrer Anforderung an den betreffenden Server in die URL einzuschließen.
**Topics**
+ [
## Verschlüsselung während der Übertragung
](#security-privacy-intransit)
+ [
# Verschlüsselung der Daten im Ruhezustand für AWS Lambda
](security-encryption-at-rest.md)
## Verschlüsselung während der Übertragung
Lambda-API-Endpunkte unterstützen ausschließlich sichere Verbindungen über HTTPS. Wenn Sie Lambda-Ressourcen mit der AWS-Managementkonsole, dem AWS SDK oder der Lambda-API verwalten, wird die gesamte Kommunikation mit Transport Layer Security (TLS) verschlüsselt. Eine vollständige Liste der API-Endpunkte finden Sie unter [AWSRegionen und Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html) in Allgemeine AWS-Referenz.
Wenn Sie [Ihre Funktion mit einem Dateisystem verbinden](configuration-filesystem.md), verwendet Lambda Verschlüsselung während der Übertragung für alle Verbindungen. Weitere Informationen finden Sie unter [Datenverschlüsselung in Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/encryption.html) im *Benutzerhandbuch zu Amazon Elastic File System*.
Wenn Sie [Umgebungsvariablen](configuration-envvars.md) verwenden, können Sie Konsolenverschlüsselungshelfer aktivieren, um die clientseitige Verschlüsselung zu verwenden, um die Umgebungsvariablen während der Übertragung zu schützen. Weitere Informationen finden Sie unter [Sicherung von Lambda-Umgebungsvariablen](configuration-envvars-encryption.md).
# Verschlüsselung der Daten im Ruhezustand für AWS Lambda
Lambda bietet immer Verschlüsselung im Ruhezustand für die folgenden Ressourcen mit einem [AWS-eigener Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) oder einem [Von AWS verwalteter Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk):
+ Umgebungsvariablen
+ Dateien, die Sie zu Lambda hochladen, einschließlich Bereitstellungspakete und Ebenenarchive
+ Objekte mit Filterkriterien für die Zuordnung von Ereignisquellen
Sie können Lambda optional so konfigurieren, dass es einen vom Kunden verwalteten Schlüssel verwendet, um Ihre [Umgebungsvariablen](configuration-envvars-encryption.md), [.zip-Bereitstellungspakete](encrypt-zip-package.md) und [Filterkriterienobjekte](invocation-eventfiltering.md#filter-criteria-encryption) zu verschlüsseln.
Amazon CloudWatch Logs und AWS X-Ray verschlüsseln Daten darüber hinaus standardmäßig und können für die Verwendung kundenverwalteter Schlüssel konfiguriert werden. Details hierzu finden Sie unter [Verschlüsseln von Protokolldaten in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html) und [Datenschutz in AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html).
## Überwachen Ihrer Verschlüsselungsschlüssel für Lambda
Wenn Sie einen von AWS KMS-Kunden verwalteten Schlüssel mit Lambda verwenden, können Sie [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) verwenden. Die folgenden Beispiele sind CloudTrail-Ereignisse für `Decrypt`-, `DescribeKey`- und `GenerateDataKey`-Aufrufe von Lambda, um auf Daten zuzugreifen, die mit Ihrem vom Kunden verwalteten Schlüssel verschlüsselt sind.
------
#### [ Decrypt ]
Wenn Sie einen vom Kunden verwalteten AWS KMS-Schlüssel verwendet haben, um Ihr [Filterkriterien](invocation-eventfiltering.md#filter-criteria-encryption)objekt zu verschlüsseln, sendet Lambda in Ihrem Namen eine `Decrypt`-Anforderung, wenn Sie versuchen, im Klartext darauf zuzugreifen (z. B. über einen `ListEventSourceMappings`-Aufruf). Das folgende Beispielereignis zeichnet den Vorgang `Decrypt` auf:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:05:46Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
```
------
#### [ DescribeKey ]
Wenn Sie einen vom Kunden verwalteten AWS KMS-Schlüssel verwendet haben, um Ihr [Filterkriterien](invocation-eventfiltering.md#filter-criteria-encryption)objekt zu verschlüsseln, sendet Lambda in Ihrem Namen eine `DescribeKey`-Anforderung, wenn Sie versuchen, darauf zuzugreifen (z. B. über einen `GetEventSourceMapping`-Aufruf). Das folgende Beispielereignis zeichnet den Vorgang `DescribeKey` auf:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:45:23Z",
"mfaAuthenticated": "false"
}
}
},
"eventTime": "2024-05-30T01:09:40Z",
"eventSource": "kms.amazonaws.com",
"eventName": "DescribeKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "54.240.197.238",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36",
"requestParameters": {
"keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_256_GCM_SHA384",
"clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com"
},
"sessionCredentialFromConsole": "true"
}
```
------
#### [ GenerateDataKey ]
Wenn Sie einen vom Kunden verwalteten AWS KMS-Schlüssel verwenden, um Ihr [Filterkriterien](invocation-eventfiltering.md#filter-criteria-encryption)objekt in einem `CreateEventSourceMapping`- oder `UpdateEventSourceMapping`-Aufruf zu verschlüsseln, sendet Lambda in Ihrem Namen eine `GenerateDataKey`-Anfrage, um einen Datenschlüssel zur Verschlüsselung der Filterkriterien zu generieren ([Umschlagverschlüsselung](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)). Das folgende Beispielereignis zeichnet den Vorgang `GenerateDataKey` auf:
```
{
"eventVersion": "1.09",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROA123456789EXAMPLE:example",
"arn": "arn:aws:sts::123456789012:assumed-role/role-name/example",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROA123456789EXAMPLE",
"arn": "arn:aws:iam::123456789012:role/role-name",
"accountId": "123456789012",
"userName": "role-name"
},
"attributes": {
"creationDate": "2024-05-30T00:06:07Z",
"mfaAuthenticated": "false"
}
},
"invokedBy": "lambda.amazonaws.com"
},
"eventTime": "2024-05-30T01:04:18Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "eu-west-1",
"sourceIPAddress": "lambda.amazonaws.com",
"userAgent": "lambda.amazonaws.com",
"requestParameters": {
"numberOfBytes": 32,
"keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"encryptionContext": {
"aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==",
"aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source",
"aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function"
},
},
"responseElements": null,
"requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
------
# Verwenden von serviceverknüpften Rollen für Lambda
Lambda verwendet AWS Identity and Access Management (IAM) [serviceverknüpfte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Rollen. Eine serviceverknüpfte Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Lambda verknüpft ist. Dienstbezogene Rollen sind von Lambda vordefiniert und enthalten Berechtigungen, die der Dienst benötigt, um andere AWS Dienste in Ihrem Namen aufzurufen.
Lambda definiert die Berechtigungen seiner dienstbezogenen Rollen, und nur Lambda kann seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Lambda-Ressourcen, da Sie die Zugriffsberechtigung für die Ressourcen nicht versehentlich entfernen können.
**Informationen zu anderen Diensten, die dienstverknüpfte Rollen unterstützen, finden Sie unter [AWS Dienste, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie in der Spalte Dienstverknüpfte Rollen nach den Diensten, für die **Ja** steht.** Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen.
## Dienstbezogene Rollenberechtigungen für Lambda
Lambda verwendet die mit dem Dienst verknüpfte Rolle namens. **AWSServiceRoleForLambda** Die serviceverknüpfte Rolle vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `lambda.amazonaws.com`
Die genannte Rollenberechtigungsrichtlinie AWSLambda ServiceRolePolicy ermöglicht es Lambda, die folgenden Aktionen für die angegebenen Ressourcen durchzuführen:
+ Aktion: `ec2:TerminateInstances` aktiviert `arn:aws:ec2:*:*:instance/*` mit der Bedingung, die entspricht `ec2:ManagedResourceOperator` `scaler.lambda.amazonaws.com`
+ Aktion: `ec2:DescribeInstanceStatus` und `ec2:DescribeInstances` auf `*`
Sie müssen Berechtigungen konfigurieren, damit eine Benutzer, Gruppen oder Rollen eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen können. Weitere Informationen finden Sie unter [serviceverknüpfte Rollenberechtigung](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
Informationen zu verwalteten Richtlinienaktualisierungen finden Sie unter [Verwaltete Lambda-Richtlinien](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates).
## Eine serviceverknüpfte Rolle für Lambda erstellen
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie einen Lambda-Kapazitätsanbieter in der AWS-Managementkonsole, der oder der AWS API erstellen AWS CLI, erstellt Lambda die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie einen Lambda-Kapazitätsanbieter erstellen, erstellt Lambda die serviceverknüpfte Rolle erneut für Sie.
Sie können auch die IAM-Konsole verwenden, um eine serviceverknüpfte Rolle mit dem Anwendungsfall zu erstellen. **AWSServiceRoleForLambda** Erstellen Sie in der AWS CLI oder der AWS API eine dienstverknüpfte Rolle mit dem `lambda.amazonaws.com` Dienstnamen. Weitere Informationen finden Sie unter [Erstellen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role) im *IAM-Benutzerhandbuch*. Wenn Sie diese serviceverknüpfte Rolle löschen, können Sie mit demselben Verfahren die Rolle erneut erstellen.
## Bearbeiten einer serviceverknüpften Rolle für Lambda
Lambda erlaubt Ihnen nicht, die AWSService RoleForLambda serviceverknüpfte Rolle zu bearbeiten. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer serviceverknüpften Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Lambda
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch die Ressourcen für Ihre serviceverknüpften Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
**Anmerkung**
Wenn der Lambda-Dienst die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt das Löschen möglicherweise fehl. Wenn dies passiert, warten Sie einige Minuten und versuchen Sie es erneut.
**Um Lambda-Ressourcen zu löschen, die von der AWSService RoleForLambda**
1. Entfernen Sie alle Lambda-Kapazitätsanbieter aus Ihrem Konto. Sie können dies mit der Lambda-Konsole, CLI oder API tun.
1. Stellen Sie sicher, dass in Ihrem Konto keine Lambda-Kapazitätsanbieter mehr vorhanden sind, bevor Sie versuchen, die serviceverknüpfte Rolle zu löschen.
**So löschen Sie die serviceverknüpfte Rolle mit IAM**
Verwenden Sie die IAM-Konsole, die oder die AWS API AWS CLI, um die serviceverknüpfte Rolle zu löschen. AWSService RoleForLambda Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Benutzerhandbuch*.
## Unterstützte Regionen für dienstverknüpfte Lambda-Rollen
Lambda unterstützt nicht die Verwendung von dienstbezogenen Rollen in jeder Region, in der der Dienst verfügbar ist. AWSServiceRoleForLambda wird in den folgenden Regionen unterstützt.
| Name der Region | Regions-ID | Support in Lambda |
| --- | --- | --- |
| USA Ost (Nord-Virginia) | us-east-1 | Ja |
| USA Ost (Ohio) | us-east-2 | Ja |
| USA West (Nordkalifornien) | us-west-1 | Ja |
| USA West (Oregon) | us-west-2 | Ja |
| Afrika (Kapstadt) | af-south-1 | Nein |
| Asien-Pazifik (Hongkong) | ap-east-1 | Ja |
| Asien-Pazifik (Jakarta) | ap-southeast-3 | Ja |
| Asien-Pazifik (Bangkok) | ap-southeast-7 | Ja |
| Asien-Pazifik (Mumbai) | ap-south-1 | Ja |
| Asien-Pazifik (Osaka) | ap-northeast-3 | Nein |
| Asien-Pazifik (Seoul) | ap-northeast-2 | Nein |
| Asien-Pazifik (Singapur) | ap-southeast-1 | Ja |
| Asien-Pazifik (Sydney) | ap-southeast-2 | Ja |
| Asien-Pazifik (Tokyo) | ap-northeast-1 | Ja |
| Kanada (Zentral) | ca-central-1 | Nein |
| Europa (Frankfurt) | eu-central-1 | Ja |
| Europa (Ireland) | eu-west-1 | Ja |
| Europa (London) | eu-west-2 | Ja |
| Europa (Milan) | eu-south-1 | Nein |
| Europa (Paris) | eu-west-3 | Nein |
| Europa (Stockholm) | eu-north-1 | Nein |
| Naher Osten (Bahrain) | me-south-1 | Nein |
| Naher Osten (VAE) | me-central-1 | Nein |
| Südamerika (São Paulo) | sa-east-1 | Nein |
| AWS GovCloud (US-Ost) | us-gov-east-1 | Nein |
| AWS GovCloud (US-West) | us-gov-west-1 | Nein |
# Identity and Access Management für AWS Lambda
AWS Identity and Access Management (IAM) hilft einem Administrator AWS-Service , den Zugriff auf AWS Ressourcen sicher zu kontrollieren. IAM-Administratoren steuern, wer *authentifiziert* (angemeldet) und *autorisiert* (Berechtigungen besitzt) ist, um Lambda-Ressourcen zu nutzen. IAM ist ein Programm AWS-Service , das Sie ohne zusätzliche Kosten nutzen können.
**Topics**
+ [
## Zielgruppe
](#security_iam_audience)
+ [
## Authentifizierung mit Identitäten
](#security_iam_authentication)
+ [
## Verwalten des Zugriffs mit Richtlinien
](#security_iam_access-manage)
+ [
# Wie AWS Lambda funktioniert mit IAM
](security_iam_service-with-iam.md)
+ [
# Beispiele für identitätsbasierte Richtlinien für AWS Lambda
](security_iam_id-based-policy-examples.md)
+ [
# AWS verwaltete Richtlinien für AWS Lambda
](security-iam-awsmanpol.md)
+ [
# Problembehandlung bei AWS Lambda Identität und Zugriff
](security_iam_troubleshoot.md)
## Zielgruppe
Wie Sie AWS Identity and Access Management (IAM) verwenden, hängt von Ihrer Rolle ab:
+ **Servicebenutzer** – Fordern Sie von Ihrem Administrator Berechtigungen an, wenn Sie nicht auf Features zugreifen können (siehe [Problembehandlung bei AWS Lambda Identität und Zugriff](security_iam_troubleshoot.md)).
+ **Serviceadministrator** – Bestimmen Sie den Benutzerzugriff und stellen Sie Berechtigungsanfragen (siehe [Wie AWS Lambda funktioniert mit IAM](security_iam_service-with-iam.md)).
+ **IAM-Administrator** – Schreiben Sie Richtlinien zur Zugriffsverwaltung (siehe [Beispiele für identitätsbasierte Richtlinien für AWS Lambda](security_iam_id-based-policy-examples.md)).
## Authentifizierung mit Identitäten
Authentifizierung ist die Art und Weise, wie Sie sich AWS mit Ihren Identitätsdaten anmelden. Sie müssen sich als IAM-Benutzer authentifizieren oder eine IAM-Rolle annehmen. Root-Benutzer des AWS-Kontos
Sie können sich als föderierte Identität anmelden, indem Sie Anmeldeinformationen aus einer Identitätsquelle wie AWS IAM Identity Center (IAM Identity Center), Single Sign-On-Authentifizierung oder Anmeldeinformationen verwenden. Google/Facebook Weitere Informationen zum Anmelden finden Sie unter [So melden Sie sich bei Ihrem AWS-Konto an](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) im *Benutzerhandbuch für AWS-Anmeldung *.
AWS Bietet für den programmatischen Zugriff ein SDK und eine CLI zum kryptografischen Signieren von Anfragen. Weitere Informationen finden Sie unter [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) im *IAM-Benutzerhandbuch*.
### AWS-Konto Root-Benutzer
Wenn Sie einen erstellen AWS-Konto, beginnen Sie mit einer Anmeldeidentität, dem sogenannten AWS-Konto *Root-Benutzer*, der vollständigen Zugriff auf alle AWS-Services Ressourcen hat. Wir raten ausdrücklich davon ab, den Root-Benutzer für Alltagsaufgaben zu verwenden. Eine Liste der Aufgaben, für die Sie sich als Root-Benutzer anmelden müssen, finden Sie unter [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) im *IAM-Benutzerhandbuch*.
### Verbundidentität
Als bewährte Methode sollten menschliche Benutzer für den Zugriff AWS-Services mithilfe temporärer Anmeldeinformationen einen Verbund mit einem Identitätsanbieter verwenden.
Eine *föderierte Identität* ist ein Benutzer aus Ihrem Unternehmensverzeichnis, Ihrem Directory Service Web-Identitätsanbieter oder der AWS-Services mithilfe von Anmeldeinformationen aus einer Identitätsquelle zugreift. Verbundene Identitäten übernehmen Rollen, die temporäre Anmeldeinformationen bereitstellen.
Für die zentrale Zugriffsverwaltung empfehlen wir AWS IAM Identity Center. Weitere Informationen finden Sie unter [Was ist IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
### IAM-Benutzer und -Gruppen
Ein *[IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* ist eine Identität mit bestimmten Berechtigungen für eine einzelne Person oder Anwendung. Wir empfehlen die Verwendung temporärer Anmeldeinformationen anstelle von IAM-Benutzern mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Erfordern, dass menschliche Benutzer den Verbund mit einem Identitätsanbieter verwenden müssen, um AWS mithilfe temporärer Anmeldeinformationen darauf zugreifen zu](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) können.
Eine [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spezifiziert eine Sammlung von IAM-Benutzern und erleichtert die Verwaltung von Berechtigungen für große Gruppen von Benutzern. Weitere Informationen finden Sie unter [Anwendungsfälle für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) im *IAM-Benutzerhandbuch*.
### IAM-Rollen
Eine *[IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* ist eine Identität mit spezifischen Berechtigungen, die temporäre Anmeldeinformationen bereitstellt. Sie können eine Rolle übernehmen, indem Sie [von einer Benutzer- zu einer IAM-Rolle (Konsole) wechseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) AWS CLI oder einen AWS API-Vorgang aufrufen. Weitere Informationen finden Sie unter [Methoden, um eine Rolle zu übernehmen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) im *IAM-Benutzerhandbuch*.
IAM-Rollen sind nützlich für den Verbundbenutzer-Zugriff, temporäre IAM-Benutzerberechtigungen, kontoübergreifenden Zugriff, serviceübergreifenden Zugriff und Anwendungen, die auf Amazon EC2 laufen. Weitere Informationen finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
## Verwalten des Zugriffs mit Richtlinien
Sie kontrollieren den Zugriff, AWS indem Sie Richtlinien erstellen und diese an AWS Identitäten oder Ressourcen anhängen. Eine Richtlinie definiert Berechtigungen, wenn sie mit einer Identität oder Ressource verknüpft sind. AWS bewertet diese Richtlinien, wenn ein Principal eine Anfrage stellt. Die meisten Richtlinien werden AWS als JSON-Dokumente gespeichert. Weitere Informationen zu JSON-Richtliniendokumenten finden Sie unter [Übersicht über JSON-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) im *IAM-Benutzerhandbuch*.
Mit Hilfe von Richtlinien legen Administratoren fest, wer Zugriff auf was hat, indem sie definieren, welches **Prinzipal** welche **Aktionen** auf welchen **Ressourcen**und unter welchen **Bedingungen**durchführen darf.
Standardmäßig haben Benutzer, Gruppen und Rollen keine Berechtigungen. Ein IAM-Administrator erstellt IAM-Richtlinien und fügt sie zu Rollen hinzu, die die Benutzer dann übernehmen können. IAM-Richtlinien definieren Berechtigungen unabhängig von der Methode, die zur Ausführung der Operation verwendet wird.
### Identitätsbasierte Richtlinien
Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität (Benutzer, Gruppe oder Rolle) anfügen können. Diese Richtlinien steuern, welche Aktionen Identitäten für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
Identitätsbasierte Richtlinien können *Inline-Richtlinien* (direkt in eine einzelne Identität eingebettet) oder *verwaltete Richtlinien* (eigenständige Richtlinien, die mit mehreren Identitäten verbunden sind) sein. Informationen dazu, wie Sie zwischen verwalteten und Inline-Richtlinien wählen, finden Sie unter [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) im *IAM-Benutzerhandbuch*.
### Ressourcenbasierte Richtlinien
Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele hierfür sind *Vertrauensrichtlinien für IAM-Rollen* und Amazon S3*-Bucket-Richtlinien*. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
Ressourcenbasierte Richtlinien sind Richtlinien innerhalb dieses Diensts. Sie können AWS verwaltete Richtlinien von IAM nicht in einer ressourcenbasierten Richtlinie verwenden.
### Weitere Richtlinientypen
AWS unterstützt zusätzliche Richtlinientypen, mit denen die maximalen Berechtigungen festgelegt werden können, die durch gängigere Richtlinientypen gewährt werden:
+ **Berechtigungsgrenzen** – Eine Berechtigungsgrenze legt die maximalen Berechtigungen fest, die eine identitätsbasierte Richtlinie einer IAM-Entität erteilen kann. Weitere Informationen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) im *-IAM-Benutzerhandbuch*.
+ **Richtlinien zur Dienstkontrolle (SCPs)** — Geben Sie die maximalen Berechtigungen für eine Organisation oder Organisationseinheit in an AWS Organizations. Weitere Informationen finden Sie unter [Service-Kontrollrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations -Benutzerhandbuch*.
+ **Richtlinien zur Ressourcenkontrolle (RCPs)** — Legen Sie die maximal verfügbaren Berechtigungen für Ressourcen in Ihren Konten fest. Weitere Informationen finden Sie im *AWS Organizations Benutzerhandbuch* unter [Richtlinien zur Ressourcenkontrolle (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html).
+ **Sitzungsrichtlinien** – Sitzungsrichtlinien sind erweiterte Richtlinien, die als Parameter übergeben werden, wenn Sie eine temporäre Sitzung für eine Rolle oder einen Verbundbenutzer erstellen. Weitere Informationen finden Sie unter [Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) im *IAM-Benutzerhandbuch*.
### Mehrere Richtlinientypen
Wenn für eine Anfrage mehrere Arten von Richtlinien gelten, sind die daraus resultierenden Berechtigungen schwieriger zu verstehen. Informationen darüber, wie AWS bestimmt wird, ob eine Anfrage zulässig ist, wenn mehrere Richtlinientypen betroffen sind, finden Sie unter [Bewertungslogik für Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) im *IAM-Benutzerhandbuch*.
# Wie AWS Lambda funktioniert mit IAM
Bevor Sie IAM zum Verwalten des Zugriffs auf Lambda verwenden, erfahren Sie, welche IAM-Features Sie mit Lambda verwenden können.
| IAM-Feature | Lambda-Unterstützung |
| --- | --- |
| [Identitätsbasierte Richtlinien](#security_iam_service-with-iam-id-based-policies) | Ja |
| [Ressourcenbasierte Richtlinien](#security_iam_service-with-iam-resource-based-policies) | Ja |
| [Richtlinienaktionen](#security_iam_service-with-iam-id-based-policies-actions) | Ja |
| [Richtlinienressourcen](#security_iam_service-with-iam-id-based-policies-resources) | Ja |
| [Richtlinienbedingungsschlüssel (servicespezifisch)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Ja |
| [ACLs](#security_iam_service-with-iam-acls) | Nein |
| [ABAC (Tags in Richtlinien)](#security_iam_service-with-iam-tags) | Teilweise |
| [Temporäre Anmeldeinformationen](#security_iam_service-with-iam-roles-tempcreds) | Ja |
| [Forward Access Sessions (FAS)](#security_iam_service-with-iam-principal-permissions) | Nein |
| [Servicerollen](#security_iam_service-with-iam-roles-service) | Ja |
| [Service-verknüpfte Rollen](#security_iam_service-with-iam-roles-service-linked) | Teilweise |
*Einen allgemeinen Überblick darüber, wie Lambda und andere AWS Dienste mit den meisten IAM-Funktionen funktionieren, finden Sie im [AWS IAM-Benutzerhandbuch unter Dienste, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
## Identitätsbasierte Richtlinien für Lambda
**Unterstützt Richtlinien auf Identitätsbasis:** Ja
Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität anfügen können, wie z. B. IAM-Benutzern, -Benutzergruppen oder -Rollen. Diese Richtlinien steuern, welche Aktionen die Benutzer und Rollen für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
Mit identitätsbasierten IAM-Richtlinien können Sie angeben, welche Aktionen und Ressourcen zugelassen oder abgelehnt werden. Darüber hinaus können Sie die Bedingungen festlegen, unter denen Aktionen zugelassen oder abgelehnt werden. Informationen zu sämtlichen Elementen, die Sie in einer JSON-Richtlinie verwenden, finden Sie in der [IAM-Referenz für JSON-Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) im *IAM-Benutzerhandbuch*.
### Beispiele für identitätsbasierte Richtlinien für Lambda
Beispiele für identitätsbasierte Lambda-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für AWS Lambda](security_iam_id-based-policy-examples.md).
## Ressourcenbasierte Richtlinien in Lambda
**Unterstützt ressourcenbasierte Richtlinien:** Ja
Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele für ressourcenbasierte Richtlinien sind IAM-*Rollen-Vertrauensrichtlinien* und Amazon-S3-*Bucket-Richtlinien*. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Für die Ressource, an welche die Richtlinie angehängt ist, legt die Richtlinie fest, welche Aktionen ein bestimmter Prinzipal unter welchen Bedingungen für diese Ressource ausführen kann. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). Zu den Prinzipalen können Konten, Benutzer, Rollen, Verbundbenutzer oder gehören. AWS-Services
Um kontoübergreifenden Zugriff zu ermöglichen, können Sie ein gesamtes Konto oder IAM-Entitäten in einem anderen Konto als Prinzipal in einer ressourcenbasierten Richtlinie angeben. Weitere Informationen finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
Sie können eine ressourcenbasierte Richtlinie an eine Lambda-Funktion oder -Ebene anhängen. Diese Richtlinie legt fest, welche Prinzipale Aktionen auf der Funktion oder Ebene durchführen können.
Weitere Informationen zum Anfügen einer ressourcenbasierten Richtlinie an eine Funktion oder eine Ebene finden Sie unter [Anzeigen von ressourcenbasierten IAM-Richtlinien in Lambda](access-control-resource-based.md).
## Richtlinienaktionen für Lambda
**Unterstützt Richtlinienaktionen:** Ja
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Action` einer JSON-Richtlinie beschreibt die Aktionen, mit denen Sie den Zugriff in einer Richtlinie zulassen oder verweigern können. Nehmen Sie Aktionen in eine Richtlinie auf, um Berechtigungen zur Ausführung des zugehörigen Vorgangs zu erteilen.
Eine Liste der Lambda-Aktionen finden Sie unter [Von AWS Lambda definierte Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions) in der *Service-Autorisierungs-Referenz*.
Richtlinienaktionen in Lambda verwenden das folgende Präfix vor der Aktion:
```
lambda
```
Um mehrere Aktionen in einer einzigen Anweisung anzugeben, trennen Sie sie mit Kommata:
```
"Action": [
"lambda:action1",
"lambda:action2"
]
```
Beispiele für identitätsbasierte Lambda-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für AWS Lambda](security_iam_id-based-policy-examples.md).
## Richtlinienressourcen für Lambda
**Unterstützt Richtlinienressourcen:** Ja
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das JSON-Richtlinienelement `Resource` gibt die Objekte an, auf welche die Aktion angewendet wird. Als Best Practice geben Sie eine Ressource mit dem zugehörigen [Amazon-Ressourcennamen (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) an. Verwenden Sie für Aktionen, die keine Berechtigungen auf Ressourcenebene unterstützen, einen Platzhalter (\$1), um anzugeben, dass die Anweisung für alle Ressourcen gilt.
```
"Resource": "*"
```
Eine Liste der Lambda-Ressourcentypen und ihrer ARNs Typen finden Sie unter [Ressourcentypen definiert von AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies) in der *Service Authorization Reference.* Informationen zu den Aktionen, mit denen Sie den ARN einzelner Ressourcen angeben können, finden Sie unter [Von AWS Lambda definierte Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Beispiele für identitätsbasierte Lambda-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für AWS Lambda](security_iam_id-based-policy-examples.md).
## Richtlinien-Bedingungsschlüssel für Lambda
**Unterstützt servicespezifische Richtlinienbedingungsschlüssel:** Ja
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Condition` gibt an, wann Anweisungen auf der Grundlage definierter Kriterien ausgeführt werden. Sie können bedingte Ausdrücke erstellen, die [Bedingungsoperatoren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) verwenden, z. B. ist gleich oder kleiner als, damit die Bedingung in der Richtlinie mit Werten in der Anforderung übereinstimmt. Eine Übersicht aller AWS globalen Bedingungsschlüssel finden Sie unter [Kontextschlüssel für AWS globale Bedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) im *IAM-Benutzerhandbuch*.
Eine Liste von Lambda-Bedingungsschlüsseln finden Sie unter [Bedingungsschlüssel für AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys) in der *Service-Autorisierungs-Referenz*. Informationen zu den Aktionen und Ressourcen, mit denen Sie einen Bedingungsschlüssel verwenden können, finden Sie unter [Aktionen definiert von AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions).
Beispiele für identitätsbasierte Lambda-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Richtlinien für AWS Lambda](security_iam_id-based-policy-examples.md).
## ACLs in Lambda
**Unterstützt ACLs: Nein**
Zugriffskontrolllisten (ACLs) steuern, welche Principals (Kontomitglieder, Benutzer oder Rollen) über Zugriffsberechtigungen für eine Ressource verfügen. ACLs ähneln ressourcenbasierten Richtlinien, verwenden jedoch nicht das JSON-Richtliniendokumentformat.
## ABAC mit Lambda
**Unterstützt ABAC (Tags in Richtlinien):** Teilweise
Die attributbasierte Zugriffskontrolle (ABAC) ist eine Autorisierungsstrategie, bei der Berechtigungen basierend auf Attributen, auch als Tags bezeichnet, definiert werden. Sie können Tags an IAM-Entitäten und AWS Ressourcen anhängen und dann ABAC-Richtlinien so entwerfen, dass Operationen möglich sind, wenn das Tag des Prinzipals mit dem Tag auf der Ressource übereinstimmt.
Um den Zugriff auf der Grundlage von Tags zu steuern, geben Sie im Bedingungselement einer[ Richtlinie Tag-Informationen ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)an, indem Sie die Schlüssel `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, oder Bedingung `aws:TagKeys` verwenden.
Wenn ein Service alle drei Bedingungsschlüssel für jeden Ressourcentyp unterstützt, lautet der Wert für den Service **Ja**. Wenn ein Service alle drei Bedingungsschlüssel für nur einige Ressourcentypen unterstützt, lautet der Wert **Teilweise**.
*Weitere Informationen zu ABAC finden Sie unter [Definieren von Berechtigungen mit ABAC-Autorisierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) im IAM-Benutzerhandbuch*. Um ein Tutorial mit Schritten zur Einstellung von ABAC anzuzeigen, siehe [Attributbasierte Zugriffskontrolle (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) verwenden im *IAM-Benutzerhandbuch*.
Weitere Informationen über das Markieren von Lambda-Ressourcen mit Tags finden Sie unter [Verwendung der attributbasierten Zugriffskontrolle in Lambda](attribute-based-access-control.md).
## Verwenden temporärer Anmeldeinformationen mit Lambda
**Unterstützt temporäre Anmeldeinformationen:** Ja
Temporäre Anmeldeinformationen ermöglichen den kurzfristigen Zugriff auf AWS Ressourcen und werden automatisch erstellt, wenn Sie einen Verbund verwenden oder die Rollen wechseln. AWS empfiehlt, temporäre Anmeldeinformationen dynamisch zu generieren, anstatt langfristige Zugriffsschlüssel zu verwenden. Weitere Informationen finden Sie unter [Temporäre Anmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) und [AWS-Services , die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) im *IAM-Benutzerhandbuch*.
## Forward Access Sessions für Lambda
**Unterstützt Forward Access Sessions (FAS):** Nein
Forward Access Sessions (FAS) verwenden die Berechtigungen des Prinzipals, der einen aufruft AWS-Service, in Kombination mit der Anfrage, Anfragen AWS-Service an nachgeschaltete Dienste zu stellen. Einzelheiten zu den Richtlinien für FAS-Anforderungen finden Sie unter [Zugriffssitzungen weiterleiten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Servicerollen für Lambda
**Unterstützt Servicerollen:** Ja
Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Service annimmt, um Aktionen in Ihrem Namen auszuführen. Ein IAM-Administrator kann eine Servicerolle innerhalb von IAM erstellen, ändern und löschen. Weitere Informationen finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS-Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*.
In Lambda wird eine Servicerolle als [Ausführungsrolle](lambda-intro-execution-role.md) bezeichnet.
**Warnung**
Das Ändern der Berechtigungen für eine Ausführungsrolle kann die Lambda-Funktionalität beeinträchtigen.
## Serviceverknüpfte Rollen für Lambda
**Unterstützt serviceverknüpfte Rollen:** Ja
Eine dienstbezogene Rolle ist eine Art von Servicerolle, die mit einer verknüpft ist. AWS-Service Der Service kann die Rolle übernehmen, um eine Aktion in Ihrem Namen auszuführen. Dienstbezogene Rollen werden in Ihrem Dienst angezeigt AWS-Konto und gehören dem Dienst. Ein IAM-Administrator kann die Berechtigungen für Service-verknüpfte Rollen anzeigen, aber nicht bearbeiten.
Lambda verfügt im Gegensatz zu Lambda@Edge nicht über serviceverknüpfte Rollen. Weitere Informationen finden Sie unter [Service-Linked Roles for Lambda @Edge](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles) im *Amazon CloudFront Developer Guide*.
Details zum Erstellen oder Verwalten von serviceverknüpften Rollen finden Sie unter [AWS -Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie in der Tabelle nach einem Service mit einem `Yes` in der Spalte **Service-linked role** (Serviceverknüpfte Rolle). Wählen Sie den Link **Yes** (Ja) aus, um die Dokumentation für die serviceverknüpfte Rolle für diesen Service anzuzeigen.
# Beispiele für identitätsbasierte Richtlinien für AWS Lambda
Standardmäßig verfügen Benutzer und Rollen nicht über die Berechtigung, Lambda-Ressourcen zu erstellen oder zu ändern. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern die Berechtigung erteilen, Aktionen für die Ressourcen auszuführen, die sie benötigen.
Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter [Erstellen von IAM-Richtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) im *IAM-Benutzerhandbuch*.
Einzelheiten zu den von Lambda definierten Aktionen und Ressourcentypen, einschließlich des Formats ARNs für die einzelnen Ressourcentypen, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html) in der *Service Authorization Reference.*
**Topics**
+ [
## Best Practices für Richtlinien
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Verwenden von Lambda-Konsole
](#security_iam_id-based-policy-examples-console)
+ [
## Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
](#security_iam_id-based-policy-examples-view-own-permissions)
## Best Practices für Richtlinien
Identitätsbasierte Richtlinien legen fest, ob jemand Lambda-Ressourcen in Ihrem Konto erstellen, aufrufen oder löschen kann. Dies kann zusätzliche Kosten für Ihr verursachen AWS-Konto. Beachten Sie beim Erstellen oder Bearbeiten identitätsbasierter Richtlinien die folgenden Richtlinien und Empfehlungen:
+ **Erste Schritte mit AWS verwalteten Richtlinien und Umstellung auf Berechtigungen mit den geringsten Rechten** — Verwenden Sie die *AWS verwalteten Richtlinien*, die Berechtigungen für viele gängige Anwendungsfälle gewähren, um damit zu beginnen, Ihren Benutzern und Workloads Berechtigungen zu gewähren. Sie sind in Ihrem verfügbar. AWS-Konto Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie vom AWS Kunden verwaltete Richtlinien definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) oder [Von AWS verwaltete Richtlinien für Auftragsfunktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) im *IAM-Benutzerhandbuch*.
+ **Anwendung von Berechtigungen mit den geringsten Rechten** – Wenn Sie mit IAM-Richtlinien Berechtigungen festlegen, gewähren Sie nur die Berechtigungen, die für die Durchführung einer Aufgabe erforderlich sind. Sie tun dies, indem Sie die Aktionen definieren, die für bestimmte Ressourcen unter bestimmten Bedingungen durchgeführt werden können, auch bekannt als *die geringsten Berechtigungen*. Weitere Informationen zur Verwendung von IAM zum Anwenden von Berechtigungen finden Sie unter [ Richtlinien und Berechtigungen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von Bedingungen in IAM-Richtlinien zur weiteren Einschränkung des Zugriffs** – Sie können Ihren Richtlinien eine Bedingung hinzufügen, um den Zugriff auf Aktionen und Ressourcen zu beschränken. Sie können beispielsweise eine Richtlinienbedingung schreiben, um festzulegen, dass alle Anforderungen mithilfe von SSL gesendet werden müssen. Sie können auch Bedingungen verwenden, um Zugriff auf Serviceaktionen zu gewähren, wenn diese für einen bestimmten Zweck verwendet werden AWS-Service, z. CloudFormation B. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von IAM Access Analyzer zur Validierung Ihrer IAM-Richtlinien, um sichere und funktionale Berechtigungen zu gewährleisten** – IAM Access Analyzer validiert neue und vorhandene Richtlinien, damit die Richtlinien der IAM-Richtliniensprache (JSON) und den bewährten IAM-Methoden entsprechen. IAM Access Analyzer stellt mehr als 100 Richtlinienprüfungen und umsetzbare Empfehlungen zur Verfügung, damit Sie sichere und funktionale Richtlinien erstellen können. Weitere Informationen finden Sie unter [Richtlinienvalidierung mit IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) im *IAM-Benutzerhandbuch*.
+ **Multi-Faktor-Authentifizierung (MFA) erforderlich** — Wenn Sie ein Szenario haben, das IAM-Benutzer oder einen Root-Benutzer in Ihrem System erfordert AWS-Konto, aktivieren Sie MFA für zusätzliche Sicherheit. Um MFA beim Aufrufen von API-Vorgängen anzufordern, fügen Sie Ihren Richtlinien MFA-Bedingungen hinzu. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) im *IAM-Benutzerhandbuch*.
Weitere Informationen zu bewährten Methoden in IAM finden Sie unter [Best Practices für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) im *IAM-Benutzerhandbuch*.
## Verwenden von Lambda-Konsole
Um auf die AWS Lambda Konsole zugreifen zu können, benötigen Sie ein Mindestmaß an Berechtigungen. Diese Berechtigungen müssen es Ihnen ermöglichen, Details zu den Lambda-Ressourcen in Ihrem AWS-Konto aufzulisten und anzuzeigen. Wenn Sie eine identitätsbasierte Richtlinie erstellen, die strenger ist als die mindestens erforderlichen Berechtigungen, funktioniert die Konsole nicht wie vorgesehen für Entitäten (Benutzer oder Rollen) mit dieser Richtlinie.
Sie müssen Benutzern, die nur die API AWS CLI oder die AWS API aufrufen, keine Mindestberechtigungen für die Konsole gewähren. Stattdessen sollten Sie nur Zugriff auf die Aktionen zulassen, die der API-Operation entsprechen, die die Benutzer ausführen möchten.
Eine Beispielrichtlinie, die minimalen Zugriff für die Funktionsentwicklung gewährt, finden Sie unter [Benutzern den Zugriff auf eine Lambda-Funktion gewähren](permissions-user-function.md). Neben Lambda verwendet die Lambda-Konsole weitere Dienste APIs, um die Triggerkonfiguration anzuzeigen und Ihnen das Hinzufügen neuer Trigger zu ermöglichen. Wenn Ihre Benutzer Lambda mit anderen Services nutzen, benötigen sie auch Zugriff auf diese Services. Details zum Konfigurieren weiterer Services mit Lambda finden Sie unter [Lambda mit Ereignissen aus anderen Diensten aufrufen AWS](lambda-services.md).
## Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die IAM-Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie umfasst Berechtigungen zum Ausführen dieser Aktion auf der Konsole oder programmgesteuert mithilfe der OR-API. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS verwaltete Richtlinien für AWS Lambda
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet AWS wird. AWS Verwaltete Richtlinien sind so konzipiert, dass sie Berechtigungen für viele gängige Anwendungsfälle bereitstellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.
Beachten Sie, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie allen AWS Kunden zur Verfügung stehen. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn eine neue Richtlinie eingeführt AWS-Service wird oder neue API-Operationen für bestehende Dienste verfügbar werden.
Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.
**Topics**
+ [
## AWS verwaltete Richtlinie: AWSLambda\$1FullAccess
](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess)
+ [
## AWS verwaltete Richtlinie: AWSLambda\$1ReadOnlyAccess
](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess)
+ [
## AWS verwaltete Richtlinie: AWSLambda BasicExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole)
+ [
## AWS verwaltete Richtlinie: AWSLambda BasicDurableExecutionRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy)
+ [
## AWS verwaltete Richtlinie: Dynamo-Rolle AWSLambda DBExecution
](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole)
+ [
## AWS verwaltete Richtlinie: Zugriff AWSLambda ENIManagement
](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess)
+ [
## AWS verwaltete Richtlinie: AWSLambdaInvocation-DynamoDB
](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB)
+ [
## AWS verwaltete Richtlinie: AWSLambda KinesisExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole)
+ [
## AWS verwaltete Richtlinie: AWSLambda MSKExecution Rolle
](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole)
+ [
## AWS verwaltete Richtlinie: AWSLambda Rolle
](#lambda-security-iam-awsmanpol-AWSLambdaRole)
+ [
## AWS verwaltete Richtlinie: AWSLambda SQSQueue ExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole)
+ [
## AWS verwaltete Richtlinie: AWSLambda VPCAccess ExecutionRole
](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole)
+ [
## AWS verwaltete Richtlinie: AWSLambda Verwaltet EC2 ResourceOperator
](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator)
+ [
## AWS verwaltete Richtlinie: AWSLambda ServiceRolePolicy
](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy)
+ [
## Lambda-Updates für AWS verwaltete Richtlinien
](#lambda-security-iam-awsmanpol-updates)
## AWS verwaltete Richtlinie: AWSLambda\$1FullAccess
Diese Richtlinie ermöglicht Vollzugriff auf alle Lambda-Aktionen. Es gewährt auch Berechtigungen für andere AWS Dienste, die zur Entwicklung und Wartung von Lambda-Ressourcen verwendet werden.
Die Richtlinie `AWSLambda_FullAccess` kann an Benutzer, Gruppen und Rollen angefügt werden.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `lambda`: Ermöglicht Prinzipalen Vollzugriff auf Lambda.
+ `cloudformation`— Ermöglicht Prinzipalen, AWS CloudFormation Stacks zu beschreiben und die Ressourcen in diesen Stacks aufzulisten.
+ `cloudwatch`— Ermöglicht Prinzipalen, CloudWatch Amazon-Metriken aufzulisten und Metrikdaten abzurufen.
+ `ec2`— Ermöglicht Prinzipalen die Beschreibung von Sicherheitsgruppen, Subnetzen und. VPCs
+ `iam`: Ermöglicht es Prinzipalen, Richtlinien, Richtlinienversionen, Rollen, Rollenrichtlinien, angefügte Rollenrichtlinien und die Liste der Rollen abzurufen. Diese Richtlinie ermöglicht es Prinzipalen außerdem, Rollen an Lambda zu übergeben. Die Berechtigung `PassRole` wird verwendet, wenn Sie einer Funktion eine Ausführungsrolle zuweisen. Die `CreateServiceLinkedRole` Berechtigung wird verwendet, wenn eine dienstbezogene Rolle erstellt wird.
+ `kms`— Ermöglicht Prinzipalen, Aliase aufzulisten und den Schlüssel für die Volumenverschlüsselung zu beschreiben.
+ `logs`: Ermöglicht Prinzipalen das Beschreiben von Protokollstreams, das Abrufen und Filtern von Protokollereignissen sowie das Starten und Beenden von Live-Tail-Sitzungen.
+ `states`— Ermöglicht es Prinzipalen, Zustandsmaschinen zu beschreiben und aufzulisten AWS Step Functions .
+ `tag`: Ermöglicht es Prinzipalen, Ressourcen auf der Grundlage ihrer Tags abzurufen.
+ `xray`— Ermöglicht Prinzipalen das Abrufen von AWS X-Ray Trace-Zusammenfassungen und das Abrufen einer nach ID spezifizierten Liste von Traces.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)im *Referenzhandbuch für AWS verwaltete Richtlinien.*
## AWS verwaltete Richtlinie: AWSLambda\$1ReadOnlyAccess
Diese Richtlinie gewährt schreibgeschützten Zugriff auf Lambda-Ressourcen und andere AWS Dienste, die zur Entwicklung und Wartung von Lambda-Ressourcen verwendet werden.
Die Richtlinie `AWSLambda_ReadOnlyAccess` kann an Benutzer, Gruppen und Rollen angefügt werden.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `lambda`: Ermöglicht es Prinzipalen, alle Ressourcen abzurufen und aufzulisten.
+ `cloudformation`— Ermöglicht Prinzipalen, Stacks zu beschreiben und aufzulisten und die Ressourcen in AWS CloudFormation diesen Stacks aufzulisten.
+ `cloudwatch`— Ermöglicht Prinzipalen, CloudWatch Amazon-Metriken aufzulisten und Metrikdaten abzurufen.
+ `ec2`— Ermöglicht Prinzipalen die Beschreibung von Sicherheitsgruppen, Subnetzen und. VPCs
+ `iam`: Ermöglicht es Prinzipalen, Richtlinien, Richtlinienversionen, Rollen, Rollenrichtlinien, angefügte Rollenrichtlinien und die Liste der Rollen abzurufen.
+ `kms`: Ermöglicht Prinzipalen das Auflisten von Aliasen.
+ `logs`: Ermöglicht Prinzipalen das Beschreiben von Protokollstreams, das Abrufen und Filtern von Protokollereignissen sowie das Starten und Beenden von Live-Tail-Sitzungen.
+ `states`— Ermöglicht es Prinzipalen, Zustandsmaschinen zu beschreiben und aufzulisten AWS Step Functions .
+ `tag`: Ermöglicht es Prinzipalen, Ressourcen auf der Grundlage ihrer Tags abzurufen.
+ `xray`— Ermöglicht Prinzipalen das Abrufen von AWS X-Ray Trace-Zusammenfassungen und das Abrufen einer nach ID spezifizierten Liste von Traces.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)im *Referenzhandbuch für AWS verwaltete Richtlinien.*
## AWS verwaltete Richtlinie: AWSLambda BasicExecutionRole
Diese Richtlinie gewährt Berechtigungen zum Hochladen von Protokollen in CloudWatch Logs.
Die Richtlinie `AWSLambdaBasicExecutionRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: AWSLambda BasicDurableExecutionRolePolicy
Diese Richtlinie gewährt Schreibberechtigungen für CloudWatch Protokolle und read/write Berechtigungen für die dauerhafte Ausführung, die von dauerhaften Lambda-Funktionen APIs verwendet werden. Diese Richtlinie stellt die grundlegenden Berechtigungen bereit, die für dauerhafte Lambda-Funktionen erforderlich sind, die eine dauerhafte Ausführung verwenden, APIs um den Fortschritt aufrechtzuerhalten und den Status bei Funktionsaufrufen aufrechtzuerhalten.
Die Richtlinie `AWSLambdaBasicDurableExecutionRolePolicy` kann an Benutzer, Gruppen und Rollen angefügt werden.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `logs`— Ermöglicht es Prinzipalen, Protokollgruppen und Protokollstreams zu erstellen und Protokollereignisse in Logs zu schreiben. CloudWatch
+ `lambda`— Ermöglicht es Prinzipalen, den dauerhaften Ausführungsstatus zu überprüfen und den dauerhaften Ausführungsstatus für langlebige Lambda-Funktionen abzurufen.
Weitere Einzelheiten zu dieser Richtlinie, einschließlich der neuesten Version des JSON-Richtliniendokuments, finden Sie unter [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) im *AWS Referenzhandbuch für verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: Dynamo-Rolle AWSLambda DBExecution
Diese Richtlinie gewährt Berechtigungen zum Lesen von Datensätzen aus einem Amazon DynamoDB DynamoDB-Stream und zum Schreiben in CloudWatch Protokolle.
Die Richtlinie `AWSLambdaDynamoDBExecutionRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie unter [AWSLambdaDynamo DBExecution Role](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html) im Referenzhandbuch *für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: Zugriff AWSLambda ENIManagement
Diese Richtlinie erteilt Berechtigungen zum Erstellen, Beschreiben und Löschen von Elastic Network-Schnittstellen, die von einer VPC-fähigen Lambda-Funktion verwendet werden.
Die Richtlinie `AWSLambdaENIManagementAccess` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie unter [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html) im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: AWSLambdaInvocation-DynamoDB
Diese Richtlinie gewährt Lesezugriff auf Amazon DynamoDB Streams.
Die Richtlinie `AWSLambdaInvocation-DynamoDB` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: AWSLambda KinesisExecutionRole
Diese Richtlinie gewährt Berechtigungen zum Lesen von Ereignissen aus einem Amazon Kinesis Kinesis-Datenstream und zum Schreiben in CloudWatch Protokolle.
Die Richtlinie `AWSLambdaKinesisExecutionRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)im *Referenzhandbuch für AWS verwaltete Richtlinien.*
## AWS verwaltete Richtlinie: AWSLambda MSKExecution Rolle
Diese Richtlinie gewährt Berechtigungen zum Lesen und Zugreifen auf Datensätze aus einem Amazon Managed Streaming for Apache Kafka Kafka-Cluster, zur Verwaltung elastischer Netzwerkschnittstellen und zum Schreiben in CloudWatch Protokolle.
Die Richtlinie `AWSLambdaMSKExecutionRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie unter [AWSLambdaMSKExecutionRolle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html) im *Referenzhandbuch für AWS verwaltete Richtlinien.*
## AWS verwaltete Richtlinie: AWSLambda Rolle
Diese Richtlinie erteilt Berechtigungen zum Aufrufen von Lambda-Funktionen.
Die Richtlinie `AWSLambdaRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie unter [AWSLambdaRolle](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html) im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: AWSLambda SQSQueue ExecutionRole
Diese Richtlinie gewährt Berechtigungen zum Lesen und Löschen von Nachrichten aus einer Amazon Simple Queue Service-Warteschlange sowie Schreibberechtigungen für CloudWatch Logs.
Die Richtlinie `AWSLambdaSQSQueueExecutionRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: AWSLambda VPCAccess ExecutionRole
Diese Richtlinie gewährt Berechtigungen zur Verwaltung elastischer Netzwerkschnittstellen innerhalb einer Amazon Virtual Private Cloud und zum Schreiben in CloudWatch Logs.
Die Richtlinie `AWSLambdaVPCAccessExecutionRole` kann an Benutzer, Gruppen und Rollen angefügt werden.
Weitere Informationen zu dieser Richtlinie, einschließlich des JSON-Richtliniendokuments und der Richtlinienversionen, finden Sie [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)im *Referenzhandbuch für AWS verwaltete Richtlinien*.
## AWS verwaltete Richtlinie: AWSLambda Verwaltet EC2 ResourceOperator
Diese Richtlinie ermöglicht automatisiertes Amazon Elastic Compute Cloud-Instanzmanagement für Lambda-Kapazitätsanbieter. Es gewährt dem Lambda Scaler Service Berechtigungen, um Instanzlebenszyklusoperationen in Ihrem Namen durchzuführen.
Die Richtlinie `AWSLambdaManagedEC2ResourceOperator` kann an Benutzer, Gruppen und Rollen angefügt werden.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `ec2:RunInstances`— Ermöglicht Lambda den Start neuer Amazon EC2 EC2-Instances unter der Bedingung, dass ec2: scaler.lambda.amazonaws.com ManagedResourceOperator entspricht und beschränkt die AMI-Nutzung nur auf Amazon-eigene Images.
+ `ec2:DescribeInstances`und `ec2:DescribeInstanceStatus` — Ermöglicht Lambda, den Instanzstatus zu überwachen und Instanzinformationen abzurufen.
+ `ec2:CreateTags`— Ermöglicht Lambda, Amazon EC2 EC2-Ressourcen zu Verwaltungs- und Identifikationszwecken zu kennzeichnen.
+ `ec2:DescribeAvailabilityZones`— Ermöglicht Lambda, verfügbare Zonen einzusehen, um Entscheidungen zur Instanzplatzierung zu treffen.
+ `ec2:DescribeCapacityReservations`— Ermöglicht Lambda, Kapazitätsreservierungen für eine optimale Instance-Platzierung zu überprüfen.
+ `ec2:DescribeInstanceTypes`und `ec2:DescribeInstanceTypeOfferings` — Ermöglicht Lambda, verfügbare Instance-Typen und deren Angebote zu überprüfen.
+ `ec2:DescribeSubnets`— Ermöglicht Lambda, Subnetzkonfigurationen für die Netzwerkplanung zu untersuchen.
+ `ec2:DescribeSecurityGroups`— Ermöglicht Lambda das Abrufen von Sicherheitsgruppeninformationen für die Konfiguration der Netzwerkschnittstelle.
+ `ec2:CreateNetworkInterface`— Ermöglicht Lambda die Erstellung von Netzwerkschnittstellen und die Verwaltung von Subnetz- und Sicherheitsgruppenzuordnungen.
+ `ec2:AttachNetworkInterface`[— Ermöglicht Lambda das Anhängen von Netzwerkschnittstellen an Amazon EC2 EC2-Instances mit der Bedingung scaler.lambda.amazonaws.com`ec2:ManagedResourceOperator`.](http://scaler.lambda.amazonaws.com/)
[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)
## AWS verwaltete Richtlinie: AWSLambda ServiceRolePolicy
Diese Richtlinie ist der serviceverknüpften Rolle zugeordnet, die so benannt ist AWSServiceRoleForLambda , dass Lambda Instances beenden kann, die als Teil von Lambda-Kapazitätsanbietern verwaltet werden.
**Details zu Berechtigungen**
Diese Richtlinie umfasst die folgenden Berechtigungen:
+ `ec2:TerminateInstances`— Ermöglicht Lambda, EC2-Instances unter der Bedingung zu beenden, dass ec2: ManagedResourceOperator gleich scaler.lambda.amazonaws.com ist.
+ `ec2:DescribeInstanceStatus`und `ec2:DescribeInstances` — Ermöglicht Lambda die Beschreibung von EC2-Instances.
Weitere Informationen zu dieser Richtlinie finden Sie unter [Verwenden von dienstverknüpften Rollen für Lambda](using-service-linked-roles.md).
## Lambda-Updates für AWS verwaltete Richtlinien
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| [AWSLambdaVerwaltet EC2 ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) — Neue Richtlinie | Lambda hat eine neue verwaltete Richtlinie hinzugefügt, um ein automatisiertes Amazon EC2 EC2-Instance-Management für Lambda-Kapazitätsanbieter zu ermöglichen, sodass der Scaler-Service Instance-Lebenszyklusoperationen durchführen kann. | 30. November 2025 |
| [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) – Neue Richtlinie | Lambda hat eine neue verwaltete Richtlinie für die serviceverknüpfte Rolle hinzugefügt, damit Lambda Instanzen beenden kann, die als Teil von Lambda-Kapazitätsanbietern verwaltet werden. | 30. November 2025 |
| [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Veränderung | Lambda hat die `AWSLambda_FullAccess` Richtlinie aktualisiert, um die `iam:CreateServiceLinkedRole` Aktionen `kms:DescribeKey` und zuzulassen. | 30. November 2025 |
| [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)— Neue verwaltete Richtlinie | Lambda hat eine neue verwaltete Richtlinie veröffentlicht`AWSLambdaBasicDurableExecutionRolePolicy`, die Schreibberechtigungen für CloudWatch Protokolle und read/write Berechtigungen für die dauerhafte Ausführung bereitstellt, die von dauerhaften Lambda-Funktionen APIs verwendet werden. | 1. Dezember 2025 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)und [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)— Veränderung | Lambda hat die Richtlinien `AWSLambda_ReadOnlyAccess` und `AWSLambda_FullAccess` aktualisiert, um die Aktionen `logs:StartLiveTail` und `logs:StopLiveTail` zuzulassen. | 17. März 2025 |
| [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)— Veränderung | Lambda hat die `AWSLambdaVPCAccessExecutionRole`-Richtlinie aktualisiert, um die Aktion `ec2:DescribeSubnets` zuzulassen. | 5. Januar 2024 |
| [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)— Veränderung | Lambda hat die `AWSLambda_ReadOnlyAccess` Richtlinie aktualisiert, sodass Prinzipale Stacks auflisten CloudFormation können. | 27. Juli 2023 |
| AWS Lambda hat begonnen, Änderungen zu verfolgen | AWS Lambda hat begonnen, Änderungen für die AWS verwalteten Richtlinien zu verfolgen. | 27. Juli 2023 |
# Problembehandlung bei AWS Lambda Identität und Zugriff
Diagnostizieren und beheben Sie mithilfe der folgenden Informationen gängige Probleme, die bei der Verwendung von Lambda und IAM auftreten können.
**Topics**
+ [
## Ich bin nicht autorisiert, eine Aktion in Lambda auszuführen.
](#security_iam_troubleshoot-no-permissions)
+ [
## Ich bin nicht berechtigt, iam auszuführen: PassRole
](#security_iam_troubleshoot-passrole)
+ [
## Ich möchte Personen außerhalb von mir den Zugriff AWS-Konto auf meine Lambda-Ressourcen ermöglichen
](#security_iam_troubleshoot-cross-account-access)
## Ich bin nicht autorisiert, eine Aktion in Lambda auszuführen.
Wenn Sie eine Fehlermeldung erhalten, dass Sie nicht zur Durchführung einer Aktion berechtigt sind, müssen Ihre Richtlinien aktualisiert werden, damit Sie die Aktion durchführen können.
Der folgende Beispielfehler tritt auf, wenn der IAM-Benutzer `mateojackson` versucht, über die Konsole Details zu einer fiktiven `my-example-widget`-Ressource anzuzeigen, jedoch nicht über `lambda:GetWidget`-Berechtigungen verfügt.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget
```
In diesem Fall muss die Richtlinie für den Benutzer `mateojackson` aktualisiert werden, damit er mit der `lambda:GetWidget`-Aktion auf die `my-example-widget`-Ressource zugreifen kann.
Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
## Ich bin nicht berechtigt, iam auszuführen: PassRole
Wenn Sie die Fehlermeldung erhalten, dass Sie nicht zur Ausführung der Aktion „`iam:PassRole`“ autorisiert sind, müssen Ihre Richtlinien aktualisiert werden, um eine Rolle an Lambda übergeben zu können.
Einige AWS-Services ermöglichen es Ihnen, eine bestehende Rolle an diesen Dienst zu übergeben, anstatt eine neue Servicerolle oder eine dienstverknüpfte Rolle zu erstellen. Hierzu benötigen Sie Berechtigungen für die Übergabe der Rolle an den Dienst.
Der folgende Beispielfehler tritt auf, wenn ein IAM-Benutzer mit dem Namen `marymajor` versucht, die Konsole zu verwenden, um eine Aktion in Lambda auszuführen. Die Aktion erfordert jedoch, dass der Service über Berechtigungen verfügt, die durch eine Servicerolle gewährt werden. Mary besitzt keine Berechtigungen für die Übergabe der Rolle an den Dienst.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In diesem Fall müssen die Richtlinien von Mary aktualisiert werden, um die Aktion `iam:PassRole` ausführen zu können.
Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
## Ich möchte Personen außerhalb von mir den Zugriff AWS-Konto auf meine Lambda-Ressourcen ermöglichen
Sie können eine Rolle erstellen, mit der Benutzer in anderen Konten oder Personen außerhalb Ihrer Organisation auf Ihre Ressourcen zugreifen können. Sie können festlegen, wem die Übernahme der Rolle anvertraut wird. Für Dienste, die ressourcenbasierte Richtlinien oder Zugriffskontrolllisten (ACLs) unterstützen, können Sie diese Richtlinien verwenden, um Personen Zugriff auf Ihre Ressourcen zu gewähren.
Weitere Informationen dazu finden Sie hier:
+ Informationen dazu, ob Lambda diese Funktionen unterstützt, finden Sie unter [Wie AWS Lambda funktioniert mit IAM](security_iam_service-with-iam.md).
+ *Informationen dazu, wie Sie Zugriff auf Ihre Ressourcen in AWS-Konten Ihrem Besitz gewähren können, finden Sie im IAM-Benutzerhandbuch unter [Gewähren des Zugriffs auf einen IAM-Benutzer in einem anderen AWS-Konto , dem Sie](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) gehören.*
+ Informationen dazu, wie Sie Dritten Zugriff auf Ihre Ressourcen gewähren können AWS-Konten, finden Sie [AWS-Konten im *IAM-Benutzerhandbuch* unter Gewähren des Zugriffs für Dritte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html).
+ Informationen dazu, wie Sie über einen Identitätsverbund Zugriff gewähren, finden Sie unter [Gewähren von Zugriff für extern authentifizierte Benutzer (Identitätsverbund)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) im *IAM-Benutzerhandbuch*.
+ Informationen zum Unterschied zwischen der Verwendung von Rollen und ressourcenbasierten Richtlinien für den kontoübergreifenden Zugriff finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
# 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.
# Compliance-Validierung für AWS Lambda
Die Auditoren Dritter bewerten die Sicherheit und die Compliance von AWS Lambda im Rahmen mehrerer AWS-Compliance-Programme. Hierzu zählen unter anderem SOC, PCI, FedRAMP und HIPAA.
Eine Liste der AWS-Services, die in den Geltungsbereich bestimmter Compliance-Programme fallen, finden Sie auf der Seite [AWS-Services in Scope nach Compliance-Programm](https://aws.amazon.com/compliance/services-in-scope/). Allgemeine Informationen finden Sie unter [AWS-Compliance-Programme](https://aws.amazon.com/compliance/programs/).
Die Auditberichte von Drittanbietern lassen sich mit herunterladen AWS Artifact. Weitere Informationen finden Sie unter [Herunterladen von Berichten in AWS-Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Ihre Compliance-Verantwortung bei Verwendung von Lambda hängt von der Vertraulichkeit der Daten, den Compliance-Zielen des Unternehmens und den geltenden Gesetzen und Vorschriften ab. Sie können Governance-Kontrollen implementieren, um sicherzustellen, dass die Lambda-Funktionen Ihres Unternehmens Ihren Compliance-Anforderungen entsprechen. Weitere Informationen finden Sie unter [Erstellen Sie eine Governance-Strategie für Lambda-Funktionen und -Layer](governance-concepts.md).
# Ausfallsicherheit in AWS Lambda
Im Zentrum der globalen AWS-Infrastruktur stehen die AWS-Regionen und Availability Zones. AWS Regionen stellen mehrere physisch getrennte und isolierte Availability Zones bereit, die mit Netzwerken mit geringer Latenz, hohem Durchsatz und hochredundanten Vernetzungen verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Availability Zones ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser hoch verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Weitere Informationen über AWS-Regionen und -Availability Zones finden Sie unter [Globale AWS-Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure/).
Zusätzlich zur globalen AWS-Infrastruktur stellt Lambda verschiedene Funktionen bereit, um Ihren Anforderungen in Bezug auf Ausfallsicherheit und Datensicherung zu erfüllen.
+ **Versioning** – Sie können in Lambda Versioning verwenden, um Code und Konfiguration Ihrer Funktion während ihrer Entwicklung zu speichern. In Verbindung mit Aliasnamen können Sie Versioning verwenden, um blaue/grüne und fortlaufende Bereitstellungen ausfzuführen. Details hierzu finden Sie unter [Versionen der Lambda-Funktion verwalten](configuration-versions.md).
+ **Skalierung** – Wenn Ihre Funktion während der Verarbeitung einer früheren Anforderung eine weitere Anforderung empfängt, startet Lambda eine weitere Instance Ihrer Funktion, um die höhere Last zu verarbeiten. Lambda wird automatisch skaliert, um 1.000 gleichzeitige Ausführungen pro Region zu verarbeiten, ein [Kontingent](gettingstarted-limits.md), das bei Bedarf erhöht werden kann. Details hierzu finden Sie unter [Verstehen der Skalierung von Lambda-Funktionen](lambda-concurrency.md).
+ **Hohe Verfügbarkeit** – Lambda führt Ihre Funktion in mehreren Availability Zones aus, um sicherzustellen, dass sie für die Verarbeitung von Ereignissen verfügbar ist, wenn der Service in einer Zone unterbrochen wird. Wenn Sie Ihre Funktion für die Herstellung von Verbindungen mit einer Virtual Private Cloud (VPC) in Ihrem Konto konfigurieren, geben Sie Subnetze in mehreren Availability Zones an, um eine hohe Verfügbarkeit sicherzustellen. Details hierzu finden Sie unter [Lambda-Funktionen Zugriff auf Ressourcen in einer Amazon VPC gewähren](configuration-vpc.md).
+ **Reservierte Gleichzeitigkeit** – Um sicherzustellen, dass Ihre Funktion stets skaliert werden kann, um zusätzliche Anforderungen zu verarbeiten, können Sie für sie Gleichzeitigkeit reservieren. Die Reservierung von Gleichzeitigkeit für eine Funktion stellt sicher, dass sie bis zu einer angegebenen Anzahl gleichzeitiger Aufrufe skaliert werden kann, diese Anzahl jedoch nicht überschreitet. Auf diese Weise wird sichergestellt, dass keine Anforderungen verloren gehen, da andere Funktionen der gesamte verfügbare Gleichzeitigkeit verbrauchen. Details hierzu finden Sie unter [Konfigurieren reservierter Gleichzeitigkeit für eine Funktion](configuration-concurrency.md).
+ **Wiederholversuche** – Im Fall asynchroner Aufrufe und bestimmter, von anderen Diensten ausgelöster Aufrufe führt Lambda bei Fehlern automatisch Wiederholversuche mit Verzögerungen zwischen den einzelnen Wiederholversuchen aus. Für die Ausführung der Wiederholversuche sind andere Clients und AWS-Services, die Funktionen synchron aufrufen, verantwortlich. Details hierzu finden Sie unter [Grundlegendes zum Wiederholungsverhalten in Lambda](invocation-retries.md).
+ **Warteschlange für unzustellbare Nachrichten** – Im Fall asynchroner Aufrufe können Sie Lambda für das Senden von Anforderungen an eine Warteschlange für unzustellbare Nachrichten konfigurieren, wenn Wiederholversuche fehlschlagen. Eine Warteschlange für unzustellbare Nachrichten ist ein Amazon-SNS-Thema oder eine Amazon-SQS-Warteschlange, die Ereignisse zur Fehlerbehebung oder erneuten Verarbeitung empfängt. Details hierzu finden Sie unter [Hinzufügen einer Warteschlange für unzustellbare Nachrichten](invocation-async-retain-records.md#invocation-dlq).
# Sicherheit der Infrastruktur in AWS Lambda
Als verwalteter Service ist AWS Lambda durch die globalen Verfahren zur Gewährleistung der Netzwerksicherheit von AWS geschützt. Informationen zu AWS-Sicherheitsdiensten und wie AWS die Infrastruktur schützt, finden Sie unter [AWSCloud-Sicherheit](https://aws.amazon.com/security/). Informationen zum Entwerfen Ihrer AWS-Umgebung anhand der bewährten Methoden für die Infrastruktursicherheit finden Sie unter [Infrastrukturschutz](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) im *Security Pillar AWS Well‐Architected Framework*.
Sie verwenden durch AWS veröffentlichte API-Aufrufe, um über das Netzwerk auf Lambda zuzugreifen. Kunden müssen Folgendes unterstützen:
+ Transport Layer Security (TLS). Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Verschlüsselungs-Suiten mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Die meisten modernen Systeme wie Java 7 und höher unterstützen diese Modi.
# Sicherung von Workloads mit öffentlichen Endpunkten
Für Workloads, die öffentlich zugänglich sind, bietet AWS eine Reihe von Features und Diensten, mit denen bestimmte Risiken gemindert werden können. Dieser Abschnitt behandelt die Authentifizierung und Autorisierung von Anwendungsbenutzern und den Schutz von API-Endpunkten.
## Authentifizierung und Autorisierung
Authentifizierung bezieht sich auf Identität und Autorisierung bezieht sich auf Aktionen. Verwenden Sie die Authentifizierung, um zu kontrollieren, wer eine Lambda-Funktion aufrufen kann und verwenden Sie dann die Autorisierung, um zu kontrollieren, was sie tun können. Für viele Anwendungen ist IAM ausreichend, um beide Kontrollmechanismen zu verwalten.
Für Anwendungen mit externen Benutzern, wie z. B. Web- oder Mobilanwendungen, ist es üblich, [JSON-Web-Tokens](https://jwt.io/introduction/) (JWTs) zur Verwaltung der Authentifizierung und Autorisierung zu verwenden. Im Gegensatz zur herkömmlichen, serverbasierten Passwortverwaltung werden JWTs bei jeder Anfrage vom Client übergeben. Sie sind eine kryptografisch sichere Methode, um Identität und Ansprüche anhand der vom Client übermittelten Daten zu überprüfen. Bei Lambda-basierten Anwendungen können Sie so jeden Aufruf an jeden API-Endpunkt sichern, ohne sich bei der Authentifizierung auf einen zentralen Server verlassen zu müssen.
Sie können [JWTs mit Amazon Cognito implementieren](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html), einem Benutzerverzeichnisdienst, der Registrierung, Authentifizierung, Kontowiederherstellung und andere gängige Kontoverwaltungsvorgänge abwickeln kann. [Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) bietet Bibliotheken, die die Integration dieses Dienstes in Ihre Frontend-Anwendung vereinfachen. Sie können auch Partnerdienste von Drittanbietern wie [Auth0](https://auth0.com/) erwägen.
Angesichts der wichtigen Sicherheitsrolle eines Identitätsanbieterdienstes ist es wichtig, professionelle Tools zum Schutz Ihrer Anwendung zu verwenden. Es wird nicht empfohlen, eigene Dienste für die Authentifizierung oder Autorisierung zu schreiben. Schwachstellen in benutzerdefinierten Bibliotheken können erhebliche Auswirkungen auf die Sicherheit Ihres Workloads und seiner Daten haben.
## API-Endpunkte schützen
Für Serverless-Anwendungen ist die Verwendung von Amazon API Gateway die bevorzugte Methode, eine Backend-Anwendung öffentlich bereitzustellen. Dies kann Ihnen helfen, eine API vor böswilligen Benutzern oder Datenverkehrsspitzen zu schützen.
API Gateway bietet zwei Endpunkttypen für Serverless-Entwickler: [REST-APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) und [HTTP-APIs](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html). Beide unterstützen die [Autorisierung mit AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html), IAM oder Amazon Cognito. Bei der Verwendung von IAM oder Amazon Cognito werden eingehende Anfragen ausgewertet. Fehlt ein erforderliches Token oder enthält es eine ungültige Authentifizierung, wird die Anfrage abgelehnt. Diese Anfragen werden Ihnen nicht in Rechnung gestellt und sie werden auch nicht auf die Drosselungskontingente angerechnet.
Auf nicht authentifizierte API-Routen kann jeder im öffentlichen Internet zugreifen. Es wird daher empfohlen, die Verwendung nicht authentifizierter APIs einzuschränken. Wenn Sie nicht authentifizierte APIs verwenden müssen, ist es wichtig, diese vor häufigen Risiken wie [Denial-of-Service](https://en.wikipedia.org/wiki/Denial-of-service_attack)-Angriffen (DoS) zu schützen. [ Die Anwendung von AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) auf diese APIs kann dazu beitragen, Ihre Anwendung vor SQL-Injektion- und Cross-Site-Scripting (XSS)-Angriffen zu schützen. API Gateway implementiert auch [Drosselung](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) auf AWS-Kontoebene und auf Client-Ebene, wenn API-Schlüssel verwendet werden.
In vielen Fällen kann die Funktionalität einer nicht authentifizierten API mit einem alternativen Ansatz erreicht werden. Beispielsweise kann eine Webanwendung Benutzern, die nicht angemeldet sind, eine Liste von Einzelhandelsgeschäften von Kunden aus einer DynamoDB-Tabelle bereitstellen. Diese Anfrage kann von einer Frontend-Webanwendung oder von einer anderen Quelle stammen, die den URL-Endpunkt aufruft. In diesem Diagramm werden drei Lösungen verglichen:
![\[Sicherheitsoperationen, Abbildung 5\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/security-ops-figure-5.png)
1. Diese nicht authentifizierte API kann von jedem Benutzer im Internet aufgerufen werden. Bei einem Denial-of-Service-Angriff ist es möglich, die API-Drosselungsgrenzen, die Lambda-Gleichzeitigkeit oder die von DynamoDB bereitgestellte Lesekapazität für eine zugrunde liegende Tabelle auszuschöpfen.
1. Eine CloudFront-Verteilung vor dem API-Endpunkt mit einer geeigneten [Time-to-Live](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL)-Konfiguration würde den größten Teil des Datenverkehrs bei einem DoS-Angriff absorbieren, ohne die zugrunde liegende Lösung für das Abrufen der Daten zu ändern.
1. Alternativ könnte die CloudFront-Distribution für statische Daten, die sich selten ändern, die Daten aus einem Amazon-S3-Bucket bereitstellen.
# Verwendung von Codesignatur zur Überprüfung der Codeintegrität mit Lambda
Die Codesignatur hilft sicherzustellen, dass nur vertrauenswürdiger Code in Ihren Lambda-Funktionen bereitgestellt wird. Mithilfe AWS Signer können Sie digital signierte Codepakete für Ihre Funktionen erstellen. Wenn Sie einer [Funktion eine Code-Signaturkonfiguration hinzufügen](configuration-codesigning-create.md), überprüft Lambda, ob alle neuen Codebereitstellungen von einer vertrauenswürdigen Quelle signiert sind. Da die Validierungsprüfungen von Codesignatur zum Zeitpunkt der Bereitstellung ausgeführt werden, gibt es keine Auswirkungen auf die Ausführung der Funktion.
**Wichtig**
Codesignatur-Konfigurationen verhindern nur neue Bereitstellungen von unsigniertem Code. Wenn Sie einer vorhandenen Funktion mit unsigniertem Code eine Codesignatur-Konfiguration hinzufügen, wird dieser Code so lange ausgeführt, bis Sie ein neues Codepaket bereitstellen.
Wenn Sie die Codesignatur für eine Funktion aktivieren, müssen alle [Ebenen](chapter-layers.md), die Sie der Funktion hinzufügen, auch von einem zulässigen Signaturprofil signiert werden.
Es fallen keine zusätzlichen Gebühren für die Verwendung AWS Signer oder Codesignatur für an AWS Lambda.
## Signaturvalidierung
Lambda führt die folgenden Validierungsprüfungen durch, wenn Sie ein signiertes Codepaket für Ihre Funktion bereitstellen:
1. **Integrität**: Überprüft, dass das Codepaket seit seiner Unterzeichnung nicht geändert wurde. Lambda vergleicht den Hash des Pakets mit dem Hash aus der Signatur.
1. **Ablauf**: Bestätigt, dass die Signatur des Codepakets nicht abgelaufen ist.
1. **Diskrepanz**: Bestätigt, dass das Codepaket mit einem der zulässigen Signaturprofil signiert ist.
1. **Widerruf**: Bestätigt, dass die Signatur des Codepakets nicht widerrufen wurde.
Wenn Sie eine Codesignaturkonfiguration erstellen, können Sie den [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment)Parameter verwenden, um anzugeben, wie Lambda reagieren soll, wenn die Ablauf-, Nichtübereinstimmungs- oder Sperrprüfungen fehlschlagen. Sie können eine der folgenden Aktionen auswählen:
+ `Warn`: Dies ist die Standardeinstellung. Lambda ermöglicht die Bereitstellung des Codepakets, gibt jedoch eine Warnung aus. Lambda gibt eine neue CloudWatch Amazon-Metrik (`SignatureValidationErrors`) aus und speichert die Warnung auch im CloudTrail Protokoll.
+ `Enforce` – Lambda gibt eine Warnung aus (wie bei der `Warn`-Aktion) und blockiert die Bereitstellung des Codepakets.
**Topics**
+ [
## Signaturvalidierung
](#config-codesigning-valid)
+ [
# Erstellen von Codesignatur-Konfigurationen für Lambda
](configuration-codesigning-create.md)
+ [
# Konfigurieren von IAM-Richtlinien für Lambda-Codesignaturkonfigurationen
](config-codesigning-policies.md)
+ [
# Verwendung von Tags in Codesignatur-Konfigurationen
](tags-csc.md)
# Erstellen von Codesignatur-Konfigurationen für Lambda
Um die Codesignatur für eine Funktion zu aktivieren, erstellen Sie eine *Codesignatur-Konfiguration* und hängen sie an die Funktion an. Eine Codesignatur-Konfiguration definiert eine Liste der zulässigen Signaturprofile und die Richtlinienaktion, die durchgeführt werden soll, wenn eine der Validierungsprüfungen fehlschlägt.
**Anmerkung**
Funktionen, die als Container-Images definiert sind, unterstützen keine Codesignatur.
**Topics**
+ [
## Voraussetzungen für die Konfiguration
](#config-codesigning-prereqs)
+ [
## Erstellen von Codesignatur-Konfigurationen
](#config-codesigning-config-console)
+ [
## Aktivieren der Codesignatur für eine Funktion
](#config-codesigning-function-console)
## Voraussetzungen für die Konfiguration
Bevor Sie die Codesignatur für eine Lambda-Funktion konfigurieren können, verwenden Sie AWS Signer, um Folgendes zu tun:
+ Erstellen Sie mindestens ein [Signaturprofil](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html).
+ Verwenden Sie ein Signaturprofil, um ein [signiertes Codepaket für Ihre Funktion zu erstellen](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html).
## Erstellen von Codesignatur-Konfigurationen
Mit einer Codesignatur-Konfiguration wird eine Liste der zulässigen Signaturprofile und die Richtlinie für Signaturvalidierung definiert.
**So erstellen Sie eine Codesignatur-Konfiguration (Konsole)**
1. Öffnen Sie die Seite [Codesignatur-Konfigurationen](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) der Lambda-Konsole.
1. Wählen Sie **Konfiguration erstellen**.
1. Geben Sie unter **Description (Beschreibung)** einen aussagekräftigen Namen für die Konfiguration ein.
1. Fügen Sie der Konfiguration unter **Signaturprofile** bis zu 20 Signaturprofile hinzu.
1. Wählen Sie für **ARN der Signaturprofilversion** den Amazon-Ressourcennamen (ARN) einer Profilversion aus oder geben Sie den ARN ein.
1. Um ein zusätzliches Signaturprofil hinzuzufügen, wählen Sie **Signaturprofil hinzufügen** aus.
1. Wählen Sie unter **Richtlinie zur Signaturvalidierung** die Option **Warnen** oder **Durchsetzen** aus.
1. Wählen Sie **Konfiguration erstellen**.
## Aktivieren der Codesignatur für eine Funktion
Um die Codesignatur für eine Funktion zu aktivieren, fügen Sie der Funktion eine Codesignatur-Konfiguration hinzu.
**Wichtig**
Codesignatur-Konfigurationen verhindern nur neue Bereitstellungen von unsigniertem Code. Wenn Sie einer vorhandenen Funktion mit unsigniertem Code eine Codesignatur-Konfiguration hinzufügen, wird dieser Code so lange ausgeführt, bis Sie ein neues Codepaket bereitstellen.
**So verknüpfen Sie eine Codesignatur-Konfiguration mit einer Funktion (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie die Funktion aus, für die Sie die Codesignatur aktivieren möchten.
1. Öffnen Sie die Registerkarte **Configuration** (Konfiguration).
1. Scrollen Sie nach unten und wählen Sie **Codesignatur** aus.
1. Wählen Sie **Bearbeiten** aus.
1. Wählen Sie i n **Codesignatur bearbeiten** eine Codesignatur-Konfiguration für diese Funktion aus.
1. Wählen Sie **Speichern**.
# Konfigurieren von IAM-Richtlinien für Lambda-Codesignaturkonfigurationen
Um einem Benutzer die Berechtigung zum Zugriff auf die Lambda-Codesignatur-API-Vorgänge zu erteilen, fügen Sie der Benutzerrichtlinie eine oder mehrere Richtlinienanweisungen bei. Weitere Informationen zu Benutzerrichtlinien finden Sie unter [Identitätsbasierte IAM-Richtlinien für Lambda](access-control-identity-based.md).
Die folgende Beispiel-Richtlinienanweisung gewährt die Berechtigung zum Erstellen, Aktualisieren und Abrufen von Codesignatur-Konfigurationen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:CreateCodeSigningConfig",
"lambda:UpdateCodeSigningConfig",
"lambda:GetCodeSigningConfig"
],
"Resource": "*"
}
]
}
```
------
Administratoren können den `CodeSigningConfigArn`-Bedingungsschlüssel verwenden, um die Codesignatur-Konfigurationen anzugeben, mit denen Entwickler Ihre Funktionen erstellen oder aktualisieren müssen.
Die folgende Beispielrichtlinienanweisung gewährt die Berechtigung zum Erstellen einer Funktion. Die Richtlinienanweisung enthält eine `lambda:CodeSigningConfigArn`-Bedingung, um die zulässige Konfiguration für die Codesignierung anzugeben. Lambda blockiert `CreateFunction` API-Anfragen, wenn der [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn)Parameter fehlt oder nicht mit dem Wert in der Bedingung übereinstimmt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowReferencingCodeSigningConfig",
"Effect": "Allow",
"Action": [
"lambda:CreateFunction"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6"
}
}
}
]
}
```
------
# Verwendung von Tags in Codesignatur-Konfigurationen
Sie können Codesignaturkonfigurationen taggen, um Ihre Ressourcen zu organisieren und zu verwalten. Tags sind frei formulierte Schlüssel-Wert-Paare, die mit Ihren Ressourcen verknüpft sind und von AWS-Services unterstützt werden. Weitere Informationen zu Anwendungsfällen für Tags finden Sie unter [Allgemeine Tagging-Strategien](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies) im *Tagging AWS Resources and Tag Editor Guide*.
Sie können die AWS Lambda API verwenden, um Tags anzuzeigen und zu aktualisieren. Sie können auch Tags anzeigen und aktualisieren, während Sie eine bestimmte Codesignatur-Konfiguration in der Lambda-Konsole verwalten.
**Topics**
+ [
## Erforderliche Berechtigungen zum Arbeiten mit Tags
](#csc-tags-required-permissions)
+ [
## Verwendung von Tags mit der Lambda-Konsole
](#tags-csc-console)
+ [
## Verwenden von Tags mit dem AWS CLI
](#tags-csc-cli)
## Erforderliche Berechtigungen zum Arbeiten mit Tags
Um einer AWS Identity and Access Management -(IAM)-Identität (Benutzer, Gruppe oder Rolle) das Lesen oder Setzen von Tags auf einer Ressource zu ermöglichen, gewähren Sie ihr die entsprechenden Berechtigungen:
+ **lambda: ListTags** —Wenn eine Ressource Tags enthält, gewähren Sie diese Berechtigung jedem, der sie aufrufen `ListTags` muss. Für Funktionen mit Tags ist diese Berechtigung auch für `GetFunction` erforderlich.
+ **lambda: TagResource** —Erteilen Sie diese Berechtigung jedem, der bei create ein Tag aufrufen `TagResource` oder ausführen muss.
Optional können Sie erwägen, auch die **lambda: UntagResource** -Berechtigung zu erteilen, um `UntagResource` Aufrufe der Ressource zuzulassen.
Weitere Informationen finden Sie unter [Identitätsbasierte IAM-Richtlinien für Lambda](access-control-identity-based.md).
## Verwendung von Tags mit der Lambda-Konsole
Sie können die Lambda-Konsole verwenden, um Codesignatur-Konfigurationen mit Tags zu erstellen, Tags zu vorhandenen Codesignatur-Konfigurationen hinzuzufügen und Codesignatur-Konfigurationen nach Tags zu filtern.
**So fügen Sie ein Tag hinzu, wenn Sie eine Codesignatur-Konfiguration erstellen**
1. Öffnen Sie [Codesignatur-Konfigurationen](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) der Lambda-Konsole.
1. Wählen Sie in der Kopfzeile des Inhaltsfensters die Option **Konfiguration erstellen** aus.
1. Richten Sie im Abschnitt oben im Inhaltsbereich Ihre Codesignatur-Konfiguration ein. Weitere Informationen zum Konfigurieren von Codesignatur-Konfigurationen finden Sie unter [Verwendung von Codesignatur zur Überprüfung der Codeintegrität mit Lambda](configuration-codesigning.md).
1. Klicken Sie im Abschnitt **Tags** auf **Neuen Tag hinzufügen**.
1. Geben Sie im Feld **Schlüssel** Ihren Tag-Schlüssel ein. Informationen zu Tagging-Einschränkungen finden Sie unter [Beschränkungen und Anforderungen für die Benennung](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) von *Tags im Tagging AWS Resources and Tag Editor Guide*.
1. Wählen Sie **Create configuration** (Konfiguration erstellen).
**So fügen Sie einer vorhandenen Codesignaturkonfiguration ein Tag hinzu**
1. Öffnen Sie [Codesignatur-Konfigurationen](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) der Lambda-Konsole.
1. Wählen Sie den Namen der Codesignatur-Konfiguration aus.
1. Wählen Sie auf den Registerkarten unter dem **Detail**bereich die Option **Tags** aus.
1. Wählen Sie **Tags verwalten** aus.
1. Wählen Sie **Neues Tag hinzufügen** aus.
1. Geben Sie im Feld **Schlüssel** Ihren Tag-Schlüssel ein. Informationen zu Einschränkungen beim Taggen finden Sie unter [Beschränkungen und Anforderungen für die Benennung von Tags im Leitfaden für AWS Tag-Ressourcen](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices) *und Tag-Editor*.
1. Wählen Sie **Speichern**.
**So filtern Sie Codesignatur-Konfigurationen nach Tags**
1. Öffnen Sie [Codesignatur-Konfigurationen](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) der Lambda-Konsole.
1. Wählen Sie das Suchfeld.
1. Wählen Sie in der Dropdown-Liste Ihr Tag unter der **Tag**-Unterüberschrift aus.
1. Wählen Sie **Verwenden: „Tag-Name“**, um alle Codesignaturkonfigurationen zu sehen, die mit dieser Taste gekennzeichnet sind oder wählen Sie einen **Operator**, um weiter nach Werten zu filtern.
1. Wählen Sie Ihren Tag-Wert aus, um nach einer Kombination aus Tag-Schlüssel und -Wert zu filtern.
Das Suchfeld unterstützt auch die Suche nach Tag-Schlüsseln. Geben Sie den Namen eines Schlüssels ein, um ihn in der Liste zu finden.
## Verwenden von Tags mit dem AWS CLI
Mit der Lambda-API können Sie Tags zu vorhandenen Lambda-Ressourcen hinzufügen und entfernen, einschließlich Codesignaturkonfigurationen. Sie können auch Tags hinzufügen, wenn Sie eine Codesignaturkonfiguration erstellen, die es Ihnen ermöglicht, eine Ressource während ihres gesamten Lebenszyklus zu kennzeichnen.
### Aktualisieren von Tags mit dem Lambda-Tag APIs
Sie können Tags für unterstützte Lambda-Ressourcen über die [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)und [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)API-Operationen hinzufügen und entfernen.
Sie können diese Operationen mit der Taste AWS CLI aufrufen. Um Tags einer vorhandenen Ressource hinzuzufügen, verwenden Sie den folgenden `tag-resource`-Befehl. In diesem Beispiel werden zwei Tags hinzugefügt, eines mit dem Schlüssel *Department* und eines mit dem Schlüssel*CostCenter*.
```
aws lambda tag-resource \
--resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \
--tags Department=Marketing,CostCenter=1234ABCD
```
Mit dem Befehl `untag-resource` können Sie Tags entfernen. In diesem Beispiel wird das Tag mit dem Schlüssel entfernt*Department*.
```
aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \
--tag-keys Department
```
### Hinzufügen von Tags beim Erstellen einer Codesignatur-Konfiguration
Verwenden Sie den [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html)API-Vorgang, um eine neue Lambda-Codesignaturkonfiguration mit Tags zu erstellen. Geben Sie den Parameter `Tags` an. Sie können diesen Vorgang mit dem `create-code-signing-config` AWS CLI Befehl und der `--tags` Option aufrufen. Weitere Informationen zum CLI-Befehl finden Sie [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)in der *AWS CLI Befehlsreferenz*.
Vergewissern Sie sich vor der Verwendung des `Tags`-Parameters mit `CreateCodeSigningConfig`, dass Ihre Rolle neben den üblichen Berechtigungen, die für diesen Vorgang erforderlich sind, auch die Berechtigung hat, Ressourcen zu taggen. Weitere Informationen zu den Berechtigungen für das Tagging finden Sie unter [Erforderliche Berechtigungen zum Arbeiten mit Tags](#csc-tags-required-permissions).
### Tags mit dem Lambda-Tag anzeigen APIs
Um die Tags anzuzeigen, die auf eine bestimmte Lambda-Ressource angewendet werden, verwenden Sie die `ListTags`-API-Operation. Weitere Informationen finden Sie unter [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html).
Sie können diesen Vorgang mit dem `list-tags` AWS CLI Befehl aufrufen, indem Sie einen ARN (Amazon Resource Name) angeben.
```
aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier
```
### Filtern von Ressourcen nach Tag
Sie können den AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html)API-Vorgang verwenden, um Ihre Ressourcen nach Tags zu filtern. Die `GetResources`-Operation empfängt bis zu 10 Filter, wobei jeder Filter einen Tag-Schlüssel und bis zu 10 Tag-Werte enthält. Sie stellen `GetResources` mit einem `ResourceType` zur Verfügung, um nach bestimmten Ressourcentypen zu filtern.
Sie können diesen Vorgang mit dem `get-resources` AWS CLI Befehl aufrufen. Beispiele für die Verwendung von `get-resources` finden Sie unter [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples) in der *AWS -CLI-Befehlsreferenz*.