Concevez votre configuration Azure Private Link

Avant de configurer votre instance Azure Private Link, prenez en compte la topologie de votre réseau et la topologie de votre routage DNS.

Comme indiqué dans l’article Utiliser Azure Private Link pour connecter des réseaux à Azure Monitor, la configuration d’une liaison privée affecte le trafic vers toutes les ressources Azure Monitor. C’est particulièrement vrai pour les ressources Application Insights. Elle affecte non seulement le réseau connecté au point de terminaison privé, mais également tous les autres réseaux qui partagent le même DNS.

L’approche la plus simple et la plus sécurisée est la suivante :

1. Créez une connexion de liaison privée unique, avec un point de terminaison privé unique et une étendue de liaison privée Azure Monitor (AMPLS) unique. Si vos réseaux sont appairés, créez la connexion de liaison privée sur le réseau virtuel partagé (ou hub).
2. Ajoutez toutes les ressources Azure Monitor, telles que les composants Application Insights, les espaces de travail Log Analytics et les points de terminaison de collecte de données à l’étendue AMPLS.
3. Bloquez autant que possible le trafic de sortie réseau.

Si vous ne pouvez pas ajouter toutes les ressources Azure Monitor dans votre étendue AMPLS, vous pouvez toujours appliquer votre liaison privée à certaines ressources, comme expliqué dans Contrôler la façon dont les liaisons privées s’appliquent à vos réseaux. Nous ne recommandons pas cette approche, car elle n’empêche pas l’exfiltration de données.

Planifier selon la topologie de réseau

Tenez compte de la topologie de réseau dans votre processus de planification.

Principe directeur : évitez les remplacements DNS à l’aide d’une étendue AMPLS unique

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.

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.

Remarque

Vous pouvez préférer créer des liaisons privées distinctes pour vos réseaux virtuels spoke, par exemple pour permettre à chaque réseau virtuel d’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.

Réseaux appairés

Le Peering de réseaux est utilisé dans diverses topologies, autres que hub-and-spoke. Ces réseaux peuvent partager les adresses IP de chacun et fort probablement partager le même DNS. Dans ce cas, créez une seule de liaison privée sur un réseau accessible par vos autres réseaux. Évitez de créer plusieurs points de terminaison privés et objets AMPLS, car, à terme, 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. Une fois effectué, créez un point de terminaison privé distinct pour chaque réseau et un autre objet AMPLS. Vos objets AMPLS peuvent lier aux mêmes espaces de travail/composants ou à d’autres.

Tests locaux : modifier le fichier hosts de votre ordinateur à la place du DNS

Pour tester les liaisons privées localement sans affecter les autres clients sur votre réseau, veillez à ne pas mettre à jour votre DNS lorsque vous créez votre point de terminaison privé. Modifiez plutôt le fichier hosts sur votre machine afin qu’il envoie des requêtes aux points de terminaison de liaison privée :

• Configurez une liaison privée. Cependant, lorsque vous vous connectez à un point de terminaison privé, choisissez de ne pas effectuer une intégration automatique au DNS (étape 5b).
• Configurez les points de terminaison appropriés sur les fichiers hosts de vos machines. Pour passer en revue les points de terminaison Azure Monitor à mapper, consultez Passez en revue les paramètres DNS de votre point de terminaison.

Nous ne recommandons pas cette approche pour les environnements de production.

Contrôler la façon dont les liaisons privées s’appliquent à vos réseaux

En utilisant des modes d’accès aux liaisons privées, vous pouvez contrôler l’incidence des liaisons privées sur votre trafic réseau. Ces paramètres peuvent s’appliquer à votre objet AMPLS (pour affecter tous les réseaux connectés) ou à des réseaux spécifiques qui y sont connectés.

Il est essentiel de choisir le mode d’accès approprié pour garantir un trafic réseau continu et ininterrompu. Chacun de ces modes peut être défini pour l’ingestion et les requêtes, séparément :

