Amazon Verified Permissions と Amazon Bedrock エージェントを使用した安全な生成 AI アプリケーションワークフローを設計する

本ブログは 2024 年 10 月 14 日に公開された「Design secure generative AI application workflows with Amazon Verified Permissions and Amazon Bedrock Agents」を翻訳したものです。

Amazon Bedrock エージェントは、生成 AI アプリケーションが様々な企業システムやデータソースにわたって複数のステップのタスクを実行できるようにします。これらは、基盤モデル（FM）の推論能力を使用してタスクを調整・分析し、正しい論理的順序に分解します。エージェントは、リクエストを満たすために必要な API を自動的に呼び出し、企業システムやプロセスと対話します。このプロセス全体を通じて、エージェントは続行可能かどうか、あるいは追加情報が必要かどうかを判断します。

お客様は、Amazon Bedrock エージェントの機能を使用して、アプリケーションワークフローをインテリジェントに調整する革新的な生成 AI アプリケーションを構築できます。このようなワークフローを構築する際、アプリケーションユーザーの権限に基づいて、アプリケーションのワークフローが認可されたデータのみで動作することを確実にするために、きめ細かなアクセスコントロールを適用することが課題となる場合があります。ユーザーコンテキスト、ロール、アクション、リソース条件に基づいてリソースへのアクセスを制御することは、アプリケーションに複数のルールをハードコーディングしたり、それらのルールを外部化するための独自の認可システムを構築する必要があるため、アプリケーションワークフローで維持することが難しい場合があります。

アプリケーションワークフローできめ細かなアクセスコントロールのために独自の認可システムを構築する代わりに、Amazon Verified Permissions をエージェントのワークフローに統合して、コンテキストを認識したきめ細かなアクセスコントロールを適用することができます。Verified Permissions は、お客様が構築したカスタムアプリケーション向けのスケーラブルな権限管理および認可サービスです。Verified Permissions は、認可コンポーネントを外部化し、ポリシー管理と管理作業を一元化することで、開発者がより迅速に安全なアプリケーションを構築できるよう支援します。

本ブログでは、請求審査システムにある保険金請求に関する質問に答える Amazon Bedrock エージェントを用いたテキストベースの生成 AI アプリケーションにおいて、Verified Permissions を使用してきめ細かなアクセスコントロールを設計する方法を示します。この保険金請求システムのユースケースでは、請求の管理者とアジャスターの 2 種類のユーザーがいます（訳者注：アジャスターとは、保険会社の顧客が事故などに遭遇した際に、保険金を適正に算出するために、保険契約の内容確認、状況把握や原因調査、損害の確認、妥当性判断、保険金額の算出、関係者との交渉などを行う職種です）。両者とも未処理の請求をリストアップできますが、請求の詳細を読み取り、変更を加えることができるのは一方のみです。また、ユーザーの地域など、カスタム属性を使用して保険金請求をフィルタリングするための権限を制限する方法も示します。本ブログでは、「Region」という用語は AWS リージョンではなく、ビジネスで定義された地域を指します。

ソリューション概要

このソリューション設計では、お客様は Amazon DynamoDB テーブルに保険金請求記録を持っており、保険金請求に関するよくある質問に答えるためのチャットベースのアプリケーションを構築したいと想定しています。このチャットアシスタントは、保険金請求の管理者やアジャスターが内部で使用し、顧客の質問に答えるために利用されます（訳者注: 以後は単に管理者またはアジャスターと記載します）。

以下は、請求チームが顧客の質問に答えるために実行する必要がある操作のリストです。

未解決の請求のリストを表示する
入力された請求番号の詳細を表示する
入力された請求番号のステータスを「完了」に更新する

お客様は、請求システムに対して以下のアクセス制御要件を持っています。

管理者は様々な地域の請求を一覧表示できますが、個別の請求記録を読むことはできません
アジャスターは自分の地域の請求を一覧表示でき、自分に割り当てられた請求の記録を読み取り、更新できます。ただし、アジャスターは他の地域の請求にアクセスできません
Amazon Cognito のグループを用いてアプリケーションレベルの権限が設定・管理されます
お客様は Verified Permissions を使用して、アプリケーションロジックをハードコーディングせずに、エンティティとレコードレベルの認可の決定を外部化したいと考えています

