second commit

ansible/roles/os_hardening/CIS_STIG_MAPPING.md

@@ -0,0 +1,71 @@
+# 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.