Hálózatkezelés és kapcsolat kritikus fontosságú számítási feladatokhoz az Azure-ban

A hálózatkezelés a kritikus fontosságú alkalmazások alapvető területe, figyelembe véve az ajánlott globálisan elosztott aktív-aktív tervezési megközelítést.

Ez a tervezési terület alkalmazásszinten vizsgálja a különböző hálózati topológia témaköröket, figyelembe véve a szükséges kapcsolatot és a redundáns forgalomkezelést. Pontosabban kiemeli azokat a kritikus szempontokat és javaslatokat, amelyek célja a kritikus fontosságú alkalmazások biztonságos és méretezhető globális hálózati topológiájának kialakítása.

Fontos

Ez a cikk az Azure Well-Architected kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a kritikus fontosságú számítási feladatokkal?

Globális forgalomirányítás

Több aktív regionális üzembehelyezési bélyeg használatához globális útválasztási szolgáltatásra van szükség a forgalom minden aktív bélyeghez való elosztásához.

Az Azure Front Door, az Azure Traffic Manager és az Azure standard Load Balancer biztosítják a többrégiós alkalmazások globális forgalmának kezeléséhez szükséges útválasztási képességeket.

Alternatív megoldásként a harmadik féltől származó globális útválasztási technológiák is megfontolhatók. Ezek a lehetőségek szinte zökkenőmentesen felcserélhetők az Azure natív globális útválasztási szolgáltatásainak lecseréléséhez vagy kiterjesztéséhez. A népszerű lehetőségek közé tartoznak a CDN-szolgáltatók útválasztási technológiái.

Ez a szakasz az Azure-beli útválasztási szolgáltatások fő különbségeit mutatja be annak meghatározásához, hogyan használhatók fel a különböző forgatókönyvek optimalizálására.

Kialakítási szempontok

• Az egyetlen régióhoz kötött útválasztási szolgáltatás egy meghibásodási pontot jelent, és jelentős kockázatot jelent a regionális kimaradások tekintetében.

• Ha az alkalmazás számítási feladatai magukban foglalják az ügyfélvezérlést, például mobil- vagy asztali ügyfélalkalmazásokkal, szolgáltatásredundancia biztosítható az ügyfél-útválasztási logikán belül.

  • Több globális útválasztási technológia, például az Azure Front Door és az Azure Traffic Manager párhuzamosan tekinthető redundancia szempontjából, és az ügyfelek úgy vannak konfigurálva, hogy egy alternatív technológiára adjanak át feladatokat, ha bizonyos meghibásodási feltételek teljesülnek. A több globális útválasztási szolgáltatás bevezetése jelentős összetettségeket mutat be a peremhálózati gyorsítótárazási és Web Application Firewall képességek, valamint az SSL-kiszervezés és a bejövő útvonalak alkalmazásérvényesítésének tanúsítványkezelése terén.
  • Külső technológiák is megfontolhatók, amelyek globális útválasztási rugalmasságot biztosítanak az Azure-platform hibáinak minden szintjére.

• Az Azure Front Door és a Traffic Manager közötti képességbeli eltérés azt jelenti, hogy ha a két technológia a redundancia érdekében egymás mellett van elhelyezve, akkor a konzisztens és elfogadható szolgáltatási szint fenntartásához eltérő bemeneti útvonalra vagy kialakítási módosításokra lenne szükség.

• Az Azure Front Door és az Azure Traffic Manager globálisan elosztott szolgáltatások, beépített többrégiós redundanciával és rendelkezésre állással.

  • A rugalmas útválasztási szolgáltatások globális elérhetőségének veszélyeztetéséhez elég nagy méretű feltételezett meghibásodási forgatókönyvek szélesebb körű kockázatot jelentenek az alkalmazás számára a kaszkádolt és korrelált hibák tekintetében.
    • Az ilyen léptékű meghibásodási forgatókönyveket csak olyan közös alapszolgáltatások okozzák, mint például az Azure DNS vagy Microsoft Entra ID, amelyek szinte az összes Azure-szolgáltatás globális platformfüggőségei. Redundáns Azure-technológia alkalmazása esetén valószínű, hogy a másodlagos szolgáltatás elérhetetlenséget vagy csökkentett teljesítményű szolgáltatást fog tapasztalni.
    • A globális útválasztási szolgáltatás meghibásodási forgatókönyvei nagy valószínűséggel jelentős hatással lesznek sok más szolgáltatásra, amelyet a kulcsfontosságú alkalmazásösszetevőkhöz használnak szolgáltatásközi függőségek révén. Még ha külső technológiát is használnak, az alkalmazás valószínűleg nem kifogástalan állapotban lesz a mögöttes probléma szélesebb körű hatása miatt, ami azt jelenti, hogy az Azure-beli alkalmazásvégpontokhoz való útválasztás egyébként is kevés értéket biztosít.

• A globális útválasztási szolgáltatás redundanciái rendkívül kevés feltételezett meghibásodási forgatókönyv esetén nyújtanak kockázatcsökkentést, ahol a globális kimaradások hatása az útválasztási szolgáltatásra korlátozódik.

  A globális üzemkimaradási forgatókönyvek szélesebb körű redundanciáinak biztosítása érdekében többfelhős aktív-aktív üzembe helyezési megközelítés is megfontolható. A többfelhős aktív-aktív üzembe helyezési megközelítés jelentős működési összetettségeket vezet be, amelyek jelentős rugalmassági kockázatokat jelentenek, ami valószínűleg messze meghaladja a globális kimaradások feltételezett kockázatait.

• Olyan esetekben, amikor az ügyfélvezérlés nem lehetséges, egy függőséget kell létrehozni egyetlen globális útválasztási szolgáltatáson, hogy egységes belépési pontot biztosítson az összes aktív üzembehelyezési régió számára.

  • Az elkülönítésben való használatuk szolgáltatásszinten egy meghibásodási pontot jelent a globális függőségek miatt, még akkor is, ha beépített többrégiós redundanciát és rendelkezésre állást biztosítanak.
  • A kiválasztott globális útválasztási szolgáltatás által biztosított SLA a maximális elérhető összetett SLA,függetlenül attól, hogy hány üzembehelyezési régiót kell figyelembe venni.

• Ha az ügyfélvezérlés nem lehetséges, a működési kockázatcsökkentések úgy tekinthetők, hogy meghatározhatók egy másodlagos globális útválasztási szolgáltatásba való migrálási folyamat, ha egy globális leállás letiltja az elsődleges szolgáltatást. Az egyik globális útválasztási szolgáltatásból egy másikba való migrálás általában több órán át tartó, hosszadalmas folyamat, különösen akkor, ha a DNS-propagálást veszik figyelembe.

• Egyes külső globális útválasztási szolgáltatások 100%-os SLA-t biztosítanak. Az e szolgáltatások által nyújtott történelmi és elérhető SLA azonban általában 100%-nál alacsonyabb.

  • Bár ezek a szolgáltatások pénzügyi jóvátételt biztosítanak az elérhetetlenség érdekében, kevés jelentősége van, ha az elérhetetlenség hatása jelentős, például olyan biztonsági szempontból kritikus helyzetekben, ahol végső soron az emberi élet forog kockán. Ezért a technológiai redundanciát vagy a megfelelő működési kockázatcsökkentést még akkor is figyelembe kell venni, ha a meghirdetett jogi SLA 100%-os.

Azure Front Door

• Az Azure Front Door globális HTTP/S terheléselosztást és optimalizált kapcsolatot biztosít az Anycast protokoll és a megosztott TCP használatával a Microsoft globális gerinchálózatának kihasználása érdekében.

  • Az egyes háttérvégpontokhoz számos kapcsolat van fenntartva.
  • A bejövő ügyfélkérések először az eredeti ügyfélhez legközelebbi peremcsomóponton fejeződnek be.
  • A szükséges forgalomvizsgálatot követően a rendszer vagy a Microsoft gerinchálózatán keresztül továbbítja a kéréseket a megfelelő háttérrendszerbe meglévő kapcsolatokkal, vagy egy peremcsomópont belső gyorsítótárából kézbesíti a kéréseket.
  • Ez a megközelítés nagyon hatékony a nagy forgalmú kötetek háttérkapcsolatokon keresztüli terjesztésében.

• Egy beépített gyorsítótárat biztosít, amely a peremcsomópontok statikus tartalmát szolgálja ki. Ez sok esetben szükségtelenné teszi a dedikált tartalomkézbesítési hálózat (CDN) használatát is.

• Az Azure Web Application Firewall (WAF) az Azure Front Dooron használható, és mivel az Azure hálózati peremhálózati pontjain van üzembe helyezve a világ minden táján, a Front Door által a hálózati peremhálózaton megvizsgált minden bejövő kérést.

• Az Azure Front Door az Azure DDoS Protection Basic használatával védi az alkalmazásvégpontokat a DDoS-támadásoktól. Az Azure DDoS Standard további és fejlettebb védelmi és észlelési képességeket biztosít, és további rétegként adható hozzá az Azure Front Doorhoz.

• Az Azure Front Door teljes körűen felügyelt tanúsítványszolgáltatást kínál. Lehetővé teszi a végpontok TLS-kapcsolatának biztonságát a tanúsítvány életciklusának kezelése nélkül.

• Az Azure Front Door Premium támogatja a privát végpontokat, így a forgalom az internetről közvetlenül az Azure-beli virtuális hálózatokra áramlik. Ez szükségtelenné tenné a nyilvános IP-címek használatát a virtuális hálózaton, hogy a háttérrendszereket elérhetővé tegye az Azure Front Door Premiumon keresztül.

• Az Azure Front Door állapottesztekre és háttérállapot-végpontokra (URL-címekre) támaszkodik, amelyeket időközönként hívunk meg, hogy visszaadjon egy HTTP-állapotkódot, amely tükrözi, hogy a háttérrendszer megfelelően működik-e, és a HTTP 200 (OK) válasz kifogástalan állapotot tükröz. Amint egy háttérrendszer nem kifogástalan állapotot jelez, egy bizonyos peremhálózati csomópont szempontjából az élcsomópont ott nem küldi el a kéréseket. A nem kifogástalan állapotú háttérrendszereket ezért a rendszer késedelem nélkül eltávolítja a forgalomból.

• Csak a HTTP/S protokollokat támogatja.

• Az Azure Front Door WAF és Application Gateway WAF némileg eltérő funkciókészletet biztosít, bár a beépített és az egyéni szabályokat is támogatja, és beállítható észlelési vagy megelőzési módban is.

• Előfordulhat, hogy a Front Door háttérbeli IP-tárhelye megváltozik, de a Microsoft biztosítja az Integráció az Azure IP-címtartományokkal és szolgáltatáscímkékkel. Feliratkozhat az Azure IP-tartományokra és a szolgáltatáscímkékre, hogy értesítéseket kapjon az esetleges változásokról vagy frissítésekről.

• Az Azure Front Door különböző terheléselosztási konfigurációkat támogat:

  • Késésalapú: az alapértelmezett beállítás, amely az ügyfél "legközelebbi" háttérrendszeréhez irányítja a forgalmat; a kérés késése alapján.
  • Prioritásalapú: aktív-passzív beállításokhoz hasznos, ahol a forgalmat mindig egy elsődleges háttérrendszerbe kell küldeni, kivéve, ha az nem érhető el.
  • Súlyozott: olyan kanári-üzemelő példányokra alkalmazható, amelyekben a forgalom bizonyos százaléka egy adott háttérrendszerbe kerül. Ha több háttérrendszerhez azonos súlyok vannak hozzárendelve, a rendszer késésalapú útválasztást használ.

• Az Azure Front Door alapértelmezés szerint késésalapú útválasztást használ, amely olyan helyzetekhez vezethet, amikor egyes háttéralkalmazások sokkal több bejövő forgalmat kapnak, mint mások, attól függően, hogy az ügyfelek honnan származnak.

• Ha az ügyfélkérések sorozatát ugyanazzal a háttérrendszerrel kell kezelni, akkor a munkamenet-affinitás konfigurálható az előtérben. Egy ügyféloldali cookie-t használ a későbbi kérések elküldéséhez az első kéréssel megegyező háttérrendszerbe, feltéve, hogy a háttérrendszer továbbra is elérhető.

Azure Traffic Manager

• Az Azure Traffic Manager egy DNS-átirányítási szolgáltatás.

  • A tényleges kérelem hasznos adatai nincsenek feldolgozva, ehelyett a Traffic Manager a kiválasztott forgalomirányítási módszer konfigurált szabályai alapján visszaadja a készlet egyik háttérrendszerének DNS-nevét.
  • A háttérBELI DNS-név ezután a végső IP-címére lesz feloldva, amelyet az ügyfél később közvetlenül hív meg.

• Az ügyfél gyorsítótárazza és újra felhasználja a DNS-választ egy megadott élettartamra (TTL) vonatkozóan, és az ebben az időszakban küldött kérések közvetlenül a háttérvégpontra kerülnek Traffic Manager-interakció nélkül. Kiküszöböli az extra csatlakozási lépést, amely költségelőnyt biztosít a Front Doorhoz képest.

• Mivel a kérés közvetlenül az ügyféltől a háttérszolgáltatáshoz történik, a háttérrendszer által támogatott protokollok kihasználhatók.

• Az Azure Front Doorhoz hasonlóan az Azure Traffic Manager állapottesztekre is támaszkodik annak megértéséhez, hogy a háttérrendszer kifogástalan állapotú-e és megfelelően működik-e. Ha egy másik értéket ad vissza, vagy semmit nem ad vissza, az útválasztási szolgáltatás felismeri a folyamatban lévő problémákat, és leállítja az adott háttérrendszerre irányuló útválasztási kéréseket.

  • Az Azure Front Doortól eltérően azonban a nem kifogástalan háttérrendszer eltávolítása nem azonnali, mivel az ügyfelek továbbra is kapcsolatot létesítenek a nem kifogástalan állapotú háttérrendszerrel, amíg a DNS TTL le nem jár, és a Traffic Manager szolgáltatástól új háttérvégpontot kérnek.
  • Emellett még a TTL lejártakor sem garantálható, hogy a nyilvános DNS-kiszolgálók betartják ezt az értéket, így a DNS-propagálás valójában sokkal tovább tarthat. Ez azt jelenti, hogy a forgalom hosszabb ideig továbbra is elküldhető a nem kifogástalan állapotú végpontra.

Azure Standard Load Balancer

Fontos

A régiók közötti standard Load Balancer előzetes verzióban, technikai korlátozásokkal érhető el. Ez a beállítás nem ajánlott kritikus fontosságú számítási feladatokhoz.

Tervezési javaslatok

• A HTTP/S-forgatókönyvek elsődleges globális forgalomirányítási szolgáltatása az Azure Front Door. Az Azure Front Door erősen támogatja a HTTP/S számítási feladatokat, mivel optimalizált forgalomirányítást, transzparens feladatátvételt, privát háttérvégpontokat (prémium termékváltozattal), peremhálózati gyorsítótárazást és integrációt biztosít a Web Application Firewall (WAF) szolgáltatással.

• Olyan alkalmazásforgatókönyvek esetén, ahol az ügyfélvezérlés lehetséges, alkalmazzon ügyféloldali útválasztási logikát a feladatátvételi forgatókönyvek figyelembevételéhez, amikor az elsődleges globális útválasztási technológia meghibásodik. Két vagy több globális útválasztási technológiát párhuzamosan kell elhelyezni a további redundancia érdekében, ha az egyszeri szolgáltatási SLA nem elegendő. Globális szolgáltatáshiba esetén az ügyféllogika szükséges a redundáns technológiához való átirányításhoz.

  • Két különböző URL-címet kell használni, amelyek mindegyike a különböző globális útválasztási szolgáltatásokra van alkalmazva a feladatátvétel általános tanúsítványkezelési élményének és útválasztási logikájának leegyszerűsítése érdekében.
  • Rangsorolja a külső útválasztási technológiák másodlagos feladatátvételi szolgáltatásként való használatát, mivel ez csökkenti a legtöbb globális hibaforgatókönyvet, és az iparág vezető CDN-szolgáltatói által kínált képességek egységes kialakítási megközelítést biztosítanak.
  • Figyelembe kell venni azt is, hogy a különálló útválasztási szolgáltatás helyett közvetlenül egyetlen regionális bélyegzőre kell közvetlenül útválasztást létrehozni. Bár ez csökkentett szolgáltatási szintet eredményez, sokkal egyszerűbb tervezési megközelítést jelent.

Ez a kép egy redundáns globális terheléselosztó-konfigurációt mutat be, amelynek során az ügyfél feladatátvétele elsődleges globális terheléselosztóként az Azure Front Doort használja.

Fontos

Annak érdekében, hogy valóban mérsékelhető legyen a globális hibák kockázata az Azure platformon belül, figyelembe kell venni egy többfelhős aktív-aktív üzembe helyezési megközelítést, amely az aktív üzembehelyezési bélyegeket két vagy több felhőszolgáltatónál üzemelteti, és redundáns külső útválasztási technológiákat használ a globális útválasztáshoz.

Az Azure hatékonyan integrálható más felhőplatformokkal. Erősen ajánlott azonban, hogy ne alkalmazzon többfelhős megközelítést, mert jelentős működési összetettséggel rendelkezik, és különböző üzembehelyezési bélyegdefiníciókkal és a különböző felhőplatformok működési állapotának ábrázolásaival rendelkezik. Ez az összetettség számos rugalmassági kockázatot jelent az alkalmazás normál működésében, ami messze meghaladja a globális platformkimaradás feltételezett kockázatait.

