次の方法で共有

監視と脅威検出のためのアーキテクチャ戦略

この Azure Well-Architected Framework セキュリティ チェックリストの推奨事項に適用されます。

SE:10 プラットフォームと統合できる最新の脅威検出メカニズムに依存する包括的な監視戦略を実装します。 メカニズムでは、トリアージに対して確実にアラートを生成し、既存の SecOps プロセスにシグナルを送信する必要があります。

このガイドでは、監視と脅威の検出に関する推奨事項について説明します。 監視は基本的に、既に 発生したイベントに関する情報を取得するプロセスです。 セキュリティ監視は、 疑わしいアクティビティを認識するために、ワークロードのさまざまな高度 (インフラストラクチャ、アプリケーション、操作) で情報をキャプチャする方法です。 目標は、インシデントを予測し、過去のイベントから学習することです。 監視データは、インシデント対応とフォレンジック調査に役立つ、インシデント発生後の分析の基礎を提供します。

監視は、Well-Architected フレームワークのすべての柱に適用されるオペレーショナル エクセレンスアプローチです。 このガイドでは、セキュリティの観点からのみ推奨事項を提供します。 コード インストルメンテーション、データ収集、分析など、監視の一般的な概念は、このガイドの範囲外です。 主要な監視の概念については、「 可観測性フレームワークの設計と構築に関する推奨事項」を参照してください。

定義

任期 Definition
監査ログ システム内の活動の記録。
セキュリティ情報とイベント管理 (SIEM) 複数のソースから集計されたデータに基づいて、組み込みの脅威検出とインテリジェンス機能を使用するアプローチ。
脅威の検出 収集、分析、および相関データを使用して、予想されるアクションからの逸脱を検出するための戦略。
脅威情報 パターンを調べることで、脅威検出データを解釈して疑わしいアクティビティまたは脅威を検出するための戦略。
脅威の防止 資産を保護するためにさまざまな高度でワークロードに配置されるセキュリティ制御。

セキュリティ監視の主な目的は、 脅威の検出です。 主な目的は、潜在的なセキュリティ侵害を防ぎ、セキュリティで保護された環境を維持することです。 ただし、すべての脅威が先制的にブロックされるわけではないことを認識することも同様に重要です。 このような場合、監視は、防止作業にもかかわらず発生したセキュリティ インシデントの原因を特定するメカニズムとしても機能します。

監視は、さまざまな観点からアプローチできます。

  • さまざまな高度で監視します。 さまざまな高度から観察することは、ユーザー フロー、データ アクセス、ID、ネットワーク、さらにはオペレーティング システムに関する情報を取得するプロセスです。 これらの各領域には、セキュリティ ベースラインに対して確立された予期される動作からの逸脱を特定するのに役立つ独自の分析情報が用意されています。 逆に、システムとアプリケーションを時間の経過と同時に継続的に監視すると、 そのベースラインの姿勢を確立するのに役立ちます。 たとえば、通常、ID システムでは 1 時間ごとに約 1,000 回のサインイン試行が行われる場合があります。 短期間に 50,000 回のサインイン試行の急増が監視によって検出された場合、攻撃者がシステムにアクセスしようとしている可能性があります。

  • さまざまな影響範囲で監視します。 アプリケーションとプラットフォームを観察することが重要です。 アプリケーション ユーザーが誤ってエスカレートされた特権を取得したか、セキュリティ侵害が発生したとします。 ユーザーが指定されたスコープを超えてアクションを実行した場合、その影響は他のユーザーが実行できるアクションに限定される可能性があります。

    ただし、内部エンティティがデータベースを侵害した場合、潜在的な損害の程度は不明です。

    Azure リソース側で侵害が発生した場合、その影響はグローバルになり、リソースと対話するすべてのエンティティに影響を与える可能性があります。

    これらのシナリオのどれが発生するかに応じて、爆発半径または衝撃範囲が大きく異なる場合があります。

  • 特殊な監視ツールを使用します。 攻撃を示す可能性のある異常な動作を継続的にスキャンできる 特殊なツール に投資することが重要です。 これらのツールのほとんどは、大量のデータと既知の脅威に基づいて予測分析を実行できる脅威 インテリジェンス機能 を備えています。 ほとんどのツールはステートレスではなく、セキュリティ コンテキストにテレメトリの深い理解を組み込みます。

    プラットフォームから深いシグナルを取得し、忠実度の高い予測を行うには、ツールをプラットフォームに統合するか、少なくともプラットフォーム対応にする必要があります。 適切なトリアージを実行するのに十分な情報を使用して、タイムリーにアラートを生成できる必要があります。 多くのツールを使用すると、複雑になる可能性があります。

  • インシデント対応の監視を使用します。 実用的なインテリジェンスに変換された集計データにより、インシデントに 対する迅速かつ効果的な対応が可能 になります。 監視 は、インシデント後のアクティビティに役立ちます。 目標は、何が起こったかを分析して理解するのに十分なデータを収集することです。 監視のプロセスでは、過去のイベントに関する情報をキャプチャして反応性機能を強化し、将来のインシデントを予測する可能性があります。

