Webbprogram som hanteras på ett säkert sätt

Den här artikeln beskriver hur du distribuerar säkra program med hjälp av App Service-miljön. Den här arkitekturen använder Azure Application Gateway och Azure Web Application Firewall för att begränsa programåtkomsten från Internet. Den här artikeln beskriver också hur du integrerar kontinuerlig integrering och kontinuerlig distribution (CI/CD) med App Service Environments med hjälp av Azure DevOps.

Branscher som bank och försäkring använder ofta den här lösningen eftersom kunderna värdesätter både säkerhet på plattformsnivå och programnivå. För att demonstrera dessa begrepp tillåter följande exempelprogram användare att skicka utgiftsrapporter.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Dataflöde

Följande dataflöde motsvarar föregående diagram:

1. HTTP- och HTTPS-begäranden når programgatewayen.

2. Du kan också aktivera Microsoft Entra-autentisering för webbappen. När trafiken når programgatewayen uppmanas användaren att ange autentiseringsuppgifter för att autentisera med programmet. Diagrammet visar inte det här steget.

3. Användarbegäranden flödar genom den interna lastbalanseraren (ILB) i miljön, som dirigerar trafiken till utgiftswebbappen.

4. Användaren skapar en utgiftsrapport.

5. Som en del av att skapa utgiftsrapporten anropas den distribuerade API-appen för att hämta användarens chefsnamn och e-post.

6. Systemet lagrar utgiftsrapporten i Azure SQL Database.

7. För att underlätta kontinuerlig distribution checkas kod in i Azure DevOps-instansen.

8. Den virtuella byggdatorn (VM) innehåller Azure DevOps-agenten. Med den här agenten kan den virtuella byggdatorn hämta webbappens artefakter och använda dem för att distribuera webbappen till App Service-miljön. Den virtuella byggdatorn finns i ett undernät i samma virtuella nätverk som App Service Environment.

Komponenter

• App Service-miljön tillhandahåller en helt isolerad, dedikerad miljö för säker körning av programmet i hög skala. Både App Service-miljön och dess arbetsbelastningar finns bakom ett virtuellt nätverk, så installationen lägger till ett extra lager av säkerhet och isolering. I det här scenariot används en ILB App Service-miljö för att uppfylla behovet av hög skala och isolering.

• Den här arbetsbelastningen använder prisnivån Isolerad i App Service. Programmet körs i en privat dedikerad miljö i ett Azure-datacenter som använder snabbare processorer och SSD-lagring (Solid State Drive) och ger maximala utskalningsfunktioner.

• Funktionerna Web Apps och API Apps i App Service är värdar för webbprogram och RESTful-API:er. Dessa appar och API:er finns i den isolerade tjänstplanen, som även tillhandahåller automatisk skalning, anpassade domäner och andra funktioner på en dedikerad nivå.

• Application Gateway är en layer-7-lastbalanserare för webbtrafik som hanterar trafik till webbprogrammet. Den tillhandahåller SSL-avlastning (Secure Sockets Layer), vilket tar bort omkostnaderna för att dekryptera trafik från de webbservrar som är värdar för programmet.

• Brandvägg för webbprogram är en funktion i Application Gateway som förbättrar säkerheten. Brandväggen för webbprogram använder OWASP-regler (Open Worldwide Application Security Project) för att skydda webbprogrammet mot attacker, till exempel skript mellan webbplatser, sessionskapningar och SQL-inmatning.

• SQL Database lagrar programmets data. De flesta data är relationsbaserade, där vissa data lagras som dokument och blobar.

• Azure Virtual Network tillhandahåller olika nätverksfunktioner i Azure. Du kan peer-koppla ihop virtuella nätverk och upprätta anslutningar med lokala datacenter via ExpressRoute eller ett virtuellt privat nätverk (VPN). Det här scenariot gör det möjligt för en tjänstslutpunkt i det virtuella nätverket att säkerställa att data endast flödar mellan det virtuella Azure-nätverket och SQL Database-instansen.

• Azure DevOps stöder flexibel utveckling genom att hjälpa team att samarbeta under sprintar och genom att tillhandahålla verktyg för att skapa bygg- och versionspipelines.

• Med en virtuell Azure-byggdator kan den installerade agenten hämta respektive version och distribuera webbappen till miljön.

Alternativ

En App Service-miljö kan köra vanliga webbappar i Windows eller, som i det här exemplet, webbappar som körs som Linux-containrar som distribueras i miljön. I det här scenariot används en App Service-miljö som värd för dessa containerbaserade program med en enda instans. Överväg följande alternativ när du utformar din lösning:

• Azure Container Apps är en serverlös plattform som minskar infrastrukturkostnaderna och sparar kostnader när du kör containerbaserade program. Det eliminerar behovet av att hantera serverkonfiguration, containerorkestrering och distributionsinformation. Container Apps tillhandahåller alla up-to-date-serverresurser som krävs för att hålla dina program stabila och säkra.

• Azure Kubernetes Service (AKS) är ett projekt med öppen källkod och en orkestreringsplattform som är utformad för att vara värd för komplexa multicontainer-program som vanligtvis använder en mikrotjänstbaserad arkitektur. AKS är en hanterad Azure-tjänst som förenklar etablering och konfiguration av ett Kubernetes-kluster. Du måste ha betydande kunskaper om Kubernetes-plattformen för att stödja och underhålla den, så värd för ett litet antal containerbaserade webbprogram med en enda instans kanske inte är det bästa alternativet.

Använd följande alternativ för datanivån:

• Azure Cosmos DB är ett bra alternativ om de flesta av dina data är i icke-relationellt format.

Potentiella användningsfall

Överväg den här lösningen för följande användningsfall:

• Skapa en Azure-webbapp som kräver extra säkerhet.
• Ange dedikerade innehavare i stället för apptjänstplaner för delad klientorganisation.
• Använd Azure DevOps med en internt belastningsbelastad App Service-miljö .

Hantera TLS- och DNS-designbeslut

DNS-inställningarna (Domain Name System) för standarddomänsuffixet i App Service Environment begränsar inte programmets räckvidd till dessa namn. Med suffixfunktionen för anpassad domän för en ILB App Service-miljö kan du använda ditt eget domänsuffix för att komma åt de program som finns i Din App Service-miljö.

Ett anpassat domänsuffix definierar en rotdomän som apptjänstmiljön använder. För en ILB App Service-miljö är appserviceenvironment.netstandardrotdomänen . En ILB App Service-miljö är intern för en kunds virtuella nätverk, så att kunderna kan använda en rotdomän utöver standarddomänen som överensstämmer med deras virtuella nätverksmiljö. Contoso Corporation kan till exempel använda en standardrotdomän internal.contoso.com för appar som är avsedda att matchas och nås endast i Contosos virtuella nätverk. Du kan nå en app i det här virtuella nätverket genom att APP-NAME.internal.contoso.comkomma åt .

Det anpassade domänsuffixet gäller för App Service-miljön. Den här funktionen skiljer sig från en anpassad domänbindning på en enskild App Service-instans.

Om certifikatet som används för det anpassade domänsuffixet innehåller en SAN-post (Subject Alternate Name) för *.scm.CUSTOM-DOMAINblir platsen Source Control Manager (SCM) tillgänglig från APP-NAME.scm.CUSTOM-DOMAIN. Du kan bara komma åt SCM via en anpassad domän med grundläggande autentisering. Enkel inloggning är bara tillgängligt när du använder standardrotdomänen.

Tänk på följande faktorer när du hanterar certifikat i en ILB App Service-miljö:

• Lagra ett giltigt SSL- eller TLS-certifikat (Transport Layer Security) i ett Azure-nyckelvalv i . PFX-format.

• Kontrollera att certifikatet är mindre än 20 KB.

• Använd ett jokerteckencertifikat för det valda anpassade domännamnet.

• Konfigurera en systemtilldelad eller användartilldelad hanterad identitet för apptjänstmiljön. Den hanterade identiteten autentiserar mot Azure-nyckelvalvet där SSL- eller TLS-certifikatet finns.

• Förvänta dig att App Service Environment tillämpar certifikatändringar inom 24 timmar efter rotation i ett nyckelvalv.

Nätverksåtkomst till Azure Key Vault

• Du kan komma åt nyckelvalvet offentligt eller via en privat slutpunkt som kan nås från undernätet där App Service-miljön distribueras.

• Om du använder offentlig åtkomst kan du skydda ditt nyckelvalv för att endast acceptera trafik från den utgående IP-adressen för App Service-miljön.

• App Service-miljön använder plattformens utgående IP-adress som källadress när den kommer åt nyckelvalvet. Du hittar den här IP-adressen på sidan IP-adresser i Azure-portalen.

DNS-konfiguration

