Bewerken

Veilig beheerde webtoepassingen

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

Dit artikel bevat een overzicht van het implementeren van beveiligde toepassingen met behulp van de Azure-app Service Environment. Als u de toegang tot toepassingen vanaf internet wilt beperken, worden de Azure-toepassing Gateway-service en Azure Web Application Firewall gebruikt. Dit artikel bevat ook richtlijnen voor continue integratie en continue implementatie (CI/CD) voor App Service Environments met behulp van Azure DevOps.

Dit scenario wordt meestal geïmplementeerd in branches zoals banken en verzekeringen, waarbij klanten zich bewust zijn van beveiliging op platformniveau naast beveiliging op toepassingsniveau. Om deze concepten te demonstreren, gebruiken we een toepassing waarmee gebruikers onkostendeclaraties kunnen indienen.

Potentiële gebruikscases

Houd rekening met dit scenario voor de volgende gebruiksvoorbeelden:

Architectuur

Diagram featuring the sample scenario architecture for Secure ILB App Service Environment Deployment.

Een Visio-bestand van deze architectuur downloaden.

Gegevensstroom

  1. HTTP/HTTPS-aanvragen raken eerst de Application Gateway.
  2. Optioneel (niet weergegeven in het diagram), kunt u Microsoft Entra-verificatie inschakelen voor de web-app. Nadat het verkeer de Application Gateway heeft bereikt, wordt de gebruiker gevraagd referenties op te geven om te verifiëren bij de toepassing.
  3. Gebruikersaanvragen stromen via de interne load balancer (ILB) van de omgeving, waarmee het verkeer op zijn beurt wordt gerouteerd naar de Onkosten-web-app.
  4. De gebruiker gaat vervolgens een onkostendeclaratie maken.
  5. Als onderdeel van het maken van het onkostenrapport wordt de geïmplementeerde API-app aangeroepen om de managernaam en het e-mailadres van de gebruiker op te halen.
  6. Het gemaakte onkostenrapport wordt opgeslagen in Azure SQL Database.
  7. Om continue implementatie te vergemakkelijken, wordt code ingecheckt in het Azure DevOps-exemplaar.
  8. Op de build-VM is de Azure DevOps-agent geïnstalleerd, zodat de build-VM de bits voor de web-app kan ophalen die in de App Service-omgeving kan worden geïmplementeerd (omdat de build-VM is geïmplementeerd in een subnet binnen hetzelfde virtuele netwerk).

Onderdelen

  • De App Service Environment biedt een volledig geïsoleerde, toegewezen omgeving voor het veilig uitvoeren van de toepassing op grote schaal. Bovendien biedt de App Service-omgeving en de workloads die erop worden uitgevoerd zich achter een virtueel netwerk, ook een extra beveiligings- en isolatielaag. De vereiste van hoge schaal en isolatie zorgde voor de selectie van ILB App Service Environment.
  • Deze workload maakt gebruik van de geïsoleerde App Service-prijscategorie, dus de toepassing wordt uitgevoerd in een privé-specifieke omgeving in een Azure-datacenter met behulp van snellere processors, SSD-opslag en dubbele geheugen-naar-kernverhouding vergeleken met Standard.
  • Azure-app Services Web App en API App host webtoepassingen en RESTful API's. Deze apps en API's worden gehost in het geïsoleerde serviceplan, dat ook automatische schaalaanpassing, aangepaste domeinen, enzovoort biedt, maar in een toegewezen laag.
  • Azure Application Gateway is een load balancer voor webverkeer die wordt uitgevoerd op Laag 7 waarmee verkeer naar de webtoepassing wordt beheerd. Het biedt SSL-offloading, waardoor extra overhead wordt verwijderd van de webservers die de web-app hosten om verkeer opnieuw te ontsleutelen.
  • Web Application Firewall (WAF) is een functie van Application Gateway. Door waf in te schakelen in Application Gateway wordt de beveiliging verder verbeterd. De WAF maakt gebruik van OWASP-regels om de webtoepassing te beschermen tegen aanvallen zoals scripting op meerdere sites, sessiekapingen en SQL-injectie.
  • Azure SQL Database is geselecteerd omdat de meeste gegevens in deze toepassing relationele gegevens zijn, met enkele gegevens als documenten en blobs.
  • Azure Networking biedt verschillende netwerkmogelijkheden in Azure en de netwerken kunnen worden gekoppeld aan andere virtuele netwerken in Azure. Verbinding maken ionen kunnen ook worden ingesteld met on-premises datacenters via ExpressRoute of site-naar-site. In dit geval is een service-eindpunt ingeschakeld op het virtuele netwerk om ervoor te zorgen dat de gegevens alleen stromen tussen het virtuele Azure-netwerk en het SQL Database-exemplaar.
  • Azure DevOps wordt gebruikt om teams te helpen samenwerken tijdens sprints, met behulp van functies die Agile Development ondersteunen en om build- en release-pijplijnen te maken.
  • Er is een Azure-build-VM gemaakt, zodat de geïnstalleerde agent de betreffende build kan ophalen en de web-app in de omgeving kan implementeren.

