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.
# Konfiguration von Autorisierung und Authentifizierung zur Sicherung Ihres GraphQL APIs
AWS AppSync bietet die folgenden Autorisierungstypen zur Sicherung von GraphQL APIs: API-Schlüssel, Lambda, IAM, OpenID Connect und Cognito User Pools. Jede Option bietet eine andere Sicherheitsmethode:
1. **API-Schlüsselautorisierung**: Steuert die Drosselung für nicht authentifizierte Benutzer und bietet so eine APIs einfache Sicherheitsoption.
1. **Lambda-Autorisierung**: Aktiviert eine benutzerdefinierte Autorisierungslogik, die Funktionseingaben und -ausgaben detailliert erklärt.
1. **IAM-Autorisierung**: Nutzt den Signaturprozess AWS der Version 4, der eine detaillierte Zugriffskontrolle durch IAM-Richtlinien ermöglicht.
1. **OpenID Connect-Autorisierung**: Lässt sich in OIDC-konforme Dienste zur Benutzerauthentifizierung integrieren.
1. **Cognito-Benutzerpools**: Implementiert eine gruppenbasierte Zugriffskontrolle mithilfe der Benutzerverwaltungsfunktionen von Cognito.
## Autorisierungstypen
Es gibt fünf Möglichkeiten, Anwendungen für die Interaktion mit Ihrer AWS AppSync GraphQL-API zu autorisieren. Sie geben an, welchen Autorisierungstyp Sie verwenden, indem Sie in Ihrem AWS AppSync API- oder CLI-Aufruf einen der folgenden Autorisierungstypwerte angeben:
+
** `API_KEY` **
Für die Verwendung von API-Schlüsseln.
+
** `AWS_LAMBDA` **
Für die Verwendung einer AWS Lambda Funktion.
+
** `AWS_IAM` **
Für die Verwendung von AWS Identity and Access Management ([IAM](https://aws.amazon.com/iam/) -) Berechtigungen.
+
** `OPENID_CONNECT` **
Für die Verwendung Ihres OpenID Connect-Anbieters.
+
** `AMAZON_COGNITO_USER_POOLS` **
Für die Verwendung eines Amazon Cognito Cognito-Benutzerpools.
Diese grundlegenden Autorisierungstypen funktionieren für die meisten Entwickler. Für fortgeschrittenere Anwendungsfälle können Sie zusätzliche Autorisierungsmodi über die Konsole, die CLI und hinzufügen AWS CloudFormation. AWS AppSync Stellt für zusätzliche Autorisierungsmodi einen Autorisierungstyp bereit, der die oben aufgeführten Werte verwendet (d. `API_KEY` h.`AWS_LAMBDA`,`AWS_IAM`,`OPENID_CONNECT`, und`AMAZON_COGNITO_USER_POOLS`).
Wenn Sie `API_KEY``AWS_LAMBDA`, oder `AWS_IAM` als Haupt- oder Standardautorisierungstyp angeben, können Sie sie nicht erneut als einen der zusätzlichen Autorisierungsmodi angeben. Ebenso können Sie die zusätzlichen Autorisierungsmodi nicht duplizieren `API_KEY` `AWS_LAMBDA` oder `AWS_IAM` innerhalb der zusätzlichen Autorisierungsmodi verwenden. Sie können mehrere Amazon Cognito Cognito-Benutzerpools und OpenID Connect-Anbieter verwenden. Sie können jedoch keine doppelten Amazon Cognito Cognito-Benutzerpools oder OpenID Connect-Anbieter zwischen dem Standardautorisierungsmodus und einem der zusätzlichen Autorisierungsmodi verwenden. Sie können verschiedene Clients für Ihren Amazon Cognito Cognito-Benutzerpool oder OpenID Connect-Anbieter angeben, indem Sie den entsprechenden regulären Konfigurationsausdruck verwenden.
Wenn Sie Änderungen an Ihrer API-Konfiguration speichern, AWS AppSync beginnt die Übertragung der Änderungen. Solange Ihre Konfigurationsänderung nicht übernommen wurde, werden AWS AppSync weiterhin Ihre Inhalte aus der vorherigen Konfiguration bereitgestellt. Sobald Ihre Konfigurationsänderung übernommen wurde, wird AWS AppSync sofort mit der Bereitstellung Ihrer Inhalte auf der Grundlage der neuen Konfiguration begonnen. Während AWS AppSync Ihre Änderungen für eine API übertragen werden, können wir nicht anhand der vorherigen Konfiguration oder der neuen Konfiguration feststellen, ob die API Ihre Inhalte bereitstellt.
## API\$1KEY Autorisierung
Für nicht authentifizierte ist eine strengere Drosselung APIs erforderlich als für authentifizierte. APIs Eine Möglichkeit zur Kontrolle der Ablehnung für nicht authentifizierte GraphQL-Endpunkte ist die Verwendung von API-Schlüsseln. Ein API-Schlüssel ist ein hartcodierter Wert in Ihrer Anwendung, der vom AWS AppSync-Service beim Erstellen eines nicht authentifizierten GraphQL-Endpunktes generiert wird. Sie können API-Schlüssel von der Konsole, von der CLI oder von der [AWS AppSync API-Referenz](https://docs.aws.amazon.com/appsync/latest/APIReference/) aus rotieren.
------
#### [ Console ]
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/).
1. Wählen Sie im **APIs Dashboard** Ihre GraphQL-API aus.
1. **Wählen Sie in der **Seitenleiste** Einstellungen.**
1. Wählen Sie unter **Standardautorisierungsmodus** die Option **API-Schlüssel** aus.
1. Wählen Sie in der Tabelle mit den **API-Schlüsseln** die Option **API-Schlüssel hinzufügen** aus.
In der Tabelle wird ein neuer API-Schlüssel generiert.
1. Um einen alten API-Schlüssel zu löschen, wählen Sie den API-Schlüssel in der Tabelle aus und wählen Sie dann **Löschen**.
1. Wählen Sie unten auf der Seite die Option **Save** aus.
------
#### [ CLI ]
1. Falls Sie dies noch nicht getan haben, konfigurieren Sie Ihren Zugriff auf die AWS CLI. Weitere Informationen finden Sie unter [Grundlagen der Konfiguration](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-quickstart.html).
1. Erstellen Sie ein GraphQL-API-Objekt, indem Sie den [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-graphql-api.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/appsync/update-graphql-api.html)Befehl ausführen.
Sie müssen zwei Parameter für diesen speziellen Befehl eingeben:
1. Die `api-id` Ihrer GraphQL-API.
1. Das Neue `name` Ihrer API. Sie können dasselbe verwenden`name`.
1. Das`authentication-type`, was sein wird`API_KEY`.
**Anmerkung**
Es gibt andere Parameter wie diesen`Region`, die konfiguriert werden müssen, aber normalerweise werden sie standardmäßig auf Ihre CLI-Konfigurationswerte gesetzt.
Ein Beispielbefehl könnte wie folgt aussehen:
```
aws appsync update-graphql-api --api-id abcdefghijklmnopqrstuvwxyz --name TestAPI --authentication-type API_KEY
```
Eine Ausgabe wird in der CLI zurückgegeben. Hier ist ein Beispiel in JSON:
```
{
"graphqlApi": {
"xrayEnabled": false,
"name": "TestAPI",
"authenticationType": "API_KEY",
"tags": {},
"apiId": "abcdefghijklmnopqrstuvwxyz",
"uris": {
"GRAPHQL": "https://s8i3kk3ufhe9034ujnv73r513e.appsync-api.us-west-2.amazonaws.com/graphql",
"REALTIME": "wss://s8i3kk3ufhe9034ujnv73r513e.appsync-realtime-api.us-west-2.amazonaws.com/graphql"
},
"arn": "arn:aws:appsync:us-west-2:348581070237:apis/abcdefghijklmnopqrstuvwxyz"
}
}
```
------
API-Schlüssel sind für bis zu 365 Tage konfigurierbar und Sie können diese ab dem Ablaufdatum für bis zu weitere 365 Tage verlängern. API-Schlüssel werden für Entwicklungszwecke oder Anwendungsfälle empfohlen, bei denen die Bereitstellung einer öffentliche API sicher ist.
Auf dem Client ist der API-Schlüssel mit dem Header `x-api-key` angegeben.
Wenn z. B. der Wert Ihres `API_KEY` `'ABC123'` lautet, können Sie über `curl` eine GraphQL-Abfrage senden. Gehen Sie dazu wie folgt vor:
```
$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql
```
## AWS\$1LAMBDA Autorisierung
Sie können Ihre eigene API-Autorisierungslogik mithilfe einer AWS Lambda Funktion implementieren. Sie können eine Lambda-Funktion entweder für Ihren primären oder sekundären Autorisierer verwenden, aber es kann nur eine Lambda-Autorisierungsfunktion pro API geben. Bei der Verwendung von Lambda-Funktionen für die Autorisierung gilt Folgendes:
+ Wenn für die API die Modi `AWS_LAMBDA` und `AWS_IAM` Autorisierung aktiviert sind, kann die SigV4-Signatur nicht als `AWS_LAMBDA` Autorisierungstoken verwendet werden.
+ Wenn für die API die `OPENID_CONNECT` Autorisierungsmodi `AWS_LAMBDA` und oder der `AMAZON_COGNITO_USER_POOLS` Autorisierungsmodus aktiviert sind, kann das OIDC-Token nicht als Autorisierungstoken verwendet werden. `AWS_LAMBDA` Beachten Sie, dass es sich bei dem OIDC-Token um ein Bearer-Schema handeln kann.
+ Eine Lambda-Funktion darf nicht mehr als 5 MB an Kontextdaten für Resolver zurückgeben.
Wenn Ihr Autorisierungstoken beispielsweise lautet`'ABC123'`, können Sie eine GraphQL-Abfrage über curl wie folgt senden:
```
$ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query":
"query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql
```
Lambda-Funktionen werden vor jeder Abfrage oder Mutation aufgerufen. Der Rückgabewert kann basierend auf der API-ID und dem Authentifizierungstoken zwischengespeichert werden. Wenn eine Lambda-Autorisierungsantwort weniger als 1.048.576 Byte umfasst, wird die Antwort für nachfolgende Anfragen AWS AppSync zwischengespeichert. Wenn die Antwort des Lambda-Autorisierers gleich oder größer als 1.048.576 Byte ist, wird die Antwort AWS AppSync nicht zwischengespeichert und der Lambda-Authorizer wird für jede eingehende Anfrage aufgerufen. Um die Leistung zu optimieren und die Kosten für Lambda-Aufrufe zu minimieren, empfehlen wir Ihnen, Ihre Lambda-Autorisierungsantworten auf 1.048.576 Byte zu beschränken. Standardmäßig ist das Caching nicht aktiviert, aber es kann auf API-Ebene oder durch Setzen des Werts im Rückgabewert einer Funktion aktiviert werden. `ttlOverride`
Bei Bedarf kann ein regulärer Ausdruck angegeben werden, der Autorisierungstoken validiert, bevor die Funktion aufgerufen wird. Diese regulären Ausdrücke werden verwendet, um zu überprüfen, ob ein Autorisierungstoken das richtige Format hat, bevor Ihre Funktion aufgerufen wird. Jede Anfrage, die ein Token verwendet, das nicht mit diesem regulären Ausdruck übereinstimmt, wird automatisch abgelehnt.
Lambda-Funktionen, die für die Autorisierung verwendet werden, erfordern, `appsync.amazonaws.com` dass eine Hauptrichtlinie auf sie angewendet wird, AWS AppSync damit sie aufgerufen werden können. Diese Aktion wird automatisch in der AWS AppSync Konsole ausgeführt. Die AWS AppSync Konsole entfernt die Richtlinie *nicht*. Weitere Informationen zum Anhängen von Richtlinien an Lambda-Funktionen finden Sie unter [Ressourcenbasierte Richtlinien](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) im Entwicklerhandbuch. AWS Lambda
Die von Ihnen angegebene Lambda-Funktion erhält ein Ereignis mit der folgenden Form:
```
{
"authorizationToken": "ExampleAUTHtoken123123123",
"requestContext": {
"apiId": "aaaaaa123123123example123",
"accountId": "111122223333",
"requestId": "f4081827-1111-4444-5555-5cf4695f339f",
"queryString": "mutation CreateEvent {...}\n\nquery MyQuery {...}\n",
"operationName": "MyQuery",
"variables": {}
}
"requestHeaders": {
application request headers
}
}
```
Das `event` Objekt enthält die Header, die in der Anfrage vom Anwendungsclient an gesendet wurden. AWS AppSync
Die Autorisierungsfunktion muss mindestens einen booleschen Wert zurückgeben`isAuthorized`, der angibt, ob die Anfrage autorisiert ist. AWS AppSync erkennt die folgenden Schlüssel, die von Lambda-Autorisierungsfunktionen zurückgegeben wurden:
**Anmerkung**
Der Wert für den `operationName` in der Operation `requestContext` for a WebSocket connect wird mit "`DeepDish:Connect`" AWS AppSync gesetzt.
### Funktionsliste
`isAuthorized`(boolescher Wert, erforderlich)
Ein boolescher Wert, der angibt, ob der Wert in berechtigt `authorizationToken` ist, Aufrufe an die GraphQL-API zu tätigen.
Wenn dieser Wert wahr ist, wird die Ausführung der GraphQL-API fortgesetzt. Wenn dieser Wert falsch ist, `UnauthorizedException` wird an ausgelöst
`deniedFields`(Liste der Zeichenketten, optional)
Eine Liste, in die zwangsweise geändert wird`null`, auch wenn ein Wert von einem Resolver zurückgegeben wurde.
Jeder Artikel ist entweder ein vollständig qualifizierter Feld-ARN in der Form von `arn:aws:appsync:us-east-1:111122223333:apis/GraphQLApiId/types/TypeName/fields/FieldName` oder eine Kurzform von`TypeName.FieldName`. Das vollständige ARN-Formular sollte verwendet werden, wenn sich zwei einen Lambda-Funktionsautorisierer APIs teilen und es zu Unklarheiten zwischen gemeinsamen Typen und Feldern zwischen den beiden kommen kann. APIs
`resolverContext`(JSON-Objekt, optional)
Ein JSON-Objekt, das wie `$ctx.identity.resolverContext` in Resolver-Vorlagen sichtbar ist. Zum Beispiel, wenn die folgende Struktur von einem Resolver zurückgegeben wird:
```
{
"isAuthorized":true
"resolverContext": {
"banana":"very yellow",
"apple":"very green"
}
}
```
Der Wert von `ctx.identity.resolverContext.apple` in Resolver-Vorlagen wird "“ `very green` sein. Das `resolverContext` Objekt unterstützt nur Schlüssel-Wert-Paare. Verschachtelte Schlüssel werden nicht unterstützt.
Die Gesamtgröße dieses JSON-Objekts darf 5 MB nicht überschreiten.
`ttlOverride`(Ganzzahl, optional)
Die Anzahl der Sekunden, für die die Antwort zwischengespeichert werden soll. Wenn kein Wert zurückgegeben wird, wird der Wert aus der API verwendet. Wenn dieser Wert 0 ist, wird die Antwort nicht zwischengespeichert.
Lambda-Autorisierer haben ein Standard-Timeout von 10 Sekunden, bei Spitzenverkehr kann es jedoch zu einem früheren Timeout kommen. Wir empfehlen, Funktionen so zu entwerfen, dass sie in möglichst kurzer Zeit (unter 1 Sekunde) ausgeführt werden, um die Leistung Ihrer API zu skalieren.
Mehrere AWS AppSync APIs können sich eine einzige Authentifizierungs-Lambda-Funktion teilen. Die kontoübergreifende Verwendung von Autorisierern ist nicht zulässig.
Wenn Sie eine Autorisierungsfunktion von mehreren Personen gemeinsam nutzen APIs, beachten Sie, dass Kurzform-Feldnamen (`typename.fieldname`) versehentlich Felder verbergen können. Um ein Feld in eindeutig zu kennzeichnen`deniedFields`, können Sie einen eindeutigen Feld-ARN in der Form von angeben. `arn:aws:appsync:region:accountId:apis/GraphQLApiId/types/typeName/fields/fieldName`
Um eine Lambda-Funktion als Standard-Autorisierungsmodus hinzuzufügen in AWS AppSync:
------
#### [ Console ]
1. Melden Sie sich bei der AWS AppSync Konsole an und navigieren Sie zu der API, die Sie aktualisieren möchten.
1. Navigieren Sie zur Einstellungsseite für Ihre API.
Ändern Sie die Autorisierung auf API-Ebene auf. **AWS Lambda**
1. Wählen Sie den AWS-Region und den Lambda-ARN aus, für den API-Aufrufe autorisiert werden sollen.
**Anmerkung**
Die entsprechende Prinzipalrichtlinie wird automatisch hinzugefügt, sodass AWS AppSync Sie Ihre Lambda-Funktion aufrufen können.
1. Legen Sie optional die Antwort-TTL und den regulären Ausdruck für die Token-Validierung fest.
------
#### [ AWS CLI ]
1. Hängen Sie die folgende Richtlinie an die verwendete Lambda-Funktion an:
```
aws lambda add-permission --function-name "my-function" --statement-id "appsync" --principal appsync.amazonaws.com --action lambda:InvokeFunction --output text
```
**Wichtig**
Wenn Sie möchten, dass die Richtlinie der Funktion an eine einzelne GraphQL-API gebunden ist, können Sie diesen Befehl ausführen:
```
aws lambda add-permission --function-name “my-function” --statement-id “appsync” --principal appsync.amazonaws.com --action lambda:InvokeFunction --source-arn “” --output text
```
1. Aktualisieren Sie Ihre AWS AppSync API, um die angegebene Lambda-Funktion ARN als Autorisierer zu verwenden:
```
aws appsync update-graphql-api --api-id example2f0ur2oid7acexample --name exampleAPI --authentication-type AWS_LAMBDA --lambda-authorizer-config authorizerUri="arn:aws:lambda:us-east-2:111122223333:function:my-function"
```
**Anmerkung**
Sie können auch andere Konfigurationsoptionen wie den regulären Token-Ausdruck einbeziehen.
------
Das folgende Beispiel beschreibt eine Lambda-Funktion, die die verschiedenen Authentifizierungs- und Fehlerzustände demonstriert, die eine Lambda-Funktion haben kann, wenn sie als AWS AppSync Autorisierungsmechanismus verwendet wird:
```
def handler(event, context):
# This is the authorization token passed by the client
token = event.get('authorizationToken')
# If a lambda authorizer throws an exception, it will be treated as unauthorized.
if 'Fail' in token:
raise Exception('Purposefully thrown exception in Lambda Authorizer.')
if 'Authorized' in token and 'ReturnContext' in token:
return {
'isAuthorized': True,
'resolverContext': {
'key': 'value'
}
}
# Authorized with no f
if 'Authorized' in token:
return {
'isAuthorized': True
}
# Partial authorization
if 'Partial' in token:
return {
'isAuthorized': True,
'deniedFields':['user.favoriteColor']
}
if 'NeverCache' in token:
return {
'isAuthorized': True,
'ttlOverride': 0
}
if 'Unauthorized' in token:
return {
'isAuthorized': False
}
# if nothing is returned, then the authorization fails.
return {}
```
### Umgehung der Autorisierungsbeschränkungen für SigV4- und OIDC-Tokens
Die folgenden Methoden können verwendet werden, um das Problem zu umgehen, dass Sie Ihre SigV4-Signatur oder Ihr OIDC-Token nicht als Lambda-Autorisierungstoken verwenden können, wenn bestimmte Autorisierungsmodi aktiviert sind.
Wenn Sie die SigV4-Signatur als Lambda-Autorisierungstoken verwenden möchten, wenn die Autorisierungsmodi `AWS_IAM` und die `AWS_LAMBDA` Autorisierungsmodi für AWS AppSync die API aktiviert sind, gehen Sie wie folgt vor:
+ Um ein neues Lambda-Autorisierungstoken zu erstellen, fügen Sie der SigV4-Signatur zufällige and/or Suffix-Präfixe hinzu.
+ Um die ursprüngliche Sigv4-Signatur abzurufen, aktualisieren Sie Ihre Lambda-Funktion, indem Sie die zufälligen and/or Präfix-Suffixe aus dem Lambda-Autorisierungstoken entfernen. Verwenden Sie dann die ursprüngliche SigV4-Signatur zur Authentifizierung.
Wenn Sie das OIDC-Token als Lambda-Autorisierungstoken verwenden möchten, wenn der Autorisierungsmodus oder die `OPENID_CONNECT` Autorisierungsmodi `AMAZON_COGNITO_USER_POOLS` und die `AWS_LAMBDA` Autorisierungsmodi für AWS AppSync die API aktiviert sind, gehen Sie wie folgt vor:
+ Um ein neues Lambda-Autorisierungstoken zu erstellen, fügen Sie dem OIDC-Token zufällige and/or Suffix-Präfixe hinzu. Das Lambda-Autorisierungstoken sollte kein Bearer-Schema-Präfix enthalten.
+ Um das ursprüngliche OIDC-Token abzurufen, aktualisieren Sie Ihre Lambda-Funktion, indem Sie die zufälligen and/or Präfix-Suffixe aus dem Lambda-Autorisierungstoken entfernen. Verwenden Sie dann das ursprüngliche OIDC-Token zur Authentifizierung.
## AWS\$1IAM Autorisierung
Dieser Autorisierungstyp erzwingt den [AWS Signaturprozess der Signaturversion 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) auf der GraphQL-API. Sie können vordefinierte Zugriffsrichtlinien für Identity and Access Management ([IAM](https://aws.amazon.com/iam/)) mit diesem Autorisierungstyp verknüpfen. Ihre Anwendung kann diese Zuordnung nutzen, indem sie einen Zugriffsschlüssel (der aus einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel besteht) oder kurzlebige, temporäre Anmeldeinformationen verwendet, die von Amazon Cognito Federated Identities bereitgestellt werden.
Wenn Sie eine Rolle möchten, die Zugriff darauf hat, alle Datenoperationen durchzuführen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"appsync:GraphQL"
],
"Resource": [
"arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*"
]
}
]
}
```
------
Sie finden es auf `YourGraphQLApiId` der API-Hauptseite in der AppSync Konsole direkt unter dem Namen Ihrer API. Alternativ können Sie sie mit der CLI abrufen: `aws appsync list-graphql-apis`.
Wenn Sie den Zugriff auf nur bestimmte GraphQL-Operationen einschränken möchten, können Sie dies für die Stammfelder `Query`, `Mutation` und `Subscription` tun.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"appsync:GraphQL"
],
"Resource": [
"arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/",
"arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/",
"arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/",
"arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/"
]
}
]
}
```
------
Angenommen, Sie haben das folgende Schema und Sie möchten den Zugriff zum Abrufen aller Beiträge beschränken:
```
schema {
query: Query
mutation: Mutation
}
type Query {
posts:[Post!]!
}
type Mutation {
addPost(id:ID!, title:String!):Post!
}
```
Die entsprechende IAM-Richtlinie für eine Rolle (die Sie beispielsweise an einen Amazon Cognito Cognito-Identitätspool anhängen könnten) würde wie folgt aussehen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"appsync:GraphQL"
],
"Resource": [
"arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/posts"
]
}
]
}
```
------
## OPENID\$1CONNECT Autorisierung
Dieser Autorisierungstyp erzwingt [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) (OIDC) -Token, die von einem OIDC-kompatiblen Dienst bereitgestellt werden. Ihre Anwendung kann Benutzer und Berechtigungen nutzen, die von Ihrem OIDC-Anbieter zur Kontrolle des Zugriffs definiert wurden.
Eine Aussteller-URL ist der einzige erforderliche Konfigurationswert, den Sie AWS AppSync bereitstellen, (z. B. `https://auth.example.com`). Diese URL muss über HTTPS adressierbar sein. AWS AppSync [hängt `/.well-known/openid-configuration` an die Aussteller-URL an und lokalisiert die OpenID-Konfiguration `https://auth.example.com/.well-known/openid-configuration` gemäß der OpenID Connect Discovery-Spezifikation.](https://openid.net/specs/openid-connect-discovery-1_0.html) Es wird erwartet, dass unter dieser URL ein [RFC5785](https://tools.ietf.org/html/rfc5785)konformes JSON-Dokument abgerufen wird. Dieses JSON-Dokument muss einen `jwks_uri` Schlüssel enthalten, der auf das JWKS-Dokument (JSON Web Key Set) mit den Signaturschlüsseln verweist. AWS AppSync erfordert, dass das JWKS die JSON-Felder und enthält. `kty` `kid`
AWS AppSync unterstützt eine Vielzahl von Signaturalgorithmen.
| Signaturalgorithmen |
| --- |
| RS256 |
| RS384 |
| RS512 |
| PS256 |
| PS384 |
| PS512 |
| HS256 |
| HS384 |
| HS512 |
| ES256 |
| ES384 |
| ES512 |
Wir empfehlen Ihnen, die RSA-Algorithmen zu verwenden. Token, die vom Anbieter ausgestellt wurden, müssen die Uhrzeit, zu der das Token ausgestellt wurde (`iat`), und den Zeitpunkt, zu dem es authentifiziert wurde (`auth_time`), enthalten. Sie können TTL-Werte für die ausgestellte Zeit (`iatTTL`) und die Authentifizierungszeit (`authTTL`) in Ihrer OpenID Connect-Konfiguration zur zusätzlichen Validierung bereitstellen. Wenn Ihr Anbieter mehrere Anwendungen autorisiert, können Sie auch einen regulären Ausdruck (`clientId`) angeben, der von der Client-ID zur Autorisierung verwendet wird. Wenn das in Ihrer OpenID Connect-Konfiguration vorhanden `clientId` ist, AWS AppSync validiert es den Anspruch, indem es verlangt, dass der `clientId` entweder mit dem `aud` oder `azp` -Anspruch im Token übereinstimmt.
Um mehrere Clients zu validieren, IDs verwenden Sie den Pipeline-Operator („\$1“), der im regulären Ausdruck ein „oder“ ist. Wenn Ihre OIDC-Anwendung beispielsweise über vier Clients mit einem Client IDs wie 0A1S2D, 1F4G9H, 1J6L4B, 6 MG verfügt, würden Sie, um nur die ersten drei Clients zu validieren, 1F4G9H\$11J6L4B\$16 GS5 MG in das Feld Client-ID eingeben. IDs GS5
Wenn eine API mit mehreren Autorisierungstypen konfiguriert ist, AWS AppSync validiert sie den im JWT-Token vorhandenen Aussteller (ISS-Anspruch) anhand der Anforderungsheader, indem er mit der in der API-Konfiguration angegebenen Aussteller-URL verglichen wird. Wenn eine API jedoch nur mit OPENID\$1CONNECT Autorisierung konfiguriert ist, wird dieser Schritt zur Überprüfung der Aussteller-URL AWS AppSync übersprungen.
## AMAZON\$1COGNITO\$1USER\$1POOLS Autorisierung
Dieser Autorisierungstyp erzwingt OIDC-Token, die von Amazon Cognito Cognito-Benutzerpools bereitgestellt werden. Ihre Anwendung kann die Benutzer und Gruppen sowohl in Ihren Benutzerpools als auch in Benutzerpools von einem anderen AWS Konto nutzen und diese mit GraphQL-Feldern verknüpfen, um den Zugriff zu kontrollieren.
Wenn Sie Amazon Cognito User Pools verwenden, können Sie Gruppen erstellen, denen Benutzer angehören. Diese Informationen sind in einem JWT-Token kodiert, an das Ihre Anwendung beim Senden von AWS AppSync GraphQL-Operationen in einem Autorisierungsheader sendet. Sie können GraphQL-Richtlinien für das Schema verwenden, um zu steuern, welche Gruppen welche Resolver auf einem Feld aufrufen können, wodurch Ihren Kunden mehr kontrollierter Zugriff gewährt wird.
Angenommen, Sie haben das folgende GraphQL-Schema:
```
schema {
query: Query
mutation: Mutation
}
type Query {
posts:[Post!]!
}
type Mutation {
addPost(id:ID!, title:String!):Post!
}
...
```
Wenn Sie zwei Gruppen in Amazon Cognito Cognito-Benutzerpools haben — Blogger und Leser — und Sie die Anzahl der Leser einschränken möchten, sodass sie keine neuen Einträge hinzufügen können, sollte Ihr Schema wie folgt aussehen:
```
schema {
query: Query
mutation: Mutation
}
```
```
type Query {
posts:[Post!]!
@aws_auth(cognito_groups: ["Bloggers", "Readers"])
}
type Mutation {
addPost(id:ID!, title:String!):Post!
@aws_auth(cognito_groups: ["Bloggers"])
}
...
```
Beachten Sie, dass Sie die `@aws_auth` Direktive weglassen können, wenn Sie standardmäßig eine bestimmte grant-or-deny Zugriffsstrategie verwenden möchten. Sie können die grant-or-deny Strategie in der Benutzerpool-Konfiguration angeben, wenn Sie Ihre GraphQL-API über die Konsole oder über den folgenden CLI-Befehl erstellen:
```
$ aws appsync --region us-west-2 create-graphql-api --authentication-type AMAZON_COGNITO_USER_POOLS --name userpoolstest --user-pool-config '{ "userPoolId":"test", "defaultEffect":"ALLOW", "awsRegion":"us-west-2"}'
```
## Verwenden zusätzlicher Autorisierungsmodi
Wenn Sie zusätzliche Autorisierungsmodi hinzufügen, können Sie die Autorisierungseinstellung direkt auf der AWS AppSync GraphQL-API-Ebene konfigurieren (d. h. das `authenticationType` Feld, das Sie direkt für das `GraphqlApi` Objekt konfigurieren können) und sie fungiert als Standard im Schema. Dies bedeutet, dass jeder Typ, der keine bestimmte Richtlinie hat, die Autorisierungseinstellung auf API-Ebene übergeben muss.
Auf Schemaebene können Sie zusätzliche Autorisierungsmodi mithilfe von Anweisungen für das Schema angeben. Sie können Autorisierungsmodi für einzelne Felder im Schema angeben. Beispielsweise würden Sie für die `API_KEY`-Autorisierung für Schemaobjekttypdefinitionen/-felder `@aws_api_key` verwenden. Die folgenden Anweisungen werden für Schemafelder und Objekttypdefinitionen unterstützt:
+ `@aws_api_key` – Zur Angabe, dass das Feld `API_KEY`-autorisiert ist.
+ `@aws_iam` – Zur Angabe, dass das Feld `AWS_IAM`-autorisiert ist.
+ `@aws_oidc` – Zur Angabe, dass das Feld `OPENID_CONNECT`-autorisiert ist.
+ `@aws_cognito_user_pools` – Zur Angabe, dass das Feld `AMAZON_COGNITO_USER_POOLS`-autorisiert ist.
+ `@aws_lambda` – Zur Angabe, dass das Feld `AWS_LAMBDA`-autorisiert ist.
Sie können die Richtlinie `@aws_auth` nicht zusammen mit zusätzlichen Autorisierungsmodi verwenden. `@aws_auth` funktioniert nur im Kontext der `AMAZON_COGNITO_USER_POOLS`-Autorisierung ohne zusätzliche Autorisierungsmodi. Sie können jedoch die `@aws_cognito_user_pools`-Anweisung anstelle der `@aws_auth`-Richtlinie verwenden, indem Sie dieselben Argumente verwenden. Der Hauptunterschied zwischen den beiden besteht darin, dass Sie für jede Feld- und Objekttypdefinition `@aws_cognito_user_pools` angeben können.
Um zu verstehen, wie die zusätzlichen Autorisierungsmodi funktionieren und wie sie in einem Schema angegeben werden können, sehen wir uns das folgende Schema an:
```
schema {
query: Query
mutation: Mutation
}
type Query {
getPost(id: ID): Post
getAllPosts(): [Post]
@aws_api_key
}
type Mutation {
addPost(
id: ID!
author: String!
title: String!
content: String!
url: String!
): Post!
}
type Post @aws_api_key @aws_iam {
id: ID!
author: String
title: String
content: String
url: String
ups: Int!
downs: Int!
version: Int!
}
...
```
Gehen Sie für dieses Schema davon aus, dass `AWS_IAM` dies der Standardautorisierungstyp auf der AWS AppSync GraphQL-API ist. Dies bedeutet, dass Felder, die keine Richtlinie haben, mit `AWS_IAM` geschützt werden. Dies ist beispielsweise der Fall für das Feld `getPost` des Typs `Query`. Mit Schemarichtlinien können Sie mehr als einen Autorisierungsmodus verwenden. Sie können beispielsweise einen zusätzlichen Autorisierungsmodus in der AWS AppSync GraphQL-API `API_KEY` konfiguriert haben, und Sie können ein Feld mithilfe der `@aws_api_key` Direktive markieren (z. B. `getAllPosts` in diesem Beispiel). Richtlinien funktionieren auf Feldebene, sodass Sie `API_KEY` auch Zugriff auf den Typ `Post` gewähren müssen. Sie können dies entweder tun, indem Sie jedes Feld des Typs `Post` mit einer Richtlinie markieren oder den Typ `Post` mit der Richtlinie `@aws_api_key` markieren.
Um den Zugriff auf Felder des Typs `Post` weiter einzuschränken, können Sie Anweisungen für einzelne Felder des Typs `Post` verwenden, wie im Folgenden gezeigt.
Sie können beispielsweise ein `restrictedContent`-Feld zum Typ `Post` hinzufügen und den Zugriff darauf mithilfe der Richtlinie `@aws_iam` einschränken. `AWS_IAM`-authentifizierte Anfragen könnten auf `restrictedContent` zugreifen, `API_KEY`-Anfragen wären dazu jedoch nicht fähig.
```
type Post @aws_api_key @aws_iam{
id: ID!
author: String
title: String
content: String
url: String
ups: Int!
downs: Int!
version: Int!
restrictedContent: String!
@aws_iam
}
...
```
## Differenzierte Zugriffskontrolle
Die vorstehenden Informationen zeigen, wie Sie den Zugriff auf bestimmte GraphQL-Felder beschränken oder gewähren. Wenn Sie Zugriffskontrollen für die Daten basierend auf bestimmten Bedingungen festlegen möchten (z. B. basierend auf dem Benutzer, der einen Aufruf ausführt, oder ob der Benutzer Eigentümer der Daten ist), können Sie dazu Zuweisungsvorlagen in Ihren Resolvern verwenden. Sie können auch eine komplexere Geschäftslogik durchführen, die wir in [Filtern von Informationen](#aws-appsync-filtering-information) beschreiben.
In diesem Abschnitt wird gezeigt, wie Sie mithilfe einer DynamoDB-Resolver-Mapping-Vorlage Zugriffskontrollen für Ihre Daten einrichten.
Bevor Sie fortfahren, sollten Sie, falls Sie mit Mapping-Vorlagen in nicht vertraut sind AWS AppSync, die [Resolver-Mapping-Vorlagenreferenz und die Resolver-Mapping-Vorlagenreferenz](resolver-mapping-template-reference.md#aws-appsync-resolver-mapping-template-reference) [für DynamoDB](resolver-mapping-template-reference-dynamodb.md#aws-appsync-resolver-mapping-template-reference-dynamodb) lesen.
Gehen Sie im folgenden Beispiel mit DynamoDB davon aus, dass Sie das vorherige Blogbeitragsschema verwenden und dass nur Benutzer, die einen Beitrag erstellt haben, ihn bearbeiten dürfen. Im Auswertungsverfahren würde der Benutzer dann z. B. mithilfe von Amazon Cognito-Benutzerpools Anmeldeinformationen in seiner Anwendung erhalten und anschließend diese Anmeldeinformationen als Teil einer GraphQL-Operation weiterleiten. Die Zuweisungsvorlage wird dann einen Wert aus den Anmeldeinformationen (z. B. den Benutzernamen) in einer bedingten Anweisung ersetzen, die anschließend mit einem Wert in Ihrer Datenbank verglichen wird.
![\[Diagram showing authentication flow from user login to database operation using AWS-Services.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/FGAC.png)
Um diese Funktionalität zu erhalten, fügen Sie ein GraphQL-Feld von `editPost` folgendermaßen hinzu:
```
schema {
query: Query
mutation: Mutation
}
type Query {
posts:[Post!]!
}
type Mutation {
editPost(id:ID!, title:String, content:String):Post
addPost(id:ID!, title:String!):Post!
}
...
```
Die Resolver-Zuweisungsvorlage für `editPost` (siehe Beispiel am Ende dieses Abschnitts) muss einen logischen Abgleich Ihres Datenspeichers durchführen, damit nur der Benutzer, der einen Beitrag erstellt hat, diesen auch bearbeiten kann. Da es sich um eine Bearbeitungsoperation handelt, entspricht sie einer `UpdateItem` in DynamoDB. Sie können vor der Durchführung der Aktion eine bedingte Prüfung mithilfe von Kontext, der zur Benutzeridentitätsvalidierung weitergeleitet wurde, vornehmen. Dieser wird in einem `Identity`-Objekt gespeichert, das die folgenden Werte hat:
```
{
"accountId" : "12321434323",
"cognitoIdentityPoolId" : "",
"cognitoIdentityId" : "",
"sourceIP" : "",
"caller" : "ThisistheprincipalARN",
"username" : "username",
"userArn" : "Sameasabove"
}
```
Um dieses Objekt in einem `UpdateItem` DynamoDB-Aufruf zu verwenden, müssen Sie die Benutzeridentitätsinformationen zum Vergleich in der Tabelle speichern. Als Erstes muss Ihre `addPost`-Mutation den Ersteller speichern. Als Zweites muss Ihre `editPost`-Mutation vor dem Update die bedingte Prüfung ausführen.
Hier ist ein Beispiel für den Resolver-Code für`addPost`, der die Benutzeridentität als Spalte speichert: `Author`
```
import { util, Context } from '@aws-appsync/utils';
import { put } from '@aws-appsync/utils/dynamodb';
export function request(ctx) {
const { id: postId, ...item } = ctx.args;
return put({
key: { postId },
item: { ...item, Author: ctx.identity.username },
condition: { postId: { attributeExists: false } },
});
}
export const response = (ctx) => ctx.result;
```
Beachten Sie, dass für das `Author`-Attribut die Daten aus dem `Identity`-Objekt der Anwendung übernommen werden.
Abschließend noch ein Beispiel für den Resolver-Code für`editPost`, der den Inhalt des Blogbeitrags nur aktualisiert, wenn die Anfrage von dem Benutzer kommt, der den Beitrag erstellt hat:
```
import { util, Context } from '@aws-appsync/utils';
import { put } from '@aws-appsync/utils/dynamodb';
export function request(ctx) {
const { id, ...item } = ctx.args;
return put({
key: { id },
item,
condition: { author: { contains: ctx.identity.username } },
});
}
export const response = (ctx) => ctx.result;
```
In diesem Beispiel wird ein verwendet`PutItem`, das alle Werte überschreibt, und nicht ein`UpdateItem`, aber das gleiche Konzept gilt für den `condition` Anweisungsblock.
## Informationen filtern
Es kann vorkommen, dass Sie die Antwort von Ihrer Datenquelle nicht steuern können, aber keine unnötigen Informationen an Clients in einem erfolgreichen Lese- oder Schreibvorgang der Datenquelle senden möchten. In diesen Fällen können Sie Informationen mithilfe einer Antwortzuweisungsvorlage filtern.
Nehmen wir beispielsweise an, Sie haben keinen geeigneten Index in der DynamoDB-Tabelle für Ihren Blogbeitrag (z. B. einen Index für). `Author` Sie könnten den folgenden Resolver verwenden:
```
import { util, Context } from '@aws-appsync/utils';
import { get } from '@aws-appsync/utils/dynamodb';
export function request(ctx) {
return get({ key: { ctx.args.id } });
}
export function response(ctx) {
if (ctx.result.author === ctx.identity.username) {
return ctx.result;
}
return null;
}
```
Der Request-Handler ruft das Element ab, auch wenn der Anrufer nicht der Autor ist, der den Beitrag erstellt hat. Um zu verhindern, dass alle Daten zurückgegeben werden, überprüft der Antworthandler, ob der Aufrufer mit dem Autor des Elements übereinstimmt. Wenn der Aufrufer nicht den Prüfkriterien entspricht, wird nur eine Null-Antwort zurückgegeben.
## Datenquellenzugriff
AWS AppSync kommuniziert mit Datenquellen mithilfe von Identity and Access Management ([IAM](https://aws.amazon.com/iam/)) -Rollen und Zugriffsrichtlinien. Wenn Sie eine bestehende Rolle verwenden, muss eine Vertrauensrichtlinie hinzugefügt werden, um die Rolle übernehmen AWS AppSync zu können. Die Vertrauensbeziehung sieht etwa wie folgt aus:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "appsync.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
------
Es ist wichtig, den Geltungsbereich der Zugriffsrichtlinie für die Rolle so zu verringern, dass nur die Berechtigungen für die minimal erforderliche Ressourcengruppe verfügbar sind. Wenn Sie die AppSync Konsole verwenden, um eine Datenquelle und eine Rolle zu erstellen, erfolgt dies automatisch für Sie. Wenn Sie jedoch eine integrierte Beispielvorlage aus der IAM-Konsole verwenden, um eine Rolle außerhalb der AWS AppSync-Konsole zu erstellen, wird der Berechtigungsumfang nicht automatisch auf eine Ressource beschränkt. Sie sollten dies tun, bevor Sie die Anwendung tatsächlich in Betrieb nehmen.
# Anwendungsfälle für die Zugriffskontrolle zur Sicherung von Anfragen und Antworten
Im Abschnitt [Sicherheit](security-authz.md#aws-appsync-security) haben Sie die unterschiedlichen Autorisierungsmodi für den Schutz Ihrer API kennengelernt und eine Einführung in detaillierte Autorisierungsmechanismen zum Verständnis der Konzepte und des Ablaufs erhalten. Da Sie mithilfe von GraphQL Resolver [Mapping-Vorlagen](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview) logische Operationen an Daten ausführen AWS AppSync können, können Sie Daten beim Lesen oder Schreiben auf sehr flexible Weise schützen, indem Sie eine Kombination aus Benutzeridentität, Bedingungen und Dateneinspeisung verwenden.
[Wenn Sie mit der Bearbeitung von AWS AppSync Resolvern nicht vertraut sind, lesen Sie das Programmierhandbuch.](resolver-mapping-template-reference-programming-guide.md#aws-appsync-resolver-mapping-template-reference-programming-guide)
## -Übersicht
Die Gewährung des Zugriffs auf Daten in einem System erfolgt traditionell über eine [Zugriffskontrollmatrix](https://en.wikipedia.org/wiki/Access_Control_Matrix), bei der sich die gewährten Berechtigungen aus einer Zeile (Ressource) und einer Spalte (Benutzer/Rolle) überschneiden.
AWS AppSync verwendet Ressourcen in Ihrem eigenen Konto und überträgt Identitätsinformationen (Benutzer/Rolle) in die GraphQL-Anfrage und -Antwort als [Kontextobjekt](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference), das Sie im Resolver verwenden können. Das bedeutet, dass Berechtigungen basierend auf der Resolver-Logik entweder für Schreib- oder Lesevorgänge entsprechend gewährt werden können. Befindet sich diese Logik auf Ressourcenebene, sodass beispielsweise nur bestimmte benannte Benutzer oder Gruppen Zugriff read/write auf eine bestimmte Datenbankzeile haben, müssen diese „Autorisierungsmetadaten“ gespeichert werden. AWS AppSync speichert keine Daten, daher müssen Sie diese Autorisierungsmetadaten zusammen mit den Ressourcen speichern, damit die Berechtigungen berechnet werden können. Autorisierungsmetadaten stellen in der Regel ein Attribut (Spalte) in einer DynamoDB-Tabelle dar, wie z. B. ein **Owner** oder eine Liste von Benutzern/Gruppen. Es können zum Beispiel die Attribute **Readers** und **Writers** vorliegen.
Im Allgemeinen bedeutet dies, dass Sie beim Lesen eines einzelnen Elements aus einer Datenquelle eine bedingte `#if () ... #end`-Anweisung in der Antwortvorlage ausführen, nachdem der Resolver den Lesevorgang aus der Datenquelle beendet hat. Bei der Prüfung werden normalerweise Benutzer- oder Gruppenwerte in `$context.identity` zur Prüfung der Mitgliedschaft anhand der Autorisierungsmetadaten verwendet, die von einem Lesevorgang zurückgegeben werden. Für mehrere Datensätze, wie z B. aus einer Tabelle `Scan` oder `Query` zurückgegebene Listen, senden Sie die Bedingungsprüfung mithilfe ähnlicher Benutzer- oder Gruppenwerte als Teil der Operation an die Datenquelle.
Entsprechend wenden Sie beim Schreiben von Daten eine bedingte Anweisung auf die Aktion an (z. B. `PutItem` oder `UpdateItem`), um zu sehen, ob der Benutzer oder die Gruppe, der bzw. die eine Mutation vornimmt, dazu berechtigt ist. Die Bedingung verwendet häufig einen Wert in `$context.identity` zum Vergleich mit den Autorisierungsmetadaten dieser Ressource. Für beide Anforderungs- und Antwortvorlagen können Sie benutzerdefinierte Header von Clients verwenden, um Validierungsprüfungen durchzuführen.
## Lesen von Daten
Wie oben erläutert, müssen die Autorisierungsmetadaten zum Durchführen einer Prüfung mit einer Ressource gespeichert oder an die GraphQL-Anforderung (Identität, Header usw.) weitergegeben werden. Um dies zu veranschaulichen, nehmen wir an, Sie haben die unten angegebene DynamoDB-Tabelle vorliegen:
![\[DynamoDB table with ID, Data, PeopleCanAccess, GroupsCanAccess, and Owner columns.\]](http://docs.aws.amazon.com/de_de/appsync/latest/devguide/images/auth.png)
Der Primärschlüssel ist `id` und die Daten, auf die zugegriffen werden soll, entsprechen `Data`. Die anderen Spalten sind Beispiele für Prüfungen, die Sie für die Autorisierung durchführen können. `Owner`würde eine `String` Weile dauern `PeopleCanAccess` und `GroupsCanAccess` wäre `String Sets` so, wie in der [Referenz zur Resolver-Mapping-Vorlage für DynamoDB](resolver-mapping-template-reference-dynamodb.md#aws-appsync-resolver-mapping-template-reference-dynamodb) beschrieben.
Das Diagramm in der [Übersicht über die Resolver-Zuweisungsvorlage](resolver-mapping-template-reference-overview.md#aws-appsync-resolver-mapping-template-reference-overview) zeigt, wie die Antwortvorlage nicht nur das Kontextobjekt, sondern auch die Ergebnisse aus der Datenquelle enthält. Für GraphQL-Abfragen einzelner Elemente können Sie anhand der Antwortvorlage prüfen, ob der Benutzer diese Ergebnisse sehen darf, oder eine Autorisierungsfehlermeldung zurückgeben. Dies wird manchmal auch als „Autorisierungsfilter“ bezeichnet. Bei GraphQL-Abfragen, die Listen zurückgeben, ist es bei Verwendung eines Scans oder einer Abfrage effizienter, die Prüfung für die Anforderungsvorlage durchzuführen und Daten nur zurückzugeben, wenn eine Autorisierungsbedingung erfüllt ist. Die Implementierung lautet wie folgt:
1. GetItem - Autorisierungsprüfung für einzelne Datensätze. Dieser Vorgang wird mit `#if() ... #end`-Anweisungen ausgeführt.
1. Scan-/Abfrageoperationen – Die Autorisierungsprüfung besteht aus einer `"filter":{"expression":...}`-Anweisung. Gängige Prüfungen erfolgen auf Gleichheit (`attribute = :input`) oder darauf, ob ein Wert in einer Liste (`contains(attribute, :input)`) enthalten ist.
Im zweiten Fall steht `attribute` in beiden Anweisungen für den Spaltennamen des Datensatzes in einer Tabelle, wie z. B. `Owner` in unserem Beispiel oben. Sie können diesen Wert mit einem `#`-Zeichen versehen und `"expressionNames":{...}` verwenden. Dies ist aber nicht obligatorisch. `:input` ist eine Referenz auf den Wert, den Sie mit dem Datenbankattribut vergleichen möchten, das Sie in `"expressionValues":{...}` definieren. Diese Beispiele finden Sie weiter unten.
### Anwendungsfall: Besitzer kann lesen
Wenn Sie unter Verwendung der Tabelle oben nur Daten zurückgegeben möchten, wenn `Owner == Nadia` für einen einzelnen Lesevorgang (`GetItem`) gilt, sieht Ihre Vorlage wie folgt aus:
```
#if($context.result["Owner"] == $context.identity.username)
$utils.toJson($context.result)
#else
$utils.unauthorized()
#end
```
An dieser Stelle möchten wir auf einige Punkte hinweisen, die für die verbleibenden Abschnitte relevant sind. Bei der Prüfung wird zunächst der benutzerfreundliche Anmeldename verwendet`$context.identity.username`, wenn Amazon Cognito-Benutzerpools verwendet werden, und der Nutzeridentität, wenn IAM verwendet wird (einschließlich Amazon Cognito Federated Identities). Es gibt noch andere Werte, die für einen Besitzer gespeichert werden müssen, z. B. den eindeutigen Wert „Amazon Cognito Identity“, der nützlich ist, wenn Anmeldungen von mehreren Standorten aus zusammengeführt werden. Sie sollten sich die Optionen ansehen, die in der [Resolver Mapping](resolver-context-reference.md#aws-appsync-resolver-mapping-template-context-reference) Template Context Reference verfügbar sind.
Zweitens: Die bedingte Prüfung, die mit `$util.unauthorized()` antwortet, ist zwar optional, wird jedoch als bewährte Methode beim Entwerfen Ihrer GraphQL-API empfohlen.
### Anwendungsfall: Hardcode-spezifischer Zugriff
```
// This checks if the user is part of the Admin group and makes the call
#foreach($group in $context.identity.claims.get("cognito:groups"))
#if($group == "Admin")
#set($inCognitoGroup = true)
#end
#end
#if($inCognitoGroup)
{
"version" : "2017-02-28",
"operation" : "UpdateItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
},
"attributeValues" : {
"owner" : $util.dynamodb.toDynamoDBJson($context.identity.username)
#foreach( $entry in $context.arguments.entrySet() )
,"${entry.key}" : $util.dynamodb.toDynamoDBJson($entry.value)
#end
}
}
#else
$utils.unauthorized()
#end
```
### Anwendungsfall: Filtern einer Ergebnisliste
Im vorherigen Beispiel haben Sie eine Prüfung für `$context.result` direkt durchführen können, da ein einzelnes Element zurückgegeben wurde. Bei einigen Operationen wie z. B. einem Scan werden jedoch mehrere Elemente in `$context.result.items` zurückgegeben. In diesen Fällen müssen Sie den Autorisierungsfilter anwenden, sodass nur Ergebnisse erscheinen, die der Benutzer sehen darf. Angenommen, für das `Owner` Feld war dieses Mal die Amazon Cognito IdentityID für den Datensatz festgelegt. Sie könnten dann die folgende Antwortzuordnungsvorlage verwenden, um zu filtern, dass nur die Datensätze angezeigt werden, die dem Benutzer gehörten:
```
#set($myResults = [])
#foreach($item in $context.result.items)
##For userpools use $context.identity.username instead
#if($item.Owner == $context.identity.cognitoIdentityId)
#set($added = $myResults.add($item))
#end
#end
$utils.toJson($myResults)
```
### Anwendungsfall: mehrere Personen können lesen
Eine weitere gängige Autorisierungsoption besteht darin, einer Gruppe von Benutzern das Lesen der Daten zu erlauben. Im folgenden Beispiel gibt `"filter":{"expression":...}` nur die Werte aus einem Tabellenscan zurück, wenn der Benutzer, der die GraphQL-Abfrage ausführt, im Set für `PeopleCanAccess` aufgelistet wird.
```
{
"version" : "2017-02-28",
"operation" : "Scan",
"limit": #if(${context.arguments.count}) $util.toJson($context.arguments.count) #else 20 #end,
"nextToken": #if(${context.arguments.nextToken}) $util.toJson($context.arguments.nextToken) #else null #end,
"filter":{
"expression": "contains(#peopleCanAccess, :value)",
"expressionNames": {
"#peopleCanAccess": "peopleCanAccess"
},
"expressionValues": {
":value": $util.dynamodb.toDynamoDBJson($context.identity.username)
}
}
}
```
### Anwendungsfall: Gruppe kann lesen
Ähnlich wie im letzten Anwendungsfall kann es vorkommen, dass nur Benutzer in einer oder mehreren Gruppen Leserechte für bestimmte Elemente in einer Datenbank besitzen. Die Verwendung der `"expression": "contains()"`-Operation ist zwar ähnlich, es muss in der Gruppenmitgliedschaft jedoch ein logisches ODER zwischen allen Gruppen, denen der Benutzer angehören kann, berücksichtigt werden. In diesem Fall erstellen wir eine `$expression`-Anweisung unten für jede Gruppe, in der sich der Benutzer befindet, und übergeben diese an den Filter:
```
#set($expression = "")
#set($expressionValues = {})
#foreach($group in $context.identity.claims.get("cognito:groups"))
#set( $expression = "${expression} contains(groupsCanAccess, :var$foreach.count )" )
#set( $val = {})
#set( $test = $val.put("S", $group))
#set( $values = $expressionValues.put(":var$foreach.count", $val))
#if ( $foreach.hasNext )
#set( $expression = "${expression} OR" )
#end
#end
{
"version" : "2017-02-28",
"operation" : "Scan",
"limit": #if(${context.arguments.count}) $util.toJson($context.arguments.count) #else 20 #end,
"nextToken": #if(${context.arguments.nextToken}) $util.toJson($context.arguments.nextToken) #else null #end,
"filter":{
"expression": "$expression",
"expressionValues": $utils.toJson($expressionValues)
}
}
```
## Daten schreiben
Das Schreiben von Daten für Mutationen wird immer in der Anforderungszuweisungsvorlage gesteuert. Im Fall von DynamoDB-Datenquellen besteht der Schlüssel in der Verwendung einer entsprechenden `"condition":{"expression"...}"` zur Durchführung der Validierung anhand der Autorisierungsmetadaten in dieser Tabelle. Unter [Sicherheit](security-authz.md#aws-appsync-security) befindet sich ein Beispiel, das zum Prüfen des Felds `Author` in einer Tabelle verwendet werden kann. Die Anwendungsfälle in diesem Abschnitt veranschaulichen weitere Fälle dieser Art.
### Anwendungsfall: mehrere Besitzer
Aus dem bereits verwendeten Beispieltabellendiagramm wird die `PeopleCanAccess`-Liste vorausgesetzt.
```
{
"version" : "2017-02-28",
"operation" : "UpdateItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
},
"update" : {
"expression" : "SET meta = :meta",
"expressionValues": {
":meta" : $util.dynamodb.toDynamoDBJson($ctx.args.meta)
}
},
"condition" : {
"expression" : "contains(Owner,:expectedOwner)",
"expressionValues" : {
":expectedOwner" : $util.dynamodb.toDynamoDBJson($context.identity.username)
}
}
}
```
### Anwendungsfall: Die Gruppe kann einen neuen Datensatz erstellen
```
#set($expression = "")
#set($expressionValues = {})
#foreach($group in $context.identity.claims.get("cognito:groups"))
#set( $expression = "${expression} contains(groupsCanAccess, :var$foreach.count )" )
#set( $val = {})
#set( $test = $val.put("S", $group))
#set( $values = $expressionValues.put(":var$foreach.count", $val))
#if ( $foreach.hasNext )
#set( $expression = "${expression} OR" )
#end
#end
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
## If your table's hash key is not named 'id', update it here. **
"id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
## If your table has a sort key, add it as an item here. **
},
"attributeValues" : {
## Add an item for each field you would like to store to Amazon DynamoDB. **
"title" : $util.dynamodb.toDynamoDBJson($ctx.args.title),
"content": $util.dynamodb.toDynamoDBJson($ctx.args.content),
"owner": $util.dynamodb.toDynamoDBJson($context.identity.username)
},
"condition" : {
"expression": $util.toJson("attribute_not_exists(id) AND $expression"),
"expressionValues": $utils.toJson($expressionValues)
}
}
```
### Anwendungsfall: Die Gruppe kann einen vorhandenen Datensatz aktualisieren
```
#set($expression = "")
#set($expressionValues = {})
#foreach($group in $context.identity.claims.get("cognito:groups"))
#set( $expression = "${expression} contains(groupsCanAccess, :var$foreach.count )" )
#set( $val = {})
#set( $test = $val.put("S", $group))
#set( $values = $expressionValues.put(":var$foreach.count", $val))
#if ( $foreach.hasNext )
#set( $expression = "${expression} OR" )
#end
#end
{
"version" : "2017-02-28",
"operation" : "UpdateItem",
"key" : {
"id" : $util.dynamodb.toDynamoDBJson($ctx.args.id)
},
"update":{
"expression" : "SET title = :title, content = :content",
"expressionValues": {
":title" : $util.dynamodb.toDynamoDBJson($ctx.args.title),
":content" : $util.dynamodb.toDynamoDBJson($ctx.args.content)
}
},
"condition" : {
"expression": $util.toJson($expression),
"expressionValues": $utils.toJson($expressionValues)
}
}
```
## Öffentliche und private Aufzeichnungen
Mit den bedingten Filtern können Sie Daten auch als privat, öffentlich oder mit einer anderen booleschen Prüfung kennzeichnen. Diese Vorgehensweise lässt sich mit einem Autorisierungsfilter innerhalb der Antwortvorlage kombinieren. Mit dieser Prüfung können Daten vorübergehend ausgeblendet oder aus der Anzeige entfernt werden, ohne dass die Gruppenmitgliedschaft kontrolliert werden muss.
Nehmen wir beispielsweise an, Sie haben ein Attribut für jedes Element in Ihrer DynamoDB-Tabelle namens `public` entweder mit dem Wert `yes` oder `no` hinzugefügt. Die folgende Antwortvorlage kann für einen `GetItem`-Aufruf verwendet werden, um nur Daten anzuzeigen, wenn sich der Benutzer in einer Gruppe befindet, die über Zugriff verfügt, UND wenn diese Daten als öffentlich gekennzeichnet sind:
```
#set($permissions = $context.result.GroupsCanAccess)
#set($claimPermissions = $context.identity.claims.get("cognito:groups"))
#foreach($per in $permissions)
#foreach($cgroups in $claimPermissions)
#if($cgroups == $per)
#set($hasPermission = true)
#end
#end
#end
#if($hasPermission && $context.result.public == 'yes')
$utils.toJson($context.result)
#else
$utils.unauthorized()
#end
```
Der obige Code kann auch ein logisches ODER (`||`) verwenden, um Benutzern das Lesen zu erlauben, wenn sie über die Berechtigung für einen Datensatz verfügen oder dieser öffentlich ist:
```
#if($hasPermission || $context.result.public == 'yes')
$utils.toJson($context.result)
#else
$utils.unauthorized()
#end
```
Im Allgemeinen sind die Standardoperatoren `==``!=`, `&&` und `||` beim Ausführen der Autorisierungsprüfungen nützlich.
## Daten in Echtzeit
Sie können eine differenzierte Zugriffskontrolle auf GraphQL-Abonnements zu dem Zeitpunkt anwenden, zu dem ein Client ein Abonnement abschließt. Verwenden Sie dazu die gleichen Techniken, wie weiter oben in dieser Dokumentation beschrieben. Sie fügen dem Abonnementfeld einen Resolver an. An diesem Punkt können Sie Daten aus einer Datenquelle abfragen und eine bedingte Logik entweder in der Anforderungs- oder der Antwortzuweisungsvorlage ausführen. Sie können auch zusätzliche Daten an den Client zurückgeben, z. B. die ersten Ergebnisse aus einem Abonnement, solange die Datenstruktur der Struktur des zurückgegebenen Typs in Ihrem GraphQL-Abonnement entspricht.
### Anwendungsfall: Der Benutzer kann nur bestimmte Konversationen abonnieren
Ein häufiger Anwendungsfall für Echtzeitdaten mit GraphQL-Abonnements ist die Erstellung einer Messaging-App oder einer Anwendung für private Chats. Beim Erstellen einer Chat-Anwendung, die von mehreren Benutzern verwendet wird, können Unterhaltungen zwischen zwei Personen oder zwischen mehreren Personen stattfinden. Diese können in „Räume“ gruppiert werden, die privat oder öffentlich sind. Daher soll nur ein Benutzer autorisiert werden, um eine Unterhaltung zu abonnieren (die zwischen zwei Personen oder in einer Gruppe stattfinden kann), für die ihnen Zugriff gewährt wurde. Zu Demonstrationszwecken wird im Beispiel unten ein einfacher Anwendungsfall von einem Benutzer gezeigt, der eine privaten Nachricht an einen anderen Benutzer sendet. Das Setup umfasst zwei Amazon DynamoDB-Tabellen:
+ Nachrichtentabelle: (Primärschlüssel) `toUser`, (Sortierschlüssel) `id`
+ Berechtigungstabelle: (Primärschlüssel) `username`
Die Nachrichtentabelle speichert die tatsächlichen Nachrichten, die über eine GraphQL-Mutation gesendet werden. Die Berechtigungstabelle wird vom GraphQL-Abonnement im Hinblick auf die Autorisierung zur Client-Verbindungszeit geprüft. Im folgenden Beispiel wird davon ausgegangen, dass Sie das folgende GraphQL-Schema verwenden:
```
input CreateUserPermissionsInput {
user: String!
isAuthorizedForSubscriptions: Boolean
}
type Message {
id: ID
toUser: String
fromUser: String
content: String
}
type MessageConnection {
items: [Message]
nextToken: String
}
type Mutation {
sendMessage(toUser: String!, content: String!): Message
createUserPermissions(input: CreateUserPermissionsInput!): UserPermissions
updateUserPermissions(input: UpdateUserPermissionInput!): UserPermissions
}
type Query {
getMyMessages(first: Int, after: String): MessageConnection
getUserPermissions(user: String!): UserPermissions
}
type Subscription {
newMessage(toUser: String!): Message
@aws_subscribe(mutations: ["sendMessage"])
}
input UpdateUserPermissionInput {
user: String!
isAuthorizedForSubscriptions: Boolean
}
type UserPermissions {
user: String
isAuthorizedForSubscriptions: Boolean
}
schema {
query: Query
mutation: Mutation
subscription: Subscription
}
```
Einige der Standardoperationen, wie z. B., werden im Folgenden nicht behandelt`createUserPermissions()`, um die Abonnement-Resolver zu veranschaulichen, sondern sind Standardimplementierungen von DynamoDB-Resolvern. Stattdessen konzentrieren wir uns auf Autorisierungsabläufe für Abonnements mit Resolvern. Zum Senden einer Nachricht von einem Benutzer an einen anderen fügen Sie dem `sendMessage()`-Feld einen Resolver an und wählen die **Nachrichten**-Tabelle als Datenquelle mit der folgenden Anforderungsvorlage aus:
```
{
"version" : "2017-02-28",
"operation" : "PutItem",
"key" : {
"toUser" : $util.dynamodb.toDynamoDBJson($ctx.args.toUser),
"id" : $util.dynamodb.toDynamoDBJson($util.autoId())
},
"attributeValues" : {
"fromUser" : $util.dynamodb.toDynamoDBJson($context.identity.username),
"content" : $util.dynamodb.toDynamoDBJson($ctx.args.content),
}
}
```
In diesem Beispiel verwenden wir `$context.identity.username`. Dadurch werden Benutzerinformationen für AWS Identity and Access Management unsere Amazon Cognito Cognito-Benutzer zurückgegeben. Die Antwortvorlage ist ein einfacher Pass-Through von `$util.toJson($ctx.result)`. Speichern Sie die Daten und wechseln Sie wieder zur Seite "Schema". Fügen Sie anschließend einen Resolver für das `newMessage()`-Abonnement mit der Tabelle **Berechtigungen** als Datenquelle und der folgenden Anforderungszuweisungsvorlage an:
```
{
"version": "2018-05-29",
"operation": "GetItem",
"key": {
"username": $util.dynamodb.toDynamoDBJson($ctx.identity.username),
},
}
```
Führen Sie mit der folgenden Antwortzuweisungsvorlage die Autorisierungsprüfungen anhand der Daten aus der Tabelle **Berechtigungen** durch:
```
#if(! ${context.result})
$utils.unauthorized()
#elseif(${context.identity.username} != ${context.arguments.toUser})
$utils.unauthorized()
#elseif(! ${context.result.isAuthorizedForSubscriptions})
$utils.unauthorized()
#else
##User is authorized, but we return null to continue
null
#end
```
In diesem Fall nehmen Sie drei Autorisierungsprüfungen vor. Die erste stellt sicher, dass ein Ergebnis zurückgegeben wird. Die zweite stellt sicher, dass der Benutzer keine Nachrichten abonniert, die für eine andere Person gedacht sind. Die dritte Option stellt sicher, dass der Benutzer beliebige Felder abonnieren darf, indem ein DynamoDB-Attribut als `isAuthorizedForSubscriptions` gespeichert überprüft wird. `BOOL`
Um die Dinge zu testen, könnten Sie sich mit Amazon Cognito Cognito-Benutzerpools und einem Benutzer namens „Nadia“ bei der AWS AppSync Konsole anmelden und dann das folgende GraphQL-Abonnement ausführen:
```
subscription AuthorizedSubscription {
newMessage(toUser: "Nadia") {
id
toUser
fromUser
content
}
}
```
Wenn in der Tabelle **Permissions (Berechtigungen)** ein Datensatz für das `username`-Schlüsselattribut `Nadia` enthalten ist, wobei `isAuthorizedForSubscriptions` auf `true` gesetzt ist, sehen Sie eine erfolgreiche Antwort. Wenn Sie einen anderen `username` in der `newMessage()`-Abfrage oben angeben, wird ein Fehler zurückgegeben.
# Verwenden Sie AWS WAF zum Schutz Ihrer AWS AppSync APIs
AWS WAF ist eine Firewall für Webanwendungen, die zum Schutz von Webanwendungen und APIs vor Angriffen beiträgt. Sie ermöglicht es Ihnen, eine Reihe von Regeln zu konfigurieren, die als Web-Zugriffskontrollliste (Web Access Control List, Web-ACL) bezeichnet werden und Webanfragen auf der Grundlage von anpassbaren Websicherheitsregeln und -bedingungen, die Sie definieren, zulassen, blockieren oder überwachen (zählen). Wenn Sie Ihre AWS AppSync API integrieren AWS WAF, erhalten Sie mehr Kontrolle und Einblick in den von Ihrer API akzeptierten HTTP-Verkehr. Weitere Informationen AWS WAF dazu finden Sie im AWS WAF Entwicklerhandbuch unter [So AWS WAF funktioniert](https://docs.aws.amazon.com/waf/latest/developerguide/how-aws-waf-works.html) es.
Sie können AWS WAF es verwenden, um Ihre AppSync API vor gängigen Web-Exploits wie SQL-Injection und Cross-Site Scripting (XSS) -Angriffen zu schützen. Diese können sich auf die Verfügbarkeit und Leistung der API auswirken, die Sicherheit gefährden oder übermäßige Ressourcen verbrauchen. Sie können beispielsweise Regeln zum Zulassen oder Blockieren von Anforderungen von angegebenen IP-Adressbereichen, Anforderungen von CIDR-Blocks, Anforderungen aus einem bestimmten Land oder einer bestimmten Region, Anforderungen mit bösartigem SQL-Code oder Anforderungen mit bösartigem Skript erstellen.
Sie können auch Regeln erstellen, die mit einer bestimmten Zeichenfolge oder einem regulären Ausdrucksmuster in HTTP-Headern, einer Methode, einer Abfragezeichenfolge, einer URI und dem Anforderungstext (nur für die ersten 8 KB) übereinstimmen. Außerdem können Sie Regeln zum Blockieren von Angriffen von bestimmten Benutzeragenten, bösartigen Bots und Content Scrapers erstellen. Beispielsweise können Sie mit durchsatzbasierten Regeln die Anzahl der zulässigen Webanforderungen angeben, die von jeder Client-IP in einem sich anschließenden, fortlaufend aktualisierten 5-Minuten-Zeitraum zugelassen werden.
[Weitere Informationen zu den unterstützten Regeltypen und zusätzlichen AWS WAF Funktionen finden Sie im [AWS WAF Entwicklerhandbuch und in der API-Referenz](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html).AWS WAF](https://docs.aws.amazon.com/waf/latest/APIReference/API_Types_AWS_WAFV2.html)
**Wichtig**
AWS WAF ist Ihre erste Verteidigungslinie gegen Web-Exploits. Wenn auf einer API aktiviert AWS WAF ist, werden AWS WAF Regeln vor anderen Zugriffskontrollfunktionen wie API-Schlüsselautorisierung, IAM-Richtlinien, OIDC-Token und Amazon Cognito Cognito-Benutzerpools ausgewertet.
## Integrieren Sie eine API mit AppSync AWS WAF
Sie können eine Appsync-API AWS WAF mithilfe des AWS-Managementkonsole, des AWS CLI AWS CloudFormation, oder eines anderen kompatiblen Clients integrieren.
**Um eine AWS AppSync API zu integrieren mit AWS WAF**
1. Erstellen Sie eine AWS WAF Web-ACL. Eine ausführliche Anleitung zur Verwendung der [AWS WAF Konsole](https://console.aws.amazon.com/waf/) finden Sie unter [Web-ACL erstellen](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-creating.html).
1. Definieren Sie die Regeln für die Web-ACL. Eine oder mehrere Regeln werden bei der Erstellung der Web-ACL definiert. Informationen zur Strukturierung von Regeln finden Sie unter [AWS WAF Regeln](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html). Beispiele für nützliche Regeln, die Sie für Ihre AWS AppSync API definieren können, finden Sie unter[Regeln für eine Web-ACL erstellen](#Creating-web-acl-rules).
1. Ordnen Sie die Web-ACL einer AWS AppSync API zu. Sie können diesen Schritt in der [AWS WAF Konsole](https://console.aws.amazon.com/wafv2/) oder in der [AppSync Konsole](https://console.aws.amazon.com/appsync/) ausführen.
+ Um die Web-ACL einer AWS AppSync API in der AWS WAF Konsole zuzuordnen, folgen Sie den Anweisungen zum [Zuordnen oder Aufheben der Zuordnung einer Web-ACL zu einer AWS Ressource im AWS WAF Entwicklerhandbuch](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-associating-aws-resource.html).
+ So verknüpfen Sie die Web-ACL mit einer AWS AppSync API in der Konsole AWS AppSync
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die [AppSync Konsole](https://console.aws.amazon.com/appsync/).
1. Wählen Sie die API aus, die Sie einer Web-ACL zuordnen möchten.
1. Wählen Sie im Navigationsbereich **Settings** (Einstellungen).
1. Aktivieren Sie im Abschnitt **Firewall für Webanwendungen** die Option **Aktivieren AWS WAF**.
1. Wählen Sie in der Dropdownliste **Web-ACL** den Namen der Web-ACL aus, die Sie Ihrer API zuordnen möchten.
1. Wählen Sie **Speichern**, um die Web-ACL mit Ihrer API zu verknüpfen.
**Anmerkung**
Nachdem Sie eine Web-ACL in der AWS WAF Konsole erstellt haben, kann es einige Minuten dauern, bis die neue Web-ACL verfügbar ist. Wenn Sie im **Firewall-Menü der Webanwendung keine neu erstellte Web-ACL** sehen, warten Sie einige Minuten und wiederholen Sie die Schritte, um die Web-ACL Ihrer API zuzuordnen.
**Anmerkung**
AWS WAF Die Integration unterstützt das `Subscription registration message` Ereignis nur für Echtzeit-Endpunkte. AWS AppSync antwortet mit einer Fehlermeldung statt mit einer `start_ack` Meldung für alle, die `Subscription registration message` blockiert wurden AWS WAF.
Nachdem Sie einer AWS AppSync API eine Web-ACL zugeordnet haben, verwalten Sie die Web-ACL mithilfe der AWS WAF APIs. Sie müssen die Web-ACL nicht erneut mit Ihrer AWS AppSync API verknüpfen, es sei denn, Sie möchten die AWS AppSync API einer anderen Web-ACL zuordnen.
## Regeln für eine Web-ACL erstellen
Regeln definieren, wie Webanfragen geprüft werden und was zu tun ist, wenn eine Webanfrage den Inspektionskriterien entspricht. Regeln existieren nicht für AWS WAF sich allein. Sie können auf eine Regel anhand des Namens in einer Regelgruppe oder in der Web-ACL zugreifen, in der sie definiert ist. Weitere Informationen finden Sie unter [AWS WAF Regeln](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rules.html). Die folgenden Beispiele zeigen, wie Regeln definiert und verknüpft werden, die für den Schutz einer AppSync API nützlich sind.
**Example Web-ACL-Regel zur Begrenzung der Größe des Anfragetextes**
Im Folgenden finden Sie ein Beispiel für eine Regel, die die Größe des Hauptteils von Anfragen begrenzt. Dies würde beim Erstellen einer Web-ACL in der AWS WAF Konsole in den **JSON-Editor für Regeln** eingegeben werden.
```
{
"Name": "BodySizeRule",
"Priority": 1,
"Action": {
"Block": {}
},
"Statement": {
"SizeConstraintStatement": {
"ComparisonOperator": "GE",
"FieldToMatch": {
"Body": {}
},
"Size": 1024,
"TextTransformations": [
{
"Priority": 0,
"Type": "NONE"
}
]
}
},
"VisibilityConfig": {
"CloudWatchMetricsEnabled": true,
"MetricName": "BodySizeRule",
"SampledRequestsEnabled": true
}
}
```
Nachdem Sie Ihre Web-ACL mit der vorherigen Beispielregel erstellt haben, müssen Sie sie mit Ihrer AppSync API verknüpfen. Als Alternative zur Verwendung von können Sie diesen Schritt in der ausführen AWS-Managementkonsole, AWS CLI indem Sie den folgenden Befehl ausführen.
```
aws waf associate-web-acl --web-acl-id waf-web-acl-arn --resource-arn appsync-api-arn
```
Es kann einige Minuten dauern, bis die Änderungen übernommen werden, aber nach der Ausführung dieses Befehls werden Anfragen, deren Hauptteil größer als 1024 Byte ist, von AWS AppSync abgewiesen.
Nachdem Sie eine neue Web-ACL in der AWS WAF Konsole erstellt haben, kann es einige Minuten dauern, bis die Web-ACL für die Verknüpfung mit einer API verfügbar ist. Wenn Sie den CLI-Befehl ausführen und eine `WAFUnavailableEntityException` Fehlermeldung erhalten, warten Sie einige Minuten und versuchen Sie erneut, den Befehl auszuführen.
**Example Web-ACL-Regel zur Beschränkung von Anfragen von einer einzelnen IP-Adresse**
Im Folgenden finden Sie ein Beispiel für eine Regel, mit der eine AppSync API auf 100 Anfragen von einer einzigen IP-Adresse gedrosselt wird. Dies würde beim Erstellen einer Web-ACL mit einer ratenbasierten **Regel in der Konsole in den JSON-Editor** für Regeln eingegeben werden. AWS WAF
```
{
"Name": "Throttle",
"Priority": 0,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "Throttle"
},
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP"
}
}
}
```
Nachdem Sie Ihre Web-ACL anhand der obigen Beispielregel erstellt haben, müssen Sie sie mit Ihrer AppSync API verknüpfen. Sie können diesen Schritt in der ausführen, AWS CLI indem Sie den folgenden Befehl ausführen.
```
aws waf associate-web-acl --web-acl-id waf-web-acl-arn --resource-arn appsync-api-arn
```
**Example Web-ACL-Regel zur Verhinderung von GraphQL \$1\$1schema Introspection-Abfragen an eine API**
Das Folgende ist ein Beispiel für eine Regel, die GraphQL \$1\$1schema Introspection-Abfragen an eine API verhindert. Jeder HTTP-Hauptteil, der die Zeichenfolge „\$1\$1schema“ enthält, wird blockiert. Dies würde beim Erstellen einer Web-ACL in der AWS WAF Konsole in den **JSON-Editor für Regeln** eingegeben werden.
```
{
"Name": "BodyRule",
"Priority": 5,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "BodyRule"
},
"Statement": {
"ByteMatchStatement": {
"FieldToMatch": {
"Body": {}
},
"PositionalConstraint": "CONTAINS",
"SearchString": "__schema",
"TextTransformations": [
{
"Type": "NONE",
"Priority": 0
}
]
}
}
}
```
Nachdem Sie Ihre Web-ACL mit der vorherigen Beispielregel erstellt haben, müssen Sie sie mit Ihrer AppSync API verknüpfen. Sie können diesen Schritt in der ausführen, AWS CLI indem Sie den folgenden Befehl ausführen.
```
aws waf associate-web-acl --web-acl-id waf-web-acl-arn --resource-arn appsync-api-arn
```