Om du vill komma åt dina program i apptjänstmiljön med hjälp av ditt anpassade domänsuffix konfigurerar du din egen DNS-server eller konfigurerar DNS i en privat Dns-zon i Azure för din anpassade domän. Mer information finns i DNS-konfiguration.

Skydda unikt standardvärdnamn

Den säkra unika standardvärdnamnsfunktionen ger en långsiktig lösning för att skydda dina resurser från dangling DNS-poster och underdomänövertagande. Om du aktiverar den här funktionen för dina App Service-resurser kan ingen utanför organisationen återskapa resurser som har samma standardvärdnamn. Det här skyddet hindrar skadliga aktörer från att utnyttja dinglande DNS-poster och ta över underdomäner. Mer information finns i Skydda unika standardvärdnamn.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns iWell-Architected Framework.

Tillförlitlighet

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

• Överväg att använda geo-distribuerad skala med App Service-miljöer för bättre återhämtning och skalbarhet.

• Granska de typiska designmönstren för återhämtning och implementera dem där det är lämpligt.

• Överväg att använda aktiv geo-replikering för datanivån och geo-redundant lagring för bilder och köer.

• Mer information finns i följande resurser:

  • Mönster för företagswebbappar
  • Tillförlitlighet i App Service-miljön
  • Konfigurera App Service Environment för zonredundans

Tillgänglighet

• Överväg att använda de typiska designmönstren för tillgänglighet när du skapar ditt molnprogram.

• Granska tillgänglighetsövervägandena i lämplig Referensarkitektur för App Service-webbprogram.

• Andra tillgänglighetsöverväganden finns i Tillförlitlighetsguider per tjänst.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

• Granska säkerhetsövervägandena i lämplig Referensarkitektur för App Service-webbprogram.

• Överväg att följa livscykelprocessen för säkerhetsutveckling för att hjälpa utvecklare att skapa säkrare programvara och uppfylla kraven på säkerhetsefterlevnad samtidigt som utvecklingskostnaden minskar.

• Använd metodtips för Azure DDoS Protection och programdesign för att förbättra skyddet mot DDoS-attacker (Distributed Denial-of-Service). Aktivera DDoS Protection i virtuella perimeternätverk.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Utforska kostnaden för att köra det här scenariot. Följande exempel på kostnadsprofiler baseras på förväntad trafik. Alla tjänster är förkonfigurerade i kostnadskalkylatorn.

• Liten distribution: Det här prisexemplet representerar komponenterna för en minsta instans på produktionsnivå som betjänar några tusen användare varje månad. Appen använder en enda liten instans av en isolerad webbapp. Varje extra komponent skalas till en Basic-nivå för att minimera kostnaderna samtidigt som servicenivåavtalsstöd (SLA) säkerställs och tillräcklig kapacitet för att hantera en arbetsbelastning på produktionsnivå.

• Medelstor distribution: Det här prisexemplet representerar komponenterna för en måttlig distribution som betjänar cirka 100 000 användare varje månad. En måttligt stor enskild isolerad App Service-instans hanterar trafiken. Application Gateway- och SQL Database-kapacitetsökningen för att stödja den tillagda arbetsbelastningen.

• Stor distribution: Det här prisexemplet representerar komponenterna för ett storskaligt program som hanterar miljontals användare varje månad och flyttar terabyte data. Den här användningsnivån kräver högpresterande webbappar på isolerad nivå som distribueras i flera regioner och frontas av Azure Traffic Manager. Uppskattningen inkluderar Traffic Manager och extra Application Gateway- och Virtual Network-instanser. Kapaciteten för SQL Database ökar för att stödja den tillagda arbetsbelastningen.

Om du vill se prissättningen för ditt specifika användningsfall ändrar du lämpliga variabler så att de matchar din förväntade trafik.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. Mer information finns i Checklista för designgranskning för prestandaeffektivitet.

• Förstå hur skalning fungerar i App Service-miljöer.

• Granska metodtips för autoskalning av molnappar.

• Förstå de typiska designmönstren för skalbarhet när du skapar ett molnprogram.

• Granska skalbarhetsövervägandena i lämplig Referensarkitektur för App Service-webbprogram.

Deltagare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Nicholas McCollum | Huvudkundtekniker

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

• Integrera din ILB App Service-miljö med en Azure-programgateway
• Geo-distribuerad skala med App Service-miljöer

Relaterade resurser

• Referensarkitektur för App Service-webbprogram
• Företagsdistribution med hög tillgänglighet via en App Service-miljö