前文

クラウドコンピューティングの環境は常に進化しており、コンプライアンスを確保しながら堅牢なセキュリティを維持することは、あらゆる規模の組織にとって重要な課題です。企業がクラウドを導入するケースが増えるにつれ、さまざまなプラットフォーム間でデータを管理および保護する複雑さが飛躍的に増大します。

Amazon Bedrock は、機械学習と AI サービスの強力な基盤を備え、組織がインテリジェントなアプリケーションを開発および展開するためのスケーラブルで安全な環境を提供します。ただし、これらのイノベーションの可能性を最大限に活用するには、セキュリティとコンプライアンスに対する合理化されたアプローチを実装することが不可欠です。

Elastic と Amazon Bedrock を統合すると、クラウド環境内のセキュリティ監視とコンプライアンス管理が大幅に強化されます。この統合により、Elastic の検索、可観測性、セキュリティ機能が活用され、Amazon Bedrock でホストされているアプリケーションとデータの管理とセキュリティ保護の方法が最適化されます。

Elastic のセキュリティ情報およびイベント管理 (SIEM) 機能を使用すると、Amazon Bedrock で実行されているアプリケーションによって生成されたログを分析し、イベントを監視できます。これにより、潜在的なセキュリティ脅威をリアルタイムで検出し、リスクを軽減するための対応アクションを自動化できます。

この記事では、Amazon Bedrock の統合を設定し、事前に構築された検出ルールを有効にしてセキュリティ操作を効率化するプロセスについて説明します。ここでは、次の重要な側面について説明します。

Elastic Amazon Bedrock 統合の前提条件:クラウドセキュリティのための Elastic Amazon Bedrock 統合を設定するためのコア要件を理解します。
Amazon Bedrock 統合の設定: 既存の AWS インフラストラクチャに Amazon Bedrock を設定するための手順。
事前構築されたセキュリティルールの有効化:事前構築されたルールを活用して、信頼性の高いポリシー違反やその他のセキュリティ脅威を検出する方法。
信頼性の高い不正行為ブロックの検出の検討: Amazon Bedrocklogs 内で信頼性の高い不正行為ブロックを検出するために設計された特定の事前構築済みルールを詳細に説明します。
Amazon Bedrock のエクスプロイトケースシナリオのデモンストレーション:サンプルの Python スクリプトを使用して、Amazon Bedrock モデルとのやり取りをシミュレートし、Elastic の事前構築済み検出ルールをトリガーする可能性のあるエクスプロイトシナリオをテストします。

Elastic Amazon Bedrock 統合の前提条件

Amazon Bedrock の Elastic 統合

Amazon Bedrock 統合では、Elastic Agent を使用して Amazon Bedrock モデル呼び出しログとランタイムメトリクスを収集します。統合の詳細については、ドキュメントをご覧ください。

以下は、Amazon Bedrock Elastic Integration を完全に正常に構成するための前提条件のリストです。

AWSアカウントの設定
Elastic Cloudの要件
Terraform（オプション）

AWSアカウントの設定

アクティブな AWS アカウント: Amazon Bedrock でリソースをデプロイおよび管理するための適切な権限を持つアクティブな AWS アカウントがあることを確認します。
Amazon Bedrock のセットアップ: Amazon Bedrock が AWS 環境内で正しく構成され、動作していることを確認します。これには、アプリケーションに必要な AI モデル、データセット、その他のリソースの設定が含まれます。セットアップの詳細については、「Amazon Bedrock の使用開始」を参照してください。
IAM のロールと権限: Elastic が Amazon Bedrock リソースにアクセスできるようにするために必要な権限を持つ Identity and Access Management (IAM) ロールを作成または構成します。これらのロールには、AWS サービスからログ、メトリクス、トレースを読み取るのに十分な権限が必要です。要件の詳細については、 AWS ドキュメントをご覧ください。

Elastic Cloudの要件

バージョン	0.7.0（ベータ版）
互換性のあるKibanaのバージョン	統合バージョン 0.2.0 以上の場合は 8.13.0 以上。Kibana の最小バージョン 8.12.0
サポートされているサーバーレスプロジェクトの種類	セキュリティの可観測性
サブスクリプションレベル	ベーシック
サポートレベル	Elastic

注:統合はベータリリースステージにあるため、 Elastic スタックの管理ペインの統合参照セクションで、ベータ統合の表示を有効にしてください。

テラフォーム

Terraform は、HashiCorp によって作成されたオープンソースの Infrastructure as Code (IaC) ツールであり、クラウドおよびオンプレミスのインフラストラクチャを一貫性と反復性のある方法で定義、プロビジョニング、管理できます。

