Implémenter un réseau hybride sécurisé

Pare-feu Azure
Équilibrage de charge Azure
Machines virtuelles Azure
Réseau virtuel Azure

Cette architecture de référence montre un réseau hybride sécurisé qui étend un réseau local à Azure. L’architecture implémente un réseau perimeter également appelé DMZ, entre le réseau local et un réseau virtuel Azure. Tout le trafic entrant et sortant passe par Pare-feu Azure.

Architecture

Diagramme montrant l’architecture du réseau hybride sécurisé.

Téléchargez un fichier Visio de cette architecture.

Composants

L’architecture repose sur les aspects suivants :

  • Réseau local. Réseau local privé implémenté dans une organisation.

  • Azure réseau virtuel. Le réseau virtuel héberge les composants de la solution et d’autres ressources s’exécutant dans Azure.

    Routes réseau virtuelles définissez le flux de trafic IP au sein du réseau virtuel Azure. Dans cette architecture, il existe deux tables de routage définies par l’utilisateur, qui acheminent le trafic via l’instance Pare-feu Azure. L’une des tables de routage est associée au sous-réseau de passerelle du réseau hub, et l’autre est associée au sous-réseau du réseau spoke.

    Note

    Selon les exigences de votre connexion VPN, vous pouvez configurer des itinéraires de protocole BGP (Border Gateway Protcol) pour implémenter les règles de transfert qui orientent le trafic par le biais du réseau local.

  • Passerelle. La passerelle assure la connectivité entre les routeurs du réseau local et ceux du réseau virtuel. La passerelle est placée dans son propre sous-réseau.

  • Pare-feu Azure. Pare-feu Azure est un pare-feu géré en tant que service. L'instance de pare-feu est placée dans son propre sous-réseau.

  • Groupes de sécurité réseau. Utilisez des groupes de sécurité pour limiter le trafic réseau au sein du réseau virtuel.

  • Groupes de machines virtuelles identiques. Les Virtual Machine Scale Sets (groupes de machines virtuelles identiques) fournissent le niveau de calcul dans les réseaux virtuels spoke. Les scale sets déploient et gèrent un ensemble de machines virtuelles identiques derrière l'équilibreur de charge interne et prennent en charge la mise à l'échelle automatique afin de s'adapter à la demande.

  • Azure Bastion. Azure Bastion fournit un accès SSH et RDP sécurisé aux instances de groupe de machines virtuelles identiques sans les exposer à Internet. Utilisez Bastion pour gérer les instances du réseau virtuel.

    Bastion nécessite un sous-réseau dédié appelé AzureBastionSubnet.

Cas d’usage potentiels

Cette architecture nécessite une connexion à votre centre de données local, à l’aide d’une passerelle VPN ou d’une connexion ExpressRoute. Utilisations courantes de cette architecture :

  • Applications hybrides où les charges de travail s’exécutent en partie localement et en partie dans Azure.
  • Infrastructure qui nécessite un contrôle granulaire du trafic entrant un réseau virtuel Azure à partir d’un centre de données local.
  • Les applications qui doivent auditer le trafic sortant. L’audit est souvent une exigence réglementaire de nombreux systèmes commerciaux, qui peut permettre d’éviter la divulgation publique d’informations privées.

Recommandations

Les recommandations suivantes s’appliquent à la plupart des scénarios. Suivez ces recommandations, sauf si vous avez un besoin spécifique qui vous oblige à les ignorer.

Recommandations en matière de contrôle d’accès

Utilisez Azure contrôle d’accès en fonction du rôle (Azure RBAC) pour gérer les ressources de votre application. Envisagez de créer les rôles personnalisés suivants :

  • Un rôle DevOps avec des autorisations pour administrer l’infrastructure pour l’application, déployer les composants de l’application et gérer les opérations de groupe de machines virtuelles identiques telles que la mise à l’échelle, la réinitialisation et les mises à niveau.

  • Un rôle d’administrateur informatique centralisé pour gérer et surveiller les ressources réseau.

  • Un rôle d'administrateur informatique de sécurité pour gérer les ressources réseau sécurisées telles que le pare-feu.

Le rôle d’administrateur informatique centralisé ne doit pas avoir accès aux ressources du pare-feu. Restreindre l’accès au rôle d’administrateur informatique de sécurité.

Recommandations pour les groupes de ressources

Des ressources Azure telles que les groupes identiques de machines virtuelles, les réseaux virtuels et les équilibreurs de charge peuvent être gérées en les regroupant au sein de groupes de ressources. Attribuez Azure rôles à chaque groupe de ressources pour restreindre l’accès.

Nous vous recommandons de créer les groupes de ressources suivants :

  • Groupe de ressources contenant le réseau virtuel (à l’exclusion des ressources de calcul), des groupes de sécurité réseau et des ressources de passerelle pour la connexion au réseau local. Assignez le rôle d’administrateur informatique centralisé à ce groupe de ressources.
  • Groupe de ressources contenant les ressources de l’instance de Pare-feu Azure et les itinéraires définis par l’utilisateur pour le sous-réseau de passerelle. Assignez le rôle d’administrateur informatique de sécurité à ce groupe de ressources.
  • Groupes de ressources distincts pour chaque réseau virtuel spoke contenant l'équilibreur de charge et les Virtual Machine Scale Sets.

Recommandations pour la mise en réseau

Dans cette architecture, tout le trafic entrant et sortant entre le réseau local, Internet et les réseaux virtuels spoke passent par Pare-feu Azure. Chaque flux qui traverse le périmètre subit une traduction d'adresses réseau au niveau du pare-feu, de sorte que ce sont les adresses IP du pare-feu, et non celles de la charge de travail, qui sont observées par les systèmes externes et les systèmes locaux. Planifiez le comportement suivant :

  • Les charges de travail publiées sont accessibles à l’adresse IP publique du pare-feu, et non à l’adresse IP de la charge de travail. Vous publiez un back-end avec une règle de traduction d’adresses réseau de destination (DNAT) sur le pare-feu. L’adresse de destination est l’adresse IP publique du pare-feu ; l’adresse traduite est une adresse IP privée au sein du réseau virtuel.

  • Les flux sortants quittent le périmètre source de l’une des adresses IP publiques du pare-feu. Pare-feu Azure sélectionne de manière aléatoire l’adresse IP publique attachée à utiliser pour chaque flux sortant. Par conséquent, les listes d’autorisation des partenaires, les règles de pare-feu locales et les journaux d’audit doivent couvrir l’ensemble des adresses IP attachées au pare-feu. Utilisez un préfixe d’adresse IP publique pour exprimer ce paramètre en tant que plage contiguë.

    Le nombre d’adresses IP publiques attachées au pare-feu détermine également le nombre de connexions sortantes simultanées pouvant être maintenues avant que les ports de traduction d’adresses réseau sources (SNAT) soient épuisés.

  • Les back-ends ne voient pas l’adresse IP du client d’origine. Pare-feu Azure applique également SNAT sur les paquets qui correspondent à une règle DNAT afin de renvoyer le trafic via la même instance de pare-feu. Le serveur principal observe l’adresse IP de l’instance de pare-feu comme source.

    Si votre application nécessite l'adresse IP du client, arrêtez la connexion cliente en amont dans un proxy inverse tel que Azure Application Gateway ou Azure Front Door, transférez l'adresse IP du client dans l'en-tête HTTP X-Forwarded-For, puis suivez Preservez le nom d'hôte HTTP d'origine afin que le serveur principal continue d'observer le nom d'hôte du client.

Forcez le tunnel pour tout le trafic Internet sortant via votre réseau local en utilisant le tunnel VPN site à site. L’appareil edge local effectue le SNAT vers Internet pour le compte des charges de travail Azure, qui route les flux sortants via vos contrôles de sortie locaux et votre pipeline d’audit existants. Cette conception empêche la divulgation accidentelle d’informations confidentielles et permet d’inspecter et d’auditer tout le trafic sortant.

Ne bloquez pas complètement le trafic Internet des ressources situées dans les sous-réseaux spoke. Le blocage du trafic empêche ces ressources d’utiliser Azure services PaaS qui s’appuient sur des adresses IP publiques, telles que la journalisation des diagnostics, l’approvisionnement des extensions de machine virtuelle et leurs dépendances et d’autres fonctionnalités de plateforme. Azure diagnostics nécessite également que les composants puissent lire et écrire dans un compte stockage Azure.