• Bár nem ajánlott, az Azure Traffic Managert az Azure Front Doorba globális útválasztási redundanciához használó HTTP-számítási feladatok esetében fontolja meg a Web Application Firewall (WAF) kiszervezését az Azure Front Dooron keresztüli elfogadható forgalom Application Gateway érdekében.
  • Ez egy további hibapontot vezet be a szabványos bemeneti útvonalhoz, egy további kritikus útvonal-összetevőt, amely felügyelhető és skálázható, és további költségekkel jár a globális magas rendelkezésre állás biztosítása érdekében. Ez azonban jelentősen leegyszerűsíti a hibaforgatókönyvet azáltal, hogy konzisztenciát biztosít az elfogadható és nem elfogadható bemeneti útvonalak között az Azure Front Door és az Azure Traffic Manager használatával, mind a WAF-végrehajtás, mind a privát alkalmazásvégpontok tekintetében.
  • A hibaforgatókönyvekben a peremhálózati gyorsítótárazás elvesztése hatással lesz a teljes teljesítményre, és ezt egy elfogadható szolgáltatási szinthez kell igazítani, vagy enyhíteni kell a tervezési megközelítést. A konzisztens szolgáltatási szint biztosítása érdekében fontolja meg a peremhálózati gyorsítótárazást egy külső CDN-szolgáltatónak mindkét útvonalon.

Javasoljuk, hogy fontolja meg egy külső globális útválasztási szolgáltatást két Azure-beli globális útválasztási szolgáltatás helyett. Ez biztosítja a hibacsökkentés maximális szintjét és egy egyszerűbb kialakítási megközelítést, mivel a legtöbb iparági vezető CDN-szolgáltató az Azure Front Door által kínált peremhálózati képességeket kínálja.

Azure Front Door

• Az Azure Front Door felügyelt tanúsítványszolgáltatásával engedélyezheti a TLS-kapcsolatokat, és eltávolíthatja a tanúsítványéletciklusok kezelésének szükségességét.

• Az Azure Front Door Web Application Firewall (WAF) használatával védelmet biztosíthat a peremhálózaton a gyakori webes biztonsági résekkel, például az SQL-injektálással szemben.

• Használja az Azure Front Door beépített gyorsítótárát a peremcsomópontok statikus tartalmának kiszolgálásához.

  • A legtöbb esetben ez azt is megszünteti, hogy szükség van egy dedikált tartalomkézbesítési hálózatra (CDN).

• Konfigurálja az alkalmazásplatform bejövő pontjait a bejövő kérések fejlécalapú szűréssel történő ellenőrzéséhez az X-Azure-FDID használatával, hogy az összes forgalom áthaladjon a konfigurált Front Door-példányon. Fontolja meg az IP ACLing konfigurálását a Front Door szolgáltatáscímkéinek használatával az Azure Front Door háttérbeli IP-címtartományából és az Azure-infrastruktúra-szolgáltatásokból származó forgalom ellenőrzéséhez. Ez biztosítja, hogy a forgalom szolgáltatásszinten haladjon át az Azure Front Dooron, de a konfigurált Front Door-példányok használatához továbbra is fejlécalapú szűrésre lesz szükség.

• Definiáljon egy egyéni TCP-állapotvégpontot a kritikus alsóbb rétegbeli függőségek regionális üzembehelyezési bélyegzőn belüli érvényesítéséhez, beleértve az adatplatform-replikákat, például az Azure Cosmos DB-t az alapszintű referencia-implementáció által biztosított példában. Ha egy vagy több függőség nem megfelelő állapotúvá válik, az állapottesztnek ezt tükröznie kell a visszaadott válaszban, hogy a teljes regionális bélyeg kivehető legyen a forgalomból.

• Győződjön meg arról, hogy az állapottesztekre adott válaszok naplózása és az Azure Front Door által közzétett összes operatív adat betöltése a globális Log Analytics-munkaterületre, így egységes adatelfogadót és egyetlen működési nézetet tesz lehetővé a teljes alkalmazáson belül.

• Ha a számítási feladat nem rendkívül késésre érzékeny, egyenletesen oszd el a forgalmat az összes figyelembe vett regionális bélyegen, hogy a leghatékonyabban használhassa az üzembe helyezett erőforrásokat.

  • Ennek eléréséhez állítsa a "Késési érzékenység (további késés)" paramétert olyan értékre, amely elég magas ahhoz, hogy kielégítse a háttérrendszer különböző régiói közötti késési különbségeket. Győződjön meg arról, hogy az alkalmazás számítási feladatai számára elfogadható tűréshatárt biztosít az ügyfélkérések teljes késésével kapcsolatban.

• Csak akkor engedélyezze a munkamenet-affinitást, ha azt az alkalmazás megköveteli, mivel negatív hatással lehet a forgalomelosztás egyensúlyára. Teljesen állapot nélküli alkalmazás esetén, ha a javasolt kritikus fontosságú alkalmazástervezési megközelítést követi, bármely kérést bármely regionális üzembe helyezés kezelhet.

Azure Traffic Manager

• Használja a Traffic Managert nem HTTP/S-forgatókönyvekhez az Azure Front Door helyett. A képességkülönbségek különböző tervezési döntéseket hoznak a gyorsítótár- és WAF-képességek, valamint a TLS-tanúsítványkezelés terén.

• A WAF-képességeket minden régióban figyelembe kell venni a Traffic Manager bemeneti útvonalához, Azure Application Gateway használatával.

• Konfiguráljon egy megfelelően alacsony TTL-értéket, hogy optimalizálja a nem megfelelő állapotú háttérvégpontok forgalomból való eltávolításához szükséges időt abban az esetben, ha a háttérrendszer nem megfelelő állapotúvá válik.

• Az Azure Front Doorhoz hasonlóan egyéni TCP-állapotvégpontot kell definiálni a kritikus alsóbb rétegbeli függőségek regionális üzembehelyezési bélyegzőn belüli érvényesítéséhez, amelynek tükröződnie kell az állapotvégpontok által adott válaszban.

  A Traffic Manager esetében azonban további figyelmet kell fordítani a szolgáltatásszintű regionális feladatátvételre. például "kutyaleokkolás" a függőségi hibák miatt nem kifogástalan állapotú háttérrendszer eltávolításával kapcsolatos esetleges késés mérséklése érdekében, különösen akkor, ha nem lehet alacsony TTL-t beállítani a DNS-rekordokhoz.

• Figyelembe kell venni a külső CDN-szolgáltatókat a peremhálózati gyorsítótárazás elérése érdekében, amikor az Azure Traffic Managert használja elsődleges globális útválasztási szolgáltatásként. Ha a külső szolgáltatás is kínál peremhálózati WAF-képességeket, figyelembe kell venni a bejövő forgalom útvonalának egyszerűsítését, és esetleg el kell távolítani a Application Gateway szükségességét.

Alkalmazáskézbesítési szolgáltatások

A kritikus fontosságú alkalmazások hálózati bejövő forgalmának figyelembe kell vennie az alkalmazáskézbesítési szolgáltatásokat is a biztonságos, megbízható és méretezhető bejövő forgalom biztosítása érdekében.

Ez a szakasz a globális útválasztási javaslatokra épül a legfontosabb alkalmazáskézbesítési képességek feltárásával, figyelembe véve az olyan releváns szolgáltatásokat, mint az Azure standard Load Balancer, a Azure Application Gateway és az Azure API Management.

Kialakítási szempontok

• A TLS-titkosítás kritikus fontosságú a kritikus fontosságú alkalmazásokba irányuló bejövő felhasználói forgalom integritásának biztosításához, és a TLS-kiszervezés csak a bélyeg bejövő forgalmának helyén van alkalmazva a bejövő forgalom visszafejtéséhez. A TLS-kiszervezéshez a TLS-tanúsítvány titkos kulcsa szükséges a forgalom visszafejtéséhez.

• A Web Application Firewall védelmet nyújt a gyakori webes biztonsági rések, például az SQL-injektálás vagy a helyek közötti szkriptelés ellen, és elengedhetetlen a kritikus fontosságú alkalmazások maximális megbízhatósági törekvéseinek eléréséhez.

