BCDR és IT-üzemeltetés: „Mutasd a BCDR-t!” – üzletmenet-folytonosság a PHP2Shell idején

Frissítés, 2026. október: ezt az oldalt most teljesen átdolgoztam. A PHP2Shell sérülékenység kapcsán az elmúlt napokban annyiszor kerültek elő ugyanazok a kérdések, hogy úgy döntöttem, egy helyre összegyűjtöm, mit jelent a BCDR a gyakorlatban, és miért ez az első dolog, amit egy incidensnél látni akarok.

Az elmúlt napokban százszor is elhangzott ugyanaz a kérdés: „Csaba, mit csináljunk? Mit javasolsz?” Én pedig mindig ugyanazt kérdeztem vissza: mi van a BCDR-ban? Mutasd a BCDR-t.

A válasz szinte mindig ugyanaz volt. „Az nincs.” Vagy: „Van, de régi, évek óta nem frissült.” Vagy a legőszintébb: „Az mi?”

És itt a lényeg. Egy kritikus sérülékenységnél nem az a kérdés, hogy van-e javítás – a PHP2Shellre van. Hanem az, hogy a szervezet tudja-e, mekkora kockázatot bír el, mennyi ideig maradhat le egy rendszer, ki dönt a leállításról, és mit vállalt ebből a szolgáltató. Ezekre a kérdésekre a BCDR adja meg a választ. Ha nincs BCDR, akkor a döntést a pánik hozza meg.

Akik hívtak – és akiknél én vagyok az IBF

Nagyon sokan hívtak az elmúlt napokban, akik nem az ügyfeleim. Olyan cégektől, ahol nem a CSE Business Kft. az IT-üzemeltető partner, és nem én vagyok a CISO. Szívesen segítek, de ilyenkor nem látok bele a rendszerekbe, a szerződésekbe és a kockázatokba – és felelősen nem is mondhatok mást, mint hogy nézzük meg a BCDR-t.

Ahol én nyújtok IBF / CISO szolgáltatást, ott teljesen más a helyzet:

Kérdés	Ahol van élő BCDR	Ahol nincs (vagy régi)
Hol fut PHP?	Rendszerleltárból percek alatt kiderül	Napokig tartó keresgélés, „elfelejtett” szerverek
Mennyire kritikus a rendszer?	A BIA-ból tudjuk, RTO és RPO rendszerenként rögzítve	„Mindegyik fontos” – vagyis egyik sem priorizált
Ki dönt a leállításról?	Szerepek és döntési jogkörök előre rögzítve	Mindenki a másikra vár
Van WAF?	Igen, szabályokkal, ideiglenes szigorítás órákon belül	„Szerintem van tűzfal”
Mit vállal a szolgáltató?	SLA, patch-határidő, értesítési kötelezettség a szerződésben	Senki nem tudja, a szerződés a fiókban van
Visszaállás, ha baj van?	Tesztelt mentés, begyakorolt visszaállítás	„Van mentés” – de visszaállítani még soha nem próbálták

Mi a BCDR?

A BCDR két, egymáshoz szorosan kapcsolódó terület összefoglaló neve:

Business Continuity (BC) – üzletmenet-folytonosság: hogyan működik tovább a szervezet egy zavar alatt. Melyek a kritikus folyamatok, mi a kerülőmegoldás, ki mit csinál, hogyan kommunikálunk.
Disaster Recovery (DR) – katasztrófa utáni helyreállítás: hogyan állnak helyre az IT-rendszerek és az adatok egy leállás, támadás vagy katasztrófa után – milyen sorrendben, mennyi idő alatt, mennyi adatvesztéssel.

Egyszerűen fogalmazva: a BC arról szól, hogy az üzlet túlélje, a DR arról, hogy az IT visszaálljon. Az egyik a másik nélkül nem működik.

A fogalmak, amelyek nélkül nincs BCDR

