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

GraphQL API を保護するための認可と認証の設定

AWS AppSync は、GraphQL APIs を保護するため、API キー、Lambda、IAM、OpenID Connect、および Cognito ユーザープールの認可タイプを提供します。各オプションは、異なるセキュリティ方法を提供します。

認可タイプ

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

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

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

API_KEY 認可

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

Console

1. にサインイン AWS Management Console し、AppSync コンソールを開きます。

   1. API ダッシュボードで、GraphQL API を選択します。

   2. サイドバーで [設定] を選択します。

2. デフォルト認可モードで、API キー を選択します。

3. [API キー] テーブルで、[API キーの追加] を選択します。

   新しい API キーがテーブルで生成されます。

   1. 古い API キーを削除するには、テーブル内で API キーを選択し、[削除] を選択します。

4. ページの最下部で [保存] をクリックします。

CLI

1. まだ設定していない場合は、 CLI AWS へのアクセスを設定します。詳細については、「設定の基本」を参照してください。

2. update-graphql-api コマンドを実行して GraphQL API オブジェクトを作成します。

   この特定のコマンドには次の 2 つのパラメータを入力する必要があります。

   1. GraphQL API の api-id。

   2. API の新しい name。同じ name を使用できます。

   3. API_KEY となる authentication-type。

   注記

   Region など、設定する必要のあるパラメータは他にもありますが、通常はデフォルトで CLI 設定値になります。

   コマンドの例は、次のようになります。

   aws appsync update-graphql-api --api-id abcdefghijklmnopqrstuvwxyz --name TestAPI --authentication-type API_KEY

   出力は CLI に返されます。以下に 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 キーは、最大 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 認可

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

例えば、認可トークン が 'ABC123' である場合、次のように curl 経由で GraphQL クエリを送信できます。

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

Lambda 関数は、各クエリまたはミューテーションの前に呼び出されます。戻り値は API ID と認証トークンに基づいてキャッシュできます。デフォルトでは、キャッシュは有効になっていませんが、これは 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": {}
    }
    "requestHeaders": {
        application request headers
    }
}

event オブジェクトには、アプリケーションクライアントから へのリクエストで送信されたヘッダーが含まれています AWS AppSync。

認可関数は少なくとも を返す必要があります。これはisAuthorized、リクエストが認可されたかどうかを示すブール値です。 は、Lambda 認可関数から返された次のキー AWS AppSync を認識します。

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

Console

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

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

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

3. API コールを許可する AWS リージョン と Lambda ARN を選択します。

   注記

   適切なプリンシパルポリシーが自動的に追加され、 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. 指定された Lambda 関数 ARN をオーソライザーとして使用するように AWS AppSync 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 認可メカニズムとして使用されたとき、その Lambda 関数が持つさまざまな認証状態および認証失敗状態を示しています。

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

SigV4 と OIDC トークンの認可制限を回避する

以下の方法を使用すると、特定の認可モードが有効になっている場合に SigV4 署名または OIDC トークンを Lambda 認可トークンとして使用できないという問題を回避できます。

AWS AppSyncの API に対して AWS_IAM および AWS_LAMBDA 認可モードが有効になっているとき、SigV4 署名を Lambda 認可トークンとして使用する場合は、次の操作を行います。

OPENID_CONNECT 認可モードまたは AMAZON_COGNITO_USER_POOLSおよび 認可モードが の API に対して有効になっているときに、OIDC トークンを Lambda AWS AppSyncAWS_LAMBDA認可トークンとして使用する場合は、以下を実行します。

AWS_IAM 認可

この承認タイプでは、GraphQL API に対して AWS 署名バージョン 4 署名プロセスを使用する必要があります。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 オペレーションのみにアクセスを制限するには、ルートの Query、Mutation、Subscription の各フィールドに対してこれを実行します。

