Az Azure-alkalmazások számítási feladatainak biztonságossá tételéhez olyan védelmi intézkedéseket kell használnia, mint például a hitelesítés és a titkosítás az alkalmazásokban. Az alkalmazásokat üzemeltető virtuális hálózatokhoz (VNetekhez) biztonsági rétegeket is hozzáadhat. Ezek a biztonsági rétegek védik az alkalmazás bejövő folyamatait a nem kívánt használattól. Emellett az internet felé irányuló kimenő folyamatokat is csak az alkalmazás által igényelt végpontokra korlátozzák. Ez a cikk az Olyan Azure-beli virtuális hálózati biztonsági szolgáltatásokat ismerteti, mint az Azure DDoS Protection, az Azure Firewall és az Azure-alkalmazás Gateway, mikor érdemes használni az egyes szolgáltatásokat, valamint a mindkettőt kombináló hálózattervezési lehetőségeket.
- Az Azure DDoS Protection alkalmazástervezési ajánlott eljárásokkal kombinálva továbbfejlesztett DDoS-kockázatcsökkentési funkciókat biztosít, hogy nagyobb védelmet nyújtson a DDoS-támadásokkal szemben. Az Azure DDOS Protectiont minden peremhálózaton engedélyeznie kell.
- Az Azure Firewall egy felügyelt következő generációs tűzfal, amely hálózati címfordítást (NAT) kínál. Az Azure Firewall a csomagszűrést az Internet Protocol (IP)-címek és a Transmission Control Protocol és a User Datagram Protocol (TCP/UDP) portokon, illetve alkalmazásalapú HTTP(S) vagy SQL-attribútumokon alapul. Az Azure Firewall a Microsoft fenyegetésfelderítését is alkalmazza a rosszindulatú IP-címek azonosítására. További információkért tekintse meg az Azure Firewall dokumentációját.
- Az Azure Firewall Premium az Azure Firewall Standard és más funkciók, például a TLS-vizsgálat és a behatolásészlelési és védelmi rendszer (IDPS) összes funkcióját tartalmazza.
- Azure-alkalmazás átjáró egy felügyelt webes forgalom terheléselosztója és HTTP(S) teljes fordított proxyja, amely képes ssl-titkosításra és visszafejtésére. Az Application Gateway megőrzi az eredeti ügyfél IP-címét egy X-Forwarded-for HTTP fejlécben. Az Application Gateway webalkalmazási tűzfalat is használ a webes forgalom vizsgálatához és a HTTP-réteg támadásainak észleléséhez. További információkért tekintse meg az Application Gateway dokumentációját.
- Az Azure Web Application Firewall (WAF) a Azure-alkalmazás Gateway opcionális kiegészítése. Ellenőrzi a HTTP-kéréseket, és megakadályozza a webes réteg rosszindulatú támadásait, például az SQL-injektálást vagy a helyek közötti szkriptelést. További információkért tekintse meg a webalkalmazási tűzfal dokumentációját.
Ezek az Azure-szolgáltatások kiegészítik egymást. Lehet, hogy az egyik vagy a másik a legjobb a számítási feladatokhoz, vagy használhatja őket együtt az optimális védelemhez mind a hálózati, mind az alkalmazásrétegekben. Az alábbi döntési fával és a cikkben szereplő példák segítségével állapítsa meg az alkalmazás virtuális hálózatának legjobb biztonsági lehetőségét.
Az Azure Firewall és Azure-alkalmazás Gateway különböző technológiákat használ, és támogatják a különböző folyamatok biztonságossá tételét:
| Alkalmazásfolyamat | Az Azure Firewall szűrhető | A WAF szűrhető az Application Gatewayen |
|---|---|---|
| HTTP-forgalom a helyszíni/internetről az Azure-ba (bejövő) | Igen | Igen |
| HTTP-forgalom az Azure-ból a helyszíni/internet felé (kimenő) | Igen | Nem |
| Nem HTTP(S) forgalom, bejövő/kimenő | Igen | Nem |
Az alkalmazás által igényelt hálózati folyamatoktól függően a kialakítás alkalmazásonként eltérő lehet. Az alábbi diagram egy egyszerűsített döntési fát kínál, amely segít kiválasztani az alkalmazáshoz javasolt megközelítést. A döntés attól függ, hogy az alkalmazás HTTP(S) vagy más protokollon keresztül van-e közzétéve:
Ez a cikk a folyamatábra széles körben ajánlott terveit, valamint a kevésbé gyakori forgatókönyvekben alkalmazhatókat ismerteti:
- Ha a virtuális hálózatban nincsenek webalkalmazások, csak az Azure Firewall. Ez szabályozza az alkalmazások bejövő forgalmát és a kimenő forgalmat is.
- Ha csak az Application Gateway van a virtuális hálózaton, és a hálózati biztonsági csoportok (NSG-k) elegendő kimeneti szűrést biztosítanak. Az Azure Firewall által biztosított funkciók számos támadási forgatókönyvet (például adatkiszivárgást, IDPS-t stb.) képesek megakadályozni. Emiatt az Application Gateway egyedüli forgatókönyve általában nem ajánlott, ezért nincs dokumentálva, és nem szerepel a fenti folyamatábra alatt.
- Az Azure Firewall és az Application Gateway párhuzamosan, amely az egyik leggyakoribb kialakítás. Ezt a kombinációt akkor használja, ha azt szeretné, hogy Azure-alkalmazás Gateway védje a HTTP(S) alkalmazásokat a webes támadásoktól, az Azure Firewall pedig az összes többi számítási feladatot, és szűrje a kimenő forgalmat.
- Az Application Gateway az Azure Firewall előtt, amikor azt szeretné, hogy az Azure Firewall vizsgálja meg az összes forgalmat, a WAF-ot a webes forgalom védelme érdekében, és az alkalmazás ismerje az ügyfél forrás IP-címét. Az Azure Firewall Premium- és TLS-ellenőrzéssel ez a kialakítás a végpontok közötti SSL-forgatókönyvet is támogatja.
- Az Azure Firewall az Application Gateway előtt, amikor azt szeretné, hogy az Azure Firewall vizsgálja meg és szűrje a forgalmat, mielőtt az eléri az Application Gatewayt. Mivel az Azure Firewall nem fogja visszafejteni a HTTPS-forgalmat, az Application Gatewayhez hozzáadott funkciók korlátozottak. Ezt a forgatókönyvet a fenti folyamatábra nem dokumentálja.
A cikk utolsó részében az előző alapvető tervek változatait ismertetjük. Ezek a változatok a következők:
- Helyszíni alkalmazás-ügyfelek.
- Küllős hálózatok.
- Az Azure Kubernetes Service (AKS) implementációi.
Más fordított proxyszolgáltatásokat is hozzáadhat, például egy API Management-átjárót vagy az Azure Front Doort. Vagy lecserélheti az Azure-erőforrásokat külső hálózati virtuális berendezésekre.
Feljegyzés
A következő forgatókönyvekben egy Azure-beli virtuális gépet használnak példaként a webalkalmazások számítási feladataira. A forgatókönyvek más számítási feladatokra is érvényesek, például tárolókra vagy Azure Web Appsre. A privát végpontokat is tartalmazó beállításokkal kapcsolatban vegye figyelembe a privát végpont felé irányuló forgalom vizsgálatára vonatkozó javaslatokat az Azure Firewallban
Csak Azure Firewall
Ha a virtuális hálózaton nincsenek olyan webes számítási feladatok, amelyek kihasználhatják a WAF előnyeit, csak az Azure Firewallt használhatja. A tervezés ebben az esetben egyszerű, de a csomagfolyamat áttekintése segít megérteni az összetettebb terveket. Ebben a kialakításban az összes bejövő forgalmat a rendszer felhasználó által megadott útvonalakon (UDR-eken) keresztül küldi el az Azure Firewallnak a helyszíni vagy más Azure-beli virtuális hálózatokról érkező kapcsolatokhoz. A cím az Azure Firewall nyilvános IP-címére vonatkozik a nyilvános internetről való kapcsolatokhoz, ahogy az alábbi ábrán is látható. Az Azure-beli virtuális hálózatokról érkező kimenő forgalmat a rendszer UDR-en keresztül küldi el a tűzfalnak, ahogyan az az alábbi párbeszédpanelen látható.
Az alábbi táblázat a forgatókönyv forgalmi folyamatait foglalja össze:
| Folyamat | Átmegy az Application Gatewayen / WAF-on | Az Azure Firewall használata |
|---|---|---|
| HTTP-forgalom az internetről/onpremből az Azure-ba | n/a | Igen (lásd alább) |
| HTTP-forgalom az Azure-ból az internetre/onprem-be | N.A. | Igen |
| Nem HTTP-forgalom az internetről/onpremből az Azure-ba | N.A. | Igen |
| Nem HTTP-forgalom az Azure-ból az internetre/onprem-be | N.A. | Igen |
Az Azure Firewall nem vizsgálja meg a bejövő HTTP(S) forgalmat. De képes lesz alkalmazni a 3. réteg 4. rétegbeli szabályait és a teljes tartománynéven alapuló alkalmazásszabályokat. Az Azure Firewall az Azure Firewall szintjétől és a TLS-ellenőrzés konfigurálásának függvényében megvizsgálja a kimenő HTTP-forgalmat:
- Az Azure Firewall Standard csak a hálózati szabályokban lévő csomagok 3. és 4. rétegbeli attribútumait, valamint a gazdagép HTTP-fejlécét vizsgálja az alkalmazásszabályokban.
- Az Azure Firewall Premium olyan képességeket biztosít, mint a többi HTTP-fejléc (például a User-Agent) vizsgálata, valamint a TLS-vizsgálat engedélyezése a mélyebb csomagelemzéshez. Az Azure Firewall nem egyenértékű a webalkalmazási tűzfallal. Ha webes számítási feladatokkal rendelkezik a virtuális hálózatban, a WAF használata erősen ajánlott.
Az alábbi csomagbejárási példa bemutatja, hogyan fér hozzá egy ügyfél egy virtuális gép által üzemeltetett alkalmazáshoz a nyilvános internetről. A diagram csak egy virtuális gépet tartalmaz az egyszerűség kedvéért. A nagyobb rendelkezésre állás és méretezhetőség érdekében több alkalmazáspéldány is rendelkezésre áll egy terheléselosztó mögött. Ebben a kialakításban az Azure Firewall mind a nyilvános internetről érkező bejövő kapcsolatokat, mind az alkalmazás alhálózati virtuális gépéről érkező kimenő kapcsolatokat az UDR használatával vizsgálja.
- Az Azure Firewall szolgáltatás több példányt is üzembe helyez a borítók alatt, itt a 192.168.100.4 előtérbeli IP-címmel és a 192.168.100.0/26 tartomány belső címeivel. Ezek az egyes példányok általában láthatatlanok az Azure-rendszergazda számára. A különbség azonban bizonyos esetekben hasznos lehet, például a hálózati problémák elhárítása során.
- Ha a forgalom az internet helyett egy helyszíni virtuális magánhálózatról (VPN) vagy Azure ExpressRoute-átjáróról érkezik, az ügyfél elindítja a kapcsolatot a virtuális gép IP-címével. Nem indítja el a kapcsolatot a tűzfal IP-címével, és a tűzfal alapértelmezés szerint nem végez forrás NAT-t.
Architektúra
Az alábbi ábra a forgalmi folyamatot mutatja be, feltéve, hogy a példány IP-címe .192.168.100.7
Munkafolyamat
- Az ügyfél elindítja a kapcsolatot az Azure Firewall nyilvános IP-címével:
- Forrás IP-címe: ClientPIP
- Cél IP-címe: AzFwPIP
- Az Azure Firewall nyilvános IP-címére irányuló kérés a tűzfal háttérpéldányára, ebben az esetben a 192.168.100.7-be kerül. Az Azure Firewall Destination NAT (DNAT) szabály lefordítja a cél IP-címet a virtuális hálózaton belüli alkalmazás IP-címére. Ha DNST-t használ, az Azure Firewall is forrásként használja a csomag NAT-jait (SNAT-okat ). További információkért tekintse meg az Azure Firewall ismert problémáit. A virtuális gép a következő IP-címeket látja a bejövő csomagban:
- Forrás IP-címe: 192.168.100.7
- Cél IP-címe: 192.168.1.4
- A virtuális gép megválaszolja az alkalmazáskérést, megfordítva a forrás- és cél IP-címeket. A bejövő folyamathoz nincs szükség felhasználó által megadott útvonalra (UDR), mert a forrás IP-címe az Azure Firewall IP-címe. A 0.0.0.0/0 ábrán szereplő UDR a kimenő kapcsolatokhoz tartozik, hogy a nyilvános internetre irányuló csomagok áthaladjanak az Azure Firewallon.
- Forrás IP-címe: 192.168.1.4
- Cél IP-címe: 192.168.100.7
- Végül az Azure Firewall visszavonja az SNAT- és DNST-műveleteket, és elküldi a választ az ügyfélnek:
- Forrás IP-címe: AzFwPIP
- Cél IP-címe: ClientPIP
Csak Application Gateway
Ez a kialakítás azt a helyzetet mutatja be, amikor csak webalkalmazások léteznek a virtuális hálózaton, és a kimenő forgalom NSG-kkel való vizsgálata elegendő az internetre irányuló kimenő folyamatok védelméhez.
Feljegyzés
Ez nem ajánlott kialakítás, mivel az Azure Firewall használata a kimenő folyamatok szabályozására (nem csak az NSG-kre) megakadályozza bizonyos támadási forgatókönyveket, például az adatkiszivárgást, ahol meggyőződhet arról, hogy a számítási feladatok csak az URL-címek jóváhagyott listájára küldenek adatokat. Továbbá az NSG-k csak a 3. és a 4. rétegen működnek, és nem rendelkeznek teljes tartománynév-támogatással.
A fő különbség az előző kialakítástól csak az Azure Firewall esetében az, hogy az Application Gateway nem jár útválasztási eszközként a NAT-jal. Teljes fordított alkalmazásproxyként viselkedik. Vagyis az Application Gateway leállítja a webes munkamenetet az ügyféltől, és létrehoz egy külön munkamenetet az egyik háttérkiszolgálójával. Az internetről bejövő HTTP-kapcsolatokat az Application Gateway nyilvános IP-címére, az Azure-ból vagy a helyszíniről az átjáró privát IP-címére kell küldeni. Az Azure-beli virtuális gépekről érkező forgalom visszatérése a szabványos virtuális hálózatnak az Application Gatewayre való visszairányítását követi (további részletekért tekintse meg a csomagsétát. Az Azure-beli virtuális gépekről érkező kimenő internetes folyamatok közvetlenül az internetre kerülnek.
Az alábbi táblázat a forgalmi folyamatokat foglalja össze:
| Folyamat | Átmegy az Application Gatewayen / WAF-on | Az Azure Firewall használata |
|---|---|---|
| HTTP-forgalom az internetről/onpremből az Azure-ba | Igen | n/a |
| HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | N.A. |
| Nem HTTP-forgalom az internetről/onpremből az Azure-ba | Nem | N.A. |
| Nem HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | N.A. |
Architektúra
Az alábbi csomagbejárási példa bemutatja, hogyan fér hozzá egy ügyfél a virtuális gép által üzemeltetett alkalmazáshoz a nyilvános internetről.
Munkafolyamat
- Az ügyfél elindítja a kapcsolatot a Azure-alkalmazás-átjáró nyilvános IP-címével:
- Forrás IP-címe: ClientPIP
- Cél IP-címe: AppGwPIP
- Az Application Gateway nyilvános IP-címére irányuló kérés az átjáró háttérpéldányára, ebben az esetben a 192.168.200.7-be kerül. A kérést fogadó Application Gateway-példány leállítja a kapcsolatot az ügyféltől, és létrehoz egy új kapcsolatot az egyik háttérrendszerrel. A háttérrendszer az Application Gateway-példányt látja forrás IP-címként. Az Application Gateway egy X-Forwarded-For HTTP-fejlécet szúr be az eredeti ügyfél IP-címével.
- Forrás IP-címe: 192.168.200.7 (az Application Gateway-példány privát IP-címe)
- Cél IP-címe: 192.168.1.4
- X-Forwarded-For fejléc: ClientPIP
- A virtuális gép megválaszolja az alkalmazáskérést, megfordítva a forrás- és cél IP-címeket. A virtuális gép már tudja, hogyan érheti el az Application Gatewayt, így nincs szükség UDR-re.
- Forrás IP-címe: 192.168.1.4
- Cél IP-címe: 192.168.200.7
- Végül az Application Gateway-példány válaszol az ügyfélre:
- Forrás IP-címe: AppGwPIP
- Cél IP-címe: ClientPIP
Azure-alkalmazás átjáró metaadatokat ad hozzá a csomag HTTP-fejléceihez, például a X-Forwarded-For fejléc, amely az eredeti ügyfél IP-címét tartalmazza. Egyes alkalmazáskiszolgálóknak szüksége van a forrásügyfél IP-címére a földrajzi helyspecifikus tartalom kiszolgálásához vagy naplózáshoz. További információ: Az Application Gateway működése.
Az IP-cím
192.168.200.7azon példányok egyike, amelyet a Azure-alkalmazás Gateway szolgáltatás a fedelek alatt helyez üzembe, itt pedig a belső, privát előtérbeli IP-címmel192.168.200.4. Ezek az egyes példányok általában láthatatlanok az Azure-rendszergazda számára. A különbség azonban bizonyos esetekben hasznos lehet, például a hálózati problémák elhárítása során.A folyamat hasonló, ha az ügyfél egy helyszíni hálózatból származik VPN-en vagy ExpressRoute-átjárón keresztül. A különbség az, hogy az ügyfél a nyilvános cím helyett az Application Gateway privát IP-címét éri el.
Feljegyzés
A fordított proxy és a háttérbeli webalkalmazás eredeti HTTP-gazdagépnevének megőrzése az X-Forwarded-For szolgáltatással kapcsolatos további információkért és a kérések gazdagépnevének megőrzéséért.
Tűzfal és Application Gateway párhuzamosan
Egyszerűsége és rugalmassága miatt az Application Gateway és az Azure Firewall párhuzamos futtatása gyakran a legjobb forgatókönyv.
Ezt a kialakítást akkor valósítja meg, ha a virtuális hálózaton webes és nem webes számítási feladatok vegyesen vannak jelen. Az Azure WAF a Azure-alkalmazás Gatewayben védi a webes számítási feladatok bejövő forgalmát, az Azure Firewall pedig a többi alkalmazás bejövő forgalmát. Az Azure Firewall mindkét számítási feladattípus kimenő folyamatait lefedi.
Az internetről bejövő HTTP(S) kapcsolatokat az Application Gateway nyilvános IP-címére, az Azure-ból vagy a helyszíni HTTP-kapcsolatokból a saját IP-címére kell küldeni. A normál virtuális hálózatok útválasztása elküldi a csomagokat az Application Gatewayről a cél virtuális gépekre, valamint a cél virtuális gépekről vissza az Application Gatewayre (további részletekért tekintse meg a csomagokat ismertető útmutatót). Nem HTTP(S) bejövő kapcsolatok esetén a forgalomnak az Azure Firewall nyilvános IP-címét kell céloznia (ha a nyilvános internetről érkezik), vagy az Azure Firewallon keresztül küldi el az UDR-ek (ha más Azure-beli virtuális hálózatokról vagy helyszíni hálózatokról érkeznek). Az Azure-beli virtuális gépekről érkező kimenő folyamatokat az UDR-ek továbbítják az Azure Firewallnak.
Az alábbi táblázat a forgatókönyv forgalmi folyamatait foglalja össze:
| Folyamat | Átmegy az Application Gatewayen / WAF-on | Az Azure Firewall használata |
|---|---|---|
| HTTP-forgalom az internetről/onpremből az Azure-ba | Igen | Nem |
| HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | Igen |
| Nem HTTP-forgalom az internetről/onpremből az Azure-ba | Nem | Igen |
| Nem HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | Igen |
Ez a kialakítás sokkal részletesebb kimenő forgalom szűrését teszi lehetővé, mint az NSG-k. Ha például az alkalmazásoknak egy adott Azure Storage-fiókhoz kell csatlakozniuk, teljes tartománynév (FQDN) alapú szűrőket használhat. Az FQDN-alapú szűrőkkel az alkalmazások nem küldenek adatokat a gazember tárfiókokba. Ez a forgatókönyv nem előzhető meg csak NSG-k használatával. Ezt a kialakítást gyakran használják, ha a kimenő forgalom FQDN-alapú szűrést igényel. Ilyen például egy Azure Kubernetes Services-fürt kimenő forgalmának korlátozása.
Architektúrák
Az alábbi ábra egy külső ügyfél bejövő HTTP(s) kapcsolatainak forgalmi folyamatát mutatja be:
Az alábbi ábra a hálózati virtuális gépekről az internetre irányuló kimenő kapcsolatok forgalmát mutatja be. Ilyen például a háttérrendszerekhez való csatlakozás vagy az operációs rendszer frissítésének lekérése:
Az egyes szolgáltatások csomagfolyamat-lépései ugyanazok, mint az előző különálló tervezési beállításokban.
Application Gateway tűzfal előtt
Ezt a kialakítást részletesebben az Azure Firewall és az Application Gateway használatával rendelkező webalkalmazások nulla megbízhatóságú hálózatában ismertetjük. Ez a dokumentum a többi tervezési lehetőséggel való összehasonlításra összpontosít. Ebben a topológiában a bejövő webes forgalom az Azure Firewallon és a WAF-on is áthalad. A WAF védelmet nyújt a webalkalmazás rétegében. Az Azure Firewall központi naplózási és vezérlési pontként működik, és az Application Gateway és a háttérkiszolgálók közötti forgalmat vizsgálja. Az Application Gateway és az Azure Firewall nem párhuzamosan, hanem egymás után ül.
Az Azure Firewall Premium használatával ez a kialakítás támogatja a teljes körű forgatókönyveket, ahol az Azure Firewall TLS-ellenőrzést alkalmaz az IDPS végrehajtására az Application Gateway és a webes háttérrendszer közötti titkosított forgalomon.
Ez a kialakítás olyan alkalmazások számára megfelelő, amelyeknek ismernie kell a bejövő ügyfélforrás IP-címeit, például földrajzi helyspecifikus tartalmak kiszolgálásához vagy naplózáshoz. Az Azure Firewall előtt található Application Gateway rögzíti a bejövő csomag forrás IP-címét az X-forwarded-for fejlécben, így a webkiszolgáló láthatja az eredeti IP-címet ebben a fejlécben. További információ: Az Application Gateway működése.
Az internetről bejövő HTTP-kapcsolatokat az Application Gateway nyilvános IP-címére, az Azure-ból vagy a helyszíni HTTP-kapcsolatokból a privát IP-címre kell elküldeni. Az Application Gateway UDR-jei gondoskodnak arról, hogy a csomagok az Azure Firewallon keresztül legyenek irányítva (további részletekért tekintse meg a csomagokat ismertető útmutatót). Nem HTTP(S) bejövő kapcsolatok esetén a forgalomnak az Azure Firewall nyilvános IP-címét kell céloznia (ha a nyilvános internetről érkezik), vagy az Azure Firewallon keresztül küldi el az UDR-ek (ha más Azure-beli virtuális hálózatokról vagy helyszíni hálózatokról érkeznek). Az Azure-beli virtuális gépekről érkező kimenő folyamatokat az UDR-ek továbbítják az Azure Firewallnak.
A kialakítás fontos megjegyzése, hogy az Azure Firewall Premium az Application Gateway alhálózatáról származó forrás IP-címmel rendelkező forgalmat fogja látni. Ha ez az alhálózat privát IP-címmel van konfigurálva (in 10.0.0.0/8, 192.168.0.0/16vagy 172.16.0.0/12100.64.0.0/10), az Azure Firewall Premium belsőként kezeli az Application Gatewayből érkező forgalmat, és nem alkalmazza a bejövő forgalomra vonatkozó IDPS-szabályokat. Az Azure Firewall IDPS-szabályirányairól és a privát IP-előtagokról az Azure Firewall IDPS-szabályaiban talál további információt. Ezért javasoljuk, hogy módosítsa az IDPS privát előtagjait az Azure Firewall-házirendben, hogy az Application Gateway alhálózata ne legyen belső forrás, hogy bejövő és kimenő IDPS-aláírásokat alkalmazzon a forgalomra.
Az alábbi táblázat a forgatókönyv forgalmi folyamatait foglalja össze:
| Folyamat | Átmegy az Application Gatewayen / WAF-on | Az Azure Firewall használata |
|---|---|---|
| HTTP-forgalom az internetről/onpremből az Azure-ba | Igen | Igen |
| HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | Igen |
| Nem HTTP-forgalom az internetről/onpremből az Azure-ba | Nem | Igen |
| Nem HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | Igen |
A helyszíni vagy az internetről az Azure-ba irányuló webes forgalom esetén az Azure Firewall megvizsgálja azokat a folyamatokat, amelyeket a WAF már engedélyezett. Attól függően, hogy az Application Gateway titkosítja-e a háttérforgalmat (az Application Gatewayről az alkalmazáskiszolgálókra irányuló forgalmat), különböző lehetséges forgatókönyvek közül választhat:
- Az Application Gateway a zéró megbízhatósági alapelvek (végpontok közötti TLS-titkosítás) alapján titkosítja a forgalmat, és az Azure Firewall titkosított forgalmat fogad. Az Azure Firewall Standard továbbra is alkalmazhat ellenőrzési szabályokat, például a 3. és 4. rétegbeli szűrést a hálózati szabályokban, vagy teljes tartománynév-szűrést az alkalmazásszabályokban a TLS Server Name Indication (SNI) fejléc használatával. Az Azure Firewall Premium mélyebb betekintést biztosít a TLS-ellenőrzéshez, például az URL-alapú szűréshez.
- Ha az Application Gateway titkosítatlan forgalmat küld az alkalmazáskiszolgálóknak, az Azure Firewall tiszta szövegben látja a bejövő forgalmat. Az Azure Firewallban nincs szükség TLS-vizsgálatra.
- Ha az IDPS engedélyezve van az Azure Firewallban, ellenőrzi, hogy a HTTP-gazdagép fejléce megegyezik-e a cél IP-címével. Ezzel a céllal névfeloldásra lesz szüksége a gazdagép fejlécében megadott teljes tartománynévhez. Ez a névfeloldás az Azure DNS privát zónáival és az Azure DNS használatával az Alapértelmezett Azure Firewall DNS-beállításokkal érhető el. Ez olyan egyéni DNS-kiszolgálókkal is elérhető, amelyeket az Azure Firewall beállításaiban kell konfigurálni. (További információ:Azure Firewall DNS Gépház.) Ha nincs rendszergazdai hozzáférés ahhoz a virtuális hálózathoz, ahol az Azure Firewall telepítve van, az utóbbi módszer az egyetlen lehetőség. Ilyenek például a Virtual WAN által védett központokban üzembe helyezett Azure Firewallok.
Architektúra
A többi folyamat (http-n kívüli bejövő forgalom és kimenő forgalom) esetében az Azure Firewall szükség esetén IDPS-ellenőrzést és TLS-ellenőrzést biztosít. Emellett teljes tartománynév-alapú szűrést is biztosít a DNS-alapú hálózati szabályokban .
Munkafolyamat
A nyilvános internetről érkező hálózati forgalom a következő folyamatot követi:
- Az ügyfél elindítja a kapcsolatot a Azure-alkalmazás-átjáró nyilvános IP-címével:
- Forrás IP-címe: ClientPIP
- Cél IP-címe: AppGwPIP
- Az Application Gateway nyilvános IP-címére irányuló kérés az átjáró háttérpéldányára, ebben az esetben a 192.168.200.7-be kerül. Az Application Gateway-példány leállítja az ügyfél kapcsolatát, és létrehoz egy új kapcsolatot az egyik háttérrendszerrel. Az Application Gateway alhálózatán található UDR
192.168.1.0/24továbbítja a csomagot az Azure Firewallnak, miközben megőrzi a cél IP-címét a webalkalmazásnak:- Forrás IP-címe: 192.168.200.7 (az Application Gateway-példány privát IP-címe)
- Cél IP-címe: 192.168.1.4
- X-Forwarded-For fejléc: ClientPIP
- Az Azure Firewall nem kezeli a forgalmat, mert a forgalom egy privát IP-címre kerül. Továbbítja a forgalmat az alkalmazás virtuális gépére, ha a szabályok engedélyezik. További információ: Azure Firewall SNAT. Ha azonban a forgalom egy alkalmazásszabályt ér el a tűzfalon, a számítási feladat látni fogja a csomagot feldolgozó adott tűzfalpéldány forrás IP-címét, mivel az Azure Firewall proxyként fogja használni a kapcsolatot:
- Forrás IP-cím, ha egy Azure Firewall hálózati szabály engedélyezi a forgalmat: 192.168.200.7 (az Application Gateway-példányok egyikének privát IP-címe).
- Forrás IP-cím, ha egy Azure Firewall-alkalmazásszabály engedélyezi a forgalmat: 192.168.100.7 (az Egyik Azure Firewall-példány privát IP-címe).
- Cél IP-címe: 192.168.1.4
- X-Forwarded-For fejléc: ClientPIP
- A virtuális gép megválaszolja a kérést, megfordítja a forrás- és cél IP-címeket. Az UDR
192.168.200.0/24rögzíti az Application Gatewaynek visszaküldött csomagot, és átirányítja az Azure Firewallra, miközben megőrzi a cél IP-címét az Application Gateway felé.- Forrás IP-címe: 192.168.1.4
- Cél IP-címe: 192.168.200.7
- Itt is az Azure Firewall nem kezeli a forgalmat, mivel egy privát IP-címre kerül, és továbbítja a forgalmat az Application Gatewaynek.
- Forrás IP-címe: 192.168.1.4
- Cél IP-címe: 192.168.200.7
- Végül az Application Gateway-példány válaszol az ügyfélre:
- Forrás IP-címe: AppGwPIP
- Cél IP-címe: ClientPIP
A virtuális gépekről a nyilvános internetre irányuló kimenő folyamatok az Azure Firewallon keresztül haladnak 0.0.0.0/0át, az UDR által meghatározott módon.
Application Gateway tűzfal után
Ez a kialakítás lehetővé teszi, hogy az Azure Firewall szűrje és elvetje a rosszindulatú forgalmat, mielőtt eléri az Application Gatewayt. Alkalmazhat például olyan funkciókat, mint a fenyegetésintelligencia-alapú szűrés. Egy másik előnye, hogy az alkalmazás ugyanazt a nyilvános IP-címet kapja a bejövő és a kimenő forgalomhoz, protokolltól függetlenül. Az Azure Firewall azonban SNAT-ként kezeli a bejövő forgalmat, így az alkalmazás nem láthatja a HTTP-kérések eredeti IP-címét. Adminisztrációs szempontból, például hibaelhárítási célokból, egy adott kapcsolat tényleges ügyfél IP-címét úgy szerezheti be, hogy az össze van összhangban az Azure Firewall SNAT-naplóival.
Ebben a forgatókönyvben korlátozott az előny, mivel az Azure Firewall csak az Application Gatewayre irányuló titkosított forgalmat látja. Lehetnek olyan forgatókönyvek, ahol ezt a kialakítást részesíti előnyben. Az egyik eset az, ha egy másik WAF a hálózat korábbi része (például az Azure Front Door esetében), amely rögzítheti az eredeti forrás IP-címet a X-Forwarded-For HTTP-fejlécben. Vagy előnyben részesíti a kialakítást, ha sok nyilvános IP-címre van szükség.
A nyilvános internetről érkező HTTP(S) bejövő folyamatoknak meg kell céloznia az Azure Firewall nyilvános IP-címét, az Azure Firewall pedig az Application Gateway privát IP-címére irányítja a csomagokat (és az SNAT-t). Más Azure-beli virtuális hálózatokról vagy helyszíni hálózatokról http(s) forgalmat kell küldeni az Application Gateway privát IP-címére, és az Azure Firewallon keresztül kell továbbítani az UDR-ekkel. A normál virtuális hálózatok útválasztása gondoskodik arról, hogy az Azure-beli virtuális gépekről érkező forgalom visszakerüljön az Application Gatewayre, az Application Gatewayről pedig az Azure Firewallra, ha DNST-szabályokat használnak. A helyszíni vagy az Azure UDR-ből érkező forgalmat az Application Gateway alhálózatán kell használni (további részletekért tekintse meg a csomagokat ismertető útmutatót). Az Azure-beli virtuális gépekről az internetre irányuló kimenő forgalmat az UDR-ek az Azure Firewallon keresztül küldik el.
Az alábbi táblázat a forgatókönyv forgalmi folyamatait foglalja össze:
| Folyamat | Átmegy az Application Gatewayen / WAF-on | Az Azure Firewall használata |
|---|---|---|
| HTTP-forgalom az internetről/onpremből az Azure-ba | Igen | Igen (lásd alább) |
| HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | Igen |
| Nem HTTP-forgalom az internetről/onpremből az Azure-ba | Nem | Igen |
| Nem HTTP-forgalom az Azure-ból az internetre/onprem-be | Nem | Igen |
Bejövő HTTP-forgalom esetén az Azure Firewall általában nem fejtené vissza a forgalmat. Ehelyett olyan IDPS-házirendeket alkalmazna, amelyek nem igényelnek TLS-ellenőrzést, például IP-alapú szűrést vagy HTTP-fejléceket.
Architektúra
Az alkalmazás nem látja a webes forgalom eredeti forrás IP-címét; az Azure Firewall SNATs-ként küldi el a csomagokat a virtuális hálózatba való bejövetelükkor. A probléma elkerülése érdekében használja az Azure Front Doort a tűzfal előtt. Az Azure Front Door http-fejlécként injektálja az ügyfél IP-címét, mielőtt belép az Azure-beli virtuális hálózatba.
Munkafolyamat
A nyilvános internetről érkező hálózati forgalom a következő folyamatot követi:
- Az ügyfél elindítja a kapcsolatot az Azure Firewall nyilvános IP-címével:
- Forrás IP-címe: ClientPIP
- Cél IP-címe: AzFWPIP
- Az Azure Firewall nyilvános IP-címére irányuló kérés a tűzfal háttérpéldányára, ebben az esetben a 192.168.100.7-be kerül. Az Azure Firewall DNS-ként kezeli a webes portot, általában a 443-at az Application Gateway-példány privát IP-címére. Az Azure Firewall a DNST használatakor is SNAT-t használ. További információkért tekintse meg az Azure Firewall ismert problémáit:
- Forrás IP-címe: 192.168.100.7 (az Azure Firewall-példány privát IP-címe)
- Cél IP-címe: 192.168.200.4
- Az Application Gateway új munkamenetet hoz létre a kapcsolatot kezelő példány és az egyik háttérkiszolgáló között. Az ügyfél eredeti IP-címe nem szerepel a csomagban:
- Forrás IP-címe: 192.168.200.7 (az Application Gateway-példány privát IP-címe)
- Cél IP-címe: 192.168.1.4
- X-Forwarded-For fejléc: 192.168.100.7
- A virtuális gép válaszol az Application Gatewayre, megfordítva a forrás- és cél IP-címeket:
- Forrás IP-címe: 192.168.1.4
- Cél IP-címe: 192.168.200.7
- Az Application Gateway válaszol az Azure Firewall-példány SNAT-forrás IP-címére. Még akkor is, ha a kapcsolat egy adott Application Gateway-példányból(például
.7) származik, az Azure Firewall az Application Gateway.4belső IP-címét látja forrás IP-címként:- Forrás IP-címe: 192.168.200.4
- Cél IP-címe: 192.168.100.7
- Végül az Azure Firewall visszavonja az SNAT-t és a DNAT-t, és válaszol az ügyfélre:
- Forrás IP-címe: AzFwPIP
- Cél IP-címe: ClientPIP
Annak ellenére, hogy az Application Gateway nem rendelkezik alkalmazásokhoz konfigurált figyelőkkel, továbbra is szüksége van egy nyilvános IP-címre, hogy a Microsoft felügyelhesse.
Feljegyzés
Az Application Gateway alhálózatán az Azure Firewallra mutató alapértelmezett útvonal 0.0.0.0/0 nem támogatott, mivel az megszakítaná a Azure-alkalmazás Átjáró megfelelő működéséhez szükséges vezérlősík-forgalmat.
Helyszíni ügyfelek
Az előző tervek mindegyike a nyilvános internetről érkező alkalmazásügyfeleket mutatja. A helyszíni hálózatok alkalmazásokhoz is hozzáférnek. A fenti információk és forgalom nagy része megegyezik az internetes ügyfelekével, de van néhány jelentős különbség:
- A VPN-átjáró vagy az ExpressRoute-átjáró az Azure Firewall vagy az Application Gateway előtt helyezkedik el.
- A WAF az Application Gateway privát IP-címét használja.
- Az Azure Firewall nem támogatja a DNST-t a privát IP-címekhez. Ezért kell az UDR-ek használatával bejövő forgalmat küldenie az Azure Firewallnak a VPN- vagy ExpressRoute-átjárókról.
- Győződjön meg arról, hogy a Azure-alkalmazás átjáró és az Azure Firewall kényszerített bújtatása során nem jár kifogással. Még ha a számítási feladatnak nincs szüksége kimenő kapcsolatra a nyilvános internethez, nem szúrhat be alapértelmezett útvonalat, például az Application Gatewayhez,
0.0.0.0/0amely a helyszíni hálózatra mutat, vagy megszakítja a forgalom vezérlését. Az Azure-alkalmazás Gateway esetében az alapértelmezett útvonalnak a nyilvános internetre kell mutatnia.
Architektúra
Az alábbi ábra a Azure-alkalmazás Átjáró és az Azure Firewall párhuzamos kialakítását mutatja be. Az alkalmazás-ügyfelek egy helyszíni hálózatból származnak, amely VPN-en vagy ExpressRoute-on keresztül csatlakozik az Azure-hoz:
Még akkor is, ha minden ügyfél a helyszínen vagy az Azure-ban található, Azure-alkalmazás Átjárónak és az Azure Firewallnak is nyilvános IP-címekkel kell rendelkeznie. A nyilvános IP-címek lehetővé teszik a Microsoft számára a szolgáltatások kezelését.
Küllős topológia
A cikkben szereplő tervek továbbra is érvényesek a küllős topológiára. A központi központi virtuális hálózat megosztott erőforrásai virtuális hálózatok közötti társviszony-létesítésen keresztül csatlakoznak az alkalmazásokhoz külön küllős virtuális hálózatokban.
Architektúra
Megfontolások
A topológia néhány megfontolandó szempontja a következők:
- Az Azure Firewall a központi központi virtuális hálózaton van üzembe helyezve. A fenti ábra az Application Gateway központi telepítésének gyakorlatát mutatja be. Az alkalmazáscsapatok azonban gyakran kezelnek olyan összetevőket, mint az Azure-alkalmazás-átjárók vagy az Azure API Management-átjárók. Ebben az esetben ezek az összetevők a küllős virtuális hálózatokban vannak üzembe helyezve.
- Különös figyelmet kell fordítani a küllős hálózatok UDR-jeire: Ha egy küllős alkalmazáskiszolgáló egy adott Azure Firewall-példányról fogad forgalmat, például az
192.168.100.7előző példákban szereplő címről, akkor vissza kell küldenie a forgalmat ugyanarra a példányra. Ha a küllőben egy UDR beállítja a központ felé az Azure Firewall IP-címére192.168.100.4(a fenti ábrákon) címzett forgalom következő ugrását, a visszaadott csomagok egy másik Azure Firewall-példányra kerülhetnek, ami aszimmetrikus útválasztást okoz. Győződjön meg arról, hogy ha a küllős virtuális hálózatokon található UDR-ek az Azure Firewallon keresztül küldik a forgalmat a központ megosztott szolgáltatásainak, ezek az UDR-ek nem tartalmazzák az Azure Firewall alhálózat előtagját. - Az előző javaslat egyformán vonatkozik az Application Gateway alhálózatára, valamint a központi virtuális hálózaton üzembe helyezhető egyéb hálózati virtuális berendezésekre vagy fordított proxykra.
- Az Application Gateway vagy az Azure Firewall alhálózatainak következő ugrását nem állíthatja be statikus útvonalakon a következő ugrástípussal
Virtual Network. Ez a következő ugrástípus csak a helyi virtuális hálózaton érvényes, a virtuális hálózatok közötti társviszonyok esetében nem. A felhasználó által megadott útvonalakról és a következő ugrástípusokról további információt a virtuális hálózati forgalom útválasztása című témakörben talál.
Aszimmetrikus útválasztás
Az alábbi ábra azt mutatja be, hogyan küldi vissza a küllő az SNATted forgalmat az Azure Firewall ALB-jének. Ez a beállítás aszimmetrikus útválasztást okoz:
A probléma megoldásához definiálja a küllőben lévő UDR-eket az Azure Firewall alhálózata nélkül, de csak azokat az alhálózatokat, ahol a megosztott szolgáltatások találhatók. A példában a küllőben a megfelelő UDR-nek csak 192.168.1.0/24-et kell tartalmaznia. Nem tartalmazhatja a teljes 192.168.0.0/16-ot pirossal jelölve.
Integráció más Azure-termékekkel
Az Azure Firewall és Azure-alkalmazás Gateway integrálható más Azure-termékekkel és szolgáltatásokkal.
API Management Gateway
Integrálja a fordított proxyszolgáltatásokat, például az API Management-átjárót az előző tervekbe, hogy olyan funkciókat biztosítson, mint az API szabályozása vagy a hitelesítési proxy. Az API Management-átjárók integrálása nem módosítja jelentősen a terveket. A fő különbség az, hogy az egyetlen Application Gateway fordított proxy helyett két fordított proxy van egymás mögött.
További információkért tekintse meg az API Management és az Application Gateway virtuális hálózatba való integrálására vonatkozó tervezési útmutatót, valamint a mikroszolgáltatásokhoz készült API Gateways alkalmazásmintát.
Azure Kubernetes Service
Az AKS-fürtön futó számítási feladatok esetében a fürttől függetlenül üzembe helyezhet Azure-alkalmazás Átjárót. Vagy integrálhatja az AKS-fürttel az Azure-alkalmazás átjáró bejövőforgalom-vezérlőjével. Bizonyos objektumok Kubernetes-szinteken (például szolgáltatások és bejövő forgalom) történő konfigurálásakor az Application Gateway automatikusan alkalmazkodik anélkül, hogy további manuális lépéseket kellene végrehajtania.
Az Azure Firewall fontos szerepet játszik az AKS-fürt biztonságában. Biztosítja a szükséges funkciókat az AKS-fürt kimenő forgalmának teljes tartománynév alapján történő szűréséhez, nem csak AZ IP-cím alapján. További információ: Az AKS-fürtcsomópontok kimenő forgalmának szabályozása.
Ha az Application Gatewayt és az Azure Firewallt kombinálja egy AKS-fürt védelméhez, a legjobb, ha a párhuzamos tervezési lehetőséget használja. A WAF-et tartalmazó Application Gateway feldolgozza a fürt webalkalmazásainak bejövő kapcsolatkéréseit. Az Azure Firewall csak kifejezetten engedélyezett kimenő kapcsolatokat engedélyez. Az Azure Kubernetes Service(AKS) fürt alapkonfigurációs architektúráját a párhuzamos kialakítási lehetőség példájában tekinthet meg.
Azure Front Door
Az Azure Front Door funkciói részben átfedésben vannak Azure-alkalmazás Átjáróval. Mindkét szolgáltatás például webalkalmazási tűzfalazást, SSL-kiszervezést és URL-alapú útválasztást kínál. Az egyik fő különbség az, hogy míg Azure-alkalmazás Átjáró egy virtuális hálózaton belül van, az Azure Front Door egy globális, decentralizált szolgáltatás.
A virtuális hálózat kialakítását olykor leegyszerűsítheti, ha az Application Gatewayt decentralizált Azure Front Doorra cseréli. Az itt leírt legtöbb terv érvényes marad, kivéve az Azure Firewall Azure Front Door előtti elhelyezésének lehetőségét.
Érdekes használati eset az Azure Firewall használata az Application Gateway előtt a virtuális hálózaton. A korábban ismertetett módon az X-Forwarded-For Application Gateway által beszúrt fejléc nem az ügyfél IP-címét, hanem a tűzfalpéldány IP-címét tartalmazza. A megkerülő megoldás az, ha az Azure Front Doort használja a tűzfal előtt, hogy fejlécként injektálja az ügyfél IP-címét, X-Forwarded-For mielőtt a forgalom belép a virtuális hálózatba, és eléri az Azure Firewallt. A második lehetőség a Forrás védelme privát kapcsolattal az Azure Front Door Premiumban.
A két szolgáltatás közötti különbségekről vagy az egyes szolgáltatások használatáról további információt az Azure Front Door gyakori kérdései című témakörben talál.
Egyéb hálózati virtuális berendezések
Nem a Microsoft-termékek az egyetlen lehetőség, hogy webalkalmazási tűzfalat vagy új generációs tűzfalfunkciót implementáljanak az Azure-ban. A Microsoft-partnerek széles köre biztosít hálózati virtuális berendezéseket (NVA-kat). A fogalmak és a kialakítások lényegében megegyeznek a jelen cikkben szereplőkkel, de van néhány fontos szempont:
- A következő generációs tűzfalakhoz használt partner NVA-k nagyobb ellenőrzést és rugalmasságot biztosíthatnak az Azure Firewall által nem támogatott NAT-konfigurációk esetében. Ilyenek például a helyszíni DNAT vagy az internetről származó DNST SNAT nélkül.
- Az Azure által felügyelt NVA-k (például az Application Gateway és az Azure Firewall) csökkentik az összetettséget, szemben azokkal az NVA-kkal, ahol a felhasználóknak számos berendezés skálázhatóságát és rugalmasságát kell kezelniük.
- Ha NVA-kat használ az Azure-ban, használjon aktív-aktív és automatikus skálázási beállításokat, így ezek a berendezések nem szűk keresztmetszetet képeznek a virtuális hálózaton futó alkalmazások számára.
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
További információ az összetevők technológiáiról:
- Mi az Azure-alkalmazás Átjáró?
- Mi az Az Azure Firewall?
- Mi az az Azure Front Door?
- Azure Kubernetes Service
- Mi az Az Azure Virtual Network?
- Mi az Az Azure Web Application Firewall?
Kapcsolódó erőforrások
Ismerkedjen meg a kapcsolódó architektúrákkal:
- Biztonságos hibrid hálózat megvalósítása
- Biztonságosan felügyelt webalkalmazások
- Microsoft Teams-csatornarobot és webalkalmazás védelme tűzfal mögött
- Fogyasztói állapot portál az Azure-ban
- Biztonsági szempontok az Azure-beli, rendkívül érzékeny IaaS-alkalmazásokhoz
- Több-bérlős SaaS az Azure-ban
- Vállalati üzembe helyezés az App Services-környezettel
- Magas rendelkezésre állású vállalati üzembe helyezés az App Services-környezettel
- Azure Kubernetes Service-fürt alaparchitektúrája