• Az Azure WAF beépített védelmet nyújt a 10 legfontosabb OWASP biztonsági rés ellen felügyelt szabálykészletek használatával.

  • A felügyelt szabálykészlet kibővítéséhez egyéni szabályok is hozzáadhatók.
  • Az Azure WAF engedélyezhető az Azure Front Dooron, Azure Application Gateway vagy az Azure CDN-en (jelenleg nyilvános előzetes verzióban).
    • Az egyes szolgáltatásokban kínált funkciók némileg eltérnek. Az Azure Front Door WAF például sebességkorlátozást, geoszűrést és robotvédelmet biztosít, amelyek még nem érhetőek el a Application Gateway WAF-ben. Ezek azonban mind a beépített, mind az egyéni szabályokat támogatják, és beállíthatók észlelési vagy megelőzési módban való működésre.
    • Az Azure WAF ütemterve biztosítja, hogy az összes szolgáltatásintegráció egységes WAF-szolgáltatáskészletet biztosítson.

• A külső WAF-technológiák, például az NVA-k és a Kubernetesen belüli fejlett bejövőforgalom-vezérlők is figyelembe vehetők a szükséges biztonságirés-védelem biztosításához.

• Az optimális WAF-konfiguráció általában finomhangolást igényel, függetlenül a használt technológiától.

  Azure Front Door

• Az Azure Front Door csak HTTP- és HTTPS-forgalmat fogad el, és csak ismert Host fejlécű kéréseket dolgoz fel. Ez a protokollblokkolás segít mérsékelni a protokollok és portok közötti mennyiségi támadásokat, valamint a DNS-erősítő és TCP-mérgezéses támadásokat.

• Az Azure Front Door egy globális Azure-erőforrás, ezért a konfiguráció globálisan üzembe van helyezve minden peremhálózati helyen.

  • Az erőforrás-konfiguráció nagy léptékben terjeszthető, hogy másodpercenként több százezer kérést kezeljen.
  • Frissítések konfigurálás, beleértve az útvonalakat és a háttérkészleteket, zökkenőmentesek, és nem okoznak állásidőt az üzembe helyezés során.

• Az Azure Front Door teljes körűen felügyelt tanúsítványszolgáltatást és saját tanúsítványt biztosít az ügyféloldali SSL-tanúsítványokhoz. A teljes körűen felügyelt tanúsítványszolgáltatás egyszerűsített üzemeltetési megközelítést biztosít, és a megoldás egyetlen területén végzett tanúsítványkezeléssel csökkenti a teljes kialakítás összetettségét.

• Az Azure Front Door legalább 60 nappal a tanúsítvány lejárata előtt automatikusan elforgatja a "felügyelt" tanúsítványokat a lejárt tanúsítványkockázatok elleni védelem érdekében. Ha önkiszolgáló tanúsítványokat használ, a frissített tanúsítványokat legkésőbb 24 órával a meglévő tanúsítvány lejárata előtt üzembe kell helyezni, különben az ügyfelek lejárt tanúsítványhibákat kaphatnak.

• A tanúsítványfrissítések csak akkor eredményeznek állásidőt, ha az Azure Front Door a "Managed" és a "Use Your Own Certificate" (Saját tanúsítvány használata) között vált.

• Az Azure Front Doort az Azure DDoS Protection Basic védi, amely alapértelmezés szerint integrálva van a Front Doorba. Ez folyamatos forgalomfigyelést, valós idejű kockázatcsökkentést biztosít, valamint védelmet nyújt a gyakori 7. rétegbeli DNS-lekérdezési áradásokkal vagy a 3/4. rétegbeli mennyiségi támadásokkal szemben.

  • Ezek a védelem segít fenntartani az Azure Front Door rendelkezésre állását akkor is, ha DDoS-támadással szembesül. Az elosztott szolgáltatásmegtagadási (DDoS-) támadások elérhetetlenné tehetnek egy célzott erőforrást, ha túlterhelik azt a illegitim forgalommal.

• Az Azure Front Door globális forgalomszinten is biztosít WAF-képességeket, míg Application Gateway WAF-et az egyes regionális üzembehelyezési bélyegeken belül kell megadni. A képességek közé tartoznak a tűzfalszabályok, amelyek védelmet nyújtanak a gyakori támadások, a geoszűrés, a címblokkolás, a sebességkorlátozás és az aláírás-egyeztetés ellen.

  Azure Load Balancer

• Az Azure Basic Load Balancer termékváltozatot nem támogatja az SLA, és a standard termékváltozathoz képest számos képességkorlátozással rendelkezik.

Tervezési javaslatok

• A lehető legkevesebb helyen végezze el a TLS-kiszervezést a biztonság fenntartása érdekében, miközben leegyszerűsíti a tanúsítványkezelési életciklust.

• Használjon titkosított kapcsolatokat (pl. HTTPS) attól a ponttól kezdve, amikor a TLS kiszervezése a tényleges alkalmazás-háttérrendszerbe történik. Az alkalmazásvégpontok nem lesznek láthatók a végfelhasználók számára, így az Azure által felügyelt tartományok( például azurewebsites.net vagy cloudapp.net) felügyelt tanúsítványokkal használhatók.

• HTTP(S) forgalom esetén győződjön meg arról, hogy a WAF-képességek az összes nyilvánosan közzétett végpont bejövő útvonalán belül vannak alkalmazva.

• Engedélyezze a WAF-képességeket egyetlen szolgáltatáshelyen, globálisan az Azure Front Door használatával, vagy regionálisan Azure Application Gateway, mivel ez leegyszerűsíti a konfiguráció finomhangolását, és optimalizálja a teljesítményt és a költségeket.

  Konfigurálja a WAF-ot megelőzési módban a támadások közvetlen blokkolásához. Csak akkor használja a WAF-et észlelési módban (azaz csak naplózással, de nem blokkolja a gyanús kéréseket), ha a megelőzési mód teljesítménybírsága túl magas. A vélelmezett további kockázatokat teljes mértékben meg kell érteni és a számítási feladat forgatókönyvének konkrét követelményeihez kell igazítani.

• Rangsorolja az Azure Front Door WAF használatát, mivel ez biztosítja a leggazdagabb Azure-natív funkciókészletet, és védelmet alkalmaz a globális peremhálózaton, ami leegyszerűsíti az általános kialakítást, és további hatékonyságot biztosít.

• Az Azure API Management csak akkor használja, ha nagy számú API-t ad ki külső ügyfeleknek vagy különböző alkalmazáscsoportoknak.

• Használja az Azure standard Load Balancer termékváltozatot a mikroszolgáltatás számítási feladatain belüli belső forgalomelosztási forgatókönyvekhez.

  • 99,99%-os SLA-t biztosít az Availability Zones üzembe helyezésekor.
  • Kritikus képességeket biztosít, például diagnosztikát vagy kimenő szabályokat.

• Az Azure DDoS Network Protection használatával védheti az egyes alkalmazás-virtuális hálózatokon üzemeltetett nyilvános végpontokat.

Gyorsítótárazás és statikus tartalomkézbesítés

A statikus tartalmak, például a képek, a JavaScript, a CSS és más fájlok speciális kezelése jelentős hatással lehet az általános felhasználói élményre és a megoldás általános költségeire. A statikus tartalom peremhálózati gyorsítótárazása felgyorsíthatja az ügyfél betöltési idejét, ami jobb felhasználói élményt eredményez, és csökkentheti a forgalom, az olvasási műveletek és a számítási teljesítmény költségeit is az érintett háttérszolgáltatásokon.

Kialakítási szempontok

