Azure Well-Architected Framework perspectief op Azure App Service (Web Apps)
Azure App Service is een PaaS (Platform as a Service) die een volledig beheerde hostingomgeving biedt voor het bouwen, implementeren en schalen van webtoepassingen. Als PaaS-oplossing abstraheert App Service de onderliggende infrastructuur, zodat u zich kunt richten op de ontwikkeling van uw toepassing. App Service (Web App) voert uw apps uit in de context van een App Service-plan, waarmee de resources, het besturingssysteem, de regio en het prijsmodel (SKU) worden bepaald die worden gebruikt om uw app te hosten.
In dit artikel wordt ervan uitgegaan dat u als architect de beslissingsstructuur hebt bekeken en App Service hebt gekozen als de berekening voor uw workload. De richtlijnen in dit artikel bevatten aanbevelingen voor architectuur die zijn toegewezen aan de principes van de Azure Well-Architected Framework-pijlers.
Belangrijk
Deze handleiding gebruiken
Elke sectie bevat een ontwerpcontrolelijst die architectuuroverwegingen en strategieën voor Azure App Service benadrukt. Aanbevelingen specifieke richtlijnen bieden voor het implementeren van deze strategieën.
De aanbevelingen vertegenwoordigen geen volledige lijst met alle configuraties die beschikbaar zijn voor de functie Web Apps van Azure App Service en hun afhankelijkheden. In plaats daarvan worden de belangrijkste aanbevelingen in kaart gebracht naar de ontwerpperspectieven. Gebruik de aanbevelingen om uw proof-of-concept te bouwen of uw bestaande omgevingen te optimaliseren.
Basisarchitectuur die de belangrijkste aanbevelingen demonstreert: App Service-basislijnarchitectuur.
technologieomvang
Deze beoordeling is gericht op de onderling gerelateerde beslissingen voor de volgende Azure-resources:
- App Service-abonnementen
- Web Apps
Andere Azure-aanbiedingen zijn gekoppeld aan App Service, zoals Azure Functions, Azure Logic Apps en App Service Environment. Deze aanbiedingen vallen buiten het bereik van dit artikel. Er wordt af en toe naar App Service Environment verwezen om functies of opties van de belangrijkste App Service-aanbiedingen te verduidelijken.
Betrouwbaarheid
Het doel van de pijler Betrouwbaarheid is om doorlopende functionaliteit te bieden door voldoende tolerantie te ontwikkelen en de mogelijkheid om snel te herstellen van storingen.
De ontwerpprincipes voor betrouwbaarheid bieden een ontwerpstrategie op hoog niveau die wordt toegepast op afzonderlijke onderdelen, systeemstromen en het systeem als geheel.
Controlelijst voor ontwerpen
Begin uw ontwerpstrategie op basis van de checklist voor de ontwerpbeoordeling en betrouwbaarheid. Bepaal de relevantie ervan voor uw bedrijfsvereisten en houd daarbij rekening met de lagen en functies van App Service en de bijbehorende afhankelijkheden. Breid de strategie uit om zo nodig meer benaderingen op te nemen.
Prioriteit geven aan gebruikersstromen: niet alle stromen zijn even kritiek. Identificeer de kritieke paden in uw toepassing en wijs prioriteiten toe aan elke stroom om uw ontwerpbeslissingen te begeleiden. Het ontwerp van gebruikersstromen kan van invloed zijn op de servicelagen en het aantal exemplaren dat u kiest voor een App Service-plan en -configuratie.
Uw toepassing kan bijvoorbeeld front-end- en back-endlagen bevatten die communiceren via een berichtenbroker. U kunt ervoor kiezen om de lagen in meerdere web-apps te segmenteren om onafhankelijk schalen, levenscyclusbeheer en onderhoud mogelijk te maken. Het plaatsen van een grote toepassing in één plan kan leiden tot geheugen- of CPU-problemen en kan de betrouwbaarheid beïnvloeden.
Mogelijk hebt u meer exemplaren aan de front-end nodig voor optimale prestaties aan de gebruikersinterfacezijde. De back-end vereist mogelijk echter niet hetzelfde aantal instanties.
Mogelijke mislukkingen: Plan mitigatiestrategieën voor mogelijke mislukkingen. In de volgende tabel ziet u voorbeelden van analyse van foutmodus.
Falen Mitigatie Fout in onderliggende of abstracte App Service-onderdelen Redundantie van onderdelen in instellingen en afhankelijkheden hebben. Controleer de status van exemplaren, netwerkprestaties en opslagprestaties. Uitval van externe afhankelijkheden Gebruik ontwerppatronen zoals het patroon Opnieuw Proberen en het patroon Circuitonderbreker. Controleer de externe afhankelijkheden en stel de juiste time-outs in. Fout vanwege verkeer dat naar niet-functionerende instances wordt gestuurd. Controleer de status van de instantie. Overweeg de reactiesnelheid en vermijd het verzenden van aanvragen naar beschadigde exemplaren. Zie Analyse van foutmodus voor Azure-toepassingenvoor meer informatie.
Implementeren van redundantie: Implementeren van redundantie in de applicatie en ondersteunende infrastructuur. Verspreid instanties over beschikbaarheidszones om fouttolerantie te verbeteren. Verkeer wordt doorgestuurd naar andere zones als één zone uitvalt. Implementeer uw toepassing in meerdere regio's om ervoor te zorgen dat uw app beschikbaar blijft, zelfs als een hele regio een storing ondervindt.
Bouw vergelijkbare redundantieniveaus in afhankelijke services. Applicatie-instanties binden bijvoorbeeld aan blobopslag. Overweeg om het gekoppelde opslagaccount te configureren met zone-redundante opslag (ZRS) als een toepassing gebruikmaakt van een zone-redundante implementatie.
Meerdere exemplaren gebruiken: Het uitvoeren van uw app op slechts één exemplaar is een direct enkel storingspunt. Wijs meerdere exemplaren toe aan uw app om hoge beschikbaarheid te garanderen. Als het ene exemplaar mislukt, kunnen andere exemplaren nog steeds binnenkomende aanvragen verwerken. Houd er rekening mee dat uw app-code meerdere exemplaren moet kunnen verwerken zonder synchronisatieproblemen bij het lezen van of schrijven naar gegevensbronnen.
Redundantie hebben in netwerkonderdelen. Gebruik bijvoorbeeld zone-redundante IP-adressen en load balancers.
Een betrouwbare schaalstrategie hebben: onverwachte belasting voor een toepassing kan dit onbetrouwbaar maken. Overweeg de juiste schaalbenadering op basis van uw workloadkenmerken. Met horizontaal schalen (uitschalen) kunt u meer exemplaren toevoegen om de belasting te verdelen, terwijl verticaal schalen (omhoog schalen) de capaciteit van een bestaand exemplaar (CPU, geheugen) verhoogt. Wees voorzichtig met overprovisioning, omdat het toevoegen van onnodige instanties, de kosten verhoogt zonder tastbare prestatievoordelen.
Soms kunt u opschalen om de belasting aan te kunnen. Als de belasting echter blijft toenemen, schaalt u uit naar nieuwe instanties. Geef de voorkeur aan automatisch of autoschalen boven handmatige benaderingen. Houd altijd een buffer van extra capaciteit bij tijdens schaalbewerkingen om prestatievermindering te voorkomen[Optie voor schalen voor App Service kiezen](Automatisch schalen in Azure App Service)
De App Service-planlaag die u kiest, is van invloed op het schalen in termen van het aantal exemplaren en de rekeneenheden.
Zorg voor de juiste initialisatie van apps, zodat nieuwe exemplaren snel worden opgewarmd en aanvragen kunnen ontvangen.
Streven naar staatloze toepassingen waar mogelijk. Het betrouwbaar schalen van de toestand met behulp van nieuwe exemplaren kan de complexiteit vergroten. Overweeg een extern gegevensarchief dat u onafhankelijk kunt schalen als u de toepassingsstatus wilt opslaan. Het opslaan van de sessiestatus in het geheugen kan leiden tot verlies van sessiestatus wanneer er een probleem is met de toepassing of App Service. Het beperkt ook de mogelijkheid om de belasting over andere instanties te spreiden.
Test regelmatig uw regels voor automatisch schalen. Simuleer laadscenario's om te controleren of uw app naar verwachting wordt geschaald. U moet schaalgebeurtenissen vastleggen, zodat u problemen kunt oplossen die zich kunnen voordoen en uw schaalstrategie in de loop van de tijd kunt optimaliseren.
App Service heeft een beperking op het aantal instanties binnen een plan, wat de betrouwbaarheid van schaalbaarheid kan beïnvloeden. Eén strategie is het gebruik van identieke implementatie-stempels, elk met een actief App Service-plan-exemplaar en een eigen eindpunt. Het is essentieel dat u alle servers met een externe load balancer gebruikt om het verkeer over deze servers te verdelen. Gebruik Azure Application Gateway voor implementaties met één zone en Azure Front Door voor implementaties in meerdere regio's. Deze benadering is ideaal voor bedrijfskritieke toepassingen waarbij betrouwbaarheid cruciaal is. Zie Bedrijfskritieke basislijn met App Servicevoor meer informatie.
uw herstelmogelijkheden plannen: Redundantie is van cruciaal belang voor bedrijfscontinuïteit. Schakel over naar een ander exemplaar als één exemplaar onbereikbaar is. Verken automatische herstelmogelijkheden in App Service, zoals het automatisch herstellen van exemplaren.
Implementeer ontwerppatronen voor het afhandelen van respijtieve degradatie voor zowel tijdelijke fouten, zoals problemen met de netwerkverbinding en grootschalige gebeurtenissen zoals regionale storingen. Houd rekening met de volgende ontwerppatronen:
Het schotpatroon segmenteert uw toepassing in geïsoleerde groepen om te voorkomen dat een storing van invloed is op het hele systeem.
Het patroon load leveling Queue-Based wachtrijen werken items die fungeren als buffer om pieken in het verkeer te vereffenen.
Het Opnieuw proberen-patroon handelt tijdelijke fouten af door netwerkstoringen, verbroken databaseverbindingen of bezet diensten.
Het circuitonderbrekerpatroon voorkomt dat een toepassing herhaaldelijk probeert een bewerking uit te voeren die waarschijnlijk mislukt.
U kunt WebJobs gebruiken om achtergrondtaken uit te voeren in uw web-app. Als u deze taken betrouwbaar wilt uitvoeren, moet u ervoor zorgen dat de app die als host fungeert voor uw taak continu wordt uitgevoerd volgens een planning of op basis van gebeurtenisgestuurde triggers.
Zie betrouwbaarheidspatronenvoor meer informatie.
voer betrouwbaarheidstests uit: voer belastingstests uit om de betrouwbaarheid en prestaties van uw toepassing onder belasting te evalueren. Testplannen moeten scenario's bevatten waarmee uw geautomatiseerde herstelbewerkingen worden gevalideerd.
Gebruik foutinjectie om opzettelijk fouten te introduceren en uw zelfherstel- en zelfbehoudmechanismen te valideren. Ontdek de foutbibliotheek van Azure Chaos Studio.
App Service legt resourcelimieten op voor gehoste apps. Het App Service-plan bepaalt deze limieten. Zorg ervoor dat uw tests bevestigen dat de app binnen deze resourcelimieten wordt uitgevoerd. Zie Azure-abonnements- en servicelimieten, quota en beperkingenvoor meer informatie.
De functie Statuscontrole gebruiken om niet-reagerende werknemers te identificeren: App Service heeft ingebouwde mogelijkheden die periodiek een specifiek pad van uw webtoepassing pingen. Het platform pingt dit pad om te bepalen of uw toepassing in orde is en reageert op aanvragen. Wanneer uw site wordt uitgeschaald naar meerdere exemplaren, sluit App Service alle beschadigde exemplaren uit van het leveren van aanvragen, waardoor uw algehele beschikbaarheid wordt verbeterd. Het pad van de statuscontrole van uw app moet de kritieke onderdelen van uw toepassing controleren, zoals uw database, cache of berichtenservice. Dit zorgt ervoor dat de status die wordt geretourneerd door het pad voor de statuscontrole een nauwkeurig beeld is van de algehele status van uw toepassing. Stel uw gezondheidscontrolepad in
De functie Automatisch herstellen gebruiken: soms ondervindt uw toepassing onverwacht gedrag dat kan worden opgelost door een eenvoudige herstart. Met de functies voor automatisch herstellen kunt u een 'voorwaarde' definiëren die Automatisch herstellen activeert en de actie die automatisch herstellen start wanneer aan de voorwaarde wordt voldaan. Diagnostische hulpmiddelen en de Auto-Heal-functie van App Service
App Service Resiliency Score Report: Raadpleeg het rapport Tolerantiescore om aanbevelingen op maat te bekijken.App Service Resiliency Score Report
Aanbevelingen
Aanbeveling | Voordeel |
---|---|
(App Service) Kies de Premium v3-laag van een App Service-plan voor productieworkloads. Stel het maximum- en minimumaantal werknemers in op basis van uw capaciteitsplanning. Zie App Service-planoverzichtvoor meer informatie. |
Een Premium V3 App Service-plan biedt geavanceerde schaalfuncties en zorgt voor redundantie als er fouten optreden. |
(App Service) zoneredundantie inschakelen. Overweeg om meer dan drie instanties in te richten om de fouttolerantie te verhogen. Controleer de regionale ondersteuning voor zoneredundantie omdat niet alle regio's deze functie bieden. |
Uw toepassing kan bestand zijn tegen storingen in één zone wanneer meerdere exemplaren verspreid zijn over zones. Verkeer wordt automatisch verplaatst naar gezonde exemplaren in andere zones en onderhoudt de betrouwbaarheid van toepassingen als één zone niet beschikbaar is. |
(Web-app) Overweeg de functie ARR-affiniteit (Application Request Routing) uit te schakelen. Met ARR-affiniteit worden plaksessies gemaakt waarmee gebruikers worden omgeleid naar het knooppunt dat hun vorige aanvragen heeft verwerkt. | Binnenkomende aanvragen worden gelijkmatig verdeeld over alle beschikbare knooppunten wanneer u ARR-affiniteit uitschakelt. Gelijkmatig gedistribueerde aanvragen voorkomen dat verkeer een willekeurig knooppunt overweldigt. Aanvragen kunnen naadloos worden omgeleid naar andere knooppunten die in orde zijn als een knooppunt niet beschikbaar is. Vermijd sessieaffiniteit om ervoor te zorgen dat uw App Service-instantie stateless blijft. Een stateless App Service vermindert de complexiteit en zorgt voor consistent gedrag tussen knooppunten. Verwijder plaksessies zodat App Service exemplaren kan toevoegen of verwijderen om horizontaal te schalen. |
(Web App) definieer automatische herstelregels op basis van het aantal aanvragen, trage aanvragen, geheugenlimieten en andere indicatoren die deel uitmaken van uw prestatiebasislijn. Overweeg deze configuratie als onderdeel van uw schaalstrategie. | Met automatische herstelregels kunt u uw toepassing automatisch herstellen na onverwachte problemen. De geconfigureerde regels activeren herstelacties wanneer drempelwaarden worden overschreden. Automatische genezing maakt automatisch proactief onderhoud mogelijk. |
(Web App) de statuscontrolefunctie inschakelen en een pad opgeven dat reageert op de statuscontroleaanvragen. | Gezondheidscontroles kunnen problemen vroegtijdig detecteren. Vervolgens kan het systeem automatisch corrigerende acties ondernemen wanneer een statuscontroleaanvraag mislukt. De load balancer routeert verkeer weg van ongezonde instanties, waardoor gebruikers worden doorgestuurd naar gezonde knooppunten. |
Veiligheid
Het doel van de pijler Beveiliging is het bieden van vertrouwelijkheid, integriteit en beschikbaarheid garanties voor de workload.
De Beginselen voor beveiligingsontwerp een ontwerpstrategie op hoog niveau bieden voor het bereiken van deze doelstellingen door benaderingen toe te passen op het technische ontwerp rond hosting op App Service.
Controlelijst voor ontwerpen
Begin uw ontwerpstrategie op basis van de checklijst voor ontwerpbeoordeling voor Beveiliging en identificeer kwetsbaarheden en maatregelen om de beveiligingshouding te verbeteren. Breid de strategie uit om zo nodig meer benaderingen op te nemen.
Beveiligingsbasislijnen controleren: als u de beveiligingspostuur van uw toepassing wilt verbeteren die wordt gehost in een App Service-plan, controleert u de beveiligingsbasislijn voor App Service-.
Gebruik de nieuwste runtime en bibliotheken: test de builds van uw toepassing grondig voordat u updates uitvoert om problemen vroeg te ondervangen en een soepele overgang naar de nieuwe versie te garanderen. App Service ondersteunt het taalruntimebeleid voor ondersteuning voor het bijwerken van bestaande stacks en het buiten gebruik stellen van stacks die het einde van hun ondersteuning hebben bereikt.
Stel segmentatie op via isolatiegrenzen om inbreuken te beheersen: Pas identiteitssegmentatie toe. Implementeer bijvoorbeeld op rollen gebaseerd toegangsbeheer (RBAC) om specifieke machtigingen toe te wijzen op basis van rollen. Volg het principe van minimale bevoegdheid om toegangsrechten te beperken tot alleen wat nodig is. Maak ook segmentatie op netwerkniveau. InjectEer App Service-apps in een virtueel Azure-netwerk voor isolatie en definieer netwerkbeveiligingsgroepen (NSG's) om verkeer te filteren.
App Service-plannen bieden de App Service Environment-laag die een hoge mate van isolatie biedt. Met App Service Environment krijgt u toegewezen rekenkracht en netwerken.
Toegangsbeheer toepassen op identiteiten: beperk zowel de toegang tot de web-app als de uitgaande toegang van de web-app naar andere resources. Met deze configuratie worden toegangsbeheer toegepast op identiteiten en wordt de algehele beveiligingspostuur van de workload gehandhaafd.
Gebruik Microsoft Entra ID voor alle verificatie- en autorisatiebehoeften. Ingebouwde rollen gebruiken, zoals een Inzender voor webplannen, inzender voor websitesen een algemene inzender, lezer en eigenaar.
Netwerkbeveiligingsbesturingselementen toepassen: Integreer uw App Service met een virtueel netwerk (VNet) om het uitgaande verkeer te beheren. Gebruik privé-eindpunten om het binnenkomende verkeer te beheren en om de toegang tot uw App Service vanuit uw VNet te beperken en openbare internettoegang uit te schakelen. Uw netwerk beveiligen, binnenkomend en uitgaand verkeer beheren
Implementeer een WAF (Web Application Firewall) om te beschermen tegen veelvoorkomende beveiligingsproblemen. Zowel Application Gateway als Azure Front Door hebben geïntegreerde WAF-mogelijkheden.
Configureer de omgekeerde proxyregels en netwerkinstellingen op de juiste manier om het gewenste beveiligings- en beheerniveau te bereiken. Voeg bijvoorbeeld NSG-regels toe aan het subnet van het privé-eindpunt om alleen verkeer van de omgekeerde proxy te accepteren.
Uitgaand verkeer van de toepassing naar andere PaaS-services moet via privé-eindpunten zijn. Overweeg om een firewallonderdeel te plaatsen om uitgaand verkeer naar het openbare internet te beperken. Beide benaderingen voorkomen exfiltratie van gegevens.
Zie App Service-netwerkfunctiesvoor een uitgebreide weergave.
Gegevens versleutelen: gegevens in transit beveiligen met end-to-end Tls (Transport Layer Security). Gebruik uw door de klant beheerde sleutels voor volledige versleuteling van gegevens in rust. Voor meer informatie, zie Versleuteling bij rust met door de klant beheerde sleutels.
Gebruik geen verouderde protocollen zoals TLS 1.0 en 1.1. Zorg ervoor dat alle web-apps alleen HTTPS gebruiken en TLS 1.2 of hoger afdwingen. De minimale TLS-standaardversie is 1.2. Zie Overzicht van App Service TLSvoor meer informatie.
Alle exemplaren van uw App Service hebben een standaarddomeinnaam. Gebruik een aangepast domein en beveilig dat domein met certificaten.
end-to-end TLS-versleuteling: End-to-end TLS-versleuteling is beschikbaar in Premium App Service-abonnementen. Deze functie versleutelt uw verkeer gedurende de hele transactie, waardoor het risico op het onderscheppen van verkeer wordt geminimaliseerd.
Verminder de kwetsbaarheid voor aanvallen: verwijder standaardconfiguraties die u niet nodig hebt. Schakel bijvoorbeeld externe foutopsporing, lokale verificatie voor SCM-sites (Source Control Manager) en basisverificatie uit. Schakel onbeveiligde protocollen zoals HTTP en File Transfer Protocol (FTP) uit. Dwing configuraties af via Azure-beleid. Zie Azure-beleidvoor meer informatie.
CorS-beleid (Cross-Origin Resource Sharing) implementeren: Gebruik beperkende CORS-beleidsregels in uw web-app om alleen aanvragen van de toegestane domeinen, headers en andere criteria te accepteren. CORS-beleid afdwingen met ingebouwde Azure-beleidsdefinities.
Beheerde identiteiten gebruiken: schakel beheerde identiteiten in voor uw App Service om veilig toegang te krijgen tot andere Azure-services zonder referenties te hoeven beheren. Meer informatie over beheerde identiteiten.
Toepassingsgeheimen beveiligen: u moet gevoelige informatie afhandelen, zoals API-sleutels of verificatietokens. In plaats van deze geheimen rechtstreeks te coderen in uw toepassingscode of configuratiebestanden, kunt u Azure Key Vault-verwijzingen gebruiken in app-instellingen. Wanneer de toepassing wordt gestart, haalt App Service automatisch de geheime waarden op uit Key Vault met behulp van de beheerde identiteit van de app.
Resourcelogboeken inschakelen voor uw toepassing: schakel resourcelogboeken voor uw toepassing in om uitgebreide activiteitentrails te maken die waardevolle gegevens bieden tijdens onderzoeken die beveiligingsincidenten volgen. Zie de richtlijnen voor logboekbewaking voor gedetailleerde richtlijnen.
Overweeg logboekregistratie als onderdeel van uw threat modeling-proces wanneer u bedreigingen evalueert.
Aanbevelingen
Aanbeveling | Voordeel |
---|---|
(Web-app) beheerde identiteiten toewijzen aan de web-app. Als u isolatiegrenzen wilt behouden, moet u identiteiten niet delen of hergebruiken tussen toepassingen. Zorg ervoor dat u veilig verbinding met uw containerregister als u containers voor uw implementatie gebruikt. |
De toepassing haalt geheimen op uit Key Vault om uitgaande communicatie van de toepassing te verifiëren. Azure beheert de identiteit en vereist niet dat u geheimen inricht of roteert. U hebt verschillende identiteiten voor granulariteit van controle. Afzonderlijke identiteiten maken het intrekken eenvoudig als een identiteit wordt aangetast. |
(Web App) Configureer aangepaste domeinen voor applicaties. Schakel HTTP uit en accepteer alleen HTTPS-aanvragen. |
Aangepaste domeinen maken beveiligde communicatie mogelijk via HTTPS met behulp van TLS-protocol (Transport Layer Security), wat de beveiliging van gevoelige gegevens garandeert en gebruikersvertrouwen bouwt. |
(Web App) geef aan of ingebouwde App Service-verificatie het juiste mechanisme is om gebruikers te verifiëren die toegang hebben tot uw toepassing. Ingebouwde App Service-verificatie kan worden geïntegreerd met Microsoft Entra ID. Deze functie verwerkt tokenvalidatie en gebruikersidentiteitsbeheer voor meerdere aanmeldingsproviders en ondersteunt OpenID Connect. Met deze functie hebt u geen autorisatie op gedetailleerd niveau en hebt u geen mechanisme om verificatie te testen. | Wanneer u deze functie gebruikt, hoeft u geen verificatiebibliotheken te gebruiken in toepassingscode, wat de complexiteit vermindert. De gebruiker wordt al geverifieerd wanneer een aanvraag de toepassing bereikt. |
(Web-app) Configureer de toepassing voor virtuele netwerkintegratie. Gebruik privé-eindpunten voor App Service-apps. Alle openbare verkeer blokkeren. Routeer de containerimage via de integratie van het virtuele netwerk. Alle uitgaand verkeer van de toepassing passeert door het virtuele netwerk. |
Profiteer van de beveiligingsvoordelen van het gebruik van een virtueel Azure-netwerk. De toepassing heeft bijvoorbeeld veilig toegang tot resources binnen het netwerk. Voeg een privé-eindpunt toe om uw toepassing te beveiligen. Privé-eindpunten beperken directe blootstelling aan het openbare netwerk en bieden gecontroleerde toegang via de omgekeerde proxy. |
(Web App) Om hardening te implementeren: - basisverificatie uitschakelen die een gebruikersnaam en wachtwoord gebruiken ten gunste van verificatie op basis van Microsoft Entra ID. - Schakel externe foutopsporing uit zodat binnenkomende poorten niet worden geopend. - Schakel CORS-beleid in om binnenkomende verzoeken strenger te maken. - Protocollen uitschakelen, zoals FTP-. |
We raden basisverificatie niet aan als een veilige implementatiemethode. Microsoft Entra ID maakt gebruik van verificatie op basis van OAuth 2.0-tokens. Dit biedt talloze voordelen en verbeteringen die betrekking hebben op de beperkingen die zijn gekoppeld aan basisverificatie. Beleid beperkt de toegang tot toepassingsbronnen, staat alleen aanvragen van specifieke domeinen toe en beveiligt aanvragen tussen regio's. |
(Web-app) Gebruik altijd Key Vault-verwijzingen als app-instellingen. |
Geheimen worden gescheiden gehouden van de configuratie van uw app. App-instellingen worden in rust versleuteld. App Service beheert ook geheime rotaties. |
(App Service) Microsoft Defender for Cloud for App Serviceinschakelen. | Realtime-beveiliging krijgen voor resources die worden uitgevoerd in een App Service-plan. Bescherm bedreigingen en verbeter uw algehele beveiligingspostuur. |
(App Service) diagnostische logboekregistratie inschakelen en instrumentatie toevoegen aan uw app. De logboeken worden verzonden naar Azure Storage-accounts, Azure Event Hubs en Log Analytics. Zie Ondersteunde logboektypenvoor meer informatie over typen auditlogboeken. | Logboekregistratie legt toegangspatronen vast. Het registreert relevante gebeurtenissen die waardevolle inzichten bieden in de manier waarop gebruikers met een toepassing of platform communiceren. Deze informatie is van cruciaal belang voor verantwoordelijkheid, naleving en beveiligingsdoeleinden. |
Kostenoptimalisatie
Kostenoptimalisatie richt zich op het detecteren van uitgavenpatronen, het prioriteren van investeringen in kritieke gebieden en het optimaliseren van andere gebieden om aan het budget van de organisatie te voldoen terwijl aan de bedrijfsvereisten wordt voldaan.
De ontwerpprincipes voor Cost Optimization een ontwerpstrategie op hoog niveau bieden om deze doelen te bereiken en zo nodig compromissen te maken in het technische ontwerp met betrekking tot uw web-apps en de omgeving waarin ze worden uitgevoerd.
Controlelijst voor ontwerpen
Begin uw ontwerpstrategie op basis van de ontwerpbeoordeling controlelijst voor kostenoptimalisatie bij investeringen en verfijn het ontwerp zodat de workload afgestemd is op het budget dat voor de workload is toegewezen. Uw ontwerp moet gebruikmaken van de juiste Azure-mogelijkheden, investeringen bewaken en mogelijkheden vinden om in de loop van de tijd te optimaliseren.
Schatting van de initiële kosten: als onderdeel van uw oefening voor kostenmodellering gebruikt u de Azure-prijscalculator om de geschatte kosten te evalueren die zijn gekoppeld aan verschillende lagen op basis van het aantal exemplaren dat u wilt uitvoeren. Elke App Service-laag biedt verschillende rekenopties.
Bewaak continu het kostenmodel om uitgaven bij te houden.
Evalueer de opties met korting: hogere lagen omvatten toegewezen rekeninstanties. U kunt een reserveringskorting toepassen als uw workload een voorspelbaar en consistent gebruikspatroon heeft. Zorg ervoor dat u gebruiksgegevens analyseert om het type reservering te bepalen dat bij uw workload past. Zie Kosten besparen met gereserveerde instanties van App Servicevoor meer informatie.
Inzicht in de gebruiksmeters: Azure brengt een uurtarief in rekening, naar rato van het tweede, op basis van de prijscategorie van uw App Service-plan. Kosten zijn van toepassing op elke uitgeschaalde instantie in uw abonnement, op basis van de tijd waarop u het VM-exemplaar toewijst. Let op onderbenutte rekenresources die uw kosten kunnen verhogen door overbezetting door suboptimale SKU-selectie of slecht geconfigureerde inschaling.
Extra App Service-functies, zoals registratie van aangepaste domeinen en aangepaste certificaten, kunnen kosten toevoegen. Andere resources, zoals virtuele netwerken om uw oplossing te isoleren of sleutelkluizen om workloadgeheimen te beveiligen, die geïntegreerd kunnen worden met uw App Service-resources, kunnen ook kosten met zich meebrengen. Zie App Services-factureringsmodelvoor meer informatie.
Houd rekening met de afwegingen tussen dichtheid en isolatie: u kunt App Service-plannen gebruiken om meerdere toepassingen op dezelfde berekening te hosten, waardoor kosten worden bespaard met gedeelde omgevingen. Zie Tradeoffsvoor meer informatie.
Evalueer het effect van uw schaalstrategie op kosten: u moet op de juiste manier ontwerpen, testen en configureren voor uitschalen en voor inschalen wanneer u automatische schaalaanpassing implementeert. Stel nauwkeurige maximum- en minimumlimieten in voor automatisch schalen.
Initialiseer de toepassing proactief voor betrouwbare schaalaanpassing. Wacht bijvoorbeeld niet totdat het CPU-gebruik 95% bereikt. In plaats daarvan activeert u schalen op ongeveer 65% om voldoende tijd te bieden voor het toewijzen en initialiseren van nieuwe exemplaren tijdens het schaalproces. Deze strategie kan echter leiden tot ongebruikte capaciteit.
We raden u aan mechanismen voor omhoog schalen en uitschalen te combineren en te verdelen. Een app kan bijvoorbeeld enige tijd omhoog schalen en zo nodig uitschalen. Verken hoge lagen die grote capaciteit en efficiënt resourcegebruik bieden. Op basis van gebruikspatronen zijn hogere Premium-lagen vaak rendabeler omdat ze beter geschikt zijn.
Omgevingskosten optimaliseren: Overweeg de basic- of gratis laag om preproductieomgevingen uit te voeren. Deze lagen zijn lage prestaties en lage kosten. Als u de basic- of gratis laag gebruikt, gebruikt u governance om de laag af te dwingen, het aantal exemplaren en CPU's te beperken, het schalen te beperken en logboekretentie te beperken.
Ontwerppatronen implementeren: Met deze strategie vermindert u het aantal aanvragen dat uw workload genereert. Overweeg patronen zoals het patroon Back-ends voor front-ends te gebruiken en het patroon Gatewayaggregatie, waardoor het aantal aanvragen kan worden geminimaliseerd en de kosten kunnen worden verlaagd.
Regelmatig gegevensgerelateerde kosten controleren: uitgebreide gegevensretentieperioden of dure opslaglagen kunnen leiden tot hoge opslagkosten. Meer uitgaven kunnen zich verzamelen vanwege zowel bandbreedtegebruik als langdurige retentie van logboekgegevens.
Overweeg om caching te implementeren om de kosten voor gegevensoverdracht te minimaliseren. Begin met lokale cacheopslag in het geheugen en verken vervolgens gedistribueerde cacheopties om het aantal aanvragen voor de back-enddatabase te verminderen. Houd rekening met de bandbreedteverkeerskosten die zijn gekoppeld aan communicatie tussen regio's als uw database zich in een andere regio bevindt.
Implementatiekosten optimaliseren: profiteer van implementatiesites om de kosten te optimaliseren. Het slot draait in dezelfde rekenomgeving als het productie-exemplaar. Gebruik ze strategisch voor scenario's zoals blue-green deployments die schakelen tussen slots. Deze aanpak minimaliseert downtime en zorgt voor soepele overgangen.
Gebruik implementatieslots met de nodige voorzichtigheid. U kunt problemen introduceren, zoals uitzonderingen of geheugenlekken, die zowel de bestaande exemplaren als nieuwe exemplaren kunnen beïnvloeden. Zorg ervoor dat u wijzigingen grondig test. Zie Operational Excellencevoor operationele richtlijnen.
Aanbevelingen
Aanbeveling | Voordeel |
---|---|
(App Service) Kies gratis of Basic-lagen voor lagere omgevingen. We raden deze lagen aan voor experimenteel gebruik. Verwijder de lagen wanneer u ze niet meer nodig hebt. | De gratis en Basic-lagen zijn budgetvriendelijk vergeleken met hogere lagen. Ze bieden een rendabele oplossing voor niet-productieomgevingen die niet de volledige functies en prestaties van Premium-abonnementen nodig hebben. |
(App Service) Profiteer van kortingen en verken voorkeursprijzen voor: - Lagere omgevingen met ontwikkel-/testplannen. - Azure-reserveringen en Azure-besparingsplannen voor toegewezen rekenkracht die u inricht in de Premium V3-laag en App Service Environment. Gebruik gereserveerde instanties voor stabiele workloads met voorspelbare gebruikspatronen. |
Dev/test-plannen bieden lagere tarieven voor Azure-services, waardoor ze rendabel zijn voor niet-productieomgevingen. Gebruik gereserveerde instanties om vooraf te betalen voor rekenresources en aanzienlijke kortingen te krijgen. |
(Web App) Kosten monitoren die door App Service-resources worden gemaakt. Voer het hulpprogramma voor kostenanalyse uit in Azure Portal. Budgetten en waarschuwingen creëren om belanghebbenden te informeren. |
U kunt kostenpieken, inefficiënties of onverwachte uitgaven vroegtijdig identificeren. Deze proactieve aanpak helpt u bij het bieden van budgettaire controles om te voorkomen dat de overbesteding wordt overschreden. |
(App Service) Afschalen wanneer de vraag afneemt. Als u wilt inschalen, definieert u schaalregels om het aantal exemplaren in Azure Monitorte verminderen. | Voorkom verspilling en verminder onnodige uitgaven. |
Operationele uitmuntendheid
Operational Excellence richt zich voornamelijk op procedures voor ontwikkelprocedures, waarneembaarheid en releasebeheer.
De ontwerpprincipes voor Operational Excellence bieden een ontwerpstrategie op hoog niveau voor het behalen van die doelen in overeenstemming met de operationele vereisten van de werkbelasting.
Controlelijst voor ontwerpen
Start uw ontwerpstrategie op basis van de controlelijst voor ontwerpbeoordeling voor Operational Excellence voor het definiëren van processen voor waarneembaarheid, testen en implementatie met betrekking tot Web Apps.
Releases beheren: Gebruik implementatieslots om releases effectief te beheren. U kunt uw toepassing implementeren in een slot, tests uitvoeren en de functionaliteit ervan valideren. Na verificatie kunt u de app naadloos naar productie verplaatsen. Voor dit proces worden geen extra kosten in rekening gebracht omdat de slot draait in dezelfde virtuele-machineomgeving (VM) als het productie-exemplaar.
Gebruik Wisselen met Preview (wisselen in meerdere fasen). Met Wisselen met Preview kunt u de app testen in uw faseringsslots tegen uw productie-instellingen en de app ook opwarmen. Nadat u uw tests hebt uitgevoerd en alle benodigde paden hebt opgewarmd, kunt u de wissel voltooien en ontvangt de app productieverkeer zonder opnieuw op te starten.
Voer geautomatiseerde tests uit: voordat u een release van uw web-app promoveerde, test u de prestaties, functionaliteit en integratie met andere onderdelen grondig. Gebruik Azure Load Testing, dat kan worden geïntegreerd met Apache JMeter, een populair hulpprogramma voor prestatietests. Verken geautomatiseerde hulpprogramma's voor andere soorten testen, zoals Phantom voor functionele tests.
Implementaties automatiseren: CI/CD-pijplijnen gebruiken met Azure DevOps of GitHub Actions om implementaties te automatiseren en handmatige inspanning te verminderen continue implementatie naar Azure App Service.
Onveranderbare eenheden implementeren: Implementeer het patroon Implementatiestempels om App Service in een onveranderbare stempel te verdelen. App Service ondersteunt het gebruik van containers, die inherent onveranderbaar zijn. Overweeg aangepaste containers voor uw App Service-web-app.
Elke stempel vertegenwoordigt een zelfstandige eenheid die u snel kunt uitschalen of inschalen. Eenheden die op deze stempel zijn gebaseerd, zijn tijdelijk en staatloos. Staatloos ontwerp vereenvoudigt bewerkingen en onderhoud. Deze benadering is ideaal voor bedrijfskritieke toepassingen. Zie Bedrijfskritieke basislijn met App Servicevoor een voorbeeld.
Gebruik een IaC-technologie (Infrastructure as Code), zoals Bicep, om eenheden met herhaalbaarheid en consistentie uit te stempelen.
Productieomgevingen veilig houden: Maak afzonderlijke App Service-plannen om productie- en preproductieomgevingen uit te voeren. Breng geen wijzigingen rechtstreeks aan in de productieomgeving om stabiliteit en betrouwbaarheid te garanderen. Afzonderlijke exemplaren bieden flexibiliteit bij het ontwikkelen en testen voordat u wijzigingen in productie promoveert.
Gebruik lage omgevingen om nieuwe functies en configuraties op een geïsoleerde manier te verkennen. Ontwikkel- en testomgevingen kortstondig houden.
Certificaten beheren: voor aangepaste domeinen moet u TLS-certificaten beheren.
Zorg ervoor dat er processen zijn om certificaten aan te schaffen, te vernieuwen en te valideren. Offload deze processen indien mogelijk naar App Service. Als u uw eigen certificaat gebruikt, moet u de verlenging ervan beheren. Kies een benadering die het beste aansluit bij uw beveiligingsvereisten.
Aanbeveling | Voordeel |
---|---|
(Web App) de status van uw exemplaren controleren en statustests van exemplaren activeren. Stel een specifiek pad in voor het afhandelen van gezondheidsonderzoekverzoeken. |
U kunt snel problemen detecteren en de benodigde acties ondernemen om de beschikbaarheid en prestaties te behouden. |
(Web App) Schakel diagnostische logboeken in voor de toepassing en de instance. Regelmatige logboekregistratie kan de prestaties van het systeem vertragen, opslagkosten toevoegen en risico's veroorzaken als u onbeveiligde toegang tot logboeken hebt. Volg deze aanbevolen procedures: - Het juiste informatieniveau vastleggen. - Bewaarbeleid instellen. - Houd een audit trail bij van geautoriseerde toegang en ongeautoriseerde pogingen. - Logboeken behandelen als gegevens en besturingselementen voor gegevensbeveiliging toepassen. |
Diagnostische logboeken bieden waardevolle inzichten in het gedrag van uw app. Bewaak verkeerspatronen en identificeer afwijkingen. |
(Web-app) Profiteer van door App Service beheerde certificaten om certificeringsbeheer naar Azure te offloaden. | App Service verwerkt automatisch processen zoals het aanschaffen van certificaten, certificaatverificatie, certificaatvernieuwing en het importeren van certificaten uit Key Vault. U kunt uw certificaat ook uploaden naar Key Vault en de App Service-resourceprovider machtigen om toegang tot het certificaat te krijgen. |
(App Service) App-wijzigingen valideren in de staging-slot voordat u deze verwisselt met de productieslot. | Vermijd stilstand en fouten. Ga snel terug naar de laatst bekende goede status als u een probleem na een wissel detecteert. |
Prestatie-efficiëntie
Prestatie-efficiëntie gaat over het behouden van de gebruikerservaring, zelfs wanneer er een toename van de belasting is, door het beheren van capaciteit. De strategie omvat het schalen van resources, het identificeren en optimaliseren van potentiële knelpunten en het optimaliseren van piekprestaties.
De ontwerpprincipes voor Prestatie-efficiëntie een ontwerpstrategie op hoog niveau bieden voor het bereiken van deze capaciteitsdoelen ten opzichte van het verwachte gebruik.
Controlelijst voor ontwerpen
Start de ontwerpstrategie op basis van de controlelijst voor de -ontwerpbeoordeling met betrekking tot performance-efficiëntie, om een uitgangspunt vast te stellen gebaseerd op sleutelprestatie-indicatoren voor webapplicaties.
Prestatie-indicatoren identificeren en bewaken: stel doelen in voor de sleutelindicatoren voor de toepassing, zoals het aantal binnenkomende aanvragen, de tijd die de toepassing nodig heeft om te reageren op aanvragen, aanvragen in behandeling en fouten in HTTP-antwoorden. Houd rekening met belangrijke indicatoren als onderdeel van de prestatiebasislijn voor de workload.
Leg metrische gegevens van App Service vast die de basis vormen van prestatie-indicatoren. Verzamel logboeken om inzicht te krijgen in resourcegebruik en -activiteiten. Gebruik APM-hulpprogramma's (Application Performance Monitoring), zoals Application Insights, om prestatiegegevens van de toepassing te verzamelen en te analyseren. Zie Gegevensreferentie voor App Service-bewakingvoor meer informatie.
Neem instrumentatie op codeniveau, transactietracering en prestatieprofilering op.
Capaciteit beoordelen: simuleer verschillende gebruikersscenario's om de optimale capaciteit te bepalen die u nodig hebt om verwacht verkeer te verwerken. Gebruik load testing om te begrijpen hoe uw toepassing zich gedraagt onder verschillende niveaus van belasting.
Selecteer de juiste laag: toegewezen rekenkracht gebruiken voor productieworkloads. Premium V3-lagen bieden grotere SKU's met meer geheugen- en CPU-capaciteit, meer exemplaren en meer functies, zoals zoneredundantie. Zie Premium V3-prijscategorievoor meer informatie.
Uw schaalstrategie optimaliseren: gebruik indien mogelijk automatisch schalen in plaats van het aantal exemplaren handmatig aan te passen wanneer de belasting van toepassingen verandert. Met automatisch schalen past App Service de servercapaciteit aan op basis van vooraf gedefinieerde regels of triggers. Zorg ervoor dat u voldoende prestatietests uitvoert en stel de juiste regels in voor de juiste triggers.
Als u prioriteit geeft aan eenvoud tijdens de eerste installatie, gebruikt u een optie voor automatisch schalen waarvoor u geen regels hoeft te definiëren en hoeft u alleen limieten in te stellen.
Zorg ervoor dat er voldoende resources beschikbaar zijn om optimale prestaties te garanderen. Wijs resources op de juiste manier toe om prestatiedoelen te behouden, zoals reactietijd of doorvoer. Overweeg indien nodig overbezetting van resources.
Wanneer u regels voor automatisch schalen definieert, moet u rekening houden met de tijd die nodig is om uw toepassing te initialiseren. Houd rekening met deze overhead wanneer u alle schaalbeslissingen neemt.
Cache-gebruiken: het ophalen van gegevens uit een resource die niet vaak verandert en die duur is voor toegang, is van invloed op de prestaties. Complexe query's, waaronder joins en meerdere zoekacties, dragen bij aan uitvoertijd. Voer caching uit om de verwerkingstijd en latentie te minimaliseren. Cache queryresultaten om herhaalde verzoeken naar de database of back-end systemen te voorkomen en verwerkingstijd te verminderen voor volgende aanvragen.
Zie Cachingvoor meer informatie over het gebruik van lokale en gedistribueerde cache in de workload.
Bekijk de antipatronen voor prestaties: Om ervoor te zorgen dat de webtoepassing presteert en schaalt in overeenstemming met uw bedrijfsvereisten, vermijd de typische antipatronen. Hier volgen enkele antipatronen die door App Service worden gecorrigeerd.
Antipatroon Beschrijving Bezet front-end Resource-intensieve taken kunnen de reactietijden voor gebruikersaanvragen verhogen en hoge latentie veroorzaken.
Verplaats processen die aanzienlijke resources verbruiken naar een afzonderlijke back-end. Gebruik een bericht broker om resource-intensieve taken in de wachtrij te plaatsen, zodat de back-end ze kan ophalen voor asynchrone verwerking.Geen cache- Dien aanvragen uit vanuit een tussenliggende cache vóór de back-enddatabase om de latentie te verminderen. Lawaaierige buur Multitenant-systemen delen bronnen tussen gebruikers. De activiteit van één tenant kan een negatief effect hebben op het gebruik van het systeem van een andere tenant. App Service Environment biedt een volledig geïsoleerde en toegewezen omgeving voor het uitvoeren van App Service-apps.
Aanbevelingen
Aanbeveling | Voordeel |
---|---|
(App Service) de instelling AlwaysOn inschakelen wanneer toepassingen één App Service-plan delen. App Service-apps worden automatisch ontladen wanneer ze inactief zijn om resources te besparen. De volgende aanvraag activeert een koude start, wat time-outs voor aanvragen kan veroorzaken. | De toepassing wordt nooit uitgeladen met AlwaysOn ingeschakeld. |
(Web Apps) Overweeg het gebruik van HTTP/2 voor toepassingen om de efficiëntie van het protocol te verbeteren. | Kies HTTP/2 via HTTP/1.1 omdat HTTP/2 verbindingen volledig multiplexes bevatten, verbindingen hergebruikt om overhead te verminderen en headers te comprimeren om de gegevensoverdracht te minimaliseren. |
Compromissen
Mogelijk moet u een compromis tussen ontwerpen maken als u de benaderingen in de controlelijsten voor pijlers gebruikt. Hier volgen enkele voorbeelden van voordelen en nadelen.
Dichtheid en isolatie
hogere dichtheid: plaats meerdere apps binnen hetzelfde App Service-plan om resources te minimaliseren. Alle apps delen resources, zoals CPU en geheugen, waardoor u geld kunt besparen en de operationele complexiteit kunt verminderen. Deze benadering optimaliseert ook het resourcegebruik. Apps kunnen niet-actieve resources van een andere app gebruiken als de belastingspatronen na verloop van tijd veranderen.
Houd ook rekening met de nadelen, zoals resource contentie. Pieken in gebruik of instabiliteit van een app kunnen bijvoorbeeld van invloed zijn op de prestaties van andere apps. Incidenten in de ene app kunnen ook worden doordrongen naar andere apps in de gedeelde omgeving, wat van invloed kan zijn op de beveiliging. Voor kritieke toepassingen waarvoor hoge beschikbaarheid en prestaties zijn vereist, bieden geïsoleerde omgevingen zoals App Service Environment V3 (ASE) toegewezen resources maar tegen hogere kosten. Overweeg het gebruik van gedeelde omgevingen voor niet-kritieke workloads en geïsoleerde omgevingen voor bedrijfskritieke toepassingen.
Hogere isolatie: Isolatie helpt interferentie te voorkomen. Deze strategie is van toepassing op beveiliging, prestaties en zelfs scheiding van ontwikkel-, test- en productieomgevingen.
App Service Environment biedt betere controle over beveiliging en gegevensbeveiliging, omdat elke app eigen beveiligingsinstellingen kan hebben. Uw omgeving kan schendingen bevatten omdat isolatie de straal beperkt. Resourceconflicten worden geminimaliseerd vanuit het perspectief van prestaties. Isolatie maakt onafhankelijk schalen mogelijk op basis van specifieke vraag en individuele capaciteitsplanning.
Als nadeel is deze aanpak duurder en vereist operationele rigor.
Betrouwbare schaalstrategie
Een goed gedefinieerde schaalstrategie zorgt ervoor dat uw toepassing verschillende belastingen kan verwerken zonder de prestaties in gevaar te brengen. Er zijn echter compromissen met de kosten. Schaalbewerkingen kosten tijd. Wanneer nieuwe resources worden toegewezen, moet de toepassing correct worden geïnitialiseerd voordat aanvragen effectief kunnen worden verwerkt. U kunt resources (prewarm-exemplaren) overprovisionen om een veiligheidsnet te bieden. Zonder die extra capaciteit kan er tijdens de initialisatiefase een vertraging optreden bij het verwerken van aanvragen, wat van invloed is op de gebruikerservaring. Automatische schaalaanpassingsbewerkingen zouden wellicht vroeg genoeg kunnen beginnen om de juiste initialisatie van resources mogelijk te maken tegen de tijd dat klanten de resources gebruiken.
Een nadeel is dat overgeprovisioneerde resources meer kosten. Je betaalt per seconde voor elk exemplaar, inclusief vooraf voorverwarmde exemplaren. Hogere niveaus omvatten voorgewarmde instanties. Bepaal of mogelijkheden met duurdere lagen de investering waard zijn.
Redundantie bouwen
Redundantie biedt tolerantie, maar brengt ook kosten met zich mee. Serviceniveaudoelstellingen (SLO's) voor uw workload bepalen acceptabele prestatiedrempels. Het wordt verspilling als redundantie de SLO-vereisten overschrijdt. Evalueer of overtollige redundantie slo's verbetert of onnodige complexiteit toevoegt.
Houd ook rekening met de nadelen. Redundantie met meerdere regio's biedt bijvoorbeeld hoge beschikbaarheid, maar voegt complexiteit en kosten toe als gevolg van gegevenssynchronisatie, failovermechanismen en communicatie tussen regio's. Bepaal of zoneredundantie aan uw SLO's kan voldoen.
Azure-beleid
Azure biedt een uitgebreide set ingebouwde beleidsregels met betrekking tot App Service en de bijbehorende afhankelijkheden. Een set Azure-beleidsregels kan enkele van de voorgaande aanbevelingen controleren. U kunt bijvoorbeeld controleren of:
De juiste netwerkcontroles zijn aanwezig. U kunt bijvoorbeeld netwerksegmentatie opnemen door App Service in Azure Virtual Network te plaatsen via een virtuele netwerkinjectie om meer controle te hebben over de netwerkconfiguratie. De toepassing heeft geen openbare eindpunten en maakt verbinding met Azure-services via privé-eindpunten.
Identiteitscontroles zijn aanwezig. De toepassing gebruikt bijvoorbeeld beheerde identiteiten om zichzelf te verifiëren bij andere resources. Ingebouwde App Service-verificatie (Easy Auth) verifieert binnenkomende aanvragen.
Functies zoals externe foutopsporing en basisverificatie zijn uitgeschakeld om het kwetsbaarheid voor aanvallen te verminderen.
Voor uitgebreide governance raadpleegt u de ingebouwde Azure Policy-definities en andere beleidsregels die van invloed kunnen zijn op de beveiliging van de rekenlaag.
Aanbevelingen voor Azure Advisor
Azure Advisor- is een gepersonaliseerde cloudconsultant waarmee u de best practices kunt volgen om uw Azure-implementaties te optimaliseren. Hier volgen enkele aanbevelingen waarmee u de betrouwbaarheid, beveiliging, kosteneffectiviteit, prestaties en operationele uitmuntendheid van uw webtoepassingsexemplaren kunt verbeteren.
Volgende stappen
Beschouw de volgende artikelen als bronnen die de aanbevelingen uit dit artikel illustreren.
Gebruik deze referentiearchitecturen als voorbeelden van het toepassen van deze aanbevelingen op een workload.
Als u nog nooit een web-app hebt geïmplementeerd, raadpleegt u Basic-webtoepassing.
Zie Baseline maximaal beschikbare zone-redundante webtoepassingvoor een basisarchitectuur als uitgangspunt voor een implementatie op productieniveau.
Gebruik de volgende productdocumentatie om uw implementatie-expertise op te bouwen: