# Verkkopalvelimen tiedosto-oikeudet

> Verkkopalvelimen tiedosto-oikeudet oikein: erilliset omistajat, 640 eikä 777, kirjoitusoikeus vain latauksille ja välimuistille. Mukana tarkistuskomennot.

Lähde: https://phpsos.de/fi/ratgeber/dateirechte-webserver/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** Verkkopalvelimen tiedosto-oikeuksissa pätee yksi perusperiaate: käyttäjä, jonka alla PHP toimii, saa lukea omaa koodiaan mutta ei muuttaa sitä. Kirjoitusoikeuden saavat vain upload-, välimuisti- ja tmp-kansiot, eikä niissä suoriteta PHP:tä. Oikeuksilla kuten 777 ei ole tuotantopalvelimella mitään sijaa.

## Miksi tiedosto-oikeudet ratkaisevat murron jälkeen

Kun hyökkääjät suorittavat aukon kautta koodia palvelimella, koodi toimii PHP-prosessin oikeuksilla. Mitä tämä käyttäjä saa tehdä, sen saa tehdä hyökkääjäkin. Juuri tässä ratkaistaan, muuttuuko murto pysyväksi takaovekseksi.

PHP2Shellin myötä tämä skenaario on lokakuussa 2026 tullut hyvin konkreettiseksi. Haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen ilman kirjautumista. Ne on korjattu 21.10.2026 alkaen versioissa PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Hyvät tiedosto-oikeudet eivät estä hyökkäystä, mutta ne estävät lisättyä koodia kirjoittamasta sovellustanne pysyvästi uusiksi.

Monissa asennuksissa koko koodi kuuluu verkkopalvelimen käyttäjälle, jotta päivitykset toimivat painikkeen painalluksella. Se on kätevää, mutta täsmälleen se asetelma, jota hyökkääjät etsivät.

## Perusperiaate: erottakaa omistaja ja ajokäyttäjä

Järkevä jako on kaksi roolia. Omistaja, esimerkiksi deploy-käyttäjä, omistaa tiedostot ja asentaa päivitykset. PHP-prosessi toimii toisen käyttäjän alla ja saa ryhmän kautta vain lukuoikeuden.

| Alue | Omistaja : ryhmä | Tiedostojen oikeudet | Kansioiden oikeudet |
|---|---|---|---|
| Ohjelmakoodi | deploy : seite1 | 640 | 750 |
| Asetukset ja salasanat | deploy : seite1 | 640 | – |
| Uploadit, välimuisti, tmp | seite1 : seite1 | 640 | 750 |
| Lokit | root tai seite1 | 640 | 750 |

