A hálózati tűzfal konfigurálása felügyelt Azure Monitor SCOM-példányhoz

Ez a cikk a hálózati tűzfal és az Azure hálózati biztonsági csoport (NSG) szabályainak konfigurálását ismerteti.

Megjegyzés

Az Azure Monitor SCOM felügyelt példány architektúrájának megismeréséhez lásd: Felügyelt Azure Monitor SCOM-példány.

Hálózati előfeltételek

Ez a szakasz három példa hálózati modellel ismerteti a hálózati előfeltételeket.

Közvetlen kapcsolat (látóvonal) létesítése a tartományvezérlő és az Azure-hálózat között

Győződjön meg arról, hogy közvetlen hálózati kapcsolat (látóvonal) van a kívánt tartományvezérlő hálózata és az Azure-alhálózat (virtuális hálózat) között, ahol üzembe szeretné helyezni a felügyelt SCOM-példány egy példányát. Győződjön meg arról, hogy a számítási feladatok/ügynökök és a felügyelt SCOM-példányt üzembe helyező Azure-alhálózat között közvetlen hálózati kapcsolat (látóvonal) van.

Közvetlen kapcsolatra van szükség, hogy az alábbi erőforrások kommunikálhassanak egymással a hálózaton keresztül:

• Tartományvezérlő
• Ügynökök
• System Center Operations Manager-összetevők, például az operatív konzol
• Felügyelt SCOM-példány összetevői, például felügyeleti kiszolgálók

A felügyelt SCOM-példány létrehozásához az alábbi három különböző hálózati modell látható.

1. hálózati modell: A tartományvezérlő a helyszínen található

Ebben a modellben a kívánt tartományvezérlő a helyszíni hálózaton belül található. Létre kell hoznia egy Azure ExpressRoute-kapcsolatot a helyszíni hálózat és a felügyelt SCOM-példányhoz használt Azure-alhálózat között.

Ha a tartományvezérlő és más összetevő helyszíni, a látóvonalat az ExpressRoute-on vagy egy virtuális magánhálózaton (VPN) keresztül kell létrehoznia. További információt az ExpressRoute dokumentációjában és az Azure VPN Gateway dokumentációjában talál.

Az alábbi hálózati modell bemutatja, hogy a kívánt tartományvezérlő hol található a helyszíni hálózaton belül. Közvetlen kapcsolat van (ExpressRoute-on vagy VPN-en keresztül) a helyszíni hálózat és a felügyelt SCOM-példány létrehozásához használt Azure-alhálózat között.

2. hálózati modell: A tartományvezérlő az Azure-ban üzemel

Ebben a konfigurációban a kijelölt tartományvezérlő az Azure-ban üzemel, és ExpressRoute- vagy VPN-kapcsolatot kell létesítenie a helyszíni hálózat és az Azure-alhálózat között. A felügyelt SCOM-példány létrehozásához és a kijelölt tartományvezérlőhöz használt Azure-alhálózathoz használatos. További információ: ExpressRoute és VPN Gateway.

Ebben a modellben a kívánt tartományvezérlő integrálva marad a helyszíni tartományi erdőbe. Azonban úgy döntött, hogy létrehoz egy dedikált Active Directory-vezérlőt az Azure-ban a helyi Active Directory infrastruktúrára támaszkodó Azure-erőforrások támogatásához.

3. hálózati modell: A tartományvezérlő és a felügyelt SCOM-példányok Azure-beli virtuális hálózatokban találhatók

Ebben a modellben a kívánt tartományvezérlő és a felügyelt SCOM-példányok különálló és dedikált virtuális hálózatokba kerülnek az Azure-ban.

Ha a kívánt tartományvezérlő és az összes többi összetevő ugyanabban a virtuális hálózatban található az Azure-ban (egy hagyományos aktív tartományvezérlő), és nincs helyszíni jelenlét, akkor már van egy látóvonal az összes összetevő között.

Ha a kívánt tartományvezérlő és az összes többi összetevő az Azure különböző virtuális hálózataiban (egy hagyományos aktív tartományvezérlőben) található, helyszíni jelenlét nélkül, virtuális hálózatok közötti társviszonyt kell létesítenie a hálózatban található összes virtuális hálózat között. További információ: Virtuális hálózatok közötti társviszony-létesítés az Azure-ban.

A fent említett három hálózatkezelési modell esetében a következő problémákat kell elhárítania:

1. Győződjön meg arról, hogy az SCOM felügyelt példány alhálózata képes kapcsolatot létesíteni az Azure-hoz vagy a felügyelt SCOM-példányhoz konfigurált kijelölt tartományvezérlővel. Győződjön meg arról is, hogy a felügyelt SCOM-példány alhálózatán belüli tartománynévfeloldás a kijelölt tartományvezérlőt listázza a megoldott tartományvezérlők között a hálózati késés, a teljesítmény- és tűzfalproblémák elkerülése érdekében.

2. A kijelölt tartományvezérlő és a tartománynévrendszer (DNS) következő portjának elérhetőnek kell lennie a felügyelt SCOM-példány alhálózatáról:

   • 389-ös VAGY 636-os TCP-port LDAP-hoz

   • 3268-os vagy 3269-ös TCP-port globális katalógushoz

   • 88-os TCP- és UDP-port Kerberoshoz

   • 53-ás TCP- és UDP-port DNS-hez

   • TCP 9389 az Active Directory webszolgáltatáshoz

   • TCP 445 az SMB-hez

   • TCP 135 az RPC-hez

     A belső tűzfalszabályoknak és az NSG-nek engedélyeznie kell a kommunikációt az SCOM felügyelt példány virtuális hálózatáról és a kijelölt tartományvezérlőről/DNS-ről a korábban felsorolt összes porton.

3. A kapcsolat létesítéséhez társviszonyt kell létesíteni a Azure SQL Managed Instance virtuális hálózattal és az SCOM felügyelt példányával. Pontosabban az 1433-at (privát port) vagy a 3342-t (nyilvános portot) el kell érni az SCOM felügyelt példányról a felügyelt SQL-példányra. Konfigurálja az NSG-szabályokat és a tűzfalszabályokat mindkét virtuális hálózaton, hogy engedélyezze az 1433-at és a 3342-et.

4. Engedélyezze a kommunikációt az 5723-at, az 5724-et és a 443-at a monitorozott gépről a felügyelt SCOM-példány felé.

   • Ha a gép helyszíni, állítsa be az NSG-szabályokat és tűzfalszabályokat a felügyelt SCOM-példány alhálózatán és azon a helyszíni hálózaton, ahol a figyelt gép található, hogy a megadott alapvető portok (5723, 5724 és 443) elérhetők legyenek a figyelt gépről az SCOM felügyelt példány alhálózatára.

   • Ha a gép az Azure-ban található, állítsa be az NSG-szabályokat és tűzfalszabályokat a felügyelt SCOM-példány virtuális hálózatán és azon a virtuális hálózaton, ahol a figyelt gép található, hogy a megadott alapvető portok (5723, 5724 és 443) elérhetők legyenek a figyelt gépről a felügyelt SCOM-példány alhálózatára.

Tűzfalkövetelmények

A megfelelő működéshez a felügyelt SCOM-példánynak hozzáféréssel kell rendelkeznie a következő portszámhoz és URL-címekhez. Konfigurálja az NSG- és tűzfalszabályokat a kommunikáció engedélyezéséhez.

Erőforrás	Port	Irány	Szolgáltatáscímkék	Cél
*.blob.core.windows.net	443	Kimenő	Tárolás	Azure Storage
management.azure.com	443	Kimenő	AzureResourceManager	Azure Resource Manager
gcs.prod.monitoring.core.windows.net *.prod.warm.ingest.monitor.core.windows.net	443	Kimenő	AzureMonitor	SCOM MI-naplók
*.prod.microsoftmetrics.com *.prod.hot.ingest.monitor.core.windows.net *.prod.hot.ingestion.msftcloudes.com	443	Kimenő	AzureMonitor	SCOM MI-metrikák
*.workloadnexus.azure.com	443	Kimenő		Nexus szolgáltatás
*.azuremonitor-scommiconnect.azure.com	443	Kimenő		Bridge Service

Fontos

Az Active Directory-rendszergazdával és a hálózati rendszergazdával folytatott kiterjedt kommunikáció minimálisra csökkentése érdekében lásd: Önellenőrzés. A cikk ismerteti azokat az eljárásokat, amelyeket az Active Directory-rendszergazda és a hálózati rendszergazda a konfigurációs módosítások ellenőrzésére és sikeres implementálásuk biztosítására használ. Ez a folyamat csökkenti az Operations Manager-rendszergazda és az Active Directory-rendszergazda és a hálózati rendszergazda közötti szükségtelen oda-vissza interakciókat. Ez a konfiguráció időt takarít meg a rendszergazdák számára.

Következő lépések

• Az Azure és a belső csoportházirend-objektumok szabályzatának ellenőrzése