Audit přístupových práv: kdo vidí firemní data

Odpověď hned: Audit přístupových práv zjistí, který člověk se skutečně dostane ke kterým firemním datům, přes jaký účet, skupinu, roli nebo sdílecí odkaz a zda k tomu má pracovní důvod. Výsledkem má být přehled efektivních oprávnění, konkrétní seznam rizik a plán nápravy, který lze po změnách znovu ověřit.

Seznam účtů nestačí

Firma může mít správně vedený seznam zaměstnanců, a přesto nemusí vědět, kdo vidí mzdy, smlouvy nebo zákaznické složky. Přístup totiž nevzniká jen přímým přidělením oprávnění jednomu člověku.

Uživatel se může k datům dostat přes:

  • členství v jedné nebo několika skupinách;
  • vnořenou skupinu z Active Directory nebo Microsoft Entra ID;
  • oprávnění zděděné z nadřazené složky;
  • přímou výjimku na konkrétním souboru nebo adresáři;
  • roli správce systému;
  • externí účet hosta;
  • odkaz pro konkrétní osoby nebo pro kohokoli, kdo odkaz získá;
  • sdílený účet či heslo;
  • servisní účet používaný aplikací nebo automatizací.

Audit proto nesleduje jen nastavená oprávnění, ale především efektivní přístup: co daný uživatel skutečně otevře, změní, stáhne, nasdílí nebo spravuje.

Nejdřív určete data, role a vlastníky

Kontrola nemá začínat exportem všech uživatelských účtů. Nejdřív je potřeba určit, která data firma chrání, kdo o jejich zpřístupnění rozhoduje a které pracovní role je potřebují.

Typickými vlastníky mohou být jednatel, finanční ředitel, vedoucí obchodu nebo personalista. IT správce může oprávnění technicky nastavit, ale neměl by sám rozhodovat, zda obchodník potřebuje přístup ke mzdám nebo externí účetní k celé dokumentaci firmy.

Základním podkladem je matice rolí a systémů:

RoleSystém nebo dataPotřebný přístupZpůsob přiděleníVlastník
ÚčetníÚčetní složka na NASčtení a zápisskupina UCETNIvedení firmy
ObchodníkCRMběžný uživatelaplikační rolevedoucí obchodu
PersonalistaPersonální dokumentyčtení a zápisskupina PERSONALNIvedení firmy
Externí ITSpráva serverůadministrace po nezbytnou dobusamostatný účetjednatel

Matice popisuje cílový stav. Teprve proti němu lze rozumně vyhodnotit, jestli je konkrétní oprávnění potřebné, nadbytečné, nebo naopak chybí.

Princip nejnižších oprávnění neznamená všem všechno zakázat. Uživatel má dostat přístup potřebný pro svou práci, v nezbytném rozsahu a na odpovídající dobu. Příliš těsné nastavení bez znalosti provozu často vede ke kopírování dokumentů mimo řízené úložiště nebo ke sdílení hesel.

Co má audit ve firmě zahrnout

Rozsah závisí na používaných systémech, ne pouze na počtu zaměstnanců. Malá firma s NAS, Microsoft 365, VPN, účetním programem a několika externisty může mít složitější oprávnění než větší firma s centrálně řízenými identitami.

Obvykle je potřeba prověřit alespoň:

  1. uživatelské, administrátorské, hostovské a servisní účty;
  2. skupiny, vnořená členství a aplikační role;
  3. sdílené složky na NAS a Windows Serveru;
  4. SharePoint, OneDrive, Teams a sdílené schránky;
  5. VPN, vzdálenou správu a přístupy dodavatelů;
  6. veřejné a externí sdílecí odkazy;
  7. sdílená hesla, vícefaktorové ověřování a nouzové účty;
  8. účty bývalých pracovníků a přístupy bez určeného vlastníka;
  9. API klíče, integrační účty a automatizace navázané na konkrétní osobu.

