Zéró megbízhatóságú hálózat webalkalmazásokhoz az Azure Firewall és az Application Gateway használatával

Ez az útmutató egy stratégiát vázol fel a zéró megbízhatóságú biztonság bevezetésére a webalkalmazások számára az ellenőrzéshez és a titkosításhoz. A nulla megbízhatósági paradigma számos egyéb fogalmat is tartalmaz, például a szereplők identitásának állandó ellenőrzését vagy az implicit megbízhatósági területek méretének minimálisra csökkentését. Ez a cikk a nyilvános internetről bejövő forgalom nulla megbízhatóságú architektúrájának titkosítási és ellenőrzési összetevőjére vonatkozik. Olvassa el az alkalmazás biztonságos üzembe helyezésének további szempontjait, például a hitelesítést. A cikk alkalmazásában a többrétegű megközelítés működik a legjobban, ahol a hálózati biztonság a nulla megbízhatósági modell egyik rétegét alkotja. Ebben a rétegben a hálózati berendezések ellenőrzik a csomagokat, hogy csak a jogszerű forgalom érje el az alkalmazásokat.

A hálózati berendezések különböző típusai általában a hálózati csomagok különböző aspektusait vizsgálják:

• A webalkalmazási tűzfalak olyan mintákat keresnek, amelyek támadást jeleznek a webalkalmazás rétegében.
• A következő generációs tűzfalak általános fenyegetéseket is kereshetnek.

Bizonyos esetekben különböző típusú hálózati biztonsági berendezéseket kombinálhat a védelem növelése érdekében. A tűzfal és az Application Gateway a virtuális hálózatokhoz külön útmutató, amely a különböző berendezések elrendezéséhez használható tervezési mintákat ismerteti. Ez a dokumentum a biztonság maximalizálásának általános mintájára összpontosít, amelyben Azure-alkalmazás Átjáró az Azure Firewall Premium előtt működik. Az alábbi ábra a következő mintát szemlélteti:

Töltse le az architektúra Visio-fájlját.

Ez az architektúra a Transport Layer Security (TLS) protokollt használja a forgalom titkosítására minden lépésnél.

• Az ügyfél csomagokat küld az Application Gatewaynek, egy terheléselosztónak. Az opcionális azure-webalkalmazási tűzfallal fut.

• Az Application Gateway visszafejti a csomagokat, és megkeresi a webalkalmazásokat fenyegető fenyegetéseket. Ha nem talál fenyegetést, a csomagok titkosításához nulla megbízhatósági elveket használ. Ezután felszabadítja őket.

• Az Azure Firewall Premium biztonsági ellenőrzéseket futtat:

  • A Transport Layer Security (TLS) vizsgálata visszafejti és megvizsgálja a csomagokat.
  • A behatolásészlelési és védelmi funkciók rosszindulatú szándékot keresnek a csomagokban.

• Ha a csomagok átmennek a teszteken, az Azure Firewall Premium a következő lépéseket végzi el:

  • A csomagok titkosítása
  • Domain Name System (DNS) szolgáltatást használ az alkalmazás virtuális gépének (VM) meghatározásához
  • A csomagok továbbítása az alkalmazás virtuális gépére

Az architektúra különböző ellenőrző motorjai biztosítják a forgalom integritását:

• A webalkalmazási tűzfal szabályokkal akadályozza meg a webes réteg támadásait. Ilyen például az SQL-kódinjektálás és a helyek közötti szkriptelés. A szabályokról és az Open Web Application Security Project (OWASP) alapvető szabálykészletéről további információt a webalkalmazási tűzfal CRS-szabálycsoportjaiban és szabályaiban talál.
• Az Azure Firewall Premium általános behatolásészlelési és megelőzési szabályokat használ. Ezek a szabályok segítenek azonosítani a webalkalmazásokat célzó rosszindulatú fájlokat és egyéb fenyegetéseket.

Ez az architektúra támogatja a hálózattervezés különböző típusait, amelyekről ez a cikk a következőket ismerteti:

• Hagyományos küllős hálózatok
• Az Azure Virtual WAN-t platformként használó hálózatok
• Az Azure Route Servert használó hálózatok a dinamikus útválasztás egyszerűsítése érdekében

Prémium szintű Azure Firewall és névfeloldás

