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

Le manuel d'audit de base de données open source DevOps - Tout ce que vous devez savoir

L'audit est la surveillance et l'enregistrement des actions sélectionnées de la base de données des utilisateurs. Il est généralement utilisé pour enquêter sur des activités suspectes ou surveiller et collecter des données sur des activités de base de données spécifiques. Par exemple, l'administrateur de la base de données peut collecter des statistiques sur les tables mises à jour, le nombre d'opérations effectuées ou le nombre d'utilisateurs simultanés qui se connectent à des moments particuliers.

Dans cet article de blog, nous allons couvrir les aspects fondamentaux de l'audit de nos systèmes de bases de données open source, en particulier MySQL, MariaDB, PostgreSQL et MongoDB. Cet article s'adresse aux ingénieurs DevOps qui ont généralement moins d'expérience ou d'exposition aux meilleures pratiques en matière de conformité d'audit et de bonne gouvernance des données lorsqu'ils gèrent l'infrastructure principalement pour les systèmes de base de données.

Audit des déclarations

Audit des instructions MySQL

MySQL a le journal général des requêtes (ou general_log), qui enregistre essentiellement ce que fait mysqld. Le serveur écrit des informations dans ce journal lorsque les clients se connectent ou se déconnectent, et il consigne chaque instruction SQL reçue des clients. Le journal des requêtes générales peut être très utile lors du dépannage, mais pas vraiment conçu pour un audit continu. Il a un impact important sur les performances et ne doit être activé que pendant de courtes périodes. Il existe d'autres options pour utiliser les tables performance_schema.events_statements* ou Audit Plugin à la place.

Audit des instructions PostgreSQL

Pour PostgreSQL, vous pouvez activer le log_statment sur "all". Les valeurs prises en charge pour ce paramètre sont none (off), ddl, mod et all (toutes les instructions). Pour "ddl", il enregistre toutes les instructions de définition de données, telles que les instructions CREATE, ALTER et DROP. Pour "mod", il enregistre toutes les instructions DDL, ainsi que les instructions de modification de données telles que INSERT, UPDATE, DELETE, TRUNCATE et COPY FROM.

Vous devez probablement configurer les paramètres associés tels que log_directory, log_filename, logging_collector et log_rotation_age, comme indiqué dans l'exemple suivant :

log_directory     = 'pg_log'
log_filename      = 'postgresql-%Y-%m-%d_%H%M%S.log'
log_statement     = 'all'
logging_collector = on
log_rotation_age  = 10080 # 1 week in minutes

Les modifications ci-dessus nécessitent un redémarrage de PostgreSQL, veuillez donc planifier soigneusement avant de les appliquer à votre environnement de production. Vous pouvez ensuite trouver les journaux actuels sous le répertoire pg_log. Pour PostgreSQL 12, l'emplacement est /var/lib/pgsql/12/data/pg_log/ . Notez que les fichiers journaux ont tendance à augmenter considérablement avec le temps et peuvent considérablement consommer de l'espace disque. Vous pouvez également utiliser log_rotation_size à la place si vous disposez d'un espace de stockage limité.

Audit des déclarations MongoDB

Pour MongoDB, il existe 3 niveaux de journalisation qui peuvent nous aider à auditer les déclarations (opérations ou ops dans le terme MongoDB) :

  • Niveau 0 - Il s'agit du niveau de profileur par défaut où le profileur ne collecte aucune donnée. Le mongod écrit toujours des opérations plus longues que le seuil slowOpThresholdMs dans son journal.

  • Niveau 1 - Collecte les données de profilage pour les opérations lentes uniquement. Par défaut, les opérations lentes sont celles qui prennent moins de 100 millisecondes. Vous pouvez modifier le seuil des opérations « lentes » avec l'option d'exécution slowOpThresholdMs ou la commande setParameter.

  • Niveau 2 - Collecte des données de profilage pour toutes les opérations de base de données.

Pour enregistrer toutes les opérations, définissez db.setProfilingLevel(2, 1000), où il doit profiler toutes les opérations avec des opérations qui prennent plus de temps que les millisecondes définies, dans ce cas, est de 1 seconde (1000 ms) . La requête à rechercher dans la collection de profils système pour toutes les requêtes qui ont pris plus d'une seconde, classées par horodatage décroissant, sera. Pour lire les opérations, nous pouvons utiliser la requête suivante :

