Hálózati és kapcsolati javaslatok

Cikk
11/15/2023

Az Azure Well-Architected Framework Security ellenőrzőlista-javaslatára vonatkozik:

SE:05	Elkülönítheti, szűrheti és vezérelheti a hálózati forgalmat a bejövő és kimenő folyamatok között. Alkalmazzon részletes védelmi alapelveket honosított hálózati vezérlők használatával a kelet-nyugati és az észak-déli forgalom minden rendelkezésre álló hálózati határán.

Ez az útmutató a hálózattervezésre vonatkozó javaslatokat ismerteti. A fókuszban olyan biztonsági vezérlők kerülnek, amelyek képesek szűrni, blokkolni és észlelni a hálózati határokat az architektúra különböző mélységében átlépő támadókat.

A hálózatalapú hozzáférés-vezérlési intézkedések végrehajtásával megerősítheti az identitásvezérlőket. Az identitásalapú hozzáférés-vezérlés mellett a hálózati biztonság kiemelt fontosságú az eszközök védelme szempontjából. A megfelelő hálózati biztonsági vezérlők részletes védelmi elemet biztosíthatnak, amely segíthet észlelni és eltárzni a fenyegetéseket, és megakadályozhatja, hogy a támadók belépjenek a számítási feladatba.

Definíciók

Időszak	Definíció
Kelet-nyugati forgalom	A megbízható határokon belül mozgó hálózati forgalom.
Kimenő forgalom	Kimenő számítási feladatok forgalma.
Ellenséges hálózat	Olyan hálózat, amely nincs üzembe helyezve a számítási feladat részeként. Az ellenséges hálózatot fenyegetésvektornak tekintik.
Bejövő forgalom	Bejövő számítási feladatok forgalma.
Hálózatszűrés	Olyan mechanizmus, amely engedélyezi vagy letiltja a hálózati forgalmat a megadott szabályok alapján.
Hálózati szegmentálás vagy elkülönítés	Egy stratégia, amely a hálózatokat kis, elkülönített szegmensekre osztja, és a határokon biztonsági vezérlőket alkalmaznak. Ez a technika segít megvédeni az erőforrásokat az ellenséges hálózatoktól, például az internettől.
Hálózatátalakítás	Egy mechanizmus, amely a hálózati csomagokat mutálja, hogy elrejtse őket.
Észak-déli forgalom	A megbízható határról a potenciálisan ellenséges külső hálózatokra átmenő hálózati forgalom, és fordítva.

Fő tervezési stratégiák

A hálózati biztonság obscurity használatával védi a számítási feladatok eszközeit az ellenséges hálózatoktól. A hálózati határ mögött található erőforrások mindaddig rejtve maradnak, amíg a határvezérlők biztonságosként nem jelölik meg a forgalmat a továbblépéshez. A hálózati biztonsági tervezés három fő stratégiára épül:

Szegmens. Ez a technika határvonalak hozzáadásával elkülöníti a forgalmat a különálló hálózatokon. Az alkalmazásrétegbe irányuló és onnan érkező forgalom például átlépi a határt, hogy más, eltérő biztonsági követelményekkel rendelkező rétegekkel kommunikáljon. A szegmentálás rétegei a mélységi védelem megközelítését valósítják meg.

A legfontosabb biztonsági határ az alkalmazás és a nyilvános hálózatok közötti hálózati peremhálózat. Fontos egyértelműen meghatározni ezt a szegélyt, hogy határt hozzon létre az ellenséges hálózatok elkülönítéséhez. Az ezen a peremen lévő vezérlőknek rendkívül hatékonynak kell lenniük, mert ez a határ az első védelmi vonal.

A virtuális hálózatok logikai határt biztosítanak. A virtuális hálózat szándékosan nem tud kommunikálni egy másik virtuális hálózattal, hacsak a határt szándékosan nem törték át a társviszony-létesítésen. Az architektúrának ki kell használnia ezt az erős, platform által biztosított biztonsági intézkedést.

Más logikai határokat is használhat, például a virtuális hálózaton belüli kivályúsított alhálózatokat. Az alhálózatok előnye, hogy ezek használatával csoportosíthatja azokat az erőforrásokat, amelyek egy elkülönítési határon belül vannak, és hasonló biztonsági garanciával rendelkeznek. Ezután konfigurálhat vezérlőket a határon a forgalom szűréséhez.
Szűrés. Ez a stratégia segít biztosítani, hogy a határt átlépő forgalom elvárt, engedélyezett és biztonságos legyen. Zero-Trust szempontjából a szűrés kifejezetten ellenőrzi az összes rendelkezésre álló adatpontot a hálózati szinten. A szabályok a határra helyezhetők, hogy bizonyos feltételeket ellenőrizzenek.

Például a fejléc szintjén a szabályok ellenőrizhetik, hogy a forgalom egy várt helyről származik-e, vagy hogy van-e várt kötete. De ezek az ellenőrzések nem elegendőek. Még ha a forgalom a várt jellemzőkkel is rendelkezik, előfordulhat, hogy a hasznos adat nem biztonságos. Az ellenőrzési ellenőrzések sql-injektálási támadást tárhatnak fel.
Átalakítás. A csomagok a határnál biztonsági intézkedésként mutatnak. Eltávolíthatja például a HTTP-fejléceket az expozíció kockázatának kiküszöbölése érdekében. Vagy egy ponton kikapcsolhatja a Transport Layer Security (TLS) szolgáltatást, és újra létrehozhatja egy másik ugrásban egy szigorúbban felügyelt tanúsítvánnyal.

