Externí účetní potřebuje otevřít podklady k fakturám. Servisní technik se má na dvě hodiny připojit k zařízení. Dodavatel interního systému řeší opravu, ke které nestačí běžná uživatelská role. Ve všech třech situacích firma zpřístupňuje své systémy člověku, jehož práci neřídí stejně jako práci vlastního zaměstnance.
Problém obvykle nevznikne samotným založením účtu. Vznikne ve chvíli, kdy není dohledatelné, kdo přístup požadoval, kdo ho schválil, co přesně externista smí dělat a kdy oprávnění skončí. Přístup pak přežije původní zakázku, rozšíří se „pro jistotu“ a při další kontrole už nikdo neví, zda je stále potřeba.
Tento článek nabízí praktický provozní rámec pro menší firmu. Nenahrazuje bezpečnostní audit, právní posouzení ani povinnosti, které se mohou vztahovat na konkrétní organizaci, smlouvu nebo regulovanou službu.
Externista potřebuje vlastní přístupový životní cyklus
Stálý pracovní účet obvykle kopíruje nástup, změnu role a odchod zaměstnance. U externisty je spouštěčem konkrétní služba, servisní zásah nebo časově omezená spolupráce. Přístup proto nemá začínat neformální zprávou správci systému a končit až při náhodném úklidu uživatelů.
Bezpečný životní cyklus spojuje šest kroků:
žádost s jasným pracovním důvodem,
posouzení rozsahu dat, funkcí a rizika,
schválení odpovědnou osobou,
aktivaci osobního účtu s omezenou platností,
kontrolu používání a trvající potřeby,
odebrání přístupu s ověřeným výsledkem.
Článek o odchodu zaměstnance řeší jednorázové ukončení širšího pracovního vztahu, včetně zařízení, e-mailu a předání práce. Přístup externisty je užší, ale často se opakuje a od prvního dne má mít stanovený konec. Přehled o firemních přístupech, doménách a e-mailech zase mapuje vlastnictví technického zázemí. Zde je hlavním předmětem jednotlivé oprávnění konkrétní externí osoby.
Žádost musí vysvětlit práci, ne jen název role
Požadavek „založit dodavateli přístup do ERP“ je příliš široký. Správce z něj nepozná, zda externí účetní potřebuje číst všechny zakázky, exportovat adresář klientů nebo pouze nahrát zpracované doklady za určité období. Bez konkrétního účelu se bezpečné oprávnění nastavuje odhadem.
Jedna přístupová žádost může být jednoduchý formulář nebo záznam v interním systému. Měla by však spojit alespoň tyto údaje:
| Položka | Co má být dohledatelné | Proč je důležitá |
|---|---|---|
| Osoba a organizace | Jméno externisty, firma a pracovní kontakt | Účet patří konkrétní identitě, ne anonymnímu „servisu“ |
| Pracovní účel | Úkol, zakázka, servisní zásah nebo služba | Rozsah lze porovnat se skutečnou potřebou |
| Interní vlastník | Člověk, který odpovídá za spolupráci a potvrdí její konec | IT správce nemusí hádat, zda obchodní důvod stále trvá |
| Systémy a data | Konkrétní aplikace, objekty, složky nebo zařízení | Přístup se nerozšíří na celé prostředí bez důvodu |
| Povolené činnosti | Čtení, zápis, export, schválení, konfigurace nebo správa | „Má přístup“ neznamená neomezenou administraci |
| Platnost | Začátek, konec a případné časové okno | Ukončení není závislé jen na paměti správce |
| Schválení a kontrola | Schvalující osoba, datum revize a způsob ověření | Výjimka má vlastníka i kontrolní bod |
Interní vlastník nemusí účet technicky zakládat. Musí ale rozumět obchodnímu důvodu a poznat okamžik, kdy práce skončila nebo se změnila. Správce systému následně převádí schválený požadavek do konkrétní role.
Nejmenší potřebné oprávnění se odvozuje od úkolu
Zásada nejmenšího oprávnění neznamená vytvořit tak omezený účet, že externista nemůže práci dokončit. Znamená povolit právě ty činnosti, které odpovídají schválenému účelu, a nic navíc. NÚKIB ve svém aktuálním manuálu popisuje princip need-to-know, pravidelnou kontrolu přidělených práv i reakci na změnu nebo ukončení vztahu s dodavatelem. Manuál je určen poskytovatelům regulovaných služeb v režimu nižších povinností; pro ostatní firmy představuje užitečný zdroj dobré praxe, nikoli automaticky závazný návod.
V praxi pomáhá rozdělit oprávnění po jednotlivých vrstvách:
rozsah dat – jen vybraná firma, zakázka, objekt, období nebo složka,
typ činnosti – čtení, nahrání, úprava, export nebo administrace,
prostředí – produkce, testovací prostředí nebo konkrétní zařízení,
způsob připojení – běžné webové přihlášení, spravované vzdálené spojení nebo fyzická návštěva,
čas – celé období spolupráce, konkrétní dny nebo jen servisní okno.
Externí účetní může například potřebovat doklady a exporty, ale nikoli správu uživatelů. Servisní technik může potřebovat dočasné připojení ke konkrétnímu zařízení, nikoli trvalý administrátorský účet do celé sítě. Dodavatel webu může upravovat svůj projekt, aniž by viděl jiné hostingové služby firmy.
Každý externista má mít vlastní účet. Sdílené přihlašovací údaje znemožňují spolehlivě určit, kdo akci provedl, a při ukončení spolupráce nutí měnit heslo všem ostatním. Pokud platforma samostatné účty nepodporuje, jde o omezení, které má být výslovně zaznamenané a řešené přiměřenou náhradní kontrolou.
Datum konce patří k přístupu už při založení
„Do dokončení zakázky“ není technický termín. Zakázka může zůstat otevřená kvůli poslední faktuře, záručnímu zásahu nebo administrativnímu doplnění. Přístup proto potřebuje konkrétní datum nebo kratší servisní okno a interního vlastníka, který případné prodloužení znovu potvrdí.
Kde to systém umožňuje, je vhodné nastavit automatické vypršení účtu, role nebo přístupového balíčku. NIST SP 800-53 zahrnuje správu dočasných účtů, jejich vypnutí po předem určené době a princip nejmenšího oprávnění. Katalog je určen pro řízení bezpečnostních kontrol a musí se přizpůsobit prostředí organizace; neposkytuje jednu univerzální lhůtu pro všechny firmy.
Prodloužení nemá přepisovat původní žádost bez historie. Nové datum potřebuje důvod a schválení. Firma pak vidí, zda šlo o jednorázový zásah, pravidelnou spolupráci nebo opakovanou výjimku, kterou by měl nahradit standardní proces.
MFA chrání identitu, ale nenahrazuje omezení role
Vícefaktorové ověření snižuje riziko, že samotné odcizené heslo otevře firemní systém. NÚKIB ve svém manuálu vícefaktorovou autentizaci výslovně popisuje mezi mechanismy ověřování identit. U externích účtů dává MFA smysl zejména tam, kde je přístup vzdálený, vede k citlivým datům nebo umožňuje administrativní změny.
MFA ale neřeší špatně navržené oprávnění. Správně ověřený externista může stále vidět příliš mnoho dat nebo provést změnu, kterou ke své práci nepotřebuje. Bezpečný účet proto kombinuje:
jednoznačnou osobní identitu,
vícefaktorové ověření podle možností a rizika systému,
omezenou roli a rozsah dat,
platnost a automatické ukončení tam, kde je dostupné,
záznam důležitých přihlášení a změn.
Ověřovací metoda má zůstat pod kontrolou konkrétní osoby. Kódy přeposílané mezi více lidmi nebo společný telefon pro několik dodavatelů vracejí do procesu stejnou nejasnost jako sdílené heslo.
Kontrola přístupu není jednorázový roční úklid
Čím kratší a přesnější je platnost, tím méně závisí bezpečnost na periodické revizi. Přesto je potřeba kontrolovat dlouhodobější spolupráce a přístupy bez technicky vynutitelného konce. Frekvence nemá univerzální hodnotu; odvíjí se od citlivosti dat, síly oprávnění, délky vztahu a možného dopadu.
Revizi má spustit také konkrétní změna:
externista přešel na jiný úkol nebo zakázku,
dodavatel změnil člověka, který službu skutečně poskytuje,
původní smluvní nebo provozní důvod skončil,
účet dlouho nevykazuje očekávanou aktivitu,
role získala nové funkce nebo přístup k dalším datům,
došlo k bezpečnostnímu incidentu nebo podezřelému přihlášení.
Kontrola nemá končit otázkou „je účet aktivní?“. Interní vlastník potvrzuje, že důvod trvá. Správce ověřuje rozsah role, platnost, MFA, členství ve skupinách a případné přístupy mimo hlavní adresář. U významnějších oprávnění se porovná i skutečné používání s očekávaným účelem.
Odebrání musí pokrýt účet, relace i vedlejší cesty
Uzavření požadavku „účet vypnut“ nemusí stačit. Externista mohl mít aktivní relaci, VPN profil, API klíč, účet v portálu výrobce, přístup do sdílené složky nebo heslo ke společnému účtu. Výstupní krok se proto vrací k původnímu inventáři a ověří všechny cesty, které byly pro práci otevřené.
zablokovat další přihlášení a ukončit aktivní relace,
odebrat role, skupiny, sdílení a přístupy ke konkrétním objektům,
zneplatnit tokeny, certifikáty, API klíče nebo vzdálené profily,
změnit sdílené tajemství, pokud ho externista znal,
vrátit kartu, klíč, zapůjčené zařízení nebo bezpečnostní prostředek,
ověřit, že výstupy práce a potřebná dokumentace zůstaly firmě dostupné.
Účet může být nejprve zablokovaný a teprve následně odstraněný podle pravidel systému a firmy. Tím se oddělí rychlé ukončení přístupu od rozhodnutí o uchování záznamů nebo převzetí pracovních výstupů.
Auditní stopa má odpovědět na praktické otázky
Auditní stopa není jen dlouhý technický log. Pro běžné řízení přístupu musí jít dohledat zejména to, kdo žádost podal a schválil, jaké oprávnění bylo skutečně přiděleno, kdy se změnilo, kdy proběhla poslední kontrola a kdo potvrdil odebrání.
U citlivějších nebo administrátorských přístupů pomáhají také záznamy přihlášení a významných změn. Rozsah logování a doba uchování se mají řídit účelem, rizikem a platnými pravidly. Cílem není bezbřehé sledování člověka, ale schopnost vysvětlit, co se v systému stalo, a ověřit, že oprávnění nebylo použito mimo schválený rámec.
Vhodný záznam o uzavření může obsahovat datum a čas deaktivace, provedené kroky, zjištěné výjimky a jméno osoby, která výsledek ověřila. Samotné zaškrtnutí úkolu bez kontroly nemusí prokázat, že zmizely i aktivní relace nebo vedlejší účty.
Kdo rozhoduje a kdo změnu technicky provede
Menší firma může několik rolí spojit do jednoho člověka. Jejich význam ale zůstává rozdílný:
Interní vlastník spolupráce popíše účel, potvrdí potřebný rozsah a oznámí změnu nebo konec práce.
Vlastník systému nebo dat posoudí, zda požadovaný přístup odpovídá citlivosti a pravidlům prostředí.
Schvalující osoba přijme rozhodnutí u silnější role, výjimky nebo přístupu s vyšším dopadem.
Technický správce účet nastaví, ověří zabezpečení, provede změny a doloží odebrání.
Externista používá vlastní identitu, chrání ověřovací prostředky a hlásí změnu osoby, zařízení nebo potřeby.
Technický správce nemá sám rozhodovat, zda účetní ještě potřebuje doklady za minulý rok nebo zda servisní dodavatel dokončil reklamaci. Interní vlastník naopak nemá bez konzultace určovat technickou administrátorskou roli. Rozdělení odpovědností brání tomu, aby obchodní pohodlí nebo technický odhad nahradily schválené rozhodnutí.
Tři modelové situace
Následující příklady jsou smyšlené a slouží pouze k vysvětlení procesu.
Externí účetní
Firma založí osobní účet s přístupem k vybraným účetním podkladům a exportům. Role neobsahuje správu uživatelů ani provozní data, která účetní nepotřebuje. Interním vlastníkem je odpovědná osoba za finance. Přístup má termín revize a při změně účetní kanceláře se starý účet nepojmenuje po novém člověku, ale zruší a nahradí novou identitou.
Servisní technik výrobce
Technik potřebuje vzdáleně diagnostikovat konkrétní zařízení. Připojení se povolí jen pro domluvené servisní okno a v rozsahu potřebném pro diagnostiku. Firma ví, kdo zásah objednal, kdo přístup otevřel a kdo po dokončení ověřil jeho uzavření. Trvalý univerzální vzdálený účet nevzniká jen proto, aby byl příští servis pohodlnější.
Dodavatel interní aplikace
Dodavatel nejprve pracuje v testovacím prostředí. Pokud oprava vyžaduje produkční zásah, vznikne samostatně schválené časové okno se silnější rolí. Po změně se přístup sníží nebo odebere a firma si ponechá záznam o zásahu. Obecná dlouhodobá administrace se nezamění za výjimku potřebnou k jedné opravě.
Nejčastější chyby při přístupu externistů
Jeden účet pro celou dodavatelskou firmu. Při změně technika není jasné, kdo se přihlásil a kdo stále zná heslo.
Role „administrátor“ pro jistotu. Pohodlí při první konfiguraci se promění v trvalé nadbytečné oprávnění.
Platnost bez data konce. Účet přežije servisní zásah i smluvní vztah.
MFA bez kontroly rozsahu. Identita je ověřená lépe, ale stále vidí zbytečně mnoho dat.
Kontrola pouze v hlavním adresáři. Zůstane VPN, portál výrobce, sdílená složka nebo lokální účet.
Smazání bez předání výstupů. Firma ukončí účet, ale ztratí dokumentaci, konfiguraci nebo vlastnictví souborů.
První verze evidence může být malá
Menší firma nepotřebuje hned pořizovat složitý nástroj pro správu identit. Začít může jedním seznamem aktivních externích přístupů a jedním schvalovacím postupem. Důležité je, aby každý záznam spojoval osobu, účel, interního vlastníka, rozsah, schválení a datum konce.
První kontrola může proběhnout nad třemi skupinami: externí účetnictví, servisní dodavatelé a lidé spravující web, hosting nebo interní aplikace. U každého účtu se ověří, zda je stále potřeba, zda patří konkrétní osobě, zda má přiměřenou roli, zda používá vhodné ověření a zda existuje plán odebrání.
Pokud firma nedokáže sestavit úplný seznam účtů, rolí a vzdálených cest, může bezpečnostní prověrka firemního prostředí začít právě mapováním přístupů a určením priorit. Cílem není přidat další administrativu, ale zajistit, aby každý externí přístup měl srozumitelný důvod, omezený rozsah a ověřitelný konec.
Zdroje a metodika
NÚKIB: Manuál pro poskytovatele regulovaných služeb v režimu nižších povinností, verze 1.1, poslední aktualizace 18. 6. 2026.
NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, včetně informace o Release 5.2.0 z 27. 8. 2025.
Microsoft Learn: Govern access for external users in entitlement management, praktický příklad schválení, expirace a životního cyklu externích identit.
Zdroje byly ověřeny k 31. 8. 2026. Článek rozlišuje obecné principy, příklady funkcí konkrétních platforem a vlastní praktický procesní rámec Metricu. Konkrétní nastavení musí odpovídat používaným systémům, smluvním vztahům, citlivosti dat a rizikům organizace.
