Modifier

Partager via


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

Pare-feu Azure
Azure Load Balancer
Machines virtuelles Azure
Réseau virtuel Azure

Cette architecture de référence montre un réseau sécurisé hybride qui étend un réseau local sur Azure. Cette architecture implémente un réseau de périmètre, également appelé DMZ, entre le réseau local et un réseau virtuel Azure. Tout le trafic entrant et sortant transite par le 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.

  • Réseau virtuel Azure Le réseau virtuel héberge les composants de la solution et les autres ressources exécutées dans Azure.

    Les itinéraires de réseau virtuel définissent le flux de trafic IP au sein du réseau virtuel Azure. Le diagramme contient deux tables de routage définies par l'utilisateur.

    Dans le sous-réseau de passerelle, le trafic est acheminé via le Pare-feu Azure.

    Notes

    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. Le 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.

  • Azure Bastion. Azure Bastion vous permet de vous connecter aux machines virtuelles du réseau virtuel via SSH ou RDP (Remote Desktop Protocol) sans exposer les machines virtuelles directement à Internet. Utilisez Bastion pour gérer les machines virtuelles 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 :

  • Les applications hybrides où les charges de travail s’exécutent en partie en local et dans Azure.
  • Une infrastructure qui nécessite un contrôle granulaire sur le trafic entrant d'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 le contrôle d’accès en fonction du rôle Azure (RBAC Azure) 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 gérer l’infrastructure de l’application, déployer les composants d’application et surveiller et redémarrer les machines virtuelles.

  • 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 ne doit pas avoir accès aux ressources du pare-feu. L’accès doit être limité au rôle d’administrateur informatique de sécurité.

Recommandations pour les groupes de ressources

Les ressources Azure, telles que les machines virtuelles, les réseaux virtuels et les équilibreurs de charge, peuvent être facilement gérées en les regroupant dans des groupes de ressources. Attribuez des rôles Azure à chaque groupe de ressources pour limiter l’accès.

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

  • Un groupe de ressources contenant le réseau virtuel (sauf les machines virtuelles), les groupes de sécurité réseau et les ressources de passerelle pour la connexion au réseau local. Assignez le rôle d’administrateur informatique centralisé à ce groupe de ressources.
  • Un groupe de ressources contenant les machines virtuelles de l'instance du 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.
  • Des groupes de ressources distincts pour chaque réseau virtuel spoke qui convient l’équilibreur de charge et les machines virtuelles.

Recommandations pour la mise en réseau

Pour accepter le trafic entrant en provenance d'Internet, ajoutez une règle DNAT (Destination Network Address Translation) au Pare-feu Azure.

  • Adresse de destination = Adresse IP publique de l'instance du pare-feu.
  • Adresse traduite = Adresse IP privée au sein du réseau virtuel.

Acheminez de force tout le trafic Internet sortant via votre réseau local à l'aide du tunnel VPN site à site, et acheminez-le vers Internet à l'aide de la traduction d'adresses réseau (NAT). 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 dans les sous-réseaux spoke. Bloquer le trafic empêchera ces ressources d’utiliser les services PaaS Azure qui reposent sur les adresses IP publiques, comme la journalisation des diagnostics des machines virtuelles, le téléchargement des extensions de machines virtuelles, et d’autres fonctionnalités. Les diagnostics Azure exigent également que les composants puissent lire et écrire dans un compte de 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.

Pensez à utiliser Application Gateway ou Azure Front Door pour l'arrêt SSL.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Pour plus d'informations sur les limites de bande passante de la passerelle VPN, consultez Références SKU de passerelles. 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 la scalabilité des passerelles Azure, consultez les sections relatives à la scalabilité dans :

Pour plus de détails sur la gestion des réseaux virtuels et des groupes de sécurité réseau à grande l'échelle, consultez Azure Virtual Network Manager (AVNM): Créer un réseau hub-and-spoke sécurisé pour créer de nouvelles topologies de réseau virtuel hub-and-spoke (et intégrer les topologies existantes) pour une gestion centralisée de la connectivité et des règles des groupes de sécurité réseau.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Si vous utilisez Azure ExpressRoute pour fournir la connectivité entre le réseau local et le réseau virtuel, configurez une passerelle VPN pour proposer un basculement si la connexion ExpressRoute n'est plus disponible.

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

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

