Maximaal beschikbare zone-redundante webtoepassing basislijn

Deze basislijnarchitectuur is gebaseerd op de basisarchitectuur voor webtoepassingen en breidt deze uit om gedetailleerde richtlijnen te bieden voor het ontwerpen van een beveiligde, zoneredundante en maximaal beschikbare webtoepassing in Azure. De architectuur maakt een openbaar eindpunt beschikbaar via Azure-toepassing Gateway met Web Application Firewall. Er worden aanvragen gerouteerd naar Azure-app Service via Private Link. De App Service-toepassing maakt gebruik van integratie van virtuele netwerken en Private Link om veilig te communiceren met Azure PaaS-services, zoals Azure Key Vault en Azure SQL Database.

Architectuur

Afbeelding 1: Basislijn Azure-app Service-architectuur

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

Veel onderdelen van deze architectuur zijn hetzelfde als de basisarchitectuur voor webtoepassingen. In de volgende lijst worden alleen de wijzigingen in de basisarchitectuur gemarkeerd.

• Application Gateway is een load balancer van laag 7 (HTTP/S) en Web Traffic Manager. Het maakt gebruik van op URL-pad gebaseerde routering om binnenkomend verkeer over beschikbaarheidszones te distribueren en versleuteling te offloads om de prestaties van toepassingen te verbeteren.
• Web Application Firewall (WAF) is een cloudeigen service die web-apps beschermt tegen veelvoorkomende aanvallen, zoals SQL-injectie en cross-site scripting. WAF biedt inzicht in het verkeer van en naar uw webtoepassing, zodat u uw toepassing kunt bewaken en beveiligen.
• Azure Key Vault is een service waarmee geheimen, versleutelingssleutels en certificaten veilig worden opgeslagen en beheerd. Het centraliseert het beheer van gevoelige informatie.
• Azure Virtual Network is een service waarmee u geïsoleerde en beveiligde virtuele netwerken in Azure kunt maken. Voor een webtoepassing in App Service hebt u een subnet van een virtueel netwerk nodig om privé-eindpunten te gebruiken voor netwerkbeveiliging tussen resources.
• Met Private Link kunnen clients rechtstreeks vanuit particuliere virtuele netwerken toegang krijgen tot PaaS-services (Platform as a Service) zonder openbare IP-adressen te gebruiken.
• Azure DNS is een hostingservice voor DNS-domeinen die naamomzetting biedt met behulp van de Microsoft Azure-infrastructuur. Privé-DNS zones bieden een manier om de FQDN (Fully Qualified Domain Name) van een service toe te wijzen aan het IP-adres van een privé-eindpunt.

Netwerken

Netwerkbeveiliging vormt de kern van de App Services-basislijnarchitectuur (zie afbeelding 2). Op hoog niveau zorgt de netwerkarchitectuur voor het volgende:

1. Eén beveiligd toegangspunt voor clientverkeer
2. Netwerkverkeer wordt gefilterd
3. Gegevens die onderweg zijn, worden end-to-end versleuteld met TLS
4. Gegevensexfiltratie wordt geminimaliseerd door verkeer in Azure te houden via het gebruik van Private Link
5. Netwerkbronnen worden logisch gegroepeerd en geïsoleerd van elkaar via netwerksegmentatie

Netwerkstromen

Afbeelding 2: Netwerkarchitectuur van de basislijn Azure-app Service-toepassing

Hier volgen beschrijvingen van de inkomende stroom van internetverkeer naar het App Service-exemplaar en de stroom van de App Service naar Azure-services.

Inkomende stroom

1. De gebruiker geeft een aanvraag uit voor het openbare IP-adres van Application Gateway.
2. De WAF-regels worden geëvalueerd. WAF-regels hebben een positieve invloed op de betrouwbaarheid van het systeem door bescherming te bieden tegen verschillende aanvallen, zoals XSS (Cross-Site Scripting) en SQL-injectie. Azure-toepassing Gateway retourneert een fout bij de aanvrager als een WAF-regel wordt geschonden en de verwerking stopt. Als er geen WAF-regels worden geschonden, stuurt Application Gateway de aanvraag naar de back-endpool, wat in dit geval het standaarddomein van App Service is.
3. De privé-DNS-zone privatelink.azurewebsites.net is gekoppeld aan het virtuele netwerk. De DNS-zone heeft een A-record waarmee het standaarddomein van App Service wordt toegewezen aan het privé-IP-adres van het privé-eindpunt van App Service. Met deze gekoppelde privé-DNS-zone kan Azure DNS het standaarddomein omzetten in het IP-adres van het privé-eindpunt.
4. De aanvraag wordt doorgestuurd naar een App Service-exemplaar via het privé-eindpunt.

