Basislijnarchitectuur van Azure Virtual Machines in een Azure-landingszone

De architectuur in dit artikel breidt de basislijnarchitectuur van de virtuele machine (VM) uit om wijzigingen en verwachtingen aan te pakken wanneer u deze implementeert in een Azure-landingszone.

In het voorbeeld in dit artikel wil een organisatie een workload op basis van een VIRTUELE machine gebruiken om federatieve resources te gebruiken die een platformteam centraal beheert. Deze resources omvatten netwerkresources voor cross-premises connectiviteit, identiteitstoegangsbeheer en beleid. In dit voorbeeld wordt ervan uitgegaan dat de organisatie Azure-landingszones gebruikt om consistente governance en kostenefficiëntie af te dwingen voor meerdere workloads.

Als eigenaar van een workload kunt u het beheer van gedeelde resources offloaden naar centrale teams, zodat u zich kunt richten op de ontwikkeling van workloads. In dit artikel wordt het perspectief van het workloadteam beschreven. Aanbevelingen die voor het platformteam zijn opgegeven.

Artikelindeling

Architectuur	Ontwerpbeslissing	Azure Well-Architected Framework-benadering
▪ Architectuurdiagram ▪ Workloadresources ▪ Federatieve resources	▪ Abonnement instellen ▪ Netwerkvereisten ▪ Wijzigingen in het netwerkontwerp van de basislijn ▪ Monitoring ▪ Patchnaleving ▪ Organisatiebeheer ▪ Wijzigingsbeheer	▪ Betrouwbaarheid ▪ Veiligheid ▪ Kostenoptimalisatie

Architectuur

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

Alle Azure-landingszonearchitecturen hebben een scheiding van eigendom tussen het platformteam en het workloadteam. Toepassingsarchitecten en DevOps-teams moeten een sterk inzicht hebben in deze verantwoordelijkheid om te begrijpen wat er onder hun directe invloed of controle valt en wat niet.

Resources die eigendom zijn van het workloadteam

De volgende resources blijven grotendeels ongewijzigd ten laste van de basislijnarchitectuur.

• Azure Virtual Machines is het toepassingsplatform. De rekenresources worden verdeeld over beschikbaarheidszones.

• Azure Load Balancer wordt gebruikt voor het privé verdelen van verkeer van de front-end-VM's naar de back-end-VM's. De load balancer verdeelt verkeer naar VM's tussen zones.

• Azure-toepassing Gateway wordt gebruikt als de omgekeerde proxy om gebruikersaanvragen naar de front-end-VM's te routeren. De geselecteerde SKU wordt ook gebruikt om Azure Web Application Firewall te hosten om de front-end-VM's te beschermen tegen mogelijk schadelijk verkeer.

• Azure Key Vault wordt gebruikt voor het opslaan van toepassingsgeheimen en -certificaten.

• Azure Monitor, Log Analytics en Application Insights worden gebruikt voor het verzamelen, opslaan en visualiseren van waarneembaarheidsgegevens.

• Azure Policy wordt gebruikt om beleidsregels toe te passen die specifiek zijn voor de workload.

Het workloadteam onderhoudt en voldoet aan de volgende resources en verantwoordelijkheden.

