Are You Well-Architected?
みなさん、Well-Architectedしてますか？
本記事では、Amazon Bedrockを用いたシステムに対して、どのようにAWS Well-Architected Frameworkを適用したらよいのかを解説します。
本記事は Amazon BedrockをWell-Architectedしてみたシリーズ の セキュリティ編 です。
対象読者
- AWS Well-Architected Frameworkに興味がある方
- Amazon Bedrockに興味がある方
- Amazon Bedrockを扱う際のベストプラクティスを知りたい方
なぜこの記事を書こうと思ったのか
昨今、生成AIが活況でAWS界隈でもAmazon Bedrockが注目を集めており、各種メディアや技術ブログでも様々な活用事例が紹介されています。
しかし、実際にそれらをプロダクト化しようとすると、セキュリティや信頼性、運用など様々な課題に直面します。
それらの課題を解決するには、AWS Well-Architected Frameworkが役に立ちます。
ただし、Amazon Bedrockは比較的新しいサービスであるため、それに対して、AWS Well-Architected Frameworkをどのように適用するのかについては、まだあまり語られていないと思います。
であれば、自分でやってみようじゃないか！ということで、この記事の執筆に至った次第です。
あとはまぁ、Amazon Bedrockに関する活用事例なんかはすでに山ほど出ているので、いまさら似たような話を書いても新鮮味はないので、別の切り口にしたほうがブログ的にも面白いかな、と。笑
シリーズ化
本記事を書くにあたり、以下の理由からAWS Well-Architected Frameworkの6つの柱ごとに記事を分け、シリーズ化しました。
- 1つの記事にまとめると結構なボリュームになるので読みづらくなる
- 柱ごと分かれていたほうが優先するテーマを確認しやすい
本記事は、その内の 運用上の優秀性 編に当たります。
他の柱を参照したい方は記事冒頭のリンクからどうぞ。
基礎知識
最初に本記事を読む上での基礎知識を説明します。
すでにご存じの方は読み飛ばしても構いません。
本章の内容は、他の柱の記事も同じ内容です。
すでに他の柱の記事を読んでいただいた方は読み飛ばしてください。
AWS Well-Architected Framework
AWS Well-Architected Frameworkとは、一言で表すなら AWSのベストプラクティスをまとめたフレームワーク です。
AWS Well-Architected Frameworkの6つの柱
AWS Well-Architected Frameworkは以下の 6つの柱 で構成されています。
- 運用上の優秀性 (Operational Excellence)
- セキュリティ (Security)
- 信頼性 (Reliability)
- パフォーマンス効率 (Performance Efficiency)
- コスト最適化 (Cost Optimization)
- 持続可能性 (Sustainability)
AWS Well-Architected Tool
AWS Well-Architected Frameworkには AWS Well-Architected Tool と呼ばれるツールが含まれています。
AWS Well-Architected Toolは、AWSマネジメントコンソールから利用可能です。
AWS Well-Architected Toolを利用し、ワークロードの定期的な評価やリスクを管理することができます。
AWS Well-Architected レビュー
AWS Well-Architected Frameworkに基づいて、アーキテクチャを評価するプロセスを AWS Well-Architected レビュー と呼びます。
Amazon Bedrock
Amazon Bedrockは、Amazon TitanやClaudeなど、Amazonや様々なAI企業が提供する基盤モデル (FM: Foundation Model)を統合APIを通じて利用できるようにするフルマネージドサービスです。
Amazon Kendra
Amazon Kendraは、機械学習を用いて最適されたエンタープライズ検索エンジンです。
RAG (Retrieval-Augmented Generation)
RAG (Retrieval-Augmented Generation)とは、大規模言語モデル (LLM: Large Language Models)によるテキスト生成に、外部情報の検索を組み合わせることにより回答精度を向上させる技術のことです。
日本語では「検索拡張生成」のように訳されます。
サンプルアーキテクチャ
本記事では、AWS Well-Architected Frameworkに基づいて、Amazon Bedrockを活用したシステムにおいて、考慮すべきベストプラクティスを解説していきます。
そのためにはレビュー対象となるアーキテクチャを定義する必要があります。
そこで、今回はAWS公式が提供している以下の AWS workshop studio 生成AI体験ワークショップ のアーキテクチャをサンプルとして進めていきます。
このアーキテクチャの肝は、Amazon BedrockとAmazon Kendraを用いたRAGの提供です。
Amazon BedrockやAmazon Kendraを用いたRAGに興味のある方は、ぜひこちらのワークショップもやってみてください。
Amazon BedrockやRAGを理解する上でとても良いコンテンツだと思います。
AWS Well-Architected レビューの実施
前置きが長くなりましたが、ここからが本題です。
先ほどのサンプルアーキテクチャを題材として、AWS Well-Architected レビューを実施≒AWS Well-Architected Frameworkに基づいたベストプラクティスのポイントを確認していきます。
本来、AWS Well-Architected レビューはシステム全体のアーキテクチャを評価するものであり、特定のサービスに着目して実施するものではありません。
しかし、本記事ではAmazon Bedrockに着目して進めていきます。（それが本記事のテーマなので）
セキュリティ (Security)
セキュリティ (SEC 1)
SEC 1は、セキュリティの柱の中の「セキュリティ」の項目です。そのままですね。
SEC 1の説明にもあるとおり、セキュリティはシステムを構成する一部に対するものではなく、包括的に考慮・適用する必要がありますが、ここではAmazon Bedrockのセキュリティに着目していきます。
Amazon Bedrockのセキュリティは、AWS公式のユーザーガイドで詳しく解説されています。
ユーザーガイドのセキュリティ項目は以下の構成となっており、詳細はSEC 2以降で確認していきます。
- データ保護 → SEC 7-9
- IDおよびアクセス管理 → SEC 2-3
- コンプライアンス検証 → SEC 7-9
- インシデント応答 → SEC 4
- 耐障害性 → 信頼性の柱
- インフラストラクチャセキュリティ → SEC 5-6
- サービス間の混乱した代理の防止 → SEC 2-3
- Amazon Bedrockでの設定と脆弱性の分析 → SEC 4
SEC 1. ワークロードを安全に運用するには、どうすればよいですか?
ワークロードを安全に運用するには、セキュリティのすべての領域に包括的なベストプラクティスを適用する必要があります。組織レベルおよびワークロードレベルにおいて、運用上の優秀性で定義した要件とプロセスを抽出し、それらをすべての領域に適用します。AWS や業界のレコメンデーションおよび脅威インテリジェンスを最新に保つことで、脅威モデルと管理の目標を進化させることができます。セキュリティプロセス、テスト、検証を自動化することで、セキュリティオペレーションをスケールできます。
IDとアクセス管理 (SEC 2-3)
SEC 2-3はIDとアクセス管理に関するベストプラクティスが定義されています。
Amazon Bedrockユーザーガイドの以下が該当します。
「IDおよびアクセス管理」はそのままですが、「サービス間の混乱した代理の防止」とは何でしょうか？
内容を見ると、IAMポリシーでサービスプリンシパルやグローバル条件コンテキストキーを用いて、Amazon Bedrockと連携するサービス間のアクセス制御をしましょう、という内容となっています。
つまり、アクセス管理の話ですね。（個人的には「IDおよびアクセス管理」に含めたほうが分かりやすいのではないかと思いますが・・・）
続いて、「IDおよびアクセス管理」を見ていきましょう。
まず、Amazon Bedrockに関する対象者を定義することが記載されています。
- サービスユーザー：Amazon Bedrockサービスを使用してジョブを実行するユーザー
- サービス管理者：Amazon Bedrockのリソースを管理するユーザー（Amazon Bedrockへのフルアクセス）
- IAM管理者：IAMを管理するユーザー
なお、Amazon Bedrockのアクセス制御は、アイデンティティベースのポリシーのみであり、リソースベースのポリシーはありません。
（リソースベースのポリシーとは、S3バケットポリシーのようにリソース側でアクセス制御するポリシーのことです）
Amazon Bedrockに関するマネージドポリシーは2種類あります。
- AmazonBedrockFullAccess：Amazon Bedrockに対するフルアクセス権限
- AmazonBedrockReadOnly：mazon Bedrockに対する読み取り専用権限
上記のマネージドポリシーだけでなく、必要に応じて、最小特権の原則に従い、カスタムポリシーを作成・適用しましょう。
カスタムポリシーを作成する上で、そもそも、Amazon Bedrockにはどのようなアクションやリソースが存在するのかは以下のリファレンスを確認し、理解・把握しましょう。
SEC 2. ユーザー ID とマシン ID はどのように管理したらよいでしょうか?
安全に AWS ワークロードを運用するアプローチには、管理する必要があるアイデンティティが 2 種類あります。管理およびアクセス権を付与する必要があるアイデンティティのタイプを理解することで、適切な ID が適切な条件下で適切なリソースにアクセスできるようになります。ユーザー ID: 管理者、開発者、オペレーター、エンドユーザーは、AWS 環境とアプリケーションにアクセスするために ID を必要とします。これらの者は、あなたの組織のメンバー、または共同作業を行う外部ユーザーで、ウェブブラウザ、クライアントアプリケーション、またはインタラクティブなコマンドラインツールを介して AWS リソースを操作する人たちです。マシン ID: サービスアプリケーション、運用ツール、およびワークロードには、たとえばデータの読み取りを行うために、AWS のサービスにリクエストを送るための ID が必要です。このような ID には、Amazon EC2 インスタンスや AWS Lambda 関数など、AWS 環境で実行されているマシンが含まれます。また、アクセスを必要とする外部関係者のマシン ID を管理することもできます。さらに、AWS 環境にアクセスする必要があるマシンが AWS 外にある場合もあります。
SEC 3. 人とマシンのアクセス許可はどのように管理すればよいでしょうか?
アクセス許可を管理して、AWS とワークロードへのアクセスを必要とするユーザー ID やマシン ID へのアクセスを制御します。アクセス許可は、どの条件で誰が何にアクセスできるかを制御します。
検知 (SEC 4)
SEC 4は検知に関するベストプラクティスが定義されています。
ログやメトリクスを分析し、セキュリティイベントや潜在的な脅威に関するベストプラクティスが定義されています。
Amazon Bedrockのログやメトリクスについては以下に詳しく記載されています。
Amazon BedrockのログはS3バケットまたはCloudWatch Logsに送信することが可能です。
また、CloudWatchによるメトリクス監視にも対応しており、以下のようなランタイムメトリクスが提供されています。
- Invocations
- InvocationLatency
- InvocationClientErrors
- InvocationServerErrors
- InvocationThrottles
- InputTokenCount
- LegacyModelInvocations
- OutputTokenCount
- OutputImageCount
また、ランタイムメトリクス以外にログ記録に関するメトリクスも提供されていますので、要件や目的に応じて、メトリクスやログの監視を設定し、セキュリティを強化しましょう。
SEC 4. セキュリティイベントをどのように検出し、調査していますか？
ログやメトリクスからイベントを可視化して把握し、分析します。セキュリティイベントや潜在的な脅威に対して措置をとることで、ワークロードを保護します。
インフラストラクチャ保護 (SEC 5-6)
SEC 5-6は、インフラストラクチャ保護に関するベストプラクティスが定義されています。
Amazon Bedrockに関するインフラストラクチャ保護は以下に詳しく記載されていますが、他のAWSサービスと比較して大きな違いはありません。
SEC 5. ネットワークリソースをどのように保護しますか?
何らかの形式のネットワーク接続があるワークロードは、インターネットでもプライベートネットワークでも、外部および内部ネットワークベースの脅威から保護するために、複数の防御レイヤーが必要です。
SEC 6. コンピューティングリソースをどのように保護していますか?
ワークロード内のコンピューティングリソースを内外の脅威から守るには、複数の防御レイヤーを設ける必要があります。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。
データ保護 (SEC 7-9)
SEC 7-9はデータ保護に関するベストプラクティスが定義されています。
Amazon Bedrockに関するデータ保護は以下に詳しく記載されています。
膨大なデータを扱う基盤モデルを提供するAmazon Bedrockにとって、データ保護は特に重要な要素です。
例えば、AWS KMSを用いたデータ保管時の暗号化機能や、AWS PrivateLinkを用いた転送時のデータ暗号化機能が提供されています。
これらの機能を用いてAmazon Bedrockが扱うデータを暗号化し、セキュリティを強化しましょう。
SEC 7. どのようにデータを分類していますか?
分類方法を確立すると、重要度と機密性に基づいてデータをカテゴリ別に分類して、各カテゴリに適した保護と保持方法でデータを管理できるようになります。
SEC 8. 保管時のデータをどのように保護していますか?
複数のコントロールを実装して保管中のデータを保護し、不正アクセスや不正処理のリスクを低減します。
SEC 9. 転送時のデータをどのように保護していますか?
複数のコントロールを実装して、転送中のデータを保護し、不正アクセスや損失のリスクを軽減します。
インシデント対応 (SEC 10)
SEC 10はインシデント対応に関するベストプラクティスが定義されています。
Amazon Bedrockに関するデータ保護は以下に記載されていますが、他のAWSサービスと比較して大きな違いはありません。
SEC 10. インシデントの予測、対応、復旧はどのように行いますか?
成熟した予防的、発見的統制が実装されていても、組織はセキュリティインシデントの潜在的な影響に対応し、影響を緩和するメカニズムを実装する必要があります。準備することで、インシデントの際にチームが効果的に動作し、問題を切り分け、封じ込め、フォレンジックを実行し、運用を既知の正常な状態に復元する能力に強く影響します。セキュリティインシデントが起こる前にツールとアクセス権を整備し、ゲームデー (実践訓練) を通じてインシデント対応を定期的に実施しておけば、ビジネスの中断を最小限に抑えながら復旧することができます。
アプリケーションのセキュリティ (SEC 11)
SEC 11はアプリケーションのセキュリティに関するベストプラクティスが定義されています。
アプリケーションのセキュリティと言っても、アプリケーションそのものだけでなく、設計、開発、デプロイといったライフサイクル全体でどのようにセキュリティを担保するのかといったことを考慮する必要があります。
ただし、本項目の内容はAmazon Bedrockに限った内容ではないため、詳細は割愛します。
SEC 11. 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?
スタッフのトレーニング、自動化によるテスト、依存関係の理解、ツールやアプリケーションのセキュリティ特性の検証は、本稼働ワークロードにおいてセキュリティの問題が発生する可能性を減らすうえで役立ちます。
あとがき
最後まで読んでいただき、ありがとうございました。
本記事が、これからAmazon Bedrockを活用していこうと考えている方やAWS Well-Architected Frameworkの導入を検討している方の一助になれば幸いです。
いいねやストックをいただけると励みになりますm(_ _)m