はじめに
今回はBedrockのセキュリティに関するチョークトークに参加したので、内容の一部をご紹介いたします。チョークトークだったのですが、いくつかスライドが用意されていたのでそちらの内容を中心にご紹介します。
スピーカー
- Andrew Kane
- Jessie-Lee Fry
チョークトークの概要
Generative AI applications have captured widespread attention; however, they have also introduced new security challenges, especially around the handling of customer data. Organizations want to ensure that their data remains safe and secure while working with foundation models (FMs) and don’t want to worry about their data being used to train an FM. Amazon Bedrock provides comprehensive data protection and privacy. In this chalk talk, explore architectures, data flows, and security-related aspects of model fine-tuning, as well as prompting and inference, while you learn about Amazon Bedrock’s security capabilities.
翻訳
生成AIアプリケーションは広く注目を集めているが、特に顧客データの取り扱いをめぐるセキュリティ上の新たな課題も生じている。組織は、基盤モデル（FM）で作業している間、データが安全でセキュアなままであることを保証したいと考えており、データがFMのトレーニングに使用されることを心配したくはありません。 Amazon Bedrockは、包括的なデータ保護とプライバシーを提供します。このチョークトークでは、Amazon Bedrockのセキュリティ機能について学びながら、アーキテクチャ、データフロー、モデルの微調整のセキュリティ関連の側面、プロンプトと推論について探求します。
内容
アジェンダとしては以下のような内容でした。
- What is Amazon Bedrock?
- Data privacy
- AWS IAM
- Model environment
- Network Dataflow
- Model fine-tuninng
- Architectual patterns
- Responsible AI
ここからは語られた内容をサマリして記載します。自分の解釈が入る部分は分離して記載します。
What is Amazon Bedrock?
Bedrock上では顧客のデータを学習に使わず、モデルと会話するときに顧客側のデータはkmsで暗号化できます。今回はAmazon Bedrockのセキュリティについてすべての側面から議論します。議論のため、Bedrockの詳細な説明などは行いません。
私たちは、特定のユースケースを満たすことができるのは、単一の製品群だけだとは考えていません。特定のユースケースを満たすことができるのは、特定のモデル、あるいはベンダーだけだと考えています。そのため、場合によってはここに記載のあるAmazonのモデルを使うこともありました。私達は分野が成熟するほど、このモデルを増やしていくつもりです。
1つのモデルが、6ヶ月後には、実はあなたにとって適切なものでないかもしれません。AWSは特定の問題に対して正確なカスタマイズされたモデルを作成し、拡張するための基盤をホスティングする責任を持ちます。
筆者の解釈：適切なユースケースに合わせて適切なものを使うというのはAmazonのDB設定時の思想とあっていて、ここでも考えは一貫しているのかと感じました。
生成AIでは様々な質問を受けます。誰が私のデータにアクセスできるのか、そして誰が私の回答にアクセスできるのか、モデルベンダーは私たちの行動を可視化できるのか。私のデータはどれくらいの期間保存されるのか？私のデータは他のモデルのトレーニングに使われるのか？他の顧客は私のデータを見ることができるのか？他の顧客がBedrockを使用した場合、影響はあるのか？あるいは、私のアプリからの回答を修正することはできますか？これらの質問にすべてお答えしたいと思います。
Data privacy
モデルベンダーがデータを見ることはできませんし、AWSが他の目的でデータを使用することもできません。私達が見れるデータは唯一オペレーションのメトリクスだけです。例えば1200トークンを使用し、100トークンを受け取ったのような情報です。
またデータの保護について、プロンプトの回答をS3に保存する場合は、暗号化は行われますがデータをどこに置くかは顧客側の責任になります。Bedrockへの通信はすべてTLS1.2になります。S3上にファインチューニング・モデルを置き、KMSで暗号化することをおすすめします。KMSキーへのIAM上でのアクセス権を持つ人だけが、データにアクセスできるよう制限できます。
Amazon Bedrockの基盤のセキュリティとして、最近ではSOCコンプライアンスも達成しました。またいくつかのセキュリティ要件にも今後数ヶ月で対応する予定です。
筆者の記載：いくつかのセキュリティ認証制度が表示されていたのですが、出してよいのか判断に迷ったので記載は控えます。
AWS IAM
既に皆さんがご存知なようにIAMの制御によって、サービスへのアクセスを制限/許可できます。今朝の時点で65のアクションがあり、今週中にはもっと増える予定です。モデルベースのアクセス制御ができるので、特定のモデルだけ使わせないということもできます。モデルにアクセスするだけの許可などを紹介します。
またクロスアカウントのアクセス制御もできます。信頼ポリシーで承認することでロールを承認することで別のアカウントからのアクセスも可能になります。ただインラインポリシーで指定したとしても別のアカウントにアクセスすることはできません。
筆者の記載：聞き漏れたので詳細な解説はできないですが、通常のIAMのクロスアカウントアクセス制御がそのまま使えますよという話と解釈しました。
Model environment
筆者の記載：環境とあるのですが、On-demandとProvisionedのタイプ別でどうBedrockが動くのかという話でした。
どの種類のデプロイメント・モデル環境を利用するにしても、次の5つの特徴があります。1つ目は、顧客のデータはAmazon bedrockで利用可能なモデルのトレーニングには利用されないということです。他のAWS AIサービスと異なり、デフォルトがオフになっています。2つ目は、全てAWSの中にデプロイされ、オペレーションはBedrockチームで完結します。3つ目に、モデルベンダーも顧客のデータにアクセスすることはできません。
4つ目は、On-demandの場合複数の顧客のデータが共有したインスタンス上で処理されます。Provisionedの場合は、顧客専用の環境を持つことができます。On-demandの場合、スループットを変更することはできません。Provisionedの場合は、必要な容量に合わせて準備することができ、TPSの可用性を担保できます。5つ目として、Provisionedの場合は、ベースラインのモデルか、ファインチューニングされたモデルのどちらかを選択してデプロイすることができます。
Network Dataflow
On-demandの場合は以下のような構成になります。プライベートのAPI EndpointからBedrock Serviceのアカウントに接続し、その動きはCloudTrailに証跡やCloudWatchにメトリクスが記録されます。インターフェースを通じて、モデルがデプロイされたアカウントと通信し、S3バケットからベースモデルを取得して実行されます。他のモデルにアクセスする場合は、別のS3バケットにアクセスします。
Provisionedの場合は以下のような構成になります。Fine-tunedモデルを別のS3バケットから取得します。Fine-tunedモデルは、実際には顧客が所有していると思いますか？いいえ違います。実際にはBedrockのサービスチームが所有しています。S3バケットを使うことでKMSを破棄すれば、顧客側でモデルを破棄することもできます。
Model fine-tuninng
ファインチューニングは以下のような構成になります。顧客側のS3バケットはVPCとのみ通信でき、VPC経由でSagemakerと通信しトレーニングさせることができます。またVPCを破棄するだけで、モデルベンダー側からはトレーニングデータへのアクセスできなくなります。学習が終わったあとはこのような方法もとれます。
筆者の記載：以下の画像でBedrockを使う場合のセキュリテイの詳細がさらに語られていたのですが、聞き取れなかったので画像のみ記載します。ここまでで一貫して発言されていたように、トレーニングデータもAWS側のファインチューニングしたモデルもカスタマーKMSで暗号化でき、KMSを破棄することでデータを破棄できることが語られていました。
Architectual patterns
さて、アーキテクチャのパターンを見てみましょう。あなたが見ている最初のアーキテクチャー・パターンはひどく単純に見えます。これは基本的な、トピックの要約/分類や電話の記録からのアクション実行のようなものを生成するための機能を単一の基礎モデルに置き換えたためです。つまり、アプリケーションやモジュール全体をAIで構成するのではなく、必要なところにAIを組み込むというアプローチです。
まず最初に、lambdaのようなコンピュートシステム上のトランスクリプトを見つけるでしょう。次に、返答用のプロンプトを構築します。そして、レスポンスを整形し送信する。3つ目は、レスポンスを生成して返します。そして最後に、Amazon DynamoDBのようなデータストアに保存し永続化します。
Responsible AI
少し話は変わりますが、私たちがお客様から受ける重要な質問の1つは、自分のモデルがさらされないようにするにはどうすればいいかというものです。その答えのひとつが、RAGと呼ばれるものです。RAGは、国や特定のトレーニング・データの両方に対処するのに役立つ戦略です。オーケストレーション・レイヤーのコードは顧客によって書かれるため、カスタマイズされたロジックが必要な場合は、そのロジックでいっぱいになることもあります。Fine-Tunedしたモデルをソースに接続する機能だけでなく、複数のモデルやソースを連結し、オーケストレーション全体を簡素化するための幅広いライブラリや多数のライブラリを提供します。
QA + General risk
ここからは筆者の言葉で記載します。最後には、ホワイトボードでQAを実施していました。Chalk Talkに参加することでこのように相互にやりとりや質問ができます。
また最後に生成AIによるリスクについても紹介がありました。
所感
生成AIを扱う上でセキュリティは重要な要素になります。Bedrock上でモデルなどを作成する上でどのような部分に気をつける必要があるのか、大まかに把握することはできました。既存のAWSサービスの延長線上にセキュリティがあるので、AWSに慣れてる方は扱いやすいと改めて感じました。今回の内容がどなたかの役に立てば幸いです。
13
