Enterprise-implementatie met App Service Environment

Azure Active Directory
Application Gateway
App Service
Firewall
Key Vault
Pipelines
Virtual Network

Azure app service is een Paas-service die wordt gebruikt voor het hosten van verschillende apps op Azure: Web apps, API apps, functions en mobiele apps. Met app service Environment of ASE kunnen bedrijven hun app service-Apps implementeren in een subnet in hun eigen Azure-Virtual Network, waarmee een geïsoleerde, zeer schaal bare en speciale omgeving wordt geboden voor de Cloud werkbelastingen.

Deze referentie architectuur toont een gemeen schappelijke zakelijke workload met behulp van ASE en best practices om de beveiliging van deze werk belasting te verhogen.

GitHub-logo Er is een referentie-implementatie voor deze architectuur beschikbaar op github.

Referentie architectuur voor de standaard implementatie van ASE

Architectuur

Het belangrijkste onderdeel van deze architectuur is de app service omgeving. Een ASE kan worden geïmplementeerd als externe ASE met een openbaar IP-adres of als interne ASE, met een intern IP-adres dat deel uitmaakt van de interne Load Balancer (ILB). Deze referentie architectuur implementeert een zakelijke webtoepassing in een interne ASE, ook wel een ILB ASE genoemd. Gebruik een ILB-ASE wanneer u voor uw scenario het volgende moet doen:

  • Intranettoepassingen veilig hosten in de cloud, waartoe u toegang hebt via een site-naar-site- of ExpressRoute.
  • Beveilig apps met een WAF-apparaat.
  • Apps die niet worden vermeld op openbare DNS-servers, hosten in de cloud.
  • Back-end-apps met internetisolatie maken, waarmee front-end-apps veilig kunnen worden geïntegreerd.

Een ASE moet altijd worden geïmplementeerd in een eigen subnet binnen het virtuele netwerk van de onderneming, waardoor het binnenkomende en uitgaande verkeer nauw keurig kan worden beheerd. Binnen dit subnet worden App Service toepassingen geïmplementeerd in een of meer app service-abonnementen. Dit is een verzameling van fysieke resources die nodig zijn om de app uit te voeren. Afhankelijk van de complexiteit en resource vereiste kan een App Service plan tussen meerdere apps worden gedeeld. Deze referentie-implementatie implementeert een web-app met de naam stem-app, die samenwerkt met een persoonlijke Web-API en een functie. Er wordt ook een dummy-web-app met de naam test-app geïmplementeerd om implementaties van meerdere apps te demonstreren. Elke App Service-app wordt in een eigen App Service plan gehost, zodat elk afzonderlijk kan worden geschaald, indien nodig. Alle resources die zijn vereist voor deze gehoste apps, zoals Storage en compute, en schaal behoeften worden volledig beheerd door de App Service Environment-infra structuur.

Met de eenvoudige stem-app in deze implementatie kunnen gebruikers bestaande items weer geven of nieuwe vermeldingen maken, en stemmen op de bestaande vermeldingen. De Web-API wordt gebruikt voor het maken en ophalen van vermeldingen en stemmen. De gegevens zelf worden opgeslagen in een SQL Server-Data Base. Voor het demonstreren van asynchrone gegevens updates, de wacht rijen van de web-app die nieuw zijn toegevoegd aan een Service Bus-exemplaar. De functie haalt stemmen in de wachtrij op en werkt de SQL database bij. CosmosDB wordt gebruikt voor het opslaan van een model van AD, dat de web-app ophaalt om weer te geven in de browser. De toepassing maakt gebruik van Azure cache voor redis voor cache beheer. Een Azure-cache voor de Premium-laag voor redis wordt gebruikt, waarmee de configuratie van hetzelfde virtuele netwerk als de ASE in een eigen subnet kan worden geconfigureerd. Dit biedt verbeterde beveiliging en isolatie voor de cache.

De web-apps zijn de enige onderdelen die toegankelijk zijn voor Internet via de app-gateway. De API en de functie zijn niet toegankelijk vanaf een Internet-client. Het binnenkomende verkeer wordt beveiligd door een Web Application firewall die is geconfigureerd op de app-gateway.

De volgende services zijn essentieel voor het vergren delen van de ASE in deze architectuur:

Azure Virtual Network of VNet is een persoonlijk Azure-Cloud netwerk dat eigendom is van de onderneming. Het biedt beveiliging op basis van het netwerk en isolatie. ASE is een App Service implementatie in een subnet van de VNet die eigendom zijn van het bedrijf. Hiermee kan de onderneming nauw keurig controleren of de netwerk ruimte en de bronnen die worden geopend, worden gebruikt voor netwerk beveiligings groepen en service-eind punten.

