次の方法で共有

Azure Monitor Private Link の構成を設計する

  • [アーティクル]

Azure Monitor Private Link Scope (AMPLS) を作成するときは、Azure Monitor リソースへのアクセスをプライベート エンドポイントに接続されているネットワークのみに制限します。 この記事では、Azure Monitor のプライベート リンクの構成のガイダンスを使用して実際に実装する前に、Azure Monitor プライベート リンクの構成と、念頭に置く必要があるその他の考慮事項を設計する方法を説明します。

AMPLS の制限

AMPLS オブジェクトには、次の制限があります。

  • 仮想ネットワークは、"1 つ" の AMPLS オブジェクトにのみ接続できます。 これは、その AMPLS オブジェクトで、仮想ネットワークでアクセスできる必要のあるすべての Azure Monitor リソースへのアクセスを提供する必要があることを意味します。
  • AMPLS オブジェクトは、最大 300 の Log Analytics ワークスペースと最大 1,000 の Application Insights コンポーネントに接続できます。
  • Azure Monitor リソースは、最大 5 つの 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 に接続し、AMPLS2 は同じグローバル/リージョナル エンドポイントを範囲 10.0.2.x の IP にマッピングして同じ DNS エントリを上書きします。 これらの仮想ネットワークはピアリングされていないため、最初の仮想ネットワークはこれらのエンドポイントに到達できないようになります。 この競合を回避するには、DNS ごとに AMPLS オブジェクトを 1 つだけ作成します。

複数の仮想ネットワークでの DNS オーバーライドを示す図。

ハブアンドスポーク ネットワーク

ハブアンドスポーク ネットワークでは、各スポーク仮想ネットワーク上ではなくハブ (メイン) ネットワーク上に設定された単一のプライベート リンク接続を使用する必要があります。

各仮想ネットワークが限られた一連の監視リソースにアクセスできるようにするために、スポーク仮想ネットワーク用に個別のプライベート リンクを作成することをお勧めします。 この場合は、仮想ネットワークごとに専用のプライベート エンドポイントと AMPLS を作成できます。 "また、DNS オーバーライドを回避するために、同じ DNS ゾーンを共有していないことを確認する必要があります"。

ハブアンドスポークの単一プライベート リンクを示す図。

ピアリングされたネットワーク

ネットワーク ピアリングを使用すると、ネットワークは互いの IP アドレスを共有でき、多くの場合、同じ DNS を共有できます。 この場合は、他のネットワークからアクセス可能なネットワーク上に単一のプライベート リンクを作成します。 複数のプライベート エンドポイントや AMPLS オブジェクトを作成することは避けてください。DNS に含まれる最後のセットのみが適用されるためです。

分離ネットワーク

ネットワークがピアリングされていない場合は、プライベート リンクを使用するために DNS も分離する必要があります。 その後、ネットワークごとに個別のプライベート エンドポイントと、個別の AMPLS オブジェクトを作成します。 AMPLS オブジェクトは、同じワークスペースやコンポーネントにリンクすることも、異なるワークスペースやコンポーネントにリンクすることもできます。

アクセス モードを選択する

プライベート リンク アクセス モードを使用すると、プライベート リンクがネットワーク トラフィックに与える影響を制御できます。 継続的で中断のないネットワーク トラフィックを確保するためには、どちらを選択するかが重要です。

アクセス モードは、AMPLS に接続されているすべてのネットワーク、またはそれに接続されている特定のネットワークに適用できます。 アクセス モードは、インジェストとクエリ用に個別に設定されます。 たとえば、インジェストには "プライベートのみ" モードを設定しつつ、クエリには "オープン" モードを設定することができます。

重要

Log Analytics インジェストではリソース固有のエンドポイントが使用されるため、AMPLS アクセス モードに準拠しません。 Log Analytics インジェスト要求で AMPLS の外部にあるワークスペースにアクセスできないようにするには、AMPLS アクセス モードには関係なく、パブリック エンドポイントへのトラフィックをブロックするようにネットワーク ファイアウォールを設定します。

プライベートのみのアクセス モード

このモードでは、仮想ネットワークが、AMPLS 内のプライベート リンク リソースのみに到達できます。 これは最も安全な選択肢であり、AMPLS から Azure Monitor リソースへのトラフィックをブロックして、データ流出を防ぎます。

AMPLS の

オープン アクセス モード