En cas de problème de connectivité sur la passerelle qui relie votre réseau local à Azure, vous pouvez toujours accéder aux machines virtuelles du réseau virtuel Azure via Azure Bastion.

Chaque sous-réseau de couche dans l’architecture de référence est protégé par les règles du groupe de sécurité réseau. Vous devrez peut-être créer une règle pour ouvrir le port 3389 pour l’accès au protocole RDP sur les machines virtuelles Windows ou le port 22 pour l’accès SSH sur les machines virtuelles Linux. D’autres 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 Azure, utilisez Azure Connectivity Toolkit (AzureCT) pour surveiller et résoudre les problèmes de connexion.

Vous trouverez des informations supplémentaires sur la supervision et la gestion des connexions VPN et ExpressRoute dans l’article Implémentation d’une architecture réseau hybride avec Azure et un VPN local.

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 Vue d’ensemble du pilier Sécurité.

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

Routage de toutes les requêtes des utilisateurs locaux via le 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 DDoS Protection, combiné aux bonnes pratiques de conception d’application, offre des fonctionnalités d’atténuation des attaques DDoS améliorées pour une meilleure défense contre les attaques DDoS. Vous devez activer Azure DDOS Protection sur tout 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 RBAC Azure pour limiter les opérations que DevOps peut effectuer sur chaque couche. 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 Vue d’ensemble du pilier d’optimisation des coûts.

Utiliser la calculatrice de prix Azure pour estimer les coûts. D'autres considérations sont décrites dans la section Optimisation des coûts de Microsoft Azure Well-Architected Framework.

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

Pare-feu Azure

Dans cette architecture, le Pare-feu Azure est déployé sur 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. De cette façon, Azure Firewall est rentable car il est utilisé en tant que solution partagée consommée par plusieurs charges de travail. Les modèles de tarification du Pare-feu Azure sont les suivants :

  • 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 (NVA), le Pare-feu Azure vous permet d'économiser 30 à 50 %. Pour plus d’informations, consultez Pare-feu Azure et appliances virtuelles réseau.

Azure Bastion

Azure Bastion se connecte en toute sécurité à votre machine virtuelle via RDP et SSH sans qu'il soit nécessaire de configurer une adresse IP publique sur celle-ci.

La facturation Bastion est comparable à celle d’une machine virtuelle de base de bas niveau configurée en tant que jumpbox. 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

Le service 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, les machines virtuelles d’un même réseau virtuel qui communiquent entre elles n’entraînent pas de frais de trafic réseau.

Équilibreur de charge interne

L'équilibrage de charge de base entre les machines virtuelles d'un même réseau virtuel est gratuit.

Dans cette architecture, des équilibreurs de charge internes sont utilisés pour équilibrer la charge du trafic au sein d'un réseau virtuel.

Déployer ce scénario

Ce déploiement crée deux groupes de ressources : la première détient un réseau local fictif, le deuxième un ensemble de réseaux Hub-and-Spoke. Le réseau local fictif et le réseau hub sont connectés à l’aide de passerelles de réseau virtuel Azure pour former une connexion de site à site. Cette configuration est très similaire à celle que vous utiliseriez pour connecter votre centre de données local à Azure.

Ce déploiement peut prendre jusqu’à 45 minutes. La méthode de déploiement recommandée utilise l’option de portail ci-dessous.

Utilisez le bouton suivant pour déployer la référence à l’aide du portail Azure.

Déployer sur Azure

Une fois le déploiement terminé, vérifiez la connectivité de site à site en examinant les ressources de connexion nouvellement créées. Tant que vous êtes dans le portail Azure, recherchez « connexions » et notez l’état de chaque connexion.

Capture d’écran montrant l’état des connexions.

L’instance IIS trouvée dans le réseau spoke est accessible à partir de la machine virtuelle située dans le réseau local fictif. Créez une connexion à la machine virtuelle à l’aide de l’hôte Azure Bastion inclus, ouvrez un navigateur web et accédez à l’adresse de l’équilibreur de charge réseau de l’application.

Pour obtenir des informations détaillées et d’autres options de déploiement, consultez les modèles Azure Resource Manager (ARM) utilisés pour déployer cette solution : Réseau hybride sécurisé.

Étapes suivantes