チャットアシスタントの性能を向上させるため、お客様は Amazon Bedrock 上で利用可能な FM を使用します。請求テーブルから必要な情報を取得し、リクエストを動的に調整するために、お客様は Amazon Bedrock エージェントを Verified Permissions と共に使用し、エージェントの呼び出しに対してきめ細かい粒度の認可を提供します。

きめ細かいアクセス制御を備えた生成 AI ベースの請求アプリケーションの例を構築するため、アプリケーションアーキテクチャを以下の図に示します（訳者注: アーキテクチャやフローの説明に Claims という単語が出てきますが、これは保険金請求を示す用語で、以後単に請求と訳している個所もあります）。

アプリケーションのアーキテクチャフローは以下の通りです。

ユーザーが生成 AI の保険金請求ウェブアプリケーション (App) にアクセスします。
App は Amazon Cognito サービスでユーザーを認証し、ID トークンとアクセストークンを発行します。ID トークンにはユーザーのアイデンティティとカスタム属性が含まれています。
ユーザーは App を使用して「オープンな請求の一覧表示」を要求します。リクエストはユーザーの ID トークンとアクセストークンと共に送信されます。App は Claims API Gateway の API を呼び出し、ユーザーリクエストとトークンを渡す Claims Proxy 関数を実行します。
Claims API Gateway はカスタムオーソライザーを実行してアクセストークンを検証します。
アクセストークンの検証が成功すると、Claims API Gateway はユーザーリクエストを Claims Proxy 関数に送信します。
Claims Proxy 関数はユーザーリクエストと ID トークンを渡して Amazon Bedrock エージェントを呼び出します。Amazon Bedrock エージェントは、Anthropic の Claude モデルを使用し、Claims Agent Helper AWS Lambda を使用してアクションを呼び出すように設定されています。
Amazon Bedrock エージェントは chain-of-thought プロンプティングを使用し、Claims Agent Helper の助けを借りて、実行する API アクションのリストを構築します。
Claims Agent Helper は Claims DB から請求レコードを取得し、請求リストオブジェクトを構築します。この例では、Lambda 関数にハードコードされた例を提供しており、例示したソリューションに DynamoDB は追加されていません。ただし、データが Lambda 外に保存される実際のユースケースを表現するために、アーキテクチャにコンポーネントを記載しています。
Claims Agent Helper は ID トークンからユーザーのメタデータ（名前など）を取得し、Verified Permissions データエンティティを構築し、Verified Permissions 認可リクエストを行います。このリクエストには、プリンシパル（ユーザーと役割）、アクション（ListClaimなど）、リソース（Claim）が含まれます。Verified Permissions はリクエストを Verified Permissions ポリシーと照らし合わせて評価し、許可または拒否の決定を返します。その後、Claims Agent Helper はその決定に基づいて請求をフィルタリングします。Verified Permissions には「デフォルト拒否」機能があり、明示的な許可がない場合、サービスはデフォルトで暗黙的に拒否します。リクエストに関与するポリシーに明示的な拒否がある場合、Verified Permissions はリクエストを拒否します。
Claims Amazon Bedrock エージェントは認可された請求リストを受け取り、プロンプトを補強して Claude モデルに応答を求めます。エージェントは応答結果をユーザーに返します。

詳細なアクセス制御のフロー

お客様のアクセス制御要件に基づき、以下のシステムシーケンス図に示すように、3 つの詳細なアクセス制御のフローがあります。

ユースケース：管理者が地域を跨いで請求を一覧表示できる

以下の図は、管理者が地域を跨いで請求を一覧表示する方法を示しています。

以下の図は、管理者の請求記録への詳細なアクセスがどのように実行されるかを示しています。この図では、Verified Permissions からの拒否の決定に注目してください。これは、プリンシパルの役割が ClaimsAdjuster ではないためです。

ユースケース: アジャスターは自分が所有する請求を閲覧できる

以下の図は、アジャスターが請求の詳細を取得するためのきめ細かなアクセス権限がどのように実行されるかを示しています。この図では、Verified Permissions からの許可の決定に注目してください。プリンシパルの役割が ClaimsAdjuster であり、リソース所有者（つまり、請求の所有者）がユーザープリンシパル（つまり、user=alice）と一致するためです。

