Einführung
Bei der Sicherheitsautomatisierung stehen häufig Benutzerkonten, Dateibesitz, Berechtigungen und die Dokumentation von Nachweisen im Mittelpunkt. Ein gut durchdachtes Playbook wendet diese Einstellungen an, ohne den Zugriff für den Administrator zu beeinträchtigen.
In diesem Lab erstellen Sie ein gesperrtes Systemkonto, stellen Sicherheitsrichtliniendateien im Besitz von root bereit, sammeln Nachweise über den SELinux-Modus und belegen die Idempotenz Ihres Playbooks.
Ein Projekt für die Sicherheitsautomatisierung erstellen
In diesem Schritt erstellen Sie ein Projekt für eine sichere Basis-Konfiguration (Security Baseline), bei der der SSH- oder sudo-Zugriff von LabEx nicht verändert wird.
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
Dieses Lab vermeidet bewusst Änderungen am labex-Konto, dem SSH-Dienst oder dem sudo-Zugriff. Das verwaltete Konto und die Richtliniendateien dienen lediglich als isolierte Übungsziele.
Variablen für die Sicherheits-Baseline definieren
In diesem Schritt definieren Sie das Konto, das Verzeichnis und die Richtliniendatei, die vom Playbook verwaltet werden sollen. Bevor Sie die Befehle in diesem Schritt ausführen, kehren Sie in das Ansible-Projektverzeichnis zurück. Dies stellt sicher, dass die Befehle auch dann stabil funktionieren, wenn LabEx die Schritte einzeln ausführt.
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
Die Variablen benennen das Dienstkonto und den Pfad zur Richtliniendatei im Besitz von root. Durch die Verwendung von Variablen lässt sich die Sicherheits-Baseline leichter überprüfen, bevor sie den Systemzustand ändert.
cat inventory/group_vars/managed.yml
Das Playbook für die Sicherheits-Baseline schreiben
In diesem Schritt schreiben Sie ein Playbook, das ein gesperrtes Systemkonto, ein Verzeichnis im Besitz von root, eine Richtliniendatei mit dem Modus 0600 sowie einen Arbeitsbereichsbericht erstellt.
Bevor Sie die Befehle in diesem Schritt ausführen, kehren Sie in das Ansible-Projektverzeichnis zurück.
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
Das Playbook kombiniert Durchsetzung und Nachweisführung. Es erstellt ein gesperrtes Systemkonto, schreibt Richtliniendateien, auf die nur root zugreifen kann, liest den SELinux-Modus aus (ohne die Aufgabe als "geändert" zu markieren) und schreibt einen für den Lernenden lesbaren Bericht in das Projektverzeichnis.
ansible-playbook playbooks/security-baseline.yml --syntax-check
Überprüfen Sie die sicherheitsrelevanten Werte vor der Ausführung: shell: /sbin/nologin, password_lock: true, den Besitz durch root und den Modus 0600 für die Richtliniendatei.
Die Sicherheits-Baseline ausführen und überprüfen
In diesem Schritt wenden Sie die Baseline an und überprüfen das Konto, die Dateiberechtigungen sowie den Nachweisbericht.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-first.txt
Der erste Durchlauf sollte das Konto und das Richtlinienverzeichnis erstellen. Die folgenden Prüfungen bestätigen den Systemzustand direkt, anstatt sich nur auf die Ausgabe des Playbooks zu verlassen.
getent passwd rhce_audit
Der Kontoeintrag sollte mit /sbin/nologin enden, was darauf hinweist, dass es nicht für interaktive Shell-Zugriffe vorgesehen ist.
sudo stat -c "%U:%G %a %n" /etc/rhce-security /etc/rhce-security/policy.conf
Die Richtliniendatei sollte sich im Besitz von root:root befinden und den Modus 600 aufweisen, was für Richtlinieninhalte, die nur für root bestimmt sind, angemessen ist.
cat reports/security-report.txt
Der Bericht protokolliert das verwaltete Konto, den erwarteten Richtlinienmodus und den beobachteten SELinux-Modus zur schnellen Überprüfung.
Idempotenz der Sicherheits-Baseline bestätigen
In diesem Schritt führen Sie die Sicherheits-Baseline erneut aus. Der bereits bestehende sichere Zustand sollte keine weiteren Änderungen erfordern.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-second.txt
Der zweite Durchlauf bestätigt, dass die Sicherheits-Baseline konvergiert. Sollten erneut Änderungen gemeldet werden, untersuchen Sie, welche Aufgabe diese ausgelöst hat, da dies bedeutet, dass ein gewünschter Zustand nicht stabil erreicht wurde.
grep -E 'host.*changed=0' reports/security-second.txt
Zusammenfassung
Sie haben die Erstellung eines gesperrten Dienstkontos, von Sicherheitsrichtliniendateien im Besitz von root, die Erfassung von SELinux-Nachweisen sowie die Validierung der Idempotenz automatisiert, ohne dabei den Zugriffspfad von LabEx zu verändern.
