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 különböző hálózati topológia témaköröket vizsgál alkalmazásszinten, figyelembe véve a szükséges kapcsolatot és a redundáns forgalomkezelést. Pontosabban a kritikus szempontokat és javaslatokat emeli ki, amelyek célja, hogy a kritikus fontosságú alkalmazások biztonságos és méretezhető globális hálózati topológiájának kialakítását tájékoztassa.

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 forgalom útválasztása

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ítja a szükséges útválasztási képességeket a többrégiós alkalmazások globális forgalmának kezeléséhez.

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őbb 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 és jelentős kockázatot jelent a regionális kimaradások tekintetében.

• Ha az alkalmazás számítási feladatai ügyfélvezérlést foglalnak magukban, 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ők meg a redundancia szempontjából, és az ügyfelek úgy vannak konfigurálva, hogy bizonyos meghibásodási feltételek teljesülése esetén egy alternatív technológiára adjanak át feladatokat. A több globális útválasztási szolgáltatás bevezetése jelentős összetettségeket vezet be a peremhálózati gyorsítótárazás és a webalkalmazási tűzfal képességei, valamint az SSL-kiszervezés tanúsítványkezelése és a bejövő útvonalak alkalmazásérvényesítése terén.
  • Külső technológiák is megfontolhatók, amelyek globális útválasztási rugalmasságot biztosítanak az Azure-platformhibák minden szintjére.

• Az Azure Front Door és a Traffic Manager közötti képességbeli különbségek azt jelentik, hogy ha a két technológia a redundancia szempontjából egymás mellett helyezkedik el, a konzisztens és elfogadható szolgáltatási szint fenntartásához eltérő bemeneti útvonalra vagy kialakítási változtatá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 kaszkádolt és korrelált hibák szempontjából.
    • Az ilyen szintű hibaforgatókönyveket csak közös alapszolgáltatások, például az Azure DNS vagy a Microsoft Entra ID okozzák, amelyek szinte az összes Azure-szolgáltatás globális platformfüggőségeként szolgálnak. Redundáns Azure-technológia alkalmazása esetén valószínű, hogy a másodlagos szolgáltatás is elérhetetlenséget vagy csökkentett 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 vannak a fő alkalmazásösszetevőkhöz szolgáltatásközi függőségeken keresztül használt számos más szolgáltatásra. Még ha külső technológiát is használnak, az alkalmazás valószínűleg nem kifogástalan állapotban lesz az alapul szolgáló 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 kis számú hipotetikus meghibásodási forgatókönyv esetén nyújtanak kockázatcsökkentést, ahol a globális kimaradás hatása maga az útválasztási szolgáltatásra van korlátozva.

  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ás feltételezett kockázatait.

• Az olyan helyzetekben, ahol az ügyfélvezérlés nem lehetséges, egy globális útválasztási szolgáltatáson kell függőséget létrehozni, hogy egységes belépési pontot biztosítson az összes aktív üzembehelyezési régióhoz.

  • Elszigetelten használva szolgáltatásszinten a globális függőségek miatt egy meghibásodási pontot jelentenek, annak ellenére, hogy 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-t jelenti, függetlenül attól, hogy hány üzembehelyezési régiót tekintünk.

• Ha az ügyfélvezérlés nem lehetséges, a működési kockázatcsökkentések meghatározhatók egy másodlagos globális útválasztási szolgáltatásba való migrálás folyamatának meghatározásához, ha egy globális kimaradás letiltja az elsődleges szolgáltatást. Az egyik globális útválasztási szolgáltatásból a 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 figyelembe veszik.

• 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, csekély jelentőséggel bír, ha az elérhetetlenség hatása jelentős, például 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 split TCP használatával, hogy kihasználhassa a Microsoft globális gerinchálózatának előnyeit.

  • A 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álat után a kérések vagy a Microsoft gerinchálózatán keresztül továbbítódnak a megfelelő háttérrendszerbe meglévő kapcsolatok használatával, vagy egy peremcsomópont belső gyorsítótárából lesznek kézbesítve.
  • Ez a megközelítés hatékonyan terjeszti a nagy forgalmú köteteket a háttérkapcsolatokon.

