Gateway によるヘッダー伝達
ヘッダーとクエリパラメータの伝播とは
ヘッダー伝達とは、ゲートウェイを介した受信リクエストから設定されたターゲットへの選択的 HTTP ヘッダーの体系的な転送と、クライアントへのレスポンスヘッダーの選択的な転送を指します。ヘッダー伝達と同様に、クエリパラメータ伝達は、受信リクエストから設定されたターゲットへの URL クエリパラメータの転送を可能にします。この機能は、クライアントとターゲット間でコンテキスト、認証、トレース、その他の重要な情報を交換する必要があるユースケースに使用できます。ゲートウェイへの呼び出しツール呼び出しで提供される、またはカスタムインターセプター Lambda から送信される、事前に許可リストに登録されたヘッダーは、特定のターゲットに転送されます。
この機能は、責任共有モデルとして動作します。
-
AWS の責任は、ターゲットに対して許可リストに登録したヘッダーとクエリパラメータを安全に渡すことです。
-
ユーザーの責任は注意し、ターゲット に不可欠な伝播用のヘッダーのみを許可リストに登録して、セキュリティと機能の要件を確実に満たすことです。
ヘッダーの制限
セキュリティを維持し、機密情報の漏洩を防ぐために、次のヘッダーは制限されており、伝播用に設定することはできません。
|
認可* |
|
Proxy-Authorization |
|
WWW 認証 |
|
Accept |
|
Accept-Charset |
|
Accept-Encoding |
|
Accept-Language |
|
Content-Type |
|
Content-Length |
|
Content-Encoding |
|
Content-Language |
|
Content-Location |
|
コンテンツ範囲 |
|
Cache-Control |
|
ETag |
|
有効期限 |
|
If-Match |
|
If-Modified-Since |
|
If-None-Match |
|
If-Range |
|
If-Unmodified-Since |
|
Last−Modified |
|
Pragma |
|
異なる |
|
接続 |
|
Keep-Alive |
|
Proxy-Connection |
|
アップグレード |
|
ホスト |
|
ユーザーエージェント |
|
リファラー |
|
から |
|
Range |
|
Accept-Ranges |
|
Transfer-Encoding |
|
TE |
|
Trailer |
|
サーバー |
|
日付 |
|
ロケーション |
|
再試行後 |
|
設定 - Cookie |
|
Cookie |
|
Content-Security-Policy |
|
Content-Security-Policy-Report-Only |
|
Strict-Transport-Security |
|
X-Content-Security-Policy |
|
X-Frame-Options |
|
X-XSS-Protection |
|
リファラーポリシー |
|
アクセス許可ポリシー |
|
Cross-Origin-Embedder-Policy |
|
Cross-Origin-Opener-Policy |
|
Cross-Origin-Resource-Policy |
|
Access-Control-Allow-Origin |
|
Access-Control-Allow-Methods |
|
Access-Control-Allow-Headers |
|
Access-Control-Allow-Credentials |
|
Access-Control-Expose-Headers |
|
Access-Control-Max-Age |
|
Access-Control-Request-Method |
|
Access-Control-Request-Headers |
|
オリジン |
|
Accept-CH |
|
Accept-CH-Lifetime |
|
DPR |
|
Width |
|
ビューポート幅 |
|
Downlink |
|
ECT |
|
RTT |
|
データの保存 |
|
Clear-Site-Data |
|
Feature-Policy |
|
Expect-CT |
|
Public-Key-Pins |
|
Public-Key-Pins-Report-Only |
|
X-Forwarded-For |
|
X-Forwarded-Host |
|
X-Forwarded-Proto |
|
X-Real-IP |
|
X-Requested-With |
|
X-CSRF-Token |
|
CF-Ray |
|
CF-Connecting-IP |
|
X-Amz-Cf-Id |
|
X キャッシュ |
|
X-Served-By |
|
:メソッド |
|
:path |
|
:スキーマ |
|
:authority |
|
: ステータス |
|
Link |
|
Sec-WebSocket-Key |
|
Sec-WebSocket-Accept |
|
Sec-WebSocket-Version |
|
Sec-WebSocket-Protocol |
|
Sec-WebSocket-Extensions |
-
ターゲットの作成中に認可ヘッダーを許可リストに登録することはできません。ただし、インターセプターラムダによって提供されると、ターゲットに転送されます。詳細については、「インターセプター Lambda からのヘッダー伝達」を参照してください。
重要
上記の制限付きヘッダーに加えて、API キーと REST API スキーマで提供されるヘッダーをヘッダー伝達用に設定することはできません。
許可されたヘッダーには、追加の検証ルールが適用されます。
-
不正使用を防ぎ、パフォーマンスを維持するために、ターゲットあたり最大 10 個のリクエストヘッダー、10 個のレスポンスヘッダー、10 個のクエリパラメータ
-
ヘッダー名には、英数字、ハイフン、アンダースコアのみを含める必要があります (正規表現:
^[a-zA-Z0-9_-]+$) -
メモリの枯渇を防ぐため、ヘッダー値は最大 4KB に制限されています
-
ヘッダー値には、印刷可能な ASCII 文字のみを含める必要があります
-
で始まるヘッダー
X-Amzn-は禁止されます (X-Amzn-Bedrock-AgentCore-Runtime-Custom-* ヘッダーを除く)
ヘッダーとクエリパラメータの伝播の設定
ゲートウェイターゲットを作成または更新するときに、ターゲットレベルでヘッダーパラメータとクエリパラメータを設定できます。ヘッダーとクエリパラメータはターゲットごとに指定されるため、各ターゲットは必要なヘッダーのみを受信できます。
ターゲットレベルの設定
ターゲットallowedRequestHeadersの に 、、および allowedResponseHeaders allowedQueryParametersフィールドを追加して、ヘッダー伝達を設定しますmetadataConfiguration。
{ "name": "my-target", "description": "my target description", "credentialProviderConfigurations": [{ "credentialProviderType": "OAUTH", "credentialProvider": { "oauthCredentialProvider": { "providerArn": "arn:aws:bedrock-agentcore:us-west-2:123456789012:credential-provider/example", "scopes": [] } } }], "targetConfiguration": { "mcp": { "mcpServer": { "endpoint": "https://example.com/mcp" } } }, "metadataConfiguration": { "allowedRequestHeaders": [ "request-header" ], "allowedResponseHeaders": [ "response-header" ], "allowedQueryParameters": [ "query-param" ] } }
Python SDK の使用:
import boto3 # Initialize the client client = boto3.client('bedrock-agentcore', region_name='us-west-2') # Create target with header propagation response = client.create_gateway_target( gatewayId='gateway-123', name='mcp-target-with-headers', description='MCP target with header propagation', targetConfiguration={ 'mcp': { 'mcpServer': { 'endpoint': 'https://example.com/mcp' } } }, metadataConfiguration={ 'allowedRequestHeaders': ['x-correlation-id', 'x-tenant-id'], 'allowedResponseHeaders': ['x-rate-limit-remaining'], 'allowedQueryParameters': ['version'] } )
インターセプター Lambda からのヘッダー伝達
ゲートウェイでカスタムインターセプター Lambda を使用する場合、インターセプター Lambda レスポンスにヘッダーを含めることで、ヘッダーの伝播を動的に制御できます。
インターセプターヘッダー伝達の仕組み
インターセプターラムダは、次の方法でヘッダーの伝播に影響を与える可能性があります。
-
認可ヘッダーの上書き: インターセプター Lambda レスポンスの
Authorizationヘッダーがターゲットに自動的に伝達されます。Authorizationヘッダーはターゲットの許可リストでは設定できませんが、インターセプターラムダによって提供されるとターゲットに転送されます。たとえば、 のような認可トークンを提供する認証情報プロバイダーをターゲットに追加
Authorization: Bearer client-tokenし、インターセプター Lambda がAuthorization: Bearer refreshed-tokenを提供する場合、インターセプター LambdaBearer refreshed-tokenの値はターゲットに転送されます。 -
カスタムヘッダーインジェクション: Interceptor Lambda レスポンスの追加ヘッダーは、設定されたターゲットヘッダー許可リストとマージされます。
-
ヘッダーの優先順位: 競合が発生した場合、インターセプターの Lambda 提供のヘッダーがクライアント提供のヘッダーよりも優先されます。
たとえば、ターゲット設定
x-tenant-idで許可リストヘッダーを指定し、受信リクエストが を提供しx-tenant-id: tenant-123、インターセプター Lambda がx-tenant-id: tenant-456を提供する場合、インターセプター Lambdatenant-456の値はターゲットに転送されます。 -
セキュリティ検証: Lambda が提供するすべてのヘッダーには、設定されたヘッダーと同じ検証ルールが適用されます。認可ヘッダーを除き、他のすべてのヘッダーをターゲットに転送するには、ターゲットの作成時に許可リストに登録する必要があります。
インターセプターでのヘッダー伝達の実装
ターゲットに伝達されるヘッダーを返すようにインターセプター Lambda を設定します。
import json import boto3 def lambda_handler(event, context): # Extract request context request_context = event.get('requestContext', {}) user_identity = request_context.get('identity', {}) # Fetch credentials from secure store (example) credentials_client = boto3.client('secretsmanager') secret = credentials_client.get_secret_value( SecretId=f"mcp-credentials/{user_identity.get('userId')}" ) credentials = json.loads(secret['SecretString']) # Return response with headers to propagate return { "interceptorOutputVersion": "1.0", "mcp": { "transformedGatewayRequest": { "headers": { # Authorization header will be propagated automatically "Authorization": f"Bearer {credentials['access_token']}", # Custom headers (must be in target allowlist) "x-tenant-id": user_identity.get('tenantId'), "x-correlation-id": request_context.get('requestId') }, "body": event['mcp']['gatewayRequest']['body'] } } }
インターセプターヘッダーの伝播の一般的なユースケースは次のとおりです。
- 認証情報の取得
-
安全なボールトから有効期間の短いトークンを取得し、認可ヘッダーとして挿入して、クライアントアプリケーションでの認証情報の漏洩を防ぎます。
- コンテキストインジェクション
-
クライアントが提供する値を信頼するのではなく、認証されたユーザークレームから派生したテナント識別子、組織コンテキスト、またはユーザー属性を追加します。
- ヘッダー変換
-
ターゲットに到達する前に、ビジネスロジック、コンプライアンス要件、またはセキュリティポリシーに基づいてヘッダーを変換またはサニタイズします。
- 動的ルーティング
-
ユーザー属性またはシステム状態のリアルタイム分析に基づいて、ルーティングヒント、機能フラグ、または A/B テストヘッダーを挿入します。
セキュリティに関する考慮事項
インターセプター Lambda を使用してヘッダー伝達を実装する場合は、次のセキュリティのベストプラクティスに従ってください。
-
ヘッダーソースの検証: ターゲット許可リストに明示的に設定されているか、信頼できるインターセプターラムダによって返されたヘッダーのみを伝達します。
-
機密データのサニタイズ: ヘッダーを外部 MCP サーバーに転送する前に、PII と機密情報を削除またはマスクする
-
最小特権を使用する: 認証情報の取得とコンテキストの取得に必要な最小限のアクセス許可でインターセプター Lambda IAM ロールを設定する
-
監査ログ記録の実装: セキュリティのモニタリングとコンプライアンスのためのログヘッダー変換と認証情報の取得アクティビティ
-
ヘッダーコンテンツの検証: Lambda で生成されたヘッダーが、設定されたヘッダーと同じ検証ルールを満たしていることを確認します。
ベストプラクティス
ヘッダー伝達を実装するときは、次のベストプラクティスに従ってください。
- ターゲット固有の設定を使用する
-
グローバルではなく、ターゲットごとにヘッダーを設定します。ターゲットごとに異なるヘッダーが必要になる場合があり、ターゲット固有の設定によりセキュリティ分離が向上します。
- ヘッダー数を最小限に抑える
-
ターゲットが実際に必要とするヘッダーのみを伝達します。ヘッダーが多すぎると、リクエストサイズと処理オーバーヘッドが増加します。
- セマンティックヘッダー名を使用する
-
x-correlation-idトレースやx-tenant-idマルチテナンシーなど、目的を明確に示すわかりやすいヘッダー名を選択します。 - 適切なエラー処理を実装する
-
必要なヘッダーがないか無効であるケースを処理します。リクエストを失敗させるか、デフォルト値を指定するかを検討してください。
- ヘッダーの使用状況をモニタリングする
-
ゲートウェイオブザーバビリティ機能を使用して、伝播されるヘッダーをモニタリングし、ヘッダーの検証または処理に関する問題を特定します。
- テストヘッダーの伝播
-
開発およびテスト中にヘッダーがターゲットに正しく伝達されていることを確認します。リクエストのログ記録やエンドポイントのデバッグなどのツールを使用して、ヘッダーフローを検証します。