Auditd-Protokolle für PCI-DSS-Konformität unter Linux 2026

Auditd ist das kernelbasierte Audit-Subsystem unter Linux und erfasst Systemereignisse auf Syscall-Ebene, nicht nur Anwendungsmeldungen.
PCI DSS 4.0 verlangt in den Anforderungen 10.1 bis 10.7 die lückenlose Erfassung, zentrale Speicherung und zwölfmonatige Aufbewahrung sicherheitsrelevanter Protokolle.
In Frankreich ergänzen die Empfehlungen der ANSSI und die Vorgaben der CNIL die PCI-DSS-Pflichten zur Journalisierung.
Entscheidend sind unveränderliche Speicherung, Zeitsynchronisation per NTP und ein dokumentierter Überprüfungsprozess.

Table of Contents

Warum Auditd für die PCI-DSS-Konformität in Frankreich unverzichtbar ist

Bevor wir uns in die Konfigurationsdetails begeben, möchte ich die grundlegende Frage klären: Warum reicht ein gewöhnlicher Syslog-Dienst für ein PCI-DSS-Audit nicht aus? Die Antwort liegt in der Erfassungstiefe. Auditd arbeitet direkt im Linux-Kernel und protokolliert Systemaufrufe (Syscalls), Dateizugriffe und Authentifizierungsereignisse, die ein reiner Syslog-Daemon schlicht nicht sieht. Für ein französisches Fintech-Unternehmen, das Kartendaten verarbeitet, ist genau diese Tiefe der Unterschied zwischen einer bestandenen Prüfung und einer Feststellung.

Kurz gesagt :

Auditd est le sous-système d'audit basé sur le noyau Linux qui capture les événements au niveau des appels système, pas seulement les messages applicatifs.
PCI DSS 4.0 exige dans les exigences 10.1 à 10.7 la capture complète, le stockage centralisé et la conservation sur douze mois des journaux de sécurité.
En France, les recommandations de l'ANSSI et les exigences de la CNIL complètent les obligations PCI DSS en matière de journalisation.
Les points critiques sont le stockage immuable, la synchronisation temporelle via NTP et un processus de vérification documenté.

Was ist Auditd und welche Rolle spielt es bei der Protokollierung unter Linux?

Auditd ist das Audit-Subsystem des Linux-Kernels und protokolliert sicherheitsrelevante Ereignisse auf Syscall-Ebene, während klassische Syslog-Dienste lediglich Anwendungsmeldungen weiterleiten. Ich evaluiere in meinen Projekten regelmäßig beide Ansätze, und der Unterschied ist erheblich: Auditd erfasst, wer welche Datei gelesen hat, welcher Prozess mit welchen Argumenten gestartet wurde und ob eine Richtlinie verletzt wurde. Syslog liefert dagegen nur das, was eine Anwendung freiwillig schreibt. Für die Anforderung 10.2.1 der PCI-DSS-Norm, die individuelle Benutzerzugriffe auf Systemkomponenten verlangt, ist Auditd damit die robustere Grundlage. Die Architektur besteht aus drei Komponenten: dem Kernel-Audit-Modul, dem Userspace-Daemon auditd und dem Steuerungswerkzeug auditctl. Ergänzend liefern ausearch und aureport die Auswertung. Diese Trennung ist bewusst gewählt, denn sie erlaubt es, die Erfassung im Kernel zu belassen, während die Auswertung im Userspace skaliert.

Welche Anforderungen stellt PCI DSS 4.0 an die Protokollierung?

PCI DSS 4.0 fordert in den Anforderungen 10.1 bis 10.7 die Erfassung aller Zugriffe auf Systemkomponenten, die zentrale Speicherung, den Schutz vor Manipulation und eine Aufbewahrung von mindestens zwölf Monaten. Die Norm unterscheidet dabei sauber zwischen Erfassung, Übertragung, Speicherung und Überprüfung. Anforderung 10.2 definiert, welche Ereignisse zwingend zu protokollieren sind: individueller Benutzerzugriff, administrative Aktionen, Zugriffe auf Audit-Trails, ungültige logische Zugriffsversuche, Identitätswechsel und Änderungen an Sicherheitskontrollen. Anforderung 10.3 verlangt, dass jeder Eintrag Benutzerkennung, Ereignistyp, Zeitstempel, Erfolg oder Misserfolg, Ursprung und betroffene Ressource enthält. Anforderung 10.5.1 legt die zwölfmonatige Aufbewahrung fest, wobei die letzten drei Monate unmittelbar verfügbar sein müssen. Das sind harte, prüfbare Kriterien, keine Empfehlungen.

