TÉMA

Dodavatelé, cloud a sdílené služby (NIS2 v praxi)

V režimu NIS2 a navazující legislativy platí jednoduché pravidlo: rizika dodavatelů jsou i vaše rizika. Pokud je klíčová služba outsourcovaná (cloud, hosting, správa IT, SaaS), odpovědnost za řízení rizik a prokazatelnost zůstává na vaší organizaci. Proto je potřeba mít dodavatelské vztahy nastavené tak, aby šly řídit, měřit a obhájit vůči auditu i vedení.

1) Zákonný pohled: „rizika dodavatelů jsou i vaše rizika“

Dodavatelé a externí služby jsou častým zdrojem incidentů: špatně nastavené přístupy, slabé procesy změn, nedostatečné logování nebo nejasná odpovědnost při výpadku. Regulace proto vyžaduje, aby organizace měla kontrolu nad riziky dodavatelského řetězce – nejen formálně, ale i v praxi.

• Identifikace klíčových dodavatelů: kteří dodavatelé jsou kritičtí pro provoz a bezpečnost.
• Hodnocení rizikovosti: dopad výpadku, citlivost dat, přístup do systémů, závislosti.
• Řízení a dohled: pravidelná kontrola plnění, evidence, revize, zlepšování.
• Prokazatelnost: schopnost doložit, že rizika dodavatelů řídíte (smluvně i procesně).

2) Klíčové oblasti ve smlouvách (co má být ošetřené)

Smlouvy a SLA nejsou „právní formalita“. Jsou to nástroje, jak zajistit, že dodavatel umožní plnit vaše povinnosti a že v krizové situaci nebude vznikat chaos. Doporučujeme mít u klíčových dodavatelů jasně upravené minimálně tyto oblasti:

• Bezpečnostní požadavky a standardy
  Minimální úroveň zabezpečení, řízení přístupů, patch management, hardening, školení, segregace rolí.
• SLA + reakce na incidenty
  Dostupnost služby, reakční časy, eskalační kontakty, postup při výpadku, RTO/RPO (pokud relevantní).
• Logy, monitoring, právo na audit
  Jaké logy se uchovávají, jak dlouho, jak k nim získáte přístup, jak probíhá audit (interní/externí).
• Oznamování incidentů a spolupráce při vyšetřování
  Lhůty pro oznámení, sdílení informací, forenzní součinnost, uchování důkazů, komunikace se třetími stranami.

Praktická poznámka: U nejkritičtějších dodavatelů doporučujeme doplnit i scénáře pro ukončení spolupráce (exit plán), aby organizace nebyla v pasti při změně poskytovatele.

3) Cloud / outsourcing IT: sdílená odpovědnost

Cloud a outsourcing obvykle fungují podle principu sdílené odpovědnosti. Poskytovatel odpovídá za určitou část (např. infrastrukturu), ale organizace si stále odpovídá za nastavení, přístupy, data, procesy a prokazatelnost. V praxi je proto nutné přesně vědět, kde končí odpovědnost poskytovatele a kde začíná vaše.

• Infrastruktura vs. nastavení a data
  Poskytovatel může garantovat provoz platformy, ale vy musíte mít správně nastavené identity, oprávnění, MFA, konfigurace a práci s daty.
• Schopnost splnit oznamovací a auditní povinnosti
  Dodavatel musí umožnit: přístup k logům, součinnost při incidentu, dostupnost podkladů pro audit, jasné kontakty a postupy.
• Pozor na vendor lock-in a lokalitu dat
  Zvažte riziko závislosti na jednom dodavateli, možnosti migrace, export dat, kompatibilitu a to, kde jsou data fyzicky ukládána (jurisdikce).

Tip pro praxi: U cloudových služeb často vzniká riziko nikoli „v cloudu“, ale ve špatném nastavení účtů a oprávnění. Rychlým přínosem bývá revize přístupů, MFA, audit logů a kontrola zálohování.

Chcete zkontrolovat smlouvy, SLA a nastavení cloudu tak, aby byly auditovatelné a splňovaly požadavky NIS2?
Napište nám na Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript. a domluvíme úvodní konzultaci.