App Service naar Azure PaaS-servicesstroom

1. App Service doet een aanvraag naar de DNS-naam van de vereiste Azure-service. De aanvraag kan zijn voor Azure Key Vault om een geheim op te halen, Azure Storage om een zip-bestand te publiceren, Azure SQL Database of een andere Azure-service die ondersteuning biedt voor Private Link. Met de functie voor integratie van virtuele netwerken van App Service wordt de aanvraag via het virtuele netwerk gerouteerd.
2. Net als stap 3 in de binnenkomende stroom heeft de gekoppelde privé-DNS-zone een A-record waarmee het domein van de Azure-service wordt toegewezen aan het privé-IP-adres van het privé-eindpunt. Nogmaals, met deze gekoppelde privé-DNS-zone kan Azure DNS het domein omzetten in het IP-adres van het privé-eindpunt van de service.
3. De aanvraag wordt doorgestuurd naar de service via het privé-eindpunt.

Inkomend verkeer naar App Services

Application Gateway is een regionale resource die voldoet aan de vereisten van deze basislijnarchitectuur. Application Gateway is een schaalbare, regionale, laag 7 load balancer die ondersteuning biedt voor functies zoals Web Application Firewall en TLS-offloading. Houd rekening met de volgende punten bij het implementeren van Application Gateway voor inkomend verkeer naar Azure-app Services.

• Implementeer Application Gateway en configureer een WAF-beleid met een door Microsoft beheerde regelset. Gebruik de preventiemodus om webaanvallen te beperken, waardoor een origin-service (App Service in de architectuur) niet meer beschikbaar is.
• End-to-end TLS-versleuteling implementeren.
• Gebruik privé-eindpunten om binnenkomende privétoegang tot uw App Service te implementeren.
• Overweeg om automatisch schalen voor Application Gateway te implementeren om zich gemakkelijk aan te passen aan dynamische verkeersstromen.
• Overweeg het gebruik van een minimumaantal exemplaren van de schaal van niet minder dan drie en gebruik altijd alle beschikbaarheidszones die uw regio ondersteunt. Hoewel Application Gateway op een maximaal beschikbare manier wordt geïmplementeerd, kan het maximaal zeven minuten duren voordat een nieuw exemplaar wordt gemaakt, zelfs voor een exemplaar met één schaal. Als u meerdere exemplaren in Beschikbaarheidszones implementeert, zorgt u ervoor dat er bij een fout een exemplaar wordt uitgevoerd terwijl er een nieuw exemplaar wordt gemaakt.
• Schakel openbare netwerktoegang in de App Service uit om netwerkisolatie te garanderen. In Bicep wordt dit bereikt door de instelling publicNetworkAccess: 'Disabled' onder properties/siteConfig.

Stromen van App Services naar Azure-services

Deze architectuur maakt gebruik van virtuele netwerkintegratie voor de App Service, met name om verkeer naar privé-eindpunten via het virtuele netwerk te routeren. Met de basislijnarchitectuur kan niet alle verkeersroutering al het uitgaande verkeer via het virtuele netwerk afdwingen, alleen intern verkeer, zoals verkeer dat is gebonden voor privé-eindpunten.

Voor Azure-services waarvoor geen toegang van het openbare internet is vereist, moeten privé-eindpunten zijn ingeschakeld en openbare eindpunten zijn uitgeschakeld. Privé-eindpunten worden in deze architectuur gebruikt om de beveiliging te verbeteren door uw App Service rechtstreeks vanuit uw particuliere virtuele netwerk verbinding te laten maken met Private Link-services zonder openbare IP-adressering te gebruiken.

In deze architectuur zijn alle openbare eindpunten uitgeschakeld voor Azure SQL Database, Azure Storage en Key Vault. Azure-servicefirewalls worden alleen gebruikt om verkeer van andere geautoriseerde Azure-services toe te staan. U moet andere Azure-services configureren met privé-eindpunten, zoals Azure Cosmos DB en Azure Redis Cache. In deze architectuur maakt Azure Monitor geen gebruik van een privé-eindpunt, maar wel.

