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

Čtvrtek odpoledne. Ředitel desetičlenné softwarové firmy v Bratislavě otevře e-mail od největšího klienta. Banka. V příloze je dlouhý dotazník o kybernetické bezpečnosti. Ptá se na šifrování dat, plán řešení incidentů, penetrační testování, správu přístupů, zálohování a obnovu po havárii.

Firma má dobrý produkt. Mzdový SaaS systém, který používají stovky klientů. Nemá však formalizovaný postup při incidentu a výsledky posledního penetračního testu už neodpovídají aktuální verzi systému. Dotazník neumí vyplnit tak, aby banka dostala ověřitelné odpovědi.

Tohle se děje čím dál častěji. A důvod se jmenuje NIS2.

NIS2 a dodavatelský řetězec

NIS2 (Network and Information Security Directive 2) je směrnice EU. Slovensko ji převzalo novelou zákona č. 69/2018 Z. z. o kybernetické bezpečnosti, která nabyla účinnosti 1. ledna 2025. Pravidla se týkají subjektů v odvětvích jako energetika, doprava, zdravotnictví, digitální infrastruktura či vybrané digitální služby. Konkrétní rozsah je třeba ověřit podle slovenského zákona, ne jen podle velikosti firmy.

Vaše softwarová firma mezi regulované subjekty patřit nemusí. Někteří z vašich klientů tam ale patří.

NIS2 ukládá regulovaným subjektům povinnost řídit bezpečnostní rizika v celém dodavatelském řetězci. Článek 21 směrnice výslovně mluví o „bezpečnosti dodavatelského řetězce včetně bezpečnostních aspektů týkajících se vztahů mezi každým subjektem a jeho přímými dodavateli nebo poskytovateli služeb". V praxi to znamená, že banka, která používá váš mzdový systém, je zodpovědná za to, že vy jako dodavatel splňujete určitou úroveň bezpečnosti.

NIS2 tedy vaši firmu přímo nereguluje a stejně se vás dotkne. Vaši klienti vám začnou klást otázky, na které budete muset umět odpovědět. Když neodpovíte, hledají náhradu.

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čí.

Řešení incidentů v desetičlenné firmě

NIS2 vyžaduje od regulovaných subjektů hlásit bezpečnostní incidenty. Do 24 hodin od zjištění musí přijít včasné varování, do 72 hodin podrobnější notifikace a do měsíce závěrečná zpráva.

Vás jako dodavatele se to týká nepřímo. Když dojde k úniku dat ve vašem SaaS systému, váš klient (banka, pojišťovna) musí nahlásit incident regulátorovi. A bude od vás potřebovat informace. Co se stalo, kdy, jaký byl rozsah, jaká data byla dotčena a co jste udělali.

Když nemáte plán řešení incidentů, tyto informace nedokážete poskytnout včas. „Dáme vědět, až to prošetříme" není odpověď, kterou banka akceptuje, když má krátkou zákonnou lhůtu na první hlášení.

Plán pro malou firmu nemusí být 50stránkový dokument. Potřebujete vědět, kdo je kontaktní osoba, jaký je komunikační kanál, kdo může rozhodnout o odpojení systému, kde jsou logy a kdo je umí analyzovat. Postup má být sepsaný, pravidelně vyzkoušený a po každé změně systému aktualizovaný.

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ů. Víc o národní kybernetické strategii a jejích dopadech na IT dodavatele jsme psali v samostatném článku.

Zdroje

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