Application Gateway is webverkeer op toepassings niveau Load Balancer, met TLS/SSL-offloading en Web Application firewall (WAF)-beveiliging. Het luistert op een openbaar IP-adres en stuurt verkeer naar het eind punt van de toepassing in de ILB ASE. Omdat dit route ring op toepassings niveau is, kan het verkeer routeren naar meerdere apps binnen dezelfde ILB-ASE. Zie Application Gateway meerdere site-hosting voor meer informatie over hoe app gateway meerdere sites ondersteunt.

Azure firewall wordt gebruikt om het uitgaande verkeer van de webtoepassing te beperken. Uitgaand verkeer dat geen gebruik maakt van de service-eindpunt kanalen en een route tabel vereist door ASE, wordt omgeleid naar het firewall subnet. Hoewel het aanbevolen is dat service-eind punten voor traceer baarheid worden geconfigureerd op het subnet van de firewall , is het mogelijk niet altijd haalbaar. Sommige service-eind punten zijn bijvoorbeeld vereist voor de ASE-infra structuur voor het ASE-subnet. Ter vereenvoudiging configureert deze architectuur alle service-eind punten in het ASE-subnet.

Azure Active Directory of Azure AD biedt toegangs rechten en machtigingen beheer voor Azure-resources en-services. Beheerde identiteiten wijst identiteiten toe aan services en apps, die automatisch worden beheerd door Azure AD. Deze identiteiten kunnen worden gebruikt om te verifiëren bij elke service die ondersteuning biedt voor Azure AD-verificatie. Hiermee wordt de nood zaak voor het expliciet configureren van referenties voor deze apps verwijderd. Deze architectuur wijst een beheerde identiteit toe aan de web-app.

Key Vault worden de geheimen en referenties opgeslagen die vereist zijn voor de apps. Gebruik deze optie om geheimen rechtstreeks in de toepassing op te slaan.

Azure-pijp lijnen bieden continue integratie en continue implementatie mogelijkheden in deze architectuur. Omdat de ASE intern is voor het virtuele netwerk, wordt een virtuele machine gebruikt als een JumpBox binnen het VNet om apps te implementeren in de app service-abonnementen. De pijp lijn bouwt de apps buiten het VNet. Voor verbeterde beveiliging en naadloze RDP/SSH-verbindingen kunt u het beste de onlangs uitgebrachte Azure Bastion gebruiken als de JumpBox.

Configuratie met meerdere locaties

Implementatie met meerdere sites

Interne ASE kunnen meerdere web-apps en Api's hosten met HTTP-eind punten. Deze toepassingen worden vanuit het open bare Internet vergrendeld omdat de ILB-IP alleen toegankelijk is vanuit de Virtual Network. De Application Gateway wordt gebruikt om deze toepassingen selectief beschikbaar te stellen op internet. ASE wijst een standaard-URL toe aan elke App Service toepassing als <default-appName>.<ASE-domain>.appserviceenvironment.net . Er wordt een privé-DNS-zone gemaakt waarmee de domein naam ASE wordt toegewezen aan het IP-adres van ASE ILB. Hiermee wordt voor komen dat een aangepaste DNS wordt gebruikt voor toegang tot de apps binnen het VNet.

De app-gateway is zo geconfigureerd dat een listener luistert op de HTTPS-poort voor aanvragen naar het IP-adres van de gateway. Ter vereenvoudiging maakt deze implementatie geen gebruik van een open bare DNS-naam registratie, en moet u het localhost-bestand op uw computer wijzigen om een wille keurig gekozen URL naar het IP-adres van de app-gateway te wijzen. Ter vereenvoudiging gebruikt de listener een zelfondertekend certificaat om deze aanvragen te verwerken. De app-gateway heeft back-endservers voor elke app service de standaard-URL van de toepassing. Een routerings regel is geconfigureerd om de listener te verbinden met de back-end-groep. Http-instellingen worden gemaakt die bepalen of de verbinding tussen de gateway en de ASE wordt versleuteld. Deze instellingen worden ook gebruikt voor het overschrijven van de binnenkomende HTTP-host-header met een hostnaam die is gekozen uit de back-end-pool. Deze implementatie maakt gebruik van standaard certificaten die zijn gemaakt voor de standaard-Url's van de ASE-app, die worden vertrouwd door de gateway. De aanvraag wordt omgeleid naar de standaard-URL van de bijbehorende app. De privé -DNS die aan het VNet is gekoppeld , stuurt deze aanvraag door naar het ILB-IP-adres. De ASE stuurt dit vervolgens door naar de aangevraagde app service. HTTP-communicatie in de ASE-apps, loopt via de privé-DNS. Houd er rekening mee dat de listener, de back-end-pool, de routerings regel en de HTTP-instellingen moeten worden geconfigureerd op de app-gateway voor elke ASE-app.