以下の図は、アジャスターの未解決請求リストへの詳細なアクセスがどのように実行されるかを示しています。この図では、Verified Permissions からの許可の決定に注目してください。プリンシパルのグループが ClaimsAdjuster であり、リソース上の地域がプリンシパルの地域と一致するためです。この認可ポリシーの地域フィルターの結果、ユーザーの地域の未解決請求のみが返されます。Verified Permissions は、認可の決定のためにプリンシパル、アクション、および個々のリソース（つまり、請求記録）に対して機能します。したがって、Lambda 関数は未解決請求のリストを反復処理し、各請求記録に対して isAuthorized リクエストを行う必要があります。これがパフォーマンスの問題を引き起こす場合、BatchIsAuthorized API を使用して、1 回の API 呼び出しで複数の authzRequest を送信することができます。

エンティティの設計に関する考慮事項

きめ細かいデータアクセスコントロールを設計する際は、アプリケーションの ER 図から始めるのがベストプラクティスです。私たちの請求アプリケーションでは、ユーザーは請求記録のリストを取得したり、個別の請求記録の詳細を取得したり、請求記録のステータスを更新したりするために請求記録を操作します。以下の図は、Verified Permissions でモデル化されたこのアプリケーションの ER 図です。Verified Permissions では、ロールベースアクセスコントロール（RBAC）と属性ベースアクセスコントロール（ABAC）の両方を適用できます。

以下は、RBAC（役割ベースのアクセス制御）と ABAC（属性ベースのアクセス制御）で使用される各エンティティと属性の簡単な説明です。

Application (アプリケーション) – このアプリケーションは、Amazon Bedrock エージェントを使用したチャットベースの生成 AI アプリケーションで、質問を理解し、関連する請求データを取得して、管理者とアジャスターを支援します。
Claim (請求) – 請求は DynamoDB テーブルに保存される保険金請求記録を表します。請求システムは請求記録を保存し、チャットボットアプリケーションはユーザーがこれらの記録を取得および更新することを可能にします。
User (ユーザー) – ユーザーです。
Role (役割) – 役割はアプリケーション内でのユーザーのアクセス権を表します。利用可能な役割は以下の通りです。
- 管理者 – 様々な地理的地域にわたる請求を一覧表示できますが、個々の請求記録を読むことはできません
- アジャスター – 自身がアクセス可能な地域の請求の一覧表示、請求記録の読み取り、更新ができます

これらの役割は Amazon Cognito と Verified Permissions を通じて管理されます。Cognito はユーザーがどの役割に割り当てられているかの記録を保持し、この情報をトークンに含めます。Verified Permissions はその役割が何を許可されているかの記録を保持します。きめ細かなアクセス制御により、ユーザーの役割に応じた適切な権限が確実に付与され、機微性の高い請求データへのアクセスが地域やユーザーグループに基づいて制限されます。

きめ細かな認可: ポリシー設計

アクションダイアグラムビューでは、ポリシーストアで設定したプリンシパルの種類、それらが実行可能なアクション、およびアクションを実行できるリソースが表示されます。エンティティ間の線は、プリンシパルがリソースに対してアクションを実行することを許可するポリシーを作成できることを示しています。以下の画像は、保険金請求のユースケースに関する Verified Permissions のアクションダイアグラムを示しています。ユーザープリンシパルは、Get、List、およびUpdate アクションへのアクセス権を持ちます。リソースは、アプリケーションやアプリケーション内の請求といったエンティティです。このダイアグラムは、ポリシー定義を管理する基礎となるスキーマを生成します。

ユースケース: 請求の管理者が全地域のクレーム記録を一覧表示できる

ポリシーとは、プリンシパルがリソースに対して 1 つ以上のアクションを実行することを許可または禁止する宣言です。各ポリシーは他のポリシーとは独立して評価されます。このユースケースに対する Verified Permissions のポリシーは、以下のコード例に示されています。このポリシーでは、プリンシパル（ここではユーザーの Bob）に管理者の役割が割り当てられています。

permit (
    principal in avp::claim::app::Role::"ClaimsAdministrator",
    action in [
    avp::claim::app::Action::"ListClaim"
    ],
    resource
) ;

ユースケース: 管理者が請求の詳細記録にアクセスできない

