Röviden: Egy IT-szolgáltatóval kötött szerződés a biztonságot ne csak mellékesen említse, hanem konkrétan szabályozza: ki mely komponenseket frissíti, milyen határidővel és milyen igazolással, hogyan tájékoztatnak a kritikus résekről, ki működik közre incidens esetén, hogyan őrzik a naplókat és kezelik a hozzáféréseket, és mi történik a kilépéskor. Ez az oldal általános útmutatást ad, és nem jogi tanácsadás; a szerződéseket ügyvéd ellenőrzi.
A kérdés, amelyet a PHP2Shell feltett: ki a felelős?
- október 21-én német idő szerint 16 órakor a PHP-projekt közzétette a javításokat. A BSI (a német Szövetségi Információbiztonsági Hivatal) azonnali frissítést javasolt, vagy ahol ez nem ment, a webszerverek átmeneti lekapcsolását a hálózatról. Sok vállalatnál ezután nem a munka kezdődött el, hanem a felelős keresése. Az ügynökség a tárhelyszolgáltatóra mutatott, a tárhelyszolgáltató a szerződésre, a szerződésben pedig az állt: „karbantartás ráfordítás szerint”.
Az ilyen szerződéses hézagok nem egyedi esetek. Az ügynökségekkel és szolgáltatókkal kötött szerződések sok esetben akkor jöttek létre, amikor egy weboldal megépítéséről volt szó, nem annak évekig tartó biztonságos üzemeltetéséről. Egy kritikus rés a PHP futtatókörnyezetében, amely sem a CMS-t, sem az alkalmazáskódot nem érinti, ilyenkor könnyen az összes szék közé esik.
Mit kell szabályoznia a biztonságról egy IT-szolgáltatói szerződésnek
A következő áttekintés azokat a pontokat nevezi meg, amelyek a gyakorlatban fontosnak bizonyultak. Nem helyettesíti a jogi ellenőrzést, de segít felismerni a meglévő szerződés hézagait.
| Szabályozási pont | Mit kell rögzíteni | Kapcsolat a PHP2Shellel |
|---|---|---|
| A szolgáltatás terjedelme | Mely rétegeket gondozzák: operációs rendszer, PHP futtatókörnyezet, webszerver, CMS, bővítmények, saját kód | A PHP futtatókörnyezet gyakran hiányzott a felsorolásból |
| Frissítési határidők | súlyosság szerint lépcsőzve, vészhelyzeti kivételszabállyal | kritikus rés, CVSS v4.0 9.2 |
| Újraindítás és igazolás | A frissítések csak az összes folyamat újraindítása után számítanak elvégzettnek, írásbeli igazolással | az új fájlok önmagukban nem zárják le a rést |
| Tájékoztatás | aktív értesítés kritikus réseknél, értékeléssel és tervvel | sok ügyfélnek magának kellett rákérdeznie |
| Közreműködés incidenseknél | támogatás az elemzésben, biztosításban, helyreállításban, kapcsolattartó | nyomkeresés a javítás után |
| Naplók | fajta, megőrzés, kiadás kérésre | a szaksajtó azt javasolta, hogy a naplókat október 20-tól biztosítsák |
| Hozzáférések | személyes fiókok, kétfaktoros bejelentkezés, az összes hozzáférés listája | tulajdonképpen kinek volt hozzáférése? |
| Alvállalkozók | ki vesz még részt, tájékoztatás váltáskor | a tárhelyszolgáltató tárhelyszolgáltatója |
| Szoftver életciklusának vége | időben jelzés a támogatás megszűnése előtt, migrációs terv | a PHP 8.2 2026. december 31-én ér véget |
| Kilépés | adatok, dokumentáció és hozzáférések kiadása, a jogok visszavonása | váltás egy incidens után |
Határidők és igazolások: a legtöbbet számító pontok
A határidők a lényeg. Az olyan megfogalmazás, mint a „haladéktalanul”, éles helyzetben nem visz tovább. Állapítson meg határidőket súlyosság szerint külön, és rögzítse, mihez mérik a súlyosságot, például a gyártó vagy a BSI besorolásához. Rendkívüli helyzetekre vészhelyzeti szabálynak kell érvényesnie: ki érhető el, ki dönt arról, hogy egy rendszert átmenetileg lekapcsolnak-e a hálózatról, és hogyan számolják el a többletmunkát.
Ugyanilyen fontos az igazolás. A PHP2Shellnél a megjelenített verziószám gyakran keveset mondott, mert a disztribúciók és a tárhelyszolgáltatók a javításokat backportként telepítik. Egy terhelhető igazolás megnevezi a csomagállapotot, a telepítés időpontját és az összes PHP-folyamat újraindítását. Hogy pontosan mely adatok számítanak, azt a Így kérdezze meg a tárhelyszolgáltatóját a patch-állapotról írja le. Vegye fel ezeket az adatokat kötelező tartalomként a szerződésbe.
Kérjen a szolgáltatótól a szerződéshez feladatmátrixot: komponensenként egy sort, feladatonként egy oszlopot, minden cellában egy névvel. A hézagok így azonnal feltűnnek, jóval a következő közlemény előtt.
Hozzáférések, alvállalkozók és kilépés
A szolgáltatóknak hozzáférések kellenek, és éppen ezek gyakori támadási útvonalak. Szabályozza, hogy minden személy saját fiókot kap, hogy a kétfaktoros bejelentkezés kötelező, ahol a technika ezt lehetővé teszi, és hogy bármikor kérhet naprakész listát az összes hozzáférésről. A szolgáltató kilépő munkatársait időben el kell távolítani az összes rendszerből.
Ha a szolgáltató maga is partnerekkel dolgozik, például egy adatközponttal vagy egy specializált forenzikai csapattal, tudnia kell róla. Ha ezen partnerek egyike személyes adatokat dolgoz fel, adatvédelmi jogi kötelezettségek jönnek hozzá. Többet erről az Adatfeldolgozás, ha szolgáltatók férnek hozzá a szerverekhez cikkben talál.
A kilépést szerződéskötéskor felejtik el a leggyakrabban. Rögzítse, hogy a szerződés végén az adatokat, a konfigurációt, a dokumentációt és a hozzáférési adatokat teljes egészében átadják, a szolgáltató összes hozzáférését visszavonják, és ezt írásban megerősítik. Éppen egy incidens után egy rendezett váltás különben nehéz.
Meglévő szerződések ellenőrzése: így járjon el
Nem kell az összes szerződést újratárgyalnia. A kezdéshez egy pragmatikus folyamat elég:
- Összegyűjteni az összes ügynökséggel, tárhelyszolgáltatóval és IT-szolgáltatóval kötött szerződést, amely weboldalakat vagy szervereket érint.
- Minden szerződést összevetni a fenti táblázattal, és megjelölni a nyitott pontokat.
- A legfontosabb hézagokat írásban felvetni a szolgáltatónál, a szolgáltatás terjedelmével, a határidőkkel és az igazolással kezdve.
- Az eredményeket kiegészítő megállapodásban rögzíteni, és jogilag ellenőriztetni.
- A feladatmátrixot átvenni a vészhelyzeti tervbe.
Az ügyvezetés számára ez a lépés gondosság kérdése is. Aki egyértelműen szabályozza a felelősségeket és dokumentálja a döntéseket, jobban áll, ha később kérdéseket tesznek fel. Háttérinformációt ad az Az ügyvezetés felelőssége IT-biztonsági rések esetén. A gondozott szervereknél a tipikus feladatmegosztást a Managed szerver: a felelősség tisztázása írja le.
Hogyan segít konkrétan a PHP SOS?
- Műszaki szemszögből elolvassuk a meglévő szerződéseit és szolgáltatásleírásait, és megjelöljük, mely komponensek és feladatok hiányoznak.
- Feladatmátrixot készítünk az összes weboldalhoz és szerverhez, amelyet egyeztethet a szolgáltatóival.
- Megfogalmazzuk a határidőkre, igazolásokra és jelentési útvonalakra vonatkozó műszaki követelményeket, amelyeket az ügyvédje átvehet a szerződésbe.
- Ahol senki sem felelős, a feladatokat mi magunk vesszük át egy egyértelműen leírt terjedelmű biztonsági karbantartási szerződés keretében.
Összegzés: Egy jó szerződés nem akadályoz meg egy biztonsági rést, de megakadályozza, hogy éles helyzetben idő vesszen el a felelősség kérdésével. Ez az oldal általános információ, nem jogi tanácsadás.
Gyakori kérdések
Köteles egy IT-szolgáltató megbízás nélkül biztonsági frissítéseket telepíteni?
Ez a szerződéstől függ. Egyértelmű szabályozás nélkül gyakran vitatott, hogy a frissítések a vállalt szolgáltatáshoz tartoznak-e. Ezért a szerződésnek kifejezetten rögzítenie kell, ki mely komponenseket frissíti, és milyen határidővel. Az egyedi esetben a jogi értékelés ügyvéd feladata.
Kell mellé adatfeldolgozói szerződés (AVV) is?
Ha a szolgáltató megbízásból személyes adatokat dolgoz fel, vagy hozzáférhet hozzájuk, általában a GDPR 28. cikke szerinti adatfeldolgozói szerződésre van szükség. Ez nem helyettesíti a szolgáltatási szerződést, hanem kiegészíti. Egyeztesse az adatvédelmi tisztviselőjével.
Milyen határidők szokásosak a biztonsági frissítésekhez?
Rögzített értékek nincsenek. Értelmes a súlyosság szerinti lépcsőzés, például külön határidők a kritikus, a magas és a többi résre. Fontos, hogy a határidők írásban álljanak, és tartalmazzanak kivételszabályt olyan vészhelyzetekre, mint a PHP2Shell.
Mi történik a hozzáférésekkel, ha a szerződés véget ér?
Ezt a szerződésnek kell szabályoznia: az adatok visszaadása vagy törlése, a hozzáférési adatok és a dokumentáció kiadása, a szolgáltató összes hozzáférésének visszavonása és erről megerősítés.