TÉMA

Co je potřeba mít pod kontrolou (NIS2 v praxi)

Požadavky NIS2 a navazujícího českého rámce stojí na jednoduchém principu: organizace musí umět prokázat, že kybernetickou bezpečnost řídí – ne pouze „má napsanou“. V praxi se hodnotí, zda víte co chráníte, zda rozumíte rizikům, máte zavedená opatření, řídíte přístupy a identity a zda systém průběžně kontrolujete a zlepšujete.

Nejde o jednorázový projekt. Jde o trvalý režim, který musí fungovat v provozu, být měřitelný, auditovatelný a s jasnou odpovědností vedení.

Co musí mít regulovaná organizace zavedeno

Regulovaná organizace musí mít nastavený systém, který je prakticky použitelný a zároveň prokazatelný při interním auditu i případné kontrole. Níže jsou klíčové oblasti, které tvoří základ „minimálního funkčního rámce“.

1) Mapa aktiv – co chráníme

Základ je mít jasný přehled o tom, co je kritické pro provoz a jaké systémy, služby a data musí být chráněny. Bez mapy aktiv nelze správně prioritizovat opatření ani smysluplně řídit rizika.

• systémy a služby: aplikace, servery, síť, cloud, externí služby, integrace,
• data: citlivá data, osobní údaje, provozní data, know-how, logy,
• technologie: koncové stanice, síťové prvky, OT/IoT, zálohování, monitoring,
• klíčové procesy: výroba, logistika, péče o klienty/pacienty, platební procesy, poskytování služeb,
• lidé/role: klíčové role pro provoz a bezpečnost (IT, bezpečnost, provoz, vedení).

Součástí mapy aktiv musí být také vlastník aktiva (kdo odpovídá za jeho provoz) a klasifikace důležitosti (kritičnost pro kontinuitu, dopad výpadku, citlivost dat).

2) Řízení rizik

Řízení rizik propojuje procesy, technologie i lidi. Organizace musí umět popsat, jaká rizika má, jak jsou prioritizována a jak se s nimi zachází. Důraz je na to, aby rozhodnutí byla transparentní a zdokumentovaná.

• hrozby, zranitelnosti, dopady: co může selhat a co to udělá s provozem, financemi a reputací,
• rozhodnutí o ošetření rizika: riziko akceptovat / snížit / přenést (např. pojistně nebo smluvně),
• Prohlášení o aplikovatelnosti: jaká opatření zavádíme (nebo nezavádíme) a proč – aby bylo obhajitelné, že opatření odpovídají rizikům.

Praktický přínos: díky řízení rizik investujete do opatření, která mají nejvyšší efekt, a umíte obhájit, proč jste zvolili právě tento rozsah.

3) Opatření

Opatření nejsou jen dokument. Jsou to pravidla a kontroly, které musí být zavedené, používané a ověřované. V praxi se obvykle dělí na organizační, technická a fyzická.

• organizační: politiky, směrnice, role a odpovědnosti, školení, řízení dodavatelů,
• technická: segmentace, logování, monitoring, zálohy a obnova, MFA, správa zranitelností,
• fyzická: přístupy do serveroven, ochrana technologií, režim kritických prostor.

4) Přístupy a identity

Účty a identity patří mezi nejčastější vektory incidentů. Dobře nastavené řízení identit snižuje riziko zneužití účtů a zároveň výrazně zjednodušuje auditovatelnost a dohled.

• žádné sdílené účty a jasně definované role a odpovědnosti,
• princip „need-to-know“ a „least privilege“ (jen nezbytná oprávnění),
• řízený životní cyklus účtů (nástupy / změny rolí / odchody),
• pravidelné revize oprávnění a evidence změn.

5) Audit a zlepšování

Bezpečnost je kontinuální disciplína. Organizace musí pravidelně ověřovat, zda opatření fungují, a průběžně je upravovat podle rizik, změn v prostředí a zjištění z auditů či incidentů.

• interní audity a pravidelné revize rizik,
• nápravná opatření (plán, termíny, vlastníci, kontrola splnění),
• příprava na kontroly a prokazatelnost (evidence, dokumentace, reporting).

Chcete rychle zmapovat aktiva, nastavit řízení rizik a připravit praktický plán opatření?
Napište nám na Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript. a domluvíme úvodní konzultaci.

TÉMA

Co je penetrační test (pentest) a proč dává smysl

Penetrační test (pentest) je řízené a bezpečné ověřování, které simuluje reálný útok útočníka na vaše systémy. Cílem není „někoho nachytat“, ale zjistit zda je možné zneužít konkrétní slabiny a jaký by byl reálný dopad na provoz, data a dostupnost služeb.

Zjednodušeně: sken zranitelností vám často řekne „tady je problém“. Pentest odpoví: „Dá se to skutečně prolomit? Jak? A co by útočník získal?“

Co se při penetračním testu typicky testuje

Rozsah (scope) se vždy domlouvá dopředu podle toho, co je pro organizaci kritické. Nejčastěji se testují:

• webové aplikace a portály (přihlášení, role, formuláře, nahrávání souborů, integrace),
• API (autorizace, přístup k datům, chybová logika, rate-limity),
• externí perimetr (veřejně dostupné služby, domény, konfigurace),
• interní síť (pohyby v síti, oprávnění, konfigurace),
• identity a přístupy (IAM) (MFA, správa účtů, slabá hesla, sdílené účty),
• cloud konfigurace (nastavení přístupů, úložišť, bezpečnostních pravidel).

Důležité: Pentest se nedělá „naslepo“ bez pravidel. Vždy se nastaví rozsah, časové okno a bezpečnostní limity, aby test neohrozil provoz.

Jak pentest probíhá (jednoduše)

Pentest je kombinace metodiky a zkušeností. Postupuje se podobně jako by postupoval útočník – jen kontrolovaně a s povolením.

• 1) Domluvení rozsahu a pravidel (ROE): co testujeme, kdy, jaké jsou limity, kontakty pro eskalaci.
• 2) Průzkum a analýza: zjištění exponovaných služeb a potenciálních slabých míst.
• 3) Ověření zneužitelnosti: pokus o reálné využití slabiny (bezpečně, s limity).
• 4) Vyhodnocení dopadu: co by útočník získal (data, přístupy, kontrolu nad službou).
• 5) Zpráva a plán náprav: priority, doporučení, rychlé opravy vs. systémová opatření.
• 6) Retest: ověření, že opravy skutečně odstranily zneužitelnost.

Jaké jsou výstupy (co dostanete)

• Executive shrnutí pro vedení (dopady, největší rizika, priority),
• technická zpráva (nálezy, důkazy, scénáře zneužití, doporučení),
• prioritizace podle rizika (kritické / vysoké / střední / nízké),
• plán náprav včetně návrhu pořadí a quick wins,
• retest – ověření, že opravy opravdu fungují.

Výhoda pro praxi i regulaci: Pentest vytváří jasné důkazy o tom, co je reálně zneužitelné a co bylo opraveno. To je užitečné jak pro bezpečnost, tak pro auditovatelnost (např. v kontextu NIS2 / zákonných požadavků).

Nejčastější otázky (rychle a srozumitelně)

Je pentest bezpečný pro provoz?

Ano, pokud jsou nastavená pravidla (ROE): limity zátěže, časové okno, zakázané techniky a možnost okamžitého zastavení. U citlivých systémů lze kombinovat staging + cílené ověření v produkci.

Jak často pentest dělat?

Podle kritičnosti systémů a změn. Typicky pravidelně (např. ročně) pro klíčové části a vždy po významných změnách (release, migrace, IAM, integrace).

Je to totéž co GAP analýza?

Ne. GAP analýza porovnává procesy a nastavení s požadavky (co chybí). Pentest technicky ověřuje, zda se dá slabina skutečně zneužít (reálný útok).

Chcete vědět, který typ testu dává smysl právě pro vás (web, API, perimetr, interní síť)?
Napište nám na Tato e-mailová adresa je chráněna před spamboty. Pro její zobrazení musíte mít povolen Javascript. a domluvíme úvodní konzultaci.