次のセクションでは、上記の監視の観点を組み込んだ推奨プラクティスについて説明します。

データをキャプチャしてアクティビティの証跡を保持する

目的は、セキュリティの観点から重要なイベントの 包括的な監査証跡 を維持することです。 ログ記録は、アクセス パターンをキャプチャする最も一般的な方法です。 ログ記録は、アプリケーションとプラットフォームに対して実行する必要があります。

監査証跡の場合は、 アクションに関連付けられている 内容、 タイミング、 およびユーザー を確立する必要があります。 アクションが実行される特定の期間を特定する必要があります。 脅威モデリングでこの評価を行います。 否認の脅威に対抗するには、アクティビティとトランザクションの記録につながる強力なログ記録と監査システムを確立する必要があります。

次のセクションでは、ワークロードのいくつかの一般的な高度のユース ケースについて説明します。

アプリケーション ユーザー フロー

アプリケーションは、イベントが発生したときに実行時の可視性を提供するように設計する必要があります。 アプリケーション内の重要なポイントを特定し、これらのポイントのログ記録を確立します。 たとえば、ユーザーがアプリケーションにログインするときに、ユーザーの ID、ソースの場所、およびその他の関連情報をキャプチャします。 ユーザー特権のエスカレーション、ユーザーが実行したアクション、およびユーザーがセキュリティで保護されたデータ ストア内の機密情報にアクセスしたかどうかを確認することが重要です。 ユーザーとユーザー セッションのアクティビティを追跡します。

この追跡を容易にするには、 構造化されたログを使用してコードをインストルメント化する必要があります。 これにより、ログのクエリとフィルター処理を簡単かつ均一に行うことができます。

Important

システムの機密性と整合性を維持するには、責任あるログ記録を強制する必要があります。 シークレットと機密データはログに表示しないでください。 このログ データをキャプチャするときは、個人データの漏洩やその他のコンプライアンス要件に注意してください。

ID とアクセスの監視

アプリケーションのアクセス パターンとプラットフォーム リソースへの変更の完全な記録を保持します。 攻撃者は多くの場合、ID を操作して未承認のアクセスを得ようとするため、堅牢なアクティビティ ログと脅威検出メカニズム (特に ID 関連のアクティビティ用) を用意します。

使用可能なすべてのデータ ポイントを使用して、包括的なログ記録を実装します。 たとえば、通常のユーザー アクティビティと予期しない場所からの潜在的な脅威を区別するために、クライアント IP アドレスを含めます。 すべてのログ イベントは、サーバーによってタイムスタンプが付けられます。

すべてのリソース アクセス アクティビティを記録し、誰が何をいつ実行しているかをキャプチャします。 特権エスカレーションのインスタンスは、ログに記録する必要がある重要なデータ ポイントです。 アプリケーションによるアカウントの作成または削除に関連するアクションも記録する必要があります。 この推奨事項は、アプリケーション シークレットにまで及びます。 シークレットにアクセスするユーザーと、シークレットがローテーションされたタイミングを監視します。

成功したアクションのログ記録は重要ですが、 セキュリティの観点から失敗を記録する必要があります。 ユーザーがアクションを試みたが承認エラーが発生した、存在しないリソースに対するアクセス試行、疑わしいと思われるその他のアクションなど、違反を文書化します。

