NIS2 pre vývojárov: Bezpečnostný základ pre SaaS, ERP a HR systémy

Bezpečnostný dotazník od klienta sa pýta na prístupy, zálohy aj postup pri incidente. Nestačí uviesť, že opatrenie máte. Dodávateľ musí vedieť ukázať aktuálny záznam alebo výsledok testu.

Tento článok opisuje slovenský právny kontext a technickú prípravu dodávateľa. Nie je posúdením, či konkrétna firma patrí do regulácie.

Najprv overte priamu pôsobnosť a požiadavky klienta

Slovensko transponovalo NIS2 novelou účinnou od 1. januára 2025. Pri posúdení firmy pracujte s aktuálnym znením zákona č. 69/2018 Z. z., najmä s pôsobnosťou, podmienkami zápisu a prílohami. Samotné označenie SaaS ani počet vývojárov odpoveď nedáva.

Firma môže mať vlastné povinnosti podľa zákona a zároveň bezpečnostné záväzky voči klientom. Aj dodávateľ mimo priamej pôsobnosti môže dostať zmluvné požiadavky na bezpečnosť a súčinnosť. Článok 21 smernice NIS2 zahŕňa bezpečnosť vzťahov s priamymi dodávateľmi. Z toho však nevyplýva, že každý dodávateľ automaticky preberá všetky povinnosti klienta.

Pri finančných klientoch rozlišujte NIS2 od DORA. Usmernenie Európskej komisie k článku 4 vysvetľuje, ktoré povinnosti DORA sa pri dotknutých finančných subjektoch uplatnia namiesto zodpovedajúcich pravidiel NIS2. Bankový dotazník preto nemožno bez posúdenia označiť za dotazník NIS2.

Bezpečnostný základ pre SaaS

Čo teda firemný klient od SaaS dodávateľa očakáva? V bezpečnostných dotazníkoch sa opakuje niekoľko oblastí.

Riadenie prístupov

Kto má prístup k produkčným dátam? Ako sa prístupy prideľujú a odoberajú? Máte MFA pre administrátorov a princíp najmenších oprávnení? A keď vývojár odíde z firmy, koľko hodín alebo dní trvá, kým naozaj stratí prístup k produkčnej infraštruktúre, k repozitáru, k monitoringu aj k cloudovému účtu?

Riziko vzniká, keď administrátorské heslo k databáze pozná polovica tímu, keď sa SSH kľúče pravidelne neobmieňajú, keď odchádzajúci zamestnanec nestratí prístup k produkcii v deň odchodu, ale až vtedy, keď si na to niekto spomenie. Pre regulovaného klienta je takýto stav neprijateľný.

Šifrovanie

Pri prenose používajte aktuálne podporované TLS a dáta v pokoji chráňte silným šifrovaním so spravovanými kľúčmi, teda takými, ktoré vie niekto vymeniť bez toho, aby vypol pol systému. Týka sa to databáz, záloh aj logov. Nešifrovaná záloha alebo logy bez riadneho overenia prístupu sú vážne riziko.

Správa zraniteľností

Skenujete závislosti? Ako často? Čo sa stane, keď sa objaví kritická CVE v knižnici, ktorú používate? Máte dohodnuté lehoty na opravu podľa rizika? Dodávateľ musí vedieť preukázať, že zraniteľnosti sleduje, že ich vyhodnocuje, že ich opravuje. Zoznam softvérových komponentov (SBOM) môže klientovi pomôcť rýchlejšie posúdiť dosah novej zraniteľnosti, pretože bez neho sa odpoveď na otázku, či sa nás to týka, hľadá ručne.

Bezpečný vývojový cyklus

Kontrola kódu, statická analýza, bezpečnostné testovanie pred vydaním. Ak kontrolujete kód iba občas a nemáte automatizované bezpečnostné skeny, toto je prvé miesto na zlepšenie, pričom treba určiť aj vlastníka vyhodnotenia nálezov. Klienti sa budú pýtať na bezpečný vývojový cyklus. Odpoveď "kód si pozeráme navzájom" bez zdokumentovaného postupu nestačí.

Dohodnite súčinnosť pri incidente vopred

Článok 23 smernice NIS2 upravuje hlásenie významných incidentov. Rozlišuje včasné varovanie do 24 hodín od dozvedenia sa o incidente, oznámenie do 72 hodín a záverečnú správu do mesiaca po oznámení. Pre prebiehajúci incident a niektoré služby stanovuje osobitné pravidlá. Konkrétne povinnosti overte podľa použiteľného vnútroštátneho alebo sektorového režimu.

Dodávateľ má s klientom dohodnúť, kto koho informuje a v akej lehote. Zmluvné oznámenie dodávateľa nie je to isté ako zákonné hlásenie regulátorovi. Pri banke nepreberajte uvedený harmonogram ako harmonogram DORA.

Plán má pomenovať kontakty, komunikačný kanál, oprávnenie odpojiť systém a prístup k logom. Určte zastupovanie a nacvičte postup. Klient potrebuje vedieť, čo sa stalo, aký je známy rozsah a ktoré údaje sú ešte neisté.

Auditná stopa ako spoločný technický základ

