Partager via


Fiabilité dans le Pare-feu Azure

Le Pare-feu Azure est un service de sécurité réseau managé basé sur le cloud qui protège les ressources de réseau virtuel Azure. Il s’agit d’un service de pare-feu entièrement avec état qui inclut une haute disponibilité intégrée et une scalabilité cloud illimitée.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre le Pare-feu Azure résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également la résilience pendant la maintenance du service et met en évidence certaines informations clés sur le contrat de niveau de service du pare-feu (SLA).

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement du Pare-feu Azure pour prendre en charge les exigences de fiabilité de votre solution et sur la façon dont la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour le Pare-feu Azure dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Une instance fait référence à une unité au niveau de la machine virtuelle du pare-feu. Chaque instance représente l’infrastructure qui gère le trafic et effectue des vérifications de pare-feu.

Pour obtenir une haute disponibilité d’un pare-feu, le Pare-feu Azure fournit automatiquement au moins deux instances, sans nécessiter votre intervention ou votre configuration. Le pare-feu s'adapte automatiquement lorsque le débit moyen, la consommation du CPU et l'utilisation de la connexion atteignent des seuils prédéfinis. Pour plus d’informations, consultez Performances du Pare-feu Azure. La plateforme gère automatiquement la création d’instances, la surveillance de l’intégrité et le remplacement d’instances non saines.

Pour bénéficier d’une protection contre les défaillances de serveur et de rack de serveur, le Pare-feu Azure distribue automatiquement les instances entre plusieurs domaines d’erreur au sein d’une région.

Le diagramme suivant illustre un pare-feu avec deux instances :

Diagramme montrant le Pare-feu Azure avec deux instances.

Pour augmenter la redondance et la disponibilité pendant les défaillances du centre de données, vous pouvez activer la redondance de zone pour distribuer des instances entre plusieurs zones de disponibilité.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Pour les applications qui se connectent via le Pare-feu Azure, implémentez une logique de nouvelle tentative avec une interruption exponentielle pour gérer les problèmes de connexion temporaires potentiels. La nature à états du Pare-feu Azure garantit que les connexions légitimes sont gardées pendant de brèves interruptions réseau.

Pendant les opérations de mise à l’échelle, qui prennent 5 à 7 minutes, les connexions existantes sont conservées alors que de nouvelles instances de pare-feu sont ajoutées pour gérer une charge accrue.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Le Pare-feu Azure est déployé automatiquement dans les zones de disponibilité dans les régions prises en charge lors de la création via le portail Azure. Pour les options de configuration de zone avancées, vous devez utiliser Azure PowerShell, Azure CLI, Bicep ou les modèles Azure Resource Manager (modèles ARM).

Le Pare-feu Azure prend en charge les modèles de déploiement redondant interzone et zonal :

  • Redondant interzone : Lorsqu’il est activé pour la redondance de zone, Azure distribue les instances de pare-feu sur plusieurs zones de disponibilité dans la région. Azure gère automatiquement l’équilibrage de charge et le basculement entre les zones.

    Les pare-feu redondants interzone obtiennent le contrat de niveau de service (SLA) de durée de fonctionnement le plus élevé. Ils sont recommandés pour les charges de travail de production qui nécessitent une disponibilité maximale.

    Le diagramme suivant illustre un pare-feu redondant interzone avec trois instances réparties entre trois zones de disponibilité :

    Diagramme montrant le Pare-feu Azure avec trois instances, chacune dans une zone de disponibilité distincte.

    Note

    Si vous créez votre pare-feu à l’aide du portail Azure, la redondance de zone est automatiquement activée.

  • Zonal: Si votre solution est inhabituellement sensible à la latence interzone, vous pouvez associer le Pare-feu Azure à une zone de disponibilité spécifique. Vous pouvez utiliser un déploiement zonal pour déployer plus près de vos serveurs principaux. Toutes les instances d’un pare-feu zonal sont déployées dans cette zone.

    Le diagramme suivant montre un pare-feu zonal avec trois instances déployées dans la même zone de disponibilité :

    Diagramme montrant le Pare-feu Azure avec trois instances, dans la même zone de disponibilité.

    Important

    Nous vous recommandons d’épingler à une seule zone de disponibilité uniquement lorsque la latence interzone dépasse les limites acceptables et que vous avez confirmé que la latence ne répond pas à vos besoins. Un pare-feu zonal seul ne fournit pas de résilience à une panne de zone de disponibilité. Pour améliorer la résilience d’un déploiement de Pare-feu Azure zonal, vous devez déployer manuellement des pare-feu distincts dans plusieurs zones de disponibilité et configurer le routage du trafic et le basculement.

Si vous ne configurez pas un pare-feu pour qu'il soit redondant ou zonal, il est considéré comme non zonal ou régional. Les pare-feu non zonaux peuvent être placés dans n’importe quelle zone de disponibilité de la région. Si une zone de disponibilité de la région subit une panne, des pare-feu non zonaux peuvent se trouver dans la zone affectée et subir des temps d'arrêt.