ネットワーク監視

ネットワーク パケットとその送信元、宛先、および構造を監視することで、ネットワーク レベルでアクセス パターンを可視化できます。

セグメント化の設計 では、境界の観測ポイントで それらの境界を越えたものを監視し、そのデータをログに記録できるようにする必要があります。 たとえば、フロー ログを生成するネットワーク セキュリティ グループがあるサブネットを監視します。 また、許可または拒否されたフローを示すファイアウォール ログも監視します。

受信接続要求のアクセス ログがあります。 これらのログには、要求を開始するソース IP アドレス、要求の種類 (GET、POST)、および要求の一部である他のすべての情報が記録されます。

DNS フローのキャプチャは、多くの組織にとって重要な要件です。 たとえば、 DNS ログは、特定の DNS クエリを開始したユーザーまたはデバイスを識別するのに役立ちます。 DNS アクティビティをユーザー/デバイス認証ログと関連付けることで、個々のクライアントにアクティビティを追跡できます。 多くの場合、この責任はワークロード チームにまで及びます。特に、DNS 要求が操作の一部となるものをデプロイする場合です。 DNS トラフィック分析は、プラットフォームのセキュリティ監視の重要な側面です。

既知のコマンドおよび制御エンドポイントに向けられた予期しない DNS 要求または DNS 要求を監視することが重要です。

トレードオフ: すべてのネットワーク アクティビティをログに記録すると、大量のデータが発生する可能性があります。 レイヤー 3 からの要求はすべて、サブネット境界を越えるすべてのトランザクションを含むフロー ログに記録できます。 残念ながら、発生した後にのみ識別できるため、有害イベントのみをキャプチャすることはできません。 キャプチャするイベントの種類と、イベントを格納する期間に関する戦略的な決定を行います。 注意しないと、データの管理が圧倒的になる可能性があります。 また、そのデータを格納するコストにもトレードオフがあります。

トレードオフがあるため、ワークロードのネットワーク監視の利点がコストを正当化するのに十分かどうかを検討する必要があります。 要求量が多い Web アプリケーション ソリューションがあり、システムでマネージド Azure リソースを広範に使用している場合、コストがメリットを上回る可能性があります。 一方、さまざまなポートとアプリケーションで仮想マシンを使用するように設計されたソリューションがある場合は、ネットワーク ログをキャプチャして分析することが重要な場合があります。

システムの変更をキャプチャする

システムの整合性を維持するには、システム状態の正確で up-toな日付レコードが必要です。 変更がある場合は、このレコードを使用して、発生した問題に迅速に対処できます。

ビルド プロセスでは、テレメトリも出力する必要があります。 イベントのセキュリティ コンテキストを理解することが重要です。 ビルド プロセスをトリガーした内容、ビルド プロセスをトリガーしたユーザー、およびトリガーされたタイミングを知ることで、貴重な分析情報を得ることができます。

リソースがいつ作成され、いつ使用が停止されているかを追跡します。 この情報は、プラットフォームから抽出する必要があります。 この情報は、リソース管理とアカウンタビリティに関する貴重な分析情報を提供します。

リソース構成の誤差を監視します。 既存のリソースへの変更を文書化します。 また、リソースのフリートへのロールアウトの一環として完了しない変更も追跡します。 ログでは、変更の詳細と正確な時刻をキャプチャする必要があります。

パッチ適用の観点から、システムが up-to-date で安全かどうかを包括的に確認できます。 定期的な更新プロセスを監視 して、計画どおりに完了したことを確認します。 完了しないセキュリティ修正プログラムの適用プロセスは、脆弱性と見なす必要があります。 パッチ レベルやその他の必要な詳細を記録するインベントリも保持する必要があります。

変更検出はオペレーティング システムにも適用されます。 これには、サービスが追加されたか無効になっているかを追跡する必要があります。 また、システムへの新しいユーザーの追加の監視も含まれます。 オペレーティング システムを対象とするように設計されたツールがあります。 これらは、ワークロードの機能を対象としていないという意味で、コンテキストのない監視に役立ちます。 たとえば、ファイルの整合性の監視は、システム ファイルの変更を追跡できる重要なツールです。

これらの変更のアラートは、特に頻繁に発生することが予想されない場合に設定する必要があります。

