Lühidalt: Logimine PHP-s andmekaitset silmas pidades tähendab: turvaküsimustega seotud sündmused tuleb täielikult talletada, kuid paroole, tokeneid, sessioonitunnuseid ja tundlikke kliendiandmeid ei kirjutata kunagi logisse. Vead kuuluvad logisse, mitte ekraanile, logid asuvad väljaspool veebijuurkataloogi ja on muutmise vastu kaitstud. Kui kaua logid säilivad, otsustate teadlikult koos andmekaitsespetsialistiga.
Jälgede kindlustamise ja andmelekke vahel
Pärast PHP2Shelli soovitasid erialameediad säilitada veebiserveri logisid alates 20. oktoobrist 2026. Kes seda tahtis teha, märkas sageli kahte asja. Kas logid olid ammu pööratud ja kustutatud. Või sisaldasid need asju, mis ei oleks kunagi seal tohtinud olla: täielikud vormisisendid, ebaõnnestunud sisselogimiste paroolid, URL-ides olevad API-võtmed.
Mõlemad on probleem. Ilma logideta saab intsidenti vaevalt rekonstrueerida. Liiga suure sisuga muutub logi ise sihtmärgiks, sest kes serveri ligipääsu saab, loeb seda meelsasti kaasa. Hea logimine asub vahepeal: piisavalt jälgede otsimiseks, nii vähe kaitset väärivaid andmeid kui võimalik.
Mida PHP-rakendus peaks logima
OWASP Logging Cheat Sheet nimetab sündmusi, mis loevad turvalisuse ja jälgitavuse jaoks. Tüüpiliste PHP-rakenduste jaoks võib need kokku võtta nii:
| Logisse | Mitte logisse |
|---|---|
| edukad ja ebaõnnestunud sisselogimised | paroolid, ka valesti sisestatud |
| ebaõnnestunud õiguste kontrollid | sessioonitunnused selge tekstina |
| muudatused kontodes ja õigustes | Access-tokenid ja API-võtmed |
| sisendi kontrolli vead | andmebaasi ligipääsuandmed |
| üleslaadimised, impordid ja ekspordid | maksete ja pangaandmed |
| konfiguratsioonimuudatused, käivitamine ja peatamine | terviseandmed ja muud eriti kaitset väärivad andmed |
| tööaja vead koha, kuid ilma kasutajaandmeteta | täielikud vormisisud |
Iga kirje peaks vastama küsimustele millal, kus, kes ja mis: ajatempel, rakendus ja host, lähteaadress, kasutajatunnus, sündmuse liik ja tulemus. Nimesid või meiliaadresse saab sageli maskeerida või asendada sisemise tunnusega, kasulikkust kaotamata.
Kaks soovimatute andmete allikat logis jäetakse sageli märkamata. Esimene on URL-id: kui token, parooli lähtestamise võti või meiliaadress asub päringustringis, satub see automaatselt veebiserveri juurdepääsulogisse, proksi logidesse ja brauseri ajalukku. Sellised väärtused kuuluvad päringu kehasse või päisesse, mitte aadressi. Teine allikas on silumisrežiim. Raamistikud ja pistikprogrammid kirjutavad silumisrežiimis sageli kaasa täielikke päringuid, andmebaasipäringuid ja keskkonnamuutujaid. Kui see režiim jääb pärast vigade otsimist aktiivseks, kasvab märkamatult fail täpselt nende andmetega, mida ründaja otsib. Kontrollige pärast iga vigade otsimist, kas silumisväljundid on taas välja lülitatud, ja kustutage seejuures tekkinud failid.
Logimine PHP-s: põhisätted
Esimene tase on PHP ise. Tootmises tuleb vigu logida, kuid mitte väljastada. Logi asub väljaspool veebijuurkataloogi, et see ei oleks URL-i kaudu kättesaadav.
; php.ini või FPM-pool tootmise jaoks
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log
Miks nähtavad vead on ohtlikud, kirjeldab Veaväljundite väljalülitamine tootmises. Kuidas vead ja erandid PHP-s kokku hõlmavad, selgitab Vead ja erandid PHP-s.
Teine tase on rakendus. Paljud raamistikud kasutavad selleks PHP-FIG-i standardi PSR-3 järgi teeki, mis määrab ühtse logija liidese. Oluline ei ole teek, vaid distsipliin: valige kontekstiandmed teadlikult, selle asemel et kirjutada logisse terveid päringuid või objekte.
<?php
// Sisendid enne logimist neutraliseerida ja maskeerida
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'] ?? '',
// mitte kunagi: 'passwort' => $_POST['passwort']
]);
Log-injection ja manipuleeritud kirjed
Kui rakendus kirjutab sisendid filtreerimata logisse, saab ründaja reavahetustega luua võltsitud kirjeid. See segab hindamist ja võib jälgi varjata. OWASP Cheat Sheet soovitab struktureeritud vorminguid, nagu JSON, reavahetuste eemaldamist või kodeerimist ning logis olevate sisendite pikkuse piiramist.
Sama oluline on logide enda kaitse:
- Salvestus väljaspool veebijuurkataloogi ja õigustega, mida veebiserveri kasutaja vajab kirjutamiseks, kuid mitte vanade failide kustutamiseks.
- Koopia teisele süsteemile, näiteks Syslogi kaudu krüpteeritud ühenduse kaudu. Kes serveri üle võtab, ei tohi jälgi lihtsalt kustutada saada.
- Piirake lugemisligipääsu ja logige seda ise. Logid sisaldavad peaaegu alati isikuandmeid.
- Tuvastage rike: Kui logi muutub järsku tühjaks, on see hoiatusmärk.
- Ühtlustage kellaaeg: Kõik serverid võtavad aja samast allikast ja kirjutavad logisse ühemõttelise ajavööndi. Muidu saab veebiserveri, PHP ja andmebaasi kirjeid pärast intsidenti vaevalt ajajoonele kokku panna.
Logi, mis asub ainult kompromiteeritud serveris, on tõendina nõrk. Töötav koopia eraldi süsteemil on pärast intsidenti sageli ainus usaldusväärne allikas.
Säilitamise ja andmekaitse üle otsustada teadlikult
Kui kaua logid tohivad ja peavad säilima, on kaalutlus turvahuvi, andmete minimeerimise ning õiguslike või lepinguliste nõuete vahel. IKÜM art 32 nõuab riskiga proportsionaalseid tehnilisi ja korralduslikke meetmeid, muu hulgas süsteemide konfidentsiaalsuse, terviklikkuse ja kättesaadavuse püsivaks tagamiseks; logimine võib selleks kaasa aidata. Samal ajal ei tohi isikuandmeid säilitada kauem kui vaja.
Määrake seetõttu iga logiliigi jaoks tähtaeg, kirjutage põhjendus üles ja kooskõlastage mõlemad oma andmekaitsespetsialistiga. Käimasoleva uurimise jaoks võib olla vajalik logisid üle tavapärase tähtaja kindlustada. Ka seda tuleks siis dokumenteerida. See leht on üldine teave ja ei ole õigusnõustamine; konkreetsete küsimuste korral aitavad andmekaitsespetsialistid ja advokaat. Kuidas logisid pärast rünnakut hinnata, näitab Veebiserveri logide hindamine pärast rünnakut.
Kuidas PHP SOS konkreetselt aitab?
- Me kontrollime teie olemasolevaid logisid paroolide, tokenite ja muude andmete suhtes, mis sinna ei kuulu.
- Me seadistame PHP ja rakenduse nii, et vigu logitakse, kuid ei näidata.
- Me seadistame logide kaitstud koopia eraldi süsteemis.
- Turbemonitooringu kaudu hindame turvaküsimustega seotud kirjeid pidevalt ja teatame märkimisväärsest arusaadavalt.
Kokkuvõte: Head logid on sisu poolest kokkuhoidlikud ja kaitse poolest heldelt. Kes määrab täna kindlaks, mida logitakse ja mida mitte kunagi, saab hädaolukorras kasutatavad jäljed ega saa lisaks andmelekke.
Korduma kippuvad küsimused
Kas IP-aadressid tohivad logifailides olla?
IP-aadressid võivad olla isikuandmed. See, kas ja kui kaua te neid salvestate, sõltub eesmärgist ja õiguslikust alusest. Selgitage maht ja säilitamine oma andmekaitsespetsialistiga; see leht ei ole õigusnõustamine.
Kui kaua tuleks logisid säilitada?
Nii kaua, kui see on turvalisuse ja vigade otsimise jaoks vajalik ning õiguslikult lubatud, ja mitte kauem. Pärast PHP2Shelli soovitas erialaajakirjandus säilitada veebiserveri logisid alates 20. oktoobrist 2026. Määrake tähtajad teadlikult ja dokumenteerige need.
Mis on log-injection?
Kui sisend sisaldab reavahetusi või juhtmärke ja kirjutatakse logisse filtreerimata, võib see luua võltsitud kirjeid. See moonutab hindamisi. Struktureeritud vormingud, nagu JSON, ja reavahetuste eemaldamine hoiavad seda ära.
Kas display_errors peaks tootmises olema välja lülitatud?
Jah. Vead peavad minema logisse, mitte külastajatele väljundisse. Nähtavad veateated reedavad teid, päringuid ja vahel ligipääsuandmeid.