Intégrer le service Gestion des API dans un réseau virtuel interne avec Application Gateway

  • Article

S’APPLIQUE À : Développeur | Premium

Vous pouvez configurer Gestion des API Azure dans un réseau virtuel en mode interne pour le rendre accessible uniquement au sein du réseau virtuel. Azure Application Gateway est une plateforme en tant que service (PaaS) qui agit comme un équilibreur de charge de couche 7. Il agit comme un service proxy inverse incluant Azure Web Application Firewall (WAF).

La combinaison du service Gestion des API approvisionné dans un réseau virtuel interne avec le service frontal Application Gateway offre les possibilités suivantes :

  • Utiliser la même ressource de gestion des API pour la consommation à la fois par les consommateurs internes et externes.
  • Utiliser une seule ressource de gestion des API et mettre à disposition un sous-ensemble d’API défini dans la gestion des API pour les consommateurs externes.
  • Fournir un moyen clé en main d’activer et désactiver l’accès au service Gestion des API à partir de l’Internet public.

Pour obtenir une aide relative à l’architecture, consultez :

Notes

Cet article a été mis à jour pour utiliser la référence SKU Application Gateway WAF_v2.

Prérequis

Notes

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour commencer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.

Pour suivre les étapes décrites dans cet article, vous devez disposer des éléments suivants :

  • Un abonnement Azure actif

    Si vous n’avez pas d’abonnement Azure, créez un compte gratuit Azure avant de commencer.

  • Certificats

    • Fichiers PFX (Personal Information Exchange) pour les noms d’hôte personnalisés de Gestion des API : passerelle, portail des développeurs et point de terminaison de gestion.
    • Fichier CER (Certificat) pour le certificat racine des certificats PFX.

    Pour plus d’informations, consultez Certificats pour le back end. À des fins de test, vous pouvez générer des certificats auto-signés.

  • La version la plus récente d’Azure PowerShell

Scénario

Cet article montre comment utiliser une seul et même instance Gestion des API pour les consommateurs internes et externes, faisant office de serveur frontal unique pour les API locales et cloud. Vous allez créer une instance Gestion des API du type version 2 à locataire unique (stv2) plus récent. Vous allez apprendre à utiliser des écouteurs publics et privés dans Application Gateway. Vous allez apprendre à exposer uniquement un sous-ensemble de vos API pour la consommation externe à l’aide des fonctionnalités de routage disponibles dans Application Gateway. Dans l’exemple, les API sont mises en surbrillance en vert.

Dans le premier exemple de configuration, toutes vos API sont gérées uniquement à partir de votre réseau virtuel. Les consommateurs internes peuvent accéder à toutes vos API internes et externes. Le trafic ne sort jamais vers Internet. Une connectivité haute performance peut être fournie via des circuits Azure ExpressRoute. Dans l’exemple, les consommateurs internes sont mis en surbrillance en orange.

Diagramme montrant la route d’URL.

Que faut-il pour intégrer les services Gestion des API et Application Gateway ?

  • Pool de serveurs principaux : ce pool de serveurs correspond à l’adresse IP virtuelle interne de Gestion des API.
  • Paramètres du pool de serveurs principaux : Chaque pool dispose de paramètres tels que le port, le protocole et l’affinité en fonction des cookies. Ces paramètres sont appliqués à tous les serveurs du pool.
  • Port frontal : ce port public est ouvert sur la passerelle applicative. Le trafic l’atteignant est redirigé vers l’un des serveurs principaux.
  • Écouteur : l’écouteur dispose d’un port front-end, d’un protocole (HTTP ou HTTPS ; valeurs sensibles à la casse) et du nom du certificat TLS (Transport Layer Security) en cas de configuration du déchargement TLS.
  • Règle : la règle relie un écouteur à un pool de serveurs principaux.
  • Sonde d’intégrité personnalisée : par défaut, Application Gateway, utilise des sondes basées sur des adresses IP pour déterminer les serveurs actifs dans BackendAddressPool. Gestion des API répond uniquement aux requêtes avec l’en-tête d’hôte est correct. Par conséquent, les sondes par défaut échouent. Vous définissez une sonde d’intégrité personnalisée pour aider la passerelle applicative à déterminer que le service est actif et doit transférer les requêtes.
  • Certificats de domaine personnalisés : pour accéder à Gestion des API à partir d’Internet, créez des enregistrements DNS (Domain Name System) pour mapper ses noms d’hôte à l’adresse IP frontal d’Application Gateway. Ce mappage veille à ce que l’en-tête de l’hôte et le certificat envoyé à la gestion des API soient valides. Dans cet exemple, nous allons utiliser trois certificats. Ils sont destinés à la passerelle de Gestion des API (principal), au portail des développeurs et au point de terminaison de gestion.