Fogalom	Jelentés	Példa
BIA – Business Impact Analysis	Üzleti hatáselemzés: mi történik, ha egy folyamat vagy rendszer kiesik, és mennyibe kerül óránként	A webshop kiesése óránként X millió forint bevételkiesés
RTO – Recovery Time Objective	Mennyi idő alatt kell a rendszernek újra működnie	A betegfelvételi rendszer RTO-ja 4 óra
RPO – Recovery Point Objective	Legfeljebb mennyi adat veszhet el, időben kifejezve	RPO 1 óra = legfeljebb az utolsó egy óra adatai vesznek el
MTPD – Maximum Tolerable Period of Disruption	Az a leghosszabb kiesés, ami után a szervezet már maradandó kárt szenved	Három nap után a partnerek szerződést bontanak
Kockázati étvágy és tűrőképesség	Mekkora kockázatot hajlandó és képes a vezetés vállalni	„Egy napnál hosszabb leállást nem vállalunk”
SLA – Service Level Agreement	A szolgáltató által szerződésben vállalt szolgáltatási szint	99,9% rendelkezésre állás, 4 órás hibaelhárítás

Mit jelent a rendelkezésre állás számokban?

Az SLA-kban szereplő százalékok papíron nagyon hasonlítanak, a valóságban óriási a különbség:

Rendelkezésre állás	Megengedett kiesés évente	Havonta kb.
99%	3,65 nap	7,3 óra
99,9%	8,76 óra	43,8 perc
99,95%	4,38 óra	21,9 perc
99,99%	52,6 perc	4,4 perc
99,999%	5,26 perc	26 másodperc

Egy 99%-os SLA tehát évente több mint három nap kiesést enged meg – szerződésszerűen. Érdemes megnézni, mit írtunk alá.

Három opció – amíg nem látom a BCDR-t

Röviden: amíg nem látom a BCDR-t, a kockázatot és a vállalat tűrőképességét, addig három opciót adok. Negyedik nincs – a „majd lesz valahogy” nem opció.

1. opció – Leállítod, frissíted, pentesztelteted, újraindítod.

A webalkalmazást vagy webportált leállítod. Frissítik a PHP-motort, ellenőrzik, hogy nincs-e már kompromittálódás, lefut egy penteszt, és csak utána indul újra. Ez a legbiztonságosabb út – ára a kiesés. Ha a BIA szerint ezt a rendszer kibírja, ez a helyes döntés.

2. opció – Vállalod a felelősséget és a kockázatot, az IBF-fel / CISO-val együtt.

A rendszer fut tovább, de ez tudatos, dokumentált döntés. Az IBF / CISO pontosan tudja, mekkora a szervezet tűrőképessége, a kockázat le van írva, a kompenzáló kontrollok (WAF, szigorított szabályok, fokozott monitorozás) élnek, és a vezetés aláírásával elfogadja a kockázatot – határidővel, nem örökre.

3. opció – Tudatos döntés a BCDR, a kockázat és a szerződések ismeretében.

Tisztában vagy a BCDR-dokumentummal és a kockázattal. Tudod, milyen szerződéseid vannak a szolgáltatókkal, és mit vállalnak: mennyi idő alatt telepítik a kritikus frissítéseket, mikor értesítenek, ki fizeti a kárt. Ezek alapján döntesz – és ha a szolgáltató nem teljesít, tudod, mire hivatkozhatsz.

Ami mindhárom opcióban közös: a PHP-motort frissíteni kell. A kérdés csak az, hogy addig a rendszer áll, vagy dokumentált, vállalt kockázattal és kompenzáló kontrollokkal fut tovább. A felelősség pedig mindkét esetben a szervezet vezetéséé – nem az üzemeltetőé, és nem a szolgáltatóé.

IT-outsourcing: a szerződés nem egyenlő a biztonsággal

Ma a legtöbb cég IT-ja részben vagy egészben kiszervezett. Ez rendben van – ha jól csinálják. Egy IT-outsourcing szerződéshez a legtöbb esetben további mellékletek és szerződési feltételek tartoznak: SLA, rendelkezésre állás, hibaelhárítási idők, és az egész szolgáltatás az ügyfél igényeihez, BCDR-jához és SLA-elvárásaihoz igazodik.