Verken appgw.jsop en dns.js aan om te begrijpen hoe deze configuraties worden uitgevoerd om meerdere sites toe te staan. De web-app testapp met de naam is een lege app die is gemaakt om deze configuratie te demonstreren. Deze JSON-bestanden zijn toegankelijk vanuit het implementatie script deploy_std. sh. Deze zijn ook toegankelijk via deploy_ha. sh, dat wordt gebruikt voor een ASE-implementatie met hoge Beschik baarheid.

Beveiligingsoverwegingen

App Service-omgeving

Een interne ASE wordt geïmplementeerd in het virtuele netwerk van de onderneming, verborgen op het open bare Internet. De onderneming kan de back-end-service, zoals web-Api's en-functies, op netwerk niveau vergren delen. Alle ASE-apps met een HTTP-eind punt kunnen worden geopend via de ILB, vanuit het virtuele netwerk. De app-gateway is geconfigureerd voor het door sturen van aanvragen naar de web-app via de ILB. De web-app zelf gaat via de ILB om toegang te krijgen tot de API. De essentiële back-end-onderdelen, dat wil zeggen, de API en de functie, zijn niet toegankelijk via het open bare Internet.

Voor elke app-service worden standaard certificaten gemaakt voor de standaard domeinnaam die wordt toegewezen door ASE. Dit certificaat kan de beveiliging van het verkeer tussen de gateway en de app verscherpen, en is mogelijk vereist in bepaalde scenario's. Deze certificaten zijn niet zichtbaar voor de client browser en kunnen alleen reageren op de certificaten die zijn geconfigureerd op de app-gateway.

App-gateway

Met de referentie-implementatie wordt de app-gateway via een programma geconfigureerd in de appgw.jsop. Het bestand deploy_std. sh gebruikt deze configuratie bij het implementeren van de gateway:

az deployment group create --resource-group $RGNAME --template-file templates/appgw.json --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

Versleuteling

Zoals beschreven in het overzicht van TLS-beëindiging en end-to-end TLS met Application Gateway, kan App gateway Transport Layer Security (TLS)/Secure Sockets Layer (SSL) gebruiken om al het verkeer van webbrowsers te versleutelen en te beveiligen. Versleuteling kan op de volgende manieren worden geconfigureerd:

  1. Versleuteling is beëindigd op de gateway. De back-end-Pools in dit geval zijn geconfigureerd voor HTTP. De versleuteling stopt bij de gateway en verkeer tussen de gateway en de app-service is niet-versleuteld. Omdat versleuteling CPU-intensief is, verbetert niet-versleuteld verkeer bij de back-end de prestaties en is eenvoudiger certificaat beheer mogelijk. Dit biedt een redelijk beveiligings niveau omdat de back-end is beveiligd op grond van de netwerk configuratie.

  2. End-to-end-versleuteling. In sommige scenario's, zoals specifieke beveiligings-of nalevings vereisten, is het mogelijk dat het verkeer tussen de gateway en de app moet worden versleuteld. Dit wordt bereikt met behulp van HTTPS-verbinding en het configureren van certificaten in de back-end-groep.

Deze referentie-implementatie maakt gebruik van zelfondertekende certificaten voor app gateway. Voor productie code moet een certificaat worden gebruikt dat is uitgegeven door een certificerings instantie . Lees certificaten die worden ondersteund voor het beëindigen van TLSvoor een lijst met ondersteunde certificaat typen. Lees een toepassings gateway met TLS-beëindiging configureren met behulp van de Azure Portal voor meer informatie over het maken van door de gateway beëindigde versleuteling. De volgende regels met code in de appgw.jsover het configureren van dit programma:

          {
            "name": "httpListeners",
            "count": "[length(parameters('appgwApplications'))]",
            "input": {
              "name": "[concat(variables('appgwListenerName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]",
              "properties": {
                "frontendIPConfiguration": {
                  "id": "[concat(variables('appgwId'), '/frontendIPConfigurations/', variables('appgwFrontendName'))]"
                },
                "frontendPort": {
                  "id": "[concat(variables('appgwId'), '/frontendPorts/port_443')]"
                },
                "protocol": "Https",
                "sslCertificate": {
                  "id": "[concat(variables('appgwId'), '/sslCertificates/', variables('appgwSslCertificateName'), parameters('appgwApplications')[copyIndex('httpListeners')].name)]"
                },
                "hostName": "[parameters('appgwApplications')[copyIndex('httpListeners')].hostName]",
                "requireServerNameIndication": true
              }
            }
          },

