階層化された認可による Amazon Bedrock エージェントのデータプライバシー強化

本ブログは 2024 年 10 月 2 日に公開された「Enhancing data privacy with layered authorization for Amazon Bedrock Agents」を翻訳したものとなります。

お客様は、自社のアプリケーション内で生成 AI を使用することにいくつかの利点を見出しています。ただし、生成 AI を使用すると、アプリケーションの脅威モデルを検討する際に新たな考慮事項が追加されます。これは生成 AI の利用が、オペレーション効率を高めるために顧客体験を向上させるためであっても、よりカスタマイズされた特定の結果を生成するためであっても、その他の理由であっても同様です。

生成 AI モデルは本質的に非決定論的です。つまり、同じ入力が与えられても、モデルの確率的性質により、生成される出力は異なる場合があります。Amazon Bedrock などのマネージドサービスをワークロードで使用する場合、Amazon Bedrock がアクセスするデータの保護を確実にするのに役立つ追加のセキュリティ上の考慮事項があります。

本ブログでは、生成 AI サービスを使用する際のデータのコントロールで直面する可能性のある現在の課題と、Amazon Bedrock 内のネイティブソリューションと階層化された認可を使用してそれらを克服する方法について説明します。

定義

まず始めに、いくつかの言葉の定義を確認してみましょう。

Amazon Bedrock エージェント: Amazon Bedrock エージェントを使用すると、企業のシステムやデータソースにわたる複数ステップのタスクを自律的に完了できます。エージェントは、入力データを充実させてより正確な結果を得ることや、繰り返しの多いタスクの自動化に使用できます。生成 AI エージェントは、エージェントがアクセスできる入力と環境のデータに基づいて意思決定を行うことができます。

階層化された認可: 階層化された認可とは、初めにアクセスされるポイントからアプリケーションコンポーネント間で複数の認可チェックを実装する手法です。これには、サービス間の認可、アプリケーションコンポーネント全体で真のエンドユーザーのアイデンティティを伝達すること、そしてサービスの認可に加えて各操作にエンドユーザーの認可を追加することが含まれます。

信頼できるアイデンティティの伝搬: 信頼できるアイデンティティを伝搬することで、AWS リソースへのユーザーアクセスの定義、付与、およびログ記録がより簡単になります。信頼できるアイデンティティの伝播は OAuth 2.0 の認可フレームワークに基づいて構築されているため、アプリケーションはパスワードを共有しなくてもユーザーデータに安全にアクセスして共有できます。

Amazon Verified Permissions: Amazon Verified Permissions は、証明可能な正しい Cedar ポリシー言語を使用するフルマネージド型の認可サービスであり、より安全なアプリケーションを構築できます。

チャレンジ

AWS で構築する場合、データやお客様の情報を安全に保つのに役立ついくつかのサービスや機能があります。これには、Amazon Simple Storage Service (Amazon S3) のデフォルト暗号化や AWS Key Management Service (AWS KMS) キーによる保存時の暗号化、または Amazon S3 のプレフィックスや Amazon DynamoDB のパーティションキーを使用してテナントのデータを分離することが含まれます。これらのメカニズムは、保存中のデータの処理やデータパーティションの分離には優れています。しかし生成 AI を搭載したアプリケーションがユーザーの入力に基づいてさまざまなデータ（異なるタイプの機微データ、複数のテナントのデータなど）にアクセスできるようになると、機微データが漏洩するリスクが高まります（AWS のデータプライバシーの詳細については、データプライバシーに関するよくある質問を参照してください）。これは、データへのアクセスが、ワークロードのなかで呼び出し元のプリンシパルに代わって信頼できないアイデンティティ (モデル) に渡されるためです。

多くのお客様が、ユーザーの入力に追加情報を付加して応答を改善するために、アーキテクチャに Amazon Bedrock エージェントを使用しています。またエージェントは、反復的なタスクを自動化し、ワークフローを効率化するためにも使用されます。たとえば、チャットボットは、医療提供者向けに患者の検査結果をまとめるなど、ユーザーエクスペリエンスを向上させるための便利なツールになります。ただし、チャットボットソリューションを実装する際には、潜在的なセキュリティリスクと緩和戦略を理解することが重要です。

一般的な生成 AI アプリケーションのアーキテクチャには、Amazon API Gateway を介してチャットボットエージェントを呼び出すものがあります。API Gateway は Amazon Cognito または AWS Lambda オーソライザーを使用して API 呼び出しを検証し、その後チャットボットエージェントにリクエストを渡してその機能を実行します。

