次の方法で共有

Log Analytics ワークスペース アーキテクチャを設計する

  • [アーティクル]

Azure Monitor と Microsoft Sentinel を使用する環境の多くは、Log Analytics ワークスペースが 1 つだけでもおそらく十分です。 しかし、多くの組織は、コストを最適化し、さまざまなビジネス要件をより適切に満たすため、複数のワークスペースを作成します。 この記事では、ワークスペースを 1 つだけ使用するか複数使用するかを決定するための一連の条件を示します。 また、要件を満たすと同時にコストを最適化できるようにこのワークスペースを構成して配置することについても説明します。

注意

この記事には Azure Monitor と Microsoft Sentinel の両方についての説明が含まれています。多くのお客様は設計において、この両方を検討する必要があるからです。 決定の条件のほとんどは、両方のサービスに当てはまります。 これらのサービスの一方のみを使用する場合は、評価時に他方を無視してください。

この動画では、Azure Monitor Logs の基本事項、ベスト プラクティス、および Azure Monitor Logs のデプロイを設計する際の設計上の考慮事項について説明しています。

設計戦略

設計を始めるときは常に、ワークスペースを 1 つだけとします。複数のワークスペースの管理と、そこからのデータに対するクエリ実行の複雑さを軽減するためです。 ワークスペース内のデータの量に由来するパフォーマンスの制限はありません。 複数のサービスとデータ ソースから同じワークスペースにデータを送信できます。 作成するワークスペースの数を増やす条件が明らかになった場合、設計では要件を満たす最小限の数のワークスペースを使う必要があります。

ワークスペース構成の設計作業には、複数の条件の評価が含まれます。 しかし、条件のいくつかが競合していることもあります。 たとえば、Azure リージョンごとに別のワークスペースを作成することでエグレス料金を減らせる可能性があります。 1 つのワークスペースに統合すると、コミットメント レベルを使用して料金をさらに減らせる可能性があります。 各条件を個別に評価します。 要件と優先順位を検討し、環境にとって最も効果的な設計を決定します。

設計基準

次の表に、ワークスペース アーキテクチャを設計するときに考慮すべき条件を示します。 その後の各セクションで、これらの条件について説明します。

条件 説明
運用データとセキュリティ データ Azure Monitor からの運用データを Microsoft Sentinel からのセキュリティ データと同じワークスペースに結合するか、それぞれを独自のワークスペースに分離するかを選択できます。 それらを組み合わせると、すべてのデータの可視性が向上しますが、セキュリティ標準では、セキュリティ チームが専用のワークスペースを持つようにそれらを分離する必要がある場合があります。 また、各戦略でコストへの影響が発生する場合もあります。
Azure テナント 複数の Azure テナントがある場合は、通常、それぞれにワークスペースを作成します。 多くのデータ ソースは、同じ Azure テナント内のワークスペースにのみ監視データを送信できます。
Azure リージョン 各ワークスペースは、特定の Azure リージョンに存在します。 特定の場所にデータを格納することを求める規制またはコンプライアンス要件が存在する場合があります。
データ所有権 データ所有権を定義するために別々のワークスペースを作成することもできます。 たとえば、子会社や関連会社別にワークスペースを作成します。
課金を分割する 個別のサブスクリプションにワークスペースを配置することにより、異なるパーティに課金できます。
データ保持 ワークスペース内のワークスペースおよびテーブルごとに異なる保持設定を設定できます。 同じテーブルにデータを送信するリソースごとに異なる保持設定が必要な場合は、個別のワークスペースが必要です。
コミットメント レベル コミットメント レベルを使用すると、1 つのワークスペース内の最小量の日次データにコミットすることで、インジェスト コストを削減できます。
レガシ エージェントの制限事項 従来の仮想マシン エージェントには、接続できるワークスペースの数に制限があります。
データのアクセスの制御 ワークスペースへのアクセスと、さまざまなリソースの異なるテーブルとデータへのアクセスを構成します。
回復力 あるリージョンで障害が発生した場合にワークスペース内のデータを使用できるようにするために、異なるリージョンの複数のワークスペースにデータを取り込むことができます。

運用データとセキュリティ データ

Azure Monitor のオペレーショナル データと Microsoft Sentinel のセキュリティ データを同じワークスペースに結合するか、それぞれを独自のワークスペースに分離するかは、セキュリティ要件と環境における潜在的なコストへの影響によって決まります。

専用ワークスペース Azure Monitor と Microsoft Sentinel 用の専用ワークスペースを作成すると、運用チームとセキュリティ チームの間でデータの所有権を分離できます。 このアプローチは、コストの最適化にも役立つ場合があります。あるワークスペースで Microsoft Sentinel が有効になっている場合は、そのワークスペース内のすべてのデータが Sentinel の価格の対象となるためです。Azure Monitor によって収集された運用データであったとしてもです。

Microsoft Sentinel を使用するワークスペースでは、無料データ保持期間が 31 日ではなく 3 か月となります。 このシナリオでは一般的に、Microsoft Sentinel を使用しないワークスペース内の運用データのコストが上昇します。 「Azure Monitor ログの料金の詳細」を参照してください。

結合されたワークスペース 同じワークスペースで Azure Monitor と Microsoft Sentinel からのデータを組み合わせると、すべてのデータの可視性が向上し、クエリとブックで両方を簡単に組み合わせることができます。 セキュリティ データへのアクセスを特定のチームに制限する必要がある場合は、テーブル レベルの RBAC を使用して、セキュリティ データを含むテーブルから特定のユーザーをブロックしたり、resource-context を使用してユーザーがワークスペースにアクセスできるように制限したりできます。

この構成により、コミットメント レベルに到達するのに役立つ場合、コスト削減につながる可能性があります。これにより、インジェスト料金が割引されます。 たとえば、運用データとセキュリティ データが 1 日あたり約 50 GB 取り込まれる組織があるとします。 データを同じワークスペース内でまとめると、100 GB/日のコミットメント レベルが可能になります。 このシナリオでは、Azure Monitor の 15% 割引と Microsoft Sentinel の 50% 割引を利用できます。

他の条件のために個別のワークスペースを作成する場合は、通常、ワークスペース ペアをさらに作成します。 たとえば、2 つの Azure テナントがある場合は、4 つのワークスペース (各テナントに運用ワークスペースとセキュリティ ワークスペース) を作成します。

  • Azure Monitor と Microsoft Sentinel の両方を使用する場合: セキュリティ チームが必要とする場合、またはコスト削減につながる場合は、それぞれを専用のワークスペースに分離することを検討してください。 結合された監視データの可視性を向上させたり、コミットメント レベルに到達したりするのに役立つ場合は、この 2 つを組み合わせることを検討してください。
  • Microsoft Sentinel と Microsoft Defender for Cloud の両方を使用する場合: セキュリティ データを 1 つの場所に保持するために、両方のソリューションに同じワークスペースを使うことを検討してください。

Azure テナント

ほとんどのリソースは、同じ Azure テナント内のワークスペースにのみ監視データを送信できます。 Azure Monitor エージェントまたは Log Analytics エージェントを使用する仮想マシンからは、それぞれ別の Azure テナントにある複数のワークスペースにデータを送信できます。 このシナリオを検討するのは、サービス プロバイダーの場合です。

  • Azure テナントが 1 つだけの場合: そのテナント用のワークスペースを 1 つだけ作成します。
  • 複数の Azure テナントがある場合: テナントごとにワークスペースを作成します。 サービス プロバイダーの戦略など、その他のオプションについては、「複数のテナント戦略」を参照してください。

Azure Azure リージョン

Log Analytics ワークスペースはそれぞれ、特定の Azure リージョンに存在します。 規制またはコンプライアンスの目的で、データを特定のリージョンに保持することが必要になる場合があります。 たとえば、多国籍企業が米国やヨーロッパなどの主要地理的リージョンのそれぞれにワークスペースを配置します。

  • データを特定の地域内に保持する要件がある場合: そのような要件を持つリージョンごとに個別のワークスペースを作成します。
  • データを特定の地域内に保持する要件がない場合: 1 つのワークスペースをすべてのリージョンに使用します。
  • 送信リソースが Azure に存在するかどうかに関わらず、ワークスペースのリージョンの外部にある地域またはリージョンにデータを送信する場合: データと同じ地域またはリージョンのワークスペースを使用することを検討してください。

また、ワークスペースに別のリージョンのリソースからデータが送信されるときに適用される可能性のある 帯域幅料金も考慮してください。 通常、これらの料金は、ほとんどのお客様にとってはデータ インジェストのコストに比べると軽微です。 これらの料金は一般的に、ワークスペースに仮想マシンからデータが送信された結果として発生します。 診断設定を使用して他の Azure リソースからのデータを監視するときは、エグレス料金は発生しません。

Azure 価格計算ツールを使用してコストを見積もり、どのリージョンが必要かを特定します。 帯域幅の料金が大きい場合は、複数のリージョンのワークスペースを検討してください。

  • 帯域幅料金が十分に高額であるため、複雑さを増すことが正当化される場合: 仮想マシンを使用するリージョンごとに個別のワークスペースを作成します。
  • 帯域幅料金がそれほど高額ではなく、複雑さを増すことが正当化されない場合: 1 つのワークスペースをすべてのリージョンに使用します。

データ所有権

所有権に基づいてデータを分離する、または境界を定義するという要件が存在する場合があります。 たとえば、さまざまな子会社または関連会社があり、それぞれの監視データの間に線引きが必要な場合です。

  • データの分離が必要な場合: データ所有者ごとに個別のワークスペースを使用します。
  • データの分離を必要としない場合: 1 つのワークスペースをすべてのデータ所有者に使用します。

課金を分割する

課金を複数の関係者間で分割することや、顧客または内部事業単位へのチャージバックを実行することが必要になる場合があります。 Azure Cost Management + Billing を使用すると、ワークスペース別の料金を見ることができます。 また、ログ クエリを使用して課金対象のデータ ボリュームを Azure リソース、リソース グループ、またはサブスクリプション別に見ることもできます。 この方法で、おそらく課金に関する要件は満たされます。

  • 課金の分割やチャージバックの実行が必要ない場合: 1 つのワークスペースをすべてのコスト所有者に使用します。
  • 課金の分割またはチャージバックの実行が必要である場合: 要件を満たす詳細さのコスト レポートが Azure Cost Management + Billing またはログ クエリによって提供されるかどうかを検討してください。 そうでない場合は、コスト所有者ごとに個別のワークスペースを使用します。

データの保持

ワークスペースに対して既定のデータ保有設定を構成することも、テーブルごとに異なる設定を構成することもできます。 特定のテーブル内のデータのセットごとに異なる設定が必要になる場合があります。 これに該当する場合は、そのデータを複数のワークスペースに分割し、それぞれに独自の保持設定を使用する必要があります。

  • 各テーブル内のすべてのデータに同じデータ保有設定を使用できる場合: すべてのリソースに 1 つのワークスペースを使います。
  • 同じテーブル内のリソースごとに異なる保有設定が必要な場合: 異なるリソースごとに個別のワークスペースを使います。

コミットメント レベル

コミットメント レベルを利用すると、指定の 1 日当たりのデータ量を確約した場合にワークスペース インジェスト コストの割引を受けることができます。 特定のレベルに到達するためにデータを 1 つのワークスペースに統合することを選択できます。 同じ量のデータが複数のワークスペースに分散している場合は、同じレベルの対象にはなりません (専用クラスターがある場合を除きます)。

1 日あたり 100 GB 以上のインジェストをコミットできる場合は、追加の機能とパフォーマンスが提供される専用クラスターを実装します。 また、専用クラスターを使用すると、クラスター内の複数のワークスペースのデータを結合して、コミットメント レベルに到達することもできます。

  • 全リソース合計で少なくとも 1 日当たり 100 GB を取り込む場合: 専用クラスターを作成して適切なコミットメント レベルを設定します。
  • 全リソース合計で少なくとも 1 日当たり 100 GB を取り込む場合: コミットメント レベルを活用するためにこれらを 1 つのワークスペースにまとめることを検討してください。

レガシ エージェントの制限事項

重複するデータを複数のワークスペースに送信することは、追加料金が発生するため避ける必要がありますが、仮想マシンが複数のワークスペースに接続されていることもあります。 最も一般的なシナリオは、Azure Monitor と Microsoft Sentinel 用の個別のワークスペースに接続されたエージェントです。

Azure Monitor エージェントと Windows 用の Log Analytics エージェントは、複数のワークスペースに接続できます。 Linux 用の Log Analytics エージェントは、1 つのワークスペースにしか接続できません。

  • Linux 用 Log Analytics エージェントを使用する場合:Azure Monitor エージェントに移行します。または、Linux マシンからのアクセスが必要であるワークスペースが確実に 1 つだけとなるようにします。

データのアクセスの制御

ユーザーにワークスペースへのアクセス権を付与すると、そのユーザーはそのワークスペース内のすべてのデータにアクセスできます。 このアクセス権は、すべてのリソースのデータにアクセスする必要がある中央管理またはセキュリティのチームのメンバーに適しています。 ワークスペースへのアクセスは、リソース コンテキスト ロールベースのアクセス制御 (RBAC) とテーブル レベルの RBAC によっても決定されます。

リソース コンテキスト RBAC: 既定では、ある Azure リソースへの読み取りアクセス権を持つユーザーは、ワークスペースに送信されるそのリソースの監視データへのアクセス許可を継承します。 このレベルのアクセス権が付与されることで、ユーザーはワークスペースへのアクセス権が明示的に付与されていなくても、自分が管理するリソースに関する情報にアクセスできます。 このアクセスをブロックする必要がある場合は、明示的なワークスペースのアクセス許可を要求するようにアクセス制御モードを変更できます。

  • ユーザーが各自のリソースのデータにアクセスできるようにする場合: 既定のアクセス制御モードである [リソースまたはワークスペースのアクセス許可を使用] を維持します。
  • すべてのユーザーに明示的にアクセス許可を割り当てる場合: アクセス制御モードを [ワークスペースのアクセス許可が必要] に変更します。

テーブル レベルの RBAC: テーブル レベルの RBAC を使用すると、ワークスペース内の特定のテーブルへのアクセスを許可または拒否できます。 この方法で、環境内の特定の状況に必要となる詳細なアクセス許可を実装できます。

たとえば、Microsoft Sentinel によって収集された特定のテーブルのみへのアクセス権を内部監査チームに付与します。 あるいは、自分のリソースに関連する運用データを必要としているリソース所有者について、セキュリティ関連テーブルへのアクセスを拒否します。

  • テーブル別の詳細なアクセス制御が必要ない場合: 運用チームとセキュリティ チームにそれぞれのリソースへのアクセス権を付与し、リソース所有者には自分のリソースに対するリソース コンテキスト RBAC の使用を許可します。
  • テーブル別の詳細なアクセス制御が必要な場合: テーブルレベルの RBAC を使用して、特定のテーブルへのアクセスを許可または拒否します。

詳細については、「リソースによる Microsoft Sentinel データへのアクセスを管理する」を参照してください。

回復力

あるリージョンで障害が発生した場合にワークスペース内の重要なデータを使用できるようにするために、異なるリージョンの複数のワークスペースにデータの一部またはすべてを取り込むことができます。

このオプションでは、ワークスペースごとに個別に他のサービスや製品との統合を管理する必要があります。 障害が発生した場合は代替ワークスペースのデータを使用できますが、アラートやブックなど、そのデータに依存するリソースでは、その代替ワークスペースに切り替えることがわかりません。 重要なリソースの ARM テンプレートは、Azure DevOps の代替ワークスペースの構成と一緒に保存するか、フェールオーバー シナリオですぐに有効にできる無効なポリシーとして保存することを検討してください。

複数のワークスペースの作業を行う

多くのデザインには、複数のワークスペースが含まれています。 たとえば、中央セキュリティ オペレーション チームは、独自の Microsoft Sentinel ワークスペースを使用して、分析ルールやブックなどの一元化された成果物を管理できます。

Azure Monitor と Microsoft Sentinel の両方には、ワークスペース間でこのデータを分析するのに役立つ機能が含まれています。 詳細については、以下を参照してください:

各ワークスペースに名前を付ける場合は、各ワークスペースの目的を簡単に識別できるように、わかりやすいインジケーターを名前に含めることをお勧めします。

複数のテナント戦略

複数の Azure テナントを持つ環境、たとえば Microsoft サービス プロバイダー (MSP)、独立系ソフトウェア ベンダー (ISV)、大規模エンタープライズ企業では多くの場合、中央管理チームに、他のテナントにあるワークスペースを管理するためのアクセス権を持たせるという戦略が必要になります。 各テナントは、それぞれ異なる顧客を表すこともあれば、異なる事業単位を表すこともあります。

注意

クラウド ソリューション プロバイダー (CSP) プログラムに参加しているパートナーやサービス プロバイダーにとって、Azure Monitor の Log Analytics は Azure CSP サブスクリプションで使用できる Azure サービスの 1 つです。

この機能に関する 2 つの基本的な戦略について、次の各セクションで説明します。

分散アーキテクチャ

