Sécuriser votre déploiement Azure Load Balancer

Azure Load Balancer fournit des fonctionnalités d’équilibrage de charge de couche 4 pour distribuer le trafic entrant et sortant entre les instances principales saines. Étant donné que Load Balancer fonctionne au niveau de la couche de transport, vous devez la combiner avec les contrôles réseau, les contrôles d’identité, la supervision et le chiffrement au niveau de la charge de travail pour sécuriser le déploiement complet.

Cet article fournit des recommandations de sécurité pour Azure Load Balancer. L’implémentation de ces recommandations vous aide à remplir vos obligations de sécurité et améliore la posture globale de sécurité de votre déploiement. Pour obtenir une vue d'ensemble des services de sécurité réseau de Azure et de leur fonctionnement ensemble, consultez Quel est Azure sécurité réseau ?.

Les recommandations de sécurité de cet article implémentent des principes de confiance zéro : « Vérifier explicitement », « Utiliser l’accès au privilège minimum » et « Supposer une violation ». Pour obtenir des conseils complets sur la confiance zéro, consultez le Centre d’aide sur la confiance Zéro.

Sécurité réseau

La sécurité réseau pour Azure Load Balancer se concentre sur la limitation de l’exposition entrante, le contrôle de la connectivité sortante, la validation de l’intégrité du serveur principal et l’intégration à d’autres services de sécurité réseau Azure.

• Utiliser le SKU Standard de Load Balancer : déployez Standard Load Balancer pour les charges de travail de production. Standard Load Balancer suit un modèle sécurisé par défaut avec des connexions entrantes fermées, prend en charge les zones de disponibilité et fournit un contrat SLA de 99,99%. Les Load Balancer de base ont été retirées le 30 septembre 2025 et ne doivent pas être utilisées pour les nouveaux déploiements. Pour plus d’informations, consultez Vue d’ensemble de Azure Load Balancer.

• Implémenter des groupes de sécurité réseau sur les sous-réseaux et interfaces réseau : Appliquer des groupes de sécurité réseau (NSG) aux sous-réseaux backend et aux interfaces réseau pour n’autoriser explicitement que le trafic applicatif requis. Les règles d’équilibrage de charge associent le trafic frontend aux pools backend, tandis que les NSG déterminent indépendamment si ce trafic est autorisé. Pour plus d’informations, consultez Azure Load Balancer base de référence de sécurité.

• Autoriser le trafic de la sonde de santé Azure Load Balancer : Vérifiez l’accès à la sonde de santé séparément de l’accès au trafic applicatif. Autoriser l’étiquette AzureLoadBalancer de service dans les NSG et l’adresse IP 168.63.129.16 dans les politiques locales du pare-feu afin que les sondes puissent atteindre les instances backend. Pour plus d’informations, consultez Sondes d’intégrité Azure Load Balancer.

• Utilisez l’équilibreur de charge interne pour les charges de travail privées : déployez un équilibreur de charge interne avec des adresses IP frontales privées lorsque le service n’a pas besoin d’une exposition Internet directe. Utilisez le peering de réseaux virtuels, vpn, ExpressRoute, Pare-feu Azure ou modèles d’accès privé pour contrôler qui peut atteindre le front-end. Pour plus d’informations, consultez Azure Load Balancer composants.

• Protéger les équilibreurs de charge publics avec Azure protection DDoS : activez Azure protection réseau DDoS sur le réseau virtuel qui héberge des équilibreurs de charge publics. La protection DDoS fournit des fonctionnalités améliorées d’atténuation et de détection DDoS qui surveillent les points de terminaison pour détecter les menaces et les signes d’abus. Pour plus d’informations, consultez Protéger votre équilibreur de charge public avec Azure protection DDoS.

• Utilisez une connectivité sortante explicite : ne vous fiez pas à l’accès sortant par défaut. Pour les versions d’API publiées après le 31 mars 2026, les nouveaux réseaux virtuels utilisent par défaut des sous-réseaux privés et nécessitent une méthode sortante explicite pour atteindre les points publics. Les réseaux virtuels existants ne sont pas modifiés automatiquement. Utilisez Azure NAT Gateway pour des adresses IP sortantes prévisibles, ou configurez des règles explicites de Standard Load Balancer pour les sortants lorsque NAT Gateway n'est pas approprié. Pour plus d’informations, consultez la vue d’ensembledes connexions sortantes dans Azure et Azure NAT Gateway.