このユースケースの Verified Permissions ポリシーは、以下のコード例で示されています。明示的な「禁止」ポリシーの使用は有効な方法です。

forbid (
    principal in avp::claim::app::Role::"ClaimsAdministrator",
    action in [
    avp::claim::app::Action::"GetClaim"
    ],
    resource
) ;

ユースケース: アジャスターは自身の担当地域内の請求を一覧表示できる

このユースケースに対する Verified Permissions ポリシーを以下のコード例に示します。このポリシーでは、プリンシパル（つまりユーザーの Alice）にアジャスターの役割が割り当てられ、その地域が ID トークンのカスタム属性として渡されます。

permit (
    principal in avp::claim::app::Role::"ClaimsAdjuster",
    action in [
    avp::claim::app::Action::"ListClaim"
    ],
    resource
) when {
    resource has owner &&
    principal == resource.owner &&
    principal has custom &&
    principal.custom has region &&
    principal.custom.region == resource.region
};

ユースケース: アジャスターは、自身が担当している請求を取得または更新することができる

permit (
    principal in avp::claim::app::Role::"ClaimsAdjuster",
    action in [
    avp::claim::app::Action::"GetClaim",
     avp::claim::app::Action::"UpdateClaim"
    ],
    resource
) when {
    principal == resource.owner&&
    principal has custom &&
    principal.custom has region &&
    principal.custom.region == resource.region
};

認証設計の考慮事項

このユースケースにおける Amazon Cognito の設定は、標準的な設定ワークフローの一部として含まれるセキュリティプラクティスに従っています。強力なパスワードポリシー、多要素認証（MFA）、そしてクライアントシークレットです。Amazon Cognito を Verified Permissions と共に使用する場合、アプリケーションはユーザープールのアクセストークンまたは ID トークンを Verified Permissions に渡して、許可または拒否の決定を行うことができます。Verified Permissions は、ポリシーストアに保存されているポリシーに基づいてユーザーのリクエストを評価します。

カスタム属性については、アジャスターが見ることができる請求を制限するために region を使用しており、アジャスター自身の地域外で行われた請求を除外しています。また、Amazon Bedrock エージェントに渡される ID トークンにその情報を提供するために、ロールをカスタム属性として使用しています。ユーザーが Cognito ユーザープールに登録される際、これらのカスタム属性はサインアッププロセスの一部として記録されます。

Amazon Cognito はコンソールの Identity sources セクションを通じて Verified Permissions と統合されます。以下のスクリーンショットは、Cognito ユーザープールを Amazon Verified Permissions ポリシーストアに接続したことを示しています。

きめ細かな認可: Amazon Bedrock エージェントに ID トークンを渡す

ユーザーが Cognito ユーザープールに対して認証されると、クライアントアプリケーションに ID トークンとアクセストークンが返されます。ID トークンは API Gateway と Proxy Lambda 関数を通じて、invoke_agent 呼び出しの SessionAttributes を介して渡されます。

# Invoke the agent API
response = bedrock_agent_runtime_client.invoke_agent(
    …    
    sessionState={
        'sessionAttributes': {
            'authorization_header': '<AUTHORIZATION_HEADER>'
        }
    },
)

Lambda イベントからヘッダーが取得され、Action Group Lambda 関数内で Verified Permissions を使用して、ユーザーのアクセスが希望のアクションに対して検証されます。

# Retrieve session attributes from event and use it to validate action
sessAttr = event.get("sessionAttributes")
auth, reason = verifyAccess(sessionAttributes, action_id)

きめ細かな認可: Amazon Bedrock エージェントとの統合

Cognito が発行する ID トークンには、ユーザーのアイデンティティとカスタム属性が含まれています。この ID トークンは Amazon Bedrock エージェントに渡され、Agent Helper Lambda はエージェントのセッション属性からそのトークンを取得します。その後、Agent Helper Lambda は DynamoDB から未処理な請求記録を取得し、Verified Permissions のスキーマエンティティを構築して、isAuthorized API コールを行います。

Verified Permissions のリソースは個々の記録のレベル（つまり、単一の請求記録）で動作するため、請求リストオブジェクトを反復処理し、認可の決定のために isAuthorized API コールを行い、フィルタリングされた請求リストを作成する必要があります。フィルタリングされた請求リストは呼び出し元に返されます。その結果、アジャスターは自分の地域の請求のみを見ることができ、管理者はすべての地域の請求を見ることができます。

