# PCI-DSS Compliance: Kreditkartendaten auf Linux sicher verarbeiten

TL;DR / Management Summary Wer Kreditkartendaten verarbeitet, speichert oder überträgt, unterliegt dem PCI-DSS (Payment Card Industry Data Security Standard). Dies ist einer der strengsten Sicherheitsstandards weltweit. Unter Linux bedeutet dies: Wir bauen eine CDE (Cardholder Data Environment) auf, die durch strikte Netzwerk-Segmentierung vom Rest des Netzes isoliert ist. Jede Dateiänderung an Systemdateien muss durch FIM (File Integrity Monitoring) überwacht werden, und die Firewall muss auf “Deny-by-Default” (Artikel 312) stehen.

# 1. Einführung & Architektur

Die Cardholder Data Environment (CDE).

PCI-DSS fordert den Schutz des gesamten Pfades der Kreditkartennummer (PAN).

# Der PCI-DSS Sicherheits-Stack (Mermaid)

graph TD
    A[Payment Terminal / Frontend] --> B[CDE: Linux App Server]
    B --> C[CDE: Linux DB Server]
    subgraph "The CDE Fortress"
        B
        C
    end
    D[Internal Network] -.-x|Blocked| B
    E[Internet] -->|HTTPS 443 Only| B
    B -->|Encrypted Database| C
    F[FIM: AIDE / Tripwire] --> B
    G[Logging: Central TLS] --> B
    G --> C

# 2. Netzwerksicherheit (Req. 1 & 2)

Isolation ist alles.

PCI-DSS verbietet den direkten Zugriff aus dem Internet auf die Datenbank.

• Segmentierung: Nutzen Sie VLANs (Artikel 336), um die CDE physisch vom Büro-Netz zu trennen.
• Firewall: Implementieren Sie eine Host-Firewall, die keinen Traffic erlaubt, der nicht explizit für die Zahlungsverarbeitung nötig ist.

# 3. Schutz der Daten (Req. 3 & 4)

Verschlüsselung auf allen Ebenen.

Kreditkartennummern (PAN) dürfen niemals im Klartext gespeichert werden.

1. Storage: Nutzen Sie LUKS (Artikel 320) für die Festplatten.
2. Applikation: Nutzen Sie GPG oder hMAC-basierte Verschlüsselung innerhalb der Datenbank.
3. Transit: Erzwingen Sie TLS 1.2+ mit starken Ciphers (Artikel 319). Deaktivieren Sie SSLv3, TLS 1.0 und 1.1.

# 4. Day-2 Operations: Kontinuierliche Überwachung (Req. 10 & 11)

Audit und Integrität.

# File Integrity Monitoring (FIM)

PCI-DSS fordert wöchentliche Integritätsprüfungen der Systemdateien.

# AIDE Check automatisieren (siehe Artikel 349)
sudo aide --check

# Vulnerability Management

Führen Sie vierteljährlich interne und externe Scans durch.

# Nmap Audit (siehe Artikel 347)
nmap --script vuln <cde_range>

# 5. Troubleshooting & “War Stories”

Wenn die Compliance den Betrieb lähmt.

# Story 1: “Der abgelehnte Audit durch Shared-Keys”

Symptom: Ein QSA (Qualified Security Assessor) lässt das Unternehmen beim Audit durchfallen, obwohl alle Server verschlüsselt sind. Ursache: Mehrere Admins teilen sich einen SSH-Key zum Zugriff auf die CDE. PCI-DSS fordert die eindeutige Identifizierung jeder Person. Lösung: Nutzen Sie individuelle SSH-Keys (Artikel 302) und erzwingen Sie Multi-Faktor-Authentifizierung (Artikel 318).

# Story 2: “Das Log-Loch bei der Fehlersuche”

Symptom: Ein Bug in der Zahlungsabwicklung kann nicht gefunden werden, weil der Admin aus Sicherheitsgründen das Logging minimiert hat. Ursache: Angst vor dem Speichern von PANs im Log (was verboten ist). Lösung: Implementieren Sie Log-Maskierung in Ihrer Applikation. Loggen Sie alle Metadaten, aber ersetzen Sie Kreditkartennummern durch XXXX-XXXX-XXXX-1234. So bleibt das System debugbar und konform.

# 6. Fazit & Empfehlung

• Zertifizierung: Planen Sie ein PCI-Audit Monate im Voraus. Es ist der zeitaufwändigste aller Compliance-Prozesse.
• Wartung: Patchen Sie kritische Sicherheitslücken in der CDE innerhalb von 30 Tagen (Req. 6.2).
• Wahl: Nutzen Sie gehärtete Repositories und OpenSCAP Berichte als Beweis für Ihre Konformität.

# Anhang: PCI-DSS Checkliste für Admins