Sajnos nap mint nap találkozunk olyan IT-szerződésekkel, ahol ezek nincsenek dokumentálva. Sőt, sem az ügyfél, sem az IT-szolgáltató nincs tisztában a rendszerekkel és a kockázatokkal. Az ügyfél azt hiszi, a szolgáltató „mindent intéz”, a szolgáltató pedig azt csinálja, amit a szerződés előír – ami sokszor alig több, mint „ha szól, megnézzük”.

Megosztott felelősség: ki mit csinál valójában?

Minden igénybe vett SaaS-, PaaS- vagy más felhős szolgáltatásnál ugyanaz a kérdés: hol ér véget a szolgáltató felelőssége, és hol kezdődik a miénk?

Terület	Saját szerver	IaaS	PaaS	SaaS
Fizikai infrastruktúra	Te	Szolgáltató	Szolgáltató	Szolgáltató
Operációs rendszer, frissítések	Te	Te	Szolgáltató	Szolgáltató
Futtatókörnyezet (pl. PHP)	Te	Te	Szolgáltató	Szolgáltató
Alkalmazás	Te	Te	Te	Szolgáltató
WAF, peremvédelem	Te	Te	Szerződés szerint	Szolgáltató – de neked kell ellenőrizni
Adatok, hozzáférések, jogosultságok	Te	Te	Te	Közös
BCDR, kockázatvállalás	Te	Te	Te	Te

Az utolsó sor a legfontosabb. A feladatot ki lehet szervezni, a felelősséget nem. Ha egy SaaS-szolgáltató kiesik vagy feltörik, a te ügyfeleid adatai kerülnek veszélybe, és a te cégednek kell megmagyaráznia – az ügyfeleknek, a hatóságnak, a partnereknek.

És ehhez nem kell felhő. Egy saját szerveren tárolt üzleti alkalmazásnak vagy weboldalnak ugyanúgy biztonságosnak kell lennie: frissítve, WAF mögött, mentve, és benne a BCDR-ban.

A vállalatok hibája – és hol van ilyenkor az IBF, a CISO?

Nap mint nap látok webalkalmazásokat és weboldalakat WAF nélkül, és IT-üzemeltető kollégákat, akik a biztonsági részt teljesen kihagyják. Szerintem ez elsősorban nem az ő hibájuk, hanem a vállalatoké: nem megfelelő szakembereket és nem megfelelő IT-üzemeltetőket bíznak meg, mert olcsóbb.

Ilyenkor jogos a kérdés: hol van az IBF, hol van a CISO? Ha egy szervezetnek nincs, vagy van, de csak papíron, akkor senki nem kérdezi meg, ami a legfontosabb: mi van kint az interneten, ki védi, és mi történik, ha holnap egy PHP2Shell jön? A WAF-ról és a WAF nélküli rendszerekről külön oldalon írtam részletesen.

Mire figyeljen minden cégvezető, aki IT- vagy SaaS-szolgáltatást vesz igénybe?

Ezeket a kérdéseket érdemes feltenni minden szolgáltatónak – szerződéskötés előtt, és utána évente. Ha egy szolgáltató ezekre nem tud válaszolni, az már önmagában válasz.