A rosszindulatú forgalom ellenőrzésekor az Azure Firewall Premium ellenőrzi, hogy a HTTP-gazdagép fejléce megegyezik-e a csomag IP-címével és a TCP-portmal. Tegyük fel például, hogy az Application Gateway webes csomagokat küld a 172.16.1.4 IP-címre és a 443-at tartalmazó TCP-portra. A HTTP-gazdagép fejlécének értékét az adott IP-címre kell feloldani.

A HTTP-gazdagép fejlécei általában nem tartalmaznak IP-címeket. A fejlécek ehelyett a kiszolgáló digitális tanúsítványának megfelelő neveket tartalmaznak. Ebben az esetben az Azure Firewall Premium DNS használatával oldja fel a gazdagép fejlécének nevét egy IP-címre. A hálózati kialakítás határozza meg, hogy melyik DNS-megoldás működik a legjobban, ahogy azt a későbbi szakaszok ismertetik.

Digitális tanúsítványok

Az alábbi ábrán az architektúra TLS-munkamenetei és tanúsítványai által használt köznapi nevek (CN-ek) és hitelesítésszolgáltatók (CA-k) láthatók:

TLS-kapcsolatok

Ez az architektúra három különböző TLS-kapcsolatot tartalmaz. A digitális tanúsítványok mindegyiket ellenőrzik:

Ügyfelektől az Application Gatewayig

Az Application Gatewayben üzembe helyezi az ügyfelek által látott digitális tanúsítványt. Egy jól ismert hitelesítésszolgáltató, például a DigiCert vagy a Let's Encrypt általában ilyen tanúsítványt ad ki.

Az Application Gatewaytől az Azure Firewall Premiumig

A TLS-forgalom visszafejtéséhez és vizsgálatához az Azure Firewall Premium dinamikusan hoz létre tanúsítványokat. Az Azure Firewall Premium webkiszolgálóként az Application Gatewaynek is bemutatja magát. Egy privát hitelesítésszolgáltató aláírja az Azure Firewall Premium által létrehozott tanúsítványokat. További információ: Azure Firewall Premium-tanúsítványok. Az Application Gatewaynek ellenőriznie kell ezeket a tanúsítványokat. Az alkalmazás HTTP-beállításaiban konfigurálja az Azure Firewall Premium által használt legfelső szintű hitelesítésszolgáltatót.

Az Azure Firewall Premiumtól a webkiszolgálóig

Az Azure Firewall Premium TLS-munkamenetet hoz létre a cél webkiszolgálóval. Az Azure Firewall Premium ellenőrzi, hogy egy jól ismert hitelesítésszolgáltató aláírja-e a webkiszolgáló TLS-csomagjait.

Összetevőszerepkörök

Az Application Gateway és az Azure Firewall Premium eltérően kezeli a tanúsítványokat, mivel szerepkörük eltér:

• Az Application Gateway egy fordított webes proxy. HTTP- és HTTPS-kérések elfogásával védi a webkiszolgálókat a rosszindulatú ügyfelektől. Minden védett kiszolgálót deklarál, amely az Application Gateway háttérkészletében található az IP-címével vagy teljes tartománynevével. A jogos ügyfeleknek képesnek kell lenniük az egyes alkalmazások elérésére. Így az Application Gatewayt egy nyilvános hitelesítésszolgáltató által aláírt digitális tanúsítvánnyal konfigurálhatja. Használjon olyan hitelesítésszolgáltatót, amelyet bármely TLS-ügyfél elfogad.
• Az Azure Firewall Premium egy webes proxy , vagy egyszerűen egy webes proxy. Védi az ügyfeleket a rosszindulatú webkiszolgálóktól azáltal, hogy elfogja a TLS-hívásokat a védett ügyfelektől. Ha egy védett ügyfél HTTP-kérést küld, a továbbítási proxy megszemélyesíti a cél webkiszolgálót digitális tanúsítványok létrehozásával és az ügyfélnek való bemutatásával. Az Azure Firewall Premium egy privát hitelesítésszolgáltatót használ, amely aláírja a dinamikusan létrehozott tanúsítványokat. A védett ügyfeleket úgy konfigurálja, hogy megbízzanak a magánhálózati hitelesítésszolgáltatóban. Ebben az architektúrában az Azure Firewall Premium az Application Gatewayről a webkiszolgálóra irányuló kérelmeket védi. Az Application Gateway megbízik az Azure Firewall Premium által használt privát hitelesítésszolgáltatóban.

Útválasztás és forgalomátirányítás

Az útválasztás a hálózat kialakításának topológiájától függően kissé eltérő lesz, a következő szakaszok a Küllős, a Virtual WAN és az Útvonalkiszolgáló topológia példáinak részleteit ismertetik. Vannak azonban olyan szempontok, amelyek minden topológiában gyakoriak:

• Azure-alkalmazás Átjáró mindig proxyként viselkedik, és az Azure Firewall Premium is ezt teszi, ha TLS-vizsgálatra van konfigurálva: az ügyfelek TLS-munkameneteit az Application Gateway leállítja, az új TLS-munkamenetek pedig az Azure Firewall felé épülnek. Az Azure Firewall megkapja és leállítja az Application Gatewayről származó TLS-munkameneteket, és új TLS-munkameneteket hoz létre a számítási feladatok felé. Ez a tény hatással van az Azure Firewall Premium IDPS-konfigurációjára, az alábbi szakaszok további részleteket tartalmaznak erről.
• A számítási feladat az Azure Firewall alhálózati IP-címéről érkező kapcsolatokat fogja látni. Az eredeti ügyfél IP-címe megmarad az X-Forwarded-For Application Gateway által beszúrt HTTP-fejlécben.
• Az Application Gatewayről a számítási feladatra irányuló forgalmat általában azure-beli útválasztási mechanizmusokkal küldik el az Azure Firewallnak, akár az Application Gateway alhálózatában konfigurált felhasználó által megadott útvonalakkal, akár az Azure Virtual WAN vagy az Azure Route Server által injektált útvonalakkal. Bár az Azure Firewall privát IP-címének explicit meghatározása az Application Gateway háttérkészletében lehetséges, technikailag nem ajánlott, mivel elveszik az Azure Firewall néhány funkcióját, például a terheléselosztást és a ragadósságot.

Az alábbi szakaszok részletesen ismertetik az Azure Firewall és az Application Gateway által használt leggyakoribb topológiákat.

Küllős topológia

A küllős és a küllős kialakítás általában a küllők megosztott hálózati összetevőit helyezi üzembe a központi virtuális hálózaton, és alkalmazásspecifikus összetevőket a küllőkben. A legtöbb rendszerben az Azure Firewall Premium megosztott erőforrás. A webalkalmazási tűzfal azonban lehet megosztott hálózati eszköz vagy alkalmazásspecifikus összetevő. A következő okok miatt általában a legjobb, ha az Application Gatewayt alkalmazás-összetevőként kezeli, és küllős virtuális hálózaton helyezi üzembe:

• A webalkalmazási tűzfal riasztásai nehezen háríthatók el. Általában alapos ismeretekre van szüksége az alkalmazásról annak eldöntéséhez, hogy a riasztásokat kiváltó üzenetek jogosak-e.
• Ha megosztott erőforrásként kezeli az Application Gatewayt, előfordulhat, hogy túllépi Azure-alkalmazás átjáró korlátait.
• Szerepköralapú hozzáférés-vezérlési problémákat tapasztalhat, ha az Application Gatewayt a központban helyezi üzembe. Ez a helyzet akkor merülhet fel, ha a csapatok különböző alkalmazásokat kezelnek, de ugyanazt az Application Gateway-példányt használják. Ezután minden csapat hozzáfér a teljes Application Gateway-konfigurációhoz.

A hagyományos központ- és küllős architektúráknak megfelelően a DNS privát zónái megkönnyítik a DNS használatát:

• Privát DNS-zóna konfigurálása.
• Kapcsolja a zónát a prémium szintű Azure Firewallt tartalmazó virtuális hálózathoz.
• Ellenőrizze, hogy létezik-e A rekord az Application Gateway által a forgalomhoz és az állapot-ellenőrzésekhez használt értékhez.

Az alábbi ábra a csomagfolyamatot mutatja be, amikor az Application Gateway küllős virtuális hálózaton van. Ebben az esetben az ügyfél a nyilvános internetről csatlakozik.

1. Az ügyfél kérést küld egy webkiszolgálónak.
2. Az Application Gateway elfogja az ügyfélcsomagokat, és megvizsgálja őket. Ha a csomagok átmennek az ellenőrzésen, az Application Gateway elküldi a csomagot a háttérbeli virtuális gépnek. Amikor a csomag eléri az Azure-t, az Application Gateway alhálózatának felhasználó által megadott útvonala (UDR) továbbítja a csomagokat az Azure Firewall Premiumnak.
3. Az Azure Firewall Premium biztonsági ellenőrzéseket futtat a csomagokon. Ha átadják a teszteket, az Azure Firewall Premium továbbítja a csomagokat az alkalmazás virtuális gépének.
4. A virtuális gép válaszol, és beállítja a cél IP-címet az Application Gatewaynek. A virtuálisgép-alhálózat egyik UDR-je átirányítja a csomagokat az Azure Firewall Premiumba.
5. Az Azure Firewall Premium továbbítja a csomagokat az Application Gatewaynek.
6. Az Application Gateway válaszol az ügyfélre.

