認証と認可 - AWS AppSync

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

認証と認可

このセクションでは、実行するアプリケーションのセキュリティとデータ保護を設定するオプションについて説明します。

アプリケーションの操作を許可するには、5 つの方法があります。AWSAppSync GraphQL API。で次のいずれかの認証タイプ値を指定することで、使用する認証タイプを指定します。AWSAppSync API または CLI 呼び出し:

  • API_KEY

    API キーを使用する場合。

  • AWS_LAMBDA

    使用するにはAWS Lambdafunction.

  • AWS_IAM

    を使用するためAWS Identity and Access Management(IAM) アクセス許可。

  • OPENID_CONNECT

    OpenID Connect プロバイダーを使用する場合。

  • AMAZON_COGNITO_USER_POOLS

    Amazon Cognito ユーザープールを使用する場合。

これらの基本的な承認タイプは、ほとんどの開発者に有効です。より高度なユースケースでは、コンソール、CLI、およびを使用して追加の承認モードを追加できます。AWS CloudFormation。追加の承認モードの場合、AppSync には上記の値 (つまり、API_KEY、AWS_LAMBDA、AWS_IAM,OPENID_CONNECT, およびAMAZON_COGNITO_USER_POOLS).

指定する場合API_KEY,AWS_LAMBDA, またはAWS_IAMメインまたはデフォルトの承認タイプとして、それを追加の承認モードの 1 つとして再度指定することはできません。同様に、重複して使用することはできません。API_KEY,AWS_LAMBDAまたはAWS_IAM追加の承認モード内。複数の Amazon Cognito ユーザープールと OpenID Connect プロバイダーを使用できます。ただし、デフォルトの承認モードと追加の承認モード間で重複する Amazon Cognito ect プロバイダーまたは OpenID Connect プロバイダーを重複して使用することはできません。Amazon Cognito ユーザープールまたは OpenID Connect プロバイダーに異なる複数のクライアントを設定するには、対応する正規表現を使用できます。

API_KEY 認証

認証されていない API は、認証された API よりも厳格なスロットリングが必要になります。認証されていない GraphQL エンドポイントに対してスロットリングを制御する方法の 1 つは API キーを使用します。API キーは、アプリケーション内でハードコードされた値です。AWS認証されていない GraphQL エンドポイントを作成する場合の AppSync サービス。コンソール、CLI、または API キーを更新できます。AWS AppSyncAPI リファレンス

API キーは、最大 365 日間有効に設定可能で、該当日からさらに最大 365 日、既存の有効期限を延長できます。API キーは、パブリック API の公開が安全であるユースケース、または開発目的での使用が推奨されます。

クライアントでは、API キーをヘッダー x-api-key で指定します。

たとえば、API_KEY'ABC123' である場合、次のように curl 経由で GraphQL クエリを送信できます。

$ curl -XPOST -H "Content-Type:application/graphql" -H "x-api-key:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql

AWS_LAMBDA 認証

を使用して、独自の API 認証ロジックを実装できます。AWS Lambdafunction. Lambda 関数をプライマリオーソライザーまたはセカンダリオーソライザーに使用できますが、API ごとに Lambda 認証関数は 1 つしかありません。Lambda 関数を認可に使用する場合、次のことが適用されます。

  • 認証トークンは 2048 文字を超えないようにしてください。

  • Lambda 関数は、リゾルバに対して 5MB を超えるコンテキストデータを返してはいけません。

たとえば、認証トークンが'ABC123'では、次のようにカール経由で GraphQL クエリを送信できます。

$ curl -XPOST -H "Content-Type:application/graphql" -H "Authorization:ABC123" -d '{ "query": "query { movies { id } }" }' https://YOURAPPSYNCENDPOINT/graphql