Důležitý je také rozsah oprávnění. Nestačí poznamenat, že uživatel „má přístup“. Audit musí rozlišit čtení, zápis, mazání, sdílení, změnu oprávnění a plnou administraci.

Windows Server: spojte oprávnění sdílení a NTFS

U složek zpřístupněných přes SMB se obvykle uplatňují dvě vrstvy: oprávnění sdílení a oprávnění souborového systému NTFS. Výsledný přístup přes síť je omezen oběma vrstvami.

Běžné nastavení může ponechat oprávnění sdílení široké a skutečné omezení řešit pomocí NTFS skupin. Samotný záznam Everyone na sdílení proto ještě nedokazuje, že všichni mohou číst obsah. Auditor musí vyhodnotit celou cestu až ke konkrétnímu uživateli.

Kontrola má zjistit:

  • které sdílené složky existují a kdo za ně odpovídá;
  • které skupiny mají právo číst, měnit nebo plně spravovat obsah;
  • zda se oprávnění dědí do podsložek;
  • kde je dědičnost přerušená;
  • zda existují přímé výjimky pro jednotlivé uživatele;
  • jak se projeví členství ve více skupinách;
  • zda se vypočtený přístup shoduje s ověřením v praxi.

Příkaz nebo export zobrazující ACL je pouze část důkazu. Samotný seznam záznamů nemusí správně vysvětlit členství ve skupinách, jejich vnoření a výsledné oprávnění konkrétní identity.

Synology a QNAP: pozor na lokální i doménové skupiny

Na zařízeních Synology s DSM a QNAP s QTS může uživatel získat přístup přes lokální účet NAS, lokální skupinu, účet z Active Directory nebo ACL zděděné z nadřazené složky. Vedle běžných sdílených složek je potřeba projít také domovské adresáře, aplikační oprávnění, administrátorské skupiny a případná připojení ke cloudovým službám.

Audit NAS má odpovědět na stejné otázky jako kontrola Windows Serveru:

  • kdo smí sdílenou složku otevřít;
  • kdo v ní může měnit nebo mazat data;
  • kdo smí měnit její oprávnění;
  • zda existují individuální výjimky;
  • jestli účet nebo skupina stále odpovídají skutečné pracovní roli.

Přidělování práv skupinám je zpravidla přehlednější než desítky výjimek pro jednotlivce. Při nástupu účetní se změní členství ve skupině UCETNI; není nutné hledat její jméno v každé složce zvlášť.

Microsoft 365: zkontrolujte role, hosty i odkazy

V Microsoft 365 může přístup vzniknout přes skupinu Microsoft 365, bezpečnostní skupinu, tým, web SharePointu, přímé oprávnění, externího hosta nebo sdílecí odkaz. Tyto cesty je potřeba posuzovat společně.

Dokument může být správně omezen na členy týmu, ale současně může existovat starší odkaz typu „kdokoli s odkazem“. Takový odkaz může být předán další osobě a podle nastavení nemusí vyžadovat přihlášení. Odkaz pro konkrétní osoby je přesnější, ani ten však nemá zůstávat aktivní bez vlastníka a důvodu.

Kontrola by měla zahrnout:

  • externí hosty a jejich poslední známý účel;
  • anonymní odkazy a odkazy s neomezenou platností;
  • přímá oprávnění mimo běžné členství v týmu;
  • vlastníky týmů a webů SharePointu;
  • oprávnění k jednotlivým složkám a dokumentům;
  • sdílené schránky a práva Full Access, Send As a Send on behalf;
  • administrátorské role v Microsoft Entra ID;
  • pracovní účty, které zároveň používají nejvyšší administrátorskou roli.

Běžný účet správce nemá být globálním administrátorem jen kvůli pohodlí. Pro správu je vhodný oddělený účet a počet nejvyšších správců má vycházet z reálné potřeby i zastupitelnosti. Pokud už došlo k podezřelému přihlášení nebo změně pravidel pošty, postupujte podle návodu pro napadený účet Microsoft 365.

