Csütörtök délután. Egy tízfős pozsonyi szoftvercég ügyvezetője megnyit egy e-mailt a legnagyobb ügyfelétől. Egy banktól. A mellékletben egy hosszú kiberbiztonsági kérdőív az adattitkosításról, az incidenskezelésről, a penetrációs tesztelésről, a hozzáférés-kezelésről, a mentésekről és a katasztrófa utáni helyreállításról.
A cégnek jó bérszámfejtő SaaS terméke van, amelyet több száz ügyfél használ. Az incidenskezelési folyamata azonban nincs formalizálva, és a legutóbbi penetrációs teszt már nem fedi le a rendszer aktuális verzióját. Nem tud a banknak ellenőrizhető válaszokat adni.
Ez egyre gyakrabban fordul elő. Az oknak neve van: NIS2.
A NIS2 (Network and Information Security Directive 2) egy uniós irányelv. Szlovákia a kiberbiztonságról szóló 69/2018 sz. törvény módosításával ültette át, amely 2025. január 1-jén lépett hatályba. Olyan szektorok szereplőire vonatkozik, mint az energetika, a közlekedés, az egészségügy, a digitális infrastruktúra és egyes digitális szolgáltatások. A pontos hatályt a szlovák törvény alapján kell ellenőrizni, nem pusztán a cég méretéből levezetni.
Az Ön szoftvercége talán nincs ezen a listán. Néhány ügyfele viszont igen.
A NIS2 előírja a szabályozott szereplők számára, hogy a teljes ellátási láncukban kezeljék a biztonsági kockázatokat. A 21. cikk kifejezetten hivatkozik „az ellátási lánc biztonságára, beleértve az egyes szervezetek és közvetlen beszállítóik vagy szolgáltatóik közötti kapcsolatok biztonsági vonatkozásait". A gyakorlatban ez azt jelenti, hogy az a bank, amely az Ön bérszámfejtő rendszerét használja, felelős azért, hogy Ön beszállítóként megfeleljen egy bizonyos biztonsági szintnek.
A NIS2 tehát közvetlenül nem szabályozza az Ön cégét, és mégis az Ön asztalán landol. Az ügyfelei olyan kérdéseket kezdenek feltenni, amelyekre tudnia kell válaszolni. Ha nem tud, alternatívát keresnek.
Mit vár el egy vállalati ügyfél egy SaaS-beszállítótól? Az ügyfeleinknél látott kérdőívek alapján több terület is rendszeresen visszatér.
Kinek van hozzáférése az éles adatokhoz? Hogyan adják ki és vonják vissza a jogosultságokat? Van MFA az adminisztrátoroknak? Betartják a legkisebb jogosultság elvét? Amikor egy fejlesztő kilép a cégtől, mennyi idő telik el, amíg megszűnik az infrastruktúrához való hozzáférése?
A legtöbb kis szoftvercég eseti alapon kezeli a hozzáféréseket. A csapat fele ismeri az adatbázis admin jelszavát. Az SSH-kulcsokat nem cserélik. Egy távozó munkatársnak egy héttel később is van éles hozzáférése, mert „nem jutottunk el odáig, hogy visszavonjuk". Egy vállalati ügyfél számára ez elfogadhatatlan.
Átvitel közben használjon jelenleg támogatott TLS-verziót, nyugalmi állapotban pedig erős, felügyelt kulcsokkal végzett titkosítást. Ez vonatkozik az adatbázisokra, a mentésekre és a naplókra is. A titkosítatlan mentés vagy a megfelelő hozzáférés-ellenőrzés nélküli naplók komoly kockázatot jelentenek.
Vizsgálja a függőségeket? Milyen gyakran? Mi történik, ha egy Ön által használt könyvtárban kritikus CVE jelenik meg? Határozzon meg kockázatalapú javítási határidőket, és őrizze meg a bizonyítékot arról, hogy a problémákat kiértékelték és kijavították. A szoftverösszetevő-jegyzék (SBOM) segíthet az ügyfélnek gyorsabban felmérni egy új sebezhetőség hatását.
Kódellenőrzés, statikus elemzés, biztonsági tesztelés a kiadás előtt. Ha csak néha végez kódellenőrzést, és nincsenek automatizált biztonsági vizsgálatok, ez az első terület, amit érdemes fejleszteni. Az ügyfelek rákérdeznek az SDLC-folyamatra. Ha nincs dokumentálva, a „csináljuk a kódellenőrzést" nem elegendő válasz.
A NIS2 előírja a szabályozott szereplőknek, hogy jelentsék a biztonsági incidenseket. Az észleléstől számított 24 órán belül korai figyelmeztetésnek kell érkeznie, 72 órán belül részletes bejelentésnek, egy hónapon belül pedig záró jelentésnek.
Beszállítóként ez közvetetten érinti Önt. Ha az Ön SaaS-rendszerében adatvédelmi incidens történik, az ügyfelének (a banknak, a biztosítónak) jelentenie kell az incidenst a szabályozó hatóságnak. És információra lesz szüksége Öntől. Mi történt, mikor, mekkora volt a kiterjedése, mely adatok érintettek és milyen lépéseket tett.
Incidenskezelési terv nélkül nem tudja időben megadni ezeket az információkat. A „szólunk, amint kivizsgáltuk" nem olyan válasz, amelyet egy bank elfogad, amikor 24 órája van jelenteni a szabályozónak.
Egy kis cég incidenskezelési tervének nem kell 50 oldalas dokumentumnak lennie. Tudnia kell, ki a kapcsolattartó, melyik kommunikációs csatornát kell használni, ki állíthatja le a rendszert, hol vannak a naplók, és ki tudja azokat elemezni. A folyamatot le kell írni, rendszeresen tesztelni kell, és a rendszer lényeges változásai után frissíteni kell.
Az eseménynaplók segítenek a biztonsági vizsgálatokban és más kötelezettségek teljesítésében. Például a magas kockázatú MI-rendszereknek az AI Act szerint szintén megfelelő naplózásra van szükségük. Nincs szükség külön naplózási platformra minden egyes szabályozáshoz. Egyetlen jól megtervezett auditnaplóra van szükség, amely lefedi a biztonsági eseményeket, az MI-döntéseket és a fontos adatváltozásokat.
A gyakorlatban ez strukturált naplókat jelent időbélyeggel, a szereplő azonosságával, a művelet típusával és eredményével. A megőrzési időt a cél, a kockázat, a szerződés és a vonatkozó szabályok szerint kell meghatározni. Nincs egyetlen univerzális időtartam minden rendszerre. A naplóknak manipulációval szemben ellenállónak és auditra elérhetőnek kell lenniük anélkül, hogy két napig kellene olvashatatlan szövegfájlokban keresgélni.
Az ellátási lánc biztonsága a NIS2 szerint azt jelenti, hogy a szabályozott ügyfele bizonyítékot fog kérni. Nem ígéreteket. Bizonyítékot.
Szabványosított űrlapok (gyakran a Cloud Security Alliance CAIQ-jén vagy az ügyfél saját sablonján alapulnak), amelyeken a titkosításról, a hozzáférésekről, a tesztelésről és a mentési szabályzatokról tesznek fel kérdéseket. Ha nincsenek előre elkészített válaszai, minden kérdőív több napi munkájába kerül.
Egy ügyfél kérhet ISO 27001-et vagy más független bizonyítékot. A tanúsítás nem helyettesíti a működő technikai kontrollokat. Ha nincs ilyen, más megállapodott módon kell bizonyítania, hogy a folyamatok léteznek és működnek.
A hatókört és a gyakoriságot a kockázat és a szerződés szerint határozza meg, fontos rendszereknél független tesztelővel. Az ügyfél látni akarja a jelentést és a bizonyítékot arra, hogy a feltárt sebezhetőségeket kijavították. A rendszer elavult verziójához készült jelentés nem segít.
Állapodjon meg a reagálási és javítási időkben a súlyosság és a valós kihasználási kockázat alapján. Ha havonta ad ki kiadást, és egy aktívan kihasznált kritikus hibát talál, kell lennie módnak arra, hogy a szokásos cikluson kívül szállítson javítást.
Ha több bérlős (multi-tenant) SaaS-t üzemeltet közös infrastruktúrán, a NIS2 által érintett ügyfelek ellenőrizhető adatelkülönítést várnak el.
A B ügyfél adatait az A ügyfél soha nem láthatja. Sem alkalmazáshiba, sem rosszul összeállított lekérdezés, sem naplószivárgás révén. A tenant_id oszloppal használt közös adatbázis logikai elkülönítést ad, és egyes vállalati ügyfelek helyette külön adatbázist vagy sémát fognak kérni. Bármelyiket választja, az architektúrának világosan meg kell tudnia mutatni, hogyan érvényesíti és hogyan teszteli ezt az elkülönítést.
A mentéseknél szokott ez kicsúszni. Ha az egész adatbázist egyszerre menti, egyetlen bérlő visszaállítása az összes ügyfél adatát érintheti. Előre tisztázza, hogyan lehet egyetlen ügyfelet biztonságosan visszaállítani anélkül, hogy a többit érintené vagy felfedné.
A GDPR és a NIS2 itt keresztezi egymást. Egy törlési kérelemhez dokumentált eljárásra van szüksége arra, hogyan szünteti meg a hozzáférést az aktív rendszerekben, és hogyan kezeli az adatokat a mentésekben a vonatkozó megőrzési ütemterv szerint. Közös mentések esetén ez nem triviális.
Ha olyan szoftvercég, amely szabályozott ügyfeleknek értékesít, itt kezdje.
Mérje fel, mely ügyfelei szabályozottak (bankok, biztosítók, egészségügyi intézmények, energiacégek), és milyen biztonsági követelményeik lesznek. Ha nem tudja, kérdezze meg őket közvetlenül. Jobb fél évvel előre felkészülni, mint nyomás alatt átküzdeni magát egy kérdőíven.
Formalizálja az incidenskezelési tervét. Nem kell hosszúnak lennie, de léteznie kell, naprakésznek és tesztelten kell lennie.
Vezessen be automatizált függőségvizsgálatot, és határozzon meg kockázatalapú javítási határidőket. Ez az egyik leggyorsabb módja a biztonsági helyzet javításának nagy befektetés nélkül.
Fontolja meg az ISO 27001 tanúsítást, ha az ügyfelei vagy a célszegmens megkövetelik. Kezdje a működő kontrollokkal, mert a tanúsítvány nem helyettesíti azokat.
Ha nem biztos benne, hol kezdje, lépjen kapcsolatba velünk. Biztonsági értékeléseket és architektúratervezést készítünk olyan cégeknek, amelyeknek meg kell felelniük a szabályozott ügyfelek követelményeinek. Szlovákia nemzeti kiberbiztonsági stratégiájáról és annak az IT-beszállítókra gyakorolt hatásáról egy külön cikkben is írtunk.
A Rise.sk alapítója és műszaki vezetője. Webalkalmazásokat, adatrendszereket és automatizálást tervez és szállít; szoftverdöntésekről, AI-ról és digitális szolgáltatásokról ír.
Az EU digitális működési rezilienciáról szóló rendelete (DORA) átalakítja, ahogyan a pénzügyi intézmények kiválasztják és kezelik IT-beszállítóikat. Ha bankoknak vagy biztosítóknak fejleszt szoftvert, ezt tudnia kell.
A kínai modellek ma már csak hónapokkal, nem évekkel maradnak el az amerikai élvonaltól, mégpedig a költség töredékéért. Egy európai cég számára a valódi kérdés nem az, ki nyeri a versenyt, hanem az, hogy érdemes-e használni őket, és hogyan.
Az AI Act nem csupán jogi téma. A vállalatoknak leltárra van szükségük az AI-eszközökről, a tulajdonosokról, az adatokról, a kockázatokról, a naplókról, az emberi felülvizsgálatról és a szállítói felelősségekről.
Az Ön helyzete határozza meg a választ
