Netwerken en connectiviteit voor bedrijfskritieke workloads in Azure

Netwerken is een fundamenteel gebied voor een bedrijfskritieke toepassing, gezien de aanbevolen wereldwijd gedistribueerde, actief-actieve ontwerpbenadering.

In dit ontwerpgebied worden verschillende onderwerpen over netwerktopologie op toepassingsniveau verkend, rekening houdend met vereiste connectiviteit en redundant verkeersbeheer. Meer in het bijzonder worden kritieke overwegingen en aanbevelingen benadrukt die zijn bedoeld om het ontwerp van een veilige en schaalbare wereldwijde netwerktopologie voor een bedrijfskritieke toepassing te informeren.

Belangrijk

Dit artikel maakt deel uit van de azure Well-Architected mission-critical workload series. Als u niet bekend bent met deze reeks, raden we u aan te beginnen met wat een bedrijfskritieke workload is?

Globale verkeersroutering

Het gebruik van meerdere actieve regionale implementatiestempels vereist een globale routeringsservice om verkeer naar elke actieve stempel te distribueren.

Azure Front Door, Azure Traffic Manager en Azure Standard Load Balancer bieden de benodigde routeringsmogelijkheden voor het beheren van wereldwijd verkeer in een toepassing met meerdere regio's.

U kunt ook globale routeringstechnologieën van derden overwegen. Deze opties kunnen bijna naadloos worden omgewisseld om het gebruik van systeemeigen globale routeringsservices van Azure te vervangen of uit te breiden. Populaire keuzes zijn routeringstechnologieën van CDN-providers.

In deze sectie worden de belangrijkste verschillen in Azure-routeringsservices beschreven om te definiëren hoe elk kan worden gebruikt om verschillende scenario's te optimaliseren.

Ontwerpoverwegingen

• Een routeringsservice die is gebonden aan één regio, vertegenwoordigt een single point-of-failure en een aanzienlijk risico met betrekking tot regionale storingen.

• Als de toepassingsworkload clientbeheer omvat, zoals met mobiele of desktopclienttoepassingen, is het mogelijk om serviceredundantie te bieden binnen clientrouteringslogica.

  • Meerdere globale routeringstechnologieën, zoals Azure Front Door en Azure Traffic Manager, kunnen parallel worden beschouwd voor redundantie, waarbij clients zijn geconfigureerd voor failover naar een alternatieve technologie wanneer aan bepaalde storingsvoorwaarden wordt voldaan. De introductie van meerdere globale routeringsservices introduceert aanzienlijke complexiteiten met betrekking tot edge-caching en Web Application Firewall-mogelijkheden, en certificaatbeheer voor SSL-offload en toepassingsvalidatie voor toegangsbeheerpaden.
  • Technologieën van derden kunnen ook worden overwogen en bieden wereldwijde routeringstolerantie voor alle niveaus van Azure-platformfouten.

• Mogelijkheidsdispariteit tussen Azure Front Door en Traffic Manager betekent dat als de twee technologieën naast elkaar staan voor redundantie, een ander ingangspad of ontwerpwijzigingen nodig zijn om een consistent en acceptabel serviceniveau te behouden.

• Azure Front Door en Azure Traffic Manager zijn wereldwijd gedistribueerde services met ingebouwde redundantie en beschikbaarheid in meerdere regio's.

  • Hypothetische foutscenario's van een schaal die groot genoeg zijn om de wereldwijde beschikbaarheid van deze flexibele routeringsservices te bedreigen, vormt een breder risico voor de toepassing in termen van trapsgewijze en gecorreleerde fouten.
    • Foutscenario's van deze schaal zijn alleen haalbaar als gevolg van gedeelde basisservices, zoals Azure DNS of Microsoft Entra ID, die fungeren als globale platformafhankelijkheden voor bijna alle Azure-services. Als een redundante Azure-technologie wordt toegepast, is de kans groot dat de secundaire service ook niet beschikbaar is of dat er een gedegradeerde service is.
    • Globale scenario's voor routeringsservicefouten zijn zeer waarschijnlijk van invloed op veel andere services die worden gebruikt voor belangrijke toepassingsonderdelen via interserviceafhankelijkheden. Zelfs als een technologie van derden wordt gebruikt, heeft de toepassing waarschijnlijk een slechte status vanwege de bredere impact van het onderliggende probleem, wat betekent dat routering naar toepassingseindpunten in Azure toch weinig waarde biedt.

• Globale routeringsserviceredundantie biedt een oplossing voor een extreem klein aantal hypothetische foutscenario's, waarbij de impact van een wereldwijde storing wordt beperkt tot de routeringsservice zelf.

  Als u een bredere redundantie wilt bieden voor globale storingsscenario's, kan een actieve implementatiebenadering met meerdere clouds worden overwogen. Een actieve implementatiebenadering met meerdere clouds introduceert aanzienlijke operationele complexiteiten, die aanzienlijke tolerantierisico's vormen, die waarschijnlijk veel opwegen tegen de hypothetische risico's van een wereldwijde storing.

• Voor scenario's waarbij clientbeheer niet mogelijk is, moet een afhankelijkheid worden uitgevoerd op één globale routeringsservice om een geïntegreerd toegangspunt te bieden voor alle actieve implementatieregio's.

  • Wanneer ze geïsoleerd worden gebruikt, vertegenwoordigen ze een single point-of-failure op serviceniveau vanwege globale afhankelijkheden, ook al worden ingebouwde redundantie en beschikbaarheid in meerdere regio's geboden.
  • De SLA die wordt geleverd door de geselecteerde globale routeringsservice vertegenwoordigt de maximaal haalbare samengestelde SLA, ongeacht het aantal implementatieregio's.

• Wanneer clientbeheer niet mogelijk is, kunnen operationele oplossingen worden overwogen om een proces te definiëren voor migratie naar een secundaire globale routeringsservice als een globale storing de primaire service uitschakelt. Migreren van de ene globale routeringsservice naar een andere is doorgaans een langdurig proces dat enkele uren duurt, met name wanneer dns-doorgifte wordt overwogen.

• Sommige wereldwijde routeringsservices van derden bieden een SLA van 100%. De historische en haalbare SLA die door deze services wordt geleverd, is doorgaans lager dan 100%.

  • Hoewel deze diensten financiële schadevergoeding bieden voor onbeschikbaarheid, is het weinig belangrijk wanneer de impact van onbeschikbaarheid aanzienlijk is, zoals bij veiligheidskritieke scenario's waarbij uiteindelijk het menselijk leven op het spel staat. Technologieredundantie of voldoende operationele oplossingen moeten daarom nog steeds worden overwogen, zelfs wanneer de aangekondigde juridische SLA 100% is.

Azure Front Door

• Azure Front Door biedt wereldwijde HTTP/S-taakverdeling en geoptimaliseerde connectiviteit met behulp van het Anycast-protocol met split TCP om te profiteren van het wereldwijde backbone-netwerk van Microsoft.

  • Er worden een aantal verbindingen onderhouden voor elk van de back-endeindpunten.
  • Binnenkomende clientaanvragen worden eerst beëindigd op het edge-knooppunt dat het dichtst bij de oorspronkelijke client ligt.
  • Na een vereiste verkeersinspectie worden aanvragen via de Microsoft-backbone doorgestuurd naar de juiste back-end met behulp van bestaande verbindingen of vanuit de interne cache van een edge-knooppunt.
  • Deze aanpak is efficiënt bij het spreiden van grote verkeersvolumes via de back-endverbindingen.

• Biedt een ingebouwde cache die statische inhoud van edge-knooppunten bedient. In veel gebruiksscenario's kan dit ook voorkomen dat een toegewezen CDN (Content Delivery Network) nodig is.

• Azure Web Application Firewall (WAF) kan worden gebruikt in Azure Front Door en omdat deze is geïmplementeerd op azure-locaties voor de edge van het azure-netwerk over de hele wereld, wordt elke binnenkomende aanvraag die door Front Door wordt geleverd, geïnspecteerd aan de netwerkrand.

• Azure Front Door beschermt toepassingseindpunten tegen DDoS-aanvallen met behulp van Azure DDoS Protection Basic. Azure DDoS Standard biedt aanvullende en geavanceerdere mogelijkheden voor beveiliging en detectie en kan worden toegevoegd als een extra laag aan Azure Front Door.

