Redigera

Dela via

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

Azure App Service
Azure Application Gateway
Azure SQL Database
Azure VPN Gateway
Azure Web Application Firewall

Den här artikeln innehåller en översikt över hur du distribuerar säkra program med hjälp av App Service-miljön. För att begränsa programåtkomsten från Internet används Azure Application Gateway-tjänsten och Azure Web Application Firewall . Den här artikeln innehåller också vägledning om kontinuerlig integrering och kontinuerlig distribution (CI/CD) för App Service-miljön med hjälp av Azure DevOps.

Det här scenariot distribueras ofta i branscher som bank och försäkring, där kunderna är medvetna om säkerhet på plattformsnivå utöver säkerhet på programnivå. För att demonstrera dessa begrepp använder vi ett program som gör det möjligt för användare att skicka utgiftsrapporter.

Potentiella användningsfall

Tänk på det här scenariot för följande användningsfall:

  • Skapa en Azure-webbapp där extra säkerhet krävs.
  • Tillhandahålla dedikerade innehavare i stället för apptjänstplaner för delad klientorganisation.
  • Använda Azure DevOps med en internt lastbalanserad (ILB) programtjänstmiljö.

Arkitektur

Diagram med exempelscenarioarkitekturen för säker ILB-App Service-miljön distribution.

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

Dataflöde

  1. HTTP/HTTPS-begäranden träffar först programgatewayen.
  2. Du kan också (visas inte i diagrammet) ha Microsoft Entra-autentisering aktiverat för webbappen. När trafiken först når programgatewayen uppmanas användaren att ange autentiseringsuppgifter för att autentisera med programmet.
  3. Användarbegäranden flödar genom den interna lastbalanseraren (ILB) i miljön, som i sin tur dirigerar trafiken till utgiftswebbappen.
  4. Användaren fortsätter sedan att skapa 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. Den skapade utgiftsrapporten lagras i Azure SQL Database.
  7. För att underlätta kontinuerlig distribution checkas kod in i Azure DevOps-instansen.
  8. Den virtuella byggdatorn har Azure DevOps-agenten installerad, vilket gör att den virtuella byggdatorn kan hämta bitarna för webbappen att distribuera till App Service-miljön (eftersom den virtuella datorn Build distribueras i ett undernät i samma virtuella nätverk).

Komponenter

  • App Service-miljön tillhandahåller en helt isolerad, dedikerad miljö för säker körning av programmet i hög skala. Eftersom App Service-miljön och de arbetsbelastningar som körs på det finns bakom ett virtuellt nätverk ger det också ett extra lager av säkerhet och isolering. Kravet på hög skala och isolering drev valet av ILB-App Service-miljön.
  • Den här arbetsbelastningen använder den isolerade prisnivån för App Service, så programmet körs i en privat dedikerad miljö i ett Azure-datacenter med snabbare processorer, SSD-lagring (Solid State Drive) och dubbla förhållandet mellan minne och kärna jämfört med Standard.
  • Azure App Service Web App och API App är värdar för webbprogram och RESTful-API:er. Dessa appar och API:er finns i den isolerade tjänstplanen, som även erbjuder automatisk skalning, anpassade domäner och så vidare, men på en dedikerad nivå.
  • Azure Application Gateway är en lastbalanserare för webbtrafik som körs på Layer 7 och som hanterar trafik till webbprogrammet. Den erbjuder SSL-avlastning, vilket tar bort extra kostnader från webbservrarna som är värdar för webbappen för att dekryptera trafiken igen.
  • Brandvägg för webbprogram är en funktion i Application Gateway. Om du aktiverar brandväggen för webbprogram i programgatewayen förbättras säkerheten ytterligare. Brandväggen för webbprogram använder OWASP-regler (Open Worldwide Application Security Project) för att skydda webbprogrammet mot attacker som skript mellan webbplatser, sessionskapningar och SQL-inmatning.
  • Azure SQL Database valdes eftersom de flesta data i det här programmet är relationsdata, med vissa data som dokument och blobbar.
  • Azure Networking tillhandahåller olika nätverksfunktioner i Azure och nätverken kan peerkopplas med andra virtuella nätverk i Azure. Anslutningar kan också upprättas med lokala datacenter via ExpressRoute eller plats-till-plats. I det här fallet aktiveras en tjänstslutpunkt i det virtuella nätverket för att säkerställa att data endast flödar mellan det virtuella Azure-nätverket och SQL Database-instansen.
  • Azure DevOps används för att hjälpa team att samarbeta under sprintar, med hjälp av funktioner som stöder agil utveckling och för att skapa bygg- och versionspipelines.
  • En virtuell Azure-byggdator skapades så att den installerade agenten kan hämta respektive version och distribuera webbappen till miljön.

Alternativ

En App Service-miljön kan köra vanliga webbappar i Windows eller, som i det här exemplet, webbappar som distribueras i miljön som alla körs som Linux-containrar. En App Service-miljön har valts som värd för dessa containerbaserade program med en enda instans. Det finns alternativ – läs igenom övervägandena nedan när du utformar din lösning.

  • Azure Service Fabric: Om din miljö till största delen är Windows-baserad och dina arbetsbelastningar främst är .NET Framework-baserade och du inte överväger att bygga om till .NET Core använder du Service Fabric för att stödja och distribuera Windows Server-containrar. Dessutom har Service Fabric stöd för programmerings-API:er för C# eller Java, och för att utveckla interna mikrotjänster kan klustren etableras i Windows eller Linux.
  • Azure Kubernetes Service (AKS) är ett projekt med öppen källkod och en orkestreringsplattform som är mer lämpad 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 abstraherar bort komplexiteten i etablering och konfiguration av ett Kubernetes-kluster. Betydande kunskaper om Kubernetes-plattformen krävs dock för att stödja och underhålla den, så värd för en handfull containerbaserade webbprogram med en enda instans kanske inte är det bästa alternativet.

