Comment gérer la protection d'une clé privée SSL de serveurs Web (mot de passe ou pas de mot de passe)?

Nous avons une discussion au sein du groupe de sécurité de mon entreprise sur la pire des options suivantes pour gérer la clé privée SSL.

Le serveur Web doit avoir accès à la clé privée pour l'opération de chiffrement. Ce fichier doit être protégé contre tout accès non autorisé. Dans le même temps, le serveur devrait démarrer automatiquement, sans intervention humaine (s'il est suffisamment sécurisé).

Nous discutons de trois options:

1. Protégez la clé avec les autorisations du système de fichiers.

2. Utilisez une clé protégée par mot de passe et entrez la clé manuellement à chaque redémarrage.

3. Utilisez une clé protégée par mot de passe et stockez la clé dans le système de fichiers pour automatiser le redémarrage.

Nos préoccupations sont les suivantes:

1. Avec l'option 1, les redémarrages sont automatiques mais un compromis pourrait copier la clé privée et, comme il n'est pas protégé, pourrait être utilisé pour déchiffrer la communication ou usurper l'identité de nos serveurs.

2. L'option 2 semble la plus sécurisée, mais elle nécessite une intervention humaine et les administrateurs système sont inquiets si cela se produit en dehors des heures. De plus, le mot de passe doit être partagé avec plusieurs administrateurs système et vous savez qu'un secret partagé n'est plus un secret.

3. L'option 3 a le meilleur des deux options précédentes, mais si quelqu'un a accès à la clé, il pourrait également avoir accès au mot de passe :(, il ne semble donc pas si sûr du tout.

Comment gérez-vous la sécurité des clés privées de vos serveurs? Existe-t-il d'autres options (plus sécurisées)?

L'option 1 est, je pense, la norme acceptée.

Cependant, si vous voulez vraiment une sécurité supplémentaire, pourquoi n'avez-vous pas un serveur sécurisé (pas dans votre DMZ) configuré pour surveiller votre serveur Web, et si apache tombe en panne, il peut automatiquement se connecter à distance et redémarrer apache , en fournissant la phrase secrète.

Ainsi, la phrase secrète est conservée sur un ordinateur, mais pas la même que celle sur laquelle Apache fonctionne, et non dans votre DMZ. Vous gagnez la sécurité supplémentaire de l'utilisation d'une phrase secrète et conservez la possibilité d'un redémarrage automatique.

Si quelqu'un a un accès suffisant au serveur pour lire la clé, il a très probablement également un accès suffisant pour attacher un débogueur et obtenir la clé de la mémoire.

À moins que vous n'aimiez vraiment être réveillé au milieu de la nuit pour taper des mots de passe, optez pour l'option 1. Lorsque vous avez plusieurs serveurs, vous souhaitez redémarrer automatiquement en cas d'échec, et l'option 2 ne le permet pas.

Une possibilité pour une sécurité supérieure à 1. mais moins de temps d'arrêt que 2. est de créer des clés privées à courte validité et de les recycler régulièrement. De cette façon, vous pouvez les stocker sans phrase secrète mais réduire la fenêtre de vulnérabilité.

Comme vous l'avez reconnu, l'option 3. n'offre aucune sécurité supplémentaire par rapport à 1.

Le caractère pratique dicte que dans presque toutes les situations, vous allez finir par utiliser l'option (1). Les perms du système de fichiers sont la meilleure façon de procéder dans la plupart des scénarios de sécurité et des scénarios pratiques.

Sur un système * nix, vous pouvez restreindre la clé privée à root uniquement, car la plupart des bons serveurs Web (comme apache) démarreront en tant que root mais déclasseront leurs privilèges vers un utilisateur restreint une fois qu'ils auront les ports privilégiés dont ils ont besoin (80, 443, etc.) .

Comme vous l'avez mentionné, l'option (3) est du point de vue de la sécurité identique à l'option (1).