Distribution sécurisée des clés privées SSL avec NGINX

Owen GarrettDirecteur senior de la gestion des produits

Cet article de blog décrit plusieurs méthodes permettant de distribuer de manière sécurisée les clés privées SSL utilisées par NGINX pour héberger des sites web chiffrés via SSL. Il explique :

• L’approche standard de configuration de SSL avec NGINX et ses éventuelles limites en matière de sécurité
• Comment chiffrer les clés à l’aide de mots de passe stockés séparément de la configuration NGINX
• Comment distribuer les mots de passe de chiffrement de manière sécurisée, sans les stocker sur disque, puis les révoquer si nécessaire

Pour de nombreux déploiements, l’approche standard est suffisante. Les deux approches plus sophistiquées présentées dans cet article empêchent un attaquant d’obtenir les clés privées SSL par d’autres moyens. Nous examinerons également quelques techniques supplémentaires dans de prochains articles :

• Utiliser des gestionnaires de secrets tiers tels que HashiCorp Vault pour distribuer les mots de passe de manière sécurisée
• Automatisation de la mise à disposition des certificats depuis Vault vers le magasin clé-valeur de NGINX Plus, afin que les clés privées ne soient jamais stockées sur disque

Les approches présentées dans cet article s’adressent aux utilisateurs qui doivent gérer leurs propres clés et élaborer leur propre stratégie sécurisée de distribution des clés. Elles ne sont pas nécessaires pour les utilisateurs qui exécutent NGINX dans des environnements intégrant déjà un magasin de secrets, comme Kubernetes.

Cet article s’applique à la fois à NGINX Open Source et à NGINX Plus. Pour faciliter la lecture, nous utiliserons le terme « NGINX » dans la suite de l’article.

Note de la rédaction – Cet article est le premier d’une série consacrée à la sécurisation des clés privées SSL dans NGINX. Consultez également les autres articles de la série :

• Protection des clés privées SSL dans NGINX avec HashiCorp Vault – Présente l’utilisation de HashiCorp Vault ou d’un module matériel de sécurité (HSM) pour automatiser et déployer à grande échelle un système de protection des clés
• Utilisation du magasin clé-valeur de NGINX Plus pour sécuriser les clés SSL éphémères provenant de HashiCorp Vault – Explique comment éviter le stockage sur disque des clés SSL en générant des clés SSL éphémères à partir de HashiCorp Vault et en les stockant dans le magasin clé-valeur en mémoire de NGINX Plus

Pourquoi protéger la clé privée SSL ?

SSL/TLS est utilisé pour authentifier et chiffrer les transactions réseau, ainsi que pour en vérifier l’intégrité. Les sites web s’authentifient à l’aide d’un certificat public signé par une autorité de certification (AC) et prouvent qu’ils possèdent ce certificat en effectuant des calculs à l’aide de la clé privée correspondante (qui doit rester secrète).

Si la clé privée est compromise (divulguée à une autre entité), cela présente deux risques principaux.

• Risque 1 : usurpation d’identité. Un attaquant qui détient la clé privée peut intercepter le trafic réseau, puis lancer une attaque de l’homme du milieu (MITM). Cette attaque permet de capturer et de déchiffrer l’ensemble du trafic, voire de le modifier, à l’insu des clients et du site web.
• Risque 2 : déchiffrement. Un attaquant qui possède la clé privée et a enregistré le trafic réseau peut alors déchiffrer ce trafic hors ligne. Notez que cette attaque ne peut pas être utilisée contre les connexions qui emploient un algorithme de chiffrement à confidentialité persistante (PFS).

Si la clé privée est compromise, votre seul recours consiste à contacter l’autorité de certification et à demander la révocation de votre certificat ; vous devez ensuite compter sur les clients pour qu’ils vérifient et respectent l’état de révocation.