A forgalmi folyamatok osztályozása

A folyamatok osztályozásának első lépése a számítási feladatok architektúrájának sémájának tanulmányozása. A séma alapján határozza meg a folyamat szándékát és jellemzőit a számítási feladat funkcionális hasznossági és működési szempontjai tekintetében. A folyamat besorolásához használja az alábbi kérdéseket:

Ha a számítási feladatnak kommunikálnia kell a külső hálózatokkal, milyen szintű közelség szükséges ezekhez a hálózatokhoz?
Mik a folyamat hálózati jellemzői, például a várt protokoll, valamint a csomagok forrása és alakja? Vannak-e megfelelőségi követelmények a hálózatkezelés szintjén?

A forgalmi folyamatok osztályozásának számos módja van. Az alábbi szakaszok a gyakran használt feltételeket ismertetik.

Külső hálózatok láthatósága

Nyilvános. A számítási feladatok nyilvánosak, ha az alkalmazás és más összetevők elérhetők a nyilvános internetről. Az alkalmazás egy vagy több nyilvános IP-címen és nyilvános DNS-kiszolgálón keresztül érhető el.
Magánjellegű. A számítási feladatok privátak, ha csak magánhálózaton, például virtuális magánhálózaton (VPN) keresztül érhetők el. Csak egy vagy több magánhálózati IP-címen keresztül érhető el, és lehetséges, hogy egy privát DNS-kiszolgálón keresztül.

Egy magánhálózaton nincs látóvonal a nyilvános internettől a számítási feladatig. Az átjáróhoz használhat terheléselosztót vagy tűzfalat. Ezek a lehetőségek biztonsági biztosítékokat nyújthatnak.

Még a nyilvános számítási feladatok esetében is törekedjen arra, hogy a számítási feladatok lehető legnagyobb részét magánjellegűen tartsa. Ez a megközelítés arra kényszeríti a csomagokat, hogy egy nyilvános hálózatról érkezve átlépjenek egy privát határt. Az elérési út átjárói áttűnési pontként működhetnek fordított proxyként.

Forgalom iránya

Bejövő forgalom. A bejövő forgalom egy számítási feladat vagy annak összetevői felé irányuló bejövő forgalom. A bejövő forgalom biztonságossá tételéhez alkalmazza az előző kulcsstratégiák készletét. Határozza meg, hogy mi a forgalmi forrás, és hogy az elvárt, engedélyezett és biztonságos-e. A nyilvános felhőszolgáltató IP-címtartományait beolvasó támadók sikeresen behatolhatnak a védelembe, ha nem ellenőrzik a bejövő forgalmat, vagy nem valósítanak meg alapvető hálózati biztonsági intézkedéseket.
Kimenő forgalom. A kimenő forgalom olyan kimenő forgalom, amely egy számítási feladattól vagy annak összetevőitől távol áramlik. A kimenő forgalom ellenőrzéséhez határozza meg, hogy hová tart a forgalom, és hogy a célhely várhatóan, engedélyezett és biztonságos-e. Előfordulhat, hogy a cél rosszindulatú, vagy adatkiszivárgási kockázatokkal van társítva.

Az expozíció szintjét úgy is meghatározhatja, ha figyelembe veszi a számítási feladat nyilvános internethez való közelségét. Az alkalmazásplatform például általában nyilvános IP-címeket szolgál ki. A számítási feladat összetevő a megoldás arca.

A befolyás hatóköre

Észak-dél. A számítási feladatok hálózata és a külső hálózatok közötti forgalom észak-déli forgalom. Ez a forgalom átlépi a hálózat peremhálózatát. A külső hálózatok lehetnek a nyilvános internet, a vállalati hálózat vagy bármely más hálózat, amely kívül esik az Ön hatókörén.

A bejövő és kimenő forgalom is lehet észak-déli forgalom.

Vegyük például egy küllős hálózati topológia kimenő forgalmát. A számítási feladat hálózati peremhálózatát úgy határozhatja meg, hogy a központ egy külső hálózat legyen. Ebben az esetben a küllő virtuális hálózatából érkező kimenő forgalom észak-déli forgalom. Ha azonban a központi hálózatot az irányítás területén belül tekinti, az észak-déli forgalom ki van terjesztve a központ tűzfalára, mert a következő ugrás az internet, amely potenciálisan ellenséges.
Kelet-Nyugat. A számítási feladatok hálózatán belüli forgalom kelet-nyugati forgalom. Az ilyen típusú forgalom akkor jelenik meg, ha a számítási feladat összetevői kommunikálnak egymással. Ilyen például az n szintű alkalmazások szintjei közötti forgalom. A mikroszolgáltatásokban a szolgáltatások közötti kommunikáció kelet-nyugati forgalom.

A mélységi védelem biztosításához tartsa fenn az egyes ugrások részét képező vagy a belső szegmensek közötti csomagok esetében használt biztonsági megfizethetőségeket. A különböző kockázati szintekhez különböző kockázatjavító módszerek szükségesek.

Az előző ábra a magánfelhőben található hálózatvédelmet szemlélteti részletesen. Ebben a diagramban a nyilvános és a magánhálózati IP-címterek közötti szegély jelentősen távolabb van a számítási feladattól, mint a nyilvános felhődiagramban. Több réteg választja el az Azure-üzemelő példányokat a nyilvános IP-címtértől.

Megjegyzés

Az identitás mindig az elsődleges szegély. A hozzáférés-kezelést a hálózati folyamatokra kell alkalmazni. Felügyelt identitások használata, ha azure-beli szerepköralapú hozzáférés-vezérlést (RBAC) használ a hálózat összetevői között.