De basislijnarchitectuur implementeert een privé-DNS-zone voor elke service. De privé-DNS-zone bevat een A-record die wordt toegewezen tussen de volledig gekwalificeerde domeinnaam van de service en het privé-eindpunt privé-IP-adres. De zones zijn gekoppeld aan het virtuele netwerk. Privé-DNS zonegroepen zorgen ervoor dat DNS-records van private link automatisch worden gemaakt en bijgewerkt.

Houd rekening met de volgende punten bij het implementeren van integratie van virtuele netwerken en privé-eindpunten.

• Gebruik de configuratierichtlijnen voor de DNS-zone van Azure-services voor het benoemen van privé-DNS-zones.
• Configureer servicefirewalls om ervoor te zorgen dat het opslagaccount, de sleutelkluis, SQL Database en andere Azure-services alleen privé kunnen worden verbonden.
  • Stel de standaardregel voor netwerktoegang van het opslagaccount in om al het verkeer te weigeren.
  • Key Vault inschakelen voor Private Link.
  • Openbare netwerktoegang tot Azure SQL weigeren.

Segmentatie en beveiliging van virtuele netwerken

Het netwerk in deze architectuur heeft afzonderlijke subnetten voor de Application Gateway- en App Service-integratieonderdelen en privé-eindpunten. Elk subnet heeft een netwerkbeveiligingsgroep die zowel inkomend als uitgaand verkeer voor deze subnetten beperkt tot alleen wat vereist is. In de volgende tabel ziet u een vereenvoudigde weergave van de NSG-regels die de basislijn toevoegt aan elk subnet. De tabel geeft de regelnaam en -functie.

Houd rekening met de volgende punten bij het implementeren van segmentatie en beveiliging van virtuele netwerken.

• Schakel DDoS-beveiliging in voor het virtuele netwerk met een subnet dat deel uitmaakt van een toepassingsgateway met een openbaar IP-adres.
• Voeg waar mogelijk een NSG toe aan elk subnet. U moet de strengste regels gebruiken die volledige oplossingsfunctionaliteit mogelijk maken.
• Gebruik toepassingsbeveiligingsgroepen. Met toepassingsbeveiligingsgroepen kunt u NSG's groeperen, waardoor het maken van regels eenvoudiger is voor complexe omgevingen.

Een voorbeeld van een virtueel subnetschema kan zijn:

Referentie voor Azure-Samples\app-service-baseline-implementation

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Overzicht van de betrouwbaarheidspijler voor meer informatie.

De App Services-basislijnarchitectuur is gericht op zonegebonden redundantie voor belangrijke regionale services. Beschikbaarheidszones zijn fysiek gescheiden locaties binnen een regio. Ze bieden zonegebonden redundantie voor ondersteunende services wanneer twee of meer exemplaren worden geïmplementeerd in ondersteunende regio's. Wanneer de ene zone downtime ondervindt, kunnen de andere zones nog steeds niet worden beïnvloed.

De architectuur zorgt er ook voor dat voldoende exemplaren van Azure-services voldoen aan de vraag. De volgende secties bieden richtlijnen voor betrouwbaarheid voor belangrijke services in de architectuur. Op deze manier kunt u met beschikbaarheidszones betrouwbaarheid bereiken door hoge beschikbaarheid en fouttolerantie te bieden.

Application Gateway

Implementeer Azure-toepassing Gateway v2 in een zone-redundante configuratie. Overweeg het gebruik van een minimumaantal exemplaren van de schaal van niet minder dan drie om de opstarttijd van zes tot zeven minuten te voorkomen voor een exemplaar van Application Gateway als er een fout optreedt.

App-services

• Implementeer minimaal drie exemplaren van App Services met ondersteuning voor beschikbaarheidszones.
• Implementeer statuscontrole-eindpunten in uw apps en configureer de app-Servicestatus controlefunctie om aanvragen om te leiden van beschadigde exemplaren. Zie App Service-exemplaren bewaken met behulp van statuscontrole voor meer informatie over App Service Health-controle. Zie Statuscontroles in ASP.NET Core voor meer informatie over het implementeren van statuscontrole-eindpunten in ASP.NET toepassingen.
• Capaciteit voor overprovision voor het afhandelen van zonefouten.

SQL Database

• Implementeer Azure SQL DB Algemeen gebruik, Premium of Bedrijfskritiek waarvoor zoneredundantie is ingeschakeld. De lagen Algemeen gebruik, Premium en Bedrijfskritiek ondersteunen zoneredundantie in Azure SQL DB.
• Configureer BACK-ups van SQL DB voor het gebruik van zone-redundante opslag (ZRS) of geografisch zone-redundante opslag (GZRS).