Zaznamenávanie udalostí pomáha pri bezpečnostnom vyšetrovaní a pri ďalších povinnostiach, napríklad ak systém používa vysokorizikové AI podľa AI Actu, kde sa rovnaká požiadavka objavuje z iného dôvodu, v inom zákone. Netreba budovať osobitný logovací systém pre každú reguláciu. Treba mať jednu premyslenú auditnú stopu, ktorá pokryje bezpečnostné udalosti, rozhodnutia AI aj dôležité zmeny údajov.

Prakticky to znamená štruktúrované logy s časom, identitou aktéra, typom akcie, výsledkom. Doba uchovávania sa má určiť podľa účelu, rizika, zmluvy, príslušných pravidiel. Neexistuje jedna univerzálna lehota pre každý systém. Logy musia byť chránené pred manipuláciou a dostupné na audit v čase, ktorý si klient predstavuje pod slovom hneď, nie po dvoch dňoch hľadania v nečitateľných súboroch.

Keď ste Vy dodávateľ

Bezpečnosť dodávateľského reťazca podľa NIS2 znamená, že regulovaný klient od Vás bude chcieť dôkazy, nie iba sľuby.

Bezpečnostné dotazníky

Štandardizované formuláre (často založené na CAIQ od Cloud Security Alliance alebo vlastné od klienta), kde odpovedáte na otázky o šifrovaní, prístupoch, testovaní, zálohovacích politikách. Ak nemáte odpovede pripravené, každý dotazník Vás bude stáť dni práce.

Certifikácie

Klient môže žiadať ISO 27001 alebo iný nezávislý dôkaz. Certifikácia však nenahrádza funkčné technické kontroly. Ak ju nemáte, musíte účinnosť svojich procesov preukázať iným dohodnutým spôsobom, napríklad správou z auditu, záznamom z testu obnovy, výstupom zo skenu závislostí, teda čímkoľvek, čo klient vie priložiť k svojmu vlastnému hláseniu.

Penetračné testovanie

Rozsah a frekvenciu určite podľa rizika a zmluvy, pri dôležitých systémoch s nezávislým testerom, a počítajte s tým, že klient bude chcieť vidieť správu aj dôkaz, že nájdené zraniteľnosti sú opravené. Stará správa k neaktuálnej verzii systému nepomôže.

Lehoty na opravu

Dohodnite si lehoty podľa závažnosti a reálneho rizika zneužitia. Ak vydávate novú verziu raz za mesiac a objaví sa aktívne zneužívaná kritická chyba, musíte vedieť pripraviť opravu mimo bežného cyklu.

Oddelenie dát vo viacnájomnom SaaS

Ak prevádzkujete viacnájomný (multi-tenant) SaaS, kde dáta viacerých klientov bežia na spoločnej infraštruktúre, potrebujete preukázateľné oddelenie dát.

Klient A nesmie vidieť dáta klienta B ani pri chybe v aplikácii, ani pri nesprávne zostavenom databázovom dopyte, ani pri úniku cez logy, o ktorom sa dozviete až od klienta. Zdieľaná databáza s identifikátorom klienta poskytuje logické oddelenie. Niektorí regulovaní klienti môžu žiadať samostatnú databázu alebo schému. Architektúra má vedieť zrozumiteľne doložiť, ako izoláciu vynucuje a ako ju testuje, a to nie na whiteboarde, ale v kóde.

Ak zálohujete celú databázu naraz, obnova jedného klienta môže znamenať prácu s dátami všetkých. Preto si vopred vyskúšajte, ako sa dá obnoviť jeden konkrétny klient bez zásahu do ostatných, a bez toho, aby ich dáta pri tej operácii kdekoľvek vyplávali. GDPR a NIS2 sa tu stretávajú. Pri žiadosti o výmaz musíte mať zdokumentované, ako sa údaje zneprístupnia v aktívnych systémoch, a ako sa s nimi naloží v zálohách podľa doby uchovávania. Pri zdieľaných zálohách to nie je triviálne.

Čo robiť teraz

Ak ste softvérová firma, ktorá dodáva produkt regulovaným klientom, začnite tu:

Zmapujte, kto sú Vaši regulovaní klienti (banky, poisťovne, zdravotnícke zariadenia, energetické firmy) a aké bezpečnostné požiadavky od Vás budú mať, ešte skôr, než príde prvý dotazník. Ak to neviete, opýtajte sa ich priamo. Lepšie je pripraviť sa šesť mesiacov dopredu ako riešiť dotazník pod tlakom.

Formalizujte plán riešenia incidentov. Nemusí byť dlhý. Musí existovať, musí byť aktuálny, musí byť odskúšaný.

Zaveďte automatizované skenovanie závislostí a určite lehoty na opravy podľa rizika. Je to jeden z najrýchlejších spôsobov, ako zlepšiť bezpečnostnú úroveň bez veľkej investície.

Certifikáciu ISO 27001 zvážte vtedy, keď ju vyžadujú Vaši zákazníci, prípadne celý cieľový segment, do ktorého sa chcete dostať. Najprv však musia fungovať samotné opatrenia, lebo certifikát ich nenahradí, iba ich potvrdí, a audítor sa pýta presne na to isté, na čo sa pýta klient.

Ak neviete, kde začať, ozvite sa nám. Robíme bezpečnostné posúdenia a návrhy architektúry pre firmy, ktoré potrebujú splniť požiadavky regulovaných klientov.

Zdroje

• Čo priniesla NIS2 (Národný bezpečnostný úrad)
• Kybernetická bezpečnosť (Národný bezpečnostný úrad)
• Smernica NIS2 na EUR-Lex