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.

Berechtigungen für Lambda-Webfunktionen

Lambda Web Functions verwenden AWS Identity and Access Management (IAM), um zu steuern, was Ihr Anwendungscode tun kann (die Ausführungsrolle) und wer auf Ihre Webfunktion zugreifen kann (ressourcenbasierte Richtlinien). Auf dieser Seite wird erklärt, wie die einzelnen Typen konfiguriert werden.

Das folgende Diagramm zeigt die Identitäten, für die Berechtigungen erforderlich sind, und zeigt, welche Identitäten jeweils verwendet werden. Der Deployer ruft Lambda-Managementaktionen und -anforderungen für die Ausführungsrolle iam:PassRole auf. Der Code-Uploader benötigt s3:PutObject den versionierten Amazon S3 S3-Bucket, und Lambda liest die Version des Codeobjekts. Lambda kann Ihren Web-Funktionscode und Ihre Umgebungsvariablen mit einem optionalen, vom Kunden verwalteten AWS KMS Schlüssel verschlüsseln. Ihr Code wird mit der Ausführungsrolle ausgeführt, die Zugriff auf Amazon CloudWatch Logs und Ihre Abhängigkeiten gewährt. Ein Endpunkt-Aufrufer benötigt lambda:InvokeWebFunctionEndpoint einen IamAuth Endpunkt oder Anwendungsanmeldedaten für einen ApplicationManaged Endpunkt.

Rolle „Ausführung“

Die Ausführungsrolle ist eine IAM-Rolle, die Lambda annimmt, wenn es Ihren Web Function-Code ausführt. Ihre Anwendung verwendet die Berechtigungen dieser Rolle, um mit anderen AWS Diensten zu interagieren. Ihre Webfunktion benötigt mindestens die Erlaubnis, Protokolle in Amazon CloudWatch Logs zu schreiben, damit Sie Ihre Anwendung überwachen können. Wenn Ihre Anwendung aus DynamoDB liest, in Amazon S3 schreibt oder andere AWS Dienste aufruft, fügen Sie diese Berechtigungen der Ausführungsrolle hinzu.

Eine Ausführungsrolle erstellen

Um eine Ausführungsrolle für Ihre Web-Funktion zu erstellen, erstellen Sie eine IAM-Rolle mit einer Vertrauensrichtlinie, die es dem Lambda-Serviceprinzipal ermöglicht, diese zu übernehmen, und fügen Sie eine Berechtigungsrichtlinie hinzu, die den Zugriff gewährt, den Ihre Anwendung benötigt.

Wenn Sie es vorziehen, eine benutzerdefinierte Berechtigungsrichtlinie zu erstellen, anstatt die verwaltete Richtlinie zu verwenden, sind die Mindestberechtigungen, die Ihre Webfunktion für die Protokollierung benötigt:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:111122223333:log-group:/aws/lambda/web/my-web-app:*",
                "arn:aws:logs:*:111122223333:log-group:/aws/lambda/web/my-web-app.local:*"
            ]
        }
    ]
}

Die Richtlinie deckt zwei Protokollgruppen ab. Lambda schreibt regionsinterne Protokolle in die .local Protokollgruppe und zentralisiert sie dann in der Protokollgruppe ohne das Suffix in der Heimatregion. Die zentrale Protokollgruppe ARN verwendet die Heimatregion. Der .local ARN verwendet einen Platzhalter „Region“, da Lambda in diese Gruppe in jeder Region schreibt, in der ein Endpunkt Traffic bedient. Auf diese Weise kann eine Ausführungsrolle Endpunkte mit unterschiedlichen Regionsgruppen unterstützen. Wenn die Rolle nicht in die .local Protokollgruppe in einer Region schreiben kann, liefert Lambda keine Protokolle aus dieser Region. Wenn Sie eine benutzerdefinierte Protokollgruppe verwenden, ersetzen Sie beide ARNs durch Ihren Protokollgruppennamen und Ihren Protokollgruppennamen, gefolgt von. .local Weitere Informationen finden Sie unter Protokollgruppen.

Berechtigungen für andere Dienste hinzufügen

Wenn Ihre Anwendung auf andere AWS Dienste zugreift, fügen Sie der Ausführungsrolle die entsprechenden Berechtigungen hinzu. Das folgende Beispiel fügt Lesezugriff auf eine DynamoDB-Tabelle und Schreibzugriff auf einen Amazon S3 S3-Bucket hinzu.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:us-east-1:111122223333:log-group:/aws/lambda/web/my-web-app:*",
                "arn:aws:logs:*:111122223333:log-group:/aws/lambda/web/my-web-app.local:*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:GetItem",
                "dynamodb:Query"
            ],
            "Resource": "arn:aws:dynamodb:us-east-1:111122223333:table/my-table"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject"
            ],
            "Resource": "arn:aws:s3:::my-output-bucket/*"
        }
    ]
}

