Partager via

Concevoir une configuration de liaison privée Azure Monitor

  • Article

Quand vous créez une étendue de liaison privée Azure Monitor (AMPLS), vous limitez l’accès aux ressources Azure Monitor aux seuls réseaux connectés au point de terminaison privé. Cet article vous aide à concevoir une configuration de liaison privée Azure Monitor et aborde d’autres considérations que vous devez prendre en compte avant de suivre les instructions fournies dans Configurer une liaison privée pour Azure Monitor pour implémenter cette configuration.

Limites d’une étendue AMPLS

Les objets AMPLS ont les limites suivantes :

  • Un réseau virtuel ne peut pas se connecter à un seul objet AMPLS. Cela signifie que l’objet AMPLS doit fournir l’accès à toutes les ressources Azure Monitor auxquelles le réseau virtuel doit avoir accès.
  • Un objet AMPLS peut se connecter à 300 espaces de travail Log Analytics et 1 000 composants Application Insights au maximum.
  • Une ressource Azure Monitor peut se connecter à cinq étendues AMPLS au maximum.
  • Un objet AMPLS peut se connecter à 10 points de terminaison privés au maximum.

Planifier selon la topologie de réseau

Les sections suivantes décrivent comment planifier votre configuration de liaison privée Azure Monitor en fonction de la topologie de votre réseau.

Éviter les remplacements DNS en utilisant une seule étendue AMPLS

Certains réseaux sont composés de plusieurs réseaux virtuels ou d’autres réseaux connectés. Si ces réseaux partagent le même DNS, la configuration d’une liaison privée sur l’un d’eux met à jour le DNS et affecte le trafic sur tous les réseaux.

Dans le diagramme suivant, le réseau virtuel 10.0.1.x se connecte à l’étendue AMPLS1 qui crée des entrées DNS mappant des points de terminaison Azure Monitor aux adresses IP à partir de la plage 10.0.1.x. Par la suite, le réseau virtuel 10.0.2.x se connecte à l’étendue AMPLS2 qui remplace les mêmes entrées DNS en mappant les mêmes points de terminaison globaux/régionaux à des adresses IP de la plage 10.0.2.x. Étant donné que ces réseaux virtuels ne sont pas appairés, le premier réseau virtuel ne parvient plus à atteindre ces points de terminaison. Pour éviter ce conflit, créez un seul objet AMPLS par DNS.

Diagramme montrant des remplacements DNS dans plusieurs réseaux virtuels.

Réseaux hub-and-spoke

Les réseaux hub-and-spoke doivent utiliser une connexion de liaison privée définie sur le réseau hub (principal), et non sur chaque réseau virtuel spoke.

Vous préférerez peut-être créer des liaisons privées distinctes pour vos réseaux virtuels spoke de manière à ce que chaque réseau virtuel puisse accéder à un ensemble limité de ressources de surveillance. Dans ce cas, vous pouvez créer un point de terminaison privé dédié et une étendue AMPLS pour chaque réseau virtuel. Vous devez également vérifier qu’elles ne partagent pas les mêmes zones DNS pour éviter les remplacements de DNS.

Diagramme montrant une liaison privée unique hub-and-spoke.

Réseaux appairés

Avec le Peering réseau, les réseaux peuvent partager leurs adresses IP respectives et très probablement le même DNS. Dans ce cas, créez une seule liaison privée sur un réseau accessible à vos autres réseaux. Évitez de créer plusieurs points de terminaison privés et objets AMPLS, car seul le dernier défini dans le DNS s’applique.

Réseaux isolés

Si vos réseaux ne sont pas appairés, vous devez également séparer leur DNS pour utiliser des liaisons privées. Vous pouvez ensuite créer un point de terminaison privé distinct pour chaque réseau et un objet AMPLS distinct. Vos objets AMPLS peuvent lier aux mêmes espaces de travail/composants ou à d’autres.

Sélectionner un mode d’accès

Les modes d’accès aux liaisons privées vous permettent de contrôler l’incidence des liaisons privées sur le trafic. Le mode que vous choisissez est critique pour garantir un trafic continu et ininterrompu.

Les modes d’accès peuvent s’appliquer à tous les réseaux connectés à votre étendue AMPLS ou à des réseaux spécifiques qui y sont connectés. Les modes d’accès sont définis séparément pour l’ingestion et les requêtes. Par exemple, vous pouvez définir le mode Privé uniquement pour l’ingestion et le mode Ouvert pour les requêtes.

Important

L’ingestion Log Analytics utilise des points de terminaison propres aux ressources et n’adhère donc pas aux modes d’accès AMPLS. Pour veiller à ce que les demandes d’ingestion de Log Analytics ne puissent pas accéder aux espaces de travail en dehors de l’étendue AMPLS, configurez le pare-feu du réseau pour bloquer le trafic vers les points de terminaison publics, quel que soit les modes d’accès de l’étendue AMPLS.

Mode d’accès Privé uniquement

Ce mode autorise le réseau virtuel à atteindre uniquement les ressources de liaison privée dans l’étendue AMPLS. Cette option, la plus sécurisée, empêche l’exfiltration de données en bloquant le trafic sortant de l’étendue AMPLS vers les ressources Azure Monitor.

Diagramme montrant le mode d’accès Privé uniquement de l’étendue AMPLS.

