Stockage des secrets d'application en toute sécurité sur Linux
J'ai une application Linux qui doit lire un secret pour décrypter certaines données. L'application permet également aux utilisateurs de modifier le mot de passe de cryptage pendant l'exécution. L'application s'exécutera sous un compte d'utilisateur distinct et le secret se trouve actuellement dans un fichier appartenant à cet utilisateur. J'essaie de penser à des moyens d'améliorer cette situation puisque le mot de passe est en clair dans un fichier.
L'application peut être démarrée en tant que root, puis abandonner les privilèges à l'utilisateur de l'application. De cette façon, le fichier secret peut appartenir à root, mais le scénario de changement de mot de passe s'arrête à moins que j'exécute un autre démon en tant que root.
Je cherche essentiellement à empêcher le secret d'être en texte brut sur le disque, et sans humain dans la boucle pour bootstrap le processus de cryptage, le mieux qui puisse être fait est de le rendre plus difficile à accéder au secret même si quelqu'un obtient l'exécution de code.
Quelqu'un peut-il partager des suggestions sur la façon dont je peux améliorer la situation actuelle? Est-ce que keyctl est quelque chose qui s'applique ici ou est-ce normalement utilisé uniquement pour stocker les secrets du noyau?
Toute suggestion sera appréciée!
Votre service ne devrait pas s'exécuter en tant que root en général . L'utilisation d'un utilisateur distinct pour stocker le secret est une sage précaution, mais le stockage de fichiers avec root propriété n'est pas meilleur pour le secret que l'utilisation d'un autre utilisateur dédié pour cela. Tant que votre fichier secret dispose d'autorisations 600 ou moins, il sera à l'abri des autres utilisateurs nonroot. Tout ce qui fonctionne root a quand même un accès complet. (sauf si vous exécutez une configuration SELinux complexe)
Il peut être utile d'utiliser deux utilisateurs pour cette seule application pour isoler la gestion des secrets du fonctionnement normal. Soit deux démons s'exécutant avec des communications en temps réel, soit des commandes utilitaires pour opérer sur le secret, obtenant les privilèges nécessaires (basés sur un utilisateur ou un groupe) via Sudo.
Vous devez considérer les vecteurs d'attaque potentiels.
SQLi, s'il est correctement configuré, n'accorde pas l'accès au système de fichiers, mais les attaques par cheminement pourraient le faire. Il existe d'autres types d'attaques contre votre application contre lesquelles vous devez vous protéger.
Des exploits dans les bibliothèques C (c'est-à-dire OpenSSL exécutant votre cryptage HTTPS, traitement d'image, etc.) pourraient être possibles. L'utilisation d'un utilisateur séparé sur les processus exposés au réseau peut aider à limiter la portée ou à ajouter de la difficulté à une attaque.
Les effractions de d'autres vecteurs d'attaque pourraient être un problème. (SSH, autres services sur la machine) Assurez-vous que tout ce qui peut accéder à
rootest bien sécurisé.
Toutes ces considérations devraient vous aider à sécuriser le secret lui-même. Maintenant, la question est, le secret doit-il vraiment être stocké en clair?
Au niveau le plus élémentaire, oui, le secret doit être stocké quelque part pour qu'il soit utilisable. Il doit au moins être stocké dans la mémoire, mais un stockage permanent d'une certaine sorte est également nécessaire.
Au-delà de la séparation des utilisateurs dont nous avons discuté, il pourrait être utile de décharger les secrets vers un module de sécurité matériel distinct , ou même un mini-ordinateur séparé . (c'est-à-dire Raspberry Pi) Il y a ne discussion sur la séparation physique ici .
Il y a très peu de cas où le secret peut être chiffré lui-même dans un stockage permanent.
Si votre problème est le vol de disque dur (en laissant le reste de la machine derrière vous), vous pourriez avoir un script de démarrage qui interroge certains des autres matériels pour des identifiants uniques , et dérive une clé de chiffrement en utilisant une bonne fonction de dérivation de clé basée sur un mot de passe; pour décrypter le secret.
Si le client peut fournir une partie du secret, ce serait utile. J'ai décrit un moyen de dériver les clés de déchiffrement des mots de passe utilisateur et des jetons de session ici . Il s'agit d'un système élaboré mais efficace qui se concentre sur la limitation de la durée de stockage d'un secret, même en mémoire. (en supposant que vous n'avez pas besoin d'une réinitialisation automatique du mot de passe)
Ce que vous avez, c'est la façon traditionnelle de faire les choses. C'est ainsi que Tomcat, par exemple, recommande de le faire, avec OWASP en accord . Donc, ce que vous avez n'est pas mauvais.
Cependant, il existe d'autres façons de procéder: les modules de sécurité matérielle sont un stockage à accès limité conçu pour le stockage des clés. Vault, KeyWhiz et les technologies similaires de Hashicorp sont des systèmes de gestion secrets, essayant essentiellement d'être des HSM logiciels. Bien sûr, toutes ces technologies doivent être en mesure d'authentifier le processus - leur avantage est qu'elles ont une variété de mécanismes pour cela. Vous pouvez utiliser root pour accéder à une clé qui n'est ensuite fournie en mémoire qu'à l'internaute - il peut utiliser cette clé pour accéder au HSM/Vault/KeyWhiz pour pouvoir accéder à la clé réelle et la modifier. Il existe également d'autres mécanismes - spécifiques à AWS utilisant des clés EC2, un tas d'autres. Vous pourrez peut-être trouver quelque chose qui s'accorde bien.
Mon opinion personnelle est que l'utilisateur restreint et éprouvé (utilisé UNIQUEMENT à cette fin) et les fichiers restreints à cet utilisateur uniquement ne sont pas une mauvaise façon de procéder. Cependant, cela ne se transforme pas aussi bien que d'autres options.
Si le secret est stocké sur le serveur d'une manière qui est lisible par l'application sans intervention humaine, alors il est lisible par au moins root sur la machine.
Peu importe que le fichier soit en texte brut; il ne peut être protégé que par des autorisations et root peut contourner ces autorisations. Le chiffrement du fichier (ou du système de fichiers dans lequel il se trouve) n'aidera que si la clé de chiffrement est uniquement mise à la disposition du processus pour lire le fichier, et cela nécessite une intervention externe (et une vérification); vous déplacez simplement le problème de l'accès au secret ailleurs.
Même si vous conservez le contrôle de tous les comptes sur le système - en le créant comme une appliance, mais cela pose toujours le problème de l'accès physique au système. Si vous êtes satisfait que l'intégrité physique peut être assurée, alors vous avez le problème de maintenir le système en tant qu'appliance - comment les correctifs seront-ils installés?
Je suis loin d'être convaincu qu'un hsm, même dans le matériel, fournit une solution complètement sécurisée, plutôt que de rendre l'accès normal trop élaboré (tout en compliquant, mais sans empêcher l'accès non autorisé).
Étant donné que toute solution serait un compromis sur vos attentes, vous devrez être plus précis sur les contraintes (coûts de développement, coûts unitaires, volume attendu) ainsi que plus de détails sur le modèle thret.