• 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 ellenőrzött bejövő kérések.

• 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 is hozzáadható 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 TLS-kapcsolat biztonságát a végpontok számára 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 közvetlenül az internetrő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 állapotadat-mintavételekre és háttérállapot-végpontokra (URL-címekre) támaszkodik, amelyeket rendszeres időközönként hív 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 kifogástalan állapotot tükröz, egy adott peremcsomópont szempontjából az élcsomópont leállítja a kérések küldését. A nem kifogástalan háttérrendszereket ezért a rendszer késedelem nélkül, transzparens módon eltávolítja a forgalomból.

• Csak a HTTP/S protokollokat támogatja.

• Az Azure Front Door WAF és az Application Gateway WAF egy kissé eltérő funkciókészletet biztosít, bár mind a beépített, mind az egyéni szabályokat 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-címe megváltozik, de a Microsoft biztosítja az Azure IP-tartományok és szolgáltatáscímkék integrációját. Az Azure IP-tartományokra és szolgáltatáscímkékre feliratkozva értesítéseket kaphat a módosítá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 a forgalmat az ügyfél "legközelebbi" háttérrendszeréhez irányítja; a kérelmek késése alapján.
  • Prioritásalapú: aktív-passzív beállítások esetén 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érrendszerek sokkal több bejövő forgalmat kapnak, mint mások, attól függően, hogy honnan származnak az ügyfelek.

• Ha az ügyfélkérések sorozatát ugyanazzal a háttérrendszerrel kell kezelni, 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 ugyanabba a háttérrendszerbe, mint az első kérés, 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égleges IP-címére lesz feloldva, amelyet az ügyfél később közvetlenül hív meg.

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

• Mivel a kérés közvetlenül az ügyféltől a háttérszolgáltatáshoz hajtható végre, 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 állapotban van-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érelmeket.

  • Az Azure Front Doortól eltérően azonban ez a nem kifogástalan háttérrendszer eltávolítása nem azonnali, mivel az ügyfelek a DNS TTL lejáratáig továbbra is kapcsolatot létesítenek a nem kifogástalan háttérrendszerrel, és új háttérvégpontot kérnek a Traffic Manager szolgáltatástól.
  • 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 továbbra is elküldhető a nem megfelelő állapotú végpontra egy tartós ideig.

Azure Standard Load Balancer

Fontos

A régiók közötti standard Load Balancer előzetes verzióban érhető el, technikai korlátozásokkal. 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ásaként használja az Azure Front Doort. 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 a webalkalmazási tűzfallal (WAF) való integrációt biztosít.

• Az olyan alkalmazásforgatókönyvek esetében, ahol az ügyfélvezérlés lehetséges, ügyféloldali útválasztási logikát alkalmazva vegye figyelembe azokat a feladatátvételi forgatókönyveket, amelyekben az elsődleges globális útválasztási technológia meghiúsul. Két vagy több globális útválasztási technológiát kell párhuzamosan elhelyezni a hozzáadott 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 vonatkozik a feladatátvétel általános tanúsítványkezelési élményének és útválasztási logikájának egyszerű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ági vezető CDN-szolgáltatók által kínált képességek egységes tervezési megközelítést biztosítanak.
  • Figyelembe kell venni azt is, hogy a külön útválasztási szolgáltatás helyett egyetlen regionális bélyegre kell közvetlenül útválasztást biztosítani. 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 az ügyfél feladatátvételével, amely elsődleges globális terheléselosztóként az Azure Front Doort használja.

Fontos

Az Azure-platformon belüli globális hibák kockázatának valódi csökkentése érdekében többfelhős aktív-aktív üzembe helyezési megközelítést kell figyelembe venni, két vagy több felhőszolgáltató aktív üzembehelyezési bélyegeivel és a globális útválasztáshoz használt redundáns külső útválasztási technológiákkal.

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 üzemeltetési összetettséggel rendelkezik, 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. 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 hipotetikus kockázatait.

