Azure Monitor と Microsoft Sentinel を使用する環境の多くは、Log Analytics ワークスペースが 1 つだけでもおそらく十分です。 しかし、多くの組織は、コストを最適化し、さまざまなビジネス要件をより適切に満たすため、複数のワークスペースを作成します。 この記事では、ワークスペースを 1 つだけ使用するか複数使用するかを決定するための一連の条件を示します。 また、要件を満たすと同時にコストを最適化できるようにこのワークスペースを構成して配置することについても説明します。
注
この記事には Azure Monitor と Microsoft Sentinel の両方についての説明が含まれています。多くのお客様は設計において、この両方を検討する必要があるからです。 決定の条件のほとんどは、両方のサービスに当てはまります。 これらのサービスの 1 つのみを使用する場合は、評価でもう一方を無視します。
次のビデオでは、Azure Monitor ログの基礎、ベスト プラクティス、およびデプロイに関する設計上の考慮事項について説明します。
設計戦略
設計を始めるときは常に、ワークスペースを 1 つだけとします。複数のワークスペースの管理と、そこからのデータに対するクエリ実行の複雑さを軽減するためです。 ワークスペース内のデータ量では、パフォーマンスの制限は課されません。 複数のサービスとデータ ソースから同じワークスペースにデータを送信できます。 より多くのワークスペースを作成するための条件を特定するときは、要件を満たすために、設計で使用するワークスペースの数を最も少なくする必要があります。
ワークスペース構成の設計作業には、複数の条件の評価が含まれます。 しかし、条件のいくつかが競合していることもあります。 たとえば、Azure リージョンごとに別のワークスペースを作成することでエグレス料金を減らせる可能性があります。 1 つのワークスペースに統合すると、コミットメント レベルを使用して料金をさらに減らせる可能性があります。 各条件を個別に評価します。 要件と優先順位を検討し、環境にとって最も効果的な設計を決定します。
設計基準
次の表に、ワークスペース アーキテクチャを設計するときに考慮すべき条件を示します。 その後の各セクションで、これらの条件について説明します。
| 条件 | 説明 |
|---|---|
| 運用データとセキュリティ データ | Azure Monitor からの運用データを Microsoft Sentinel からのセキュリティ データと同じワークスペースに結合するか、それぞれを独自のワークスペースに分離するかを選択できます。 それらを組み合わせると、すべてのデータの可視性が向上しますが、セキュリティ標準では、セキュリティ チームが専用のワークスペースを持つようにそれらを分離する必要がある場合があります。 また、各戦略でコストへの影響が発生する場合もあります。 |
| Microsoft Entra テナント | 複数のMicrosoft Entraテナントがある場合は、通常、それぞれに 1 つのワークスペースを作成します。 複数のデータ ソースは、同じMicrosoft Entra テナント内のワークスペースにのみ監視データを送信できます。 |
| 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 を 使用して、セキュリティ データを持つテーブルから特定のユーザーをブロックするか、 リソース コンテキストを使用してワークスペースへのアクセスをユーザーに制限します。
この構成により、コミットメント レベルに到達するのに役立つ場合、コスト削減につながる可能性があります。これにより、インジェスト料金が割引されます。 たとえば、運用データとセキュリティ データが 1 日あたり約 50 GB 取り込まれる組織があるとします。 データを同じワークスペース内でまとめると、100 GB/日のコミットメント レベルが可能になります。 このシナリオでは、Azure Monitor の 15% 割引と Microsoft Sentinel の 50% 割引を利用できます。
他の条件のために個別のワークスペースを作成する場合は、通常、ワークスペース ペアをさらに作成します。 たとえば、2 つのMicrosoft Entra テナントがある場合は、各テナントに運用ワークスペースとセキュリティ ワークスペースを持つ 4 つのワークスペースを作成できます。
- Azure Monitor と Microsoft Sentinel の両方を使用する場合: セキュリティ チームが必要とする場合、またはコスト削減につながる場合は、それぞれを専用のワークスペースに分離することを検討してください。 結合された監視データの可視性を向上させたり、コミットメント レベルに到達したりするのに役立つ場合は、この 2 つを組み合わせることを検討してください。
- Microsoft Sentinel と Microsoft Defender for Cloud の両方を使用する場合: セキュリティ データを 1 つの場所に保持するために、両方のソリューションに同じワークスペースを使うことを検討してください。
Microsoft Entra テナント
ほとんどのリソースは、同じ Microsoft Entra テナント内のワークスペースにのみ監視データを送信できます。 Azure Monitor Agent または Log Analytics エージェント を使用する仮想マシンは、個別のMicrosoft Entra テナント内のワークスペースにデータを送信できます。 このシナリオを検討するのは、サービス プロバイダーの場合です。
- 1 つのMicrosoft Entra テナントがある場合: そのテナントの 1 つのワークスペースを作成します。
- 複数のMicrosoft Entraテナントがある場合:テナントごとにワークスペースを作成します。 サービス プロバイダーの戦略など、その他のオプションについては、「複数のテナント戦略」を参照してください。
Azure リージョン
Log Analytics ワークスペースはそれぞれ、特定の Azure リージョンに存在します。 規制またはコンプライアンスの目的で、データを特定のリージョンに保持することが必要になる場合があります。 たとえば、多国籍企業が米国やヨーロッパなどの主要地理的リージョンのそれぞれにワークスペースを配置します。
- データを特定の地域内に保持する要件がある場合: そのような要件を持つリージョンごとに個別のワークスペースを作成します。
- データを特定の地域内に保持する要件がない場合: 1 つのワークスペースをすべてのリージョンに使用します。
ワークスペースのリージョンの外部にある地域またはリージョンにデータを送信する場合、送信リソースが Azure : データと同じ地理的またはリージョン内のワークスペースを使用することを検討してください。
また、ワークスペースに別のリージョンのリソースからデータが送信されるときに適用される可能性のある 帯域幅料金も考慮してください。 通常、これらの料金は、ほとんどのお客様にとってはデータ インジェストのコストに比べると軽微です。 これらの料金は一般的に、ワークスペースに仮想マシンからデータが送信された結果として発生します。 診断設定を使用して他の Azure リソースからのデータを監視するときは、エグレス料金は発生しません。
Azure 価格計算ツールを使用してコストを見積もり、どのリージョンが必要かを特定します。 帯域幅の料金が大きい場合は、複数のリージョンのワークスペースを検討してください。
- 帯域幅料金が十分に高額であるため、複雑さを増すことが正当化される場合: 仮想マシンを使用するリージョンごとに個別のワークスペースを作成します。
- 帯域幅料金がそれほど高額ではなく、複雑さを増すことが正当化されない場合: 1 つのワークスペースをすべてのリージョンに使用します。
データ所有権
所有権に基づいてデータを分離する、または境界を定義するという要件が存在する場合があります。 たとえば、さまざまな子会社または関連会社があり、それぞれの監視データの間に線引きが必要な場合です。
- データの分離が必要な場合: データ所有者ごとに個別のワークスペースを使用します。
- データの分離を必要としない場合: 1 つのワークスペースをすべてのデータ所有者に使用します。
課金の分割
課金を複数の関係者間で分割することや、顧客または内部事業単位へのチャージバックを実行することが必要になる場合があります。 Microsoft Cost Management + Billing ワークスペース別の料金が表示されます。 ログ クエリでは、Azure リソース、リソース グループ、またはサブスクリプションごとの課金対象データ量を表示することもできます。 この方法で、おそらく課金に関する要件は満たされます。
- 課金の分割やチャージバックの実行が必要ない場合: 1 つのワークスペースをすべてのコスト所有者に使用します。
- 課金を分割するか、請求を元に戻す必要がある場合:Microsoft Cost Management + 請求またはログ クエリによって、要件に十分な詳細なコスト レポートが提供されるかどうかを検討します。 そうでない場合は、コスト所有者ごとに個別のワークスペースを使用します。
データの保持
ワークスペースの既定の データ保持設定 を構成するか、 テーブルごとに異なる設定を構成します。 Azure ポータルで、Log Analytics ワークスペース> ワークスペース >Tables に移動して、テーブルごとの保持期間を表示および変更します。 特定のテーブル内のデータのセットごとに異なる設定が必要になる場合があります。 その場合は、そのデータを異なるワークスペースに分割し、それぞれ固有の保持設定を使用します。
- 各テーブルのすべてのデータに対して同じ保持設定が機能する場合: すべてのリソースに 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 の両方には、ワークスペース間でこのデータを分析するのに役立つ機能が含まれています。 詳細については、以下を参照してください:
各ワークスペースに名前を付ける場合は、各ワークスペースの目的を簡単に識別できるように、わかりやすいインジケーターを名前に含めます。
マルチ テナント戦略
多くの場合、複数のMicrosoft Entra テナントを持つ組織では、テナントの境界を越えてワークスペースを管理するための戦略が必要です。 一般的なマルチテナント シナリオは次のとおりです。
- サービス プロバイダー: 個別のテナント内の顧客に代わってワークスペースを管理する MSP、MSP、ISV。
- 企業の合併と買収: 統合中または統合後に個別のテナントを保持する子会社または買収企業。
- 環境の分離: 開発、ステージング、運用環境に個別のテナントを使用する組織。
各シナリオでは、中央管理チームは通常、他のテナントにあるワークスペースにアクセスする必要があります。 各テナントは、個別の顧客、部署、または環境ステージを表す場合があります。
注
クラウド ソリューション プロバイダー (CSP) プログラムに参加しているパートナーやサービス プロバイダーにとって、Azure Monitor の Log Analytics は Azure CSP サブスクリプションで使用できる Azure サービスの 1 つです。
この機能に関する 2 つの基本的な戦略について、次の各セクションで説明します。
分散アーキテクチャ
分散アーキテクチャでは、Log Analytics ワークスペースが各Microsoft Entra テナントに作成されます。 このオプションは、仮想マシン以外のサービスAzure監視に使用できる唯一のオプションです。
サービス プロバイダー管理者は、次の 2 つのオプションを使用して、顧客テナント内のワークスペースにアクセスできます。
- Azure Lighthouse を使用して各顧客テナントにアクセスします。 サービス プロバイダーの管理者は、サービス プロバイダーのテナント内の Microsoft Entra ユーザー グループの 1 つに含まれています。 このグループには、各顧客のオンボード プロセス中のアクセスが許可されます。 これで、管理者はサービス プロバイダー自身のテナント内から各顧客のワークスペースにアクセスできます。つまり、各顧客のテナントに個別にログインする必要はありません。 詳細については、顧客のリソースの大規模な監視に関する記事をご覧ください。
- サービス プロバイダーからの個々のユーザーを Microsoft Entra ゲスト ユーザー (B2B) として追加します。 顧客テナントの管理者が、各サービス プロバイダー管理者の個別のアクセスを管理します。 サービス プロバイダーの管理者がこれらのワークスペースにアクセスするには、Azure portal で各テナントのディレクトリにサインインする必要があります。
この戦略の利点は次のとおりです。
- ログは、リソースのすべてのタイプから収集できます。
- 顧客は、Azure の委任されたリソース管理を使用して特定のレベルのアクセス許可を確認できます。 または、顧客が自身の Azure RBAC を使用してログへのアクセスを管理できます。
- 顧客ごとに異なるワークスペース設定 (保有期間やデータ上限など) が可能です。
- 顧客間の隔離は、規制やコンプライアンスを目的としています。
- 各ワークスペースの料金は顧客のサブスクリプションの請求書に含まれます。
この戦略の欠点は次のとおりです。
- 多数のワークスペースに対するクエリの実行は遅く、100 を超えるワークスペースにスケーリングすることはできません。 中央の視覚化とデータ分析レイヤーは可能ですが、数十を超えるワークスペースが存在する場合は遅くなります。 この状況は、すべてのワークスペースが同じ専用クラスターに併置されている場合は、それほど深刻ではありません。 詳細については、「 ワークスペース間でクエリを実行する」を参照してください。
- Azure の委任されたリソース管理に顧客がオンボードしていない場合は、サービス プロバイダーの管理者が顧客のディレクトリ内でプロビジョニングされている必要があります。 この要件があるため、サービス プロバイダーが多数の顧客テナントを一度に管理することが困難になります。
- ワークスペースでクエリを実行する場合、ワークスペース管理者がクエリ監査でクエリのテキスト全体を表示できる可能性があります。
一元化
サービス プロバイダーのサブスクリプションに 1 つのワークスペースが作成されます。 このオプションでは、診断設定に基づいて、顧客の仮想マシンと Azure PaaS サービスからのデータを収集できます。 仮想マシンにインストールされたエージェントと PaaS サービスは、ログをこの中央ワークスペースに送信するように構成できます。
この戦略の利点は次のとおりです。
- サービス プロバイダーは、1 つのワークスペースから多数の顧客を管理します。
- サービス プロバイダーがログとさまざまな成果物 (関数や保存クエリなど) に対する完全な所有権を持ちます。
- サービス プロバイダーが、担当する顧客すべての分析を実行できます。
この戦略の欠点は次のとおりです。
- ログは、エージェントがある仮想マシンまたは Azure PaaS サービスからのみ収集できます (Azure Lighthouse の委任を介して)。 SaaS コネクタまたは Azure Service Fabric のデータ ソースでは機能しません。
- データを顧客別に分離することが困難な場合があります。複数の顧客のデータで 1 つのワークスペースが共有されるからです。 クエリでコンピューターの完全修飾ドメイン名または Azure サブスクリプション ID を使用する必要があります。
- すべての顧客からのすべてのデータが同じリージョンに格納され、請求書は 1 件だけで、保持および構成の設定も同じです。
ハイブリッド
ハイブリッド モデルでは、各テナントに専用のワークスペースがあります。 あるメカニズムを使用してデータが 1 つの中央の場所にプルされ、レポートと分析に使用されます。 このデータには、少数のデータ型が含まれることもあれば、日次統計などのアクティビティの要約のこともあります。
一元的な場所にログを実装するためのオプションがいくつかあります。
-
中央ワークスペース: サービス プロバイダーは、テナントに 1 つのワークスペースを作成し、次を使用してさまざまなワークスペースからデータをプルします。
- テナント ワークスペースから中央ワークスペースにデータを送信するためにログ インジェスト API と共にクエリ API を使用するスクリプト。
- 中央ワークスペースにデータをコピーするための Azure Logic Apps。
- ソース ワークスペースからのデータ エクスポートと、中央ワークスペースへの再インジェスト。 サマリー ルール には別のアプローチが用意されています。元のワークスペースから中央ワークスペースにキー データの集計をエクスポートします。
- Power BI: Log Analytics ワークスペースと Power BI の統合を使用して、テナント ワークスペースから Power BI にデータをエクスポートします。
次のステップ
- ワークスペースでのデータ アクセスの設計と構成についてさらに学びます。
- Microsoft Sentinel のサンプル ワークスペース アーキテクチャを取得します。
- ワークスペースの構成方法についてさらに詳しく知るには、ITOps Talk: Log Analytics ワークスペース設計の詳細解説をご覧ください。