De netwerkfirewall configureren voor Azure Monitor SCOM Managed Instance
In dit artikel wordt beschreven hoe u de regels voor netwerkfirewalls en Netwerkbeveiligingsgroepen (NSG) van Azure configureert.
Notitie
Netwerkvereisten
In deze sectie worden netwerkvereisten besproken met drie voorbeelden van netwerkmodellen.
Directe connectiviteit (zichtlijn) tot stand brengen tussen uw domeincontroller en het Azure-netwerk
Zorg ervoor dat er directe netwerkconnectiviteit (zichtlijn) is tussen het netwerk van de gewenste domeincontroller en het Azure-subnet (virtueel netwerk) waar u een exemplaar van SCOM Managed Instance wilt implementeren. Zorg ervoor dat er directe netwerkconnectiviteit (lijn van detectie) is tussen de workloads/agents en het Azure-subnet waarin het beheerde SCOM-exemplaar is geïmplementeerd.
Directe connectiviteit is vereist, zodat al uw volgende resources met elkaar kunnen communiceren via het netwerk:
- Domeincontroller
- Agents
- System Center Operations Manager-onderdelen, zoals de Operations-console
- Onderdelen van SCOM Managed Instance, zoals beheerservers
De volgende drie afzonderlijke netwerkmodellen worden visueel weergegeven om het beheerde SCOM-exemplaar te maken.
Netwerkmodel 1: De domeincontroller bevindt zich on-premises
In dit model bevindt de gewenste domeincontroller zich in uw on-premises netwerk. U moet een Azure ExpressRoute-verbinding tot stand brengen tussen uw on-premises netwerk en het Azure-subnet dat wordt gebruikt voor het beheerde SCOM-exemplaar.
Als uw domeincontroller en ander onderdeel zich on-premises bevinden, moet u de zichtlijn vaststellen via ExpressRoute of een virtueel particulier netwerk (VPN). Zie de ExpressRoute-documentatie en documentatie voor Azure VPN Gateway voor meer informatie.
In het volgende netwerkmodel ziet u waar de gewenste domeincontroller zich in het on-premises netwerk bevindt. Er bestaat een directe verbinding (via ExpressRoute of VPN) tussen het on-premises netwerk en het Azure-subnet dat wordt gebruikt voor het maken van een beheerd SCOM-exemplaar.
Netwerkmodel 2: De domeincontroller wordt gehost in Azure
In deze configuratie wordt de aangewezen domeincontroller gehost in Azure en moet u een ExpressRoute- of VPN-verbinding tot stand brengen tussen uw on-premises netwerk en het Azure-subnet. Het wordt gebruikt voor het maken van het met SCOM beheerde exemplaar en het Azure-subnet dat wordt gebruikt voor de aangewezen domeincontroller. Zie ExpressRoute en VPN Gateway voor meer informatie.
In dit model blijft de gewenste domeincontroller geïntegreerd in uw on-premises domeinforest. U hebt er echter voor gekozen om een toegewezen Active Directory-controller in Azure te maken ter ondersteuning van Azure-resources die afhankelijk zijn van de on-premises Active Directory-infrastructuur.
Netwerkmodel 3: De domeincontroller en SCOM Managed Instances bevinden zich in virtuele Azure-netwerken
In dit model worden zowel de gewenste domeincontroller als de door SCOM beheerde exemplaren in afzonderlijke en toegewezen virtuele netwerken in Azure geplaatst.
Als de gewenste domeincontroller en alle andere onderdelen zich in hetzelfde virtuele netwerk van Azure bevinden (een conventionele actieve domeincontroller) zonder aanwezigheid on-premises, hebt u al een zichtlijn tussen al uw onderdelen.
Als de gewenste domeincontroller en alle andere onderdelen zich in verschillende virtuele netwerken van Azure bevinden (een conventionele actieve domeincontroller) zonder aanwezigheid on-premises, moet u peering van virtuele netwerken uitvoeren tussen alle virtuele netwerken die zich in uw netwerk bevinden. Zie Peering van virtuele netwerken in Azure voor meer informatie.
Zorg voor de volgende problemen voor alle drie de eerder genoemde netwerkmodellen:
Zorg ervoor dat het subnet SCOM Managed Instance verbinding kan maken met de aangewezen domeincontroller die is geconfigureerd voor Azure of SCOM Managed Instance. Zorg er ook voor dat de domeinnaamomzetting binnen het subnet van het beheerde SCOM-exemplaar de aangewezen domeincontroller vermeldt als de bovenste vermelding van de opgeloste domeincontrollers om netwerklatentie of prestatie- en firewallproblemen te voorkomen.
De volgende poorten op de aangewezen domeincontroller en DNS (Domain Name System) moeten toegankelijk zijn vanuit het subnet van het beheerde SCOM-exemplaar:
TCP-poort 389 of 636 voor LDAP
TCP-poort 3268 of 3269 voor globale catalogus
TCP- en UDP-poort 88 voor Kerberos
TCP- en UDP-poort 53 voor DNS
TCP 9389 voor Active Directory-webservice
TCP 445 voor SMB
TCP 135 voor RPC
De interne firewallregels en NSG moeten communicatie vanuit het virtuele SCOM Managed Instance-netwerk en de aangewezen domeincontroller/DNS toestaan voor alle eerder vermelde poorten.
Het virtuele netwerk van Azure SQL Managed Instance en het beheerde SCOM-exemplaar moeten worden gekoppeld om connectiviteit tot stand te brengen. Met name de poort 1433 (privépoort) of 3342 (openbare poort) moet bereikbaar zijn van het beheerde SCOM-exemplaar naar het beheerde SQL-exemplaar. Configureer de NSG-regels en firewallregels op beide virtuele netwerken om poorten 1433 en 3342 toe te staan.
Communicatie toestaan op poorten 5723, 5724 en 443 van de machine die wordt bewaakt naar SCOM Managed Instance.
Als de machine on-premises is, stelt u de NSG-regels en firewallregels in het subnet van het beheerde SCOM-exemplaar in en op het on-premises netwerk waar de bewaakte machine zich bevindt om ervoor te zorgen dat opgegeven essentiële poorten (5723, 5724 en 443) bereikbaar zijn vanaf de bewaakte machine naar het subnet van het beheerde SCOM-exemplaar.
Als de machine zich in Azure bevindt, stelt u de NSG-regels en firewallregels in het virtuele SCOM Managed Instance-netwerk in en op het virtuele netwerk waar de bewaakte machine zich bevindt om ervoor te zorgen dat opgegeven essentiële poorten (5723, 5724 en 443) bereikbaar zijn vanaf de bewaakte machine naar het subnet van het beheerde SCOM-exemplaar.
Firewallvereisten
Om goed te kunnen functioneren, moet SCOM Managed Instance toegang hebben tot het volgende poortnummer en de VOLGENDE URL's. Configureer de NSG- en firewallregels om deze communicatie toe te staan.
| Bron | Poort | Richting | Servicetags | Doel |
|---|---|---|---|---|
| *.blob.core.windows.net | 443 | Uitgaand | Storage | Azure Storage |
| management.azure.com | 443 | Uitgaand | AzureResourceManager | Azure Resource Manager |
| gcs.prod.monitoring.core.windows.net *.prod.warm.ingest.monitor.core.windows.net |
443 | Uitgaand | AzureMonitor | SCOM MI-logboeken |
| *.prod.microsoftmetrics.com *.prod.hot.ingest.monitor.core.windows.net *.prod.hot.ingestion.msftcloudes.com |
443 | Uitgaand | AzureMonitor | Metrische gegevens van SCOM MI |
| *.workloadnexus.azure.com | 443 | Uitgaand | Nexus Service | |
| *.azuremonitor-scommiconnect.azure.com | 443 | Uitgaand | Bridge Service |
Belangrijk
Als u de behoefte aan uitgebreide communicatie met zowel uw Active Directory-beheerder als de netwerkbeheerder wilt minimaliseren, raadpleegt u Zelfverificatie. In het artikel worden de procedures beschreven die de Active Directory-beheerder en de netwerkbeheerder gebruiken om hun configuratiewijzigingen te valideren en ervoor te zorgen dat de implementatie is geslaagd. Dit proces vermindert onnodige back-and-forth interacties van de Operations Manager-beheerder naar de Active Directory-beheerder en de netwerkbeheerder. Met deze configuratie bespaart u tijd voor de beheerders.