Webhelyenkénti elkülönítés
Az elszigetelés jelenti a különbséget egy incidens és egy leállás között. Minden általunk üzemeltetett webhely egy kernelszintű CloudLinux LVE ketrecben fut, saját CPU-, RAM-, IO- és folyamatkorlátokkal, saját CageFS fájlrendszer-nézettel, saját PHP-verzióval és saját adatbázis-szabályozással. A megtámadott, kompromittálódott vagy egyszerűen csak nagy terhelést jelentő lekérdezést futtató webhely a saját környezetén belül marad elkülönítve — és az elszigetelési alapszint minden csomag része, nem értékesítjük Önnek frissítésként. Elérhetőség: a webhelyenkénti adatbázis-szabályozás és a webhelyenkénti erőforrás-statisztikák aktív fejlesztés alatt állnak, és még nem érhetők el. Minden más, itt leírt funkció már ma működik.
A feldolgozó flotta a CloudLinux OS rendszert futtatja, amely a több-bérlős működést közvetlenül a kernelbe integrálja. Minden webhely kap egy könnyűsúlyú virtuális környezetet – egy LVE-t –, amely szigorú határvonalat jelent, nem pusztán udvarias megegyezést. Semmi, amit egy webhely a saját ketrecén belül tesz, nem használható fel valaki más költségkeretéből.
Az LVE webhelyenként függetlenül korlátozza a CPU-t, a RAM-ot, az IO-t, az IOPS-t, a folyamatokat és a belépési folyamatokat. Amikor egy webhely túllépi a felső határát, a rendszer a saját elkülönített környezetében korlátozza — a hibát az adott webhelyhez rögzíti, a szomszédos webhelyek pedig zavartalanul működnek tovább.
Egy ciklusban ragadt bővítmény, egy rosszul megírt cron feladat vagy egy végpontot túlterhelő crawler először magának a webhelynek a folyamat- és belépési folyamatkorlátaiba ütközik. Egyetlen webhely nem tudja egyszerűen felemészteni az egész gépet.
Mivel a belépési folyamatok korlátozva vannak környezetenként (cage), az egyetlen webhelyre irányuló túlterhelés nem indíthat korlátlan munkamenetet a kiszolgálón. A LiteSpeed kapcsolat- és kéréskorlátozása, valamint az Imunify360 hálózati tűzfal ez előtt helyezkedik el, így a támadás kizárólag a célpont problémája marad.
Minden LVE-hiba webhelyenként rögzítésre kerül, és bekerül a platform szabályzati motorjába, amely automatikusan szigoríthatja vagy lazíthatja a korlátokat. Ön láthatja, miért és mikor lett korlátozva egy webhely — fokozatosan, visszafordíthatóan és naplózva.
Az erőforrás-elkülönítés megakadályozza, hogy egy webhely túlterhelje a rendszert. A fájlrendszer-elkülönítés megakadályozza a kíváncsiskodást. A CageFS minden bérlő számára privát, korlátozott rálátást biztosít a gépre.
A CageFS alatt a bérlő kizárólag a saját fájljait és a rendszerbinárisok minimális, megtisztított készletét látja — a többi bérlőt, azok webhelyeit és a bizalmas rendszerfájlokat nem láthatja. A megosztott tárhelyek szokásos hibamódja, amely során egy feltört fiók hozzáférési ponttá válik a szerveren lévő összes többi fiók olvasásához, rendszermagszinten van kizárva.
Ez azon a napon számít a leginkább, amikor valami elromlik. Ha egy webhelyet feltörnek — egy elavult bővítmény, ellopott hitelesítési adatok vagy egy sebezhető téma miatt —, a CageFS az, amely a károk hatósugarát erre az egyetlen ketrecre korlátozza. Biztonsági specifikációnk tudatosan fogalmaz: a CageFS elszigeteli a biztonsági réseket. Az elszigetelés az őszinte állítás, és ez dönti el, hogy egy incidens egyetlen webhely tisztítását vagy egy egész flottára kiterjedő beavatkozást igényel-e.
A biztonsági mentések ugyanezt a határt erősítik meg. A webhelyenkénti biztonsági mentések megváltoztathatatlanok, külső helyszínen találhatók és el vannak különítve a futó szerverparktól, tesztelt visszaállítással, így egy adott webhely legrosszabb forgatókönyv szerinti kompromittálódása esetén is tiszta, független helyreállítási útvonal áll rendelkezésre, amely nem függ a futtató gép állapotától.
A webszintű elkülönítés csak a történet fele. Egy WordPress flottán a szervert leggyakrabban egy adott webhely lekérdezései lassítják le, nem pedig a forgalma. Ezt kifejezetten kezeljük.
A CloudLinux MySQL Governor webhelyenként korlátozza az adatbázis-használatot, így egyetlen webhely nagy lekérdezései nem lassíthatják le a szervert a többiek számára. Ez a lassulás elleni vezérlés, és attól függetlenül működik, hogy a túlterhelő webhely észreveszi-e a korlátozást vagy sem.
A géppark MariaDB-t (vagy Perconát) futtat, amelyet nem alapértelmezésként vettünk át, hanem kifejezetten a WordPress munkaterhelésekhez választottunk, és amelynek tetején a Governor működik a bérlőnkénti méltányosságot biztosító rétegként.
A webhelyenkénti Redis objektum-gyorsítótár elnyeli az ismétlődő olvasási műveleteket, mielőtt azok elérnék az adatbázist, ami már eleve csökkenti a Governor által kezelendő terhelést. A gyorsítótárazás és az elkülönítés egyetlen rendszerként működik.
A CloudLinux alt-PHP minden webhely számára saját PHP-verzióválasztót, saját kiterjesztéseket (imagick, gd, redis és a többi) és saját, megerősített beállításokat biztosít — az LSAPI-folyamatokat pedig az adott webhely LVE-korlátai szabják meg, így a PHP-párhuzamosság a ketrec részét képezi, nem pedig menekülést jelent belőle.
Az elszigetelés határozza meg, hogy egy probléma milyen mértékben terjed tovább. A kényszerítés dönti el, mi történjen ezután. A nyers ki/be kapcsolásos felfüggesztést egy állapotgépre cseréltük, amelyet tartós munkafolyamatok vezérelnek, és amelyet a worker szintjén kényszerítünk ki a LiteSpeed, az LVE és az Imunify segítségével.
Az elszigetelés nem egy olyan díjcsomag-funkció, amely csak három szinttel feljebb jelenik meg. Ez az alapinfrastruktúra tulajdonsága, így teljesen azonos, függetlenül attól, hogy Ön egyetlen WooCommerce áruházat vagy kétezer hálózati webhelyet üzemeltet.
A tömeges és PBN hálózatok ugyanazon az LVE és CageFS szubsztrátumon futnak, lábnyom-tudatos CDN-fiók rotációval és statikus HTML-kiszolgálással együtt. Az elszigetelés teszi biztonságossá a sűrűséget: a webhelyek megosztanak egy flottát anélkül, hogy a sorsukban osztoznának.
A felügyelt WordPress, WooCommerce, PHP, statikus és Node webhelyek ugyanazokat az izolált környezeteket (cage-eket) kapják, valamint teljes önkiszolgálást — az Ön saját PHP verzióját és bővítményeit, Redis objektum-gyorsítótárat, staging környezetet és élesítési lehetőséget.
A sűrűségre optimalizált alapértelmezettnél erősebb elhatárolást igénylő munkaterhelések esetén teljes, webhelyenkénti tároló-elkülönítés érhető el provisionálási illesztőprogram-változatként: azonos motor, azonos vezérlési sík, eltérő elhelyezés, magasabb többletterhelés mellett.
Az LVE és a CageFS izoláció, a proaktív WAF és a kártevő-ellenőrzés minden ügyfél számára biztosított, mivel egy fertőzött vagy elszabadult webhely veszélyezteti a szomszédait és az IP-címünk hírnevét. Az egykattintásos kártevő-eltávolítás és a fejlett védelmi szintek fizetős kiegészítők — az alapszint nem az.
A tárhelyszolgáltatásban a kereskedelmi kísértés az, hogy a biztonságot szintek szerint értékesítsék: az olcsóbb ügyfeleket egy laza korlátokkal rendelkező megosztott gépre helyezik, és felárat számítanak fel azoknak, akiknek fontos a határok megléte. Mi nem ezt tesszük, mivel az az ügyfél, aki nem fizetett az elszigetelésért, pontosan az, akinek a feltört webhelye mindenki más incidensévé válik.
Több mint 700 000 webhelyet üzemeltetünk világszerte egy olyan infrastruktúrán, ahol a sűrűség jelenti a teljes gazdasági ajánlatot. Ez csak akkor működik, ha az alapjául szolgáló elszigetelés feltétel nélküli. A rendszermag szintű elkülönítés, a privát fájlrendszer-nézet, a webhelyenkénti adatbázis-szabályozás és a webhelyenkénti PHP az ára annak, hogy ekkora léptékben, közös kockázat nélkül működjünk — így ezek mindenki számára, minden díjcsomagban elérhetők, már az első üzembe helyezett webhelytől kezdve.
Az eredmény egy olyan platform, amely kiszámíthatóan viselkedik mások rossz napjain is. A háttérben 99,99%-os rendelkezésreállási garancia, webhelyenkénti, nem módosítható, külső helyszíni biztonsági mentések tesztelt visszaállítással, valamint a webhelyein végrehajtott összes kényszerítő intézkedés teljes naplózási nyomvonala áll.
Az elszigetelést kifejezetten ennek megakadályozására tervezték. Az LVE webhelyenként korlátozza a CPU-, RAM-, IO-, IOPS-használatot és a folyamatokat, a MySQL Governor szabályozza a webhelyenkénti adatbázis-használatot, az LSAPI-workereket pedig a webhely saját cage-e korlátozza — így a szomszédos webhely forgalomcsúcsa vagy nagy lekérdezési terhelése az ő plafonjukhoz képest korlátozódik, nem az Önéhez. Minden hiba webhelyenként naplózásra kerül, és a szabályzómotor automatikusan szigoríthatja a zajos webhelyek korlátait.
Az őszinte válasz a kordában tartás, nem pedig a garancia. A CageFS minden bérlő számára elszigetelt fájlrendszer-nézetet biztosít — egy kompromittált bérlő nem láthatja a többi bérlőt, azok webhelyeit vagy a bizalmas rendszerfájlokat —, a megerősített kártevő- vagy adathalászati esetek pedig karanténba helyezik az adott webhelyet: offline állapot, zárolt fájlok, nincs végrehajtás, törvényszéki vizsgálathoz elkülönítve. Ez az, ami korlátozza a kár kiterjedését. Emellett kártevő-ellenőrzést és proaktív WAF-ot futtatunk minden webhelyen, valamint webhelyenkénti, megváltoztathatatlan külső biztonsági mentéseket tesztelt visszaállításokkal, így a helyreállítás soha nem függ az érintett gép állapotától.
Minden csomag tartalmazza. Az LVE és a CageFS izoláció, a proaktív WAF és a kártevő-ellenőrzés minden ügyfél számára alapkövetelmény, mivel egy fertőzött vagy elszabadult webhely veszélyezteti a szomszédait és az IP-hírnevünket — ezt ésszerűen nem hagyhatjuk opcionálisan. Ami kiegészítőként kapható, az az egykattintásos kártevő-eltávolítás és -helyreállítás, valamint az olyan fejlett védelmi szintek, mint a továbbfejlesztett WAF-szabályok, a prioritási vizsgálat, a botkezelés és a magasabb szintű DDoS-védelem.
A rendszer nem lekapcsolja, hanem a saját elkülönített környezetén (cage) belül korlátozza azt. A korlátozás szigorúbb LVE-limiteket és sebességkorlátozást jelent, miközben a webhely továbbra is működik és kiszolgálja a kéréseket, a kiváltó ok megszűnése után pedig automatikusan visszaáll. Ön értesítést kap az okról, az átmenetet a bizonyítékaival együtt naplózzuk, és a döntés megfellebbezhető. Ha a terhelést valódi növekedés és nem hiba okozza, a megoldás egy nagyobb csomag, nem pedig a végleges korlátozás.
Nem — a felfüggesztett oldal egy márkajelzéssel ellátott, az okot megjelölő tájékoztató oldalt jelenít meg (számlázás, karbantartás vagy visszaélés), így szándékos leállításnak tűnik, nem pedig hibának. A felfüggesztés fizetés, hibajavítás vagy felülvizsgálati kérelem esetén megszűnik. A karantén szigorúbb és eltérően működik: kizárólag megtisztítás és ellenőrzés után szűnik meg, automatikusan soha.
A Zinn® Managed WordPress esetében igen — a CloudLinux alt-PHP minden webhely számára saját PHP-verzióválasztót, saját kiterjesztéseket (például imagick, gd és redis) és saját megerősített beállításokat biztosít, amelyeket a webhely LVE-korlátai határoznak meg. A Footprint-Free tárhely szándékosan szabványosítottabb, webhelyenként zárolt konfigurációt futtat, mivel maga a konfigurációs változatosság is digitális ujjlenyomatnak (footprint) minősül.
Igen. A CloudLinux LVE és a CageFS a sűrűségre optimalizált alapértelmezett megoldás mindkét termékcsaládban. A szigorúbb elkülönítést igénylő munkaterhelések esetén a webhelyenkénti teljes konténeres elkülönítés elérhető lefoglalási-illesztőprogram változatként — ugyanaz a motor és vezérlési sík eltérő elhelyezéssel, a nagyobb többletterhelést erősebb szétválasztásra cserélve.
Igen. A Footprint-Free tárhely egy bankkártya nélküli, 14 napos próbaidőszakkal indul, amely legfeljebb öt webhelyet fed le — fizetési adatok és elkötelezettség nélkül. Telepítsen néhány webhelyet, tegye ki őket némi terhelésnek, és nézze meg, hogyan viselkednek a ketrecek, mielőtt döntene.
Indítson el egy bankkártya nélküli 14 napos próbaidőszakot a Footprint-Free tárhelyen – akár öt webhely, fizetési adatok és kötelezettségek nélkül. A kernelszintű elkülönítés, a proaktív WAF és a kártevő-ellenőrzés már az első üzembe helyezéstől kezdve elérhető.
Kezdés ingyen