A forgalom a nyilvános internet helyett helyszíni hálózatról is érkezhet. A forgalom egy helyek közötti virtuális magánhálózaton (VPN) vagy az ExpressRoute-on keresztül áramlik. Ebben a forgatókönyvben a forgalom először egy virtuális hálózati átjárót ér el a központban. A többi hálózati folyamat megegyezik az előző esetével.

1. Egy helyszíni ügyfél csatlakozik a virtuális hálózati átjáróhoz.
2. Az átjáró továbbítja az ügyfélcsomagokat az Application Gatewaynek.
3. Az Application Gateway megvizsgálja a csomagokat. Ha átesnek az ellenőrzésen, az Application Gateway alhálózatán található UDR továbbítja a csomagokat az Azure Firewall Premiumnak.
4. Az Azure Firewall Premium biztonsági ellenőrzéseket futtat a csomagokon. Ha átadják a teszteket, az Azure Firewall Premium továbbítja a csomagokat az alkalmazás virtuális gépének.
5. A virtuális gép válaszol, és beállítja a cél IP-címét az Application Gatewayre. A virtuálisgép-alhálózat egyik UDR-je átirányítja a csomagokat az Azure Firewall Premiumba.
6. Az Azure Firewall Premium továbbítja a csomagokat az Application Gatewaynek.
7. Az Application Gateway elküldi a csomagokat a virtuális hálózati átjárónak.
8. Az átjáró válaszol az ügyfélre.

Virtual WAN-topológia

Ebben az architektúrában a Virtual WAN hálózati szolgáltatást is használhatja. Ez az összetevő számos előnnyel jár. Például szükségtelenné teszi a felhasználó által karbantartott UDR-ek szükségességét a küllős virtuális hálózatokban. Ehelyett statikus útvonalakat határozhat meg a virtuális központ útvonaltábláiban. A központhoz csatlakozó összes virtuális hálózat programozása ezeket az útvonalakat tartalmazza.

Ha a Virtual WAN-t hálózati platformként használja, két fő különbséget eredményez:

• A DNS privát zónái nem kapcsolhatók virtuális központhoz, mert a Microsoft felügyeli a virtuális központokat. Az előfizetés tulajdonosaként nincs engedélye a privát DNS-zónák összekapcsolására. Emiatt nem társíthat DNS-privát zónát a prémium szintű Azure Firewallt tartalmazó biztonságos központhoz. Az Azure Firewall Premium DNS-feloldási megoldásának implementálásához használja inkább a DNS-kiszolgálókat:

  • Konfigurálja az Azure Firewall DNS-Gépház egyéni DNS-kiszolgálók használatára.
  • Helyezze üzembe a kiszolgálókat a virtuális WAN-hoz csatlakozó megosztott szolgáltatások virtuális hálózatában.
  • Privát DNS-zóna csatolása a megosztott szolgáltatások virtuális hálózatához. A DNS-kiszolgálók ezután feloldhatják az Application Gateway által a HTTP-gazdagép fejléceiben használt neveket. További információ: Azure Firewall DNS Gépház.

• A Virtual WAN használatával csak akkor programozza az útvonalakat küllőben, ha az előtag rövidebb (kevésbé specifikus), mint a virtuális hálózati előtag. A küllős virtuális hálózat fenti ábráiban például a 172.16.0.0/16 előtag található: ebben az esetben A Virtual WAN nem tud olyan útvonalat injektálni, amely megfelel a VNet előtagjának (172.16.0.0/16) vagy valamelyik alhálózatnak (172.16.0.0/24, 172.16.1.0/24). Más szóval a Virtual WAN nem tud forgalmat vonzani két alhálózat között, amelyek ugyanabban a virtuális hálózatban találhatók. Ez a korlátozás akkor válik nyilvánvalóvá, ha az Application Gateway és a cél webkiszolgáló ugyanabban a virtuális hálózatban van: a Virtual WAN nem tudja kényszeríteni az Application Gateway és a webkiszolgáló közötti forgalmat az Azure Firewall Premiumon való áthaladásra (a megkerülő megoldás a felhasználó által megadott útvonalak manuális konfigurálása az Application Gateway és a webkiszolgáló alhálózatain).

