次の方法で共有

監視と脅威検出に関する推奨事項

  • [アーティクル]

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

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

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

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

定義

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

主要な設計戦略

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

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

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

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

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

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

    これらのシナリオのどれが発生するかによって、爆発半径または影響範囲が大幅に異なる場合があります。

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

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

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

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

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

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

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

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

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

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

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

重要

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

ID とアクセスの監視

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

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

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

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

ネットワーク監視

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

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

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

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

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

相関ログを使用した一元化された脅威検出

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

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

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

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

コスト効率の高いオプションの一部は、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 リソースの組み込みの脅威保護サービスを有効にします。 たとえば、仮想マシン、データベース、コンテナーなどの Azure リソースのMicrosoft Defenderを有効にして、既知の脅威を検出して保護します。

Defender for Cloud は、すべてのワークロード リソースの脅威検出のためのクラウド ワークロード保護プラットフォーム (CWPP) 機能を提供します。

詳しくは、「Microsoft Defender for Cloud とは」をご覧ください。

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

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

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

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

機能が重複しているにもかかわらず、Defender と Microsoft Sentinel は連携して動作します。 このコラボレーションにより、包括的な脅威の検出と対応を保証することで、全体的なセキュリティ体制が強化されます。

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

ネットワーク

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

ID

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

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

Azure Pipelines

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

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

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

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