réseau de production Azure

Les utilisateurs du réseau de production Azure incluent à la fois des clients externes qui accèdent à leurs propres applications Azure et le personnel interne support Azure qui gère le réseau de production. Cet article traite des méthodes d’accès de sécurité et des mécanismes de protection pour établir des connexions au réseau de production Azure.

Routage Internet et tolérance aux pannes

Une infrastructure DNS (DNS) interne Azure et externe globalement redondante, combinée à plusieurs clusters de serveurs DNS principaux et secondaires, offre une tolérance aux pannes. Azure applique également une protection DDoS au niveau de l’infrastructure et d’autres contrôles de sécurité réseau pour aider à se défendre contre les attaques DDoS courantes au niveau réseau et protéger l’intégrité des services Azure DNS.

Les serveurs Azure DNS sont situés dans plusieurs centres de données de type datacenter. L’implémentation Azure DNS intègre une hiérarchie de serveurs DNS secondaires et principaux pour résoudre publiquement les noms de domaine clients Azure. Les noms de domaine pointent généralement vers une adresse cloudapp.net, qui encapsule l’adresse IP virtuelle (VIP) du service du client. Une fonctionnalité propre à Azure : les équilibreurs de charge Microsoft chargés de gérer cette adresse VIP la traduisent en adresse IP interne dédiée (DIP) du locataire.

Microsoft héberge Azure dans des centres de données Azure géographiquement répartis aux États-Unis. Azure utilise des plateformes de routage à la pointe de la technologie qui implémentent des normes architecturales solides et évolutives. Parmi les caractéristiques notables figurent :

  • L’ingénierie du trafic basée sur la commutation d’étiquettes multiprotocole (MPLS), qui permet une utilisation efficace des liaisons et une dégradation harmonieuse du service en cas de panne.
  • Microsoft met en œuvre des réseaux selon des architectures de redondance N+1 ou supérieures.
  • À l’extérieur, des circuits réseau dédiés à haute bande passante desservent des centres de données qui connectent redondantement des propriétés avec plus de 1 200 fournisseurs d’accès Internet à travers le monde à plusieurs points de peering. Cette connexion offre plus de 2 000 gigaoctets par seconde (GBps) de capacité de bord.

Parce que Microsoft possède ses propres circuits réseau entre centres de données, ces attributs permettent à l’offre Azure d’atteindre 99,9+ % de disponibilité réseau sans avoir besoin de fournisseurs d’accès internet tiers traditionnels.

Connexion au réseau de production et aux pare-feux associés

La politique de flux de trafic internet sur le réseau Azure dirige le trafic vers le réseau de production Azure situé dans le centre de données régional le plus proche aux États-Unis. Parce que les centres de données de production Azure maintiennent une architecture réseau et un matériel cohérents, la description du flux de trafic qui suit s’applique de manière cohérente à tous les centres de données.

Après que le trafic internet d’Azure a été acheminé vers le centre de données le plus proche, le trafic établit une connexion avec les routeurs d’accès. Ces routeurs d’accès isolent le trafic entre les nœuds Azure et les machines virtuelles instanciées par le client. Les dispositifs d’infrastructure réseau situés aux emplacements d’accès et de périphérie sont les points frontières où les filtres d’entrée et de sortie s’appliquent. Ces routeurs utilisent une liste de contrôle d’accès (ACL) à plusieurs niveaux pour filtrer le trafic réseau indésirable et appliquer des limites de débit, si nécessaire. Les routes ACL autorisaient le trafic à destination des équilibreurs de charge. Les routeurs de distribution n’autorisent que les adresses IP approuvées par Microsoft, offrent une anti-usurpation et établissent des connexions TCP utilisant des ACL.

Microsoft place des dispositifs d’équilibrage de charge externes derrière les routeurs d’accès pour effectuer la traduction d’adresses réseau (NAT) des IP routables sur Internet vers les IP internes Azure. Les périphériques avoitent également les paquets vers des IP et ports internes de production valides. Ces dispositifs agissent comme un mécanisme de protection pour limiter l’exposition de l’espace d’adressage interne du réseau de production.

Par défaut, Microsoft applique le protocole de transfert d'hypertexte sécurisé (HTTPS) pour tout le trafic transmis aux navigateurs web des clients, y compris la connexion et tout le trafic qui s'en est déroulé. TLS v1.2 crée un tunnel sécurisé pour le trafic. Les ACL des routeurs d’accès et de noyau garantissent que la source du trafic correspond à la source attendue.

Une distinction importante dans cette architecture, comparée à l'architecture de sécurité traditionnelle, est qu'Azure ne dispose pas de pare-feux matériels dédiés, de dispositifs spécialisés de détection ou de prévention des intrusions, ni d'autres appliances de sécurité normalement attendus avant la connexion à l'environnement de production Azure. Les clients s’attendent généralement à ces dispositifs de pare-feu matériels dans le réseau Azure. Cependant, Azure n'utilise pas ces appareils. Presque exclusivement, ces fonctionnalités de sécurité sont intégrées au logiciel qui fait tourner l’environnement Azure pour offrir des mécanismes de sécurité solides et multicouches, y compris des capacités de pare-feu. De plus, le logiciel qui fait tourner Azure facilite la gestion et l’inventaire de la frontière et de l’étendue associée des dispositifs de sécurité critiques.