Alternatieven

Een App Service-omgeving kan reguliere web-apps uitvoeren in Windows of, zoals in dit voorbeeld, web-apps die zijn geïmplementeerd in de omgeving die elk als Linux-containers worden uitgevoerd. Er is een App Service Environment geselecteerd om deze toepassingen met één exemplaar te hosten. Er zijn alternatieven beschikbaar. Bekijk de onderstaande overwegingen bij het ontwerpen van uw oplossing.

  • Azure Service Fabric: Als uw omgeving voornamelijk op Windows is gebaseerd en uw workloads voornamelijk op .NET Framework zijn gebaseerd en u niet overweegt om opnieuw te ontwerpen naar .NET Core, gebruikt u Service Fabric om Windows Server-containers te ondersteunen en te implementeren. Daarnaast biedt Service Fabric ondersteuning voor C# of Java-programmeer-API's en voor het ontwikkelen van systeemeigen microservices kunnen de clusters worden ingericht in Windows of Linux.
  • Azure Kubernetes Service (AKS) is een opensource-project en een indelingsplatform dat geschikter is voor het hosten van complexe toepassingen met meerdere containers die doorgaans gebruikmaken van een architectuur op basis van microservices. AKS is een beheerde Azure-service waarmee de complexiteit van het inrichten en configureren van een Kubernetes-cluster wordt weggenomen. Belangrijke kennis van het Kubernetes-platform is echter vereist om het te ondersteunen en te onderhouden, dus het hosten van een handvol webtoepassingen met één exemplaar in containers is mogelijk niet de beste optie.

Andere opties voor de gegevenslaag zijn:

  • Azure Cosmos DB: Als de meeste gegevens een niet-relationele indeling hebben, is Azure Cosmos DB een goed alternatief. Deze service biedt een platform voor het uitvoeren van andere gegevensmodellen, zoals MongoDB, Cassandra, Graph-gegevens of eenvoudige tabelopslag.

Overwegingen

Er zijn bepaalde overwegingen bij het omgaan met certificaten in ILB App Service Environment. U moet een certificaat genereren dat is gekoppeld aan een vertrouwde basis zonder dat een certificaatondertekeningsaanvraag is vereist die wordt gegenereerd door de server waarop het certificaat uiteindelijk wordt opgeslagen. Met IIS (Internet Information Services) bijvoorbeeld is de eerste stap het genereren van een CSR van uw IIS-server en deze vervolgens verzenden naar de instantie die het SSL-certificaat uitgeeft.

U kunt geen CSR uitgeven vanuit de Interne Load Balancer (ILB) van een App Service Environment. De manier om deze beperking af te handelen, is door de jokertekenprocedure te gebruiken.

Met de jokertekenprocedure kunt u het eigendom van DNS-naam gebruiken in plaats van een CSR. Als u eigenaar bent van een DNS-naamruimte, kunt u een speciale DNS TXT-record invoeren, met de procedure voor jokertekens wordt gecontroleerd of de record er is en of u de eigenaar bent van de DNS-server omdat u de juiste record hebt. Op basis van deze informatie geeft het een certificaat uit dat is geregistreerd bij een vertrouwde basis, die u vervolgens kunt uploaden naar uw ILB. U hoeft niets te doen met de afzonderlijke certificaatarchieven in de Web Apps, omdat u een vertrouwd basis-SSL-certificaat bij de ILB hebt.

Zelfondertekend of intern uitgegeven SSL-certificaat werken als u beveiligde aanroepen wilt uitvoeren tussen services die worden uitgevoerd in een ILB App Service Environment. Een andere oplossing die u kunt overwegen om ILB App Service Environment te laten werken met intern uitgegeven SSL-certificaat en hoe u de interne CA laadt in het vertrouwde basisarchief.

Houd tijdens het inrichten van de App Service-omgeving rekening met de volgende beperkingen bij het kiezen van een domeinnaam voor de omgeving. Domeinnamen kunnen niet:

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

Daarnaast kan de aangepaste domeinnaam die wordt gebruikt voor apps en de domeinnaam die door de ILB App Service Environment wordt gebruikt, niet overlappen. Voor een ILB App Service Environment met de domeinnaam contoso.com kunt u geen aangepaste domeinnamen gebruiken voor uw apps, zoals:

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

Kies een domein voor de ILB App Service Environment die geen conflict veroorzaakt met die aangepaste domeinnamen. U kunt voor dit voorbeeld iets als contoso-internal.com gebruiken voor het domein van uw omgeving, omdat dat geen conflict veroorzaakt met aangepaste domeinnamen die eindigen op .contoso.com.