Lambda 関数は、各クエリまたはミューテーションの前に呼び出されますが、戻り値はキャッシュされます。繰り返されるリクエストでは、API ID と認証トークンに基づいてキャッシュされる前に 1 回だけ関数が呼び出されます。デフォルトでは、このキャッシュ時間は 300 秒(5 分)ですが、これは API レベルで、またはttlOverrideは関数の戻り値の値。

必要に応じて、関数が呼び出される前に認可トークンを検証する正規表現を指定できます。これらの正規表現は、関数が呼び出される前に、認可トークンが正しい形式であることを検証するために使用されます。この正規表現と一致しないトークンを使用したリクエストは自動的に拒否されます。

認可に使用する Lambda 関数には、次のプリンシパルポリシーが必要です。appsync.amazonaws.comそれらに適用して許可するAWS AppSyncと呼んだ。この操作は、AWS AppSyncコンソール;AWS AppSyncコンソールはないポリシーを削除します。Lambda 関数にポリシーをアタッチする方法の詳細については、「」を参照してください。リソースベースのポリシーのAWS Lambda開発者ガイド の最初のリリースです。

指定した Lambda 関数は、次の形状のイベントを受け取ります。

{ "authorizationToken": "ExampleAUTHtoken123123123", "requestContext": { "apiId": "aaaaaa123123123example123", "accountId": "111122223333", "requestId": "f4081827-1111-4444-5555-5cf4695f339f", "queryString": "mutation CreateEvent {...}\n\nquery MyQuery {...}\n", "operationName": "MyQuery", "variables": {} } }

認可関数は少なくとも返さなければならないisAuthorized、リクエストが承認されているかどうかを示すブール値。AWS AppSyncは、Lambda 認証関数から返される次のキーを認識します。

isAuthorized(ブール、必須)

その値がのかどうかを示すブール値authorizationTokenは GraphQL API への呼び出しを行う権限を持ちます。

この値が true の場合、GraphQL API の実行が継続されます。この値が false の場合、UnauthorizedExceptionが上げられる

deniedFields(文字列のリスト、オプション)

そのリストは強制的に変更されますnull、リゾルバから値が返された場合でも。

各項目は、次の形式の完全修飾フィールド ARN です。arn:aws:appsync:us-east-1:111122223333:apis/GraphQLApiId/types/TypeName/fields/FieldNameまたは短い形式のTypeName.FieldName。2 つの API がラムダ関数のオーソライザーを共有し、2 つの API の間に共通の型とフィールドの間にあいまいさがある可能性がある場合は、完全な ARN 形式を使用する必要があります。

resolverContext(JSON オブジェクト、オプション)

JSON オブジェクトは次のように表示されます。$ctx.identity.resolverContextリゾルバテンプレート内。たとえば、リゾルバによって次の構造体が返されたとします。

{ "isAuthorized":true "resolverContext": { "banana":"very yellow", "apple":"very green" } }

の価値$ctx.identity.resolverContext.appleリゾルバ内のテンプレートは次のようになります」very green「。-resolverContextオブジェクトは、キーと値のペアのみをサポートします。ネストされたキーはサポートされません。

警告

この JSON オブジェクトの合計サイズは 5 MB を超えないようにしてください。

ttlOverride(整数、オプション)

応答をキャッシュする秒数。値が返されない場合は、API からの値(設定されている場合)またはデフォルトの 300 秒(5 分)が使用されます。0 の場合、応答はキャッシュされません。

Lambda オーソライザーのタイムアウトは 10 秒です。API のパフォーマンスをスケールするために、できるだけ短い時間で実行する関数を設計することをお勧めします。

複数AWS AppSyncAPI は単一の認証 Lambda 関数を共有できます。クロスアカウントオーソライザーの使用は許可されていません。

複数の API 間で認証関数を共有する場合は、短い形式のフィールド名 (typename.fieldname) が誤ってフィールドを隠すことがある。のフィールドを明確化するにはdeniedFieldsの場合、明確なフィールド ARN をの形式で指定できます。arn:aws:appsync:region:accountId:apis/GraphQLApiId/types/typeName/fields/fieldName