mongodb> db.system.profile.find( { millis : { $gt:1000 } } ).sort( { ts : -1 } )

Il existe également le projet Mongotail, qui simplifie le processus de profilage des opérations avec un outil externe au lieu d'interroger directement la collection de profils.

Gardez à l'esprit qu'il n'est pas recommandé d'exécuter un audit complet des instructions dans les serveurs de base de données de production, car cela introduit généralement un impact significatif sur le service de base de données avec un énorme volume de journalisation. La méthode recommandée consiste à utiliser à la place un plug-in d'audit de base de données (comme indiqué plus bas), qui fournit un moyen standard de produire des journaux d'audit souvent requis pour se conformer aux certifications gouvernementales, financières ou ISO.

Audit des privilèges pour MySQL, MariaDB et PostgreSQL

L'audit des privilèges audite les privilèges et le contrôle d'accès aux objets de la base de données. Le contrôle d'accès garantit que les utilisateurs accédant à la base de données sont formellement identifiés et peuvent accéder, mettre à jour ou supprimer les données auxquelles ils ont droit. Ce domaine est généralement négligé par l'ingénieur DevOps, ce qui fait de la sur-privilégiation une erreur courante lors de la création et de l'octroi d'un utilisateur de base de données.

Exemples de privilèges excessifs :

  • Les hôtes d'accès de l'utilisateur sont autorisés à partir d'un très large éventail, par exemple en accordant à l'utilisateur l'hôte [email protected]' %', au lieu d'une adresse IP individuelle.

  • Les privilèges administratifs sont attribués aux utilisateurs de base de données non administratifs, par exemple, un utilisateur de base de données pour l'application est attribué avec le privilège SUPER ou RELOAD.

  • Manque de contrôle des ressources contre tout type d'utilisation excessive comme le nombre maximal de connexions utilisateur, le nombre maximal de requêtes par heure ou le nombre maximal Connexions par heure.

  • Autoriser des utilisateurs de base de données spécifiques à accéder également à d'autres schémas.

Pour MySQL, MariaDB et PostgreSQL, vous pouvez effectuer un audit des privilèges via le schéma d'informations en interrogeant les tables liées aux droits, aux rôles et aux privilèges. Pour MongoDB, utilisez la requête suivante (nécessite l'action viewUser pour les autres bases de données) :

mongodb> db.getUsers( { usersInfo: { forAllDBs: true } } )

ClusterControl fournit un bon résumé des privilèges attribués à un utilisateur de base de données. Allez dans Gérer -> Schémas et utilisateurs -> Utilisateurs et vous obtiendrez un rapport des privilèges des utilisateurs, ainsi que des options avancées telles que Nécessite SSL, Max Connections Per Hour, etc.

ClusterControl prend en charge l'audit des privilèges pour MySQL, MariaDB et PostgreSQL sous le même utilisateur interface.

Audit d'objet de schéma

Les objets de schéma sont des structures logiques créées par les utilisateurs. Des exemples d'objets de schéma sont des tables, des index, des vues, des routines, des événements, des procédures, des fonctions, des déclencheurs et autres. Il s'agit essentiellement d'objets contenant des données ou pouvant consister uniquement en une définition. Généralement, on audite les autorisations associées aux objets de schéma pour détecter les paramètres de sécurité médiocres et comprendre la relation et les dépendances entre les objets.

Pour MySQL et MariaDB, il existe information_schema et performance_schema que nous pouvons utiliser pour auditer essentiellement les objets de schéma. Performance_schema est un peu en profondeur dans l'instrumentation comme son nom l'indique. Cependant, MySQL inclut également un schéma sys depuis la version 5.7.7, qui est une version conviviale de performance_schema. Toutes ces bases de données sont directement accessibles et interrogeables par les clients.

Plug-ins/extensions d'audit de base de données

La méthode la plus recommandée pour effectuer un audit des déclarations consiste à utiliser un plug-in ou une extension d'audit, spécialement conçu pour la technologie de base de données utilisée. MariaDB et Percona ont leur propre implémentation de plug-in Audit, qui est un peu différente du plug-in Audit de MySQL disponible dans MySQL Enterprise. Les enregistrements d'audit incluent des informations sur l'opération qui a été auditée, l'utilisateur effectuant l'opération, ainsi que la date et l'heure de l'opération. Les enregistrements peuvent être stockés soit dans une table de dictionnaire de données, appelée piste d'audit de la base de données, soit dans des fichiers du système d'exploitation, appelés piste d'audit du système d'exploitation.