Een ander punt om rekening mee te houden is DNS. Als u wilt toestaan dat toepassingen in de App Service-omgeving met elkaar communiceren, bijvoorbeeld een webtoepassing om met een API te communiceren, moet u DNS hebben geconfigureerd voor uw virtuele netwerk met de omgeving. U kunt uw eigen DNS gebruiken of u kunt privézones van Azure DNS gebruiken.

Beschikbaarheid

  • Overweeg om de typische ontwerppatronen voor beschikbaarheid toe te passen bij het bouwen van uw cloudtoepassing.
  • Bekijk de beschikbaarheidsoverwegingen in de juiste Referentiearchitectuur voor App Service-webtoepassingen.
  • Zie de controlelijst voor beschikbaarheid in Het Azure Architecture Center voor andere overwegingen met betrekking tot beschikbaarheid.

Schaalbaarheid

  • Begrijpen hoe schaal werkt in App Service Environments.
  • Bekijk de aanbevolen procedures voor automatische schaalaanpassing van cloud-apps.
  • Houd bij het bouwen van een cloudtoepassing rekening met de typische ontwerppatronen voor schaalbaarheid.
  • Bekijk de overwegingen voor schaalbaarheid in de juiste Referentiearchitectuur van de App Service-webtoepassing.
  • Zie de controlelijst voor prestatie-efficiëntie die beschikbaar is in het Azure Architecture Center voor andere artikelen over schaalbaarheid.

Beveiliging

  • Bekijk het overzicht van de beveiligingspijler.
  • Bekijk de beveiligingsoverwegingen in de juiste referentiearchitectuur van de App Service-webtoepassing.
  • Overweeg om een beveiligd levenscyclusproces voor ontwikkeling te volgen om ontwikkelaars te helpen veiligere software te bouwen en te voldoen aan de vereisten voor beveiligingsnaleving en tegelijkertijd de ontwikkelingskosten te verlagen.
  • Bekijk de blauwdrukarchitectuur voor Naleving van Azure PCI DSS.
  • Azure DDoS Protection, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties om meer bescherming te bieden tegen DDoS-aanvallen. Schakel Azure DDOS Protection in voor elk virtueel perimeternetwerk.

Tolerantie

Dit scenario implementeren

Als u dit scenario wilt implementeren, volgt u deze stapsgewijze zelfstudie om aan te geven hoe u elk onderdeel handmatig implementeert. Selecteer App Service Environment v3 in plaats van v2 wanneer u de zelfstudie volgt. Deze zelfstudie biedt ook een .NET-voorbeeldtoepassing waarmee een eenvoudige contoso-onkostenrapportagetoepassing wordt uitgevoerd.

Prijzen

Bekijk de kosten voor het uitvoeren van dit scenario. Alle services zijn vooraf geconfigureerd in de kostencalculator. Als u wilt zien hoe de prijzen voor uw specifieke use case veranderen, wijzigt u de juiste variabelen zodat deze overeenkomen met het verwachte verkeer.

We hebben drie voorbeeldkostenprofielen verstrekt op basis van de hoeveelheid verkeer die u verwacht te krijgen:

  • Klein: Dit prijsvoorbeeld vertegenwoordigt de onderdelen die nodig zijn voor een minimaal exemplaar op productieniveau dat een paar duizend gebruikers per maand bedient. De app maakt gebruik van één exemplaar van een standaardweb-app die voldoende is om automatisch schalen in te schakelen. Elk van de andere onderdelen wordt geschaald naar een basislaag waarmee de kosten worden geminimaliseerd, maar er wordt nog steeds gezorgd voor SLA-ondersteuning en voldoende capaciteit voor het afhandelen van een workload op productieniveau.
  • Gemiddeld: Dit prijsvoorbeeld vertegenwoordigt de onderdelen die nodig zijn voor een implementatie met gemiddelde grootte. Hier schatten we ongeveer 100.000 gebruikers gedurende een maand. Het verwachte verkeer wordt verwerkt in één App Service-exemplaar met een gemiddelde standard-laag. Daarnaast worden gemiddelde lagen van cognitieve en zoekservices toegevoegd aan de rekenmachine.
  • Groot: Dit prijsvoorbeeld vertegenwoordigt een toepassing die is bedoeld voor grote schaal, in de volgorde van miljoenen gebruikers per maand, waarmee terabytes aan gegevens worden verplaatst. Op dit niveau van gebruik zijn hoge prestaties, hoogwaardige web-apps in de premiumlaag die zijn geïmplementeerd in meerdere regio's die worden fronteerd door Traffic Manager vereist. Gegevens bestaan uit de volgende onderdelen: opslag, databases en CDN, die allemaal zijn geconfigureerd voor terabytes aan gegevens.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

  • Faisal Microsoft | Senior klanttechnicus

Volgende stappen