Webhelyenkénti elszigetelés
Az izoláció jelenti a különbséget egy incidens és egy leállás között. Minden áhított webhelyünk egy kernel szintű CloudLinux LVE környezetben fut, saját CPU-, RAM-, I/O- é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, feltört vagy egyszerűen csak erőforrás-igényes lekérdezést futtató webhely a saját helyén marad elszigetelve – és ez az elszigetelési alapcsomag minden csomagban benne van, nem pedig felár ellenében értékesítjük extraként. Elérhetőség: a webhelyenkénti adatbázis-szabályozás és a webhelyenkénti erőforrásstatisztika aktív fejlesztés alatt áll, és még nem érhető el. Minden egyéb itt leírt funkció már ma is él.
A worker flotta CloudLinux OS-t futtat, amely a többfelhasználós architektúrát mélyen a kernelbe ágyazza. Minden egyes webhely egy Lightweight Virtual Environmentet — egy LVE-t — kap, amely egy szigorú határvonal, nem pedig egy udvarias egyezmény. Semmi, amit egy webhely a saját keretén belül tesz, nem vonható le más költségvetéséből.
Az LVE korlátozza a CPU-t, a RAM-ot, az IO-t, az IOPS-ot, a folyamatokat és a belépési folyamatokat minden egyes webhely esetében külön-külön. Amikor egy webhely túllépi a felső határát, a saját keretén belül korlátozásra kerül – a hiba a webhelyhez rögzítésre kerül, a mellette lévő webhelyek pedig zavartalanul működnek tovább.
Egy végtelen ciklusban ragadt bővítmény, egy rosszul megírt cron feladat vagy egy végpontot bombázó keresőrobot először a webhely saját folyamat- és belépési folyamat-korlátait éri el. Egyetlen webhely nem merítheti ki egyszerűen a gépet.
Mivel a belépési folyamatok keretenként korlátozva vannak, az egyik webhelyre irányuló áradat nem nyithat korlátlan számú munkát a hosztnál. A LiteSpeed kapcsolat- és kérésfojtás, valamint az Imunify360 hálózati tűzfal ezek előtt helyezkedik el, így a támadás a célpont problémája marad.
Minden egyes LVE hiba webhelyenként kerül rögzítésre, és betáplálódik a platform szabályzat-motorjába, amely automatikusan szigoríthatja vagy enyhítheti a korlátokat. Ön láthatja, hogy egy webhelyet miért és mikor korlátoztak – fokozatosan, visszafordíthatóan és naplózva.
Az erőforrás-izoláció megakadályozza, hogy egy webhely túl hangos legyen. Fájlrendszer-izoláció megakadályozza, hogy túl kíváncsi legyen. A CageFS minden egyes ügyfélnek a gép privát, korlátozott nézetét biztosítja.
A CageFS alatt a bérlő csak a saját fájljait és a rendszerbinárisok minimális, tisztított készletét látja — a többi bérlőt, a többi bérlő webhelyét vagy az érzékeny rendszerfájlokat azonban nem. A szokásos osztott tárhelyes hibaforrás, amely során egy feltört fiók azonos olvasási pozícióba hozza a támadót a szerveren lévő összes többi fiókkal szemben, a kernel szintjén le van zárva.
Ez abban a pillanatban számít a legtöbbször, amikor valami elromlik. Ha egy webhelyet feltörnek – egy elavult bővítmény, ellopott bejelentkezési adatok vagy sebezhető téma miatt –, a CageFS az, ami az érintett területet az arra az egyetlen „ketrecre” korlátozza. Biztonsági specifikációnk tudatosan fogalmaz: a CageFS bezárja a biztonsági rések hatását. A kármentesítés az őszinte ígéret, és ez dönti el, hogy egy incidens egynapos webhelytisztítás vagy teljes hálózatra kiterjedő vészhelyzet-e.
A biztonsági mentések ugyanezt a határvonalat erősítik meg. Az oldalankénti biztonsági mentések megváltoztathatatlanok, külső helyszínen tároltak és el vannak választva a futó gépparktól, tesztelt visszaállítással, így még egy webhelyet érintő legrosszabb esetben is tiszta, független helyreállítási útvonal áll rendelkezésre, amely nem függ annak a gépnek az állapotától, amelyen futott.
A webszintű izoláció csak a történet fele. Egy WordPress flottánál a szervert leggyakrabban nem az egyik oldal forgalma lassítja le, hanem az lekérdezései. Ezt kifejezetten kezeljük.
A CloudLinux MySQL Governor webhelyenként korlátozza az adatbázis-használatot, így egyetlen webhely túlterhelő lekérdezései sem lassíthatják le a szervert a többi felhasználó számára. Ez a lassulásgátló vezérlő, amely attól függetlenül működik, hogy a zajos webhely észreveszi-e a korlátozást vagy sem.
A flotta MariaDB-t (vagy Percona-t) használ, amelyet a WordPress munkaterhelésekhez választottunk ahelyett, hogy alapértelmezésként örököltük volna, és a tetején a Governor fut bérlőnkénti igazságosság rétegként.
A webhelyenkénti Redis objektumgyorsítótár elnyeli az ismétlődő olvasásokat, mielőtt azok elérnék az adatbázist, ami csökkenti azt a nyomást, amelyet a Governornek eleve kezelnie kell. A gyorsítótárazás és az izoláció egyetlen rendszerként működik.
A CloudLinux alt-PHP minden egyes webhely számára biztosít 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 – az adott webhely LVE-korlátai által határolt LSAPI-munkafolyamatokkal, így a PHP-konkurencia a keret részét képezi, nem pedig egy abból való kitörést.
Az izoláció határozza meg, hogy egy probléma milyen messzire terjed. A kényszerítés dönti el, hogy mi történik ezután. A túlzottan egyszerű ki/bekapcsolásos felfüggesztést egy állapotgépre cseréltük, amelyet tartós munkafolyamatok irányítanak, és a workeren keresztül a LiteSpeed, az LVE és az Imunify kényszerít ki.
Az izoláció nem egy olyan csomagfunkció, amely három szinttel feljebb jelenik meg. Ez az infrastruktúra tulajdonsága, így teljesen azonos, függetlenül attól, hogy egyetlen WooCommerce áruházat vagy kétezer hálózati webhelyet futtat.
A tömeges és PBN hálózatok ugyanazon az LVE és CageFS infrastruktúrán futnak, a keresőoptimalizálási nyomokat kiszűrő CDN-fiókrotációval és statikus HTML-kézbesítéssel együtt. Az izoláció teszi biztonságossá a sűrűséget: a webhelyek osztoznak egy flotta erőforrásain, de nem osztoznak a sorsukon.
A Managed WordPress, WooCommerce, PHP, statikus és Node oldalak ugyanazokat a kereteket kapják teljes önkiszolgálással kiegészítve – saját PHP-verzióval és -bővítményekkel, Redis objektumgyorsítótárral, tesztkörnyezettel és élesítés funkcióval.
Azoknak a feladatoknak, amelyek a sűrűségre optimalizált alapértelmezettnél erősebb elhatárolást igényelnek, a teljes webhelyenkénti tárolóalapú izoláció kiépítési-illesztőprogram variánsként érhető el: ugyanez a motor, ugyanaz a vezérlősík, eltérő elhelyezés, nagyobb többletterhelés mellett.
Az LVE és CageFS izoláció, a proaktív WAF és a kártevővizsgálat minden ügyfél számára biztosított, mivel egy fertőzött vagy elszabadult webhely veszélyezteti a szomszédait és a mi IP-reputációnkat. 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 üzletileg csábító dolog a biztonságot csomagokba sorolni: az olcsó ügyfeleket puha korlátokkal ellátott, közös szerverre tenni, és teli árat számolni azoknak, akik törődnek az elszigeteltséggel. Mi ezt nem tesszük, mert az az ügyfél, aki nem fizetett az izolációért, éppen az, akinek a feltört oldala mindenki más számára incidenssé válik.
Világszerte több mint 650 000 webhelyet üzemeltetünk olyan szerverflettán, ahol a sűrűség jelenti a teljes gazdasági koncepciót. Ez csak úgy működik, ha az alatta lévő izoláció feltétel nélküli. A rendszermag szintű elszigetelés, a privát fájlrendszernézet, a webhelyenkénti adatbázis-szabályozás és a webhelyenkénti PHP az ára annak, hogy ilyen léptékben, sorsközösség nélkül tudjunk működni – így ezek mindenkinél, minden csomagban be vannak kapcsolva, az első telepített 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 izolációt kifejezetten arra tervezték, hogy megállítsa ezt. Az LVE korlátozza webhelyenként a CPU-t, a RAM-ot, az IO-t, az IOPS-ot és a folyamatokat, a MySQL Governor szabályozza a webhelyenkénti adatbázis-használatot, az LSAPI-munkafolyamatok pedig a webhely saját keretébe vannak zárva – így a szomszédos webhely forgalmi csúcsai vagy nehéz lekérdezési terhelése a saját korlátján belül marad, nem a tiéden. Minden hiba webhelyenként naplózásra kerül, és a házirendmotor automatikusan szigoríthatja a zajos webhelyek korlátait.
Az őszinte válasz a bezárás, nem pedig a garancia. A CageFS minden egyes bérlőnek elszigetelt fájlrendszer-nézetet biztosít — a kompromittálódott bérlő nem láthatja a többi bérlőt, azok webhelyeit vagy a bizalmas rendszerfájlok –, és egy megerősített rosszindulatú szoftver vagy adathalászat esete a webhelyet karanténba helyezi: offline állapotba, zárolt fájlokkal, végrehajtás nélkül, igazságügyi vizsgálat céljából elszigetelve. Ez az, ami korlátozza a robbanási sugarat. Ezzel párhuzamosan minden webhelyen rosszindulatú szoftverek keresését és proaktív WAF-ot futtatunk, valamint webhelyenkénti, módosíthatatlan, külső helyszíni biztonsági mentéseket tesztelt visszaállítással, így a helyreállító művelet soha nem függ az érintett gép állapotától.
Minden csomag tartalmazza. Az LVE- és CageFS-izoláció, a proaktív WAF és a kártevőkeresés minden ügyfél számára alapfelszereltség, mivel egy fertőzött vagy elszabadult webhely veszélyezteti a szomszédait és a IP-hírnevünket – ezt nem tehetjük megfontoltan opcionálissá. Amit kiegészítőként értékesítünk, az az egykattintásos kártevő-eltávolítás és helyreállítás, valamint a fejlett védelmi szintek, mint például a továbbfejlesztett WAF-szabályok, a prioritásos vizsgálat, a botkezelés és a magasabb DDoS-szintek.
A rendszer a teljes kikapcsolás helyett a saját keretein belül korlátozza. A korlátozás szigorúbb LVE-limiteket és sebességkorlátozást jelent úgy, hogy a webhely továbbra is elérhető marad és kiszolgálja a kéréseket, és az ok megszűnése után automatikusan helyreáll. Az okról értesítést kap, az átmenetet a bizonyítékaival együtt naplózzuk, és a döntés fellebbezhető. Ha a terhelés valós növekedésből és nem hibából adódik, a megoldás egy nagyobb csomag, nem pedig az állandó korlátozás.
Nem – a felfüggesztett webhely egy márkajelzéssel ellátott, ok-specifikus nyitóoldalt (számlázási, karbantartási vagy visszaélési) jelenít meg, így az szándékosnak tűnik, nem pedig hibásnak. A felfüggesztés fizetés, javítás vagy fellebbezés esetén oldódik fel. A karantén szigorúbb és másként működik: csak takarítás és felülvizsgálat után oldódik fel, soha nem automatikusan.
A Zinn® Managed WordPress hostingeken igen — a CloudLinux alt-PHP mindegyik webhelynek saját PHP-verzióválasztót, saját kiterjesztéseket, például imagick, gd és redis, valamint saját megerősített beállításokat biztosít, amelyeket az adott webhely LVE-korlátai határolnak be. A Footprint-Free Hosting szándékosan egy egységesebb, jobban lezárt webhelyenkénti konfigurációt futtat, mivel a konfigurációs változatosság maga is egy footprint.
Igen. A CloudLinux LVE és a CageFS a sűrűségre optimalizált alapértelmezett beállítás mindkét termékcsaládban. Azon munkaterhelések esetében, amelyek szigorúbb határt igényelnek, a teljes webhelyenkénti konténer-izoláció kiépítési meghajtó (provisioning-driver) variánsként érhető el – ugyanaz a motor és vezérlőpík (control plane) eltérő elhelyezéssel, amely a nagyobb elszigeteltség érdekében feláldozza a többletterhelést (overhead).
Igen. A Footprint-Free Hosting egy kártya nélkül indítható, 14 napos próbaverzióval kezdődik, amely legfeljebb öt webhelyet fed le – nincs szükség fizetési adatokra, és semmilyen elkötelezettséggel nem jár. Telepítsen néhány webhelyet, indítson rajtuk terhelést, és nézze meg, hogyan viselkednek a ketrecek, mielőtt döntést hozna.
Kezdj el egy kártya nélkül igénybe vehető 14 napos próbaidőszakot a Footprint-Free Hosting szolgáltatással – legfeljebb öt webhely, nincs szükség fizetési adatokra, nincsenek kötelezettségek. A rendszermag szintű izoláció, a proaktív WAF és a kártevővírus-keresés az első üzembe helyezéstől kezdve biztosított.
Kezdje ingyen