Exposer le portail des développeurs et le point de terminaison de gestion en externe via Application Gateway

Dans cet article, nous allons également exposer le portail des développeurset le point de terminaison de gestion à un public extérieur via la passerelle applicative. Des étapes supplémentaires sont nécessaires pour créer un écouteur, une sonde, des paramètres et des règles pour chaque point de terminaison. Tous les détails sont fournis dans leurs étapes respectives.

Si vous utilisez Microsoft Entra ID ou une authentification tierce, activez la fonctionnalité d’affinité de session basée sur les cookies dans Application Gateway.

Avertissement

Pour empêcher le WAF Application Gateway d’interrompre le téléchargement des spécifications OpenAPI dans le portail des développeurs, désactivez la règle de pare-feu 942200 - "Detects MySQL comment-/space-obfuscated injections and backtick termination".

Les règles du WAF Application Gateway pouvant affecter la fonctionnalité du portail sont les suivantes :

  • 920300, 920330, 931130, 942100, 942110, 942180, 942200, 942260, 942340, 942370 pour le mode administratif
  • 942200, 942260, 942370, 942430, 942440 pour le portail publié

Définition des variables

Vous allez devoir définir plusieurs variables tout au long de ce guide. L’affectation de noms est basée sur les instructions d’abréviation de Cloud Adoption Framework.

# These variables must be changed.
$subscriptionId = "00000000-0000-0000-0000-000000000000"      # GUID of your Azure subscription
$domain = "contoso.net"                                       # The custom domain for your certificate
$apimServiceName = "apim-contoso"                             # API Management service instance name, must be globally unique    
$apimDomainNameLabel = $apimServiceName                       # Domain name label for API Management's public IP address, must be globally unique
$apimAdminEmail = "admin@contoso.net"                         # Administrator's email address - use your email address

$gatewayHostname = "api.$domain"                              # API gateway host
$portalHostname = "portal.$domain"                            # API developer portal host
$managementHostname = "management.$domain"                    # API management endpoint host

$baseCertPath = "C:\Users\Contoso\"                           # The base path where all certificates are stored
$trustedRootCertCerPath = "${baseCertPath}trustedroot.cer"    # Full path to contoso.net trusted root .cer file
$gatewayCertPfxPath = "${baseCertPath}gateway.pfx"            # Full path to api.contoso.net .pfx file
$portalCertPfxPath = "${baseCertPath}portal.pfx"              # Full path to portal.contoso.net .pfx file
$managementCertPfxPath = "${baseCertPath}management.pfx"      # Full path to management.contoso.net .pfx file

$gatewayCertPfxPassword = "certificatePassword123"            # Password for api.contoso.net pfx certificate
$portalCertPfxPassword = "certificatePassword123"             # Password for portal.contoso.net pfx certificate
$managementCertPfxPassword = "certificatePassword123"         # Password for management.contoso.net pfx certificate

# These variables may be changed.
$resGroupName = "rg-apim-agw"                                 # Resource group name that will hold all assets
$location = "West US"                                         # Azure region that will hold all assets
$apimOrganization = "Contoso"                                 # Organization name    
$appgwName = "agw-contoso"                                    # The name of the Application Gateway

Créer un groupe de ressources pour Resource Manager

Pour créer un groupe de ressources pour Azure Resource Manager :

  1. Connectez-vous à Azure.

    Connect-AzAccount

  2. Authentifiez-vous à l’aide de vos informations d’identification.

  3. Sélectionnez l’abonnement de votre choix.

    Get-AzSubscription -Subscriptionid $subscriptionId | Select-AzSubscription

  4. Créez un groupe de ressources. Ignorez cette étape si vous utilisez un groupe de ressources existant.

    New-AzResourceGroup -Name $resGroupName -Location $location

Resource Manager requiert que tous les groupes de ressources spécifient un emplacement. Celui-ci est utilisé comme emplacement par défaut pour les ressources de ce groupe de ressources. Assurez-vous que toutes les commandes pour la création d'une passerelle Application Gateway utiliseront le même groupe de ressources.

