Amazon API Gateway
開発者ガイド

Amazon API Gateway リソースポリシーが認証ワークフローに影響を与える方法

API にアタッチされたリソースポリシーを API Gateway が評価すると、以降のセクションのフローチャートに示すように、結果は API に対して定義した認証タイプによって影響を受けます。

API Gateway リソースポリシーのみ

このワークフローでは、API Gateway リソースポリシーは API にアタッチされますが、認証タイプは API に対して定義されません。ポリシーの評価により、呼び出し元のインバウンド条件に基づいて、明示的な許可の検索が呼び出されます。暗黙的な拒否または明示的な拒否により、呼び出し元が拒否されます。

以下に、このようなリソースポリシーの例を示します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:region:account-id:api-id/", "Condition": { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ] } } } ] }

Lambda オーソライザーとリソースポリシー

このワークフローでは、Lambda オーソライザーはリソースポリシーに加えて API に対して設定されます。リソースポリシーは 2 つの段階で評価されます。Lambda オーソライザーを呼び出す前に、API Gateway は最初にポリシーを評価し、明示的な拒否を確認します。見つかった場合、呼び出し元は即座にアクセスを拒否されます。それ以外の場合、Lambda オーソライザーが呼び出され、ポリシードキュメントを返します。これはリソースポリシーと一緒に評価されます。結果は、以下の表 A に基づいて決定されます。

次のリソースポリシー例では、VPC エンドポイント ID が vpce-1a2b3c4d である VPC エンドポイントからのみ、呼び出しを許可します。認証前の評価中は、以下に示す VPC エンドポイントからの呼び出しのみが、Lambda オーソライザーを評価することを許可されます。残りの呼び出しはすべてブロックされます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "execute-api:Invoke", "Resource": [ "arn:aws:execute-api:region:account-id:api-id/" ], "Condition" : { "StringNotEquals": { "aws:SourceVpce": "vpce-1a2b3c4d" } } } ] }

IAM 認証とリソースポリシー

このワークフローでは、リソースポリシーに加えて API に対して IAM 認証が設定されます。IAM サービスを使用してユーザーを認証した後、IAM ユーザーにアタッチされたポリシーが、リソースポリシーに加えて一緒に評価されます。この結果は、呼び出し元が API 所有者と同じアカウントであるか、別の AWS アカウントであるかによって異なります。呼び出し元と API 所有者が別のアカウントである場合、IAM ユーザーポリシーとリソースポリシーの両方により、呼び出し元は明示的に続行が許可されます(以下の表 B を参照してください)。 これとは対照的に、呼び出し元および API 所有者が同じアカウントである場合、ユーザーポリシーまたはリソースポリシーで、呼び出し元の続行を明示的に許可する必要があります(以下の表 A を参照してください)。

以下に、クロスアカウントリソースポリシーの例を示します。このリソースポリシーでは、IAM ユーザーポリシーに許可が含まれていることを想定し、VPC ID が vpc-2f09a348 である VPC からの呼び出しのみが許可されます(以下の表 B を参照してください)。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "", "Action": "execute-api:Invoke", "Resource": [ "arn:aws:execute-api:region:account-id:api-id/" ], "Condition" : { "StringEquals": { "aws:SourceVpc": "vpc-2f09a348" } } } ] }

Amazon Cognito 認証とリソースポリシー

このワークフローでは、リソースポリシーに加えて Amazon Cognito ユーザープール が API に対して設定されます。API Gateway は Amazon Cognito を介して最初に呼び出し元の認証を試みます。これは通常、呼び出し元から提供された JWT トークンを介して実行されます。認証が成功した場合、リソースポリシーは個別に評価され、明示的な許可が必要です。拒否の場合は拒否になり、許可と拒否のどちらでもない場合も拒否になります。Amazon Cognito ユーザープール と一緒に使用される可能性のあるリソースポリシーの例を以下に示します。

次の例では、指定されたソース IP からのみ呼び出しを許可するリソースポリシーの例を示します。Amazon Cognito 認証トークンには許可が含まれていると想定します(以下の表 A を参照してください)。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": "*", "Action": "execute-api:Invoke", "Resource": "arn:aws:execute-api:region:account-id:api-id/", "Condition": { "IpAddress": { "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ] } } } ] }

ポリシー評価の結果の表

表 A は、API Gateway API へのアクセスが IAM ポリシー (または Lambda、Amazon Cognito ユーザープール オーソライザー) および API Gateway リソースポリシーによって制御されるときの動作を示しています。これらはどちらも同じ AWS アカウントにあります。

表 A: アカウント A が所有する API をアカウント A が呼び出す

IAM ユーザーポリシー (または、Lambda、Amazon Cognito ユーザープール オーソライザー) API Gateway リソースポリシー 結果として生じる動作
許可 許可 許可
許可 許可も拒否もしない 許可
許可 拒否 明示的な拒否
許可も拒否もしない 許可 許可
許可も拒否もしない 許可も拒否もしない 暗黙的な拒否
許可も拒否もしない 拒否 明示的な拒否
拒否 許可 明示的な拒否
拒否 許可も拒否もしない 明示的な拒否
拒否 拒否 明示的な拒否

表 B は、API Gateway API へのアクセスが IAM ポリシー (または Lambda、Amazon Cognito ユーザープール オーソライザー) および API Gateway リソースポリシーによって制御されるときの動作を示しています。これらはどちらも異なる AWS アカウントにあります。どちらかがサイレントである (許可でも拒否でもない) 場合、クロスアカウントアクセスは拒否されます。これは、クロスアカウントアクセスでは、リソースポリシーと IAM ポリシー (または Lambda、Amazon Cognito ユーザープール オーソライザー) で明示的にアクセス権が付与される必要があるためです。

表 B: アカウント A が所有する API をアカウント B が呼び出す

IAM ユーザーポリシー (または、Lambda、Amazon Cognito ユーザープール オーソライザー) API Gateway リソースポリシー 結果として生じる動作
許可 許可 許可
許可 許可も拒否もしない 暗黙的な拒否
許可 拒否 明示的な拒否
許可も拒否もしない 許可 暗黙的な拒否
許可も拒否もしない 許可も拒否もしない 暗黙的な拒否
許可も拒否もしない 拒否 明示的な拒否
拒否 許可 明示的な拒否
拒否 許可も拒否もしない 明示的な拒否
拒否 拒否 明示的な拒否