Amazon BedrockがAI生成フィッシングを検出する方法

ソーシャルエンジニアリングによるフィッシングは、依然としてサイバー攻撃を仕掛ける最も一般的な戦術の1つです。AI生成のフィッシングメールは、電子メールシステムを管理するセキュリティチームに新たな課題をもたらし、その高度な洗練性によりリスクを大幅に高めています。現代のソーシャルエンジニアは、生成AIとオープンソースインテリジェンス（OSINT）を利用して、完璧な文法、適切な文脈、パーソナライズされた詳細を持つ何千ものユニークなメッセージを作成します。今日では、フィッシングメールの指標は、完璧に書かれ、専門的にフォーマットされたメッセージである可能性があります。

中堅企業のITセキュリティエンジニアであるJohnのような人物にとって、フィッシング検出のルールはかつて単純でした。タイプミスをフラグし、一般的な挨拶をキャッチし、送信者ドメインが一致しないものを隔離することです。これらは、攻撃が大量の汎用的でエラーの多いメールを大規模に送信し、正確さではなく量に依存して被害者を見つけていた、初期のフィッシング時代の特徴でした。セキュリティフィルターはまさにこれらの脅威のために構築され、長年にわたって効果的でした。貧弱な文法、一般的な挨拶、不一致のロゴは、攻撃者を露呈させる指標でした。

現在Johnが監視する脅威環境は、それらのフィルターが捕捉するように設計されたものとはまったく異なります。生成AIはフィッシングの仕組みを変えました。攻撃は文法的に正しく、文脈的に正確で、ターゲットにパーソナライズされています。これらのメッセージは従来のフィルターをトリガーしません。なぜなら、それらのフィルターはそれらを捕捉するように設計されていなかったからです。脅威はもはやその外観ではなく、それが知っていることによって識別可能です。現代のAIシステムは、専門家ネットワーク、企業ウェブサイト、公開されているデジタルフットプリントからデータを取得し、組織の階層と関係をマッピングするOSINT操作を実行します。そのインテリジェンスを使用して、ソーシャルエンジニアは大規模なデータセットを処理し、組織に合わせた文脈的に正確なメッセージを生成できます。これらの通信は、応答に基づいてリアルタイムで適応し、トーンを変えたり、会話と一貫性を保つために詳細を調整したりすることもできます。

Amazon Bedrockは、主要なAI企業からの高性能基盤モデル（FM）を統一APIを通じて利用可能にし、セキュリティ、プライバシー、責任あるAIを備えた生成AIアプリケーションを構築するために必要な機能を提供するフルマネージドサービスです。Amazon Bedrockは、従来の表面レベルのフィルタリングを超えて、既存のセキュリティインフラストラクチャに分析の追加レイヤーを追加します。コンテキストを理解し、文法品質やフォーマットではなく行動パターンに基づいてフィッシングの試みを検出します。これを実践するために、Amazon Bedrockがメールが受信箱に到着した瞬間からどのように分析するかを分解してみましょう。

Amazon Bedrockは、膨大な量のデータで事前トレーニングされた大規模汎用AIモデルを使用します。基盤モデルは、メールコンテンツの行動パターンを分析し、文脈上の関係を理解し、メッセージがフィッシングの試みである可能性を示す異常を特定できます。実際には、これらの機能は多段階分析パイプラインとして構成できます。各メールは、ユーザーの受信箱に届く前に、認証、行動分析、リスクスコアリングを通過します。

Amazon Bedrockは、AI駆動のフィッシング防御を強化するための2つの統合機能を提供します。事前トレーニングされた基盤モデルは、ルールベースのシステムでは見えない微妙な操作、文脈上の異常、なりすましパターンを検出できる高度な自然言語理解をもたらします。2番目の機能であるAmazon Bedrock Guardrailsは、カスタム検出ロジックを必要とせずに、基盤モデルのインタラクションを組織の責任あるAIポリシーとアプリケーション要件に合わせるための設定可能なセーフガードを提供します。これらの機能を組み合わせて、多段階メール分析パイプラインに統合できます。