で Lambda 関数をデフォルトの認証モードとして追加するにはAWS AppSync:

Console

Lambda オーソライザーをAWS AppSyncコンソール

  1. にログインするAWS AppSyncコンソールを開き、更新する API に移動します。

  2. API の [設定] ページに移動します。

    API レベルの認証をに変更します。AWS Lambda

  3. [AWS リージョンと Lambda ARN を使用して API 呼び出しを承認します。

    注記

    適切なプリンシパルポリシーが自動的に追加され、AWS AppSyncに Lambda 関数を呼び出します。

  4. 必要に応じて、レスポンス TTL とトークン検証の正規表現を設定します。

AWS CLI
  1. 使用している Lambda 関数に次のポリシーをアタッチします。

    aws lambda add-permission --function-name "my-function" --statement-id "appsync" --principal appsync.amazonaws.com --action lambda:InvokeFunction --output text
    重要

    関数のポリシーを単一の GraphQL API にロックする場合は、次のコマンドを実行できます。

    aws lambda add-permission --function-name “my-function” --statement-id “appsync” --principal appsync.amazonaws.com --action lambda:InvokeFunction --source-arn “<my AppSync API ARN>” --output text
  2. を更新するAWS AppSync指定された Lambda 関数 ARN をオーソライザーとして使用する API:

    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"
    注記

    トークンの正規表現など、他の設定オプションを含めることもできます。

次の例では、Lambda 関数がAWS AppSync承認機構:

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 {}

AWS_IAM 認証

この認証タイプでは、AWS署名バージョン 4 の署名プロセスGraphQL API で。Identity and Access Management (IAM) アクセスポリシーをこの承認タイプに関連付けることができます。アクセスキー (アクセスキー ID とシークレットアクセスキーで構成) または Amazon Cognito フェデレーテッドアイデンティティによって提供される有効期限の短い、一時的な認証情報を使用して、アプリケーションでこの関連付けを活用します。

すべてのデータオペレーションを実行できるアクセス権限を持つロールが必要な場合。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appsync:GraphQL" ], "Resource": [ "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/*" ] } ] }

AppSync コンソールのメイン API リストページから、使用する API の名前の直下で、YourGraphQLApiId を確認できます。CLI aws appsync list-graphql-apis を使用して取得することもできます。

特定の GraphQL オペレーションのみにアクセスを制限するには、ルートの QueryMutationSubscription の各フィールドに対してこれを実行します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "appsync:GraphQL" ], "Resource": [ "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-1>", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Query/fields/<Field-2>", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Mutation/fields/<Field-1>", "arn:aws:appsync:us-west-2:123456789012:apis/YourGraphQLApiId/types/Subscription/fields/<Field-1>" ] } ] }

たとえば、以下のスキーマがあり、すべての投稿を取得するアクセスを制限する場合。

schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { addPost(id:ID!, title:String!):Post! }

ロール (Amazon Cognito ID プールなどにアタッチできる) に対応する IAM ポリシーは次のようになります。

{ "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_CONNECT 認証

この認証タイプは、OIDC 準拠サービスによって提供される OpenID Connect (OIDC) トークンを適用します。アプリケーションは、アクセス制御に対して、使用する OIDC プロバイダーによって定義されたユーザーと権限を活用できます。

発行者 URL は、に指定する唯一の必須設定値です。AWSAppSync(例えば、https://auth.example.com). この URL に HTTPS 経由でアクセスできる必要があります。AWSAppSync が追加される/.well-known/openid-configurationを発行者 URL に移動し、にある OpenID 設定を見つけます。https://auth.example.com/.well-known/openid-configuration/OpenID Connect の検出仕様。この URL で RFC5785 準拠の JSON ドキュメントを取得するものとします。この JSON ドキュメントに jwks_uri キーが含まれている必要があります。これは JWKS JSON Web キー (JWKS) ドキュメントと署名キーを指します。

AWSAppSync には、JWKS に JSON フィールドを含める必要があります。alg,kty, およびkid

AWSAppSync は署名アルゴリズムとして RS256、RS384、RS512 をサポートします。プロバイダーによって発行されたトークンに、トークンが発行された時刻 (iat) が含まれている必要があり、認証された時刻 (auth_time) が含まれる場合があります。発行時刻の TTL 値 (iatTTL) および認証時刻の TTL 値 (authTTL) を、追加の検証用に OpenID Connect 設定に入力できます。使用するプロバイダーが複数のアプリケーションを認証している場合は、クライアント ID で認証するために使用される正規表現を (clientId) も入力できます。

複数のクライアント ID を検証するには、正規表現で「or」であるパイプライン演算子 (「|」) を使用します。たとえば、OIDC アプリケーションに 4 つのクライアントがあり、そのクライアント ID が 0A1S2D、1F4G9H、1J6L4B、6GS5MG などである場合、最初の 3 つのクライアント ID のみを検証するには、クライアント ID フィールドに「1F4G9H|1J6L4B|6GS5MG」と入力します。

AMAZON_COGNITO_USER_POOLS 認証

この認証タイプでは、Amazon Cognito ユーザープールによって提供される OIDC トークンが使用されます。アプリケーションはさらに、ユーザープール内のユーザーとグループを活用して、これらをアクセスをコントロールするための GraphQL フィールドに関連付けることができます。

Amazon Cognito ユーザープールを使用する場合、ユーザーが属するグループを作成できます。この情報は、アプリケーションが送信する JWT トークンの中にエンコードされます。AWSGraphQL オペレーションを送信するときに authorizaton ヘッダーの AppSync スキーマで GraphQL ディレクティブを使用して、フィールドでどのグループがどのリゾルバーを起動できるのかを制御します。したがってカスタマーのアクセスを細かく制御できます。

たとえば、以下の GraphQL スキーマがあるとします。

schema { query: Query mutation: Mutation } type Query { posts:[Post!]! } type Mutation { addPost(id:ID!, title:String!):Post! } ...

Amazon Cognito ユーザープールに 2 つのグループ (bloggers と readers) があり、readers が新しいエントリを追加できないように制限する場合、スキーマは次のようになります。

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"]) } ...

@aws_auth ディレクティブは、個別のアクセス許可/拒否戦略をデフォルトにする場合に省略できることに注意してください。コンソールまたは以下の CLI コマンド経由で GraphQL API を作成するときに、ユーザープール設定で許可/拒否戦略を指定できます。

$ 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"}'

追加の承認モードの使用

追加の認可モードを追加する場合は、で許可設定を直接設定できます。AWSAppSync GraphQL APIレベル(つまり、authenticationTypeで直接設定できるフィールドGraphqlApiobject)であり、スキーマのデフォルトとして機能します。つまり、特定のディレクティブのないタイプは API レベルの承認設定を渡す必要があります。

スキーマレベルでは、スキーマでディレクティブを使用して追加の承認モードを指定できます。スキーマの個々のフィールドに承認モードを指定できます。たとえば、API_KEY 承認の場合、スキーマオブジェクトタイプの定義/フィールドで @aws_api_key を使用します。以下のディレクティブは、スキーマフィールドおよびオブジェクトタイプ定義でサポートされています。

  • @aws_api_key - フィールドが API_KEY で承認されることを指定します。

  • @aws_iam - フィールドが AWS_IAM で承認されることを指定します。

  • @aws_oidc - フィールドが OPENID_CONNECT で承認されることを指定します。

  • @aws_cognito_user_pools - フィールドが AMAZON_COGNITO_USER_POOLS で承認されることを指定します。

  • @aws_lambda - フィールドが AWS_LAMBDA で承認されることを指定します。

@aws_auth ディレクティブを追加の承認モードと共に使用することはできません。@aws_auth は、追加の承認モードのない AMAZON_COGNITO_USER_POOLS 承認のコンテキストでのみ機能します。ただし、同じ引数で @aws_auth ディレクティブの代わりに @aws_cognito_user_pools ディレクティブを使用できます。2 つの主な違いは、フィールドとオブジェクトタイプの定義で @aws_cognito_user_pools を指定できることです。

追加の承認モードがどのように機能し、スキーマでどのように指定できるかを理解するために、以下のスキーマを見てみましょう。

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! } ...

このスキーマでは、AWS_IAMは、のデフォルトの承認タイプですかAWSAppSync GraphQL API。つまり、ディレクティブのないフィールドは AWS_IAM を使用して保護されます。たとえば、Query タイプの getPost フィールドの場合です。スキーマディレクティブにより、複数の承認モードを使用できます。たとえば、以下のようになります。API_KEYで追加の認可モードとして設定AWSAppSync GraphQL API を使用してフィールドをマークできます。@aws_api_keyディレクティブ (たとえば、getAllPostsこの例では)。ディレクティブはフィールドレベルで機能するため、Post タイプへの API_KEY アクセスも許可する必要があります。そのためには、Post タイプの各フィールドをディレクティブでマークするか、Post タイプを @aws_api_key ディレクティブでマークします。

Post タイプのフィールドへのアクセスをさらに制限するには、以下に示すように、Post タイプの個々のフィールドに対してディレクティブを使用できます。

たとえば、restrictedContent フィールドを Post タイプに追加し、@aws_iam ディレクティブを使用してそのフィールドへのアクセスを制限できます。ただし restrictedContent に、AWS_IAM 認証済みリクエストからはアクセスできますが、API_KEY リクエストからはアクセスできません。

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 } ...

FGAC (Fine-Grained Access Control)

前述の情報は、特定の GraphQL フィールドへのアクセスを制限または許可する方法を示しています。特定の条件に基づいて (たとえば、呼び出し元のユーザーがだれであるかや、そのユーザーがデータを所有しているかどうかに基づいて) データに対するアクセスコントロールを設定する場合は、リゾルバーでマッピングテンプレートを使用できます。より複雑なビジネスロジックも実行できます。「フィルター処理情報」で説明します。

このセクションでは、DynamoDB リゾルバーのマッピングテンプレートを使用してデータにアクセスコントロールを設定する方法を示します。

さらに進む前に、のマッピングテンプレートがよくわからない場合はAWSAppSync、次のようになります。リゾルバーのマッピングテンプレートリファレンスDynamoDB のリゾルバーのマッピングテンプレートリファレンス

DynamoDB を使用した次の例では、前述のブログ投稿スキーマを使用し、投稿を作成したユーザーのみが編集を許可されているものとします。評価プロセスは、Amazon Cognito ユーザープールなどを使用して、ユーザーがアプリケーションで認証情報を取得し、GraphQL オペレーションの一部として、これらの認証情報を渡すというものです。その後、マッピングテンプレートが、条件ステートメントで、認証情報 (username など) からの値を置き換えます。値はデータベースの値と比較されます。

この機能を追加するには、次のように editPost GraphQL フィールドを追加します。

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! } ...

editPost のリゾルバーマッピングテンプレート (このセクションの最後にある例) では、投稿を作成したユーザーのみが編集を許可されるように、データストアに対する論理チェックを実行する必要があります。これは編集オペレーションなので、UpdateItemDynamoDB で。ユーザー ID 検証に渡されるコンテキストを使用して、このアクションを実行する前に条件チェックを実行できます。これは次の値を持つ Identity オブジェクトに保存されます。

{ "accountId" : "12321434323", "cognitoIdentityPoolId" : "", "cognitoIdentityId" : "", "sourceIP" : "", "caller" : "ThisistheprincipalARN", "username" : "username", "userArn" : "Sameasabove" }

DynamoDB でこのオブジェクトを使用するにはUpdateItemを呼び出す場合は、比較用テーブルにユーザー ID 情報を保存する必要があります。まず、addPost ミューテーションは作成者を保存する必要があります。次に、更新する前に、editPost ミューテーションで条件チェックを実行する必要があります。

次の例は、addPost に対するリクエストマッピングテンプレートで、Author 列としてユーザー ID を保存します。

{ "version" : "2017-02-28", "operation" : "PutItem", "key" : { "postId" : $util.dynamodb.toDynamoDBJson($context.arguments.id) }, "attributeValues" : { "Author" : $util.dynamodb.toDynamoDBJson($context.identity.username) #foreach( $entry in $context.arguments.entrySet() ) #if( $entry.key != "id" ) ,"${entry.key}" : $util.dynamodb.toDynamoDBJson($entry.value) #end #end }, "condition" : { "expression" : "attribute_not_exists(postId)" } }

Author 属性が、アプリケーションから得られた Identity オブジェクトから入力されていることに注意してください。

最後に、editPost に対する、リクエストマッピングテンプレートの例を次に示します。投稿を作成したユーザーからリクエストが来た場合に、ブログ投稿のコンテンツを更新するだけです。

{ "version" : "2017-02-28", "operation" : "PutItem", "key" : { "id": $util.dynamodb.toDynamoDBJson($ctx.args.id), }, "attributeValues" : $util.dynamodb.toMapValuesJson($ctx.args), "condition" : { "expression" : "contains(#author,:expectedOwner)", "expressionNames" : { "#author" : "Author" }, "expressionValues" : { ":expectedOwner" : $util.dynamodb.toDynamoDBJson($context.identity.username) } } }

この例では、たとえばやや冗長になる UpdateItem ではなく、すべての値を上書きする PutItem を使用していますが、condition ステートメントブロックには同じ概念が適用されます。

フィルタ処理情報

データソースからのレスポンスを制御できないときに、データソースへの正常な書き込みまたは読み取りに対して、不必要な情報をクライアントに送信したくない場合があります。このような場合は、レスポンスマッピングテンプレートを使用して情報をフィルタリングすることができます。

たとえば、ブログ投稿 DynamoDB テーブルに適切なインデックス (のインデックスなど) がない場合を考えます。Author). 次のマッピングテンプレートを使用して GetItem クエリを実行できます。

{ "version" : "2017-02-28", "operation" : "GetItem", "key" : { "postId" : $util.dynamodb.toDynamoDBJson($ctx.args.id) } }

すべてのレスポンス値を返します。発信者が投稿を作成した筆者ではない場合でも返します。これを回避するには、次のようにこの場合のレスポンスマッピングテンプレートでアクセスチェックを実行できます。

{ #if($context.result["Author"] == "$context.identity.username") $utils.toJson($context.result); #end }

発信者がこのチェックに一致しない場合に、null レスポンスのみが返されます。

データソースへのアクセス

AWSAppSync は Identity and Access Management () を使用してデータソースと通信します (IAM) ロールとアクセスポリシー。既存のロールを使用している場合、次のように Trust Policy を追加する必要があります。AWSAppSync は、ロールを引き受けるために使用します。信頼関係は以下のようになります。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "appsync.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

必要な最小限のリソースについて作業を行うアクセス許可のみを持つように、ロールのアクセスポリシーを制限することが重要です。AppSync コンソールを使用してデータソースを作成し、ロールを作成したとき、これは自動的に行われます。ただし、IAM コンソールから組み込みのサンプルテンプレートを使用して、の外部でロールを作成している場合AWSAppSync Console アクセス許可はリソースに対して自動的に制限はされず、アプリケーションを本番環境に移行する前に、手動でこの処置を実施する必要があります。