Voor verkeer tussen de web-apps op de ASE en de gateway worden de standaard SSL-certificaten gebruikt. De back-endservers in deze implementatie zijn geconfigureerd voor het omleiden van HTTPS-verkeer met de hostnaam die is overschreven door de standaard domein namen die zijn gekoppeld aan de web-apps. De app-gateway vertrouwt de standaard SSL-certificaten sinds deze zijn uitgegeven door micro soft. Lees app service met Application Gateway configureren om te weten hoe deze configuraties worden uitgevoerd. De volgende regels in de appgw.jsop weer geven hoe dit is geconfigureerd in de referentie-implementatie:

         {
            "name": "backendHttpSettingsCollection",
            "count": "[length(parameters('appgwApplications'))]",
            "input": {
              "name": "[concat(variables('appgwHttpSettingsName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]",
              "properties": {
                "Port": 443,
                "Protocol": "Https",
                "cookieBasedAffinity": "Disabled",
                "pickHostNameFromBackendAddress": true,
                "requestTimeout": 20,
                "probe": {
                  "id": "[concat(variables('appgwId'), '/probes/', variables('appgwHealthProbeName'), parameters('appgwApplications')[copyIndex('backendHttpSettingsCollection')].name)]"
                }
              }
            }
          },

Web Application Firewall

Web Application firewall (WAF) op de Application Gateway beschermt de web-apps tegen kwaad aardige aanvallen, zoals SQL-injectie. Het is ook geïntegreerd met Azure Monitor om aanvallen te bewaken met behulp van een real-time logboek. WAF moet worden ingeschakeld op de gateway, zoals beschreven in een toepassings gateway maken met een firewall voor webtoepassingen met behulp van de Azure Portal. Met de referentie-implementatie kan WAF programmatisch worden in de appgw.jsin het bestand met het volgende code fragment:

        "webApplicationFirewallConfiguration": {
          "enabled": true,
          "firewallMode": "Detection",
          "ruleSetType": "OWASP",
          "ruleSetVersion": "3.0"
        },

Virtual Network

Netwerk beveiligings groepen kunnen worden gekoppeld aan een of meer subnetten in het VNet. Dit zijn beveiligings regels waarmee verkeer tussen verschillende Azure-resources wordt toegestaan of geweigerd. Deze architectuur koppelt een afzonderlijke NSG voor elk subnet. Dit maakt het mogelijk om deze regels per subnet te verfijnen, afhankelijk van de service (s) die in dat subnet zijn opgenomen. Bekijk bijvoorbeeld de configuratie voor "type": "Microsoft.Network/networkSecurityGroups" in het bestand ase.jsop voor de NSG voor het subnet ASE en in het bestand appgw.jsop voor het subnet NSG for app gateway.

Met service-eind punten worden de persoonlijke adres ruimte en identiteit van uw VNet uitgebreid naar de ondersteuning van Azure-Services, waardoor de toegang tot deze services alleen kan worden beperkt tot uw VNet. Voor een betere beveiliging moeten service-eind punten zijn ingeschakeld in het ASE-subnet voor elke Azure-service die dit ondersteunt. De service kan vervolgens worden beveiligd met het VNet van de onderneming door de regels voor virtuele netwerken op de service in te stellen, waardoor de toegang van open bare Internet effectief wordt geblokkeerd. ASE-infra structuur stelt service-eind punten in voor Event hub, SQL Server en Storage, voor eigen beheer, zelfs als de architectuur zelf deze niet kan gebruiken, zoals vermeld in de sectie systeem architectuur van dit artikel. Deze architectuur configureert service-eind punten voor de gebruikte services, die ondersteuning bieden voor: Service Bus, SQL Server, Key Vault en CosmosDB. Verken deze configuratie in de ase.jsop, zoals "type": "Microsoft.Network/virtualNetworks/subnets" --> "properties" --> "serviceEndpoints" .

Het inschakelen van service-eind punten in een subnet is een proces dat uit twee stappen bestaat. De resources moeten worden geconfigureerd voor het ontvangen van verkeer op de service-eind punten van dit virtuele netwerk. Lees netwerk toegang tot een resource beperken voor meer informatie.

Firewall

