Comment auditer une base de données PostgreSQL avec InSpec sur Ubuntu 18.04

InSpec est un cadre de test automatisé open source pour tester et auditer votre système afin de garantir la conformité de l'intégration, de la sécurité et d'autres exigences de politique. Les développeurs peuvent tester l'état actuel de leur infrastructure et de leurs applications par rapport à un état cible à l'aide du code InSpec.

Pour spécifier les exigences de stratégie que vous testez, InSpec inclutaudit controls. En règle générale, les développeurs appliquent manuellement les exigences en matière de règles et le font bien avant le déploiement des modifications en production. Cependant, avec InSpec, les développeurs peuvent évaluer en permanence la conformité à chaque étape du développement du produit, ce qui aide à résoudre les problèmes plus tôt dans le processus de développement. LeInSpec DSL (Domain Specific Language) construit surRSpec, un outil de test DSL écrit en Ruby, spécifie la syntaxe utilisée pour écrire les contrôles d'audit.

InSpec comprend également une collection deresources pour vous aider à configurer des parties spécifiques de votre système et pour simplifier les contrôles d'audit. Il existe une fonctionnalité permettant d’écrire vos propres ressources personnalisées lorsque vous devez définir une solution spécifique qui n’est pas disponible. Universal matchers vous permet de comparer les valeurs des ressources aux attentes de tous les tests InSpec.

Dans ce tutoriel, vous installerez InSpec sur un serveur exécutant Ubuntu 18.04. Vous commencerez par écrire un test qui vérifie la famille du système d’exploitation du serveur, puis vous créerez un profil d’audit PostgreSQL. Ce profil d'audit commence par vérifier que PostgreSQL est installé sur le serveur et que ses services sont en cours d'exécution. Ensuite, vous ajouterez des tests pour vérifier que le service PostgreSQL est en cours d’exécution avec le port, l’adresse, le protocole et l’utilisateur corrects. Vous allez ensuite tester des paramètres de configuration PostgreSQL spécifiques et, enfin, auditer la configuration de l’authentification du client.

Avant de suivre ce tutoriel, vous aurez besoin des éléments suivants:

[[step-1 -—- Preparing-the-Environment]] == Étape 1 - Préparation de l'environnement

Au cours de cette étape, vous allez télécharger et décompresser la dernière version stable d’InSpec dans votre répertoire personnel. InSpec fournit des binaires installables sur leur pagedownloads.

Accédez à votre répertoire personnel:

Maintenant, téléchargez le binaire aveccurl:

Ensuite, utilisez la commandesha256sum pour générer une somme de contrôle du fichier téléchargé. Ceci permet de vérifier l'intégrité et l'authenticité du fichier téléchargé.

Les sommes de contrôle pour chaque binaire sont répertoriées sur lesInSpec downloads page, alors visitez la page des téléchargements pour comparer avec votre sortie de cette commande.

Si les sommes de contrôle sont différentes, supprimez le fichier téléchargé et répétez le processus de téléchargement.

Ensuite, vous installerez le binaire téléchargé. Pour cela, vous utiliserez la commandedpkg que vous pouvez utiliser pour la gestion des paquets, et qui est fournie avec tous les systèmes basés sur Debian, comme Ubuntu, par défaut. L'indicateur-i invite la commande dpkg à installer les fichiers du package.

S'il n'y a pas d'erreur, cela signifie que vous avez installé InSpec avec succès. Pour vérifier l'installation, entrez la commande suivante:

Vous recevrez une sortie indiquant la version d'InSpec que vous venez d'installer:

Si vous ne voyez pas de numéro de version affiché, recommencez l’étape 1.

Après cela, vous pouvez supprimerinspec_3.7.11-1_amd64.deb car vous n'en avez plus besoin car vous avez installé le package:

Vous avez correctement installé InSpec sur votre serveur. Dans l'étape suivante, vous allez écrire un test pour vérifier la famille de système d'exploitation de votre serveur.

[[step-2 -—- completion-your-first-inspec-test]] == Étape 2 - Réalisation de votre premier test InSpec

Au cours de cette étape, vous effectuerez votre premier test InSpec, qui vérifiera que la famille de votre système d’exploitation estdebian.

