La sécurité des données est cruciale à l'époque du RGPD, PCI DSS ou HIPPA. Pour se conformer à la réglementation, il faut faire preuve d'une extrême prudence quant à la manière dont les données doivent être stockées et protégées. Les données, généralement, peuvent être au repos ou en transit. Les données en transit sont les données transférées depuis ou vers la base de données. Les résultats de requête envoyés au client ou à l'application ou les données répliquées entre les nœuds du cluster sont des exemples de cas où les données sont en transit. Nous avons tendance à sécuriser les données dans cet état en utilisant les connexions cryptées SSL ou TLS entre les nœuds de la base de données ou la base de données et le client.
De l'autre côté du spectre, nous avons des données au repos - nous dirions que la plupart des données sont, à un moment donné, au repos. On parle ici de données stockées sur disque dans des tablespaces, de différentes structures de données (buffer gcache, redo logs) et de logs (binary et relay logs). Jetons un coup d'œil aux considérations autour de ce sujet dans MariaDB.
Que chiffrer dans MariaDB ?
Idéalement, vous devez tout chiffrer. Les bases de données stockent les données à différents endroits et de différentes manières, comme mentionné ci-dessus. Le plus grand ensemble de données est stocké dans les tablespaces - c'est l'emplacement « final » où les données sont stockées. Évidemment, il est possible de chiffrer les tablespaces - sinon, toute la fonctionnalité serait inutile. MariaDB peut stocker les données dans un espace de table partagé, plusieurs d'entre eux ou chaque table peut être stockée dans un espace de table séparé - tous ces scénarios sont pris en charge. Les utilisateurs disposent d'un certain niveau de flexibilité lorsqu'ils choisissent ce qu'ils veulent chiffrer. Vous pouvez tout chiffrer, des tables individuelles ou tout sauf certaines tables individuelles.
Journal de rétablissement MariaDB InnoDB
Une autre structure qui stocke les données est le journal redo InnoDB. Le journal de rétablissement InnoDB est un endroit où les données sont écrites après la mise à niveau d'une ligne donnée. Les données du journal redo seront finalement transférées vers l'espace de table, mais pour un moment, le journal redo InnoDB contient toutes les modifications qui se sont produites récemment. Comme vous pouvez l'imaginer, ces données sont également critiques et doivent être protégées - MariaDB vous permet de chiffrer le journal de rétablissement InnoDB.
Journaux binaires MariaDB
Les journaux binaires (ainsi que les journaux de relais) stockent des informations sur les requêtes exécutées qui modifient les données. Comme les informations incluses nous permettent de reconstruire l'état actuel d'une ligne qui a subi une modification, il s'agit d'une autre forme de données qui doit être protégée et cryptée. Les journaux binaires et de relais peuvent être chiffrés dans MariaDB.
Cache Galera
Le cache Galera (gcache) est un tampon sur disque dans Galera Cluster qui stocke les informations sur les modifications exécutées. Il est utilisé en cas de panne de nœud ou de problèmes de réseau temporaires pour permettre aux nœuds qui rejoignent le cluster de rattraper leur retard en utilisant uniquement les données qui leur manquent, en évitant de transférer l'ensemble des données. Semblable aux logs binaires ou aux redo logs, gcache contient la liste des modifications et, à ce titre, il peut être utilisé pour récupérer et assembler des données. Dans la version communautaire de MariaDB Galera Cluster, gcache ne peut pas être chiffré. Cette option devient disponible dans la version Entreprise de MariaDB Galera Cluster.
Qu'est-ce qui ne peut pas être chiffré dans MariaDB ?
Il existe encore des endroits où des éléments de données peuvent apparaître qui ne peuvent pas être chiffrés, du moins pour le moment, dans MariaDB. Premièrement, les journaux d'erreurs peuvent contenir des exemples de requêtes susceptibles d'exposer certaines données. Il est impossible de chiffrer les journaux d'erreurs, mais il est possible de rediriger le journal des erreurs vers le syslog et d'implémenter un mécanisme de protection en dehors de MariaDB.
Journaux du plug-in d'audit
Audit Plugin génère également un journal - ce journal peut contenir des informations sensibles, y compris les requêtes exactes qui ont été exécutées sur la base de données. Il n'est pas possible de chiffrer ce journal, mais il peut être redirigé vers le syslog et y être chiffré.
Journaux de requête
Journaux des requêtes générales et lentes :ces journaux contiendront des requêtes (ou au moins des exemples de celles-ci) qui ont été exécutées par MariaDB. Pour l'instant, il n'est pas possible de chiffrer ces journaux.
Pool de mémoire tampon InnoDB
Mémoire - MariaDB effectue le chiffrement uniquement pour les pages stockées sur le disque. Toutes les données stockées dans le pool de mémoire tampon InnoDB ne seront pas chiffrées. Le pool de mémoire tampon InnoDB est destiné à conserver les lignes récemment modifiées ou consultées par la requête SELECT - ces lignes contiendront évidemment des échantillons de données. Pour l'instant, il n'y a pas d'option pour chiffrer le pool de mémoire tampon InnoDB dans MariaDB. Veuillez garder à l'esprit qu'il faudrait accéder au système pour lire la mémoire vive. Ce n'est pas une tâche triviale, même si ce n'est pas non plus impossible à accomplir.
Veuillez garder à l'esprit que nous avons couvert les options de chiffrement incluses dans MariaDB. Il y a toujours la possibilité d'utiliser une autre couche de cryptage. Par exemple, chiffrer tout le stockage rendra les journaux illisibles pour quiconque aurait un accès physique au disque. D'un autre côté, cela ne protégera pas les données d'une personne capable de se connecter au système.
Compatibilité avec les outils externes
Une autre chose à considérer est la compatibilité. Si vous décidez de chiffrer votre MariaDB, vous devez garder à l'esprit que cela peut avoir un impact sur votre façon de fonctionner. Il n'est pas possible d'utiliser des outils externes comme XtraBackup ou mysqlbinlog pour traiter les données et créer une sauvegarde ou pour gérer les journaux binaires. Vous devrez vous en tenir aux outils créés par MariaDB (comme Mariabackup), qui sont écrits avec le mécanisme de cryptage à l'esprit. Ils peuvent gérer les données au repos, le chiffrement est implémenté dans MariaDB.
Planification du processus de chiffrement
Cette section n'abordera pas le processus en détail, mais elle examine ce que vous devez prendre en compte lors de la planification du chiffrement, comme les ressources et le temps. L'utilisation du processeur augmentera ainsi que l'activité d'E/S pendant la durée du processus. Du point de vue de l'utilisateur, tout se résume aux paramètres de configuration, puis à l'exécution des commandes ALTER pour reconstruire et chiffrer les tables existantes. Pour les grandes bases de données, cela seul peut être un défi important qui nécessiterait une planification. Les changements de schéma peuvent être un fardeau sérieux, et il est recommandé d'utiliser des outils comme pt-online-schema-change pour réduire leur impact sur les systèmes de production et mieux contrôler le processus.
Réflexions finales
Comme nous l'avons mentionné, les données sont essentielles pour toutes les organisations, et il est crucial de s'assurer que les données sont sûres et protégées. Le chiffrement des données au repos est l'un des éléments importants de l'ensemble. Nous aimerions connaître votre expérience avec le chiffrement des données au repos dans MariaDB. Si vous souhaitez partager vos réflexions, vous êtes invités à laisser un commentaire ci-dessous.