Az alábbi ábra a Virtual WAN-t használó eset csomagfolyamatát mutatja be. Ebben az esetben az Application Gatewayhez való hozzáférés helyszíni hálózatról történik. Egy helyek közötti VPN vagy ExpressRoute csatlakoztatja a hálózatot a Virtual WAN-hoz. Az internetről való hozzáférés hasonló.

1. Egy helyszíni ügyfél csatlakozik a VPN-hez.
2. A VPN továbbítja az ügyfélcsomagokat az Application Gatewaynek.
3. Az Application Gateway megvizsgálja a csomagokat. Ha átesnek az ellenőrzésen, az Application Gateway alhálózata továbbítja a csomagokat az Azure Firewall Premiumnak.
4. Az Azure Firewall Premium DNS-feloldási kérést kér egy DNS-kiszolgálótól a megosztott szolgáltatások virtuális hálózatában.
5. A DNS-kiszolgáló válaszol a megoldási kérelemre.
6. Az Azure Firewall Premium biztonsági ellenőrzéseket futtat a csomagokon. Ha átadják a teszteket, az Azure Firewall Premium továbbítja a csomagokat az alkalmazás virtuális gépének.
7. A virtuális gép válaszol, és beállítja a cél IP-címét az Application Gatewayre. Az alkalmazás alhálózata átirányítja a csomagokat az Azure Firewall Premium szolgáltatásba.
8. Az Azure Firewall Premium továbbítja a csomagokat az Application Gatewaynek.
9. Az Application Gateway elküldi a csomagokat a VPN-nek.
10. A VPN választ ad az ügyfélnek.

Ezzel a kialakítással előfordulhat, hogy módosítania kell az útválasztást, amelyet a központ hirdet a küllős virtuális hálózatokon. Az Application Gateway 2-es verzió csak egy 0.0.0.0/0-s útvonalat támogat, amely az internetre mutat. Az ilyen címmel rendelkező útvonalak, amelyek nem az internetre mutatnak, megszakítják a Microsoft által az Application Gateway kezeléséhez szükséges kapcsolatot. Ha a virtuális központ 0.0.0.0/0-s útvonalat hirdet, az alábbi lépések egyikével megakadályozhatja, hogy az útvonal propagálása az Application Gateway alhálózatra terjedjen:

• Hozzon létre egy útvonaltáblát a 0.0.0.0/0 útvonallal és a következő ugrástípussal Internet. Társítsa ezt az útvonalat azzal az alhálózattal, amelyben az Application Gatewayt üzembe helyezi.
• Ha dedikált küllőben helyezi üzembe az Application Gatewayt, tiltsa le az alapértelmezett útvonal propagálását a virtuális hálózati kapcsolat beállításai között.

Útvonalkiszolgáló topológiája

A Route Server egy másik módot kínál az útvonalak automatikus beszúrására küllőkben. Ezzel a funkcióval elkerülheti az útvonaltáblák karbantartásának adminisztratív többletterhelését. A Route Server egyesíti a Virtual WAN és a küllős változatokat:

• A Route Serverrel az ügyfelek a központi virtuális hálózatokat kezelik. Ennek eredményeképpen összekapcsolhatja a központi virtuális hálózatot egy PRIVÁT DNS-zónával.
• Az útválasztási kiszolgálóra ugyanazok a korlátozások vonatkoznak, mint a Virtual WAN az IP-címelőtagokra. Csak akkor szúrhat be útvonalakat küllőbe, ha az előtag rövidebb (kevésbé specifikus), mint a virtuális hálózati előtag. A korlátozás miatt az Application Gatewaynek és a cél webkiszolgálónak különböző virtuális hálózatokban kell lennie.

Az alábbi ábra a csomagfolyamatot mutatja be, amikor az Útválasztási kiszolgáló leegyszerűsíti a dinamikus útválasztást. Jegyezze fel az alábbi pontokat:

• Az útválasztási kiszolgálónak jelenleg az az eszközre van szüksége, amely injektálja az útvonalakat a Border Gateway Protocol (BGP) protokollon keresztüli küldéshez. Mivel az Azure Firewall Premium nem támogatja a BGP-t, használjon inkább egy külső hálózati virtuális berendezést (NVA).
• A központi NVA funkciója határozza meg, hogy az implementációnak SZÜKSÉGE van-e DNS-re.