Die IAM-Identität, die eine Webfunktion oder Revision erstellt, verwendet ihre eigenen Berechtigungen, nicht die Ausführungsrolle. Diese Identität benötigt lambda:CreateWebFunction oderlambda:CreateWebFunctionRevision, iam:PassRole in der Ausführungsrolle, Lesezugriff auf das Bereitstellungspaket in Amazon S3. Informationen zu den Amazon S3 S3-Berechtigungen finden Sie unterBerechtigungen des Anrufers. Wenn Sie einen vom Kunden verwalteten Schlüssel verwenden, um Ihren Web-Funktionscode und Ihre Umgebungsvariablen zu verschlüsseln, benötigt diese Identität ebenfalls AWS KMS Berechtigungen. Weitere Informationen finden Sie unter Verschlüsselung im Ruhezustand für Webfunktionen.

Resource-based Richtlinien

Eine ressourcenbasierte Richtlinie ist ein JSON-Richtliniendokument, das Sie an Ihre Webfunktion anhängen. Sie kann jede Webfunktionsaktion gewähren, mit Ausnahme lambda:CreateWebFunction von IAM-Prinzipalen oder -Diensten. AWS Sie kann beispielsweise lambda:InvokeWebFunctionEndpoint für einen IamAuth Endpunkt gewähren. Es kann auch Verwaltungsaktionen wie lambda:GetWebFunctionlambda:CreateWebFunctionRevision, und gewährenlambda:UpdateWebFunctionEndpoint.

Der Richtlinienanhang und die zugehörigen Erklärungen verwenden unterschiedliche Ressourcen-ARNs:

Für einen IAM-Prinzipal in demselben Konto kann entweder die identitätsbasierte Richtlinie des Prinzipals oder die ressourcenbasierte Richtlinie der Webfunktion die Erlaubnis erteilen. Für einen IAM-Prinzipal in einem anderen Konto müssen beide Richtlinien eine Genehmigung gewähren. Dies gilt sowohl für Aufruf- als auch für Verwaltungsaktionen.

Verwenden Sie die attributebasierte Zugriffskontrolle (ABAC), um Aktionen, die auf den Tags einer Webfunktion basieren, zuzulassen oder zu verweigern. Informationen zu den unterstützten Bedingungsschlüsseln finden Sie unter. Webfunktionen taggen

Verwenden Sie ressourcenbasierte Richtlinien, wenn:

Öffentliche Richtlinien sind nicht zulässig

Sie können einer Webfunktion keine auf öffentlichen Ressourcen basierende Richtlinie zuordnen. Wenn eine Richtlinie öffentlich ist, schlägt die Anfrage mit einem fehl. ValidationException

In diesem Abschnitt beschreibt public eine Richtlinie, die Zugriff auf eine nicht spezifizierte Gruppe von Prinzipalen gewährt. Sie beschreibt nicht den Netzwerkzugriff oder den Authentifizierungstyp des Endpunkts.

Was macht eine Richtlinie öffentlich

Eine Richtlinie ist öffentlich, es sei denn, sie beschränkt, wer die Ressource aufrufen kann, auf eine genau spezifizierte Gruppe von Prinzipalen. Lambda geht davon aus, dass die Richtlinie öffentlich ist, und bewertet dann, ob sie als nicht öffentlich gilt. Eine Richtlinie ist öffentlich, wenn sie einen Prinzipal zulässt, von dem jeder AWS Kunde ausgehen könnte. Der häufigste Fall ist ein uneingeschränkter Platzhalterprinzipal, wie im folgenden Beispiel. Lambda lehnt diese Richtlinie mit einem ab. ValidationException Benutze es nicht.

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "lambda:InvokeWebFunctionEndpoint",
  "Resource": "arn:aws:lambda:us-west-2:123456789012:web-function/my-web-function/endpoint/prod"
}

Die folgenden Einschränkungen machen eine Richtlinie nicht unveröffentlicht:

Es gibt zwei Möglichkeiten, eine Richtlinie nicht öffentlich zu machen.

Geben Sie die Principals im Principal-Block an

Listet einen oder mehrere vollständig angegebene Prinzipale im Block aufPrincipal. Die Werte dürfen keine Platzhalter oder Richtlinienvariablen enthalten. Die Anzahl der Principals spielt keine Rolle.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "123456789012",
      "111122223333"
    ]
  },
  "Action": "lambda:InvokeWebFunctionEndpoint",
  "Resource": "arn:aws:lambda:us-west-2:123456789012:web-function/my-web-function/endpoint/prod"
}

Ein IAM-Prinzipal in einem anderen Konto benötigt ebenfalls eine identitätsbasierte Berechtigung, um den Endpunkt aufzurufen.

Verwenden Sie einen vertrauenswürdigen Bedingungsschlüssel

Beschränken Sie einen der folgenden Bedingungsschlüssel auf einen festen Wert. Diese Schlüssel identifizieren den authentifizierten Anrufer und können nicht vom Anforderer festgelegt werden.