Créer un réseau virtuel et un sous-réseau pour la passerelle Application Gateway

L’exemple ci-après indique comment créer un réseau virtuel à l’aide de Resource Manager. Dans cet exemple, le réseau virtuel se compose de sous-réseaux distincts pour les services Application Gateway et Gestion des API.

  1. Définissez les adresses IP Application Gateway.

    Remarque

    Comme il y aura des écouteurs publics et privés, nous avons besoin d’une adresse IP publique et privée. L’adresse IP publique statique doit être créée, tandis que l’adresse IP privée doit être sélectionnée à partir du sous-réseau associé à la passerelle applicative. L’adresse IP privée a été sélectionnée arbitrairement.

    $appGatewayExternalIP = New-AzPublicIpAddress -ResourceGroupName $resGroupName -name "pip-ag" -location $location -AllocationMethod Static -Sku Standard -Force
$appGatewayInternalIP = "10.0.0.100"

[String[]]$appGwNsgDestIPs = $appGatewayInternalIP, $appGatewayExternalIP.IpAddress

  2. Créez un groupe de sécurité réseau (NSG) et des règles de groupe de sécurité réseau pour le sous-réseau Application Gateway.

    $appGwRule1 = New-AzNetworkSecurityRuleConfig -Name appgw-in -Description "AppGw inbound" `
    -Access Allow -Protocol * -Direction Inbound -Priority 100 -SourceAddressPrefix `
    GatewayManager -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 65200-65535

$appGwRule2 = New-AzNetworkSecurityRuleConfig -Name appgw-in-internet -Description "AppGw inbound Internet" `
    -Access Allow -Protocol "TCP" -Direction Inbound -Priority 110 -SourceAddressPrefix `
    Internet -SourcePortRange * -DestinationAddressPrefix $appGwNsgDestIPs -DestinationPortRange 443