A folyamatok besorolása után végezzen szegmentálási gyakorlatot a hálózati szegmensek kommunikációs útvonalán található tűzfalinjektálási pontok azonosításához. Ha a hálózatvédelmet minden szegmensben és minden forgalomtípusban mélységben tervezi meg, feltételezheti, hogy minden ponton megsérti a forgalmat. Használjon különböző honosított hálózati vezérlők kombinációját minden elérhető határnál. További információ: Szegmentálási stratégiák.

Tűzfalak alkalmazása a peremhálózaton

Az internet peremhálózati forgalma észak-déli forgalom, és a bejövő és kimenő forgalmat is magában foglalja. A fenyegetések észleléséhez vagy letiltásához egy peremhálózati stratégiának a lehető legtöbb internetes támadást kell elhárítania.

Kimenő forgalom esetén egyetlen tűzfalon keresztül küldje el az összes internethez kötött forgalmat , amely fokozott felügyeletet, szabályozást és forgalomirányítást biztosít. Bejövő forgalom esetén kényszerítse az internetről érkező összes forgalmat egy hálózati virtuális berendezésen (NVA) vagy egy webalkalmazási tűzfalon keresztül.

A tűzfalak általában egyhangosak, amelyek régiónként vannak üzembe helyezve egy szervezeten belül. Ennek eredményeképpen megosztják őket a számítási feladatok között, és egy központi csapat tulajdonában vannak. Győződjön meg arról, hogy a használt NVA-k a számítási feladat igényeinek kielégítésére vannak konfigurálva.
Javasoljuk, hogy a lehető legnagyobb mértékben használja az Azure natív vezérlőinek használatát.

A natív vezérlők mellett olyan partner NVA-kat is figyelembe vehet, amelyek speciális vagy speciális funkciókat biztosítanak. A partneri tűzfal és a webalkalmazási tűzfal gyártói termékei Azure Marketplace érhetők el.

A natív funkciók és a partnermegoldások használata a szervezet tapasztalatain és követelményein kell alapulnia.

Kompromisszum: A partneri képességek gyakran speciális funkciókat biztosítanak, amelyek védelmet nyújtanak a kifinomult, de általában ritka támadások ellen. A partnermegoldások konfigurációja összetett és törékeny lehet, mivel ezek a megoldások nem integrálhatók a felhő hálóvezérlőivel. Költség szempontjából a natív vezérlést részesíti előnyben, mert olcsóbb, mint a partnermegoldások.

Az Ön által megfontolt technológiai lehetőségeknek biztonsági vezérlőket és monitorozást kell biztosítaniuk mind a bejövő, mind a kimenő folyamatokhoz. Az Azure-hoz elérhető beállítások megtekintéséhez tekintse meg a cikk Edge-biztonság szakaszát.

Virtuális hálózat és alhálózat biztonságának megtervezése

A magánfelhő elsődleges célja a nyilvános internetről származó erőforrások elhomályosulása. Ennek a célnak több módja is van:

Lépjen privát IP-címterekre, amelyeket virtuális hálózatok használatával érhet el. Minimalizálja a hálózati látóvonalat még a saját magánhálózatán belül is.
Csökkentse a nyilvános DNS-bejegyzések számát, amellyel kevesebbet tesz közzé a számítási feladatból.
Adja hozzá a bejövő és kimenő hálózati forgalom vezérlését. Ne engedélyezze a nem megbízható forgalmat.

Szegmentálási stratégia

A hálózati láthatóság minimalizálása érdekében szegmentálta a hálózatot, és kezdje a minimális jogosultságú hálózati vezérlőkkel. Ha egy szegmens nem módosítható, nem érhető el. Bővítse a hatókört úgy, hogy csak azokat a szegmenseket foglalja magában, amelyeknek hálózati hozzáféréssel kell kommunikálniuk egymással.

A virtuális hálózatokat alhálózatok létrehozásával szegmentálta. Az osztás feltételeinek szándékosnak kell lenniük. Amikor egy alhálózaton belül rendezi a szolgáltatásokat, győződjön meg arról, hogy ezek a szolgáltatások láthatják egymást.

A szegmentálást számos tényezőre alapozhatja. Például különböző alkalmazásszinteket helyezhet el dedikált szegmensekben. Egy másik módszer az alhálózatok tervezése a jól ismert protokollokat használó gyakori szerepkörök és függvények alapján.

További információ: Szegmentálási stratégiák.

Alhálózati tűzfalak

Fontos megvizsgálni az egyes alhálózatok bejövő és kimenő forgalmát. Használja a cikk korábbi részében tárgyalt három fő stratégiát a Kulcstervezési stratégiák című témakörben. Ellenőrizze, hogy a folyamat várt, engedélyezett és biztonságos-e. Ezen információk ellenőrzéséhez definiáljon tűzfalszabályokat, amelyek a forgalom protokollján, forrásán és célján alapulnak .

Az Azure-ban hálózati biztonsági csoportokban állít be tűzfalszabályokat. További információkért lásd a cikk Hálózati biztonsági csoportok szakaszát.

Az alhálózatok kialakítására példa: Azure Virtual Network alhálózatok.

Vezérlők használata az összetevő szintjén

Miután minimálisra csökkentette a hálózat láthatóságát, leképezheti azure-erőforrásait hálózati szempontból, és kiértékelheti a folyamatokat. A következő típusú folyamatok lehetségesek:

Tervezett forgalom vagy a szolgáltatások közötti szándékos kommunikáció az architektúratervnek megfelelően. Ha például az architektúra azt javasolja, hogy Azure Functions lekérje az üzeneteket Azure Service Bus.
Felügyeleti forgalom vagy kommunikáció, amely a szolgáltatás funkcióinak részeként történik. Ez a forgalom nem része a tervnek, és ön nem szabályozhatja azt. A felügyelt forgalomra példa az architektúra Azure-szolgáltatásai és az Azure felügyeleti síkja közötti kommunikáció.

A tervezett és a felügyeleti forgalom megkülönböztetésével honosított vagy szolgáltatási szintű vezérlőket hozhat létre. Minden ugrásnál jól ismeri a forrást és a célt. Különösen annak megértése, hogy az adatsík hogyan van közzétéve.

Kiindulási pontként határozza meg, hogy az egyes szolgáltatások ki vannak-e téve az internetnek. Ha igen, tervezze meg, hogyan korlátozhatja a hozzáférést. Ha nem, helyezze egy virtuális hálózatba.

Szolgáltatás tűzfalai

Ha azt várja, hogy egy szolgáltatás elérhetővé válik az interneten, használja ki a legtöbb Azure-erőforráshoz elérhető szolgáltatásszintű tűzfalat. Ha ezt a tűzfalat használja, hozzáférési minták alapján állíthat be szabályokat. További információkért lásd a cikk Azure-szolgáltatás tűzfalai szakaszát.

Megjegyzés

Ha az összetevő nem szolgáltatás, használjon gazdagépalapú tűzfalat a hálózati szintű tűzfalak mellett. A virtuális gép (VM) egy olyan összetevő példája, amely nem szolgáltatás.

Kapcsolat a szolgáltatásként nyújtott platformszolgáltatásokkal (PaaS)

Fontolja meg privát végpontok használatát a PaaS-szolgáltatásokhoz való hozzáférés biztonságossá tételéhez. A privát végponthoz privát IP-cím van hozzárendelve a virtuális hálózatból. A végpont lehetővé teszi, hogy a hálózat többi erőforrása a privát IP-címen keresztül kommunikáljon a PaaS szolgáltatással.

A PaaS-szolgáltatással való kommunikáció a szolgáltatás nyilvános IP-címének és DNS-rekordjának használatával érhető el. Ez a kommunikáció az interneten keresztül történik. Ezt a kommunikációt privátsá teheti.

A PaaS szolgáltatás és az egyik alhálózat közötti alagút létrehoz egy privát csatornát. Az összes kommunikáció az összetevő privát IP-címéről az alhálózat egy privát végpontjára történik, amely ezután kommunikál a PaaS szolgáltatással.

Ebben a példában a bal oldali képen látható a nyilvánosan közzétett végpontok folyamata. A jobb oldalon ezt a folyamatot privát végpontok védik.

További információt a jelen cikk Privát végpontok szakaszában talál.

Megjegyzés

Javasoljuk, hogy privát végpontokat használjon a szolgáltatás tűzfalaival együtt. A szolgáltatás tűzfala blokkolja a bejövő internetes forgalmat, majd privát módon teszi elérhetővé a szolgáltatást a privát végpontot használó belső felhasználók számára.

A privát végpontok használatának másik előnye, hogy nem kell megnyitnia a tűzfal portjait a kimenő forgalomhoz. A privát végpontok zárolják a nyilvános internet portján lévő összes kimenő forgalmat. A kapcsolat a hálózaton belüli erőforrásokra korlátozódik.

Kompromisszum: Azure Private Link egy fizetős szolgáltatás, amely mérőkkel rendelkezik a feldolgozott bejövő és kimenő adatokhoz. A privát végpontokért is díjat számítunk fel.

Védelem az elosztott szolgáltatásmegtagadási (DDoS-) támadások ellen

A DDoS-támadások megpróbálják kimeríteni az alkalmazás erőforrásait, hogy elérhetetlenné tegyék az alkalmazást a jogszerű felhasználók számára. A DDoS-támadások az interneten keresztül nyilvánosan elérhető végpontokat célozhatják meg.

A DDoS-támadás általában a rendszer erőforrásainak tömeges, széles körben elterjedt, földrajzilag szétszórt visszaélése, amely megnehezíti a forrás meghatározását és letiltását.

A támadások elleni védelem érdekében Azure-támogatás lásd a cikk Azure DDoS Protection szakaszát.

Azure-beli facilitálás

Az alábbi Azure-szolgáltatások segítségével részletes védelmi képességeket adhat a hálózathoz.

Azure Virtual Network

Virtual Network segít az Azure-erőforrásoknak biztonságosan kommunikálni egymással, az internettel és a helyszíni hálózatokkal.

Alapértelmezés szerint a virtuális hálózat összes erőforrása képes kimenő kommunikációt folytatni az internettel. A bejövő kommunikáció azonban alapértelmezés szerint korlátozott.

Virtual Network a forgalom szűrésére szolgáló funkciókat kínál. A hozzáférést a virtuális hálózat szintjén korlátozhatja egy felhasználó által megadott útvonal (UDR) és egy tűzfalösszetevő használatával. Az alhálózat szintjén hálózati biztonsági csoportok használatával szűrheti a forgalmat.

Peremhálózat biztonsága

Alapértelmezés szerint a bejövő és a kimenő forgalom is a nyilvános IP-címeken halad át. A szolgáltatástól vagy a topológiától függően vagy ön állítja be ezeket a címeket, vagy az Azure hozzárendeli őket. A bejövő és kimenő forgalom egyéb lehetőségei közé tartozik a forgalom átvitele terheléselosztón vagy hálózati címfordítási (NAT) átjárón keresztül. Ezek a szolgáltatások azonban forgalomelosztásra szolgálnak, és nem feltétlenül a biztonságra.

A következő technológiai lehetőségek ajánlottak:

Azure Firewall. A Azure Firewall használhatja a hálózati peremhálózaton és népszerű hálózati topológiákban, például küllős hálózatokban és virtuális WAN-okban. A Azure Firewall általában kimenő tűzfalként helyezi üzembe, amely végső biztonsági kapuként szolgál, mielőtt a forgalom az internetre kerül. Azure Firewall irányíthatja a nem HTTP- és nem HTTPS-protokollokat használó forgalmat, például a Távoli asztali protokollt (RDP), a Secure Shell Protocolt (SSH) és a fájlátviteli protokollt (FTP). A Azure Firewall szolgáltatáskészlete a következőket tartalmazza:
- Célhálózati címfordítás (DNAT) vagy porttovábbítás.
- Behatolásészlelési és -megelőzési rendszer (IDPS) aláírásészlelése.
- Erős 3. réteg, 4. réteg és teljes tartománynév (FQDN) hálózati szabályok.
Megjegyzés

A legtöbb szervezet rendelkezik kényszerített bújtatási szabályzattal, amely kényszeríti a forgalmat egy NVA-n keresztüli forgalomra.

Ha nem használ virtuális WAN-topológiát, egy olyan UDR-t kell üzembe helyeznie, amely az egyiket Internet használja NextHopType az NVA privát IP-címére. Az UDR-ek az alhálózat szintjén vannak alkalmazva. Alapértelmezés szerint az alhálózatok közötti forgalom nem halad át az NVA-n.

Egyidejűleg Azure Firewall is használhat a bejövő forgalomhoz. Http- és HTTPS-forgalmat irányíthat. A magasabb szintű termékváltozatokban a Azure Firewall TLS-lezárásokat kínál, így hasznos adatszintű vizsgálatokat végezhet.

A következő eljárások ajánlottak:
- Engedélyezze a diagnosztikai beállításokat a Azure Firewall a forgalmi naplók, az IDPS-naplók és a DNS-kérések naplóinak gyűjtéséhez.
- A szabályokban a lehető legspecifikusabbnak kell lennie.
- Ahol ez praktikus, kerülje az FQDN-szolgáltatáscímkéket. Ha azonban használja őket, használja a regionális változatot, amely lehetővé teszi a szolgáltatás összes végpontjával való kommunikációt.
- Ip-csoportok használatával definiálhat olyan forrásokat, amelyeknek azonos szabályokkal kell rendelkeznie az IP-csoport élettartama során. Az IP-csoportoknak tükrözniük kell a szegmentálási stratégiát.
- Az infrastruktúra teljes tartománynevének engedélyezési szabályát csak akkor bírálja felül, ha a számítási feladathoz abszolút kimenőforgalom-vezérlés szükséges. A szabály felülbírálása megbízhatósági kompromisszummal jár, mivel az Azure platformkövetelményei megváltoznak a szolgáltatásokon.
Kompromisszum: Azure Firewall hatással lehet a teljesítményére. A szabályrend, a mennyiség, a TLS-vizsgálat és más tényezők jelentős késést okozhatnak.

A számítási feladat megbízhatóságára is hatással lehet. Előfordulhat, hogy a forráshálózati címfordítás (SNAT) portfogyását tapasztalja. A probléma megoldásához szükség szerint adjon hozzá nyilvános IP-címeket.

Kockázat: Kimenő forgalom esetén az Azure nyilvános IP-címet rendel hozzá. Ez a hozzárendelés alsóbb rétegbeli hatással lehet a külső biztonsági kapura.
Azure Web Application Firewall. Ez a szolgáltatás támogatja a bejövő szűrést, és csak a HTTP- és HTTPS-forgalmat célozza meg.

Alapvető biztonságot nyújt a gyakori támadásokhoz, például az Open Worldwide Application Security Project (OWASP) által az OWASP Top 10 dokumentumban azonosított fenyegetésekhez. Az Azure Web Application Firewall a 7. rétegre összpontosító egyéb biztonsági funkciókat is biztosít, például a sebességkorlátozást, az SQL-injektálási szabályokat és a helyek közötti szkriptelést.

Az Azure Web Application Firewall esetében a TLS-lezárás szükséges, mert a legtöbb ellenőrzés hasznos adatokon alapul.

Az Azure Web Application Firewall integrálható útválasztókkal, például Azure Application Gateway vagy Azure Front Doornal. Az ilyen típusú útválasztók azure-Web Application Firewall implementációi eltérőek lehetnek.

Azure Firewall és az Azure Web Application Firewall nem egymást kizáró lehetőségek. A peremhálózati biztonsági megoldáshoz különböző lehetőségek érhetők el. Példákért lásd: Tűzfal és Application Gateway virtuális hálózatokhoz.

Network security groups (Hálózati biztonsági csoportok)

A hálózati biztonsági csoport egy 3. és 4. rétegbeli tűzfal, amelyet az alhálózat vagy a hálózati adapter (NIC) szintjén alkalmaz. A hálózati biztonsági csoportok alapértelmezés szerint nincsenek létrehozva vagy alkalmazva.

A hálózati biztonsági csoport szabályai tűzfalként működnek az alhálózat szegélyén bejövő és kimenő forgalom leállításához. A hálózati biztonsági csoportok alapértelmezett szabálykészlete túlságosan megengedő. Az alapértelmezett szabályok például nem állítanak be tűzfalat a kimenő forgalom szempontjából. Bejövő forgalom esetén nem engedélyezett a bejövő internetes forgalom.