• Configurez le mode de distribution approprié : sélectionnez le mode de distribution adapté à vos exigences d’application et de sécurité. Utilisez le hachage 5 tuples par défaut pour la plupart des charges de travail et utilisez la persistance de session uniquement lorsque l’application l’exige, car la persistance peut créer une distribution inégale et réduire la résilience. Pour plus d’informations, consultez Azure Load Balancer modes de distribution.

• Activez la réinitialisation TCP pour une gestion plus claire des connexions : configurez la réinitialisation TCP sur les règles d’équilibrage de charge afin que les clients et les applications back-end reçoivent des paquets de réinitialisation TCP bidirectionnels lors du délai d’inactivité. Un état de connexion clair aide les applications à récupérer plus rapidement et réduit les connexions semi-ouvertes ambiguës. Pour plus d’informations, consultez Azure Load Balancer meilleures pratiques.

• Architectures sécurisées avec adresses IP flottantes et Gateway Load Balancer : lorsque vous utilisez une adresse IP flottante dans des scénarios de haute disponibilité, configurez correctement les interfaces de bouclage et appliquez les règles du pare-feu de l’hôte. Pour Gateway Load Balancer et les appliances virtuelles réseau, séparez le trafic de confiance et le trafic non fiable sur des interfaces de tunnel distinctes et tenez compte de la surcharge de l’en-tête VXLAN. Pour plus d’informations, consultez Azure Load Balancer meilleures pratiques.

• Intégrez des services d’inspection si nécessaire : Azure Load Balancer est un service de couche 4 et n’inspecte pas le contenu des paquets applicatifs. Acheminer le trafic via Pare-feu Azure, les appliances virtuelles réseau, Application Gateway ou Azure Front Door lorsque vous avez besoin d’un pare-feu, d’un pare-feu d’applications web ou d’une inspection de couche 7. Pour plus d’informations, consultez les meilleures pratiques relatives à l’architecture pour Azure Load Balancer.

Gestion de l’identité et de l’accès

Gestion des identités et des accès pour les contrôles Azure Load Balancer qui peuvent créer, mettre à jour, supprimer et examiner les ressources de l’équilibreur de charge, les règles, les sondes, les adresses IP frontales, les pools principaux et la connectivité sortante.

• Utilisez Microsoft Entra ID pour l’accès au plan de gestion : exiger que les administrateurs s’authentifient auprès de Microsoft Entra ID lors de l’utilisation du portail Azure, Azure CLI, Azure PowerShell ou Azure Resource Manager Api. Appliquez des contrôles d’accès conditionnel tels que l’authentification multifacteur, les exigences d’appareil conformes et les stratégies de risque de connexion pour les rôles réseau privilégiés. Pour plus d’informations, consultez Accès conditionnel Microsoft Entra.

• Implémenter le contrôle d’accès en fonction du rôle Azure : attribuez des rôles Azure RBAC aux utilisateurs, aux groupes, aux identités gérées et aux comptes Automation qui gèrent les équilibreurs de charge. Utilisez des rôles intégrés tels que Contributeur réseau uniquement lorsque l’étendue complète de la gestion du réseau est requise. Pour plus d’informations, consultez Qu’est-ce que Azure contrôle d’accès en fonction du rôle ?.

• Utilisez l’accès au privilège minimum : évitez les affectations de propriétaire ou de contributeur étendues pour les opérations d’équilibreur de charge courantes. Créez des rôles personnalisés lorsque les opérateurs n’ont besoin que d’autorisations spécifiques pour les opérations de lecture, d’écriture, de règle, de sonde ou de pool backend du Load Balancer. Pour plus d’informations, consultez Rôles Azure personnalisés.

• Utilisez Privileged Identity Management pour l’accès avec élévation de privilèges : rendre les rôles à impact élevé éligibles au lieu d’être attribués définitivement à l’aide de Microsoft Entra Privileged Identity Management (PIM). Exiger l’approbation, l’authentification multifacteur, la justification et l’activation liée au temps pour les rôles qui peuvent modifier les équilibreurs de charge de production. Pour plus d’informations, consultez Qu’est-ce que Microsoft Entra Privileged Identity Management ?.