Important

運用環境にロールアウトするときは、アプリケーション リソースとビルド プロセスで検出された異常なアクティビティをキャッチするようにアラートが構成されていることを確認します。

テスト計画に、優先順位付けされたテスト ケースとして ログ記録とアラートの検証を含めます 。

データの格納、集計、分析

これらの監視アクティビティから収集されたデータは、データ シンクに格納する必要があります。データ シンクは、徹底的に 調査、正規化、および関連付けることができます。 セキュリティ データは、システム独自のデータ ストアの外部に保持する必要があります。 シンクの監視は、ローカライズされているか中央にあるかに関係なく、データ ソースよりも長く必要です。 シンクは侵入検出システムのソースであるため、シンクを エフェメラルにすることはできません 。

ネットワーク ログは詳細になり、ストレージを占有する場合があります。 ストレージ システムのさまざまなレベルを調べる。 ログは、時間の経過と同時に、より寒いストレージに自然に移行する可能性があります。 通常、古いフロー ログはアクティブに使用されず、必要に応じてのみ必要になるため、この方法が役立ちます。 この方法により、効率的なストレージ管理が保証され、必要なときに履歴データにアクセスできるようになります。

ワークロードのフローは、通常、複数のログ ソースを複合したものです。 監視データは、 すべてのソースでインテリジェントに分析する必要があります。 たとえば、ファイアウォールでは、ファイアウォールに到達したトラフィックのみがブロックされます。 特定のトラフィックを既にブロックしているネットワーク セキュリティ グループがある場合、そのトラフィックはファイアウォールに表示されません。 一連のイベントを再構築するには、フロー内のすべてのコンポーネントのデータを集計してから、すべてのフローのデータを集計する必要があります。 このデータは、インシデント対応後のシナリオで何が起こったかを理解しようとするときに特に役立ちます。 正確なタイムキーピングが不可欠です。 セキュリティ上の理由から、すべてのシステムで常に同期されるように、ネットワーク タイム ソースを使用する必要があります。

相関ログを使用した一元的な脅威検出

セキュリティ情報およびイベント管理 (SIEM) などのシステムを使用して、 セキュリティ データ をさまざまなサービス間で関連付けることができる中央の場所に統合できます。 これらのシステムには、 脅威検出メカニズムが組み込まれています 。 外部フィードに接続して、脅威インテリジェンス データを取得できます。 たとえば、Microsoft は、使用できる脅威インテリジェンス データを公開します。 Anomali や FireEye などの他のプロバイダーから脅威インテリジェンス フィードを購入することもできます。 これらのフィードは、貴重な分析情報を提供し、セキュリティ体制を強化することができます。 Microsoft からの脅威に関する分析情報については、 Security Insider を参照してください。

SIEM システムは、相関データと正規化されたデータに基づいて アラートを生成 できます。 これらのアラートは、インシデント対応プロセス中の重要なリソースです。

トレードオフ: SIEM システムはコストがかかり、複雑になり、特殊なスキルが必要になる場合があります。 ただし、データがない場合は、独自にデータを関連付ける必要があります。 これは、時間がかかり、複雑なプロセスになる可能性があります。

SIEM システムは通常、組織の中央チームによって管理されます。 組織に存在しない場合は、それを主張することを検討してください。 これにより、手動のログ分析と相関関係の負担が軽減され、より効率的で効果的なセキュリティ管理が可能になります。

一部のコスト効率の高いオプションは、Microsoft によって提供されます。 多くの Microsoft Defender 製品では、SIEM システムのアラート機能が提供されますが、データ集計機能はありません。

いくつかの小さなツールを組み合わせることで、SIEM システムのいくつかの機能をエミュレートできます。 ただし、これらのその場しのぎのソリューションでは相関分析を実行できない可能性があることを知る必要があります。 これらの代替手段は便利ですが、専用 SIEM システムの機能を完全に置き換えるわけではありません。

不正使用を検出する

SSH コンポーネントや RDP エンドポイントに対する ID ブルート フォース攻撃など、脅威の検出に積極的に取り組み、悪用の兆候に注意してください。 外部の脅威によって多くのノイズが発生する可能性がありますが、特にアプリケーションがインターネットに公開されている場合は、 内部の脅威が大きな懸念事項となります。 信頼されたネットワーク ソースからの予期しないブルート フォース攻撃や、不注意による構成の誤りなどを直ちに調査する必要があります。

