Fonctionnalités du Pare-feu Azure Premium
Le pare-feu Azure Premium offre une protection avancée contre les menaces qui répond aux besoins des environnements hautement sensibles et réglementés, tels que les secteurs des paiements et des soins de santé.
Les organisations peuvent utiliser des fonctionnalités de références SKU Premium, comme l’inspection IDPS et TLS, pour empêcher les programmes malveillants et les virus de se répandre sur les réseaux dans des directions latérales et horizontales. Pour répondre aux demandes de performances accrues de fournisseurs et de l’inspection TLS, le pare-feu Azure Premium utilise une référence SKU de machine virtuelle plus puissante. À l’instar de la référence SKU Standard, la référence SKU Premium peut monter sans problème jusqu’à 100 Gbits/s et s’intégrer aux zones de disponibilité pour prendre en charge le contrat de niveau de service (SLA) de 99,99 %. La référence SKU Premium est conforme aux besoins des environnements PCI DSS (Payment Card Industry Data Security Standard).
Le Pare-feu Azure Premium inclut les fonctionnalités suivantes :
- Inspection TLS : déchiffre le trafic sortant, traite les données, puis les chiffre et les transmet à la destination.
- IDPS : un système IDPS (Intrusion Detection and Prevention System) vous permet de surveiller les activités malveillantes, de consigner des informations sur ces activités, de les signaler, voire de les bloquer.
- Filtrage d’URL : étend la fonctionnalité de filtrage de nom de domaine complet du Pare-feu Azure pour prendre en compte une URL entière ainsi que tout chemin supplémentaire. Par exemple,
www.contoso.com/a/cplutôt quewww.contoso.com. - Catégories web : permettent aux administrateurs d’autoriser ou de refuser aux utilisateurs l’accès aux catégories de sites web telles que les sites web de jeux d’argent, les sites web de réseaux sociaux, etc.
Pour comparer les fonctionnalités Pare-feu Azure pour toutes les références SKU du pare-feu, consultez Choisir la référence SKU du Pare-feu Azure adaptée à vos besoins.
Inspection TLS
Le protocole TLS (Transport Layer Security) fournit principalement un chiffrement pour la confidentialité, l’intégrité et l’authenticité en utilisant des certificats entre deux applications de communication ou plus. Il s’exécute dans la couche application et est largement utilisé pour chiffrer le protocole HTTP.
Le trafic chiffré a un risque de sécurité possible, et peut masquer une activité utilisateur illégale et un trafic malveillant. Le Pare-feu Azure sans inspection TLS (comme indiqué dans le diagramme suivant) n’a aucune visibilité sur les données qui circulent dans le tunnel TLS chiffré. Il ne peut donc pas fournir une couverture de protection complète.
Le second diagramme montre comment le Pare-feu Azure Premium met fin aux connexions TLS et les inspecte pour détecter, alerter et atténuer les activités malveillantes dans HTTPS. Le pare-feu crée deux connexions TLS dédiées : une avec le serveur web (contoso.com) et une autre avec le client. À l’aide du certificat d’autorité de certification fourni par le client, il génère un certificat à la volée qui remplace le certificat de serveur web et le partage avec le client pour établir la connexion TLS entre le pare-feu et le client.
Pare-feu Azure sans inspection TLS : 
Pare-feu Azure avec inspection TLS : 
Les cas d’usage suivants sont pris en charge avec le Pare-feu Azure :
Inspection TLS du trafic sortant
Pour vous protéger contre le trafic malveillant envoyé depuis un client interne hébergé dans Azure vers Internet.
Inspection TLS du trafic Est-Ouest (comprend le trafic qui part depuis/vers un réseau local)
Pour protéger vos charges de travail Azure contre le trafic malveillant potentiel envoyé à partir d’Azure.
Le cas d’usage suivant est pris en charge par Azure Web Application Firewall sur Azure Application Gateway :
Inspection TLS du trafic entrant
Pour protéger les serveurs internes ou les applications hébergées dans Azure contre les demandes malveillantes provenant d’Internet ou d’un réseau externe. Application Gateway fournit un chiffrement de bout en bout.
Pour plus d’informations, consultez :
Conseil
Les versions 1.0 et 1.1 de TSL sont déconseillées et non prises en charge. Les versions 1.0 et 1.1 de TLS/SSL (Secure Sockets Layer) se sont avérées vulnérables et bien qu’elles fonctionnent encore pour assurer la compatibilité descendante, elles sont déconseillées. Migrez vers TLS 1.2 dès que possible.
Pour en savoir plus sur les conditions requises pour les certificats d’autorité de certification intermédiaires du Pare-feu Azure Premium, consultez Certificats du Pare-feu Azure Premium.
Pour en savoir plus sur l’inspection TLS, consultez Création d’une preuve de concept pour l’inspection TLS dans le Pare-feu Azure.
IDPS
Un système IDPS (Intrusion Detection and Prevention System) vous permet de surveiller les activités malveillantes, de consigner des informations sur ces activités, de les signaler, voire de les bloquer.
Le Pare-feu Azure Premium propose un système IDPS basé sur les signatures pour permettre une détection rapide des attaques en recherchant des modèles spécifiques, tels que des séquences d’octets dans le trafic réseau ou des séquences d’instructions malveillantes connues utilisées par un programme malveillant. Les signatures IDPS sont applicables au trafic de niveau application et de niveau réseau (couches 3-7). Elles sont complètement managées et mises à jour en permanence. Les IDP peuvent être appliqués au trafic entrant, au trafic spoke-to-spoke (est-ouest) et au trafic sortant. Spoke-to-spoke (Est-Ouest) comprend le trafic qui part depuis/vers un réseau local. Vous pouvez configurer vos plages d’adresses IP privées IDPS à l’aide de la fonctionnalité Plages d’adresses IP privées. Pour plus d’informations, consultez Plages d’adresses IP privées IDPS.
Les signatures/ensembles de règles du Pare-feu Azure incluent les éléments suivants :
- Accent mis sur la prise d’empreinte numérique des logiciels malveillants, des centres de commande et de contrôle, des kits de code malveillant exploitant une faille de sécurité et des diverses activités malveillantes manquées par les méthodes de protection traditionnelles
- Plus de 67 000 règles dans plus de 50 catégories.
- Exemples de catégories : commande et contrôle des logiciels malveillants, hameçonnage, chevaux de Troie, botnets, événements d’information, code malveillant exploitant une faille de sécurité, vulnérabilités, protocoles réseau SCADA, activité des kits de code malveillant, etc.
- Entre 20 et 40 nouvelles règles publiées quotidiennement
- Faible classification des faux positifs grâce à des techniques de pointe de détection des programmes malveillants, telles que la boucle de rétroaction du réseau de capteurs globaux.
Le système IDPS vous permet de détecter des attaques dans tous les ports et protocoles pour le trafic non chiffré. Cela étant, lorsque le trafic HTTPS doit être inspecté, le Pare-feu Azure peut utiliser sa fonction d’inspection TLS pour déchiffrer le trafic et mieux détecter les activités malveillantes.
La liste de contournement IDPS est une configuration qui vous permet de ne pas filtrer le trafic vers les adresses IP, les plages et les sous-réseaux spécifiés dans cette liste. La liste de contournement IDPS n’est pas destinée à améliorer les performances de débit, car le pare-feu reste soumis aux performances associées à votre cas d’usage. Pour plus d’informations, consultez Performances du Pare-feu Azure.
Plages d'adresses IP privées IDPS
Dans Pare-feu Azure Premium IDPS, les plages d’adresses IP privées sont utilisées pour identifier si le trafic est entrant, sortant ou interne (Est-Ouest). Chaque signature est appliquée à une direction de trafic spécifique, comme indiqué dans la table des règles de signature. Par défaut, seules les plages définies par la RFC IANA 1918 sont considérées comme des adresses IP privées. Le trafic envoyé d’une plage d’adresses IP privées à une plage d’adresses IP privées est donc considéré comme interne. Pour modifier vos adresses IP privées, vous pouvez facilement modifier, supprimer ou ajouter des plages en fonction des besoins.
Règles de signature IDPS
Les règles de signature IDPS vous permettent d’effectuer les opérations suivantes :
Personnalisez une ou plusieurs signatures et changer leur mode en Désactiver, Alerter ou Alerter et refuser.
Par exemple, si vous recevez un faux positif pour le blocage d’une demande légitime par le Pare-feu Azure en raison d’une signature défectueuse, vous pouvez utiliser l’ID de signature issu des journaux des règles réseau et définir son mode IDPS sur désactivé. La signature « défectueuse » est ainsi ignorée et le problème de faux positif est résolu.
Vous pouvez appliquer la même procédure de réglage aux signatures qui créent un trop grand nombre d’alertes de faible priorité et, par conséquent, empêchent de voir des alertes de haute priorité.
Obtenir une vue holistique de l’intégralité des 55 000 signatures
Recherche intelligente
Cette action vous permet d’effectuer des recherches dans l’ensemble de la base de données de signatures par n’importe quel type d’attribut. Par exemple, vous pouvez rechercher un identifiant CVE-ID spécifique pour découvrir quelles signatures prennent en charge cette CVE en tapant l’ID dans la barre de recherche.
Les règles de signature IDPS présentent les propriétés suivantes :
| Colonne | Description |
|---|---|
| ID de signature | ID interne pour chaque signature. Cet ID est également présenté dans les journaux des règles réseau du Pare-feu Azure. |
| Mode | Indique si la signature est active ou non, et si le pare-feu abandonne les trafics correspondants ou génère des alertes. Le mode de signature ci-dessous peut remplacer le mode IDPS - Désactivé : la signature n’est pas activée sur votre pare-feu. - Alerte : vous recevez des alertes lorsqu’un trafic suspect est détecté. - Alerter et refuser : vous recevez des alertes et le trafic suspect est bloqué. Seules quelques catégories de signatures sont définies sur « Alerter uniquement » : par conséquent, par défaut, le trafic correspondant à ces signatures n’est pas bloqué, même si le mode IDPS est défini sur « Alerter et refuser ». Les clients peuvent changer cela en personnalisant ces signatures spécifiques avec le mode « Alerter et refuser ». L’une des raisons suivantes détermine le mode Signature IDPS : 1. Défini par le mode stratégie : Le mode Signature découle du mode IDPS de la stratégie existante. 2. Défini par la stratégie parente : Le mode Signature découle du mode IDPS de la stratégie parente. 3. Remplacé : Vous pouvez remplacer et personnaliser le mode Signature. 4. Défini par système : Le mode Signature est défini sur Alerte uniquement par le système du fait de sa catégorie. Vous pouvez remplacer ce mode signature. Remarque : les alertes IDPS sont disponibles sur le portail via une requête de journal de règles réseau. |
| Gravité | Chaque signature est associée à un niveau de gravité et se voit attribuer une priorité qui indique la probabilité d’une attaque réelle. - Faible (priorité 3) : un événement anormal est un événement qui ne se produit normalement pas sur un réseau ou des événements d’information sont journalisés. La probabilité d’une attaque est faible. - Moyenne (priorité 2) : la signature indique une attaque de nature suspecte. L’administrateur doit effectuer des recherches plus poussées. - Élevée (priorité 1) : les signatures d’attaque indiquent qu’une attaque de nature grave est en cours. Il est très peu probable que les paquets aient un objectif légitime. |
| Direction | Direction du trafic à laquelle s’applique la signature. - Entrant : la signature s’applique uniquement au trafic en provenance d’Internet et à destination de votre plage d’adresses IP privées configurée. - Sortant : la signature s’applique uniquement au trafic envoyé vers Internet à partir de votre plage d’adresses IP privées configurée. - Interne : la signature s’applique uniquement au trafic envoyé à partir de et destiné à votre plage d’adresses IP privées configurée. - Interne/Entrant : La signature s’applique au trafic en provenance de votre plage d’adresses IP privées configurée ou d’Internet et à destination de votre plage d’adresses IP privées configurée. - Interne/Sortant : La signature s’applique au trafic en provenance de votre plage d’adresses IP privées configurée et à destination de votre plage d’adresses IP privées configurée ou d’Internet. - Quelconque : la signature s’applique toujours, quelle que soit la direction du trafic. |
| Groupe | Nom du groupe auquel la signature appartient. |
| Description | Structurée à partir des trois parties suivantes : - Nom de la catégorie : nom de la catégorie à laquelle appartient la signature, comme décrit dans Catégories de règles de signature IDPS pour le Pare-feu Azure. - Description générale de la signature - ID CVE (facultatif) dans le cas où la signature est associée à une CVE spécifique. |
| Protocol | Protocole associé à la signature. |
| Ports source/destination | Ports associés à la signature. |
| Dernière mise à jour | Dernière date à laquelle cette signature a été introduite ou modifiée. |
Pour plus d’informations sur IDPS, consultez Prise de Pare-feu Azure IDPS sur une version d’évaluation.
Un filtrage des URL
Le filtrage d’URL étend la fonctionnalité de filtrage de nom de domaine complet du Pare-feu Azure pour prendre en compte une URL entière. Par exemple, www.contoso.com/a/c plutôt que www.contoso.com.
Le filtrage d’URL peut être appliqué au trafic HTTP et HTTPS. Lorsque le trafic HTTPS est inspecté, le Pare-feu Azure Premium peut utiliser sa fonctionnalité d’inspection TLS pour déchiffrer le trafic et extraire l’URL cible afin de vérifier si l’accès est autorisé. L’inspection TLS nécessite un consentement au niveau de la règle d’application. Après activation, vous pouvez utiliser des URL pour le filtrage avec HTTPS.
Catégories web
Les catégories Web permettent aux administrateurs d’autoriser ou de refuser l’accès des utilisateurs à des catégories de sites Web, telles que les sites de jeux d’argent, les sites de réseaux sociaux et autres. Les catégories web sont également incluses dans le niveau tarifaire Standard du service Pare-feu Azure, mais elles sont mieux ajustées dans niveau tarifaire Premium de ce service. Contrairement à la fonctionnalité de catégories web de la référence SKU Standard qui correspond à la catégorie basée sur un nom de domaine complet, la référence SKU Premium correspond à la catégorie en fonction de l’URL complète pour le trafic HTTP et HTTPS.
Les catégories Web Premium du Pare-feu Azure sont disponibles uniquement dans les stratégies de pare-feu. Assurez-vous que la référence SKU de votre stratégie correspond à la référence SKU de votre instance pare-feu. Par exemple, si vous avez une instance pare-feu Premium, vous devez utiliser une stratégie Pare-feu Premium.
Par exemple, si le Pare-feu Azure intercepte une demande HTTPS pour www.google.com/news, la catégorisation suivante est attendue :
Niveau tarifaire Standard du service Pare-feu Azure : seule la partie du nom de domaine complet est examinée, donc
www.google.comest placé dans la catégorie Moteur de recherche.Niveau tarifaire Premium du service Pare-feu Azure : toute l’URL est examinée, donc
www.google.com/newsest placé dans la catégorie Actualités.
Les catégories sont organisées en fonction de leur gravité sous Responsabilité, Bande passante élevée, Utilisation métier, Perte de productivité, Navigation générale et Sans catégorie. Pour obtenir une description détaillée des catégories Web, consultez Catégories web Azure Firewall.
Journalisation des catégories web
Vous pouvez afficher le trafic ayant été filtré par le champ Catégories web dans les journaux d’application. Le champ Catégories web s’affiche uniquement s’il a été explicitement configuré dans vos règles d’application de stratégie de pare-feu. Par exemple, si vous n’avez pas de règle qui refuse explicitement les moteurs de recherche et qu’un utilisateur demande à accéder à www.bing.com, seul un message de refus par défaut s’affiche au lieu d’un message de catégorie web. Cela est dû au fait que la catégorie web n’a pas été explicitement configurée.
Exceptions de catégorie
Vous pouvez créer des exceptions à vos règles de catégorie web. Créez une collection de règles d’autorisation ou de refus distincte avec une priorité plus élevée au sein du groupe de collections de règles. Par exemple, vous pouvez configurer une collection de règles qui autorise www.linkedin.com avec la priorité 100, avec une collection de règles qui refuse Réseaux sociaux avec la priorité 200. Cette opération crée l’exception pour la catégorie web Réseaux sociaux prédéfinie.
Recherche de catégorie web
Vous pouvez identifier la catégorie d’un FQDN ou d’une URL donnés à l’aide de la fonctionnalité de contrôle de catégorie web. Pour ce faire, sélectionnez l’onglet Catégories web sous Paramètres de stratégie de pare-feu. C’est utile lors de la définition de vos règles d’application pour le trafic de destination.
Important
Pour utiliser la fonctionnalité Vérification des catégories web, l’utilisateur doit disposer d’un accès à Microsoft.Network/azureWebCategories/* pour le niveau abonnement, et non au niveau du groupe de ressources.
Changement de catégorie
Sous l’onglet Catégories web des Paramètres de stratégie de pare-feu, vous pouvez demander un changement de catégorie si vous :
pensez qu’un nom de domaine complet (FQDN) ou une URL doit être dans une catégorie différente
or
avez une catégorie suggérée pour un FQDN ou une URL sans catégorie
Une fois que vous avez envoyé un rapport de changement de catégorie, vous recevez un jeton dans les notifications. Il indique que nous avons reçu la requête à traiter. Vous pouvez vérifier si la demande est en cours, refusée ou approuvée en entrant le jeton dans la barre de recherche. Pour ce faire, veillez à enregistrer votre ID de jeton.
Catégories web qui ne prennent pas en charge la terminaison TLS
Pour des raisons de confidentialité et de conformité, certains trafics web chiffrés ne peuvent pas être déchiffrés à l’aide de la terminaison TLS. Par exemple, des données d’intégrité des employés transmises via le trafic web sur un réseau d’entreprise ne doivent pas être terminées par TLS pour des raisons de confidentialité.
Par conséquent, les catégories web suivantes ne prennent pas en charge la terminaison TLS :
- Education
- Finance
- Administration
- Santé et médecine
En tant que solution de contournement, si vous souhaitez qu’une URL spécifique prenne en charge la terminaison TLS, vous pouvez ajouter manuellement la ou les URL avec une terminaison TLS dans des règles d’application. Par exemple, vous pouvez ajouter www.princeton.edu à des règles d’application pour autoriser ce site web.
Régions prises en charge
Pour connaître les régions prises en charge par Pare-feu Azure, consultez Disponibilité des produits Azure par région.