Configurer le pare-feu réseau pour l’instance SCOM gérée d’Azure Monitor

Cet article explique comment configurer le pare-feu réseau et les règles de groupe de sécurité réseau Azure.

Remarque

Pour en savoir plus sur l’architecture de l’instance SCOM gérée d’Azure Monitor, consultez Instance SCOM gérée d’Azure Monitor.

Configuration réseau requise

Cette section décrit les prérequis réseau avec trois exemples de modèle réseau.

Établir une connectivité directe (ligne de vue) entre votre contrôleur de domaine et le réseau Azure

Vérifiez la connectivité réseau directe (ligne de vue) entre le réseau de votre contrôleur de domaine souhaité et le sous-réseau Azure (réseau virtuel) où vous souhaitez déployer une instance SCOM gérée. Vérifiez la connectivité réseau directe (ligne de vue) entre les charges de travail/agents et le sous-réseau Azure dans lequel l’instance SCOM gérée est déployée.

La connectivité directe est requise pour que toutes vos ressources suivantes puissent communiquer entre elles sur le réseau :

• Contrôleur de domaine
• Agents
• Composants SCOM, tels que la console Opérations
• Composants de l’instance SCOM gérée, tels que les serveurs d’administration

Les trois modèles de réseau distincts suivants sont visuellement représentés pour créer l’instance SCOM gérée.

Modèle de réseau 1 : le contrôleur de domaine se trouve en local

Dans ce modèle, le contrôleur de domaine souhaité se trouve dans votre réseau local. Vous devez établir une connexion Azure ExpressRoute entre votre réseau local et le sous-réseau Azure utilisé pour l’instance SCOM gérée.

Si votre contrôleur de domaine et d’autres composants sont locaux, vous devez établir la ligne de vue via ExpressRoute ou un réseau privé virtuel (VPN). Pour plus d’informations, consultez la documentation ExpressRoute et la documentation sur la passerelle VPN Azure.

Le modèle de réseau suivant montre où se trouve le contrôleur de domaine souhaité dans le réseau local. Une connexion directe existe (via ExpressRoute ou VPN) entre le réseau local et le sous-réseau Azure utilisé pour la création de l’instance SCOM gérée.

Modèle de réseau 2 : le contrôleur de domaine est hébergé dans Azure

Dans cette configuration, le contrôleur de domaine désigné est hébergé dans Azure et vous devez établir une connexion ExpressRoute ou VPN entre votre réseau local et le sous-réseau Azure. Il est utilisé pour la création de l’instance SCOM gérée et le sous-réseau Azure utilisé pour le contrôleur de domaine désigné. Pour plus d’informations, consultez ExpressRoute et la passerelle VPN.

Dans ce modèle, le contrôleur de domaine souhaité reste intégré à votre forêt de domaines locale. Toutefois, vous avez choisi de créer un contrôleur Active Directory dédié dans Azure pour prendre en charge les ressources Azure qui s’appuient sur l’infrastructure Active Directory locale.

Modèle de réseau 3 : le contrôleur de domaine et les instances SCOM gérées se trouvent dans des réseaux virtuels Azure

Dans ce modèle, le contrôleur de domaine souhaité et les instances SCOM gérées sont placés dans des réseaux virtuels distincts et dédiés dans Azure.

Si le contrôleur de domaine souhaité et tous les autres composants se trouvent dans le même réseau virtuel d’Azure (un contrôleur de domaine actif conventionnel) sans présence locale, vous disposez déjà d’une ligne de vue entre tous vos composants.

Si le contrôleur de domaine souhaité et tous les autres composants se trouvent dans différents réseaux virtuels d’Azure (un contrôleur de domaine actif conventionnel) sans présence locale, vous devez effectuer un appairage de réseaux entre tous les réseaux virtuels de votre réseau. Pour plus d’informations, consultez Appairage de réseaux virtuels dans Azure.

Prenez soin des problèmes suivants pour les trois modèles de mise en réseau mentionnés précédemment :

