Kontrola používateľských prístupov: postup, frekvencia a šablóna

Kontrola používateľských prístupov je zaznamenané overenie zodpovednou osobou, že každý účet a každé oprávnenie v systéme stále zodpovedá aktuálnej potrebe. Ak prístup už nie je potrebný, kontrola sa končí odobratím, ktoré bolo potvrdené v cieľovom systéme. Kontrola, ktorá zozbiera odškrtnutia „schválené“, ale nepotrebné prístupy ponechá, nedáva audítorovi nič, o čo by sa mohol oprieť.

Tento sprievodca opisuje postup krok za krokom, intervaly kontrol, ktoré predpisy a normy skutočne stanovujú, spôsoby, akými kontroly zlyhávajú pri auditoch, kontrolný zoznam a bezplatnú tabuľkovú šablónu, ktorú môžete použiť pri svojej ďalšej kampani. Každý interval uvedený nižšie pochádza z primárneho textu overeného 21. októbra 2026, s odkazom na zdroj uvedeným vedľa neho. Ak rámec nestanovuje žiadne číslo, uvedieme to namiesto toho, aby sme si nejaké vymysleli.

Stručná odpoveď k frekvencii: Technický predpis k DORA vyžaduje aktualizáciu prístupových práv, ak sú potrebné zmeny, a aspoň každých 6 mesiacov pri IKT systémoch podporujúcich kritické alebo dôležité funkcie a aspoň raz ročne pri ostatných IKT systémoch. PCI DSS v4.0.1 stanovuje najmenej raz za šesť mesiacov pre používateľské účty v jej rozsahu. Slovenská vyhláška NBÚ č. 227/2025 Z. z. stanovuje najmenej raz ročne pre prevádzkovateľov základných služieb. NIST SP 800-53 a vykonávacie nariadenie k NIS2 ponechávajú interval na organizácii a text opatrenia ISO/IEC 27001 nie je verejný, preto z neho žiadne číslo necitujeme. Bez ohľadu na interval má odchod zmeniť prístup vtedy, keď nastane; technický predpis k DORA vyžaduje odobratie prístupových práv bez zbytočného odkladu po skončení pracovného pomeru alebo ak prístup už nie je potrebný.

Čo je kontrola používateľských prístupov

Kontrola kladie ku každému riadku jednu otázku: má tento účet, ktorý patrí tejto osobe alebo systému, stále mať toto oprávnenie? Oprávnenie je jedna jednotka prístupu, napríklad členstvo v skupine, aplikačná rola alebo databázové privilégium. Posudzovateľ odpovie ponechať, odobrať alebo upraviť a uvedie dôvod.

Kontrola je použiteľná ako auditný podklad vďaka trom veciam. Posudzovateľom musí byť niekto, kto dokáže pracovnú potrebu skutočne posúdiť, zvyčajne priamy nadriadený alebo vlastník aplikácie či údajov. Kontrolovaná skupina účtov musí byť úplná, aby zoznam odrážal to, čo systém skutočne prideľuje, vrátane prístupov zdedených cez skupiny. A každé rozhodnutie o odobratí sa musí vykonať a skontrolovať, pretože rozhodnutie zaznamenané v tabuľke nezmení ani jedno oprávnenie.

Kontrola, certifikácia a recertifikácia

Pojmy sa prekrývajú. „Certifikácia prístupu“ a „recertifikácia“ sú v produktoch na riadenie identít bežné názvy pre tú istú činnosť, často vykonávanú ako kampaň: určený rozsah, skupina posudzovateľov a termín. midPoint, open source platforma, na ktorej easyIGA beží, nazýva túto funkciu certifikácia prístupu a implementuje ju ako certifikačné kampane s krokom nápravy. Tento sprievodca používa „kontrola používateľských prístupov“ pre celý proces a „kampaň“ pre jeden jeho beh. Slovník pojmov definuje súvisiace pojmy.

Privilegované účty a strojové identity potrebujú vlastnú kontrolnú skupinu

Administrátorské práva, núdzové účty (break-glass) a servisné účty nesú iné riziká než členstvá bežného používateľa v skupinách. Viaceré rámce ich posudzujú osobitne. Vykonávacie nariadenie k NIS2 má samostatnú požiadavku na preskúmanie privilegovaných účtov a účtov na správu systému a PCI DSS vyčleňuje aplikačné a systémové účty do požiadavky 7.2.5.1 s intervalom podľa rizika. Kontrolujte ich v samostatnej kampani s posudzovateľmi, ktorí rozumejú tomu, čo dané práva umožňujú.

Servisný účet nemá nadriadeného v personálnom zmysle. Potrebuje menovite určeného ľudského vlastníka, uvedený účel a, ak sú dostupné, údaje o poslednom použití. Keď sa priameho nadriadeného spýtate, či svc_batch_07 je „stále potrebný“, spoľahlivú odpoveď dostanete len zriedka. Naša stránka o účtoch bez vlastníka a strojových identitách vysvetľuje, ako sa pred kontrolou určuje vlastníctvo.

Kto čo robí