• Bár nem ajánlott, az Azure Traffic Managert az Azure Front Doorba irányuló globális útválasztási redundanciához használó HTTP-számítási feladatok esetében fontolja meg a webalkalmazási tűzfal (WAF) az Application Gatewayre való kiszervezését az Azure Front Dooron áthaladó elfogadható forgalom érdekében.
  • Ez egy további hibapontot vezet be a standard bemeneti útvonalhoz, egy további kritikus útvonal-összetevőhöz, 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 Dooron és az Azure Traffic Manageren keresztül, mind a WAF-végrehajtás, mind a privát alkalmazásvégpontok tekintetében.
  • A hibaforgatókönyvben a peremhálózati gyorsítótárazás elvesztése hatással lesz az általános teljesítményre, és ezt egy elfogadható szolgáltatási szinthez vagy a tervezési megközelítés csökkentéséhez kell igazítani. A konzisztens szolgáltatási szint biztosítása érdekében fontolja meg az él-gyorsítótárazás külső CDN-szolgáltatóhoz való kiszervezését mindkét útvonalon.

Javasoljuk, hogy fontolja meg egy külső globális útválasztási szolgáltatást két Globális Azure-útválasztási szolgáltatás helyett. Ez biztosítja a hibaelhárítá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élyezze a TLS-kapcsolatokat, és távolítsa el 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 szükségtelenné teszi a dedikált tartalomkézbesítési hálózat (CDN) használatát is.

• Konfigurálja az alkalmazásplatform bejövő pontjait a bejövő kérések fejlécalapú szűrésen keresztüli ellenőrzéséhez az X-Azure-FDID használatával annak biztosítása érdekében, hogy az összes forgalom a konfigurált Front Door-példányon haladjon keresztül. Fontolja meg az IP ACLing konfigurálását a Front Door szolgáltatáscímkék használatával annak ellenőrzéséhez, hogy a forgalom az Azure Front Door háttérbeli IP-címteréből és az Azure infrastruktúra-szolgáltatásokból származik-e. 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 ellenőrzéséhez, beleértve az adatplatform-replikákat is, 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 állapotadat-mintavételnek tükröznie kell ezt 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 állapotadat-mintavételi válaszok naplózva vannak, és betöltik az Azure Front Door által közzétett összes operatív adatot a globális Log Analytics-munkaterületre, hogy egységes adatel fogadót és egyetlen működési nézetet biztosítson az egész alkalmazás számára.

• Hacsak a számítási feladat nem rendkívül késésre érzékeny, egyenletesen terjessze el a forgalmat az összes figyelembe vett regionális bélyegen a telepített erőforrások leghatékonyabb használatához.

  • Ennek eléréséhez állítsa a "Latency Sensitivity (Additional Latency)" 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 forgalomeloszlás egyensúlyára. Teljesen állapot nélküli alkalmazás esetén, ha az ajánlott 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 helyére. A képességbeli kü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 bejövő útvonalához, Azure-alkalmazás Átjáró használatával.

• Konfiguráljon egy megfelelően alacsony TTL-értéket, hogy optimalizálja a nem kifogástalan háttérbeli vé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 egyéni TCP-állapotvégpontot kell definiálni a kritikus alsóbb rétegbeli függőségek regionális üzembe helyezési bélyegen belüli ellenőrzé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. mint például a "kutya legging" a függőségi hibák miatti, nem kifogástalan háttérrendszer eltávolításával járó esetleges késés csökkenté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 bemeneti útvonal egyszerűsítése és az Application Gateway szükségességének esetleges megszüntetése érdekében.

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 kulcsfontosságú 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-alkalmazás Gateway és az Azure API Management.

Kialakítási szempontok

• A TLS-titkosítás kritikus fontosságú a kritikus fontosságú alkalmazások bejövő felhasználói forgalmának 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 kulcsára van szükség a forgalom visszafejtéséhez.