• Nem minden olyan tartalom jön létre dinamikusan, amelyet egy megoldás elérhetővé tesz az interneten keresztül. Az alkalmazások statikus objektumokat (képeket, JavaScriptet, CSS-t, honosítási fájlokat stb.) és dinamikus tartalmakat egyaránt kiszolgálnak.
• A gyakran használt statikus tartalommal rendelkező számítási feladatok nagy mértékben profitálnak a gyorsítótárazásból, mivel csökkenti a háttérszolgáltatások terhelését, és csökkenti a tartalomelérés késését a végfelhasználók számára.
• A gyorsítótárazás natív módon implementálható az Azure-ban az Azure Front Door vagy az Azure Content Delivery Network (CDN) használatával.
  • Az Azure Front Door azure-natív peremhálózati gyorsítótárazási képességeket és útválasztási funkciókat biztosít a statikus és dinamikus tartalmak megosztásához.
    • A megfelelő útválasztási szabályok Azure Front Doorban /static/* való létrehozásával a forgalom transzparensen átirányítható statikus tartalmakra.
  • Összetettebb gyorsítótárazási forgatókönyvek implementálhatók az Azure CDN szolgáltatással, hogy teljes körű tartalomkézbesítési hálózatot hozzanak létre jelentős statikus tartalomkötetekhez.
    • Az Azure CDN szolgáltatás valószínűleg költséghatékonyabb lesz, de nem nyújtja ugyanazokat a speciális útválasztási és Web Application Firewall (WAF- ) képességeket, amelyeket az alkalmazástervezés más területeihez ajánlott. Ugyanakkor további rugalmasságot biztosít a külső megoldások hasonló szolgáltatásaival, például az Akamai és a Verizon hasonló szolgáltatásaival való integráláshoz.
  • Az Azure Front Door és az Azure CDN-szolgáltatások összehasonlítása során a következő döntési tényezőket kell megvizsgálni:
    • A szükséges gyorsítótárazási szabályok a szabálymotor használatával adhatók meg.
    • A tárolt tartalom mérete és a kapcsolódó költség.
    • A szabálymotor végrehajtásának havi díja (kérésenként számítva az Azure Front Dooron).
    • Kimenő forgalomra vonatkozó követelmények (az ár célonként eltérő).

Tervezési javaslatok

• A létrehozott statikus tartalom, például a képfájlok olyan méretű másolatai, amelyek soha nem vagy csak ritkán változnak, a gyorsítótárazásnak is hasznát vehetik. A gyorsítótárazás URL-paraméterek alapján és változó gyorsítótárazási időtartammal konfigurálható.
• Válassza el a statikus és dinamikus tartalmak kézbesítését a felhasználók számára, és a releváns tartalmakat a gyorsítótárból, hogy csökkentse a háttérszolgáltatások terhelését, és optimalizálja a végfelhasználók teljesítményét.
• Tekintettel arra, hogy az Azure Front Door globális útválasztási és Web Application Firewall (WAF) célokra való használatára vonatkozó erősen ajánlott (hálózati és kapcsolattervezési terület), javasoljuk, hogy rangsorolja az Azure Front Door gyorsítótárazási képességeinek használatát, hacsak nincsenek hiányosságok.

Virtuális hálózat integrációja

A kritikus fontosságú alkalmazások általában magukban foglalják a más alkalmazásokkal vagy függő rendszerekkel való integráció követelményeit, amelyek üzemeltethetők az Azure-ban, egy másik nyilvános felhőben vagy helyszíni adatközpontokban. Ez az alkalmazásintegráció nyilvános végpontok és az internet, illetve magánhálózatok használatával valósítható meg hálózati szintű integrációval. Végső soron az alkalmazásintegráció elérésének módja jelentős hatással lesz a megoldás biztonságára, teljesítményére és megbízhatóságára, és jelentősen befolyásolja a tervezési döntéseket más tervezési területeken.

A kritikus fontosságú alkalmazások a három átfogó hálózati konfiguráció egyikén belül helyezhetők üzembe, amely meghatározza, hogy az alkalmazásintegráció hogyan történhet hálózati szinten.

1. Nyilvános alkalmazás vállalati hálózati kapcsolat nélkül .
2. Nyilvános alkalmazás vállalati hálózati kapcsolattal .
3. Privát alkalmazás vállalati hálózati kapcsolattal .

Figyelemfelhívás

Azure-beli célzónán belüli üzembe helyezéskor 1. konfiguráció. online célzónán belül kell üzembe helyezni, míg a 2) és a 3) is a Corp. Connected Landing Zone (Csatlakoztatott kezdőzóna) szolgáltatáson belül kell üzembe helyezni a hálózati szintű integráció elősegítése érdekében.

Ez a szakasz bemutatja ezeket a hálózati integrációs forgatókönyveket, az Azure-beli virtuális hálózatok és a környező Azure hálózati szolgáltatások megfelelő használatának rétegezését, hogy az integrációs követelmények optimálisan teljesüljenek.

Kialakítási szempontok

Nincsenek virtuális hálózatok

• A legegyszerűbb kialakítási módszer az alkalmazás virtuális hálózaton belüli üzembe helyezése.

  • Az összes figyelembe vett Azure-szolgáltatás közötti kapcsolat teljes egészében nyilvános végpontokon és a Microsoft Azure gerinchálózatán keresztül érhető el. Az Azure-ban üzemeltetett nyilvános végpontok közötti kapcsolat csak a Microsoft gerinchálózatán halad át, és nem halad át a nyilvános interneten.
  • Az Azure-on kívüli külső rendszerekhez való kapcsolódást a nyilvános internet biztosítja.

• Ez a kialakítási megközelítés az "identitás mint biztonsági peremhálózat" használatát alkalmazza, hogy hozzáférést biztosítson a különböző szolgáltatásösszetevők és a függő megoldás között. Ez elfogadható megoldás lehet olyan forgatókönyvek esetében, amelyek kevésbé érzékenyek a biztonságra. Minden alkalmazásszolgáltatás és függőség nyilvános végponton keresztül érhető el, így sebezhetővé válik a jogosulatlan hozzáférés megszerzésére irányuló további támadási vektorokkal szemben.

• Ez a kialakítási megközelítés nem alkalmazható minden Azure-szolgáltatásra, mivel számos szolgáltatás, például az AKS, szigorú követelményt jelent egy mögöttes virtuális hálózat számára.

Izolált virtuális hálózatok

• A szükségtelen nyilvános végpontokkal kapcsolatos kockázatok csökkentése érdekében az alkalmazás üzembe helyezhető egy különálló hálózaton, amely nem csatlakozik más hálózatokhoz.

• A bejövő ügyfélkérésekhez továbbra is nyilvános végpontot kell kitenni az internetre, de minden további kommunikáció a virtuális hálózaton belül lehet privát végpontok használatával. Az Azure Front Door Premium használatakor közvetlenül az élcsomópontokról lehet privát alkalmazásvégpontokra irányítani.

• Bár az alkalmazásösszetevők közötti privát kapcsolat virtuális hálózatokon keresztül történik, a külső függőségekkel való kapcsolat továbbra is nyilvános végpontokra támaszkodik.

  • Ha támogatott, privát végpontokkal létesíthető kapcsolat az Azure platformszolgáltatásokkal. Ha más külső függőségek is léteznek az Azure-ban, például egy másik alsóbb rétegbeli alkalmazás, a kapcsolatot nyilvános végpontokon és a Microsoft Azure gerinchálózatán keresztül biztosítjuk.
  • Az Azure-on kívüli külső rendszerekhez való csatlakozást a nyilvános internet biztosítja.

• Az olyan forgatókönyvek esetében, ahol a külső függőségekre nem vonatkoznak hálózati integrációs követelmények, a megoldás elkülönített hálózati környezetben való üzembe helyezése maximális tervezési rugalmasságot biztosít. A szélesebb körű hálózati integrációhoz nincs társítva címzési és útválasztási korlátozás.

• Az Azure Bastion egy teljes mértékben platform által felügyelt PaaS-szolgáltatás, amely üzembe helyezhető egy virtuális hálózaton, és biztonságos RDP-/SSH-kapcsolatot biztosít az Azure-beli virtuális gépekhez. Amikor az Azure Bastionon keresztül csatlakozik, a virtuális gépeknek nincs szükségük nyilvános IP-címre.

• Az alkalmazás virtuális hálózatainak használata jelentős üzembehelyezési összetettségeket vezet be a CI/CD-folyamatokban, mivel az alkalmazástelepítések megkönnyítéséhez mind az adatsík, mind a vezérlősík hozzáférése szükséges a magánhálózatokon üzemeltetett erőforrásokhoz.

  • Biztonságos magánhálózati elérési utat kell létrehozni, hogy a CI/CD-eszközök elvégezhessenek a szükséges műveleteket.
  • A privát buildügynökök az alkalmazás virtuális hálózatán belül helyezhetők üzembe a virtuális hálózat által védett erőforrásokhoz való proxyhozzáférés érdekében.

Csatlakoztatott virtuális hálózatok

• A külső hálózati integrációs követelményekkel rendelkező forgatókönyvek esetében az alkalmazás virtuális hálózatai különböző kapcsolódási lehetőségek használatával csatlakoztathatók más virtuális hálózatokhoz az Azure-on belül, egy másik felhőszolgáltatón vagy helyszíni hálózatokon. Egyes alkalmazásforgatókönyvek például megfontolhatják az alkalmazásszintű integrációt más üzletági alkalmazásokkal, amelyeket privát módon üzemeltetnek egy helyszíni vállalati hálózaton belül.

• Az alkalmazáshálózat kialakításának összhangban kell lennie a szélesebb körű hálózati architektúrával, különösen az olyan témákkal kapcsolatban, mint a címzés és az útválasztás.

• Az Azure-régiók vagy a helyszíni hálózatok között átfedésben lévő IP-címterek jelentős versengést hoznak létre, ha figyelembe vesszük a hálózati integrációt.

  • A virtuális hálózati erőforrások frissíthetők, hogy további címteret vegyenek figyelembe, azonban ha egy társhálózat virtuális hálózati címtere megváltozik, szinkronizálásra van szükség a társviszony-létesítési hivatkozáson, ami ideiglenesen letiltja a társviszony-létesítést.
  • Az Azure az egyes alhálózatokon belül öt IP-címet foglal le, amelyeket figyelembe kell venni az alkalmazás virtuális hálózatainak és az azokat magában foglaló alhálózatoknak megfelelő méretek meghatározásakor.
  • Egyes Azure-szolgáltatások dedikált alhálózatokat igényelnek, például az Azure Bastiont, a Azure Firewall vagy az Azure Virtual Network Gatewayt. Ezeknek a szolgáltatási alhálózatoknak a mérete nagyon fontos, mivel elég nagynak kell lenniük ahhoz, hogy a szolgáltatás összes jelenlegi példányát támogathassák a jövőbeli skálázási követelmények figyelembevételével, de ne legyenek olyan nagyok, mint a szükségtelenül hulladékcímek.

• Ha helyszíni vagy többfelhős hálózatintegrációra van szükség, az Azure két különböző megoldást kínál a biztonságos kapcsolat létrehozásához.

  • Az ExpressRoute-kapcsolatcsoport mérete akár 100 Gb/s sávszélességet is biztosít.
  • A virtuális magánhálózat (VPN) úgy méretezhető, hogy összesített sávszélességet biztosítson akár 10 Gb/s-ig a küllős és a küllős hálózatokon, valamint akár 20 Gb/s-os azure-Virtual WAN.

Megjegyzés

Az Azure-beli célzónán belüli üzembe helyezéskor vegye figyelembe, hogy a helyszíni hálózatokhoz való szükséges kapcsolódást a célzóna implementációjának kell biztosítania. A kialakítás az ExpressRoute-ot és más Azure-beli virtuális hálózatokat használhatja Virtual WAN vagy küllős hálózat kialakításával.

• A további hálózati útvonalak és erőforrások felvétele további megbízhatósági és üzemeltetési szempontokat vezet be az alkalmazás számára az állapot fenntartásának biztosítása érdekében.

Tervezési javaslatok

• Ajánlott kritikus fontosságú megoldásokat üzembe helyezni az Azure-beli virtuális hálózatokon, ahol lehetséges, hogy eltávolítsák a szükségtelen nyilvános végpontokat, és korlátozzák az alkalmazás támadási felületét a biztonság és a megbízhatóság maximalizálása érdekében.

  • Privát végpontok használata az Azure platformszolgáltatásokhoz való csatlakozáshoz. A szolgáltatásvégpontok a Private Link nem támogató szolgáltatások esetében tekinthetők meg, feltéve, hogy az adatkiszivárgási kockázatok elfogadhatók vagy alternatív vezérlőkkel csökkenthetők.

• A vállalati hálózati kapcsolatot nem igénylő alkalmazásforgatókönyvek esetében az összes virtuális hálózatot rövid élettartamú erőforrásként kell kezelni, amelyet az új regionális üzembe helyezés során lecserélnek.

• Ha más Azure- vagy helyszíni hálózatokhoz csatlakozik, az alkalmazás virtuális hálózatait nem szabad rövid élettartamúként kezelni, mivel ez jelentős bonyodalmakat okoz a virtuális hálózatok közötti társviszony-létesítés és a virtuális hálózati átjáró erőforrásainak esetében. A virtuális hálózaton belüli összes releváns alkalmazás-erőforrásnak továbbra is rövid élettartamúnak kell lennie, és párhuzamos alhálózatokat kell használni a frissített regionális üzembehelyezési bélyegzők kék-zöld üzembe helyezésének megkönnyítésére.

• Olyan esetekben, amikor vállalati hálózati kapcsolatra van szükség az alkalmazások privát hálózatokon keresztüli integrációjának megkönnyítéséhez, győződjön meg arról, hogy a regionális alkalmazás virtuális hálózataihoz használt IPv4-címtér nem fedi át a többi csatlakoztatott hálózattal, és megfelelően van méretezve ahhoz, hogy megkönnyítse a szükséges skálázást anélkül, hogy frissítenie kellene a virtuális hálózati erőforrást, és állásidőt kellene eredményeznie.

  • Erősen ajánlott csak a magánhálózati internet címlefoglalásából származó IP-címeket használni (RFC 1918).
    • A privát IP-címek korlátozott rendelkezésre állásával rendelkező környezetek esetében (RFC 1918) fontolja meg az IPv6 használatát.
    • Ha nyilvános IP-cím használatára van szükség, győződjön meg arról, hogy csak a saját tulajdonú címblokkokat használja.
  • Az Azure-beli IP-címzés szervezeti terveihez igazodva biztosíthatja, hogy az alkalmazás hálózati IP-címtartománya ne legyen átfedésben más hálózatokkal helyszíni helyeken vagy Azure-régiókban.
  • Ne hozzon létre szükségtelenül nagy méretű alkalmazás virtuális hálózatokat annak érdekében, hogy az IP-címtér ne vessz el.

• Rangsorolja az Azure CNI for AKS hálózati integrációját, mivel egy gazdagabb funkciókészletet támogat.

  • Fontolja meg a Kubenet használatát olyan forgatókönyvek esetében, ahol korlátozott dühű IP-címek érhetők el, hogy illeszkedjenek az alkalmazáshoz egy korlátozott címtérben.

  • Rangsorolja az Azure CNI hálózati beépülő modul használatát az AKS hálózati integrációjához, és fontolja meg a Kubenet használatát az elérhető IP-címek korlátozott tartományával rendelkező forgatókönyvek esetében. További részletekért lásd: Mikroszegmentálás és kubernetes hálózati szabályzatok .

• Helyszíni hálózati integrációt igénylő forgatókönyvek esetén rangsorolja az Express Route használatát a biztonságos és méretezhető kapcsolat biztosítása érdekében.

  • Győződjön meg arról, hogy az Express Route-ra vagy VPN-re alkalmazott megbízhatósági szint teljes mértékben megfelel az alkalmazás követelményeinek.
  • Több hálózati útvonalat kell figyelembe venni, hogy szükség esetén további redundanciát biztosítson, például a több csatlakoztatott ExpressRoute-kapcsolatcsoportot, vagy a VPN feladatátvételi kapcsolati mechanizmusként való használatát.

• Győződjön meg arról, hogy a kritikus hálózati útvonalakon lévő összes összetevő összhangban van a társított felhasználói folyamatok megbízhatósági és rendelkezésre állási követelményeivel, függetlenül attól, hogy az elérési utak és a társított összetevő kezelését a központi informatikai csapatok alkalmazáscsapata biztosítja-e.

  Megjegyzés

  Az Azure-beli kezdőzónán belüli üzembe helyezéskor és a szélesebb körű szervezeti hálózati topológiával való integráláskor vegye figyelembe a hálózati útmutatót , hogy az alapvető hálózat összhangban legyen a Microsoft ajánlott eljárásaival.

• Az Azure Bastion vagy a virtuális magánkapcsolatok használatával elérheti az Azure-erőforrások adatsíkját, vagy felügyeleti műveleteket hajthat végre.

Internetes kimenő forgalom

Az internetes kimenő forgalom alapvető hálózati követelmény egy kritikus fontosságú alkalmazás számára a külső kommunikáció megkönnyítése érdekében a következő kontextusban:

1. Közvetlen alkalmazásfelhasználói interakció.
2. Alkalmazásintegráció az Azure-on kívüli külső függőségekkel.
3. Hozzáférés az alkalmazás által használt Azure-szolgáltatások által igényelt külső függőségekhez.

Ez a szakasz azt mutatja be, hogyan érhető el az internetes kimenő forgalom a biztonság, a megbízhatóság és a fenntartható teljesítmény fenntartása mellett, kiemelve a kritikus fontosságú környezetben ajánlott szolgáltatások fő kimenő forgalomra vonatkozó követelményeit.

Kialakítási szempontok

• Számos Azure-szolgáltatásnak nyilvános végpontokhoz kell hozzáférnie ahhoz, hogy a különböző felügyeleti és vezérlősík-funkciók a kívánt módon működjenek.

• Az Azure különböző közvetlen internetkapcsolati módszereket biztosít, például az Azure NAT Gatewayt vagy a Azure Load Balancer virtuális gépekhez vagy számítási példányokhoz egy virtuális hálózaton.

• Ha a virtuális hálózaton belülről érkező forgalom kifelé halad az internetre, hálózati címfordítást (NAT) kell végezni. Ez egy számítási művelet, amely a hálózati veremen belül történik, és amely hatással lehet a rendszer teljesítményére.

• Ha a NAT kis léptékben történik, a teljesítményre gyakorolt hatásnak elhanyagolhatónak kell lennie, ha azonban nagy számú kimenő kérés hálózati probléma merülhet fel. Ezek a problémák általában a "Forrás NAT (vagy SNAT) portfogyása" formájában jelentkeznek.

• Több-bérlős környezetben, például Azure App Service, az egyes példányok számára korlátozott számú kimenő port érhető el. Ha ezek a portok elfogynak, nem lehet új kimenő kapcsolatokat kezdeményezni. Ez a probléma a privát/nyilvános peremhálózati bejárások számának csökkentésével vagy egy méretezhetőbb NAT-megoldás, például az Azure NAT Gateway használatával hárítható el.

• A NAT korlátozásai mellett a kimenő forgalomra is szükség lehet biztonsági ellenőrzésekre.

  • Azure Firewall megfelelő biztonsági képességeket biztosít a hálózati kimenő forgalom védelméhez.

  • Azure Firewall (vagy ezzel egyenértékű NVA) a Kubernetes kimenő forgalomra vonatkozó követelményeinek védelmére használható a kimenő forgalom részletes szabályozásának biztosításával.

• A nagy mennyiségű internetes kimenő forgalom adatátviteli díjakat von maga után.

Azure NAT Gateway

• Az Azure NAT Gateway 64 000 tcp- és UDP-kapcsolatot támogat hozzárendelt kimenő IP-címenként.

  • Egyetlen NAT Gatewayhez legfeljebb 16 IP-cím rendelhető hozzá.
  • A TCP alapértelmezett üresjárati időtúllépése 4 perc. Ha az üresjárati időtúllépést magasabb értékre módosítják, a folyamatok hosszabb ideig lesznek tárolva, ami növeli az SNAT-portleltárra nehezedő nyomást.

• A NAT Gateway nem tud beépített zónaelkülönítést biztosítani. A zónaszintű redundancia eléréséhez a zónaszintű erőforrásokat tartalmazó alhálózatot hozzá kell igazítani a megfelelő zónaszintű NAT-átjárókhoz.

Tervezési javaslatok

• Minimalizálja a kimenő internetkapcsolatok számát, mivel ez hatással lesz a NAT teljesítményére.

  • Ha nagy számú internetkapcsolatra van szükség, fontolja meg az Azure NAT Gateway használatát a kimenő forgalom absztrakciójára.

• Használja Azure Firewall, ahol a kimenő internetes forgalom szabályozására és vizsgálatára vonatkozó követelmények léteznek.

  • Győződjön meg arról, hogy a Azure Firewall nem az Azure-szolgáltatások közötti forgalom vizsgálatára szolgál.

Megjegyzés

Azure-beli kezdőzónán belüli üzembe helyezéskor fontolja meg az alapszintű platform Azure Firewall erőforrás (vagy ezzel egyenértékű NVA) használatát. Ha egy központi platformbeli erőforrástól függ az internetes kimenő forgalom, akkor az erőforrás megbízhatósági szintjét és a társított hálózati útvonalat szorosan össze kell hangolni az alkalmazás követelményeivel. Az erőforrásból származó működési adatokat is elérhetővé kell tenni az alkalmazás számára, hogy tájékoztassa a lehetséges műveleti műveletet a meghibásodási forgatókönyvekben.

Ha a kimenő forgalomhoz nagy léptékű követelmények kapcsolódnak, figyelembe kell vennie egy kritikus fontosságú alkalmazás dedikált Azure Firewall-erőforrását, hogy mérsékelje a központilag megosztott erőforrásokkal kapcsolatos kockázatokat, például zajos szomszéd forgatókönyveket.

• Ha Virtual WAN környezetben van üzembe helyezve, a Tűzfalkezelőnek figyelembe kell vennie, hogy központosított felügyeletet biztosítson a dedikált alkalmazások Azure Firewall példányok számára, hogy a szervezeti biztonsági állapotok a globális tűzfalszabályzatokon keresztül legyenek megfigyelhetők.
• Győződjön meg arról, hogy a növekményes tűzfalszabályzatok szerepköralapú hozzáférés-vezérléssel delegálva vannak az alkalmazásbiztonsági csapatoknak, hogy lehetővé tegyék az alkalmazásszabályzatok önállóságát.

Zónák közötti és régiók közötti kapcsolat

Bár az alkalmazástervezés erősen támogatja a független regionális üzembehelyezési bélyegeket, számos alkalmazásforgatókönyv esetében továbbra is szükség lehet a különböző zónákban vagy Azure-régiókban üzembe helyezett alkalmazás-összetevők hálózati integrációjára, még akkor is, ha csak csökkentett szolgáltatási körülmények között. Az a módszer, amellyel a zónák közötti és régiók közötti kommunikációt el lehet érni, jelentős hatással van az általános teljesítményre és megbízhatóságra, amelyet az ebben a szakaszban szereplő szempontok és javaslatok vizsgálnak meg.

Kialakítási szempontok

• A kritikus fontosságú alkalmazások alkalmazástervezési megközelítése támogatja a független regionális üzemelő példányok használatát az egyetlen régióban lévő összes összetevőszinten alkalmazott zónaszintű redundanciával.

• A rendelkezésre állási zóna (AZ) egy fizikailag különálló adatközpont-hely egy Azure-régión belül, amely fizikai és logikai hibaelkülönítést biztosít egyetlen adatközpont szintjéig.

  A zónák közötti kommunikációhoz garantált a 2 ms-nál kisebb körúti késés. A zónák kis késési eltérést mutatnak a zónák közötti különböző távolságok és szálláncok miatt.

• A rendelkezésre állási zóna kapcsolata a regionális jellemzőktől függ, ezért előfordulhat, hogy a peremhálózati helyeken keresztül egy régióba belépő forgalmat a zónák között kell átirányítani a cél eléréséhez. Ez körülbelül 1ms-2ms késést ad hozzá a zónák közötti útválasztás és a "fénysebesség" megkötései miatt, de ennek csak a hiperérzékeny számítási feladatokra kell hatással lennie.

• Availability Zones egyetlen előfizetés kontextusában logikai entitásokként kezelik, így a különböző előfizetések eltérő zónaszintű leképezéssel rendelkezhetnek ugyanahhoz a régióhoz. Az A előfizetés 1. zónája például ugyanahhoz a fizikai adatközponthoz tartozhat, mint a B előfizetés 2. zónája.

• A régión belüli zónák közötti kommunikáció adatátviteli díjat számít fel GB sávszélességenként.

• Az alkalmazásösszetevők közötti rendkívül gyakori alkalmazásforgatókönyvek esetén az alkalmazásszintek zónák közötti szétosztása jelentős késést és megnövekedett költségeket okozhat. Ezt a kialakításon belül enyhítheti, ha egy üzembehelyezési bélyeget egyetlen zónára korlátoz, és több bélyeget helyez üzembe a különböző zónákban.

• A különböző Azure-régiók közötti kommunikáció nagyobb adatátviteli díjat von maga után GB sávszélességenként.

  • A vonatkozó adatátviteli sebesség a figyelembe vett Azure-régiók kontinensétől függ.
  • A kontinenseken áthaladó adatokért jelentősen magasabb díjakat kell fizetni.

• Az Express Route- és VPN-kapcsolati módszereket is használhatja a különböző Azure-régiók közvetlen összekapcsolására bizonyos forgatókönyvek vagy akár különböző felhőplatformok esetében.

• A szolgáltatások kommunikációs Private Link privát végpontok használatával történő közvetlen kommunikációhoz használhatók.

• A forgalom a helyszíni kapcsolatokhoz használt Express Route-kapcsolatcsoportokon keresztül rögzíthető, hogy megkönnyítse az útválasztást egy Azure-régióban lévő virtuális hálózatok és az ugyanazon a földrajzi régión belüli különböző Azure-régiók között.

  • Az ExpressRoute-on keresztüli hajbevágás megkerüli a virtuális hálózatok közötti társviszony-létesítéssel kapcsolatos adatátviteli költségeket, így a költségek optimalizálására is használható.
  • Ez a megközelítés további hálózati ugrásokat igényel az azure-beli alkalmazásintegrációhoz, ami késési és megbízhatósági kockázatokat jelent. Kibővíti az Express Route és a társított átjáróösszetevők szerepkörét az Azure-ból/helyszínről, hogy az Azure-/Azure-kapcsolatokat is magában foglalja.

• Ha a szolgáltatások között kis mértékű késésre van szükség, a közelségi elhelyezési csoportok akkor használhatók, ha a használt szolgáltatások támogatják.

Tervezési javaslatok

• Virtuális hálózatok közötti társviszony-létesítés használata egy régión belüli és különböző régiók közötti hálózatok összekapcsolásához. Erősen ajánlott elkerülni a hajbevágást az ExpressRoute-on belül.

• A Private Link használatával közvetlenül hozhat létre kommunikációt az ugyanabban a régióban lévő szolgáltatások vagy régiók között (az A régió szolgáltatása kommunikál a B régió szolgáltatásával).

• Olyan alkalmazás-számítási feladatok esetében, amelyek rendkívül forgalmasak az összetevők között, fontolja meg egy üzembehelyezési bélyeg egyetlen zónára való korlátozását, és több bélyeg üzembe helyezését a különböző zónákban. Ez biztosítja, hogy a zónaszintű redundancia egyetlen alkalmazásösszetevő helyett egy beágyazott üzembehelyezési bélyeg szintjén maradjon fenn.

• Ahol lehetséges, kezelje az egyes üzembehelyezési bélyegeket függetlenként és a többi bélyegtől leválasztva.

  • Az adatplatform-technológiákkal szinkronizálhatja az állapotokat a régiók között, nem pedig az alkalmazás szintjén a közvetlen hálózati útvonalakkal való konzisztenciát.
  • Kerülje a "kutya legging" forgalmat a különböző régiók között, hacsak nem szükséges, még meghibásodási forgatókönyv esetén is. Globális útválasztási szolgáltatások és végpontok közötti állapottesztek használatával egy teljes bélyeget kivonhat a forgalomból abban az esetben, ha egyetlen kritikus összetevőszint meghibásodik, ahelyett, hogy az adott hibás összetevőszinten lévő forgalmat egy másik régióba irányítanák.

• A hiperkésés szempontjából érzékeny alkalmazásforgatókönyvek esetében rangsorolja a zónák regionális hálózati átjárókkal való használatát, hogy optimalizálja a hálózati késést a bejövő útvonalakhoz.

Mikroszegmentálási és Kubernetes-hálózati szabályzatok

A mikroszegmentálás egy hálózatbiztonsági tervezési minta, amellyel elkülöníthetők és biztonságossá alakíthatóak az egyes alkalmazások számítási feladatai, és a számítási feladatok közötti hálózati forgalmat egy Teljes felügyelet modell alapján korlátozzák. Általában a hálózati támadási felület csökkentésére, a biztonsági incidensek elszigetelésének javítására és a biztonság megerősítésére alkalmazzák a szabályzatalapú alkalmazásszintű hálózati vezérlők használatával.

A kritikus fontosságú alkalmazások alkalmazásszintű hálózati biztonságot kényszeríthetnek ki hálózati biztonsági csoportok (NSG) használatával alhálózat vagy hálózati adapter szintjén, szolgáltatás Access Control listák (ACL) és hálózati szabályzatok használatával Azure Kubernetes Service (AKS) használatakor.

Ez a szakasz ezeknek a képességeknek az optimális használatát ismerteti, és alapvető szempontokat és javaslatokat nyújt az alkalmazásszintű mikroszegmentálás eléréséhez.

Kialakítási szempontok

• Az AKS két különböző hálózati modellben helyezhető üzembe:

  • Kubenet-hálózatkezelés: Az AKS-csomópontok integrálva vannak egy meglévő virtuális hálózaton belül, de a podok minden csomóponton egy virtuális átfedő hálózaton belül léteznek. A különböző csomópontokon lévő podok közötti forgalom a kube-proxyn keresztül irányítja át.
  • Az Azure Container Networking Interface (CNI) hálózatkezelése: Az AKS-fürt egy meglévő virtuális hálózaton belül van integrálva, és csomópontjai, podjai és szolgáltatásai ugyanabból a virtuális hálózatból kapnak IP-címeket, amelyhez a fürtcsomópontok csatlakoznak. Ez a különböző hálózati forgatókönyvek esetében releváns, amelyek a podok közötti közvetlen kapcsolatot igénylik. Különböző csomópontkészletek helyezhetők üzembe különböző alhálózatokon.

  Megjegyzés

  Az Azure CNI több IP-címteret igényel a Kubenethez képest. A hálózat megfelelő előzetes tervezésére és méretezésére van szükség. További információkért tekintse meg az Azure CNI dokumentációját.

• Alapértelmezés szerint a podok nem elkülönítettek, és bármilyen forrásból fogadják a forgalmat, és bármilyen célhelyre képesek forgalmat küldeni; egy pod képes kommunikálni egy adott Kubernetes-fürt összes többi podjával; A Kubernetes nem biztosít hálózati szintű elkülönítést, és nem különít el névtereket a fürt szintjén.

• A podok és a névterek közötti kommunikáció hálózati házirendek használatával elkülöníthető. A Hálózati házirend egy Kubernetes-specifikáció, amely hozzáférési szabályzatokat határoz meg a podok közötti kommunikációhoz. A hálózati házirendek használatával szabálykészlet definiálható a forgalom küldésének/fogadásának szabályozására, valamint egy vagy több címkeválasztónak megfelelő podgyűjteményre való alkalmazásra.

  • Az AKS két beépülő modult támogat, amelyek a hálózati szabályzatot, az Azure-t és a Calico-t implementálják. Mindkét beépülő modul Linux IPTable-t használ a megadott szabályzatok kényszerítéséhez. További részletekért tekintse meg az Azure és a Calico-szabályzatok közötti különbségeket és azok képességeit .
  • A hálózati szabályzatok nem ütköznek, mivel additívak.
  • A két pod közötti hálózati forgalom engedélyezéséhez a forrás pod kimenő forgalmának és a cél pod bejövőforgalom-szabályzatának egyaránt engedélyeznie kell a forgalmat.
  • A hálózati házirend szolgáltatás csak a fürt példányosításának időpontjában engedélyezhető. Meglévő AKS-fürtön nem engedélyezhető a hálózati szabályzat.
  • A hálózati szabályzatok kézbesítése konzisztens, függetlenül attól, hogy az Azure vagy a Calico van-e használatban.
  • A Calico gazdagabb funkciókészletet biztosít, beleértve a windows-csomópontok támogatását, és támogatja az Azure CNI-t és a Kubenetet.

• Az AKS támogatja a különböző csomópontkészletek létrehozását a különböző számítási feladatok elkülönítéséhez különböző hardver- és szoftverjellemzőkkel rendelkező csomópontok, például GPU-képességekkel rendelkező és anélküli csomópontok használatával.

  • A csomópontkészletek használata nem biztosít hálózati szintű elkülönítést.
  • A csomópontkészletek különböző alhálózatokat használhatnak ugyanazon a virtuális hálózaton belül. Az NSG-k alhálózati szinten alkalmazhatók a csomópontkészletek közötti mikroszegmentálás megvalósításához.

Tervezési javaslatok

• Konfiguráljon egy NSG-t az összes figyelembe vett alhálózaton, hogy ip ACL-t biztosítson a bejövő útvonalak védelméhez és az alkalmazás összetevőinek elkülönítéséhez egy Teljes felügyelet modell alapján.

  • Használjon Front Door-szolgáltatáscímkéket az NSG-kben az Azure Front Doorban definiált alkalmazás-háttérrendszereket tartalmazó összes alhálózaton, mivel ez ellenőrzi, hogy a forgalom egy jogszerű Azure Front Door háttérbeli IP-címtérből származik-e. Ez biztosítja, hogy a forgalom szolgáltatásszinten haladjon át az Azure Front Dooron, de a fejlécalapú szűrésre továbbra is szükség lesz egy adott Front Door-példány használatának biztosításához és az "IP-hamisítás" biztonsági kockázatainak csökkentéséhez.

  • A nyilvános internetes forgalmat le kell tiltani az RDP- és SSH-portokon az összes vonatkozó NSG-n.

  • Rangsorolja az Azure CNI hálózati beépülő modul használatát, és fontolja meg a Kubenet használatát olyan forgatókönyvek esetében, ahol korlátozott számú elérhető IP-cím található, hogy illeszkedjen az alkalmazáshoz egy korlátozott címtérben.

    • Az AKS az Azure CNI és a Kubenet használatát is támogatja. Az üzembe helyezéskor van kiválasztva.
    • Az Azure CNI hálózati beépülő modul egy robusztusabb és méretezhetőbb hálózati beépülő modul, és a legtöbb forgatókönyvhöz ajánlott.
    • A Kubenet egy egyszerűsített hálózati beépülő modul, amely korlátozott számú elérhető IP-címmel rendelkező forgatókönyvekhez ajánlott.
    • További részletekért lásd: Azure CNI .

• A Kubernetes Hálózati házirend funkcióját kell használni a fürt podjai közötti bejövő és kimenő forgalom szabályainak meghatározására. Részletes hálózati szabályzatok definiálása a podok közötti kommunikáció korlátozásához és korlátozásához.

  • Engedélyezze a hálózati házirendet Azure Kubernetes Service üzembe helyezéskor.
  • Fontossági sorrendbe kell állítani a Calico használatát, mert gazdagabb, szélesebb körű közösségi bevezetést és támogatást nyújtó funkciókészletet biztosít.

Következő lépés

Tekintse át az alkalmazás állapotának számszerűsítésével és megfigyelésével kapcsolatos szempontokat.

Állapotmodellezés és megfigyelhetőség