Kā droši izolēt mitināšanas lietotājus operētājsistēmā Linux

Publicēts 2026. gada 12. novembrī

Koplietots serveris var nevainojami darboties mēnešiem ilgi — līdz brīdim, kad kāda apdraudēta vietne nolasa failu, kuru tai nekad nevajadzētu redzēt. Tāpēc komandām ir droši jāizolē mitināšanas lietotāji — nevis kā greznība lieliem mitināšanas uzņēmumiem, bet gan kā pamatnoteikums ikvienam serverim, kurā atrodas vairāk nekā viena vietne, klients vai projekts.

Lietotāju izolācija ierobežo kaitējumu, ja lietotnes spraudnim ir ievainojamība, parole ir vāja vai augšupielādētais fails izrādās ļaunprātīgs. Tā arī neļauj vienam noslogotam kontam palēnināt visu pārējo vietņu darbību. Mērķis ir vienkāršs: katram klientam jābūt pietiekamai kontrolei, lai pārvaldītu savas vietnes, kamēr serveris uztur skaidras robežas starp tām un visu pārējo.

Ko patiesībā nozīmē mitināšanas lietotāju izolācija

Izolācija nav viens iestatījums. Tā ir slāņu kopa, kuras darbojas kopā. Vismaz mitināšanas kontam ir nepieciešams savs Linux lietotājs, mājas direktorijs, failu atļaujas, datubāzes akreditācijas dati, PHP process un piekļuves noteikumi. Problēma vienā vietnē nedrīkst automātiski nodrošināt piekļuvi visām serverī esošajām vietnēm.

Uztveriet koplietotu serveri kā daudzdzīvokļu māju. Atsevišķs Linux lietotājs ir dzīvokļa durvis. Pareizas failu atļaujas ir slēdzene. Atsevišķi PHP-FPM pūli, datubāzu lietotāji un resursu ierobežojumi ir sienas, komunālie pakalpojumi un automātslēdži. Viens slānis palīdz, taču paļaušanās tikai uz vienu slāni ir iemesls, kāpēc nelieli incidenti pārvēršas garos vakaros.

Piemērotais izolācijas līmenis ir atkarīgs no tā, ko mitināt. Dažām iekšējām vietnēm, ko pārvalda viens uzticams administrators, ir citas vajadzības nekā aģentūras serverim ar 80 klientu kontiem. Ja klienti nav savstarpēji saistīti, stingrāka nošķiršana ir papildu konfigurācijas un nedaudz lielāka atmiņas patēriņa vērta.

Sāciet ar vienu Linux lietotāju katram mitināšanas kontam

Nekad nedarbiniet visas vietnes ar vienu un to pašu sistēmas kontu. Ja visi tīmekļa faili pieder vispārīgam tīmekļa lietotājam, piemēram, `www-data`, jebkurš ievainojams skripts, kas var rakstīt failos, var modificēt arī cita klienta vietni.

Izveidojiet katram mitināšanas kontam atsevišķu Linux lietotāju un piešķiriet tam īpašumtiesības uz tā dokumentu saknes direktoriju, žurnāliem, pagaidu failiem un lietotnes failiem. Kad vien iespējams, izvairieties no koplietotiem direktorijiem, kuros var rakstīt. Direktorijs, kurā var rakstīt ikviens konts, agrāk vai vēlāk kļūst par vietu, kur uzglūn problēmas.

Pēc noklusējuma iestatiet ierobežojošas atļaujas. Vietņu direktorijiem parasti ir nepieciešama atļauja `755`, savukārt parastiem failiem var izmantot `644`. Konfigurācijas failiem, kuros ir noslēpumi, jāiestata stingrākas atļaujas — bieži vien `600` vai `640` atkarībā no tā, kuram pakalpojuma kontam tie ir jālasa. Neizmantojiet `777` tikai tāpēc, ka augšupielādes mape nedarbojas. Tas novērš simptomu, noņemot durvīm slēdzeni.