Azure Firewall-en service-eind punten vormen een aanvulling op elkaar. Wanneer service-eind punten de resources beveiligen door het binnenkomende verkeer te beperken tot afkomstig van uw virtuele netwerk, kunt u met Azure Firewall het uitgaande verkeer van uw toepassingen beperken. U kunt het beste al het uitgaande verkeer laten passeren door het subnet van de firewall, inclusief verkeer van service-eind punten. Hierdoor kan het uitgaande verkeer beter worden bewaakt. ASE-infra structuur vereist echter service-eind punten voor SQL Server, opslag en Event Hubs worden geconfigureerd in het subnet ASE. Zie een app service Environment vergren delen voor discussies over Firewall integratie. Daarnaast maakt deze implementatie gebruik van CosmosDB in de modus directe verbinding. hiervoor moet een aantal poorten worden geopend. Dit kan de firewall configuratie bemoeilijken. Ter vereenvoudiging configureert deze referentie architectuur alle service-eind punten in het subnet ASE in plaats van het subnet van de firewall. Dit geldt ook voor eind punten voor Service Bus, CosmosDB en Key Vault, naast de vereisten van de ASE-infra structuur.

Zie Azure firewall configureren met uw ASE voor meer informatie over hoe firewall is geïntegreerd met de ASE. Verkeer dat niet gaat over de service-eind punten en de route tabel van het virtuele netwerk, wordt bewaakt en gegatedeerd door de firewall. De nood zaak van de route tabel wordt beschreven in de volgende sectie.

Ip's voor ASE-beheer

Het ASE-beheer verkeer loopt via het virtuele netwerk van de onderneming. Dit verkeer moet rechtstreeks naar de toegewezen IP-adressen buiten het virtuele netwerk worden gerouteerd, waardoor de firewall wordt voor komen. Dit wordt bereikt door een door de gebruiker gedefinieerde virtuele netwerk route tabelte maken. In het artikel app service Environment beheer adressen worden deze IP-adressen weer gegeven. Deze lijst kan te lang zijn om hand matig te worden geconfigureerd in de firewall. Deze implementatie laat zien hoe dit kan worden gevuld met een programma. De volgende regel in de deploy_std. sh haalt deze lijst op met behulp van Azure CLI en JQ, een opdracht regel JSON-parser:

ENDPOINTS_LIST=$(az rest --method get --uri $ASE_ID/inboundnetworkdependenciesendpoints?api-version=2016-09-01 | jq '.value[0].endpoints | join(", ")' -j)

Dit is gelijk aan de gedocumenteerde methode voor het ophalen van de beheer adressen van API.

Met de volgende opdrachten in de deploy_std. sh maakt u het virtuele netwerk samen met de route tabel, zoals geconfigureerd in de network.jsop:

VNET_NAME=$(az network vnet list -g $RGNAME --query "[?contains(addressSpace.addressPrefixes, '${NET_PREFIX}')]" --query [0].name -o tsv)
az deployment group create --resource-group $RGNAME --template-file templates/network.json --parameters existentVnetName=$VNET_NAME vnetAddressPrefix=$NET_PREFIX
VNET_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetName.value -o tsv)
VNET_ROUTE_NAME=$(az deployment group show -g $RGNAME -n network --query properties.outputs.vnetRouteName.value -o tsv)

Wanneer het ASE-subnet wordt gemaakt, wordt de route tabel eraan gekoppeld:

az deployment group create --resource-group $RGNAME --template-file templates/ase.json -n ase --parameters vnetName=$VNET_NAME vnetRouteName=$VNET_ROUTE_NAME aseSubnetAddressPrefix=$ASE_PREFIX

Wanneer de firewall is gemaakt, wordt deze route tabel door de firewall.jsin het configuratie bestand bijgewerkt met de ASE-beheer ip's, gevolgd door het IP-adres van de firewall. Hiermee wordt het resterende verkeer via het IP-adres van de firewall aangestuurd:

"variables": {
    "firewallSubnetName": "AzureFirewallSubnet",
    "firewallPublicIpName": "[concat('firewallIp', '-', uniqueString(resourceGroup().id))]",
    "firewallName": "[concat('firewall', '-', uniqueString(resourceGroup().id))]",
    "aseManagementEndpoints": "[split(replace(parameters('aseManagementEndpointsList') ,' ', ''), ',')]",
    "copy": [
      {
        "name": "aseManagementIpRoutes",
        "count": "[length(variables('aseManagementEndpoints'))]",
        "input": {
          "name": "[replace(variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')], '/', '-')]",
          "properties": {
            "addressPrefix": "[variables('aseManagementEndpoints')[copyIndex('aseManagementIpRoutes')]]",
            "nextHopType": "Internet"
          }
        }
      }
    ]
  },
  "resources": [
    {
      "type": "Microsoft.Network/routeTables",
      "apiVersion": "2019-11-01",
      "name": "[parameters('vnetRouteName')]",
      "location": "[parameters('location')]",
      "tags": {
        "displayName": "UDR - Subnet"
      },
      "dependsOn": [
        "[resourceId('Microsoft.Network/azureFirewalls', variables('firewallName'))]"
      ],
      "properties": {
        "routes": "[concat(variables('aseManagementIpRoutes'), array(json(concat('{ \"name\": \"Firewall\", \"properties\": { \"addressPrefix\": \"0.0.0.0/0\", \"nextHopType\": \"VirtualAppliance\", \"nextHopIpAddress\": \"', reference(concat('Microsoft.Network/azureFirewalls/', variables('firewallName')),'2019-09-01','Full').properties.ipConfigurations[0].properties.privateIPAddress, '\" } }'))))]"
      }
    },

De lijst met beheer-IP kan worden gewijzigd nadat de route tabel is geïmplementeerd. in dat geval moet deze route tabel opnieuw worden geïmplementeerd.

Azure Active Directory

Azure Active Directory biedt beveiligings functies voor het verifiëren van toepassingen en het machtigen van toegang tot resources. Deze referentie architectuur maakt gebruik van twee belang rijke functies van Azure Active Directory: beheerde identiteiten en toegangs beheer op basis van rollen.

Wanneer u Cloud toepassingen bouwt, moeten de referenties die nodig zijn om te worden geverifieerd bij Cloud Services, worden beveiligd. In het ideale geval worden de referenties nooit weer gegeven op werk stations voor ontwikkel aars of ingecheckt in broncode beheer. Azure Key Vault biedt een manier om veilig referenties en geheimen op te slaan, maar de app moet nog steeds worden geverifieerd bij Key Vault om deze op te halen. Beheerde identiteiten voor Azure-resources biedt Azure-Services met een automatisch beheerde identiteit in azure AD. Deze identiteit kan worden gebruikt om te verifiëren bij elke service die ondersteuning biedt voor Azure AD-verificatie, met inbegrip van Key Vault, zonder enige referenties in de toepassing.

Toegangs beheer op basis van rollen (Azure RBAC) van Azure beheert de toegang tot Azure-resources. Dit omvat:

  • welke entiteit heeft de toegang: gebruiker, beheerde identiteit, beveiligings-principal.
  • welk type toegang heeft: eigenaar, bijdrager, lezer, beheerder.
  • het bereik van de toegang: resource, resource groep, abonnement of beheer groep.

U kunt de toegang tot ASE-toepassingen vergren delen door de vereiste functie en het type toegang voor elke app nauw keurig te beheren. Op deze manier kunnen meerdere apps worden geïmplementeerd op dezelfde ASE van verschillende ontwikkel teams. De front-end kan bijvoorbeeld worden verwerkt door één team en de back-end door een andere. U kunt Azure RBAC gebruiken om de toegang van elk team te beperken tot de app (s) waaraan deze werkt. Verken aangepaste Azure-rollen om rollen te maken die geschikt zijn voor uw organisatie.

Key Vault

Sommige services ondersteunen beheerde identiteiten, maar ze gebruiken Azure RBAC om machtigingen voor de app in te stellen. Zie bijvoorbeeld Service Bus ingebouwde rollen, maar ook Azure RBAC in azure Cosmos DB. De toegang voor de eigenaar van het abonnement is vereist voor het verlenen van deze machtigingen, zelfs als personeel met Inzender toegang deze services kan implementeren. Om een breder team van ontwikkel aars in staat te stellen de implementatie scripts uit te voeren, is de volgende beste optie voor het gebruik van systeem eigen toegangs beheer beleid van de service:

De verbindings reeksen voor dit toegangs beheer beleid worden vervolgens opgeslagen in de Key Vault. De kluis zelf wordt geopend via beheerde identiteiten, waarvoor Azure RBAC niet is vereist. Stel het toegangs beleid voor deze verbindings reeksen op de juiste manier in. Bijvoorbeeld alleen-lezen voor de back-end, alleen-schrijven voor de front-end, enzovoort, in plaats van het standaard beleid voor basis toegang te gebruiken.

In het volgende code fragment in services.js vindt u de configuratie van de sleutel kluis voor deze services:

    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/CosmosKey')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.DocumentDB/databaseAccounts', variables('cosmosName'))]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.DocumentDB/databaseAccounts',variables('cosmosName')),'2015-04-08').primaryMasterKey]"
      }
    },
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/ServiceBusListenerConnectionString')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'ListenerSharedAccessKey')]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'ListenerSharedAccessKey'),'2015-08-01').primaryConnectionString]"
      }
    },
    {
      "type": "Microsoft.KeyVault/vaults/secrets",
      "name": "[concat(variables('keyVaultName'), '/ServiceBusSenderConnectionString')]",
      "apiVersion": "2015-06-01",
      "dependsOn": [
        "[resourceId('Microsoft.KeyVault/vaults', variables('keyVaultName'))]",
        "[resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules', variables('serviceBusName'), 'SenderSharedAccessKey')]"
      ],
      "properties": {
        "value": "[listKeys(resourceId('Microsoft.ServiceBus/namespaces/AuthorizationRules',variables('serviceBusName'),'SenderSharedAccessKey'),'2015-08-01').primaryConnectionString]"
      }
    },

