Den här artikeln innehåller en översikt över hur du distribuerar säkra program med hjälp av Azure 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
Ladda ned en Visio-fil med den här arkitekturen.
Dataflöde
- HTTP/HTTPS-begäranden träffar först Application Gateway.
- Du kan också (visas inte i diagrammet) ha Microsoft Entra-autentisering aktiverat för webbappen. När trafiken först når Application Gateway uppmanas användaren att ange autentiseringsuppgifter för att autentisera med programmet.
- Användarbegäranden flödar genom den interna lastbalanseraren (ILB) i miljön, som i sin tur dirigerar trafiken till utgiftswebbappen.
- Användaren fortsätter sedan att skapa en utgiftsrapport.
- Som en del av att skapa utgiftsrapporten anropas den distribuerade API-appen för att hämta användarens chefsnamn och e-post.
- Den skapade utgiftsrapporten lagras i Azure SQL Database.
- För att underlätta kontinuerlig distribution checkas kod in i Azure DevOps-instansen.
- 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 och dubbla förhållandet mellan minne och kärna jämfört med Standard.
- Azure App Services 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.
- Web Application Firewall (WAF) är en funktion i Application Gateway. Om du aktiverar WAF i Application Gateway förbättras säkerheten ytterligare. WAF använder OWASP-regler 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. Anslut ions 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 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
- Ö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.
- Mer information om tillgänglighet finns i tillgänglighetschecklistan i Azure Architecture Center.
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
- Granska översikten över säkerhetspelare.
- Granska säkerhetsövervägandena i lämplig Referensarkitektur för App Service-webbprogram.
- Överväg att följa en säker livscykelprocess för utveckling för att hjälpa utvecklare att skapa säkrare programvara och uppfylla kraven på säkerhetsefterlevnad samtidigt som utvecklingskostnaden minskar.
- Granska skissarkitekturen för Azure PCI DSS-efterlevnad.
- Azure DDoS Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner för att ge mer skydd mot DDoS-attacker. Du bör aktivera Azure DDOS Protection i alla virtuella perimeternätverk.
Motståndskraft
- Överväg att använda geo-distribuerad skala med App Service-miljön för bättre återhämtning och skalbarhet.
- Granska de typiska designmönstren för återhämtning och överväg att implementera dessa när det är lämpligt.
- Du hittar flera rekommenderade metoder för App Service i Azure Architecture Center.
- Överväg att använda aktiv geo-replikering för datanivån och geo-redundant lagring för bilder och köer.
- En djupare diskussion om återhämtning finns i relevant artikel i Azure Architecture Center.
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 grundläggande nivå som minimerar kostnaderna men ändå ser till att det finns stöd för serviceavtal 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å premiumnivå 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
- Stegvis distributionsguide
- Integrera en ILB App Service-miljö med Azure Application Gateway
- Integrera dina webbappar med Azure Application Gateway
- Geo-distribuerad skala med App Service-miljön