Amazon Web Services ブログ

Amazon Bedrock を活用した RAG チャットボットアーキテクチャのハードニング : セキュアデザインのためのブループリントとアンチパターンへの緩和戦略

本ブログは「Hardening the RAG chatbot architecture powered by Amazon Bedrock: Blueprint for secure design and anti-pattern mitigation」を翻訳したものとなります。

本ブログでは、Amazon Bedrock を詳細なセキュリティ計画とともに使用して、安全で責任あるチャットボットアプリケーションをデプロイする方法を示しています。また、アプリケーションで大規模言語モデル (LLM) を公開する際に発生する可能性のある一般的なセキュリティリスクとアンチパターンを特定します。Amazon Bedrock には、脆弱性を軽減し、安全な設計の原則を取り入れるために使用できる機能が組み込まれています。本ブログでは、LLM ベースのアプリケーションの信頼性を高めるためのアーキテクチャ上の考慮事項とベストプラクティス戦略に焦点を当てています。

Amazon Bedrock は生成 AI (人工知能) と LLM の融合を実現し、インパクトのあるチャットボットアプリケーションを作成できるようにします。機密データや知的財産を扱うテクノロジーと同様に、セキュリティを優先し、強固なセキュリティ態勢を採用することが重要です。適切な対策を講じないと、これらのアプリケーションはプロンプトインジェクション、情報の開示、モデルの悪用、規制違反などのリスクにさらされる可能性があります。これらのセキュリティ上の考慮事項に積極的に対処することで、Amazon Bedrock 基盤モデルと生成 AI 機能を責任を持って使用できます。

チャットボットアプリケーションのユースケースは、組織が生成 AI 基盤モデル (FM) の力を利用して独自のアプリケーションを構築したいと考えているエンタープライズ環境によく見られるパターンです。これは、生成 AI セキュリティスコーピングマトリックスの事前学習済みのモデルのカテゴリに分類されます。このスコープでは、組織は Amazon Bedrock API を介して Anthropic 社の Claude などの FM と直接統合し、カスタマーサポート、検索拡張生成 (RAG) チャットボット、コンテンツ生成ツール、意思決定支援システムなどのカスタムアプリケーションを作成します。

本ブログでは、Amazon Bedrock と統合するチャットボットアプリケーションをデプロイするための包括的なセキュリティブループリントを紹介します。これにより、エンタープライズ環境で LLM と生成 AI を責任を持って運用できるようになります。LLM と生成 AI 機能を統合する際の課題に合わせた安全な設計の原則、アーキテクチャ上の考慮事項、ベストプラクティスを通じて、緩和戦略の概要を説明します。

本ブログのガイダンスに従うことで、Amazon Bedrock と統合され、生成 AI モデルを使用するチャットボットアプリケーションのデプロイと運用に関連するリスクを積極的に特定して軽減できます。このガイダンスは、セキュリティ態勢の強化、機密データや知的財産の保護、規制コンプライアンスの維持、エンタープライズ環境への生成 AI 機能を責任を持ってデプロイするのに役立ちます。

本ブログには、次の大まかなセクションが含まれています。

  • チャットボットアプリケーションアーキテクチャの概要
  • 包括的なロギングおよびモニタリング戦略
  • セキュリティアンチパターンと緩和戦略
    • アンチパターン 1: 安全な認証とアクセス制御の欠如
    • アンチパターン 2: 不十分な入力のサニタイズとバリデーション
    • アンチパターン 3: 安全でない通信チャネル
    • アンチパターン 4: 不適切なロギング、監査、否認防止
    • アンチパターン 5: 安全でないデータストレージとアクセス制御
    • アンチパターン 6: FM と生成 AIコンポーネントの安全性の欠如
    • アンチパターン 7: 責任ある AI ガバナンスと倫理の欠如
    • アンチパターン 8: 包括的なテストと検証の欠如
    • アンチパターンの一般的な緩和戦略
  • 安全で責任あるアーキテクチャブループリント

チャットボットアプリケーションアーキテクチャの概要

本ブログで説明するチャットボットのアプリケーションアーキテクチャは、さまざまな AWS サービスを使用し、Amazon Bedrock および Anthropic 社の Claude 3 Sonnet LLM と統合する実装例を示しています。このベースラインアーキテクチャは、コアコンポーネントとその相互作用を理解するための基礎となります。ただし、お客様が Amazon Bedrock と統合するチャットボットアーキテクチャを設計および実装するには、お客様固有の要件や制約に応じて複数の方法があることに注意してください。実装のアプローチにかかわらず、生成 AI アプリケーションの安全な設計とデプロイには、適切なセキュリティコントロールを組み込み、ベストプラクティスに従うことが重要です。

チャットボットアプリケーションを使用すると、ユーザーはフロントエンドインターフェースを介して対話し、プロンプトやクエリを送信できます。これらのプロンプトは、Amazon Bedrock と統合することで処理され、Anthropic 社の Claude 3 Sonnet LLM と取り込まれたデータから構築されたナレッジベースを使用します。LLM は、プロンプトとナレッジベースから取得したコンテキストに基づいて、関連する応答を生成します。このベースライン実装では中核となる機能を概説していますが、生成 AI アプリケーションの導入に関連する潜在的なリスクを軽減するには、セキュリティコントロールを組み込み、ベストプラクティスに従う必要があります。以降のセクションでは、このようなアプリケーションで発生する可能性のあるセキュリティアンチパターンと、それに対応する緩和戦略について説明します。さらに、Amazon Bedrock を搭載したチャットボットアプリケーションの安全で責任あるアーキテクチャブループリントも提示します。

図 1: AWS サービスと Amazon Bedrock を使用したベースラインチャットボットアプリケーションアーキテクチャ

チャットボットアプリケーションベースラインアーキテクチャのコンポーネント

