Azure Monitor Private Link Scope (AMPLS) を作成するときは、プライベート エンドポイントに接続されているネットワークのみに Azure Monitor リソースへのアクセスを制限します。 この記事では、「Azure Monitor のプライベート リンクの構成」のガイダンスを使用して実際に実装する前に、 Azure Monitor のプライベート リンク構成を設計する方法とその他の考慮事項について説明します。
AMPLS の制限
AMPLS オブジェクトには、次の制限があります。
- 仮想ネットワークは、"1 つ" の AMPLS オブジェクトにのみ接続できます。 これは、その AMPLS オブジェクトで、仮想ネットワークでアクセスできる必要のあるすべての Azure Monitor リソースへのアクセスを提供する必要があることを意味します。
- AMPLS オブジェクトは、最大 3,000 個の Log Analytics ワークスペースと最大 10,000 個の Application Insights コンポーネントに接続できます。
- Azure Monitor リソースは、最大 100 AMPLS に接続できます。
- 1 つの AMPLS オブジェクトは、最大 10 個のプライベート エンドポイントに接続できます。
ネットワーク トポロジ別の計画
次のセクションでは、ネットワーク トポロジに基づいて Azure Monitor プライベート リンクの構成を計画する方法について説明します。
単一の AMPLS を使用して DNS のオーバーライドを回避する
一部のネットワークは、複数の仮想ネットワークまたは接続された他のネットワークで構成されます。 これらのネットワークで同じ DNS を共有している場合は、これらのいずれかでプライベート リンクを構成すると、DNS が更新され、すべてのネットワークのトラフィックに影響します。
次の図では、仮想ネットワーク 10.0.1.x が AMPLS1 に接続し、Azure Monitor のエンドポイントを範囲 10.0.1.x の IP にマッピングする DNS エントリを作成します。 その後、仮想ネットワーク 10.0.2.x は AMPLS2 に接続します。これは、同 じグローバル/リージョン エンドポイント を範囲 10.0.2.x の IP にマッピングすることで、同じ DNS エントリをオーバーライドします。 これらの仮想ネットワークはピアリングされていないため、最初の仮想ネットワークはこれらのエンドポイントに到達できないようになります。 この競合を回避するには、DNS ごとに AMPLS オブジェクトを 1 つだけ作成します。
ハブアンドスポーク ネットワーク
ハブアンドスポーク ネットワークでは、各スポーク仮想ネットワーク上ではなくハブ (メイン) ネットワーク上に設定された単一のプライベート リンク接続を使用する必要があります。
各仮想ネットワークが限られた一連の監視リソースにアクセスできるようにするために、スポーク仮想ネットワーク用に個別のプライベート リンクを作成することをお勧めします。 この場合は、仮想ネットワークごとに専用のプライベート エンドポイントと AMPLS を作成できます。 "また、DNS オーバーライドを回避するために、同じ DNS ゾーンを共有していないことを確認する必要があります"。
ピアリングされたネットワーク
ネットワーク ピアリングを使用すると、ネットワークは互いの IP アドレスを共有でき、多くの場合、同じ DNS を共有できます。 この場合は、他のネットワークからアクセス可能なネットワーク上に単一のプライベート リンクを作成します。 複数のプライベート エンドポイントや AMPLS オブジェクトを作成することは避けてください。DNS に含まれる最後のセットのみが適用されるためです。
分離ネットワーク
ネットワークがピアリングされていない場合は、プライベート リンクを使用するために DNS も分離する必要があります。 その後、ネットワークごとに個別のプライベート エンドポイントと、個別の AMPLS オブジェクトを作成します。 AMPLS オブジェクトは、同じワークスペースやコンポーネントにリンクすることも、異なるワークスペースやコンポーネントにリンクすることもできます。
アクセス モード
プライベート リンク アクセス モードを使用すると、プライベート リンクがネットワーク トラフィックに与える影響を制御できます。 継続的で中断のないネットワーク トラフィックを確保するためには、どちらを選択するかが重要です。
アクセス モードは、AMPLS に接続されているすべてのネットワークまたは接続されている特定のネットワークに適用できます。 データ インジェストとクエリにはそれぞれ独自の設定があります。 たとえば、インジェストの プライベートのみ モードとクエリの オープン モードを設定できます。
Important
Log Analytics インジェストではリソース固有のエンドポイントが使用されるため、AMPLS アクセス モードに準拠しません。 Log Analytics インジェスト要求で AMPLS の外部にあるワークスペースにアクセスできないようにするには、AMPLS アクセス モードには関係なく、パブリック エンドポイントへのトラフィックをブロックするようにネットワーク ファイアウォールを設定します。
プライベートのみのアクセス モード
プライベートのみ モードでは、仮想ネットワークが AMPLS 内のプライベート リンク リソースにのみ到達できます。 これは最も安全な選択肢であり、AMPLS から Azure Monitor リソースへのトラフィックをブロックして、データ流出を防ぎます。
オープン アクセス モード
オープン モードでは、仮想ネットワークが AMPLS にないプライベート リンク リソースとリソースの両方に到達できます ( パブリック ネットワークからのトラフィックを受け入れる場合)。 "オープン" アクセス モードでは、データ流出を防ぐことはできませんが、プライベート リンクの他の恩恵は得られます。 プライベート リンク リソースへのトラフィックは、検証される前にプライベート エンドポイントを介して送信され、Microsoft バックボーン経由で送信されます。 オープン モードは、一部のリソースがパブリックにアクセスされ、他のリソースがプライベート リンク経由でアクセスされる混合モードの場合に便利です。 段階的なオンボーディング プロセス中にも役立ちます。
Important
アクセス モードを選択するときは注意が必要です。 [プライベートのみ] を使用すると、サブスクリプションやテナントに関係なく、同じ DNS を共有するすべてのネットワークの AMPLS にないリソースへのトラフィックがブロックされます。 すべての Azure Monitor リソースを AMPLS に追加できない場合は、まず選択したリソースを追加し、そのモードを適用します。 "すべての Azure Monitor リソースを AMPLS に追加した後にのみ"、最大のセキュリティを確保するために "プライベートのみ" モードに切り替えます。
特定のネットワークのアクセス モードを設定する
AMPLS リソースに設定されたアクセス モードは、すべてのネットワークに影響します。ただし、特定のネットワークに対してこれらの設定をオーバーライドすることができます。
次の図では、VNet1 は "オープン" モードを使用し、VNet2 は "プライベートのみ" モードを使用しています。 VNet1 からの要求は、プライベート リンク経由でワークスペース 1 とコンポーネント 2 に到達できます。 要求は、 パブリック ネットワークからのトラフィックを受け入れる場合にのみ、コンポーネント 3 に到達できます。 VNet2 の要求は、コンポーネント 3 に到達できません。
AMPLS リソースへのネットワーク アクセスを制御する
Azure Monitor コンポーネントは、次のいずれかに設定できます。
- 公衆ネットワーク (リソースの AMPLS に接続されていないネットワーク) からのインジェストを受け入れるかブロックする。
- 公衆ネットワーク (リソースの AMPLS に接続されていないネットワーク) からのクエリを受け入れるかブロックする。
この細分性により、ワークスペースごとに特定のニーズに応じてアクセスを設定できます。 たとえば、ネットワークに接続された プライベート リンク経由のインジェストのみを受け入れ、パブリックであれプライベートであれすべてのネットワークからのクエリを受け入れるように選択することができます。
注
公衆ネットワークからのクエリをブロックすると、接続されている AMPLS の外部のマシンや SDK などのクライアントはそのリソース内のデータに対してクエリを実行できなくなります。 このデータには、ログ、メトリック、およびライブ メトリック ストリームが含まれます。 公衆ネットワークからのクエリをブロックすると、これらのクエリを実行するすべてのエクスペリエンス (ブック、ダッシュボード、Azure portal 内の分析情報、Azure portal の外部から実行されるクエリなど) に影響が及びます。
このネットワーク アクセスの例外を次に示します。
- 診断ログ。 診断設定からワークスペースに送信されるログとメトリックは、セキュリティで保護されたプライベート Microsoft チャネル経由であり、これらの設定によって制御されません。
- カスタム メトリックまたは Azure Monitor ゲスト メトリック。 Azure Monitor エージェントから送信されるカスタム メトリックは、DCEs によって制御されず、プライベート リンク経由で構成することはできません。
注
Resource Manager API を介して送信されたクエリでは、Azure Monitor プライベート リンクを使用できません。 これらのクエリは、ターゲット リソースがパブリック ネットワークからのクエリを許可している場合にのみアクセスできます。
次のエクスペリエンスについては、Resource Manager API を介してクエリが実行されることが確認されています。
- LogicApp コネクタ
- Update Management ソリューション
- ソリューションの変更の追跡
- VM Insights
- コンテナ インサイト
- Log Analytics ワークスペースの概要 (非推奨) ウィンドウ (ソリューション ダッシュボードが表示されます)
- Application Insights の [メトリック] ウィンドウ (ログベースのメトリックグラフ)
Application Insights
- 監視対象のワークロードをホストしているリソースをプライベート リンクに追加します。 たとえば、「 Azure Web App でのプライベート エンドポイントの使用」を参照してください。
- ポータル以外の消費エクスペリエンスも、監視対象のワークロードを含むプライベート リンク仮想ネットワークで実行する必要があります。
- .NET Profiler とデバッガーのプライベート リンクをサポートする独自のストレージ アカウントを指定します。
注
ワークスペース ベースの Application Insights を完全に保護するには、Application Insights リソースと基になる Log Analytics ワークスペースへのアクセスをロックダウンします。
次のステップ
- プライベート リンクを構成する方法について説明します。
- カスタム ログとカスタマー マネージド キーの プライベート ストレージ について説明します。
- Private Link for Automation について説明します。