• Tâches distinctes pour les équipes de mise en réseau et de charge de travail : limite qui peut modifier les règles d’équilibrage de charge, les règles NAT de trafic entrant, les règles de trafic sortant, l’appartenance au pool principal et les paramètres de sonde. La séparation des tâches réduit le risque qu’une seule identité compromise puisse exposer un service et modifier la charge de travail derrière elle. Pour plus d’informations, consultez les meilleures pratiques Azure RBAC.

• Auditer les modifications du plan de gestion : surveillez les événements du journal d’activité Azure concernant les modifications de configuration de l’équilibreur de charge, les attributions de rôles et les modifications des paramètres de diagnostic. Alerter en cas de mises à jour inattendues des configurations IP du front-end, des mappages de règles, des règles de trafic sortant ou de l’appartenance au pool back-end. Pour plus d’informations, consultez Surveiller Azure Load Balancer.

Protection de données

La protection des données pour Azure Load Balancer se concentre sur la protection du trafic géré par les charges de travail back-end et la protection de la configuration et de la télémétrie, car Load Balancer ne stocke pas les données d'application client.

• Encrypter le trafic de l'application de bout en bout : Azure Load Balancer fonctionne au niveau de la couche 4 et ne termine pas TLS ni inspecte les charges utiles. Configurez TLS sur l’application back-end ou sur un service de couche 7 devant le serveur principal afin que le trafic reste chiffré si nécessaire. Pour plus d’informations, consultez les meilleures pratiques relatives à l’architecture pour Azure Load Balancer.

• Utilisez le service approprié pour l’arrêt TLS : si votre charge de travail HTTP ou HTTPS nécessite l’arrêt TLS, la gestion des certificats, le routage d’URL ou l’inspection du pare-feu d’applications web, utilisez Azure Application Gateway ou Azure Front Door au lieu de vous appuyer sur Load Balancer pour ces fonctions. Pour plus d’informations, consultez Vue d’ensemble de Azure Load Balancer.

• Protéger les secrets principaux et les certificats : stocker des certificats TLS, des clés privées et des secrets d’application utilisés par les instances principales dans Azure Key Vault. Utilisez des identités managées pour les charges de travail principales au lieu d’incorporer des secrets dans des scripts, des modèles ou des extensions de machine virtuelle. Pour plus d’informations, consultez la vue d’ensemble d’Azure Key Vault.

• Destinations de données de diagnostic sécurisées : les métriques de l’équilibreur de charge, les journaux de flux et les diagnostics archivés peuvent inclure des adresses IP, des ports et des détails de topologie. Limitez l’accès à Log Analytics espaces de travail, comptes de stockage et Event Hubs qui reçoivent des diagnostics et utilisez des clés gérées par le client pour les comptes de stockage lorsque vos exigences de conformité les appellent. Pour plus d’informations, consultez chiffrement du stockage Azure.

• Évitez d’exposer la topologie sensible dans les noms et les balises : n’incluez pas de secrets, de noms de projet internes ou de détails réseau sensibles dans les noms d’équilibreur de charge, les noms de règles, les étiquettes DNS IP publiques ou les étiquettes de ressources. Ces valeurs peuvent apparaître dans les journaux, les exportations, les alertes et les vérifications des accès. Pour plus d’informations, consultez règles et restrictions d’affectation de noms pour les ressources Azure.

Enregistrement et surveillance

La journalisation et la surveillance des Azure Load Balancer offrent une visibilité sur la disponibilité, les sondes d’intégrité, les modèles de trafic et les modifications de configuration afin que les équipes puissent détecter rapidement les problèmes de sécurité et de fiabilité.

• Activer les paramètres de diagnostic : Configurez les paramètres de diagnostic pour envoyer les métriques de l’équilibreur de charge et les journaux pris en charge vers un espace de travail Log Analytics, un compte de stockage ou Event Hubs à des fins d’analyse et de conservation. Pour plus d’informations, consultez Surveiller Azure Load Balancer.