Szabályok létrehozásához kezdje az alapértelmezett szabálykészlettel:

Bejövő forgalom vagy bejövő forgalom esetén:
- A közvetlen, társhálózati és VPN-átjárókból származó virtuális hálózati forgalom engedélyezett.
- Azure Load Balancer állapottesztek engedélyezettek.
- Minden más forgalom le van tiltva.
Kimenő forgalom vagy kimenő forgalom esetén:
- A virtuális hálózati forgalom a közvetlen, a társhálózati és a VPN-átjáró célhelyeire engedélyezett.
- Az internetes forgalom engedélyezett.
- Minden más forgalom le van tiltva.

Ezután vegye figyelembe a következő öt tényezőt:

Protokoll
Forrás IP-címe
Forrásport
Cél IP-cím
Célport

Az FQDN támogatásának hiánya korlátozza a hálózati biztonsági csoportok működését. Adott IP-címtartományokat kell megadnia a számítási feladathoz, és nehéz őket karbantartani.

Az Azure-szolgáltatások esetében azonban szolgáltatáscímkék használatával összegzheti a forrás- és cél IP-címtartományokat. A szolgáltatáscímkék biztonsági előnye, hogy átlátszatlanok a felhasználó számára, és a felelősség ki van töltve az Azure-ba. Az alkalmazásbiztonsági csoportokat céltípusként is hozzárendelheti a forgalom átirányításához. Ez a névvel ellátott csoporttípus hasonló bejövő vagy kimenő hozzáférési igényű erőforrásokat tartalmaz.

Kockázat: A szolgáltatáscímkék tartományai nagyon szélesek, így a lehető legszélesebb ügyféltartományt képesek kielégíteni. Frissítések szolgáltatáscímkék esetében a szolgáltatás változásai elmaradnak.

Az előző képen a hálózati biztonsági csoportok lesznek alkalmazva a hálózati adapteren. A rendszer megtagadja az internetes forgalmat és az alhálózatok közötti forgalmat. A hálózati biztonsági csoportok a VirtualNetwork címkével együtt lesznek alkalmazva. Ebben az esetben tehát a társhálózatok alhálózatai közvetlen látóvonalat láthatnak. A címke széles körű definíciója VirtualNetwork jelentős biztonsági hatással lehet.

Szolgáltatáscímkék használata esetén lehetőség szerint használjon regionális verziókat, például Storage.WestUS a helyett Storage. Ezzel a megközelítéssel a hatókört egy adott régió összes végpontjára korlátozhatja.

Egyes címkék kizárólag bejövő vagy kimenő forgalomhoz használhatók. Mások mindkét típushoz tartoznak. A bejövő címkék általában lehetővé teszik az összes üzemeltetési számítási feladatból, például AzureFrontDoor.Backendaz Azure-ból vagy az Azure-ból érkező forgalmat a szolgáltatás futtatókörnyezeteinek(például LogicAppsManagement) támogatásához. Hasonlóképpen, a kimenő címkék lehetővé teszik az összes üzemeltetési számítási feladat felé vagy az Azure-ból érkező forgalmat a szolgáltatás-futtatókörnyezetek támogatásához.

A szabályok hatóköre a lehető legnagyobb mértékben. Az alábbi példában a szabály adott értékekre van beállítva. A rendszer minden más típusú forgalmat elutasít.

Tájékoztatás	Példa
Protokoll	Transmission Control Protocol (TCP), UDP
Forrás IP-címe	Bejövő forgalom engedélyezése az alhálózatra a forrás-IP-címtartományból<>: 4575/UDP
Forrásport	Bejövő forgalom engedélyezése az alhálózatra a következő szolgáltatáscímkéből<>: 443/TCP
Cél IP-cím	Kimenő forgalom engedélyezése az alhálózatról a cél-IP-címtartományba<>: 443/TCP
Célport	Kimenő forgalom engedélyezése az alhálózatról a következő szolgáltatáscímkére<>: 443/TCP

Összegezve:

Szabályok létrehozásakor legyen pontos. Csak az alkalmazás működéséhez szükséges forgalom engedélyezése. Minden mást tagadj. Ez a megközelítés korlátozza a hálózati látóvonalat a számítási feladat működéséhez szükséges hálózati folyamatokra. A szükségesnél több hálózati folyamat támogatása szükségtelen támadási vektorokhoz vezet, és kiterjeszti a felületét.

A forgalom korlátozása nem jelenti azt, hogy az engedélyezett folyamatok túlmutatnak a támadás hatókörén. Mivel a hálózati biztonsági csoportok a 3. és a 4. rétegben működnek az Open Systems Interconnection (OSI) veremen, csak alakzat- és irányinformációkat tartalmaznak. Ha például a számítási feladatnak engedélyeznie kell a DNS-forgalmat az internetre, akkor a hálózati biztonsági csoportot kell használnia.Internet:53:UDP Ebben az esetben előfordulhat, hogy a támadó adatokat tud kiszúrni az UDP-n keresztül az 53-os porton keresztül egy másik szolgáltatásba.
Ismerje meg, hogy a hálózati biztonsági csoportok némileg eltérhetnek egymástól. Könnyű figyelmen kívül hagyni a különbségek szándékát. A részletes szűrés érdekében biztonságosabb további hálózati biztonsági csoportokat létrehozni. Állítson be legalább egy hálózati biztonsági csoportot.
- A hálózati biztonsági csoport hozzáadása számos diagnosztikai eszközt, például folyamatnaplókat és hálózati forgalomelemzést old fel.
- A Azure Policy segítségével szabályozhatja a hálózati biztonsági csoportokkal nem rendelkező alhálózatok forgalmát.
Ha egy alhálózat támogatja a hálózati biztonsági csoportokat, adjon hozzá egy csoportot, még akkor is, ha az minimális hatással van rá.

