Azure Monitor ログのデプロイの設計Designing your Azure Monitor Logs deployment

Azure Monitor では、ログ データが Log Analytics ワークスペースに格納されます。Log Analytics ワークスペースは Azure リソースであり、データが収集、集計され、管理境界として機能するコンテナーです。Azure Monitor stores log data in a Log Analytics workspace, which is an Azure resource and a container where data is collected, aggregated, and serves as an administrative boundary. 1 つまたは複数のワークスペースを Azure サブスクリプションにデプロイできますが、組織のニーズを満たす、コスト効率に優れ、管理可能で、スケーラブルなデプロイを実現するためのガイドラインに初期のデプロイが従っていることを確認するために、理解しておく必要がある考慮事項がいくつかあります。While you can deploy one or more workspaces in your Azure subscription, there are several considerations you should understand in order to ensure your initial deployment is following our guidelines to provide you with a cost effective, manageable, and scalable deployment meeting your organizations needs.

ワークスペース内のデータがテーブルに整理されます。それぞれのテーブルにはさまざまな種類のデータが格納され、データを収集しているリソースに基づく独自かつ一意のプロパティ セットがあります。Data in a workspace is organized into tables, each of which stores different kinds of data and has its own unique set of properties based on the resource generating the data. ほとんどのデータ ソースでは、Log Analytics ワークスペース内の独自のテーブルに書き込みます。Most data sources will write to their own tables in a Log Analytics workspace.

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

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

  • データ ストレージの地理的な場所。A geographic location for data storage.
  • 推奨される設計戦略のいずれかに従ってさまざまなユーザーにアクセス権を付与することによるデータの分離。Data isolation by granting different users access rights following one of our recommended design strategies.
  • 価格レベルリテンション期間データ キャッピングなどの設定の構成のスコープ。Scope for configuration of settings like pricing tier, retention, and data capping.

この記事では、設計と移行に関する考慮事項の詳しい概要、アクセス制御の概要、および IT 組織に推奨される設計の実装について説明します。This article provides a detailed overview of the design and migration considerations, access control overview, and an understanding of the design implementations we recommend for your IT organization.

アクセス制御戦略に関する重要な考慮事項Important considerations for an access control strategy

必要なワークスペース数の特定は、次の要件の 1 つまたは複数の影響を受けます。Identifying the number of workspaces you need is influenced by one or more of the following requirements:

  • 世界規模の企業が、データ主権またはコンプライアンス上の理由から特定のリージョンにログ データを格納する必要がある。You are a global company and you need log data stored in specific regions for data sovereignty or compliance reasons.
  • Azure を使用しているときに、管理対象の Azure リソースと同じリージョンにワークスペースを配置することによって送信データ転送の料金が生じるのを回避したい。You are using Azure and you want to avoid outbound data transfer charges by having a workspace in the same region as the Azure resources it manages.
  • 複数の部門またはビジネス グループを管理しており、各部門やビジネス グループが他からのデータではなく各自のデータを確認できるようにしたい。You manage multiple departments or business groups, and you want each to see their own data, but not data from others. また、統合された部門間ビューやビジネス グループ ビューに関するビジネス要件はない。Also, there is no business requirement for a consolidated cross department or business group view.