Fonctionnalités de sécurité et de pare-feu de base

Azure met en œuvre de solides fonctionnalités de sécurité logicielle et de pare-feu à différents niveaux pour renforcer les caractéristiques de sécurité que les clients attendent généralement dans un environnement traditionnel afin de protéger la frontière principale de l’autorisation de sécurité.

Fonctionnalités de sécurité Azure

Azure implémente des pare-feux logiciels basés sur l’hôte à l’intérieur du réseau de production. Plusieurs fonctionnalités de sécurité et de pare-feu de base résident dans l’environnement Azure central. Ces fonctionnalités de sécurité reflètent une stratégie de défense en profondeur dans l’environnement Azure. Les pare-feux suivants protègent les données des clients dans Azure :

Pare-feu d’hyperviseur (filtre à paquets) : L’hyperviseur implémente ce pare-feu, et l’agent du contrôleur de fabric (FC) le configure. Ce pare-feu protège le client en cours d’exécution à l’intérieur de la machine virtuelle contre tout accès non autorisé. Par défaut, lorsqu’une VM est créée, Azure bloque tout le trafic, puis l’agent FC ajoute des règles et des exceptions dans le filtre pour permettre le trafic autorisé.

Azure programme deux catégories de règles :

  • Règles de configuration ou d’infrastructure de la machine : Par défaut, Azure bloque toute communication. Les exceptions permettent à une VM d’envoyer et de recevoir les communications et informations DNS du protocole de configuration dynamique hôte (DHCP), et d’envoyer du trafic vers l’internet « public » sortant vers d’autres VM au sein du cluster FC et du serveur d’activation du système d’exploitation. Comme la liste autorisée des destinations sortantes des VM n'inclut pas les sous-réseaux de routeurs Azure ni les autres propriétés Microsoft, les règles servent de couche de défense pour eux.
  • Règles de fichier de configuration de rôle : Ces règles définissent les ACL entrantes en fonction du modèle de service des locataires. Par exemple, si un locataire possède une interface web sur le port 80 d’une certaine VM, le port 80 est ouvert à toutes les adresses IP. Si la machine virtuelle exécute un rôle de travail, ce rôle n’est accessible que depuis la machine virtuelle du même locataire.

Pare-feu hôte natif : Azure Service Fabric et stockage Azure fonctionnent sur un système d’exploitation natif, qui ne possède pas d’hyperviseur et, par conséquent, les deux ensembles de règles précédents configurent le pare-feu Windows.

Pare-feu hôte : Le pare-feu hôte protège la partition hôte, qui exécute l’hyperviseur. Les règles permettent uniquement aux FC et aux boîtes de saut de communiquer avec la partition hôte sur un port spécifique. Les autres exceptions sont d’autoriser la réponse DHCP et les réponses DNS. Azure utilise un fichier de configuration machine, qui contient un modèle de règles de pare-feu pour la partition hôte. Une exception de pare-feu hôte existe également qui permet aux VM de communiquer avec les composants hôte, le serveur de fil et le serveur de métadonnées, via des protocoles et ports spécifiques.

Pare-feu invité : Le composant pare-feu Windows du système d’exploitation invité, que les clients peuvent configurer sur les machines virtuelles et le stockage des clients.

Parmi les fonctionnalités de sécurité intégrées aux capacités d’Azure, on trouve :

  • Azure attribue des adresses IP des DIP aux composants d’infrastructure. Un attaquant sur Internet ne peut pas diriger le trafic vers ces adresses car il n'atteindrait pas Microsoft. Les routeurs passerelle Internet filtrent les paquets adressés uniquement vers des adresses internes, afin qu’ils n’entrent pas dans le réseau de production. Les seuls composants qui acceptent le trafic dirigé vers les VIP sont les équilibreurs de charge.

  • Les pare-feux implémentés sur tous les nœuds internes comportent trois considérations principales de l’architecture de sécurité pour chaque scénario donné :

    • Les pare-feux sont placés derrière l’équilibreur de charge et acceptent les paquets de n’importe où. Ces paquets sont destinés à être exposés de l’extérieur et correspondraient aux ports ouverts dans un pare-feu périmétrique traditionnel.
    • Les pare-feux n’acceptent que les paquets provenant d’un ensemble limité d’adresses. Cette considération fait partie de la stratégie défensive en profondeur contre les attaques DDoS. Ces connexions sont authentifiées cryptographiquement.
    • Seuls certains nœuds internes peuvent accéder aux pare-feus. Ils n’acceptent que les paquets provenant d’une liste énumérée d’adresses IP sources, toutes étant des DIP au sein du réseau Azure. Par exemple, une attaque sur le réseau d’entreprise pourrait diriger les requêtes vers ces adresses, mais Azure bloque les attaques à moins que l’adresse source du paquet ne soit une dans la liste énumérée au sein du réseau Azure.
      • Le routeur d'accès au périmètre bloque les paquets sortants adressés à une adresse située dans le réseau Azure à cause de ses routes statiques configurées.

Étapes suivantes

Pour en savoir plus sur ce que Microsoft fait pour sécuriser l’infrastructure Azure, voir :

  • Last updated on