Utilisation de TLS mutuel
L'authentification mTLS (Mutual Transport Layer Security) garantit que le trafic entre un client et un serveur est sécurisé et digne de confiance dans les deux sens. Il n'est accessible qu'aux clients ayant souscrit un plan d'entreprise, quel qu'il soit.
Lorsque mTLS est configuré, l'accès est accordé uniquement aux demandes avec un certificat client correspondant. Lorsqu'une demande parvient à votre application, CIS répond en demandant le certificat du client. Si le client ne parvient pas à présenter le certificat, la demande n'est pas autorisée à continuer. Sinon, l'échange de clé se poursuit.
Configuration de TLS mutuel
Mutual TLS ( mTLS ) fournit une authentification client basée sur un certificat pour une sécurité accrue. mTLS n'est pas activé par défaut et nécessite une autorisation préalable pour chaque domaine. Pour configurer mTLS,, procédez comme suit :
-
Demande d'autorisation. Créez un dossier de support pour demander l'activation de mTLS pour votre compte IBM Cloud.
Une fois que mTLS est activé, il ne peut plus être désactivé.
-
Activer mTLS:
- Dans la console CIS, cliquez sur Security, puis sélectionnez l'onglet Mutual TLS.
- Cliquez sur Activer.
-
Télécharger les certificats racine :
-
Dans le tableau Certificats racine de la page TLS mutuel, cliquez sur Ajouter pour définir un nouveau certificat racine.
-
Collez le contenu du certificat dans le champ Contenu du certificat. Indiquez un nom pour le certificat de l'autorité de certification racine et ajoutez un ou plusieurs noms de domaine complets (FQDN) des terminaux qui utiliseront ce certificat.
Ces FQDN sont les noms d'hôtes utilisés par les ressources protégées par la politique d'application mTLS. Vous devez associer l'autorité de certification racine au FQDN utilisé par l'application protégée.
-
Cliquez sur Sauvegarder.
Si vous utilisez un certificat intermédiaire, téléchargez toute la chaîne de certificats.
-
-
Créer une politique d'accès à mTLS:
-
Dans le tableau des politiques d'accès MTLS de la page TLS mutuel, cliquez sur Créer pour créer une application d'accès.
-
Sélectionnez ou saisissez un nom d'hôte correspondant à l'un des FQDN associés au certificat racine téléchargé et cliquez sur Créer.
La politique d'application est prédéfinie pour utiliser une décision de
non_identity, et inclure une règle qui correspond à tout certificat client valide.
-
-
Activer le transfert de certificat client avec l'API :
Pour transmettre les certificats clients validés à votre serveur d'origine (utile pour la journalisation, l'audit ou l'authentification en arrière-plan), vous devez activer la transmission.
Le certificat du client n'est transmis qu'avec la première demande de chaque connexion mTLS.
Pour un exemple d'API curl permettant d'activer le transfert de certificat client, voir l'API de mise à jour des paramètres des certificats d'accès.
En-têtes du certificat du client envoyés à votre serveur d'origine :
Cf-Client-Cert-Der-Base64: Base64-encoded Version DER du certificat du clientCf-Client-Cert-Sha256SHA-256 empreinte digitale du certificat du client
Pour vérifier l'état du transfert avec l'API :
curl -X GET https://api.cis.cloud.ibm.com/v1/crn:v1:bluemix:public:internet-svcs:global:a/<account-id>:<instance-id>::/zones/<zone-id>/access/certificates/settings \ -H 'X-Auth-User-Token: Bearer <IAM-TOKEN>' -
Créer une règle personnalisée WAF pour bloquer les requêtes non authentifiées :
Pour améliorer la sécurité, en particulier pour les points d'extrémité sensibles tels que les chemins de connexion ou les API, créez une règle WAF pour bloquer les requêtes qui ne présentent pas de certificat client valide.
-
Dans la console CIS, revenez à la section Sécurité, puis sélectionnez l'onglet Règles personnalisées.
-
Cliquez sur Créer.
-
Dans le panneau latéral Créer une règle personnalisée WAF, cliquez sur Utiliser l'éditeur d'expression.
-
Saisissez la condition suivante (mettez à jour
hostnameetpathsi nécessaire) dans le champ Use Expression Builder.(http.host eq "example.com" and http.request.uri.path eq "/authenticate" and not cf.tls_client_auth.cert_verified) -
Réglez l'action sur Blocage.
-
Cliquez sur Créer.
Cette règle n'autorise l'accès à l'authentification que si le certificat du client est vérifié avec succès. Les demandes sans mTLS ou avec des certificats non valides sont bloquées.
-
Test de l'accès à mTLS
L'exemple suivant utilise curl pour tester l'authentification mTLS en effectuant des requêtes avec et sans certificat client.
-
Tentative d'accès au site sans certificat client.
Cet exemple montre comment utiliser curl pour tester l'accès à un site qui impose mTLS. La cible URL dans cet exemple est
https://auth.example.com.curl -sv https://auth.example.comComme aucun certificat de client n'est fourni, la demande est censée échouer avec une réponse
403 Forbidden. -
Ajoutez votre certificat client et votre clé privée à la demande :
curl -sv https://auth.example.com --cert example.pem --key key.pemSi le client est correctement authentifié, la réponse comprend un en-tête
CF_Authorization Set-Cookie, indiquant que l'authentification mTLS est réussie.
Validation de TLS mutuel
Lorsque vous activez cette politique d'accès, utilisez le flux de travail suivant pour valider les certificats des clients :
Toutes les demandes envoyées à l'origine sont évaluées à la recherche d'un certificat client valide.
- Le client établit une connexion en envoyant un message
Hello. - L'application d'accès répond par un
Helloet demande le certificat du client. - Le client envoie son certificat pour validation.
- Le certificat du client est authentifié par rapport à l'autorité de certification racine configurée.
- Si une chaîne de certificats est utilisée, le système vérifie également si des certificats ont expiré et valide l'ensemble de la chaîne.
- Si le certificat du client est fiable, un jeton Web JSON (JWT) signé est généré pour le client, ce qui permet à la demande et aux demandes ultérieures d'être traitées.
- Si le client ne présente pas de certificat valide, le serveur renvoie une réponse
403 Forbidden.
Pour récupérer les certificats d'accès avec l'API, voir Liste des certificats d'accès.