現在、IT 組織は、一元化構造、分散型構造、または両方の構造のハイブリッドに従ってモデル化されています。IT organizations today are modeled following either a centralized, decentralized, or an in-between hybrid of both structures. その結果、これらの組織構造のいずれかにマップするために、次のワークスペース デプロイ モデルが一般的に使用されています。As a result, the following workspace deployment models have been commonly used to map to one of these organizational structures:

  • 一元化:すべてのログが中央ワークスペースに格納され、1 つのチームによって管理されます。Azure Monitor によって、チームごとに差別化されたアクセスが提供されます。Centralized: All logs are stored in a central workspace and administered by a single team, with Azure Monitor providing differentiated access per-team. このシナリオでは、管理、リソース間の検索、ログの相互関連付けが簡単です。In this scenario, it is easy to manage, search across resources, and cross-correlate logs. サブスクリプション内の複数のリソースから収集されるデータの量によっては、ワークスペースが大幅に増加する可能性があります。また、異なるユーザーに対するアクセス制御を維持するための管理オーバーヘッドも追加されます。The workspace can grow significantly depending on the amount of data collected from multiple resources in your subscription, with additional administrative overhead to maintain access control to different users.
  • 分散型:各チームが所有して管理するリソース グループ内に独自のワークスペースが作成され、ログ データはリソースごとに分離されます。Decentralized: Each team has their own workspace created in a resource group they own and manage, and log data is segregated per resource. このシナリオでは、ワークスペースをセキュリティで保護し、アクセス制御とリソース アクセスの一貫性を保つことができますが、ログを相互に関連付けることは困難です。In this scenario, the workspace can be kept secure and access control is consistent with resource access, but it's difficult to cross-correlate logs. 多くのリソースを広範囲に表示する必要があるユーザーは、意味のある方法でデータを分析できません。Users who need a broad view of many resources cannot analyze the data in a meaningful way.
  • ハイブリッド:多くの組織が両方のデプロイ モデルを並行して実装するため、セキュリティ監査コンプライアンス要件によってこのシナリオがさらに複雑になります。Hybrid: Security audit compliance requirements further complicate this scenario because many organizations implement both deployment models in parallel. これにより、多くの場合、ログ カバレッジにギャップがある、複雑でコストが高く、保守が困難な構成になります。This commonly results in a complex, expensive, and hard-to-maintain configuration with gaps in logs coverage.

Log Analytics エージェントを使用してデータを収集している場合は、エージェントのデプロイを計画するために次のことを理解しておく必要があります。When using the Log Analytics agents to collect data, you need to understand the following in order to plan your agent deployment:

  • Windows エージェントからデータを収集するには、1 つまたは複数のワークスペースにレポートするように各エージェントを構成できます。これは、System Center Operations Manager 管理グループにレポートしている場合でも同様です。To collect data from Windows agents, you can configure each agent to report to one or more workspaces, even while it is reporting to a System Center Operations Manager management group. Windows エージェントでは、最大 4 つのワークスペースを報告できます。The Windows agent can report up to four workspaces.
  • Linux エージェントでは、マルチホームがサポートされず、1 つのワークスペースにしかレポートできません。The Linux agent does not support multi-homing and can only report to a single workspace.

System Center Operations Manager 2012 R2 以降を使用している場合:If you are using System Center Operations Manager 2012 R2 or later:

  • 各 Operations Manager 管理グループは、1 つのワークスペースにのみ接続できます。Each Operations Manager management group can be connected to only one workspace.
  • 管理グループにレポートしている Linux コンピューターは、Log Analytics ワークスペースに直接レポートするように構成する必要があります。Linux computers reporting to a management group must be configured to report directly to a Log Analytics workspace. Linux コンピューターが既にワークスペースに直接レポートしており、それらを Operations Manager で監視する場合は、次の手順に従って、Operations Manager の管理グループにレポートします。If your Linux computers are already reporting directly to a workspace and you want to monitor them with Operations Manager, follow these steps to report to an Operations Manager management group.
  • Windows コンピューターに Log Analytics Windows エージェントをインストールし、ワークスペースに統合された Operations Manager と別のワークスペースの両方にレポートさせることができます。You can install the Log Analytics Windows agent on the Windows computer and have it report to both Operations Manager integrated with a workspace, and a different workspace.

アクセス制御の概要Access control overview

ロールベースのアクセス制御 (RBAC) を使用すると、ユーザーとグループには、ワークスペース内の監視データを操作するために必要な量のアクセス権のみを付与できます。With role-based access control (RBAC), you can grant users and groups only the amount of access they need to work with monitoring data in a workspace. これにより、1 つのワークスペースを使用して、すべてのリソースに対して収集されたデータを格納することで、IT 組織の運用モデルに合わせることができます。This allows you to align with your IT organization operating model using a single workspace to store collected data enabled on all your resources. たとえば、Azure 仮想マシン (VM) にホストされているインフラストラクチャ サービスを担当するチームにアクセス権を付与します。その結果、そのチームは、VM によって生成されたログのみにアクセスできるようになります。For example, you grant access to your team responsible for infrastructure services hosted on Azure virtual machines (VMs), and as a result they'll have access to only the logs generated by the VMs. これは、新しいリソース コンテキスト ログ モデルに従っています。This is following our new resource-context log model. このモデルの基礎は、Azure リソースによって生成されるすべてのログ レコードがこのリソースに自動的に関連付けられることです。The basis for this model is for every log record emitted by an Azure resource, it is automatically associated with this resource. ログは、リソースに基づくスコープと RBAC を考慮する中央ワークスペースに転送されます。Logs are forwarded to a central workspace that respects scoping and RBAC based on the resources.