Die Benennung eines vertrauenswürdigen Schlüssels allein reicht nicht aus. Sie müssen den Wert auch einschränken:

Die folgende Richtlinie gewährt Prinzipalen in Ihrer Organisation die ressourcenbasierte Berechtigung, die zum Aufrufen des Endpunkts erforderlich ist. Sie gilt nicht als öffentlich. Ein IAM-Prinzipal in einem anderen Konto benötigt ebenfalls eine identitätsbasierte Berechtigung.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOrgAccess",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "lambda:InvokeWebFunctionEndpoint",
      "Resource": "arn:aws:lambda:us-west-2:123456789012:web-function/my-web-function/endpoint/prod",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-a1b2c3d4e5"
        }
      }
    }
  ]
}

Cross-account Zugriff

Die folgende ressourcenbasierte Richtlinie gewährt einer bestimmten IAM-Rolle in einem anderen Konto die Berechtigung, einen Endpunkt Ihrer Webfunktion aufzurufen. Die Rolle benötigt außerdem eine identitätsbasierte Berechtigung, um den Endpunkt aufzurufen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCrossAccountInvoke",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::444455556666:role/caller-role"
            },
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod"
        }
    ]
}

Damit der kontenübergreifende Aufruf erfolgreich ist, müssen alle der folgenden Bedingungen erfüllt sein:

Gewährung des Zugriffs auf ein AWS Service nicht zulässig

Die folgende ressourcenbasierte Richtlinie gewährt dem CloudFront Dienstprinzipal die Erlaubnis, Ihre Webfunktion aufzurufen. Verwenden Sie diese Richtlinie, wenn Sie eine CloudFront Distribution mit Ihrem Web Function-Endpunkt als Ursprung konfigurieren.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontInvoke",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "lambda:InvokeWebFunctionEndpoint",
            "Resource": "arn:aws:lambda:us-east-1:111122223333:web-function/my-function/endpoint/prod",
            "Condition": {
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
                }
            }
        }
    ]
}

Die aws:SourceArn Bedingung schränkt den Zugriff auf eine bestimmte CloudFront Distribution ein. Ohne diese Bedingung könnte jede CloudFront Verteilung in einem beliebigen Konto Ihre Webfunktion aufrufen.

Replikation und letztendliche Konsistenz

Wenn Sie eine ressourcenbasierte Richtlinie an eine Webfunktion anhängen oder aktualisieren, die über PerRegionEndpunkte verfügt MultiRegion, repliziert Lambda die Richtlinie auf alle AWS-Regionen Replikate, auf denen die Endgeräte betrieben werden. Diese Replikation ist letztendlich konsistent.

Während des Replikationsfensters bewertet Lambda möglicherweise Anfragen in Replikatregionen anhand der vorherigen Version der Richtlinie. Das bedeutet Folgendes:

Es gibt kein für den Kunden sichtbares Abschlusssignal für die Richtlinienreplikation. Testen Sie das erwartete Zulassen- oder Ablehnungsverhalten in jeder Endpunktregion, bevor Sie sich auf die neue Richtlinie verlassen. throttleConfig.rateLimitUm Notfälle einzudämmen, aktualisieren Sie das Routing des Datenverkehrs oder stellen Sie die Endgeräte so ein, 0 dass der gesamte Datenverkehr blockiert wird, solange sich die Richtlinienänderung verbreitet. Weitere Informationen finden Sie unter Drosselung.

Für HomeRegionEndgeräte gilt die Richtlinie nur in der Heimatregion und erfordert keine regionsübergreifende Replikation. Es kann immer noch eine Weile dauern, bis eine Änderung wirksam wird.

Berechtigungen für die Netzwerkkonfiguration

Die Identität, die das Netzwerk konfiguriert, benötigt die Erlaubnis, die entsprechenden Lambda-Ressourcen zu erstellen oder zu aktualisieren. Außerdem benötigt sie die Erlaubnis, die erforderlichen Rollen und den Konnektor zu übergeben. Je nach Vorgang umfassen die Berechtigungen:

Der Anrufer muss lambda:PassNetworkConnector auf dem Connector, auf den verwiesen wird, immer wenn ein create-web-function create-web-function-revision Oder-Aufruf gesetzt egressNetworkConnectorArn wird, aktiviert sein. Schränken Sie diese Berechtigung auf genehmigte Connector-Ressourcen ein. Der Geltungsbereich erstreckt iam:PassRole sich auf genehmigte Ausführungsrollen, die Sie beim Erstellen einer Webfunktion oder -version übergeben, und auf genehmigte Operatorrollen, die Sie beim Erstellen oder Aktualisieren eines Netzwerkconnectors übergeben. Informationen zur Richtlinie über Berechtigungen für Operatorrollen finden Sie unterBerechtigungen für die Operatorrolle.