Introduction
L'automatisation de la sécurité se concentre souvent sur les comptes, la propriété, les permissions et les preuves. Un bon playbook applique ces paramètres sans affaiblir l'accès de l'utilisateur de gestion.
Dans ce laboratoire, vous allez créer un compte système verrouillé, déployer des fichiers de politique de sécurité appartenant à root, collecter des preuves sur le mode SELinux et prouver que le playbook est idempotent.
Créer un projet d'automatisation de la sécurité
Dans cette étape, vous allez créer un projet pour une base de référence de sécurité sécurisée qui évite de modifier l'accès SSH ou sudo de LabEx.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory,playbooks,reports}
cd rhce-ansible
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
EOF
cat > inventory/hosts <<'EOF'
[managed]
host ansible_connection=local
EOF
Ce laboratoire évite délibérément de modifier le compte labex, le service SSH ou l'accès sudo. Le compte géré et les fichiers de politique sont des cibles d'entraînement isolées.
Définir les variables de la base de référence de sécurité
Dans cette étape, vous allez définir le compte, le répertoire et le fichier de politique que le playbook devra gérer. Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible. Cela garantit la stabilité des commandes, même si LabEx exécute chaque étape séparément.
cd /home/labex/project/rhce-ansible
mkdir -p inventory/group_vars
cat > inventory/group_vars/managed.yml <<'EOF'
audit_user: rhce_audit
security_dir: /etc/rhce-security
security_policy: /etc/rhce-security/policy.conf
EOF
Les variables nomment le compte de service et le chemin de la politique appartenant à root. Les conserver dans des variables rend la base de référence de sécurité plus facile à auditer avant qu'elle ne modifie l'état du système.
cat inventory/group_vars/managed.yml
Rédiger le playbook de la base de référence de sécurité
Dans cette étape, vous allez rédiger un playbook qui crée un compte système verrouillé, un répertoire appartenant à root, un fichier de politique en mode 0600 et un rapport de preuves dans l'espace de travail.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet Ansible.
cd /home/labex/project/rhce-ansible
cat > playbooks/security-baseline.yml <<'EOF'
---
- name: Apply safe security baseline
hosts: managed
become: true
gather_facts: true
tasks:
- name: Ensure locked audit service account exists
ansible.builtin.user:
name: "{{ audit_user }}"
system: true
shell: /sbin/nologin
create_home: false
password_lock: true
state: present
- name: Ensure root-owned security directory exists
ansible.builtin.file:
path: "{{ security_dir }}"
state: directory
owner: root
group: root
mode: '0750'
- name: Deploy root-only security policy
ansible.builtin.copy:
dest: "{{ security_policy }}"
owner: root
group: root
mode: '0600'
content: |
managed_by=ansible
selinux_status={{ ansible_selinux.status | default('unknown') }}
- name: Check current SELinux mode
ansible.builtin.command: getenforce
register: selinux_mode
changed_when: false
failed_when: false
- name: Write learner-readable security report
ansible.builtin.copy:
dest: /home/labex/project/rhce-ansible/reports/security-report.txt
owner: labex
group: labex
mode: '0640'
content: |
audit_user={{ audit_user }}
policy_mode=0600
selinux_mode={{ selinux_mode.stdout | default('unknown') }}
EOF
Le playbook combine application des règles et collecte de preuves. Il crée un compte système verrouillé, écrit des fichiers de politique accessibles uniquement par root, lit le mode SELinux sans marquer la tâche comme modifiée, et écrit un rapport lisible par l'apprenant dans le projet.
ansible-playbook playbooks/security-baseline.yml --syntax-check
Vérifiez les valeurs sensibles à la sécurité avant l'exécution : shell: /sbin/nologin, password_lock: true, la propriété root et le mode 0600 sur le fichier de politique.
Exécuter et inspecter la base de référence de sécurité
Dans cette étape, vous allez appliquer la base de référence et inspecter le compte, les permissions des fichiers et le rapport de preuves.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-first.txt
La première exécution doit créer le compte et le répertoire de politique. Les vérifications ci-dessous confirment directement l'état du système au lieu de se fier uniquement à la sortie du playbook.
getent passwd rhce_audit
L'entrée du compte doit se terminer par /sbin/nologin, indiquant qu'il n'est pas destiné à un accès shell interactif.
sudo stat -c "%U:%G %a %n" /etc/rhce-security /etc/rhce-security/policy.conf
Le fichier de politique doit appartenir à root:root et utiliser le mode 600, ce qui est approprié pour un contenu de politique réservé à root.
cat reports/security-report.txt
Le rapport enregistre le compte géré, le mode de politique attendu et le mode SELinux observé pour une révision rapide.
Confirmer l'idempotence de la base de référence de sécurité
Dans cette étape, vous allez exécuter à nouveau la base de référence de sécurité. L'état sécurisé existant ne devrait nécessiter aucune modification supplémentaire.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-second.txt
La deuxième exécution vérifie que la base de référence de sécurité converge. Si elle signale à nouveau des changements, inspectez quelle tâche a été modifiée, car cela signifie qu'un état souhaité n'était pas stable.
grep -E 'host.*changed=0' reports/security-second.txt
Résumé
Vous avez automatisé la création d'un compte de service verrouillé, de fichiers de politique de sécurité appartenant à root, la collecte de preuves SELinux et la validation de l'idempotence, sans modifier le chemin d'accès LabEx.