1. Vérifiez que le sous-réseau de l’instance SCOM gérée peut établir la connectivité au contrôleur de domaine désigné configuré pour Azure ou l’instance SCOM gérée. Assurez-vous également que la résolution de noms de domaine dans le sous-réseau de l’instance SCOM gérée répertorie le contrôleur de domaine désigné comme entrée supérieure parmi les contrôleurs de domaine résolus pour éviter des problèmes de latence réseau, de performances ou de pare-feu.

2. Les ports suivants sur le contrôleur de domaine désigné et le DNS doivent être accessibles à partir du sous-réseau de l’instance SCOM gérée :

   • Port TCP 389 ou 636 pour LDAP

   • Port TCP 3268 ou 3269 pour le catalogue global

   • Port TCP et UDP 88 pour Kerberos

   • Port TCP et UDP 53 pour DNS

   • Port TCP 9389 pour le service web Active Directory

   • Port TCP 445 pour SMB

   • Port TCP 135 pour RPC

     Les règles de pare-feu internes et le groupe de sécurité réseau doivent autoriser la communication à partir du réseau virtuel de l’instance SCOM gérée et du contrôleur de domaine/DNS désigné pour tous les ports répertoriés précédemment.

3. Le réseau virtuel Azure SQL Managed Instance et l’instance SCOM gérée doivent être appairés pour établir la connectivité. Plus précisément, le port 1433 (port privé) ou 3342 (port public) doit être accessible de l’instance SCOM gérée à l’instance managée SQL. Configurez les règles de groupe de sécurité réseau et les règles de pare-feu sur les deux réseaux virtuels pour autoriser les ports 1433 et 3342.

4. Autorisez la communication sur les ports 5723, 5724 et 443 de la machine surveillée vers l’instance SCOM gérée.

   • Si la machine est locale, configurez les règles de groupe de sécurité réseau et les règles de pare-feu sur le sous-réseau de l’instance SCOM gérée et sur le réseau local où se trouve l’ordinateur surveillé pour garantir que les ports essentiels spécifiés (5723, 5724 et 443) sont accessibles de l’ordinateur surveillé au sous-réseau de l’instance SCOM gérée.

   • Si la machine se trouve dans Azure, configurez les règles de groupe de sécurité réseau et les règles de pare-feu sur le réseau virtuel de l’instance SCOM gérée et sur le réseau virtuel où se trouve la machine surveillée pour garantir que les ports essentiels spécifiés (5723, 5724 et 443) sont accessibles de la machine surveillée au sous-réseau de l’instance SCOM gérée.

Configuration requise du pare-feu

Pour fonctionner correctement, l’instance SCOM gérée doit avoir accès au numéro de port et aux URL suivants. Configurez les règles de groupe de sécurité réseau et de pare-feu pour autoriser cette communication.

Ressource	Port	Direction	Étiquettes de service	Objectif
*.blob.core.windows.net	443	Règle de trafic sortant	Stockage	Stockage Azure
management.azure.com	443	Règle de trafic sortant	AzureResourceManager	Azure Resource Manager
gcs.prod.monitoring.core.windows.net *.prod.warm.ingest.monitor.core.windows.net	443	Règle de trafic sortant	AzureMonitor	Journaux SCOM MI
*.prod.microsoftmetrics.com *.prod.hot.ingest.monitor.core.windows.net *.prod.hot.ingestion.msftcloudes.com	443	Règle de trafic sortant	AzureMonitor	Métriques SCOM MI
*.workloadnexus.azure.com	443	Règle de trafic sortant		Service Nexus
*.azuremonitor-scommiconnect.azure.com	443	Règle de trafic sortant		Service de pont

Important

Pour réduire au minimum la nécessité d’une communication détaillée avec votre administrateur Active Directory et avec l’administrateur réseau, consultez Auto-vérification. L’article décrit les procédures utilisées par l’administrateur Active Directory et par l’administrateur réseau pour valider les modifications qu’ils apportent à la configuration et pour garantir la réussite de leur implémentation. Ce processus réduit les allers-retours inutiles entre l’administrateur Operations Manager, l’administrateur Active Directory et l’administrateur réseau. Cette configuration permet aux administrateurs de gagner du temps.

Étapes suivantes

• Vérifier les stratégies GPO Azure et internes