Īpašumtiesības ir tikpat svarīgas kā skaitliskās atļaujas. Piemēram, WordPress vietnei var būt nepieciešama rakstīšanas piekļuve `wp-content/uploads`, taču tīmekļa pakalpojumam nevajadzētu būt atļaujai pārrakstīt visu lietotni. Piešķiriet rakstīšanas piekļuvi tikai tiem direktorijiem, kuros tā patiešām ir nepieciešama.

Neizmantojiet koplietotus ceļus, kas šķērso kontu robežas

Var rasties kārdinājums glabāt dublējumkopijas, sesijas, kešatmiņas vai izvietošanas failus kopīgā atrašanās vietā. Tas var būt ērti, līdz mainās atļaujas vai tīrīšanas uzdevums izdzēš nepareizos failus. Katra lietotāja lietotnes datus glabājiet šī konta mājas direktorijā vai citā vietā, kas pieder tieši šim kontam.

Ja no koplietota pakalpojuma nevar izvairīties, skaidri norādiet piekļuves tiesības. Izmantojiet atsevišķu grupu ar iespējami šaurākajām nepieciešamajām atļaujām, dokumentējiet tās izveides iemeslu un pēc izmaiņām pārskatiet tās iestatījumus. “Pagaidu” koplietotai piekļuvei ir tendence kļūt par pastāvīgu.

Darbini PHP atsevišķi katram kontam

PHP vietnēm izpildes modelis ir viena no svarīgākajām izvēlēm, ko nāksies izdarīt. Ja PHP darbojas koplietotā procesā, ievainojama vietne var iegūt piekļuvi, kas ievērojami pārsniedz tās failu piekļuves robežas. Izmantojot atsevišķu PHP-FPM pūlu katram mitināšanas lietotājam, tiek izveidota skaidrāka robeža: PHP darbprocess darbojas ar attiecīgā konta Linux lietotāja tiesībām, un tam ir savi procesa iestatījumi un ierobežojumi.

Atsevišķs PHP-FPM pūls katram lietotājam arī atvieglo problēmu novēršanu. Ja viena klienta lietotne sāk patērēt darbprocesus vai atmiņu, varat noteikt atbildīgo pūlu, nevis uztvert visu serveri kā vienu lielu mīklu. Iestatiet pūla līmeņa ierobežojumus, piemēram, maksimālo bērnprocesu skaitu un pieprasījumu noildzes, ņemot vērā konta plānu un lietotnes faktiskās vajadzības.

Te jārēķinās ar kompromisu. Vairāki PHP-FPM pūli patērē vairāk atmiņas nekā viens koplietots pūls, īpaši nelielā virtuālajā serverī. Serverim, kurā ir tikai dažas vietnes ar nelielu datplūsmu, izvēlieties saprātīgus ierobežojumus, nevis veidojiet pārmērīgi lielus pūlus. Tomēr neatsakieties no kontu nošķiršanas, lai ietaupītu nelielu RAM apjomu. Palieliniet servera resursus, pirms visus nomniekus ievietojat vienā drošības zonā.

Lietotnēm, kas nav rakstītas PHP, ievērojiet to pašu principu. Palaidiet Node.js, Python, Ruby vai pielāgotus pakalpojumus ar īpaši šim nolūkam izveidotiem lietotājiem. Izmantojiet atsevišķus sistēmas pakalpojumus un vides failus, nevis vienu koplietotu lietotnes kontu, kuram ir piekļuve visiem projektiem.

Nošķiriet datubāzes, akreditācijas datus un noslēpumus

Datubāzes serveris bieži vien ir vieta, kur izolācija nemanāmi pārstāj darboties. Piešķirt katrai lietotnei vienu un to pašu datubāzes administratora pieteikšanās informāciju ir ērti iestatīšanas laikā, taču pēc tam tas rada pastāvīgu risku. Katrai vietnei vajadzētu būt savai datubāzei un datubāzes lietotājam, kura atļaujas attiecas tikai uz šo datubāzi.

