NIS2 pro vývojáře: Bezpečnostní základ pro SaaS, ERP a HR systémy

Bezpečnostní dotazník od klienta žádá doklady o přístupech, zálohách a řešení incidentů. Dodavatel potřebuje aktuální záznamy nebo výsledky testů, ne jen tvrzení, že opatření existují.

Článek se věnuje slovenskému právnímu kontextu. Český dodavatel musí samostatně posoudit českou úpravu a případné přeshraniční povinnosti. Následující text neurčuje, zda konkrétní firma do regulace spadá.

Rozlište vlastní povinnosti a požadavky zákazníka

Slovenská transpozice NIS2 nabyla účinnosti 1. ledna 2025. Pro posouzení použijte aktuální slovenský zákon č. 69/2018 Z. z., jeho působnost, podmínky zápisu a přílohy. Označení SaaS ani samotný počet vývojářů nestačí.

Firma může mít vlastní zákonné povinnosti a současně závazky vůči zákazníkům. Také dodavatel mimo přímou působnost může dostat smluvní požadavky na bezpečnost a součinnost. Článek 21 směrnice NIS2 zahrnuje vztahy s přímými dodavateli. Nepřenáší však automaticky všechny povinnosti zákazníka na každého z nich.

U finančních klientů odlišujte NIS2 od DORA. Pokyny Evropské komise k článku 4 vysvětlují, které povinnosti DORA nahrazují odpovídající pravidla NIS2 u dotčených finančních subjektů. Bankovní dotazník proto nelze bez posouzení označit za dotazník NIS2.

Bezpečnostní základ pro SaaS

Co tedy firemní klient od SaaS dodavatele očekává? V bezpečnostních dotaznících se opakuje několik oblastí.

Řízení přístupů

Kdo má přístup k produkčním datům? Jak se přístupy přidělují a odebírají? Máte MFA pro administrátory? Máte princip nejmenších oprávnění? Když vývojář odejde z firmy, jak dlouho trvá, než ztratí přístup k infrastruktuře?

Riziko vzniká, když administrátorské heslo k databázi zná polovina týmu, SSH klíče se pravidelně neobměňují nebo odcházející zaměstnanec neztratí přístup k produkci v den odchodu. Pro regulovaného klienta je takový stav nepřijatelný.

Šifrování

Při přenosu používejte aktuálně podporované TLS a data v klidu chraňte silným šifrováním se spravovanými klíči. Týká se to databází, záloh i logů. Nešifrovaná záloha nebo logy bez řádného ověření přístupu jsou vážné riziko.

Správa zranitelností

Skenujete závislosti? Jak často? Co se stane, když se objeví kritická CVE v knihovně, kterou používáte? Máte dohodnuté lhůty na opravu podle rizika? Dodavatel musí umět prokázat, že zranitelnosti sleduje, vyhodnocuje a opravuje. Seznam softwarových komponent (SBOM) může klientovi pomoct rychleji posoudit dopad nové zranitelnosti.

Bezpečný vývojový cyklus

Kontrola kódu, statická analýza a bezpečnostní testování před vydáním. Když kontrolujete kód jen občas a nemáte automatizované bezpečnostní skeny, tohle je první místo na zlepšení. Klienti se budou ptát na bezpečný vývojový cyklus. Odpověď "kód si prohlížíme navzájem" bez zdokumentovaného postupu nestačí.

Součinnost při incidentu dohodněte předem

Článek 23 směrnice NIS2 řeší významné incidenty. Stanovuje včasné varování do 24 hodin od zjištění, oznámení do 72 hodin a závěrečnou zprávu do měsíce po oznámení. Pro probíhající incidenty a některé služby platí zvláštní pravidla. Konkrétní povinnost ověřte podle použitelné národní nebo sektorové úpravy.

Ve smlouvě určete, kdo koho informuje a v jaké lhůtě. Oznámení dodavatele není totožné se zákonným hlášením regulátorovi. U banky nepřebírejte uvedené termíny jako harmonogram DORA.

Plán potřebuje kontakty, komunikační kanál, oprávnění odpojit systém a přístup k logům. Určete zastupování a postup vyzkoušejte. Klient musí dostat známý rozsah dopadu i jasně označené nejistoty.

Auditní stopa jako společný technický základ