Blob-opslag

• Azure Zone-Redundant Storage (ZRS) repliceert uw gegevens synchroon over drie beschikbaarheidszones in de regio. Maak Standard ZRS- of Standard GZRS-opslagaccounts om ervoor te zorgen dat gegevens worden gerepliceerd in beschikbaarheidszones.
• Maak afzonderlijke opslagaccounts voor implementaties, webassets en andere gegevens, zodat u de accounts afzonderlijk kunt beheren en configureren.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.

In de volgende secties wordt de schaalbaarheid voor belangrijke onderdelen in deze architectuur besproken.

Application Gateway

• Implementeer automatisch schalen voor Application Gateway om in of uit te schalen om te voldoen aan de vraag.
• Stel het maximumaantal exemplaren in op een getal dat hoger is dan uw verwachte behoefte. Er worden alleen kosten in rekening gebracht voor de capaciteitseenheden die u gebruikt.
• Stel een minimumaantal exemplaren in dat kleine pieken in het verkeer kan verwerken. U kunt het gemiddelde gebruik van rekeneenheden gebruiken om het minimale aantal exemplaren te berekenen.
• Volg de richtlijnen voor het aanpassen van de grootte van het Application Gateway-subnet.

App Service

• Gebruik Standard- of hogere abonnementen met drie of meer werkrolexemplaren voor hoge beschikbaarheid.
• Schakel Automatische schaalaanpassing in om ervoor te zorgen dat u omhoog en omlaag kunt schalen om aan de vraag te voldoen.
• U kunt een ondersteuningsticket openen om het maximum aantal werknemers te verhogen tot twee keer het aantal exemplaren als uw App Service consistent de helft van het aantal exemplaren gebruikt. Het maximum aantal exemplaren is standaard ingesteld op maximaal 30 voor een Premium App Service-abonnement en 10 voor een Standard-abonnement.
• Overweeg om meerdere stempels van de toepassing te implementeren wanneer uw App Service de bovengrens bereikt.
• Kies het juiste Azure-app Service-plan dat voldoet aan uw workloadvereisten.
• Voeg Azure CDN toe aan Azure-app Service om statische inhoud te leveren.
• Overweeg App Service Environment als lawaaierige buren een probleem zijn.

SQL Server

Het schalen van databasebronnen is een complex onderwerp buiten het bereik van deze architectuur. Houd rekening met de volgende resources bij het schalen van uw database.

• Databasebronnen dynamisch schalen met minimale downtime
• Uitbreiden met Azure SQL Database
• Alleen-lezen replica's gebruiken om alleen-lezen queryworkloads te offloaden

Andere richtlijnen voor schaalbaarheid

• Bekijk abonnementslimieten en -quota om ervoor te zorgen dat services naar vraag worden geschaald.
• Overweeg caching voor de volgende soorten gegevens om de prestaties en schaalbaarheid te verbeteren:
  • Semi-statische transactiegegevens.
  • Sessiestatus.
  • HTML-uitvoer. Dit kan handig zijn in toepassingen die complexe HTML-uitvoer weergeven.

Beveiliging

De App Service-basislijnarchitectuur is gericht op essentiële beveiligingsaanaanveling voor uw web-app. Begrijpen hoe versleuteling en identiteit op elke laag werken, is essentieel voor het beveiligen van uw workload.

App Service

• Lokale verificatiemethoden uitschakelen voor FTP- en SCM-site-implementaties
• Schakel externe foutopsporing uit.
• Gebruik de nieuwste TLS-versie.
• Schakel Microsoft Defender voor App Service in.
• Gebruik de nieuwste versies van ondersteunde platforms, programmeertalen, protocollen en frameworks.
• Overweeg App Service Environment als u een hogere isolatie of beveiligde netwerktoegang nodig hebt.

Versleuteling

Een productieweb-app moet gegevens tijdens overdracht versleutelen met behulp van HTTPS. HTTPS-protocol is afhankelijk van Tls (Transport Layer Security) en maakt gebruik van openbare en persoonlijke sleutels voor versleuteling. U moet een certificaat (X.509) opslaan in Key Vault en de Application Gateway toestaan om de persoonlijke sleutel op te halen. Voor data-at-rest versleutelen sommige services automatisch gegevens en andere services kunt u aanpassen.

Actieve gegevens

In de basislijnarchitectuur worden gegevens die onderweg zijn versleuteld van de gebruiker naar de web-app in App Service. In de volgende werkstroom wordt beschreven hoe versleuteling op hoog niveau werkt.