セキュリティ強化のプラクティスに従ってください。 監視は、環境を積極的に強化するための代わりではありません。 より大きな領域は、より多くの攻撃を受けやすくなります。 練習と同じくらいコントロールを強化します。 たとえば、未使用のアカウントを検出して無効にしたり、未使用のポートを削除したり、Web アプリケーション ファイアウォールを使用したりします。 セキュリティ強化の手法の詳細については、「セキュリティ強化 に関する推奨事項」を参照してください。

署名ベースの検出 では、システムを詳細に検査できます。 攻撃の可能性を示す可能性のあるアクティビティ間の兆候や相関関係を探す必要があります。 検出メカニズムは、特定の種類の攻撃を示す特定の特性を識別する場合があります。 攻撃のコマンドアンドコントロールメカニズムを直接検出できるとは限りません。 ただし、多くの場合、特定のコマンド アンド コントロール プロセスに関連付けられたヒントやパターンがあります。 たとえば、攻撃は、要求の観点から特定のフロー レートによって示されたり、特定の終了を持つドメインに頻繁にアクセスしたりする場合があります。

予期されるパターンからの逸脱を特定して調査できるように、 異常なユーザー アクセス パターンを検出します。 これには、現在のユーザーの動作と過去の動作を比較して異常を特定する必要があります。 このタスクを手動で実行することはできませんが、脅威インテリジェンス ツールを使用して実行できます。 監視データからユーザーの行動を収集して分析するユーザー とエンティティの行動分析 (UEBA) ツール に投資します。 これらのツールは、多くの場合、疑わしい動作を潜在的な種類の攻撃にマップする予測分析を実行できます。

デプロイ前とデプロイ後の段階で脅威を検出します。 デプロイ前フェーズでは、脆弱性スキャンをパイプラインに組み込み、結果に基づいて必要なアクションを実行します。 デプロイ後、引き続き脆弱性スキャンを実行します。 コンテナー イメージをスキャンする Microsoft Defender for Containers などのツールを使用できます。 収集されたデータに結果を含めます。 セキュリティで保護された開発プラクティスの詳細については、「 安全なデプロイプラクティスを使用するための推奨事項」を参照してください。

プラットフォームが提供する検出メカニズムとメジャーを活用します。 たとえば、Azure Firewall はトラフィックを分析し、信頼されていない宛先への接続をブロックできます。 Azure には、分散型サービス拒否 (DDoS) 攻撃を検出して保護する方法も用意されています。

Azure ファシリテーション

Azure Monitor は、環境全体で可観測性を提供します。 構成なしで、ほとんどの Azure リソースからプラットフォーム メトリック、アクティビティ ログ、診断ログが自動的に取得されます。 アクティビティ ログには、詳細な診断情報と監査情報が表示されます。

注

プラットフォーム ログは無期限に使用できません。 監査目的やオフライン分析のために後で確認できるように、それらを保持する必要があります。 長期/アーカイブ ストレージには Azure ストレージ アカウントを使用します。 Azure Monitor で、リソースの診断設定を有効にする際の保持期間を指定します。

定義済みまたはカスタムのメトリックとログに基づいてアラートを設定し、特定のセキュリティ関連のイベントまたは異常が検出されたときに通知を取得します。

詳細については、 Azure Monitor のドキュメントを参照してください。

Microsoft Defender for Cloud には、脅威検出用の組み込み機能が用意されています。 収集されたデータに対して動作し、ログを分析します。 生成されるログの種類を認識しているため、組み込みのルールを使用して、情報に基づいた意思決定を行うことができます。 たとえば、侵害された可能性のある IP アドレスの一覧を確認し、アラートを生成します。

Azure リソースの組み込みの脅威保護サービスを有効にします。 たとえば、仮想マシン、データベース、コンテナーなどの Microsoft Defender for Azure リソースを有効にして、既知の脅威を検出して保護します。

Defender for Cloud には、すべてのワークロード リソースの脅威検出のためのクラウド ワークロード保護プラットフォーム (CWPP) 機能が用意されています。

