Considérations relatives à la topologie et à la connectivité réseau pour l’accélérateur de zone d’atterrissage des services d’intégration
Cet article fournit des considérations et des recommandations relatives à la conception pour la topologie et la connectivité du réseau que vous pouvez appliquer quand vous utilisez l’accélérateur de zone d’atterrissage des services d’intégration Azure (AIS). La mise en réseau est au cœur de presque tout ce qui se passe dans une zone d’atterrissage.
Les considérations relatives à la topologie et à la connectivité du réseau pour cette architecture dépendent des exigences des charges de travail hébergées et des exigences de sécurité et de conformité de votre organisation.
Remarques relatives à la conception
Utilisez une topologie de réseau basée sur Virtual WAN si votre organisation :
Envisage de déployer des ressources dans plusieurs régions Azure et nécessite une connectivité globale entre les réseaux virtuels de ces régions Azure et plusieurs emplacements locaux.
Doit intégrer un réseau de succursale à grande échelle directement dans Azure, soit par le biais d’un déploiement de réseau étendu à définition logicielle, soit en exigeant plus de 30 sites de succursales pour une terminaison IPsec native.
Vous avez besoin d’un routage transitif entre le réseau privé virtuel et ExpressRoute. Par exemple, les succursales distantes connectées par un réseau privé virtuel de site à site ou les utilisateurs distants connectés par un réseau privé virtuel de point à site ont besoin d’une connectivité à un contrôleur de domaine connecté à ExpressRoute par le biais d’Azure.
Les organisations utilisent Virtual WAN pour répondre aux besoins d’interconnexion à grande échelle. Microsoft gère ce service, ce qui permet de réduire la complexité globale du réseau et de moderniser le réseau de votre organisation.
Utilisez une topologie de réseau Azure traditionnelle basée sur une architecture hub-and-spoke si votre organisation :
Prévoit de déployer des ressources dans les régions Azure sélectionnées uniquement.
N’a pas besoin d’un réseau interconnecté global.
Dispose de quelques sites distants ou succursales par région et a besoin de moins de 30 tunnels de sécurité IP (IPsec).
Nécessite un contrôle total de la configuration ou une configuration personnalisée manuelle de votre réseau Azure.
Topologie de réseau de référence
Le diagramme d’architecture suivant montre l’architecture de référence pour un déploiement d’entreprise AIS :
Planifier l’adressage IP
Les déploiements d’entreprise d’AIS doivent inclure l’utilisation de points de terminaison privés et de réseaux virtuels. Les considérations de conception suivantes doivent être prises en compte lors de la planification de votre adressage IP :
Certains services AIS nécessitent des sous-réseaux dédiés.
Vous pouvez désigner un sous-réseau donné pour un service donné pour créer des instances de ce service au sein du sous-réseau. Par exemple, vous pouvez désigner un sous-réseau pour des plans App Service afin de pouvoir ajouter des applications supplémentaires au fil du temps.
La passerelle VPN Azure peut connecter des sites locaux se chevauchant avec des espaces d’adressage IP se chevauchant via la fonctionnalité de traduction d’adresses réseau (NAT).
Système DNS personnalisé
La plupart des services AIS permettent aux clients d’utiliser leurs propres noms DNS pour des points de terminaison publics, soit à l’aide de leurs propres serveurs DNS, soit via l’offre Azure DNS. La configuration de ces ressources est effectuée une ressource à la fois, mais les ressources prises en charge sont répertoriées ci-dessous :
Gestion des API prend en charge les domaines personnalisés.
Les applications de fonction et Logic Apps prennent en charge les domaines personnalisés, lorsqu’ils sont hébergés par un plan App Service ou un App Service Environment.
Les comptes de stockage prennent en charge les domaines personnalisés pour les points de terminaison de stockage d’objets blob.
Data Factory, Service Bus et Event Grid ne prennent pas en charge les domaines personnalisés.
DNS privé
Azure Private DNS fournit un service DNS fiable et sécurisé pour votre réseau virtuel. Azure Private DNS gère et résout les noms de domaine dans le réseau virtuel sans nécessiter la configuration d’une solution DNS personnalisée.
Pour résoudre les enregistrements d’une zone DNS privée de votre réseau virtuel, vous devez lier le réseau virtuel à la zone. Les réseaux virtuels liés disposent d’un accès complet et peuvent résoudre tous les enregistrements DNS publiés dans la zone privée.
Remarques relatives à la conception
Il est important de configurer correctement vos paramètres DNS pour résoudre l’adresse IP du point de terminaison privé en nom de domaine complet (FQDN) de vos ressources.
Les services Microsoft Azure existants sont susceptibles de disposer d’une configuration DNS pour un point de terminaison public. Cette configuration doit être remplacée pour la connexion à l’aide de votre point de terminaison privé.
Chiffrement et authentification par certificat
Si la conception de votre réseau nécessite le chiffrement du trafic en transit et/ou l’authentification basée sur des certificats, vous devrez peut-être déterminer où et comment ce chiffrement/cette authentification est effectué. Par exemple, vous devez identifier le service qui effectue la terminaison TLS.
Remarques relatives à la conception
Votre conception nécessite-t-elle que le trafic entre les services Azure soit chiffré ? Votre chiffrement peut-il se terminer sur une instance Azure Front Door, puis non chiffré lors de l’utilisation du réseau principal Azure ou au sein de votre réseau virtuel ?
Devrez-vous terminer le chiffrement à plusieurs endroits ?
Avez-vous besoin de gérer l’authentification à plusieurs emplacements, ou peut-elle être effectuée une fois pour une requête externe ?
Recommandations de conception
Si vous utilisez une conception hub-and-spoke d’entreprise, envisagez d’utiliser Azure Front Door comme point d’entrée pour les requêtes basées sur Internet.
Envisagez d’utiliser Azure Application Gateway comme point d’arrêt pour toutes les requêtes basées sur TLS externes ou Gestion des API pour l’authentification par certificat et/ou la terminaison SSL.
Connectivité aux ressources locales
De nombreux scénarios d’intégration d’entreprise nécessitent la connexion de vos systèmes locaux à Azure. Il est important de prendre en compte les modèles recommandés pour fournir cette connectivité.
Remarques relatives à la conception
Azure ExpressRoute fournit une connectivité privée dédiée aux ressources IaaS et PaaS d’Azure à partir d’emplacements locaux.
La passerelle VPN Azure fournit une connectivité partagée de site à site (S2S) via l’Internet public aux ressources de réseaux virtuels IaaS Azure à partir d’emplacements locaux.
Azure ExpressRoute et la passerelle VPN Azure présentent différents coûts, fonctionnalités et performances.
La passerelle de données locale (OPDG) ou les connexions hybrides Azure peuvent être utilisées là où ExpressRoute ou une passerelle VPN n’est pas pratique. Les connexions OPDG/hybrides sont deux exemples de services de relais, utilisant Service Bus pour établir des connexions sortantes à partir de votre réseau local pour recevoir des requêtes d’Azure, sans avoir à ouvrir des ports dans votre pare-feu/réseau externe.
OPDG est limité dans le nombre de requêtes par minute qu’il prend en charge (limite), a des limites de taille de données spécifiques et fonctionne uniquement avec des ressources Azure limitées (Logic Apps, Power BI, Power Apps, Power Automate, Analysis Services).
Les connexions hybrides fonctionnent avec App Services (applications de fonction ou Web Apps) et ont leurs propres limitations et limites de dimensionnement.
Les connexions hybrides Azure Relay sont un élément clé de Service Bus qui permet d’effectuer des relais en dehors d’App Services ou d’OPDG.
Recommandations de conception
Utilisez Azure ExpressRoute comme canal de connectivité principal pour connecter un réseau local à Azure.
Vérifiez que vous utilisez la référence (SKU) appropriée pour ExpressRoute et/ou une passerelle VPN en fonction des exigences de bande passante et de performances.
Utilisez une passerelle VPN Azure pour connecter des branches ou des emplacements distants à Azure.
Utilisez OPDG et/ou des connexions hybrides pour lesquelles ExpressRoute ou une passerelle VPN ne peuvent pas être utilisés, où les limites de débit ne seront pas un problème et où vous utilisez une ressource Azure de prise en charge (par exemple, Logic Apps, Function Apps).
Connectivité aux services PaaS AIS
Les services PaaS AIS Azure sont généralement accessibles sur des points de terminaison publics. La plateforme Azure fournit des fonctionnalités pour sécuriser ces points de terminaison ou même les rendre entièrement privés.
La sécurisation de ces points de terminaison peut être obtenue à l’aide de points de terminaison privés.
Pour bloquer tout le trafic Internet vers une ressource cible, utilisez un point de terminaison privé.
Si vous souhaitez sécuriser une sous-ressource spécifique sur vos ressources de réseau virtuel, utilisez un point de terminaison privé.
Si vous souhaitez sécuriser un compte de stockage spécifique sur vos ressources de réseau virtuel, vous pouvez utiliser un point de terminaison privé.
Azure Private Link vous permet d’accéder aux services Azure AIS (par exemple Service Bus et Gestion des API) ainsi qu’aux services de partenaires/clients hébergés par Azure sur un point de terminaison privé dans votre réseau virtuel.
Lorsque vous utilisez Private Link, le trafic entre votre réseau virtuel et le service transite par le réseau principal de Microsoft, ce qui signifie que vous n’avez plus besoin d’exposer votre service à l’Internet public. Vous pouvez créer votre propre service de liaison privée dans votre réseau virtuel et le distribuer à vos clients. La configuration et la consommation à l’aide d’Azure Private Link est cohérente entre le service Azure PaaS, les services appartenant au client et les services de partenaires partagés.
Remarques relatives à la conception
L’injection de réseau virtuel fournit des déploiements privés dédiés pour les services pris en charge. Toutefois, le trafic de plan de gestion transite encore par des adresses IP publiques.
Azure Private Link fournit un accès dédié à l’aide d’adresses IP privées à des instances PaaS Azure, ou à des services personnalisés derrière un niveau standard Azure Load Balancer.
Les clients entreprises ont souvent des préoccupations concernant les points de terminaison publics pour les services PaaS, qui doivent être résolues de manière appropriée.
Recommandations de conception
Utilisez une injection de réseau virtuel pour les services Azure pris en charge afin de rendre ceux-ci disponibles à partir de votre réseau virtuel.
Les services PaaS Azure injectés dans un réseau virtuel continuent d’effectuer des opérations de plan de gestion à l’aide d’adresses IP publiques propres au service. La connectivité doit être garantie pour que le service fonctionne correctement.
Accédez aux services PaaS Azure à partir d’un emplacement local via un peering privé ExpressRoute. Utilisez une injection de réseau virtuel pour des services Azure dédiés ou une liaison privée Azure pour les services Azure partagés disponibles.
Pour accéder aux services PaaS Azure à partir d’un emplacement local quand une injection de réseau virtuel ou Private Link ne sont pas disponibles, utilisez ExpressRoute avec un peering Microsoft, qui vous permet d’éviter le transit sur l’Internet public.
L’accès aux services PaaS Azure à partir d’un emplacement local via ExpressRoute avec le peering Microsoft n’empêche pas l’accès aux points de terminaison publics du service PaaS. Vous devez configurer et restreindre cela séparément selon les besoins.
N’activez pas les points de terminaison de service de réseau virtuel par défaut sur tous les sous-réseaux.
Désactivez l’accès public aux services PaaS AIS.
Conception réseau pour Gestion des API
Remarques relatives à la conception
Déterminez si les API sont accessibles en externe, en interne ou un hybride des deux.
Décidez si vous souhaitez utiliser la passerelle de Gestion des API interne comme point de terminaison principal, ou si vous souhaitez utiliser un service Web Application Firewall (WAF) comme Azure Application Gateway ou Azure Front Door.
Déterminez s’il doit y avoir plusieurs passerelles déployées et comment elles doivent être équilibrées en charge en utilisant, par exemple, Application Gateway devant la passerelle Gestion des API.
Déterminez si la connectivité à des environnements locaux ou multiclouds est requise.
Recommandations de conception
Déployez votre instance Gestion des API dans un réseau virtuel pour autoriser l’accès aux services back-end dans le réseau.
Utilisez Application Gateway pour l’accès externe à Gestion des API lorsque l’instance Gestion des API est déployée dans un réseau virtuel en mode interne.
Utilisez un point de terminaison privé pour votre instance Gestion des API afin de permettre aux clients de votre réseau privé d’accéder en toute sécurité à l’instance via Azure Private Link.
Conception réseau pour les comptes de stockage
Stockage Azure est utilisé comme solution de stockage pour Azure Logic Apps et Azure Functions.
Recommandations de conception
Pour des performances optimales, votre application logique/de fonction doit utiliser un compte de stockage dans la même région, ce qui réduit la latence.
Utilisez des points de terminaison privés pour vos comptes Stockage Azure afin de permettre aux clients d’un réseau virtuel (VNet) d’accéder en toute sécurité aux données via une liaison Private Link.
Vous devez créer des points de terminaison privés différents pour chacun des services de stockage Table, File d’attente et Blob.
Conception réseau pour App Service Environment
Un App Service Environment (ASE) est un environnement dédié et isolé pour l’exécution d’applications web, d’applications de fonction et d’applications logiques (Standard). Il est déployé dans votre réseau virtuel et contient un certain nombre de plans App Service, chacun d’entre eux étant utilisé pour héberger vos services d’application.
Remarques relatives à la conception
Un ASE est déployé sur un seul sous-réseau au sein de votre réseau virtuel. Un ASE peut être déployé à l’aide d’une adresse IP virtuelle (VIP) permettant aux connexions externes d’utiliser une adresse IP visible publiquement, qui peut être ajoutée à un enregistrement DNS public.
Les applications au sein d’un environnement ASE auront accès à toutes les autres ressources du réseau virtuel, en fonction des règles d’accès réseau. L’accès aux ressources d’autres réseaux virtuels peut être obtenu à l’aide du peering de réseaux virtuels.
Les applications au sein d’un environnement ASE n’ont pas besoin d’être configurées pour appartenir à un réseau virtuel : elles le sont automatiquement au sein du réseau virtuel en raison du déploiement sur l’ASE. Cela signifie qu’au lieu d’avoir à configurer l’accès réseau par ressource, vous pouvez le configurer une fois au niveau de l’ASE.
Recommandations de conception
- Utilisez ASE v3 dans la mesure du possible, car cela offre la plus grande flexibilité réseau, tout en réduisant la configuration nécessaire pour les ressources individuelles au sein de l’ASE. ASE v3 prend également en charge la redondance de zone.
Conception de réseau pour les plans App Service
App Services dans un environnement mutualisé peut être déployé avec un point de terminaison privé ou public. Lorsqu’un service est déployé avec un point de terminaison privé, l’exposition publique de l’App Service est supprimée. S’il est nécessaire que le point de terminaison privé d’App Service soit également accessible via Internet, envisagez l’utilisation d’App Gateway pour exposer le service d’application.
Planifiez soigneusement vos sous-réseaux pour l’intégration de réseau virtuel sortant en tenant compte du nombre d’adresses IP requises. L’intégration au réseau virtuel requiert un sous-réseau dédié. Lorsque vous planifiez la taille de votre sous-réseau, n’oubliez pas qu’Azure réserve 5 adresses IP dans chaque sous-réseau. En outre, une seule adresse du sous-réseau d’intégration est utilisée pour chaque instance de plan. Lorsque vous définissez l’échelle de votre application sur quatre instances, quatre adresses sont utilisées. Lorsque vous en augmentez ou diminuez la taille, l’espace d’adressage requis est doublé pendant une brève période de temps. Cela affecte les instances prises en charge réelles et disponibles dans votre sous-réseau.
Lorsqu’il est nécessaire de se connecter aux services locaux, privés ou restreints à des adresses IP à partir d’un App Service, considérez que :
Lors de l’exécution dans l’environnement mutualisé, l’appel App Service peut provenir d’une large gamme d’adresses IP et une intégration de réseau virtuel peut être nécessaire pour répondre à vos exigences de mise en réseau.
Les services tels que Gestion des API (APIM) peuvent être utilisés pour traiter des appels par proxy entre les limites réseau et fournir une adresse IP statique si nécessaire.
Recommandations de conception
- Comme vous ne pouvez pas modifier les tailles de sous-réseau l’affectation, utilisez un sous-réseau suffisamment grand pour s’adapter à l’échelle que votre application est susceptible d’atteindre. Pour éviter tout problème de capacité du sous-réseau, vous devez utiliser un suffixe /26 (64 adresses) pour l’intégration du réseau virtuel.
Conception réseau pour Azure Data Factory
Remarques relatives à la conception
Pour connecter Data Factory à une source de données située dans votre réseau local, ou peut-être sur un service Azure qui a été configuré pour bloquer l’accès à partir de tous les services Azure, sauf s’ils sont spécifiquement autorisés, vous devez envisager d’intégrer votre Data Factory à un réseau virtuel qui fournit un accès réseau à la source de données cible.
Data Factory utilise des environnements distincts appelés runtimes d’intégration. Le runtime Data Factory par défaut, le runtime d’intégration Azure, n’est pas associé à un réseau virtuel et, par conséquent, il ne peut pas être utilisé pour se connecter à des sources de données sécurisées avec les pare-feu les plus restrictifs. Déterminez lequel de ces runtimes répond le mieux à vos besoins.
Le démarrage des VNET managés prend un certain temps, tandis que les runtimes Azure normaux sont disponibles presque instantanément. Il s’agit d’un aspect que vous devez garder à l’esprit lors de la planification et du débogage de vos pipelines.
Le démarrage des runtimes SSIS avec un runtime intégré au réseau virtuel prend jusqu’à 30 minutes.
Les runtimes d’intégration auto-hébergés peuvent uniquement exécuter l’activité de copie, qui copie les données d’une source vers une autre telle quelle. Si vous souhaitez effectuer des transformations sur les données, vous ne pouvez pas les effectuer à l’aide des flux de données de Data Factory.
Les points de terminaison privés managés sont des points de terminaison privés créés sur le réseau virtuel managé Azure Data Factory qui établissent une liaison privée vers des ressources Azure (généralement des sources de données pour ADF). Azure Data Factory gère ces points de terminaison privés à votre place.
Les points de terminaison privés sont uniquement disponibles pour les runtimes d’intégration auto-hébergés afin de se connecter à Data Factory.
Conception réseau pour Logic Apps (Standard) – Applications intégrées au réseau virtuel
Remarques relatives à la conception
Le trafic entrant dans vos applications logiques passe par des points de terminaison privés. Reportez-vous à la documentation Considérations relatives au trafic entrant via des points de terminaison privés lors de la planification de votre conception réseau Logic Apps.
Le trafic sortant de vos applications logiques transite par le réseau virtuel. Reportez-vous aux considérations relatives au trafic sortant via la documentation d’intégration de réseau virtuel lors de la planification de votre conception réseau Logic Apps.
Conception de réseau pour Service Bus
Remarques relatives à la conception
Utilisez-vous des zones DNS privées ou votre propre serveur DNS (avec transfert DNS) pour la résolution en ressource de liaison privée ?
Le filtrage IP et les réseaux virtuels sont uniquement pris en charge dans le niveau de référence SKU Premium pour Service Bus. Si le niveau Premium n’est pas pratique, envisagez d’utiliser des jetons SAS comme moyen principal de verrouiller l’accès à votre espace de noms.
Recommandations de conception
L’accès au réseau public doit être désactivé à l’aide du filtrage IP, qui s’applique à tous les protocoles pris en charge (par exemple, AMQP et HTTPS).
Le trafic vers cet espace de noms doit être limité uniquement sur les points de terminaison privés, en limitant l’accès au réseau public (à l’aide du filtrage IP).
Placez votre point de terminaison privé dans son propre sous-réseau dédié réservé à Service Bus.
Ajoutez un enregistrement DNS à l’aide de la zone DNS privée pour le point de terminaison privé. Autorisez les services de confiance dans Azure à accéder directement à votre espace de noms (en contournant ainsi le pare-feu) pour éviter les problèmes liés à votre conception d’intégration.
Conception réseau pour les applications de fonction
Remarques relatives à la conception
- Utilisez-vous des zones DNS privées ou votre propre serveur DNS (avec transfert DNS) pour la résolution en ressource de liaison privée ?
Recommandations de conception
L'accès réseau public doit être désactivé.
Le trafic vers cet espace de noms doit être limité uniquement sur des points de terminaison privés.
Placez votre point de terminaison privé dans son propre sous-réseau dédié réservé à Functions.
Ajoutez un enregistrement DNS à l’aide de la zone DNS privée pour le point de terminaison privé.
Conception réseau pour Azure Key Vault
Recommandations de conception
L'accès réseau public doit être désactivé.
Créez un point de terminaison privé pour restreindre l’accès via le réseau virtuel uniquement.
Placez votre point de terminaison privé dans son propre sous-réseau dédié réservé à Key Vault.
Ajoutez un enregistrement DNS à l’aide de la zone DNS privée pour le point de terminaison privé.
Conception de réseau pour Event Grid
Remarques relatives à la conception
- Utilisez-vous des zones DNS privées ou votre propre serveur DNS (avec transfert DNS) pour la résolution en ressource de liaison privée ?
Recommandations de conception
L’accès au réseau public doit être désactivé à l’aide du filtrage IP.
Le trafic vers vos rubriques et votre domaine doit être limité uniquement sur les points de terminaison privés.
Placez votre point de terminaison privé dans son propre sous-réseau dédié réservé à Event Grid.
Ajoutez un enregistrement DNS à l’aide de la zone DNS privée pour le point de terminaison privé.
Conception de réseau pour Event Hubs
Remarques relatives à la conception
- La restriction de l’accès réseau ne fonctionne pas avec le niveau tarifaire De base dans Event Hubs
Recommandations de conception
L’accès au réseau public doit être désactivé à l’aide du filtrage IP.
L’accès au réseau public doit être désactivé à l’aide de points de terminaison de service : créez un point de terminaison de service de réseau virtuel dans votre réseau virtuel et liez-le à votre espace de noms Event Hubs à l’aide d’une règle de réseau virtuel
Activez l’option Services approuvés pour autoriser certaines ressources Azure à accéder à votre espace de noms.
Étape suivante
Vérifiez les zones de conception critiques pour achever les considérations et recommandations relatives à votre architecture.