Vous utiliserez la ressourceos, qui est une ressource d'audit InSpec intégrée pour tester la plate-forme sur laquelle le système s'exécute. Vous utiliserez également le matchereq. Le matchereq est un matcher universel qui teste l'égalité exacte de deux valeurs.

Un test InSpec consiste en un blocdescribe, qui contient une ou plusieurs instructionsit etits dont chacune valide l’une des fonctionnalités de la ressource. Chaque instruction décrit une attente d'une condition spécifique du système enassertions. Deux mots-clés que vous pouvez inclure pour faire une assertion sontshould etshould_not, qui affirment que la condition doit être respectivement vraie et fausse.

Créez un fichier appeléos_family.rb pour organiser votre test et ouvrez-le avec votre éditeur de texte:

Ajoutez ce qui suit dans votre fichier:

os_family.rb

Ce test garantit que la famille de système d'exploitation du système cible estdebian. Les autres valeurs possibles sontwindows,unix,bsd, etc. Vous pouvez trouver une liste complète dans lesos resource documentation. Enregistrez et quittez le fichier.

Ensuite, lancez votre test avec la commande suivante:

Le test réussira et vous recevrez une sortie semblable à celle-ci:

Dans votre sortie, leProfile contient le nom du profil qui vient d'être exécuté. Comme ce test n’est pas inclus dans un profil, InSpec génère un nom de profil par défaut à partir du nom de fichier du testtests from os_family.rb. (Vous travaillerez avec InSpecprofiles dans la section suivante où vous commencerez à créer votre profil PostgreSQL InSpec.) Ici, InSpec présente lesVersion commenot specified, car vous ne pouvez spécifier des versions que dans profils.

Le champTarget spécifie le système cible sur lequel le test est exécuté, qui peut être local ou distant viassh. Dans ce cas, vous avez exécuté votre test sur le système local pour que la cible affichelocal://.

De manière utile, la sortie affiche également le test exécuté avec un symbole en forme de coche (✔) à gauche indiquant que le test a réussi. La sortie affichera un symbole en croix () si le test échoue.

Enfin, le récapitulatif des tests fournit des détails généraux sur le nombre de tests réussis, échoués et ignorés. Dans ce cas, vous avez eu un seul test réussi.

Vous verrez maintenant à quoi ressemble la sortie d’un test ayant échoué. Ouvriros_family.rb:

Dans le test que vous avez créé plus tôt dans cette étape, vous allez maintenant changer la valeur attendue de la famille du système d'exploitation dedebian àwindows. Le contenu de votre fichier après cela sera le suivant:

os_family.rb

Enregistrez et quittez le fichier.

Ensuite, exécutez le test mis à jour avec la commande suivante:

Vous obtiendrez une sortie similaire à celle-ci:

Comme prévu, le test a échoué. La sortie indique que vos valeurs attendues (windows) et réelles (debian) ne correspondent pas à la propriétéos.family. La sortie(compared using ==) indique que le matchereq a effectué une comparaison de chaînes entre les deux valeurs pour obtenir ce résultat.

Dans cette étape, vous avez écrit un test réussi qui vérifie la famille de systèmes d’exploitation du serveur. Vous avez également créé un test ayant échoué afin de voir à quoi ressemble la sortie InSpec d’un test ayant échoué. Dans l'étape suivante, vous allez commencer à créer le profil d'audit pour tester votre installation PostgreSQL.

[[step-3 -—- auditing-your-postgresql-installation]] == Étape 3 - Audit de votre installation PostgreSQL

Maintenant, vous allez auditer votre installation PostgreSQL. Vous commencerez par vérifier que PostgreSQL est installé et que son service fonctionne correctement. Enfin, vous allez auditer le port et les processus du système PostgreSQL. Pour votre audit PostgreSQL, vous allez créer divers contrôles InSpec, tous dans un InSpecprofile nomméPostgreSQL.

