AD je v mnohých organizáciách základom identity už desiatky rokov. Okrem prihlasovania slúži na prideľovanie prístupov k súborom, tlačiarňam a aplikáciám a cez skupinové politiky (Group Policy) aj na jednotné nastavenie zariadení.

Ako Active Directory funguje

Objekty sú usporiadané do hierarchie: les (forest) obsahuje jednu alebo viac domén, domény sa delia na organizačné jednotky (OU). Doménové radiče si medzi sebou replikujú databázu, takže výpadok jedného servera prihlasovanie nezastaví. Na overovanie sa používajú protokoly Kerberos a staršie NTLM, na vyhľadávanie v adresári protokol LDAP.

• Používatelia a skupiny – kto je kto a do akých rolí patrí.
• Počítače a servery – zariadenia pripojené do domény.
• Skupinové politiky – centrálne nastavenia bezpečnosti a konfigurácie.
• Delegovanie práv – kto smie spravovať ktorú časť adresára.

Prečo je AD citlivým miestom bezpečnosti

Kto ovládne Active Directory, ovláda prakticky celú sieť. Útočníci preto po prieniku do jedného počítača hľadajú cestu k doménovým administrátorom, často cez zabudnuté privilegované účty, nadmerne delegované práva, slabé heslá servisných účtov alebo zastarané protokoly. Prostredie, ktoré rástlo roky bez pravidelnej revízie, obsahuje takýchto skratiek zvyčajne viac, než správcovia očakávajú.

Dnes AD často funguje spolu s cloudovou službou Entra ID v hybridnom režime, takže chyba v lokálnej doméne sa môže preniesť aj do cloudu.

Ako AD posúdiť a spevniť

1. Zmapovať privilegované skupiny a účty a odstrániť nepotrebné členstvá.
2. Skontrolovať delegovanie práv a trust vzťahy s inými doménami.
3. Vypnúť alebo obmedziť staré protokoly a slabé šifrovanie.
4. Oddeliť administrátorské účty od bežnej práce a zaviesť MFA tam, kde to prostredie umožňuje.
5. Posúdenie pravidelne opakovať, nielen raz.

PosAm pri posúdení používa nástroje PingCastle a Purple Knight a výsledky dopĺňa manuálnou analýzou, ako opisuje článok o systematickom posilňovaní kybernetickej odolnosti.

Časté otázky

Nahrádza Entra ID klasické Active Directory?

Nie automaticky. Entra ID je cloudová identitná služba s iným modelom fungovania. Mnohé firmy prevádzkujú obe a synchronizujú medzi nimi identity, kým sa aplikácie a zariadenia postupne nepresunú do cloudu.

Ako často by sa mala robiť bezpečnostná kontrola AD?

Odporúča sa aspoň raz ročne a po každej väčšej zmene, napríklad pri fúzii firiem, migrácii alebo zmene správcu. Výsledky môžu slúžiť aj ako podklad pre audit podľa zákona o kybernetickej bezpečnosti.

Ak chcete vedieť, v akom stave je vaša doména, začnite jednorazovým posúdením Active Directory a Entra ID. Súvisiace služby nájdete v ponuke návrhu a správy IT infraštruktúry, prípadne nás kontaktujte priamo.

Príspevok Active Directory (AD) je zobrazený ako prvý na posam.sk.

Cieľom nie je len zoznam položiek, ale schopnosť kedykoľvek odpovedať na otázky: čo máme, kde to je, kto to používa, koľko nás to stojí a čo bude treba obnoviť.

Čo sa v správe IT majetku eviduje

• Hardvér – počítače, notebooky, mobily, servery, sieťové prvky, tlačiarne; s výrobným číslom, umiestnením a používateľom.
• Softvér a licencie – nainštalované aplikácie, počet zakúpených a skutočne využívaných licencií, termíny obnovy.
• Finančné a zmluvné údaje – dátum obstarania, záruka, leasing, servisné zmluvy, odpisy.
• Stav – v sklade, nasadené, v oprave, vyradené.

Prečo je to pre firmu dôležité

Bez aktuálnej evidencie firma platí za licencie, ktoré nikto nepoužíva, a zároveň riskuje nesúlad pri licenčnom audite. Z bezpečnostného hľadiska platí jednoduché pravidlo: chrániť sa dá len to, o čom viete. Zariadenie, ktoré v evidencii chýba, často nedostáva aktualizácie a môže sa stať slabým miestom.

Správa IT majetku tiež dáva podklady pre rozpočet – vidno, koľko zariadení končí záruku alebo dosluhuje a kedy treba plánovať obnovu. Na to nadväzuje riadenie celého životného cyklu zariadenia od obstarania po recykláciu.

Ako asset management zaviesť

1. Urobte prvotnú inventúru, ideálne automatizovaným zberom údajov zo siete a nástrojov na správu zariadení.
2. Stanovte, ktoré údaje evidujete a kto je za ne zodpovedný.
3. Prepojte evidenciu s procesmi – nákupom, nástupom a odchodom zamestnanca, servisom.
4. Pravidelne porovnávajte evidenciu so skutočnosťou.

Asset management sa často prekrýva s konfiguračným managementom (CMDB). Rozdiel je v pohľade: ITAM sleduje majetok najmä finančne a zmluvne, CMDB zachytáva technické väzby medzi komponentmi služieb. O tom, aké prekvapenia prináša detailný prehľad o infraštruktúre, píšeme v článku Poznáte svoju infraštruktúru tak dobre, ako si myslíte?

Časté otázky

Stačí na evidenciu IT majetku tabuľka?

Pre pár desiatok zariadení áno, pri väčšom počte sa však rýchlo stáva neaktuálnou. Spoľahlivejší je nástroj, ktorý údaje zbiera automaticky.

Patrí do asset managementu aj cloud?

Áno. Cloudové predplatné a SaaS licencie sú majetok, ktorý stojí peniaze a treba ho evidovať rovnako ako hardvér.

Evidenciu majetku a konfigurácií podľa ITIL pokrýva modul assets & configuration management v riešení Servio na manažment IT služieb; správu zariadení vrátane ich obstarania zabezpečuje služba Modern End User Services (mEUS).

Príspevok Asset management (správa IT majetku) je zobrazený ako prvý na posam.sk.

Útočná cesta zvyčajne nevzniká z jednej veľkej chyby. Skladá sa z viacerých drobností, ktoré samostatne pôsobia neškodne: priveľké oprávnenia skupiny, zabudnutý servisný účet s heslom bez expirácie, administrátor prihlasujúci sa na bežné stanice alebo nevhodne nastavené delegovanie práv.

Ako útočné cesty vznikajú

Najčastejšie ich nájdete v adresárových službách, typicky v Active Directory a Entra ID. Vzťahy medzi používateľmi, skupinami, počítačmi a oprávneniami tvoria graf, v ktorom útočník hľadá najkratšiu trasu k privilegovaným účtom. Každý krok pritom môže využiť niečo iné:

• zneužitie uložených prihlasovacích údajov na stanici, kde sa prihlásil administrátor,
• právo meniť členstvo v skupine alebo resetovať heslo inému účtu,
• trust vzťahy medzi doménami a lesmi, ktoré rozširujú dosah kompromitácie,
• neopravenú zraniteľnosť na serveri, ktorá umožní ďalší laterálny pohyb.

Prečo je dôležité na ne myslieť

Bezpečnosť sa často posudzuje po jednotlivých nálezoch. Pohľad cez útočné cesty ukazuje, ktoré kombinácie nálezov sú skutočne nebezpečné. Prirovnanie: jedna odomknutá brána na pozemku ešte neznamená vlámanie do trezoru, ak cestou stoja ďalšie zamknuté dvere. Ak sú však otvorené všetky, stačí jedna chyba na začiatku.

Pre vedenie firmy je tento pohľad zrozumiteľnejší než dlhý zoznam zistení – ukazuje, ako by sa útočník k najcennejším aktívam reálne dostal a ktorý zásah cestu preruší.

Ako útočné cesty odhaliť a prerušiť

Pri posúdení bezpečnosti Active Directory a Microsoft Entra ID sa kombinujú špecializované nástroje (napríklad PingCastle a Purple Knight) s manuálnou analýzou privilegovaných účtov, delegovania práv a starých protokolov. PosAm tento postup opisuje v článku o tom, ako systematicky posilniť kybernetickú odolnosť organizácie. Typické opatrenia potom zahŕňajú:

1. oddelenie administrátorských účtov a obmedzenie, kde sa smú prihlasovať,
2. odstránenie nadbytočných oprávnení podľa princípu minimálnych práv,
3. hardening serverov a segmentáciu siete v duchu Zero Trust.

Časté otázky

Je attack path to isté ako zraniteľnosť?

Nie. Zraniteľnosť je jednotlivá slabina, útočná cesta je reťazec krokov, ktorý môže obsahovať zraniteľnosti, ale aj chybné nastavenia a oprávnenia.

Stačí na odhalenie útočných ciest automatický nástroj?

Nástroje výrazne pomáhajú, no výsledky treba interpretovať v kontexte organizácie. Preto sa odporúča kombinovať ich s manuálnou analýzou.

Ako často treba útočné cesty kontrolovať?

Pravidelne a po väčších zmenách, napríklad po reorganizácii skupín, migrácii alebo pridaní novej domény, pretože nové cesty vznikajú priebežne.

Ak chcete vedieť, aké útočné cesty existujú vo vašom prostredí, odporúčaný začiatok je jednorazové posúdenie infraštruktúry a analýza AD a Entra ID. Kontaktujte PosAm a dohodnite si posúdenie.

Príspevok Attack path (útočná cesta) je zobrazený ako prvý na posam.sk.

Cieľom nie je nahradiť ľudí, ale odbremeniť ich od rutiny. Dispečer, ktorý nemusí prepisovať údaje z e-mailov, má viac času na riešenie výnimiek a komunikáciu so zákazníkom.

Čo sa v servise bežne automatizuje

• Príjem požiadaviek – z webového formulára, e-mailu, monitoringu alebo zákazníckeho portálu priamo do systému.
• Triedenie a prioritizácia – kategorizácia podľa typu, lokality a SLA; AI triáž dokáže odhaliť aj duplicitné hlásenia.
• Prideľovanie a plánovanie – návrh technika a termínu podľa kompetencií, dostupnosti a trasy.
• Notifikácie a eskalácie – upozornenia pre zákazníka, technika aj vedúceho, keď hrozí prekročenie lehoty.
• Opakované úlohy – automatické generovanie pracovných príkazov podľa plánu pravidelných kontrol.
• Reporting – priebežné prehľady bez ručného spájania tabuliek.

Ako postupovať

1. Zmapujte súčasný proces a identifikujte kroky, ktoré sú časté, pravidelné a založené na jasných pravidlách.
2. Upracte dáta – automatizácia nad neúplnými alebo nekonzistentnými údajmi chyby len zrýchli.
3. Začnite malým rozsahom, overte prínos a až potom rozširujte.
4. Ponechajte ľudskú kontrolu pri rozhodnutiach s vysokým dopadom a nastavte jasné výnimky.
5. Merajte výsledky – napríklad čas od nahlásenia po pridelenie, dodržanie SLA či First-Time Fix Rate.

Typické chyby

Najčastejšie sa automatizuje zlý proces, ktorý sa predtým nezjednodušil. Ďalším problémom sú izolované automatizácie v jednotlivých systémoch bez integrácie – napríklad medzi FSM, ERP a skladom –, ktoré síce ušetria čas v jednom kroku, no v ďalšom vyžadujú ručné prepisovanie. Pri nasadzovaní umelej inteligencie je dôležité pochopiť, na akých dátach model pracuje a ako sa overujú jeho výstupy; tejto téme sa venuje stránka AI a hodnota pre biznis.

Časté otázky

Je automatizácia vhodná aj pre menší servisný tím?

Áno, najmä pri notifikáciách, šablónach pracovných príkazov a reportingu, kde sa prínos prejaví rýchlo aj pri menšom objeme.

Treba kvôli automatizácii meniť celý systém?

Nie vždy. Často stačí doplniť pravidlá do existujúceho nástroja alebo ho prepojiť s ďalšími systémami; niekedy dáva zmysel aj vývoj softvéru na mieru.

Automatizáciu v terénnom servise podporuje riešenie Field Service Management, v IT službách manažment služieb Servio.

Príspevok Automatizácia servisných procesov je zobrazený ako prvý na posam.sk.

Riadenie kontinuity (Business Continuity Management, BCM) je systematický proces, ktorého výsledkom je plán kontinuity (BCP). Jeho technickou časťou je disaster recovery – obnova IT systémov a dát po havárii.

Ako sa kontinuita prevádzky pripravuje

1. Analýza dopadov (BIA) – ktoré procesy sú kritické, aké následky má ich výpadok a ako dlho ho firma znesie.
2. Stanovenie cieľov obnovy – pre každý systém sa určí RPO a RTO, teda prijateľná strata dát a čas do obnovenia.
3. Posúdenie hrozieb – čo môže kritické procesy prerušiť a aké opatrenia to zmiernia.
4. Návrh riešení – redundantné komponenty, záložná lokalita, replikácia úložísk, zálohovanie dát, náhradné manuálne postupy.
5. Testovanie a aktualizácia – pravidelné cvičenia obnovy a úprava plánu pri každej väčšej zmene.

Prečo je to dôležité pre firmu

Pre energetiku, banky, telekomunikácie či verejnú správu môže niekoľkohodinový výpadok znamenať priame škody, sankcie aj stratu dôvery. Kontinuita činností, zálohovanie a krízové riadenie patria aj medzi oblasti bezpečnostných opatrení, ktoré rieši smernica NIS2 a zákon č. 69/2018 Z. z. o kybernetickej bezpečnosti; rozsah povinností pre konkrétnu organizáciu je vhodné overiť s odborníkom.

Dobrým prirovnaním je rezervné koleso v aute: nikto ho nechce používať, ale keď ho potrebujete, musí byť nafúkané, na mieste a vy musíte vedieť, ako ho vymeniť.

Úloha IT infraštruktúry

Technická časť kontinuity stojí na spoľahlivých úložiskách, replikácii dát medzi lokalitami a overenej obnove. PosAm spolupracuje s Hitachi Vantara aj v oblasti Disaster Recovery a s ďalšími výrobcami, ktorých prehľad nájdete v partnerských riešeniach. Návrh úložísk, zálohovania a ochrany dát pokrývajú naše storage professional services.

Medzi typické chyby patrí plán, ktorý nikto netestoval, záložná lokalita závislá od rovnakého napájania, siete alebo identít ako primárna, a zameranie len na technológie bez určenia ľudí a komunikačných postupov.

Časté otázky

Aký je rozdiel medzi business continuity a disaster recovery?

Business continuity rieši pokračovanie celej činnosti firmy, disaster recovery je jej technická časť zameraná na obnovu IT systémov a dát.

Kto má byť vlastníkom plánu kontinuity?

Vedenie organizácie s podporou IT, bezpečnosti a vlastníkov procesov. Samotné IT oddelenie nedokáže rozhodnúť, ktoré obchodné procesy majú prednosť.

Ako často plán kontinuity aktualizovať?

Pri každej významnej zmene procesov, systémov alebo dodávateľov a pravidelne po cvičeniach, ktoré odhalia medzery.

Ak chcete preveriť, či vaše prostredie zvládne výpadok podľa očakávaní, pozrite si návrh IT infraštruktúry a starostlivosť o ňu.

Príspevok Business Continuity (kontinuita prevádzky) je zobrazený ako prvý na posam.sk.

Prirovnanie: vlastné dátové centrum je ako vlastná elektráreň, cloud ako prípojka do elektrickej siete. Nemusíte sa starať o turbíny, ale musíte dobre rozumieť spotrebe a zmluvným podmienkam.

Modely služieb a nasadenia

• IaaS (Infrastructure as a Service) – virtuálne servery, siete a úložiská; o operačný systém a aplikácie sa stará zákazník.
• PaaS (Platform as a Service) – spravovaná platforma, napríklad databáza alebo aplikačný server.
• SaaS (Software as a Service) – hotová aplikácia, napríklad Microsoft 365.

Podľa nasadenia rozlišujeme verejný cloud (napríklad Microsoft Azure alebo Oracle Cloud Infrastructure), privátny cloud a ich kombináciu, teda hybridný cloud. Mnohé firmy využívajú aj multi-cloud – služby viacerých poskytovateľov súčasne.

Prínosy a na čo si dať pozor

Cloud umožňuje rýchlo spustiť nové prostredie, pružne reagovať na sezónne špičky a presunúť časť nákladov z investícií (CAPEX) do prevádzkových výdavkov (OPEX). Nie je však automaticky lacnejší. Bez správy náklady rastú – zabudnuté virtuálne stroje, predimenzované inštancie či drahé úložisko pre zriedka používané dáta.

Dôležitý je aj model zdieľanej zodpovednosti: poskytovateľ zabezpečuje fyzickú infraštruktúru, za konfiguráciu, identity, prístupy a dáta však zodpovedá zákazník. Časté bezpečnostné problémy v cloude vznikajú práve chybnou konfiguráciou.

Ako postupovať pri prechode do cloudu

1. Zmapovať aplikácie, ich závislosti a nároky na výkon.
2. Rozhodnúť, čo presunúť bez zmien, čo upraviť a čo ponechať on-premise.
3. Navrhnúť sieť, identity a zabezpečenie (MFA, podmienený prístup, minimálne oprávnenia).
4. Migrovať po etapách a priebežne optimalizovať náklady.

Ako môže vyzerať optimalizácia v praxi, ukazuje referencia z optimalizácie cloudovej infraštruktúry v Microsoft Azure alebo projekt IT v cloude pre spoločnosť Hameln.

Časté otázky

Je cloud bezpečný pre citlivé dáta?

Môže byť, ak je správne nakonfigurovaný, dáta sú šifrované a prístupy riadené. Pri regulovaných dátach treba posúdiť aj lokalitu dátových centier a zmluvné podmienky.

Musíme presunúť do cloudu všetko?

Nie. Niektoré systémy je výhodnejšie ponechať vo vlastnom prostredí, napríklad pre latenciu či výkon pri AI. Tieto úvahy rozoberáme v článku o pripravenosti IT infraštruktúry na AI.

Ak zvažujete prechod do cloudu alebo jeho optimalizáciu, pozrite si náš návrh IT infraštruktúry a starostlivosť o ňu.

Príspevok Cloud computing je zobrazený ako prvý na posam.sk.

Ide o praktické uplatnenie princípu Zero Trust: samotné správne heslo nestačí, rozhoduje aj kontext. Funkcia je dostupná v licenciách Entra ID P1 a vyšších, ktoré bývajú súčasťou viacerých balíkov Microsoft 365.

Ako pravidlo podmieneného prístupu funguje

Každá politika má tvar „ak platí toto, urob toto“. Vstupné signály sú najmä:

• kto – používateľ, skupina, administrátorská rola, hosť,
• k čomu – konkrétna aplikácia, napríklad e-mail alebo portál Azure,
• odkiaľ – krajina, dôveryhodná sieť, IP adresa,
• z čoho – typ a stav zariadenia, či je spravované a v súlade s pravidlami,
• riziko – podozrivé prihlásenie alebo kompromitovaný účet (pri vyšších licenciách).

Výsledkom je napríklad: administrátori musia vždy použiť MFA, prístup k firemným dátam je povolený len zo zariadení spravovaných cez Intune a staré klientske protokoly sú blokované.

Prečo to má pre firmu význam

Ukradnuté heslo je jedným z najčastejších spôsobov prieniku, typicky po phishingovej kampani. Podmienený prístup takéto heslo znehodnotí, ak útočník nesplní ďalšie podmienky. Zároveň umožňuje rozlíšiť prísnosť: od účtovníčky v kancelárii netreba vyžadovať to isté ako od administrátora, ktorý sa prihlasuje v noci zo zahraničia.

Postup zavádzania a typické chyby

1. Začnite režimom „iba report“, ktorý ukáže dopad bez blokovania.
2. Vytvorte núdzové (break-glass) účty vyňaté z politík, aby ste sa nezamkli.
3. Najprv chráňte administrátorov, potom všetkých používateľov.
4. Blokujte staršie spôsoby overovania, ktoré MFA nepodporujú.
5. Výnimky dokumentujte a pravidelne revidujte.

Častou chybou je priveľa výnimiek „na skúšku“, ktoré nikto neodstráni, a politiky, ktoré si navzájom odporujú. Pomáha jednotná konvencia pomenovania politík a pravidelná kontrola prihlasovacích záznamov.

Časté otázky

Stačí zapnúť bezpečnostné predvolené nastavenia (security defaults)?

Pre malú organizáciu je to dobrý začiatok. Conditional Access však ponúka jemnejšie riadenie podľa skupín, aplikácií a zariadení, ktoré väčšie prostredie zvyčajne potrebuje.

Musia byť zariadenia spravované cez Intune?

Nie je to povinné, no podmienka „spravované a vyhovujúce zariadenie“ patrí k najúčinnejším pravidlám.

Ochranu identít cez MFA a Conditional Access obsahuje už úroveň mEUS Basic služby Modern End User Services. Širší kontext Zero Trust opisuje článok o posilňovaní kybernetickej odolnosti organizácií.

Príspevok Conditional Access (podmienený prístup) je zobrazený ako prvý na posam.sk.

Vďaka jednotnému označeniu hovoria výrobcovia, bezpečnostné nástroje, správcovia aj audítori o tej istej chybe rovnakým jazykom. CVE samotné nehodnotí závažnosť – to je úloha systému CVSS.

Kto CVE spravuje a ako záznam vzniká

Program CVE prevádzkuje nezisková organizácia MITRE s podporou americkej agentúry CISA. Identifikátory prideľujú takzvané CNA (CVE Numbering Authorities) – výrobcovia softvéru, bezpečnostné firmy či národné tímy, ktoré sú na to oprávnené. Postup je zjednodušene takýto:

1. niekto objaví zraniteľnosť a nahlási ju výrobcovi alebo CNA,
2. CNA rezervuje identifikátor CVE,
3. po zverejnení sa doplní popis, dotknuté verzie a odkazy na opravy,
4. ďalšie databázy, napríklad americká NVD, záznam obohacujú o hodnotenie CVSS a technické detaily.

Prečo je CVE dôležité pre firmy

CVE je spoločný kľúč, ktorý prepája celý proces riadenia bezpečnosti. Skener zraniteľností nájde na serveri konkrétne CVE, bezpečnostné bulletiny výrobcu uvádzajú, ktoré CVE záplata rieši, a reporty pre vedenie či audítora môžu sledovať, ktoré zraniteľnosti boli odstránené. Bez jednotného označenia by sa zistenia z rôznych zdrojov ťažko porovnávali.

Dôležité je aj pre výrobcov softvéru: nariadenie Cyber Resilience Act zavádza povinnosť hlásiť aktívne zneužívané zraniteľnosti produktov s digitálnymi prvkami, a to od 11. septembra 2026. Viac o tom nájdete v článku Cyber Resilience Act mení spôsob, akým sa vyvíja softvér.

Na čo si dať pozor

• Nie každá chyba má CVE – chybné nastavenia, slabé heslá či interné aplikácie v katalógu nenájdete.
• Počet CVE neznamená mieru rizika – desiatky nálezov s nízkou závažnosťou môžu byť menej dôležité ako jedna zneužívaná zraniteľnosť na serveri dostupnom z internetu.
• Záznamy sa menia – popis aj hodnotenie sa môžu po zverejnení aktualizovať.

Časté otázky

Je CVE to isté ako CVSS?

Nie. CVE zraniteľnosť pomenúva, CVSS hodnotí jej závažnosť na stupnici od 0 do 10.

Kde zistím, či sa CVE týka môjho systému?

V bezpečnostných bulletinoch výrobcu a vo výsledkoch skenovania zraniteľností, ktoré porovnávajú nainštalované verzie s databázou.

Ak ste objavili zraniteľnosť v produkte PosAm, použite formulár na nahlásenie bezpečnostnej zraniteľnosti. Pri sledovaní CVE vo vlastnej infraštruktúre vám pomôže systematický vulnerability management, ktorý PosAm opisuje na blogu.

Príspevok CVE je zobrazený ako prvý na posam.sk.

CVSS sa zvyčajne uvádza pri zázname CVE, v bezpečnostných bulletinoch výrobcov aj vo výstupoch skenerov. Aktuálnou verziou štandardu je CVSS 4.0, v praxi sa však stále stretnete aj so staršou verziou 3.1.

Ako sa CVSS skóre počíta

Skóre nevzniká odhadom, ale z presne definovaných metrík. Základné (base) metriky opisujú vlastnosti samotnej zraniteľnosti, napríklad:

• či ju možno zneužiť cez sieť alebo len s lokálnym prístupom,
• aká zložitá je jej exploitácia a či vyžaduje oprávnenia alebo interakciu používateľa,
• aký dopad má na dôvernosť, integritu a dostupnosť.

Verzia 4.0 dopĺňa skupiny metrík hrozby (napríklad či existuje funkčný exploit), prostredia (dôležitosť systému v konkrétnej organizácii) a doplnkové informácie. Výsledné číslo sa priraďuje do pásiem závažnosti:

• 0,0 – None (žiadna),
• 0,1 až 3,9 – Low (nízka),
• 4,0 až 6,9 – Medium (stredná),
• 7,0 až 8,9 – High (vysoká),
• 9,0 až 10,0 – Critical (kritická).

Prečo samotné číslo nestačí

Verejne uvádzané skóre väčšinou zohľadňuje len základné metriky – teda zraniteľnosť „vo vákuu“. Nevie, či je dotknutý server dostupný z internetu, či je zraniteľnosť aktívne zneužívaná alebo či na systéme beží kritická služba. Zraniteľnosť so skóre 9,8 na izolovanom testovacom stroji môže byť menej naliehavá ako zraniteľnosť so skóre 7,5 na verejnom webovom serveri.

Preto PosAm pri vulnerability managemente neprioritizuje podľa surového CVSS skóre, ale podľa reálnej exponovanosti, dostupnosti exploitu a kritickosti služby. Postup je opísaný v článku Posilňujeme kybernetickú odolnosť organizácií systematicky a technicky.

Ako CVSS používať v praxi

1. Používajte skóre ako východisko, nie konečné rozhodnutie.
2. Doplňte kontext prostredia: exponovanosť, kritickosť systému, kompenzačné opatrenia.
3. Sledujte, či je zraniteľnosť aktívne zneužívaná.
4. Na základe toho stanovte poradie a termíny pre patch management.

Časté otázky

Hovorí CVSS skóre o pravdepodobnosti útoku?

Nie priamo. CVSS opisuje závažnosť zraniteľnosti, nie pravdepodobnosť, že ju niekto vo vašom prostredí zneužije.

Môže sa skóre pri tej istej zraniteľnosti líšiť?

Áno. Rôzne zdroje alebo verzie štandardu môžu uviesť odlišné hodnoty, preto je dobré vedieť, z ktorej verzie a zdroja číslo pochádza.

Ak chcete prioritizovať zraniteľnosti podľa reálneho rizika, nielen podľa čísla, kontaktujte PosAm.

Príspevok CVSS skóre je zobrazený ako prvý na posam.sk.

Podstatou je posun zodpovednosti na výrobcu: bezpečnosť už nemá byť dodatočnou funkciou, ale vlastnosťou produktu od návrhu cez vývoj až po podporu na konci životného cyklu.

Hlavné povinnosti a termíny

• Hlásenie – od 11. septembra 2026 musia výrobcovia hlásiť aktívne zneužívané zraniteľnosti a vážne incidenty národnému CSIRT-u a agentúre ENISA. Prvé varovanie do 24 hodín, podrobnejšie hlásenie do 72 hodín.
• Ostatné povinnosti – väčšina ďalších požiadaviek sa uplatňuje od 11. decembra 2027.
• SBOM – výrobca vedie zoznam softvérových komponentov v strojovo čitateľnom formáte a uchováva ho minimálne 10 rokov.
• Bezpečnostné aktualizácie – poskytujú sa bezplatne, spravidla aspoň 5 rokov.
• Sankcie – pokuty môžu dosiahnuť až 15 mil. € alebo 2,5 % celosvetového ročného obratu.

Čo to znamená pre vývoj softvéru

Ako opisuje článok Cyber Resilience Act mení spôsob, akým sa vyvíja softvér, výrobcovia musia mať prehľad o všetkých knižniciach a závislostiach, proces na prijímanie a vyhodnocovanie hlásení o zraniteľnostiach a spôsob, ako bezpečnostné opravy dostať k zákazníkom. V praxi to znamená bezpečný vývojový cyklus, automatizované skenovanie závislostí, verziovanie a dokumentáciu.

PosAm tieto požiadavky rieši aj na vlastných produktoch – pripravuje Servio WFMS na požiadavky CRA – a pre svoje produkty prevádzkuje kanál na nahlásenie bezpečnostnej zraniteľnosti.

CRA verzus NIS2

Smernica NIS2 rieši kybernetickú bezpečnosť prevádzky organizácií, CRA bezpečnosť produktov. Ak nakupujete softvér, CRA vám dáva silnejšiu pozíciu: môžete od dodávateľa očakávať transparentnosť komponentov a dlhodobú podporu.

Časté otázky

Týka sa CRA aj softvéru na zákazku?

Závisí od toho, či sa produkt uvádza na trh, a od výnimiek v nariadení. Pri konkrétnom produkte odporúčame posúdenie s odborníkom.

Čo by mal výrobca urobiť ako prvé?

Zmapovať produkty a ich komponenty, vytvoriť SBOM a nastaviť proces prijímania a hlásenia zraniteľností, keďže táto povinnosť už platí.

Ak plánujete nový softvér a chcete mať požiadavky CRA zapracované od začiatku, pozrite si, ako PosAm pristupuje k vývoju softvéru.

Príspevok Cyber Resilience Act (CRA) je zobrazený ako prvý na posam.sk.