Zaznamenávání událostí pomáhá při bezpečnostním vyšetřování a při dalších povinnostech, například když systém používá vysoce rizikovou AI podle AI Actu. Není třeba budovat zvláštní logovací systém pro každou regulaci. Je třeba mít jednu promyšlenou auditní stopu, která pokryje bezpečnostní události, rozhodnutí AI i důležité změny údajů.

Prakticky to znamená strukturované logy s časem, identitou aktéra, typem akce a výsledkem. Doba uchovávání se má určit podle účelu, rizika, smlouvy a příslušných pravidel. Neexistuje jedna univerzální lhůta pro každý systém. Logy musí být chráněné před manipulací a dostupné pro audit bez dvoudenního hledání v nečitelných souborech.

Když jste dodavatel vy

Bezpečnost dodavatelského řetězce podle NIS2 znamená, že regulovaný klient od vás bude chtít důkazy, ne jen sliby.

Bezpečnostní dotazníky

Standardizované formuláře (často založené na CAIQ od Cloud Security Alliance nebo vlastní od klienta), kde odpovídáte na otázky o šifrování, přístupech, testování, zálohovacích politikách. Když nemáte odpovědi připravené, každý dotazník vás bude stát dny práce.

Certifikace

Klient může žádat ISO 27001 nebo jiný nezávislý důkaz. Certifikace však nenahrazuje funkční technické kontroly. Když ji nemáte, musíte procesy a jejich účinnost prokázat jiným dohodnutým způsobem.

Penetrační testování

Rozsah a frekvenci určete podle rizika a smlouvy, u důležitých systémů s nezávislým testerem. Klient bude chtít vidět zprávu a důkaz, že nalezené zranitelnosti byly opraveny. Stará zpráva k neaktuální verzi systému nepomůže.

Lhůty na opravu

Dohodněte si lhůty podle závažnosti a reálného rizika zneužití. Když vydáváte novou verzi jednou za měsíc a objeví se aktivně zneužívaná kritická chyba, musíte umět připravit opravu mimo běžný cyklus.

Oddělení dat ve vícenájemním SaaS

Když provozujete vícenájemní (multi-tenant) SaaS, kde data více klientů běží na společné infrastruktuře, potřebujete prokazatelné oddělení dat.

Klient A nesmí vidět data klienta B ani při chybě v aplikaci, špatně sestaveném databázovém dotazu či úniku přes logy. Sdílená databáze s identifikátorem klienta poskytuje logické oddělení. Někteří regulovaní klienti mohou žádat samostatnou databázi nebo schéma. Architektura má umět srozumitelně doložit, jak izolaci vynucuje a testuje.

Když zálohujete celou databázi najednou, obnova jednoho klienta může znamenat práci s daty všech. Proto je třeba předem ověřit, jak lze bezpečně obnovit konkrétního klienta bez zásahu do ostatních a bez úniku jejich dat.

GDPR a NIS2 se tu potkávají. Při žádosti o výmaz musíte mít zdokumentované, jak se údaje znepřístupní v aktivních systémech a jak se s nimi naloží v zálohách podle doby uchovávání. U sdílených záloh to není triviální.

Co dělat teď

Když jste softwarová firma, která dodává produkt regulovaným klientům, začněte tady:

Zmapujte, kdo jsou vaši regulovaní klienti (banky, pojišťovny, zdravotnická zařízení, energetické firmy) a jaké bezpečnostní požadavky od vás budou mít. Když to nevíte, zeptejte se jich přímo. Lepší je připravit se šest měsíců dopředu než řešit dotazník pod tlakem.

Zformalizujte plán řešení incidentů. Nemusí být dlouhý, ale musí existovat, být aktuální a vyzkoušený.

Zaveďte automatizované skenování závislostí a určete lhůty na opravy podle rizika. Je to jeden z nejrychlejších způsobů, jak zlepšit bezpečnostní úroveň bez velké investice.

Certifikaci ISO 27001 zvažte tehdy, když ji vyžadují vaši zákazníci nebo cílový segment. Nejdřív ale musí fungovat samotná opatření. Certifikát je nenahradí.

Když nevíte, kde začít, ozvěte se nám. Děláme bezpečnostní posouzení a návrhy architektury pro firmy, které potřebují splnit požadavky regulovaných klientů.

Zdroje

• Co přinesla NIS2 (Národní bezpečnostní úřad)
• Kybernetická bezpečnost (Národní bezpečnostní úřad)
• Směrnice NIS2 na EUR-Lex