AgentCore Gatewayの呼び出し元の認可と接続先への認証を分ける
Gatewayを呼べることと、その先の顧客データを操作できることは別。inboundとoutboundの両方で、誰の権限を使い、どの対象を許すかを設計する。
用語
- inbound
- 呼び出し元からGatewayへ入る要求を扱う認証・認可。
- outbound
- Gatewayから接続先へ出る要求に使う認証。
- サービスロール
- サービスがAWSリソースへアクセスする際に使うIAMロール。
図と例
inboundで呼び出し元を確認 → 接続先の認証方式を選ぶ → outboundで接続 → 顧客と操作対象を認可
仮定の例：Gatewayへのログインは有効でも、利用者Aが顧客Bの請求書を更新する権限はない。共有接続の先のAPIが顧客Bへの更新を拒否する。
実際のサービス・製品では
Amazon Bedrock AgentCore Gateway
AWSはGatewayのinboundとoutboundを別資料で説明し、AUTHENTICATE_ONLYではGatewayが認可判断をしないことも明記している。
資料を読む
解説
Gatewayへの到達と業務操作の許可を別々に試す。別顧客IDを引数へ入れるケースや、Gatewayから広いサービス権限で接続するケースを検証する。
inboundはGatewayへの呼び出しを受け付ける側の認証・認可、outboundはGatewayが接続先へアクセスする側の認証を扱う。接続方式によりGatewayのサービスロール、呼び出し元のIAM認証情報、OAuthなどを使えるが、全方式が利用者本人の権限を伝えるわけではない。共有のサービス権限で接続する場合は、接続先で顧客・操作対象・引数の認可を検証する。AUTHENTICATE_ONLYは署名を検証してもGateway自身で認可判断をしない方式なので、通常のIAM認可と同じだと考えない。ツールの一覧を絞るだけで実行時の認可を代替しない。
トレードオフ
- 対応する接続で利用者の権限を使う
- 得るもの：接続先で本人の権限を評価しやすい
- 払うもの：対象サービスと委任方式への対応が必要
- 共有のサービス権限で接続し業務APIで認可する
- 得るもの：共通の接続を運用しやすい
- 払うもの：APIが顧客・対象・操作の許可を検証する必要がある
さらに学ぶ
チェック
inbound認証が有効で、outboundは共有のサービス権限を使う。顧客をまたぐ操作を防ぐには？
- 業務APIで利用者と顧客・操作対象の許可を検証する
- Gatewayへ入れた人には全顧客の更新を許す
- ツールの説明文に他社データ禁止と書くだけにする
解答と解説
業務APIで利用者と顧客・操作対象の許可を検証する
Gatewayへの到達許可は接続先の全データへの許可を意味しない。共有接続でも、信頼できる利用者情報に基づく業務の認可が要る。