MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Comment utiliser le chiffrement pour protéger vos données MongoDB

La sécurité de la base de données est un facteur clé à prendre en compte pour toute application impliquant des données hautement sensibles telles que des rapports financiers et de santé. La protection des données peut être obtenue grâce au cryptage à différents niveaux, de l'application elle-même aux fichiers contenant les données.

Étant donné que MongoDB est une base de données non relationnelle, il n'est pas nécessaire de définir des colonnes avant d'insérer des données ; et par conséquent, les documents d'une même collection peuvent avoir des champs différents les uns des autres.

D'autre part, pour le SGBD SQL, il faut définir des colonnes pour les données, donc toutes les lignes ont les mêmes colonnes. On peut décider de chiffrer des colonnes individuelles, un fichier de base de données entier ou des données de l'application avant d'être impliqué dans le processus de base de données.

Le cryptage des colonnes individuelles est le plus préféré car il est moins cher et moins de données sont cryptées, améliorant ainsi la latence. En général, les performances globales ont un impact en raison du chiffrement.

Pour les SGBD NoSQL, cette approche ne sera cependant pas la meilleure. Étant donné que tous les documents peuvent ne pas contenir tous les champs que vous souhaitez utiliser dans votre chiffrement, le chiffrement au niveau des colonnes ne peut pas être effectué.

Le chiffrement des données au niveau de l'application est assez coûteux et difficile à mettre en œuvre. Nous restons donc avec une option de cryptage des données au niveau de la base de données.

MongoDB fournit un cryptage natif qui ne nécessite pas de payer un coût supplémentaire pour sécuriser vos données sensibles.

Cryptage des données dans MongoDB

Toute opération de base de données implique l'une ou l'autre de ces deux formes de données, les données au repos ou les données en mouvement.

Les données en mouvement sont un flux de données se déplaçant sur tout type de réseau, tandis que les données au repos sont statiques et ne se déplacent nulle part.

Ces deux types de données sont sujets à des interférences externes par des utilisateurs anonymes, sauf si le cryptage est impliqué. Le processus de cryptage implique :

  • Génération d'une clé principale pour l'ensemble de la base de données
  • Générer des clés uniques pour chaque base de données
  • Chiffrer vos données avec les clés de base de données que vous avez générées
  • Chiffrer l'intégralité de la base de données avec la clé principale

Cryptage des données en transit

Les données sont échangées entre MongoDB et l'application serveur de deux manières, à savoir via Transport Layer Security (TLS) et Secure Socket Layer (SSL).

Ces deux protocoles de cryptage sont les plus utilisés pour sécuriser les données envoyées et reçues entre deux systèmes. Fondamentalement, le concept consiste à chiffrer les connexions aux instances mongod et mongos de sorte que le trafic réseau ne soit lisible que par le client prévu.

TLS/SSL sont utilisés dans MongoDB avec certains certificats sous forme de fichiers PEM qui sont émis par l'autorité de certification ou peuvent être un certificat auto-signé. Ce dernier a une limitation dans la mesure où le canal de communication est crypté, il n'y a toujours aucune validation contre l'identité du serveur, donc vulnérable aux attaques externes à mi-chemin. Il est donc conseillé d'utiliser des certificats d'autorité de confiance qui permettent aux pilotes MongoDB de vérifier également l'identité du serveur.

Outre le chiffrement, TLS/SSL peut être utilisé pour l'authentification du client et les authentifications internes des membres des jeux de réplicas et des clusters fragmentés via les certificats.

Configuration TLS/SSL pour les clients

Il existe différents paramètres d'option TLS/SSL qui peuvent être utilisés dans la configuration de ces protocoles.

Par exemple, si vous souhaitez vous connecter à une instance Mongod en utilisant le cryptage, vous devez démarrer votre instance comme suit :

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl active la connexion TLS/SSL.

--sslCAFile spécifie le fichier pem de l'autorité de certification (CA) pour la vérification du certificat présenté par le mongod ou les mongos. Le shell Mongo vérifiera donc le certificat émis par l'instance mongod par rapport au fichier CA spécifié et au nom d'hôte.

Vous pouvez également connecter une instance MongoDB qui nécessite un certificat client. Nous utilisons l'exemple de code ci-dessous

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

L'option --sslPEMKeyFile spécifie le fichier .pem qui contient le certificat shell mongo et une clé à présenter à l'instance mongod ou mongos. Pendant le processus de connexion :

Le shell mongo vérifiera si le certificat provient de l'autorité de certification spécifiée qui est le (--sslCAFile) et si ce n'est pas le cas, le shell ne parviendra pas à se connecter.

Deuxièmement, le shell vérifiera également si le nom d'hôte spécifié dans l'option --host correspond au SAN/CN dans le certificat présenté par le mongod ou les mongos. Si ce nom d'hôte ne correspond à aucun des deux, la connexion échouera.

Si vous ne souhaitez pas utiliser de certificats auto-signés, vous devez vous assurer que le réseau de connexion est fiable.

En outre, vous devez réduire l'exposition de la clé privée, en particulier lorsque des jeux de répliques/cluster fragmenté sont impliqués. Ceci peut être réalisé en utilisant différents certificats sur différents serveurs.

Les options supplémentaires pouvant être utilisées dans les connexions sont :

requireSSL :cela limitera chaque serveur à n'utiliser que des connexions chiffrées TLS/SSL.

--sslAllowConnectionsWithoutCertificates :Ceci permet la validation si seul le client présente un certificat sinon s'il n'y a pas de certificat, le client sera toujours connecté en mode crypté. Par exemple :

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols :cette option empêche les serveurs d'accepter les connexions entrantes qui utilisent des protocoles spécifiques. Cela peut être fait avec :

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Chiffrement des données au repos