Amazon Bedrock エージェントは、このフィルタリングされた請求リストを使用して、ユーザーの請求リスト表示リクエストを完了します。チャットアプリケーションは、ユーザーが閲覧を許可された請求記録にのみアクセスでき、Amazon Bedrock エージェントのワークフローと統合されたきめ細かなアクセス制御を提供します。

はじめるにあたって

Amazon Verified Permissions を使用して安全な生成 AI アプリケーションの開発を始めるには、私たちのコードをご確認ください。本ブログで説明したアーキテクチャの完全な実装と、異なるユーザーの権限をテストできるデモ UI を提供しています。このサンプルを更新して、お客様のユースケースに合わせた生成 AI アプリケーションを実装してください。

まとめ

本ブログでは、生成 AI アプリケーションにおけるエージェントワークフローに対するきめ細かなアクセス制御の適用に関する課題について議論しました。Amazon Bedrock エージェントを使用してワークフローをオーケストレーションし、Amazon Verified Permissions を使用してきめ細かなアクセス制御を適用するチャットベースの生成 AI アプリケーションの例を構築するためのアプリケーションアーキテクチャを共有しました。ペルソナに基づくアクセス制御ワークフローの設計を通じて、きめ細かなアクセス権限をどのように設計するかについて説明しました。生成 AI エージェントベースのワークフローにきめ細かな権限を適用するためのスケーラブルで安全な方法をお探しの場合は、このソリューションを試してフィードバックをお寄せください。

著者について

Ram Vittal はアマゾンウェブサービス（AWS）のプリンシパル ML ソリューションアーキテクトです。分散型、ハイブリッド、クラウドアプリケーションの設計と構築において 30 年以上の経験を持っています。エンタープライズのお客様のクラウド導入と最適化のジャーニーを支援し、ビジネス成果を向上させるため安全で拡張性があり信頼性の高い AI/ML およびビッグデータソリューションの構築に情熱を注いでいます。余暇にはバイクに乗ったり、3 歳のシーパドゥードルと散歩したりしています。

Samantha Wylatowska はアマゾンウェブサービス（AWS）のソリューションアーキテクトです。DevSecOps のバックグラウンドを持ち、自動化の力を活用してシームレスなクラウド体験を実現するため、組織を安全で効率的な運用へと導くことに情熱を注いでいます。自由時間には、音楽、文学、映画を通じて新しいことを学んでいます。

Anil Nadiminti はアマゾンウェブサービス（AWS）のシニアソリューションアーキテクトで、組織がクラウドコンピューティングと AI を活用してデジタル変革とイノベーションを実現できるよう支援することを専門としています。拡張性のあるソリューションの設計とデータ駆動型戦略の実装に関する彼の専門知識により、企業は今日の急速に進化する技術環境において革新・成長することができます。

Michael Daniels はアマゾンウェブサービス（AWS）の AI/ML スペシャリストです。複雑で困難なビジネス課題に対する AI/ML および生成 AI ソリューションの構築とリードに専門性があり、テキサス大学での博士号とジョージア工科大学での機械学習専攻のコンピューターサイエンス修士号によってその専門性が強化されています。最先端のクラウド技術を適用して業界をリードする組織のイノベーション、インスピレーション、変革を実現すると同時に、あらゆるレベルや規模のステークホルダーと効果的にコミュニケーションを取ることに長けています。余暇はスキーやスノーボードを楽しんでいます。

Maira Ladeira Tanke はアマゾンウェブサービス（AWS）のシニア生成 AI データサイエンティストです。機械学習のバックグラウンドを持ち、様々な業界のお客様とのAIアプリケーションの設計と構築に 10 年以上の経験があります。テクニカルリードとして、Amazon Bedrock での生成 AI ソリューションを通じて、お客様がビジネス価値の達成を加速できるよう支援しています。自由時間には、旅行を楽しんだり、猫と遊んだり、暖かい場所で家族と過ごしたりしています。

翻訳はプロフェッショナルサービス本部の藤浦雄大が担当しました。

Amazon Web Services ブログ