チャットボットエージェントにユーザーが入力プロンプトを提供できる場合、潜在的なリスクが生じます。この入力により、プロンプトインジェクション（OWASP LLM:01）または機微情報の漏出（OWASP LLM:06）の脆弱性につながる可能性があります。根本的な原因は、チャットボットエージェントがその機能を果たすために、さまざまなデータストア (S3 バケットやデータベースなど) へのアクセス権を持つ AWS Identity and Access Management (IAM) サービスロールによる広範なアクセス権限を必要とすることです。適切なセキュリティコントロールがない場合、あるテナントの脅威アクターが、別のテナントに属するデータにアクセスしたり操作したりする可能性があります。

解決策

すべてのリスクを軽減できる単一のソリューションはありませんが、コンシューマーアプリケーションの適切な脅威モデルを用意してリスク (データへの不正アクセスなど) を特定することは重要です。AWS では、適切な脅威モデルを作成するのに役立つ、いくつかの生成 AI セキュリティ戦略を提供しています。本ブログでは、コンシューマーアプリケーションをサポートするソリューションを中心に、アプリケーション全体にわたる階層化された認可に注目します。

注: これは、ワークフォースアプリケーション向けの Trusted identity propagation (TIP) と Amazon S3 Access Grants を使用して実現することもできます。

コンシューマー向けの OpenID Connect (OIDC) アイデンティティプロバイダー (IdP) などの強力な認証プロセスを多要素認証 (MFA) と組み合わせて使用することで、API Gateway でエージェントを呼び出すためのアクセスを統制できます。図 1 に示すように、リクエストのヘッダーにある JWT トークンを使用して、エージェントにカスタムパラメーターを渡すことをお勧めします。このような構成では、エージェントが記述された機能を実行する前に、Amazon Verified Permissions を使用して isAuthorized リクエストを評価し、呼び出しユーザーが要求されたデータにアクセスできることを確認します。このアーキテクチャを図 1 に示します。

図 1: 認可アーキテクチャ

アーキテクチャの手順は次のとおりです。

クライアントはアプリケーションフロントエンドに接続します。
クライアントは、認証のための Amazon Cognito ユーザープール UI へリダイレクトされます。
クライアントは Amazon Cognito から JWT トークンを受け取ります。
アプリケーションフロントエンドは、クライアントから提示された JWT トークンを使用して Amazon Bedrock エージェントへのリクエストを認可します。アプリケーションフロントエンドは、InvokeAgent API 呼び出しに JWT トークンを追加します。
エージェントはリクエストを確認し、必要に応じてナレッジベースを呼び出たり、Lambda 関数を呼び出したりします。エージェントは、アプリケーションフロントエンドから提供された JWT トークンを Lambda 呼び出しコンテキストに含めます。
Lambda 関数は JWT トークンの詳細を使用して、Verified Permissions を使用して DynamoDB テーブルへの以降の呼び出しを認可します(6a)。呼び出しが認可された場合のみ DynamoDB テーブルを呼び出します (6b)。

ディープダイブ

Amazon Bedrock エージェントをトリガーする API Gateway の背後にあるアプリケーションを設計する場合を考えます。このとき、 AssumeRole により Amazon Bedrock へのアクセス権を付与する信頼ポリシーを使用して、エージェント用の IAM サービスロールを作成する必要があります。このロールにより、Amazon Bedrock はエージェントアクショングループの Lambda 関数用 OpenAPI スキーマを S3 バケットから取得でき、指定されたモデルへの bedrock:InvokeModel アクションが可能になります。エージェントのセッションデータを暗号化するためにデフォルトの KMS キーを選択しなかった場合は、カスタマー管理の KMS キーにアクセスするための権限を IAM サービスロールに付与する必要があります。ポリシーと信頼関係の例を次に示します。

次のポリシーは、Amazon Bedrock モデルを呼び出す権限をエージェントに付与します。“Resource“ では、承認された基盤モデル(FM)を対象としています。

{
"Version": "2012-10-17",
"Statement": [
    { 
        "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicy",
        "Effect": "Allow",
        "Action": "bedrock:InvokeModel",
        "Resource": [
            "arn:aws:bedrock:us-west-2::foundation-model/your_chosen_model"
            ]
        }
    ]
}

次に、Amazon Bedrock エージェントに s3:GetObject へのアクセスを許可するポリシーステートメントを追加します。このステートメントでは、アカウント番号が組織内のアカウント番号と一致する S3 バケットを対象とします。