Odchod zaměstnance: zablokovat přístup, nesmazat naslepo

Při odchodu pracovníka je potřeba rychle zablokovat jeho přihlášení a ukončit aktivní relace. Jiná věc je nevratné smazání identity. Před ním musí firma převést potřebná data, poštu, dokumenty, vlastnictví týmů a závislé automatizace.

Audit má hledat zejména:

  • aktivní účty bývalých zaměstnanců;
  • externisty bez stanoveného konce přístupu;
  • nevyužívané lokální účty na serverech a NAS;
  • přístupy vedené na soukromé e-mailové adresy;
  • VPN profily a účty vzdálené správy;
  • API klíče a servisní účty svázané s konkrétním člověkem;
  • sdílená hesla, která odcházející pracovník stále zná.

Ukvapené smazání může přerušit zálohování, synchronizaci, účetní integraci nebo automatizovaný export. Pokud firma přebírá infrastrukturu po správci či dodavateli, pomůže checklist Odešel nám ajťák a nikdo nezná hesla.

Sdílené účty skrývají, kdo změnu provedl

Účty jako sklad, recepce nebo admin, jejichž heslo zná několik lidí, znemožňují spolehlivě přiřadit konkrétní akci konkrétnímu člověku. Po odchodu zaměstnance navíc nelze odebrat jen jeho přístup bez změny hesla pro všechny ostatní.

Každý člověk má mít vlastní účet. Technická hesla, která nelze úplně odstranit, patří do firemního správce hesel s řízeným sdílením, historií změn a možností odebrat jednotlivého uživatele. Výběr řešení rozebíráme v článku Správce hesel pro firmu.

Důležité účty mají používat vícefaktorové ověřování. U systémů, které je podporují, poskytují passkeys nebo hardwarové klíče založené na FIDO2 lepší ochranu proti podvrženým přihlašovacím stránkám než opsaný kód. Firma ale musí vyřešit také náhradní způsob přihlášení, ztrátu zařízení a nouzový přístup. Praktické rozdíly popisuje přehled MFA ve firmě: passkeys a FIDO2 místo SMS.

Jak má vypadat použitelný výstup

Výsledkem auditu nemá být několik technických exportů bez vysvětlení. Firma potřebuje nejméně tři navazující výstupy.

Matice rolí a systémů

Popisuje schválený cílový stav: která role potřebuje který přístup, kdo jej schválil a kdo za daná data odpovídá.

Seznam nálezů

Každý nález má určit konkrétní účet, skupinu, složku, roli nebo odkaz. Součástí má být důkaz zjištění, obchodní dopad a návrh dalšího kroku.

Místo obecného „oprávnění nejsou v pořádku“ má být uvedeno například:

Skupina OBCHOD má přes zděděné NTFS oprávnění možnost měnit složku Mzdy. Vlastník personálních dat tento přístup nepotvrdil. Před odebráním se ověří, zda stejná skupina neobsluhuje potřebný export do účetního systému.

Plán nápravy a ověření

Plán určuje odpovědnou osobu, pořadí změn, termín, vratný postup a způsob následné kontroly. Za dokončenou nelze považovat změnu, kterou správce pouze uložil. Je potřeba ověřit, že neoprávněný uživatel přístup ztratil a oprávnění lidé mohou dál pracovat.

Pokud nikdo ve firmě nedokáže spolehlivě určit, kdo vidí citlivá data, umíme tento postup provést jako součást IT auditu; jak takový audit probíhá krok za krokem, popisuje článek IT audit malé firmy. Výstupem je popsaný stav, priority nápravy a podklady pro opakovanou kontrolu, ne jen nekomentovaný export účtů.

Nápravu oddělte od sběru podkladů

Samotný audit může probíhat převážně čtením konfigurace, exportů a ověřováním vybraných scénářů. Nemá automaticky měnit hesla, vypínat účty nebo přepisovat dědičnost oprávnění.

