Présentation de la stratégie TLS Application Gateway
Vous pouvez utiliser Azure Application Gateway pour centraliser la gestion des certificats TLS/SSL et réduire la surcharge de chiffrement et de déchiffrement à partir d’un pool de serveurs back-end. Cette gestion TLS centralisée permet également de spécifier une stratégie TLS centrale adaptée aux besoins de sécurité de votre organisation. Celle-ci vous aide à respecter les exigences de conformité ainsi que les directives en matière de sécurité et pratiques recommandées.
La stratégie TLS inclut le contrôle de la version du protocole TLS ainsi que des suites de chiffrement et de l’ordre dans lequel les chiffrements sont utilisés lors d’une négociation TLS. Application Gateway offre deux mécanismes pour contrôler la stratégie TLS. Vous pouvez utiliser une stratégie prédéfinie ou une stratégie personnalisée.
Détails de l’utilisation et de la version
Important
À compter du 31 août 2025, tous les clients et serveurs back-end qui interagissent avec Azure Application Gateway doivent utiliser le protocole TLS (Transport Layer Security) 1.2 ou une version plus récente, car la prise en charge des protocoles TLS 1.0 et 1.1 sera interrompue.
- Les protocoles SSL 2.0 et 3.0 sont désactivés pour toutes les passerelles d’application et ne sont pas configurables.
- Une stratégie TLS personnalisée vous permet de sélectionner n'importe quel protocole TLS comme version de protocole minimale pour votre passerelle : TLSv1_0, TLSv1_1, TLSv1_2 ou TLSv1_3.
- Si aucune stratégie TLS n’est choisie, une stratégie TLS par défaut est appliquée en fonction de la version de l’API utilisée pour créer cette ressource.
- Les nouvelles stratégies 2022 prédéfinies et Customv2 qui prennent en charge TLS v1.3 sont actuellement uniquement disponibles avec les références SKU V2 Application Gateway (Standard_v2 ou WAF_v2).
- L’utilisation d’une stratégie 2022 prédéfinie ou Customv2 améliore la sécurité SSL et la posture de performances de la passerelle entière (pour la stratégie SSL et le profil SSL). Par conséquent, les anciennes et nouvelles stratégies ne peuvent pas coexister sur une passerelle. Vous devez utiliser l’une des stratégies prédéfinies ou personnalisées antérieures sur la passerelle si les clients nécessitent des versions ou des chiffrements TLS plus anciens (par exemple, TLS v1.0).
- Les suites de chiffrement TLS utilisées pour la connexion sont également basées sur le type de certificat utilisé. Les suites de chiffrement utilisées dans les « connexions client-passerelle Application Gateway » sont basées sur le type de certificats écouteur sur la passerelle applicative. Alors que les suites de chiffrement utilisées pour établir « les connexions passerelle applicative vers le pool backend » sont basées sur le type de certificats de serveur présentés par les serveurs principaux.
Stratégie TLS prédéfinie
Application Gateway offre plusieurs stratégies de sécurité prédéfinies. Vous pouvez configurer votre passerelle avec n’importe laquelle de ces stratégies pour obtenir le niveau de sécurité approprié. Les noms de stratégie sont annotés en fonction de leur année et leur mois de configuration (AppGwSslPolicy<AAAAMMJJ>). Chaque stratégie offre différentes versions de protocole TLS et/ou de suites de chiffrement. Ces stratégies prédéfinies sont configurées en gardant à l’esprit les meilleures pratiques et recommandations de l’équipe de sécurité Microsoft. Nous vous recommandons d’utiliser les dernières stratégies TLS pour garantir la meilleure sécurité TLS.
Le tableau suivant montre la liste des suites de chiffrement et la prise en charge minimale des versions de protocole pour chaque stratégie prédéfinie. L’ordre des suites de chiffrement détermine l’ordre de priorité pendant la négociation TLS. Pour connaître l’ordre exact des suites de chiffrement pour ces stratégies prédéfinies, vous pouvez faire référence au panneau PowerShell, CLI, REST ou écouteurs dans le portail.
| Noms de stratégie prédéfinis (AppGwSslPolicy<AAAAMMJJ>) | 20150501 | 20170401 | 20170401S | 20220101 | 20220101S |
|---|---|---|---|---|---|
| Version minimale du protocole | 1.0 | 1.1 | 1,2 | 1.2 | 1.2 |
| Versions du protocole prises en charge | 1.0 1.1 1,2 |
1,1 1,2 |
1.2 | 1.2 1.3 |
1.2 1.3 |
| Par défaut | True (pour la version de l’API < 2023-02-01) |
False | False | True (pour la version de l’API >= 2023-02-01) |
False |
| TLS_AES_128_GCM_SHA256 | ✗ | ✗ | ✗ | ✓ | ✓ |
| TLS_AES_256_GCM_SHA384 | ✗ | ✗ | ✗ | ✓ | ✓ |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ✓ | ✓ | ✓ | ✓ | ✓ |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ✓ | ✓ | ✓ | ✓ | ✓ |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 | ✓ | ✗ | ✗ | ✓ | ✗ |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 | ✓ | ✗ | ✗ | ✓ | ✗ |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_RSA_WITH_AES_256_GCM_SHA384 | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_RSA_WITH_AES_128_GCM_SHA256 | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_RSA_WITH_AES_256_CBC_SHA256 | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_RSA_WITH_AES_128_CBC_SHA256 | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_RSA_WITH_AES_256_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_RSA_WITH_AES_128_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ✓ | ✓ | ✓ | ✓ | ✓ |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ✓ | ✓ | ✓ | ✓ | ✓ |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | ✓ | ✓ | ✓ | ✓ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | ✓ | ✓ | ✓ | ✓ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | ✓ | ✓ | ✓ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_256_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_AES_128_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
| TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA | ✓ | ✗ | ✗ | ✗ | ✗ |
Stratégie de protocole TLS par défaut
Lorsqu’aucune stratégie SSL spécifique n’est spécifiée dans la configuration des ressources de passerelle d’application, une stratégie TLS par défaut est appliquée. La sélection de cette stratégie par défaut est basée sur la version de l’API utilisée pour créer cette passerelle.
- Pour les versions d’API 2023-02-01 ou ultérieures, la version minimale du protocole est définie sur 1.2 (la version jusqu’à 1.3 est prise en charge). Les passerelles créées avec ces versions d’API voient une propriété en lecture seule defaultPredefinedSslPolicy :AppGwSslPolicy20220101 dans la configuration des ressources. Cette propriété définit la stratégie TLS par défaut à utiliser.
- Pour les versions antérieures de l’API < 2023-02-01, la version minimale du protocole est définie sur 1.0 (les versions jusqu’à 1.2 sont prises en charge) car elles utilisent la stratégie prédéfinie AppGwSslPolicy20150501 par défaut.
Si le protocole TLS par défaut ne correspond pas à vos besoins, choisissez une stratégie prédéfinie différente ou utilisez une stratégie personnalisée.
Remarque
La prise en charge d’Azure PowerShell et de l’interface CLI pour la stratégie TLS par défaut mise à jour sera bientôt disponible.
Stratégie TLS personnalisée
Si une stratégie TLS doit être configurée pour vos besoins, vous devez utiliser une stratégie TLS personnalisée. Avec une stratégie TLS personnalisée, vous contrôlez totalement la version minimale du protocole TLS à prendre en charge, ainsi que les suites de chiffrement prises en charge et leur ordre de priorité.
Remarque
Les chiffrements plus récents et plus forts et la prise en charge de TLSv1.3 sont disponibles uniquement avec la stratégie CustomV2. Il offre des avantages améliorés en matière de sécurité et de performances.
Important
- Si vous utilisez une stratégie SSL personnalisée dans le SKU Application Gateway v1 (Standard ou WAF), assurez-vous d’ajouter le chiffrement obligatoire « TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 » à la liste. Ce chiffrement est requis pour activer les métriques et la journalisation dans la référence (SKU) Application Gateway v1. Cela n’est pas obligatoire pour la référence SKU Application Gateway v2 (Standard_v2 ou WAF_v2).
- Les suites de chiffrement « TLS_AES_128_GCM_SHA256 » et « TLS_AES_256_GCM_SHA384 » sont obligatoires pour TLSv1.3. Vous n’avez PAS besoin de les mentionner explicitement lors de la définition d’une stratégie CustomV2 avec la version minimale du protocole 1.2 ou 1.3 via PowerShell ou CLI. En conséquence, ces suites de chiffrement ne s’affichent pas dans la sortie Obtenir les détails, à l’exception du portail.
Suites de chiffrement
Application Gateway prend en charge les suites de chiffrement suivantes à partir desquelles vous pouvez choisir votre stratégie personnalisée. L’ordre des suites de chiffrement détermine l’ordre de priorité pendant la négociation TLS.
- TLS_AES_128_GCM_SHA256 (disponible uniquement avec Customv2)
- TLS_AES_256_GCM_SHA384 (disponible uniquement avec Customv2)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Limites
- Les connexions aux serveurs principaux se font toujours avec le protocole TLS v1.0 au minimum et jusqu’à TLS v1.2. Par conséquent, seules les versions TLS 1.0, 1.1 et 1.2 sont prises en charge pour établir une connexion sécurisée avec les serveurs principaux.
- À l’heure actuelle, l’implémentation de TLS 1.3 n’est pas activée avec la fonctionnalité « Temps d’aller-retour zéro (0-RTT) ».
- La reprise de session TLS (ID ou Tickets) n’est pas prise en charge.
- Application Gateway v2 ne prend pas en charge les chiffrements DHE suivants. Ceux-ci ne sont pas utilisés pour les connexions TLS avec les clients, même s’ils sont mentionnés dans les stratégies prédéfinies. Au lieu de chiffrements DHE, les chiffrements ECDHE sécurisés et plus rapides sont recommandés.
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA
- Les clients contraints qui recherchent la prise en charge de la « négociation de longueur de fragment maximale » doivent utiliser les plus récentes 2022 pré-définies ou stratégies Customv2.
Étapes suivantes
Pour apprendre à personnaliser une stratégie TLS, consultez Configurer les versions de stratégie TLS et les suites de chiffrement sur Application Gateway.