# Droša žurnālēšana: kļūdu protokolēšana bez datu noplūdes

> Kļūdu un notikumu protokolēšana PHP bez paroļu, tokenu vai klientu datu izpaušanas: kas pieder žurnālā, kas ne un kā žurnālus aizsargāt.

Avots: https://phpsos.de/lv/blog/sicher-loggen-php/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi sakot:** Žurnālēšana PHP ar datu aizsardzības ievērošanu nozīmē: drošībai nozīmīgus notikumus fiksēt pilnībā, bet paroles, tokenus, sesiju identifikatorus un sensitīvus klientu datus nekad nerakstīt žurnālā. Kļūdām jānonāk protokolā, nevis uz ekrāna, žurnāli atrodas ārpus tīmekļa saknes un ir pasargāti no izmaiņām. Cik ilgi žurnāli paliek, jūs izlemjat apzināti kopā ar datu aizsardzības speciālistu.

## Starp pēdu nodrošināšanu un datu noplūdi

Pēc PHP2Shell specializētie mediji ieteica saglabāt tīmekļa servera žurnālus no 2026. gada 20. oktobra. Kas to gribēja īstenot, bieži konstatēja divas lietas. Vai nu žurnāli jau sen bija rotēti un dzēsti. Vai arī tie saturēja lietas, kam tur nekad nevajadzēja būt: pilnas veidlapu ievades, paroles no neveiksmīgām pieteikšanās, API atslēgas URL.

Abas ir problēma. Bez žurnāliem incidentu gandrīz nevar rekonstruēt. Ar pārāk daudz satura pats žurnāls kļūst par mērķi, jo kas iegūst piekļuvi serverim, to labprāt nolasa līdzi. Labs žurnālēšanas risinājums ir pa vidu: pietiekami pēdu meklēšanai, pēc iespējas mazāk aizsargājamo datu.

## Ko PHP lietojumprogrammai vajadzētu protokolēt

OWASP Logging Cheat Sheet min notikumus, kas ir svarīgi drošībai un izsekojamībai. Tipiskām PHP lietojumprogrammām tos var apkopot šādi:

| Žurnālā | Ne žurnālā |
|---|---|
| sekmīgas un neveiksmīgas pieteikšanās | paroles, arī nepareizi ievadītas |
| neveiksmīgas atļauju pārbaudes | sesiju identifikatori atklātā tekstā |
| izmaiņas kontos un tiesībās | piekļuves tokeni un API atslēgas |
| ievades pārbaudes kļūdas | piekļuves dati datubāzei |
| augšupielādes, importi un eksporti | maksājumu un bankas dati |
| konfigurācijas izmaiņas, starts un apstāšanās | veselības dati un citi īpaši aizsargājami dati |
| izpildes laika kļūdas ar vietu, bez lietderīgajiem datiem | pilns veidlapu saturs |

Katram ierakstam jāatbild uz jautājumiem kad, kur, kas un ko: laika zīmogs, lietojumprogramma un resursdators, avota adrese, lietotāja identifikators, notikuma veids un rezultāts. Vārdus vai e-pasta adreses bieži var maskēt vai aizstāt ar iekšēju identifikatoru, nezaudējot lietderību.

Divus nevēlamu datu avotus žurnālā bieži nepamana. Pirmais ir URL: ja query string ir tokens, paroles atiestatīšanas atslēga vai e-pasta adrese, tā automātiski nonāk tīmekļa servera piekļuves žurnālā, starpniekservera žurnālos un pārlūka vēsturē. Šādas vērtības pieder pieprasījuma ķermenim vai galvenei, nevis adresei. Otrs avots ir atkļūdošanas režīms. Ietvari un spraudņi atkļūdošanas darbībā bieži raksta līdzi pilnus pieprasījumus, datubāzes vaicājumus un vides mainīgos. Ja šis režīms pēc kļūdu meklēšanas paliek aktīvs, nemanot aug fails ar tieši to informāciju, ko uzbrucējs meklē. Pārbaudiet pēc katras kļūdu meklēšanas, vai atkļūdošanas izvade ir atkal izslēgta, un izdzēsiet tā radušos failus.

## Žurnālēšana PHP: pamatiestatījumi

Pirmais līmenis ir pats PHP. Ražošanā kļūdas jāprotokolē, bet nedrīkst izvadīt. Žurnāls atrodas ārpus tīmekļa saknes, lai to nevarētu atvērt pa URL.

```ini
; php.ini vai FPM pūls ražošanai
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log
```