ソリューションのワークフローでは、各メッセージは最初に標準の認証チェック（SPF、DKIM、DMARC）を受けます。これらのプロトコルは、送信サーバーがドメインに代わって送信する権限があり、メッセージが転送中に改ざんされていないことを確認します。Amazon Bedrock基盤モデルを利用したフィッシング検出ワークフローは、単語の選択、コミュニケーションスタイルの逸脱、リクエストの文脈上の適切さという3つの主要な要素に対してメッセージを分析します。書き方の微妙な不整合や誤ったリクエストを検出することで、従来のセキュリティ制御に加えてより深い分析層を追加します。AI分析には、定義された境界内で責任を持って動作することを確認するための慎重なガバナンスも必要です。Amazon Bedrock Guardrailsは、入力プロンプトとモデル出力の両方をフィルタリングするのに役立ちます。機密データが誤って漏洩する可能性のある応答を防ぎ、分析結果が設定したポリシーに準拠していることを確認します。ガードレールは、アプリケーション要件を満たすために注意深い設定と調整が必要であることに留意してください。

Amazon Bedrock Guardrailsの実装により、コンテンツフィルター、拒否トピック、ワードフィルター、機密情報フィルターを通じて、基盤モデルがメールコンテンツを処理する方法をきめ細かく制御できます。たとえば、セキュリティエンジニアのJohnは、メール分析中に発見された機密の個人識別情報（PII）を自動的に編集するようにガードレールを設定し、基盤モデルが誤って機密データを漏洩する応答を生成するのを防ぐことができます。

ただし、セキュリティ分析のためのガードレール設定には注意深い調整が必要です。コンテンツフィルターは不適切な入力と出力を防ぎますが、過度に制限的な設定は、評価する必要がある正当な疑わしいコンテンツをモデルが分析するのを妨げる可能性があります。ソーシャルエンジニアがフィルターを回避するためにメールに攻撃的な言葉を含めた場合、ガードレールはセキュリティシステムがそのコンテンツを分析できるようにしなければなりません。同時に、ガードレールは他のコンテキストでも不適切な入力と出力を防ぐ必要があります。ガードレールはまた、モデルの応答を分析中のメールコンテンツに事実に基づいて固定する文脈的グラウンディングチェックを提供し、モデルの幻覚による誤検出を減らします。これにより、AI駆動の分析は定義された境界内で動作しながらも、複雑なパターンを検出できます。

この記事では、Amazon Bedrock基盤モデルを使用して送信者の行動パターン、文脈上の適切さ、コミュニケーションの異常を評価し、AI生成のフィッシング試行がユーザーに届く前に識別する多段階メール分析パイプラインを実装する方法を学びます。

以下のフレームワークは、既存のメールセキュリティインフラストラクチャ内でこれを実践する方法を示し、Johnのような立場の人が受動的なフィルタリングから能動的な検出に移行できるようにします。標準の認証チェック（SPF、DKIM、DMARC）でメールが正当なメールサーバーから送信されたことが確認された後、フィッシング検出ワークフローは行動分析を層状に追加することでさらに一歩進みます。システムは、サーバーが認可されているかどうかのチェックから、メッセージが同僚の通常のコミュニケーション方法と一致するかどうかの評価に移行します。

実装に入る前に、各コンポーネントの役割を明確にしましょう。行動分析は、送信者ベースライントラッカーから始まります。これは、あなたにメールを送信する各人のプロファイルです。送信者ベースライントラッカーは、従業員が通常どのように書くかを記録し、Amazon Bedrock分析パイプラインが比較するためのリファレンスポイントを持てるようにします。

継続的な使用を通じて、フィッシング検出ワークフローは、従業員が使用する単語、フォーマルまたはカジュアルな程度、通常何を要求するか、誰と通常コミュニケーションするかを理解します。Johnの環境を考えてみてください。通常は短い一言を送る同僚が、突然、緊急の銀行振込を要求する正式なメールを書いた場合、分析パイプラインはその変化をキャッチし、Johnのチームが詳しく調べるようにフラグを立てます。これにより、誤報が減少し、Johnのチームが実際の脅威でないフラグ付きメールの選別に費やす時間を節約できます。

以下は、メールがフィッシング検出ワークフローに入ったときにこれらのコンポーネントがどのように連携するかの高レベルの概要です。

ステップ1：入力ガードレールと前処理 EmailSecurityAnalyzerの初期化:

• Amazon Bedrockクライアントの設定（Claude Sonnet 4.5モデル）
• PII保護とコンテンツフィルタリングのためのAmazon Bedrock Guardrailsの設定
• フィッシングサンプルの知識ベースの初期化
• 送信者ベースライントラッカーの初期化
• リスクしきい値の設定（安全 = 70）

関数 analyze_email(email): // ステップ1：ガードレールで前処理 processed_email = apply_input_guardrails(email) コンテンツがブロックされた場合: 手動レビューが必要を返す

フィッシング検出ワークフローは、最初に受信メールをAmazon Bedrock Guardrailsで実行し、機密コンテンツをスクリーニングし、分析開始前に手動レビューが必要なものをフラグします。

ステップ2：コンテキストを含むプロンプト構築 // ステップ2：分析プロンプトの構築 prompt = construct_prompt( email_content, sender_baseline_patterns, organizational_context, known_phishing_examples )

メールがそのチェックを通過した後、ワークフローはメールコンテンツと送信者のベースラインコミュニケーションパターン、組織コンテキスト、そしてAmazon Bedrock Knowledge Basesを使用した既知のフィッシング例を組み合わせて分析プロンプトを構築します。これにより、モデルは孤立してではなく、全体像に対してメッセージを評価します。

ステップ3：ガードレール付きAI駆動分析 // ステップ3：ガードレールを使用してAIモデルを呼び出す analysis = bedrock_invoke_with_guardrails(prompt) ガードレールが介入した場合: 理由とともにブロックを返す

基盤モデルは構築されたプロンプトを使用してメールを処理し、ガードレールは分析を定義されたセキュリティ境界内に保ちます。基盤モデルは疑わしいコンテンツを徹底的に調査できますが、ガードレールはその過程で機密情報を露出する出力を生成するのを防ぎます。

ステップ4：多要素リスクスコアリング // ステップ4：リスクスコアの計算 risk_score = weighted_average( content_anomaly_score, behavioral_deviation_score, context_alignment_score )

その分析から、Amazon Bedrockパイプラインは3つのスコアを生成します。1つはコンテンツ異常用、1つは行動逸脱用、1つはコンテキスト整合性用です。パイプラインはそれらを0〜100の単一のリスクスコアに結合し、メールのルーティング先を決定します。

ステップ5：分類と自動ルーティング // ステップ5：分類とルーティング risk_level = classify_risk(risk_score) action = route_email(risk_level) // 配信、隔離、ブロック 分析結果を返す

関数 route_email(risk_level): risk_level == 安全の場合: 受信箱に配信 risk_level == 疑わしい場合: レビューのために隔離 risk_level == 危険の場合: ブロックしてセキュリティチームに警告

安全なメッセージは通常通り従業員の受信箱に届きます。疑わしいメールは隔離され、セキュリティチームがレビューします。危険なメールは直接ブロックされます。

フィードバックによる継続的学習

関数 process_feedback(email, is_phishing): is_phishingの場合: フィッシング知識ベースに追加(email) それ以外の場合: 送信者ベースラインを更新(email) 正当な例に追加(email)

これらのステップは、メッセージがルーティングシステムを通過する際にミリ秒単位で発生します。既存のインフラストラクチャは、メッセージのルーティングと配信を引き続き処理します。分析はそれと並行して検査レイヤーとして実行され、メッセージがユーザーの受信箱に届く前に行動リスクを評価します。

継続的な使用を通じて、フィッシング検出ワークフローはフィードバックループを通じて送信者ベースラインと知識ベースを更新し、誤報を減らし検出精度を向上させます。