$appGwNsg = New-AzNetworkSecurityGroup -ResourceGroupName $resGroupName -Location $location -Name `
    "nsg-agw" -SecurityRules $appGwRule1, $appGwRule2

  3. Créez un groupe de sécurité réseau (NSG) et des règles de groupe de sécurité réseau pour le sous-réseau Gestion des API. La Gestion des API stv2 nécessite plusieurs règles NSG spécifiques.

    $apimRule1 = New-AzNetworkSecurityRuleConfig -Name APIM-Management -Description "APIM inbound" `
    -Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix ApiManagement `
    -SourcePortRange * -DestinationAddressPrefix VirtualNetwork -DestinationPortRange 3443

$apimRule2 = New-AzNetworkSecurityRuleConfig -Name AllowAppGatewayToAPIM -Description "Allows inbound App Gateway traffic to APIM" `
    -Access Allow -Protocol Tcp -Direction Inbound -Priority 110 -SourceAddressPrefix "10.0.0.0/24" `
    -SourcePortRange * -DestinationAddressPrefix "10.0.1.0/24" -DestinationPortRange 443

$apimRule3 = New-AzNetworkSecurityRuleConfig -Name AllowAzureLoadBalancer -Description "Allows inbound Azure Infrastructure Load Balancer traffic to APIM" `
    -Access Allow -Protocol Tcp -Direction Inbound -Priority 120 -SourceAddressPrefix AzureLoadBalancer `
    -SourcePortRange * -DestinationAddressPrefix "10.0.1.0/24" -DestinationPortRange 6390

$apimRule4 = New-AzNetworkSecurityRuleConfig -Name AllowKeyVault -Description "Allows outbound traffic to Azure Key Vault" `
    -Access Allow -Protocol Tcp -Direction Outbound -Priority 100 -SourceAddressPrefix "10.0.1.0/24" `
    -SourcePortRange * -DestinationAddressPrefix AzureKeyVault -DestinationPortRange 443

$apimNsg = New-AzNetworkSecurityGroup -ResourceGroupName $resGroupName -Location $location -Name `
    "nsg-apim" -SecurityRules $apimRule1, $apimRule2, $apimRule3, $apimRule4

  4. Affectez la plage d’adresses 10.0.0.0/24 à la variable de sous-réseau à utiliser pour le service Application Gateway lorsque vous créez un réseau virtuel.

    $appGatewaySubnet = New-AzVirtualNetworkSubnetConfig -Name "appGatewaySubnet" -NetworkSecurityGroup $appGwNsg -AddressPrefix "10.0.0.0/24"

  5. Affectez la plage d’adresses 10.0.1.0/24 à la variable de sous-réseau à utiliser pour le service Gestion des API lorsque vous créez un réseau virtuel.

    $apimSubnet = New-AzVirtualNetworkSubnetConfig -Name "apimSubnet" -NetworkSecurityGroup $apimNsg -AddressPrefix "10.0.1.0/24"

  6. Créez un réseau virtuel nommé vnet-contoso. Utilisez le préfixe 10.0.0.0/16 avec les sous-réseaux 10.0.0.0/24 et 10.0.1.0/24.

    $vnet = New-AzVirtualNetwork -Name "vnet-contoso" -ResourceGroupName $resGroupName `
  -Location $location -AddressPrefix "10.0.0.0/16" -Subnet $appGatewaySubnet,$apimSubnet

  7. Attribuez des variables de sous-réseau pour les étapes suivantes.

    $appGatewaySubnetData = $vnet.Subnets[0]
$apimSubnetData = $vnet.Subnets[1]

Créer une instance Gestion des API au sein d’un réseau virtuel

L’exemple suivant montre comment créer une instance Gestion des API dans un réseau virtuel configuré pour un accès interne uniquement.

  1. La Gestion des API stv2 nécessite une adresse IP publique avec un DomainNameLabel unique.

    $apimPublicIpAddressId = New-AzPublicIpAddress -ResourceGroupName $resGroupName -name "pip-apim" -location $location `
    -AllocationMethod Static -Sku Standard -Force -DomainNameLabel $apimDomainNameLabel

  2. Créez un objet réseau virtuel du service Gestion des API à l’aide du sous-réseau $apimSubnetData que vous avez créé.

    $apimVirtualNetwork = New-AzApiManagementVirtualNetwork -SubnetResourceId $apimSubnetData.Id

  3. Créez une instance Gestion des API au sein du réseau virtuel. Cet exemple crée le service dans le niveau de service Développeur. Spécifiez un nom unique pour votre instance Gestion des API.

    $apimService = New-AzApiManagement -ResourceGroupName $resGroupName -Location $location -Name $apimServiceName -Organization $apimOrganization `
    -AdminEmail $apimAdminEmail -VirtualNetwork $apimVirtualNetwork -VpnType "Internal" -Sku "Developer" -PublicIpAddressId $apimPublicIpAddressId.Id

La création et l’activation d’une instance Gestion des API à ce niveau peuvent prendre entre 30 et 40 minutes. Une fois la commande précédente exécutée, pour confirmer l’accès, consultez Configuration DNS requise pour accéder au service Gestion des API du réseau virtuel interne.

Configurer des noms de domaine personnalisés dans le service Gestion des API

Pour configurer des noms de domaine personnalisés dans le service Gestion des API :

  1. Initialisez les variables suivantes avec les détails des certificats incluant des clés privées pour les domaines et le certificat racine approuvé. Dans cet exemple, nous utilisons api.contoso.net, portal.contoso.net et management.contoso.net.

    $certGatewayPwd = ConvertTo-SecureString -String $gatewayCertPfxPassword -AsPlainText -Force
$certPortalPwd = ConvertTo-SecureString -String $portalCertPfxPassword -AsPlainText -Force
$certManagementPwd = ConvertTo-SecureString -String $managementCertPfxPassword -AsPlainText -Force

  2. Créez et définissez les objets de configuration de Hostname pour les points de terminaison de Gestion des API.

    $gatewayHostnameConfig = New-AzApiManagementCustomHostnameConfiguration -Hostname $gatewayHostname `
  -HostnameType Proxy -PfxPath $gatewayCertPfxPath -PfxPassword $certGatewayPwd

$portalHostnameConfig = New-AzApiManagementCustomHostnameConfiguration -Hostname $portalHostname `
  -HostnameType DeveloperPortal -PfxPath $portalCertPfxPath -PfxPassword $certPortalPwd

$managementHostnameConfig = New-AzApiManagementCustomHostnameConfiguration -Hostname $managementHostname `
  -HostnameType Management -PfxPath $managementCertPfxPath -PfxPassword $certManagementPwd

$apimService.ProxyCustomHostnameConfiguration = $gatewayHostnameConfig
$apimService.PortalCustomHostnameConfiguration = $portalHostnameConfig
$apimService.ManagementCustomHostnameConfiguration = $managementHostnameConfig