Nepiešķiriet lietotņu lietotājiem globālas privilēģijas, atļauju izveidot jaunus lietotājus vai piekļuvi visām shēmām, ja vien tam nav konkrēta operatīva iemesla. Kompromitēti CMS akreditācijas dati var apdraudēt vienas lietotnes datus, nevis klientu ierakstus visā serverī.

Tikpat rūpīgi rīkojieties ar noslēpumiem. Glabājiet datubāzu paroles, API atslēgas un pasta akreditācijas datus konfigurācijas failos, kas pieder attiecīgajam kontam. Neglabājiet tos publiski pieejamos tīmekļa direktorijos, versiju kontroles mapēs vai koplietotās dublējumkopiju atrašanās vietās. Ja darbiniekam, līgumdarbiniekam vai klientam piekļuve vairs nav nepieciešama, atņemiet to, nevis paļaujieties uz to, ka vecie akreditācijas dati paliks nekaitīgi.

Kontrolējiet piekļuvi čaulai, SSH un plānotajiem uzdevumiem

Ne katram mitināšanas lietotājam ir nepieciešams SSH. Klientam, kurš pārvalda tikai vienkāršu vietni, var pietikt ar failu pārvaldību, izmantojot vadības paneli vai SFTP. Izstrādātājiem un aģentūrām SSH var būt ļoti noderīgs izvietošanai, Composer, WP-CLI un žurnālu pārbaudei. Praktiskais risinājums nav bloķēt to visur, bet gan piešķirt piekļuvi pārdomāti.

Kad vien iespējams, paroļu vietā izmantojiet SSH atslēgas. Atspējojiet tiešu root pieteikšanos, izvairieties no koplietotiem administratora kontiem un piešķiriet darbiniekiem atsevišķus kontus ar unikāliem lietotājvārdiem, lai varētu izsekot darbībām. Ja lietotājam ir nepieciešama tikai failu pārsūtīšana, apsveriet iespēju ierobežot kontu līdz SFTP. Ja lietotājam ir nepieciešama čaula, pārliecinieties, ka viņš nevar lasīt citu lietotāju mājas direktorijus vai izmantot riskantus privilēģiju paaugstināšanas ceļus.

Arī cron uzdevumiem jāpievērš tikpat liela uzmanība. Palaidiet katru plānoto uzdevumu kā lietotājs, kuram tas pieder, nevis kā root vai koplietota tīmekļa konta lietotājs. Bojāts cron uzdevums var aizpildīt disku, nosūtīt tūkstošiem e-pasta ziņojumu vai atkārtoti palaist resursus patērējošu skriptu. Iestatiet skaidrus ierobežojumus un pārskatiet uzdevumus, kas ilgu laiku nav mainīti.

Iestatiet resursu ierobežojumus katram kontam

Drošība un stabilitāte satiekas resursu pārvaldībā. Viens konts var ietekmēt visus pārējos kontus, neielaužoties to failos, vienkārši izsmeldams procesora jaudu, atmiņu, procesu skaitu, diska vietu vai inodu skaitu. Resursu ierobežojumi nodrošina, ka datplūsmas pieauguma, kļūdaina vaicājuma vai nejaušas bezgalīgas cilpas ietekme paliek attiecīgajā kontā.

Izmantojiet jūsu Linux vidē pieejamos rīkus, piemēram, procesu ierobežojumus, PHP-FPM pūla iestatījumus, diska kvotas un sistēmas līmeņa cgroups. Pirms skaitlisko vērtību iestatīšanas uzraugiet faktisko resursu patēriņu. Pārāk zems ierobežojums var traucēt likumīgu e-komercijas datplūsmu, fona importēšanas uzdevumus vai dublējumkopiju veidošanu. Pārāk augsts ierobežojums diez ko neierobežo.