チャットボットアプリケーションアーキテクチャは、さまざまな AWS サービスを使用し、Amazon Bedrock サービスおよび Anthropic 社の Claude 3 Sonnet LLM と統合して、インタラクティブでインテリジェントなチャットボット体験を提供します。このアーキテクチャの主なコンポーネント (図 1 参照) は次のとおりです。

  1. ユーザーインタラクションレイヤー:
    ユーザーは、Streamlit フロントエンド(3)を通してチャットボットアプリケーションとやり取りします。Streamlitは、Python ベースのオープンソースライブラリで、ユーザーフレンドリーでインタラクティブなインターフェースを構築するために使用されています
  2. Amazon Elastic Container Service (Amazon ECS) on AWS Fargate:
    フルマネージドでスケーラブルなコンテナオーケストレーションサービスで、サーバーのプロビジョニングと管理が不要になり、基盤となるコンピューティングインフラストラクチャを管理しなくてもコンテナ化されたアプリケーションを実行できます
  3. アプリケーションのホスティングとデプロイ:
    Streamlit アプリケーション (3) のコンポーネントは AWS Fargate (2) 上の Amazon ECS にホストおよびデプロイされ、スケーラビリティと高可用性を維持しています。このアーキテクチャは、独立した仮想プライベートクラウド (VPC) 内のアプリケーションとホスティング環境を表し、疎結合アーキテクチャを促進します。Streamlit フロントエンドは組織固有のフロントエンドに置き換えることができ、VPC のバックエンド Amazon API Gateway とすばやく統合できます。アプリケーションロードバランサーは、Streamlit アプリケーションインスタンスにトラフィックを分散するために使用されます
  4. API Gateway 駆動での Lambda との統合:
    このサンプルアーキテクチャでは、フロントエンドから Amazon Bedrock サービスを直接呼び出す代わりに、AWS Lambda 関数 (5) をバックエンドとした API Gateway が中間レイヤーとして使用されます。このアプローチは、フロントエンドからの直接的な露出を制限することで、懸念事項を分離し、スケーラビリティ、Amazon Bedrock への安全なアクセスを促進します
  5. Lambda:
    Lambda は、拡張性の高い短期的なサーバーレスコンピューティングを提供します。ここで、Streamlit からのリクエストが処理されます。まず、ユーザーのセッションの履歴が Amazon DynamoDB (6) から取得されます。次に、ユーザーの質問、履歴、コンテキストがプロンプトテンプレートにフォーマットされ、検索拡張生成 (RAG) を使用してナレッジベースで Amazon Bedrock に対してクエリされます
  6. DynamoDB:
    DynamoDB は、Lambda 関数を使用してチャット履歴、会話履歴、推奨事項、およびその他の関連データを保存および取得します
  7. Amazon S3:
    Amazon Simple Storage Services (Amazon S3) はデータストレージサービスで、ここではナレッジベースに取り込まれたデータアーティファクトを保存するために使用されます
  8. Amazon Bedrock:
    Amazon Bedrock はアーキテクチャにおいて中心的な役割を果たしています。Anthropic 社の Claude 3 Sonnet LLM (9) と、顧客の組織固有のデータから事前に生成されたナレッジベース (10) を組み合わせてユーザーから寄せられた質問を処理します
  9. Anthropic 社の Claude 3 Sonnet:
    Anthropic 社の Claude 3 Sonnet は、ユーザーの入力とナレッジベースから取得したコンテキストに基づいて、カスタマイズされた推奨事項と回答を生成するために使用される LLM です。これは Amazon Bedrock のテキスト分析および生成モジュールの一部です
  10. ナレッジベースとデータの取り込み:
    パブリックとして分類された関連ドキュメントは、Amazon S3 (9) から Amazon Bedrock ナレッジベースに取り込まれます。ナレッジベースは Amazon OpenSearch Service がバックエンドになっています。Amazon Titan Embeddings (10) を使用して、ドキュメントのベクトルエンベディングデータベースが生成されます。データをベクトルエンベディングとして保存すると、ドキュメントのセマンティック検索や類似検索が可能になり、ユーザーが提起した質問のコンテキストを取得できます (RAG)。質問に加えてコンテキストを LLM に提供することで、LLM から有用な回答を得る可能性がはるかに高くなります。

包括的なロギングおよびモニタリング戦略