Set-AzApiManagement -InputObject $apimService

Configurer une zone privée pour la résolution DNS dans le réseau virtuel

Pour configurer une zone DNS privée pour la résolution DNS dans le réseau virtuel :

  1. Créez une zone DNS privée et liez le réseau virtuel.

    $myZone = New-AzPrivateDnsZone -Name $domain -ResourceGroupName $resGroupName

$link = New-AzPrivateDnsVirtualNetworkLink -ZoneName $domain `
  -ResourceGroupName $resGroupName -Name "mylink" `
  -VirtualNetworkId $vnet.id

  2. Créez des enregistrements A pour les noms d’hôte de domaine personnalisés mappés à l’adresse IP privée de Gestion des API.

    $apimIP = $apimService.PrivateIPAddresses[0]

New-AzPrivateDnsRecordSet -Name api -RecordType A -ZoneName $domain `
  -ResourceGroupName $resGroupName -Ttl 3600 `
  -PrivateDnsRecords (New-AzPrivateDnsRecordConfig -IPv4Address $apimIP)

New-AzPrivateDnsRecordSet -Name portal -RecordType A -ZoneName $domain `
  -ResourceGroupName $resGroupName -Ttl 3600 `
  -PrivateDnsRecords (New-AzPrivateDnsRecordConfig -IPv4Address $apimIP)

New-AzPrivateDnsRecordSet -Name management -RecordType A -ZoneName $domain `
  -ResourceGroupName $resGroupName -Ttl 3600 `
  -PrivateDnsRecords (New-AzPrivateDnsRecordConfig -IPv4Address $apimIP)

Créer une configuration de passerelle Application Gateway

Tous les éléments de configuration doivent être installés avant de créer la passerelle Application Gateway. Les étapes suivantes permettent de créer les éléments de configuration nécessaires à une ressource Application Gateway.

  1. Créez une configuration IP de passerelle Application Gateway nommée gatewayIP01. Au démarrage, la passerelle Application Gateway sélectionne une adresse IP du sous-réseau configuré et achemine le trafic réseau vers les adresses IP du pool IP principal. Gardez à l’esprit que chaque instance utilise une adresse IP unique.

    $gipconfig = New-AzApplicationGatewayIPConfiguration -Name "gatewayIP01" -Subnet $appGatewaySubnetData

  2. Configurez le même port frontal pour le point de terminaison IP public et privé. Ce port est celui auquel les utilisateurs se connectent. En utilisant le même port, nous nous assurons que les requêtes internes et externes peuvent être effectuées sur le même port.

    $fp01 = New-AzApplicationGatewayFrontendPort -Name "port01"  -Port 443

  3. Configurez deux adresses IP frontales : une adresse publique et une privée. L’adresse IP privée est extraite du sous-réseau de passerelle d’application, qui a été la première à être créée à l’index 0.

    $fipconfig01 = New-AzApplicationGatewayFrontendIPConfig `
  -Name "gateway-public-ip" -PublicIPAddress $appGatewayExternalIP

$fipconfig02 = New-AzApplicationGatewayFrontendIPConfig `
  -Name "gateway-private-ip" -PrivateIPAddress $appGatewayInternalIP `
  -Subnet $vnet.Subnets[0]

  4. Configurez les certificats pour la passerelle applicative. Ils sont utilisés pour déchiffrer et rechiffrer le trafic qui y transite.

    Notes

    Application Gateway prend en charge la définition d’options TLS personnalisées, la désactivation de certaines versions du protocole TLS et la spécification de suites de chiffrement et de l’ordre de préférence. Pour en savoir plus sur les options TLS configurables, consultez cette vue d’ensemble de la stratégie TLS.

    $certGateway = New-AzApplicationGatewaySslCertificate -Name "gatewaycert" `
  -CertificateFile $gatewayCertPfxPath -Password $certGatewayPwd

$certPortal = New-AzApplicationGatewaySslCertificate -Name "portalcert" `
  -CertificateFile $portalCertPfxPath -Password $certPortalPwd

$certManagement = New-AzApplicationGatewaySslCertificate -Name "managementcert" `
  -CertificateFile $managementCertPfxPath -Password $certManagementPwd

  5. Créez les écouteurs HTTP pour la passerelle applicative. Affectez-leur la configuration IP front-end, le port et les certificats TLS/SSL.

    # Public/external listeners
