Analyser un hôte Linux par rapport à une référence de sécurité avec OpenSCAP

Objectif

Évaluer un hôte Linux par rapport à un profil de sécurité publié à l'aide d'OpenSCAP, et produire un rapport indiquant précisément quelles vérifications réussissent, échouent ou ne s'appliquent pas.

Prérequis

Des privilèges root (une analyse sans root ne peut pas lire bon nombre des fichiers et paramètres contrôlés par les règles). Sur les systèmes de la famille RHEL, le paquet openscap-scanner fournit oscap et scap-security-guide fournit le contenu, c'est-à-dire un fichier data-stream tel que /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml (ssg-rhel8-ds.xml, ssg-rhel10-ds.xml pour d'autres versions ; listez le répertoire plutôt que de deviner le nom). Les autres distributions empaquettent ce contenu sous des noms différents, voire pas du tout. Le projet s'appelait à l'origine SCAP Security Guide (SSG) et livre un fichier data-stream par produit pris en charge.

Étapes

1. Lister les profils disponibles dans un fichier data-stream : oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. Chaque profil possède un identifiant, par exemple xccdf_org.ssgproject.content_profile_cis ; les profils disponibles (niveaux CIS, STIG, OSPP, etc.) dépendent de la version du contenu, donc copiez l'identifiant depuis cette sortie.
2. Lancer une évaluation avec le profil choisi, en écrivant à la fois un fichier de résultats exploitable par machine et un rapport HTML : oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --results-arf arf.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. Le manuel de oscap documente précisément cette forme xccdf eval --profile PROFILE_ID ... --report REPORT_FILE. Dans les scripts, notez que oscap renvoie le code 2 lorsque l'analyse s'est terminée mais qu'au moins une règle a échoué, et le code 1 en cas d'erreur réelle ; ne considérez pas tout code de sortie non nul comme une analyse défaillante.
3. Ouvrir report.html (ou le copier hors de l'hôte) et lire, règle par règle, les compteurs pass/fail/notapplicable avant de modifier quoi que ce soit.
4. Un script de remédiation peut être généré à partir des résultats avec oscap xccdf generate fix --fix-type bash --output fix.sh --result-id <id> arf.xml (ou --fix-type ansible) ; lisez chaque commande qu'il contient : c'est un point de départ, pas un script à envoyer directement dans un shell. Évitez oscap xccdf eval --remediate sur les hôtes de production : cette option applique pendant l'analyse toutes les corrections du profil.
5. N'appliquer que les remédiations relues et acceptées, puis relancer la même commande oscap xccdf eval pour confirmer que les règles concernées passent désormais.
6. Conserver la paire arf.xml/report.html datée comme trace d'audit pour cet hôte et cette version du profil.

Résultat attendu

Un rapport listant chaque règle du profil choisi avec un statut pass/fail/notapplicable/error, reproductible en relançant la même commande avec le même fichier data-stream.

Limites et base de vérification

oscap indique l'état d'un système au regard des vérifications d'un profil ; il ne garantit pas que ces vérifications conviennent à une charge de travail donnée : relisez avant de remédier (voir l'article sur les références CIS/STIG). Aucune de ces opérations n'est annulable par une seule commande : sauvegardez tout fichier de configuration que oscap ou sa remédiation modifie avant de l'exécuter, comme pour toute autre modification manuelle. Aucun redémarrage n'est nécessaire pour lancer une analyse ; une étape de remédiation peut en exiger un selon ce qu'elle modifie.