PCI-DSS relevante Linux Härtung: Server für die Zahlungsdaten-Umgebung absichern

1. PCI-DSS Grundlagen und Scope für die Linux Infrastruktur

Der Payment Card Industry Data Security Standard, kurz PCI-DSS, gilt für jeden Server, der Karteninhaberdaten speichert, verarbeitet oder überträgt. Dieser Bereich wird als Cardholder Data Environment, kurz CDE, bezeichnet und ist der zentrale Ausgangspunkt jeder PCI-DSS Härtung. Auf Linux Ebene bedeutet das zunächst eine saubere Scope-Definition: Welche Server berühren tatsächlich Kartendaten, welche sind nur netzwerktechnisch verbunden, und welche lassen sich durch Segmentierung ganz aus dem Scope entfernen.

Eine korrekte Scope-Reduktion ist der wirkungsvollste Hebel vor jeder technischen PCI-DSS Härtung, weil jeder Server im CDE denselben vollständigen Anforderungskatalog erfüllen muss. Ein Magento-Shop, der Zahlungen über einen externen Payment-Gateway per iFrame oder Redirect abwickelt und selbst keine Kartendaten speichert, kann unter bestimmten Bedingungen aus dem vollen Scope herausfallen. Wo Kartendaten aber tatsächlich den eigenen Server berühren, greift die volle Anforderungstiefe.

Für Linux Administratoren konzentriert sich die PCI-DSS Härtung praktisch auf drei Anforderungsblöcke: sichere Standardkonfiguration nach Anforderung 2, starke Zugriffskontrolle nach Anforderung 8 und lückenloses Logging nach Anforderung 10. Diese drei Blöcke bilden das technische Rückgrat, das im Folgenden konkret durchgegangen wird.

2. Anforderung 2: Standardkonfigurationen und Härtungsstandards

Anforderung 2 des PCI-DSS verlangt explizit, dass Vendor-Defaults nicht verwendet werden und ein dokumentierter Härtungsstandard existiert. Für die PCI-DSS Härtung unter Linux heißt das konkret: Standardpasswörter entfernen, unnötige Dienste deaktivieren, nur ein primärer Zweck pro Server, und ein anerkannter Härtungsstandard wie ein CIS Benchmark als Referenz. Der Standard selbst schreibt keine Konfigurationswerte vor, verlangt aber ausdrücklich die Existenz und Anwendung eines solchen Standards.

In der Praxis bedeutet das für jeden Linux Server im CDE: eine Inventarliste laufender Dienste, eine Begründung für jeden offenen Port, und eine deaktivierte oder deinstallierte Liste aller nicht benötigten Pakete. Die PCI-DSS Härtung verlangt außerdem verschlüsselte Administrationszugriffe, was in der Praxis SSH mit Public-Key-Authentifizierung statt Telnet oder unverschlüsseltem HTTP-Management bedeutet.

#!/usr/bin/env bash
# PCI-DSS Requirement 2 baseline audit: unnecessary services and open ports
set -euo pipefail

echo "== Active listening services =="
ss -tulpn | grep LISTEN

echo "== Enabled systemd services (potential attack surface) =="
systemctl list-unit-files --state=enabled --type=service

echo "== Checking for disallowed legacy services =="
for svc in telnet rsh-server vsftpd xinetd; do
  if systemctl is-enabled "$svc" &>/dev/null; then
    echo "[GAP] $svc is enabled, review against Requirement 2 hardening standard"
  fi
done

3. Anforderung 8: Authentifizierung und Passwort-Policy unter Linux

Anforderung 8 des PCI-DSS betrifft Identifikation und Authentifizierung jedes einzelnen Nutzers mit Zugriff auf Systemkomponenten im CDE. Für die PCI-DSS Härtung bedeutet das konkret: keine geteilten Accounts, Multi-Faktor-Authentifizierung für Remote-Zugriffe auf das CDE, eine Passwort-Mindestlänge von zwölf Zeichen seit PCI-DSS Version 4.0, und eine Kontosperrung nach spätestens zehn fehlgeschlagenen Anmeldeversuchen.

Unter Linux setzt man diese Anforderungen über PAM Module um, konkret pam_pwquality für Passwort-Komplexität und pam_faillock für Kontosperrung nach fehlgeschlagenen Versuchen. Die PCI-DSS Härtung verlangt zusätzlich, dass Passwörter nicht in Klartext übertragen oder gespeichert werden, was moderne Linux Distributionen mit SHA-512 Hashing in /etc/shadow standardmäßig erfüllen, sofern keine veraltete Konfiguration dies überschreibt.

# /etc/security/pwquality.conf
# PCI-DSS v4.0 Requirement 8.3.6: minimum 12 characters, complexity enforced
minlen = 12
minclass = 3
maxrepeat = 3
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1

