Azure Monitor ログのデプロイの設計

Azure Monitor では、ログ データが Log Analytics ワークスペースに格納されます。Log Analytics ワークスペースは Azure リソースであり、データが収集、集計され、管理境界として機能するコンテナーです。 1 つまたは複数のワークスペースを Azure サブスクリプションにデプロイできますが、組織のニーズを満たす、コスト効率に優れ、管理可能で、スケーラブルなデプロイを実現するためのガイドラインに初期のデプロイが従っていることを確認するために、理解しておく必要がある考慮事項がいくつかあります。

ワークスペース内のデータがテーブルに整理されます。それぞれのテーブルにはさまざまな種類のデータが格納され、データを収集しているリソースに基づく独自かつ一意のプロパティ セットがあります。 ほとんどのデータ ソースでは、Log Analytics ワークスペース内の独自のテーブルに書き込みます。

ワークスペース データ モデルの例

Log Analytics ワークスペースには次の情報が示されます。

ワークスペースは、物理クラスターでホストされます。 既定で、システムによってこれらのクラスターが作成され管理されています。 4 TB/日以上を取り込むユーザーは、ワークスペース用の独自の専用クラスターを作成することが期待されます。これにより、制御の強化とインジェスト レートの向上を実現できます。

この記事では、設計と移行に関する考慮事項の詳しい概要、アクセス制御の概要、および IT 組織に推奨される設計の実装について説明します。

アクセス制御戦略に関する重要な考慮事項

必要なワークスペース数の特定は、次の要件の 1 つまたは複数の影響を受けます。

  • 世界規模の企業が、データ主権またはコンプライアンス上の理由から特定のリージョンにログ データを格納する必要がある。
  • Azure を使用しているときに、管理対象の Azure リソースと同じリージョンにワークスペースを配置することによって送信データ転送の料金が生じるのを回避したい。
  • 複数の部門またはビジネス グループを管理しており、各部門やビジネス グループが他からのデータではなく各自のデータを確認できるようにしたい。 また、統合された部門間ビューやビジネス グループ ビューに関するビジネス要件はない。

現在、IT 組織は、一元化構造、分散型構造、または両方の構造のハイブリッドに従ってモデル化されています。 その結果、これらの組織構造のいずれかにマップするために、次のワークスペース デプロイ モデルが一般的に使用されています。

  • 一元化:すべてのログが中央ワークスペースに格納され、1 つのチームによって管理されます。Azure Monitor によって、チームごとに差別化されたアクセスが提供されます。 このシナリオでは、管理、リソース間の検索、ログの相互関連付けが簡単です。 サブスクリプション内の複数のリソースから収集されるデータの量によっては、ワークスペースが大幅に増加する可能性があります。また、異なるユーザーに対するアクセス制御を維持するための管理オーバーヘッドも追加されます。 このモデルは、"ハブ アンド スポーク" と呼ばれます。
  • 分散型:各チームが所有して管理するリソース グループ内に独自のワークスペースが作成され、ログ データはリソースごとに分離されます。 このシナリオでは、ワークスペースをセキュリティで保護し、アクセス制御とリソース アクセスの一貫性を保つことができますが、ログを相互に関連付けることは困難です。 多くのリソースを広範囲に表示する必要があるユーザーは、意味のある方法でデータを分析できません。
  • ハイブリッド:多くの組織が両方のデプロイ モデルを並行して実装するため、セキュリティ監査コンプライアンス要件によってこのシナリオがさらに複雑になります。 これにより、多くの場合、ログ カバレッジにギャップがある、複雑でコストが高く、保守が困難な構成になります。

Log Analytics エージェントを使用してデータを収集している場合は、エージェントのデプロイを計画するために次のことを理解しておく必要があります。

  • Windows エージェントからデータを収集するには、1 つまたは複数のワークスペースにレポートするように各エージェントを構成できます。これは、System Center Operations Manager 管理グループにレポートしている場合でも同様です。 Windows エージェントでは、最大 4 つのワークスペースを報告できます。
  • Linux エージェントでは、マルチホームがサポートされず、1 つのワークスペースにしかレポートできません。

