Lühidalt: Kas hallatav majutus või root-server on turvalisem, otsustab vähem tehnika kui küsimus, kes paigaldab uuendused usaldusväärselt. Hallatava majutuse puhul teeb seda pakkuja kokkulepitud ulatuses, oma root-serveri puhul teie meeskond või teenusepakkuja. Ettevõtetele ilma serveripädevuseta on hallatav majutus tavaliselt turvalisem valik. Kes vajab kontrolli ja omab hooldavat meeskonda, võib oma serveriga sama turvaliselt sõita.
Mida PHP2Shell tegevusmudelite kohta näitas
- aasta oktoobri olukord oli praktiline test. 21.10. kell 16 Saksamaa aja järgi ilmusid paigad, BSI (Saksamaa föderaalne infoturbeamet) soovitas kohest uuendust. Kellel oli hallatav pakett, pidi ennekõike ühte tegema: pakkujalt järele küsima ja laskma paigaseis ning taaskäivitus endale kinnitada. Kes käitas oma serverit, pidi ise tegutsema, sageli õhtul või nädalavahetusel.
Mõlemal oli lõkse. Hallatava majutuse klientidel võis paneel näidata edasi vana versiooninumbrit, näiteks 8.2.34, kuigi tagasiportimine (backport) oli paigaldatud; ilma pakkuja kinnituseta jäi seis siis ebaselgeks. Oma serverite käitajad seisid küsimuse ees, kas neil on õiged paketid ja kas kõik PHP protsessid on taaskäivitatud. Põhilisi vastutusalasid kirjeldavad Hallatav server: vastutuse selgitamine ja Root-serveri ja vServeri enda kaitsmine. Siin on jutt otsusest nende kahe vahel.
Hallatav majutus või root-server: võrdlus
| Kriteerium | Hallatav majutus | Oma root-server või vServer |
|---|---|---|
| Kes paigab PHP ja operatsioonisüsteemi? | Pakkuja, kokkulepitud ulatuses | Teie või teie teenusepakkuja |
| Kiirus kriitiliste turvaaukude korral | Sõltub pakkuja protsessidest | Sõltub teie kättesaadavusest |
| Kontroll konfiguratsiooni üle | Piiratud, sageli ainult paneeli või päringu kaudu | Täielik |
| Üleminekumeetmed serveri tasandil | Võimalikud ainult pakkuja kaudu | Ise teostatavad |
| Paigaseisu tõend | Vaja pakkuja kinnitust | Ise kontrollitav paketi muudatuslogi kaudu |
| Ettevõttes vajalikud erialateadmised | Väike serveri jaoks, rakendus jääb teile | Suured, püsivalt |
| Erinõuded, vana tarkvara | Sageli ei ole võimalik | Võimalik, kuid oma risk |
| Jälgede otsimine pärast intsidente | Logid ja ligipääs ainult kokkuleppel | Täielik ligipääs, kuid vaja on oma pädevust |
| Sõltuvus | Pakkujast ja tema lepingust | Teie meeskonnast ja selle kättesaadavusest |
Tabel näitab: mõlemad mudelid nihutavad vastutust, ükski ei kõrvalda seda. Hallatava majutuse puhul viite serverihoolduse mujale, kuid säilitate kohustuse järele küsida ja oma rakendust kaitsta. Oma serveri puhul jääb teile kõik, sealhulgas nädalavahetused.
Viis küsimust tegevusmudeli valikuks
- Kas ettevõttes on isik serveripädevusega, keda haiguse või puhkuse korral asendatakse? Kui ei, on oma server ilma välise hoolduseta riskantne.
- Kas teie rakendus vajab erikonfiguratsioone, oma teenuseid või vana tarkvara? Kui jah, jõuab hallatav majutus sageli piirideni.
- Kui kriitiline on veebisait käibe või tegevuse jaoks? Mida kriitilisem, seda olulisemad on selged kinnitused uuenduste ja kättesaadavuse kohta, ükskõik, millises mudelis.
- Milliseid andmeid te töötlete? Tundlike andmete puhul loevad tõendid ja logide ligipääs. Selgitage, kas teie pakkuja annab hädaolukorras logid välja.
- Mitut veebisaiti te käitate? Paljusid sarnaseid lehti saab oma, hästi hooldatud serveril tõhusalt koondada. Üksikud lehed on hallatavas majutuses sageli paremini hoitud.
Vahevormid, mis end tõestavad
Kahe poolluse vahel on mudeleid, mis praktikas sageli kõige paremini toimivad. Kõige sagedasem on oma server välise hooldusega: te säilitate kontrolli konfiguratsiooni ja andmete üle, teenusepakkuja võtab kindlate kokkulepete järgi uuendused, jälgimise ja hädaolukorra reageerimise. Teine variant on hallatav majutus täiendava turvakontrolliga. Pakkuja hooldab serveri, sõltumatu teenusepakkuja kontrollib korrapäraselt rakendust, pistikprogramme ja jälgi, mis jäävad väljapoole hallatavat ulatust. Lihtsate veebisaitide jaoks jääb lõpuks jagatud majutus mõistlikuks lahenduseks, kui majutaja paigab usaldusväärselt ja veebisaidil ei ole erinõudeid.
Oluline kõigis mudelites: operatsioonisüsteemi automaatsed turvauuendused, korrapäraselt kontrollitud varukoopiad ja kaheastmeline sisselogimine kõigile ligipääsudele on alused, mis kehtivad mudelist sõltumata. Kes seadistab oma serveril automaatsed uuendused, peab siiski kontrollima, et PHP protsessid pärast taaskäivituvad; miks see on otsustav, selgitab artikkel Pärast uuendust: PHP-FPM-i ja kõigi tööprotsesside taaskäivitamine.
Ükski tegevusmudel ei võta teilt vastutust teie rakenduse ja andmete eest. Ka hallatava majutuse puhul tuleb CMS-i, pistikprogramme ja administraatorikontosid hooldada ning andmelekkeid hindate teie.
Millal vahetus on mõistlik ja millal mitte
Vahetus tasub end ära, kui PHP2Shell on näidanud struktuurset nõrkust: teie meeskond ei suutnud oma serverit õigel ajal paigata või teie hallatava majutuse pakkuja ei reageerinud järelepärimistele ja ei esitanud tõendit. Mida pakkuja vahetusel silmas pidada, kirjeldab artikkel Veebimajutaja vahetamine pärast turvaintsidenti.
Hea põhjus vahetuseks ei ole seevastu üksik sündmus, mis oleks lahendatav parema kokkuleppega. Sageli piisab, kui täiendada olemasolevat lepingut sätetega turvauuenduste, taaskäivituste ja kriitilistest turvaaukudest teavitamise kohta.
Arvestage ka ajastusega. Kolimine ägedas olukorras seob just need jõud, mida paikade ja jälgede otsimise jaoks parajasti vaja on. Parem on kõigepealt olemasolev server turvaliseks teha ja vahetus siis rahulikult planeerida, puhta uuesti ülesehitamisega, mitte vana süsteemi koopiaga.
Kuidas PHP SOS konkreetselt aitab?
- Võrdleme teie praegust mudelit teie tegelike nõuetega ja näitame, kus vastutus on selgitamata.
- Kontrollime hallatava majutuse pakkujate teenusekirjeldusi punktide osas, mis hädaolukorras loevad.
- Oma serverite jaoks võtame uuendused, karastamise ja jälgimise enda peale turvahoolduslepingu raames.
- Vahetuse korral toetame kolimist, et vanad ligipääsud või kontrollimata andmed kaasa ei koliks.
Kokkuvõte
Hallatav majutus on turvalisem valik ettevõtetele ilma serveripädevuseta, oma server paindlikum valik meeskondadele erialateadmiste ja valmisolekuga. Kõige paremini kukuvad sageli välja vahevormid, kus on selgelt reguleeritud, kes paigab, kes taaskäivitab ja kes hädaolukorras reageerib.
Korduma kippuvad küsimused
Kas hallatav majutus on põhimõtteliselt turvalisem kui root-server?
Mitte põhimõtteliselt. Hallatav majutus on turvalisem, kui pakkuja paigaldab uuendused usaldusväärselt ja teil endal on vähe serveriteadmisi. Hästi hooldatud oma server võib olla sama turvaline, kuid nõuab püsivalt aega ja erialateadmisi.
Kes vastutab root-serveri puhul PHP uuenduste eest?
Üldjuhul teie ise. Andmekeskuse käitaja hoolitseb tavaliselt ainult riistvara, võrgu ja virtualiseerimise eest. Operatsioonisüsteem, PHP, veebiserver ja rakendus on teie või teie teenusepakkuja käes.
Kas hallatava majutuse puhul saan seada oma PHP sätteid?
Sageli ainult piiratult. Paljud pakkujad lubavad muudatusi paneeli kaudu või nõudmisel. PHP2Shelli-sarnaste üleminekumeetmete jaoks tuleb mõned sätted seada serveriülese; see käib siis ainult pakkuja kaudu.
Mis on jagatud majutusega?
Jagatud majutus on hallatava majutuse lihtsaim vorm. Pakkuja hooldab süsteemi paljude klientide jaoks korraga. Teil on PHP versioonile ja konfiguratsioonile vähe mõju, kuid peate sellega ka vaevalt tegelema.
Kas tegevusmudeli vahetus pärast PHP2Shelli tasub end ära?
Ainult siis, kui olukord on näidanud tõelist nõrkust, näiteks et keegi ei suutnud oma serverit õigel ajal paigata. Kõhutundest lähtuv vahetus lahendab harva tegeliku probleemi.