Azure-szolgáltatás tűzfalai

A legtöbb Azure-szolgáltatás szolgáltatásszintű tűzfalat kínál. Ez a funkció megvizsgálja a szolgáltatás felé a megadott osztály nélküli tartományközi útválasztási (CIDR) tartományokból érkező bejövő forgalmat. Ezek a tűzfalak az alábbi előnyökkel járnak:

Alapvető biztonsági szintet biztosítanak.
Elviselhető teljesítményre van hatással.
A legtöbb szolgáltatás külön költség nélkül kínálja ezeket a tűzfalakat.
A tűzfalak naplókat bocsátanak ki az Azure-diagnosztika segítségével, ami hasznos lehet a hozzáférési minták elemzéséhez.

Ezekhez a tűzfalakhoz azonban biztonsági problémák is társulnak, és a paraméterek biztosításának korlátai is vannak. Ha például a Microsoft által üzemeltetett fordítóügynököket használja, meg kell nyitnia a Microsoft által üzemeltetett összes buildügynök IP-címtartományát. A tartomány ekkor megnyílik a buildügynök, más bérlők és támadók számára, akik visszaélhetnek a szolgáltatással.

Ha rendelkezik hozzáférési mintákkal a szolgáltatáshoz, amely szolgáltatás tűzfalszabály-készletként konfigurálható, engedélyeznie kell a szolgáltatást. A Azure Policy használatával engedélyezheti. Győződjön meg arról, hogy nem engedélyezi a megbízható Azure-szolgáltatások beállítást, ha alapértelmezés szerint nincs engedélyezve. Ezzel a szabályok hatókörébe tartozó összes függő szolgáltatást behozza.

További információkért tekintse meg az egyes Azure-szolgáltatások termékdokumentációját.

Privát végpontok

Private Link lehetővé teszi, hogy a PaaS-példánynak privát IP-címet adjon. A szolgáltatás ezután nem érhető el az interneten keresztül. A privát végpontok nem minden termékváltozat esetében támogatottak.

Privát végpontok használatakor tartsa szem előtt az alábbi javaslatokat:

Konfigurálja a virtuális hálózatokhoz kötött szolgáltatásokat, hogy privát végpontokon keresztül lépjen kapcsolatba a PaaS-szolgáltatásokkal, még akkor is, ha ezeknek a PaaS-szolgáltatásoknak is nyilvános hozzáférést kell biztosítaniuk.
A privát végpontok hálózati biztonsági csoportjainak használatának előmozdítása a privát végponti IP-címekhez való hozzáférés korlátozásához .
Privát végpontok használatakor mindig használjon szolgáltatás tűzfalakat.
Ha lehetséges, ha olyan szolgáltatással rendelkezik, amely csak privát végpontokon keresztül érhető el, távolítsa el a nyilvános végpont DNS-konfigurációját.
Fontolja meg a futtatókörnyezeti látási problémákat a privát végpontok implementálásakor. De vegye figyelembe a DevOps és a monitorozás szempontjait is.
Az erőforrás-konfiguráció kényszerítéséhez használja a Azure Policy.

Kompromisszum: A privát végpontokkal rendelkező szolgáltatás-termékváltozatok költségesek. A privát végpontok bonyolíthatják a műveleteket a hálózati homály miatt. Saját üzemeltetésű ügynököket, jump boxokat, VPN-t és más összetevőket kell hozzáadnia az architektúrához.

A DNS-kezelés összetett lehet a gyakori hálózati topológiákban. Előfordulhat, hogy DNS-továbbítókat és más összetevőket kell bevezetnie.

Virtuális hálózat injektálás

A virtuális hálózat injektálási folyamatával üzembe helyezhet néhány Azure-szolgáltatást a hálózatban. Ilyen szolgáltatások például a Azure App Service, a Functions, az Azure API Management és az Azure Spring Apps. Ez a folyamat elkülöníti az alkalmazást az internettől, a privát hálózatok rendszereitől és más Azure-szolgáltatásoktól. Az alkalmazás bejövő és kimenő forgalma hálózati szabályok alapján engedélyezhető vagy megtagadható.

Azure Bastion

Az Azure Bastion használatával csatlakozhat egy virtuális géphez a böngésző és a Azure Portal használatával. Az Azure Bastion fokozza az RDP- és SSH-kapcsolatok biztonságát. A tipikus használati esetek közé tartozik a jump boxhoz való csatlakozás ugyanabban a virtuális hálózatban vagy egy társviszonyban lévő virtuális hálózatban. Az Azure Bastion használatával nincs szükség arra, hogy a virtuális gép nyilvános IP-címmel rendelkezzen.

Azure DDoS Protection

Az Azure-ban minden tulajdonságot az Azure DDoS-infrastruktúra védelme véd extra költség nélkül és további konfiguráció nélkül. A védelem szintje alapszintű, de a védelem magas küszöbértékekkel rendelkezik. Emellett nem biztosít telemetriát vagy riasztást, és számítási feladattól független.

A DDoS Protection magasabb szintű termékváltozatai elérhetők, de nem ingyenesek. A globálisan üzembe helyezett Azure-hálózat mérete és kapacitása védelmet nyújt a gyakori hálózati szintű támadások ellen. Ezt a képességet olyan technológiák biztosítják, mint a folyamatos forgalomfigyelés és a valós idejű kockázatcsökkentés.

