Où stocker une clé de chiffrement côté serveur?
J'ai des données chiffrées symétriquement avec une seule clé dans ma base de données. Plutôt que de le coder en dur dans mon code, je recherche un moyen plus sûr de stocker la clé de cryptage. Où puis-je le stocker en toute sécurité?
Voici vos possibilités, à peu près en ordre décroissant de sophistication.
Utilisez un module de sécurité matérielle externe. Il existe un toute l'industrie des produits conçu pour décharger les opérations sensibles à la sécurité sur des périphériques externes. Cela ne fait pas résoudre le problème autant que relocaliser, mais il le déplace sur un appareil qui est beaucoup plus sécurisé, donc c'est une victoire en matière de sécurité. Si vous faites quelque chose d'important, alors cela va presque certainement jouer un rôle dans votre solution.
Attachez le chiffrement à votre matériel. En théorie, les HSM font précisément cela, seulement nous avons tendance à nous attendre à un peu plus de sophistication d'un HSM qu'un simple chiffrement soutenu par du matériel . Mais il existe des options moins chères si vous n'avez pas besoin du débit et de la conformité qu'un véritable HSM apporte à la table. Les puces TPM ont été inventées en partie à cette fin, et de nombreux exemples montrent comment les intégrer. De plus, le matériel de cryptographie dédié est devenu assez peu coûteux, et réutiliser des appareils comme Clés U2F Open-Source pour cela est plus simple qu'il n'y paraît.
Attachez la clé de cryptage à votre connexion administrateur (par exemple, cryptez la clé de cryptage avec votre connexion administrateur). Ceci n'est que marginalement utile car il nécessite que vous soyez connecté pour crypter/décrypter quoi que ce soit. Mais du côté positif, personne ne peut chiffrer/déchiffrer quoi que ce soit à moins d'être connecté (c'est-à-dire un meilleur contrôle). Une grande partie du stockage sécurisé dans Windows fonctionne comme ceci.
Tapez la clé de chiffrement au démarrage, stockez-la en mémoire. Cela protège contre les attaques hors ligne (sauf si elles capturent la clé hors de la RAM, ce qui est plus difficile à faire). Similaire à l'option ci-dessus, mais également différent. Cependant, le serveur démarre dans un état inutilisable, vous obligeant à fournir manuellement la clé avant de pouvoir travailler.
Stockez la clé sur un autre serveur. Par exemple. mettre la clé sur le serveur web et les données cryptées sur le serveur de base de données. Cela vous protège dans une certaine mesure parce que quelqu'un devrait savoir pour récupérer la clé ainsi que la base de données, et il devrait également avoir accès aux deux serveurs. Pas incroyablement sûr, mais une option extrêmement populaire de toute façon. La plupart des gens qui pensent le faire c'est vrai le font de cette façon. Si vous envisagez de le faire, envisagez également l'une des deux premières options mentionnées ci-dessus.
Stockez la clé ailleurs sur le même serveur. Ajoute une sécurité marginale, mais pas beaucoup. La plupart des petites exploitations font cela - elles ne devraient pas, mais elles le font. Généralement, car ils n'ont qu'un seul serveur et il s'exécute quelque part dans un cloud. C'est comme coller une clé sur la porte au lieu de la laisser dans la serrure; garanti pour arrêter le plus incompétent des attaquants.
Stockez la clé dans la base de données. Maintenant, vous n'essayez même pas. Pourtant, une option déprimant populaire.
De nombreuses solutions KMS basées sur le cloud (par exemple: AWS , GCP , Azure ), lorsqu'il est utilisé le plus efficacement, liera votre chiffrement à vos machines virtuelles ou à votre environnement cloud. L'identité unique de votre VM est facile pour l'hyperviseur à établir et à affirmer, et le KMS utilise la combinaison de cette identité et des autorisations que vous lui avez attribuées pour permettre l'accès à un HSM-géré clé de chiffrement. Ceci est similaire à une combinaison des options 1 et 2, modulée pour tenir compte de la nature éphémère des machines virtuelles cloud. Ces solutions KMS sont généralement également compatibles avec les autres mécanismes d'identité de la plate-forme, liant efficacement les clés de chiffrement aux clés de connexion; un peu comme option 3.
Je sais que cela a été répondu il y a quelque temps, mais pour donner quelques exemples à la bonne réponse de Tyler:
Je prévois d'utiliser son # pour lier un mot de passe à un compte de service et utiliser une applet de commande Powershell pour l'obtenir. De cette façon, les scripts n'ont pas besoin d'être aussi fortement modifiés. Le mot de passe du compte de service se trouve dans Active Directory et devrait être compromis en premier. Cela fonctionne pour moi car je l'ai utilisé sur deux serveurs.
Pour son # 5, pour répondre à notre conformité, nous avons pu stocker une clé en texte brut sur un autre serveur avec un stockage externe car ce stockage était lui-même crypté et l'accès y était restreint. Comme Tyler le mentionne, ce dernier ne semble pas si sûr, mais c'était assez bon même pour un évaluateur difficile.
Vous pouvez créer une architecture à deux couches pour la gestion des clés.
- Une clé pour crypter vos données au repos en cryptant les tablespaces, ou en fonction des colonnes.
- Clé principale pour déverrouiller 1.
pour vos clés principales, utilisez l'une des solutions de gestion de clés établies telles que:
- Amazon AWS KMS
- Oracle Vault
- Microsoft MKS.
- ou open source.
N'oubliez pas que votre gestionnaire de clés doit prendre en charge une disponibilité égale ou supérieure à votre infrastructure où la clé gérée est utilisée.