En outre, il est recommandé d’utiliser des certificats ayant une courte durée de validité (par exemple, les certificats Let’s Encrypt expirent au bout de 90 jours). Peu avant l’expiration d’un certificat, vous devez générer une nouvelle clé privée et obtenir un nouveau certificat auprès de l’autorité de certification. Cela réduit les risques auxquels vous êtes exposé en cas de compromission de la clé privée.

Le périmètre de sécurité de NGINX

Quelles personnes et quels processus peuvent accéder aux clés privées SSL dans NGINX ?

Tout d’abord, tout utilisateur qui obtient un accès root au serveur exécutant NGINX peut lire et utiliser toutes les ressources utilisées par NGINX lui-même. Par exemple, il existe des méthodes connues permettant d’extraire la clé privée SSL de la mémoire d’un processus en cours d’exécution.

Par conséquent, quelles que soient les modalités de stockage et de distribution de la clé privée, il est impossible de la protéger contre un attaquant disposant de privilèges root sur le serveur hôte.

Ensuite, tout utilisateur capable de modifier et de valider la configuration de NGINX peut exploiter ce pouvoir de nombreuses façons, par exemple pour ouvrir un accès par proxy aux services internes, contourner les mesures d’authentification, etc. Cette personne peut modifier la configuration de NGINX afin d’obtenir un accès root au serveur (ou un accès équivalent), bien que des outils tels que SELinux et AppArmor contribuent à limiter ce risque.

Par conséquent, il n’est généralement pas possible de protéger la clé privée contre un attaquant capable de modifier et de valider la configuration de NGINX.

Heureusement, toute organisation compétente dispose de processus de sécurité robustes qui rendent difficile pour un attaquant d’obtenir les privilèges root ou de modifier la configuration de NGINX.

Cependant, il existe deux autres moyens par lesquels un attaquant disposant de privilèges moindres pourrait accéder à la clé privée :

• Un utilisateur peut avoir une raison légitime de devoir consulter la configuration NGINX, ou peut obtenir l’accès à une base de données de configuration ou à une sauvegarde. Les clés privées NGINX sont généralement stockées dans la configuration.
• Un utilisateur peut obtenir l’accès au système de fichiers du serveur NGINX, par exemple par l’intermédiaire d’un hyperviseur ou d’une sauvegarde système. Toutes les données stockées sur le système de fichiers, y compris les clés privées, sont potentiellement accessibles.

Les processus décrits dans ce document permettent de contrer ces deux méthodes d’attaque.

Configuration NGINX standard

Commençons par examiner à quoi ressemble une configuration NGINX classique avec SSL/TLS :

server {
    listen 443 ssl;

    server_name a.dev0; 

    ssl_certificate ssl/a.dev0.crt;
    ssl_certificate_key ssl/a.dev0.key;

    location / {
        return 200 "Hello from service A\n";
    }
}

Le certificat SSL public (a.dev0.crt) et la clé privée (a.dev0.key) sont stockés dans le système de fichiers, sous /etc/nginx/ssl/. La clé privée est uniquement lue par le processus maître de NGINX, qui s’exécute généralement en tant que root, ce qui vous permet de lui attribuer les autorisations d’accès les plus strictes possible :

root@web1:/etc/nginx/ssl# ls -l a.dev0.key-r-------- 1 root root 1766 Aug 15 16:32 a.dev0.key

La clé privée doit être disponible à tout moment. Le processus maître NGINX la lit à chaque démarrage du logiciel NGINX, rechargement de la configuration ou vérification de la syntaxe (nginx -t).

Pour plus d’informations sur la configuration de SSL/TLS, consultez le Guide d’administration de NGINX Plus.

Implications de la configuration standard en matière de sécurité

Comme indiqué ci-dessus, la clé privée SSL peut être lue par un attaquant qui obtient un accès root au conteneur, à la machine virtuelle ou au serveur en cours d’exécution sur lequel s’exécute le logiciel NGINX.

Chiffrement des clés privées SSL

NGINX prend en charge les clés privées chiffrées à l’aide d’algorithmes sécurisés tels qu’AES256 :