Mode d’accès Ouvert

Ce mode autorise le réseau virtuel à atteindre les ressources de liaison privée et celles qui ne se trouvent pas dans l’étendue AMPLS (si elles acceptent le trafic provenant de réseaux publics). Le mode d’accès Ouvert n’empêche pas l’exfiltration des données, mais il offre toujours les autres avantages des liaisons privées. Le trafic vers les ressources de liaison privée est envoyé via des points de terminaison privés avant d’être validé, puis envoyé sur le réseau principal de Microsoft. Le mode Ouvert est utile en mode mixte où certaines ressources sont accessibles publiquement et d’autres via une liaison privée. Il peut également être utile au cours d’un processus d’intégration progressif.

Diagramme représentant le mode d’accès Ouvert dans l’étendue AMPLS.

Important

Soyez prudent lorsque vous sélectionnez votre mode d’accès. L’utilisation du mode d’accès Privé uniquement bloque le trafic vers les ressources ne figurant pas dans l’étendue AMPLS sur tous les réseaux qui partagent le même DNS, quel que soit l’abonnement ou le locataire. Si vous ne pouvez pas ajouter toutes les ressources Azure Monitor à AMPLS, commencez par ajouter les ressources sélectionnées en appliquant le mode d’accès Ouvert. Basculez vers le mode Privé uniquement afin de bénéficier d’une sécurité maximale uniquement après avoir ajouté toutes les ressources Azure Monitor à votre étendue AMPLS.

Définir des modes d’accès pour des réseaux spécifiques

Les modes d’accès définis sur la ressource AMPLS affectent tous les réseaux. Vous pouvez toutefois remplacer ces paramètres pour des réseaux spécifiques.

Dans le diagramme suivant, le réseau VNet1 utilise le mode Ouvert, tandis que le réseau VNet2 utilise le mode Privé uniquement. Les requêtes du réseau virtuel 1 peuvent atteindre l’espace de travail 1 et le composant 2 via une liaison privée. Les demandes ne peuvent atteindre le composant 3 que s’il accepte le trafic provenant de réseaux publics. Les requêtes du réseau virtuel 2 ne peuvent pas atteindre le composant 3.

Diagramme montrant les modes d’accès mixtes.

Contrôler l’accès réseau aux ressources AMPLS

Vous pouvez définir les composants Azure Monitor pour, au choix :

  • Accepter ou bloquer l’ingestion à partir des réseaux publics (réseaux non connectés à l’étendue AMPLS de la ressource).
  • Accepter ou bloquer les requêtes provenant de réseaux publics (réseaux non connectés à l’étendue AMPLS de la ressource).

Cette granularité vous permet de définir l’accès par espace de travail en fonction de vos besoins spécifiques. Par exemple, vous pouvez accepter l’ingestion uniquement via des réseaux connectés par liaison privée, mais choisir d’accepter les requêtes de tous les réseaux, publics et privés.

Remarque

Le blocage des requêtes provenant des réseaux publics signifie que des clients situés en dehors de l’étendue AMPLS connectée, comme des machines et des Kits de développement logiciel (SDK), ne peuvent pas interroger les données de la ressource. Ces données incluent les journaux, les métriques et les flux de métriques temps réel. Le blocage de requêtes provenant de réseaux publics affecte toutes les expériences qui exécutent ces requêtes telles que les classeurs, tableaux de bord et insights dans le Portail Azure, ainsi que les requêtes exécutées en dehors du Portail Azure.

Voici des exceptions à cet accès réseau :

  • Journaux de diagnostic. Les journaux et les métriques envoyés à un espace de travail à partir d’un paramètre de diagnostic passent par un canal Microsoft privé sécurisé et ne sont pas contrôlés par ces paramètres.
  • Métriques personnalisées ou métriques d’invité Azure Monitor. Les métriques personnalisées envoyées à partir de l’agent Azure Monitor ne sont pas contrôlées par les points de terminaison de collecte de données (DCE) et ne peuvent pas être configurées via des liaisons privées.

Remarque

Les requêtes envoyées via l’API Resource Manager ne peuvent pas utiliser les liaisons privées Azure Monitor. Ces requêtes peuvent uniquement accéder à la ressource cible si celle-ci autorise les requêtes provenant de réseaux publics.

Les expériences suivantes sont connues pour exécuter des requêtes via l’API Resource Manager :

  • Connecteur LogicApp
  • Solution Update Management
  • Solution de suivi des modifications
  • Insights de machine virtuelle
  • Container Insights
  • Volet Résumé de l’espace de travail (),déconseillé Log Analytics (affichant le tableau de bord des solutions)

Considérations spéciales

Application Insights

Remarque

Pour sécuriser entièrement Application Insights en fonction de l’espace de travail, verrouillez l’accès à la ressource Application Insights et à l’espace de travail Log Analytics sous-jacent.

Prometheus managé

  • Les paramètres d’ingestion Private Link sont créés avec une étendue AMPLS et des paramètres sur les points de terminaison de collecte de données qui référencent l’espace de travail Azure Monitor utilisé pour stocker les métriques Prometheus.
  • Les paramètres de requête Private Link sont créés directement sur l’espace de travail Azure Monitor utilisé pour stocker les métriques Prometheus et ne sont pas gérés avec une étendue AMPLS.

Étapes suivantes