Pour PostgreSQL, il existe pgAudit, une extension PostgreSQL qui fournit une journalisation d'audit détaillée de session et/ou d'objet via la fonction de journalisation PostgreSQL standard. Il s'agit essentiellement d'une version améliorée de la fonctionnalité log_statement de PostgreSQL avec la possibilité de rechercher et de rechercher facilement les données capturées pour l'audit en suivant le journal d'audit standard.

MongoDB Enterprise (payant) et Percona Server pour MongoDB (gratuit) incluent une capacité d'audit pour les instances mongod et mongos. Lorsque l'audit est activé, le serveur génère des messages d'audit qui peuvent être enregistrés dans syslog, console ou fichier (format JSON ou BSON). Dans la plupart des cas, il est préférable de se connecter au fichier au format BSON, où l'impact sur les performances est inférieur à JSON. Ce fichier contient des informations sur différents événements utilisateur, notamment l'authentification, les échecs d'autorisation, etc. Consultez la documentation d'audit pour plus de détails.

Pistes d'audit du système d'exploitation

Il est également important de configurer les pistes d'audit du système d'exploitation. Pour Linux, les gens utiliseraient couramment auditd. Auditd est le composant de l'espace utilisateur du système d'audit Linux et est responsable de l'écriture des enregistrements d'audit sur le disque. La visualisation des logs se fait avec les utilitaires ausearch ou aureport. La configuration des règles d'audit se fait avec l'utilitaire auditctl, ou en modifiant directement les fichiers de règles.

Les étapes d'installation suivantes sont notre pratique courante lors de la configuration de tout type de serveurs pour une utilisation en production :

$ yum -y install audit # apt install auditd python
$ mv /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.ori
$ cd /etc/audit/rules.d/
$ wget https://gist.githubusercontent.com/ashraf-s9s/fb1b674e15a5a5b41504faf76a08b4ae/raw/2764bf0e9bf25418bb86e33c13fb80356999d220/audit.rules
$ chmod 640 audit.rules
$ systemctl daemon-reload
$ systemctl start auditd
$ systemctl enable auditd
$ service auditd restart

Notez que la dernière ligne de redémarrage du service auditd est obligatoire car audit ne fonctionne pas très bien lors du chargement de règles avec systemd. Cependant, systemd est toujours nécessaire pour surveiller le service auditd. Au démarrage, les règles dans /etc/audit/audit.rules sont lues par auditctl. Le démon d'audit lui-même dispose de certaines options de configuration que l'administrateur peut souhaiter personnaliser. Ils se trouvent dans le fichier auditd.conf.

La ligne suivante est une sortie extraite d'un journal d'audit configuré :

$ ausearch -m EXECVE | grep -i 'password' | head -1
type=EXECVE msg=audit(1615377099.934:11838148): argc=7 a0="mysql" a1="-NAB" a2="--user=appdb1" a3="--password=S3cr3tPassw0rdKP" a4="-h127.0.0.1" a5="-P3306" a6=2D6553484F5720474C4F42414C205641524941424C4553205748455245205641524941424C455F4E414D4520494E20282776657273696F6E272C202776657273696F6E5F636F6D6D656E74272C2027646174616469722729

Comme vous pouvez le voir ci-dessus, il est facile de repérer un mot de passe en clair pour MySQL ("--password=S3cr3tPassw0rdKP") en utilisant l'utilitaire ausearch tel que capturé par auditd. Ce type de découverte et d'audit est essentiel pour sécuriser notre infrastructure de base de données, où un mot de passe en clair est inacceptable dans un environnement sécurisé.

Réflexions finales

Le journal d'audit ou la piste est un aspect vital qui est souvent négligé par les ingénieurs DevOps lors de la gestion des infrastructures et des systèmes, sans parler du système de base de données qui est un système très critique pour stocker des données sensibles et confidentielles. Toute exposition ou violation de vos données privées peut être extrêmement dommageable pour l'entreprise et personne ne voudrait que cela se produise à l'ère actuelle des technologies de l'information.