Un InSpeccontrol est un regroupement de haut niveau de tests associés. Dans un contrôle, vous pouvez avoir plusieurs blocsdescribe, ainsi que des métadonnées pour décrire vos tests comme le niveau d'impact, le titre, la description et les balises. Les profils InSpec organisent les contrôles pour prendre en charge la gestion des dépendances et la réutilisation du code, ce qui permet de gérer la complexité des tests. Ils sont également utiles pour empaqueter et partager des tests avec le public via lesChef Supermarket. Vous pouvez utiliser des profils pour définir des ressources personnalisées à implémenter en tant que classes Ruby standard.

Pour créer un profil InSpec, vous utiliserez la commandeinit. Entrez cette commande pour créer le profilPostgreSQL:

Cela crée le profil dans un nouveau répertoire avec le même nom que votre profil, dans ce casPostgreSQL. Maintenant, déplacez-vous dans le nouveau répertoire:

La structure du répertoire ressemblera à ceci:

Le fichiercontrols/example.rb contient un exemple de contrôle qui teste si le dossier/tmp existe sur le système cible. Ceci n’est présent qu’à titre d’échantillon et vous le remplacerez par votre propre test.

Votre premier test consistera à vous assurer que le packagepostgresql-10 est installé sur votre système et que le servicepostgresql est installé, activé et en cours d’exécution.

Renommez le fichiercontrols/example.rb encontrols/postgresql.rb:

Ensuite, ouvrez le fichier avec votre éditeur de texte:

Remplacez le contenu du fichier par ce qui suit:

controls/postgresql.rb

Dans le bloc de code précédent, vous commencez par définir le contrôle avec son nom et ses métadonnées.

Dans le premier blocdescribe, vous utilisez la ressourcepackage et passez le nom du package PostgreSQLpostgresql-10 comme argument de ressource. La ressourcepackage fournit le matcherbe_installed pour tester que le package nommé est installé sur le système. Il renvoietrue si le package est installé, etfalse dans le cas contraire. Ensuite, vous avez utilisé l'instructionits pour valider que la version du package PostgreSQL installé est au moins 10. Vous utilisezcmp au lieu deeq car les chaînes de version de package contiennent généralement d'autres attributs en dehors de la version numérique. eq renvoietrue uniquement s'il y a une correspondance exacte alors quecmp est moins restrictif.

Dans le deuxième blocdescribe, vous utilisez la ressourceservice et passez le nom de service PostgreSQL 10postgresql@10-main comme argument de ressource. La ressourceservice fournit les correspondantsbe_enabled,be_installed etbe_running et ils renvoienttrue si le service nommé est installé, activé et exécuté sur le système cible respectivement.

Enregistrez et quittez votre fichier.

Ensuite, vous allez lancer votre profil. Assurez-vous que vous vous trouvez dans le répertoire~/PostgreSQL avant d'exécuter la commande suivante:

Puisque vous avez terminé le tutoriel sur les prérequis pour PostgreSQL, votre test réussira. Votre sortie ressemblera à ce qui suit:

La sortie indique que votre contrôle a réussi. Un contrôle est réussi si, et seulement si, tous les tests qu'il contient ont réussi. La sortie confirme également que tous vos tests ont réussi.

Maintenant que vous avez vérifié que la version correcte de PostgreSQL est installée et que le service fonctionne correctement, vous allez créer un nouveau contrôle garantissant que PostgreSQL écoute sur le port, l'adresse et le protocole corrects.

Pour ce test, vous utiliserez égalementattributes. Un attribut InSpec est utilisé pour paramétrer un profil afin de permettre une réutilisation facile dans différents environnements ou systèmes cibles. Vous allez définir l’attributPORT.

Ouvrez le fichierinspec.yml dans votre éditeur de texte:

Vous allez ajouter l'attributport à la fin du fichier. Ajoutez ce qui suit à la fin de votre fichier:

inspec.yml

Dans le bloc de code précédent, vous avez ajouté l'attributport et le définissez sur une valeur par défaut de5432 car c'est le port que PostgreSQL écoute par défaut.

Enregistrez et quittez le fichier. Ensuite, exécutezinspec check pour vérifier que le profil est toujours valide puisque vous venez de modifierinspec.yml:

S'il n'y a pas d'erreur, vous pouvez continuer. Sinon, ouvrez le fichierinspec.yml et assurez-vous que l'attribut est présent à la fin du fichier.

Vous allez maintenant créer le contrôle qui vérifie que le processus PostgreSQL est en cours d’exécution et configuré avec le bon utilisateur. Ouvrezcontrols/postgresql.rb dans votre éditeur de texte:

Ajoutez le contrôle suivant à la fin de votre fichier de tests actuelcontrols/postgresql.rb:

controls/postgresql.rb

Ici, vous commencez par déclarer une variablePORT pour contenir la valeur de l'attribut de profilport. Ensuite, vous déclarez le contrôle et ses métadonnées.

Dans le premier blocdescribe, vous incluez la ressourceport pour tester les propriétés de base du port. La ressourceport fournit les correspondantsbe_listening,addresses etprotocols. Vous utilisez le matcherbe_listening pour tester que le port nommé écoute sur le système cible. Il renvoietrue si le port5432 écoute et renvoiefalse dans le cas contraire. Le matcheraddresses teste si l'adresse spécifiée est associée au port. Dans ce cas, PostgreSQL écoutera sur l'adresse locale,127.0.0.1.
Le matcherprotocols teste le protocole Internet que le port écoute, qui peut êtreicmp, tcp /tcp6 ouudp /udp6. PostgreSQL écoutera les connexions detcp.

Dans le deuxième blocdescribe, vous incluez la ressourceprocesses. Vous utilisez la ressourceprocesses pour tester les propriétés des programmes en cours d'exécution sur le système. Tout d'abord, vous vérifiez que le processuspostgres existe sur le système, puis vous utilisez le matcherusers pour tester que l'utilisateurpostgres possède le processuspostgres.

Dans le troisième blocdescribe, vous avez la ressourceuser. Vous incluez la ressourceuser pour tester les propriétés de l'utilisateur pour un utilisateur, par exemple si l'utilisateur existe ou non, le groupe auquel l'utilisateur appartient, etc. À l'aide de cette ressource, vous testez que l'utilisateurpostgres existe sur le système. Enregistrez et quittezcontrols/postgresql.rb.

Ensuite, lancez votre profil avec la commande suivante:

Les tests réussiront et votre sortie ressemblera à ceci:

La sortie indique que vos deux contrôles et tous vos tests ont réussi.

Dans cette section, vous avez créé votre premier profil et contrôle InSpec et les avez utilisés pour organiser vos tests. Vous avez utilisé plusieurs ressources InSpec pour vous assurer que la version correcte de PostgreSQL est installée, que le service PostgreSQL est activé et qu'il fonctionne correctement et que l'utilisateur PostgreSQL existe sur le système. Avec cette configuration, vous êtes prêt à auditer votre configuration.

[[step-4 -—- auditing-your-postgresql-configuration]] == Étape 4 - Audit de votre configuration PostgreSQL

Dans cette étape, vous allez auditer certaines valeurs de configuration PostgreSQL, ce qui vous donnera une base pour utiliser ces fichiers de configuration, vous permettant d’auditer comme vous le souhaitez tous les paramètres de configuration PostgreSQL.

Maintenant que vous avez des tests d’audit de l’installation de PostgreSQL, vous allez auditer votre configuration PostgreSQL elle-même. PostgreSQL a plusieurs paramètres de configuration que vous pouvez utiliser pour l'ajuster comme vous le souhaitez, et ceux-ci sont stockés dans le fichier de configuration situé par défaut à/etc/postgresql/10/main/postgresql.conf. Vous pouvez avoir des exigences différentes concernant la configuration PostgreSQL pour vos différents déploiements tels que la journalisation, le cryptage des mots de passe, SSL et les stratégies de réplication - ces exigences que vous spécifiez dans le fichier de configuration.

Vous utiliserez la ressourcepostgres_conf qui teste des options de configuration nommées spécifiques par rapport aux valeurs attendues dans le contenu du fichier de configuration PostgreSQL.

Ce test suppose certaines valeurs de configuration PostgreSQL non définies par défaut que vous définissez manuellement.

Ouvrez le fichier de configuration PostgreSQL dans votre éditeur de texte préféré:

Définissez les valeurs de configuration suivantes. Si l'option existe déjà dans le fichier mais est commentée, supprimez-la de commentaire en supprimant les# et définissez la valeur comme indiqué:

/etc/postgresql/10/main/postgresql.conf

Les valeurs de configuration que vous avez définies:

Enregistrez et quittez le fichier de configuration. Puis redémarrez le service PostgreSQL:

Vous ne testerez que quelques options de configuration, mais vous pouvez tester n'importe quelle option de configuration PostgreSQL avec la ressourcepostgres_conf.

Vous passerez dans votre répertoire de configuration PostgreSQL, qui est à/etc/postgresql/10/main, en utilisant un nouvel attribut de profil,postgres_conf_dir. Ce répertoire de configuration n’est pas le même sur tous les systèmes d’exploitation et toutes les plateformes. Par conséquent, en le transmettant en tant qu’attribut de profil, vous faciliterez la réutilisation de ce profil dans différents environnements.

Ouvrez votre fichierinspec.yml:

Ajoutez ce nouvel attribut à la sectionattributes deinspec.yml:

inspec.yml

Enregistrez et quittez votre fichier. Exécutez ensuite la commande suivante pour vérifier que le profil InSpec est toujours valide car vous venez de modifier lesinspec.yml:

S'il n'y a pas d'erreur, vous pouvez continuer. Sinon, ouvrez le fichierinspec.yml et assurez-vous que les lignes ci-dessus sont présentes à la fin du fichier.

Vous allez maintenant créer le contrôle qui vérifie les valeurs de configuration que vous appliquez. Ajoutez le contrôle suivant à la fin du fichier de testscontrols/postgresql.rb:

controls/postgresql.rb

Ici vous définissez deux variables:

Ensuite, vous définissez le contrôle avec son nom et ses métadonnées. Ensuite, vous utilisez la ressourcepostgres_conf avec le matchereq pour vous assurer que les valeurs requises pour les options de configuration sont correctes. Enregistrez et quittezcontrols/postgresql.rb.

Ensuite, vous allez exécuter le test avec la commande suivante:

Les tests réussiront et vos résultats ressembleront à ce qui suit:

La sortie indique que vos trois contrôles et tous vos tests ont réussi sans tests ni contrôles ignorés.

Dans cette étape, vous avez ajouté un nouveau contrôle InSpec qui teste des valeurs de configuration PostgreSQL spécifiques à partir du fichier de configuration à l'aide de la ressourcepostgres_conf. Vous avez audité quelques valeurs dans cette section, mais vous pouvez l’utiliser pour tester toute option de configuration à partir du fichier de configuration.

[[step-5 -—- auditing-postgresql-client-authentication]] == Étape 5 - Audit de l'authentification du client PostgreSQL

Maintenant que vous avez écrit des tests pour votre configuration PostgreSQL, vous allez écrire des tests pour l’authentification du client. Ceci est important pour les installations qui doivent garantir des méthodes d'authentification spécifiques pour différents types d'utilisateurs. Par exemple, pour garantir que les clients qui se connectent à PostgreSQL localement doivent toujours s'authentifier avec un mot de passe ou refuser les connexions à partir d'une adresse IP ou d'une plage d'adresses IP spécifique, etc.

Une configuration importante pour les installations PostgreSQL où la sécurité est un problème est d'autoriser uniquement les authentifications cryptées de mot de passe. PostgreSQL 10supports two password encryption methods pour l'authentification client:md5 etscram-sha-256. Ce test nécessitera le cryptage du mot de passe pour tous les clients, ce qui signifie que le champMETHOD pour tous les clients dans le fichier de configuration client doit être défini surmd5 ouscram-sha-256. Pour ces tests, vous utiliserezscram-sha-256 car il est plus sécurisé quemd5.

Par défaut, les clientslocal ont leur méthode d'authentificationpeer dans le fichierpg_hba.conf. Pour le test, vous devez les changer enscram-sha-256. Ouvrez le fichier/etc/postgresql/10/main/pg_hba.conf:

Le haut du fichier contient des commentaires. Faites défiler vers le bas et recherchez les lignes non commentées où le type d'authentification estlocal, et changez la méthode d'authentification depeer àscram-sha-256. Par exemple, changez:

/etc/postgresql/10/main/pg_hba.conf

to:

/etc/postgresql/10/main/pg_hba.conf

À la fin, la configuration de votrepg_hba.conf ressemblera à ce qui suit:

/etc/postgresql/10/main/pg_hba.conf

Enregistrez et quittez le fichier de configuration. Puis redémarrez le service PostgreSQL:

Pour ce test, vous utiliserez la ressourcepostgres_hba_conf. Cette ressource est utilisée pour tester les données d'authentification client définies dans le fichierpg_hba.conf. Vous passerez le chemin de votre fichierpg_hba.conf comme paramètre à cette ressource.

Votre contrôle sera composé de deux blocsdescribe qui vérifient les champsauth_method pour les clientslocal ethost respectivement pour s'assurer qu'ils sont tous deux égaux àscram-sha-256. Ouvrezcontrols/postgresql.rb dans votre éditeur de texte:

Ajoutez le contrôle suivant à la fin du fichier de testcontrols/postgresql.rb:

controls/postgresql.rb

Dans ce bloc de code, vous définissez une nouvelle variablePOSTGRES_HBA_CONF_FILE pour stocker l'emplacement absolu de votre fichierpg_hba.conf. File.join est une méthode Ruby pour concaténer deux segments de chemin de fichier avec/. Vous l'utilisez ici pour joindre la variablePOSTGRES_CONF_DIR, déclarée dans la section précédente, avec le fichier de configuration PostgreSQLpg_hba.conf. Cela produira un chemin de fichier absolu du fichierpg_hba.conf et le stockera dans la variablePOSTGRES_HBA_CONF_FILE.

Ensuite, vous déclarez et configurez le contrôle et ses métadonnées. Le premier blocdescribe vérifie que toutes les entrées de configuration où le type de client estlocal ont égalementscram-sha-256 comme méthodes d'authentification. Le deuxième blocdescribe fait de même pour les cas où le type de client esthost. Enregistrez et quittezcontrols/postgresql.rb.

Vous exécuterez ce contrôle en tant qu'utilisateurpostgres car l'accès deReadà la configuration de PostgreSQL HBA n'est accordé qu'au propriétaire et au groupe, qui est l'utilisateur depostgres. Exécutez le profil en lançant:

Votre sortie ressemblera à ceci:

Cette sortie indique que le nouveau contrôle que vous avez ajouté, ainsi que tous les contrôles précédents, ont réussi. Il indique également que tous les tests de votre profil ont réussi.

Dans cette étape, vous avez ajouté un contrôle à votre profil qui a audité avec succès votre configuration d'authentification client PostgreSQL pour vous assurer que tous les clients sont authentifiés viascram-sha-256 en utilisant la ressourcepostgres_hba_conf.

Vous avez configuré InSpec et audité avec succès une installation de PostgreSQL 10. Au cours de ce processus, vous avez utilisé une sélection d’outils InSpec, tels que: le DSL InSpec, les correspondants, les ressources, les profils, les attributs et la CLI. De là, vous pouvez incorporer d'autres ressources fournies par InSpec dans lesResources section de leur documentation. InSpec fournit également un mécanisme pour définir lescustom resources pour vos besoins spécifiques. Ces ressources personnalisées sont écrites comme une classe Ruby standard.

Vous pouvez également explorer la sectionCompliance Profiles desChef supermarket qui contient des profils InSpec partagés publiquement que vous pouvez exécuter directement ou étendre dans vos propres profils. Vous pouvez également partager vos propres profils avec le grand public dans le supermarché Chef.

Vous pouvez aller plus loin en explorant d'autres outils de l'univers Chef tels queChef etHabitat. InSpec is integrated with Habitat et cela offre la possibilité d'expédier vos contrôles de conformité avec vos applications packagées Habitat et de les exécuter en continu. Vous pouvez explorer les didacticiels InSpec officiels et communautaires sur la pagetutorials. Pour des références InSpec plus avancées, consultez lesInSpec documentation officiels.