ssh-jumphost/ansible/roles/os_hardening/CIS_STIG_MAPPING.md

CIS/STIG-Mapping der os_hardening-Rolle

Diese Rolle deckt eine bewusst ausgewählte, für einen dedizierten Jumphost (Debian/Ubuntu-Familie) relevante Teilmenge der CIS Debian/Ubuntu Linux Benchmarks sowie einzelner DISA-STIG-typischer Controls ab. Sie ist kein vollständiger, zertifizierter Benchmark-Lauf — dafür fehlt ein automatisiertes Compliance-Scanning-Tool. Empfehlung: nach dem Rollout zusätzlich mit oscap xccdf eval (OpenSCAP) gegen das jeweils zutreffende Profil prüfen und diese Tabelle bei Abweichungen als Startpunkt für die Nacharbeit nutzen.

Referenz-Control-IDs folgen der CIS-Nummerierung sinngemäß (Benchmark-Version kann je nach Debian/Ubuntu-Release leicht abweichen); wo passend ist zusätzlich vermerkt, wenn ein Control STIG-typisch, aber nicht CIS-nummeriert ist.

Bereich	CIS-Control (sinngemäß)	Umsetzung	Status
Unsichere Legacy-Dienste	2.1.x	tasks/packages.yml	Implementiert
Automatische Sicherheitsupdates	1.9	tasks/packages.yml	Implementiert
Deaktivierung seltener Dateisystemtreiber	1.1.1.1–1.1.1.8	tasks/kernel_modules.yml	Implementiert
Deaktivierung seltener Netzwerkprotokolle	3.4.1–3.4.4	tasks/kernel_modules.yml	Implementiert
USB-Speichermedien deaktivieren	1.1.23	tasks/kernel_modules.yml	Implementiert
Netzwerk-/Kernel-sysctl-Härtung	3.x, 1.5.x	tasks/sysctl.yml	Implementiert
Core Dumps deaktivieren	1.5.1	tasks/sysctl.yml	Implementiert
/tmp, /dev/shm mit noexec/nosuid/nodev	1.1.2.x	tasks/mounts.yml	Best-Effort — nur wirksam, wenn bereits eigene Mountpoints existieren (siehe unten)
Passwortqualität (Länge/Komplexität)	5.4.1	tasks/pam_password_policy.yml	Implementiert (lokale OS-Konten)
Account-Lockout (pam_faillock)	5.3.1	tasks/pam_password_policy.yml	Implementiert, siehe Einschränkung unten
Passwort-Historie	5.4.2	tasks/pam_password_policy.yml	Implementiert
Passwort-Ablauf (login.defs)	5.4.1.1–5.4.1.4	tasks/pam_password_policy.yml	Implementiert
Erweiterte auditd-Regeln (Identität, Zeit, Netzwerk, Logins, Kernelmodule)	4.1.3–4.1.14	tasks/auditd.yml	Implementiert
auditd-Log-Handling (keep_logs, space_left_action)	4.1.2.3, 4.1.2.4	tasks/auditd.yml	Implementiert
auditd unveränderlich (-e 2)	4.1.1.4 (STIG)	tasks/auditd.yml	Implementiert, standardmäßig deaktiviert (Opt-in os_hardening_auditd_immutable, da Reboot zum Ändern nötig)
Datei-Integritäts-Monitoring (AIDE)	1.4.1, 1.4.2	tasks/aide.yml	Implementiert
Rootkit-Scanner (rkhunter, ergänzend)	STIG-typisch, nicht CIS-nummeriert	tasks/rootkit_scan.yml	Implementiert
Anmelde-Banner	STIG-typisch (Legal Notice)	tasks/banners.yml, tasks/sshd.yml	Implementiert
cron/at auf autorisierte Nutzer beschränken	2.4.1.x	tasks/cron_at.yml	Implementiert
Berechtigungen kritischer Dateien (/etc/shadow etc.)	6.1.x	tasks/file_permissions.yml	Implementiert
sudo-Logging (log_input, log_output, use_pty)	STIG-typisch	tasks/file_permissions.yml	Implementiert
su auf Gruppe sudo beschränken	5.6	tasks/file_permissions.yml	Implementiert
SSH-Daemon-Härtung (Ciphers/KEX/MACs, kein Root-Login, etc.)	5.2.x	tasks/sshd.yml	Implementiert
IPv6 deaktivieren	3.1.1	tasks/sysctl.yml	Implementiert, Opt-in (os_hardening_disable_ipv6, Default aus)