• Privé uniquement : autorise le réseau virtuel à atteindre uniquement les ressources de liaison privée (ressources dans l’étendue AMPLS). C’est le mode de travail le plus sécurisé. Il empêche l’exfiltration des données en bloquant le trafic hors de l’étendue AMPLS vers les ressources Azure Monitor.
• Ouvert : autorise le réseau virtuel à atteindre les ressources de liaison privée et les ressources qui ne se trouvent pas dans l’étendue AMPLS (s’ils 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, validé et envoyé sur le réseau principal de Microsoft. Le mode Ouvert est utile dans le cadre d’un mode de travail mixte (qui accède à certaines ressources de manière publique et à d’autres via une liaison privée) ou d’un processus d’intégration progressif. 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.

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. Les demandes d’ingestion Log Analytics constituent l’exception, comme expliqué. 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.

Pour obtenir des exemples et des détails sur la configuration, consultez Utiliser des API et une ligne de commande.

Notes

L’ingestion Log Analytics utilise des points de terminaison spécifiques d’une ressource. Par conséquent, elle ne se conforme pas aux modes d’accès de l’étendue 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.

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.

Envisager les limites AMPLS

L’objet AMPLS présente les limitations 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 maximum.
• Une ressource Azure Monitor (espace de travail, composant Application Insights ou point de terminaison de collecte de données) peut être connectée à cinq objets AMPLS maximum.
• Un objet AMPLS peut se connecter à 10 points de terminaison privés au maximum.

Notes

Les ressources AMPLS créées avant le 1er décembre 2021 prennent seulement en charge 50 ressources.

Dans le schéma suivant :

• Chaque réseau virtuel se connecte à un seul objet AMPLS.
• L’étendue AMPLS A se connecte à deux espaces de travail et à un composant Application Insight, en utilisant deux des 300 espace de travail Log Analytics possibles et un des 1 000 composants Application Insights possibles auxquels elle peut se connecter.
• L’espace de travail 2 se connecte à AMPLS A et à AMPLS B en utilisant deux de ses cinq connexions AMPLS possibles.
• AMPLS B est connectée aux points de terminaison privés de deux réseaux virtuels (réseau virtuel 2 et réseau virtuel 3) en utilisant 2 de ses 10 connexions de points de terminaison privés possibles.

Contrôler l’accès réseau à vos ressources

Vos espaces de travail Log Analytics ou composants Application Insights peuvent être définis pour :

• 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 précision vous permet de définir l’accès en fonction de vos besoins, par espace de travail. Par exemple, vous pouvez accepter l’ingestion uniquement via des réseaux connectés par liaison privée (c’est-à-dire des réseaux virtuels spécifiques) tout en choisissant d’accepter les requêtes de tous les réseaux, publics et privés.

Le blocage des requêtes provenant des réseaux publics signifie que les clients (machines, Kit de développement logiciel (SDK), etc.) situés en dehors des étendues AMPLS connectées 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.

Remarque

Il existe certaines exceptions où ces paramètres ne s’appliquent pas. Vous trouverez des détails dans la section suivante.

Vos points de terminaison de collecte de données peuvent être définis pour accepter ou bloquer l’accès à partir de réseaux publics (réseaux non connectés à la ressource de l’étendue AMPLS).

Pour en savoir plus sur la configuration, consultez Définir les indicateurs d’accès aux ressources.

Exceptions

Notez les exceptions suivantes.

Journaux de diagnostic

Les journaux et métriques chargés sur un espace de travail par le biais des paramètres de diagnostic passent par un canal privé sécurisé de Microsoft 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 (préversion) collectées et chargées via l’agent Azure Monitor ne sont pas actuellement contrôlées par des points de terminaison de collecte de données. Elles ne peuvent pas être configurées sur des liaisons privées.

Azure Resource Manager

La restriction d’accès, qui a été précédemment expliqué, s’applique aux données de la ressource. Cependant, les modifications de configuration, comme l’activation ou la désactivation de ces paramètres d’accès, sont gérées par Azure Resource Manager. Pour contrôler ces paramètres, limitez l’accès aux ressources en utilisant des rôles, autorisations, contrôles réseau et audits appropriés. Pour en savoir plus, consultez Rôles, autorisations et sécurité Azure Monitor.

Notes

Les requêtes envoyées via l’API Resource Manager ne peuvent pas utiliser les liaisons privées Azure Monitor. Ces requêtes ne peuvent être exécutées que si la ressource cible autorise les requêtes provenant de réseaux publics (définis via le volet Isolement réseau ou en utilisant l’interface CLI).

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 relatives à Application Insights

• Vous devez ajouter des ressources hébergeant les charges de travail surveillées à une liaison privée. Par consulter un exemple, voir Utilisation de points de terminaison privés pour Azure Web App.
• Les expériences de consommation hors portail doivent également être exécutées dans le réseau virtuel connecté par liaison privée qui comprend les charges de travail surveillées.
• Vous devez fournir votre propre compte de stockage pour prendre en charge des liaisons privées pour le Profiler et le débogueur.

Notes

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

Considérations relatives à Log Analytics

Notez les points suivants sur Log Analytics.

Télécharger des packs de solutions Log Analytics

Les agents Log Analytics doivent accéder à un compte de stockage global pour télécharger des packs de solutions. Les configurations de liaison privée créées à partir du 19 avril 2021 (ou de juin 2021 sur les clouds souverains Azure) peuvent accéder au stockage de packs de solutions des agents via la liaison privée. Cette fonctionnalité est rendue possible via une zone DNS créée pour blob.core.windows.net.

Si votre installation de liaison privée a été créée avant le 19 avril 2021, elle n’atteindra pas le stockage de packs de solutions via une liaison privée. Pour gérer cela, vous pouvez :

• Recréez votre étendue AMPLS et le point de terminaison privé qui y est connecté.

• Autorisez vos agents à accéder au compte de stockage, via son point de terminaison public, en ajoutant les règles suivantes à la liste d’autorisation de votre pare-feu :

  Environnement cloud	Ressource de l’agent	Ports	Sens
  Azure (public)	scadvisorcontent.blob.core.windows.net	443	Règle de trafic sortant
  Azure Government	usbn1oicore.blob.core.usgovcloudapi.net	443	Règle de trafic sortant
  Microsoft Azure géré par 21Vianet	mceast2oicore.blob.core.chinacloudapi.cn	443	Règle de trafic sortant

Collecter des journaux personnalisés et un journal Internet Information Services (IIS) via une liaison privée

Des comptes de stockage sont utilisés dans le processus d’ingestion de journaux personnalisés. Par défaut, des comptes de stockage gérés par le service sont utilisés. Pour ingérer des journaux personnalisés via des liaisons privées, vous devez utiliser vos propres comptes de stockage et les associer aux espace de travail Log Analytics.

Pour en savoir plus sur la connexion de votre propre compte de stockage, consultez Comptes de stockage appartenant aux clients pour l’ingestion de journaux et, spécifiquement, Utiliser des liens privés et Lier des comptes de stockage à votre espace de travail Log Analytics.

Automatisation

Si vous utilisez des solutions Log Analytics qui requièrent un compte Azure Automation (comme Update Management, Change Tracking ou Inventory), vous devez également créer une liaison privée pour votre compte Automation. Pour plus d’informations, consultez Utiliser Azure Private Link pour connecter en toute sécurité des réseaux à Azure Automation.

Notes

Certains produits et expériences du Portail Azure interrogent les données via Resource Manager. Dans ce cas, ils ne pourront pas interroger les données via une liaison privée, sauf si les paramètres de liaison privée sont également appliqués à Resource Manager. Pour surmonter cette restriction, vous pouvez configurer vos ressources pour qu’elles acceptent les requêtes provenant des réseaux publics, comme cela est expliqué dans Contrôler l’accès réseau à vos ressources. (L’ingestion peut rester limitée aux réseaux de liaison privés.) Nous avons identifié les produits et expériences suivants qui interrogent les espaces de travail via Resource Manager :

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

Considérations du Prometheus managé

• Paramètres d’ingestion Private Link sont créés à l’aide d’AMPLS et des paramètres sur les points de terminaison de la collecte de données (DCE) qui référencent l’espace de travail Azure Monitor utilisé pour stocker vos 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 vos métriques Prometheus et ne sont pas gérés par AMPLS.

Configuration requise

Notez la configuration requise suivante.

Taille de sous-réseau du réseau

Le plus petit sous-réseau IPv4 pris en charge est /27 (à l’aide des définitions de sous-réseaux CIDR). Bien que les réseaux virtuels Azure puissent être aussi petits qu’un sous-réseau /29, Azure réserve cinq adresses IP. La configuration de la liaison privée Azure Monitor nécessite au moins 11 adresses IP supplémentaires, même si vous vous connectez à un seul espace de travail. Passez en revue les paramètres DNS de votre point de terminaison pour obtenir la liste des points de terminaison de la liaison privée Azure Monitor.

Agents

Les versions les plus récentes des agents Windows et Linux doivent être utilisées pour permettre une ingestion sécurisée vers les espaces de travail Log Analytics. Les versions antérieures ne peuvent pas charger les données d’analyse via un réseau privé.

Agents Windows Azure Monitor

Agent Windows Azure Monitor 1.1.1.0 ou une version ultérieure (en utilisant des points de terminaison de collecte de données).

Agents Linux Azure Monitor

Agent Linux Azure Monitor 1.10.5.0 ou une version ultérieure (en utilisant des points de terminaison de collecte de données).

Agent Windows Log Analytics (sur le point d’être déconseillé)

Utilisez la version 10.20.18038.0 ou ultérieure de l’agent Log Analytics.

Agent Linux Log Analytics (sur le point d’être déconseillé)

Utilisez la version 1.12.25 ou une version ultérieure de l’agent. Si cela n’est pas possible, exécutez les commandes suivantes sur votre machine virtuelle :

$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -X
$ sudo /opt/microsoft/omsagent/bin/omsadmin.sh -w <workspace id> -s <workspace key>

Portail Azure

Pour utiliser les expérience du Portail Azure Monitor, telles qu’Application Insights, Log Analytics et les points de terminaison de collecte de données, vous devez autoriser l’accès au Portail Azure et aux extensions Azure Monitor sur les réseaux privés. Ajoutez les étiquettes de serviceAzureActiveDirectory, AzureResourceManager, AzureFrontDoor.FirstParty et AzureFrontdoor.Frontend à votre groupe de sécurité réseau.

Accès par programme

Pour utiliser l’API REST, l’interface Azure CLI ou PowerShell avec Azure Monitor sur des réseaux privés, ajoutez les étiquettes de serviceAzureActiveDirectory et AzureResourceManager à votre pare-feu.

Téléchargement du Kit de développement logiciel (SDK) Application Insights à partir d’un réseau de distribution de contenu

Regroupez le code JavaScript dans votre script afin que le navigateur ne tente pas de télécharger le code à partir d’un réseau de distribution de contenu. Un exemple est disponible sur GitHub.

Paramètres DNS du navigateur

Si vous vous connectez à vos ressources Azure Monitor via une liaison privée, le trafic vers ces ressources doit passer par le point de terminaison privé configuré sur votre réseau. Pour activer le point de terminaison privé, mettez à jour vos paramètres DNS en procédant de la manière décrite dans Se connecter à un point de terminaison privé. Certains navigateurs utilisent leurs propres paramètres DNS à la place de ceux que vous définissez. Le navigateur peut tenter de se connecter à des points de terminaison publics d’Azure Monitor et contourner totalement la liaison privée. Vérifiez que les paramètres de votre navigateur ne remplacent pas ou ne mettent pas en cache d’anciens paramètres DNS.

Limitation d’interrogation : opérateur externaldata

• L’opérateur externaldata n’est pas pris en charge sur une liaison privée, car il lit les données à partir de comptes de stockage, mais ne garantit pas l’accès au stockage de manière privée.
• Le proxy Azure Data Explorer (proxy ADX) permet aux requêtes de journal d’interroger Azure Data Explorer. Le proxy ADX n’est pas pris en charge sur une liaison privée, car il ne garantit pas l’accès à la ressource cible de manière privée.

Étapes suivantes

• Découvrez comment configurer votre liaison privée.
• En savoir plus sur le stockage privé pour les journaux personnalisés et les clés gérées par le client (CMK).
• En savoir plus sur Private Link pour Automation.