System Center Operations Manager 2012 R2 以降を使用している場合:

  • 各 Operations Manager 管理グループは、1 つのワークスペースにのみ接続できます。
  • 管理グループにレポートしている Linux コンピューターは、Log Analytics ワークスペースに直接レポートするように構成する必要があります。 Linux コンピューターが既にワークスペースに直接レポートしており、それらを Operations Manager で監視する場合は、次の手順に従って、Operations Manager の管理グループにレポートします。
  • Windows コンピューターに Log Analytics Windows エージェントをインストールし、ワークスペースに統合された Operations Manager と別のワークスペースの両方にレポートさせることができます。

アクセス制御の概要

Azure ロールベースのアクセス制御 (Azure RBAC) を使用すると、ユーザーとグループには、ワークスペース内の監視データを操作するために必要な量のアクセス権のみを付与できます。 これにより、1 つのワークスペースを使用して、すべてのリソースに対して収集されたデータを格納することで、IT 組織の運用モデルに合わせることができます。 たとえば、Azure 仮想マシン (VM) にホストされているインフラストラクチャ サービスを担当するチームにアクセス権を付与します。その結果、そのチームは、VM によって生成されたログのみにアクセスできるようになります。 これは、新しいリソース コンテキスト ログ モデルに従っています。 このモデルの基礎は、Azure リソースによって生成されるすべてのログ レコードがこのリソースに自動的に関連付けられることです。 ログは、リソースに基づくスコープと Azure RBAC を考慮する中央ワークスペースに転送されます。

ユーザーがアクセスできるデータは、次の表に記載されている要因の組み合わせによって決まります。 それぞれについて後のセクションで説明します。

要素 説明
アクセス モード ユーザーがワークスペースにアクセスするために使用する方法。 使用可能なデータの範囲と適用されるアクセス制御モードを定義します。
アクセス制御モード アクセス許可をワークスペース レベルとリソース レベルのどちらで適用するかを定義するワークスペースの設定。
アクセス許可 ワークスペースまたはリソースについて、個々のユーザーまたはユーザー グループに適用される許可。 ユーザーがアクセスできるデータを定義します。
テーブル レベルの Azure RBAC アクセス モードまたはアクセス制御モードに関係なく、すべてのユーザーに適用されるオプションのきめ細かいアクセス許可。 ユーザーがアクセスできるデータ型を定義します。

アクセス モード

アクセス モード は、ユーザーが Log Analytics ワークスペースにアクセスする方法を参照して、アクセスできるデータの範囲を定義します。

ユーザーには、データにアクセスするための 2 つのオプションがあります。

  • ワークスペース コンテキスト:ご自身がアクセス許可を持つワークスペース内のすべてのログを表示できます。 このモードのクエリの範囲は、ワークスペース内のすべてのテーブルのすべてのデータです。 このアクセス モードが使用されるのは、Azure portal の [Azure Monitor] メニューで [ログ] を選択する場合など、ワークスペースを範囲としてログにアクセスするときです。

    ワークスペースからの Log Analytics コンテキスト

  • リソース コンテキスト:Azure portal のリソース メニューで [ログ] を選択する場合など、特定のリソース、リソース グループまたはサブスクリプションに関してワークスペースにアクセスするときは、ご自身がアクセス許可を持っているすべてのテーブル内のそのリソースのログのみを表示できます。 このモードのクエリの範囲は、そのリソースに関連するデータのみです。 このモードでは、きめ細かい Azure RBAC も有効になります。

    リソースからの Log Analytics コンテキスト

    注意

    リソース コンテキスト クエリでログを使用できるのは、関連するリソースにログが適切に関連付けられている場合のみです。 現在、次のリソースには制限があります。

    ログがリソースに適切に関連付けられているかをテストするために、クエリを実行して、関心があるレコードを調べることができます。 正しいリソース ID が _ResourceId プロパティにあれば、リソース中心クエリでデータを使用できます。

Azure Monitor では、ログ検索の実行コンテキストに応じて適切なモードが自動的に決定されます。 スコープは、常に Log Analytics の左上のセクションに表示されます。

アクセス モードを比較する

アクセス モードを以下の表にまとめています。