Kāpēc redzamas kļūdas ir bīstamas, apraksta [Kļūdu izvades izslēgšana ražošanā](https://phpsos.de/lv/blog/display-errors-produktion/). Kā PHP kļūdas un izņēmumi savstarpēji saistīti, skaidro [Kļūdas un izņēmumi PHP](https://phpsos.de/lv/php/fehler-und-exceptions/).

Otrais līmenis ir lietojumprogramma. Daudzi ietvari šim nolūkam izmanto bibliotēku pēc PHP-FIG standarta PSR-3, kas nosaka vienotu žurnālētāja saskarni. Svarīga nav bibliotēka, bet disciplīna: konteksta datus izvēlēties apzināti, nevis rakstīt žurnālā veselus pieprasījumus vai objektus.

```php
<?php
// Ievadi pirms žurnālēšanas padarīt nekaitīgu un maskēt
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'] ?? '',
    // nekad: 'passwort' => $_POST['passwort']
]);
```

## Log injection un manipulēti ieraksti

Ja lietojumprogramma ievadi raksta žurnālā nefiltrētu, uzbrucējs ar rindu pārtraukumiem var radīt viltotus ierakstus. Tas mulsina izvērtēšanu un var aizsegt pēdas. OWASP Cheat Sheet iesaka strukturētus formātus, piemēram, JSON, rindu pārtraukumu noņemšanu vai kodēšanu un garuma ierobežojumu ievadei žurnālā.

Tikpat svarīga ir pašu žurnālu aizsardzība:

1. **Glabāšana ārpus tīmekļa saknes** un ar tiesībām, kas tīmekļa servera lietotājam vajadzīgas rakstīšanai, bet ne veco failu dzēšanai.
2. **Kopija otrā sistēmā**, piemēram, ar Syslog pa šifrētu savienojumu. Kas pārņem serveri, tam nevajadzētu varēt vienkārši izdzēst pēdas.
3. **Ierobežot lasīšanas piekļuvi** un pašu to žurnālēt. Žurnāli gandrīz vienmēr satur personas datus.
4. **Atpazīt pārtraukumu:** ja žurnāls pēkšņi paliek tukšs, tas ir brīdinājuma signāls.
5. **Saskaņot pulksteņa laiku:** visi serveri laiku ņem no viena avota un žurnālā raksta viennozīmīgu laika joslu. Citādi tīmekļa servera, PHP un datubāzes ierakstus pēc incidenta gandrīz nevar saliktu laika joslā.

> **Svarīgi:**
> Žurnāls, kas atrodas tikai kompromitētajā serverī, kā pierādījums ir vājš. Darbojoša kopija atsevišķā sistēmā pēc incidenta bieži ir vienīgais uzticamais avots.

## Glabāšanas laiku un datu aizsardzību izlemt apzināti

Cik ilgi žurnāli drīkst un tiem jāpaliek, ir izsvēršana starp drošības interesēm, datu minimizēšanu un likumiskām vai līgumiskām prasībām. VDAR 32. pants pieprasa riskam atbilstošus tehniskus un organizatoriskus pasākumus, cita starpā lai ilgstoši nodrošinātu sistēmu konfidencialitāti, integritāti un pieejamību; protokolēšana to var veicināt. Vienlaikus personas datus nedrīkst glabāt ilgāk nekā nepieciešams.

Tāpēc katram žurnāla veidam nosakiet termiņu, pierakstiet pamatojumu un abus saskaņojiet ar savu datu aizsardzības speciālistu. Notiekošai izmeklēšanai var būt nepieciešams žurnālus saglabāt ilgāk par parasto termiņu. Arī tas jādokumentē. Šī lapa ir vispārīga informācija, nevis juridiska konsultācija; konkrētos jautājumos palīdz datu aizsardzības speciālisti un jurists. Kā žurnālus pēc uzbrukuma izvērtēt, rāda [Tīmekļa servera žurnālu izvērtēšana pēc uzbrukuma](https://phpsos.de/lv/ratgeber/logfiles-auswerten/).

## Kā PHP SOS palīdz konkrēti?

- Mēs pārbaudām jūsu esošos žurnālus uz parolēm, tokeniem un citiem datiem, kam tur nav vietas.
- Mēs iestatām PHP un lietojumprogrammu tā, lai kļūdas tiktu protokolētas, bet nerādītas.
- Mēs ierīkojam aizsargātu žurnālu kopiju atsevišķā sistēmā.
- Ar [drošības monitoringu](https://phpsos.de/lv/leistungen/security-monitoring/) mēs pastāvīgi izvērtējam drošībai nozīmīgus ierakstus un par atrasto ziņojam saprotami.

**Secinājums:** Labi žurnāli ir taupīgi saturā un devīgi aizsardzībā. Kas šodien nosaka, kas tiek protokolēts un kas nekad, tam ārkārtas gadījumā ir izmantojamas pēdas un nav papildu datu noplūdes.


## Biežāk uzdotie jautājumi

**Vai IP adreses drīkst atrasties žurnālfailos?**  
IP adreses var būt personas dati. Vai un cik ilgi tās glabājat, atkarīgs no mērķa un tiesiskā pamata. Apjomu un glabāšanas laiku noskaidrojiet ar savu datu aizsardzības speciālistu; šī lapa nav juridiska konsultācija.

**Cik ilgi jāglabā žurnāli?**  
Tik ilgi, cik tas nepieciešams drošībai un kļūdu meklēšanai un ir tiesiski pieļaujams, un ne ilgāk. Pēc PHP2Shell speciālistu prese ieteica saglabāt tīmekļa servera žurnālus no 2026. gada 20. oktobra. Termiņus nosakiet apzināti un dokumentējiet.

**Kas ir Log injection?**  
Ja ievadē ir rindu pārtraukumi vai vadības rakstzīmes un tā tiek rakstīta žurnālā nefiltrēta, tā var radīt viltotus ierakstus. Tas sagroza izvērtējumus. To novērš strukturēti formāti, piemēram, JSON, un rindu pārtraukumu noņemšana.

**Vai display_errors ražošanā jābūt izslēgtam?**  
Jā. Kļūdām jānonāk žurnālā, nevis izvadē apmeklētājiem. Redzami kļūdu ziņojumi izpauž ceļus, vaicājumus un reizēm piekļuves datus.

## Avoti

- [OWASP: Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
- [PHP-FIG: PSR standarti](https://www.php-fig.org/)
- [PHP rokasgrāmata](https://www.php.net/manual/de/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)