次の方法で共有

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

  • [アーティクル]

この Power Platform Well-Architected Security チェックリストのレコメンデーションに適用されます。

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

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

監視は、すべてのWell-Architectedの柱に適用される運用上の卓越性アプローチです。 Power Platform このガイドでは、セキュリティの観点からのみ推奨事項を提供します。 監視の一般的な概念については、監視システムの設計と作成に関する推奨事項で説明します。

定義

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

主要な設計戦略

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

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

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

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

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

    これらのシナリオのどれが発生するかによって、被害範囲や影響範囲は大きく異なる可能性があります。

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

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

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

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

データをキャプチャして活動の記録を残す

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

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

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

ワークロード ユーザー フロー

ワークロードは、イベントが発生したときに実行時の可視性を提供するように設計する必要があります。 ワークロード内の重要なポイントを特定し、これらのポイントのログ記録を確立します。 ユーザー特権のエスカレーションやユーザーが実行したアクション、ユーザーが安全なデータ ストアで機密情報にアクセスしたかどうかを認識することが重要です。 ユーザーおよびユーザー セッションの活動を追跡します。

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

重要

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

ID とアクセスの監視

アプリケーションのアクセス パターンとプラットフォーム リソースへの変更の詳細な記録を維持します。 攻撃者は ID を操作して不正アクセスを試みることが多いため、特に ID 関連の活動に対して、堅牢なアクティビティ ログと脅威検出のメカニズムを用意します。

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

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

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

ネットワーク監視

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

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

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

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

トレードオフ: すべてのネットワーク活動をログに記録すると、大量のデータが発生する可能性があります。残念ながら、有害イベントは発生した後にのみ識別できるため、それだけをキャプチャすることはできません。 キャプチャするイベントの種類と格納期間に関する戦略的な決定を行います。 注意しないと、データの管理が困難になる可能性があります。 また、データを保存するコストにもトレードオフがあります。

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

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

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

リソースがいつ作成され、いつ廃止されるかを追跡します。 この情報はプラットフォームから抽出する必要があります。 この情報は、リソース管理と説明責任に関する貴重な分析情報を提供します。

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

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

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

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

重要

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

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

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

これらの監視活動から収集されたデータは、完全に監視できるデータ シンクに保存する必要があります。データ シンクは、徹底的に検査、正規化、および関連付けることができます。 セキュリティ データは、システム自体のデータ ストアの外部に保存する必要があります。 監視しているシンクは、ローカライズされているか中央であるかに関係なく、データ ソースよりも長く存続する必要があります。 シンクは侵入検知システムのソースであるため、一時的なものであってはなりません。

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

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

相関ログによる集中型脅威検出

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

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

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

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

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

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

不正使用を検出する

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

セキュリティ強化のプラクティスを確認します。 監視は、環境を事前に強化するための代わりではありません。 領域が大きいほど、攻撃を受けやすくなります。 十分なプラクティスで制御を強化します。 たとえば、未使用のアカウントを検出して無効化し、IPファイアウォールを使用し、データ損失防止ポリシーで不要なエンドポイントをブロックします。

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

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

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

Power Platform の促進

次のセクションでは、Power Platform で脅威を監視および検出するために使用できるメカニズムについて説明します。

Microsoft Sentinel

Microsoft Power Platform 用 Microsoft Sentinel ソリューションを使用すると、顧客は次のようなさまざまな不審なアクティビティを検出できるようになります:

  • 未承認地域からの Power Apps の実行
  • Power Apps による不審なデータの破棄
  • Power Apps の一括削除
  • Power Apps を介したフィッシング攻撃
  • 退職者による Power Automate フロー活動
  • 環境に追加された Microsoft Power Platform コネクター
  • Microsoft Power Platform データ損失防止ポリシーの更新または削除

詳細情報については、Microsoft Power Platform のための Microsoft Sentinel ソリューションの概要 を参照してください。

Microsoft Purview のアクティビティ ログ記録

Power Apps、Power Automate コネクター、データ損失防止、Power Platform 管理アクティビティログは、Microsoft Purview コンプライアンス ポータルから追跡および表示されます。

詳細については、以下を参照してください。

Dataverse 監査

データベース監査では、Dataverse データベースの環境にある顧客レコードに対して加えられた変更をログに記録します。 Dataverse 監査は、環境のアプリまたは SDK を介したユーザー アクセスも記録します。 この監査は環境レベルで有効になっており、個々のテーブルと列ごとに追加の構成が必要です。 詳細については、「Dataverse 監査を管理する」を参照してください。

Application Insights を使用してテレメトリを分析する

Azure Monitor の機能である Application Insights は、エンタープライズ ランドスケープ内での監視と診断に広く使用されています。 特定のテナントまたは環境からすでに収集されたデータは、使用している Application Insights 環境にプッシュされます 。 データは Application Insights によって Azure Monitor ログに保存され、左のペインにある [調査] の下の [パフォーマンス] パネルと [失敗] パネルで視覚化されます。 データは、Application Insights によって定義された標準スキーマで、使用中の Application Insights 環境にエクスポートされます。 サポート、開発者、および管理者のペルソナは、この機能を使用して問題をトリアージして解決できます。

次のこともできます。

  • Application Insights 環境を設定して、Dataverse プラットホームで取得された診断とパフォーマンスに関するテレメトリを受信することができます。
  • アプリケーションが Dataverse データベースおよびモデル駆動型アプリ内で実行する操作に関するテレメトリを受信するように登録できます。 このテレメトリは、エラーとパフォーマンスに関連する問題の診断とトラブルシューティングに使用できる情報を提供します。
  • Application Insights と統合するように Power Automate クラウド フローを設定します。
  • Power Apps キャンバス アプリのイベントとアクティビティを Application Insights に書き込みます。

詳細については、Application Insights との統合の概要を参照してください。

ID

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

  • Microsoft Entra ID レポート機能を使用します。 詳細については、ID 保護とはと ID 保護を参照してください。

  • Identity Protection リスク検出 API メンバーを使用して、Microsoft Graph を使用してセキュリティ検出にプログラムでアクセスします。 詳細については、riskDetection と riskyUser を参照してください。

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

Azure Pipelines

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

参照

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

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

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