このセクションでは、Amazon Bedrock を搭載したチャットボットアプリケーションの包括的なロギングおよびモニタリング戦略の概要を説明します。さまざまな AWS サービスを使用して、セキュリティイベント、パフォーマンスメトリックス、および潜在的な脅威の一元的なロギング、監査、およびプロアクティブなモニタリングを可能にします。

  1. ロギングと監査:
    • AWS CloudTrail: InvokeModel リクエストを含む Amazon Bedrock に対して行われた API 呼び出しと、リクエストを行ったユーザーまたはサービスに関する情報を記録します
    • AWS CloudWatch Logs: Amazon Bedrock の呼び出しログ、ユーザープロンプト、生成されたレスポンス、呼び出しプロセス中に発生したエラーまたは警告をキャプチャして分析します
    • Amazon OpenSearch Service: OpenSearch の統合、コンテキストデータの取得、ナレッジベースのオペレーションに関連するデータをログ記録し、またインデックス化します
    • AWS Config: IAM ポリシー、VPC 設定、暗号化キー管理、その他のリソース設定を含む、チャットボットアプリケーションと Amazon Bedrock サービスに関連するリソースの設定をモニタリングおよび監査します
  2. モニタリングとアラート:
    • AWS CloudWatch: モデル呼び出しの数、呼び出しのレイテンシー、エラーメトリクス (クライアント側のエラー、サーバー側のエラー、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングします。Bedrock の呼び出しとパフォーマンスに関連する異常や問題を事前に検出して対応できるように、対象を絞った CloudWatch アラームを設定します
    • AWS GuardDuty: CloudTrail のログを継続的にモニタリングして、AWS 環境内の潜在的な脅威や不正なアクティビティがないかどうかを確認します
    • AWS Security Hub: セキュリティポスチャ管理とコンプライアンスチェックを一元化します
    • Amazon Security Lake: ログ分析のための一元化されたデータレイクを提供します。CloudTrail およびSecurity Hub と統合されています
  3. セキュリティ情報とイベント管理の統合:
    • セキュリティ情報およびイベント管理 (SIEM) ソリューションと統合することで、ログの一元管理、セキュリティイベントのリアルタイムモニタリング、複数のソース (CloudTrail、CloudWatch Logs、OpenSearch Service など) からのロギングデータの関連付けを行うことができます
  4. 継続的な改善:
    • 新たな脅威、アプリケーション要件の変化、または進化するベストプラクティスに対処するために、ロギングとモニタリングの設定、アラートの閾値、セキュリティソリューションとの統合を定期的に見直して更新します

セキュリティアンチパターンと緩和戦略

このセクションでは、Amazon Bedrock チャットボットアプリケーションアーキテクチャに関連する一般的なセキュリティ上のアンチパターンを特定して説明します。開発段階とデプロイ段階の早い段階でこれらのアンチパターンを認識することで、効果的な緩和戦略を実施し、セキュリティ態勢を強化することができます。

Amazon Bedrock チャットボットアプリケーションアーキテクチャのセキュリティアンチパターンに対処することが重要である理由はいくつかあります。

  1. データ保護とプライバシー: チャットボットアプリケーションは、個人情報、知的財産、ビジネス上の機密データなどのセンシティブなデータを処理して生成します。セキュリティアンチパターンに対処しないと、データ侵害、不正アクセス、および潜在的な規制違反につながる可能性があります
  2. モデルの完全性と信頼性: チャットボットアプリケーションの脆弱性により、不正なアクターが基盤となる生成 AI モデルを操作または悪用できるようになり、生成された出力の完全性と信頼性が損なわれる可能性があります。これは、特に意思決定の支援や重要なアプリケーションにおいて、深刻な結果をもたらす可能性があります
  3. 責任ある AI の導入: 生成 AI モデルの運用が増え続ける中、責任ある倫理的な導入のプラクティスを維持することが不可欠です。AI モデルを利用したチャットボットアプリケーションの信頼性、透明性、説明責任を維持するには、セキュリティアンチパターンに対処することが不可欠です
  4. コンプライアンスおよび規制要件: 多くの業界や地域には、AI 技術の使用、データプライバシー、情報セキュリティに関する特定の規制やガイドラインがあります。セキュリティアンチパターンに対処することは、チャットボットアプリケーションのコンプライアンスを順守し維持するための重要なステップです

本ブログで取り上げるセキュリティアンチパターンには次のものがあります。

  1. 安全な認証とアクセス制御の欠如
  2. 不十分な入力のサニタイズとバリデーション
  3. 安全でない通信チャネル
  4. 不適切なロギング、監査、否認防止
  5. 安全でないデータストレージとアクセス制御
  6. FM と生成 AIコンポーネントの安全性の欠如
  7. 責任ある AI ガバナンスと倫理の欠如
  8. 包括的なテストと検証の欠如

アンチパターン 1: 安全な認証とアクセス制御の欠如

Amazon Bedrock を使用する生成 AI チャットボットアプリケーションでは、安全な認証とアクセス制御がないと、システムの機密性、完全性、可用性に重大なリスクが生じます。ID スプーフィングや不正アクセスにより、脅威アクターが正当なユーザーやシステムになりすましたり、チャットボットアプリケーションで処理された機密データに不正にアクセスしたり、アプリケーションで使用される顧客のデータや知的財産の完全性と機密性を侵害したりする可能性があります。

チャットボットアプリケーションは、機密情報や知的財産を含む可能性のあるユーザーのプロンプトや応答を処理するため、ID スプーフィングと不正アクセスはこのアーキテクチャで対処すべき重要な領域です。脅威アクターが正当なユーザーまたはシステムになりすますことができれば、悪意のあるプロンプトを挿入したり、ナレッジベースから機密データを取得したり、Amazon Bedrock と統合された Anthropic Claude 3 LLM によって生成された応答を操作したりする可能性があります。

アンチパターンの例

  • Streamlit のフロントエンドインターフェースまたは API Gateway エンドポイントを適切な認証メカニズムなしで公開すると、認証されていないユーザーがチャットボットアプリケーションと対話し、悪意のあるプロンプトを挿入できる可能性があります
  • AWS アクセスキーまたは API 認証情報をアプリケーションコードまたは設定ファイルに保存またはハードコーディングすると、認証情報が公開されたり、Amazon Bedrock や DynamoDB などの AWS サービスへの不正アクセスのリスクが高まります
  • Amazon Bedrock サービスやその他の重要なコンポーネントにアクセスするための上位権限を持つ管理者アカウントまたはサービスアカウントに、弱い、または推測しやすいパスワードを実装します
  • AWS Identity and Access Management (IAM) ユーザーまたは権限のあるロールには多要素認証 (MFA) がないため、認証情報が漏洩した場合に Amazon Bedrock サービスを含む AWS リソースへの不正アクセスのリスクが高まります

緩和戦略

安全な認証とアクセス制御の欠如に関連するリスクを軽減するには、堅牢な IAM コントロールのほか、継続的なロギング、モニタリング、脅威検出メカニズムを実装してください。

IAM コントロール:

  • OAuth 2.0 や OpenID Connect などの業界標準のプロトコルを使用し、AWS IAM Identity Center やその他のアイデンティティプロバイダーと統合することで、Streamlit フロントエンドインターフェースと AWS API Gateway エンドポイントの認証と認可を一元的に行うことができます
  • AWS IAM ポリシーとリソースベースのポリシーを使用してきめ細かなアクセス制御を実装し、必要な Amazon Bedrock リソース、Lambda 関数、およびチャットボットアプリケーションに必要なその他のコンポーネントのみへのアクセスを制限します
  • Amazon Bedrock、DynamoDB、Streamlit アプリケーションなどの重要なコンポーネントにアクセスできるすべての IAM ユーザー、ロール、およびサービスアカウントに MFA の使用を強制します

継続的なロギングとモニタリング、脅威の検出:

  • 一元的なロギングおよびモニタリングソリューションの実装に関するガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。またチャットボットアプリケーションコンポーネントと Amazon Bedrock サービス全体にわたる認証イベント、アクセス試行、潜在的な不正アクセスまたは認証情報の不正使用を追跡および監査するとともに、CloudWatch、Lambda、GuardDuty を使用して異常な動作や潜在的な脅威を検出して対応します

アンチパターン 2: 不十分な入力のサニタイズとバリデーション

生成 AI チャットボットアプリケーションの入力バリデーションとサニタイズが不十分だと、インジェクションイベント、データ改ざん、敵対的イベント、データ汚染イベントなど、さまざまな脅威にシステムがさらされる可能性があります。これらの脆弱性は、不正アクセス、データ改ざん、モデル出力の侵害につながる可能性があります。

インジェクションイベント: ユーザーのプロンプトや入力が適切にサニタイズおよびバリデーションされていない場合、脅威アクターは SQL コードなどの悪意のあるコードを注入して、DynamoDB チャット履歴データへの不正アクセスや操作を引き起こす可能性があります。さらに、チャットボットアプリケーションまたはコンポーネントが適切なバリデーションなしにユーザー入力を処理すると、脅威アクターがバックエンドシステムに任意のコードを注入して実行し、アプリケーション全体を危険にさらす可能性があります

データ改ざん: 脅威アクターは、チャットボットインターフェースと Amazon Bedrock サービスの間で送信されるユーザープロンプトやペイロードを変更し、意図しないモデル応答やアクションを引き起こす可能性があります。データの完全性チェックを行わないと、脅威アクターが Amazon Bedrock と OpenSearch の間で交換されるコンテキストデータを改ざんし、LLM の応答に影響する誤った検索結果や悪意のある検索結果につながる可能性があります

データ汚染イベント: LLM またはチャットボットアプリケーションで使用されるトレーニングデータまたはコンテキストデータが適切にバリデーションおよびサニタイズされていない場合、不正なアクターが悪意のあるデータや誤解を招くデータを導入し、偏ったモデル出力や侵害されたモデル出力につながる可能性があります

アンチパターンの例

  • Amazon Bedrock に送信する前にユーザープロンプトのバリデーションとサニタイズに失敗すると、インジェクションイベントが発生したり、意図しないデータ漏洩が発生したりする可能性があります
  • OpenSearch から取得したコンテキストデータの入力バリデーションとサニタイズが行われていないため、不正なデータや悪意のあるデータが LLM の応答に影響を与える可能性があります
  • LLM が生成した応答をユーザーに表示する前にサニタイズが不十分なため、コードインジェクションや有害なコンテンツのレンダリングが発生する可能性があります
  • Streamlit アプリケーションまたは Lambda 関数でのユーザー入力の不適切なサニタイズにより、特殊文字、コードスニペット、または潜在的に悪意のあるパターンを削除またはエスケープできず、コードインジェクションイベントが発生する可能性があります
  • LLM またはチャットボットアプリケーションで使用されるトレーニングデータやその他のデータソースの検証とサニタイズが不十分なため、データ汚染イベントが発生し、悪意のあるデータや誤解を招くデータが取り込まれ、偏ったモデル出力や侵害されたモデル出力につながる可能性があります
  • ユーザープロンプトやデータ入力に無制限の文字セット、入力長、特殊文字を使用できるようにすることで、攻撃者が入力バリデーションやサニタイズのメカニズムを迂回する入力を作成できるようになり、望ましくない出力や悪意のある出力が発生する可能性があります
  • 入力のバリデーションは拒否リストのみに頼っているため、攻撃者はこれをすばやく回避できるため、インジェクションイベント、データ改ざん、その他の悪用シナリオにつながる可能性があります

緩和戦略

不十分な入力のサニタイズとバリデーションに関連するリスクを軽減するには、チャットボットアプリケーションとそのコンポーネント全体に堅牢な入力バリデーションとサニタイズのメカニズムを実装してください。

入力のバリデーションとサニタイズ:

  • チャットボットインターフェースと Amazon Bedrock サービスの境界でユーザープロンプトの厳格な入力バリデーションルールを実装し、許可される文字セットと最大入力長を定義し、特殊文字やコードスニペットを禁止します。Amazon Bedrock のガードレール機能を使用すると、拒否トピックとコンテンツフィルタを定義して、アプリケーションとのユーザー操作から望ましくない有害なコンテンツを削除できます
  • より堅牢で包括的なアプローチを維持するには、入力バリデーションに拒否リストの代わりに許可リストを使用してください
  • 特殊文字、コードスニペット、または潜在的に悪質なパターンを削除またはエスケープすることで、ユーザー入力をサニタイズします

データフロー検証:

  • 以下を含むコンポーネント間のデータフローの検証とサニタイズを行います
    • FM に送信されたユーザープロンプトと、FM によって生成されてチャットボットインターフェースに返された応答
    • FM またはチャットボットアプリケーションで使用されるトレーニングデータ、コンテキストデータ、およびその他のデータソース

保護コントロール:

  • AWS WAF を使用して、入力のバリデーションと一般的なウェブエクスプロイトから保護します
  • AWS Shield を使用して、分散型サービス拒否 (DDoS) イベントから保護します
  • CloudTrail を使用して、InvokeModel リクエストを含む Amazon Bedrock への API 呼び出しをモニタリングできます
  • CloudTrail ログを分析し、アプリケーションログ、ユーザープロンプト、応答を取り込み、インシデントレスポンスや SIEM ソリューションとの統合を行うための Lambda 関数、Amazon EventBridge ルール、CloudWatch Logs の実装に関するガイダンスについては、包括的なロギングおよびモニタリング戦略のセクションをご覧ください。入力のバリデーションとサニタイズ、ジェイルブレイクの試行や異常な動作に関連するセキュリティインシデントの検出、調査、緩和に役立ちます

アンチパターン 3: 安全でない通信チャネル

チャットボットアプリケーションコンポーネント間の安全でない通信チャネルは、機密データを傍受、改ざん、不正アクセスのリスクにさらす可能性があります。セキュリティで保護されていないチャネルでは、攻撃者が送信中のデータ (ユーザープロンプト、応答、コンテキストデータなど) を傍受して変更する中間者イベントが発生し、データの改ざん、悪意のあるペイロードの注入、不正な情報アクセスにつながります。

アンチパターンの例

  • VPC 内の安全なサービス間通信のために AWS PrivateLink を使用しないと、HTTPS を使用している場合でも、Amazon Bedrock と他の AWS サービスとの間の通信がパブリックインターネットを介した潜在的なリスクにさらされます
  • コンポーネント間の転送中のデータ改ざんを検出および防止するためのデータ完全性チェックまたはメカニズムがない
  • 新たな脅威に対処し、セキュリティのベストプラクティスに準拠していることを確認するために、通信チャネルの構成、プロトコル、および暗号化メカニズムを定期的に見直して更新していない

緩和戦略

安全でない通信チャネルに関連するリスクを軽減するには、安全な通信メカニズムを実装し、チャットボットアプリケーションのコンポーネントとその相互作用全体でデータの完全性を強化する必要があります。転送中の機密データを保護し、不正アクセス、データ改ざん、中間者攻撃を防ぐために、適切な暗号化、認証、および完全性チェックを実施する必要があります。

安全な通信チャネル:

  • PrivateLink を使用すると、Amazon Bedrock とチャットボットアプリケーションアーキテクチャで使用される他の AWS サービスとの間の安全なサービス間通信が可能になります。PrivateLink は、Amazon VPC 内にプライベートで分離された通信チャネルを提供するため、パブリックインターネットを経由する必要がありません。これにより、HTTPS を使用している場合でも、サービス間で送信される機密データへの傍受、改ざん、または不正アクセスの可能性が軽減されます
  • AWS Certificate Manager (ACM) を使用して、チャットボットのフロントエンドインターフェース (Streamlit アプリケーション) と API Gateway エンドポイント間の安全な通信に使用される SSL/TLS 証明書のデプロイを管理および自動化します。ACM は SSL/TLS 証明書のプロビジョニング、更新、デプロイを簡素化し、ユーザー向けコンポーネントとバックエンド API 間の通信チャネルが、業界標準のプロトコルと最新の証明書を使用して安全に暗号化されるようにします

継続的なロギングとモニタリング:

  • 潜在的な通信チャネルの異常やセキュリティインシデントを検出して対応するための一元的なロギングおよびモニタリングメカニズムの実装に関するガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。これには CloudWatch、CloudTrail、AWS WAF などの AWS サービスを使用して、通信チャネルメトリクス、API 呼び出しパターン、リクエストペイロード、およびレスポンスデータをモニタリングすることも含まれます

ネットワークのセグメンテーションと分離のコントロール:

  • 専用の VPC とサブネット内に Amazon ECS クラスターをデプロイし、他のコンポーネントから分離し、最小権限の原則に基づいて通信を制限することにより、ネットワークセグメンテーションを実装します
    パブリック向けのフロントエンド層とバックエンドアプリケーション層用に VPC 内に個別のサブネットを作成し、コンポーネントをさらに分離します
  • AWS セキュリティグループとネットワークアクセスコントロールリスト (NACL) を使用して、ECS クラスターとフロントエンドインスタンスのインバウンドトラフィックとアウトバウンドトラフィックをそれぞれインスタンスレベルとサブネットレベルで制御します

アンチパターン 4: 不適切なロギング、監査、否認防止

生成 AI チャットボットアプリケーションのロギング、監査、否認防止のメカニズムが不十分だと、説明責任の欠如、フォレンジック分析の課題、コンプライアンス上の懸念など、さまざまなリスクにつながる可能性があります。適切なロギングと監査がなければ、ユーザーアクティビティの追跡、問題の診断、セキュリティインシデントの際のフォレンジック分析の実施、規制や内部ポリシーの遵守の証明が困難になります。

アンチパターンの例

  • Amazon Bedrock に送信されたユーザープロンプト、OpenSearch と交換されるコンテキストデータ、LLM からの応答など、コンポーネント間のデータフローのログ記録が不足しているため、セキュリティインシデントやデータ侵害が発生した場合の調査が妨げられます
  • チャットボットアプリケーション内のユーザーアクティビティ(ログイン試行、セッション時間、実行されたアクションなど) のロギングが不十分なため、特定のユーザーを追跡してアクションを関連付ける機能が制限されます
  • ログに記録されたデータの完全性と信頼性を保証するメカニズムがないため、記録されたイベントが改ざんされたり否認されたりする可能性があります
  • ログデータを安全に保管し、不正アクセスや改ざんから保護できないため、ログ情報の信頼性と機密性が損なわれます

緩和戦略

不適切なロギング、監査、否認防止に関連するリスクを軽減するには、包括的なロギングおよび監査メカニズムを実装して、チャットボットアプリケーションコンポーネント全体の重大なイベント、ユーザーアクティビティ、およびデータフローをキャプチャします。さらに、ログデータの完全性と信頼性を維持し、改ざんや否認を防止し、ログ情報を安全に保管して不正アクセスから保護するための対策を講じる必要があります。

包括的なロギングと監査:

  • CloudTrail、CloudWatch Logs、OpenSearch Service を使用してロギングメカニズムを実装するための詳細なガイダンスについては、「包括的なロギングとモニタリングの戦略」セクションを参照してください。また、CloudTrail を使用して API 呼び出し、特に Amazon Bedrock API の呼び出しや AWS 環境内のその他の API アクティビティのロギングとモニタリングを行います。CloudWatch を使用して Amazon Bedrock 固有のメトリックスをモニタリングします。また、CloudTrail ログファイルの整合性検証機能と Amazon S3 に保存されているログデータの S3 オブジェクトロックと S3 バージョニングの実装により、ログデータの完全性と否認防止を確保します
  • 保存中の暗号化には AWS Key Management Service (AWS KMS) を使用し、ログデータへのアクセスを制御するための制限的な IAM ポリシーとリソースベースのポリシーを実装することで、ログデータが安全に保存され、不正アクセスから保護されていることを確認してください
  • CloudTrail ログファイルの整合性検証と CloudWatch Logs の保持期間とデータアーカイブ機能を使用して、コンプライアンス要件に基づいて適切な期間ログデータを保持します

ユーザーアクティビティのモニタリングと追跡:

  • CloudTrail を使用して API 呼び出し、特に Amazon Bedrock API 呼び出しや AWS 環境内のその他の API アクティビティ (API Gateway、Lambda、DynamoDB など) のロギングとモニタリングを行います。さらに、CloudWatch を使用して、モデル呼び出しの数、レイテンシー、エラーメトリックス (クライアント側のエラー、サーバー側のエラー、スロットリング) など、Amazon Bedrock 固有のメトリクスをモニタリングできます
  • セキュリティ情報およびイベント管理 (SIEM) ソリューションと統合して、一元的なログ管理とセキュリティイベントのリアルタイムモニタリングを行います

データの完全性と否認防止:

  • デジタル署名または否認防止メカニズムを実装して、記録されたデータの完全性と信頼性を検証し、記録されたイベントの改ざんや否認を最小限に抑えます。CloudTrail ログファイルの整合性検証機能を使用すると、業界標準のアルゴリズム (ハッシュには SHA-256、デジタル署名には SHA-256、デジタル署名には SHA-256 と RSA) を使用して否認防止を行い、ログデータの整合性を検証できます。Amazon S3 に保存されているログデータについては、S3 オブジェクトロックと S3 バージョニングを有効にし、変更不可能な Write Once Read Many (WORM) データストレージモデルを実現することで、オブジェクトの削除や変更を防ぎ、データの完全性と否認防止を維持できます。さらに、S3 バケットポリシーと IAM ポリシーを実装して、S3 に保存されているログデータへのアクセスを制限することで、ログに記録されたイベントのセキュリティと否認防止をさらに強化します

アンチパターン 5: 安全でないデータストレージとアクセス制御

生成 AI チャットボットアプリケーションにおける安全でないデータストレージとアクセス制御は、情報開示、データ改ざん、不正アクセスなどの重大なリスクにつながる可能性があります。チャット履歴などの機密データを暗号化されていない、または安全でない方法で保存すると、データストアが侵害されたり、権限のないエンティティによってアクセスされた場合に情報漏えいが発生する可能性があります。さらに、適切なアクセス制御が行われていないと、権限のない第三者がデータにアクセス、変更、または削除できるようになり、データが改ざんされたり、不正アクセスされたりする可能性があります。

アンチパターンの例

  • AWS KMS カスタマー管理キー (CMK) を使用してチャット履歴データを暗号化せずに DynamoDB に保存します
  • OpenSearch、Amazon S3、または機密データを処理するその他のコンポーネントのデータに対する、AWS KMS の CMK を使用した保存時の暗号化の不足
  • DynamoDB のチャット履歴、OpenSearch、Amazon S3、またはその他のデータストアに対する過度に寛容なアクセス制御や、きめ細かなアクセス制御メカニズムの欠如により、不正アクセスやデータ侵害のリスクが高まります
  • 機密データをクリアテキストで保存するか、安全でない暗号化アルゴリズムや鍵管理手法を使用する
  • 潜在的なセキュリティの脆弱性やアクセス要件の変更に対処するために、暗号化キーを定期的に確認してローテーションしたり、アクセス制御ポリシーを更新したりしていない

緩和戦略

安全でないデータストレージとアクセス制御に関連するリスクを軽減するには、強固な暗号化メカニズム、安全な鍵管理手法、きめ細かなアクセス制御ポリシーを実装してください。保存中および転送中の機密データを暗号化し、AWS KMS のお客様が管理する暗号化キーを使用し、IAM ポリシーとリソースベースのポリシーに基づいて最小権限のアクセス制御を実装することで、チャットボットアプリケーションアーキテクチャ内のデータのセキュリティと保護を大幅に強化できます。

保存時の鍵管理と暗号化:

  • AWS KMS を実装して、DynamoDB、OpenSearch、Amazon S3 などのコンポーネント間のデータ暗号化のための CMK へのアクセスを管理および制御します
    • CMK を使用して、保存中のチャット履歴データを自動的に暗号化するように DynamoDB を設定します
    • OpenSearch と Amazon S3 が、これらのサービスに保存されているデータについて AWS KMS CMK で保存時に暗号化を使用するように設定します
    • CMK ではセキュリティと制御が強化され、暗号化キーの作成、ローテーション、無効化、取り消しが可能になり、キーの分離と職務の分離が容易になります
    • CMK を使用すると、キーポリシーを適用したり、キーの使用状況を監査したり、顧客による暗号化キーの管理を義務付ける規制要件や組織のポリシーを順守したりできます
    • CMK は移植性が高く、特定のサービスから独立しているため、暗号化キーの管理を維持しながら、複数のサービス間でデータを移行または統合できます
    • AWS KMS は、一元化された安全なキー管理ソリューションを提供し、さまざまなコンポーネントやサービスにわたる暗号化キーの管理と監査を簡素化します
  • 以下を含む安全な鍵管理手法を実装します
    • 暗号化されたデータのセキュリティを維持するための定期的なキーローテーション
    • 特定の個人が主要な管理業務を完全に制御できないようにするための職務分離
    • キー管理操作の厳格なアクセス制御。IAM ポリシーとロールを使用して最小権限の原則を適用します

きめ細かなアクセス制御:

  • IAM ポリシーとロールを使用して、DynamoDB チャット履歴データストア、OpenSearch、Amazon S3、およびその他のデータストアへのきめ細かなアクセス制御を実装します
  • DynamoDB チャット履歴データストア、OpenSearch、Amazon S3、その他のデータストアやサービスなど、機密データを処理するすべてのリソースに対して、きめ細かなアクセス制御を実装し、最小権限のアクセスポリシーを定義します。たとえば、IAM ポリシーとリソースベースのポリシーを使用して、特定の DynamoDB テーブル、OpenSearch ドメイン、S3 バケットへのアクセスを制限し、最小権限の原則に基づいて必要なアクション (読み取り、書き込み、一覧表示など) のみへのアクセスを制限します。このアプローチをチャットボットアプリケーションアーキテクチャ内の機密データを処理するすべてのリソースに拡張し、各コンポーネントまたはユーザーロールに最低限必要なリソースとアクションにのみアクセスが付与されるようにします

継続的な改善:

  • 潜在的なセキュリティの脆弱性やアクセス要件の変更に対処するために、暗号化構成、アクセス制御ポリシー、およびキー管理方法を定期的に見直して更新してください

アンチパターン 6: FM と生成 AI コンポーネントの安全性の欠如

チャットボットアプリケーションの FM や生成 AI コンポーネントに対するセキュリティ対策が不十分だと、モデルの改ざん、意図しない情報開示、サービス拒否などの深刻なリスクにつながる可能性があります。脅威アクターは、セキュリティで保護されていない FM や生成 AI モデルを操作して、偏った、有害な、または悪意のある応答を生成し、重大な損害や評判の低下を引き起こす可能性があります。

適切なアクセス制御や入力バリデーションを行わないと、意図しない情報漏えいが発生し、機密データが誤ってモデル応答に含まれてしまう可能性があります。さらに、安全でない FM または生成 AI コンポーネントは、サービス拒否イベントに対して脆弱であり、チャットボットアプリケーションの可用性を妨げ、その機能に影響を与える可能性があります。

アンチパターンの例

  • 信頼できないデータソースや侵害されたデータソースを使用するなど、安全でないモデルのファインチューニング手法は、偏ったモデルや悪意のあるモデルにつながる可能性があります
  • FM および生成 AI コンポーネントを継続的にモニタリングできないため、新たな脅威や既知の脆弱性に対して脆弱なままになっています
  • FM や生成 AI コンポーネントの出力を制御およびフィルタリングするためのガードレールや安全対策がないため、有害な、偏った、または望ましくないコンテンツが生成される可能性があります
  • FM コンポーネントに送信されるプロンプトやコンテキストデータのアクセス制御や入力バリデーションが不十分なため、インジェクションイベントや意図しない情報開示のリスクが高まります
  • 安全な通信チャネル、モデルアーティファクトの暗号化、アクセス制御など、FM および生成 AI コンポーネントの安全なデプロイプラクティスの実装の欠如

緩和戦略

保護が不十分な FM と生成 AI コンポーネントに関連するリスクを軽減するには、安全な統合メカニズム、堅牢なモデルのファインチューニングとデプロイ手法、継続的なモニタリング、効果的なガードレールと安全対策を実施する必要があります。これらの緩和戦略は、チャットボットアプリケーションの生成 AI 機能のセキュリティ、信頼性、倫理的な整合性を確保しながら、モデルの改ざん、意図しない情報開示、サービス拒否イベント、有害または望ましくないコンテンツの生成を防ぐのに役立ちます。

LLM とナレッジベースとの安全な統合:

  • Amazon Bedrock、OpenSearch、および FM コンポーネント間に安全な通信チャネル (HTTPS や PrivateLink など) を実装して、不正アクセスやデータ改ざんを防止してください
  • インジェクションイベントや意図しない情報漏洩を防ぐために、FM コンポーネントに送信されるプロンプトとコンテキストデータには厳格な入力バリデーションとサニタイズを実装してください
  • OpenSearch と統合するためにアクセス制御と最小権限の原則を実装して、LLM コンポーネントがアクセスできるデータを制限します

安全なモデルのファインチューニング、デプロイ、モニタリング:

  • 信頼できる検証済みのデータソースを使用して、安全で監査可能なファインチューニングパイプラインを確立し、改ざんやバイアスの導入を防止します
  • アクセス制御、安全な通信チャネル、モデルアーティファクトの暗号化など、FM および生成 AI コンポーネントの安全なデプロイプラクティスを実装します
  • FM および生成 AI コンポーネントを継続的にモニタリングして、セキュリティの脆弱性、パフォーマンスの問題、意図しない動作がないかどうかを確認します
  • レート制限、スロットリング、および負荷分散メカニズムを実装して、FM および生成 AI コンポーネントでのサービス拒否イベントを防止します
  • セキュリティポリシー、業界のベストプラクティス、規制要件への準拠について、FM と生成 AI コンポーネントを定期的に見直し、監査します

ガードレールと安全対策

  • ガードレールを導入しましょう。ガードレールとは、有害なアウトプットを減らし、FM や生成 AI コンポーネントの動作を人間の価値と調和させることを目的とした安全対策です
  • キーワードベースのフィルタリング、メトリックベースのしきい値、人的モニタリング、各アプリケーションドメインの特定のリスクと文化的および倫理的規範に合わせたカスタマイズされたガードレールを使用してください
  • パフォーマンスベンチマークと敵対的テストを通じてガードレールの有効性をモニタリングします

ジェイルブレイクに対する堅牢性テスト

  • ジェイルブレイクに対する堅牢制テストを実施してください。様々な禁止シナリオにわたる多様なジェイルブレイクを LLM および生成 AI コンポーネントにプロンプトを与えて試行し、脆弱性を特定してモデルの堅牢性を高めます

アンチパターン 7: 責任ある AI ガバナンスと倫理の欠如

これまでのアンチパターンは技術的なセキュリティ面に焦点を当てていましたが、生成 AI システムの倫理的かつ責任あるガバナンスに取り組むことも同様に重要です。強力なガバナンスの枠組み、倫理的ガイドライン、アカウンタビリティ対策がなければ、チャットボットアプリケーションは意図しない結果や偏った結果、透明性と信頼性の欠如につながる可能性があります。

アンチパターンの例

  • 生成 AI チャットボットアプリケーションの責任ある開発とデプロイを導く原則、ポリシー、プロセスを含む、確立された倫理的なAI ガバナンスフレームワークの欠如
  • LLM と生成 AI コンポーネントの透明性、説明可能性、解釈可能性を確保するための対策が不十分なため、意思決定プロセスの理解と監査が困難になっています
  • 利害関係者の関与、公的な協議、社会的影響の考慮のためのメカニズムがないため、チャットボットアプリケーションに対する信頼が失われ受け入れられなくなる可能性があります
  • 生成 AI システムのトレーニングデータ、モデル、または出力における潜在的なバイアス、差別、または不公平に対処できない
  • チャットボットアプリケーションの倫理的行動や組織の価値観や社会規範との整合性をテスト、検証、継続的なモニタリングを行うためのプロセスが不十分

緩和戦略

責任ある AI ガバナンスと倫理の欠如を最小限に抑えるために、包括的な倫理的 AI ガバナンスの枠組みを確立し、透明性と解釈可能性を促進し、利害関係者を関与させて社会的影響を考慮し、潜在的なバイアスや公平性の問題に対処し、継続的な改善とモニタリングプロセスを実施し、ガードレールと安全対策を講じます。これらの緩和戦略は、生成 AI チャットボットアプリケーションの開発と導入における信頼、説明責任、倫理的連携を促進するのに役立ち、意図しない結果、偏った結果、透明性の欠如などのリスクを軽減します。

倫理的な AI ガバナンスの枠組み:

  • 生成 AI チャットボットアプリケーションの責任ある開発とデプロイを導くための原則、ポリシー、プロセスを含む、倫理的な AI ガバナンスの枠組みを確立します
  • 潜在的な倫理的ジレンマ、バイアス、または意図しない結果に対処するための明確な倫理ガイドラインと意思決定の枠組みを定義します
  • チャットボットアプリケーションの倫理的な開発とデプロイを監督するために、指定された倫理委員会、倫理責任者、外部諮問委員会などのアカウンタビリティ措置を実施します

透明性と解釈可能性:

  • LLM と生成 AI コンポーネントの透明性と解釈可能性を促進するための対策を実施し、意思決定プロセスの監査と理解を可能にする。
  • チャットボットアプリケーションの機能、制限、潜在的なバイアスや倫理的考慮事項について、利害関係者やユーザーに明確でアクセスしやすい情報を提供します

利害関係者の関与と社会的影響:

  • 利害関係者の関与、公的な協議、社会的影響の考慮のためのメカニズムを確立し、チャットボットアプリケーションの信頼と受け入れを促進します
  • 影響評価を実施して、個人、地域社会、または社会に対する潜在的な悪影響またはリスクを特定し、軽減する

バイアスと公平性:

  • 厳格なテスト、バイアスの軽減手法、継続的なモニタリングを通じて、生成 AIシステムのトレーニングデータ、モデル、または出力における潜在的なバイアス、差別、または不公平に対処します
  • 潜在的なバイアスや盲点を減らすために、開発、テスト、ガバナンスのプロセスにおいて多様性と包括性のある表現を促進します

継続的な改善とモニタリング:

  • チャットボットアプリケーションの動作と組織の価値観や社会規範との整合性を継続的にテスト、検証、モニタリングするためのプロセスを実装します
  • 新たな倫理的課題、社会的期待、規制の進展に対応するために、AI ガバナンスの枠組み、ポリシー、プロセスを定期的に見直し、更新します

ガードレールと安全対策: (訳者注: 日本語でアプリケーションを利用される場合、ユーザーガイドを参照の上日本語がサポートされているか事前にご確認下さい)

  • Guardrails for Amazon Bedrock などのガードレールを導入します。これは、有害なアウトプットを減らし、LLM や生成 AI コンポーネントの動作を人間の価値観や責任ある AI ポリシーと一致させることを目的とした安全対策です
  • Guardrails for Amazon Bedrock を使用して拒否トピックを定義し、コンテンツフィルターを使用してユーザーとアプリケーション間のやり取りから望ましくない有害なコンテンツを削除します
    • 自然言語による説明を使用して拒否トピックを定義し、アプリケーションのコンテキストでは望ましくないトピックや主題分野を指定します
    • コンテンツフィルターを設定して、ユースケースと責任ある AI ポリシーに基づいて、ヘイト、侮辱、セクシャリティ、暴力などのカテゴリーにわたって有害なコンテンツをフィルタリングするための閾値を設定します
    • 個人識別情報 (PII) リダクション機能を使用して、LLM が生成した応答から名前、電子メールアドレス、電話番号などの情報をリダクションしたり、PII を含むユーザー入力をブロックします
  • Guardrails for Amazon Bedrock を CloudWatch と統合して、定義されたポリシーに違反するユーザー入力と LLM レスポンスをモニタリングおよび分析することで、潜在的な問題を事前に検出して対応できるようになります
  • パフォーマンスベンチマークと敵対的テストを通じてガードレールの有効性をモニタリングし、実際の使用状況や新たな倫理的考慮事項に基づいてガードレールの改良と更新を継続的に行います

ジェイルブレイクに対する堅牢性テスト:

  • ジェイルブレイクに対する堅牢制テストを実施してください。様々な禁止シナリオにわたる多様なジェイルブレイクを LLM および生成 AI コンポーネントにプロンプトを与えて試行し、脆弱性を特定してモデルの堅牢性を高めます

アンチパターン 8: 包括的なテストと検証の欠如

LLM システムと生成 AI チャットボットアプリケーションのテストと検証プロセスが不十分だと、未確認の脆弱性、パフォーマンスのボトルネック、可用性の問題が発生する可能性があります。包括的なテストと検証を行わないと、組織はアプリケーションを本番環境にデプロイする前に、潜在的なセキュリティリスク、機能上のギャップ、スケーラビリティとパフォーマンスの制限を検出できない可能性があります。

アンチパターンの例

  • LLM の応答の正確性と完全性、およびチャットボットアプリケーションの特徴と機能を検証するための機能テストが不足しています
  • さまざまな負荷条件下でのボトルネック、リソースの制約、またはスケーラビリティの制限を特定するためのパフォーマンステストが不十分です
  • 潜在的なセキュリティの脆弱性やモデルの悪用を発見するための侵入テスト、脆弱性スキャン、敵対的テストなどのセキュリティテストが行われていません
  • 自動化されたテストと検証のプロセスを継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインに組み込めないと、手動で 1 回限りのテスト作業が行われ、重大な問題を見落とす可能性があります
  • Amazon Bedrock、OpenSearch、DynamoDB などの外部サービスやコンポーネントとのチャットボットアプリケーションの統合のテストが不十分であると、互換性の問題やデータ完全性の問題が発生する可能性があります

緩和戦略

包括的なテストと検証の欠如に対処するには、機能テスト、パフォーマンステスト、セキュリティテスト、および統合テストを含む強固なテスト戦略を実装する必要があります。自動テストを CI/CD パイプラインに統合し、脅威モデリングや侵入テストなどのセキュリティテストを実施し、敵対的検証手法を使用します。テストプロセスを継続的に改善して、生成 AI チャットボットアプリケーションの信頼性、セキュリティ、スケーラビリティを検証します。

包括的なテスト戦略:

  • LLM システムとチャットボットアプリケーション全体の機能テスト、パフォーマンステスト、負荷テスト、セキュリティテスト、統合テストを含む包括的なテスト戦略を確立します
  • アプリケーションの機能要件と非機能要件、およびセキュリティとコンプライアンス基準に基づいて、明確なテスト要件、テストケース、および承認基準を定義します

自動化されたテストと CI/CD 統合:

  • 自動化されたテストと検証プロセスを CI/CD パイプラインに組み込むことで、LLM のパフォーマンス、セキュリティ、信頼性をライフサイクル全体にわたって継続的にモニタリングおよび評価できます
  • 自動化されたテストツールとフレームワークを使用して、テストプロセスを合理化し、テストカバレッジを向上させ、回帰テストを容易にします

セキュリティテストと敵対的検証:

  • 潜在的なセキュリティリスクと脆弱性を事前に特定するために、設計プロセスの早い段階で、チャットボットアプリケーションアーキテクチャの設計が完成したらすぐに脅威モデリング演習を実施してください。その後、侵入テスト、脆弱性スキャン、敵対的テストを含む定期的なセキュリティテストを実施して、特定されたセキュリティの脆弱性やモデルエクスプロイトを発見して検証します
  • 敵対的な検証手法を実装し、モデルの堅牢制とセキュリティを向上させます。これには、LLM に対して弱点や脆弱性を明らかにするように慎重に作成された入力をプロンプトとして与えることが含まれます

パフォーマンスと負荷テスト:

  • パフォーマンスと負荷を包括的にテストして、さまざまな負荷条件下で発生する可能性のあるボトルネック、リソースの制約、またはスケーラビリティの制限を特定します
  • 負荷の生成、ストレステスト、キャパシティプランニングのためのツールとテクニックを使用して、チャットボットアプリケーションが予想されるユーザートラフィックとワークロードを処理できることを確認します

統合テスト:

  • 徹底的な統合テストを実施して、チャットボットアプリケーションと Amazon Bedrock、OpenSearch、DynamoDB などの外部サービスおよびコンポーネントとの統合を検証し、シームレスな通信とデータの完全性を維持します

継続的な改善:

  • 新たな脅威、新たな脆弱性、またはアプリケーション要件の変化に対処するために、テストと検証のプロセスを定期的に見直し、更新してください
  • テストの知見と結果を利用して、LLM システム、チャットボットアプリケーション、および全体的なセキュリティ態勢を継続的に改善してください

すべてのアンチパターンに共通の緩和戦略

  • LLM と生成 AI コンポーネントのセキュリティ対策、アクセス制御、モニタリングメカニズム、ガードレールを定期的に見直し、更新して、新たな脅威、脆弱性、進化する責任ある AI のベストプラクティスに対処します
  • 定期的なセキュリティ評価、侵入テスト、およびコードレビューを実施して、ロギング、監査、および否認防止メカニズムに関連する脆弱性または設定ミスを特定して修正します
  • 生成 AI アプリケーションのロギング、監査、否認防止に関するセキュリティのベストプラクティス、ガイダンス、および AWS や業界団体からの最新情報を常に把握してください

安全で責任あるアーキテクチャブループリント

ベースラインとなるチャットボットアプリケーションアーキテクチャについて説明し、Amazon Bedrock を使用して構築された生成 AI アプリケーションに関連する重要なセキュリティアンチパターンを特定したので、安全で責任あるアーキテクチャブループリントを紹介します。このブループリント (図 2) には、アンチパターン分析全体を通して説明した推奨される緩和戦略とセキュリティコントロールが組み込まれています。

図 2: 安全で責任ある生成 AI チャットボットのアーキテクチャブループリント

このターゲットステートアーキテクチャでは、認証されていないユーザーがフロントエンドインターフェース (1) を介してチャットボットアプリケーションと対話します。この場合、安全なコーディングプラクティスと入力バリデーションを実装することで、不十分な入力バリデーションとサニタイズというアンチパターンを軽減することが重要です。その後、ユーザー入力は、それぞれ DDoS 対策、Web アプリケーションファイアウォール機能、コンテンツ配信ネットワークを提供する AWS Shield、AWS WAF、CloudFront (2) を介して処理されます。これらのサービスは、入力バリデーションに AWS WAF を使用し、定期的なセキュリティテストを実施することで、不十分な入力バリデーション、ウェブエクスプロイト、および包括的なテストの欠如を軽減するのに役立ちます。

その後、ユーザーのリクエストは API Gateway (3) を介してルーティングされます。API Gateway (3) は、チャットボットアプリケーションのエントリポイントとして機能し、Streamlit フロントエンドへの API 接続を容易にします。認証、安全でない通信、LLM セキュリティに関連するアンチパターンに対処するには、API Gateway 内に安全な認証プロトコル、HTTPS/TLS、アクセス制御、入力バリデーションを実装することが不可欠です。VPC 内のリソースと API Gateway 間の通信は、VPC エンドポイント (4) を介して保護されます。PrivateLink を使用して安全なプライベート通信を行い、エンドポイントポリシーをアタッチしてどの AWS プリンシパルが API Gateway サービスにアクセスできるかを制御し (8)、安全でない通信チャネルのアンチパターンを軽減します。

Streamlit アプリケーション (5) は、VPC 内のプライベートサブネットにある Amazon ECS でホストされています。フロントエンドインターフェースをホストし、入力の検証とサニタイズが不十分にならないように、安全なコーディング手法と入力バリデーションを実装する必要があります。その後、ユーザー入力は VPC 内でホストされるサーバーレスコンピューティングサービスである Lambda (6) によって処理され、VPC エンドポイント (7) を介して Amazon Bedrock、OpenSearch、および DynamoDB に接続します。これらの VPC エンドポイントには、アクセスを制御するエンドポイントポリシーがアタッチされているため、Lambda 関数とサービス間の安全なプライベート通信が可能になり、安全でない通信チャネルのアンチパターンが軽減されます。Lambda では、入力バリデーションのアンチパターンに対処するために、厳格な入力バリデーションルール、許可リスト、ユーザー入力のサニタイズを実装しています。

ユーザーからのチャットボットアプリケーションのリクエストは、生成 AI ソリューションの Amazon Bedrock (12) に送信され、LLM の機能を提供します。FM と生成 AI コンポーネントの安全性を確保できないアンチパターンを緩和するために、Amazon Bedrock とのやり取りの際には、安全な通信チャンネル、入力のバリデーション、プロンプトとコンテキストデータのサニタイズを実装する必要があります。

Amazon Bedrock は、Amazon Bedrock ナレッジベースを使用して OpenSearch Service (9) とやり取りし、ユーザーの質問に関連するコンテキストデータを取得します。ナレッジベースは Amazon S3 (10) から公開ドキュメントを取り込むことによって作成されます。安全でないデータストレージとアクセス制御のアンチパターンを軽減するには、AWS KMS と OpenSearch Service 内のアクセス制御用のきめ細かい IAM ポリシーとロールを使用して保管時の暗号化を実装してください。Titan エンベディング (11) は、ベクトルエンベディング形式で Amazon S3 に保存されているドキュメントを表します。ベクトル形式により、類似度の計算と関連情報の検索が可能になります (12)。FM および生成 AI コンポーネントのセキュリティ対策が不十分なアンチパターンに対処するため、Titan エンベディングとの安全な統合と入力データのバリデーションを実装する必要があります。

ナレッジベースデータ、ユーザープロンプト、およびコンテキストデータは、Amazon Bedrock (13) と Claude 3 LLM(14) によって処理されます。生成 AI コンポーネントの安全性の欠如、責任ある AI ガバナンスと倫理の欠如といったアンチパターンに対処するため、安全な通信チャンネル、入力バリデーション、倫理的な AI ガバナンスフレームワーク、透明性と解釈可能性の対策、ステークホルダーの関与、バイアスの緩和戦略、および Guardrails for Amazon Bedrock のようなガードレールを実装する必要があります。

生成された応答と推奨事項は、Lambda 関数によって Amazon DynamoDB (15) に保存および取得されます。安全でないデータストレージとアクセスを軽減するには、保存中のデータを AWS KMS (16) で暗号化し、IAM ポリシーとロールによるきめ細かなアクセス制御を実装します。

ロギング、監査、モニタリングの包括的なメカニズムが CloudTrail (17)、CloudWatch (18)、AWS Config (19) により提供され、不適切なロギング、監査、および否認防止のアンチパターンに対処します。包括的なロギング、監査、およびモニタリングメカニズムの実装の詳細なガイダンスについては、「包括的なロギングおよびモニタリング戦略」セクションを参照してください。これには、Amazon Bedrock サービスに対して行われた API 呼び出しのロギング、Amazon Bedrock 固有のメトリクスのモニタリング、Bedrock 呼び出しログの記録と分析、およびチャットボットアプリケーションと Amazon Bedrock サービスに関連するリソースの構成のモニタリングと監査が含まれます。

IAM (20) は、アーキテクチャ全体において、また認証や安全でないデータの保存とアクセスに関連するアンチパターンの緩和において重要な役割を果たします。IAM ロールや IAM ポリシーは、チャットボットアプリケーションのさまざまなコンポーネントにわたる安全な認証メカニズム、最小権限によるアクセス、多要素認証、および堅牢な認証情報の管理を実施する上で重要です。さらに、Amazon Bedrock 内の特定のモデルやナレッジベースへのアクセスを制限するようにサービスコントロールポリシー (SCP) を設定して、機密性の高い知的財産への不正アクセスや使用を防ぐことができます。

最後に、チャットボットアプリケーションのセキュリティ態勢をさらに強化するための推奨サービスとして、GuardDuty (21)、Amazon Inspector (22)、Security Hub (23)、および Security Lake (24) が追加されています。GuardDuty (21) はコントロールプレーンとデータプレーン全体で脅威を検出し、Amazon Inspector (22) は Amazon ECS および Lambda ワークロードの脆弱性評価と継続的なモニタリングを可能にします。Security Hub (23) はセキュリティポスチャ管理とコンプライアンスチェックを一元化し、Security Lake (24) はログ分析のための一元化されたデータレイクとして機能し、CloudTrail および Security Hub と統合されています。

結論

重要なアンチパターンを特定し、包括的な緩和戦略を提供することで、企業環境に生成 AIテクノロジーを安全かつ責任を持って導入するための強固な基盤が得られます。

本ブログで紹介する安全で責任あるアーキテクチャブループリントは、強固なセキュリティ、データ保護、倫理的ガバナンスを確保しながら、生成 AI の力を活用したい組織向けの包括的なガイドとなります。このブループリントは、安全な認証メカニズム、暗号化されたデータストレージ、きめ細かなアクセス制御、安全な通信チャネル、入力のバリデーションとサニタイズ、包括的なロギングと監査、安全な FM の統合とモニタリング、責任ある AI ガードレールなど、業界をリードするセキュリティコントロールを組み込むことで、生成 AI アプリケーションに関連する固有の課題と脆弱性に対処します。

さらに、包括的なテストと検証プロセスに重点を置き、倫理的な AI ガバナンスの原則を組み込むことで、潜在的なリスクを軽減できるだけでなく、潜在的なバイアスに対処し、組織の価値観や社会規範との整合性を確保しながら、LLM コンポーネントの透明性、説明可能性、解釈可能性を高めることができます。

本ブログで概説され、アーキテクチャブループリントに示されているガイダンスに従うことで、潜在的なリスクを積極的に特定して軽減し、生成 AI ベースのチャットボットソリューションのセキュリティ態勢を強化し、機密データや知的財産を保護し、規制コンプライアンスを維持し、責任を持って企業環境に LLM と生成 AI テクノロジーを導入することができます。

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

Magesh Dhanasekaran
Magesh Dhanasekaran
Magesh は AWS のセキュリティアーキテクトです。オーストラリアと米国の金融機関や政府機関に情報セキュリティコンサルティングサービスを提供した実績があります。Magesh は、クラウドセキュリティアーキテクチャ、デジタルトランスフォーメーション、安全なアプリケーション開発の実践における経験を活かして、AWS 製品とサービスに関するセキュリティアドバイスを提供しています。彼は現在、複数の業界認定資格を取得しています。
Amy Tipple
Amy Tipple
Amy はプロフェッショナルサービスのデータ・機械学習チームのシニアデータサイエンティストで、AWS に約 4 年間在籍しています。エイミーは、生成 AI に関するいくつかの取り組みに携わっており、生成 AI 関連のセキュリティを AWS ユーザーが利用しやすく理解しやすいものにすることを推進しています。

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