À propos de l'authentification réciproque par « TLS » pour les équilibreurs de charge d'applications
L'authentification mutuelle TLS ( mTLS ) renforce la sécurité de votre équilibreur de charge d'application (ALB) IBM Cloud® en permettant une authentification par certificat entre les clients et l'équilibreur de charge, ainsi qu'entre ce dernier et les serveurs back-end.
Qu'est-ce que l' TLS e mutuel?
mTLS Il s'agit d'une extension du protocole standard « TLS » qui exige que les deux parties d'une connexion s'authentifient mutuellement à l'aide de certificats numériques. Alors que l'authentification standard ( TLS ) exige uniquement que le serveur présente un certificat au client, l'authentification mutuelle ( mTLS ) exige que le client et le serveur présentent tous deux un certificat, créant ainsi un mécanisme d'authentification bidirectionnel.
Grâce à la prise en charge des ALB par mTLS, vous pouvez mettre en œuvre une authentification par certificat à deux niveaux :
- Authentification côté client
- Vérifiez l'identité des clients en leur demandant de présenter des certificats valides lorsqu'ils se connectent au listener de l'équilibreur de charge.
- Authentification côté serveur
- Authentifiez l'équilibreur de charge auprès des serveurs back-end en présentant un certificat client, et vérifiez, si vous le souhaitez, les certificats des serveurs back-end.
Principales fonctionnalités
La prise en charge d'ALB mTLS offre les fonctionnalités suivantes :
- Vérification du certificat client au niveau du listener
- Activez l'authentification des clients au niveau du front-end de l'équilibreur de charge en configurant un certificat d'autorité de certification (CA) afin de vérifier les certificats des clients. La vérification garantit que seuls les clients disposant de certificats valides signés par l'autorité de certification de confiance peuvent établir des connexions.
- Prise en charge de la liste de révocation de certificats (CRL)
- Importez une liste CRL pour vérifier si des certificats clients ont été révoqués, ce qui apporte un niveau de sécurité supplémentaire en rejetant les certificats compromis ou périmés.
- Vérification du certificat du serveur back-end
- Validez les certificats des serveurs back-end lors des procédures d'établissement de connexion TLS afin de garantir que l'équilibreur de charge ne se connecte qu'à des serveurs back-end de confiance. La validation permet de prévenir les attaques de type « homme du milieu ».
- Authentification du client côté serveur
- Présenter un certificat client provenant de l'équilibreur de charge aux serveurs back-end lorsque l'infrastructure back-end exige l' mTLS, permettant ainsi une authentification bidirectionnelle sécurisée.
Cas d'utilisation
mTLS L'authentification s'avère utile dans les situations où vous avez besoin d'une sécurité renforcée et d'une vérification d'identité :
- Architectures de sécurité « zero-trust »
- Mettez en œuvre les principes du modèle « zero-trust » en exigeant une authentification par certificat pour toutes les connexions, afin de garantir que chaque client et chaque serveur soient vérifiés avant l'établissement de la communication.
- Sécurité de l'API
- Protégez les points de terminaison de vos API en exigeant que les clients présentent des certificats valides, ce qui empêche tout accès non autorisé aux API sensibles et garantit que seules les applications authentifiées peuvent utiliser vos services.
- Communication entre microservices
- Assurer la sécurité des communications entre les microservices en mettant en œuvre l'authentification et le chiffrement de bout en bout ( mTLS ) tant au niveau du front-end que du back-end, afin de garantir que toutes les communications entre services soient authentifiées et chiffrées.
- Exigences en matière de conformité
- Respectez les exigences réglementaires imposant des mécanismes d'authentification forts, notamment dans les secteurs des services financiers, de la santé ou de l'administration publique.
- Validation côté serveur
- Assurez-vous que votre équilibreur de charge ne se connecte qu'à des serveurs back-end légitimes en vérifiant leurs certificats, ce qui vous protège contre les instances back-end malveillantes ou compromises.
Fonctionnement d' mTLS avec les équilibreurs de charge d'applications
Les ALB prennent en charge la fonction « mTLS » (mise en attente des requêtes) tant pour les connexions client-équilibreur de charge que pour les connexions équilibreur de charge-serveur. Les schémas suivants illustrent le processus de validation des certificats lors de chaque établissement de connexion avec TLS.
mTLS front-end (au niveau de l'écouteur)
Lorsque vous activez l'authentification client ( mTLS ) au niveau du listener :
- Un client établit une connexion « HTTPS » avec l'équilibreur de charge.
- L'équilibreur de charge présente son certificat de serveur au client.
- L'équilibreur de charge demande un certificat client au client.
- Le client présente son certificat au répartiteur de charge.
- L'équilibreur de charge vérifie la validité du certificat client par rapport au certificat de l'autorité de certification configurée.
- Si une liste CRL est configurée, l'équilibreur de charge vérifie si le certificat a été révoqué.
- Si la vérification aboutit, la connexion est établie. Dans le cas contraire, la connexion est refusée.
mTLS s du back-end (au niveau du pool)
Lorsque vous activez l'authentification du serveur ou la présentation d'un certificat client au niveau du pool :
- L'équilibreur de charge établit une connexion avec un serveur back-end.
- Le serveur back-end présente son certificat à l'équilibreur de charge.
- Si la vérification du serveur est activée, l'équilibreur de charge valide le certificat du serveur back-end par rapport au certificat de l'autorité de certification (CA) configuré.
- Si le serveur back-end exige une authentification du client, l'équilibreur de charge présente son certificat client.
- Le serveur back-end vérifie le certificat du client.
- Si la vérification aboutit, la connexion est établie et le trafic est acheminé vers le serveur back-end.
Prise en charge de la liste de révocation de certificats (CRL)
Une liste CRL est une liste de certificats qui ont été révoqués par l'autorité de certification avant leur date d'expiration. Les certificats peuvent être révoqués pour diverses raisons, notamment :
- La clé privée a été compromise
- Le certificat a été délivré de manière erronée
- Les droits du titulaire du certificat ont changé
- Le certificat n'est plus nécessaire
Lorsque vous configurez une liste de révocation (CRL) pour votre écouteur, l'équilibreur de charge vérifie chaque certificat client par rapport à la liste de révocation lors de la phase d'établissement de la connexion « TLS ». Si un certificat figure dans la liste CRL, la connexion est refusée, même si ce certificat est par ailleurs valide et correctement signé.
La prise en charge du CRL offre une couche de sécurité supplémentaire en garantissant que les certificats compromis ou invalidés ne puissent pas être utilisés pour accéder à vos services, même s'ils n'ont pas encore expiré.
Prérequis
Avant de configurer la fonctionnalité « mTLS » pour votre ALB, assurez-vous de remplir les conditions suivantes :
- Vous disposez d'un ALB doté d'un profil prenant en charge mTLS. Vérifiez la propriété «
mtls_supported» dans le profil de l'équilibreur de charge. - Votre écouteur utilise le protocole HTTPS. L'adresse mTLS n'est disponible que pour les écouteurs HTTPS.
- Vous disposez de certificats valides au format « PEM » stockés dans le répertoire « Secrets Manager ».
- Vous disposez des autorisations IAM nécessaires pour gérer les équilibreurs de charge et les certificats d'accès dans Secrets Manager.
Exigences du certificat
Tous les certificats utilisés pour mTLS doivent répondre aux exigences suivantes :
- Les certificats doivent être au format « PEM ».
- Les certificats doivent être enregistrés dans Secrets Manager et identifiés par leur CRN.
- Les certificats CA utilisés à des fins de vérification doivent inclure la chaîne de certificats complète (certificats racine et intermédiaires).
- Les certificats clients présentés par l'équilibreur de charge aux serveurs back-end doivent inclure la clé privée.
- Les certificats doivent être valides (non périmés) et dûment signés par une autorité de certification de confiance.
Remarques importantes
Tenez compte des éléments suivants lors de la mise en œuvre mTLS:
- Responsabilité en matière de gestion des certificats
- Il vous incombe de gérer l'ensemble des certificats, notamment leur obtention, leur téléchargement, leur renouvellement et leur révocation. IBM Cloud ne gère ni ne renouvelle automatiquement les certificats.
- Validation du certificat
- Vous devez vérifier que les certificats sont bien signés par les autorités de certification prévues et que les relations de confiance sont correctement établies. Des certificats non valides ou non correspondants entraînent des échecs de la négociation de connexion « TLS » et l'indisponibilité du service.
- Vérification du serveur back-end
- La vérification par le serveur côté serveur est désactivée par défaut afin de garantir la rétrocompatibilité. Lorsque cette option est activée, vous devez vous assurer qu'une relation de confiance valide existe entre l'équilibreur de charge et les serveurs back-end en téléchargeant le certificat d'autorité de certification (CA) approprié.
- Configuration au niveau du pool
- La vérification par le serveur côté serveur et l'authentification côté client sont toutes deux configurées au niveau du pool. Tous les serveurs back-end d'un même pool utilisent la même configuration. Si vous avez besoin de politiques de certificats différentes pour différents serveurs back-end, créez des pools distincts.
- Mises à jour des certificats
- Pour que les mises à jour ou les révocations de certificats prennent effet, il peut être nécessaire de redémarrer le service d'équilibrage de charge. Prévoyez les mises à jour des certificats pendant les fenêtres de maintenance afin de limiter au maximum les interruptions de service.
- Plusieurs autorités de certification
- Lorsque les serveurs back-end d'un même pool sont signés par différentes autorités de certification (CA), vous pouvez fournir un fichier CA regroupant tous les certificats racine et intermédiaires nécessaires. Tous les serveurs back-end sont considérés comme fiables si leur chaîne de certificats est liée à une autorité de certification (CA) figurant dans le faisceau.