Kontrola sa dotýka viacerých rolí. Ak si ich zapíšete pred prvou kampaňou, každý riadok bude mať odpoveď na otázku, ktorú k nemu položí audítor: kto bol zodpovedný za toto rozhodnutie?

Dvaja posudzovatelia pre ten istý riadok sú vecou návrhu. Manažér môže poznať pracovnú náplň človeka, ale nie to, čo umožňuje kryptická rola v ERP. Vlastník aplikácie pozná rolu, ale nevie, či človek minulý mesiac zmenil tím. Pri citlivých systémoch dáva lepšie rozhodnutie spojenie oboch pohľadov alebo smerovanie privilegovaných práv na vlastníka aplikácie.

Technický predpis k DORA to pre finančné subjekty stanovuje výslovne: jeho postupy riadenia účtov musia zahŕňať „prideľovanie úloh a zodpovedností za udeľovanie, preskúmavanie a odoberanie prístupových práv“ (delegované nariadenie (EÚ) 2024/1774, článok 21 písm. e) bod i)).

Postup kontroly používateľských prístupov krok za krokom

Sedem krokov nižšie sleduje jednu kampaň od rozsahu po uložený záznam. Kroky 5 a 6 sa odohrávajú mimo súboru kontroly, a preto sa najľahšie vynechávajú.

1. Určte rozsah

Pomenujte systémy v kampani, typy účtov (zamestnanci, externisti, pracovníci tretích strán, servisné účty, privilegované účty) a typy oprávnení (roly, skupiny, priame oprávnenia). Zaznamenajte, prečo bol niektorý systém patriaci do rozsahu vynechaný. Kontrola, ktorá niektorý systém potichu preskočí, sa neskôr ťažko obhajuje.

Prepojte rozsah so svojimi povinnosťami. Subjekt regulovaný podľa DORA potrebuje vedieť, ktoré IKT systémy podporujú kritické alebo dôležité funkcie, pretože tie majú kratší interval. DORA definuje kritickú alebo dôležitú funkciu okrem iných podmienok ako funkciu, ktorej narušenie „by v podstatnej miere negatívne ovplyvnilo finančnú výkonnosť finančného subjektu či správnosť alebo kontinuitu jeho služieb a činností“ (nariadenie (EÚ) 2022/2554, článok 3 bod 22). Subjekt, na ktorý sa vzťahuje PCI DSS, kontroluje účty vo svojom rozsahu PCI DSS.

2. Získajte údaje o prístupoch, ktorým môžete dôverovať

Z každého systému získajte aktuálne účty a oprávnenia k pevnému dátumu a výpis uchovajte. Kde je to možné, použite skutočne dostupný prístup: oprávnenia, ktoré môže človek skutočne využívať, vrátane oprávnení zdedených cez vnorené skupiny alebo roly. Samotný zoznam priamych priradení neobsahuje prístupy udelené cez skupiny a roly.

Každý účet priraďte k osobe alebo k servisnej identite so známym vlastníkom. Účty, ktoré nezodpovedajú nikomu, sú nálezom ešte pred začiatkom kontroly. Doplňte kontext, ktorý pomáha pri rozhodovaní: oddelenie, pracovnú pozíciu, dátum vytvorenia účtu, kto a kedy prístup udelil a posledné použitie. Ak systém nedokáže poskytnúť posledné použitie, nechajte pole prázdne a uveďte to. Odhadnutá hodnota je horšia než známa medzera.

3. Priraďte posudzovateľov a dajte im kontext

Každý riadok smerujte osobe, ktorá ho dokáže posúdiť. Dajte posudzovateľovi zrozumiteľný opis každého oprávnenia, nielen jeho technický názov. „FI_AP_POST“ manažérovi povie málo; „Môže účtovať dodávateľské faktúry vo finančnom systéme“ je rozhodnutie, ktoré dokáže urobiť.

Stanovte termín a vopred rozhodnite, čo sa stane, keď posudzovateľ neodpovie. Odporúčame eskaláciu na manažéra daného posudzovateľa alebo na vlastníka kontrolného opatrenia. Ak sa mlčanie považuje za schválenie, kontrola sa mení na formalitu; ak to teda vaša politika niekedy pripúšťa, zapíšte prečo a pre ktorú nízkorizikovú skupinu.

4. Zaznamenajte rozhodnutia s odôvodnením

Každý riadok sa končí jedným z troch rozhodnutí:

• Ponechať: prístup stále zodpovedá aktuálnej práci osoby.
• Odobrať: prístup už nie je potrebný.
• Upraviť: potreba existuje, ale úroveň je nesprávna, napríklad prístup na zápis tam, kde by stačil prístup na čítanie.

Pri každom rozhodnutí ponechať privilegovaný alebo citlivý prístup a pri každej výnimke vyžadujte krátke odôvodnenie. Zaznamenajte identitu posudzovateľa a dátum rozhodnutia. Ak posudzovateľ kontrolu deleguje, zaznamenajte delegáta. Audítor testujúci opatrenie bude z týchto polí vyberať vzorku.

5. Vykonajte odobratia a úpravy

Rozhodnutie o odobratí nič nezmení, kým podľa neho niekto nekoná. Pre každé takéto rozhodnutie založte tiket alebo automatizovanú zmenu prepojenú s riadkom kontroly. Technický predpis k DORA vyžaduje „odobratie prístupových práv bez zbytočného odkladu po skončení pracovného pomeru, alebo ak prístup už nie je potrebný“ (článok 21 písm. e) bod iii)). Podľa nášho výkladu je rozhodnutie posudzovateľa o odobratí okamihom, keď je známe, že prístup už nie je potrebný, takže odobratie by malo začať od tohto dátumu.

Stanovte cieľový čas na dokončenie odobratí, kratší pri privilegovaných právach. Otvorené odobratia sledujte v kampani, aby sa kampaň nedala uzavrieť bez zaznamenanej výnimky, kým sú ešte nevybavené.

6. Overte výsledok v cieľovom systéme

Overte, že každé odobratie sa skutočne vykonalo. Po zmene znova získajte výpis prístupov z cieľového systému alebo použite report zo zosúlaďovania údajov (reconciliation) a porovnajte ho s rozhodnutiami. Zaznamenajte, kto a kedy to overil. Zablokovaný účet v adresári môže po sebe zanechať lokálny aplikačný účet, token API alebo aktívnu reláciu, takže overenie sa musí urobiť tam, kde prístup existuje. Náš sprievodca odchodom zamestnanca vysvetľuje, kde prístup prežije zmenu v adresári.

V záznamoch rozlišujte štyri stavy odobratia: vyžiadané, pokus vykonaný, neúspešné a overené. Neúspešná zmena započítaná ako dokončená je v zázname kontroly závažnou chybou, pretože vyzerá ako fungujúce opatrenie.

7. Uložte záznam a oznámte výsledok

Kampaň uzavrite súhrnom: rozsah, dátum výpisu, počet riadkov, rozhodnutia podľa typu, overené odobratia, stále otvorené odobratia, výnimky s vlastníkmi a termínmi a posudzovatelia, ktorí neodpovedali. Výpis, súbor s rozhodnutiami a podklady o overení uložte spolu.

Niektoré predpisy stanovujú lehotu uchovávania. Slovenská vyhláška NBÚ č. 227/2025 Z. z. vyžaduje, aby sa záznam o kontrole uchovával najmenej na obdobie od ukončenia posledného auditu do ukončenia nasledujúceho auditu alebo samohodnotenia (príloha č. 1, bod 80). Vykonávacie nariadenie k NIS2 stanovuje, že „príslušné subjekty zaznamenajú výsledky preskúmania vrátane nevyhnutných zmien prístupových práv“ (príloha, bod 11.2.3). Ak lehotu nestanovuje žiadny predpis, uchovávajte záznamy najmenej dovtedy, kým audítor, ktorý ich bude testovať, neskončí, a lehotu dohodnite so svojím vlastníkom kontrolného opatrenia.

Ako často kontrolovať prístupy podľa primárnych textov

Odpovede na internete často opakujú intervaly kontrol bez zdroja. Tabuľka uvádza iba to, čo hovorí každý primárny text, podľa overenia z 21. októbra 2026.

Technický predpis k DORA stanovuje šesť a dvanásť mesiacov a navyše aktualizácie na základe udalostí

Článok 21 písm. e) bod iv) technického predpisu k DORA vyžaduje „aktualizáciu prístupových práv, ak sú potrebné zmeny, a to aspoň raz ročne v prípade všetkých IKT systémov iných ako IKT systémy podporujúce kritické alebo dôležité funkcie a aspoň každých 6 mesiacov v prípade IKT systémov podporujúcich kritické alebo dôležité funkcie“. Slová „ak sú potrebné zmeny“ sú rovnako dôležité ako intervaly. Podľa nášho výkladu je takouto zmenou presun alebo odchod, takže aktualizácia nasleduje po udalosti a pravidelná aktualizácia zachytí to, čo proces viazaný na udalosti prehliadol. Samotný predpis uvádza jednu udalosť: odobratie prístupových práv bez zbytočného odkladu po skončení pracovného pomeru alebo ak prístup už nie je potrebný (písm. e) bod iii)).

Tieto intervaly platia pre subjekty podľa hlavy II predpisu. Subjekty, ktoré spĺňajú podmienky zjednodušeného rámca riadenia rizík IKT podľa článku 16 ods. 1 DORA, sa namiesto toho riadia článkom 33, ktorý vyžaduje pravidelné preskúmanie a odobratie, ale nestanovuje žiadny interval. Skôr než si na šesťmesačnej hodnote postavíte kalendár, potvrďte, ktorý režim sa na vás vzťahuje. Náš sprievodca riadením prístupov podľa DORA opisuje súvisiace požiadavky podrobnejšie.

PCI DSS v4.0.1 stanovuje šesť mesiacov pre používateľské účty

Požiadavka 7.2.4 vyžaduje, aby „všetky používateľské účty a súvisiace prístupové privilégiá vrátane účtov tretích strán/dodávateľov boli kontrolované takto: najmenej raz za šesť mesiacov“, aby sa neprimeraný prístup riešil a aby manažment potvrdil, že prístup zostáva primeraný. Požiadavka 7.2.5.1 pokrýva aplikačné a systémové účty s frekvenciou stanovenou cielenou analýzou rizík subjektu. Organizácia PCI SSC v júni 2024 oznámila, že verzia 4.0 bude 31. decembra 2024 vyradená a že v4.0.1 bude potom jedinou aktívnou verziou normy.

Poznámka k nášmu zdroju: dokument PCI DSS sa distribuuje cez knižnicu dokumentov PCI SSC po prijatí licencie, ktoré sme našimi overovacími nástrojmi nedokázali dokončiť, takže samotný text v4.0.1 sme nečítali. Vyššie uvedené znenie citujeme tak, ako je reprodukované na stránke Microsoftu k požiadavke 7 PCI DSS, teda zo sekundárneho zdroja; séria usmernení Microsoftu o sebe uvádza, že vychádza z PCI DSS v4.0, a PCI SSC uvádza, že v4.0.1 nepriniesla žiadne nové ani zrušené požiadavky. Znenie si overte vo svojej licencovanej kópii v4.0.1.

Vykonávacie nariadenie k NIS2 používa plánované intervaly

Vykonávacie nariadenie Komisie (EÚ) 2024/2690 sa vzťahuje na vymedzený okruh digitálnych subjektov vrátane poskytovateľov služieb DNS, poskytovateľov cloud computingu, služieb dátových centier a riadených služieb, online trhovísk a poskytovateľov dôveryhodných služieb. Bod 11.2.3 jeho prílohy znie: „Príslušné subjekty v plánovaných intervaloch preskúmavajú prístupové práva a upravujú ich na základe organizačných zmien.“ Bod 11.3.3 uplatňuje rovnaké pravidlo na privilegované účty a účty na správu systému. Obidva vyžadujú zaznamenanie výsledkov.

ENISA vo svojom technickom usmernení k implementácii (jún 2025, verzia 1.0) uvádza k bodu 11.2.3 toto usmernenie: „Vykonávajte kontroly riadenia prístupu k aktívam, aby ste overili, že všetky privilégiá sú autorizované, v opakujúcom sa harmonograme najmenej raz ročne.“ K bodu 11.5.4, ktorý vyžaduje, aby subjekty pravidelne preskúmavali identity a deaktivovali tie, ktoré už nie sú potrebné, ten istý dokument ENISA uvádza, že preskúmanie aktívnych identít „sa môže vykonávať v opakujúcom sa harmonograme, minimálne štvrťročne alebo častejšie“, s ročným preskúmaním pri mikrosubjektoch. Obidve hodnoty sú usmernením, nie zákonným minimom, ale sú rozumným oporným bodom, keď si stanovujete vlastný plán. Pri ostatných subjektoch podľa NIS2 rozhoduje národná transpozícia, ako ukazuje slovenský príklad nižšie.

NIST SP 800-53 necháva frekvenciu na vás

Katalóg opatrení NIST ponecháva interval ako parameter definovaný organizáciou. AC-2 j. vyžaduje, aby organizácia „preskúmala účty z hľadiska súladu s požiadavkami na správu účtov [Priradenie: frekvencia definovaná organizáciou]“. AC-6(7) vyžaduje preskúmanie, s frekvenciou definovanou organizáciou, „privilégií priradených [Priradenie: roly alebo triedy používateľov definované organizáciou] na overenie potreby takýchto privilégií“ a v prípade potreby ich opätovné priradenie alebo odobratie. V SP 800-53B je AC-6(7) súčasťou základných súborov opatrení pre strednú a vysokú úroveň (moderate a high baseline). Katalóg je dostupný ako Release 5.2.0, vydaný 27. augusta 2025. Programy postavené na NIST, napríklad federálne autorizácie v USA, môžu parameter doplniť číslom; overte si program, podľa ktorého ste hodnotení.

ISO/IEC 27001:2022, príloha A 5.18 a vaša vlastná politika

ISO/IEC 27001:2022 (3. vydanie, zverejnené v októbri 2022) je norma, ktorú predáva ISO, a text jej opatrení z prílohy A tu necitujeme. Verejným dokladom o tom, kde sa v prílohe A nachádza preskúmanie prístupových práv, je mapovacia tabuľka ENISA (verzia 1.2), ktorá priraďuje požiadavku NIS2 na správu prístupových práv (bod 11.2) k ISO/IEC 27001:2022 A.5.3 a A.5.18 a požiadavku na privilegované účty (bod 11.3) k A.8.2 a A.8.18, pričom upozorňuje, že mapovanie „by sa nemalo vykladať ako miera rovnocennosti medzi rôznymi normami alebo rámcami“.

Odporúčame rozhodnúť o intervale vo vlastnom ošetrení rizík, zapísať ho spolu s odôvodnením do svojej politiky riadenia prístupu a uchovávať podklady o tom, že každá kampaň ho dodržala. Audítor potom môže kampaň otestovať oproti vášmu vlastnému zdokumentovanému pravidlu. Opatrenie a usmernenie ISO/IEC 27002:2022 si prečítajte vo svojej licencovanej kópii.

Kontroly podľa SOX sa riadia audítorskou praxou, nie zákonným intervalom

Oddiel 404 zákona Sarbanes-Oxley (15 U.S.C. § 7262) vyžaduje, aby výročná správa emitenta obsahovala správu o vnútornej kontrole, ktorá uvádza zodpovednosť manažmentu za vnútornú kontrolu finančného výkazníctva a ktorá musí „obsahovať hodnotenie účinnosti štruktúry a postupov vnútornej kontroly emitenta pre finančné výkazníctvo ku koncu posledného fiškálneho roka emitenta“. Zákon kontroly prístupov nespomína. V programoch SOX sa kontroly používateľských prístupov pre finančne významné systémy bežne navrhujú a testujú ako všeobecné IT kontroly (ITGC). Audítorský štandard PCAOB AS 2201 uvádza medzi faktormi, ktoré ovplyvňujú riziko spojené s kontrolným opatrením, „mieru, do akej sa kontrolné opatrenie spolieha na účinnosť iných kontrolných opatrení (napr. kontrolného prostredia alebo všeobecných kontrol informačných technológií)“ (odsek .47); interval kontroly prístupov nestanovuje. Interval je rozhodnutím o návrhu kontrolného opatrenia, ktoré robí manažment a testuje externý audítor.

Slovenská vyhláška NBÚ č. 227/2025 Z. z. vyžaduje kontrolu najmenej raz ročne

Pre slovenských prevádzkovateľov základných služieb platí vyhláška NBÚ č. 227/2025 Z. z., účinná od 1. septembra 2025, ktorá v bode 80 prílohy č. 1 vyžaduje kontrolu „v pravidelných intervaloch, najmenej raz ročne“. Kontrola porovnáva schválené oprávnenia so skutočným stavom, zahŕňa detekciu a zneplatnenie nepoužívaných účtov a vytvára záznam, ktorý sa uchováva najmenej na obdobie od ukončenia posledného auditu do ukončenia nasledujúceho auditu alebo samohodnotenia. Náš sprievodca vyhláškou NBÚ č. 227/2025 Z. z. vysvetľuje body 76 až 87 a to, ako vykonať ročnú kontrolu.

Nemecký MaRisk už intervaly kontrol nestanovuje

Niektoré príručky stále citujú intervaly MaRisk od BaFin: najmenej ročná kontrola podpisových práv k platobným účtom a významných IT práv, najmenej každých šesť mesiacov pri obzvlášť kritických IT právach, ako je administrátorský prístup, a najmenej každé tri roky pri všetkých ostatných. Tieto intervaly sa nachádzali vo vysvetlivke k AT 4.3.1 vo verzii z roku 2024. Aktuálna verzia, Rundschreiben 06/2026 (BA) z 30. júna 2026, ich už neobsahuje. Ako uvádza sprievodný list BaFin, vypustenie vysvetliviek neznamená, že by orgán dohľadu prestal uznávať riešenia na nich postavené. Staré hodnoty neprezentujte ako aktuálnu požiadavku MaRisk. Inštitúcie v pôsobnosti DORA uplatňujú intervaly technického predpisu k DORA uvedené vyššie. Pri inštitúciách mimo pôsobnosti DORA sme v aktuálnom texte MaRisk nenašli žiadny interval kontroly; odporúčame stanoviť interval podľa rizika a odôvodnenie zdokumentovať.

Určenie vlastného intervalu

Ak váš rámec nestanovuje žiadne číslo alebo stanovuje iba maximum, určte interval podľa rizika a odôvodnenie zapíšte:

Stĺpec s intervalom je naše odporúčanie zostavené z vyššie uvedených pravidiel, nie právna požiadavka. Každá z týchto skupín potrebuje aj kontrolu na základe udalostí: nástupy, zmeny zaradenia a odchody majú zmeniť prístup vtedy, keď udalosť nastane.

Prečo kontroly zlyhávajú

Každá slabina uvedená nižšie spôsobí, že záznam kontroly nedokáže odpovedať na otázky audítora k vybranej vzorke. Každá má praktickú nápravu, ktorú môžete zabudovať do ďalšej kampane.

Formálne schvaľovanie bez posúdenia. Posudzovateľ schváli každý riadok za pár sekúnd, pretože zoznam je dlhý, názvy oprávnení sú kryptické a keď povie áno, nič sa nestane. Znaky v údajoch: 100 percent rozhodnutí ponechať, veľa riadkov rozhodnutých v tej istej minúte a žiadny text odôvodnenia. Kratšie zoznamy, zrozumiteľné opisy, zvýraznenie toho, čo sa od poslednej kontroly zmenilo, a požadovanie dôvodu pri ponechaní privilegovaných práv, to všetko ho obmedzuje.

Chýbajúci kontext. Posudzovateľ vidí používateľské meno a názov skupiny a nič iné. Bez aktuálnej pracovnej pozície osoby, významu oprávnenia, informácie o tom, kto ho udelil a či sa používa, nemá ani starostlivý posudzovateľ podľa čoho rozhodnúť. Doplňte kontext do zoznamu, inak sa kontrola zmení na hádanie.

Neúplná kontrolovaná skupina. Výpis vynechá účty v lokálnej aplikácii, zdedené oprávnenia alebo druhý adresár. Kontrola potom certifikuje zoznam, ktorý je menší než skutočnosť. Pred rozoslaním výpis zosúlaďte so systémom.

Chýbajúci dôkaz o odobratí. Kampaň zaznamená rozhodnutia „odobrať“, ale nikto nedokáže preukázať, že prístup bol odobratý. V niektorých prípadoch bol prístup odobratý a potom sa znova objavil, pretože ho opäť udelil automatizovaný proces alebo priradenie roly. Túto medzeru uzatvára overenie v cieľovom systéme a kontrola v ďalšej kampani, či odobratý prístup zostal odobratý.

Nesprávny posudzovateľ. Manažér kontroluje privilegovanú databázovú rolu, ktorej nerozumie, alebo tím odchádzajúceho manažéra nikto nikdy nepriradí inému posudzovateľovi. Technické a privilegované práva smerujte vlastníkovi systému a pri zmene posudzovateľov kontroly znovu priraďte.

Žiadny záznam o výnimkách. Niekto si ponechá prístup, ktorý je v rozpore s politikou, z dobrého dôvodu, ktorý existuje iba v e-maile. Výnimku, jej vlastníka a dátum jej skončenia zaznamenajte v kampani.

Kontrolný zoznam ku kontrole používateľských prístupov

Tento zoznam používajte pred každou kampaňou, počas nej aj po nej.

Pred kampaňou

• Rozsah je zapísaný: systémy, typy účtov, typy oprávnení, vylúčenia s dôvodmi
• Interval pre každú skupinu je stanovený a odvodený od vášho pravidla alebo rozhodnutia o riziku
• Prístupy sú získané z každého systému s dátumom výpisu, kde je to možné, ako skutočne dostupný prístup
• Každý účet je priradený k osobe alebo k servisnej identite so známym vlastníkom; nepriradené účty sú uvedené ako nálezy
• Oprávnenia sú opísané zrozumiteľným jazykom
• Posudzovatelia sú priradení, privilegované práva sú smerované vlastníkom systémov
• Termín, cesta eskalácie a pravidlo pri neodpovedaní sú dohodnuté

Počas kampane

• Každý riadok má rozhodnutie: ponechať, odobrať alebo upraviť
• Odôvodnenie je zaznamenané pri rozhodnutiach ponechať privilegovaný a citlivý prístup a pri každej výnimke
• Identita posudzovateľa a dátum rozhodnutia sú zaznamenané vrátane delegátov
• Neodpovedania sú eskalované, nie automaticky schválené

Po kampani

• Pre každé rozhodnutie odobrať a upraviť je založený tiket alebo zmena
• Každé odobratie je overené v cieľovom systéme s údajom, kto a kedy
• Neúspešné alebo čakajúce odobratia sú sledované až do dokončenia alebo zaznamenanej výnimky
• Súhrn je napísaný: počty podľa rozhodnutí, overené odobratia, otvorené položky, výnimky
• Výpis, rozhodnutia a podklady o overení sú uložené spolu počas požadovanej lehoty uchovávania
• Dátum ďalšej kampane je stanovený; odobratý prístup sa v ďalšom behu znova skontroluje

Bezplatná šablóna na kontrolu používateľských prístupov

Táto šablóna na kontrolu používateľských prístupov (XLSX) je jeden zošit s tromi hárkami. Je bezplatná a nevyžaduje registráciu. Používa štandardné funkcie (COUNTA, COUNTIF, COUNTIFS, SUMPRODUCT, IF, AND, MAX, LEN a TRIM) a overenie údajov s rozbaľovacími zoznamami; jej vzorce sme otestovali v LibreOffice Calc.

• Instructions (Pokyny) vysvetľuje, ako vyplniť hárky, význam každého rozhodnutia a pravidlo overenia.
• Review (Kontrola) má jeden riadok na každý účet a oprávnenie, s rozbaľovacími zoznamami pre rozhodnutie a polia overenia.
• Summary (Súhrn) počíta rozhodnutia a stav overenia pomocou vzorcov, takže súčty sa aktualizujú priebežne, ako posudzovatelia pracujú.

Stĺpce v hárku Review

Čo počíta hárok Summary

Hárok Summary počíta riadky v kontrole, každý typ rozhodnutia, riadky ešte bez rozhodnutia a podiel rozhodnutých. Potom počíta odobratia a úpravy, ktoré vyžadujú zmenu, koľko z nich je overených v cieľovom systéme a koľko je označených Nie (No). Dve kontroly kvality počítajú rozhodnutia ponechať bez odôvodnenia a rozhodnutia bez dátumu. Stavová bunka zobrazí Hotovo (Complete) iba vtedy, keď je každý riadok rozhodnutý a každá zmena overená. V hárku Review je riadok s rozhodnutím odobrať alebo upraviť, ktorý ešte nie je overený, podfarbený oranžovo a rozhodnutie ponechať bez dôvodu je podfarbené žlto.

Tabuľka funguje pri prvej kampani alebo malom rozsahu. Súbor chráňte, pôvodný výpis uchovávajte vedľa neho a pri uzavretí kampane uložte kópiu s dátumom, pretože zdieľaná tabuľka neuchováva spoľahlivú históriu toho, kto zmenil rozhodnutie.

Keď tabuľka prestane stačiť

Tabuľky zlyhávajú na predvídateľných miestach: veľa systémov a posudzovateľov, výpisy, ktoré počas kampane starnú, ručné prepisovanie rozhodnutí do tiketov a žiadne prepojenie medzi rozhodnutím a zmenou, ktorá po ňom nasledovala. Systém na riadenie a správu identít (IGA) sa pripája k zdrojovým systémom, generuje kontrolu z aktuálnych údajov, zaznamenáva rozhodnutia s identitou posudzovateľa a dokáže odobratie riadiť alebo sledovať. To obmedzuje prepisovanie. Váš tím stále rozhoduje o rozsahu a posudzovateľoch a stále overuje, či sa odobratia dostali do cieľových systémov.

Pri hodnotení nástroja otestujte časti, ktoré zlyhávajú pri auditoch: dokáže ukázať, odkiaľ každé oprávnenie pochádza, necháva chýbajúcu hodnotu viditeľne chýbať a oddeľuje zaznamenané rozhodnutie o odobratí od potvrdenej zmeny v cieľovom systéme?

Kde má easyIGA svoje miesto

easyIGA je softvér na riadenie identít postavený na midPointe. Pri kontrolách prístupov zobrazuje človeka, oprávnenie a dostupnú históriu spoločne, takže posudzovateľ má z čoho pri rozhodnutí vychádzať. Posledné použitie, údaje o pridelení a zachytené schválenia sa zobrazujú tam, kde ich pripojené zdroje poskytujú, a chýbajúce informácie sú jasne označené.

easyIGA zaznamenáva žiadateľa a zachytené schvaľovacie kroky pri žiadostiach podaných cez produkt. Prístupy pridelené mimo easyIGA sú označené osobitne podľa údajov o vytvorení, ktoré zaznamenal midPoint. Ponechanie aj odobratie prístupu sú zaznamenané rozhodnutia a čakajúca alebo neúspešná zmena zostáva odlíšená od overeného odobratia. Exporty podkladov ku kontrolám obsahujú dostupnú históriu žiadostí a schválení. Pri žiadostiach o prístup vidí schvaľovateľ v čase rozhodnutia konflikty z pravidiel nezlučiteľnosti nastavených v midPointe (oddelenie povinností). Tvorba a simulácia pravidiel priamo v easyIGA sú plánované a zatiaľ nie sú dostupné.

Kontrolované skupiny a frekvenciu si volíte podľa svojich rizík a povinností, ako je opísané vyššie. Stránka o kontrolách prístupov opisuje pracovný postup a stránka o auditných podkladoch vysvetľuje, ktoré záznamy podporujú rozhodnutie a čo samy osebe nedokážu preukázať.

Často kladené otázky

Ako často sa majú vykonávať kontroly používateľských prístupov?

Závisí to od pravidla, ktoré sa na vás vzťahuje. Technický predpis k DORA vyžaduje aktualizáciu prístupových práv, ak sú potrebné zmeny, a aspoň každých 6 mesiacov pri IKT systémoch podporujúcich kritické alebo dôležité funkcie a aspoň raz ročne pri ostatných IKT systémoch. Požiadavka 7.2.4 PCI DSS v4.0.1 stanovuje pre používateľské účty najmenej raz za šesť mesiacov. Vyhláška NBÚ č. 227/2025 Z. z. stanovuje najmenej raz ročne pre slovenských prevádzkovateľov základných služieb. NIST SP 800-53 a vykonávacie nariadenie k NIS2 ponechávajú interval na vás. Pri ISO/IEC 27001 odporúčame interval stanoviť a zdokumentovať vo vlastnej politike. Pri privilegovanom prístupe odporúčame kontrolu najmenej tak často, ako vyžaduje vaše najprísnejšie uplatniteľné pravidlo.

Je štvrťročná kontrola prístupov povinná?

Žiadny z primárnych textov overených pre tohto sprievodcu nestanovuje štvrťročný interval. Najbližšia hodnota je nezáväzná: technické usmernenie ENISA k implementácii navrhuje k bodu 11.5.4 vykonávacieho nariadenia k NIS2 (preskúmanie identít) opakujúci sa harmonogram „minimálne štvrťročne alebo častejšie“, s ročným preskúmaním pri mikrosubjektoch. Organizácia si napriek tomu môže zvoliť štvrťročné kontroly pre vysokorizikové skupiny alebo ich dohodnúť so svojím audítorom. Zapíšte, prečo ste interval zvolili.

Aký je rozdiel medzi kontrolou používateľských prístupov a certifikáciou prístupu?

V praxi opisujú tú istú kontrolu. „Certifikácia“ a „recertifikácia“ sú pojmy, ktoré produkty IGA používajú pre kontrolnú kampaň. midPoint túto funkciu nazýva certifikácia prístupu.

Kto má kontrolovať používateľské prístupy?

Osoba, ktorá dokáže posúdiť pracovnú potrebu: zvyčajne priamy nadriadený pri súlade s pracovnou pozíciou a vlastník aplikácie alebo údajov pri tom, čo technické alebo privilegované oprávnenie umožňuje. Vlastník kontrolného opatrenia definuje proces a schvaľuje výsledok.

Aké podklady očakáva audítor z kontroly prístupov?

Počítajte s tým, že preukážete rozsah a dátum výpisu, kontrolovaný zoznam, každé rozhodnutie s posudzovateľom a dátumom, odôvodnenia ponechaného privilegovaného prístupu a výnimiek, tikety na odobratia a dôkaz, že odobratia boli dokončené v cieľovom systéme. Niektoré predpisy pridávajú požiadavky na uchovávanie, napríklad bod 80 vyhlášky NBÚ.

Nahrádza kontrola procesy odchodu a zmeny zaradenia?

Nie. Kontrola zachytí to, čo procesy viazané na udalosti prehliadli. Technický predpis k DORA vyžaduje odobratie prístupových práv bez zbytočného odkladu po skončení pracovného pomeru alebo ak prístup už nie je potrebný a osobitne vyžaduje pravidelnú aktualizáciu opísanú vyššie; podľa nášho výkladu tieto dve povinnosti platia nezávisle od seba.

Môžem šablónu použiť ako auditný podklad pre ISO 27001 alebo SOC 2?

Šablóna zaznamenáva polia, ktoré tento sprievodca odporúča uchovávať: posudzovateľa, rozhodnutie, odôvodnenie, dátumy, tiket na odobratie a overenie. Či je postačujúca, závisí od návrhu vášho kontrolného opatrenia a od vášho audítora. Sama osebe súlad nepreukazuje.

Zdroje a overovací záznam

Všetky zdroje, URL adresy a licencia na obrázok boli skontrolované 21. októbra 2026, pričom právne tvrdenia a tvrdenia o normách boli v ten istý deň v samostatnom kontrolnom kroku znova overené oproti primárnym textom. EUR-Lex, iso.org, pcaobus.org a unsplash.com blokujú jednoduché automatizované kontroly stavu; ich stránky boli v ten deň prečítané nástrojom na načítanie stránok.

1. Európska komisia, delegované nariadenie Komisie (EÚ) 2024/1774 z 13. marca 2024 (RTS k DORA o riadení rizík IKT), Úradný vestník z 25. júna 2024, články 21 a 33
2. Európsky parlament a Rada, Nariadenie (EÚ) 2022/2554 (DORA), článok 3 bod 22
3. Európska komisia, vykonávacie nariadenie Komisie (EÚ) 2024/2690 zo 17. októbra 2024, príloha, body 11.2.3 a 11.3.3
4. ENISA, Technické usmernenie k implementácii vykonávacieho nariadenia (EÚ) 2024/2690, verzia 1.0, zverejnené 26. júna 2025 (usmernenie k bodom 11.2.3 a 11.5.4), a mapovacia tabuľka, verzia 1.2, 21. augusta 2025
5. PCI Security Standards Council, knižnica dokumentov (Document Library) (PCI DSS v4.0.1, vyžaduje sa prijatie licencie; text pre tento článok nebol prečítaný), a Práve zverejnené: PCI DSS v4.0.1, 11. júna 2024
6. Microsoft, Microsoft Entra ID a požiadavka 7 PCI-DSS, aktualizované 23. augusta 2024 (sekundárny zdroj citovaného znenia požiadavky; séria Microsoftu uvádza, že vychádza z PCI DSS v4.0)
7. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0, 27. augusta 2025, opatrenia AC-2 a AC-6(7)
8. ISO, ISO/IEC 27001:2022, 3. vydanie, október 2022
9. Legal Information Institute, 15 U.S. Code § 7262, hodnotenie vnútorných kontrol manažmentom
10. PCAOB, AS 2201: audit vnútornej kontroly finančného výkazníctva
11. Národný bezpečnostný úrad (NBÚ), vyhláška č. 227/2025 Z. z. o bezpečnostných opatreniach, Slov-Lex, účinná od 1. septembra 2025, a príloha č. 1 (PDF)
12. BaFin, Rundschreiben 06/2026 (BA), MaRisk, 30. júna 2026, jeho sprievodný list a porovnávacia verzia
13. Evolveum, certifikácia prístupu v midPointe (konfiguračná referencia pre midPoint 4.10; neverzovaná adresa docs.evolveum.com/midpoint/reference/roles-policies/certification/ presmerúva sem)
14. Foto Jakub Żerdzicki, Unsplash, použitá v súlade s licenciou Unsplash License

Tento článok je praktickým usmernením a výkladom citovaných textov. Nie je právnym poradenstvom. To, ktoré predpisy sa vzťahujú na vašu organizáciu a aké intervaly očakáva váš orgán dohľadu alebo audítor, si potvrďte s kvalifikovanými právnymi poradcami a poradcami pre súlad s predpismi.