$gatewayListener = New-AzApplicationGatewayHttpListener -Name "gatewaylistener" `
  -Protocol "Https" -FrontendIPConfiguration $fipconfig01 -FrontendPort $fp01 `
  -SslCertificate $certGateway -HostName $gatewayHostname -RequireServerNameIndication true

$portalListener = New-AzApplicationGatewayHttpListener -Name "portallistener" `
  -Protocol "Https" -FrontendIPConfiguration $fipconfig01 -FrontendPort $fp01 `
  -SslCertificate $certPortal -HostName $portalHostname -RequireServerNameIndication true

$managementListener = New-AzApplicationGatewayHttpListener -Name "managementlistener" `
  -Protocol "Https" -FrontendIPConfiguration $fipconfig01 -FrontendPort $fp01 `
  -SslCertificate $certManagement -HostName $managementHostname -RequireServerNameIndication true

# Private/internal listeners
$gatewayListenerPrivate = New-AzApplicationGatewayHttpListener -Name "gatewaylistener-private" `
  -Protocol "Https" -FrontendIPConfiguration $fipconfig02 -FrontendPort $fp01 `
  -SslCertificate $certGateway -HostName $gatewayHostname -RequireServerNameIndication true

$portalListenerPrivate = New-AzApplicationGatewayHttpListener -Name "portallistener-private" `
  -Protocol "Https" -FrontendIPConfiguration $fipconfig02 -FrontendPort $fp01 `
  -SslCertificate $certPortal -HostName $portalHostname -RequireServerNameIndication true

$managementListenerPrivate = New-AzApplicationGatewayHttpListener -Name "managementlistener-private" `
  -Protocol "Https" -FrontendIPConfiguration $fipconfig02 -FrontendPort $fp01 `
  -SslCertificate $certManagement -HostName $managementHostname -RequireServerNameIndication true

  6. Créez des sondes personnalisées sur le point de terminaison de domaine de la passerelle ContosoApi de Gestion des API. Le chemin d’accès /status-0123456789abcdef est un point de terminaison d’intégrité par défaut hébergé sur toutes les instances de Gestion des API. Définissez api.contoso.net comme nom d’hôte de sonde personnalisée pour la sécuriser à l’aide du certificat TLS/SSL.

    Notes

    Le nom d’hôte contosoapi.azure-api.net est le nom d’hôte du proxy par défaut configuré lorsqu’un service nommé contosoapi est créé dans la version publique d’Azure.

    $apimGatewayProbe = New-AzApplicationGatewayProbeConfig -Name "apimgatewayprobe" `
  -Protocol "Https" -HostName $gatewayHostname -Path "/status-0123456789abcdef" `
  -Interval 30 -Timeout 120 -UnhealthyThreshold 8

$apimPortalProbe = New-AzApplicationGatewayProbeConfig -Name "apimportalprobe" `
  -Protocol "Https" -HostName $portalHostname -Path "/signin" `
  -Interval 60 -Timeout 300 -UnhealthyThreshold 8

$apimManagementProbe = New-AzApplicationGatewayProbeConfig -Name "apimmanagementprobe" `
  -Protocol "Https" -HostName $managementHostname -Path "/ServiceStatus" `
  -Interval 60 -Timeout 300 -UnhealthyThreshold 8

  7. Configurez le certificat racine approuvé des certificats backend. Ce certificat vérifie l’authenticité des certificats backend.

    $trustedRootCert = New-AzApplicationGatewayTrustedRootCertificate `
  -Name "allowlistcert1" -CertificateFile $trustedRootCertCerPath

  8. Configurez les paramètres du serveur backend HTTP pour la passerelle applicative, y compris une limite de délai d’expiration pour les demandes du serveur backend, au-delà de laquelle elles sont annulées. Cette valeur diffère du délai d’expiration de la sonde.

    $apimPoolGatewaySetting = New-AzApplicationGatewayBackendHttpSettings -Name "apimPoolGatewaySetting" `
  -Port 443 -Protocol "Https" -CookieBasedAffinity "Disabled" -Probe $apimGatewayProbe `
  -TrustedRootCertificate $trustedRootCert -PickHostNameFromBackendAddress -RequestTimeout 180

$apimPoolPortalSetting = New-AzApplicationGatewayBackendHttpSettings -Name "apimPoolPortalSetting" `
  -Port 443 -Protocol "Https" -CookieBasedAffinity "Disabled" -Probe $apimPortalProbe `
  -TrustedRootCertificate $trustedRootCert -PickHostNameFromBackendAddress -RequestTimeout 180

$apimPoolManagementSetting = New-AzApplicationGatewayBackendHttpSettings -Name "apimPoolManagementSetting" `
  -Port 443 -Protocol "Https" -CookieBasedAffinity "Disabled" -Probe $apimManagementProbe `
  -TrustedRootCertificate $trustedRootCert -PickHostNameFromBackendAddress -RequestTimeout 180

  9. Configurez un pool d’adresses IP backend pour chaque point de terminaison de gestion des API à l’aide de son nom de domaine respectif.

    $apimGatewayBackendPool = New-AzApplicationGatewayBackendAddressPool -Name "gatewaybackend" `
  -BackendFqdns $gatewayHostname