Bewusst nicht automatisiert (mit Begründung)

Bereich	CIS-Control (sinngemäß)	Warum nicht automatisiert
Getrenntes Partitionslayout (/tmp, /var, /var/log, /var/log/audit, /home als eigene Partitionen)	1.1.1–1.1.1.30	Erfordert eine Neupartitionierung der Festplatte — nur zum Zeitpunkt der OS-Installation sinnvoll setzbar, nicht nachträglich per Ansible auf ein laufendes System ohne Datenverlustrisiko. Empfehlung: beim Erstellen des Basis-Images/der VM-Vorlage bereits mit diesem Layout provisionieren.
Bootloader-Passwort (GRUB)	1.4.1 (ältere CIS-Nummerierung)	Erfordert physischen/Konsolen-Zugriff zum Testen und ist bei Cloud-/Hypervisor-Images oft irrelevant oder sogar kontraproduktiv (verhindert automatisierten Neustart). Bewusst dem jeweiligen Betreiber überlassen.
Volltext-Festplattenverschlüsselung	Nicht CIS-nummeriert, STIG-typisch	Muss bei der OS-Installation eingerichtet werden (LUKS o.ä.), nicht nachträglich per Ansible. In Cloud-Umgebungen häufig durch Provider-seitige Verschlüsselung (z.B. verschlüsselte Volumes) abgedeckt — separat prüfen.
Physische Sicherheit / BIOS-UEFI-Passwort	Nicht CIS-nummeriert	Außerhalb der Reichweite von Ansible; organisatorische/physische Maßnahme.
Zentrales Log-Forwarding an SIEM/Syslog-Server	Nicht CIS-nummeriert, aber im Jumphost-Konzept Kap. 6.9 gefordert	Erfordert Kenntnis der Ziel-SIEM-Infrastruktur (Empfänger-Host, Protokoll, TLS-Zertifikate) — als eigener Konfigurationspunkt vorgesehen, aber nicht Teil dieser Rolle (siehe Konzept Kap. 6.9, Erweiterungspunkt).
Netzwerksegmentierung / Firewalling zwischen Zielsystemen	Außerhalb des Jumphost-Scopes	Betrifft die Netzwerkinfrastruktur rund um den Jumphost, nicht den Jumphost selbst — Bestandteil des übergeordneten Netzwerkkonzepts.

Bekannte Einschränkungen

• pam_faillock-Einbindung (tasks/pam_password_policy.yml) fügt einen Block direkt in /etc/pam.d/common-auth ein. Auf Systemen, die pam-auth-update --force als Teil eines anderen Automatisierungsschritts laufen lassen, kann dieser Block überschrieben werden. Für produktive Systeme mit häufigen PAM-Änderungen wird empfohlen, stattdessen ein eigenes pam-auth-update-Profil unter /usr/share/pam-configs/ zu pflegen (sauberer, upgrade-fest) — hier aus Gründen der Nachvollziehbarkeit als direkter Block-Insert gehalten.
• /tmp//dev/shm-Remount wirkt nur, wenn diese Pfade bereits eigene Mountpoints sind. Ist das nicht der Fall, gibt die Rolle eine Debug-Meldung aus, ändert aber nichts automatisch am Partitionslayout (siehe Tabelle oben).
• Diese Rolle wurde in dieser Session nicht gegen ein reales Debian/Ubuntu-System ausgeführt (kein Root-/Zielsystem verfügbar) — nur ansible-playbook --syntax-check sowie YAML-/Jinja2-Parsing wurden verifiziert (siehe README, Abschnitt „Was bewusst noch offen ist"). Ein --check-Lauf (Dry-Run) und ein realer Rollout-Test in einer Staging-Umgebung stehen vor dem Produktivbetrieb noch aus.