1. De gebruiker verzendt een HTTPS-aanvraag naar de web-app.
2. De HTTPS-aanvraag bereikt de toepassingsgateway.
3. De toepassingsgateway maakt gebruik van een certificaat (X.509) in Key Vault om een beveiligde TLS-verbinding te maken met de webbrowser van de gebruiker. De toepassingsgateway ontsleutelt de HTTPS-aanvraag, zodat de webtoepassingsfirewall deze kan inspecteren.
4. De toepassingsgateway maakt een TLS-verbinding met App Service om de gebruikersaanvraag opnieuw te versleutelen. App Service biedt systeemeigen ondersteuning voor HTTPS, dus u hoeft geen certificaat toe te voegen aan App Service. De toepassingsgateway verzendt het versleutelde verkeer naar App Service. App Service ontsleutelt het verkeer en de web-app verwerkt de aanvraag.

Houd rekening met de volgende aanbevelingen bij het configureren van gegevens-in-transit-versleuteling.

• Maak of upload uw certificaat naar Key Vault. HTTPS-versleuteling vereist een certificaat (X.509). U hebt een certificaat van een vertrouwde certificeringsinstantie nodig voor uw aangepaste domein.
• Sla de persoonlijke sleutel op in het certificaat in Key Vault.
• Volg de richtlijnen in Machtigingen verlenen aan toepassingen voor toegang tot een Azure-sleutelkluis met behulp van Azure RBAC en beheerde identiteiten voor Azure-resources om Application Gateway toegang te bieden tot de persoonlijke sleutel van het certificaat. Gebruik geen Key Vault-toegangsbeleid om toegang te bieden. Met toegangsbeleid kunt u alleen uitgebreide machtigingen verlenen, niet alleen aan specifieke waarden.
• Schakel end-to-end-versleuteling in. App Service is de back-endpool voor de toepassingsgateway. Wanneer u de back-endinstelling voor de back-endpool configureert, gebruikt u het HTTPS-protocol via de back-endpoort 443.

Inactieve gegevens