• A webalkalmazási tűzfal 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 az OWASP 10 legfontosabb biztonsági rése 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-alkalmazás Gatewayen vagy az Azure CDN-en (jelenleg nyilvános előzetes verzióban).
    • Az egyes szolgáltatások szolgáltatásai kissé eltérnek egymástól. Az Azure Front Door WAF például sebességkorlátozást, geoszűrést és robotvédelmet biztosít, amelyet még nem kínálnak az Application Gateway WAF-ben. Ezek azonban mind támogatják a beépített és az egyéni szabályokat, é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 tekinthetők a szükséges sebezhetőségi védelem biztosításának.

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

  Azure Front Door

• Az Azure Front Door csak HTTP- és HTTPS-forgalmat fogad el, és csak ismert Host fejlécet tartalmazó 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 van üzembe helyezve minden peremhálózati helyen.

  • Az erőforráskonfiguráció nagy léptékben terjeszthető másodpercenként több százezer kérés kezelésére.
  • Frissítések konfiguráció, beleértve az útvonalakat és a háttérkészleteket, zökkenőmentesek, és nem okoznak leállást 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 automatikusan elforgatja a "felügyelt" tanúsítványokat legalább 60 nappal a tanúsítvány lejárata előtt, hogy védelmet nyújtson a lejárt tanúsítványkockázatokkal szemben. Ha önkiszolgáló tanúsítványokat használ, a frissített tanúsítványokat a meglévő tanúsítvány lejárata előtt legkésőbb 24 órával kell üzembe helyezni, ellenkező esetben 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 "Felügyelt" és a "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, és védelmet nyújt a 7. rétegbeli DNS-lekérdezések gyakori áradásai vagy a 3/4. rétegbeli mennyiségi támadások ellen is.

  • Ezek a védelem segít fenntartani az Azure Front Door rendelkezésre állását, még 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 illegitim forgalommal terhelik.

• Az Azure Front Door globális forgalmi szinten is biztosít WAF-képességeket, míg az Application Gateway WAF-et minden egyes regionális üzembehelyezési bélyegen belül meg kell adni. 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 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és a tényleges alkalmazás háttérrendszereibe 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, akár globálisan az Azure Front Door használatával, akár regionálisan Azure-alkalmazás Átjáróval, 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 a gyanús kérések blokkolásával), ha a megelőzési mód teljesítménybírsága túl magas. A vélelmezett további kockázatot teljes mértékben meg kell érteni, és hozzá kell igazítani a számítási feladat forgatókönyvének konkrét követelményeihez.

• 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.

• Csak akkor használja az Azure API Managementet, 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 feladatokon belüli belső forgalomelosztási forgatókönyvekhez.

  • 99,99%-os SLA-t biztosít a rendelkezésre állási zónákban való üzembe helyezéskor.
  • Olyan kritikus képességeket biztosít, mint a diagnosztika vagy a kimenő szabályok.