Soutien régional

Le Pare-feu Azure prend en charge les zones de disponibilité dans toutes les régions qui prennent en charge les zones de disponibilité, où le service pare-feu Azure est disponible.

Spécifications

  • Tous les niveaux du Pare-feu Azure prennent en charge les zones de disponibilité.
  • Pour les pare-feu redondants interzone, vous devez utiliser des adresses IP publiques standard et les configurer pour qu’elles soient redondantes interzone.
  • Pour les pare-feu zonaux, vous devez utiliser des adresses IP publiques standard et les configurer pour qu’elles soient redondantes interzone ou zonales dans la même zone que le pare-feu.

Coûts

Il n’existe aucun coût supplémentaire pour un pare-feu déployé dans plusieurs zones de disponibilité.

Configurez la prise en charge des zones de disponibilité

Cette section explique comment configurer la prise en charge des zones de disponibilité pour vos pare-feu.

  • Créez un pare-feu avec prise en charge des zones de disponibilité : L’approche que vous utilisez pour configurer des zones de disponibilité dépend de la création d’un pare-feu redondant interzone ou zonal et de l’outil que vous utilisez.

    Important

    La redondance de zone est automatiquement activée lorsque vous déployez via le Portail Microsoft Azure. Pour configurer des zones spécifiques, vous devez utiliser un autre outil, tel que Azure CLI, Azure PowerShell, Bicep ou les modèles ARM.

    • Redondant interzone : Lorsque vous déployez un nouveau pare-feu à l’aide du Portail Microsoft Azure, votre pare-feu est redondant par zone par défaut. Pour plus d’informations, consultez Déployer le Pare-feu Azure à l’aide du Portail Microsoft Azure.

      Lorsque vous utilisez Azure CLI, Azure PowerShell, Bicep, modèles ARM ou Terraform, vous pouvez éventuellement spécifier les zones de disponibilité pour le déploiement. Pour déployer un pare-feu redondant interzone, spécifiez deux zones ou plus. Nous vous recommandons de sélectionner toutes les zones afin que votre pare-feu puisse utiliser chaque zone de disponibilité, sauf si vous avez une raison spécifique d’exclure une zone.

      Pour plus d’informations sur le déploiement d’un pare-feu ZR, consultez Déployer un pare-feu Azure avec des zones de disponibilité.

      Note

      Lorsque vous sélectionnez les zones de disponibilité à utiliser, vous sélectionnez en fait la zone de disponibilité logique. Si vous déployez d’autres composants de charge de travail dans un autre abonnement Azure, ils peuvent utiliser un autre numéro de zone de disponibilité logique pour accéder à la même zone de disponibilité physique. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

  • Activez la prise en charge des zones de disponibilité sur un pare-feu existant : Vous pouvez activer les zones de disponibilité sur un pare-feu existant s’il répond à des critères spécifiques. Le processus vous oblige à arrêter (libérer) le pare-feu et à le reconfigurer. Attendez-vous à un temps d’arrêt. Pour plus d’informations, consultez Configurer les zones de disponibilité après le déploiement.

  • Modifiez la configuration de la zone de disponibilité d’un pare-feu existant : Pour modifier la configuration de la zone de disponibilité, vous devez d’abord arrêter (libérer) le pare-feu, un processus qui implique un certain temps d’arrêt. Pour plus d’informations, consultez Configurer les zones de disponibilité après le déploiement.

  • Désactiver la prise en charge des zones de disponibilité : Vous pouvez modifier les zones de disponibilité utilisées par un pare-feu, mais vous ne pouvez pas convertir un pare-feu redondant ou zonal en une configuration non zonale.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque le Pare-feu Azure est configuré avec la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

  • Routage du trafic entre les zones : Le comportement de routage du trafic dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Redondant interzone : Le Pare-feu Azure distribue automatiquement les requêtes entrantes entre les instances de toutes les zones que votre pare-feu utilise. Cette configuration active-active garantit des performances et une répartition de charge optimales dans des conditions de fonctionnement normales.

    • Zonal: Si vous déployez plusieurs instances zonales sur différentes zones, vous devez configurer le routage du trafic à l’aide de solutions d’équilibrage de charge externes telles qu’Azure Load Balancer ou Azure Traffic Manager.

  • Gestion des instances : La plateforme gère automatiquement l’emplacement des instances dans les zones que votre pare-feu utilise, en remplaçant les instances ayant échoué et en conservant le nombre d’instances configurées. La surveillance de l’état de santé garantit que seules les instances saines reçoivent du trafic.

  • Réplication des données entre les zones : Le Pare-feu Azure n’a pas besoin de synchroniser l’état de connexion entre les zones de disponibilité. Instance qui traite la requête conserve l’état de chaque connexion.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque le Pare-feu Azure est configuré avec la prise en charge des zones de disponibilité et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles.

  • Détection et réponse : La responsabilité de la détection et de la réponse dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Redondant interzone : Pour les instances configurées pour utiliser la redondance de zone, la plateforme Pare-feu Azure détecte et répond à une défaillance dans une zone de disponibilité. Vous n’avez pas besoin de lancer un basculement de zone.

    • Zonal: Pour que les pare-feu configurés soient zonaux, vous devez détecter la perte d’une zone de disponibilité et lancer un basculement vers un pare-feu secondaire que vous créez dans une autre zone de disponibilité.

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.
  • Connexions actives : Lorsqu'une zone de disponibilité n'est pas disponible, les requêtes en cours connectées à une instance de pare-feu dans la zone de disponibilité défectueuse peuvent se terminer et nécessiter de nouvelles tentatives.

  • Perte de données attendue : Aucune perte de données n’est attendue pendant le basculement de zone, car le Pare-feu Azure ne stocke pas les données client persistantes.

  • Temps d’arrêt attendu : Le temps d’arrêt dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Redondant interzone : Attendez un temps d’arrêt minimal (généralement quelques secondes) pendant une panne de zone de disponibilité. Les applications clientes doivent suivre les pratiques de gestion des erreurs temporaires, notamment l’implémentation de stratégies de nouvelle tentative avec une interruption exponentielle.

    • Zonal : Lorsqu’une zone n’est pas disponible, votre pare-feu reste indisponible jusqu’à ce que la zone de disponibilité récupère.

  • Réacheminement du trafic : Le comportement de réacheminement du trafic dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Redondant interzone : Le trafic redirige automatiquement vers des zones de disponibilité saines. Si nécessaire, la plateforme crée de nouvelles instances de pare-feu dans des zones saines.

    • Zonal : Lorsqu’une zone n’est pas disponible, votre pare-feu zonal n’est pas disponible. Si vous disposez d’un pare-feu secondaire dans une autre zone de disponibilité, vous êtes responsable de la réacheminement du trafic vers ce pare-feu.