Welche Besonderheiten gelten für französische Unternehmen?

In Frankreich treffen die PCI-DSS-Pflichten auf die Empfehlungen der ANSSI und die Aufsicht der CNIL, sodass die Journalisierung zwei Regelwerke gleichzeitig erfüllen muss. Die CNIL verlangt im Rahmen der DSGVO-Umsetzung, dass personenbezogene Daten in Protokollen zweckgebunden und zeitlich begrenzt gespeichert werden. Die ANSSI wiederum empfiehlt in ihren Leitfäden zur Systemhärtung eine zentrale, signierte Protokollierung mit getrennten Rechten. Das klingt nach einem Widerspruch, ist aber keiner: Sie speichern sicherheitsrelevante Ereignisse zwölf Monate lang, minimieren jedoch die personenbezogenen Inhalte und regeln den Zugriff über Rollen. Genau diese Balance habe ich in mehreren Audits als kritischen Erfolgsfaktor erlebt.

Der Kontext von Payfrance Solutions vor dem Audit

Um die folgenden Maßnahmen greifbar zu machen, skizziere ich das Ausgangsszenario, das ich in vergleichbarer Form bei mehreren französischen Zahlungsdienstleistern angetroffen habe. Das Unternehmen Payfrance Solutions mit Sitz in Paris beschäftigt 45 Mitarbeiter und verarbeitet Zahlungskarten für E-Commerce-Händler. Der Wunsch, PCI DSS Level 1 zu erreichen, entstand aus einem konkreten Geschäftsanlass: Ein großer französischer Händler machte die Zusammenarbeit von einem gültigen Attest of Compliance abhängig.

Welche Infrastruktur und welches Geschäftsmodell lagen vor?

Die Serverlandschaft umfasste 50 virtuelle Maschinen in einer gemischten Umgebung aus Debian und RHEL, die etwa zwei Millionen Transaktionen pro Monat verarbeitete. Diese Heterogenität ist typisch und zugleich der erste Performance-Engpass bei der Einführung einer einheitlichen Journalisierung. Zwei Distributionen bedeuten zwei Paketstände, zwei Pfade für Konfigurationsdateien und zwei Verhaltensweisen bei der Rotation. Wer hier mit manuellen Änderungen arbeitet, verliert die Konsistenz innerhalb weniger Wochen. Ich empfehle deshalb von Beginn an eine deklarative Verwaltung, etwa über Ansible, und eine zentrale Ablage der Regelwerke im Versionskontrollsystem.

Welche Schwachstellen wurden bei der ersten internen Prüfung festgestellt?

Die erste interne Prüfung förderte drei gravierende Lücken zutage: fehlende zentrale Protokollierung, unvollständige Erfassung privilegierter Zugriffe und eine Aufbewahrungsfrist von nur 30 Tagen statt der geforderten 12 Monate. Besonders die zweite Lücke ist tückisch, denn sie fällt im Normalbetrieb nicht auf. Ein Administrator meldet sich per SSH an, wechselt mit sudo su zu root und arbeitet weiter, ohne dass ein Audit-Eintrag entsteht. Genau solche Szenarien prüft ein qualifizierter Sicherheitsprüfer (QSA) mit Vorliebe, weil sie die Wirksamkeit der Kontrollen unmittelbar infrage stellen.

Welche Risiken drohten bei einem Scheitern des Audits?

Bei einem Scheitern hätte das Unternehmen einen Großkunden verloren und Vertragsstrafen in Höhe von 250.000 Euro riskiert, ganz abgesehen vom Reputationsschaden im französischen Fintech-Sektor. Man muss das nüchtern betrachten: Der direkte finanzielle Verlust ist die kleinere Gefahr. Der eigentliche Schaden entsteht, wenn Zahlungsdienstleister und Kartennetzwerke das Vertrauen verlieren. Ich habe erlebt, wie ein einzelnes fehlendes Audit-Attest über Jahre hinweg Geschäftsbeziehungen blockiert hat.

Die Maßnahmen zur Einführung von Auditd im Detail

Nun zum operativen Teil, den ich bewusst als nachvollziehbare Sequenz aufbaue. Die Reihenfolge ist nicht beliebig, denn jede Stufe setzt auf der vorherigen auf. Wer mit den Regeln beginnt und die Zeitsynchronisation vergisst, produziert Protokolle, die vor Gericht und im Audit wertlos sind.

Wie wurde Auditd auf allen Servern installiert und konfiguriert?

Die Installation erfolgte über Ansible-Playbooks zur einheitlichen Bereitstellung, gefolgt von einer Anpassung der Datei auditd.conf an die PCI-DSS-Vorgaben. Auf Debian-Systemen heißt das Paket auditd, auf RHEL-Systemen identisch, doch die Standardpfade und die Einbindung in systemd unterscheiden sich. Die zentralen Parameter, die wir angepasst haben, sind diese:

log_file = /var/log/audit/audit.log mit separater Partition, um ein Volllaufen des Root-Dateisystems zu verhindern.
max_log_file = 200 und num_logs = 10 für eine Rotation, die etwa 2 GB pro Host abdeckt.
max_log_file_action = keep_logs, damit Ereignisse bei Erreichen der Grenze nicht verworfen werden.
space_left_action = email und admin_space_left_action = single als Eskalationsstufen.
flush = incremental mit freq = 20, um Datenverlust bei einem Absturz auf maximal 20 Sekunden zu begrenzen.

Frankly, die Wahl von keep_logs statt rotate ist eine bewusste Entscheidung zugunsten der Compliance und gegen den Komfort. Sie müssen den Speicherbedarf dann aktiv überwachen, sonst füllt sich die Partition und der Host wechselt in den Single-User-Modus. Das ist ein scharfes Schwert (ich habe diese Falle einmal in einer Testumgebung ausgelöst).

Welche Regeln wurden in den Audit-Regelsätzen definiert?

Die Regelsätze wurden so gewählt, dass sie genau die PCI-DSS-Anforderungen 10.2.x abdecken, ohne den Kernel mit überflüssigen Ereignissen zu fluten. Eine Überwachung auf Kartendaten, privilegierte Befehle und Authentifizierung bildet das Fundament. Konkret haben wir folgende Regeln in /etc/audit/rules.d/pci.rules hinterlegt:

Dateizugriffe auf Karteninhaberdaten: -w /var/pci-data -p rwxa -k pci_cardholder_data
Überwachung privilegierter Befehle über execve, etwa -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands
Authentifizierungsereignisse über PAM: -w /etc/pam.d -p wa -k pam_config sowie -w /var/log/faillog -p wa -k logins
Änderungen an Benutzerkonten: -w /etc/passwd -p wa -k identity und -w /etc/shadow -p wa -k identity
Manipulationsschutz der Audit-Konfiguration: -w /etc/audit/ -p wa -k audit_rules und -e 2 als unveränderlicher Abschluss.

Der Parameter -e 2 am Ende ist entscheidend. Er versetzt das Audit-Subsystem in den unveränderlichen Modus, sodass selbst root die Regeln bis zum Neustart nicht mehr ändern kann. Für die Anforderung 10.3.2, die den Schutz der Audit-Trails verlangt, ist das ein zentraler Baustein. Ohne ihn bleibt jede Regel theoretisch umgehbar.

Wie wurde die zentrale Protokollierung mit Auditd umgesetzt?

Die Ereignisse wurden an einen zentralen rsyslog-Server in einem anderen Rechenzentrum weitergeleitet, verschlüsselt mit TLS und zusätzlich durch Signaturen integritätsgesichert. Ein lokaler Puffer ist unverzichtbar, denn bei einem Netzausfall darf kein Ereignis verloren gehen. Wir haben deshalb eine Queue im Speicher und auf Platte konfiguriert, die bei Wiederherstellung der Verbindung automatisch abgearbeitet wird. Die Übertragung erfolgt über omfwd mit dem Modul gtls. Zusätzlich signiert jeder Host seine Protokolle mit einem eigenen Schlüssel, sodass eine nachträgliche Manipulation auf dem zentralen Server erkennbar wird. Diese Kombination aus Transportverschlüsselung und Signatur ist mehr als Best Practice, sie ist die Voraussetzung für die Anforderung 10.3.3 zur Integritätsüberwachung.

Wie wurden Aufbewahrung und Rotation der Protokolle organisiert?

Wir haben eine Aufbewahrung von 13 Monaten gemäß PCI-DSS-Anforderung 10.5.1 konfiguriert, mit automatisierter Rotation und Archivierung auf WORM-Speicher. Der zusätzliche Monat ist kein Zufall, sondern ein Puffer für die Prüfungsdauer. Die letzten drei Monate liegen auf schnellem Speicher und sind unmittelbar durchsuchbar, ältere Monate wandern auf kostengünstigeren, aber unveränderlichen Speicher (Write Once Read Many). Diese Schichtung senkt die Kosten erheblich, ohne die Compliance zu gefährden. Ein Punkt, den viele unterschätzen: Die Uhrzeit muss auf allen Hosts synchron sein. Ohne konsistente NTP-Konfiguration lassen sich Ereignisse über Hosts hinweg nicht korrelieren, und im Audit entsteht der Eindruck lückenhafter Erfassung.

Welche Schulungen und Prozesse wurden im Team eingeführt?

Die Systemadministratoren wurden in der Interpretation von Auditd-Berichten geschult, und wir haben einen wöchentlichen Überprüfungsprozess für sicherheitsrelevante Ereignisse eingeführt. Technik allein erfüllt keine Anforderung, denn PCI DSS 10.4 verlangt die regelmäßige Überprüfung der Protokolle. Ein Werkzeug, das niemand liest, ist wertlos. Wir haben deshalb feste Suchabfragen definiert, etwa ausearch -k root_commands -ts recent für privilegierte Befehle und aureport --failed --summary für fehlgeschlagene Authentifizierungen. Jeder Administrator prüft wöchentlich einen definierten Satz von Schlüsseln und dokumentiert die Ergebnisse. Diese Routine — so unspektakulär sie wirkt — hat im Audit den entscheidenden Eindruck gemacht.

Die Ergebnisse nach sechs Monaten

Nach einem halben Jahr Betrieb lohnt der nüchterne Blick auf die Zahlen. Ich halte wenig von Erfolgsgeschichten ohne Messgrößen, deshalb habe ich die relevanten Werte vor und nach der Einführung gegenübergestellt.

Welche Messgrößen verbesserten sich konkret?

Die Vollständigkeit der Protokollerfassung stieg von 62 Prozent auf 99,4 Prozent, und die Erkennungszeit verdächtiger Aktivitäten sank von durchschnittlich 14 Stunden auf 22 Minuten. Diese 22 Minuten verdienen eine Einordnung: Sie entstehen nicht durch Automatisierung allein, sondern durch die zentrale Ablage und die definierten Suchabfragen. Vorher musste ein Administrator 50 Hosts einzeln durchsuchen, was in der Praxis oft ganz unterblieb. Die folgende Übersicht fasst die wichtigsten Werte zusammen.

Vergleich der Messgrößen bei Payfrance Solutions vor und nach der Auditd-Einführung
Messgröße	Vor der Einführung	Nach sechs Monaten	PCI-DSS-Bezug
Vollständigkeit der Protokollerfassung	62 Prozent	99,4 Prozent	Anforderung 10.2
Aufbewahrungsdauer	30 Tage	13 Monate	Anforderung 10.5.1
Erkennungszeit verdächtiger Aktivitäten	14 Stunden	22 Minuten	Anforderung 10.4
Abdeckung privilegierter Zugriffe	teilweise	vollständig	Anforderung 10.2.2
Projektkosten	—	rund 85.000 Euro	—

Wie verlief das offizielle PCI-DSS-Audit?

Das Audit wurde im ersten Anlauf mit nur zwei geringfügigen Feststellungen bestanden, was der qualifizierte Sicherheitsprüfer ausdrücklich auf die zentrale Protokollierung zurückführte. Die beiden Feststellungen betrafen Dokumentationsdetails, nicht die technische Umsetzung. Für mich ist das ein typisches Muster: Wer die Technik sauber implementiert und jeden Konfigurationsschritt dokumentiert, besteht die Prüfung ohne Nachbesserungsrunde. Die Prüfer interessieren sich weniger für exotische Werkzeuge als für Nachvollziehbarkeit.

Welche finanziellen und operativen Auswirkungen ergaben sich?

Die Gesamtkosten des Projekts beliefen sich auf rund 85.000 Euro für Lizenzen, Beratung und interne Arbeitszeit, während drei neue Großkunden gewonnen und der Umsatz um 18 Prozent gesteigert wurden. Rechnet man die drohenden Vertragsstrafen von 250.000 Euro hinzu, ist die Amortisation offensichtlich. Wichtiger noch: Die wöchentliche Prüfroutine hat zwei echte Vorfälle frühzeitig sichtbar gemacht, die sonst erst nach Tagen aufgefallen wären. Sicherheit, die sich rechnet, ist selten ein Zufall.

Was man daraus lernt

Aus diesem Projekt lassen sich mehrere übertragbare Lehren ziehen, die unabhängig von Unternehmensgröße und Branche gelten. Ich formuliere sie bewusst als konkrete Empfehlungen, nicht als allgemeine Ratschläge.

Warum eine schrittweise Einführung von Auditd entscheidend ist

Eine schrittweise Einführung verhindert die Überlastung des Systems durch zu viele Regeln auf einmal und erlaubt eine belastbare Messung der Auswirkungen. Wir haben mit acht Kernregeln begonnen und nach vier Wochen auf 24 erweitert. Jede Erweiterung wurde zuerst in einer Testumgebung evaluiert, denn eine schlecht formulierte execve-Regel kann die Ereignisrate um ein Vielfaches erhöhen. Ein hypothetisches Szenario verdeutlicht das: Eine Regel ohne arch-Filter erfasst jeden Syscall doppelt, auf 64-Bit- und auf 32-Bit-Ebene. Auf einem stark frequentierten Host bedeutet das schnell mehrere hundert Megabyte Protokoll pro Tag, nur für Rauschen.

Welche Fehler vermieden werden sollten

Die häufigsten Fehler sind die Unterschätzung des Speicherbedarfs und die Vernachlässigung der Zeitsynchronisation zwischen den Servern. Beide sind vermeidbar und beide sind teuer. Die folgende Liste fasst die Stolpersteine zusammen, die ich in Audits am häufigsten gesehen habe:

Zu viele Regeln ohne Bedarfsanalyse, was die Ereignisrate unkontrolliert steigen lässt.
Fehlende separate Partition für /var/log/audit, was im Ernstfall das gesamte System blockiert.
Keine NTP-Synchronisation, wodurch Zeitstempel über Hosts hinweg nicht korrelierbar sind.
Unverschlüsselte Übertragung zum zentralen Server, was Anforderung 10.3.3 verletzt.
Fehlende Dokumentation der Regeln, was die Prüfung durch einen QSA erschwert.
Keine regelmäßige Auswertung, wodurch die Protokolle ihren eigentlichen Zweck verfehlen.

Welche Best Practices sich für französische Unternehmen bewährt haben

Bewährt hat sich die frühzeitige Einbindung der CNIL-Anforderungen in die Planung sowie die lückenlose Dokumentation jeder Konfigurationsänderung für das Audit. Konkret bedeutet das: Sie definieren vor der ersten Regel, welche Daten personenbezogen sind und wie lange sie gespeichert werden dürfen. Sie versionieren die Regelwerke im Git und verknüpfen jede Änderung mit einem Ticket. Und Sie halten die Empfehlungen der ANSSI zur Systemhärtung ein, weil französische Prüfer diese Referenz kennen und schätzen. Diese drei Maßnahmen kosten wenig Zeit und sparen im Audit erheblich Nerven.

Häufig gestellte Fragen zu Auditd und PCI DSS

Die folgenden Fragen begegnen mir in fast jedem Projekt, und sie decken sich mit den Suchanfragen, die französische Administratoren am häufigsten stellen. Ich beantworte sie so knapp wie möglich und so präzise wie nötig.

Ist Auditd allein ausreichend für die PCI-DSS-Konformität?

Nein, Auditd allein reicht nicht aus, denn es liefert die Erfassung, aber nicht die zentrale Auswertung, Alarmierung und Aufbewahrung, die PCI DSS 4.0 zusätzlich verlangt. Sie benötigen eine zentrale Sammelstelle, einen manipulationsgeschützten Speicher und einen dokumentierten Überprüfungsprozess. Auditd ist das Fundament, nicht das Gebäude.

Wie lange müssen Auditd-Protokolle gemäß PCI DSS aufbewahrt werden?

PCI DSS verlangt eine Aufbewahrung von mindestens zwölf Monaten, wobei die letzten drei Monate unmittelbar verfügbar sein müssen. In der Praxis empfehle ich 13 Monate, um die Prüfungsdauer abzudecken und einen Puffer für Nachfragen zu haben.

Welche Alternativen zu Auditd gibt es für französische Unternehmen?

Als Alternativen kommen SystemTap, eBPF-basierte Werkzeuge wie Falco sowie kommerzielle Agenten von SIEM-Anbietern infrage, doch keine davon ersetzt die Kernel-Tiefe von Auditd vollständig. eBPF ist performanter, aber weniger standardisiert und damit schwieriger zu auditieren.

Wie unterscheidet sich Auditd von SIEM-Lösungen?

Auditd erfasst Ereignisse lokal auf Syscall-Ebene, während eine SIEM-Lösung Daten aus vielen Quellen korreliert, alarmiert und langfristig archiviert. Die beiden ergänzen sich: Auditd liefert die Rohdaten, das SIEM die Analyse. Wer nur eines von beiden betreibt, lässt eine Lücke offen.

Wie Sie Ihre Auditd-Protokolle auf PCI-DSS-Konformität prüfen

Wenn Sie die hier beschriebenen Schritte auf Ihre eigene Umgebung übertragen möchten, empfehle ich eine strukturierte Vorgehensweise. Beginnen Sie mit einer Bestandsaufnahme, nicht mit der Konfiguration. Die folgende Sequenz hat sich in meinen Projekten bewährt:

Erfassen Sie alle Hosts, Distributionen und Versionen in einer Inventarliste.
Prüfen Sie die aktuelle Ereignisrate mit aureport --summary über mindestens sieben Tage.
Definieren Sie die Schlüssel und Regeln anhand der Anforderungen 10.2.1 bis 10.2.7.
Richten Sie die zentrale Sammlung mit TLS und Signatur ein, bevor Sie Regeln ausrollen.
Testen Sie die Rotation und die Aufbewahrung mit einem simulierten Volllaufen der Partition.
Dokumentieren Sie jede Änderung und verknüpfen Sie sie mit einem Ticket.

Möchten Sie Ihre Auditd-Konfiguration auf PCI-DSS-Konformität prüfen lassen? Laden Sie unseren kostenlosen Prüfleitfaden herunter oder kontaktieren Sie unser Expertenteam für ein unverbindliches Erstgespräch. Wir schauen gemeinsam auf Ihre Regelsätze, Ihre Aufbewahrung und Ihre Überprüfungsroutine, und wir sagen Ihnen ehrlich, wo die Lücken liegen.

Für eine effektive Sicherheitsanalyse ist es entscheidend, Linux-Logs mit Auditd auszuwerten und die gesammelten Daten zu interpretieren.

Die korrekte Konfiguration von Auditd-Regeln unter Linux ist dabei ein Schlüsselfaktor, um alle relevanten Ereignisse zu erfassen.

Um die Systemlast gering zu halten, sollte man auch die Auditd Performance Optimierung unter Linux berücksichtigen.

Pour aller plus loin sur ce sujet, consultez aussi notre article sur eigene Regeln erstellen.

Anna Berger

IT-Sicherheitsanalystin und Tech-Journalistin

Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …

Tous les articles de Anna Berger →