SLA és rendelkezésre állás: van-e írásos SLA, hány százalék, mi számít kiesésnek, és mi a kötbér, ha nem teljesül?
RTO és RPO: mennyi idő alatt áll helyre a szolgáltatás, és mennyi adat veszhet el? Összhangban van-e ez a saját BIA-nkkal?
Biztonsági frissítések: mennyi időn belül telepítik a kritikus javításokat? Van-e erre írásos vállalás (patch SLA)?
WAF és penteszt: WAF mögött fut-e a szolgáltatás? Van-e rendszeres, független penteszt, és kérhető-e róla vezetői összefoglaló?
Mentés: milyen gyakran mentenek, tesztelik-e a visszaállítást, és van-e offline vagy módosíthatatlan (immutable) másolat zsarolóvírus ellen?
Incidens-értesítés: mennyi időn belül értesítenek egy incidensről, és ki a kapcsolattartó éjjel-nappal?
Adatok helye és adatvédelem: hol tárolják az adatokat (EU / EGT?), ki fér hozzájuk, van-e GDPR szerinti adatfeldolgozói szerződés?
Tanúsítványok: ISO/IEC 27001, ISO 22301 (üzletmenet-folytonosság), SOC 2 – és érvényesek-e?
Alvállalkozók: kik a szolgáltató beszállítói, és rájuk is vonatkoznak-e ugyanezek a feltételek? Van-e auditjogunk?
Hozzáférések: kinél van az adminisztrátori hozzáférés, kötelező-e a többfaktoros azonosítás, és mi történik, ha a kulcsember elmegy?
Kilépési terv: ha szerződést bontunk vagy a szolgáltató megszűnik, hogyan, milyen formátumban és mennyi idő alatt kapjuk vissza az adatainkat?
Szabályozás: vonatkozik-e ránk a NIS2 irányelvet átültető hazai kiberbiztonsági törvény (2024. évi LXIX. törvény), pénzügyi szektorban a DORA, vagy egészségügyi adatkezelési előírás – és a szolgáltató ennek megfelelően működik-e?

Mit tartalmaz egy élő BCDR?

A BCDR nem egy 200 oldalas dokumentum, amit egyszer megírtak egy audit kedvéért. Akkor ér valamit, ha egy hajnali incidensnél elő lehet venni, és pontosan megmondja, mi a teendő. A minimum:

Rendszerleltár és függőségek: mi fut, hol fut, mi mitől függ – beleértve a felhős és SaaS-szolgáltatásokat is.
BIA: a kritikus folyamatok és rendszerek, RTO-val és RPO-val.
Szerepek és döntési jogkörök: ki dönt egy rendszer leállításáról, ki kommunikál, ki a helyettes.
Incidenskezelési és kommunikációs terv: kit, mikor, milyen csatornán értesítünk – ügyfelek, hatóság, partnerek.
Offline kontaktlista: ha a levelezés és a telefonrendszer is áll, akkor is elérhető legyen.
Mentés és visszaállítás: tesztelve, legalább egy offline vagy módosíthatatlan másolattal.
Beszállítói lista: szerződések, SLA-k, kapcsolattartók, eszkalációs útvonalak.
Vészhelyzeti change folyamat: hogyan kerül fel egy kritikus javítás gyorsan, de mégis kontrolláltan, visszaállítási tervvel.
Gyakorlatok: legalább évente egy DR-teszt vagy asztali gyakorlat.
Felülvizsgálat: évente, és minden jelentős változás vagy incidens után.

Ugyanezt a hiányt láttam az Autosecurit / Skyguard 40+ órás leállásánál is: amikor nincs BCDR, a kiesés nem órákig, hanem napokig tart.

Mit tegyél most, a PHP2Shell kapcsán?

Vedd elő a BCDR-t. Ha nincs, vagy régi, ez az első feladat – a mostani incidens után is.
Kérdezd meg az IT-szolgáltatót és minden SaaS-szolgáltatót: érintettek-e, frissítettek-e, és WAF mögött fut-e a szolgáltatás. Kérd írásban.
Válassz a három opció közül – tudatosan, dokumentáltan, határidővel.
Nézd meg, mit jelent a te weboldal-típusodnak a kockázati kézikönyvben, a technikai teendőket pedig a PHP2Shell-oldalon.

                            A tanulság egy mondatban: a BCDR nem fiókban porosodó papír, hanem az a lap, amit egy ilyen éjszakán elővesz az ember – ha nincs, akkor nem a szervezet dönt, hanem a véletlen.
                        

Ha szeretnéd, hogy átnézzük a BCDR-odat, az IT- és SaaS-szerződéseidet, vagy IBF / CISO szolgáltatásra van szükséged, keress a kapcsolati oldalon, a CSE Business oldalán vagy a LinkedInen.

BCDR és IT-üzemeltetés: „Csaba, mit csináljunk?” – „Mutasd a BCDR-t!”