1. Egy helyszíni ügyfél csatlakozik a virtuális hálózati átjáróhoz.
2. Az átjáró továbbítja az ügyfélcsomagokat az Application Gatewaynek.
3. Az Application Gateway megvizsgálja a csomagokat. Ha átmennek az ellenőrzésen, az Application Gateway alhálózata továbbítja a csomagokat egy háttérgépnek. Az ApplicationGateway alhálózatban az útvonalkiszolgáló által injektált útvonal továbbítja a forgalmat egy NVA-nak.
4. Az NVA biztonsági ellenőrzéseket futtat a csomagokon. Ha átadják a teszteket, az NVA továbbítja a csomagokat az alkalmazás virtuális gépének.
5. A virtuális gép válaszol, és beállítja a cél IP-címét az Application Gatewayre. Az útválasztási kiszolgáló által a virtuálisgép-alhálózatba injektált útvonal átirányítja a csomagokat az NVA-ba.
6. Az NVA továbbítja a csomagokat az Application Gatewaynek.
7. Az Application Gateway elküldi a csomagokat a virtuális hálózati átjárónak.
8. Az átjáró válaszol az ügyfélre.

A Virtual WAN-hoz hasonlóan előfordulhat, hogy módosítania kell az útválasztást az útválasztási kiszolgáló használatakor. Ha meghirdeti a 0.0.0.0/0 útvonalat, az az Application Gateway alhálózatára is propagálásra kerülhet. Az Application Gateway azonban nem támogatja ezt az útvonalat. Ebben az esetben konfiguráljon egy útvonaltáblát az Application Gateway alhálózatához. Adja meg a 0.0.0.0/0 útvonalát és a következő ugrás típusát Internet a táblában.

IDPS és privát IP-címek

Az Azure Firewall IDPS-szabályaiban leírtak szerint az Azure Firewall Premium a csomagok forrás- és cél IP-címétől függően dönti el, hogy mely IDPS-szabályokat kell alkalmaznia. Az Azure Firewall az RFC 1918 tartomány (és 172.16.0.0/12) és az RFC 659810.0.0.0/8192.168.0.0/16 tartomány (100.64.0.0/10) alapértelmezett privát IP-címeit belsőként kezeli. Következésképpen, ha a jelen cikkben szereplő ábrákhoz hasonlóan az Application Gateway ezen tartományok172.16.0.0/24 valamelyikében (a fenti példákban) egy alhálózatban van üzembe helyezve, az Azure Firewall Premium belsőnek tekinti az Application Gateway és a számítási feladat közötti forgalmat, és csak a belső forgalomra vagy a forgalomra való alkalmazásra megjelölt IDPS-aláírásokat fogja használni. A bejövő vagy kimenő forgalomra alkalmazandó IDPS-aláírások nem lesznek alkalmazva az Application Gateway és a számítási feladat közötti forgalomra.

Az IDPS bejövő aláírási szabályok alkalmazásának legegyszerűbb módja az Application Gateway és a számítási feladat közötti forgalomra való kényszerítés, ha az Application Gatewayt egy olyan alhálózatban helyezi el, amelynek előtagja kívül esik a privát tartományokon. Ehhez az alhálózathoz nem feltétlenül kell nyilvános IP-címeket használnia, ehelyett testre szabhatja azOkat az IP-címeket, amelyeket az Azure Firewall Premium belsőként kezel az IDPS-hez. Ha például a szervezet nem használja a 100.64.0.0/10 tartományt, akkor ezt a tartományt kizárhatja az IDPS belső előtagjainak listájából (ennek további részleteiért lásd az Azure Firewall Premium privát IPDS-tartományait), és üzembe helyezheti az Application Gatewayt egy IP-címmel konfigurált alhálózaton.100.64.0.0/10

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

• Jose Moreno | Vezető ügyfélmérnök

Következő lépések

• Biztonságos hálózatok nulla megbízhatósággal
• Virtuális hálózat forgalmának útválasztása
• Az Application Gateway működése

Kapcsolódó erőforrások

• Számítási feladatok védelme és szabályozása hálózati szintű szegmentálással
• Biztonságos hibrid hálózat megvalósítása
• Küllős hálózati topológia az Azure-ban
• Küllős hálózati topológia az Azure Virtual WAN használatával