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

Cet article de blog décrit plusieurs méthodes permettant de distribuer en toute sécurité les clés privées SSL utilisées par NGINX lors de l’hébergement de sites Web cryptés SSL. Il explique :

• L' approche standard pour la configuration de SSL avec NGINX et les limitations de sécurité potentielles
• Comment crypter 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 cryptage en toute sécurité , en évitant le stockage sur disque, puis les révoquer en cas de besoin

Pour de nombreux déploiements, l’approche standard est suffisante. Les deux approches les plus sophistiquées décrites dans cet article bloquent d’autres moyens par lesquels un attaquant peut obtenir des clés privées SSL. Nous examinerons également quelques autres techniques dans les prochains articles :

• Utiliser des magasins secrets tiers tels que HashiCorp Vault pour distribuer les mots de passe en toute sécurité
• Automatisation de la fourniture de certificats de Vault au magasin de clés-valeurs de NGINX Plus, afin que le matériel de clé privée ne soit jamais stocké sur le disque

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

Cet article s'applique à la fois à NGINX Open Source et à NGINX Plus. Pour faciliter la lecture, nous ferons référence à NGINX tout au long du document.

Éditeur – Cet article est le premier d'une série sur la sécurisation des clés privées SSL dans NGINX. Voir également les autres articles de la série :

• Protection des clés privées SSL dans NGINX avec HashiCorp Vault – Discute de l'utilisation de HashiCorp Vault ou d'un module de sécurité matériel (HSM) pour automatiser et faire évoluer un système de protection des clés
• Utilisation du magasin de clés-valeurs NGINX Plus pour sécuriser les clés SSL éphémères de HashiCorp Vault – Explique comment contourner 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 de clés-valeurs en mémoire NGINX Plus

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

SSL/TLS est utilisé pour authentifier, crypter et vérifier l'intégrité des transactions réseau. Les sites Web s'authentifient à l'aide d'un certificat public signé par une autorité de certification (CA) et démontrent qu'ils sont propriétaires du certificat en effectuant des calculs à l'aide de la clé privée correspondante (qui doit être gardée secrète).

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

• Risque 1 : Usurpation d'identité . Un attaquant disposant de la clé privée peut intercepter le trafic réseau et ensuite lancer une attaque de l'homme du milieu (MITM). Cette attaque capture et décrypte tout le trafic, en le modifiant peut-être également, sans que les clients ou le site Web n'en soient conscients.
• Risque 2 : Décryptage . Un attaquant qui dispose de la clé privée et qui a enregistré le trafic réseau est alors en mesure de décrypter le trafic réseau hors ligne. Notez que cette attaque ne peut pas être utilisée contre les connexions qui utilisent un chiffrement Perfect Forward Secrecy (PFS).

Si la clé privée est compromise, votre seul recours est de contacter l'autorité de certification et de demander la révocation de votre certificat ; vous devez alors compter sur les clients pour vérifier et respecter le statut de révocation.