Deze connection string waarden worden gebruikt door de apps door te verwijzen naar de Key Vault sleutel/waarde-paar. Dit doet u in het sites.js bestand als het volgende code fragment wordt weer gegeven voor de stem-app:

   "properties": {
        "enabled": true,
        "name": "[variables('votingWebName')]",
        "hostingEnvironment": "[variables('aseId')]",
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('votingWebPlanName'))]",
        "siteConfig": {
          "appSettings": [
            {
...
...
...
            {
              "name": "ConnectionStrings:sbConnectionString",
              "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('serviceBusSenderConnectionStringSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
            },
...
...
            {
              "name": "ConnectionStrings:RedisConnectionString",
              "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('redisSecretName')), '2016-10-01').secretUriWithVersion, ')')]"
            },
...
...
            {
              "name": "ConnectionStrings:CosmosKey",
              "value": "[concat('@Microsoft.KeyVault(SecretUri=', reference(resourceId('Microsoft.KeyVault/vaults/secrets', parameters('keyVaultName'), variables('cosmosKeySecretName')), '2016-10-01').secretUriWithVersion, ')')]"
            }

De functie opent ook de Service Bus listener connection string op een vergelijk bare manier.

Schaalbaarheidsoverwegingen

Schaal bare apps ontwerpen

De toepassing in deze referentie architectuur is gestructureerd, zodat afzonderlijke onderdelen kunnen worden geschaald op basis van gebruik. Elke web-app, API en functie wordt geïmplementeerd in een eigen App Service-abonnement. U kunt elke app controleren op prestatie knelpunten en deze vervolgens zo nodig schalen . Lees de schaal baarheid in een Azure-webtoepassing verbeteren voor meer informatie over het ontwerpen van schaal bare webtoepassingen met behulp van Azure app service.

App-gateway automatisch schalen

Automatisch schalen kan worden ingeschakeld op Azure-toepassing gateway v2. Hierdoor kan app gateway omhoog of omlaag worden geschaald op basis van de verkeers laad patronen. Deze referentie architectuur wordt geconfigureerd autoscaleConfiguration in het bestand appgw.jsop om te schalen tussen nul en tien extra exemplaren. Zie Application Gateway schalen en WAF v2 voor meer informatie.

Overwegingen bij de implementatie

De implementatie scripts in deze referentie architectuur worden gebruikt voor het implementeren van ASE, andere services en de toepassingen in de ASE. Zodra deze toepassingen zijn geïmplementeerd, willen ondernemingen mogelijk een plan maken voor continue integratie en implementatie voor het onderhoud en upgrades van apps. In deze sectie vindt u enkele van de algemene manieren waarop ontwikkel aars de CI/CD-ASE-toepassingen gebruiken.

Apps kunnen alleen in het virtuele netwerk worden geïmplementeerd voor een interne ASE. De volgende drie methoden worden veel gebruikt voor het implementeren van ASE-apps:

  1. Maak hand matig binnen het Virtual Network een virtuele machine in het ASE VNet met de vereiste hulpprogram ma's voor de implementatie. Open de RDP-verbinding met de virtuele machine met behulp van een NSG-configuratie. Kopieer uw code artefacten naar de VM, bouw en implementeer deze naar het ASE-subnet. Dit is een eenvoudige manier om een eerste ontwikkel omgeving in te stellen en te testen. Het wordt echter niet aanbevolen voor de productie omgeving, omdat de vereiste implementatie doorvoer niet kan worden geschaald.

  2. Punt-naar-site-verbinding vanaf het lokale werk station : Hiermee kunt u uw ASE VNet uitbreiden naar uw ontwikkel machine en vanaf daar implementeren. Dit is een andere manier om een eerste ontwikkel omgeving in te stellen en niet aanbevolen voor productie.

  3. Via Azure-pijp lijnen : Hiermee implementeert u een volledige CI/cd-pijp lijn, eindigend op een agent die zich in het VNet bevindt. Dit is ideaal voor productie omgevingen die een hoge door Voer van implementatie vereisen. De build-pijp lijn blijft volledig buiten het VNet. Met de Deploy-pijp lijn worden de gemaakte objecten gekopieerd naar de build-agent binnen het VNet en vervolgens geïmplementeerd in het ASE-subnet. Lees voor meer informatie deze discussie over de zelf-hostende bouw agent tussen pijp lijnen en het ASE VNet.

Het gebruik van Azure-pijp lijnen wordt aanbevolen voor productie omgevingen. Scripting CI/CD met behulp van het YAML-schema van Azure pipelines helpt de bouw-en implementatie processen te automatiseren. De Azure-pipelines. yml implementeert een dergelijke CI/cd-pijp lijn voor de web-app in deze referentie-implementatie. Er zijn Vergelijk bare CI/CD-scripts voor de Web-API en de functie. Lees Azure-pijp lijnen gebruiken voor meer informatie over hoe deze worden gebruikt voor het AUTOMATISEREN van CI/cd voor elke toepassing.

Het is mogelijk dat sommige ondernemingen geen permanente build-agent in het VNet willen houden. In dat geval kunt u ervoor kiezen om een build-agent in de DevOps-pijp lijn te maken en deze te verbreken zodra de implementatie is voltooid. Hiermee voegt u nog een stap toe aan de DevOps, maar deze verlaagt echter de complexiteit van het onderhoud van de virtuele machine. U kunt zelfs containers gebruiken als build-agents in plaats van Vm's. Bouw agenten kunnen ook volledig worden voor komen door te implementeren vanuit een zip-bestand dat buiten het VNet wordt geplaatst, meestal in een opslag account. Het opslag account moet toegankelijk zijn vanaf de ASE. De pijp lijn moet toegang hebben tot de opslag. Aan het einde van de release pijplijn kan een zip-bestand worden verwijderd naar de Blob-opslag. De ASE kan vervolgens worden gekozen en geïmplementeerd. Houd rekening met de volgende beperkingen van deze benadering:

  • Er is een verbreking van de verbinding tussen de DevOps en het daad werkelijke implementatie proces, wat leidt tot problemen bij het controleren en traceren van implementatie problemen.
  • In een vergrendelde omgeving met beveiligd verkeer moet u wellicht de regels wijzigen om toegang te krijgen tot het zip-bestand op de opslag.
  • U moet specifieke extensies en hulpprogram ma's op de ASE installeren om vanaf de zip te kunnen implementeren.

Als u meer wilt weten over de verschillende manieren waarop de apps kunnen worden geïmplementeerd in de App Service-abonnementen, leest u de app service artikelen die gericht zijn op implementatie strategieën.

Kostenoverwegingen

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Andere overwegingen worden beschreven in de sectie kosten in Microsoft Azure Well-Architected Framework. Azure-reserveringen helpen u geld te besparen door een toezegging te doen voor een abonnement van één of drie jaar voor veel Azure-resources. Meer informatie vindt u in het artikel een reserve ring kopen.

Hier volgen enkele punten waarmee u rekening moet houden voor een aantal van de belangrijkste services die in deze architectuur worden gebruikt.

App Service-omgeving

Er zijn diverse prijs opties beschikbaar voor app service. Een App Service omgeving wordt geïmplementeerd met behulp van het geïsoleerde service-abonnement. In dit plan zijn er drie opties voor CPU-grootten: i1, I2 en i3. Deze referentie-implementatie maakt gebruik van drie I1's per instantie.

Application Gateway

Application Gateway prijzen bieden diverse prijs opties voor app gateway. We gebruiken de Application Gateway Standard_v2 en WAF_V2 SKU, die ondersteuning biedt voor automatisch schalen en zone redundantie. Lees dit artikel voor meer informatie over het prijs model dat wordt gebruikt voor deze SKU.

Azure Cache voor Redis

Azure cache for redis prijzen biedt de diverse prijs opties voor deze service. Deze architectuur maakt gebruik van de Premium-SKU voor de ondersteuning van het virtuele netwerk.

Hieronder vindt u de prijs pagina's voor andere services die worden gebruikt voor het vergren delen van de ASE:

De oplossing implementeren

Als u de referentie-implementatie voor deze architectuur wilt implementeren, raadpleegt u het github Leesmij-bestanden volgt u het script voor de standaard implementatie.

Volgende stappen

Lees voor meer informatie over het uitbreiden van deze architectuur voor maximale Beschik baarheid de app-implementatie met hoge Beschik baarheid met app Services-omgeving.