$apimPortalBackendPool = New-AzApplicationGatewayBackendAddressPool -Name "portalbackend" `
  -BackendFqdns $portalHostname

$apimManagementBackendPool = New-AzApplicationGatewayBackendAddressPool -Name "managementbackend" `
  -BackendFqdns $managementHostname

  10. Créez des règles de routage pour que la passerelle applicative utilise le routage de base.

    # Public/external gateway rules
$gatewayRule = New-AzApplicationGatewayRequestRoutingRule -Name "gatewayrule" `
  -RuleType Basic -HttpListener $gatewayListener -BackendAddressPool $apimGatewayBackendPool `
  -BackendHttpSettings $apimPoolGatewaySetting -Priority 10

$portalRule = New-AzApplicationGatewayRequestRoutingRule -Name "portalrule" `
  -RuleType Basic -HttpListener $portalListener -BackendAddressPool $apimPortalBackendPool `
  -BackendHttpSettings $apimPoolPortalSetting -Priority 20

$managementRule = New-AzApplicationGatewayRequestRoutingRule -Name "managementrule" `
  -RuleType Basic -HttpListener $managementListener -BackendAddressPool $apimManagementBackendPool `
  -BackendHttpSettings $apimPoolManagementSetting -Priority 30

# Private/internal gateway rules
$gatewayRulePrivate = New-AzApplicationGatewayRequestRoutingRule -Name "gatewayrule-private" `
  -RuleType Basic -HttpListener $gatewayListenerPrivate -BackendAddressPool $apimGatewayBackendPool `
  -BackendHttpSettings $apimPoolGatewaySetting -Priority 11

$portalRulePrivate = New-AzApplicationGatewayRequestRoutingRule -Name "portalrule-private" `
  -RuleType Basic -HttpListener $portalListenerPrivate -BackendAddressPool $apimPortalBackendPool `
  -BackendHttpSettings $apimPoolPortalSetting -Priority 21

$managementRulePrivate = New-AzApplicationGatewayRequestRoutingRule -Name "managementrule-private" `
  -RuleType Basic -HttpListener $managementListenerPrivate -BackendAddressPool $apimManagementBackendPool `
  -BackendHttpSettings $apimPoolManagementSetting -Priority 31

    Conseil

    Modifiez -RuleType et le routage afin de limiter l’accès à certaines pages du portail des développeurs.

  11. Configurez le nombre d’instances et taille de la passerelle Application Gateway. Dans cet exemple, nous utilisons la référence SKU WAF_v2 pour une sécurité accrue de la ressource Gestion des API.

    Utilisez un minimum de deux instances (Capacité) pour les charges de travail de production. Vous pouvez utiliser une seule instance pour les scénarios de non-production ou pour l’expérimentation générale. Pour plus d’informations, consultez Tarification d’Azure Application Gateway.

    $sku = New-AzApplicationGatewaySku -Name "WAF_v2" -Tier "WAF_v2" -Capacity 2

  12. Configurez le mode WAF.

    Conseil

    Pendant une courte période durant la configuration et pour tester vos règles de pare-feu, vous pouvez configurer le mode « Détection », qui surveille et journalise les alertes de menace, sans bloquer le trafic. Vous pouvez ensuite effectuer toutes les mises à jour des règles de pare-feu avant de passer au mode « Prévention », qui bloque les intrusions et attaques détectées par les règles.

    $config = New-AzApplicationGatewayWebApplicationFirewallConfiguration -Enabled $true -FirewallMode "Prevention"

  13. Étant donné que TLS 1.0 est actuellement la valeur par défaut, configurez la passerelle applicative pour utiliser une des stratégies TLS 1.2 les plus récentes.

    $policy = New-AzApplicationGatewaySslPolicy -PolicyType Predefined -PolicyName AppGwSslPolicy20220101

