Bezpečné logování: protokolovat chyby bez úniku dat

Stručně: Logování v PHP s ohledem na ochranu osobních údajů znamená: bezpečnostně relevantní události zaznamenat úplně, hesla, tokeny, identifikátory relací a citlivá data zákazníků ale nikdy do logu nezapisovat. Chyby patří do protokolu, ne na obrazovku, logy leží mimo webroot a jsou chráněny proti změně. Jak dlouho logy zůstanou, rozhodněte vědomě společně s pověřencem pro ochranu osobních údajů.

Mezi zajištěním stop a únikem dat

Po PHP2Shell radila odborná média uchovávat logy webserveru od 20. 10. 2026. Kdo to chtěl provést, často zjistil dvojí. Buď byly logy dávno rotovány a smazány. Nebo obsahovaly věci, které tam nikdy neměly být: úplné vstupy formulářů, hesla z neúspěšných přihlášení, klíče API v URL.

Obojí je problém. Bez logů lze incident sotva rekonstruovat. S příliš velkým obsahem se samotný log stává cílem, protože kdo získá přístup k serveru, rád si ho přečte. Dobré logování leží mezi tím: dost pro hledání stop, co nejméně chráněných dat.

Co by aplikace PHP měla protokolovat

OWASP Logging Cheat Sheet uvádí události, které se počítají pro bezpečnost a dohledatelnost. Pro typické aplikace PHP je lze shrnout takto:

Každý záznam by měl odpovídat na otázky kdy, kde, kdo a co: časové razítko, aplikace a hostitel, zdrojová adresa, identifikátor uživatele, druh události a výsledek. Jména nebo e-mailové adresy lze často maskovat nebo nahradit interním identifikátorem, aniž by se ztratil užitek.

Dva zdroje nechtěných dat v logu se často přehlížejí. První jsou URL: pokud token, klíč k resetu hesla nebo e-mailová adresa stojí v query stringu, skončí automaticky v přístupovém logu webserveru, v lozích proxy a v historii prohlížeče. Takové hodnoty patří do těla požadavku nebo do hlavičky, ne do adresy. Druhým zdrojem je ladicí režim. Frameworky a pluginy v ladicím provozu často zapisují úplné požadavky, databázové dotazy a proměnné prostředí. Pokud tento režim po hledání chyby zůstane aktivní, nepozorovaně roste soubor přesně s informacemi, které útočník hledá. Po každém hledání chyby zkontrolujte, zda jsou ladicí výstupy opět vypnuty, a smažte soubory, které při tom vznikly.

Logování v PHP: základní nastavení

První úrovní je samotné PHP. V produkci se mají chyby protokolovat, ale nevypisovat. Log leží mimo webroot, aby nebyl dostupný přes URL.

; php.ini nebo pool FPM pro produkci
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Proč jsou viditelné chyby nebezpečné, popisuje článek Vypnutí výpisu chyb v produkci. Jak spolu chyby a výjimky v PHP souvisejí, vysvětluje stránka Chyby a výjimky v PHP.

Druhou úrovní je aplikace. Mnoho frameworků k tomu používá knihovnu podle standardu PSR-3 od PHP-FIG, který stanoví jednotné rozhraní loggeru. Důležitá není knihovna, ale disciplína: kontextová data vybírat vědomě, místo aby se do logu zapisovaly celé požadavky nebo objekty.

<?php
// Vstupy před zalogováním zneškodnit a maskovat
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // nikdy: 'passwort' => $_POST['passwort']
]);

Log injection a manipulované záznamy

Pokud aplikace zapisuje vstupy do logu nefiltrovaně, může útočník pomocí zalomení řádků vytvářet padělané záznamy. To mate vyhodnocení a může zakrýt stopy. OWASP Cheat Sheet doporučuje strukturované formáty jako JSON, odstranění nebo kódování zalomení řádků a omezení délky vstupů v logu.

Stejně důležitá je ochrana samotných logů:

1. Uložení mimo webroot a s právy, která uživatel webserveru potřebuje k zápisu, ale ne k mazání starých souborů.
2. Kopie na druhý systém, například přes syslog po šifrovaném spojení. Kdo server převezme, nesmí snadno smazat stopy.
3. Omezit přístup ke čtení a sám ho protokolovat. Logy obsahují téměř vždy osobní údaje.
4. Rozpoznat výpadek: Pokud je log náhle prázdný, je to varovné znamení.
5. Sladit čas: Všechny servery přebírají čas ze stejného zdroje a do logu zapisují jednoznačné časové pásmo. Jinak lze záznamy webserveru, PHP a databáze po incidentu jen těžko složit do časové osy.

Uchovávání a ochranu osobních údajů rozhodnout vědomě

Jak dlouho smějí a musí logy zůstat, je vážení mezi bezpečnostním zájmem, šetřením daty a zákonnými či smluvními požadavky. Čl. 32 GDPR vyžaduje technická a organizační opatření přiměřená riziku, mimo jiné k trvalému zajištění důvěrnosti, integrity a dostupnosti systémů; protokolování k tomu může přispět. Zároveň se osobní údaje nesmějí ukládat déle, než je nutné.

Stanovte proto lhůtu pro každý druh logu, napište odůvodnění a obojí odsouhlaste se svým pověřencem pro ochranu osobních údajů. Pro probíhající vyšetřování může být nutné zajistit logy i nad rámec běžné lhůty. To by se pak mělo rovněž zdokumentovat. Tato stránka je obecná informace a není právním poradenstvím; při konkrétních otázkách pomohou pověřenec pro ochranu osobních údajů a advokát. Jak logy po útoku vyhodnotit, ukazuje Vyhodnocení logů webserveru po útoku.

Jak konkrétně pomáhá PHP SOS?

• Zkontrolujeme vaše stávající logy na hesla, tokeny a další data, která tam nepatří.
• PHP a aplikaci nastavíme tak, aby se chyby protokolovaly, ale nezobrazovaly.
• Zavedeme chráněnou kopii logů na odděleném systému.
• Prostřednictvím bezpečnostního monitoringu průběžně vyhodnocujeme bezpečnostně relevantní záznamy a nápadnosti hlásíme srozumitelně.

Závěr: Dobré logy jsou úsporné v obsahu a štědré v ochraně. Kdo dnes stanoví, co se protokoluje a co nikdy, bude mít v krizovém případě využitelné stopy a žádný další únik dat.

Časté dotazy

Zdroje

• OWASP: Logging Cheat Sheet
• PHP-FIG: standardy PSR
• Příručka PHP
• OWASP Top 10