Kuidas Linuxis majutusteenuse kasutajaid turvaliselt isoleerida
Avaldatud 12. novembril 2026
Jagatud server võib kuid laitmatult töötada, kuni üks kompromiteeritud veebisait loeb faili, mida ta ei tohiks kunagi näha. Seepärast peavad meeskonnad majutuskasutajaid turvaliselt isoleerima: see pole suurte veebimajutusettevõtete luksus, vaid elementaarne reegel iga serveri puhul, kus majutatakse rohkem kui üht saiti, klienti või projekti.
Kasutajate isoleerimine piirab kahju, kui rakenduses on haavatav plugin, nõrk parool või üles laaditud fail osutub pahatahtlikuks. Samuti takistab see ühel suure koormusega kontol kõigi teiste veebisaitide aeglustamist. Eesmärk on lihtne: igal kliendil peaks olema piisavalt õigusi oma veebisaitide haldamiseks, samal ajal kui server hoiab kõige muu ümber selged piirid.
Mida majutuskasutajate isoleerimine tegelikult tähendab
Isoleerimine ei ole üks seadistus. See on koos toimivate kihtide kogum. Minimaalselt vajab majutuskonto oma Linuxi kasutajat, kodukataloogi, failide õigusi, andmebaasi mandaate, PHP protsessi ja juurdepääsureegleid. Ühe veebisaidi rike ei tohiks automaatselt anda juurdepääsu kõigile serveris olevatele veebisaitidele.
Kujutle jagatud serverit kortermajana. Eraldi Linuxi kasutaja on korteriuks. Õiged failiõigused on lukk. Eraldi PHP-FPM-i protsessikogumid, andmebaasikasutajad ja ressursipiirangud on seinad, tehnovõrgud ja kaitselülitid. Üks kaitsekiht aitab, kuid ainult sellele lootmine muudab väikesed intsidendid pikkadeks õhtuteks.
Sobiv isolatsioonitase sõltub sellest, mida majutad. Mõnel usaldusväärsel administraatoril kasutatavatel paaril sisemisel saidil on teistsugused vajadused kui 80 kliendikontoga agentuuriserveril. Omavahel mitteseotud klientide puhul tasub tugevam eraldatus ära, isegi kui see nõuab rohkem seadistamist ja veidi rohkem mälukasutust.
Alusta igale majutuskontole eraldi Linuxi kasutaja loomisest
Ära käivita kõiki veebisaite sama süsteemikonto all. Kui kõik veebifailid kuuluvad üldisele veebikasutajale, näiteks `www-data`, võib iga haavatav skript, mis saab faile kirjutada, muuta ka mõne teise kliendi saiti.
Loo igale majutuskontole spetsiaalne Linuxi kasutaja ning määra selle kasutaja omandusse tema enda dokumendijuure kataloog, logid, ajutised failid ja rakenduse failid. Väldi võimaluse korral ühiskasutatavaid kirjutatavaid katalooge. Kataloogist, kuhu saavad kirjutada kõik kontod, saab varem või hiljem probleemide ooteala.
Määra vaikimisi konservatiivsed õigused. Veebisaidi kataloogid vajavad tavaliselt õigust `755`, tavaliste failide puhul sobib aga `644`. Saladusi sisaldavatele konfiguratsioonifailidele tuleks seada rangemad õigused, sageli `600` või `640`, olenevalt teenusekontost, millel on vaja neid faile lugeda. Ära kasuta õigust `777` ainult sellepärast, et üleslaadimiskaustaga on probleeme. Nii kõrvaldad sümptomi, eemaldades ukselt luku.
Omandiõigus on sama tähtis kui numbrilised õigused. Näiteks võib WordPressi sait vajada kirjutusõigust asukohale `wp-content/uploads`, kuid veebiteenusel ei tohiks olla õigust kogu rakendust ümber kirjutada. Anna kirjutusõigus ainult nendele kataloogidele, mis seda tegelikult vajavad.
Hoia kontode piirid jagatud asukohtadest eemal
Varukoopiaid, seansse, vahemälu või juurutusfaile võib tunduda ahvatlev salvestada ühisesse asukohta. See võib olla mugav, kuni õigused muutuvad või puhastustöö kustutab valed failid. Hoia kasutajapõhiseid rakenduseandmeid selle konto kodukataloogis või muus asukohas, mis kuulub konkreetselt sellele kontole.
Kui ühiskasutatavat teenust ei saa vältida, määra juurdepääs selgesõnaliselt. Kasuta spetsiaalset rühma, millel on ainult vajalikud õigused, dokumenteeri selle olemasolu põhjus ja vaata rühm pärast muudatusi üle. „Ajutine” ühiskasutatav juurdepääs kipub muutuma alaliseks.
Käivita PHP-d iga konto jaoks eraldi
PHP-veebisaitide puhul on käitusmudel üks olulisemaid valikuid, mida teed. PHP käitamine ühise protsessi kaudu tähendab, et haavatav sait võib saada juurdepääsu, mis ulatub selle enda failidest palju kaugemale. Eraldi PHP-FPM-i protsessikogumi kasutamine iga majutuskasutaja jaoks loob selgema piiri: PHP-tööprotsess käivitatakse selle konto Linuxi kasutajana ning sellel on oma protsessiseaded ja piirangud.
Kasutajapõhine PHP-FPM-i protsessikogum muudab ka tõrkeotsingu lihtsamaks. Kui ühe kliendi rakendus hakkab kasutama liiga palju protsessitöötajaid või mälu, saad tuvastada vastutava protsessikogumi, selle asemel et käsitleda serverit ühe suure mõistatusena. Määra protsessikogumi tasemel piirangud, näiteks maksimaalne alamprotsesside arv ja päringute ajalõpud, lähtudes konto paketist ja rakenduse tegelikest vajadustest.
Siin tuleb teha kompromiss. Rohkem PHP-FPM-i protsessikogumeid tarbib rohkem mälu kui üks ühine protsessikogum, eriti väikeses virtuaalserveris. Vähese liiklusega saitidega serveris vali mõistlikud piirangud, selle asemel et luua liiga suuri protsessikogumeid. Ära aga loobu kontode eraldatusest ainult väikese RAM-i kokkuhoiu nimel. Suurenda serveri võimekust, enne kui muudad kõik kliendid üheks turvatsooniks.
Mitte-PHP-rakenduste puhul järgi sama põhimõtet. Käivita Node.js-i, Pythoni, Ruby või kohandatud teenuseid spetsiaalsete kasutajate all. Kasuta eraldi süsteemiteenuseid ja keskkonnafaile, mitte üht jagatud rakendusekontot, millel on juurdepääs igale projektile.
Eralda andmebaasid, mandaadid ja saladused
Andmebaasiserveris laguneb isolatsioon sageli märkamatult. Kõigile rakendustele sama andmebaasiadministraatori sisselogimise andmete andmine on seadistamise ajal mugav, kuid jääb pärast seda igaveseks riskiks. Igal saidil peaks olema oma andmebaas ja andmebaasikasutaja, kelle õigused piirduvad selle andmebaasiga.
Ära anna rakendusekasutajatele üldõigusi, uute kasutajate loomise õigust ega juurdepääsu kõigile skeemidele, välja arvatud juhul, kui selleks on konkreetne töökorralduslik põhjus. Ohustatud CMS-i mandaat peaks paljastama ühe rakenduse andmed, mitte serveri klientide andmeid.
Käsitle saladusi sama hoolikalt. Salvesta andmebaasi paroolid, API-võtmed ja e-posti mandaadid kontole kuuluvatesse konfiguratsioonifailidesse. Hoia need avalikest veebikataloogidest, versioonihalduskaustadest ja jagatud varukoopia asukohtadest eemal. Kui töötaja, töövõtja või klient ei vaja enam juurdepääsu, eemalda see, selle asemel et eeldada, et vanad mandaadid jäävad ohutuks.
Piira shelli, SSH ja ajastatud toimingute juurdepääsu
Kõik majutuskasutajad ei vaja SSH-d. Kliendile, kes haldab ainult lihtsat veebisaiti, võib piisata failide haldamisest juhtpaneeli või SFTP kaudu. Arendajatele ja agentuuridele võib SSH olla juurutuste, Composer'i, WP-CLI ja logide kontrollimise jaoks tõeliselt kasulik. Praktiline vastus ei ole selle kõikjal blokeerimine, vaid sellele teadlikult juurdepääsu andmine.
Kasuta võimaluse korral paroolide asemel SSH-võtmeid. Keela root-kasutaja otselogimine, väldi jagatud administraatorikontosid ja anna töötajatele eraldi nimelised kontod, et toiminguid saaks jälgida. Kui kasutaja vajab ainult failiedastust, kaalu konto piiramist SFTP-ga. Kui kasutaja vajab shelli, veendu, et ta ei saaks lugeda teiste kasutajate kodukatalooge ega kasutada ohtlikke õiguste suurendamise võimalusi.
Croni tööülesanded vajavad sama tähelepanu. Käivita iga ajastatud töö selle omaniku kasutajana, mitte root-kasutajana ega ühise veebikonto all. Katkine cron-töö võib täita ketta, saata tuhandeid e-kirju või käivitada kuluka skripti korduvalt. Määra selged piirangud ja vaata üle tööd, mida pole kaua puudutatud.
Sea igale kontole ressursipiirangud
Turvalisus ja stabiilsus kohtuvad ressursside haldamisel. Üks konto võib mõjutada kõiki teisi kontosid nende failidesse sisse murdmata, kasutades lihtsalt ära protsessori, mälu, protsessid, kettaruumi või inode'id. Ressursipiirangud hoiavad liiklussööstu, vigase päringu või juhusliku tsükli põhjustatud probleemid nende tekitanud konto piires.
Kasuta oma Linuxi keskkonna toetatavaid juhtimisvõimalusi, näiteks protsessipiiranguid, PHP-FPM-i protsessikogumi seadeid, kettakvoote ja süsteemitaseme cgroup'e. Jälgi tegelikku kasutust enne arvväärtuste määramist. Liiga madal piirang võib häirida seaduslikku e-kaubanduse liiklust, taustal tehtavaid importimisi või varukoopiaid. Liiga kõrge piirang pole eriti piirav.
Võimaluse korral jälgi vähemalt iga konto protsessori koormust, mälukoormust, kettakasutust, inode'ide kasutust, protsesside arvu, nurjunud sisselogimisi ja väljaminevate e-kirjade hulka. Reaalajas jälgimine muudab „server tundub aeglane” kasulikuks vastuseks: milline kasutaja, milline protsess ja millal see algas.
Lisa isoleerimismeetmeid, kuid ära pea neid raviks
Chroot-keskkonnad, konteinerid ja virtualiseerimine võivad kasutajate vahele luua tugevamad piirid. Konteinerid on eriti kasulikud, kui kliendid vajavad kohandatud käituskeskkondi, sõltuvusi või teenusetaseme juhtimist, mis muidu ühes operatsioonisüsteemis konflikti läheksid. Virtuaalmasinad pakuvad veelgi tugevamat eraldatust, kuid nende haldamine on kulukam.
Need tööriistad on abiks, kuid ei asenda õiguste haldamist, paikamist ega turvalisi mandaate. Konteiner, mis töötab root-kasutajana ja mille hosti ühendatud kataloog on kirjutatav, ei taga klientide vahel turvalist piiri. Samamoodi võib chroot-keskkond piirata nähtavat juurdepääsu failisüsteemile, kuid ei pruugi ohjeldada kõiki rakendustaseme probleeme. Vali riskile vastav kiht ja seadista see hoolikalt.
Praktiline isoleerimise kontrollnimekiri
Enne uue majutuskonto lisamist kontrolli järgmisi olulisi punkte:
- Kontol on oma Linuxi kasutaja, kodukataloog, veebisaidi failid, logid ja ajutised asukohad.
- PHP või muu rakenduse käituskeskkond töötab selle kasutaja all, mitte ühise teenuseidentiteediga.
- Kontol on eraldi andmebaasi mandaadid, mis annavad juurdepääsu ainult selle enda andmebaasile.
- Failide omandiõigus ja õigused takistavad kontodevahelist lugemist ja kirjutamist.
- SSH, SFTP, cron-tööd, varukoopiad ja ressursipiirangud on antud ning seadistatud just selle konkreetse konto jaoks.
Juhtpaneel peaks need piirid nähtavaks tegema, mitte peitma neid serverižargooni taha. FASTPANEL aitab administraatoritel hallata eraldi kontosid, domeene, andmebaase ja serveri tegevust ühes selges tööruumis, mis hõlbustab hea isolatsiooni säilitamist serveri kasvades.
Jätka kontrollimist ka pärast seadistamist
Isoleerimine pole ülesanne, mille saad ühe korra ära teha ja siis unustada. Uued pluginad, migreerimisskriptid, käsitsi muudetud õigused ja kiirustades tehtud tugiparandused võivad seda aja jooksul nõrgendada. Vaata pärast saidi migreerimist kontode omandiõigused üle, otsi kõigile kirjutatavaid faile, eemalda mitteaktiivsed kasutajad, paigalda turvauuendused ning testi varukoopiaid, andmata varundusprotsessidele tarbetut juurdepääsu kõigile kontodele.
Parim seadistus on selline, millest su meeskond saab aru ja mida suudab pinge all hallata. Määra igale kasutajale selge piir, tee erandid harvaks ja dokumenteerituks ning lase serveril vaikselt hoolitseda selle eest, et ühe veebisaidi halb päev ei muutuks kõigi probleemiks.