HarryHarcourt.ansible_rhel8_cis_benchmarks

HarryHarcourt.Ansible-RHEL8-CIS-Benchmarks

Tous les crédits vont à anthcourtney pour le cadre original trouvé ici : https://github.com/anthcourtney/ansible-role-cis-amazon-linux

Cette implémentation a été convertie pour Red Hat Enterprise Linux 8.X et CentOS 8.X (note : pas encore testée).

Cette implémentation a été rendue idempotente à plusieurs endroits et continue de l'être.

Cette implémentation permet d'activer et de configurer certains services.

Le benchmark CIS pour Linux RHEL. https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v2.1.1.pdf

Ce rôle a été développé et testé sur Red Hat Linux 8.0 en utilisant l'AMI AWS : ami-079596bf7a949ddf8

Pourquoi utiliser ce rôle ?

Si vous essayez d'obtenir la conformité avec une norme de sécurité acceptée par le secteur, comme PCI DSS, APRA ou ISO 27001, alors vous devez prouver que vous avez appliqué des normes de sécurisation documentées à tous les systèmes concernés.

Si vous utilisez Red Hat Linux, ce rôle tente de fournir une partie de la solution au puzzle de la conformité.

Attention !

Si vous envisagez d'appliquer ce rôle à n'importe quel serveur, vous devriez avoir une connaissance de base du benchmark CIS (ou d'autres benchmarks similaires) et comprendre l'impact que cela peut avoir sur un système.

Veuillez prendre le temps de vous familiariser avec la norme et les valeurs par défaut configurables, et exclure tout élément avant de l'appliquer à un système.

Voici quelques exemples d'éléments qui devraient être considérés pour exclusion (ou au moins, pour modification des valeurs par défaut associées) :

3.4.2 et 3.4.3, qui, par défaut, limitent effectivement l'accès à l'hôte (y compris via ssh) à localhost uniquement.

Exemple de Playbook

Un exemple de playbook utilisant ce rôle est le suivant :

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  roles:
    - Ansible-RHEL8-CIS-Benchmarks

Un exemple plus avancé, incluant des modifications aux valeurs par défaut et l'exclusion de certains éléments dans le benchmark jugés inutiles pour un environnement fictif, est le suivant :

---

- hosts: localhost
  connection: local
  gather_facts: true
  become: yes

  vars:
    cis_level_1_exclusions:
      - 5.4.4
      - 3.4.2
      - 3.4.3
      - 6.2.13   
    cis_pass_max_days: 45
    cis_umask_default: 002
 
  roles:
    - Ansible-RHEL8-CIS-Benchmarks

Notez que l'utilisation de become: yes est requise car 99 % des tâches nécessitent un accès privilégié pour s'exécuter.

Variables de Rôle

Consultez defaults/main.yml pour les variables qui peuvent être remplacées selon vos préférences.

Options

Des balises (et combinaisons de balises) peuvent être utilisées pour exécuter un niveau particulier de la norme CIS, une section ou une recommandation individuelle. Par exemple :

Exécuter uniquement les tâches Niveau 1

ansible-playbook playbook.yml -t level-1

Exécuter uniquement les tâches de la Section 3

ansible-playbook playbook.yml -t section-3

Exécuter uniquement les tâches 1.3.1 et 2.2.10

ansible-playbook playbook.yml -t 1.3.1,2.2.10

Exécuter uniquement les tâches notées

ansible-playbook playbook.yml -t scored

Limitations

Pour l'instant, seuls les éléments de Niveau 1 du benchmark sont implémentés. Les éléments de Niveau 2 seront ajoutés à mesure que le temps le permettra.

Les vérifications suivantes n'ont pas été implémentées :

3.6.2. Les règles de pare-feu sont spécifiques à l'environnement.
3.6.3. Les règles de pare-feu sont spécifiques à l'environnement.
3.6.4. Les règles de pare-feu sont spécifiques à l'environnement.
3.6.5. Les règles de pare-feu sont spécifiques à l'environnement.
4.2.1.2. La détermination de ce qui doit être enregistré et la destination des messages est spécifique à l'environnement.
4.2.2.2. La détermination de ce qui doit être enregistré et la destination des messages est spécifique à l'environnement.
4.2.2.3. L'édition en ligne du fichier de configuration de syslog-ng est considérée comme trop imprécise et est mieux réalisée par un fichier de configuration fourni qui répond à cette exigence et à d'autres exigences connexes.
4.2.2.4. L'édition en ligne du fichier de configuration de syslog-ng est considérée comme trop imprécise et est mieux réalisée par un fichier de configuration fourni qui répond à cette exigence et à d'autres exigences connexes.
4.2.2.5. L'édition en ligne du fichier de configuration de syslog-ng est considérée comme trop imprécise et est mieux réalisée par un fichier de configuration fourni qui répond à cette exigence et à d'autres exigences connexes.
4.3. La configuration de logrotate est spécifique au site.
5.3.2. L'édition multi-lignes des fichiers de configuration pam est considérée comme trop imprécise et dangereuse, et est mieux réalisée par un fichier de configuration fourni qui répond à cette exigence et à d'autres exigences connexes.
5.3.3. L'édition multi-lignes des fichiers de configuration pam est considérée comme trop imprécise et dangereuse, et est mieux réalisée par un fichier de configuration fourni qui répond à cette exigence et à d'autres exigences connexes.

Compatibilité

Ce rôle est compatible avec les versions suivantes d'ansible :

2.0.2
2.1.3
2.2.0
2.3.0

Ce rôle n'a pas été testé avec d'autres versions d'ansible.

Tests

Les processus de test suivants sont appliqués par le développeur de ce rôle :

La syntaxe du rôle est vérifiée. Voir make syntax.
ansible-review est exécuté contre le rôle et tous les avertissements jugés appropriés sont corrigés. Voir make review.
Le rôle est appliqué sur un conteneur docker en utilisant à la fois ansible v2.1.3 et ansible v2.2. voir make test.

Les tests suivants ont été signalés mais ne sont pas encore implémentés :