• Az Azure DDoS Network Protection használatával védheti az egyes alkalmazás-virtuális hálózatokban ü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 forgalmat, az olvasási műveleteket és a háttérszolgáltatások számítási teljesítményét.

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 is kiszolgálnak.
• A gyakran használt statikus tartalommal rendelkező számítási feladatok nagy előnye a gyorsítótárazásnak, mivel csökkenti a háttérszolgáltatások terhelését, és csökkenti a végfelhasználók tartalomhozzáférési késését.
• 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 natív azure-beli 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.
    • Az Azure Front Doorban /static/* a megfelelő útválasztási szabályok létrehozásával a forgalom transzparens módon átirányítható statikus tartalomra.
  • Ö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ötetek számára.
    • Az Azure CDN szolgáltatás valószínűleg költséghatékonyabb lesz, de nem biztosítja ugyanazokat a speciális útválasztási és webalkalmazási tűzfal(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 Akamaival és a Verizonnal való integrációhoz.
  • 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 hajthatóak végre.
    • A tárolt tartalom mérete és a kapcsolódó költség.
    • A szabálymotor végrehajtásának havi díja (az Azure Front Dooron kérésre felszámítva).
    • 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ás is előnyös lehet. A gyorsítótárazás konfigurálható URL-paraméterek alapján és változó gyorsítótárazási időtartammal.
• Különítse el a statikus és dinamikus tartalmak felhasználókhoz való továbbítását, és a megfelelő 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 webalkalmazási tűzfal (WAF) célokra való használatára vonatkozó erős javaslat (hálózati és kapcsolattervezési terület) ajánlott előnyben részesíteni az Azure Front Door gyorsítótárazási képességeit, 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ó a nyilvános végpontok és az internet, illetve a magánhálózatok használatával, hálózati szintű integrációval valósítható meg. Végső soron az alkalmazásintegráció módszere 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 három átfogó hálózati konfiguráció egyikén belül telepíthetők, amely meghatározza, hogyan fordulhat elő az alkalmazásintegráció 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 az 1. konfiguráció. egy online célzónán belül kell üzembe helyezni, míg a 2) és a 3) műveletet a corp. Csatlakozás ed célzónán belül kell üzembe helyezni a hálózati szintű integráció megkönnyítése érdekében.

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

Kialakítási szempontok

Nincs virtuális hálózat

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

  • Csatlakozás minden figyelembe vett Azure-szolgáltatás teljes mértékben nyilvános végpontokon és a Microsoft Azure gerinchálózatán keresztül érhető el. Csatlakozás az Azure-ban üzemeltetett nyilvános végpontok közötti eltérés csak a Microsoft gerinchálózatán halad át, és nem lépi át a nyilvános internetet.
  • Csatlakozás nyilvános internet biztosítja az Azure-on kívüli külső rendszerekhez való hozzáférést.

• Ez a tervezési megközelítés az "identitás mint biztonsági peremhálózat" használatát alkalmazza a különböző szolgáltatásösszetevők és a függő megoldás közötti hozzáférés-vezérlés biztosítása érdekében. 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ó az összes Azure-szolgáltatásra, mivel számos szolgáltatásnak, például az AKS-nek kemény követelménye van egy mögöttes virtuális hálózathoz.

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 belül, amely nem csatlakozik más hálózatokhoz.

• A bejövő ügyfélkérelmekhez továbbra is nyilvános végpontot kell kitárni az interneten, de az azt követő kommunikáció a virtuális hálózaton belül, privát végpontok használatával is lehetséges. Az Azure Front Door Premium használatakor közvetlenül a peremcsomópontokról a privát alkalmazásvégpontokra irányítható.

• 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 fog támaszkodni.

  • Csatlakozás azure-platformszolgáltatásokhoz való csatlakozás privát végpontokkal is létesíthető, ha támogatott. Ha az Azure-ban más külső függőségek is léteznek, 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.
  • Csatlakozás nyilvános internet biztosítaná az Azure-on kívüli külső rendszerekhez való hozzáférést.

• A külső függőségekre vonatkozó hálózati integrációs követelmények nélküli forgatókönyvek esetében a megoldás izolált 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 kapcsolódó címzési és útválasztási korlátozás.

• Az Azure Bastion egy teljesen 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 mind az adatsík, mind a vezérlősík hozzáférése a magánhálózatokon üzemeltetett erőforrásokhoz az alkalmazások üzembe helyezésének megkönnyítése érdekében szükséges.

  • 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ások proxyhozzáférése érdekében.

Csatlakozás virtuális hálózatok

• Külső hálózati integrációs követelményekkel rendelkező forgatókönyvek esetén az alkalmazás virtuális hálózatai különböző kapcsolati lehetőségek használatával csatlakoztathatók más Azure-beli virtuális hálózatokhoz, egy másik felhőszolgáltatóhoz vagy helyszíni hálózatokhoz. Egyes alkalmazásforgatókönyvek például megfontolhatják az alkalmazásszintű integrációt a helyszíni vállalati hálózaton belül magánhálózaton üzemeltetett más üzletági alkalmazásokkal.

• 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ös tekintettel az olyan témákra, mint a címzés és az útválasztás.

• Az Azure-régiókban vagy a helyszíni hálózatokban átfedésben lévő IP-címterek jelentős versengést hoznak létre a hálózati integráció mérlegelésekor.

  • 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 kapcsolaton, 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 érintett alhálózatok megfelelő méretének meghatározásakor.
  • Egyes Azure-szolgáltatások dedikált alhálózatokat igényelnek, például az Azure Bastiont, az Azure Firewallt 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 támogassák a szolgáltatás összes jelenlegi példányát, figyelembe véve a jövőbeli méretezési követelményeket, de nem olyan nagyok, mint a szükségtelenül hulladékcímek.

• Ha helyszíni vagy felhőközi hálózati integrá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) mérete akár 10 Gb/s összesített sávszélességet biztosít a küllős hálózatokban és a küllős hálózatokban, és akár 20 Gb/s-os sávszélességet is biztosít az Azure Virtual WAN-ban.

Feljegyzés

Az Azure-beli célzónán belüli üzembe helyezéskor vegye figyelembe, hogy a helyszíni hálózatokhoz szükséges kapcsolódást a célzóna implementációjának kell biztosítania. A kialakítás használhatja az ExpressRoute-ot és más azure-beli virtuális hálózatokat a Virtual WAN vagy a 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 telepíteni az Azure-beli virtuális hálózatokon, ahol lehetséges, hogy eltávolítsa a szükségtelen nyilvános végpontokat, és korlátozza 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 olyan szolgáltatások esetében tekinthetők meg, amelyek nem támogatják a Private Linket, feltéve, hogy az adatkiszivárgási kockázatok elfogadhatók vagy alternatív vezérlőkkel csökkenthetők.

• Olyan alkalmazásforgatókönyvekben, amelyek nem igényelnek vállalati hálózati kapcsolatot, az összes virtuális hálózatot rövid élettartamú erőforrásként kell kezelnie, amelyet egy új regionális üzembe helyezés során cserélnek le.

• Más Azure-beli vagy helyszíni hálózatokhoz való csatlakozáskor az alkalmazás virtuális hálózatait nem szabad rövidesen 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ásai esetében. A virtuális hálózaton belüli összes releváns alkalmazáserő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 kapcsolat szükséges 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ózatokhoz használt IPv4-címtér nem fedi egymást más csatlakoztatott hálózatokkal, és megfelelően méretezhető a szükséges skálázás megkönnyítéséhez 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ózat címfoglalá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 (RFC 1918) rendelkező környezetek esetében 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ímblokkok vannak használatban.
  • Igazodjon az Azure-beli IP-címzés szervezeti terveihez annak érdekében, hogy az alkalmazáshálózat IP-címtere 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 legyen elveszteve.

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

  • Fontolja meg a Kubenetet olyan forgatókönyvek esetében, ahol korlátozott a rendelkezésre álló IP-cím, hogy elférjen az alkalmazás 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 skálájával rendelkező forgatókönyvek esetében. További részletekért tekintse meg a mikroszegmentálási és kubernetes-hálózati szabályzatokat .

• A helyszíni hálózati integrációt igénylő forgatókönyvek esetében 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 úgy kell tekinteni, 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 útvonalak összes összetevője ö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 útvonalak és a társított összetevők kezelését a központi informatikai csapatok alkalmazáscsapata biztosítja-e.

  Feljegyzés

  Az Azure-beli célzónán belüli üzembe helyezéskor és egy szélesebb körű szervezeti hálózati topológiával való integráláskor vegye figyelembe a hálózati útmutatást annak biztosítása érdekében, hogy az alapszintű hálózat megfeleljen a Microsoft ajánlott eljárásainak.

• Az Azure Bastion vagy a virtuális magánkapcsolatok használatával érheti el 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. Az alkalmazás által használt Azure-szolgáltatások által igényelt külső függőségekhez való hozzáférés.

Ez a szakasz bemutatja, 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ásokra vonatkozó legfontosabb kimenő követelményeket.

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-függvények a kívánt módon működjenek.

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

• Amikor a virtuális hálózaton belülről érkező forgalom kifelé halad az internetre, a hálózati címfordításnak (NAT) kell végbe mennie. Ez egy számítási művelet, amely a hálózati veremen belül történik, és ezért 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, azonban ha nagy számú kimenő kérés merül fel, hálózati problémák léphetnek fel. Ezek a problémák általában a "Forrás NAT (vagy SNAT) portkimerülése" formájában jelentkeznek.

• Több-bérlős környezetben, például Azure-alkalmazás szolgáltatásban 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 csökkenthető.

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

  • Az Azure Firewall megfelelő biztonsági képességeket biztosít a hálózati forgalom biztonságossá tételéhez.

  • Az Azure Firewall (vagy azzal egyenértékű NVA) a Kubernetes kimenő forgalmának követelményeinek védelmére használható a kimenő forgalom részletes szabályozá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 kapcsolatot támogat a TCP és az UDP számára hozzárendelt kimenő IP-címenként.

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

• A NAT-átjáró nem tud helyszíni elkülönítést biztosítani. A zonális redundancia lekéréséhez a zonális erőforrásokat tartalmazó alhálózatot a megfelelő zonális NAT-átjárókkal kell összehangolni.

Tervezési javaslatok

• Csökkentse 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 az Azure Firewallt, 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 az Azure Firewall nem az Azure-szolgáltatások közötti forgalom vizsgálatára szolgál.

Feljegyzés

Azure-beli célzónán belüli üzembe helyezéskor fontolja meg az alapszintű Platform Azure Firewall-erőforrás (vagy azzal 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áskövetelményekkel. Az erőforrás működési adatait is elérhetővé kell tenni az alkalmazás számára, hogy tájékoztassa a lehetséges működési műveletet a meghibásodási forgatókönyvekben.

Ha a kimenő forgalomhoz nagy léptékű követelmények tartoznak, figyelembe kell venni egy dedikált Azure Firewall-erőforrást egy kritikus fontosságú alkalmazáshoz, hogy mérsékelje a központilag megosztott erőforrások, például a zajos szomszéd forgatókönyvek használatával járó kockázatokat.

• A Virtual WAN-környezetben történő üzembe helyezéskor figyelembe kell venni a Firewall Managert, hogy központosított felügyeletet biztosítson a dedikált alkalmazás Azure Firewall-példányai számára, hogy a szervezeti biztonsági helyzeteket a globális tűzfalszabályzatok betarthassá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 csapatokhoz, hogy lehetővé tegyék az alkalmazásszabályzatok önállóságát.

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

Bár az alkalmazástervezés határozottan 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 hálózati integrációra a különböző zónákban vagy Azure-régiókban üzembe helyezett alkalmazás-összetevők között, még akkor is, ha csak csökkentett szolgáltatási körülmények között. A zónák közötti és régiók közötti kommunikáció megvalósításának módszere 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 alapján fogunk megvizsgálni.

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ó összes összetevőszintjén alkalmazott zonális 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 a 2 ms-nál kisebb utazási késés garantált. A zónák kis késési varianciájúak lesznek 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ózaton keresztül egy régióba érkező forgalmat a zónák között kell irányítani a célhely eléréséhez. Ez ~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 lesz hatással.

• A rendelkezésre állási zónák logikai entitásokként vannak kezelve egyetlen előfizetés kontextusában, így a különböző előfizetések eltérő zónaleké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.

• Az alkalmazásösszetevők között rendkívül gyakori alkalmazásforgatókönyvek esetén az alkalmazásszintek zónák közötti elterjesztése 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 eredményez GB sávszélességenként.

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

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

• A szolgáltatásközvetíteni kívánt szolgáltatások esetében a Private Link magánvégpontok használatával történő közvetlen kommunikációhoz használható.

• A forgalom a helyszíni kapcsolatokhoz használt Express Route-kapcsolatcsoportokon keresztül rögzíthető annak érdekében, hogy megkönnyítse az útválasztást az Azure-régión belüli 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 Express Route-on keresztüli forgalom szőrös rögzítése 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ása érdekében 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 kapcsolódó átjáróösszetevők szerepkörét az Azure-ból/a helyszínen, hogy az Azure-beli/Azure-kapcsolatokra is kiterjedjen.

• Ha a szolgáltatások között almilliszekundumos 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 szőrös rögzítést az Express Route-on belül.

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

• Az összetevők között rendkívül csevegős alkalmazásterhelések esetén fontolja meg az üzembehelyezési bélyegek 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ónaredundancia egy beágyazott üzembehelyezési bélyeg szintjén maradjon, és ne egyetlen alkalmazásösszetevőt.

• 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, kivéve, ha szükséges, még meghibásodási forgatókönyv esetén is. Globális útválasztási szolgáltatások és teljes körű állapottesztek használatával teljes bélyeget vehet ki a forgalomból abban az esetben, ha egyetlen kritikus összetevőszint meghibásodik, ahelyett, hogy az adott hibás összetevő szintjén 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 a bejövő útvonalak hálózati késésének optimalizálása érdekében.

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

A mikroszegmentálás egy olyan hálózati biztonsági tervezési minta, amely elkülöníti és védi az egyes alkalmazások számítási feladatait, és szabályzatokat alkalmaz a számítási feladatok közötti hálózati forgalom korlátozására egy Teljes felügyelet modell alapján. Ez általában a hálózati támadási felület csökkentésére, a szabálysértések elszigetelésének javítására és a biztonság megerősítésére vonatkozik a szabályzatalapú alkalmazásszintű hálózati vezérlőkkel.

A kritikus fontosságú alkalmazások az azure Kubernetes Service (AKS) használatakor az alkalmazásszintű hálózati biztonságot az alhálózat vagy a hálózati adapter szintjén, a szolgáltatáshozzáférés-vezérlési listák (ACL) és a hálózati házirendek használatával kényszeríthetik ki.

Ez a szakasz ezeknek a képességeknek az optimális használatát ismerteti, és kulcsfontosságú 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 telepíthető:

  • 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ési hálózaton belül vannak. A különböző csomópontokon lévő podok közötti forgalom kube-proxyn keresztül van irányítva.
  • Azure Container Networking Interface (CNI) hálózatkezelés: Az AKS-fürt egy meglévő virtuális hálózatba van integrálva, és annak 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 podok közötti közvetlen kapcsolatot igénylő különböző hálózati forgatókönyvek esetében releváns. A különböző csomópontkészletek különböző alhálózatokban helyezhetők üzembe.

  Feljegyzé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 elszigeteltek, és bármilyen forrásból fogadják a forgalmat, és bármilyen célhelyre küldhetnek forgalmat; egy pod képes kommunikálni egy adott Kubernetes-fürt minden 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 egy rendezett szabálykészlet határozható meg a forgalom küldésének/fogadásának szabályozására, és alkalmazható egy vagy több címkeválasztónak megfelelő podok gyűjteményére.

  • Az AKS két olyan beépülő modult támogat, amelyek a Network Policyt, az Azure-t és a Calico-t implementálják. Mindkét beépülő modul Linux IPTables használatával kényszeríti ki a megadott szabályzatokat. 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 házirendek nem ütköznek, mivel azok additívak.
  • Ahhoz, hogy engedélyezhető legyen a két pod közötti hálózati forgalom, a forrás pod kimenő házirendjének és a cél pod bejövő forgalmá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ási idején engedélyezhető. Egy meglévő AKS-fürt hálózati szabályzata nem engedélyezhető.
  • 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 szolgáltatáskészletet biztosít, beleértve a Windows-csomópontok támogatását, valamint az Azure CNI és a Kubenet támogatását.

• 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 nem rendelkező 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 elkülönítse az alkalmazás összetevőit 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 megbízható 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 fér el az alkalmazás számára egy korlátozott címtérben.

    • Az AKS az Azure CNI és a Kubenet használatát is támogatja. Ez a hálózati beállítás 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űbb 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 tekintse meg az Azure CNI-t .

• 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 az Azure Kubernetes Service-hez az üzembe helyezéskor.
  • Fontossági sorrendbe kell állítani a Calico használatát, mert szélesebb körű közösségi bevezetést és támogatást nyújt.

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