Bedrockを利用するアプリのセキュリティ周りについて調べる
bun913気になっていること
- （意識せずとも備わっている）仕組み
- 入力した情報をBecrockとAWSがどのように扱うか
- 学習
- 蓄積される？されない？
- 不正検知とかの仕組みは？
- いわゆるトレーサビリティというやつは？
- 余談ですが、これを聞いて何を「トレース」したいのかわからなくなる時が多々ある
- あと本当に「ビリティ」があったとして「トレース」するのかとか
- 入力した情報をBecrockとAWSがどのように扱うか
- アプリの設定やAWSの他の仕組みでカバーできること
- 一般的に実施する方がいいだろうなぁという事項を整理
bun913意識せずとも備わっている仕組み
Bedrockの規約
これらの規約は2024年6月4日改訂バージョンを読んでいます。
入力データの利用
出力されたコンテンツの所在
「AIサービスを利用して生成されたアウトプットは貴社コンテンツ」です。と明記されている。
Claude3 とかのサードパーティー製のモデル
- 「サードパーティモデル」は「サードパーティコンテンツ」として提供されている
- Bedrockだけでなく関連文書で指定される追加のサードパーティ製のライセンスの条件の適用対象になる
有害なコンテンツ
- Bedrockは有害なコンテンツを自動検知する自動不正検知メカニズムを利用することがある
データ保護
データの利用について
一番大事なことはここ。
Amazon Bedrock doesn't store or log your prompts and completions. Amazon Bedrock doesn't use your prompts and completions to train any AWS models and doesn't distribute them to third parties.
Bedrock側でpromptに対するログをとったりしないし、学習にも利用しないしサードパーティにも提供しないことが明記されている。
アカウントで実施を推奨するデータ保護のための施策
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
- Use multi-factor authentication (MFA) with each account.
- Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
- Set up API and user activity logging with AWS CloudTrail.
- Use AWS encryption solutions, along with all default security controls within AWS services.
- Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
If you require FIPS 140-2 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see Federal Information Processing Standard (FIPS) 140-2.
bun913追跡性
Azure OpenAI Serviceの場合
デフォルトで監視のためのダッシュボードが提供されているのかな。
これは確かに便利そうだけど、私が今利用したい用途は特定の顧客向けのサービスではないのでここまでは必要ない気がしている。
Bedrock の場合
デフォルトで提供されているダッシュボードとかはなさそう。
ログの出力
あくまでトレーサビリティという意味で言うとSlackbotを呼び出したユーザーが「誰で」「何を」「いつ」訪ねたのかっていうのが追跡できれば十分いいんじゃないかな。
このログを別アカウントの CloudWatch Logs に飛ばすことも考えたけど、継続的に運用していく分には今回の用途だとただ面倒な自己満足になるだけのような気がする。
それよりも開発用アカウントをちゃんと作って、それ用にIAM Identity Center とかできっちりアクセス管理・Cloud Trail のログを収集用アカウントに集めることをした方がいいと思った。
その他Bedrockを利用するにあたって有用そうなサービス
このガードレールはどうなんだろ？
機微な情報を入れさせたくない場合はこれが使えるのかな？
日本語での入力に対する有用性がまだよくわからないのがあるな
bun913一般的なベストプラクティス
大事なことはいつも臼田さんが教えてくれる。
このあたりのベスプラをちゃんと守りつつ、トレーサビリティが取れるようにログを適切に出力して、適切に保管しよう。
- Control Tower や Organizationによるマルチアカウント統制
- CloudTrail によるログは別アカウントに飛ばして、「ちゃんと監視してるんだぜ」という状態を作ろう
- 開発用のアカウントを用意
- 当然ここには IAM Identity Center などによるアクセス管理を行う
- トレーサビリティを確保
- CloudWatch Logs に適切に「誰が」「いつ」「何を」インプットしたのかを保管しよう
- 保存日数は企業や業界ごとのルールを最低限守ろう
- ログを別アカウントに出力するのは、今回の用途だと多分やりすぎ。開発や運用が遅くなるだけ
- セキュリティ系のマネージドサービスを使おう
- Seucirity Hub によるルールチェック
- GuardDuty や Inspector も有効かを検討
- Lambda 用の GuardDuty Lambda Protectin を検討してみてもいいかもね
- ※ 個人の検証環境ではちょっときつい。あくまでちゃんとするならっていうことではあるが
bun913こんな感じのアカウント管理かなぁと想像