Vérifiez que le trafic Internet sortant est correctement acheminé de force. Si vous utilisez une connexion VPN avec le service de routage et d'accès à distance sur un serveur local, utilisez un outil tel que WireShark.

Envisagez d’utiliser Application Gateway ou Azure Front Door pour l’arrêt SSL.

Considérations

Ces considérations implémentent les piliers du cadre Azure Well-Architected, comprenant des principes directeurs qui peuvent être utilisés pour améliorer la qualité de la charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

Si vous utilisez Azure ExpressRoute pour fournir une connectivité entre le réseau virtuel et le réseau local, configurer une passerelle VPN pour fournir un basculement si la connexion ExpressRoute devient indisponible.

Pour obtenir des informations sur le maintien de la disponibilité des connexions VPN et ExpressRoute, consultez les considérations relatives à la disponibilité dans :

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

Cette architecture de référence implémente plusieurs niveaux de sécurité.

Routage de toutes les requêtes utilisateur locales via Pare-feu Azure

L'itinéraire défini par l'utilisateur dans le sous-réseau de passerelle bloque toutes les requêtes des utilisateurs en dehors de celles reçues du site local. La route transmet les demandes autorisées au pare-feu. Les demandes sont transmises ensuite aux ressources dans les réseaux virtuels spoke si elles sont autorisées par les règles de pare-feu. Vous pouvez ajouter d'autres itinéraires, mais veillez à ce qu'ils ne contournent pas par inadvertance le pare-feu ou à ce qu'ils ne bloquent pas le trafic destiné au sous-réseau de gestion.

Utilisation de groupes de sécurité réseau pour bloquer/transmettre le trafic vers des sous-réseaux de réseau virtuel spoke

Le trafic vers et depuis des sous-réseaux de ressources dans des réseaux virtuels spoke est limité moyennant des groupes de sécurité réseau. Si vous avez besoin d’une exigence pour développer les règles du groupe de sécurité réseau afin d’autoriser un accès plus large à ces ressources, évaluez ces exigences par rapport aux risques de sécurité. Chaque nouveau chemin d’accès entrant représente un risque d’altération d’application ou de divulgation de données volontaire ou accidentelle.

Protection DDoS

Azure protection DDoS, combinée aux meilleures pratiques de conception d’application, offre une atténuation améliorée contre les attaques DDoS. Activez Azure protection DDoS sur n’importe quel réseau virtuel de périmètre.

Utiliser AVNM pour créer des règles de base d’administration de la sécurité

AVNM vous permet de créer des bases de référence de règles de sécurité, qui peuvent prendre la priorité sur les règles de groupe de sécurité réseau. Les règles d’administration de la sécurité sont évaluées avant celles du NSG (groupe de sécurité réseau) et ont la même nature que ces dernières, avec la prise en charge de la hiérarchisation, des balises de service et des protocoles L3-L4. AVNM permet au service informatique central de mettre en place une base de référence des règles de sécurité, tout en autorisant une indépendance des règles de groupe de sécurité réseau supplémentaires pour les propriétaires des réseaux virtuels spoke. Pour faciliter un déploiement contrôlé des changements de règles de sécurité, la fonctionnalité de déploiements d’AVNM vous permet de libérer en toute sécurité les changements de rupture de ces configurations dans les environnements hub-and-spoke.

Accès DevOps

Utilisez Azure RBAC pour restreindre les opérations que DevOps peut effectuer sur chaque niveau. Lorsque vous accordez des autorisations, utilisez le principe des privilèges minimum. Journalisez toutes les opérations d’administration et réalisez des audits réguliers pour vérifier qu’aucune modification de configuration n’est prévue.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

Utilisez cette estimation preconfigurée dans la calculatrice de prix Azure comme point de départ pour estimer les coûts de votre scénario. Il inclut les composants réseau décrits dans cet article avec des exemples de machines virtuelles.

Les considérations de coûts suivantes s'appliquent aux services utilisés dans cette architecture.

Pare-feu Azure

Dans cette architecture, Pare-feu Azure est déployée dans le réseau virtuel pour contrôler le trafic entre le sous-réseau de la passerelle et les ressources des réseaux virtuels spoke. L’utilisation de Pare-feu Azure en tant que solution partagée sur plusieurs charges de travail peut contribuer à réduire l’infrastructure en double. Voici les modèles de tarification Pare-feu Azure :

  • Taux fixe par heure de déploiement.
  • Données traitées par Go pour prendre en charge la mise à l'échelle automatique.