root@web1:/etc/nginx/ssl# mv a.dev0.key a.dev0.key.plainroot@web1:/etc/nginx/ssl# openssl rsa -aes256 -in a.dev0.key.plain -out a.dev0.key
writing RSA key
Enter PEM pass phrase: secure password
Verifying - Enter PEM pass phrase: secure password again

Lorsque vous démarrez ensuite NGINX, ou que vous rechargez ou testez sa configuration, NGINX vous demande de saisir le mot de passe de déchiffrement de manière interactive :

root@web1:/etc/nginx# nginx -tEnter PEM pass phrase: secure password
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Utilisation d’un fichier de mot de passe SSL

La saisie interactive des mots de passe est peu pratique et difficile à automatiser, mais vous pouvez configurer NGINX pour qu’il utilise une liste de mots de passe stockée dans un fichier distinct indiqué par la directive « ssl_password_file ». Lorsque NGINX doit lire une clé privée, il tente de la déchiffrer en essayant successivement chacun des mots de passe du fichier. Si aucun des mots de passe n’est valide, NGINX refuse de démarrer.

ssl_password_file /var/lib/nginx/ssl_passwords.txt;

Le fichier ssl_password_file doit être distribué séparément de la configuration et être lisible uniquement par l’utilisateur root. Vous pouvez le considérer comme un jeton d’autorisation placé sur les serveurs de confiance. NGINX ne peut déchiffrer les clés privées que lorsqu’il s’exécute sur un serveur disposant de ce jeton d’autorisation.

Implications en matière de sécurité des clés chiffrées stockées dans un fichier distinct

Cette méthode réduit la surface d’attaque en rendant la configuration NGINX seule inutilisable par un attaquant. Celui-ci doit également obtenir le contenu du fichier « ssl_password_file ».

Si un attaquant parvient à obtenir un accès root au système de fichiers où le fichier ssl_password_file est stocké (par exemple, à partir d’une sauvegarde ou via le système hôte), il peut lire ce fichier et utiliser les mots de passe pour déchiffrer les clés privées SSL.

Vous pouvez réduire ce risque en stockant le fichier ssl_password_file sur un disque RAM ou un système de fichiers tmpfs. Ce type de stockage est généralement moins accessible à un attaquant externe (par exemple, son contenu est effacé au redémarrage du serveur) et peut être exclu des sauvegardes système. Vous devez vous assurer que le fichier de mots de passe est initialisé au démarrage du système.

Distribuer les listes de mots de passe SSL de manière plus sécurisée

Le processus ci-dessous décrit une méthode plus sécurisée pour distribuer des listes de mots de passe SSL à partir d’un point de distribution central.

Chaque fois que NGINX doit déchiffrer une clé SSL, il interroge le point de distribution central et utilise les mots de passe sans jamais les stocker sur le disque local. Pour s’authentifier auprès du serveur central de mots de passe, l’instance NGINX utilise un jeton que vous pouvez révoquer à tout moment afin de bloquer l’accès aux mots de passe.

Création d’un point central de distribution des mots de passe

Commencez par créer un point de distribution des mots de passe (PDP). Pour cette implémentation simple, nous utilisons un service HTTPS afin de fournir la liste des mots de passe, avec une authentification par nom d’utilisateur et mot de passe :

$ curl -u dev0:mypassword https://pdpserver.local/ssl_passwords.txt
password1
password2
...

Vous pouvez ensuite autoriser ou révoquer l’accès selon vos besoins en ajoutant ou en supprimant des jetons d’authentification au niveau du PDP. Vous pouvez mettre en œuvre le serveur de distribution de mots de passe à l’aide d’un serveur web tel que NGINX et utiliser le type de jetons d’authentification qui convient.

Ensuite, nous devons configurer NGINX afin qu’il récupère les mots de passe depuis le PDP. Commençons par créer un script shell nommé « connector.sh » avec le contenu suivant :

