Bewerken

Maximaal beschikbare zone-redundante webtoepassing basislijn

Azure App Service
Azure Application Gateway
Azure Storage
Azure SQL Database
Azure Private Link
Azure Virtual Network
Azure Monitor

Dit artikel bevat een basislijnarchitectuur voor het uitvoeren van webtoepassingen in Azure-app Service in één regio. Het bevat richtlijnen voor het ontwerpen van een beveiligde, zone-redundante 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.

Belangrijk

GitHub-logo De richtlijnen worden ondersteund door een voorbeeld van een implementatie waarin een App Service-basislijn-implementatie in Azure wordt getoond. Deze implementatie kan worden gebruikt als basis voor verdere ontwikkeling van oplossingen in uw eerste stap naar productie.

Architectuur

Diagram met een App Service-basislijnarchitectuur met zonegebonden redundantie en hoge beschikbaarheid.

Afbeelding 1: Basislijn Azure-app Service-architectuur

Een Visio-bestand van deze architectuur downloaden.

Onderdelen

  • Microsoft Entra ID is een cloudservice voor identiteits- en toegangsbeheer. Het biedt één identiteitsbeheervlak voor het beheren van machtigingen en rollen voor gebruikers die toegang hebben tot uw webtoepassing. Het integreert met App Service en vereenvoudigt verificatie en autorisatie voor web-apps.
  • 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.
  • App Service is een volledig beheerd platform voor het bouwen, implementeren en schalen van webtoepassingen.
  • Azure Key Vault is een service waarmee geheimen, versleutelingssleutels en certificaten veilig worden opgeslagen en beheerd. Het centraliseert het beheer van gevoelige informatie.
  • Azure Monitor is een bewakingsservice die telemetriegegevens verzamelt, analyseert en uitvoert in uw implementatie.
  • Virtueel Azure-netwerk is een service waarmee u geïsoleerde en beveiligde virtuele privé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.
  • Azure SQL Database is een beheerde relationele databaseservice voor relationele gegevens.

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

Diagram met een App Service-basisnetwerkarchitectuur.

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.

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.

Subnet Inkomend Uitgaand
snet-AppGateway AppGw.In.Allow.ControlPlane: Toegang tot het binnenkomende besturingsvlak toestaan

AppGw.In.Allow443.Internet: Binnenkomende HTTPS-toegang tot internet toestaan		 AppGw.Out.Allow.AppServices: Uitgaande toegang tot AppServicesSubnet toestaan

AppGw.Out.Allow.PrivateEndpoints: Uitgaande toegang tot PrivateEndpointsSubnet toestaan

AppPlan.Out.Allow.AzureMonitor: Uitgaande toegang tot Azure Monitor toestaan
snet-PrivateEndpoints Standaardregels: inkomend verkeer vanuit een virtueel netwerk toestaan Standaardregels: uitgaand naar virtueel netwerk toestaan
snet-AppService Standaardregels: inkomend verkeer vanuit vnet toestaan AppPlan.Out.Allow.PrivateEndpoints: Uitgaande toegang tot PrivateEndpointsSubnet toestaan

AppPlan.Out.Allow.AzureMonitor: Uitgaande toegang tot Azure Monitor toestaan

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:

Type Naam Adresbereik
Virtual Network Adresvoorvoegsel 10.0.0.0/16
Subnet GatewaySubnet 10.0.1.0/24
Subnet AppServicesSubnet 10.0.0.0/24
Subnet PrivateEndpointsSubnet 10.0.2.0/27
Subnet AgentsSubject 10.0.2.32/27

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

Betrouwbaarheid

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

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.

Schaalbaarheid

Dankzij schaalbaarheid kunnen toepassingen toenames en afnames in de vraag verwerken en tegelijkertijd de prestaties en kosten optimaliseren. 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

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.

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.

Diagram met een App Service-versleutelingsstroom volgens basislijn.

  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.

Implementatie

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.

Diagram met een app Service-basislijnimplementatiearchitectuur.

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

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

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

Maximaal beschikbare webtoepassing voor meerdere regio's lezen