• Subnetten van virtuele spoke-netwerken en de netwerkbeveiligingsgroepen (NSG's) die op deze subnetten worden geplaatst om segmentatie te onderhouden en de verkeersstroom te beheren.

• Privé-eindpunten voor het beveiligen van connectiviteit met PaaS-oplossingen (Platform as a Service) en de privé-DNS-zones die vereist zijn voor deze eindpunten.

• Azure Managed Disks slaat logboekbestanden op de back-endservers op en de gegevens blijven behouden, zelfs wanneer vm's opnieuw worden opgestart. Op de front-endservers zijn schijven gekoppeld die u kunt gebruiken om uw staatloze toepassing te implementeren.

Resources die eigendom zijn van het platform

Het platformteam is eigenaar van en onderhoudt deze gecentraliseerde resources. In deze architectuur wordt ervan uitgegaan dat deze resources vooraf zijn voorbereid en dat ze afhankelijkheden worden beschouwd.

• Azure Firewall in het hubnetwerk wordt gebruikt om uitgaand verkeer te inspecteren en te beperken. Dit onderdeel vervangt de standaard load balancer in de basislijnarchitectuur, die geen beperkingen biedt voor uitgaand verkeer naar internet.

• Azure Bastion in het hubnetwerk biedt veilige operationele toegang tot workload-VM's. In de basislijnarchitectuur is het workloadteam eigenaar van dit onderdeel.

• In het virtuele spoke-netwerk wordt de workload geïmplementeerd.

• Door de gebruiker gedefinieerde routes (UDR's) worden gebruikt om tunneling naar het hubnetwerk af te dwingen.

• Op Azure Policy gebaseerde governancebeperkingen en DeployIfNotExists (DINE)-beleidsregels maken deel uit van het workloadabonnement.

Abonnement instellen

In een context van een landingszone moet uw workloadteam het platformteam informeren over hun specifieke vereisten.

Uw workloadteam moet gedetailleerde informatie bevatten over de netwerkruimte die uw workload nodig heeft, zodat het platformteam de benodigde resources kan toewijzen. Uw team bepaalt de vereisten en het platformteam bepaalt de IP-adressen die moeten worden toegewezen binnen het virtuele netwerk en de beheergroep waaraan het abonnement is toegewezen.

Het platformteam wijst een geschikte beheergroep toe op basis van de bedrijfskritiek en technische vereisten van de workload, bijvoorbeeld als een workload beschikbaar is op internet. De organisatie bepaalt de configuratie van deze beheergroepen en het platformteam implementeert ze.

De beheergroepen in de toepassingsscenario's voor de basislijnarchitectuur worden bijvoorbeeld als volgt beschouwd:

• Privétoepassingen, zoals interne Line-Of-Business-toepassingen of commerciële off-the-shelf -oplossingen (COTS), die zich vaak onder de Corp-beheergroep van Azure-landingszones bevinden.

• Openbare toepassingen, zoals in internetgerichte toepassingen, die zich vaak onder de beheergroep Corp of Online bevinden.

Het platformteam is ook verantwoordelijk voor het instellen van een abonnement of een groep abonnementen voor de workloadimplementatie.

De volgende secties bevatten richtlijnen voor de eerste installatie van het abonnement. Het platformteam brengt echter meestal wijzigingen aan in de gecentraliseerde services om te voldoen aan gemiste of gewijzigde vereisten. Platformwijzigingen hebben een breder effect op alle workloadteams.

Daarom moet het platformteam ervoor zorgen dat alle VM-workloads worden voorbereid op eventuele wijzigingen en ze moeten rekening houden met de levenscyclus van de vm-oplossing en de testcyclus. Zie Wijzigingen in de loop van de tijd beheren voor meer informatie.

Workloadvereisten en -uitvoeringen

Het workloadteam en platformteams delen twee belangrijke verantwoordelijkheden: beheergroeptoewijzing en netwerkinstallatie. Houd voor deze architectuur rekening met de volgende netwerkvereisten die u moet communiceren met het platformteam. Gebruik deze punten als voorbeelden om inzicht te hebben in de discussie en onderhandelingen tussen de twee teams wanneer u een vergelijkbare architectuur implementeert.

• Het aantal virtuele spoke-netwerken: in deze architectuur is slechts één toegewezen spoke vereist. De geïmplementeerde resources hoeven zich niet over meerdere netwerken te bevinden en zich binnen één virtueel netwerk bevinden.

• De grootte van het spoke-netwerk: neem rekening met de operationele vereisten en de verwachte groei van de workload. Als u bijvoorbeeld blauw/groen of kanarie-updates wilt implementeren, moet de maximale grootte rekening houden met de ruimte die uw implementaties naast elkaar vereisen.

  Voor toekomstige wijzigingen is mogelijk meer IP-ruimte vereist, wat verkeerd kan worden afgestemd op de huidige toewijzing. De integratie van deze ruimten kan extra complexiteit veroorzaken. Wees proactief en vraag voldoende netwerkresources vooraf aan om ervoor te zorgen dat de toegewezen ruimte ruimte geschikt is voor toekomstige uitbreiding.

• De implementatieregio: het is belangrijk om de regio's op te geven waar de workload wordt geïmplementeerd. Het platformteam kan deze informatie gebruiken om ervoor te zorgen dat de virtuele spoke- en hubnetwerken in dezelfde regio worden ingericht. Netwerken in verschillende regio's kunnen leiden tot latentieproblemen vanwege verkeer dat regionale grenzen overschrijdt en kan ook extra bandbreedtekosten in rekening brengen.

• De kenmerken en ontwerpkeuzen van de werkbelasting: Geef uw ontwerpkeuzes, onderdelen en kenmerken door aan uw platformteam. Als u bijvoorbeeld verwacht dat uw workload een groot aantal gelijktijdige verbindingen met internet genereert (chatty), moet het platformteam ervoor zorgen dat er voldoende poorten beschikbaar zijn om uitputting te voorkomen. Ze kunnen IP-adressen toevoegen aan de gecentraliseerde firewall om het verkeer te ondersteunen of een NAT-gateway (Network Address Translation) instellen om het verkeer via een alternatief pad te routeren.

  Als u echter verwacht dat uw workload minimaal netwerkverkeer genereert (achtergrondruis), moet het platformteam resources efficiënt in de hele organisatie gebruiken.

  Het platformteam moet duidelijk inzicht krijgen in eventuele afhankelijkheden. Uw workload heeft bijvoorbeeld toegang nodig tot een database die eigenaar is van een ander team, of mogelijk heeft uw workload cross-premises verkeer. Heeft uw workload afhankelijkheden buiten Azure? Dergelijke informatie is belangrijk voor het platformteam.

• De firewallconfiguratie: het platformteam moet op de hoogte zijn van verkeer dat het spoke-netwerk verlaat en wordt getunneld naar het hubnetwerk. De firewall in de hub kan dat verkeer niet blokkeren.

  Als uw workload bijvoorbeeld toegang nodig heeft tot Windows-updates om gepatcht te blijven, moet een firewall deze updates niet blokkeren. Als er monitoragents zijn die toegang hebben tot specifieke eindpunten, moet een firewall dat verkeer niet blokkeren, omdat het bewakingsgegevens voor uw workload kan verstoren. De toepassing vereist mogelijk toegang tot eindpunten van derden. U kunt ook een gecentraliseerde firewall gebruiken om onderscheid te maken tussen verwacht en onwarrant verkeer.

• Operatortoegang: Als er Microsoft Entra ID-beveiligingsgroepen zijn die operators gebruiken voor toegang tot de VM's via Azure Bastion, informeert u het platformteam. Azure Bastion is doorgaans een centrale resource. Het is van cruciaal belang om ervoor te zorgen dat de beveiligingsgroepen en de VM's het beveiligde protocol ondersteunen.

  Informeer het platformteam bovendien over de IP-bereiken die de VM's bevatten. Deze informatie is nodig voor het configureren van de NSG's rond Azure Bastion in het hubnetwerk.

• De openbare IP-adressen: informeer het platformteam over het profiel voor inkomend verkeer, inclusief eventuele verwachte openbare IP-adressen. In deze architectuur is alleen internetverkeer gericht op het openbare IP-adres op Application Gateway. Het platformteam moet het workloadteam informeren als deze IP-adressen onder een Azure DDoS Protection-plan vallen of als dat de verantwoordelijkheid van het workloadteam is.

  In deze architectuur is er nog een openbaar IP-adres voor operationele toegang via Azure Bastion. Het platformteam is eigenaar van dit openbare IP-adres en is ingeschreven in een service, zoals DDoS Protection, die het platformteam ook beheert.

Keuzen voor VM-ontwerp

De VM-SKU en schijfselecties blijven hetzelfde als de basislijnarchitectuur.

Een organisatie kan nalevingsvereisten opleggen aan het workloadteam dat het gebruik van specifieke VM-installatiekopieën verplicht stelt. Op basis van dergelijke vereisten kan het platformteam een set gestandaardiseerde installatiekopieën beheren, ook wel gouden afbeeldingen genoemd, die worden gemaakt voor gebruik in de hele organisatie.

Het platformteam kan gebruikmaken van een beheerd aanbod, zoals Azure Compute Gallery of een privéopslagplaats voor het opslaan van goedgekeurde installatiekopieën van besturingssystemen of workloadartefacten. Wanneer u een installatiekopieën van het besturingssysteem voor VM's kiest, raadpleegt u uw platformteam over afbeeldingsbronnen, updatefrequentie en gebruiks verwachtingen. Zorg er ook voor dat installatiekopieën kunnen voldoen aan de benodigde bedrijfsvereisten waaraan de workload voldoet.

Netwerken

In de basislijnarchitectuur wordt de workload ingericht in één virtueel netwerk. Het workloadteam beheert het virtuele netwerk.

In deze architectuur bepaalt het platformteam de netwerktopologie. Hub-spoke-topologie wordt aangenomen in deze architectuur.

Een Visio-bestand van deze architectuur downloaden.

• Virtueel hubnetwerk: een regionale hub bevat gecentraliseerde services die communiceren met workloadresources in dezelfde regio. Zie Platform-teamresources voor meer informatie. U wordt aangeraden de hub in het connectiviteitsabonnement te plaatsen.

• Virtueel spoke-netwerk: In deze architectuur is het enige virtuele netwerk van de basislijnarchitectuur het spoke-netwerk. Het is gekoppeld aan het hubnetwerk, dat de gecentraliseerde services bevat. Het platformteam is eigenaar van dit spoke-netwerk en beheert dit spoke-netwerk. Dit netwerk bevat de workloadresources. Het workloadteam is eigenaar van de resources in dit netwerk, met inbegrip van de subnetten.

Zorg ervoor dat u de workloadvereisten communiceert met het platformteam en controleer deze regelmatig.

Virtueel netwerk-subnetten

In het virtuele spoke-netwerk maakt en wijst het workloadteam de subnetten toe. Het plaatsen van besturingselementen om verkeer in en uit de subnetten te beperken, helpt segmentatie te bieden. Deze architectuur maakt gebruik van dezelfde subnettopologie als de basislijnarchitectuur, met toegewezen subnetten voor Application Gateway, front-end-VM's, de load balancer, back-end-VM's en privé-eindpunten.

Wanneer u uw workload in een Azure-landingszone implementeert, moet u nog steeds netwerkbesturingselementen implementeren. Organisaties kunnen beperkingen opleggen om gegevensexfiltratie te beschermen en zichtbaarheid te garanderen voor het centrale Security Operations Center (SOC) en het IT-netwerkteam.

Met deze aanpak kan het platformteam de totale organisatorische uitgaven optimaliseren met behulp van gecentraliseerde services in plaats van redundante beveiligingscontroles te implementeren voor elke workload in de hele organisatie. In deze architectuur is Azure Firewall een voorbeeld van een centrale service. Het is niet rendabel of praktisch voor elk workloadteam om hun eigen firewallexemplaren te beheren. We raden een gecentraliseerde benadering aan voor firewallbeheer.

Inkomend verkeer

De stroom voor inkomend verkeer blijft hetzelfde als de basislijnarchitectuur.

De eigenaar van de workload is verantwoordelijk voor alle resources die zijn gerelateerd aan inkomend internet in uw workload. In deze architectuur worden Application Gateway en het bijbehorende openbare IP-adres bijvoorbeeld in het spoke-netwerk geplaatst en niet in het hubnetwerk. Sommige organisaties kunnen resources plaatsen met inkomend verkeer in een connectiviteitsabonnement met behulp van een gecentraliseerde gedemilitariseerde (DMZ)-implementatie. Integratie met die specifieke topologie valt buiten het bereik van dit artikel.

Uitgaand verkeer

In de basislijnarchitectuur hebben virtuele-machineschaalsets toegang tot het openbare internet via Azure Load Balancer, maar dat verkeer is niet beperkt.

Dat ontwerp is anders in deze architectuur. Al het verkeer dat het virtuele spoke-netwerk verlaat, wordt gerouteerd via het peered hub-netwerk via een uitgaande firewall. Een route wordt gekoppeld aan alle mogelijke subnetten in het spoke-netwerk waarmee al het verkeer voor IP-adressen die niet in het lokale virtuele netwerk (0.0.0.0/0) naar de Azure Firewall van de hub worden geleid.

Een Visio-bestand van deze architectuur downloaden.

Werkbelastingcommunicatie naar het privé-eindpunt voor Key Vault-toegang blijft hetzelfde als de basislijnarchitectuur. Dit pad wordt weggelaten uit het voorgaande diagram voor beknoptheid.

Het workloadteam moet alle benodigde uitgaande verkeersstromen identificeren, documenteren en communiceren voor de infrastructuur- en workloadbewerkingen. Het platformteam staat het vereiste verkeer toe en al het niet-gecommuniceerde uitgaand verkeer wordt waarschijnlijk geweigerd.

Het beheren van uitgaand verkeer is meer dan alleen om ervoor te zorgen dat het verwachte verkeer wordt toegestaan. Het gaat er ook om ervoor te zorgen dat alleen verwacht verkeer wordt toegestaan. Niet-gecommuniceerd uitgaand verkeer wordt waarschijnlijk standaard geweigerd, maar het is het beste beveiligingsbelang van de workload om ervoor te zorgen dat verkeer correct wordt gerouteerd.

Communiceer alle unieke vereisten voor uitgaand verkeer naar het platformteam. Als uw workload bijvoorbeeld talloze gelijktijdige verbindingen met externe netwerkeindpunten tot stand brengt, informeert u het platformteam. Vervolgens kan het platformteam een geschikte Azure NAT Gateway-implementatie inrichten of meer openbare IP-adressen toevoegen aan de regionale firewall voor risicobeperking.

Uw organisatie heeft mogelijk vereisten die het gebruik van architectuurpatronen ontmoedigen, die gebruikmaken van openbare IP-adressen die eigendom zijn van workloads voor uitgaand verkeer. In dat geval kunt u Azure Policy gebruiken om openbare IP-adressen op VM-netwerkinterfacekaarten (NIC's) en andere openbare IP-adressen te weigeren, behalve uw bekende ingangspunten.

Persoonlijke DNS-zones

Architecturen die gebruikmaken van privé-eindpunten hebben privé-DNS-zones nodig om met de DNS-provider te werken. Het workloadteam moet een duidelijk inzicht hebben in de vereisten en het beheer van privé-DNS-zones in het abonnement dat het platformteam biedt. Privé-DNS zones worden doorgaans op grote schaal beheerd met DINE-beleid, waardoor Azure Firewall kan functioneren als een betrouwbare DNS-proxy en FQDN-netwerkregels (Fully Qualified Domain Name) ondersteunt.

In deze architectuur zorgt het platformteam voor de betrouwbare privé-DNS-omzetting voor privékoppelingseindpunten. Werk samen met uw platformteam om inzicht te hebben in hun verwachtingen.

Verbinding maken iviteitstests

Voor VM-architecturen zijn er verschillende testhulpprogramma's die u kunnen helpen bij het bepalen van netwerklijn-of-detectie-, routerings- en DNS-problemen. U kunt traditionele hulpprogramma's voor probleemoplossing gebruiken, zoals netstat, nslookupof tcping. Daarnaast kunt u de DHCP-instellingen (Dynamic Host Configuration Protocol) en DNS van de netwerkadapter onderzoeken. Als er NIC's zijn, hebt u meer probleemoplossingsmogelijkheden waarmee u connectiviteitscontroles kunt uitvoeren met behulp van Azure Network Watcher.

Operatortoegang

Net als bij de basislijnarchitectuur wordt operationele toegang via Azure Bastion ondersteund in deze architectuur.

De basislijnarchitectuur implementeert Azure Bastion echter als onderdeel van de workload. Voor een typische organisatie die overstapt op Azure-landingszones, implementeren ze Azure Bastion als centrale resources voor elke regio. Het platformteam is eigenaar van En onderhoudt Azure Bastion en alle workloads in de organisatie delen het. Azure Bastion bevindt zich in het hubnetwerk in het connectiviteitsabonnement om aan te tonen dat deze use case in deze architectuur wordt gebruikt.

Operatoridentiteit

Deze architectuur maakt gebruik van dezelfde verificatie-extensie als de basislijnarchitectuur.

Begin altijd met het principe van minimale bevoegdheden en gedetailleerde toegang tot een taak in plaats van langdurige toegang. Profiteer in de context van de landingszone van Just-In-Time (JIT) die het platformteam beheert.

Patchnaleving en upgrades van het besturingssysteem

De basislijnarchitectuur beschrijft een autonome benadering van patches en upgrades. Wanneer de workload is geïntegreerd met landingszones, kan deze benadering veranderen. Het platformteam kan de patchbewerkingen dicteren, zodat alle workloads voldoen aan de vereisten van de organisatie.

Zorg ervoor dat het patchproces alle onderdelen bevat die u aan de architectuur toevoegt. Als u er bijvoorbeeld voor kiest om buildagent-VM's toe te voegen om de implementatie, schaal en beheer van toepassingen te automatiseren, moeten deze VM's voldoen aan de platformvereisten.

Controleren

Het Azure-landingszoneplatform biedt gedeelde waarneembaarheidsbronnen als onderdeel van het beheerabonnement. We raden u echter aan uw eigen bewakingsresources in te richten om de verantwoordelijkheden van de workload te vergemakkelijken. Deze benadering is consistent met de basislijnarchitectuur.

Het workloadteam richt de bewakingsresources in, waaronder:

• Application Insights als de APM-service (Application Performance Monitoring) voor het workloadteam.

• De Log Analytics-werkruimte als de geïntegreerde sink voor alle logboeken en metrische gegevens die worden verzameld van Azure-resources die eigendom zijn van de workload en de toepassingscode.

Een Visio-bestand van deze architectuur downloaden.

Net als bij de basislijn worden alle resources geconfigureerd voor het verzenden van Diagnostische logboeken van Azure naar de Log Analytics-werkruimte die het workloadteam indeelt als onderdeel van de implementatie van de infrastructuur als code (IaC) van de resources. Mogelijk moet u ook logboeken verzenden naar een centrale Log Analytics-werkruimte. In Azure-landingszones bevindt die werkruimte zich in het beheerabonnement.

Het platformteam kan ook DINE-beleid hebben dat ze kunnen gebruiken om diagnostische gegevens te configureren voor het verzenden van logboeken naar hun gecentraliseerde beheerabonnementen. Het is belangrijk om ervoor te zorgen dat uw implementatie de extra logboekstromen niet beperkt.

Gegevens uit meerdere sinks correleren

De logboeken en metrische gegevens van de werkbelasting en de bijbehorende infrastructuuronderdelen worden opgeslagen in de Log Analytics-werkruimte van de workload. Logboeken en metrische gegevens die gecentraliseerde services, zoals Azure Firewall, Microsoft Entra-id en Azure Bastion, genereren, worden echter opgeslagen in een centrale Log Analytics-werkruimte. Het correleren van gegevens uit meerdere sinks kan een complexe taak zijn.

Gecorreleerde gegevens worden vaak gebruikt tijdens het reageren op incidenten. Als er een probleem is met het correleren van gegevens uit meerdere sinks, moet u ervoor zorgen dat het runbook voor het triage-runbook voor deze architectuur deze aanpakt en organisatorische contactpunten bevat als het probleem zich buiten de werkbelastingresources bevindt. Workloadbeheerders hebben mogelijk hulp nodig van platformbeheerders om logboekvermeldingen van bedrijfsnetwerken, beveiliging of andere platformservices te correleren.

Azure Policy

Het platformteam past waarschijnlijk beleidsregels toe die van invloed zijn op de workloadimplementatie. Ze passen vaak DINE-beleid toe om geautomatiseerde implementaties af te handelen in een toepassingslandingszoneabonnement. DINE-beleid kan workloadresources wijzigen of resources toevoegen aan uw implementatie, wat kan leiden tot een discrepantie tussen de resources die declaratief worden geïmplementeerd via de workloadsjabloon en de resources die de verwerkingsaanvragen daadwerkelijk gebruiken. Een typische oplossing is het oplossen van deze wijzigingen met imperatieve benaderingen, die niet ideaal zijn.

Om deze discrepantie te voorkomen, moet u de door het platform geïnitieerde wijzigingen vooraf opnemen en testen in uw IaC-sjablonen. Als het platformteam Azure-beleid gebruikt dat conflicteren met de vereisten van de toepassing, kunt u onderhandelen over een oplossing met het platformteam.

Wijzigingen in de loop van de tijd beheren

Door het platform geleverde services en bewerkingen worden beschouwd als externe afhankelijkheden in deze architectuur. Het platformteam blijft wijzigingen toepassen, gebruikers onboarden en kostenbeheer toepassen. Het platformteam, dat de organisatie bedient, kan geen prioriteit geven aan afzonderlijke workloads. Wijzigingen in deze afhankelijkheden, of het nu gouden installatiekopieën zijn, firewallwijzigingen, geautomatiseerde patching of regelwijzigingen, kunnen van invloed zijn op meerdere workloads.

Daarom moeten workload- en platformteams efficiënt en tijdig communiceren om alle externe afhankelijkheden te beheren. Het is belangrijk om wijzigingen te testen, zodat ze geen negatieve invloed hebben op workloads.

Platformwijzigingen die van invloed zijn op de workload

In deze architectuur beheert het platformteam de volgende resources. Wijzigingen in deze resources kunnen de betrouwbaarheid, beveiliging, bewerkingen en prestatiedoelen van de workload beïnvloeden. Het is belangrijk om deze wijzigingen te evalueren voordat het platformteam ze van kracht maakt om te bepalen hoe deze van invloed zijn op de workload.

• Azure-beleid: wijzigingen in Azure-beleid kunnen invloed hebben op workloadresources en hun afhankelijkheden. Er kunnen bijvoorbeeld directe beleidswijzigingen of verplaatsingen van de landingszone zijn in een nieuwe hiërarchie van beheergroepen. Deze wijzigingen kunnen onopgemerkt blijven totdat er een nieuwe implementatie is, dus het is belangrijk om ze grondig te testen.

• Firewallregels: wijzigingen in firewallregels kunnen van invloed zijn op het virtuele netwerk van de werkbelasting of regels die breed van toepassing zijn op al het verkeer. Deze wijzigingen kunnen leiden tot geblokkeerd verkeer en zelfs stille procesfouten, zoals mislukte toepassing van besturingssysteempatches. Deze mogelijke problemen zijn van toepassing op zowel de uitgaande Azure-firewall als de NSG-regels die zijn toegepast op Azure Virtual Network Manager.

• Gedeelde resources: wijzigingen in de SKU of functies op gedeelde resources kunnen van invloed zijn op de workload.

• Routering in het hubnetwerk: wijzigingen in de transitieve aard van routering in de hub kunnen van invloed zijn op de workloadfunctionaliteit als een workload afhankelijk is van routering naar andere virtuele netwerken.

• Azure Bastion-host: wijzigingen in de beschikbaarheid of configuratie van de Azure Bastion-host kunnen invloed hebben op workloadbewerkingen. Zorg ervoor dat wijzigingen in jump box-toegangspatronen effectieve routine, ad-hoc en toegang tot noodgevallen hebben.

• Eigendomswijzigingen: Communiceer eventuele wijzigingen in eigendom en contactpunten met het workloadteam, omdat deze van invloed kunnen zijn op het beheer- en ondersteuningsverzoek van de workload.

Workloadwijzigingen die van invloed zijn op het platform

De volgende voorbeelden zijn workloadwijzigingen in deze architectuur die u moet communiceren met het platformteam. Het is belangrijk dat het platformteam de betrouwbaarheid, beveiliging, bewerkingen en prestatiedoelen van de platformservice valideert op basis van de wijzigingen in het nieuwe workloadteam voordat ze van kracht worden.

• Uitgaand netwerk: bewaak een aanzienlijke toename van het uitgaand netwerkverkeer om te voorkomen dat de werkbelasting een lawaaierige buur op netwerkapparaten wordt. Dit probleem kan mogelijk van invloed zijn op de prestatie- of betrouwbaarheidsdoelen van andere workloads.

• Openbare toegang: wijzigingen in de openbare toegang tot workloadonderdelen kunnen verdere tests vereisen. Het platformteam kan de workload verplaatsen naar een andere beheergroep.

• Classificatie bedrijfskritiek: als er wijzigingen zijn in de serviceovereenkomsten (SLA's) van de workload, hebt u mogelijk een nieuwe samenwerkingsbenadering nodig tussen het platform- en workloadteam.

• Eigendomswijzigingen: Communiceer wijzigingen in eigendom en contactpunten met het platformteam.

Wijzigingen in bedrijfsvereisten voor workloads

Als u serviceniveaudoelstellingen (SLO's) van de workload wilt behouden, moet het platformteam mogelijk betrokken zijn bij wijzigingen in de workloadarchitectuur. Deze wijzigingen vereisen mogelijk wijzigingsbeheer van het platformteam of validatie dat bestaande governance ondersteuning biedt voor de gewijzigde vereisten.

U kunt bijvoorbeeld wijzigingen doorgeven aan een eerder niet-toegestane uitgaande stroom, zodat het platformteam die stroom kan toevoegen aan de firewall, Virtual Network Manager of andere onderdelen om het vereiste verkeer te ondersteunen. Als een eerder toegestane uitgaande stroom daarentegen niet meer nodig is, moet het platformteam die stroom blokkeren om de beveiliging van de workload te behouden. Communiceer ook wijzigingen in routering naar andere virtuele netwerken of cross-premises eindpunten of wijzigingen in de architectuuronderdelen. Elke resource is onderworpen aan beleidsregels en mogelijk uitgaand firewallbeheer.

Betrouwbaarheid

Deze architectuur is afgestemd op de betrouwbaarheidsgaranties in de basislijnarchitectuur.

Betrouwbaarheidsdoelen

De maximaal mogelijke samengestelde SLO is lager dan de basislijn samengestelde SLO vanwege onderdelen zoals uitgaand netwerkbeheer. Deze onderdelen, die gebruikelijk zijn in landingszoneomgevingen, zijn niet uniek voor deze architectuur. De SLO wordt op dezelfde manier verminderd als het workloadteam deze Azure-services rechtstreeks beheert.

Ondanks een lagere maximaal mogelijke SLO is het belangrijkste betrouwbaarheidsaspect de verdeling van workloadonderdelen in functionele teams. Met deze methode profiteert het workloadteam van een gespecialiseerd team dat zich richt op de operationele kritieke infrastructuur die door deze workload en andere workloads wordt gebruikt.

Zie Aanbevelingen voor het definiëren van betrouwbaarheidsdoelen voor meer informatie.

Kritieke afhankelijkheden

Bekijk alle functionaliteit die de workload uitvoert in het platform en de landingszone van de toepassing als afhankelijkheden. Reactieplannen voor incidenten vereisen dat het workloadteam op de hoogte is van het punt en de methode van contactgegevens voor deze afhankelijkheden. Neem deze afhankelijkheden ook op in de analyse van de foutmodus van de workload (FMA).

Houd voor deze architectuur rekening met de volgende afhankelijkheden:

• Uitgaande firewall: de gecentraliseerde firewall voor uitgaand verkeer, gedeeld door meerdere workloads, ondergaat wijzigingen die niet gerelateerd zijn aan de workload.

• Netwerkpoortuitputting: pieken in gebruik van alle workloads die het netwerkapparaat delen, kunnen leiden tot netwerkverzadiging of poortuitputting op de firewall voor uitgaand verkeer.

• DINE-beleid: DINE-beleid voor privé-DNS-zones van Azure DNS (of een andere door het platform geleverde afhankelijkheid) is het beste werk, zonder SLA voor uitvoering. Een vertraging in de DNS-configuratie kan vertragingen veroorzaken bij de gereedheid van een toepassing om verkeer te verwerken.

• Groepsbeleid voor beheer: consistent beleid tussen omgevingen is essentieel voor betrouwbaarheid. Zorg ervoor dat preproductieomgevingen vergelijkbaar zijn met productieomgevingen om nauwkeurige tests te bieden en omgevingsspecifieke afwijkingen te voorkomen die een implementatie of schaal kunnen blokkeren. Zie Toepassingsontwikkelingsomgevingen beheren in Azure-landingszones voor meer informatie.

Veel van deze overwegingen kunnen bestaan zonder Azure-landingszones, maar de workload- en platformteams moeten deze problemen gezamenlijk aanpakken om ervoor te zorgen dat aan de behoeften wordt voldaan.

Zie Aanbevelingen voor meer informatie voor het uitvoeren van analyse van de foutmodus.

Beveiliging

De beveiligingsoverwegingen voor deze architectuur worden overgedragen van de basislijnarchitectuur. De aanbevelingen in de volgende secties zijn gebaseerd op de controlelijst voor beveiligingsontwerp in het Well-Architected Framework.

Netwerkbediening

Configureer netwerkbesturingselementen op de juiste manier om ervoor te zorgen dat uw workload veilig is.

Inkomend verkeer

U kunt uw workload isoleren van andere werkbelastingspaken binnen uw organisatie via NSG's op uw subnetten of de niet-transitieve aard of besturingselementen in de regionale hub. Bouw uitgebreide NSG's die alleen de binnenkomende netwerkvereisten van uw toepassing en de bijbehorende infrastructuur toestaan. U wordt aangeraden niet alleen te vertrouwen op de niet-transitieve aard van het hubnetwerk voor beveiliging.

Het platformteam implementeert waarschijnlijk Azure-beleid om ervoor te zorgen dat Application Gateway Web Application Firewall heeft ingesteld op de modus Weigeren, om het aantal openbare IP-adressen te beperken dat beschikbaar is voor uw abonnement en andere controles. Naast dit beleid moet het workloadteam de verantwoordelijkheid hebben voor het implementeren van workloadgerichte beleidsregels die het beveiligingspostuur voor inkomend verkeer versterken.

In de volgende tabel ziet u voorbeelden van besturingselementen voor inkomend verkeer in deze architectuur.

Bron	Doel	Workloadbeheer	Platformbeheer
Internet	Verkeersstromen van gebruikers	Trechtert alle aanvragen via een NSG, Web Application Firewall en routeringsregels voordat openbaar verkeer kan worden overgestapt op privéverkeer dat de front-end-VM's binnenkomt	Geen
Azure Bastion	Operatortoegang tot VM's	NSG op VM-subnetten die al het verkeer naar poorten voor externe toegang blokkeren, tenzij deze afkomstig is van het aangewezen Azure Bastion-subnet van het platform	Geen
Andere spokes	Geen	Geblokkeerd via NSG-regels	Niet-transitieve routering of Azure Firewall-regels in het geval van een met Azure Virtual WAN beveiligde hub

Uitgaand verkeer

Pas NSG-regels toe die de vereiste uitgaande connectiviteitsvereisten van uw oplossing uitdrukken en alles weigeren. Vertrouw niet alleen op de netwerkbesturingselementen van de hub. Als workloadoperator hebt u de verantwoordelijkheid om ongewenst uitgaand verkeer zo dicht mogelijk bij de bron te stoppen.

Houd er rekening mee dat terwijl u eigenaar bent van uw subnetten binnen het virtuele netwerk, het platformteam waarschijnlijk firewallregels heeft gemaakt om uw vastgelegde vereisten specifiek weer te geven als onderdeel van uw abonnementsautomaat proces. Zorg ervoor dat wijzigingen in subnetten en resourceplaatsing gedurende de levensduur van uw architectuur nog steeds compatibel zijn met uw oorspronkelijke aanvraag. U kunt ook samenwerken met uw netwerkteam om de continuïteit van uitgaand verkeer van minimale toegang te garanderen.

In de volgende tabel ziet u voorbeelden van uitgaand verkeer in deze architectuur.

Eindpunt	Doel	Besturingselement voor werkbelasting (NSG)	Platformbeheer (hub)
ntp.ubuntu.com	Het Network Time Protocol (NTP) voor linux-VM's	UDP/123 naar internet op het front-end VM-subnet (de uitgaande firewall beperkt deze brede opening)	Toelage voor firewallnetwerkregels voor hetzelfde als het workloadbeheer
Windows Update-eindpunten	Windows Update-functionaliteit van Microsoft-servers	TCP/443 en TCP/80 naar internet op het back-end-VM-subnet (de uitgaande firewall beperkt deze brede opening)	Regel voor firewallvergoeding met FQDN-tag van WindowsUpdate
Agenteindpunten bewaken	Vereist verkeer voor de Monitor-extensie op VM's	TCP/443 naar internet op beide VM-subnetten (de uitgaande firewall beperkt deze brede opening)	Vereiste regels voor firewalltoepassingen voor alle specifieke FQDN's op TCP/443
nginx.org	Nginx (een voorbeeldtoepassingsonderdeel) rechtstreeks vanuit de leverancier installeren	TCP/443 naar internet op het front-end-VM-subnet (de uitgaande firewall beperkt deze brede opening)	Vereiste toelage voor firewalltoepassingsregel voor nginx.org op TCP/443
Key Vault	TLS-certificaten importeren (Transport Layer Security) in Application Gateway en VM's	- TCP/443 naar een privé-eindpuntsubnet van beide VM-subnetten naar een subnet van een privé-eindpunt - TCP/443 naar een privé-eindpuntsubnet van een Application Gateway-subnet - TCP/443 van VM's die zijn gelabeld met een vereiste asg-aanduiding (application security group) en application gateway-subnet	Geen

DDoS-beveiliging

Bepaal wie verantwoordelijk is voor het toepassen van het DDoS Protection-plan dat betrekking heeft op alle openbare IP-adressen van uw oplossing. Het platformteam kan IP-beveiligingsplannen gebruiken of zelfs Azure Policy gebruiken om beveiligingsplannen voor virtuele netwerken af te dwingen. Deze architectuur moet dekking hebben omdat het een openbaar IP-adres voor inkomend verkeer van internet omvat.

Zie Aanbevelingen voor netwerken en connectiviteit voor meer informatie.

Geheimenbeheer

Voor geheimbeheer volgt deze architectuur de basislijnarchitectuur.

Als workloadteam kunt u uw geheimen blijven bewaren in uw Key Vault-exemplaar. Implementeer zo nodig meer exemplaren ter ondersteuning van uw toepassings- en infrastructuurbewerkingen.

Zie Aanbevelingen voor het beveiligen van toepassingsgeheimen voor meer informatie.

Kostenoptimalisatie

Voor de workloadresources zijn de strategieën voor kostenoptimalisatie in de basislijnarchitectuur ook van toepassing op deze architectuur.

Deze architectuur profiteert enorm van azure-platformbronnen voor landingszones. Zelfs als u deze resources gebruikt via een terugstortingsmodel, zijn de toegevoegde beveiliging en cross-premises connectiviteit rendabeler dan het zelf beheren van deze resources.

Het platformteam beheert de volgende resources in deze architectuur. Deze resources zijn vaak op basis van verbruik (terugstorting) of mogelijk gratis voor het workloadteam.

• Azure Firewall
• Security Information and Event Management (SIEM)
• Azure Bastion-hosts
• Cross-premises connectiviteit, zoals ExpressRoute

Profiteer van andere gecentraliseerde aanbiedingen van uw platformteam om deze voordelen uit te breiden naar uw workload zonder afbreuk te doen aan de SLO, beoogde hersteltijd (RTO) of RPO (Recovery Point Objective).

Zie Aanbevelingen voor meer informatie voor het verzamelen en controleren van kostengegevens.

Dit scenario implementeren

Een implementatie voor deze referentiearchitectuur is beschikbaar op GitHub.

Volgende stap

Bekijk de samenwerking en technische details die worden gedeeld tussen een workloadteam en platformteams.

Abonnementsverkoop