これはオプションの手順ですが、この記事の次のセクションでこのツールを使用して必要な AWS インフラストラクチャをセットアップするため、実行しておくと便利です。インストールとドキュメントの詳細については、こちらをご覧ください。

Amazon Bedrock 統合の設定

この記事のセクションでは、Amazon Bedrock と Elastic の統合を設定する手順を 2 つの部分に分けて説明します。

Terraform を使用した AWS インフラストラクチャのセットアップ: このセクションでは、Terraform を使用して AWS インフラストラクチャをセットアップする手順について説明します。S3 バケットと、S3 バケットにアクセスするために必要な IAM ロールとポリシーを持つ EC2 インスタンスを作成し、SSH アクセスを許可するようにセキュリティグループを構成します。この設定は、データ処理やストレージなど、EC2 インスタンスが S3 と対話する必要があるシナリオに最適です。
Elastic Agent と統合のセットアップ: このセクションでは、AWS EC2 インスタンスに Elastic Agent をインストールし、Amazon Bedrock 統合を構成する手順について説明します。

Terraform を使用した AWS インフラストラクチャのセットアップ

高レベルの構成プロセスには、次の手順が含まれます。

設定 providers.tf
設定 variables.tf
設定 outputs.tf
設定 main.tf

providers.tfファイルには、通常、プロジェクトで使用している Terraform プロバイダーの構成が含まれています。この例では、AWS プロバイダーの構成が含まれています。以下はproviders.tfファイルのサンプルコンテンツです。providers.tfに記載されているprofile 、AWS 認証情報ファイル(~/.aws/credentials)のユーザースペースで設定する必要があります。Elastic の AWS ドキュメントの認証情報セクションでも強調されている「構成と認証情報ファイルの設定 - AWS コマンドラインインターフェイス」を参照してください。

variables.tfファイルには、Terraform 構成全体で使用される変数定義が含まれています。このシナリオでは、aws_region と resource_labels の定義が含まれます。以下はvariables.tfファイルのサンプルコンテンツです。

outputs.tfファイルには、通常、Terraform 構成の出力定義が含まれています。これらの出力は、インフラストラクチャがプロビジョニングされた後に役立つ情報を表示するために使用できます。以下はoutputs.tfファイルのサンプルコンテンツです

main.tfファイルには、通常、データソース、S3 バケットとバケットポリシー、Amazon Bedrock モデル呼び出しログ構成、SQS キュー構成、Elastic Agent をインストールしてログをストリームする EC2 インスタンスに必要な IAM ロールとポリシー、Amazon Bedrock Guardrail 構成など、これらすべてのリソースのコレクションが含まれています。以下はmain.tfファイルのサンプルコンテンツです。

main.tfが要件に従って構成されると、Terraform 構成を初期化、計画、適用できるようになります。

terraform init // initializes the directory and sets up state files in backend
terraform plan // command creates an execution plan
terraform apply // command applies the configuration aka execution step

terraform が以前に作成したインフラストラクチャを削除するには、 terraform destroyコマンドを使用できます。

インフラストラクチャのセットアップが完了すると、必要なリソース識別子がoutputs.tf.経由で提供されます。次の手順で、作成されたインフラストラクチャの基本的な検証を実行できます。

Terraform から作成された S3 バケットを確認します。aws cli コマンドリファレンスlist-buckets — AWS CLI 1.34.10 コマンドリファレンスを使用するか、AWS コンソール経由で移動して確認することができます。2. Terraform から作成された SQS キューを確認します。aws cli コマンドリファレンスlist-queues — AWS CLI 1.34.10 コマンドリファレンスを使用するか、AWS コンソール経由で移動して確認します。
AWS コンソールから作成された EC2 インスタンスを確認し、 EC2 Instance Connect - Amazon Elastic Compute Cloud を使用して Connect 経由でec2-instance に接続し、 aws s3 ls example-bucket-nameを実行して、インスタンスが作成された S3 バケットにアクセスできるかどうかを確認します。
Terraform から作成された Amazon Bedrock Guardrail を検証するには、Amazon Bedrock API ListGuardrails - Amazon Bedrock を使用するか、AWS コンソール経由で移動して検証することができます。

Elastic Agentと統合設定のセットアップ