ユーザーがアクセスできるデータは、次の表に記載されている要因の組み合わせによって決まります。The data a user has access to is determined by a combination of factors that are listed in the following table. それぞれについて後のセクションで説明します。Each is described in the sections below.

要素Factor [説明]Description
アクセス モードAccess mode ユーザーがワークスペースにアクセスするために使用する方法。Method the user uses to access the workspace. 使用可能なデータの範囲と適用されるアクセス制御モードを定義します。Defines the scope of the data available and the access control mode that's applied.
アクセス制御モードAccess control mode アクセス許可をワークスペース レベルとリソース レベルのどちらで適用するかを定義するワークスペースの設定。Setting on the workspace that defines whether permissions are applied at the workspace or resource level.
アクセス許可Permissions ワークスペースまたはリソースについて、個々のユーザーまたはユーザー グループに適用される許可。Permissions applied to individual or groups of users for the workspace or resource. ユーザーがアクセスできるデータを定義します。Defines what data the user will have access to.
テーブル レベルの RBACTable level RBAC アクセス モードまたはアクセス制御モードに関係なく、すべてのユーザーに適用されるオプションのきめ細かいアクセス許可。Optional granular permissions that apply to all users regardless of their access mode or access control mode. ユーザーがアクセスできるデータ型を定義します。Defines which data types a user can access.

アクセス モードAccess mode

アクセス モードは、ユーザーが Log Analytics ワークスペースにアクセスする方法を参照して、アクセスできるデータの範囲を定義します。The access mode refers to how a user accesses a Log Analytics workspace and defines the scope of data they can access.

ユーザーには、データにアクセスするための 2 つのオプションがあります。Users have two options for accessing the data:

  • ワークスペース コンテキスト:ご自身がアクセス許可を持つワークスペース内のすべてのログを表示できます。Workspace-context: You can view all logs in the workspace you have permission to. このモードのクエリの範囲は、ワークスペース内のすべてのテーブルのすべてのデータです。Queries in this mode are scoped to all data in all tables in the workspace. このアクセス モードが使用されるのは、Azure portal の [Azure Monitor] メニューで [ログ] を選択する場合など、ワークスペースを範囲としてログにアクセスするときです。This is the access mode used when logs are accessed with the workspace as the scope, such as when you select Logs from the Azure Monitor menu in the Azure portal.

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

  • リソース コンテキスト:Azure portal のリソース メニューで [ログ] を選択する場合など、特定のリソース、リソース グループまたはサブスクリプションに関してワークスペースにアクセスするときは、ご自身がアクセス許可を持っているすべてのテーブル内のそのリソースのログのみを表示できます。Resource-context: When you access the workspace for a particular resource, resource group, or subscription, such as when you select Logs from a resource menu in the Azure portal, you can view logs for only resources in all tables that you have access to. このモードのクエリの範囲は、そのリソースに関連するデータのみです。Queries in this mode are scoped to only data associated with that resource. このモードでは、きめ細かい RBAC も有効になります。This mode also enables granular RBAC.

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


    リソース コンテキスト クエリでログを使用できるのは、関連するリソースにログが適切に関連付けられている場合のみです。Logs are available for resource-context queries only if they were properly associated with the relevant resource. 現在、次のリソースには制限があります。Currently, the following resources have limitations:

    • Azure 外部のコンピューターComputers outside of Azure
    • Service FabricService Fabric
    • Application InsightsApplication Insights

    ログがリソースに適切に関連付けられているかをテストするために、クエリを実行して、関心があるレコードを調べることができます。You can test if logs are properly associated with their resource by running a query and inspecting the records you're interested in. 正しいリソース ID が _ResourceId プロパティにあれば、リソース中心クエリでデータを使用できます。If the correct resource ID is in the _ResourceId property, then data is available to resource-centric queries.

Azure Monitor では、ログ検索の実行コンテキストに応じて適切なモードが自動的に決定されます。Azure Monitor automatically determines the right mode depending on the context you perform the log search from. スコープは、常に Log Analytics の左上のセクションに表示されます。The scope is always presented in the top-left section of Log Analytics.

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

アクセス モードを以下の表にまとめています。The following table summarizes the access modes:

ワークスペース コンテキストWorkspace-context リソース コンテキストResource-context
モデルの利用対象者Who is each model intended for? 全体管理。Central administration. データ収集を構成する必要がある管理者と多様なリソースにアクセスする必要があるユーザー。Administrators who need to configure data collection and users who need access to a wide variety of resources. また、現時点では、Azure 外部のリソースのログにアクセスする必要があるユーザーにとって必要です。Also currently required for users who need to access logs for resources outside of Azure. アプリケーション チーム。Application teams. 監視されている Azure リソースの管理者。Administrators of Azure resources being monitored.
ログを表示するために必要なものWhat does a user require to view logs? ワークスペースに対するアクセス許可。Permissions to the workspace. ワークスペースのアクセス許可を使用してアクセスを管理する」のワークスペースのアクセス許可の説明を参照してください。See Workspace permissions in Manage access using workspace permissions. リソースへの読み取りアクセス。Read access to the resource. Azure のアクセス許可を使用してアクセスを管理する」の「リソースのアクセス許可」を参照してください。See Resource permissions in Manage access using Azure permissions. アクセス許可は継承する (含まれているリソース グループなどから) ことも、リソースに直接割り当てることもできます。Permissions can be inherited (such as from the containing resource group) or directly assigned to the resource. リソースのログに対するアクセス許可は自動的に割り当てられます。Permission to the logs for the resource will be automatically assigned.
アクセス許可の範囲What is the scope of permissions? ワークスペース。Workspace. ワークスペースへのアクセス権を持つユーザーは、アクセス許可を持っているテーブルについて、ワークスペース内のすべてのログを照会できます。Users with access to the workspace can query all logs in the workspace from tables that they have permissions to. テーブル アクセス制御に関する説明をご覧ください。See Table access control Azure リソース。Azure resource. ユーザーは、自分がアクセス権を持つ特定のリソース、リソース グループまたはサブスクリプションのログをすべてのワークスペースから照会できますが、その他のリソースのログは照会できません。User can query logs for specific resources, resource groups, or subscription they have access to from any workspace but can't query logs for other resources.
ログにアクセスする方法How can user access logs?
  • Azure Monitor メニューで [ログ] を開始します。Start Logs from Azure Monitor menu.
  • Log Analytics ワークスペース[ログ] を開始します。Start Logs from Log Analytics workspaces.
  • Azure リソースのメニューで [ログ] を開始しますStart Logs from the menu for the Azure resource
  • Azure Monitor メニューで [ログ] を開始します。Start Logs from Azure Monitor menu.
  • Log Analytics ワークスペース[ログ] を開始します。Start Logs from Log Analytics workspaces.

アクセス制御モードAccess control mode

"アクセス制御モード" は、ワークスペースのアクセス許可の決定方法を定義するワークスペースごとの設定です。The Access control mode is a setting on each workspace that defines how permissions are determined for the workspace.

  • ワークスペースのアクセス許可が必要:この制御モードでは、きめ細かい RBAC は使用できません。Require workspace permissions: This control mode does not allow granular RBAC. ユーザーがワークスペースにアクセスするためには、ワークスペースまたは特定のテーブルへのアクセス許可を付与される必要があります。For a user to access the workspace, they must be granted permissions to the workspace or to specific tables.

    ユーザーがワークスペース コンテキスト モードでワークスペースにアクセスする場合は、アクセス権を与えられたすべてのテーブル内のすべてのデータにアクセスできます。If a user accesses the workspace following the workspace-context mode, they have access to all data in any table they've been granted access to. ユーザーがリソース コンテキスト モードでワークスペースにアクセスする場合は、アクセス権を与えられたすべてのテーブルの該当リソースのデータのみにアクセスできます。If a user accesses the workspace following the resource-context mode, they have access to only data for that resource in any table they've been granted access to.

    これは、2019 年 3 月よりも前に作成されたすべてのワークスペースの既定設定です。This is the default setting for all workspaces created before March 2019.

  • リソースまたはワークスペースのアクセス許可を使用:この制御モードでは、きめ細かい RBAC を使用できます。Use resource or workspace permissions: This control mode allows granular RBAC. Azure read アクセス許可を割り当てることによって、ユーザーが表示できるリソースに関連付けられたデータのみへのアクセス権をそのユーザーに付与できます。Users can be granted access to only data associated with resources they can view by assigning Azure read permission.

    ユーザーがワークスペース コンテキスト モードでワークスペースにアクセスするときは、ワークスペースのアクセス許可が適用されます。When a user accesses the workspace in workspace-context mode, workspace permissions apply. ユーザーがリソース コンテキスト モードでワークスペースにアクセスするときは、リソースのアクセス許可のみが確認され、ワークスペースのアクセス許可は無視されます。When a user accesses the workspace in resource-context mode, only resource permissions are verified, and workspace permissions are ignored. ユーザーに対して RBAC を有効にするには、ワークスペースのアクセス許可からユーザーを削除して、リソースのアクセス許可が認識されるようにします。Enable RBAC for a user by removing them from workspace permissions and allowing their resource permissions to be recognized.

    これは、2019 年 3 月よりも後に作成されたすべてのワークスペースの既定設定です。This is the default setting for all workspaces created after March 2019.


    ワークスペースへのリソース アクセス許可のみを持つユーザーは、ワークスペース アクセス モードが [リソースまたはワークスペースのアクセス許可を使用] に設定されていることを前提として、リソース コンテキスト モードを使用してワークスペースにアクセスすることのみできます。If a user has only resource permissions to the workspace, they are only able to access the workspace using resource-context mode assuming the workspace access mode is set to Use resource or workspace permissions.