問題 ワークスペース コンテキスト リソース コンテキスト
モデルの利用対象者 全体管理。 データ収集を構成する必要がある管理者と多様なリソースにアクセスする必要があるユーザー。 また、現時点では、Azure 外部のリソースのログにアクセスする必要があるユーザーにとって必要です。 アプリケーション チーム。 監視されている Azure リソースの管理者。
ログを表示するために必要なもの ワークスペースに対するアクセス許可。 「ワークスペースのアクセス許可を使用してアクセスを管理する」の ワークスペースのアクセス許可 の説明を参照してください。 リソースへの読み取りアクセス。 「Azure のアクセス許可を使用してアクセスを管理する」の「リソースのアクセス許可」を参照してください。 アクセス許可は継承する (含まれているリソース グループなどから) ことも、リソースに直接割り当てることもできます。 リソースのログに対するアクセス許可は自動的に割り当てられます。
アクセス許可の範囲 ワークスペース。 ワークスペースへのアクセス権を持つユーザーは、アクセス許可を持っているテーブルについて、ワークスペース内のすべてのログを照会できます。 テーブル アクセス制御に関する説明をご覧ください。 Azure リソース。 ユーザーは、自分がアクセス権を持つ特定のリソース、リソース グループまたはサブスクリプションのログをすべてのワークスペースから照会できますが、その他のリソースのログは照会できません。
ログにアクセスする方法
  • Azure Monitor メニューで [ログ] を開始します。
  • Log Analytics ワークスペース[ログ] を開始します。
  • Azure リソースのメニューで [ログ] を開始します
  • Azure Monitor メニューで [ログ] を開始します。
  • Log Analytics ワークスペース[ログ] を開始します。

アクセス制御モード

"アクセス制御モード" は、ワークスペースのアクセス許可の決定方法を定義するワークスペースごとの設定です。

  • ワークスペースのアクセス許可が必要:この制御モードでは、きめ細かい Azure RBAC は使用できません。 ユーザーがワークスペースにアクセスするためには、ワークスペースまたは特定のテーブルへのアクセス許可を付与される必要があります。

    ユーザーがワークスペース コンテキスト モードでワークスペースにアクセスする場合は、アクセス権を与えられたすべてのテーブル内のすべてのデータにアクセスできます。 ユーザーがリソース コンテキスト モードでワークスペースにアクセスする場合は、アクセス権を与えられたすべてのテーブルの該当リソースのデータのみにアクセスできます。

    これは、2019 年 3 月よりも前に作成されたすべてのワークスペースの既定設定です。

  • リソースまたはワークスペースのアクセス許可を使用:この制御モードでは、きめ細かい Azure RBAC を使用できます。 Azure read アクセス許可を割り当てることによって、ユーザーが表示できるリソースに関連付けられたデータのみへのアクセス権をそのユーザーに付与できます。

    ユーザーがワークスペース コンテキスト モードでワークスペースにアクセスするときは、ワークスペースのアクセス許可が適用されます。 ユーザーがリソース コンテキスト モードでワークスペースにアクセスするときは、リソースのアクセス許可のみが確認され、ワークスペースのアクセス許可は無視されます。 ユーザーに対して Azure RBAC を有効にするには、ワークスペースのアクセス許可からユーザーを削除して、リソースのアクセス許可が認識されるようにします。

    これは、2019 年 3 月よりも後に作成されたすべてのワークスペースの既定設定です。

    注意

    ワークスペースへのリソース アクセス許可のみを持つユーザーは、ワークスペース アクセス モードが [リソースまたはワークスペースのアクセス許可を使用] に設定されていることを前提として、リソース コンテキスト モードを使用してワークスペースにアクセスすることのみできます。

ポータル、PowerShell、または Resource Manager テンプレートを使用してアクセス制御モードを変更する方法については、「アクセス制御モードを構成する」を参照してください。

スケールとインジェスト ボリューム レートの制限

Azure Monitor とは、毎月増加するペタバイト単位のデータを送信する何千もの顧客にサービスを提供する高スケールのデータ サービスです。 ワークスペースは、それらの記憶域スペースに制限されず、ペタバイト単位のデータまで拡大できます。 スケーリングのためにワークスペースを分割する必要はありません。