AWS EC2 インスタンスに Elastic Agent をインストールし、Amazon Bedrock 統合を構成するには、「Elastic Agent ポリシー | フリートおよび Elastic Agent ガイド [8.15]」のガイド手順に従ってエージェントポリシーを作成します。次に、 EC2 Instance Connect - Amazon Elastic Compute Cloud を使用して Connect経由でインフラストラクチャのセットアップ手順で作成された ec2-instance にログインし、 Elastic Agents のインストール | フリートおよび Elastic Agent ガイド [8.15]のガイド手順に従って Elastic Agent をインストールします。エージェントのインストール中は、このセットアッププロセスの開始時に作成されたエージェントポリシーを選択し、作成されたインスタンスに応じて適切なエージェントインストール方法を使用するようにしてください。最後に、エージェントが適切に構成され、エージェントからの受信データがあることを確認します。

新しく作成されたポリシーで Amazon Bedrock 統合を構成するには、「Elastic Agent 統合をポリシーに追加する」のガイド付き手順に従って Amazon Bedrock 統合を追加します。以下の画像に示すように、ベータ統合を有効にして Amazon Bedrock 統合を使用します。

Amazon Bedrock が設定されている AWS アカウントにアクセスするには、AWS アクセスキーとの統合を設定します。S3 バケットからログを収集し、セットアップ手順で作成したバケット ARN を指定します。セットアップ中は、S3 バケットまたは SQS キュー URL のいずれかを使用し、両方を使用しないように注意してください。この統合を、ec2 インスタンスが設定されている既存のポリシーに追加します。

Amazon Bedrock モデル呼び出しログの取り込みを確認する

Elastic Agent と統合のセットアップが完了したら、次のサンプル API 呼び出しを使用して、統合の基本的な検証を実施し、ログが期待どおりに取り込まれているかどうかを確認できます。

aws bedrock-runtime converse \
--model-id "anthropic.claude-3-5-sonnet-20240620-v1:0" \
--messages '[{"role":"user","content":[{"text":"Hello "}]}]' \
--inference-config '{"maxTokens":2000,"stopSequences":[],"temperature":1,"topP":0.999}' \
--additional-model-request-fields '{"top_k":250}' \
--region us-east-1

このサンプル API 呼び出しでは、aws cli を使用したセットアップが機能していること、および基本モデルAnthropic Claude Messages API - Amazon Bedrockへのアクセスがあることを前提としています。ユーザーがモデルにアクセスできない場合は、「Amazon Bedrock 基盤モデルへのアクセス」で提案されているように、モデルアクセスページからモデルへのアクセスをリクエストするか、オプションで API 呼び出しをユーザーがアクセスできる既存のモデルに変更することもできます。

上記の API 呼び出しが正常に実行されると、Amazon Bedrock モデルの呼び出しログが入力され、Kibana logs-aws_bedrock.invocation-defaultにそれらの呼び出しログが入力されます。次の簡単な ES|QL クエリを使用して、最近取り込まれたイベントを返すことができます。

from logs-aws_bedrock.invocation-* | LIMIT 10

事前構築された検出ルールを有効にする

事前構築された検出ルールを有効にするには、まずエラスティックインスタンスにログインし、左側のペインのナビゲーションから [セキュリティ] → [ルール] → [検出ルール (SIEM)] に移動します。タグセクションから「データソース: Amazon Bedrock」をフィルタリングします。

利用可能な事前構築済みルールを有効にします。事前構築されたルールの場合、セットアップ情報には、Amazon Bedrock 用の AWS Guardrails をセットアップするためのヘルパーガイドが含まれています。これは、例に正しく従って、Terraform に Amazon Bedrock Guardrail 構成がある場合は、「Terraform を使用した AWS インフラストラクチャのセットアップ」手順で実行できます。この設定は、一部のルールがアラートを生成するために不可欠であることに注意してください。インフラストラクチャのセットアップ段階でスキップされた場合は、ガードレールが適切に設定されていることを確認する必要があります。

信頼性の高い不正行為ブロック検出の検討

ユーザーが Amazon Bedrock モデルに拒否されたトピックをクエリする実際のシナリオをシミュレートしてみましょう。Amazon UI コンソールの Amazon Bedrock セクションに移動し、左側のナビゲーションペインを使用して、Safeguards の下の Guardrails サブセクションに移動します。この演習のセットアップ手順で作成されたサンプルガードレールを使用し、テストオプションを使用してガードレールを使用したモデル呼び出しを実行し、構成された拒否されたトピックをクエリします。

事前構築されたルールは、 5 超える高信頼ブロックに対してアラートを出すように設計されているため、クエリを少なくとも 6 回繰り返します。アラートスケジュールが実行されると、アラートが表示されます。 Unusual High Confidence Misconduct Blocks Detected.