• Versleutel gevoelige gegevens in Azure SQL Database met behulp van transparante gegevensversleuteling. Transparante gegevens versleutelen de volledige database, back-ups en transactielogboekbestanden en vereist geen wijzigingen in uw webtoepassing.
• Minimaliseer de latentie van databaseversleuteling. Als u de versleutelingslatentie wilt minimaliseren, plaatst u de gegevens die u in een eigen database moet beveiligen en schakelt u alleen versleuteling in voor die database.
• Krijg inzicht in ingebouwde versleutelingsondersteuning. Azure Storage versleutelt gegevens in rust automatisch met behulp van versleuteling aan de serverzijde (256-bits AES). Azure Monitor versleutelt data-at-rest automatisch met behulp van door Microsoft beheerde sleutels (MMK's).

Identiteits- en toegangsbeheer

De App Service-basislijn configureert verificatie en autorisatie voor gebruikersidentiteiten (gebruikers) en workloadidentiteiten (Azure-resources) en implementeert het principe van minimale bevoegdheden.

Gebruikersidentiteiten

• Gebruik het geïntegreerde verificatiemechanisme voor App Service ('EasyAuth'). EasyAuth vereenvoudigt het proces van het integreren van id-providers in uw web-app. Hiermee wordt verificatie buiten uw web-app verwerkt, zodat u geen belangrijke codewijzigingen hoeft aan te brengen.
• Configureer de antwoord-URL voor het aangepaste domein. U moet de web-app omleiden naar https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Vervang <application-gateway-endpoint> door het openbare IP-adres of de aangepaste domeinnaam die is gekoppeld aan uw toepassingsgateway. Vervang <provider> door de verificatieprovider die u gebruikt, zoals 'aad' voor Microsoft Entra-id. U kunt de Documentatie van Azure Front gebruiken om deze stroom in te stellen met Application Gateway of Application Gateway in te stellen.

Workloadidentiteiten

• Beheerde identiteit gebruiken voor workloadidentiteiten. Beheerde identiteit elimineert de noodzaak voor ontwikkelaars om verificatiereferenties te beheren.
• Gebruik door de gebruiker toegewezen beheerde identiteiten. Een door het systeem toegewezen identiteit kan ertoe leiden dat implementaties van infrastructuur als code mislukken op basis van racevoorwaarden en volgorde van bewerkingen. U kunt door de gebruiker toegewezen beheerde identiteiten gebruiken om een aantal van deze implementatiefoutscenario's te voorkomen. Zie Beheerde identiteiten voor meer informatie.

Operationele uitmuntendheid

Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.

Implementatie voor de App Service-basislijntoepassing volgt de richtlijnen in CI/CD voor Azure Web Apps met Azure Pipelines. Naast deze richtlijnen houdt de Architectuur van de App Services-basislijn rekening met het feit dat de toepassing en het implementatieopslagaccount netwerkbeveiliging hebben. De architectuur weigert openbare toegang tot App Service. Dit betekent dat u niet buiten het virtuele netwerk kunt implementeren. De basislijn laat zien hoe u de toepassingscode in het virtuele netwerk implementeert met behulp van zelf-hostende implementatieagents. De volgende implementatierichtlijnen zijn gericht op het implementeren van de toepassingscode en het niet implementeren van infrastructuur- of databasewijzigingen.

Afbeelding 3: Azure-app Service-toepassingen implementeren

Implementatiestroom

1. Als onderdeel van de release-pijplijn plaatst de pijplijn een taakaanvraag voor de zelf-hostende agents in de taakwachtrij. De taakaanvraag is dat de agent het buildartefact van het zip-bestand uploadt naar een Azure Storage-account.

2. De zelf-hostende implementatieagent haalt de nieuwe taakaanvraag op via polling. De taak en het build-artefact worden gedownload.

3. De zelf-hostende implementatieagent uploadt het zip-bestand naar het opslagaccount via het privé-eindpunt van het opslagaccount.

4. De pijplijn wordt voortgezet en een beheerde agent haalt een volgende taak op. De beheerde agent roept een CLI-aanroep uit om de appSetting-WEBSITE_RUN_FROM_PACKAGE bij te werken naar de naam van het nieuwe zip-bestand voor publiceren voor de staging-site.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. Azure-app Service haalt het nieuwe zip-bestand uit de opslag op via het privé-eindpunt van het opslagaccount. Het faseringsexemplaren worden opnieuw opgestart met het nieuwe pakket omdat WEBSITE_RUN_FROM_PACKAGE is ingesteld op een andere bestandsnaam.

6. De pijplijn hervat en voert eventuele betrouwbaarheidstests uit of wacht op goedkeuring. Als de tests zijn geslaagd of goedgekeurd, wisselt de pijplijn de faserings- en productiesites om.

Implementatierichtlijnen

Hieronder ziet u belangrijke implementatierichtlijnen voor de basislijnarchitectuur.

• Gebruik uitvoeren vanuit pakket om implementatieconflicten te voorkomen. Wanneer u uw app rechtstreeks vanuit een pakket uitvoert in Azure-app Service, worden de bestanden in het pakket niet gekopieerd naar de wwwroot-map. In plaats daarvan wordt het ZIP-pakket zelf rechtstreeks gekoppeld als de alleen-lezen wwwroot-map. Dit elimineert bestandsvergrendelingsconflicten tussen implementatie en runtime en zorgt ervoor dat alleen volledig geïmplementeerde apps op elk gewenst moment worden uitgevoerd
• Neem versienummers op in de zip-bestanden van het geïmplementeerde pakket. Als u appSetting WEBSITE_RUN_FROM_PACKAGE bijwerkt naar het implementatiepakket met een andere bestandsnaam, zorgt u ervoor dat App Services automatisch de nieuwe versie ophaalt en de service opnieuw start.
• Implementatiesites gebruiken voor flexibele code-implementaties.
• Overweeg het gebruik van een combinatie van beheerde en zelf-hostende agents.
  • Gebruik zelf-hostende agents om het zip-pakketbestand te uploaden naar het opslagaccount via het privé-eindpunt. De agent initieert communicatie met de pijplijn via polling , zodat het niet nodig is om het netwerk te openen voor een inkomende oproep.
  • Gebruik beheerde agents voor de andere taken in de pijplijn.
• Automatiseer infrastructuurimplementaties met Infrastructure as Code (IaC).
• Valideer continu de workload om de prestaties en tolerantie van de hele oplossing te testen met behulp van services zoals Azure Load Testing en Azure Chaos Studio.

Configuratie

Voor toepassingen zijn zowel configuratiewaarden als geheimen vereist. Gebruik de volgende richtlijnen voor configuratie- en geheimenbeheer.

• Controleer nooit geheimen zoals wachtwoorden of toegangssleutels in broncodebeheer.
• Gebruik Azure Key Vault om geheimen op te slaan.
• Gebruik App Service-configuratie voor de configuratie van uw toepassing. Als u de configuratie wilt externaliseren vanuit de configuratie van uw toepassing of ondersteuning van functievlagken nodig hebt, kunt u overwegen Azure-app Configuratie te gebruiken.
• Gebruik Key Vault-verwijzingen in de App Service-configuratie om geheimen veilig beschikbaar te maken in uw toepassing.
• Maak app-instellingen die zich aan een site houden en worden niet gewisseld als u andere productie- en faseringsinstellingen nodig hebt. Wanneer u een implementatiesite wisselt, worden de app-instellingen standaard ook gewisseld.
• Stel lokale omgevingsvariabelen in voor lokale ontwikkeling of profiteer van de functies van het toepassingsplatform. App Services-configuratie maakt app-instellingen beschikbaar als omgevingsvariabelen. Met Visual Studio kunt u bijvoorbeeld omgevingsvariabelen instellen in startprofielen. Hiermee kunt u ook app-instellingen en gebruikersgeheimen gebruiken om lokale toepassingsinstellingen en -geheimen op te slaan.

Controleren

Bewaking is het verzamelen en analyseren van gegevens van IT-systemen. Het doel van bewaking is waarneembaarheid op meerdere lagen om de status en beveiliging van web-apps bij te houden. Waarneembaarheid is een belangrijk facet van de App Service-basislijnarchitectuur.

Als u uw web-app wilt bewaken, moet u metrische gegevens en logboeken verzamelen en analyseren vanuit uw toepassingscode, infrastructuur (runtime) en het platform (Azure-resources). Zie het Activiteitenlogboek van Azure, Azure-resourcelogboeken en toepassingslogboeken voor meer informatie.

Het platform bewaken

Platformbewaking is het verzamelen van gegevens van de Azure-services in uw architectuur. Houd rekening met de volgende richtlijnen met betrekking tot platformbewaking.

• Voeg een diagnostische instelling toe voor elke Azure-resource. Elke Azure-service heeft een andere set logboeken en metrische gegevens die u kunt vastleggen. Gebruik de volgende tabel om de metrische gegevens en logboeken te achterhalen die u wilt verzamelen.

  Azure-resource	Beschrijvingen van metrische gegevens en logboeken
  Application Gateway	Beschrijvingen van metrische gegevens en logboeken van Application Gateway
  Web Application Firewall	Beschrijvingen van metrische gegevens en logboeken van Web Application Firewall
  App Service	Beschrijvingen van metrische gegevens en logboeken van App Service
  Azure SQL-database	Beschrijving van metrische gegevens en logboeken van Azure SQL Database
  Cosmos DB	Beschrijvingen van metrische gegevens en logboeken van Azure Cosmos DB
  Key Vault	Beschrijvingen van metrische gegevens en logboeken van Key Vault
  Blob Storage	Beschrijvingen van metrische gegevens en logboeken van Azure Blob Storage
  Analyses van toepassingen	Beschrijvingen van metrische gegevens en logboeken van Application Insights
  Openbaar IP-adres	Beschrijvingen van metrische gegevens en logboeken van openbaar IP-adres

• Inzicht in de kosten van het verzamelen van metrische gegevens en logboeken. Hoe meer metrische gegevens en logboeken u verzamelt, hoe meer het kost. Zie Log Analytics-kostenberekeningen en -opties en -prijzen voor de Log Analytics-werkruimte voor meer informatie.

• Waarschuwingen maken. U moet waarschuwingen maken voor alle Azure-resources in de architectuur en Acties configureren om problemen op te lossen. Kies algemene en aanbevolen waarschuwingsregels om te beginnen met en te wijzigen in de loop van de tijd, indien nodig. Zie voor meer informatie:

  • Overzicht van Azure Monitor-waarschuwingen
  • Application Gateway-waarschuwingen
  • App Service-waarschuwingen
  • Waarschuwingen voor Azure SQL Database
  • Blob Storage-waarschuwingen
  • Key Vault-waarschuwingen

Application Gateway

Application Gateway bewaakt de status van resources in de back-endpool. Gebruik de Application Gateway Access-logboeken om informatie te verzamelen, zoals de tijdstempel, de HTTP-antwoordcode en het URL-pad. Zie de standaardstatustest van Application Gateway en logboeken voor back-endstatus en diagnostische logboeken voor meer informatie.

App Service

App Service heeft ingebouwde en geïntegreerde bewakingshulpprogramma's die u moet inschakelen voor verbeterde waarneembaarheid. Als uw web-app al telemetrie- en bewakingsfuncties ('in-process instrumentatie') heeft, moet deze blijven werken aan App Service.

• Schakel automatische instrumentatie in. App Service heeft een instrumentatie-extensie die u zonder codewijzigingen kunt inschakelen. U krijgt inzicht in de prestaties van toepassingen (APM). Zie Prestaties van Azure-app service bewaken voor meer informatie.
• Schakel gedistribueerde tracering in. Automatische instrumentatie biedt een manier om gedistribueerde cloudsystemen te bewaken via gedistribueerde tracering en een prestatieprofielfunctie.
• Gebruik instrumentatie op basis van code voor aangepaste telemetrie. Azure-toepassing Insights biedt ook ondersteuning voor op code gebaseerde instrumentatie voor aangepaste toepassingstelemetrie. Voeg de Application Insights-SDK toe aan uw code en gebruik de Application Insights-API.
• Schakel App Service-logboeken in. Het App Service-platform ondersteunt vier extra logboeken die u moet inschakelen om probleemoplossing te ondersteunen. Deze logboeken zijn toepassingslogboeken, webserverlogboeken, gedetailleerde foutberichten en tracering van mislukte aanvragen.
• Gebruik gestructureerde logboekregistratie. Voeg een bibliotheek voor gestructureerde logboekregistratie toe aan uw toepassingscode. Werk uw code bij voor het gebruik van sleutel-waardeparen en schakel toepassingslogboeken in App Service in om deze logboeken op te slaan in uw Log Analytics-werkruimte.
• Schakel de App Service Health-controle in. Statuscontrole routeert aanvragen weg van beschadigde exemplaren en vervangt de beschadigde exemplaren. Uw App Service-plan moet twee of meer exemplaren gebruiken om statuscontroles te laten werken.

Database

• Inzichten in gebruikersdatabases. Voor Azure SQL-databases moet u SQL Insights configureren in Azure Monitor. Database Insights maakt gebruik van dynamische beheerweergaven om de gegevens weer te geven die u nodig hebt om de status te bewaken, problemen te diagnosticeren en de prestaties af te stemmen. Zie Azure SQL Database bewaken met Azure Monitor voor meer informatie.
• Als uw architectuur Cosmos DB bevat, hoeft u niets in te schakelen of te configureren voor het gebruik van Cosmos DB-inzichten.

Beheer

Web-apps profiteren van Azure Policy door beslissingen op het gebied van architectuur en beveiliging af te dwingen. Azure Policy kan het (1) onmogelijk maken om configuratiedrift te implementeren (weigeren) of (2) eenvoudig te detecteren (controle) configuratiedrift van de gewenste status. Dit helpt u infrastructuur als codeimplementaties (IaC) of wijzigingen in Azure Portal te ondervangen die afwijken van de overeengekomen architectuur. U moet alle resources in uw architectuur plaatsen onder Azure Policy-governance. Gebruik waar mogelijk ingebouwde beleidsregels of beleidsinitiatieven om essentiële netwerktopologie, servicefuncties, beveiliging en bewakingsbeslissingen af te dwingen, bijvoorbeeld:

• App Service moet openbare netwerktoegang uitschakelen
• App Service moet gebruikmaken van integratie van virtuele netwerken
• App Service moet Azure Private Link gebruiken om verbinding te maken met PaaS-services
• App Service moet lokale verificatiemethoden hebben uitgeschakeld voor FTP - en SCM-site-implementaties
• App Service moet externe foutopsporing hebben uitgeschakeld
• App Service-apps moeten de nieuwste TLS-versie gebruiken
• Microsoft Defender voor App Service moet zijn ingeschakeld
• Web Application Firewall (WAF) moet zijn ingeschakeld voor Application Gateway

Bekijk meer ingebouwde beleidsregels voor belangrijke services, zoals Application Gateway en netwerkonderdelen, App Service, Key Vault en Bewaking. Het is mogelijk om aangepaste beleidsregels te maken of communitybeleid (zoals van Azure Landing Zones) te gebruiken als ingebouwde beleidsregels niet volledig aan uw behoeften voldoen. Geef de voorkeur aan ingebouwde beleidsregels wanneer deze beschikbaar zijn.

Volgende stappen

Verwante resources

• Handleiding voor Private Link in Virtual WAN
• Een app omhoog schalen in Azure-app Service
• App Service migreren naar ondersteuning voor beschikbaarheidszones
• Application Gateway v2 en WAF v2 schalen