• Azure Front Door biedt een volledig beheerde certificaatservice. Hiermee kunt u TLS-verbindingsbeveiliging voor eindpunten inschakelen zonder dat u de levenscyclus van het certificaat hoeft te beheren.

• Azure Front Door Premium ondersteunt privé-eindpunten, waardoor verkeer rechtstreeks van internet naar virtuele Azure-netwerken kan stromen. Hierdoor hoeft u geen openbare IP-adressen op het VNet te gebruiken om de back-ends toegankelijk te maken via Azure Front Door Premium.

• Azure Front Door is afhankelijk van statustests en back-endstatuseindpunten (URL's) die op intervalbasis worden aangeroepen om een HTTP-statuscode te retourneren die weergeeft of de back-end normaal werkt, met een HTTP 200-antwoord (OK) dat een goede status weergeeft. Zodra een back-end een beschadigde status weerspiegelt, vanuit het perspectief van een bepaald edge-knooppunt, stopt dat edge-knooppunt met het verzenden van aanvragen daar. Beschadigde back-ends worden daarom zonder vertraging transparant verwijderd uit de verkeerscirculatie.

• Ondersteunt alleen HTTP/S-protocollen.

• De WAF van Azure Front Door en Application Gateway WAF bieden een iets andere functieset, hoewel zowel ingebouwde als aangepaste regels worden ondersteund en kunnen worden ingesteld op gebruik in de detectiemodus of preventiemodus.

• De back-end-IP-ruimte van Front Door kan veranderen, maar Microsoft zorgt voor integratie met Azure IP-bereiken en servicetags. Het is mogelijk om u te abonneren op Azure IP Ranges en servicetags om meldingen te ontvangen over wijzigingen of updates.

• Azure Front Door ondersteunt verschillende configuraties voor belastingdistributie:

  • Op latentie gebaseerd: de standaardinstelling waarmee verkeer naar de dichtstbijzijnde back-end wordt gerouteerd vanaf de client; op basis van de latentie van aanvragen.
  • Op basis van prioriteit: handig voor actief-passieve instellingen, waarbij verkeer altijd naar een primaire back-end moet worden verzonden, tenzij het niet beschikbaar is.
  • Gewogen: van toepassing op canaire implementaties waarbij een bepaald percentage verkeer naar een specifieke back-end wordt verzonden. Als aan meerdere back-ends dezelfde gewichten zijn toegewezen, wordt routering op basis van latentie gebruikt.

• Standaard maakt Azure Front Door gebruik van routering op basis van latentie die kan leiden tot situaties waarin sommige back-ends veel meer binnenkomend verkeer krijgen dan andere, afhankelijk van waar clients vandaan komen.

• Als een reeks clientaanvragen moet worden verwerkt door dezelfde back-end, kan sessieaffiniteit worden geconfigureerd op de front-end. Er wordt gebruikgemaakt van een cookie aan de clientzijde om volgende aanvragen naar dezelfde back-end te verzenden als de eerste aanvraag, mits de back-end nog steeds beschikbaar is.

Azure Traffic Manager

• Azure Traffic Manager is een DNS-omleidingsservice.

  • De werkelijke nettolading van de aanvraag wordt niet verwerkt, maar in plaats daarvan retourneert Traffic Manager de DNS-naam van een van de back-ends in de pool, op basis van geconfigureerde regels voor de geselecteerde verkeersrouteringsmethode.
  • De dns-naam van de back-end wordt vervolgens omgezet in het uiteindelijke IP-adres dat vervolgens rechtstreeks door de client wordt aangeroepen.

• Het DNS-antwoord wordt in de cache opgeslagen en opnieuw gebruikt door de client voor een opgegeven TTL-periode (Time-To-Live) en aanvragen die tijdens deze periode worden gedaan, worden rechtstreeks naar het back-endeindpunt verzonden zonder tussenkomst van Traffic Manager. Elimineert de extra connectiviteitsstap die kostenvoordelen biedt vergeleken met Front Door.

• Omdat de aanvraag rechtstreeks van de client naar de back-endservice wordt gedaan, kan elk protocol dat door de back-end wordt ondersteund, worden gebruikt.

• Net als bij Azure Front Door is Azure Traffic Manager ook afhankelijk van statustests om te begrijpen of een back-end in orde is en normaal werkt. Als er een andere waarde wordt geretourneerd of er niets wordt geretourneerd, herkent de routeringsservice lopende problemen en stopt de routeringsaanvragen naar die specifieke back-end.

  • In tegenstelling tot Azure Front Door is dit verwijderen van beschadigde back-ends echter niet onmiddellijk, omdat clients verbindingen blijven maken met de beschadigde back-end totdat de DNS-TTL verloopt en een nieuw back-endeindpunt wordt aangevraagd vanuit de Traffic Manager-service.
  • Zelfs wanneer de TTL verloopt, is er bovendien geen garantie dat openbare DNS-servers deze waarde respecteren, zodat DNS-doorgifte veel langer kan duren. Dit betekent dat verkeer gedurende een langere periode nog steeds naar het beschadigde eindpunt wordt verzonden.

Azure Standard Load Balancer

Belangrijk

Standard Load Balancer voor meerdere regio's is beschikbaar in preview met technische beperkingen. Deze optie wordt niet aanbevolen voor bedrijfskritieke workloads.

Ontwerpaanaanvelingen

• Gebruik Azure Front Door als de primaire globale verkeersrouteringsservice voor HTTP/S-scenario's. Azure Front Door wordt sterk aangeraden voor HTTP/S-workloads, omdat het geoptimaliseerde verkeersroutering, transparante failover, privé-back-endeindpunten (met de Premium SKU), edge-caching en integratie met Web Application Firewall (WAF) biedt.

• Voor toepassingsscenario's waarbij clientbeheer mogelijk is, past u routeringslogica aan de clientzijde toe om failoverscenario's te overwegen waarbij de primaire globale routeringstechnologie mislukt. Twee of meer globale routeringstechnologieën moeten parallel worden weergegeven voor extra redundantie, als de SLA voor één service niet voldoende is. Clientlogica is vereist om naar de redundante technologie te routeren in het geval van een globale servicefout.

  • Er moeten twee afzonderlijke URL's worden gebruikt, waarbij één wordt toegepast op elk van de verschillende globale routeringsservices om de algehele ervaring voor certificaatbeheer en routeringslogica voor een failover te vereenvoudigen.
  • Prioriter het gebruik van routeringstechnologieën van derden als de secundaire failoverservice, omdat dit het grootste aantal globale foutscenario's vermindert en de mogelijkheden die door toonaangevende CDN-providers worden geboden, een consistente ontwerpbenadering mogelijk maken.
  • Er moet ook aandacht worden besteed aan rechtstreekse routering naar één regionale stempel in plaats van een afzonderlijke routeringsservice. Hoewel dit resulteert in een gedegradeerd serviceniveau, is het een veel eenvoudigere ontwerpbenadering.

In deze afbeelding ziet u een redundante globale load balancer-configuratie met clientfailover met behulp van Azure Front Door als primaire globale load balancer.

Belangrijk

Om het risico op wereldwijde storingen binnen het Azure-platform echt te beperken, moet een actieve implementatiebenadering met meerdere clouds worden overwogen, waarbij actieve implementatiestempels worden gehost in twee of meer cloudproviders en redundante routeringstechnologieën van derden die worden gebruikt voor wereldwijde routering.

Azure kan effectief worden geïntegreerd met andere cloudplatforms. Het wordt echter sterk aangeraden geen multicloudbenadering toe te passen, omdat het een aanzienlijke operationele complexiteit introduceert, met verschillende definities van implementatiestempels en representaties van operationele status op de verschillende cloudplatforms. Deze complexiteit introduceert op zijn beurt talloze tolerantierisico's binnen de normale werking van de toepassing, die veel opwegen tegen de hypothetische risico's van een wereldwijde platformstoring.

• Hoewel dit niet wordt aanbevolen, kunt u voor HTTP(s) workloads die Gebruikmaken van Azure Traffic Manager voor globale routeringredundantie naar Azure Front Door, overwegen om Web Application Firewall (WAF) naar Application Gateway te offloaden voor acceptabel verkeer dat via Azure Front Door stroomt.
  • Dit introduceert een extra storingspunt op het standaardpad voor inkomend verkeer, een extra onderdeel van het kritieke pad dat moet worden beheerd en geschaald, en brengt ook extra kosten in rekening om wereldwijde hoge beschikbaarheid te garanderen. Het zal echter het foutscenario aanzienlijk vereenvoudigen door consistentie te bieden tussen de acceptabele en niet acceptabele toegangspaden via Azure Front Door en Azure Traffic Manager, zowel wat betreft waF-uitvoering als privétoepassingseindpunten.
  • Het verlies van edge-caching in een foutscenario heeft invloed op de algehele prestaties. Dit moet worden afgestemd op een acceptabel serviceniveau of een oplossing voor het ontwerp. Om een consistent serviceniveau te garanderen, kunt u edge-caching offloaden naar een externe CDN-provider voor beide paden.

Het is raadzaam om een globale routeringsservice van derden te overwegen in plaats van twee globale routeringsservices van Azure. Dit biedt het maximale niveau van foutbeperking en een eenvoudigere ontwerpbenadering, omdat de meeste toonaangevende CDN-providers edge-mogelijkheden bieden die grotendeels consistent zijn met die van Azure Front Door.

Azure Front Door

• Gebruik de door Azure Front Door beheerde certificaatservice om TLS-verbindingen in te schakelen en verwijder de noodzaak om levenscycluss van certificaten te beheren.

• Gebruik de Azure Front Door Web Application Firewall (WAF) om beveiliging aan de rand te bieden tegen veelvoorkomende aanvallen op internet en beveiligingsproblemen, zoals SQL-injectie.

• Gebruik de ingebouwde Azure Front Door-cache om statische inhoud van edge-knooppunten te leveren.

  • In de meeste gevallen zal dit ook de noodzaak voor een toegewezen CDN (Content Delivery Network) elimineren.

• Configureer het ingangspunt van het toepassingsplatform om binnenkomende aanvragen te valideren via filters op basis van headers met behulp van de X-Azure-FDID om ervoor te zorgen dat al het verkeer via het geconfigureerde Front Door-exemplaar stroomt. Overweeg ook IP-ACLing te configureren met behulp van Front Door-servicetags om te valideren dat verkeer afkomstig is van de AZURE Front Door-back-end-IP-adresruimte en Azure-infrastructuurservices. Dit zorgt ervoor dat verkeer via Azure Front Door op serviceniveau stroomt, maar op headers gebaseerde filtering is nog steeds vereist om ervoor te zorgen dat een geconfigureerd Front Door-exemplaar wordt gebruikt.

• Definieer een aangepast TCP-statuseindpunt om kritieke downstreamafhankelijkheden binnen een regionale implementatiestempel te valideren, inclusief replica's van het gegevensplatform, zoals Azure Cosmos DB in het voorbeeld van de basisreferentieimplementatie. Als een of meer afhankelijkheden beschadigd raken, moet de statustest dit weergeven in het geretourneerde antwoord, zodat het hele regionale stempel uit de circulatie kan worden gehaald.

• Zorg ervoor dat statustestantwoorden worden geregistreerd en opgenomen in alle operationele gegevens die door Azure Front Door worden weergegeven in de globale Log Analytics-werkruimte om een uniforme gegevenssink en één operationele weergave in de hele toepassing mogelijk te maken.

• Tenzij de workload uiterst latentiegevoelig is, verspreidt u verkeer gelijkmatig over alle beschouwde regionale stempels om geïmplementeerde resources het meest effectief te gebruiken.

  • Hiervoor stelt u de parameter Latentiegevoeligheid (aanvullende latentie) in op een waarde die hoog genoeg is om te voldoen aan latentieverschillen tussen de verschillende regio's van de back-ends. Zorg voor een tolerantie die acceptabel is voor de workload van de toepassing met betrekking tot de totale latentie van clientaanvragen.

• Schakel sessieaffiniteit niet in, tenzij dit vereist is voor de toepassing, omdat dit een negatieve invloed kan hebben op het saldo van de verkeersdistributie. Als bij een volledig stateless toepassing de aanbevolen bedrijfskritieke toepassingsontwerpbenadering wordt gevolgd, kan elke aanvraag worden verwerkt door een van de regionale implementaties.

Azure Traffic Manager

• Gebruik Traffic Manager voor niet-HTTP/S-scenario's als vervanging voor Azure Front Door. Verschillen in mogelijkheden zorgen voor verschillende ontwerpbeslissingen voor cache- en WAF-mogelijkheden en TLS-certificaatbeheer.

• WAF-mogelijkheden moeten worden overwogen binnen elke regio voor het toegangspad van Traffic Manager met behulp van Azure-toepassing Gateway.

• Configureer een geschikte lage TTL-waarde om de tijd te optimaliseren die nodig is om een beschadigd back-endeindpunt uit de circulatie te verwijderen in het geval dat de back-end beschadigd raakt.

• Net als bij Azure Front Door moet een aangepast TCP-statuseindpunt worden gedefinieerd om kritieke downstreamafhankelijkheden binnen een regionale implementatiestempel te valideren. Dit moet worden weerspiegeld in het antwoord van statuseindpunten.

  Voor Traffic Manager moet echter extra aandacht worden besteed aan regionale failover op serviceniveau. zoals 'dog legging', om de mogelijke vertraging die samenhangt met het verwijderen van een beschadigde back-end te beperken vanwege afhankelijkheidsfouten, met name als het niet mogelijk is om een lage TTL in te stellen voor DNS-records.

• Er moet aandacht worden besteed aan CDN-providers van derden om edge-caching te bereiken bij het gebruik van Azure Traffic Manager als primaire globale routeringsservice. Wanneer edge WAF-mogelijkheden ook worden aangeboden door de service van derden, moet er aandacht worden besteed aan het vereenvoudigen van het toegangsbeheerpad en mogelijk de noodzaak voor Application Gateway verwijderen.

Services voor toepassingslevering

Het netwerkinkomende pad voor een bedrijfskritieke toepassing moet ook rekening houden met services voor het leveren van toepassingen om veilig, betrouwbaar en schaalbaar inkomend verkeer te garanderen.

Deze sectie bouwt voort op algemene routeringsaanbevelingsaanbeveling door belangrijke mogelijkheden voor het leveren van toepassingen te verkennen, rekening houdend met relevante services zoals Azure Standard Load Balancer, Azure-toepassing Gateway en Azure API Management.

Ontwerpoverwegingen

• TLS-versleuteling is essentieel om de integriteit van inkomend gebruikersverkeer naar een bedrijfskritieke toepassing te garanderen, waarbij TLS-offloading alleen wordt toegepast op het punt van inkomend verkeer van een stempel om binnenkomend verkeer te ontsleutelen. TLS-offloading Vereist de persoonlijke sleutel van het TLS-certificaat om verkeer te ontsleutelen.

• Een Web Application Firewall biedt bescherming tegen veelvoorkomende webexploties en beveiligingsproblemen, zoals SQL-injectie of scripting op meerdere sites, en is essentieel voor het bereiken van de maximale betrouwbaarheid van een bedrijfskritieke toepassing.

• Azure WAF biedt out-of-the-box-beveiliging tegen de top 10 OWASP-beveiligingsproblemen met behulp van beheerde regelsets.

  • Aangepaste regels kunnen ook worden toegevoegd om de beheerde regelset uit te breiden.
  • Azure WAF kan worden ingeschakeld binnen Azure Front Door, Azure-toepassing Gateway of Azure CDN (momenteel in openbare preview).
    • De functies die voor elk van de services worden aangeboden, verschillen enigszins. De Azure Front Door WAF biedt bijvoorbeeld snelheidsbeperking, geofiltering en botbeveiliging, die nog niet worden aangeboden binnen de Application Gateway WAF. Ze ondersteunen echter allemaal ingebouwde en aangepaste regels en kunnen worden ingesteld om te werken in de detectiemodus of preventiemodus.
    • De roadmap voor Azure WAF zorgt ervoor dat er een consistente WAF-functieset wordt geleverd voor alle service-integraties.

• WAF-technologieën van derden, zoals NVA's en geavanceerde toegangsbeheerobjectcontrollers binnen Kubernetes, kunnen ook worden beschouwd als vereiste bescherming tegen beveiligingsproblemen.

• Voor een optimale WAF-configuratie is doorgaans afstemming vereist, ongeacht de gebruikte technologie.

  Azure Front Door

• Azure Front Door accepteert alleen HTTP- en HTTPS-verkeer en verwerkt alleen aanvragen met een bekende Host header. Dit protocol blokkeert helpt bij het beperken van volumetrische aanvallen verspreid over protocollen en poorten, en DNS-versterking en TCP-vergiftigingsaanvallen.

• Azure Front Door is een globale Azure-resource, zodat de configuratie wereldwijd wordt geïmplementeerd op alle edge-locaties.

  • Resourceconfiguratie kan op grote schaal worden gedistribueerd om honderdduizenden aanvragen per seconde te verwerken.
  • Updates voor configuratie, inclusief routes en back-endpools, zijn naadloos en veroorzaken geen downtime tijdens de implementatie.

• Azure Front Door biedt zowel een volledig beheerde certificaatservice als een bring-your-own-certificate-methode voor de clientgerichte SSL-certificaten. De volledig beheerde certificaatservice biedt een vereenvoudigde operationele benadering en helpt de complexiteit in het algehele ontwerp te verminderen door certificaatbeheer binnen één gebied van de oplossing uit te voeren.

• Azure Front Door draait automatisch beheerde certificaten ten minste 60 dagen voordat het certificaat verloopt om te beschermen tegen verlopen certificaatrisico's. Als zelfbeheerde certificaten worden gebruikt, moeten bijgewerkte certificaten uiterlijk 24 uur vóór de vervaldatum van het bestaande certificaat worden geïmplementeerd, anders kunnen clients verlopen certificaatfouten ontvangen.

• Certificaatupdates leiden alleen tot downtime als Azure Front Door wordt overgeschakeld tussen 'Beheerd' en 'Uw eigen certificaat gebruiken'.

• Azure Front Door wordt beveiligd door Azure DDoS Protection Basic, dat standaard is geïntegreerd in Front Door. Dit biedt altijd on-on verkeersbewaking, realtime-beperking en beschermt ook tegen veelvoorkomende DNS-query-overstromingen van laag 7 of laag 3/4 volumetrische aanvallen.

  • Deze beveiligingen helpen om de beschikbaarheid van Azure Front Door te behouden, zelfs wanneer u te maken hebt met een DDoS-aanval. DDoS-aanvallen (Distributed Denial of Service) kunnen ervoor zorgen dat een doelresource niet beschikbaar is door deze te overweldigen met illegitimate verkeer.

• Azure Front Door biedt ook WAF-mogelijkheden op globaal verkeersniveau, terwijl Application Gateway WAF moet worden opgegeven binnen elke regionale implementatiestempel. Mogelijkheden zijn onder andere firewallregelsets om te beschermen tegen veelvoorkomende aanvallen, geofiltering, adresblokkering, snelheidsbeperking en handtekeningkoppeling.

  Azure-belastingsverdeling

• De Azure Basic Load Balancer-SKU wordt niet ondersteund door een SLA en heeft verschillende capaciteitsbeperkingen vergeleken met de Standard-SKU.

Ontwerpaanaanvelingen

• Voer TLS-offloading op zo weinig mogelijk plaatsen uit om de beveiliging te behouden en tegelijkertijd de levenscyclus van certificaatbeheer te vereenvoudigen.

• Gebruik versleutelde verbindingen (bijvoorbeeld HTTPS) vanaf het punt waar TLS-offloading plaatsvindt voor de werkelijke toepassingsback-ends. Toepassingseindpunten zijn niet zichtbaar voor eindgebruikers, zodat door Azure beheerde domeinen, zoals azurewebsites.net of cloudapp.net, kunnen worden gebruikt met beheerde certificaten.

• Voor HTTP(S)-verkeer moet u ervoor zorgen dat WAF-mogelijkheden worden toegepast binnen het toegangspad voor alle openbaar weergegeven eindpunten.

• Schakel WAF-mogelijkheden in op één servicelocatie, globaal met Azure Front Door of regionaal met Azure-toepassing Gateway, omdat dit het afstemmen van de configuratie vereenvoudigt en de prestaties en kosten optimaliseert.

  Configureer WAF in de preventiemodus om aanvallen rechtstreeks te blokkeren. Gebruik WAF alleen in de detectiemodus (bijvoorbeeld alleen logboekregistratie maar geen verdachte aanvragen blokkeren) wanneer de prestatiestraf van de preventiemodus te hoog is. Het impliciete extra risico moet volledig worden begrepen en afgestemd op de specifieke vereisten van het workloadscenario.

• Geef prioriteit aan het gebruik van Azure Front Door WAF, omdat het de rijkste azure-systeemeigen functieset biedt en beveiligingen toepast aan de wereldwijde rand, waardoor het algehele ontwerp wordt vereenvoudigd en de efficiëntie wordt vergroot.

• Gebruik Azure API Management alleen wanneer u een groot aantal API's beschikbaar hebt voor externe clients of verschillende toepassingsteams.

• Gebruik de Azure Standard Load Balancer-SKU voor elk intern verkeersdistributiescenario binnen micros-serviceworkloads.

  • Biedt een SLA van 99,99% wanneer deze wordt geïmplementeerd in Beschikbaarheidszones.
  • Biedt essentiële mogelijkheden, zoals diagnostische gegevens of uitgaande regels.

• Gebruik Azure DDoS-netwerkbeveiliging om openbare eindpunten te beveiligen die worden gehost binnen elk virtueel toepassingsnetwerk.

Opslaan in cache en levering van statische inhoud

Speciale behandeling van statische inhoud, zoals afbeeldingen, JavaScript, CSS en andere bestanden, kan een aanzienlijke invloed hebben op de algehele gebruikerservaring en op de totale kosten van de oplossing. Het opslaan van statische inhoud aan de rand kan de laadtijden van de client versnellen, wat resulteert in een betere gebruikerservaring en kan ook de kosten voor verkeer, leesbewerkingen en rekenkracht op back-endservices verminderen.

Ontwerpoverwegingen

• Niet alle inhoud die een oplossing via internet beschikbaar maakt, wordt dynamisch gegenereerd. Toepassingen dienen zowel statische assets (afbeeldingen, JavaScript, CSS, lokalisatiebestanden, enzovoort) als dynamische inhoud.
• Workloads met vaak gebruikte statische inhoud profiteren aanzienlijk van caching, omdat dit de belasting van back-endservices vermindert en de latentie van inhoudstoegang voor eindgebruikers vermindert.
• Caching kan systeemeigen worden geïmplementeerd in Azure met behulp van Azure Front Door of Azure Content Delivery Network (CDN).
  • Azure Front Door biedt mogelijkheden voor azure-systeemeigen edge-caching en routeringsfuncties om statische en dynamische inhoud te verdelen.
    • Door de juiste routeringsregels in Azure Front Door te maken, /static/* kan verkeer transparant worden omgeleid naar statische inhoud.
  • Complexere cachingscenario's kunnen worden geïmplementeerd met behulp van de Azure CDN-service om een volwaardig netwerk voor contentlevering tot stand te brengen voor aanzienlijke statische inhoudsvolumes.
    • De Azure CDN-service is waarschijnlijk rendabeler, maar biedt niet dezelfde geavanceerde routerings- en WAF-mogelijkheden (Web Application Firewall) die worden aanbevolen voor andere gebieden van een toepassingsontwerp. Het biedt echter wel meer flexibiliteit om te integreren met vergelijkbare services van oplossingen van derden, zoals Akamai en Verizon.
  • Wanneer u de Azure Front Door- en Azure CDN-services vergelijkt, moeten de volgende beslissingsfactoren worden verkend:
    • Kan vereist cacheregels worden uitgevoerd met behulp van de regelengine.
    • Grootte van de opgeslagen inhoud en de bijbehorende kosten.
    • Prijs per maand voor de uitvoering van de regelengine (in rekening gebracht per aanvraag in Azure Front Door).
    • Vereisten voor uitgaand verkeer (prijs verschilt per bestemming).

Ontwerpaanaanvelingen

• Gegenereerde statische inhoud, zoals kopieën van afbeeldingsbestanden die nooit of slechts zelden worden gewijzigd, kunnen ook profiteren van caching. Caching kan worden geconfigureerd op basis van URL-parameters en met verschillende cacheduur.
• Scheid de levering van statische en dynamische inhoud aan gebruikers en lever relevante inhoud uit een cache om de belasting van back-endservices te verminderen, zodat de prestaties voor eindgebruikers worden geoptimaliseerd.
• Gezien de sterke aanbeveling (ontwerpgebied voor netwerk en connectiviteit ) voor het gebruik van Azure Front Door voor globale routering en WAF-doeleinden (Web Application Firewall), wordt aanbevolen om prioriteit te geven aan het gebruik van azure Front Door-cachemogelijkheden, tenzij er hiaten bestaan.

Integratie van virtueel netwerk

Een bedrijfskritieke toepassing omvat doorgaans vereisten voor integratie met andere toepassingen of afhankelijke systemen, die kunnen worden gehost in Azure, een andere openbare cloud of on-premises datacenters. Deze toepassingsintegratie kan worden gerealiseerd met behulp van openbare eindpunten en internet of particuliere netwerken via integratie op netwerkniveau. Uiteindelijk heeft de methode waarmee de integratie van toepassingen wordt bereikt een aanzienlijke invloed op de beveiliging, prestaties en betrouwbaarheid van de oplossing, en is het sterk van invloed op ontwerpbeslissingen binnen andere ontwerpgebieden.

Een bedrijfskritieke toepassing kan worden geïmplementeerd binnen een van de drie overkoepelende netwerkconfiguraties, waarmee wordt bepaald hoe de integratie van toepassingen op netwerkniveau kan plaatsvinden.

1. Openbare toepassing zonder bedrijfsnetwerkconnectiviteit.
2. Openbare toepassing met bedrijfsnetwerkconnectiviteit.
3. Privétoepassingmet bedrijfsnetwerkconnectiviteit.

Let op

Bij de implementatie binnen een Azure-landingszone, configuratie 1. moet worden geïmplementeerd binnen een onlinelandingszone, terwijl zowel 2) als 3) moet worden geïmplementeerd binnen een Corp. Verbinding maken ed Landing Zone om integratie op netwerkniveau te vergemakkelijken.

In deze sectie worden deze scenario's voor netwerkintegratie verkend, waarbij het juiste gebruik van Azure Virtual Networks en omringende Azure-netwerkservices wordt gebruikt om ervoor te zorgen dat aan de integratievereisten optimaal wordt voldaan.

Overwegingen bij het ontwerpen

Geen virtuele netwerken

• De eenvoudigste ontwerpmethode is het niet implementeren van de toepassing binnen een virtueel netwerk.

  • Verbinding maken iviteit tussen alle beschouwde Azure-services wordt volledig geboden via openbare eindpunten en de Microsoft Azure-backbone. Verbinding maken iviteit tussen openbare eindpunten die worden gehost in Azure, gaat alleen via de Microsoft-backbone en gaat niet via het openbare internet.
  • Verbinding maken iviteit voor externe systemen buiten Azure wordt geleverd door het openbare internet.

• Bij deze ontwerpbenadering wordt 'identiteit als beveiligingsperimeter' gebruikt om toegangsbeheer te bieden tussen de verschillende serviceonderdelen en afhankelijke oplossing. Dit kan een acceptabele oplossing zijn voor scenario's die minder gevoelig zijn voor beveiliging. Alle toepassingsservices en afhankelijkheden zijn toegankelijk via een openbaar eindpunt, waardoor ze kwetsbaar zijn voor extra aanvalsvectoren die zijn gericht op het verkrijgen van onbevoegde toegang.

• Deze ontwerpbenadering is ook niet van toepassing op alle Azure-services, omdat veel services, zoals AKS, een harde vereiste hebben voor een onderliggend virtueel netwerk.

Geïsoleerde virtuele netwerken

• Om de risico's te beperken die zijn gekoppeld aan onnodige openbare eindpunten, kan de toepassing worden geïmplementeerd in een zelfstandig netwerk dat niet is verbonden met andere netwerken.

• Voor binnenkomende clientaanvragen moet nog steeds een openbaar eindpunt worden weergegeven op internet, maar alle volgende communicatie kan zich binnen het virtuele netwerk bevinden met behulp van privé-eindpunten. Wanneer u Azure Front Door Premium gebruikt, is het mogelijk om rechtstreeks van edge-knooppunten naar privétoepassingseindpunten te routeren.

• Hoewel privéconnectiviteit tussen toepassingsonderdelen plaatsvindt via virtuele netwerken, is alle connectiviteit met externe afhankelijkheden nog steeds afhankelijk van openbare eindpunten.

  • Verbinding maken iviteit van Azure-platformservices kan worden ingesteld met privé-eindpunten, indien ondersteund. Als er andere externe afhankelijkheden bestaan in Azure, zoals een andere downstreamtoepassing, wordt connectiviteit geboden via openbare eindpunten en de Microsoft Azure-backbone.
  • Verbinding maken iviteit voor externe systemen buiten Azure wordt geleverd door het openbare internet.

• Voor scenario's waarbij er geen netwerkintegratievereisten zijn voor externe afhankelijkheden, biedt het implementeren van de oplossing in een geïsoleerde netwerkomgeving maximale flexibiliteit bij het ontwerpen. Er zijn geen adresserings- en routeringsbeperkingen gekoppeld aan een bredere netwerkintegratie.

• Azure Bastion is een volledig platformbeheerde PaaS-service die kan worden geïmplementeerd in een virtueel netwerk en beveiligde RDP-/SSH-connectiviteit met Virtuele Azure-machines biedt. Wanneer u verbinding maakt via Azure Bastion, hebben virtuele machines geen openbaar IP-adres nodig.

• Het gebruik van virtuele netwerken van toepassingen introduceert aanzienlijke implementatiecomplexiteiten binnen CI/CD-pijplijnen, omdat zowel de toegang tot het gegevensvlak als het besturingsvlak tot resources die worden gehost op privénetwerken vereist is om toepassingsimplementaties te vergemakkelijken.

  • Beveiligd privénetwerkpad moet tot stand worden gebracht om CI/CD-hulpprogramma's toe te staan om vereiste acties uit te voeren.
  • Privé-buildagents kunnen worden geïmplementeerd binnen virtuele netwerken van toepassingen om proxytoegang te verlenen tot resources die zijn beveiligd door het virtuele netwerk.

Verbinding maken ed virtuele netwerken

• Voor scenario's met vereisten voor externe netwerkintegratie kunnen virtuele netwerken van toepassingen worden verbonden met andere virtuele netwerken binnen Azure, een andere cloudprovider of on-premises netwerken met behulp van verschillende connectiviteitsopties. Sommige toepassingsscenario's kunnen bijvoorbeeld integratie op toepassingsniveau overwegen met andere Line-Of-Business-toepassingen die privé worden gehost binnen een on-premises bedrijfsnetwerk.

• Het toepassingsnetwerkontwerp moet zijn afgestemd op de bredere netwerkarchitectuur, met name met betrekking tot onderwerpen zoals adressering en routering.

• Overlappende IP-adresruimten tussen Azure-regio's of on-premises netwerken zorgen voor grote conflicten wanneer de netwerkintegratie wordt overwogen.

  • Een virtuele netwerkresource kan worden bijgewerkt om rekening te houden met extra adresruimte, maar wanneer een adresruimte van een virtueel netwerk van een gekoppeld netwerk een synchronisatie op de peeringkoppeling wijzigt, waardoor peering tijdelijk wordt uitgeschakeld.
  • Azure reserveert vijf IP-adressen binnen elk subnet, wat moet worden overwogen bij het bepalen van de juiste grootten voor virtuele netwerken van toepassingen en ingesloten subnetten.
  • Voor sommige Azure-services zijn toegewezen subnetten vereist, zoals Azure Bastion, Azure Firewall of Azure Virtual Network Gateway. De grootte van deze servicesubnetten is erg belangrijk, omdat ze groot genoeg moeten zijn om alle huidige exemplaren van de service te ondersteunen die rekening houden met toekomstige schaalvereisten, maar niet zo groot als onnodige afvaladressen.

• Wanneer on-premises of cross-cloudnetwerkintegratie is vereist, biedt Azure twee verschillende oplossingen om een beveiligde verbinding tot stand te brengen.

  • Een ExpressRoute-circuit kan een grootte hebben voor bandbreedten van maximaal 100 Gbps.
  • Een VIRTUAL Private Network (VPN) kan een grootte hebben voor een geaggregeerde bandbreedte van maximaal 10 Gbps in hub- en spoke-netwerken, en maximaal 20 Gbps in Azure Virtual WAN.

Notitie

Wanneer u binnen een Azure-landingszone implementeert, moet u er rekening mee houden dat elke vereiste verbinding met on-premises netwerken moet worden geboden door de implementatie van de landingszone. Het ontwerp kan ExpressRoute en andere virtuele netwerken in Azure gebruiken met behulp van Virtual WAN of een hub-and-spoke-netwerkontwerp.

• De opname van extra netwerkpaden en resources introduceert aanvullende betrouwbaarheids- en operationele overwegingen voor de toepassing om ervoor te zorgen dat de status behouden blijft.

Ontwerpaanaanvelingen

• Het wordt aanbevolen om bedrijfskritieke oplossingen waar mogelijk te implementeren in virtuele Azure-netwerken om onnodige openbare eindpunten te verwijderen, waardoor het kwetsbaarheid voor toepassingsaanvallen wordt beperkt om de beveiliging en betrouwbaarheid te maximaliseren.

  • Gebruik privé-eindpunten voor connectiviteit met Azure-platformservices. Service-eindpunten kunnen worden overwogen voor services die Private Link ondersteunen, mits exfiltratierisico's voor gegevens acceptabel zijn of worden beperkt via alternatieve besturingselementen.

• Voor toepassingsscenario's waarvoor geen bedrijfsnetwerkconnectiviteit is vereist, behandelt u alle virtuele netwerken als tijdelijke resources die worden vervangen wanneer een nieuwe regionale implementatie wordt uitgevoerd.

• Wanneer u verbinding maakt met andere Azure- of on-premises netwerken, moeten virtuele netwerken van toepassingen niet als kortstondig worden behandeld, omdat dit aanzienlijke complicaties veroorzaakt wanneer peering van virtuele netwerken en virtuele netwerkgatewayresources betrokken zijn. Alle relevante toepassingsresources binnen het virtuele netwerk moeten kortstondig blijven, waarbij parallelle subnetten worden gebruikt om blauwgroene implementaties van bijgewerkte regionale implementatiestempels te vergemakkelijken.

• In scenario's waarin bedrijfsnetwerkconnectiviteit is vereist om de integratie van toepassingen via particuliere netwerken te vergemakkelijken, moet u ervoor zorgen dat de IPv4-adresruimte die wordt gebruikt voor virtuele netwerken van regionale toepassingen, niet overlapt met andere verbonden netwerken en de juiste grootte heeft om de vereiste schaal te vergemakkelijken zonder dat u de resource van het virtuele netwerk hoeft bij te werken en uitvaltijd hoeft te veroorzaken.

  • Het wordt sterk aanbevolen om alleen IP-adressen te gebruiken uit de adrestoewijzing voor privéinternet (RFC 1918).
    • Voor omgevingen met een beperkte beschikbaarheid van privé-IP-adressen (RFC 1918) kunt u overwegen IPv6 te gebruiken.
    • Als het gebruik van een openbaar IP-adres is vereist, moet u ervoor zorgen dat alleen adresblokken in eigendom worden gebruikt.
  • Stem af op organisatieplannen voor IP-adressering in Azure om ervoor te zorgen dat de IP-adresruimte van het toepassingsnetwerk niet overlapt met andere netwerken in on-premises locaties of Azure-regio's.
  • Maak geen onnodig grote virtuele toepassingsnetwerken om ervoor te zorgen dat de IP-adresruimte niet wordt verspild.

• Geef prioriteit aan het gebruik van Azure CNI voor AKS-netwerkintegratie, omdat het ondersteuning biedt voor een uitgebreidere functieset.

  • Overweeg Kubenet voor scenario's met een beperkt aantal beschikbare IP-adressen die geschikt zijn voor de toepassing binnen een beperkte adresruimte.

  • Geef prioriteit aan het gebruik van de Azure CNI-netwerkinvoegtoepassing voor AKS-netwerkintegratie en overweeg Kubenet voor scenario's met een beperkt aantal beschikbare IP-adressen. Zie Microsegmentatie en kubernetes-netwerkbeleid voor meer informatie.

• Voor scenario's waarvoor on-premises netwerkintegratie is vereist, geeft u prioriteit aan het gebruik van Express Route om veilige en schaalbare connectiviteit te garanderen.

  • Zorg ervoor dat het betrouwbaarheidsniveau dat is toegepast op de Express Route of VPN volledig voldoet aan de toepassingsvereisten.
  • Er moeten meerdere netwerkpaden worden overwogen om extra redundantie te bieden wanneer dat nodig is, zoals cross-connected ExpressRoute-circuits of het gebruik van VPN als een mechanisme voor failoverconnectiviteit.

• Zorg ervoor dat alle onderdelen op kritieke netwerkpaden voldoen aan de betrouwbaarheids- en beschikbaarheidsvereisten van gekoppelde gebruikersstromen, ongeacht of het beheer van deze paden en het bijbehorende onderdeel wordt geleverd door het toepassingsteam van centrale IT-teams.

  Notitie

  Wanneer u binnen een Azure-landingszone implementeert en integreert met een bredere netwerktopologie van de organisatie, moet u rekening houden met de netwerkrichtlijnen om ervoor te zorgen dat het basisnetwerk is afgestemd op de best practices van Microsoft.

• Gebruik Azure Bastion of geproxiede privéverbindingen om toegang te krijgen tot het gegevensvlak van Azure-resources of beheerbewerkingen uit te voeren.

Uitgaand internetverkeer

Uitgaand internetverkeer is een fundamentele netwerkvereiste voor een bedrijfskritieke toepassing om externe communicatie in de context van:

1. Interactie van gebruikers van directe toepassing.
2. Toepassingsintegratie met externe afhankelijkheden buiten Azure.
3. Toegang tot externe afhankelijkheden die zijn vereist voor de Azure-services die door de toepassing worden gebruikt.

In deze sectie wordt beschreven hoe internetuitgangen kunnen worden bereikt terwijl beveiliging, betrouwbaarheid en duurzame prestaties worden gehandhaafd, waarbij belangrijke uitgaande vereisten worden gemarkeerd voor services die worden aanbevolen in een bedrijfskritieke context.

Overwegingen bij het ontwerpen

• Veel Azure-services vereisen toegang tot openbare eindpunten voor verschillende beheer- en besturingsvlakfuncties om naar behoren te kunnen werken.

• Azure biedt verschillende directe uitgaande connectiviteitsmethoden voor internet, zoals Azure NAT-gateway of Azure Load Balancer, voor virtuele machines of rekenprocessen in een virtueel netwerk.

• Wanneer verkeer van binnen een virtueel netwerk naar internet gaat, moet NAT (Network Address Translation) plaatsvinden. Dit is een rekenbewerking die zich in de netwerkstack voordoet en die dus van invloed kan zijn op de systeemprestaties.

• Wanneer NAT op kleine schaal plaatsvindt, moet de invloed op de prestaties te verwaarlozen zijn, maar als er een groot aantal uitgaande aanvragen netwerkproblemen kunnen optreden. Deze problemen komen meestal voor in de vorm van 'Bron-NAT-poortuitputting (of SNAT)'.

• In een omgeving met meerdere tenants, zoals Azure-app Service, is er een beperkt aantal uitgaande poorten beschikbaar voor elk exemplaar. Als deze poorten uitlopen, kunnen er geen nieuwe uitgaande verbindingen worden gestart. Dit probleem kan worden opgelost door het aantal privé-/openbare edge-traversals te verminderen of door een schaalbare NAT-oplossing zoals de Azure NAT-gateway te gebruiken.

• Naast NAT-beperkingen kan uitgaand verkeer ook onderhevig zijn aan vereiste beveiligingsinspecties.

  • Azure Firewall biedt de juiste beveiligingsmogelijkheden voor het beveiligen van uitgaand netwerkverkeer.

  • Azure Firewall (of een equivalente NVA) kan worden gebruikt om uitgaande Kubernetes-vereisten te beveiligen door gedetailleerde controle te bieden over uitgaande verkeersstromen.

• Voor grote hoeveelheden internetuitgang worden kosten in rekening gebracht voor gegevensoverdracht.

Azure NAT-gateway

• Azure NAT Gateway ondersteunt 64.000 verbindingen voor TCP en UDP per toegewezen uitgaand IP-adres.

  • Maximaal 16 IP-adressen kunnen worden toegewezen aan één NAT-gateway.
  • Een standaardtime-out voor TCP-inactiviteit van 4 minuten. Als er een time-out voor inactiviteit wordt gewijzigd in een hogere waarde, worden stromen langer bewaard, waardoor de druk op de SNAT-poortinventaris toeneemt.

• Nat-gateway kan niet standaard zonegebonden isolatie bieden. Als u zonegebonden redundantie wilt ophalen, moet een subnet met zonegebonden resources worden afgestemd op de bijbehorende zonegebonden NAT-gateways.

Ontwerpaanaanvelingen

• Minimaliseer het aantal uitgaande internetverbinding, omdat dit van invloed is op de NAT-prestaties.

  • Als er grote aantallen internetverbindingen vereist zijn, kunt u overwegen Om Azure NAT Gateway te gebruiken om uitgaande verkeersstromen te abstraheren.

• Gebruik Azure Firewall waar vereisten voor het beheren en inspecteren van uitgaand internetverkeer bestaan.

  • Zorg ervoor dat Azure Firewall niet wordt gebruikt om verkeer tussen Azure-services te controleren.

Notitie

Overweeg bij het implementeren binnen een Azure-landingszone de Azure Firewall-resource (of een equivalente NVA) van het basisplatform te gebruiken. Als een afhankelijkheid wordt gebruikt op een centrale platformresource voor uitgaand internetverkeer, moet het betrouwbaarheidsniveau van die resource en het bijbehorende netwerkpad nauw worden afgestemd op de toepassingsvereisten. Operationele gegevens van de resource moeten ook beschikbaar worden gesteld aan de toepassing om potentiële operationele actie in foutscenario's te informeren.

Als er hoge schaalvereisten zijn gekoppeld aan uitgaand verkeer, moet er aandacht worden besteed aan een toegewezen Azure Firewall-resource voor een bedrijfskritieke toepassing, om risico's te beperken die zijn gekoppeld aan het gebruik van een centraal gedeelde resource, zoals scenario's voor lawaaierige buren.

• Wanneer deze wordt geïmplementeerd in een Virtual WAN-omgeving, moet er aandacht worden besteed aan Firewall Manager om gecentraliseerd beheer van toegewezen Azure Firewall-instanties te bieden om ervoor te zorgen dat de beveiligingspostuur van de organisatie wordt waargenomen via globaal firewallbeleid.
• Zorg ervoor dat incrementeel firewallbeleid wordt gedelegeerd aan toepassingsbeveiligingsteams via op rollen gebaseerd toegangsbeheer om autonomie van toepassingsbeleid mogelijk te maken.

Verbinding maken iviteit tussen zones en regio's

Hoewel het toepassingsontwerp sterk pleit voor onafhankelijke regionale implementatiestempels, kunnen veel toepassingsscenario's nog steeds netwerkintegratie vereisen tussen toepassingsonderdelen die zijn geïmplementeerd in verschillende zones of Azure-regio's, zelfs als deze alleen onder verslechterde serviceomstandigheden vallen. De methode waarmee communicatie tussen zones en regio's wordt bereikt, heeft een aanzienlijke invloed op de algehele prestaties en betrouwbaarheid, die worden verkend door de overwegingen en aanbevelingen in deze sectie.

Overwegingen bij het ontwerpen

• De aanpak voor het ontwerpen van toepassingen voor een bedrijfskritieke toepassing onderschrijft het gebruik van onafhankelijke regionale implementaties met zonegebonden redundantie die op alle onderdeelniveaus binnen één regio wordt toegepast.

• Een beschikbaarheidszone (AZ) is een fysiek afzonderlijke datacenterlocatie binnen een Azure-regio, waardoor fysieke en logische foutisolatie wordt geboden tot het niveau van één datacenter.

  Een retourlatentie van minder dan 2 ms is gegarandeerd voor communicatie tussen zones. Zones hebben een kleine latentievariantie op basis van verschillende afstanden en glasvezelpaden tussen zones.

• Connectiviteit van beschikbaarheidszones is afhankelijk van regionale kenmerken en daarom moet verkeer dat via een randlocatie binnenkomt mogelijk worden gerouteerd tussen zones om de bestemming te bereiken. Hiermee wordt een latentie van ~1ms-2 ms toegevoegd op basis van routering tussen zones en 'snelheid van licht', maar dit mag alleen van invloed zijn op hypergevoelige workloads.

• Beschikbaarheidszones worden behandeld als logische entiteiten binnen de context van één abonnement, zodat verschillende abonnementen mogelijk een andere zonegebonden toewijzing hebben voor dezelfde regio. Zone 1 in abonnement A kan bijvoorbeeld overeenkomen met hetzelfde fysieke datacenter als zone 2 in abonnement B.

• Met toepassingsscenario's die zeer goed zijn verdeeld tussen toepassingsonderdelen, kan het spreiden van toepassingslagen over zones aanzienlijke latentie en hogere kosten veroorzaken. Het is mogelijk om dit binnen het ontwerp te beperken door een implementatiestempel te beperken tot één zone en meerdere stempels in de verschillende zones te implementeren.

• Bij communicatie tussen verschillende Azure-regio's worden grotere kosten voor gegevensoverdracht per GB aan bandbreedte in rekening gebracht .

  • De toepasselijke snelheid voor gegevensoverdracht is afhankelijk van het continent van de beschouwde Azure-regio's.
  • Gegevens die continenten doorkruisen, worden aanzienlijk hoger in rekening gebracht.

• ExpressRoute- en VPN-connectiviteitsmethoden kunnen ook worden gebruikt om verschillende Azure-regio's rechtstreeks met elkaar te verbinden voor bepaalde scenario's of zelfs verschillende cloudplatforms.

• Voor services naar servicecommunicatie kan Private Link worden gebruikt voor directe communicatie met behulp van privé-eindpunten.

• Verkeer kan worden vastgemaakt via Express Route-circuits die worden gebruikt voor on-premises connectiviteit om routering tussen virtuele netwerken binnen een Azure-regio en in verschillende Azure-regio's binnen dezelfde geografie te vergemakkelijken.

  • Het vastmaken van verkeer via Express Route omzeilt de kosten voor gegevensoverdracht die zijn gekoppeld aan peering van virtuele netwerken, dus kan worden gebruikt als een manier om de kosten te optimaliseren.
  • Deze aanpak vereist extra netwerkhops voor toepassingsintegratie in Azure, waardoor latentie- en betrouwbaarheidsrisico's worden geïntroduceerd. Breidt de rol van Express Route en bijbehorende gatewayonderdelen van Azure/on-premises uit om ook Azure/Azure-connectiviteit te omvatten.

• Wanneer latentie van submilliseconden tussen services vereist is, kunnen nabijheidsplaatsingsgroepen worden gebruikt wanneer deze worden ondersteund door de gebruikte services.

Ontwerpaanaanvelingen

• Gebruik peering van virtuele netwerken om netwerken binnen een regio en in verschillende regio's te verbinden. Het wordt sterk aanbevolen om hair-pinning in Express Route te voorkomen.

• Gebruik Private Link om rechtstreeks communicatie tot stand te brengen tussen services in dezelfde regio of tussen regio's (service in regio A die communiceert met de service in regio B.

• Voor toepassingsworkloads die zeer goed tussen onderdelen zijn, kunt u overwegen om een implementatiestempel te beperken tot één zone en meerdere stempels in de verschillende zones te implementeren. Dit zorgt ervoor dat zonegebonden redundantie wordt gehandhaafd op het niveau van een ingekapselde implementatiestempel in plaats van één toepassingsonderdeel.

• Behandel waar mogelijk elke implementatiestempel als onafhankelijk en losgekoppeld van andere stempels.

  • Gebruik gegevensplatformtechnologieën om de status tussen regio's te synchroniseren in plaats van consistentie te bereiken op toepassingsniveau met directe netwerkpaden.
  • Vermijd 'hondenlegging'-verkeer tussen verschillende regio's, tenzij dat nodig is, zelfs in een foutscenario. Gebruik globale routeringsservices en end-to-end statustests om een volledige zegel uit de circulatie te halen in het geval dat één kritieke onderdeellaag mislukt, in plaats van verkeer te routeren op dat defect onderdeelniveau naar een andere regio.

• Voor scenario's met gevoelige hyperlatentie geeft u prioriteit aan het gebruik van zones met regionale netwerkgateways om de netwerklatentie voor inkomend verkeer te optimaliseren.

Microsegmentatie en Kubernetes-netwerkbeleid

Microsegmentatie is een ontwerppatroon voor netwerkbeveiliging dat wordt gebruikt voor het isoleren en beveiligen van afzonderlijke toepassingsworkloads, waarbij beleid wordt toegepast om netwerkverkeer tussen workloads te beperken op basis van een Zero Trust-model. Het wordt doorgaans toegepast om het netwerkaanvaloppervlak te verminderen, de insluiting van schendingen te verbeteren en de beveiliging te versterken via netwerkcontroles op toepassingsniveau op beleidsniveau.

Een bedrijfskritieke toepassing kan netwerkbeveiliging op toepassingsniveau afdwingen met behulp van netwerkbeveiligingsgroepen (NSG) op subnet- of netwerkinterfaceniveau, servicetoegangsbeheerlijsten (ACL) en netwerkbeleid bij gebruik van Azure Kubernetes Service (AKS).

In deze sectie wordt het optimale gebruik van deze mogelijkheden verkend en worden belangrijke overwegingen en aanbevelingen geboden om microsegmentatie op toepassingsniveau te bereiken.

Overwegingen bij het ontwerpen

• AKS kan worden geïmplementeerd in twee verschillende netwerkmodellen:

  • Kubenet-netwerken: AKS-knooppunten zijn geïntegreerd in een bestaand virtueel netwerk, maar pods bestaan binnen een virtueel overlaynetwerk op elk knooppunt. Verkeer tussen pods op verschillende knooppunten wordt gerouteerd via kube-proxy.
  • Azure Container Networking Interface (CNI)-netwerken: het AKS-cluster is geïntegreerd in een bestaand virtueel netwerk en de knooppunten, pods en services die IP-adressen hebben ontvangen van hetzelfde virtuele netwerk waaraan de clusterknooppunten zijn gekoppeld. Dit is relevant voor verschillende netwerkscenario's waarvoor directe connectiviteit van en naar pods is vereist. Verschillende knooppuntgroepen kunnen worden geïmplementeerd in verschillende subnetten.

  Notitie

  Azure CNI vereist meer IP-adresruimte in vergelijking met Kubenet. De juiste planning en grootte van het netwerk zijn vereist. Raadpleeg de Documentatie van Azure CNI voor meer informatie.

• Pods zijn standaard niet geïsoleerd en accepteren verkeer van elke bron en kunnen verkeer verzenden naar elke bestemming; een pod kan communiceren met elke andere pod in een bepaald Kubernetes-cluster; Kubernetes zorgt niet voor isolatie op netwerkniveau en isoleert geen naamruimten op clusterniveau.

• Communicatie tussen pods en naamruimten kan worden geïsoleerd met behulp van netwerkbeleid. Netwerkbeleid is een Kubernetes-specificatie die toegangsbeleid definieert voor communicatie tussen pods. Met behulp van netwerkbeleid kan een geordende set regels worden gedefinieerd om te bepalen hoe verkeer wordt verzonden/ontvangen en toegepast op een verzameling pods die overeenkomen met een of meer labelkiezers.

  • AKS ondersteunt twee invoegtoepassingen die Network Policy, Azure en Calico implementeren. Beide invoegtoepassingen gebruiken Linux IPTables om het opgegeven beleid af te dwingen. Zie Verschillen tussen Azure- en Calico-beleid en hun mogelijkheden voor meer informatie.
  • Netwerkbeleidsregels conflicteren niet omdat ze additief zijn.
  • Om een netwerkstroom tussen twee pods toe te staan, moeten zowel het uitgaand beleid op de bronpod als het toegangsbeleid op de doelpod het verkeer toestaan.
  • De functie voor netwerkbeleid kan alleen worden ingeschakeld tijdens het instantiëringstijdstip van het cluster. Het is niet mogelijk netwerkbeleid in te schakelen op een bestaand AKS-cluster.
  • De levering van netwerkbeleidsregels is consistent, ongeacht of Azure of Calico wordt gebruikt.
  • Calico biedt een uitgebreidere functieset, waaronder ondersteuning voor Windows-knooppunten en biedt ondersteuning voor Azure CNI en Kubenet.

• AKS ondersteunt het maken van verschillende knooppuntgroepen om verschillende workloads te scheiden met behulp van knooppunten met verschillende hardware- en softwarekenmerken, zoals knooppunten met en zonder GPU-mogelijkheden.

  • Het gebruik van knooppuntgroepen biedt geen isolatie op netwerkniveau.
  • Knooppuntgroepen kunnen verschillende subnetten binnen hetzelfde virtuele netwerk gebruiken. NSG's kunnen worden toegepast op subnetniveau om microsegmentatie tussen knooppuntgroepen te implementeren.

Ontwerpaanaanvelingen

• Configureer een NSG op alle beschouwde subnetten om een IP-ACL te bieden voor het beveiligen van toegangsbeheerpaden en het isoleren van toepassingsonderdelen op basis van een Zero Trust-model.

  • Gebruik Front Door-servicetags binnen NSG's op alle subnetten met toepassingsback-ends die zijn gedefinieerd in Azure Front Door, omdat hiermee wordt gevalideerd of verkeer afkomstig is van een legitieme IP-adresruimte van de Back-end van Azure Front Door. Dit zorgt ervoor dat verkeer via Azure Front Door op serviceniveau stroomt, maar filters op basis van headers zijn nog steeds vereist om ervoor te zorgen dat een bepaald Front Door-exemplaar wordt gebruikt en om ook beveiligingsrisico's van IP-adresvervalsing te beperken.

  • Openbaar internetverkeer moet worden uitgeschakeld op RDP- en SSH-poorten voor alle toepasselijke NSG's.

  • Geef prioriteit aan het gebruik van de Azure CNI-netwerkinvoegtoepassing en overweeg Kubenet voor scenario's met een beperkt aantal beschikbare IP-adressen om de toepassing binnen een beperkte adresruimte aan te passen.

    • AKS ondersteunt het gebruik van zowel Azure CNI als Kubenet. Deze netwerkkeuze is geselecteerd tijdens de implementatie.
    • De Azure CNI-netwerkinvoegtoepassing is een robuustere en schaalbare netwerkinvoegtoepassing en wordt aanbevolen voor de meeste scenario's.
    • Kubenet is een lichtgewicht netwerkinvoegtoepassing en wordt aanbevolen voor scenario's met een beperkt aantal beschikbare IP-adressen.
    • Zie Azure CNI voor meer informatie.

• De functie Netwerkbeleid in Kubernetes moet worden gebruikt om regels te definiëren voor inkomend en uitgaand verkeer tussen pods in een cluster. Definieer gedetailleerd netwerkbeleid om communicatie tussen pods te beperken en te beperken.

  • Schakel Netwerkbeleid in voor Azure Kubernetes Service tijdens de implementatie.
  • Geef prioriteit aan het gebruik van Calico omdat het een uitgebreidere functieset biedt met bredere acceptatie en ondersteuning van de community.

Volgende stap

Bekijk de overwegingen voor het kwantificeren en observeren van de toepassingsstatus.

Statusmodellering en waarneembaarheid