Stručně: U Managed Serveru převezme poskytovatel část bezpečnosti, typicky operační systém, balíčky PHP a standardní služby. Aplikace, pluginy, přístupy a odpovědnost z hlediska ochrany osobních údajů zpravidla zůstávají na vás. Po PHP2Shell byste měli obojí vyjasnit písemně: co poskytovatel udělal a co zůstává na vás?
Co „managed“ znamená a co ne
Pojem není chráněn. Jeden poskytovatel jím může rozumět jen instalaci aktualizací operačního systému, jiný pečuje i o webový server, PHP, databázi a zálohy. Některé tarify zahrnují nepřetržitý monitoring, jiné jen kontaktní osobu v pracovní době.
Právě u situace, jako je PHP2Shell, se ukáže, jak přesný je popis služeb. Obě zranitelnosti CVE-2026-109618 a CVE-2026-109619 leží v samotném PHP. Zda váš poskytovatel PHP spravuje jako součást své platformy, nebo zda PHP platí jako „váš software“, je uvedeno ve smlouvě. Nespoléhejte na předpoklad, že se o to už někdo stará.
Bezpečnost Managed Serveru: typické rozdělení úkolů
Následující tabulka ukazuje časté rozdělení. Nenahrazuje pohled do vaší smlouvy, pomáhá ale klást správné otázky.
| Oblast | Většinou u poskytovatele | Většinou u vás |
|---|---|---|
| Hardware, síť, virtualizace | ano | ne |
| Aktualizace operačního systému | ano | ne |
| Balíčky PHP z platformy | často | pokud nainstalovány samostatně |
| Restart PHP-FPM a webového serveru | často | u vlastních služeb |
| Konfigurace PHP pro celý server | často | u zvláštních požadavků |
| CMS, e-shop, pluginy, vlastní kód | ne | ano |
| Administrátorské účty aplikace | ne | ano |
| Zálohy | často | kontrola obnovení |
| Posouzení a oznámení porušení zabezpečení údajů | ne | ano |
| Sledování útoků | podle tarifu | podle tarifu |
Nejasná pole jsou skutečné riziko. Kde byste museli napsat „podle tarifu“ nebo „často“, chybí úprava.
Jaké otázky byste měli nyní položit
Pošlete svému poskytovateli krátký, věcný dotaz. Požádejte o odpověď v textové formě, abyste ji mohli později předložit. Měly by v něm být tyto body:
- Jaké verze PHP běží na našem serveru a jsou zabezpečeny proti CVE-2026-109618 a CVE-2026-109619?
- Od kdy to platí a byly poté restartovány všechny procesy PHP a webový server?
- Byla oprava nasazena jako backport? Pokud ano, jaká verze balíčku to dokládá?
- Existovaly náznaky pokusů o útok nebo nápadné procesy na našem serveru?
- Uchovávají se logy webového serveru od 20. 10. 2026 a jak je obdržíme?
Hotový vzor najdete na stránce Zeptejte se hostingu na stav záplat. Číslo verze v zákaznické administraci není doklad: u backportů často zůstává beze změny, například na 8.2.34.
I když poskytovatel PHP zazáplatoval, vaši aplikaci je třeba zkontrolovat. Záplata neodstraní škodlivý software zavlečený před aktualizací a nedokazuje, že se nic nestalo.
Co zůstává na vás
Vaše část zahrnuje především aplikaci. Zkontrolujte CMS, e-shop a pluginy, zda jsou aktuální, odstraňte nepoužívaná rozšíření a prohlédněte seznam administrátorů. Dávejte pozor na nové soubory v adresářích pro nahrávání, cizí přesměrování a neobvyklé plánované úlohy v aplikaci.
K tomu přistupuje právní stránka. Pokud se při incidentu dostanou osobní údaje do cizích rukou, oznamovací povinnost má zpravidla vaše firma jako správce, nikoli poskytovatel. Ten vás jako zpracovatel musí bez zbytečného odkladu informovat. Základy vysvětluje stránka Oznamovací povinnost podle GDPR: 72 hodin. Jde o obecnou informaci, nikoli o právní poradenství; konkrétní případ posoudí pověřenec pro ochranu osobních údajů nebo právník.
Další bod se často přehlíží: software, který jste na Managed Serveru nainstalovali vy nebo vaše agentura, například další verze PHP z cizího zdroje, kontejner nebo pomocný program, zpravidla pod péči poskytovatele nespadá. Zeptejte se proto také, zda poskytovatel ví, co vedle standardní výbavy běží. A vyjasněte, kdo v případě podezření převezme vyšetřování. Mnoho poskytovatelů platformu obnoví, ale nezkoumá, zda a jaká data byla dotčena. Právě tuto odpověď však potřebujete pro posouzení možných oznamovacích povinností.
Zlepšit smlouvy pro budoucnost
Využijte situace k tomu, abyste rozdělení úkolů zakotvili písemně. Smysl mají úpravy bezpečnostních aktualizací včetně restartu, informování o kritických zranitelnostech, uchovávání a vydávání logů a podpory při incidentech. Zeptejte se také, zda vás poskytovatel aktivně upozorňuje, nebo zda se musíte dotazovat sami.
Alternativou je vlastní server bez péče, který však přesouvá veškerou práci na vás. Co to znamená, popisuje stránka Vlastní zabezpečení root serveru a vServeru.
Jak konkrétně pomáhá PHP SOS?
- Přečteme váš popis služeb a sestavíme matici úkolů, která mezery zviditelní.
- Formulujeme technické otázky pro vašeho poskytovatele a vyhodnotíme jeho odpovědi.
- Zkontrolujeme část aplikace, která leží na vás, na stopy a zastaralé komponenty.
- Co poskytovatel nepokrývá, převezmeme na přání prostřednictvím smlouvy o bezpečnostní údržbě nebo doplníme bezpečnostním monitoringem.
Časté dotazy
Je u Managed Serveru automaticky vše zabezpečeno?
Ne. Managed znamená, že poskytovatel převezme určité smluvně stanovené úkoly, většinou operační systém a standardní služby. Aplikace, pluginy, přístupy a vlastní software často zůstávají na vás.
Kde je uvedeno, za co můj poskytovatel odpovídá?
V popisu služeb a ve smluvních podmínkách, často také v dokumentu o rozdělení úkolů. U osobních údajů přistupuje smlouva o zpracování osobních údajů. Pokud chybí jasná úprava bezpečnostních aktualizací, zeptejte se písemně.
Musím i přes Managed Server sám něco udělat kvůli PHP2Shell?
Ano. Vyžádejte si potvrzení, že všechny verze PHP jsou zazáplatovány a procesy restartovány. Zkontrolujte také svou aplikaci, zda nenese stopy, a vyjasněte, zda existuje oznamovací povinnost.
Kdo ohlásí porušení zabezpečení údajů, pokud byl dotčen poskytovatel?
Oznamovací povinnost vůči dozorovému úřadu má zpravidla správce, tedy vaše firma. Poskytovatel jako zpracovatel vás musí bez zbytečného odkladu informovat. Konkrétní případ nechte posoudit pověřencem pro ochranu osobních údajů.