Itse verkkopalvelin, esimerkiksi Nginx, tarvitsee PHP-FPM:n kanssa vain lukuoikeuden staattisiin tiedostoihin kuten kuviin ja CSS:ään. Sen saatte ryhmän tai kohdennetun pääsysäännön kautta. Jos ylläpidätte useita verkkosivustoja, antakaa jokaiselle oma ajokäyttäjä; miten se toimii yhdessä poolien kanssa, kerrotaan oppaassa [open_basedir ja sivustokohtainen eristys](https://phpsos.de/fi/ratgeber/open-basedir/).

## Tiedosto-oikeuksien tarkistus verkkopalvelimella

Ennen kuin muutatte mitään, hankkikaa yleiskuva. Seuraavat komennot eivät muuta mitään.

```bash
# Minkä käyttäjän alla PHP-prosessit toimivat?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c

# Kaikille kirjoitettavat tiedostot ja kansiot
find /var/www -perm -o+w -ls

# Verkkopalvelimen käyttäjän omistamat tiedostot (esimerkkinä www-data)
find /var/www -user www-data -type f -name "*.php" | head -50

# Asetustiedostojen oikeudet
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
```

Kaikille kirjoitettavat kohteet ovat lähes aina virhe. PHP-tiedostot, jotka kuuluvat ajokäyttäjälle, osoittavat, että tämä voi muuttaa omaa koodiaan. Huomiota herättävät myös yksittäiset tiedostot, joiden omistaja tai oikeudet poikkeavat viereisistä tiedostoista. Se voi viitata lisättyihin tiedostoihin, kuten kuvataan oppaassa [Web shellien tunnistaminen ja poistaminen](https://phpsos.de/fi/ratgeber/webshell-erkennen/).

## Oikeuksien korjaaminen vaihe vaiheelta

Muuttakaa oikeuksia vain varmuuskopioinnin jälkeen ja mahdollisuuksien mukaan ensin testiympäristössä. Jos epäilette murtoa, varmistakaa jäljet ensin, sillä omistaja ja aikaleimat ovat silloin todisteita.

```bash
SITE=/var/www/seite1
# Omistaja: deploy-käyttäjä, ryhmä: ajokäyttäjä
sudo chown -R deploy:seite1 "$SITE"
# Kansiot 750, tiedostot 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Vain näihin kansioihin PHP saa kirjoittaa (muokkaa polut sovellukseen)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
```

Tarkistakaa sen jälkeen verkkosivusto kokonaan: etusivu, kirjautuminen, lomakkeet, kuvan lataus, välimuistit. Mihin kansioihin sovelluksen on saatava kirjoittaa, kerrotaan valmistajan järjestelmävaatimuksissa sen virallisella sivulla.

> **Tärkeää:**
> `chmod -R 777` ongelman nopeaksi ratkaisemiseksi avaa palvelimen jokaiselle paikalliselle käyttäjälle ja jokaiselle lisätylle prosessille. Korjatkaa sen sijaan omistaja ja ryhmä.

## PHP:n suorituksen estäminen kirjoitettavissa kansioissa

Kirjoitusoikeudet ovat vain puoliksi niin vaarallisia, jos siellä ei voi ajaa koodia. Estäkää PHP:n suoritus upload- ja välimuistikansioissa verkkopalvelimen tasolla. Apachessa VirtualHost-asetuksissa:

```apache
<Directory "/var/www/seite1/public/uploads">
    <FilesMatch "\.(php|phtml|phar)$">
        Require all denied
    </FilesMatch>
</Directory>
```

Nginxissä riittää `location`-lohko, joka hylkää pyynnöt PHP-tiedostoihin näissä kansioissa. Sääntö kuuluu palvelimen asetuksiin, ei upload-kansion `.htaccess`-tiedostoon, jonka hyökkääjä voisi kirjoitusoikeudella muuttaa takaisin.

Lisäksi kannattaa katsoa deploy-käyttäjän `umask`-arvoa, jotta uusia tiedostoja ei luoda automaattisesti liian avoimina. Arvo `027` tuottaa tiedostoille 640 ja kansioille 750. Omilla palvelimilla tämä vastuu on kokonaan teillä; mitä siihen muuten kuuluu, kuvataan sivulla [Root-palvelimen ja vServerin suojaaminen itse](https://phpsos.de/fi/server/root-server-vserver/).

## Erikoistapaukset: hosting-paneelit, jaettu hosting ja deploymentit

Kaikkia palvelimia ei voi konfiguroida oppikirjan mukaan. Hosting-paneelit kuten Plesk tai cPanel luovat omat käyttäjänsä ja oikeutensa ja palauttavat ne joissakin toiminnoissa. Muuttakaa oikeuksia siellä mieluiten paneelin toiminnoilla tai tarkistakaa paneelipäivitysten jälkeen, ovatko asetuksenne yhä voimassa.

Jaetussa hostingissa teillä on yleensä vain yksi käyttäjä kaikkeen. Omistajan ja ajokäyttäjän erotus ei silloin ole mahdollista. Sitä tärkeämpiä ovat niukat oikeudet asetustiedostoille, ei 777-oikeuksia ja PHP:n suorituksen estäminen upload-kansioissa, kunhan hosting-yritys sen sallii.

Jos käytätte automaattisia deploymenteja, oikeudet kannattaa asettaa deployment-komentosarjassa itsessään. Muuten jokainen uusi versio palauttaa vanhan, liian avoimen tilan. Lyhyt tarkistus deploymentin lopussa, esimerkiksi yllä olevalla kirjoitettavien tiedostojen komennolla, pysäyttää tällaiset takaiskut luotettavasti ja sen voi lisätä mihin tahansa putkeen ilman suurta vaivaa.

## Miten PHP SOS auttaa konkreettisesti?

- Kartoitamme palvelimen kaikkien verkkosivustojen omistajat, oikeudet ja ajokäyttäjät.
- Määrittelemme oikeuskonseptin, joka sopii sovellukseenne ja päivitystapaanne.
- Toteutamme oikeudet ja suoritusestot ja testaamme verkkosivuston sen jälkeen kokonaan.
- Dokumentoimme konseptin, jottei deploymentit ja päivitykset heikennä sitä uudelleen.

Miten tämä liittyy pysyvään suojaukseen, kuvaa palvelu [PHP-verkkopalvelimen koventaminen](https://phpsos.de/fi/leistungen/server-haertung/).


## Usein kysytyt kysymykset

**Ovatko 777-oikeudet koskaan hyväksyttäviä?**  
Tuotantopalvelimella käytännössä eivät koskaan. Oikeuksilla 777 jokainen järjestelmän käyttäjä voi luoda ja muuttaa tiedostoja. Jos sovellus ei toimi ilman oikeuksia 777, vika on yleensä väärin asetettu omistaja, ei liian niukat oikeudet.

**Miksi verkkopalvelimen ei pitäisi saada muuttaa omia tiedostojaan?**  
Koska lisätty koodi toimii verkkopalvelimen oikeuksilla. Jos verkkopalvelin saa kirjoittaa PHP-tiedostoja, hyökkääjä voi manipuloida olemassa olevia komentosarjoja tai luoda uusia takaovia. Kun omistaja ja ajokäyttäjä erotetaan, koodi pysyy kirjoitussuojattuna.

**Miten päivitän CMS:n, jos verkkopalvelin ei saa kirjoittaa?**  
Päivitykset tehdään silloin omistajan kautta, esimerkiksi WP-CLI:llä, Composerilla tai deploymentilla, ei hallintapaneelin päivityspainikkeella. Se on hieman työläämpää, mutta lisätty koodi ei voi muuttaa ohjelmatiedostoja.

**Mitkä oikeudet tarvitsee asetustiedosto, jossa on tietokannan salasana?**  
Mahdollisimman vähän: luettavissa PHP-käyttäjälle, ei kenellekään muulle. Tavallisia ovat 640 sopivalla ryhmällä tai 400, jos PHP-käyttäjä on itse omistaja.

## Lähteet

- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: tietoturvatiedotteet](https://www.php.net/)