# /etc/security/faillock.conf
# Requirement 8.3.4: lock account after 10 failed attempts, unlock after 30 minutes
deny = 10
unlock_time = 1800
fail_interval = 900

4. Anforderung 10: Logging und Monitoring Pflichten

Anforderung 10 ist einer der aufwendigsten Blöcke jeder PCI-DSS Härtung, weil sie lückenloses Logging für jeden Zugriff auf Kartendaten, jede Rechteänderung und jede Nutzung privilegierter Konten verlangt. Konkret müssen Zeitstempel, Nutzer, Ereignistyp, Erfolg oder Misserfolg und der betroffene Systembestandteil in jedem Log-Eintrag erkennbar sein. Auf Linux Ebene ist auditd das zentrale Werkzeug, um diese Detailtiefe zu erreichen, weit über Standard-Syslog hinaus.

Ein häufig übersehener Teil der PCI-DSS Härtung ist die Zeitsynchronisation über NTP, weil Anforderung 10 explizit korrekte, konsistente Zeitstempel über alle Systeme im CDE verlangt. Ohne synchronisierte Uhrzeiten lassen sich Log-Einträge verschiedener Server im Incident-Fall nicht zuverlässig korrelieren, was den gesamten Logging-Nachweis entwertet.

#!/usr/bin/env bash
# PCI-DSS Requirement 10 audit rules for privileged access and cardholder data paths
set -euo pipefail

cat >> /etc/audit/rules.d/pci-dss.rules << 'EOF'
# Track use of privileged commands
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k pci_privileged

# Track changes to authentication configuration
-w /etc/pam.d/ -p wa -k pci_auth_config
-w /etc/security/ -p wa -k pci_auth_config

# Track access to application data directory holding cardholder data references
-w /var/www/magento/var/log -p wa -k pci_cde_access

# Track modifications to audit configuration itself
-w /etc/audit/ -p wa -k pci_audit_config
EOF

augenrules --load
systemctl restart auditd

5. Firewall-Segmentierung und Netzwerkhärtung für den CDE

Anforderung 1 des PCI-DSS verlangt eine Firewall-Konfiguration, die das CDE klar vom restlichen Netzwerk trennt. Für die PCI-DSS Härtung auf Linux Servern bedeutet das eine Default-Deny-Policy mit expliziten Freigaben nur für tatsächlich benötigte Verbindungen, sowohl eingehend als auch ausgehend. Ausgehender Traffic wird in vielen Umgebungen vernachlässigt, ist aber ausdrücklich Teil der Anforderung, weil kompromittierte Systeme sonst unbemerkt Daten exfiltrieren könnten.

Praktisch setzt man das mit nftables oder iptables um, ergänzt durch eine Dokumentation, die jede Regel mit einer Geschäftsbegründung verknüpft. Diese Dokumentationspflicht wird bei der PCI-DSS Härtung oft unterschätzt: ein QSA prüft nicht nur, ob eine Regel existiert, sondern auch, ob nachvollziehbar ist, warum sie existiert und wer sie zuletzt überprüft hat.

6. Datei-Integrität und Anti-Malware Anforderungen

Anforderung 11.5 des PCI-DSS verlangt ein File Integrity Monitoring System, das unautorisierte Änderungen an kritischen Systemdateien, Konfigurationsdateien und Content-Dateien erkennt und meldet. Für die PCI-DSS Härtung ist AIDE unter Linux das gebräuchlichste Werkzeug, weil es quelloffen ist und feingranular konfigurierbar, welche Pfade mit welchen Attributen überwacht werden.

Wichtig ist, dass die PCI-DSS Härtung hier nicht nur die Installation, sondern auch den Nachweis regelmäßiger Auswertung verlangt. Ein FIM-Tool, das läuft, aber dessen Alerts niemand ansieht, erfüllt die Anforderung formal nicht. Ergänzend verlangt Anforderung 5 des Standards eine Anti-Malware-Lösung auf Systemen, die typischerweise von Malware betroffen sind, was auf Linux Web- und Applikationsservern oft ClamAV mit regelmäßigen Signatur-Updates bedeutet.

# ansible/roles/pci-fim/tasks/main.yml
# File Integrity Monitoring rollout as part of PCI-DSS hardening

- name: Install AIDE for PCI-DSS Requirement 11.5 file integrity monitoring
  apt:
    name: aide
    state: present

- name: Initialize AIDE baseline database
  command: aideinit
  args:
    creates: /var/lib/aide/aide.db

- name: Schedule daily integrity checks with alerting
  cron:
    name: "PCI-DSS AIDE integrity check"
    minute: "0"
    hour: "3"
    job: "/usr/bin/aide --check | mail -s 'AIDE Report' compliance@example.com"

- name: Deploy ClamAV for Requirement 5 malware protection
  apt:
    name:
      - clamav
      - clamav-daemon
    state: present

7. Patch-Management und Schwachstellen-Scans

Anforderung 6 des PCI-DSS verlangt, kritische Sicherheitspatches innerhalb eines definierten Zeitrahmens einzuspielen, meist innerhalb von 30 Tagen ab Veröffentlichung für kritische Schwachstellen. Für die PCI-DSS Härtung ist ein dokumentierter, wiederholbarer Patch-Prozess erforderlich, keine Ad-hoc-Updates nach Gefühl. Unattended Upgrades kombiniert mit einer Testphase in Staging ist der pragmatische Ansatz für die meisten Linux Serverumgebungen.

Anforderung 11.3 verlangt zusätzlich vierteljährliche interne und externe Schwachstellen-Scans, sowie einen ASV-Scan durch einen zertifizierten Approved Scanning Vendor für die externe Angriffsfläche. Die PCI-DSS Härtung ist damit kein einmaliger Zustand, sondern ein wiederkehrender Zyklus aus Patchen, Scannen und Nachbessern, dessen Ergebnisse dokumentiert und für den nächsten Audit-Zyklus aufbewahrt werden müssen.

8. Nachweisführung: Evidence für den QSA sammeln

Eine technisch korrekte PCI-DSS Härtung nützt wenig, wenn sie im Audit nicht nachweisbar ist. Für jeden Kontrollpunkt sollte eine Evidence-Quelle klar zugeordnet sein: Konfigurationsdateien als Screenshot oder Export, Ansible-Playbook-Läufe als Log, Scoring-Reports aus Vulnerability-Scans, und Change-Tickets für jede Konfigurationsänderung am CDE.

#!/usr/bin/env bash
# PCI-DSS evidence collection script, run before QSA on-site assessment
set -euo pipefail

EVIDENCE_DIR="/var/compliance/pci-evidence/$(date +%Y-%m)"
mkdir -p "$EVIDENCE_DIR"

# Requirement 2: configuration hardening proof
ss -tulpn > "$EVIDENCE_DIR/open-ports.txt"
systemctl list-unit-files --state=enabled > "$EVIDENCE_DIR/enabled-services.txt"

# Requirement 8: authentication policy proof
cp /etc/security/pwquality.conf "$EVIDENCE_DIR/"
cp /etc/security/faillock.conf "$EVIDENCE_DIR/"

# Requirement 10: logging configuration proof
auditctl -l > "$EVIDENCE_DIR/audit-rules.txt"
chronyc tracking > "$EVIDENCE_DIR/ntp-sync-status.txt" 2>/dev/null || true

# Requirement 11: file integrity and vulnerability scan proof
aide --check > "$EVIDENCE_DIR/aide-last-check.txt" 2>&1 || true

echo "Evidence collected in $EVIDENCE_DIR"

Diese Automatisierung reduziert den Aufwand vor jedem QSA-Termin erheblich und stellt sicher, dass die PCI-DSS Härtung nicht nur technisch existiert, sondern jederzeit belegbar ist. Ein wiederkehrender monatlicher Snapshot dieser Evidence-Sammlung dient gleichzeitig als interner Frühwarnindikator, falls sich Konfigurationen unbemerkt zurückentwickeln.

9. PCI-DSS Anforderungen und Linux Maßnahmen im Überblick

Die folgende Tabelle ordnet die wichtigsten PCI-DSS Anforderungen konkreten Linux Maßnahmen zu, wie sie im Rahmen einer PCI-DSS Härtung typischerweise umgesetzt werden.

Wer diese Tabelle als Ausgangspunkt für die eigene PCI-DSS Härtung nutzt, deckt bereits den technisch anspruchsvollsten Teil des Standards ab. Die verbleibenden organisatorischen Anforderungen, etwa Richtlinienpflege und Mitarbeiterschulung, bauen auf dieser technischen Basis auf.

10. Zusammenfassung

Eine belastbare PCI-DSS Härtung für Linux Server konzentriert sich auf drei technische Kernblöcke: sichere Standardkonfiguration nach Anforderung 2, starke Authentifizierung nach Anforderung 8 und lückenloses Logging nach Anforderung 10, ergänzt um Firewall-Segmentierung, Datei-Integritätsprüfung und ein dokumentiertes Patch-Management. Jede dieser Maßnahmen lässt sich mit Standard-Linux-Werkzeugen wie PAM, auditd, AIDE und nftables reproduzierbar umsetzen.

Der entscheidende Unterschied zwischen einer formalen und einer im Audit tatsächlich bestehenden PCI-DSS Härtung liegt in der Nachweisführung. Wer Evidence-Sammlung automatisiert und Scope-Reduktion konsequent verfolgt, reduziert nicht nur den Aufwand für jeden QSA-Termin, sondern senkt gleichzeitig das reale Risiko einer Kompromittierung der Zahlungsdaten-Umgebung.

11. FAQ: PCI-DSS relevante Linux Härtung