ポータル、PowerShell、または Resource Manager テンプレートを使用してアクセス制御モードを変更する方法については、「アクセス制御モードを構成する」を参照してください。To learn how to change the access control mode in the portal, with PowerShell, or using a Resource Manager template, see Configure access control mode.

取り込みボリュームと取り込み率の制限Ingestion volume rate limit

Azure Monitor とは、毎月増加するテラバイト単位のデータを送信する何千もの顧客にサービスを提供する高スケールのデータ サービスです。Azure Monitor is a high scale data service that serves thousands of customers sending terabytes of data each month at a growing pace. インジェスト率の既定のしきい値は、ワークスペースあたり 6 GB/分に設定されています。The default ingestion rate threshold is set to 6 GB/min per workspace. これは概算値であり、実際のサイズはログの長さとその圧縮率に左右され、データの種類によって異なることがあります。This is an approximate value since the actual size can vary between data types depending on the log length and its compression ratio. この上限は、エージェントまたはデータ コレクター API から送信されるデータには適用されません。This limit does not apply to data that is sent from agents or Data Collector API.

1 つのワークスペースに高い比率でデータを送信すると、一部のデータが削除され、しきい値を超え続けている間、6 時間ごとにワークスペースの操作テーブルにイベントが送信されます。If you send data at a higher rate to a single workspace, some data is dropped, and an event is sent to the Operation table in your workspace every 6 hours while the threshold continues to be exceeded. インジェスト ボリュームがインジェスト率の制限を超えている場合、または間もなくそれに達すると予測される場合は、サポート リクエストを開いて、ワークスペースの増加を要求できます。If your ingestion volume continues to exceed the rate limit or you are expecting to reach it sometime soon, you can request an increase to your workspace by opening a support request.

ワークスペース内でのそのようなイベントの通知を受け取るには、ゼロより大きい結果数のアラート ロジック ベースを使った次のクエリを使用して、ログ アラート ルールを作成します。To be notified on such an event in your workspace, create a log alert rule using the following query with alert logic base on number of results grater than zero.

|where OperationCategory == "Ingestion"
|where Detail startswith "The rate of data crossed the threshold"


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

このシナリオでは、IT 組織のサブスクリプションにおいて、データ主権や規制遵守によって制約されない、またはリソースがデプロイされているリージョンにマップする必要がある 1 つのワークスペース設計について説明します。This scenario covers a single workspace design in your IT organizations subscription that is not constrained by data sovereignty or regulatory compliance, or needs to map to the regions your resources are deployed within. これにより、組織のセキュリティおよび IT 管理者チームは、Azure アクセス管理との強化された統合と、より安全なアクセス制御を活用できます。It allows your organizations security and IT admin teams the ability to leverage the improved integration with Azure access management and more secure access control.

Application Insights や Azure Monitor for VMs など、異なるチームによってメンテナンスされているインフラストラクチャとアプリケーションをサポートするすべてのリソース、監視ソリューション、および分析情報は、収集したログ データを IT 組織の一元的な共有ワークスペースに転送するように構成されています。All resources, monitoring solutions, and Insights such as Application Insights and Azure Monitor for VMs, supporting infrastructure and applications maintained by the different teams are configured to forward their collected log data to the IT organizations centralized shared workspace. 各チームのユーザーには、アクセス権が付与されているリソースのログへのアクセスが許可されます。Users on each team are granted access to logs for resources they have been given access to.