À partir de la version 3.2, MongoDB a introduit une option de chiffrement natif pour le moteur de stockage WiredTiger. L'accès aux données de ce stockage par un tiers ne peut être obtenu que par le biais d'une clé de déchiffrement pour décoder les données dans un format lisible.

L'algorithme de chiffrement de chiffrement couramment utilisé dans MongoDB est l'AES256-GCM. Il utilise la même clé secrète pour chiffrer et déchiffrer les données. Le cryptage peut être activé à l'aide du mode FIPS, garantissant ainsi que le cryptage répond aux normes et à la conformité les plus élevées.

L'ensemble des fichiers de la base de données est crypté à l'aide du cryptage transparent des données (TDE) au niveau du stockage.

Chaque fois qu'un fichier est crypté, une clé de cryptage privée unique est générée et il est bon de comprendre comment ces clés sont gérées et stockées. Toutes les clés de base de données générées sont ensuite chiffrées avec une clé principale.

La différence entre les clés de base de données et la clé principale est que les clés de base de données peuvent être stockées avec les données cryptées elles-mêmes, mais pour la clé principale, MongoDB conseille de la stocker sur un serveur différent des données cryptées telles que la clé d'entreprise tierce. solutions de gestion.

Avec les données répliquées, les critères de chiffrement ne sont pas partagés avec les autres nœuds puisque les données ne sont pas chiffrées de manière native sur le câble. On peut réutiliser la même clé pour les nœuds, mais la meilleure pratique consiste à utiliser des clés individuelles uniques pour chaque nœud.

Rotation des clés de chiffrement

La clé gérée utilisée pour déchiffrer les données sensibles doit être renouvelée ou remplacée au moins une fois par an. Il existe deux options dans MongoDB pour réaliser la rotation.

Rotation principale KMIP

Dans ce cas, seule la clé principale est modifiée car elle est gérée en externe. Le processus de rotation de la clé est décrit ci-dessous.

  1. La clé principale des membres secondaires du jeu de réplicas est tournée une à la fois. C'est-à-dire

    mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

    Une fois le processus terminé, mongod se fermera et vous devrez redémarrer le secondaire sans le paramètre kmipRotateMasterKey

    mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

  2. Le jeu de réplicas primaire est réduit :
    En utilisant la méthode rs.stepDown(), le primaire est désactivé, forçant ainsi l'élection d'un nouveau primaire.

  3. Vérifiez l'état des nœuds à l'aide de la méthode rs.status() et si le primaire indique avoir été réduit, faites pivoter sa clé principale. Redémarrez le membre rétrogradé, y compris l'option kmipRotateMasterKey.

    mongod --enableEncryption --kmipRotateMasterKey \
  --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Journalisation

MongoDB fonctionne toujours avec un fichier journal pour enregistrer un état ou des informations spécifiées à différents intervalles.

Cependant, le fichier journal n'est pas chiffré dans le cadre du moteur de stockage. Cela présente un risque dans la mesure où une instance mongod exécutée avec la journalisation peut générer des données potentiellement sensibles dans les fichiers journaux dans le cadre de la journalisation normale.

À partir de la version 3.4 de MongoDB, il existe le paramètre security.redactClientLogData qui empêche les données potentiellement sensibles d'être enregistrées dans le journal de processus mongod. Cependant, cette option peut compliquer les diagnostics du journal.

Plusieursnines Devenez un administrateur de base de données MongoDB – Amener MongoDB en productionDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer MongoDBDélécharger gratuitement

Performances de chiffrement dans MongoDB

Le chiffrement à un moment donné entraîne une latence accrue, dégradant ainsi les performances d'une base de données. C'est généralement le cas lorsqu'un grand volume de documents est impliqué.

Le chiffrement et le déchiffrement nécessitent plus de ressources, il est donc important de comprendre cette relation afin d'ajuster la planification de la capacité en conséquence.

En ce qui concerne les tests MongoDB, un moteur de stockage chiffré connaîtra une latence comprise entre 10 % et 20 % à la charge la plus élevée. C'est souvent le cas lorsqu'un utilisateur écrit une grande quantité de données dans la base de données, ce qui entraîne une réduction des performances. Pour les opérations de lecture, la dégradation des performances est négligeable, de l'ordre de 5 à 10 %.

Pour une meilleure pratique de chiffrement dans MongoDB, le moteur de stockage WiredTiger est préféré en raison de ses hautes performances, de sa sécurité et de son évolutivité. En outre, il optimise le cryptage des fichiers de base de données au niveau de la page, ce qui a un grand mérite en ce que, si un utilisateur lit ou écrit des données dans la base de données cryptée, l'opération de débit ne sera appliquée qu'à la page sur laquelle les données sont stockées plutôt qu'à l'ensemble. base de données.

Cela réduira la quantité de données qui devront être chiffrées et déchiffrées pour traiter une seule donnée.

Résumé

La sécurité des données pour les informations sensibles est indispensable et il est nécessaire de les protéger sans dégrader les performances du système de base de données.

MongoDB fournit des procédures de chiffrement natives robustes qui peuvent nous aider à sécuriser nos données à la fois au repos et en mouvement. En outre, les procédures de cryptage doivent être conformes aux normes établies par différentes organisations.

Le moteur de stockage avancé WiredTiger offre une meilleure option en raison de ses mérites associés tels que la haute performance, l'évolutivité et la sécurité. Lors du chiffrement de données dans des jeux de réplicas, il est recommandé d'utiliser des clés principales différentes pour chacun, en plus de les changer au moins une fois par an.

Cependant, la disponibilité d'options de chiffrement tierces ne garantit pas que votre déploiement correspondra à celles-ci en termes d'évolutivité. Il est donc tout à fait prudent d'employer un chiffrement au niveau de la base de données.