Lyhyesti: Lokitus PHP:ssä tietosuoja huomioiden tarkoittaa: tietoturvan kannalta olennaiset tapahtumat kirjataan kattavasti, mutta salasanoja, tokeneita, sessiotunnuksia ja arkaluonteisia asiakastietoja ei koskaan kirjoiteta lokiin. Virheiden kuuluu mennä lokiin, ei näytölle, lokit sijaitsevat verkkojuuren ulkopuolella ja ne on suojattu muutoksilta. Kuinka kauan lokit säilytetään, päätätte tietoisesti yhdessä tietosuojavastaavan kanssa.
Jälkien varmistuksen ja tietovuodon välissä
PHP2Shellin jälkeen ammattimediat neuvoivat säilyttämään verkkopalvelinten lokit 20.10.2026 alkaen. Joka halusi toteuttaa tämän, huomasi usein kahta asiaa. Joko lokit oli kierrätetty ja poistettu jo kauan sitten. Tai niissä oli asioita, joiden ei olisi koskaan pitänyt olla siellä: kokonaisia lomakesyötteitä, epäonnistuneiden kirjautumisten salasanoja, API-avaimia URL-osoitteissa.
Molemmat ovat ongelma. Ilman lokeja tapahtumaa on vaikea rekonstruoida. Liian suuren sisällön kanssa loki muuttuu itse kohteeksi, sillä joka saa pääsyn palvelimelle, lukee sen mielellään mukana. Hyvä lokitus on siinä välissä: tarpeeksi jäljityksen kannalta, mahdollisimman vähän suojattavia tietoja.
Mitä PHP-sovelluksen pitäisi kirjata
OWASP Logging Cheat Sheet nimeää tapahtumat, jotka ovat tärkeitä tietoturvalle ja jäljitettävyydelle. Tyypillisille PHP-sovelluksille ne voi tiivistää näin:
| Lokiin | Ei lokiin |
|---|---|
| onnistuneet ja epäonnistuneet kirjautumiset | salasanat, myös väärin syötetyt |
| epäonnistuneet käyttöoikeustarkistukset | sessiotunnukset selkotekstinä |
| tilien ja oikeuksien muutokset | Access-tokenit ja API-avaimet |
| syötteiden tarkistuksen virheet | tietokannan tunnukset |
| uploadit, tuonnit ja viennit | maksu- ja pankkitiedot |
| konfiguraatiomuutokset, käynnistys ja pysäytys | terveystiedot ja muut erityisen suojattavat tiedot |
| ajonaikaiset virheet paikkoineen, ilman käyttötietoja | kokonaiset lomakkeiden sisällöt |
Jokaisen merkinnän tulisi vastata kysymyksiin milloin, missä, kuka ja mitä: aikaleima, sovellus ja isäntä, lähdeosoite, käyttäjätunniste, tapahtuman laji ja tulos. Nimet tai sähköpostiosoitteet voi usein maskata tai korvata sisäisellä tunnisteella hyötyä menettämättä.
Kaksi ei-toivottujen tietojen lähdettä jää usein huomaamatta. Ensimmäinen ovat URL-osoitteet: jos token, salasanan nollausavain tai sähköpostiosoite on kyselymerkkijonossa, se päätyy automaattisesti verkkopalvelimen Access-lokiin, välityspalvelinten lokeihin ja selainhistoriaan. Tällaiset arvot kuuluvat pyynnön runkoon tai otsikkoon, eivät osoitteeseen. Toinen lähde on debug-tila. Kehykset ja laajennukset kirjaavat debug-käytössä usein kokonaisia pyyntöjä, tietokantakyselyjä ja ympäristömuuttujia. Jos tämä tila jää päälle vianhaun jälkeen, kasvaa huomaamatta tiedosto, jossa on juuri ne tiedot, joita hyökkääjä etsii. Tarkistakaa jokaisen vianhaun jälkeen, onko debug-tulosteet kytketty takaisin pois, ja poistakaa niistä syntyneet tiedostot.
Lokitus PHP:ssä: perusasetukset
Ensimmäinen taso on PHP itse. Tuotannossa virheet kirjataan mutta ei tulosteta. Loki sijaitsee verkkojuuren ulkopuolella, jottei se ole haettavissa URL-osoitteella.
; php.ini tai FPM-pooli tuotantoon
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log
Miksi näkyvät virheet ovat vaarallisia, kuvaa Virhetulosteiden kytkeminen pois tuotannossa. Miten virheet ja poikkeukset liittyvät toisiinsa PHP:ssä, selittää Virheet ja poikkeukset PHP:ssä.
Toinen taso on sovellus. Monet kehykset käyttävät siihen PHP-FIG:n PSR-3-standardin mukaista kirjastoa, joka määrittelee yhtenäisen lokirajapinnan. Tärkeää ei ole kirjasto vaan kuri: valitkaa kontekstitiedot tietoisesti sen sijaan, että kirjaisitte lokiin kokonaisia pyyntöjä tai olioita.
<?php
// Neutraloi ja maskaa syötteet ennen lokitusta
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'] ?? '',
// älä koskaan: 'passwort' => $_POST['passwort']
]);
Lokin injektio ja manipuloidut merkinnät
Jos sovellus kirjoittaa syötteet suodattamattomina lokiin, hyökkääjä voi rivinvaihdoilla luoda väärennettyjä merkintöjä. Se hämmentää analyysiä ja voi peittää jälkiä. OWASPin Cheat Sheet suosittelee jäsenneltyjä muotoja kuten JSON, rivinvaihtojen poistamista tai koodausta ja lokin syötteiden pituusrajaa.
Yhtä tärkeää on itse lokien suojaus:
- Säilytys verkkojuuren ulkopuolella ja oikeuksilla, jotka verkkopalvelinkäyttäjä tarvitsee kirjoittamiseen mutta ei vanhojen tiedostojen poistamiseen.
- Kopio toiseen järjestelmään, esimerkiksi Syslogilla salatun yhteyden yli. Joka ottaa palvelimen haltuunsa, ei saa voida yksinkertaisesti poistaa jälkiä.
- Rajoittakaa lukuoikeus ja kirjatkaa se itse. Lokit sisältävät lähes aina henkilötietoja.
- Tunnistakaa katkos: Jos loki yhtäkkiä tyhjenee, se on varoitusmerkki.
- Tasatkaa kellonaika: Kaikki palvelimet hakevat ajan samasta lähteestä ja kirjoittavat lokiin yksiselitteisen aikavyöhykkeen. Muuten verkkopalvelimen, PHP:n ja tietokannan merkinnät on tapahtuman jälkeen vaikea yhdistää aikajanaksi.
Loki, joka on vain vaarantuneella palvelimella, on heikko todiste. Käynnissä oleva kopio erillisellä järjestelmällä on tapahtuman jälkeen usein ainoa luotettava lähde.
Säilytys ja tietosuoja: päättäkää tietoisesti
Kuinka kauan lokien saa ja pitää säilyä, on punninta tietoturvaintressin, tietojen minimoinnin ja lakisääteisten tai sopimusperusteisten vaatimusten välillä. GDPR:n 32 artikla edellyttää riskiin nähden asianmukaisia teknisiä ja organisatorisia toimenpiteitä, muun muassa järjestelmien luottamuksellisuuden, eheyden ja saatavuuden pysyväksi varmistamiseksi; lokitus voi edistää tätä. Samalla henkilötietoja ei saa säilyttää tarpeettoman pitkään.
Määritelkää siksi kullekin lokityypille määräaika, kirjatkaa perustelu ja sopikaa molemmat tietosuojavastaavanne kanssa. Käynnissä olevaa tutkintaa varten voi olla tarpeen varmistaa lokit normaalin määräajan yli. Se tulisi dokumentoida samoin. Tämä sivu on yleistä tietoa eikä oikeudellista neuvontaa; konkreettisissa kysymyksissä auttavat tietosuojavastaavat ja lakimies. Miten analysoitte lokit hyökkäyksen jälkeen, näyttää Verkkopalvelimen lokien analysointi hyökkäyksen jälkeen.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme olemassa olevat lokinne salasanojen, tokenien ja muiden sinne kuulumattomien tietojen varalta.
- Asetamme PHP:n ja sovelluksen niin, että virheet kirjataan mutta niitä ei näytetä.
- Otamme käyttöön suojatun kopion lokeista erillisellä järjestelmällä.
- Security-valvonnan kautta analysoimme tietoturvan kannalta olennaiset merkinnät jatkuvasti ja ilmoitamme havainnoista ymmärrettävästi.
Yhteenveto: Hyvät lokit ovat säästeliäitä sisällön suhteen ja anteliaita suojauksen suhteen. Joka määrittelee nyt, mitä kirjataan ja mitä ei koskaan, saa hätätilanteessa käyttökelpoiset jäljet eikä ylimääräistä tietovuotoa.
Usein kysytyt kysymykset
Saavatko IP-osoitteet olla lokitiedostoissa?
IP-osoitteet voivat olla henkilötietoja. Se, tallennatteko niitä ja kuinka kauan, riippuu tarkoituksesta ja oikeusperustasta. Selvittäkää laajuus ja säilytys tietosuojavastaavanne kanssa; tämä sivu ei ole oikeudellista neuvontaa.
Kuinka kauan lokeja pitäisi säilyttää?
Niin kauan kuin se on tarpeen tietoturvan ja vianhaun kannalta ja oikeudellisesti sallittua, ei pidempään. PHP2Shellin jälkeen ammattilehdistö suositteli säilyttämään verkkopalvelinten lokit 20.10.2026 alkaen. Määritelkää määräajat tietoisesti ja dokumentoikaa ne.
Mitä on lokin injektio (Log Injection)?
Jos syöte sisältää rivinvaihtoja tai ohjausmerkkejä ja se kirjoitetaan suodattamattomana lokiin, se voi luoda väärennettyjä merkintöjä. Se vääristää analyysejä. Jäsennellyt muodot kuten JSON ja rivinvaihtojen poistaminen estävät tämän.
Pitäisikö display_errors olla pois päältä tuotannossa?
Kyllä. Virheiden kuuluu mennä lokiin, ei kävijöille näytettävään tulosteeseen. Näkyvät virheilmoitukset paljastavat polkuja, kyselyjä ja joskus tunnuksia.