Amazon Bedrock のエクスプロイトケースシナリオのデモンストレーション

Amazon Bedrock セキュリティバイパスをシミュレートするには、Amazon Bedrock モデルと対話するためのエクスプロイトシミュレーションスクリプトが必要です。私たちが提供するエクスプロイトスクリプトの例では、次の攻撃パターンをシミュレートします。

AWS Bedrock 内で拒否されたモデルリソースを使用するための複数の連続したリクエストを試みます
Amazon Bedrock 内で複数の連続した検証例外エラーを生成します
ユーザーは一貫して高い入力トークン数を生成し、多数のリクエストを送信し、リソース枯渇のパターンを模倣した大きな応答を受け取ります。
繰り返しの高い信頼性で「ブロック」されたアクションと、「不法行為」などの特定の違反コードを組み合わせ、モデルの継続的な誤用や倫理的境界を探ろうとする試みを示します。

class BedrockModelSimulator:
   def __init__(self, profile_name, region_name):
       // Create a Boto3 Session Client for Ineration 
   def generate_args_invoke_model(self, model_id, user_message, tokens): 	// Generate Model Invocation parameters
       guardrail_id = <<GUARDRAIL_ID>>
       guardrail_version = <<GUARDRAIL_VERSION>>

       guardrail_config = {
           "guardrailIdentifier": guardrail_id,
           "guardrailVersion": guardrail_version,
           "trace": "enabled"
       }
       conversation = [
           {
               "role": "user",
               "content": [{"text": user_message}],
           }
       ]
       inference_config = {"maxTokens": tokens, "temperature": 0.7, "topP": 1}
       additional_model_request_fields = {}

       kwargs = {
           "modelId": model_id,
           "messages": conversation,
           "inferenceConfig": inference_config,
           "additionalModelRequestFields": additional_model_request_fields
	    "guardrailConfig" : guardrail_config
       }
       return kwargs
  
   def invoke_model(self, invocation_arguments):
       for _ in range(count):
           try:
               // Invoke Model With right invocation_arguments
           except ClientError as e:
               // Error meesage

def main():
   profile_name = <<AWS Profile>>
   region_name = 'us-east-1'
   denied_model_id = // Use a denied model   
   denied_model_user_message = // Sample Message 
   available_model_id = // Use an available model  
   validation_exception_user_message = // Sample Message 
   resource_exploit_user_message = // A very big message for resource exhuastion
   denied_topic_user_message = // Sample Message that can query denied topic configured
   simulator = BedrockModelSimulator(profile_name, region_name)
   denied_model_invocation_arguments = simulator.generate_args_invoke_model(denied_model_id, denied_model_user_message, 200)
   simulator.invoke_model(denied_model_invocation_arguments)
   validation_exception_invocation_arguments = simulator.generate_args_invoke_model(available_model_id, validation_exception_user_message, 6000)
   simulator.invoke_model(validation_exception_invocation_arguments)
   resource_exhaustion_invocation_arguments = simulator.generate_args_invoke_available_model(available_model_id, resource_exploit_user_message, 4096)
   simulator.invoke_model(resource_exhaustion_invocation_arguments)
   denied_topic_invocation_arguments = simulator.generate_args_invoke_available_model_guardrail(available_model_id, denied_topic_user_message, 4096)
   simulator.invoke_model(denied_topic_invocation_arguments)

if __name__ == "__main__":
   main()

注: GUARDRAIL_ID と GUARDRAIL_VERSION はoutputs.tfにあります。

制御された環境で実行すると、提供されたスクリプトは、Elastic Security で検出アラートを生成するエクスプロイトシナリオをシミュレートします。Elastic Attack Discovery 機能を使用してこれらのアラートを分析すると、スクリプトはさまざまなアラート間の関係を示す攻撃チェーンを作成し、複数のアラートが大規模な攻撃の一部となる可能性をアナリストが明確に理解できるようにします。

まとめ

Elastic と Amazon Bedrock を統合することで、組織は AI と機械学習のメリットを最大限に活用しながら、安全でコンプライアンスに準拠したクラウド環境を維持できるようになります。Elastic の高度なセキュリティおよび可観測性ツールを活用することで、企業は脅威を積極的に検出し、コンプライアンスレポートを自動化し、クラウド運用に関するより深い分析情報を得ることができます。企業は、最も深刻な脅威を明らかにするために、ますます不透明なデータソースとテクノロジに依存するようになっています。透明なセキュリティに対する当社の取り組みは、オープンな成果物、統合、およびソースコードに表れています。

セキュリティの合理化: Amazon Bedrock と Elastic の統合

前文