{
"Version": "2012-10-17",
"Statement": [
    { 
        "Sid": "AmazonBedrockAgentDataStorePolicy",
        "Effect": "Allow",
        "Action": [
        "s3:GetObject"
        ],
        "Resource": [
            "arn:aws:s3:::S3BucketName/*"
        ],
        "Condition": {
            "StringEquals": {
                "aws:ResourceAccount": "Account_Number"
                }
            }
        }
    ]
}

最後に、定義されたロールを引き受ける権限を Amazon Bedrock に付与する信頼ポリシーを追加します。また、混乱する代理問題を防ぐため、サービスがアカウントに代わって呼び出していることを確認するための条件も追加しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AmazonBedrockAgentTrustPolicy",
            "Effect": "Allow",
            "Principal": {
                "Service": "bedrock.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "Account_Number"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:bedrock:us-west-2:Account_Number:agent/*"
                }
            }
        }
    ]
}

Amazon Bedrock エージェントはサービスロールを使用しており、一般には利用者のアイデンティティを伝搬しません。これは、テナントのデータを保護する上での潜在的な問題につながる可能性があります。エージェントが未分類のデータ（訳者注: 保護の必要ないデータ）にアクセスしている場合、認可の呼び出し元に基づいてアクセスをさらに分離する必要がないため、階層化された認可を追加する必要はありません。ただし、アプリケーションが機微データにアクセスできる場合は、認可をエージェントの機能の処理に加える必要があります。

そのためには、エージェントを呼び出してトリガーされる Lambda 関数に認可の階層を追加します。まず、エージェントを初期化して、 Verified Permissions への isAuthorized 呼び出しを行います。 Allow 応答があった場合にのみ、エージェントは残りの機能を実行します。Verified Permissions からの応答が Deny の場合、エージェントはステータス 403 またはわかりやすいエラーメッセージをユーザーに返す必要があります。

Verified Permissions には、データへのアクセス時にどのように認可を行うかを規定するポリシーがあらかじめ組み込まれている必要があります。たとえば、呼び出し元のプリンシパルが医師の場合に、患者の記録へのアクセスを許可する次のようなポリシーがあるかもしれません。

permit(
  principal in Group::"doctor", 
  action == Action::"view", 
  resource
 )
 when {
 resource.fileType == Sensitive &&
 resource.patient == doctor.patient
};

この例では、この決定を処理する認可ロジックはエージェントから呼ばれる Lambda 内にあります。そのために、Lambda 関数はまず、Amazon Bedrock エージェントにカスタムパラメータとして渡された JWT をデコードしてエンティティ構造を構築し、呼び出し元のプリンシパルのアクセスを評価します。リクエストされたデータには isAuthorized 呼び出しも含める必要があります。このデータが Verified Permissions に渡されると、提供されたコンテキストとポリシーストア内のポリシーを評価しアクセス可否を決定します。ポリシー決定ポイント (Policy Decision Point: PDP) として、許可または拒否の決定はアプリケーションレベルで実施する必要があることに注意します。この決定に基づいて、データへのアクセスが許可または拒否されます。アクセスされるリソースは、アプリケーションがアクセス制御を評価しやすいように分類する必要があります。たとえば、データが DynamoDB に保存されている場合、患者は Verified Permissions スキーマで定義された階層的に参照されるパーティションキーで区切ることも考えられます。

結論

本ブログでは、AWS ネイティブサービスを使用して Amazon Bedrock エージェントを使用するコンシューマーアプリケーション全体に階層化された認可を適用することで、データ保護を向上させる方法を学びました。また、アイデンティティプロセスを通じてアクセス制御の適用を改善する手順を説明しました。これは Amazon Bedrock エージェントを使用してアプリケーションを構築するのに役立ち、データの強力な分離を維持することで意図しない機密データの漏洩を防ぐことができます。

Verified Permissions と Amazon Bedrock エージェントを使用してアプリケーション全体に階層化された認可を適用する方法について詳しく学ぶには、「Secure Generative AI Solutions using OWASP Framework」ワークショップをお勧めします。

本ブログについて質問がある場合は、AWS サポートにお問い合わせください。

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

Amazon Web Services ブログ

階層化された認可による Amazon Bedrock エージェントのデータプライバシー強化

定義

チャレンジ

解決策

ディープダイブ

結論

お役立ちリンク

フォローお願いいたします