このモードでは、仮想ネットワークは、プライベート リンク リソースと AMPLS にないリソースの両方に到達できます (それらが公衆ネットワークからのトラフィックを受け入れる場合)。 "オープン" アクセス モードでは、データ流出を防ぐことはできませんが、プライベート リンクの他の恩恵は得られます。 プライベート リンク リソースへのトラフィックは、検証される前にプライベート エンドポイントを介して送信され、Microsoft バックボーン経由で送信されます。 オープン モードは、一部のリソースがパブリックにアクセスされ、他のリソースがプライベート リンク経由でアクセスされる混合モードの場合に便利です。 段階的なオンボーディング プロセス中にも役立ちます。

AMPLS の

重要

アクセス モードは慎重に選択してください。 プライベートのみのアクセス モードを使用すると、AMPLS にないリソースへのトラフィックが、サブスクリプションやテナントに関係なく、同じ DNS を共有するすべてのネットワークでブロックされます。 すべての Azure Monitor リソースを AMPLS に追加できない場合、まず、一部のリソースを追加し、"オープン" アクセス モードを適用します。 "すべての Azure Monitor リソースを AMPLS に追加した後にのみ"、最大のセキュリティを確保するために "プライベートのみ" モードに切り替えます。

特定のネットワークのアクセス モードを設定する

AMPLS リソースに設定されたアクセス モードは、すべてのネットワークに影響します。ただし、特定のネットワークに対してこれらの設定をオーバーライドすることができます。

次の図では、VNet1 は "オープン" モードを使用し、VNet2 は "プライベートのみ" モードを使用しています。 VNet1 からの要求は、プライベート リンク経由でワークスペース 1 とコンポーネント 2 に到達できます。 要求は、公衆ネットワークからのトラフィックを受け入れる場合にのみ、コンポーネント 3 に到達できます。 VNet2 の要求は、コンポーネント 3 に到達できません。

混合アクセス モードを示す図。

AMPLS リソースへのネットワーク アクセスを制御する

Azure Monitor コンポーネントは、次のいずれかに設定できます。

  • 公衆ネットワーク (リソースの AMPLS に接続されていないネットワーク) からのインジェストを受け入れるかブロックする。
  • 公衆ネットワーク (リソースの AMPLS に接続されていないネットワーク) からのクエリを受け入れるかブロックする。

この細分性により、ワークスペースごとに特定のニーズに応じてアクセスを設定できます。 たとえば、ネットワークに接続された プライベート リンク経由のインジェストのみを受け入れ、パブリックであれプライベートであれすべてのネットワークからのクエリを受け入れるように選択することができます。

Note

公衆ネットワークからのクエリをブロックすると、接続されている AMPLS の外部のマシンや SDK などのクライアントはそのリソース内のデータに対してクエリを実行できなくなります。 このデータには、ログ、メトリック、およびライブ メトリック ストリームが含まれます。 公衆ネットワークからのクエリをブロックすると、これらのクエリを実行するすべてのエクスペリエンス (ブック、ダッシュボード、Azure portal 内の分析情報、Azure portal の外部から実行されるクエリなど) に影響が及びます。

このネットワーク アクセスの例外を次に示します。

  • 診断ログ。 診断設定からワークスペースに送信されたログとメトリックは、セキュリティで保護されたプライベート Microsoft チャネルを経由し、これらの設定によって制御されることはありません。
  • カスタム メトリックまたは Azure Monitor ゲスト メトリック。 Azure Monitor エージェントから送信されるカスタム メトリックは DCE によって制御されず、プライベート リンク上で構成することはできません。

Note

Resource Manager API を介して送信されたクエリでは、Azure Monitor プライベート リンクを使用できません。 これらのクエリは、ターゲット リソースがパブリック ネットワークからのクエリを許可している場合にのみアクセスできます。

次のエクスペリエンスについては、Resource Manager API を介してクエリが実行されることが確認されています。

  • LogicApp コネクタ
  • Update Management ソリューション
  • ソリューションの変更の追跡
  • VM Insights
  • Container Insights
  • Log Analytics の [ワークスペースの概要 (非推奨)] ペイン (ソリューション ダッシュボードを表示)

特別な注意事項

Application Insights

Note

ワークスペース ベースの Application Insights を完全に保護するには、Application Insights リソースと基になる Log Analytics ワークスペースへのアクセスをロックダウンします。

マネージド Prometheus

  • Private Link のインジェスト設定は、AMPLS と、Prometheus メトリックの格納に使用される Azure Monitor ワークスペースを参照するデータ収集エンドポイント (DCE) の設定を使用して行われます。
  • Private Link のクエリ設定は、Prometheus メトリックの格納に使用される Azure Monitor ワークスペースで直接行われ、AMPLS では処理されません。

次のステップ