Hálózati és kapcsolati javaslatok
Az Azure Well-Architected Framework biztonsági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
SE:06 | Elkülönítheti, szűrheti és szabályozhatja 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 az összes rendelkezésre álló hálózathatáron a kelet-nyugati és az észak-déli forgalom között. |
---|
Ez az útmutató a hálózattervezésre vonatkozó javaslatokat ismerteti. A fókusz a biztonsági vezérlőkre összpontosít, amelyek képesek szűrni, blokkolni és észlelni a hálózati határokat átlépő támadókat az architektúra különböző mélységében.
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 megfékezni a fenyegetéseket, és megakadályozhatja, hogy a támadók belépjenek a számítási feladatba.
Meghatározások
Kifejezés | 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ózatokat 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 olyan 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 elhomályosítja. |
É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őbb 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ötti erőforrások addig rejtve maradnak, amíg a határvezérlők nem jelölik meg a forgalmat biztonságosként az előrehaladthoz. A hálózatbiztonsá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ásszintek felé 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édelmi megközelítést valósítják meg.
A legelső 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. A peremhálózat vezérlőinek rendkívül hatékonynak kell lenniük, mivel 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 nem tud kommunikálni egy másik virtuális hálózattal, hacsak a határt szándékosan nem törték fel társviszony-létesítéssel. 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 kifaragott alhálózatokat egy virtuális hálózaton belül. Az alhálózatok előnye, hogy segítségével 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álhatja a határ vezérlőelemeket a forgalom szűréséhez.
Szűrő. Ez a stratégia biztosítja, hogy a határt átlépő forgalom várható, engedélyezett és biztonságos legyen. Nulla megbízhatósági szempontból a szűrés kifejezetten ellenőrzi az összes rendelkezésre álló adatpontot a hálózati szinten. A megadott feltételek ellenőrzéséhez szabályokat helyezhet a határra.
A fejléc szintjén például a szabályok ellenőrizhetik, hogy a forgalom egy várt helyről származik-e, vagy hogy a forgalom a várt kötettel rendelkezik-e. De ezek az ellenőrzések nem elegendőek. Még ha a forgalom is a várt jellemzőket mutatja, előfordulhat, hogy a hasznos adatok nem biztonságosak. Az ellenőrzési ellenőrzések SQL-injektálási támadást eredményezhetnek.
Átalakítás. A csomagok mutációja a határnál biztonsági mértékként. Eltávolíthatja például a HTTP-fejléceket az expozíció kockázatának elkerülése érdekében. Vagy kikapcsolhatja a Transport Layer Security (TLS) szolgáltatást egy ponton, és újra létrehozhatja egy másik ugráskor 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 aspektusai 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, mi legyen a hálózatokhoz való szükséges közelségi szint?
Mik a folyamat hálózati jellemzői, például a várt protokoll, valamint a csomagok forrása és alakja? Vannak megfelelőségi követelmények a hálózatkezelés szintjén?
A forgalmi folyamatok osztályozása számos módon lehetséges. 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.
Privát. 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, illetve egy privát DNS-kiszolgálón keresztül érhető el.
Egy magánhálózatban 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én is törekedjen arra, hogy a számítási feladatok lehető legnagyobb része privát maradjon. 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 útvonal á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 olyan bejövő forgalom, amely egy számítási feladat vagy annak összetevői felé halad. 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 forgalom forrása, é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 implementálnak alapvető hálózati biztonsági intézkedéseket.
Kimenő forgalom. A kimenő forgalom olyan kimenő forgalom, amely egy számítási feladatból vagy annak összetevőiből áramlik. A kimenő forgalom ellenőrzéséhez határozza meg, hogy hová tart a forgalom, és hogy a cél várhatóan, engedélyezett és biztonságos-e. Előfordulhat, hogy a cél rosszindulatú, vagy adatkiszivárgási kockázattal 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 hatá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 nyilvános internet, vállalati hálózat vagy bármely más, az Ön hatókörén kívül eső hálózat.
A bejövő és a kimenő forgalom is lehet észak-déli forgalom.
Vegyük például a 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 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 figyelembe veszi a központi hálózatot a vezérlési szférán belül, az észak-déli forgalom kiterjeszthető 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 jön ki, 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 kézben az egyes ugrásokban szereplő, illetve a belső szegmensek közötti csomagokban használt biztonsági megfizethetőségeket. A különböző kockázati szintek különböző kockázatjavító módszereket igényelnek.
Az előző ábra a magánfelhőben található hálózatvédelmet mutatja be 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.
Feljegyzé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 részletesen megtervezi, akkor minden ponton feltételezze a behatolást. 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 a peremhálózati stratégiának a lehető legtöbb internetes támadást kell mérsékelnie.
Kimenő forgalom esetén az összes internethez kötött forgalmat egyetlen tűzfalon keresztül küldheti el, amely fokozott felügyeletet, szabályozást és forgalomvezérlé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 való áthaladáshoz.
A tűzfalak általában egytonosak, amelyek régiónként vannak üzembe helyezve egy szervezetben. 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 úgy vannak konfigurálva, hogy támogassák a számítási feladat igényeit.
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 a speciális vagy speciális funkciókat biztosító partner NVA-k is megfontolhatók. A partneri tűzfal és a webalkalmazási tűzfal gyártói termékei az Azure Marketplace-en é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 olyan fejlett funkciókat biztosítanak, amelyek védelmet nyújtanak a kifinomult, de általában nem gyakori 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 előnyben részesítjük a natív vezérlést, mert olcsóbb, mint a partnermegoldások.
A megfontolandó technológiai beállításoknak biztonsági vezérlőket és monitorozást kell biztosítaniuk mind a bejövő, mind a kimenő forgalom számára. Az Azure-hoz elérhető beállítások megtekintéséhez tekintse meg a cikk Edge biztonsági szakaszát.
Virtuális hálózat és alhálózat biztonságának tervezése
A magánfelhők elsődleges célja az erőforrások elhomályosulása a nyilvános internetről. Ennek a célnak több módja is van:
Lépjen a privát IP-címterekre, amelyeket virtuális hálózatok használatával érhet el. Csökkentse 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, amelyekkel kevesebbet tehet közzé a számítási feladatból.
Bejövő és kimenő hálózati forgalom vezérlésének hozzáadása. Ne engedélyezze a nem megbízható forgalmat.
Szegmentálási stratégia
A hálózat láthatóságának 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 érhető el, nem érhető el. Bővítse a hatókört úgy, hogy csak olyan szegmenseket tartalmazzon, 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 szegmentelheti. 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ákban. 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élhelyén alapulnak.
Az Azure-ban hálózati biztonsági csoportokban állít be tűzfalszabályokat. További információkért tekintse meg a cikk Hálózati biztonsági csoportok szakaszát.
Egy alhálózat-kialakításra 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. Például tervezett forgalmat, amikor az architektúra azt javasolja, hogy az Azure Functions lekérje az üzeneteket az Azure Service Busból.
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 elérhetők-e az interneten. Ha igen, tervezze meg a hozzáférés korlátozását. 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 tekintse meg az Azure szolgáltatás tűzfalai szakaszt ebben a cikkben.
Feljegyzé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 platformmal (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ásból az egyik alhálózatba való 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ókért tekintse meg a jelen cikk Privát végpontok szakaszát.
Feljegyzés
Javasoljuk, hogy a szolgáltatás tűzfalaival együtt használjon privát végpontokat. 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 portokat a tűzfalon a kimenő forgalom számára. A privát végpontok zárolják az összes kimenő forgalmat a nyilvános internet portján. A kapcsolat a hálózaton belüli erőforrásokra korlátozódik.
Kompromisszum: Az 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ás megpróbálja kimeríteni az alkalmazás erőforrásait, hogy elérhetetlenné tegye az alkalmazást a jogos felhasználók számára. A DDoS-támadások bármilyen olyan végpontot célozhatnak meg, amely nyilvánosan elérhető az interneten keresztül.
A DDoS-támadás általában a rendszer erőforrásaival való tömeges, széles körben elterjedt, földrajzilag elosztott visszaélés, amely megnehezíti a forrás felismerését és blokkolását.
A támadások elleni védelem Azure-támogatás lásd a jelen cikk Azure DDoS Protection szakaszát.
Az Azure megkönnyítése
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
A virtuális hálózat segítségével az Azure-erőforrások biztonságosan kommunikálhatnak 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.
A Virtuális hálózat szolgáltatásokkal szűri a forgalmat. 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 nyilvános IP-címeken halad át. A szolgáltatástól vagy a topológiától függően beállíthatja 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. Az Azure Firewallt a hálózat peremhálózatán és népszerű hálózati topológiákban, például küllős hálózatokban és virtuális WAN-okban használhatja. Az Azure Firewall általában kimenő tűzfalként van üzembe helyezve, amely végső biztonsági kapuként működik, mielőtt a forgalom az internetre kerül. Az Azure Firewall átirányíthatja a nem HTTP- és nem HTTPS protokollokat használó forgalmat, például távoli asztali protokollt (RDP), Secure Shell Protocol (SSH) és File Transfer Protocol (FTP) protokollt. Az 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.
Feljegyzés
A legtöbb szervezet rendelkezik kényszerített bújtatási szabályzattal, amely arra kényszeríti a forgalmat, hogy egy NVA-n haladjon keresztül.
Ha nem használ virtuális WAN-topológiát, egy olyan UDR-t kell üzembe helyeznie, amelyből egy
NextHopType
vanInternet
az NVA privát IP-címére. A rendszer az alhálózat szintjén alkalmazza az UDR-eket. Alapértelmezés szerint az alhálózatok közötti forgalom nem halad át az NVA-n.Az Azure Firewallt egyidejűleg is használhatja a bejövő forgalomhoz. HTTP- és HTTPS-forgalmat irányíthat. A magasabb szintű termékváltozatokban az Azure Firewall TLS-lezárásokat kínál, hogy hasznos adatszintű ellenőrzéseket valósítson meg.
A következő eljárások ajánlottak:
Engedélyezze a diagnosztikai beállításokat az Azure Firewallban a forgalmi forgalmi naplók, az IDPS-naplók és a DNS-kérelmek naplóinak gyűjtéséhez.
A szabályokban a lehető legkonkrasztosabbnak kell lennie.
Ahol 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. Ennek a szabálynak a felülírása megbízhatósági kompromisszummal jár, mivel az Azure platformkövetelményei változnak a szolgáltatásokon.
Kompromisszum: Az Azure Firewall hatással lehet a teljesítményére. A szabályrend, a mennyiség, a TLS-ellenőrzés és más tényezők jelentős késést okozhatnak.
A számítási feladatok megbízhatóságára is hatással lehet. Előfordulhat, hogy a forráshálózati címfordítás (SNAT) portkimerülése tapasztalható. 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 TLS-lezárás szükséges, mivel a legtöbb ellenőrzés hasznos adatokon alapul.
Az Azure Web Application Firewallt olyan útválasztókkal integrálhatja, mint például Azure-alkalmazás Gateway vagy Azure Front Door. Az Ilyen típusú útválasztók Azure Web Application Firewall-implementációi eltérőek lehetnek.
Az 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 állnak rendelkezésre. Példák : Tűzfal és Application Gateway virtuális hálózatokhoz.
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 be- é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 a kimenő forgalom szempontjából állítják be a tűzfalat. 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.
- Az Azure Load Balancer állapotmintái 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 internetre irányuló 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
A teljes tartománynév támogatásának hiánya korlátozza a hálózati biztonsági csoportok funkcióit. Adott IP-címtartományokat kell megadnia a számítási feladathoz, és nehezen tarthatók fenn.
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 csoport olyan erőforrásokat tartalmaz, amelyeknek hasonló bejövő vagy kimenő hozzáférési igényeik vannak.
Kockázat: A szolgáltatáscímkék tartományai nagyon szélesek, így a lehető legszélesebb ügyféltartományt tudják kielégíteni. A szolgáltatáscímkék frissítései elmaradnak a szolgáltatás változásaitól.
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 rendszer a címkével együtt alkalmazza a VirtualNetwork
hálózati biztonsági csoportokat. Ebben az esetben tehát a társhálózatok alhálózatai közvetlen látóvonalat alkotnak. 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 ahelyettStorage
, hogy Storage.WestUS
a . Ezzel a megközelítéssel a hatókört egy adott régió összes végpontja számá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 engedélyezik a forgalmat az összes üzemeltetési számítási feladatból, például AzureFrontDoor.Backend
az Azure-ból a szolgáltatás futtatókörnyezeteinek támogatása érdekében, például LogicAppsManagement
. Hasonlóképpen, a kimenő címkék lehetővé teszik az összes üzemeltetési számítási feladat vagy az Azure felé irányuló forgalmat a szolgáltatás futtatókörnyezeteinek 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 meghatározott é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ányából<>: 4575/UDP |
Forrásport | Bejövő forgalom engedélyezése az alhálózatra a következő szolgáltatáscímkérő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 meg. 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 kibővíti a felületet.
A forgalom korlátozása nem jelenti azt, hogy az engedélyezett folyamatok túllépik a támadás hatókörét. Mivel a hálózati biztonsági csoportok a 3. és a 4. rétegben dolgoznak az Open Systems-összekapcsolás (OSI) veremen, csak alakzat- és irányinformációkat tartalmaznak. Ha például a számítási feladatnak engedélyeznie kell az internetre irányuló DNS-forgalmat, akkor a következő hálózati biztonsági csoportot kell használnia
Internet:53:UDP
: . Ebben az esetben előfordulhat, hogy egy támadó az UDP-n keresztül képes adatokat kiszúrni az 53-os porton keresztül egy másik szolgáltatásba.Ismerje meg, hogy a hálózati biztonsági csoportok kissé 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ót és hálózati forgalomelemzést old fel.
Az Azure Policy használatával 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 ez minimálisan 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ó a megadott osztály nélküli tartományközi útválasztási (CIDR) tartományokból bejövő forgalmat vizsgálja a szolgáltatás felé. Ezek a tűzfalak előnyöket nyújtanak:
- Alapvető biztonsági szintet biztosítanak.
- Elviselhető a teljesítmény.
- A legtöbb szolgáltatás extra 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 megadására vonatkozó korlátozások is vannak. Ha például a Microsoft által üzemeltetett buildügynököket használja, meg kell nyitnia az IP-címtartományt az összes Microsoft által üzemeltetett buildügynök számára. A tartomány ekkor megnyílik a buildügynök, más bérlők és támadók számára, akik esetleg visszaélnek 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. Az Azure Policy használatával engedélyezheti azt. 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 minden függő szolgáltatást behoz, amely a szabályok hatókörébe tartozik.
További információkért tekintse meg az egyes Azure-szolgáltatások termékdokumentációját.
Privát végpontok
A Private Link segítségével privát IP-címet adhat egy PaaS-példánynak. A szolgáltatás ezután nem érhető el az interneten keresztül. A privát végpontok nem támogatottak az összes termékváltozat esetében.
Magánvé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égpontOK IP-címéhez 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 szemszögből kapcsolatos aggályokat a privát végpontok megvalósításakor. De vegye figyelembe a DevOps és a monitorozás szempontjait is.
Az Azure Policy használatával kényszerítse ki az erőforrás-konfigurációt.
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 egyéb ö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-alkalmazás Szolgáltatás, 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 magánhálózatok rendszereitől és más Azure-szolgáltatásoktól. Az alkalmazásból érkező és kimenő forgalom hálózati szabályok alapján engedélyezett vagy megtagadható.
Azure Bastion
Az Azure Bastion használatával csatlakozhat egy virtuális géphez a böngésző és az Azure Portal használatával. Az Azure Bastion fokozza az RDP- és SSH-kapcsolatok biztonságát. Egy tipikus használati eset magában foglalja a jump boxhoz való csatlakozást ugyanabban a virtuális hálózatban vagy egy társhálózatban lévő virtuális hálózathoz. 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 minden tulajdonságát az Azure DDoS-infrastruktúra védelme védi további költségek nélkül és hozzáadott 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 feladat-agnosztikus.
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ókért tekintse meg az Azure DDoS Protection áttekintését.
Példa
Íme néhány példa a cikkben javasolt hálózati vezérlők használatára.
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 széles körű ismereteket nyújt a forgalom korlátozása érdekében a különböző szegélyeken alkalmazott hálózati vezérlőkről.
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 OLYAN Azure-környezeten keresztül érheti el a helyszíni környezetet, amely VPN-en keresztül kapcsolódik a helyszíni környezethez. Konfiguráljon IPSec protokollal a biztonságos kommunikáció engedélyezéséhez.
Nyilvános hozzáférés az alkalmazáshoz. A hálózati OSI-réteg 7. rétegében egy webalkalmazási tűzfal (WAF) áll az alkalmazás előtt.
Operátori hozzáférés. A hálózati OSI-rétegek 4. rétegén keresztüli távelérést védeni kell. Fontolja meg az Azure Firewall használatát IDP/IDS-funkciókkal.
DDoS-védelem. DDoS-védelemmel rendelkezik a teljes virtuális hálózathoz.
Hálózati topológia. A küllős hálózati topológia 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) a privát virtuális hálózatban, és az Azure-szolgáltatáshoz kötik.
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 NSG-vel, amely egy ingyenes erőforrás, amely szűri a TCP/UDP bejövő és kimenő kommunikáció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 Analyticsben betöltött telemetriát bocsátanak ki, majd egy SIEM-megoldással, például a Microsoft Sentinellel használják elemzésre.
Microsoft Sentinel-integráció. A Log Analytics integrálva van a Microsoft Sentinellel és más megoldásokkal, például Felhőhöz készült Microsoft Defender.
Felhőhöz készült Microsoft Defender. Felhőhöz készült Microsoft Defender számos számítási feladatvédelmi megoldást kínál, beleértve a környezetére vonatkozó hálózati javaslatokat 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 Watcheren keresztül van konfigurálva, és összesíti az NSG által gyűjtött alhálózatok bejövő és kimenő találatait.
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ő vezérlőire összpontosít.
Az Application Gateway egy webes forgalom terheléselosztója , amellyel kezelheti a webalkalmazások felé irányuló forgalmat. Az Application Gatewayt egy dedikált alhálózaton helyezi üzembe, amely hálózati biztonsági csoportvezérlőkkel és webalkalmazási tűzfalvezérlőkkel rendelkezik.
Az összes PaaS-szolgáltatással folytatott 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átozva van, ami segít biztonságos és zökkenőmentes RDP- és SSH-kapcsolatot biztosítani a virtuális gépekhez közvetlenül az Azure Portalról 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ások, például a számítási erőforrások, a tárolóregisztrációs adatbázisok és az adatbázisok számára. Ez a megközelítés segít biztonságos és elszigetelt 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ással az összes forgalmat az Azure Firewallon keresztül irányíthatja. Ez a megközelítés segít biztonságos és elszigetelt 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.
Kapcsolódó hivatkozások
- Javaslatok szegmentálási stratégiák tervezéséhez
- Azure Virtual Network-alhálózatok
- Azure Virtual Network
- Azure Firewall
- Azure Web Application Firewall
- Tűzfal és Application Gateway virtuális hálózatokhoz
- Hálózati biztonsági csoportok
- Szolgáltatáscímkék
- Azure Private Link
- Privát végpontok
- Azure Bastion
- Az Azure DDoS Protection áttekintése
Biztonsági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.