AWS AppSync
AWS AppSync 開発者ガイド

セキュリティ

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

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

  • API_KEY

    API キーを使用する場合。

  • AWS_IAM

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

  • OPENID_CONNECT

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

  • AMAZON_COGNITO_USER_POOLS

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

API_KEY 認証

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

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 } }" }' http://YOURAPPSYNCENDPOINT/graphql

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 オペレーションのみにアクセスを制限するには、ルートの 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 CognitoID プールなどにアタッチできる) に対応する 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 は /.well-known/openid-configuration を発行者 URL に追加し、https://auth.example.com/.well-known/openid-configuration (OpenID Connect Discovery 仕様ごとに) にある OpenID 設定を見つけます。この URL で RFC5785 準拠の JSON ドキュメントを取得するものとします。この JSON ドキュメントに jwks_uri キーが含まれている必要があります。これは JWKS JSON Web キー (JWKS) ドキュメントと署名キーを指します。

AWS AppSync では、algkty、および kid の JSON フィールドを含めるには、JWKS が必要です。

AWS AppSync は署名アルゴリズムとして 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 トークンの中にエンコードされます。これはアプリケーションが、GraphQL オペレーションを送信するときに authorizaton ヘッダーで AWS 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"}'

FGAC(Fine-Grained Access Control)

前述の情報は、特定の 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" }

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

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

{ "version" : "2017-02-28", "operation" : "PutItem", "key" : { "postId" : { "S" : "${context.arguments.id}" } }, "attributeValues" : { "Author" : {"S" : "${context.identity.username}"} #foreach( $entry in $context.arguments.entrySet() ) #if( $entry.key != "id" ) ,"${entry.key}" : { "S" : "${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" : { "S" : "${context.identity.username}" } } } }

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

フィルタ処理情報

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

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

{ "version" : "2017-02-28", "operation" : "GetItem", "key" : { "postId" : { "S" : "${context.arguments.id}" } } }

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

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

発信者がこのチェックに一致しない場合に、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 コンソールの外部でロールを作成している場合、アクセス許可はリソースに対して自動的に制限はされず、アプリケーションを本番環境に移行する前に、手動でこの処置を実施する必要があります。