#!/bin/sh
# Usage: connector.sh   

CONNECTOR=$1
CREDS=$2
PDP_URL=$3

[ -e $CONNECTOR ] && /bin/rm -f $CONNECTOR

mkfifo $CONNECTOR; chmod 600 $CONNECTOR

while true; do
    curl -s -u $CREDS -k $PDP_URL -o $CONNECTOR
done

Le script doit s’exécuter en tant que processus d’arrière-plan, lancé comme suit :

root@web1:~# ./connector.sh /var/run/nginx/ssl_passwords \dev0:mypassword https://pdpserver.local/ssl_passwords.txt &

Le connecteur se rattache au chemin local spécifié (/var/run/nginx/ssl_passwords), et vous utilisez la directive ssl_password_file pour configurer NGINX afin qu’il accède à ce chemin :

ssl_password_file /var/run/nginx/ssl_passwords;

Testez le connecteur en effectuant une lecture à partir de son chemin d’accès :

root@web1:~# cat /var/run/nginx/ssl_passwords
password1
password2
...

Vérifiez que NGINX peut lire le mot de passe et déchiffrer les clés SSL :

root@web1:~# nginx -tnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Vous pouvez utiliser l’approche PDP centralisée pour distribuer de manière sécurisée toute ressource que NGINX lit habituellement sur le disque, par exemple des clés privées individuelles ou d’autres données sensibles.

Implications d’un PDP en matière de sécurité

Cette solution présente plusieurs avantages par rapport au stockage des mots de passe SSL sur disque :

• Les mots de passe SSL ne sont jamais stockés dans le système de fichiers du serveur, de sorte qu’un attaquant ayant accès au système de fichiers ne peut pas y accéder directement.
• Les mots de passe sont distribués depuis un point d’accès central, ce qui facilite la surveillance et les audits.
• L’accès à chaque serveur peut être contrôlé de manière centralisée. Par exemple, lorsqu’un serveur est mis hors service, vous révoquez son jeton d’accès.

Notez qu’un utilisateur ayant accès au système de fichiers peut potentiellement extraire les identifiants utilisés pour accéder au PDP. Il est important de révoquer ces identifiants lorsqu’ils ne sont plus nécessaires.

Résumé

Il existe de nombreuses façons de protéger les clés privées SSL contre toute divulgation, avec des niveaux de sécurité et de complexité croissants :

• Pour la grande majorité des organisations, il suffit de restreindre l’accès aux environnements exécutant NGINX afin que les utilisateurs non autorisés ne puissent pas obtenir un accès root ni consulter la configuration de NGINX.
• Dans certains environnements, il peut être impossible de restreindre totalement l’accès à la configuration de NGINX. Il est alors possible d’utiliser un fichier de mots de passe SSL.
• Dans certains cas particuliers, les organisations peuvent souhaiter s’assurer que les clés et les mots de passe ne sont jamais stockés sur disque. Le processus de « point de distribution des mots de passe » constitue une démonstration de faisabilité de cette solution.

Les autres articles de cette série décrivent des mesures supplémentaires que vous pouvez prendre pour sécuriser les clés SSL :

• Protection des clés privées SSL dans NGINX avec HashiCorp Vault – Explique comment configurer HashiCorp Vault en tant que PDP afin d’assurer une distribution évolutive et sécurisée des secrets, avec un contrôle d’accès précis. Présente également l’utilisation d’un module matériel de sécurité (HSM) pour stocker les clés privées à distance et fournir une API permettant d’effectuer une opération cryptographique à la demande.
• Utilisation du magasin clé-valeur de NGINX Plus pour sécuriser les clés SSL éphémères provenant de HashiCorp Vault – Explique comment éviter le stockage sur disque des clés SSL en générant des clés SSL éphémères à partir de HashiCorp Vault et en les stockant dans le magasin clé-valeur en mémoire de NGINX Plus.

Essayez NGINX Plus par vous-même : commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

À propos de l’auteur

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett