Auditd Průvodce: CIS a PCI DSS (2026)

Q: Jak ověřím, že jsou audit pravidla aktivní?

Spusťte sudo auditctl -l pro výpis aktuálně zavedených pravidel a sudo auditctl -s pro status jaderného subsystému. Očekáváte enabled 1 a lost 0 . Pokud lost roste, zvyšte backlog_limit . Pro test konkrétního pravidla použijte akci, kterou má sledovat, a hned poté sudo ausearch -k <klíč> --start recent .

Aktualizováno: 11. července 2026

Auditd je uživatelský démon linuxového audit subsystému v jádře, který spolehlivě zaznamenává syscall události, přístupy k souborům a autentizační akce pro potřeby bezpečnostního auditu a compliance frameworků jako CIS Benchmark, PCI DSS 4.0 a HIPAA. V tomhle průvodci ukazuju, jak nasadit audit-userspace 4.0 na jádrech řady 6.x, jak psát efektivní pravidla přes auditctl, jak splnit požadavky CIS a PCI DSS, a jak logy analyzovat pomocí ausearch, aureport a integrace se SIEM systémy. Přiznávám, že jsem si tenhle setup léta bránil (přišel mi zbytečně upovídaný), dokud jsem neseděl u prvního reálného PCI auditu.

Auditd je součástí balíku audit-userspace; aktuální verze 4.0 podporuje jádra 6.x a přináší podporu io_uring auditu (CVE-2022-2585 a související opravy jsou už zapracované).
CIS Benchmark pro RHEL 9 a Ubuntu 24.04 definuje v sekci 4.1 přibližně 40 auditních pravidel, která pokrývají změny /etc/passwd, mount události, sudo a modifikace času.
PCI DSS 4.0 požadavek 10.2 vyžaduje audit trail pro všechny administrátorské akce a přístupy k datům držitelů karet. Auditd to řeší nativně, bez potřeby externí agentury.
Když nepřenášíte logy přes rsyslog, ale využijete audisp-remote nebo Wazuh agenta, dosáhnete integrity logů podle SOC 2 a ISO 27001.
Neúmyslně vysoký objem pravidel (třeba -a always,exit -F arch=b64 -S execve) může na produkčním serveru způsobit ztrátu událostí; správně nastavené backlog_limit je klíčové.
Pro runtime detekci hrozeb s nižší režií zvažte doplnění auditd o eBPF nástroje jako Falco nebo Tetragon. Auditd pokrývá compliance, eBPF pokrývá detekci.

Co je auditd a proč jej používat pro compliance auditing?

Auditd (audit daemon) je jediný uživatelský proces, který čte události z jaderného audit netlink socketu a zapisuje je do /var/log/audit/audit.log. Jaderná strana (CONFIG_AUDIT a CONFIG_AUDITSYSCALL) je součástí linuxového kernelu už od verze 2.6 a od té doby prošla řadou vylepšení. Jádra 6.x podporují audit i pro nové asynchronní subsystémy včetně io_uring (viz commit 5bd2182d58e9 od Paula Moora, kernel 6.5).

Proč auditd, když existují eBPF nástroje, o kterých píšu v článku runtime bezpečnost Linuxu s eBPF, Falco a Tetragon? Auditd je totiž oficiálně akceptovaným zdrojem důkazů pro auditory. Rámce jako CIS Benchmark, PCI DSS 4.0, HIPAA §164.312(b) a STIG explicitně jmenují auditd (nebo ekvivalent) v kontrolních bodech, protože je součástí distribuce, běží mimo prostor sledovaného procesu a jeho výstup je strojově parsovatelný přes auparse. eBPF je vhodný pro operativní detekci, auditd pro forenzní a compliance stopu. V praxi obvykle nasazuji obojí paralelně: auditd pro CIS/PCI, Falco pro alerting v Kubernetes.

Klíčové vlastnosti? Neztrátové doručení (backlog buffer v jádře), izolace od uživatelských shellů (nelze obejít bez CAP_AUDIT_CONTROL), integrace s USE flags v RHEL/Fedora a nativní podpora v distribucích Ubuntu, Debian, SUSE a Amazon Linux 2023.

Instalace a základní konfigurace auditd 4.0

Aktuální verze audit-userspace k červenci 2026 je 4.0.2 (vyšlo v lednu 2026). Instalace na hlavních distribucích:

# RHEL 9 / Rocky Linux / AlmaLinux
sudo dnf install -y audit audit-libs

# Ubuntu 24.04 LTS / Debian 12
sudo apt-get update && sudo apt-get install -y auditd audispd-plugins

# Ověření verze a stavu
auditctl -v            # očekáváte 4.0.x
sudo systemctl enable --now auditd
sudo systemctl status auditd

Hlavní konfigurační soubor je /etc/audit/auditd.conf. Nejdůležitější parametry pro produkci:

# /etc/audit/auditd.conf, produkční nastavení

log_file = /var/log/audit/audit.log
log_format = ENRICHED           # doplní UID→username, syscall→jméno
log_group = adm                 # čtení pro auditory bez rootu
max_log_file = 100              # MB
num_logs = 20                   # rotace 20 souborů = ~2 GB retence
max_log_file_action = ROTATE
space_left = 1024               # MB, přejde do warning stavu
space_left_action = SYSLOG
admin_space_left = 512          # MB, kritický stav
admin_space_left_action = SUSPEND  # pro PCI použijte HALT
disk_full_action = SUSPEND
disk_error_action = SUSPEND
flush = INCREMENTAL_ASYNC
freq = 50                       # zápis na disk po každých 50 událostech

Po změně konfigurace znovu načtěte démon: sudo systemctl reload auditd. Na rozdíl od většiny služeb nepodporuje reload u některých parametrů, takže pro jistotu restart. Ověření, že jaderný subsystém běží: sudo auditctl -s vypíše enabled 1 failure 1 pid 1234 rate_limit 0 backlog_limit 8192.

Struktura audit pravidel: auditctl a audit.rules

Audit pravidla existují ve třech typech: kontrolní (-w watch pro soubory), syscall (-a always,exit -S ...) a metapravidla pro řízení chování démona. Trvalá pravidla patří do souborů v /etc/audit/rules.d/*.rules. Při startu je augenrules spojí do /etc/audit/audit.rules.

# /etc/audit/rules.d/10-base.rules, základ pro každý server

## Vymazání předchozích pravidel
-D

## Velikost fronty v jádře. Vyšší = menší riziko ztráty, více paměti.
-b 16384

## Failure mode: 1=vypsat do dmesg, 2=panic (STIG vyžaduje 2)
-f 1

## Sledování změn v uživatelských účtech (CIS 4.1.11)
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group  -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

## Sudo a privilege escalation
-w /etc/sudoers   -p wa -k scope
-w /etc/sudoers.d -p wa -k scope
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -F key=priv_esc

## Pokus o změnu systémového času
-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time-change
-w /etc/localtime -p wa -k time-change

## Nakonec zamknout konfiguraci, vyžaduje reboot pro změnu
-e 2

Po přidání pravidel spusťte sudo augenrules --load a ověřte pomocí sudo auditctl -l | head. Volba -e 2 na konci pravidla zamkne konfiguraci. Jakákoliv další modifikace pak vyžaduje restart, což auditoři chtějí vidět zaznamenané v logu.

Jak nakonfigurovat auditd pro CIS Benchmark

CIS Benchmark for Red Hat Enterprise Linux 9 v2.0.0 (leden 2026) a ekvivalentní benchmark pro Ubuntu 24.04 LTS definují v sekci 4.1 (Configure Data Retention) přibližně 40 kontrolních bodů týkajících se auditd. Kompletní referenční sadu pravidel udržuje komunita v projektu linux-audit/audit-userspace v adresáři rules. Začněte souborem 30-stig.rules, který pokrývá STIG i většinu CIS bodů.

Ukázka klíčových pravidel z CIS Level 2:

# /etc/audit/rules.d/40-cis.rules, výběr CIS 4.1.x pravidel

## 4.1.3.5, pokusy o získání oprávnění (SUID/SGID executables)
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid_exec
-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid_exec

## 4.1.3.6, přístup k souborům, který selhal (EACCES/EPERM)
-a always,exit -F arch=b64 -S openat,open,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access
-a always,exit -F arch=b64 -S openat,open,open_by_handle_at -F exit=-EPERM  -F auid>=1000 -F auid!=unset -k access

## 4.1.3.7, modifikace DAC oprávnění
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -k perm_mod
-a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -k perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod

## 4.1.3.8, mount události
-a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k mounts

## 4.1.3.9, nahrávání a mazání modulů jádra
-a always,exit -F arch=b64 -S init_module,delete_module,finit_module -F auid>=1000 -F auid!=unset -k modules
-w /usr/sbin/insmod  -p x -k modules
-w /usr/sbin/rmmod   -p x -k modules
-w /usr/sbin/modprobe -p x -k modules

Filter -F auid>=1000 -F auid!=unset vyloučí systémové účty a nepřihlášené sezení. CIS to explicitně vyžaduje, aby log neobsahoval šum ze cronů. Ověření compliance provedete nástrojem OpenSCAP se SCAP profily: sudo oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis /usr/share/xml/scap/ssg/content/ssg-rhel9-xccdf.xml. Report v HTML pak předáte auditorovi.

Auditování pro PCI DSS 4.0 a HIPAA

PCI DSS 4.0 (schválené v březnu 2024, plně vynutitelné od 31. března 2025) v požadavku 10.2 vyjmenovává, které události musí být zaznamenávány v auditním trailu. Pro Linux hosty držící data držitelů karet potřebujete auditd pokrývající tyto scénáře:

PCI DSS 4.0 požadavek	Popis	Odpovídající audit pravidlo
10.2.1.1	Přístup uživatele k cardholder data	`-w /var/lib/pgsql/data -p rwa -k pci_cde`
10.2.1.2	Akce s root/administrátorskými oprávněními	`-a always,exit -F arch=b64 -S execve -F euid=0 -k pci_admin`
10.2.1.3	Přístup k audit logům	`-w /var/log/audit -p rwa -k pci_audit_access`
10.2.1.4	Neúspěšné pokusy o autentizaci	`-w /var/log/faillog -p wa -k pci_auth`
10.2.1.5	Změny identifikačních a autentizačních mechanismů	`-w /etc/pam.d -p wa -k pci_pam`
10.2.1.6	Inicializace nebo zastavení audit logů	Nativně logováno auditd démonem
10.2.1.7	Vytvoření a mazání systémových objektů	`-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F auid>=1000 -k pci_objects`

HIPAA §164.312(b) (Audit controls) je méně preskriptivní než PCI, ale technický safeguard požaduje mechanismus zaznamenávající aktivitu s elektronickými chráněnými zdravotnickými informacemi (ePHI). V praxi nasazuji stejnou sadu pravidel jako pro PCI, jen změním klíč (-k hipaa_phi) a watch cesty přesměruji na adresáře s databází pacientů. Retence u HIPAA je minimálně 6 let, takže nastavte num_logs tak, aby s log rotací ROTATE a mimo-hostním archivem (rsync na WORM úložiště, viz další kapitola) šlo požadovanou lhůtu doložit. Detailní požadavky najdete v oficiálním výkladu HIPAA Security Rule od HHS.

Analýza logů pomocí ausearch a aureport

Surový audit.log je textový formát s prefixem type=SYSCALL msg=audit(TIMESTAMP:SERIAL):. Pro forenzní práci soubor téměř nikdy nečtu přímo. Nástroje ausearch a aureport obsluhují časové rozsahy, klíče i překlad UID na jména.

# Všechny události s klíčem pci_admin za posledních 24 hodin
sudo ausearch -k pci_admin --start today -i

# Neúspěšné přihlášení za poslední týden
sudo ausearch -m USER_LOGIN -sv no --start week-ago -i

# Souhrn spuštěných příkazů podle uživatele
sudo aureport -x --summary -i

# Kdo modifikoval /etc/shadow?
sudo ausearch -f /etc/shadow -i | aureport -f --summary

# Export do JSON pro další zpracování (od audit-userspace 3.1)
sudo ausearch --start today --format csv > events.csv
sudo ausearch --start today --format text | jq -R -s . > events.json

Přepínač -i (interpret) doplní jména uživatelů, syscallů a signálů. Pro zpracování ve skriptech použijte auparse Python bindings (balík python3-audit):

#!/usr/bin/env python3
# Vypíše všechny execve události s cestou obsahující 'ssh'
import auparse

au = auparse.AuParser(auparse.AUSOURCE_FILE, "/var/log/audit/audit.log")
while au.parse_next_event() != 0:
    if au.get_type_name() != "SYSCALL":
        continue
    au.first_record()
    while True:
        if au.find_field("exe"):
            exe = au.interpret_field()
            if "ssh" in exe:
                ts = au.get_timestamp()
                print(f"{ts.sec}\t{exe}")
        if not au.next_record():
            break

Integrace auditd se SIEM systémy a journald

Ponechat audit log jen na lokálním disku odporuje požadavku PCI DSS 10.5 (chránit audit trail před modifikací). Existují čtyři cesty, jak logy vyvést z hosta:

1) audisp-remote pro TLS přenos na centrální kolektor

Nativní řešení. Nakonfigurujete /etc/audit/audisp-remote.conf se vzdáleným hostem a spustíte plugin audisp-remote. Podporuje mutual TLS (od verze 3.0) a garantuje pořadí událostí.

2) Přenos přes journald

Od auditd 3.0 lze zapisovat události paralelně do systemd journal pomocí audisp-syslog. Pak stačí nakonfigurovat systemd-journal-upload nebo journald-relay. Nevýhoda: journald může události "de-duplikovat", což je v rozporu s PCI. Používejte spíš přímý plugin.

3) Wazuh agent

Wazuh čte přímo /var/log/audit/audit.log, dekóduje syscally přes vlastní parser a mapuje je na MITRE ATT&CK. Vhodné, pokud máte Wazuh jako SIEM.

4) Filebeat + Elastic

Módul auditd ve Filebeatu 8.x provádí dekódování ENRICHED formátu do JSON polí. Rychlé nasazení, ale pozor na data-loss při restartu Filebeatu. Nastavte queue.disk.

# /etc/audit/plugins.d/au-remote.conf, aktivace vzdáleného přenosu
active = yes
direction = out
path = /sbin/audisp-remote
type = always
format = string

# /etc/audit/audisp-remote.conf
remote_server = siem.internal.example.com
port = 60
transport = tcp
enable_krb5 = no
network_retry_time = 1
max_tries_per_record = 3
queue_file = /var/spool/audit/remote.log
mode = immediate

Výkonnostní optimalizace a nejčastější problémy

Auditd na busy webserveru s tisíci syscally za sekundu může zabírat 5 až 15 % CPU jednoho jádra. Nejčastější příčiny:

Ztráta událostí. auditctl -s ukazuje lost > 0. Zvyšte -b (backlog_limit) na 32768 nebo 65536. V jádrech 6.x je maximum 1 048 576.
Vysoká latence syscallů. Široká pravidla jako -a always,exit -F arch=b64 -S execve bez filtrů zaznamenávají KAŽDÉ spuštění příkazu. Filtrujte podle UID (-F auid>=1000) nebo cesty (-F path=/usr/bin/sudo).
Plný disk. Nastavte space_left_action = SYSLOG a monitorujte přes journald nebo Prometheus node_exporter.
Pořadí pravidel. V pravidlech typu exit se aplikuje první shoda. Umístěte "vylučovací" pravidla (-a never,exit) na začátek.
Konflikt se SELinuxem. Na Fedora 40+ v SELinux enforcing módu vyžaduje čtení z audit.log správný kontext. Použijte roli auditor_r, případně připojte auditory do skupiny log_group.

Pro širší pohled na hardening doporučuju zkombinovat auditd s dalšími bezpečnostními vrstvami, například s hardeningem systemd služeb a sandboxingem pro omezení blast radius, s runtime monitoringem přes eBPF a s pravidelným OpenSCAP skenováním. Auditd je základ, který dokumentuje "co se stalo"; hardening minimalizuje "co se stát může".

Často kladené otázky

Jaký je rozdíl mezi auditd a syslog?

Syslog (nebo journald) přijímá zprávy, které aplikace samy odešlou, jde tedy o kooperativní logování. Auditd naproti tomu čte události přímo z jaderného audit subsystému, takže zaznamenává i syscally, které daná aplikace vůbec nevidí (například execve podřízeného procesu). Pro compliance je auditd nezbytný, protože ho běžný uživatel nemůže obejít bez CAP_AUDIT_CONTROL.

Zpomalí auditd můj server?

Sám démon má minimální režii. Zpomalení pochází z konkrétních pravidel: širokých execve pravidel bez filtrů, monitorování /var/log nebo /tmp, a nízkého backlog_limit způsobujícího spinning v jádře. Se správnou sadou CIS pravidel a -b 16384 běžně vidím režii pod 3 % CPU.

Jak dlouho uchovávat audit logy pro PCI DSS a HIPAA?

PCI DSS 4.0 požaduje minimálně 12 měsíců, z toho poslední 3 měsíce okamžitě dostupné. HIPAA vyžaduje 6 let. V praxi nastavuju lokálně 30 až 90 dní (rotace num_logs) a externí archivace na WORM úložiště zbytek. Nezapomeňte na kryptografický otisk (SHA-256) exportovaných souborů pro doložení integrity.

Můžu použít auditd v kontejnerech?

Jaderný audit subsystém je globální, kontejnery sdílejí stejný audit netlink jako host. Uvnitř kontejneru tedy auditd nespouštějte. Démon běží na hostu a rozlišuje události přes pole audit_container_id (kernel 5.14+). Pro Kubernetes clustery používám kombinaci auditd na node úrovni a Falco pro pod-level detekci.

Jak ověřím, že jsou audit pravidla aktivní?

Spusťte sudo auditctl -l pro výpis aktuálně zavedených pravidel a sudo auditctl -s pro status jaderného subsystému. Očekáváte enabled 1 a lost 0. Pokud lost roste, zvyšte backlog_limit. Pro test konkrétního pravidla použijte akci, kterou má sledovat, a hned poté sudo ausearch -k <klíč> --start recent.