• Utilisez Azure Monitor Insights : déployez Load Balancer Insights pour afficher les tableaux de bord préconfigurés, les diagrammes de dépendances fonctionnelles, l’intégrité des ressources et les métriques pour une surveillance proactive. Pour plus d’informations, consultez Utiliser Insights pour surveiller et configurer Azure Load Balancer.

• Configurer la surveillance des sondes d’intégrité : implémentez des sondes d’intégrité qui reflètent fidèlement l’état de préparation de l’application, et non pas uniquement la disponibilité de l’hôte. Surveillez l’état de la sonde afin que les échecs principaux, les blocs de pare-feu et les pannes d’application soient détectés avant que les utilisateurs ne soient affectés. Pour plus d’informations, consultez Gérer les sondes d’intégrité pour Azure Load Balancer.

• Surveiller les métriques de connexion et de disponibilité : suivez les métriques telles que la disponibilité du chemin de données, l’état de la sonde d’intégrité, le nombre de connexions SNAT, le nombre de connexions SNAT et les ports SNAT alloués. Utilisez des alertes pour identifier les back-ends défaillants, les pics de connexion anormales ou l’épuisement des ports sortants. Pour plus d’informations, consultez le diagnostic de Standard Load Balancer à l’aide des métriques, des alertes et de l’intégrité des ressources.

• Activez les journaux de flux de réseau virtuel : configurez les journaux de flux de réseau virtuel pour analyser les modèles de trafic autour des sous-réseaux principaux et identifier les flux suspects ou inattendus. Transférez les journaux vers votre système SIEM afin de les corréler avec les événements liés aux charges de travail et aux identités. Pour plus d’informations, consultez Surveiller Azure Load Balancer.

• Configurez des alertes de sécurité et d’opérations : créez des alertes Azure Monitor pour les sondes d’intégrité ayant échoué, la disponibilité du chemin de données faible, les augmentations inhabituelles du trafic, les indicateurs d’épuisement SNAT et les modifications inattendues du journal d’activité. Incluez des liens de runbook et des informations de propriétaire dans les actions d’alerte. Pour plus d’informations, consultez Surveiller Azure Load Balancer.

Gouvernance et conformité

La conformité et la gouvernance pour Azure Load Balancer permettent de garantir des configurations cohérentes, prises en charge et auditables dans les abonnements, les régions et les environnements.

• Mettre en œuvre des contrôles Azure Policy : utilisez Azure Policy pour auditer et faire respecter les exigences relatives aux équilibreurs de charge, telles que l’utilisation du SKU Standard, les paramètres de diagnostic, les balises et les associations de groupes de sécurité réseau (NSG) sur les sous-réseaux back-end. Pour plus d’informations, consultez Azure Load Balancer base de référence de sécurité.

• Standardisez le déploiement à l’aide de l’infrastructure en tant que code : déployez des équilibreurs de charge, des adresses IP publiques, des règles, des sondes, des pools back-end et des configurations de trafic sortant avec des modèles ARM, Bicep ou d’autres pipelines approuvés d’infrastructure en tant que code. Les modèles contrôlés par version réduisent la dérive et fournissent des preuves pour les révisions de conformité. Pour plus d’informations, consultez Créer un équilibreur de charge public à l’aide de Bicep et créer un équilibreur de charge public à l’aide d’un modèle ARM.

• Utilisez le balisage des ressources : appliquez des balises cohérentes pour le propriétaire de la charge de travail, la classification des données, l’environnement, la critique métier et le niveau de récupération d’urgence. Les balises permettent la gestion des coûts, le suivi de la conformité, le routage des incidents et les revues de propriété. Pour plus d’informations, consultez Azure guide de décision de nommage et de marquage des ressources.

• Passez en revue les configurations non prises en charge et héritées : Inventaire des équilibreurs de charge de base, dépendances sortantes implicites, adresses IP publiques non managées et diagnostics manquants. Hiérarchiser la migration vers Standard Load Balancer, la passerelle NAT ou les règles de trafic sortant explicite et les configurations supervisées. Pour plus d’informations, consultez Upgrade from Basic to Standard Load Balancer.