Par rapport aux appliances virtuelles réseau, avec Pare-feu Azure vous pouvez économiser jusqu’à 30 à 50%. Pour plus d’informations, consultez Pare-feu Azure vs NVA.

Azure Bastion

Azure Bastion se connecte de manière sécurisée aux instances de Virtual Machine Scale Sets via RDP et SSH, sans nécessiter d'adresse IP publique sur les instances.

La facturation Bastion est comparable à celle d'une machine virtuelle de base, de bas niveau, configurée comme un jump box. Bastion est plus rentable qu’un serveur de rebond, car il intègre des fonctionnalités de sécurité et n’entraîne pas de coûts supplémentaires pour le stockage et la gestion d’un serveur distinct.

Réseau virtuel Azure

Réseau virtuel Azure est gratuit. Chaque abonnement est autorisé à créer jusqu’à 1,000 réseaux virtuels dans toutes les régions. Au sein du réseau virtuel, tout le trafic est gratuit. Par exemple, le trafic entre l'équilibreur de charge interne et les instances de Virtual Machine Scale Sets n'entraîne aucun frais de trafic réseau.

Équilibreur de charge interne

Dans cette architecture, des équilibreurs de charge internes sont utilisés pour distribuer le trafic entre les instances des groupes identiques de machines virtuelles au sein d’un réseau virtuel. Standard Load Balancer est requis pour utiliser les Virtual Machine Scale Sets.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et la conservent en production. Pour plus d’informations, consultez Liste de vérification de la conception pour l'excellence opérationnelle.

Si la connectivité de passerelle de votre réseau local à Azure est en panne, vous pouvez toujours utiliser Azure Bastion pour accéder aux ressources dans le réseau virtuel Azure pour résoudre les problèmes. Étant donné que les instances de Virtual Machine Scale Sets sont éphémères, privilégiez la journalisation et la supervision centralisées à l'aide d'Azure Monitor et des diagnostics de démarrage plutôt que les sessions interactives à distance pour les opérations courantes.

Chaque subnet de chaque niveau dans l'architecture de référence est protégé par les règles du groupe de sécurité réseau. Les outils de gestion et de surveillance peuvent nécessiter des règles pour ouvrir des ports supplémentaires.

Si vous utilisez ExpressRoute pour fournir la connectivité entre votre centre de données local et votre Azure, utilisez le Azure Connectivity Toolkit (AzureCT) pour surveiller et résoudre les problèmes de connexion.

Vous trouverez des informations supplémentaires sur la surveillance et la gestion des connexions VPN et ExpressRoute dans l’article Implement une architecture réseau hybride avec Azure et vpn local.

Efficacité des performances

L’efficacité des performances est la capacité de la charge de votre travail à s’adapter efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Les Virtual Machine Scale Sets des réseaux spoke prennent en charge la mise à l'échelle automatique. Configurez des règles de mise à l’échelle automatique basées sur des métriques telles que l’utilisation du processeur ou le nombre de demandes afin que les instances soient ajoutées ou supprimées en réponse à la demande. Choisissez un mode d’orchestration et une stratégie de mise à niveau qui correspond à la tolérance de votre charge de travail pour les interruptions pendant les mises à jour.

Pour plus d’informations sur les limites de bande passante de passerelle VPN, consultez les références SKU Gateway. Pour des bandes passantes plus élevées, envisagez d’effectuer une mise à niveau vers une passerelle ExpressRoute. ExpressRoute offre jusqu’à 10 Gbit/s de bande passante avec une latence inférieure à celle d’une connexion VPN.

Pour plus d’informations sur l’extensibilité des passerelles Azure, consultez les sections relatives à la scalabilité dans :

Pour plus d’informations sur la gestion des réseaux virtuels et des groupes de sécurité réseau à grande échelle, consultez Azure Virtual Network Manager (AVNM) : Créez un réseau sécurisé en étoile et branche pour créer de nouvelles topologies de réseau virtuel en étoile et branche (et intégrer les existantes) pour la gestion centralisée de la connectivité et des règles de groupe de sécurité réseau.

Étapes suivantes