{
   "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 は、 AWS AppSync に提供する唯一の必須設定値です (例: https://auth.example.com）。この URL は HTTPS 経由でアドレス可能である必要があります。 AWS AppSync は発行者 URL /.well-known/openid-configuration に を追加し、OpenID Connect Discovery 仕様https://auth.example.com/.well-known/openid-configurationに従って で OpenID 設定を見つけます。 OpenID この URL で RFC5785 準拠の JSON ドキュメントを取得するものとします。この JSON ドキュメントには、署名jwks_uriキーを含む JSON Web Key Set (JWKS) ドキュメントを指すキーが含まれている必要があります。 AWS AppSync では、JWKS に ktyおよび の JSON フィールドが含まれている必要がありますkid。

AWS AppSync は、幅広い署名アルゴリズムをサポートしています。

RSA アルゴリズムを使用することをお勧めします。プロバイダーによって発行されたトークンに、トークンが発行された時刻 (iat) が含まれている必要があり、認証された時刻 (auth_time) が含まれる場合があります。発行時刻の TTL 値 (iatTTL) および認証時刻の TTL 値 (authTTL) を、追加の検証用に OpenID Connect 設定に入力できます。使用するプロバイダーが複数のアプリケーションを認可している場合は、クライアント ID で認可するために使用される正規表現を (clientId) も入力できます。clientId が OpenID Connect 設定に存在する場合、 AWS AppSync は、 がトークン内の audまたは クレームのいずれかと一致するclientIdように要求することで、 azp クレームを検証します。

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

AMAZON_COGNITO_USER_POOLS 認可

この認可タイプでは、Amazon Cognito ユーザープールによって提供される OIDC トークンが使用されます。アプリケーションは、別のアカウントのユーザープールとユーザープールの両方のユーザーとグループを活用し AWS 、これらを GraphQL フィールドに関連付けてアクセスを制御できます。

Amazon Cognito ユーザープールを使用する場合、ユーザーが属するグループを作成できます。この情報は、GraphQL オペレーションを送信するときにアプリケーションが認可ヘッダーで AWS AppSync に送信する JWT トークンにエンコードされます。スキーマで 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"}'

追加の承認モードの使用

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

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

@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が AWS AppSync GraphQL API のデフォルトの認可タイプであると仮定します。つまり、ディレクティブのないフィールドは AWS_IAM を使用して保護されます。たとえば、Query タイプの getPost フィールドの場合です。スキーマディレクティブにより、複数の承認モードを使用できます。例えば、 AWS AppSync GraphQL API で を追加の認可モードとしてAPI_KEY設定し、 @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
}
...

きめ細かなアクセスコントロール

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

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

さらに進む前に、 AWS AppSync のマッピングテンプレートがよくわからない場合は、「リゾルバーのマッピングテンプレートリファレンス」と「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 のリゾルバーマッピングテンプレート (このセクションの最後にある例) では、投稿を作成したユーザーのみが編集を許可されるように、データストアに対する論理チェックを実行する必要があります。これは編集オペレーションなので、DynamoDB の UpdateItem に対応します。ユーザー ID 検証に渡されるコンテキストを使用して、このアクションを実行する前に条件チェックを実行できます。これは次の値を持つ Identity オブジェクトに保存されます。

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

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

Author 列としてユーザー ID を保存する addPost のリゾルバーコードの例を次に示します。

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;

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

最後に、editPost のリゾルバーコードの例を次に示します。これは、投稿を作成したユーザーからリクエストが来た場合にのみ、ブログ投稿のコンテンツを更新します。

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;

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

フィルタ処理情報

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

たとえば、ブログ投稿 DynamoDB テーブルに適切なインデックス (Author のインデックスなど) がない場合を考えます。以下のリゾルバーを使用できます。

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

リクエストハンドラは、呼び出し元が投稿の作成者でなくても、項目をフェッチします。これによってすべてのデータが返されるのを防ぐために、レスポンスハンドラは呼び出し元が項目の作成者と一致することを確認します。発信者がこのチェックに一致しない場合に、null レスポンスのみが返されます。

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

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

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

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