Créer une passerelle Application Gateway

  1. Créez une passerelle applicative avec tous les objets de configuration des étapes précédentes. La création d’une instance peut prendre 15 minutes.

    $appgw = New-AzApplicationGateway `
  -Name $appgwName `
  -ResourceGroupName $resGroupName `
  -Location $location `
  -Sku $sku `
  -SslPolicy $policy `
  -SslCertificates $certGateway, $certPortal, $certManagement `
  -TrustedRootCertificate $trustedRootCert `
  -BackendAddressPools $apimGatewayBackendPool, $apimPortalBackendPool, $apimManagementBackendPool `
  -BackendHttpSettingsCollection $apimPoolGatewaySetting, $apimPoolPortalSetting, $apimPoolManagementSetting `
  -GatewayIpConfigurations $gipconfig `
  -FrontendIpConfigurations $fipconfig01, $fipconfig02 `
  -FrontendPorts $fp01 `
  -HttpListeners $gatewayListener, $portalListener, $managementListener, $gatewayListenerPrivate, $portalListenerPrivate, $managementListenerPrivate `
  -RequestRoutingRules $gatewayRule, $portalRule, $managementRule, $gatewayRulePrivate, $portalRulePrivate, $managementRulePrivate `
  -Probes $apimGatewayProbe, $apimPortalProbe, $apimManagementProbe `
  -WebApplicationFirewallConfig $config

  2. Vérifiez l’état d’intégrité du serveur backend de gestion des API.

    Get-AzApplicationGatewayBackendHealth -Name $appgwName -ResourceGroupName $resGroupName

Assurez-vous que l’état d’intégrité de chaque pool principal est sain. Si vous devez dépanner un serveur principal non sain ou un serveur principal dont l’état d’intégrité est inconnu, consultez Résoudre les problèmes d’intégrité des back-ends dans Application Gateway.

Créer des enregistrements DNS pour accéder aux points de terminaison Gestion des API à partir d’internet

Une fois la passerelle applicative créée, configurez la communication pour la gestion des API à partir d’internet. Créez des enregistrements DNS A qui mappent chacun des noms d’hôtes de point de terminaison Gestion des API que vous avez configurés à l’adresse IP publique statique de la passerelle d’application. Dans cet article, les exemples de noms d’hôte sont api.contoso.net, portal.contoso.net et management.contoso.net.

Vérification de la connectivité

En guise de test rapide, vous pouvez éventuellement temporairement modifier le fichier hosts de votre ordinateur avec des entrées qui mappent l’adresse IP publique de la passerelle d’application aux noms d’hôte de point de terminaison de gestion des API :

  1. Modifiez les fichiers hosts. Par exemple, si l’adresse IP publique de la passerelle d’application est 172.203.129.101, l’entrée peut être 172.203.129.101 api.contoso.net.
  2. Exécutez une commande curl sur le point de terminaison d’état de gestion des API (le même chemin utilisé pour la sonde d’intégrité précédemment) : curl -v https://api.contoso.net/status-0123456789abcdef Cela doit renvoyer un état 200 Service Operational , ce qui indique une communication réussie avec la gestion des API via Application Gateway.

Considérations relatives au DNS

Application Gateway dispose désormais de voies privées et publiques. L’utilisation des mêmes domaines et ports crée une situation DNS fractionnée dans laquelle un programme de résolution DNS externe doit être défini pour résoudre api.contoso.net à l’adresse IP externe de la passerelle d’application, tandis qu’un programme de résolution DNS interne doit résoudre le même domaine à l’adresse IP interne de la passerelle d’application. Cette configuration a un véritable avantage, c’est-à-dire que les applications n’ont pas besoin de modifier le domaine ou le port pour le ciblage interne ou externe d’applications et d’API. La responsabilité du ciblage est correctement différée aux résolveurs DNS.

Résumé

Le service Gestion des API configuré dans un réseau virtuel fournit une interface de passerelle unique pour l’ensemble des API configurées, qu’elles soient hébergées localement ou dans le cloud. L’intégration d’Application Gateway avec Gestion des API vous offre la possibilité d’activer de manière sélective des API spécifiques accessibles sur Internet. L’intégration fournit également un WAF comme serveur frontal de votre instance Gestion des API.

Étapes suivantes