Azure Monitor ユーザーとそのバックエンド インフラストラクチャを保護および分離するために、スパイクやフラッドの状況から保護するように設計された既定のインジェスト レート制限があります。 レート制限の既定値は約 6 GB/分 であり、通常のインジェストを可能にするように設計されています。 インジェスト ボリュームの制限の測定の詳細については、「Azure Monitor サービスの制限」を参照してください。

取り込みが 4 TB/日に満たないユーザーは、通常これらの制限に達することはありません。 大量のボリュームを取り込むか、または通常の運用の一部としてスパイクが発生するユーザーは、インジェスト レート制限を引き上げることができる専用クラスターに移行することを検討してください。

インジェスト レート制限がアクティブになっているか、またはしきい値の 80% に達した場合、ワークスペースの Operation テーブルにイベントが追加されます。 それを監視し、アラートを作成することをお勧めします。 詳細については「データ インジェストのボリューム レート」を参照してください。

推奨事項

リソース コンテキストの設計例

このシナリオでは、IT 組織のサブスクリプションにおいて、データ主権や規制遵守によって制約されない、またはリソースがデプロイされているリージョンにマップする必要がある 1 つのワークスペース設計について説明します。 これにより、組織のセキュリティおよび IT 管理者チームは、Azure アクセス管理との強化された統合と、より安全なアクセス制御を活用できます。

Application Insights や VM insights など、異なるチームによってメンテナンスされているインフラストラクチャとアプリケーションをサポートするすべてのリソース、監視ソリューション、および分析情報は、収集したログ データを IT 組織の一元的な共有ワークスペースに転送するように構成されています。 各チームのユーザーには、アクセス権が付与されているリソースのログへのアクセスが許可されます。

ワークスペース アーキテクチャをデプロイしたら、Azure Policy を使用して Azure リソースにこれを適用できます。 これにより、ポリシーを定義し、Azure リソースへのコンプライアンスを確保して、すべてのリソース ログが特定のワークスペースに送信されるようにする方法が提供されます。 たとえば、Azure 仮想マシンまたは仮想マシン スケール セットを使用すると、ワークスペースのコンプライアンスとレポートの結果を評価する既存のポリシーを使用したり、非準拠の場合に修復するようにカスタマイズしたりすることができます。

ワークスペース統合移行戦略

複数のワークスペースを既にデプロイしていて、リソース コンテキスト アクセス モデルへの統合に関心があるお客様には、漸進的アプローチを採用して推奨アクセス モデルに移行することをお勧めします。これをすばやくまたは積極的に実現しようとしないでください。 適切なタイムラインに従って計画、移行、検証、およびインベントリからの削除を行う段階的アプローチに従うと、計画外のインシデントや、クラウド運用への予期しない影響を回避できます。 コンプライアンスまたはビジネス上の理由でデータ保持ポリシーがない場合は、プロセス中に移行元のワークスペースにデータを保持する適切な時間の長さを評価する必要があります。 共有ワークスペースにレポートするようにリソースを再構成している間でも、必要に応じて元のワークスペース内のデータを分析できます。 移行が完了した後、保持期間が終了するまで元のワークスペースにデータを保持することにした場合は、それを削除しないでください。

このモデルへの移行を計画する際には、次の点を考慮してください。

  • 遵守する必要があるデータ保有に関する業界の規制や内部ポリシーを理解します。
  • アプリケーション チームが既存のリソース コンテキスト機能内で作業できることを確認します。
  • 運用環境に実装する前に、アプリケーション チームのリソースに付与されたアクセス権を特定し、開発環境内でテストします。
  • [リソースまたはワークスペースのアクセス許可を使用] を有効にするようにワークスペースを構成します。
  • ワークスペースの読み取りとクエリを行うために、アプリケーション チームのアクセス許可を削除します。
  • 元のワークスペース内にデプロイされていた、任意の監視ソリューション、Container insights や Azure Monitor for VMs などの分析情報、Automation アカウント、Update Management、VM の開始/停止などの管理ソリューションを有効にして構成します。

次のステップ

このガイドで推奨されているセキュリティのアクセス許可と制御を実装するには、ログへのアクセスの管理に関する記事を参照してください。