Andra alternativ för datanivån är:

  • Azure Cosmos DB: Om de flesta data är i icke-relationellt format är Azure Cosmos DB ett bra alternativ. Den här tjänsten tillhandahåller en plattform för att köra andra datamodeller som MongoDB, Cassandra, Graph-data eller enkel tabelllagring.

Att tänka på

Det finns vissa saker att tänka på när du hanterar certifikat på ILB-App Service-miljön. Du måste generera ett certifikat som är kopplat till en betrodd rot utan att kräva en begäran om certifikatsignering som genereras av servern där certifikatet så småningom lagras. Med Internet Information Services (IIS) är till exempel det första steget att generera en certifikatsigneringsbegäran (CSR) från din IIS-server och sedan skicka den till utfärdaren för SSL-certifikatutfärdare.

Du kan inte utfärda en CSR från den interna lastbalanseraren (ILB) för en App Service-miljön. Sättet att hantera den här begränsningen är att använda jokerteckenproceduren.

Med jokerteckenproceduren kan du använda bevis på DNS-namnägarskap i stället för en CSR. Om du äger ett DNS-namnområde kan du lägga till en särskild DNS TXT-post, jokerteckenproceduren kontrollerar att posten finns där, och om den hittas vet du att du äger DNS-servern eftersom du har rätt post. Baserat på den informationen utfärdar den ett certifikat som är registrerat på en betrodd rot, som du sedan kan ladda upp till din ILB. Du behöver inte göra något med de enskilda certifikatarkiven i Web Apps eftersom du har ett betrott rot-SSL-certifikat i ILB.

Gör så att självsignerade eller internt utfärdade SSL-certifikat fungerar om du vill göra säkra anrop mellan tjänster som körs i en ILB-App Service-miljön. En annan lösning att överväga om hur du gör så att ILB-App Service-miljön fungerar med internt utfärdade SSL-certifikat och hur du läser in den interna certifikatutfärdaren till det betrodda rotarkivet.

När du etablerar App Service-miljön bör du överväga följande begränsningar när du väljer ett domännamn för miljön. Domännamn kan inte vara:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Dessutom kan det anpassade domännamn som används för appar och domännamnet som används av ILB-App Service-miljön inte överlappa varandra. För en ILB-App Service-miljön med domännamnet contoso.com kan du inte använda anpassade domännamn för dina appar som:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Välj en domän för ILB-App Service-miljön som inte kommer i konflikt med de anpassade domännamnen. Du kan använda något som liknar contoso-internal.com för domänen i din miljö för det här exemplet, eftersom det inte står i konflikt med anpassade domännamn som slutar i .contoso.com.

En annan sak att tänka på är DNS. För att program inom App Service-miljön ska kunna kommunicera med varandra måste du, till exempel ett webbprogram, kommunicera med ett API, ha DNS konfigurerat för ditt virtuella nätverk som innehåller miljön. Du kan antingen ta med din egen DNS eller använda privata Azure DNS-zoner.

Tillgänglighet

Skalbarhet

  • Förstå hur skalning fungerar i App Service-miljön.
  • Granska metodtips för autoskalning av molnappar.
  • När du skapar ett molnprogram bör du vara medveten om de typiska designmönstren för skalbarhet.
  • Granska skalbarhetsövervägandena i lämplig Referensarkitektur för App Service-webbprogram.
  • Andra skalbarhetsartiklar finns i checklistan för prestandaeffektivitet som är tillgänglig i Azure Architecture Center.

Säkerhet

Motståndskraft

Distribuera det här scenariot

Om du vill distribuera det här scenariot följer du den här stegvisa självstudien som visar hur du distribuerar varje komponent manuellt. Välj App Service-miljön v3 i stället för v2 när du följer självstudien. Den här självstudien innehåller också ett .NET-exempelprogram som kör ett enkelt Contoso-program för utgiftsrapportering.

Prissättning

Utforska kostnaden för att köra det här scenariot. Alla tjänster är förkonfigurerade i kostnadskalkylatorn. Om du vill se hur prissättningen skulle ändras för ditt specifika användningsfall ändrar du lämpliga variabler så att de matchar din förväntade trafik.

Vi har angett tre exempel på kostnadsprofiler baserat på hur mycket trafik du förväntar dig att få:

  • Liten: Det här prisexemplet representerar de komponenter som krävs för en minsta instans på produktionsnivå som betjänar några tusen användare per månad. Appen använder en enda instans av en standardwebbapp som räcker för att aktivera automatisk skalning. Var och en av de andra komponenterna skalas till en Basic-nivå som minimerar kostnaderna men ändå ser till att det finns stöd för serviceavtal (SLA) och tillräckligt med kapacitet för att hantera en arbetsbelastning på produktionsnivå.
  • Medel: Det här prisexemplet representerar de komponenter som behövs för en måttlig storleksdistribution. Här uppskattar vi cirka 100 000 användare under en månad. Den förväntade trafiken hanteras i en enda App Service-instans med en måttlig standardnivå. Dessutom läggs måttliga nivåer av kognitiva tjänster och söktjänster till i kalkylatorn.
  • Stor: Det här prisexemplet representerar ett program som är avsett för hög skala, i storleksordningen miljontals användare per månad, och flyttar terabyte data. På den här användningsnivån krävs högpresterande webbappar på Premium-nivå som distribueras i flera regioner som frontas av Traffic Manager. Data består av följande komponenter: lagring, databaser och CDN, alla konfigurerade för terabyte data.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

  • Faisal Mustafa | Senior kundtekniker

Nästa steg