詳細については、「 Microsoft Defender for Cloud とは」を参照してください。

Defender によって生成されたアラートは、SIEM システムに送ることもできます。 Microsoft Sentinel はネイティブ オファリングです。 AI と機械学習を使用して、セキュリティの脅威をリアルタイムで検出して対応します。 セキュリティ データの一元的なビューを提供し、プロアクティブな脅威の検出と調査を容易にします。

詳細については、「 Microsoft Sentinel とは」を参照してください。

Microsoft Sentinel では、さまざまなソースからの脅威インテリジェンス フィードを使用することもできます。 詳細については、「 Microsoft Sentinel での脅威インテリジェンス統合」を参照してください。

Microsoft Sentinel では、監視データからユーザーの動作を分析できます。 詳細については、「 Microsoft Sentinel のユーザーとエンティティの動作分析 (UEBA) を使用して高度な脅威を特定する」を参照してください。

機能が重複していても、Defender と Microsoft Sentinel は連携します。 このコラボレーションは、包括的な脅威の検出と対応を確実に行うことで、全体的なセキュリティ体制を強化します。

Azure Business Continuity Center を利用して、ビジネス継続性資産のギャップを特定し、ランサムウェア攻撃、悪意のあるアクティビティ、悪意のある管理者インシデントなどの脅威から防御します。 詳細については、「 Azure Business Continuity Center とは」を参照してください。

ネットワーク

ネットワーク デバイスから生のトラフィックを含むすべてのログを確認します。

  • 仮想ネットワーク フロー ログ。 フロー ログと診断ログを確認します。

  • Azure Network Watcher。 パケット キャプチャ機能を利用してアラートを設定し、パケット レベルでリアルタイムのパフォーマンス情報にアクセスできます。

    パケット キャプチャは、仮想マシンとの間のトラフィックを追跡します。 これを使用して、ネットワーク侵入に関する情報など、定義されたネットワーク異常に基づいてプロアクティブ キャプチャを実行できます。

    例については、「 パケット キャプチャを使用してアラートと Azure Functions を使用してネットワークを事前に監視する」を参照してください。

  • トラフィック分析を使用して、仮想ネットワーク フロー ログを分析して強化し、トラフィック フローに関する分析情報を表示します。 組み込みのクエリを使用すると、ブロックされたトラフィック、悪意のあるフロー、Azure インフラストラクチャ全体でインターネットに公開されているアクティブなポートに関する分析情報を取得できます。 トラフィック分析を使用して、セグメント化、トラフィック フローの可視性、異常または未承認のアクティビティの検出を有効にすることで、ゼロ トラスト セキュリティをサポートします。

  • AI を利用したセキュリティ機能を使用して、脅威の検出を改善します。 Azure Web Application Firewall と Microsoft Security Copilot の統合 により、Azure Front Door と Azure Application Gateway の両方から Web Application Firewall イベントに対して AI を利用した脅威分析と応答機能が提供されます。 また、Azure Firewall は Security Copilot と統合 され、侵入検出および防止システム (IDPS) 機能によって傍受された悪意のあるトラフィックを調査します。

アイデンティティ

侵害された可能性のある ID に対する ID 関連のリスク イベントを監視し、それらのリスクを修復します。 報告されたリスク イベントを次の方法で確認します。

Microsoft Entra ID は、アダプティブ 機械学習アルゴリズム、ヒューリスティック、既知の侵害された資格情報 (ユーザー名とパスワードのペア) を使用して、ユーザー アカウントに関連する疑わしいアクションを検出します。 これらのユーザー名とパスワードのペアは、パブリック Web とダーク Web を監視し、セキュリティ研究者、法執行機関、Microsoft のセキュリティ チームなどと協力して表示されます。

Azure Pipelines

DevOps では、継続的インテグレーションと継続的デリバリー (CI/CD) を使用したワークロードの変更管理を推進しています。 必ず、パイプラインにセキュリティ検証を追加してください。 Azure Pipelines のセキュリティ保護に関するページで説明されているガイダンスに従ってください。

セキュリティ チェックリスト

推奨事項の完全なセットを参照してください。

セキュリティ チェックリスト