Restauration automatique

Le comportement de restauration automatique dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

  • Redondant interzone : Une fois la zone de disponibilité récupérée, le Pare-feu Azure redistribue automatiquement des instances dans toutes les zones que votre pare-feu utilise et restaure l’équilibrage de charge normal entre les zones.

  • Zonal : Une fois la zone de disponibilité récupérée, vous êtes responsable de la réacheminement du trafic vers le pare-feu dans la zone de disponibilité d’origine.

Tester les pannes de zone

Les options de test des défaillances de zone dépendent de la configuration de la zone de disponibilité de votre pare-feu.

  • Zone-redondant : La plateforme pare-feu Azure gère le routage du trafic, le basculement et le rétablissement pour les ressources de pare-feu zone-redondantes. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

  • Zonal : Vous pouvez simuler des aspects de l’échec d’une zone de disponibilité en arrêtant un pare-feu. Utilisez cette approche pour tester la façon dont d’autres systèmes et équilibreurs de charge gèrent une panne dans le pare-feu. Pour plus d’informations, consultez Arrêter et démarrer le Pare-feu Azure.

Résilience aux défaillances à l’échelle de la région

Le Pare-feu Azure est un service à région unique. Si la région n’est pas disponible, votre ressource de pare-feu n’est pas disponible.

Solutions multirégions personnalisées pour la résilience

Pour implémenter une architecture multirégionale, utilisez des pare-feu distincts. Cette approche vous oblige à déployer un pare-feu indépendant dans chaque région, à router le trafic vers le pare-feu régional approprié et à implémenter une logique de basculement personnalisée. Tenez compte des points suivants :

  • Utilisez Azure Firewall Manager pour la gestion centralisée des stratégies sur plusieurs pare-feu. Utilisez la méthode de stratégie de pare-feu pour la gestion centralisée des règles sur plusieurs instances de pare-feu.

  • Implémentez le routage du trafic à l’aide de Traffic Manager ou d’Azure Front Door.

Pour un exemple d’architecture illustrant les architectures de sécurité réseau multirégionales, consultez Équilibrage de charge multirégional à l’aide de Traffic Manager, du Pare-feu Azure et d’Application Gateway.

Résilience à la maintenance du service

Le Pare-feu Azure effectue des mises à niveau de service régulières et d’autres formes de maintenance.

Vous pouvez configurer des fenêtres de maintenance quotidienne pour aligner les planifications de mise à niveau avec vos besoins opérationnels. Pour plus d’informations, consultez Configurer la maintenance contrôlée par le client pour le Pare-feu Azure.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Le Pare-feu Azure fournit un contrat SLA de disponibilité plus élevé pour les pare-feu déployés sur deux zones de disponibilité ou plus.