Netwerken en connectiviteit voor bedrijfskritieke workloads
De regionale distributie van resources in de bedrijfskritieke referentiearchitectuur vereist een robuuste netwerkinfrastructuur.
Een wereldwijd gedistribueerd ontwerp wordt aanbevolen, waarbij Azure-services worden gecombineerd om een toepassing met hoge beschikbaarheid te bieden. De wereldwijde load balancer in combinatie met regionale stempels biedt een betrouwbare connectiviteit.
De regionale stempels zijn de implementeerbare eenheid in de architectuur. De mogelijkheid om snel een nieuwe stempel te implementeren, biedt schaalbaarheid en ondersteuning voor hoge beschikbaarheid. De stempels volgen een geïsoleerd virtueel netwerkontwerp. Kruisstempelverkeer wordt niet aanbevolen. Peerings van virtuele netwerken of VPN-verbindingen met andere stempels zijn niet vereist.
De architectuur is opzettelijk bij het definiëren van de regionale stempels als van korte duur. De globale status van de infrastructuur wordt opgeslagen in de globale resources.
Een globale load balancer is vereist om verkeer naar gezonde stempels te routeren en beveiligingsservices te bieden. Het moet bepaalde mogelijkheden hebben.
De statustest is vereist, zodat de load balancer de status van de oorsprong kan controleren voordat verkeer wordt gerouteerd.
Gewogen verkeersdistributie.
Optioneel moet het cachen aan de rand kunnen uitvoeren. Geef ook enige beveiligingsgarantie voor inkomend verkeer door gebruik te maken van Waf (Web Application Firewall).
Een Visio-bestand van deze architectuur downloaden.
Inkomend verkeer
De toepassing die in de architectuur is gedefinieerd, is internetgericht en heeft verschillende vereisten:
Een routeringsoplossing die wereldwijd is en verkeer kan distribueren tussen onafhankelijke regionale stempels.
Lage latentie bij statuscontrole en de mogelijkheid om te stoppen met het verzenden van verkeer naar beschadigde stempels.
Preventie van schadelijke aanvallen aan de rand.
Cachemogelijkheden bieden aan de rand.
Het toegangspunt voor al het verkeer in het ontwerp is via Azure Front Door. Front Door is een globale load balancer die HTTP(S)-verkeer routeert naar geregistreerde back-ends/origins. Front Door maakt gebruik van statustests die aanvragen verzenden naar een URI in elke back-end/oorsprong. In de referentie-implementatie is de aangeroepen URI een statusservice. De gezondheidsdienst adverteert de status van de zegel. Front Door gebruikt het antwoord om de status van een afzonderlijke zegel te bepalen en verkeer om te leiden naar gezonde stempels die geschikt zijn voor het verwerken van toepassingsaanvragen.
Azure Front Door-integratie met Azure Monitor biedt bijna realtime bewaking van verkeer, beveiliging, metrische gegevens over succes en fouten en waarschuwingen.
Azure Web Application Firewall, geïntegreerd met Azure Front Door, wordt gebruikt om aanvallen aan de rand te voorkomen voordat ze het netwerk binnenkomen.
Geïsoleerd virtueel netwerk - API
De API in de architectuur gebruikt Azure Virtual Networks als grens voor de isolatie van verkeer. Onderdelen in het ene virtuele netwerk kunnen niet rechtstreeks communiceren met onderdelen in een ander virtueel netwerk.
Aanvragen naar het toepassingsplatform worden gedistribueerd met een standaard-SKU externe Azure Load Balancer. Er wordt gecontroleerd of verkeer dat de load balancer bereikt, is gerouteerd via Azure Front Door. Deze controle zorgt ervoor dat al het verkeer is geïnspecteerd door de Azure WAF.
Build-agents die worden gebruikt voor de bewerkingen en implementatie van de architectuur, moeten het geïsoleerde netwerk kunnen bereiken. Het geïsoleerde netwerk kan worden geopend zodat de agents kunnen communiceren. Zelf-hostende agents kunnen ook worden geïmplementeerd in het virtuele netwerk.
Bewaking van de netwerkdoorvoer, prestaties van de afzonderlijke onderdelen en status van de toepassing is vereist.
Communicatieafhankelijkheid van toepassingsplatform
Het toepassingsplatform dat wordt gebruikt met de afzonderlijke stempels in de infrastructuur, heeft de volgende communicatievereisten:
Het toepassingsplatform moet veilig kunnen communiceren met Microsoft PaaS-services.
Het toepassingsplatform moet veilig kunnen communiceren met andere services wanneer dat nodig is.
De architectuur zoals gedefinieerd maakt gebruik van Azure Key Vault om geheimen op te slaan, zoals verbindingsreeksen en API-sleutels, om veilig via internet te communiceren met Azure PaaS-services. Er zijn mogelijke risico's voor het beschikbaar maken van het toepassingsplatform via internet voor deze communicatie. Geheimen kunnen worden aangetast en betere beveiliging en bewaking van de openbare eindpunten wordt aanbevolen.
Overwegingen voor uitgebreide netwerken
In deze sectie worden de voor- en nadelen van alternatieve benaderingen voor het netwerkontwerp besproken. Alternatieve netwerkoverwegingen en het gebruik van Privé-eindpunten van Azure zijn de focus in de volgende secties.
Subnetten en NSG
Subnetten binnen de virtuele netwerken kunnen worden gebruikt om verkeer binnen het ontwerp te segmenteren. Subnetisolatie scheidt resources voor verschillende functies.
Netwerkbeveiligingsgroepen kunnen worden gebruikt om het verkeer te beheren dat in en uit elk subnet is toegestaan. Regels die binnen de NSG's worden gebruikt, kunnen worden gebruikt om verkeer te beperken op basis van IP, poort en protocol om ongewenst verkeer in het subnet te blokkeren.
Privé-eindpunten - Inkomend verkeer
De Premium-SKU van Front Door ondersteunt het gebruik van Azure-privé-eindpunten. Privé-eindpunten maken een Azure-service beschikbaar voor een privé-IP-adres in een virtueel netwerk. Verbindingen worden veilig en privé gemaakt tussen services zonder dat het verkeer naar openbare eindpunten hoeft te worden gerouteerd.
Azure Front Door Premium en Azure-privé-eindpunten maken volledig privé-rekenclusters in de afzonderlijke stempels mogelijk. Verkeer is volledig vergrendeld voor alle Azure PaaS-services.
Het gebruik van privé-eindpunten verhoogt de beveiliging van het ontwerp. Er wordt echter een ander foutpunt geïntroduceerd. Openbare eindpunten die in de toepassingsstempels worden weergegeven, zijn niet meer nodig en kunnen niet meer worden geopend en blootgesteld aan een mogelijke DDoS-aanval.
De verhoogde beveiliging moet worden afgewogen tegen de toegenomen betrouwbaarheidsinspanning, kosten en complexiteit.
Voor de zegelimplementatie moeten zelf-hostende buildagents worden gebruikt. Het beheer van deze agents wordt geleverd met een onderhoudsoverhead.
Privé-eindpunten - Toepassingsplatform
Privé-eindpunten worden ondersteund voor alle Azure PaaS-services die in dit ontwerp worden gebruikt. Als privé-eindpunten zijn geconfigureerd voor het toepassingsplatform, wordt alle communicatie via het virtuele netwerk van de zegel verzonden.
De openbare eindpunten van de afzonderlijke Azure PaaS-services kunnen worden geconfigureerd om openbare toegang niet toe te staan. Hiermee worden de resources geïsoleerd van openbare aanvallen die downtime en beperkingen kunnen veroorzaken die van invloed zijn op de betrouwbaarheid en beschikbaarheid.
Zelf-hostende buildagents moeten voor de zegelimplementatie op dezelfde als hierboven worden gebruikt. Het beheer van deze agents wordt geleverd met een onderhoudsoverhead.
Volgende stappen
Implementeer de referentie-implementatie om een volledig inzicht te krijgen in de resources en hun configuratie die in deze architectuur worden gebruikt.