• Contrôler les modifications par le biais de flux de travail approuvés : exiger une révision des modifications pour les adresses IP frontales, les règles de trafic entrant, les règles NAT, les règles de trafic sortant, l’appartenance au pool principal, les chemins d’accès aux sondes et les paramètres de délai d’inactivité. Utilisez le journal d’activité Azure et l’historique des déploiements pour vérifier que les modifications proviennent d’identités et de pipelines approuvés. Pour plus d’informations, consultez Azure Resource Manager’historique de déploiement.

Sauvegarde et récupération

La sauvegarde et la récupération pour Azure Load Balancer se concentrent sur la préservation de la configuration, la documentation des dépendances et la conception de topologies résilientes qui continuent de circuler pendant les défaillances d’instance, de zone ou régionales.

• Exporter et versionr la configuration de l’équilibreur de charge : exportez la configuration Standard Load Balancer en tant que modèle ARM ou fichier Bicep et stockez-le dans le contrôle de code source. Capturez les configurations IP frontales, les ressources IP publiques, les pools principaux, les règles d’équilibrage de charge, les règles NAT de trafic entrant, les règles de trafic sortant, les sondes d’intégrité et les dépendances afin de pouvoir restaurer ou recréer rapidement le déploiement. Pour plus d’informations, consultez Exporter des modèles dans le portail Azure et Exporter des modèles avec Azure CLI.

• Documentez la topologie avant les modifications : Enregistrer les adresses IP frontales, les noms DNS, les membres du pool principal, les mappages de règle à sonde, les mappages NAT, la conception de connectivité sortante, les dépendances NSG, les tables de routage et les équipes propriétaires avant les modifications planifiées. La documentation actuelle réduit le temps de récupération lorsqu’une restauration ou une reconstruction régionale est nécessaire. Pour plus d’informations, consultez Azure Load Balancer composants.

• Utilisez un équilibreur de charge interrégion pour le basculement multirégion : déployez un équilibreur de charge interrégion, également appelé équilibreur de charge global, lorsque vous avez besoin d’un seul point d’entrée global qui distribue le trafic entre des équilibreurs de charge régionaux. Associez-le à une surveillance régionale de l’état et à des procédures de basculement testées. Pour plus d’informations, consultez l’équilibreur de charge interrégion et déployez un équilibreur de charge inter-régions à l’aide d’un modèle ARM.

• Utilisez les serveurs frontaux redondants interzone pour la résilience des zones de disponibilité : utilisez Standard Load Balancer avec des configurations IP frontales redondantes interzone où les zones de disponibilité sont prises en charge. Le SKU Standard inclut une prise en charge intégrée de la redondance de zone, et un frontend redondant interzone permet de maintenir le chemin de données disponible en cas de défaillance d’une zone. Pour plus d’informations, consultez Azure Load Balancer meilleures pratiques.

• Répartissez les pools back-end entre les zones : placez des instances back-end dans plusieurs zones de disponibilité à l’aide de groupes identiques de machines virtuelles (Virtual Machine Scale Sets) ou de machines virtuelles zonales. Les pools principaux redondants interzone réduisent le risque qu’une défaillance d’une seule zone retire de la rotation toutes les instances saines. Pour plus d’informations, consultez Migrer Load Balancer pour prendre en charge les zones de disponibilité.

• Configurer des sondes d’intégrité pour le basculement automatique au sein de la région : les sondes d’intégrité déterminent quelles instances backend reçoivent le trafic. Configurez des sondes sur des points de terminaison prêts pour l’application, choisissez des intervalles et des seuils appropriés, puis testez le comportement de la sonde pendant la maintenance afin que le trafic bascule automatiquement vers des instances saines au sein de la région. Pour plus d’informations, consultez Gérer les sondes d’intégrité pour Azure Load Balancer.

• Testez régulièrement le basculement : simulez des scénarios de basculement au niveau de l’instance, de la zone et de la région selon un calendrier défini. Vérifiez que les sondes suppriment les instances non saines, les Load Balancer ou le routage DNS envoient du trafic vers la région secondaire, la connectivité sortante fonctionne toujours et les alertes de surveillance atteignent les répondeurs appropriés. Pour plus d’informations, consultez Azure Load Balancer meilleures pratiques.

Étapes suivantes

• base de référence de sécurité Azure Load Balancer
• Qu’est-ce que la sécurité réseau Azure ?