Je suis heureux de partager qu’Azure Application Gateway prend désormais en charge Mutual Transport Layer Security (mTLS) et Online Certificate Status Protocol (OCSP). C’était l’une des principales questions de nos clients, car ils recherchaient des options de connectivité plus sécurisées pour leurs charges de travail dans le cloud. Ici, je couvre ce qu’est mTLS, comment cela fonctionne, quand l’envisager et comment le vérifier dans Application Gateway.
Qu’est-ce que mTLS ?
Mutual Transport Layer Security (TLS) est un processus de communication dans lequel les deux parties vérifient et authentifient les certificats numériques de l’autre avant d’établir une connexion chiffrée TLS. mTLS est une extension du protocole TLS standard et fournit une couche de sécurité supplémentaire sur TLS. Avec TLS traditionnel, le serveur est authentifié, mais pas le client. Cela signifie que n’importe qui peut se connecter au serveur et initier une connexion sécurisée, même si le client ou l’utilisateur n’y est pas autorisé. Avec mTLS, vous pouvez vous assurer que le client et le serveur doivent s’authentifier avant que la connexion sécurisée puisse être établie, ce qui garantira qu’aucun accès non autorisé n’est possible de part et d’autre. mTLS fonctionne sur un cadre de confiance zéro – ne faites jamais confiance, vérifiez toujours. Cette structure garantit qu’aucune connexion n’est automatiquement approuvée.
Comment fonctionne mTLS ?
mTLS fonctionne en utilisant une combinaison de certificats numériques sécurisés et de clés privées pour authentifier à la fois le client et le serveur. Le client et le serveur ont chacun leur propre certificat numérique et clé privée, qui sont utilisés pour établir la confiance et une connexion sécurisée. Le client vérifie le certificat du serveur et le serveur vérifie le certificat du client – cela garantit que les deux parties sont bien celles qu’elles prétendent être.
En quoi TLS et mTLS diffèrent-ils ?
Les protocoles TLS et mTLS sont utilisés pour chiffrer les communications réseau entre le client et le serveur. Dans le protocole TLS, le client vérifie uniquement que le serveur est valide avant d’établir la connexion chiffrée. Le serveur ne valide pas le client lors d’une connexion TLS. D’autre part, mTLS est une forme de TLS qui ajoute une couche de sécurité supplémentaire en exigeant une authentification mutuelle entre le client et le serveur. Cela signifie que le client et le serveur doivent présenter un certificat valide avant que la connexion cryptée puisse être établie. Cela rend mTLS plus sécurisé que TLS car il ajoute une couche de sécurité supplémentaire grâce à la validation du client et du serveur.
Flux d’appels TLS :
Flux d’appels mTLS :
Quand envisager mTLS
- mTLS est utile lorsque les organisations adoptent une approche de confiance zéro. De cette manière, le serveur doit s’assurer que le client ou l’appareil spécifique qui souhaite utiliser les informations du serveur est autorisé. Par exemple, une organisation peut disposer d’une application Web que les employés ou les clients peuvent utiliser pour accéder à des informations hautement sensibles, telles que des données financières, des dossiers médicaux ou des informations personnelles. Avec mTLS, une organisation peut s’assurer que seuls les employés, clients ou appareils autorisés peuvent accéder à l’application Web et aux informations sensibles qu’elle contient.
- Les appareils de l’Internet des objets (IoT) communiquent entre eux à l’aide de mTLS. Chaque appareil IoT présente son propre certificat à l’autre afin d’être authentifié.
- La plupart des nouvelles applications s’exécutent sur une architecture basée sur des microservices. Les microservices communiquent entre eux via des API, avec mTLS, vous pouvez être sûr que la communication API est sécurisée. De plus, avec mTLS, vous pouvez vous assurer que les API malveillantes n’appellent pas vos propres API
- Pour empêcher diverses attaques, telles que la force brute ou le credential stuffing. Si un attaquant peut mettre la main sur un mot de passe divulgué ou si un BOT essaie de forcer son entrée avec des mots de passe aléatoires, cela ne sert à rien – sans un certificat TLS valide, l’attaquant ne pourra pas passer une poignée de main TLS.
À un niveau élevé, vous comprenez maintenant ce qu’est mTLS et comment il fournit une communication plus sécurisée en suivant le modèle de sécurité zéro confiance. Si vous débutez avec Application Gateway et que vous n’avez jamais configuré TLS dans Application Gateway, suivez le lien pour créer APPGW et des serveurs principaux. Ce tutoriel utilise des certificats auto-signés à des fins de démonstration. Pour un environnement de production, utilisez des certificats signés par une autorité de certification publiquement approuvée (CA). Une fois que vous avez configuré votre TLS de bout en bout, vous pouvez suivre ce lien pour configurer mTLS. Pour tester cette configuration, la condition préalable est que vous ayez installé l’outil OpenSSL et curl sur votre machine. Vous devez avoir accès au certificat client et à la clé privée du client.
Voyons comment tester la passerelle d’implémentation mTLS. Dans la commande ci-dessous, la clé privée du client est utilisée pour créer une signature pour un fichier Vérification du certificat Message. La clé privée ne quitte pas la machine cliente lors d’une connexion mTLS.
Vérifiez votre configuration mTLS en utilisant curl / openssl
- curl -vk https://> –key client.key –cert client.crt
-> Votre adresse de domaine
client.key -> la clé privée du client
client.crt -> certificat client
Dans la sortie ci-dessus, nous vérifions si mTLS est correctement configuré. S’il est configuré correctement, le serveur de prise de contact TSL demandera le certificat du client. Ensuite, dans le processus de prise de contact, vous devez vérifier si le client a fourni un certificat client avec un fichier Vérification du certificat Message. Étant donné que le certificat client était valide, la connexion a réussi et l’application a répondu par une réponse HTTP “200”.
Si le certificat client n’est pas signé par le fichier CA racine téléchargé selon le lien de l’étape 8, la connexion échouera. Vous trouverez ci-dessous la réponse que nous obtiendrons si le certificat client n’est pas valide.
Vous pouvez également vérifier la connectivité mTLS à l’aide de la commande OpenSSL.
- openssl s_client-bind
: client 443 clés. clé -cert client. crt
Une fois la connexion SSL établie, tapez comme écrit ci-dessous :
obtenir / http / 1.1
Héberger:
Vous devriez obtenir un code de réponse – 200. Ceci confirme que l’authentification mutuelle est réussie.
Conclusion
J’espère que vous avez maintenant appris ce qu’est mTLS, quel problème il résout, comment le configurer dans Application Gateway et comment valider votre configuration. C’est l’une des nombreuses fonctionnalités intéressantes de l’App Gateway qui offre à nos clients une couche de sécurité supplémentaire pour les différents cas d’utilisation dont nous avons parlé ci-dessus. Une chose à noter est qu’Application Gateway ne prend actuellement en charge mTLS que sur le front-end (entre le client et la passerelle d’application). Si le serveur principal attend un certificat client lors de la négociation SSL entre la passerelle d’application et le serveur principal, cette demande échouera. Si vous voulez savoir comment envoyer des certificats à une application back-end via http, veuillez attendre notre prochain article de blog mTLS. Dans ce blog, je vais expliquer comment utiliser la fonction de réécriture pour envoyer le certificat du client en tant qu’en-tête http. Nous discuterons également de la manière dont nous pouvons valider le certificat client OCSP.
En savoir plus et démarrer avec Azure Application Gateway
Qu’est-ce qu’Azure Application Gateway | Apprendre Microsoft
Présentation de l’authentification mutuelle Azure Application Gateway | Apprendre Microsoft
Questions fréquemment posées sur Azure Application Gateway | Apprendre Microsoft