AgentCore Gateway のアクセス許可を設定する
Amazon Bedrock AgentCore Gateway とその機能を使用するには、次のアクセス許可を考慮する必要があります。
-
Gateway Builder/ユーザーアクセス許可 – AgentCore ゲートウェイを作成、管理、使用できるように、ゲートウェイビルダーまたはユーザーに提供されるアクセス許可。
-
ゲートウェイサービスロールのアクセス許可 – ゲートウェイ用に作成するサービスロールに提供されるアクセス許可。これらのアクセス許可により、Amazon Bedrock AgentCore サービスはゲートウェイを呼び出す ID に代わってアクションを実行できます。
-
リソースベースのアクセス許可 – ゲートウェイサービスロールがリソースにアクセスできるようにするアクセス許可。ゲートウェイサービスロールの Amazon リソースネーム (ARN) をリソースベースのポリシー
Principalに として含めます。 -
ゲートウェイリソースベースのポリシー – ゲートウェイリソースに直接アタッチされ、呼び出せるプリンシパルを制御するポリシー。詳細については、「Amazon Bedrock AgentCore のリソースベースのポリシー」を参照してください。
注記
カスタムアクセス許可を設定しない場合は、次のオプションを使用して簡単にセットアップできます。* BedrockAgentCoreFullAccess を IAM アイデンティティにアタッチして、ゲートウェイの作成、管理、呼び出しを許可します。* AWS マネジメントコンソールまたは AgentCore CLI を使用して、適切なアクセス許可を持つ AgentCore ゲートウェイサービスロールを作成し、適切なリソースベースのポリシーを持つゲートウェイターゲットを作成して、サービスロールがそれらにアクセスできるようにします。
詳細情報については、トピックを選択してください。
Gateway ビルダーとユーザーのアクセス許可
ID がゲートウェイを作成、管理、または使用できるようにするには、アイデンティティベースのポリシーを IAM ID にアタッチして、Amazon Bedrock AgentCore 関連のアクションを実行できるようにする必要があります。包括的なアクセス許可については、BedrockAgentCoreFullAccess 管理ポリシーを使用できます。
セキュリティと制御を強化するために、フルアクセスポリシーのアクセス許可を減らすことで、独自のカスタムポリシーを作成できます。たとえば、次のポリシーでは、アイデンティティが AgentCore Gateway に関連するアクションを実行できますが、AgentCore Runtime や AgentCore Browser などの他の AgentCoreサービスには実行できません。
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:*Gateway*", "bedrock-agentcore:*WorkloadIdentity", "bedrock-agentcore:*CredentialProvider", "bedrock-agentcore:*Token*", "bedrock-agentcore:*Access*" ], "Resource": "arn:aws:bedrock-agentcore:*:*:*gateway*" } ] }
- 次のカスタムポリシーは、ゲートウェイとゲートウェイターゲットへの読み取りアクセスのみを許可する、より制限の厳しいポリシーです。
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "bedrock-agentcore:ListGateways", "bedrock-agentcore:GetGateway", "bedrock-agentcore:ListGatewayTargets", "bedrock-agentcore:GetGatewayTarget" ], "Resource": "arn:aws:bedrock-agentcore:*:*:*gateway*" } ] }
ゲートウェイアクセス許可 (インバウンド認可)
ゲートウェイ関連のアクセス許可に加えて、呼び出し中に ID がゲートウェイにアクセスできるようにアクセス許可を設定する必要があります。インバウンド認可を設定するときに、これらのアクセス許可を設定します。
AgentCore Gateway サービスロールのアクセス許可
ゲートウェイを作成するときは、IAM ロールを引き受け、IAM ロールに代わって AWS リソースと外部サービスにアクセスするためのアクセス許可を持つサービスロールが必要です。サービスロールは、次の方法で作成できます。
-
AWS マネジメントコンソールまたは AgentCore CLI を使用してゲートウェイを作成する場合は、必要なアクセス許可を持つサービスロールを AgentCore が自動的に作成するように選択できます。この方法を使用する場合は、この前提条件をスキップできます。
-
カスタマイズを強化するために独自のサービスロールを作成する場合は、このトピックで説明されているアクセス許可を使用してロールを設定する必要があります。サービスロールを作成してアクセス許可をアタッチする方法については、「 AWS サービスにアクセス許可を委任するロールを作成する」を参照してください。
サービスロールに必要なアクセス許可については、以下のトピックを参照してください。
信頼アクセス許可
サービスロールには、AgentCore サービスが IAM ID を引き受け、その代わりにアクションを実行できるようにする信頼ポリシーがアタッチされている必要があります。
以下は、使用できる信頼ポリシーの例です。
{ "Version":"2012-10-17", "Statement": [ { "Sid": "GatewayAssumeRolePolicy", "Effect": "Allow", "Principal": { "Service": "bedrock-agentcore.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:111122223333:gateway/gateway-name-*" } } } ] }
注記
ゲートウェイ ARN を作成する前にわからないため、サービスロールを初めて作成するときに Conditionフィールドを省略できます。ゲートウェイを作成したら、ベストプラクティスとして Conditionフィールドをポリシーに追加し、次の操作を行います。* aws:SourceAccount条件キーの値をゲートウェイが属するアカウントの ID に置き換えます。* aws:SourceArn条件キーをゲートウェイの ARN に置き換えます。
アウトバウンド認可のアクセス許可
ゲートウェイターゲットに使用するアウトバウンド認可のタイプに応じて、サービスロールにアクセス許可を追加して、ターゲットの呼び出しを許可する必要があります。これらのアクセス許可により、ゲートウェイサービスロールはターゲットを呼び出すための認可認証情報を取得できます。これは、アウトバウンド認可を設定するプロセスで実行できます。
AWS リソースへのアクセス許可
ゲートウェイのセットアップまたはゲートウェイに追加するターゲットによっては、ゲートウェイサービスロールにアクセス許可を追加して AWS 、リソースへのアクセスを許可する必要がある場合があります。以下のトピックでは、ゲートウェイサービスロールがアクセスする必要がある可能性のあるリソースについて説明します。
Lambda ターゲットをゲートウェイにアタッチする場合は、以下を実行して AgentCore Gateway サービスロールが関数を呼び出せるようにするためのアクセス許可を追加する必要があります。
-
Lambda 関数リソースに対する
lambda:InvokeFunctionアクションを許可するアイデンティティベースのポリシーを AgentCore Gateway サービスロールにアタッチします。 -
(関数がゲートウェイサービスロールとは異なるアカウントにある場合) リソースベースのポリシーを Lambda 関数にアタッチし、ゲートウェイサービスロールプリンシパルが Lambda 関数リソースに対して
lambda:InvokeFunctionアクションを実行できるようにします。
アクセス許可を設定する方法については、トピックを選択してください。
トピック
===== アイデンティティベースのポリシーをゲートウェイサービスロールにアタッチする
ゲートウェイサービスロールが Lambda ターゲットにアクセスできるようにするには、「ユースケースに関連する IAM ID アクセス許可の追加と削除」のトピックを選択し、手順に従って、次のアイデンティティベースのポリシーを AgentCore Gateway サービスロールにアタッチします。
{ "Version": "2012-10-17", "Statement": [{ "Sid": "AmazonBedrockAgentCoreGatewayLambdaProd", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": [ "arn:aws:lambda:us-east-1:123456789012:function:FunctionName" ] }] }
Resource フィールドの ARN を Lambda 関数ゲートウェイターゲットの ARN に置き換えます。ゲートウェイに複数の Lambda ターゲットがある場合は、各関数の ARN をResourceリストに追加できます。
===== (関数が別のアカウントにある場合) リソースベースのポリシーを Lambda 関数にアタッチする
Lambda 関数ターゲットがゲートウェイサービスロールとは異なるアカウントにある場合は、リソースベースのポリシーをアタッチして、ゲートウェイサービスロールがアクセスできるようにする必要があります。以下は、使用できるポリシーの例です。
{ "Version":"2012-10-17", "Statement": [ { "Sid": "LambdaAllowGatewayServiceRoleMyFunction", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:role/MyGatewayExecutionRole" }, "Action": "lambda:InvokeFunction", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:MyFunction" } ] }
次のフィールドの値を置き換えます。
-
AWS– ゲートウェイサービスロールの ARN を使用します。 -
Resource– Lambda 関数の ARN を使用します。- ゲートウェイサービスロールが関数にアクセスできるようにするリソースベースのポリシーを Lambda 関数にアタッチする方法については、次のいずれかの方法を選択してください。
例
Amazon S3 URI からゲートウェイターゲットツール定義を含める場合は、バケットにアクセスするためのゲートウェイサービスロールのアクセス許可を含める必要があります。AmazonS3ReadOnlyAccess ポリシーは、サービスロールにアタッチできるポリシーの例です。セキュリティを強化Resourceするために、 を S3 の場所にスコープできます。
Smithy ターゲットを追加する場合は、Smithy モデルが参照する AWS サービスにアクセスするためのゲートウェイサービスロールのアクセス許可を追加する必要があります。サービスロールにアタッチする必要があるアクセス許可を確認するには、そのサービスのドキュメントを参照してください。
サービスロールにアクセス許可を追加するには、「ユースケースに関連する IAM ID アクセス許可の追加と削除」のトピックを選択し、手順に従います。
たとえば、Smithy モデルターゲットが DynamoDB テーブルにアクセスする場合、次のポリシーをアタッチして、サービスロールがテーブルに対して DynamoDB オペレーションを実行できるようにします。
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:Query", "dynamodb:Scan" ], "Resource": "arn:aws:dynamodb:*:*:table/*" } ] }
Gateway アクセス許可のベストプラクティス
- 最小特権の原則に従う
-
-
Gateway が機能するために必要なアクセス許可のみを付与する
-
可能な場合は、ワイルドカードではなく特定のリソース ARNs を使用する
-
アクセス許可を定期的に確認および監査する
-
- ロールを 関数で区切る
-
-
管理と実行に異なるロールを使用する
-
異なる目的を持つ異なるゲートウェイ用に個別のロールを作成する
-
- 安全な認証情報ストレージ
-
-
API キーと OAuth 認証情報を AWS Secrets Manager に保存
-
認証情報を定期的にローテーションする。
-
- モニタリングと監査
-
-
Gateway オペレーションの CloudTrail ログ記録を有効にする
-
アクセスパターンとアクセス許可の使用状況を定期的に確認する
-
- ポリシーで条件を使用する
-
-
アクセス許可をいつ、どのように使用できるかを制限する条件を追加する
-
管理オペレーションにソース IP 制限を使用することを検討する
-