分散アーキテクチャでは、Log Analytics ワークスペースが各 Azure テナントに作成されます。 これは、仮想マシン以外の Azure サービスを監視する場合に使用できる唯一のオプションです。

サービス プロバイダーの管理者が顧客テナント内のワークスペースにアクセスできるようにするには、次の 2 つのオプションがあります。

  • Azure Lighthouse を使用して各顧客テナントにアクセスします。 サービス プロバイダーの管理者は、サービス プロバイダーのテナント内の Microsoft Entra ユーザー グループの 1 つに含まれています。 このグループには、各顧客のオンボード プロセス中のアクセスが許可されます。 これで、管理者はサービス プロバイダー自身のテナント内から各顧客のワークスペースにアクセスできます。つまり、各顧客のテナントに個別にログインする必要はありません。 詳細については、顧客のリソースの大規模な監視に関する記事をご覧ください。
  • サービス プロバイダーからの個々のユーザーを Microsoft Entra ゲスト ユーザー (B2B) として追加します。 顧客テナントの管理者が、各サービス プロバイダー管理者の個別のアクセスを管理します。 サービス プロバイダーの管理者がこれらのワークスペースにアクセスするには、Azure portal で各テナントのディレクトリにサインインする必要があります。

この戦略の利点は次のとおりです。

  • ログは、リソースのすべてのタイプから収集できます。
  • 顧客は、Azure の委任されたリソース管理を使用して特定のレベルのアクセス許可を確認できます。 または、顧客が自身の Azure RBAC を使用してログへのアクセスを管理できます。
  • 顧客ごとに異なるワークスペース設定 (保有期間やデータ上限など) が可能です。
  • 規制やコンプライアンスについて顧客間で分離します。
  • 各ワークスペースの料金は顧客のサブスクリプションの請求書に含まれます。

この戦略の欠点は次のとおりです。

  • 複数の顧客テナントを対象としてデータの視覚化と分析を一元的に、Azure Monitor ブックなどのツールを使用して行うときに、処理速度が低下する場合があります。 特に、50 を超えるワークスペースのデータをまとめて分析するときです。
  • Azure の委任されたリソース管理に顧客がオンボードしていない場合は、サービス プロバイダーの管理者が顧客のディレクトリ内でプロビジョニングされている必要があります。 この要件があるため、サービス プロバイダーが多数の顧客テナントを一度に管理することが困難になります。

一元化

サービス プロバイダーのサブスクリプションに 1 つのワークスペースが作成されます。 このオプションでは、顧客の仮想マシンからのみデータを収集できます。 仮想マシンにインストールされたエージェントは、ログをこの中央ワークスペースに送信するように構成されます。

この戦略の利点は次のとおりです。

  • 多数の顧客の管理が簡単です。
  • サービス プロバイダーがログとさまざまな成果物 (関数や保存クエリなど) に対する完全な所有権を持ちます。
  • サービス プロバイダーが、担当する顧客すべての分析を実行できます。

この戦略の欠点は次のとおりです。

  • ログは、エージェントがある仮想マシンからのみ収集できます。 PaaS、SaaS、または Azure Service Fabric のデータ ソースでは機能しません。
  • データを顧客別に分離することが困難な場合があります。複数の顧客のデータで 1 つのワークスペースが共有されるからです。 クエリでコンピューターの完全修飾ドメイン名または Azure サブスクリプション ID を使用する必要があります。
  • すべての顧客からのすべてのデータが同じリージョンに格納され、請求書は 1 件だけで、保持および構成の設定も同じです。

ハイブリッド

ハイブリッド モデルでは、各テナントに専用のワークスペースがあります。 あるメカニズムを使用してデータが 1 つの中央の場所にプルされ、レポートと分析に使用されます。 このデータには、少数のデータ型が含まれることもあれば、日次統計などのアクティビティの要約のこともあります。

ログを中央の場所に実装するには 2 つの方法があります。

  • 中央ワークスペース: サービス プロバイダーが自身のテナント内にワークスペースを作成し、スクリプトでクエリ API をログ インジェスト API と共に利用してテナントのワークスペースからのデータをこの中央の場所に取り込みます。 もう 1 つのオプションは、Azure Logic Apps を使用して中央ワークスペースにデータをコピーすることです。
  • Power BI: Log Analytics ワークスペースと Power BI の統合を使用して、テナント ワークスペースから Power BI にデータをエクスポートします。

次のステップ