De plus, il est recommandé d'utiliser des certificats avec des délais d'expiration courts (par exemple, les certificats Let's Encrypt expirent après 90 jours). Peu de temps 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 votre exposition dans le cas où la clé privée est compromise.

La limite de sécurité de NGINX

Quelles personnes et 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 est capable de lire et d’utiliser toutes les ressources que NGINX lui-même utilise. Par exemple, il existe des méthodes connues pour extraire la clé privée SSL de la mémoire d'un processus en cours d'exécution.

Par conséquent, quelle que soit la manière dont la clé privée est stockée et distribuée, il n'est pas possible de protéger la clé privée d'un attaquant disposant de privilèges root sur le serveur hôte.

Ensuite, tout utilisateur pouvant modifier et valider la configuration NGINX peut utiliser ce pouvoir de plusieurs manières : pour ouvrir l’accès proxy aux services internes, pour contourner les mesures d’authentification, etc. Il ou elle peut modifier la configuration NGINX pour obtenir un accès root (ou équivalent) au serveur, bien que des outils comme SELinux et AppArmor aident à atténuer cette possibilité.

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

Heureusement, toute organisation compétente dispose de processus de sécurité solides pour empêcher un attaquant d’obtenir des privilèges root ou de modifier la configuration NGINX.

Cependant, il existe deux autres manières par lesquelles un attaquant moins privilégié pourrait obtenir l'accès à la clé privée :

• Un utilisateur peut avoir une raison légitime de vouloir afficher 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, peut-être via un hyperviseur ou une sauvegarde système. Toutes les données stockées sur le système de fichiers, y compris le matériel de clé privée, sont potentiellement accessibles.

Les processus décrits dans ce document scellent ces deux méthodes d’attaque.

Configuration NGINX standard

Nous commençons par examiner à quoi ressemble une configuration NGINX typique avec SSL/TLS :

serveur { écouter 443 ssl; nom_serveur a.dev0; certificat_ssl ssl/a.dev0.crt; clé_certificat_ssl ssl/a.dev0.key; emplacement / { retourner 200 "Bonjour du service A\n"; } }

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

root@web1:/etc/nginx/ssl# ls -l a.dev0.key -r-------- 1 root root 1766 15 août 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, lorsque la configuration est rechargée ou lorsqu'une vérification de syntaxe est effectuée ( nginx -t ).

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

Conséquences de la configuration standard sur la 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 qui exécute le logiciel NGINX.

Cryptage des clés privées SSL

NGINX prend en charge les clés privées cryptées, à l'aide d'algorithmes sécurisés tels que AES256 :

root@web1:/etc/nginx/ssl# mv a.dev0.key a.dev0.key.plain root@web1:/etc/nginx/ssl# openssl rsa -aes256 -in a.dev0.key.plain -out a.dev0.key écriture de la clé RSA Entrez la phrase de passe PEM : secure password Vérification - Entrez à nouveau la phrase de passe PEM : secure password

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

root@web1:/etc/nginx# nginx -t Entrez la phrase de passe PEM : mot de passe sécurisé nginx : la syntaxe du fichier de configuration /etc/nginx/nginx.conf est correcte nginx : le test du fichier de configuration /etc/nginx/nginx.conf est réussi

Utilisation d'un fichier de mot de passe SSL

La saisie interactive de mots de passe est peu pratique et difficile à automatiser, mais vous pouvez configurer NGINX pour utiliser une liste de mots de passe stockés dans un fichier séparé nommé par la directive ssl_password_file . Lorsque NGINX doit lire une clé privée, il tente de déchiffrer la clé en utilisant tour à tour chacun des mots de passe du fichier. Si aucun des mots de passe n'est valide, NGINX refuse de démarrer.

fichier_mot_de_passe_ssl /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 des serveurs de confiance. NGINX ne peut décrypter les clés privées que lorsqu'il s'exécute sur un serveur avec le jeton d'autorisation.

Conséquences en matière de sécurité des clés cryptées dans un fichier séparé

Cette méthode réduit la surface d’attaque en rendant la configuration NGINX seule inutile pour un attaquant. L'attaquant doit également obtenir le contenu du fichier ssl_password_file .

Si un attaquant parvient à accéder à la racine du 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 le fichier et utiliser les mots de passe pour décrypter les clés privées SSL.

Vous pouvez réduire ce risque en stockant le fichier ssl_password_file sur un disque RAM ou tmpfs . Ce stockage est généralement moins accessible à un attaquant externe (par exemple, il est effacé lorsque le serveur est redémarré) et peut être exclu des sauvegardes système. Vous devez vous assurer que le fichier de mot 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 manière plus sécurisée de distribuer des listes de mots de passe SSL, à partir d'un point de distribution central.

Chaque fois que NGINX doit décrypter 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 de mots de passe central, l'instance NGINX utilise un jeton que vous pouvez révoquer à tout moment pour couper l'accès aux mots de passe.

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

Commencez par créer un point de distribution de mot de passe (PDP). Pour cette implémentation simple, nous utilisons un service HTTPS pour fournir la liste des mots de passe, authentifiés par nom d'utilisateur et mot de passe :

$ curl -u dev0:monmot de passe https://pdpserver.local/ssl_passwords.txt mot de passe1 mot de passe2 ...

Vous pouvez ensuite activer ou révoquer l’accès en ajoutant ou en supprimant des jetons d’authentification au niveau du PDP selon vos besoins. Vous pouvez implémenter 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 approprié.

Ensuite, nous devons configurer NGINX pour récupérer les mots de passe du PDP. Nous commençons par créer un script shell appelé connector.sh avec le contenu suivant :

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

CONNECTEUR=$1
CREDS=$2
PDP_URL=$3

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

mkfifo $CONNECTEUR ; chmod 600 $CONNECTEUR

tant que vrai ; faire
curl -s -u $CREDS -k $PDP_URL -o $CONNECTEUR
terminé

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

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

Le connecteur se connecte au chemin local spécifié ( /var/run/nginx/ssl_passwords ) et vous utilisez la directive ssl_password_file pour configurer NGINX afin d'accéder à ce chemin :

fichier_mot_de_passe_ssl /var/run/nginx/ssl_passwords;

Testez le connecteur en lisant le chemin du connecteur :

root@web1:~# cat /var/run/nginx/ssl_passwords mot de passe1 mot de passe2 ...

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

root@web1:~# nginx -t nginx : la syntaxe du fichier de configuration /etc/nginx/nginx.conf est correcte nginx : le test du fichier de configuration /etc/nginx/nginx.conf est réussi

Vous pouvez utiliser l’approche PDP centrale pour distribuer en toute sécurité toute ressource que NGINX lit normalement à partir du disque, par exemple des clés privées individuelles ou d’autres données sensibles.

Conséquences d'un PDP sur la 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 sur le système de fichiers du serveur , donc un attaquant ayant accès au système de fichiers ne peut pas y accéder directement.
• Les mots de passe sont distribués à partir d'un point d'accès central , ce qui facilite la surveillance et l'audit.
• L'accès aux serveurs individuels peut être contrôlé de manière centralisée . Par exemple, une fois qu’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 informations d'identification utilisées pour accéder au PDP. Il est important de révoquer ces informations d’identification lorsqu’elles ne sont plus nécessaires.

Résumé

Il existe de nombreuses façons de protéger les clés privées SSL contre la 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 et ne puissent pas consulter la configuration NGINX.
• Pour certains environnements, il peut ne pas être possible de restreindre entièrement l'accès à la configuration NGINX, un fichier de mot de passe SSL peut donc être utilisé.
• Dans certains cas limités, les organisations peuvent souhaiter s’assurer que les clés et les mots de passe ne sont jamais stockés sur le disque. Le processus de point de distribution de mot de passe illustre une preuve de concept pour cette solution.

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

• Protection des clés privées SSL dans NGINX avec HashiCorp Vault – Montre comment configurer HashiCorp Vault comme PDP, offrant une distribution évolutive et sécurisée des secrets avec un contrôle d'accès précis. Il décrit également l’utilisation d’un module de sécurité matériel (HSM) pour stocker des clés privées à distance, exposant ainsi une API qui peut être utilisée à la demande pour effectuer une opération de clé.
• Utilisation du magasin de clés-valeurs NGINX Plus pour sécuriser les clés SSL éphémères de HashiCorp Vault – Montre comment contourner 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 de clés-valeurs en mémoire NGINX Plus.

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