Bezpečné logovanie: protokolovať chyby bez úniku údajov

Stručne: Logovanie v PHP s ohľadom na ochranu údajov znamená: bezpečnostne relevantné udalosti zachytiť úplne, heslá, tokeny, identifikátory relácií a citlivé údaje zákazníkov však nikdy nezapisovať do logu. Chyby patria do protokolu, nie na obrazovku, logy ležia mimo webového koreňa a sú chránené pred zmenou. Ako dlho logy zostanú, rozhodnete vedome spolu so zodpovedným pracovníkom pre ochranu údajov.

Medzi zabezpečením stôp a únikom údajov

Po PHP2Shell radili odborné médiá uchovávať logy webservera od 20. 10. 2026. Kto to chcel zaviesť, často zistil dvojaké. Buď sa logy dávno rotovali a zmazali. Alebo obsahovali veci, ktoré tam nikdy nemali byť: úplné vstupy z formulárov, heslá z neúspešných prihlásení, kľúče API v URL.

Obe je problém. Bez logov sa incident len ťažko rekonštruuje. S priveľkým obsahom sa stane cieľom samotný log, pretože kto získa prístup na server, rád si ho prečíta. Dobré logovanie leží medzi tým: dosť na hľadanie stôp, čo najmenej chránených údajov.

Čo by mala aplikácia PHP protokolovať

OWASP Logging Cheat Sheet uvádza udalosti, ktoré sú dôležité pre bezpečnosť a dohľadateľnosť. Pre typické aplikácie PHP sa dajú zhrnúť takto:

Každý záznam by mal odpovedať na otázky kedy, kde, kto a čo: časová pečiatka, aplikácia a hostiteľ, zdrojová adresa, identifikátor používateľa, druh udalosti a výsledok. Mená alebo e-mailové adresy sa často dajú maskovať alebo nahradiť interným identifikátorom bez straty užitočnosti.

Dva zdroje nechcených údajov v logu sa často prehliadnu. Prvým sú URL: ak stojí token, kľúč na reset hesla alebo e-mailová adresa v query stringu, automaticky skončí v access logu webservera, v logoch proxy a v histórii prehliadača. Takéto hodnoty patria do tela požiadavky alebo do hlavičky, nie do adresy. Druhým zdrojom je režim ladenia (debug). Frameworky a pluginy v režime ladenia často zapisujú úplné požiadavky, databázové dotazy a premenné prostredia. Ak tento režim zostane po hľadaní chyby aktívny, nepozorovane narastá súbor práve s tými informáciami, ktoré útočník hľadá. Po každom hľadaní chyby skontrolujte, či sú ladiace výstupy opäť vypnuté, a súbory, ktoré pritom vznikli, zmažte.

Logovanie v PHP: základné nastavenia

Prvou úrovňou je samotné PHP. V produkcii sa majú chyby protokolovať, ale nevypisovať. Log leží mimo webového koreňa, aby nebol dostupný cez URL.

; php.ini alebo pool FPM pre produkciu
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Prečo sú viditeľné chyby nebezpečné, opisuje Vypnutie výpisu chýb v produkcii. Ako súvisia chyby a výnimky v PHP, vysvetľuje Chyby a výnimky v PHP.

Druhou úrovňou je aplikácia. Mnohé frameworky na to používajú knižnicu podľa štandardu PSR-3 od PHP-FIG, ktorý určuje jednotné rozhranie loggera. Dôležitá nie je knižnica, ale disciplína: kontextové údaje vyberať vedome, namiesto zapisovania celých požiadaviek alebo objektov do logu.

<?php
// Vstupy pred zalogovaním zneškodniť a maskovať
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

Ak aplikácia zapisuje vstupy do logu nefiltrované, môže útočník pomocou zalomení riadkov vytvoriť sfalšované záznamy. To mätie vyhodnotenie a môže zakryť stopy. OWASP Cheat Sheet odporúča štruktúrované formáty ako JSON, odstraňovanie alebo kódovanie zalomení riadkov a obmedzenie dĺžky vstupov v logu.

Rovnako dôležitá je ochrana samotných logov:

1. Uloženie mimo webového koreňa a s právami, ktoré používateľ webservera potrebuje na zápis, ale nie na mazanie starých súborov.
2. Kópia na druhý systém, napríklad cez Syslog cez šifrované spojenie. Kto server prevezme, nemá môcť stopy jednoducho zmazať.
3. Obmedziť prístup na čítanie a sám ho protokolovať. Logy obsahujú takmer vždy osobné údaje.
4. Rozpoznať výpadok: ak je log zrazu prázdny, je to varovný signál.
5. Zosúladiť čas: všetky servery preberajú čas z toho istého zdroja a zapisujú do logu jednoznačné časové pásmo. Inak sa záznamy webservera, PHP a databázy po incidente len ťažko zložia do časovej osi.

Uchovávanie a ochranu údajov rozhodnúť vedome

Ako dlho smú a musia logy zostať, je vyváženie medzi bezpečnostným záujmom, minimalizáciou údajov a zákonnými alebo zmluvnými požiadavkami. Čl. 32 GDPR vyžaduje technické a organizačné opatrenia primerané riziku, okrem iného na trvalé zabezpečenie dôvernosti, integrity a dostupnosti systémov; protokolovanie k tomu môže prispieť. Zároveň sa osobné údaje nesmú uchovávať dlhšie, než je nutné.

Určte preto lehotu pre každý druh logu, zapíšte zdôvodnenie a oboje odsúhlaste so svojím zodpovedným pracovníkom pre ochranu údajov. Pre prebiehajúce vyšetrovanie môže byť nutné zabezpečiť logy nad rámec bežnej lehoty. To by sa malo tiež zdokumentovať. Táto stránka je všeobecná informácia a nie právne poradenstvo; pri konkrétnych otázkach pomôže zodpovedný pracovník pre ochranu údajov a právnik. Ako logy po útoku vyhodnotiť, ukazuje Vyhodnotenie protokolov webservera po útoku.

Ako konkrétne pomáha PHP SOS?

• Preveríme vaše existujúce logy na heslá, tokeny a iné údaje, ktoré tam nepatria.
• PHP a aplikáciu nastavíme tak, aby sa chyby protokolovali, ale nezobrazovali.
• Zavedieme chránenú kópiu logov na oddelenom systéme.
• Cez Security Monitoring priebežne vyhodnocujeme bezpečnostne relevantné záznamy a nápadnosti hlásime zrozumiteľne.

Záver: Dobré logy sú šetrné pri obsahu a štedré pri ochrane. Kto dnes určí, čo sa protokoluje a čo nikdy, má v kritickom prípade použiteľné stopy a nie dodatočný únik údajov.

Časté otázky

Zdroje

• OWASP: Logging Cheat Sheet
• PHP-FIG: štandardy PSR
• Príručka PHP
• OWASP Top 10