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

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 サービスを使用してユーザーを認証した後、API は、ユーザーにアタッチされたポリシーとリソースポリシーの両方を評価します。この結果は、発信者が API 所有者と同じ AWS アカウント にいるか、API 所有者とは別の AWS アカウント にいるかに応じて異なります。

呼び出し元と API 所有者が別のアカウントである場合、IAM ポリシーとリソースポリシーの両方により、呼び出し元は明示的に続行が許可されます 詳細については、[テーブル B] を参照してください。

ただし、呼び出し元および API 所有者が同じ AWS アカウント である場合、IAM ユーザーポリシーまたはリソースポリシーで、呼び出し元の続行を明示的に許可する必要があります 詳細については、[テーブル A] を参照してください。

以下に、クロスアカウントリソースポリシーの例を示します。このリソースポリシーでは、IAM ポリシーに Allow Effect が含まれていることを想定し、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 認証とリソースポリシー

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

次の例では、指定されたソース IP からのみ呼び出しを許可するリソースポリシーの例を示します。Amazon Cognito 認証トークンには許可が含まれていると想定します 詳細については、[テーブル B] を参照してください。

{ "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 ポリシーによって制御されているか、同じ AWS アカウント 内にある Lambda オーソライザーと API Gateway リソースポリシーによって制御されている場合です。

テーブル A: アカウント A が所有する API をアカウント A が呼び出す
IAM ポリシー (または Lambda オーソライザー) API Gateway リソースポリシー 結果として生じる動作
許可 許可 許可
許可 許可も拒否もしない 許可
許可 拒否 明示的な拒否
許可も拒否もしない 許可 許可
許可も拒否もしない 許可も拒否もしない 暗黙的な拒否
許可も拒否もしない 拒否 明示的な拒否
拒否 許可 明示的な拒否
拒否 許可も拒否もしない 明示的な拒否
拒否 拒否 明示的な拒否

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

テーブル B: アカウント A が所有する API をアカウント B が呼び出す
IAM ポリシー (または Amazon Cognito ユーザープールオーソライザー) API Gateway リソースポリシー 結果として生じる動作
許可 許可 許可
許可 許可も拒否もしない 暗黙的な拒否
許可 拒否 明示的な拒否
許可も拒否もしない 許可 暗黙的な拒否
許可も拒否もしない 許可も拒否もしない 暗黙的な拒否
許可も拒否もしない 拒否 明示的な拒否
拒否 許可 明示的な拒否
拒否 許可も拒否もしない 明示的な拒否
拒否 拒否 明示的な拒否