Hromadná změna NTFS práv, odstranění všech externích odkazů nebo deaktivace servisních účtů může zastavit běžný provoz. Před významnější změnou je potřeba:

  1. potvrdit nález s vlastníkem dat;
  2. zjistit závislosti účtu nebo skupiny;
  3. zaznamenat původní nastavení;
  4. připravit vratný postup;
  5. provést omezenou změnu;
  6. ověřit očekávaný i nežádoucí přístup;
  7. teprve potom pokračovat dalšími účty nebo složkami.

Prioritu mají opuštěné administrátorské účty, veřejně dostupné citlivé dokumenty, neřízený vzdálený přístup a sdílená hesla k důležitým systémům. Přesné pořadí ale musí vycházet z dopadu na konkrétní firmu.

Jak často přístupová práva kontrolovat

Jednorázový audit uklidí historický stav, ale nezabrání vzniku nových výjimek. Kontrola má navazovat na události, které oprávnění mění:

  • nástup nebo odchod zaměstnance;
  • změna pracovní role;
  • příchod či odchod externího dodavatele;
  • založení nového systému nebo úložiště;
  • reorganizace sdílených složek;
  • bezpečnostní incident;
  • převzetí IT od jiného správce.

Pravidelná čtvrtletní revize může být pro menší firmu rozumným výchozím intervalem, není však univerzální povinností. Citlivější prostředí nebo časté personální změny mohou vyžadovat kratší cyklus; stabilní systém s dobře řízenými rolemi může pracovat s jiným intervalem podle vlastního rizika.

NIS2 a GDPR: audit není certifikát shody

Řízení přístupu patří mezi bezpečnostní opatření řešená ochranou osobních údajů i kybernetickou bezpečností. Audit může doložit skutečný stav, vlastníky oprávnění a provedené nápravy. Sám o sobě ale neprokazuje úplné splnění GDPR, směrnice NIS2 ani českého zákona č. 264/2025 Sb., o kybernetické bezpečnosti.

Kdo pod nový zákon spadá, shrnuje článek NIS2 a zákon 264/2025 Sb.. Soulad závisí také na řízení rizik, zálohování, reakci na incidenty, správě dodavatelů, kontinuitě provozu a dalších opatřeních. Výrok „provedli jsme audit přístupů, takže máme splněno“ proto není obhajitelným závěrem.

Nejčastější otázky

Jak dlouho audit přístupových práv trvá?

Rozhoduje počet systémů, skupin, individuálních výjimek a kvalita dokumentace. Firma s dvaceti lidmi může mít složitější oprávnění než firma s padesáti zaměstnanci, pokud používá více oddělených cloudových služeb, lokální NAS a historické účty externistů.

Musí se při auditu měnit hesla?

Ne automaticky. Změna je namístě například u sdíleného, uniklého nebo jinak nedůvěryhodného hesla. Sběr podkladů má být od nápravy oddělený, aby audit sám nezpůsobil výpadek.

Je odkaz „kdokoli s odkazem“ vždy chyba?

Ne vždy. Musí však mít konkrétní účel, vlastníka, přiměřený rozsah a dobu platnosti. Pro interní, personální nebo smluvní dokumenty je zpravidla vhodnější sdílení určeným a ověřeným osobám.

Stačí bývalého zaměstnance odebrat ze skupin?

Nestačí. Je potřeba prověřit také cloudové, lokální, VPN a administrátorské účty, aktivní relace, sdílená hesla, vlastnictví dat, integrační klíče a automatizace navázané na jeho identitu.

Jak poznat, že audit nebyl jen formální?

U každého významného přístupu musí být dohledatelné, odkud vznikl, kdo jej schválil a zda odpovídá pracovní potřebě. Po nápravě musí následovat ověření, že nadbytečný přístup zmizel a oprávnění uživatelé o potřebná data nepřišli.