További információ: Az Azure DDoS Protection áttekintése.

Példa

Íme néhány példa, amelyek bemutatják az ebben a cikkben javasolt hálózati vezérlők használatát.

Informatikai környezet

Ez a példa a biztonsági alapkonfigurációban (SE:01) létrehozott informatikai környezetre épül. Ez a megközelítés átfogó képet nyújt a különböző szegélyeken alkalmazott hálózati vezérlőkről a forgalom korlátozása érdekében.

Hálózati támadási személyek. Egy hálózati támadás több személyt is figyelembe vehet, beleértve a rendszergazdákat, az alkalmazottakat, az ügyfél ügyfeleit és a névtelen támadókat.
VPN-hozzáférés. Egy rossz szereplő egy VPN-en vagy egy VPN-en keresztül a helyszíni környezethez csatlakoztatott Azure-környezeten keresztül érheti el a helyszíni környezetet. Konfiguráljon IPSec protokollal a biztonságos kommunikáció engedélyezéséhez.
Nyilvános hozzáférés az alkalmazáshoz. Az alkalmazás előtt legyen egy webalkalmazási tűzfal (WAF), amely a hálózati OSI-réteg 7. rétegében védi azt.
Operátori hozzáférés. A hálózati OSI-rétegek 4. rétegén keresztüli távelérést biztonságossá kell tenni. Fontolja meg a Azure Firewall idp/IDS-funkciókkal való használatát.
DDoS-védelem. DDoS-védelemmel rendelkezik a teljes virtuális hálózat számára.
Hálózati topológia. Az olyan hálózati topológia, mint a küllő, biztonságosabb, és optimalizálja a költségeket. A központi hálózat központi tűzfalvédelmet biztosít az összes társviszonyban lévő küllő számára.
Privát végpontok: Fontolja meg a nyilvánosan közzétett szolgáltatások magánhálózatba való hozzáadását privát végpontok használatával. Ezek létrehoznak egy hálózati kártyát (NIC-t) a privát virtuális hálózaton, és kötik az Azure-szolgáltatással.
TLS-kommunikáció. Az átvitel alatt lévő adatok védelme TLS-en keresztüli kommunikációval.
Hálózati biztonsági csoport (NSG): A virtuális hálózaton belüli szegmensek védelme az NSG-vel, amely egy ingyenes erőforrás, amely szűri a TCP/UDP bejövő és kimenő kommunikációját az IP- és porttartományok figyelembevételével. Az NSG része az alkalmazásbiztonsági csoport (ASG), amely lehetővé teszi címkék létrehozását a forgalmi szabályokhoz a könnyebb felügyelet érdekében.
Log Analytics. Az Azure-erőforrások a Log Analyticsbe betöltött telemetriát bocsátanak ki, amelyet egy SIEM-megoldással, például a Microsoft Sentinellel használnak elemzéshez.
Microsoft Sentinel-integráció. A Log Analytics integrálva van a Microsoft Sentinellel és más megoldásokkal, például a felhőhöz készült Microsoft Defender.
Microsoft Defender a felhőhöz. Microsoft Defender a Felhőhöz számos számítási feladatvédelmi megoldást kínál, beleértve a környezet hálózati javaslatait is.
Traffic Analytics: A hálózati vezérlők figyelése a Traffic Analytics használatával. Ez az Azure Monitor részét képező Network Watcher keresztül van konfigurálva, és az NSG által gyűjtött alhálózatokon lévő bejövő és kimenő találatokat összesíti.

Tárolóalapú számítási feladatok architektúrája

Ez a példaarchitektúra egyesíti a cikkben ismertetett hálózati vezérlőket. A példa nem jeleníti meg a teljes architektúrát. Ehelyett a magánfelhő bejövőforgalom-vezérlésére összpontosít.

Application Gateway egy webes forgalom terheléselosztója, amellyel kezelheti a webalkalmazások forgalmát. A Application Gateway egy dedikált alhálózaton helyezi üzembe, ahol hálózati biztonsági csoportvezérlők és webalkalmazási tűzfalvezérlők vannak érvényben.

Az összes PaaS-szolgáltatással való kommunikáció privát végpontokon keresztül történik. Minden végpont egy dedikált alhálózatba kerül. A DDoS Protection segít megvédeni az alapszintű vagy magasabb szintű tűzfalvédelemhez konfigurált összes nyilvános IP-címet.

A felügyeleti forgalom az Azure Bastionon keresztül korlátozott, így biztonságos és zökkenőmentes RDP- és SSH-kapcsolatot biztosít a virtuális gépekhez közvetlenül a Azure Portal TLS-en keresztül. A buildügynökök a virtuális hálózatba kerülnek, hogy hálózati nézetük legyen a számítási erőforrásokhoz, például a számítási erőforrásokhoz, a tárolóregisztrációs adatbázisokhoz és az adatbázisokhoz. Ez a megközelítés segít biztonságos és elkülönített környezetet biztosítani a buildügynökök számára, ami növeli a kód és az összetevők védelmét.

A számítási erőforrások alhálózati szintjén lévő hálózati biztonsági csoportok korlátozzák a kimenő forgalmat. A kényszerített bújtatás az összes forgalom Azure Firewall keresztüli irányítására szolgál. Ez a megközelítés segít biztonságos és elkülönített környezetet biztosítani a számítási erőforrások számára, ami növeli az adatok és alkalmazások védelmét.

Biztonsági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Biztonsági ellenőrzőlista

Share via

Hálózati és kapcsolati javaslatok