# Kiberbiztosítás: mi számít káresetben > Kiberbiztosítás káresetben: mikor tájékoztassa a biztosítót, mik a jellemző kötelezettségek, és hogyan őrizheti meg szabályosan a bizonyítékokat. Forrás: https://phpsos.de/hu/compliance/cyberversicherung/ Állapot: 2026. 10. 25. Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6 **Röviden:** Kiberbiztosításnál káresetben főként háromféle dolog számít: korán tájékoztatni a biztosítót, bizonyítékokat menteni az elhamarkodott újratelepítés helyett, és a fontos lépéseket előre egyeztetni. Hogy pontosan mi érvényes, azt a biztosítási feltételei tartalmazzák. Ez az oldal általános tudnivalókat ad, nem jogi tanácsadás, és nem helyettesíti a biztosítóval, az alkusszal vagy az ügyvéddel való egyeztetést. > **Fontos:** > Nem jogi vagy biztosítási tanácsadás: kizárólag a szerződése és a biztosítója tájékoztatása mérvadó. A feltételeket legjobb, ha most olvassa el, nem csak éles helyzetben. ## Miért különleges a káresemény a kiberkockázatoknál Egy vízkárnál nyilvánvaló, mi történt. Egy webszerver elleni támadásnál ez másképp van: az elején gyakran csak egy gyanú áll, például egy különös fájl, egy szokatlan folyamat vagy a tárhelyszolgáltató figyelmeztetése. Hogy ténylegesen bekövetkezett-e kár, csak a vizsgálatnál derül ki. A PHP2Shell jó példa. A CVE-2026-109618 és a CVE-2026-109619 rés kódfuttatást tesz lehetővé bejelentkezés nélkül. Aki csak napokkal 2026. október 21. után javított, az nem zárhatja ki biztosan, hogy korábban történt valami. A javítás nem távolítja el a már bejuttatott kártevőt, és nem bizonyítja, hogy nem történt semmi. A kérdés, hogy fennáll-e biztosítási esemény és mikor, ezért gyakran nem egyértelmű. ## Kiberbiztosítás káresetben: a jellemző kötelezettségek A kötelezettségek (Obliegenheit) a szerződő fél olyan kötelességei, amelyek megsértése veszélyeztetheti a szolgáltatást. Sok kötvény hasonló pontokat tartalmaz, de a részletekben jelentősen eltérnek: - **Bejelentés:** a biztosítót indokolatlan késedelem nélkül tájékoztatni, amint biztosítási esemény bekövetkezett vagy fenyeget. - **Kárenyhítés:** elvárható intézkedéseket tenni a kár csekélyen tartására, például az érintett rendszereket levenni a hálózatról. - **Egyeztetés:** a lényeges lépéseket, megbízásokat és kifizetéseket előre tisztázni a biztosítóval. - **Tájékoztatás és igazolások:** információkat adni és olyan iratokat rendelkezésre bocsátani, amelyek a kár megállapításához szükségesek. - **Bizonyítékok megőrzése:** a nyomokat szükségtelenül nem megsemmisíteni, hogy az ok és a terjedelem megállapítható maradjon. Egyes szerződések emellett követelményeket tartalmaznak a kár előtti biztonságra, például rendszeres frissítésekre, mentésekre vagy többfaktoros bejelentkezésre. A szerződéskötéskor a kockázati kérdőívben megadott adatok is szerepet játszhatnak. ## Az első hívás a biztosítónál Sok kiberbiztosítás vészhelyzeti forródrótot kínál. Tartsa kéznél a biztosítási számot és egy rövid helyzetleírást. Az első kapcsolatfelvételnél tisztázza a következő kérdéseket, és a válaszokat jegyezze fel a beszélgetőpartner dátumával, időpontjával és nevével: 1. Hivatalosan be kell-e jelenteni az esetet, és milyen formában? 2. Biztosít-e a biztosító saját szolgáltatókat a forenzikához és a helyreállításhoz, vagy megbízhatunk sajátot? 3. Mely költségeket engedélyezték előre, melyekhez kell jóváhagyás? 4. Milyen iratokra van szükség? 5. Vannak-e előírások a kifelé irányuló kommunikációra vagy ügyvédek bevonására? ## Bizonyítékok mentése az újratelepítés előtt A támadás utáni érthető reflex a szerver azonnali újratelepítése. A biztosítás, az adatvédelem és egy esetleges feljelentés szempontjából ez gyakran kedvezőtlen, mert így nyomok tűnnek el. Jobb: az érintett rendszereket elkülöníteni, naplókat és memóriaképeket menteni, időbélyegekkel ellátott fájllistákat készíteni, és csak azután tisztítani vagy újraépíteni. A PHP2Shellnél a szakmai sajtó azt javasolja, hogy a szervernaplókat 2026. október 20-tól őrizzék meg. Közzétett, megerősített Indicators of Compromise eddig nincsenek; az észlelés viselkedéselemzésen alapul. Annál fontosabb, hogy a nyers adatok megmaradjanak. Szakszerű mentést az [IT-forenzika](https://phpsos.de/hu/leistungen/it-forensik/) nyújt. ## Együttműködés az adatvédelemmel és a feljelentéssel Egy biztosítási eset ritkán áll egyedül. Ha személyes adatok lehetnek érintettek, a GDPR 33. cikke szerinti bejelentési kötelezettség érvényes, lehetőleg a tudomásszerzéstől számított 72 órán belül. Erről többet itt talál: [GDPR-bejelentési kötelezettség](https://phpsos.de/hu/compliance/dsgvo-meldepflicht-72-stunden/). Sok biztosító ebben közvetített ügyvédekkel támogat. A rendőrségen tett feljelentés is lehet célszerű, vagy a biztosító kívánhatja. A tartományi bűnügyi hivatalok Zentrale Ansprechstellen Cybercrime (ZAC, központi kiberbűnözési kapcsolattartó pontok) szervezetei erre a megfelelő cím, lásd [Feljelentés tétele](https://phpsos.de/hu/compliance/anzeige-polizei-zac/). A sorrendet egyeztesse a biztosítóval. ## Előrelátás: a szerződés és a vészhelyzeti terv összevetése Vegye alkalomnak a jelenlegi helyzetet, hogy elolvassa a szerződését, és a kötelezettségeket átvegye a vészhelyzeti tervébe. A forródrót számát és a biztosítási számot olyan helyre írja be, amely működő IT nélkül is elérhető. Ellenőrizze, hogy a biztonsági állapotra vonatkozó adatai még helytállóak-e. Ebben segít egy strukturált [IT-vészhelyzeti terv](https://phpsos.de/hu/compliance/notfallplan-erstellen/). Hasznos emellett egy rövid beszélgetés az alkusszal vagy a biztosítóval káreseményen kívül. Kérdezze meg, hogyan kezeli a biztosító az olyan óvintézkedéseket, mint egy weboldal offline állapotba helyezése, milyen igazolásokat vár a frissítésekről, és vannak-e ajánlások a naplók megőrzésére. A válaszok írásban a vészhelyzeti tervbe tartoznak. ## Hogyan segít konkrétan a PHP SOS? - A naplókat és a rendszerállapotokat követhetően mentjük a tisztítás előtt, és minden intézkedést időponttal dokumentálunk. - Műszaki jelentést készítünk az okról, a terjedelemről és a megtett intézkedésekről, amelyet bemutathat a biztosítónak. - Kérésére egyeztetünk a biztosító szolgáltatóival. - Az [Incident Response](https://phpsos.de/hu/leistungen/incident-response/) keretében a dokumentált helyreállításig kísérjük az incidenst. ## Gyakori kérdések **Mikor kell tájékoztatnom a kiberbiztosítót?** Ezt a szerződése szabályozza. Sok feltétel indokolatlan késedelem nélküli bejelentést kíván, amint biztosítási esemény bekövetkezett vagy komolyan fenyeget. Kétség esetén jelezzen korán, akkor is, ha a terjedelem még tisztázatlan. **Megbízhatok magam egy IT-szolgáltatót?** Egyes kötvények vészhelyzeti forródrótot és a biztosító saját szolgáltatóit írják elő, vagy harmadik felek megbízása előtt egyeztetést kívánnak. Ezt tisztázza az első hívásnál, hogy a költségek ne legyenek vitatottak. A választ rögzítse írásban. **Fizet a biztosítás, ha hiányzott egy frissítés?** Ez a feltételektől, a szerződéskötéskor megadott adatoktól és az egyedi esettől függ. Egyes szerződések követelményeket tartalmaznak a technika állására vagy a frissítésekre. Ezt a kérdést értékeltesse a biztosítási alkusszal vagy egy ügyvéddel. **A puszta javítás már biztosítási esemény?** Egy óvintézkedésként végzett frissítés általában még nem kár. Ha viszont vannak jelek betörésre, ez megváltozhat. Kérdezze meg a biztosítóját, mikortól kíván tájékoztatást. ## Források - [BSI](https://www.bsi.bund.de/) - [GDPR 33. cikk](https://dsgvo-gesetz.de/art-33-dsgvo/) - [php.net: biztonsági közlemények](https://www.php.net/)