ワークスペース アーキテクチャをデプロイしたら、Azure Policy を使用して Azure リソースにこれを適用できます。Once you have deployed your workspace architecture, you can enforce this on Azure resources with Azure Policy. これにより、ポリシーを定義し、Azure リソースへのコンプライアンスを確保して、すべてのリソース ログが特定のワークスペースに送信されるようにする方法が提供されます。It provides a way to define policies and ensure compliance with your Azure resources so they send all their resource logs to a particular workspace. たとえば、Azure 仮想マシンまたは仮想マシン スケール セットを使用すると、ワークスペースのコンプライアンスとレポートの結果を評価する既存のポリシーを使用したり、非準拠の場合に修復するようにカスタマイズしたりすることができます。For example, with Azure virtual machines or virtual machine scale sets, you can use existing policies that evaluate workspace compliance and report results, or customize to remediate if non-compliant.

ワークスペース統合移行戦略Workspace consolidation migration strategy

複数のワークスペースを既にデプロイしていて、リソース コンテキスト アクセス モデルへの統合に関心があるお客様には、漸進的アプローチを採用して推奨アクセス モデルに移行することをお勧めします。これをすばやくまたは積極的に実現しようとしないでください。For customers who have already deployed multiple workspaces and are interested in consolidating to the resource-context access model, we recommend you take an incremental approach to migrate to the recommended access model, and you don't attempt to achieve this quickly or aggressively. 適切なタイムラインに従って計画、移行、検証、およびインベントリからの削除を行う段階的アプローチに従うと、計画外のインシデントや、クラウド運用への予期しない影響を回避できます。Following a phased approach to plan, migrate, validate, and retire following a reasonable timeline will help avoid any unplanned incidents or unexpected impact to your cloud operations. コンプライアンスまたはビジネス上の理由でデータ保持ポリシーがない場合は、プロセス中に移行元のワークスペースにデータを保持する適切な時間の長さを評価する必要があります。If you do not have a data retention policy for compliance or business reasons, you need to assess the appropriate length of time to retain data in the workspace you are migrating from during the process. 共有ワークスペースにレポートするようにリソースを再構成している間でも、必要に応じて元のワークスペース内のデータを分析できます。While you are reconfiguring resources to report to the shared workspace, you can still analyze the data in the original workspace as necessary. 移行が完了した後、保持期間が終了するまで元のワークスペースにデータを保持することにした場合は、それを削除しないでください。Once the migration is complete, if you're governed to retain data in the original workspace before the end of the retention period, don't delete it.

このモデルへの移行を計画する際には、次の点を考慮してください。While planning your migration to this model, consider the following:

  • 遵守する必要があるデータ保有に関する業界の規制や内部ポリシーを理解します。Understand what industry regulations and internal policies regarding data retention you must comply with.
  • アプリケーション チームが既存のリソース コンテキスト機能内で作業できることを確認します。Make sure that your application teams can work within the existing resource-context functionality.
  • 運用環境に実装する前に、アプリケーション チームのリソースに付与されたアクセス権を特定し、開発環境内でテストします。Identify the access granted to resources for your application teams and test in a development environment before implementing in production.
  • [リソースまたはワークスペースのアクセス許可を使用] を有効にするようにワークスペースを構成します。Configure the workspace to enable Use resource or workspace permissions.
  • ワークスペースの読み取りとクエリを行うために、アプリケーション チームのアクセス許可を削除します。Remove application teams permission to read and query the workspace.
  • 元のワークスペース内にデプロイされていた、任意の監視ソリューション、コンテナーに対する Azure Monitor や Azure Monitor for VMs などの分析情報、Automation アカウント、Update Management、VM の開始/停止などの管理ソリューションを有効にして構成します。Enable and configure any monitoring solutions, Insights such as Azure Monitor for containers and/or Azure Monitor for VMs, your Automation account(s), and management solutions such as Update Management, Start/Stop VMs, etc., that were deployed in the original workspace.

次のステップNext steps

このガイドで推奨されているセキュリティのアクセス許可と制御を実装するには、ログへのアクセスの管理に関する記事を参照してください。To implement the security permissions and controls recommended in this guide, review manage access to logs.