Ja iespējams, vismaz uzskaitiet katra konta procesora noslodzi, atmiņas noslodzi, diska un inodu patēriņu, procesu skaitu, neveiksmīgās pieteikšanās reizes un izejošo pasta ziņojumu apjomu. Reāllaika uzraudzība pārvērš apgalvojumu “serveris šķiet lēns” lietderīgā atbildē: kurš lietotājs, kurš process un kad tas sākās.

Pievienojiet ierobežošanas mehānismus, bet nejauciet tos ar problēmas novēršanu

Chroot vides, konteineri un virtualizācija var izveidot stingrākas robežas starp lietotājiem. Konteineri ir īpaši noderīgi, ja klientiem ir nepieciešamas pielāgotas izpildvides, atkarības vai pakalpojumu līmeņa kontrole, kas citādi vienā operētājsistēmā radītu konfliktus. Virtuālās mašīnas nodrošina vēl stingrāku nošķiršanu, taču to uzturēšana ir dārgāka.

Šie rīki palīdz, taču neaizstāj pareizas atļaujas, atjaunināšanu un drošu rīkošanos ar akreditācijas datiem. Konteiners, kas darbojas kā root un kuram ir pievienots rakstāms resursdatora direktorijs, nenodrošina drošu nomnieku nošķiršanu. Tāpat chroot izolācija var ierobežot redzamo piekļuvi failu sistēmai, taču tā var nenovērst visas lietotnes līmeņa problēmas. Izvēlieties riskam atbilstošo slāni un rūpīgi to konfigurējiet.

Praktisks izolācijas kontrolsaraksts

Pirms jauna mitināšanas konta pievienošanas pārbaudiet tālāk minēto:

• Kontam ir savs Linux lietotājs, mājas direktorijs, vietnes faili, žurnāli un pagaidu direktoriji.
• PHP vai cita lietotnes izpildvide darbojas ar šī lietotāja tiesībām, nevis ar koplietota pakalpojuma identitāti.
• Kontam ir atsevišķi datubāzes akreditācijas dati, kas nodrošina piekļuvi tikai paša konta datubāzei.
• Failu īpašumtiesības un atļaujas nepieļauj piekļuvi failiem starp kontiem ne lasīšanas, ne rakstīšanas režīmā.
• SSH, SFTP, cron uzdevumi, dublējumkopijas un resursu ierobežojumi ir piešķirti un konfigurēti tieši šim kontam.

Vadības panelim šīm robežām jābūt skaidri redzamām, nevis noslēptām aiz serveru žargona. FASTPANEL palīdz administratoriem pārvaldīt atsevišķus kontus, domēnus, datubāzes un servera darbību vienā pārskatāmā darba vidē, tādējādi atvieglojot labas izolācijas uzturēšanu, serverim augot.

Turpiniet pārbaudes arī pēc iestatīšanas

Izolācija nav uzdevums, ko paveic vienreiz un pēc tam aizmirst. Jauni spraudņi, migrācijas skripti, manuālas atļauju izmaiņas un steidzīgi atbalsta dienesta labojumi laika gaitā var to vājināt. Pēc vietņu migrācijas pārskatiet kontu īpašumtiesības, meklējiet failus, kuros var rakstīt ikviens, noņemiet neaktīvos lietotājus, instalējiet drošības atjauninājumus un pārbaudiet dublējumkopijas, nepiešķirot dublēšanas procesiem nevajadzīgu piekļuvi visiem kontiem.

Labākais risinājums ir tāds, ko jūsu komanda spēj saprast un uzturēt stresa situācijās. Nosakiet katram lietotājam skaidras piekļuves robežas, izņēmumus pieļaujiet reti un dokumentējiet tos, kā arī ļaujiet serverim nemanāmi parūpēties, lai vienas vietnes slikta diena nekļūtu par visu problēmu.