Správa tajných údajů strojových identit pro audity v roce 2026

Upozornění v 02:13, které nikdo nedokázal přiřadit

V úterý ve 02:13 ráno se rozsvítí kanál bezpečnostního provozu. Z interního automatizačního účtu byl spuštěn export produkční databáze. Přístupová cesta je legitimní. Token je platný. Zdrojová IP adresa patří cloudovému runneru používanému vývojovým týmem. Malware není viditelný. Neexistuje žádné hlášení phishingu.

CISO položí první zřejmou otázku: „Kdo tuto identitu vlastní?“

Ticho.

Vedoucí týmu DevOps si vzpomene, že token vznikl při migraci zákazníka před dvěma lety. Platformní tým říká, že jej možná používá fakturační integrace. Správce databáze uvádí, že má přístup pro čtení, protože jeho odebrání kdysi narušilo noční úlohu. Právní oddělení se ptá, zda šlo o osobní údaje. Útvar compliance se ptá, zda jde o incident podléhající hlášení podle NIS2, DORA nebo GDPR. Auditor žádá důkazy, že servisní účty, API klíče, certifikáty a tajné údaje CI/CD jsou evidovány, přezkoumávány, rotovány, monitorovány a rušeny.

V 09:00 už se rýsuje návrh auditního zjištění. V zapomenuté mikroslužbě byl objeven pevně zakódovaný API klíč, který nebyl rotován. Poskytuje široký přístup k produkční databázi zákaznických transakcí. Vývojář, který jej vytvořil, odešel před dvěma lety. Systém nemá určeného vlastníka, dokumentovaný účel, záznam o rotaci ani monitorovací pravidlo.

To je problém strojových identit v roce 2026.

Většina organizací zlepšila řízení přístupu u lidských uživatelů. Mají MFA, procesy nástupu, změn rolí a odchodů, přezkumy privilegovaných přístupových práv a logy poskytovatelů identit. Strojové identity se však rozmnožily rychleji než jejich správa. Servisní účty, identity pracovních zátěží, API klíče, OAuth tokeny, SSH klíče, certifikáty, tajné údaje Kubernetes, integrační tokeny SaaS, účty robotické procesní automatizace a nasazovací přihlašovací údaje CI/CD dnes provádějí kritické podnikové úkony, aniž by byly „uživateli“ v lidském smyslu.

Pro poskytovatele SaaS, fintech společnosti, poskytovatele řízených služeb, provozovatele cloudu a datově intenzivní malé a střední podniky už nespravované strojové identity nejsou jen otázkou technické hygieny. Jsou rizikem odolnosti a souladu na úrovni vedoucího orgánu. NIS2 považuje řízení přístupu, správu aktiv, zabezpečení dodavatelského řetězce, zvládání incidentů a kybernetickou hygienu za základní opatření řízení rizik kybernetické bezpečnosti. DORA u finančních subjektů podřizuje riziko ICT, provozní odolnost, hlášení incidentů a riziko ICT třetích stran odpovědnosti vedoucího orgánu. GDPR vyžaduje, aby správci a zpracovatelé chránili osobní údaje a byli schopni doložit odpovědnost.

Obtížné není prokázat, že tajné údaje existují. Obtížné je prokázat, že každá strojová identita má vlastníka, účel, životní cyklus, hodnocení rizika, schválený přístup, bezpečnou metodu uložení, pravidlo rotace, pokrytí monitorováním a postup revokace.

Proč se strojové identity staly novým problémem privilegovaného přístupu

Strojová identita, tedy NHI, je jakákoli digitální identita používaná softwarem, infrastrukturou nebo automatizovanými procesy namísto osoby. V praxi zahrnuje servisní účty používané aplikacemi, API klíče používané integracemi SaaS, OAuth a refresh tokeny používané aplikacemi třetích stran, SSH klíče používané automatizací, certifikáty TLS a soukromé klíče, tajné údaje CI/CD, cloudové identity pracovních zátěží, databázové připojovací řetězce, vložené přihlašovací údaje, účty RPA botů a integrační přihlašovací údaje spravované dodavatelem.

Tyto identity mají často tři vlastnosti, které auditory zneklidňují.

Za prvé, mají dlouhou životnost. Lidský uživatel může rotovat přihlašovací údaje, měnit role a odejít formálním procesem offboardingu. API token vytvořený během okna vydání může zůstat aktivní roky, protože nikdo nechce riskovat narušení produkčního prostředí.

Za druhé, jsou silné. Nasazovací token může měnit infrastrukturu. Cloudový instanční objekt služby může vytvářet úložiště. Databázový účet může exportovat zákaznické záznamy. Podpisový klíč může kompromitovat integritu softwarového dodavatelského řetězce.

Za třetí, jsou obtížně přiřaditelné. Lidské identity jsou navázány na HR záznamy. Strojové identity jsou často navázány na skripty, pipeline, dodavatele, zapomenuté projekty nebo nedokumentované integrace.

Clarysec ve svém Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint na tento problém upozorňuje přímo ve fázi Controls in Action, krok 22:

A nezapomeňte na strojové identity. Právě zde audity často odhalí tichou expozici. Jsou API tokeny sledovány? Jsou integrační účty navázány na konkrétní osoby, nebo visí ve vzduchoprázdnu? Kdy byl naposledy rotován databázový přístupový řetězec vložený ve skriptu starém desítky let?

Správa identit není efektní, ale je strukturální. Bez ní je váš ISMS jen souborem zamčených dveří, aniž by bylo možné ověřit, kdo drží klíče.

V té poslední větě je podstata. Společnost může mít propracovanou politiku řízení přístupu a přesto neuspět u auditu, pokud nejsou strojové identity řízeny. ISMS, který nedokáže vysvětlit, kdo vlastní tajný údaj, proč existuje a kdy byl naposledy přezkoumán, ještě nefunguje jako řízený systém.

ISO/IEC 27001:2022 mění správu tajných údajů na důkazy

ISO/IEC 27001:2022 je účinná právě proto, že nepovažuje správu tajných údajů za izolovaný inženýrský úkol. Vyžaduje rizikově orientovaný ISMS s definovaným rozsahem, požadavky zainteresovaných stran, odpovědností vedení, posouzením rizik, ošetřením rizik, výběrem opatření, Prohlášením o použitelnosti a neustálým zlepšováním.

U strojových identit by organizace neměla začínat nákupem nástroje. Měla by začít rozsahem a povinnostmi.

Podle kapitol ISO/IEC 27001:2022 4.1 až 4.4 organizace určuje interní a externí otázky, zainteresované strany, právní, regulační a smluvní požadavky, rozhraní a závislosti. V kontextu NHI má rozsah ISMS identifikovat cloudová prostředí, platformy SaaS, systémy CI/CD, produkční aplikace, zákaznické integrace, zpracovatele dat, poskytovatele řízených služeb a kryptografické služby, ve kterých existují strojové přihlašovací údaje.

Kapitoly 5.1 až 5.3 stanovují odpovědnost vedení za politiku, zdroje, role a vykazování výkonnosti. Je to důležité, protože náprava NHI často vytváří provozní napětí. Rotace přihlašovacího údaje produkční databáze, nahrazení staršího sdíleného servisního účtu nebo vynucení načítání tajných údajů z trezoru může narušit křehké pracovní postupy. Bez výkonného sponzora týmy úklid odkládají.

Kapitoly 6.1.1 až 6.1.3 a 6.2 poskytují řídicí mechanismus. Organizace definuje kritéria rizik, identifikuje rizika důvěrnosti, integrity a dostupnosti, přiřazuje vlastníky rizik, hodnotí pravděpodobnost a dopad, volí možnosti ošetření, vybírá opatření, vytváří Prohlášení o použitelnosti a sleduje měřitelné cíle.

V praxi má plán ošetření rizik strojových identit odpovědět na tyto otázky:

• Které systémy a podnikové služby jsou závislé na NHI?
• Které tajné údaje umožňují přístup k osobním údajům, regulovaným finančním službám, produkční infrastruktuře nebo kritickým zákaznickým službám?
• Které identity jsou privilegované, neaktivní, sdílené, spravované dodavatelem nebo neřízené?
• Která opatření snižují riziko, například uložení do trezoru, rotace, zásada minimálních oprávnění, expirace, řízení životního cyklu certifikátů, skenování CI/CD, monitorování a nouzová revokace?
• Která zbytková rizika vyžadují obchodní schválení?

ISO/IEC 27002:2022 následně poskytuje katalog opatření přílohy A. Mezi nejrelevantnější opatření patří 5.9 Evidence informací a dalších souvisejících aktiv, 5.15 Řízení přístupu, 5.16 Správa identit, 5.17 Autentizační informace, 5.18 Přístupová práva, 5.19 Bezpečnost informací ve vztazích s dodavateli, 5.20 Řešení bezpečnosti informací ve smlouvách s dodavateli, 5.21 Řízení bezpečnosti informací v dodavatelském řetězci ICT, 5.23 Bezpečnost informací při používání cloudových služeb, 5.24 Plánování a příprava řízení incidentů, 5.28 Sběr důkazů, 8.2 Privilegovaná přístupová práva, 8.3 Omezení přístupu k informacím, 8.5 Bezpečná autentizace, 8.15 Protokolování, 8.16 Monitorovací činnosti, 8.24 Používání kryptografie, 8.25 Životní cyklus bezpečného vývoje, 8.26 Požadavky na zabezpečení aplikací, 8.28 Bezpečné kódování a 8.31 Oddělení vývojového, testovacího a produkčního prostředí.

Clarysec ve svém Zenith Controls: The Cross-Compliance Guide Zenith Controls mapuje tyto vazby ISO/IEC 27002:2022 způsobem použitelným pro auditory i vlastníky opatření. U opatření 5.16, Správa identit, Zenith Controls vysvětluje vztah mezi identitou a přihlašovacími údaji:

Správa identit určuje „kdo“, zatímco autentizační informace zajišťují „jak“ ověřením, že osoba prohlašující určitou identitu je legitimní. 5.16 řídí životní cyklus identit, zatímco 5.17 zajišťuje, že hesla, tokeny, certifikáty a další přihlašovací údaje jsou bezpečně navázány na tyto identity a řádně spravovány tak, aby podporovaly silnou autentizaci.

Tento vztah je pro NHI zásadní. Token bez vlastníka identity není auditovatelný. Servisní účet bez přezkumu přístupových práv není v souladu se zásadou minimálních oprávnění. Certifikát bez stavu životního cyklu není řízenou kryptografií. Integrační přihlašovací údaj dodavatele bez smluvních podmínek není účinným řízením rizik třetích stran.

Kontrolní model Clarysec: identita, tajný údaj, oprávnění, důkaz

Clarysec zavádí správu strojových identit a tajných údajů prostřednictvím opakovatelného kontrolního modelu. „Tajné údaje“ nepovažujeme pouze za téma DevOps ani „servisní účty“ pouze za téma IAM. Propojujeme identitu, tajný údaj, oprávnění a důkazy.

Vrstva politik je místem, kde se z toho stávají vymahatelné požadavky.

Pro malé a střední podniky uvádí Clarysec Politika správy uživatelských účtů a oprávnění pro malé a střední podniky Politika správy uživatelských účtů a oprávnění pro malé a střední podniky:

Servisní účty používané systémy nebo aplikacemi musí být dokumentovány, omezeny na konkrétní systémy a nikdy nesmí být používány pro interaktivní přihlášení.

Tím se předchází klasickému anti-patternu, kdy se servisní účet stane sdíleným administrátorským přihlášením. Auditor tím zároveň získává jasný test: předložte evidenci servisních účtů, ukažte omezení na systémy a dokažte, že interaktivní přihlášení je vypnuto nebo technicky znemožněno.

Clarysec Politika správy aktiv pro malé a střední podniky Politika správy aktiv pro malé a střední podniky rozšiřuje definici aktiv tak, aby zahrnovala:

Digitální přihlašovací údaje a služby: doménová jména, digitální certifikáty, API klíče, e-mailové účty, cloudová přihlášení

Je to důležité, protože mnoho organizací eviduje pouze servery, notebooky a aplikace. V roce 2026 může být API klíč citlivější než notebook. Soukromý klíč certifikátu může být produkčním autentizačním aktivem. Cloudové přihlášení používané automatizací může vytvořit expozici regulovaných dat. Zacházet s přihlašovacími údaji jako s aktivy je základem správy tajných údajů připravené na audit.

Pro podniková prostředí zvyšuje Clarysec Politika správy uživatelských účtů a oprávnění Politika správy uživatelských účtů a oprávnění laťku důkazů:

Organizace musí udržovat podrobnou evidenci všech aktivních a neaktivních přihlašovacích údajů, privilegovaných účtů a systémových servisních účtů. Tato evidence musí být průběžně aktualizována a čtvrtletně přezkoumávána.

Právě při čtvrtletním přezkumu se objeví mnoho mezer. Neaktivní přihlašovací údaje, osiřelé instanční objekty služeb, starší integrační uživatelé, neřízené dodavatelské účty a nouzové tokeny se stanou viditelnými teprve tehdy, když někdo porovná registr se skutečnými záznamy IAM, trezoru, CI/CD a cloudu.

Tajné údaje jsou autentizační informace, ne vývojářské pohodlí

Nejnebezpečnější fráze ve správě tajných údajů je „dočasný klíč“.

Dočasné klíče se stávají trvalými. Testovací přihlašovací údaje se dostávají do produkce. Zdrojový kód odhaluje tokeny. Logy sestavení zpřístupňují hesla. Týmy podpory sdílejí certifikáty prostřednictvím tiketů. Vývojáři kopírují soubory prostředí do chatu. Dodavatel vytvoří cloudový instanční objekt služby a odejde.

Zenith Blueprint, fáze Controls in Action, krok 22, popisuje autentizační informace široce:

Toto opatření se netýká pouze hesel, i když hesla jsou samozřejmě součástí problému. Týká se každého přihlašovacího údaje používaného k prokázání identity: hesel, PINů, kryptografických klíčů, biometrických šablon, čipových karet, tokenů, certifikátů, OAuth tokenů, SSH klíčů a API tajných údajů. To jsou klíče ke království a opatření 5.17 zajišťuje, že se s nimi zachází s vážností, kterou si zaslouží.

Řekněme to jasně: špatná správa autentizace zůstává jednou z hlavních kořenových příčin porušení bezpečnosti. Slabá nebo sdílená hesla. Pevně zakódované přihlašovací údaje ve zdrojovém kódu. Nezměněná výchozí přihlášení na administrátorských portálech. Certifikáty s expirovaným nebo neznámým vlastnictvím. Ve všech těchto případech neselhala identita, ale selhala schopnost chránit a řídit mechanismus používaný k prokázání této identity.

Politiky Clarysec to převádějí do provozních pravidel.

Politika kryptografických opatření pro malé a střední podniky Politika kryptografických opatření pro malé a střední podniky stanoví:

Klíče nesmí být ukládány v prostém textu ani vkládány do zdrojového kódu, dokumentů nebo e-mailů.

Politika bezpečného vývoje pro malé a střední podniky Politika bezpečného vývoje pro malé a střední podniky stanoví:

Žádné pevně zakódované přihlašovací údaje nebo tajné údaje ve zdrojovém kódu.

Pro podnikové týmy Politika bezpečného vývoje Politika bezpečného vývoje stanoví:

Tajné údaje nesmí být pevně zakódované ani ukládané v prostém textu v repozitářích.

A Politika požadavků na zabezpečení aplikací Politika požadavků na zabezpečení aplikací je ještě přímější:

Ukládání hesel nebo kryptografických klíčů v prostém textu je přísně zakázáno.

Tato ustanovení politik vytvářejí jasnou auditní stopu. Bezpečnostní týmy mohou testovat repozitáře, proměnné CI/CD, obrazy kontejnerů, konfigurační úložiště, systémy pro evidenci požadavků, dokumentační platformy a logy proti výslovným požadavkům. Podporují také Article 32 GDPR o zabezpečení zpracování, protože expozice tajných údajů může přímo vést k neoprávněnému přístupu k osobním údajům.

Podniková kryptografická správa potřebuje také vlastnictví. Clarysec Politika kryptografických opatření Politika kryptografických opatření vyžaduje:

Musí být veden centralizovaný registr správy klíčů, který zaznamenává všechny kryptografické klíče, jejich stav životního cyklu, přiřazené správce a kontexty používání.

U strojových identit má tento registr propojit klíče certifikátů, podpisové klíče, API klíče a klíče spravované cloudem s širším registrem NHI. Auditor musí být schopen vysledovat produkční certifikát od podnikové služby přes vlastníka, správce, expiraci a důkazy o rotaci až po postup reakce na incidenty.

NIS2, DORA a GDPR: jeden model důkazů, více regulátorů

Správa strojových identit je průřezovou otázkou souladu, protože stejné selhání může vyvolat více povinností.

Uniklý API token u poskytovatele SaaS může způsobit narušení služby podle NIS2, expozici osobních údajů podle GDPR a smluvní hlášení incidentů finančním zákazníkům podle očekávání DORA v dodavatelském řetězci. Kompromitovaný tajný údaj CI/CD u poskytovatele ICT služeb může ovlivnit odolnost zákazníků, integritu softwaru a kontinuitu provozu. Zapomenutý integrační účet dodavatele může vytvořit přístup k regulovaným systémům bez řádné náležité péče nebo smluvních kontrol.

NIS2 Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření. Minimální oblasti zahrnují analýzu rizik, politiky bezpečnosti informačních systémů, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování, vývoj a údržbu, řešení zranitelností, hodnocení účinnosti, kybernetickou hygienu, kryptografii, bezpečnost lidských zdrojů, řízení přístupu a správu aktiv a tam, kde je to vhodné, MFA nebo průběžnou autentizaci. Strojové identity zasahují téměř do všech těchto oblastí. NIS2 Article 23 také zavádí postupné hlášení významných incidentů, včetně včasného varování do 24 hodin, oznámení incidentu do 72 hodin a závěrečné zprávy nejpozději do jednoho měsíce od oznámení incidentu.

DORA se použije od 17. ledna 2025 a pokrývá řízení rizik v oblasti ICT, hlášení závažných incidentů souvisejících s ICT, testování provozní odolnosti, sdílení informací a riziko ICT třetích stran. Articles 5 a 6 vyžadují správu a řízení, odpovědnost vedoucího orgánu a dokumentovaný rámec řízení rizik v oblasti ICT. Article 8 vyžaduje identifikaci podnikových funkcí podporovaných ICT, informačních aktiv a závislostí. Articles 17 až 19 vyžadují řízení incidentů, klasifikaci a hlášení. Articles 28 až 30 vyžadují řízení rizik ICT třetích stran, smluvní registry, náležitou péči, bezpečnostní standardy, práva na audit, podporu při incidentech, kontroly subdodávek a exit strategie.

GDPR se použije všude, kde jsou osobní údaje zpracovávány v jeho územní působnosti. Article 5 vyžaduje integritu, důvěrnost a odpovědnost. Article 32 vyžaduje vhodná technická a organizační opatření pro zabezpečení zpracování. Pokud servisní účet nebo API klíč umožňuje přístup k osobním údajům, neřízené tajné údaje se stávají selháním kontrol ochrany soukromí, nikoli pouze IT problémem.

Stejné důkazy mohou podporovat certifikaci ISO/IEC 27001:2022, dohled podle NIS2, šetření podle DORA a odpovědnost podle GDPR, pokud jsou správně strukturovány.

NIST CSF 2.0 lze použít jako komunikační vrstvu pro stejné důkazy. Jeho funkce GOVERN pokrývá očekávání zainteresovaných stran, právní a smluvní povinnosti, ochotu podstupovat riziko, odpovědnost vedení, politiku a dohled. Jeho provozní výsledky pokrývají evidence aktiv, služby poskytované dodavateli, správu identit a přihlašovacích údajů, zásadu minimálních oprávnění, zabezpečení dat, protokolování, monitorování, reakci na incidenty a obnovu.

COBIT 2019 a týmy zajišťování ve stylu ISACA se obvykle zaměří na správu a řízení a způsobilost procesů. Budou se ptát, zda je přiřazena odpovědnost, zda jsou opatření začleněna do provozních procesů, zda jsou výjimky schvalovány, zda jsou metriky reportovány vedení a zda důkazy prokazují opakovatelnost, nikoli jednorázový úklid.

Praktický sprint k vytvoření registru strojových identit

Praktické zapojení Clarysec často začíná cíleným sprintem, nikoli šestiměsíčním programem zavádění nástrojů. Cílem je vytvořit obhajitelný registr NHI, rizikové pořadí a plán nápravy, které mohou vstoupit do plánu ošetření rizik ISO/IEC 27001:2022 a Prohlášení o použitelnosti.

Začněte jednou podnikovou službou, například zákaznickou fakturační platformou, obchodní aplikací, pacientským portálem nebo systémem správy tenantů SaaS. Zahrňte produkci, staging prostředí, CI/CD, cloudovou infrastrukturu, monitorovací nástroje, databáze, integrace SaaS a služby spravované dodavatelem.

Propojte to se Zenith Blueprint, fáze Risk Management, krok 14, kde Clarysec slaďuje politiky ošetření s regulačními křížovými odkazy. V tomto kroku zahrnují opatření bezpečného vývoje a pipeline žádné pevně zakódované tajné údaje, kolegiální přezkoumání, automatizovanou statickou analýzu, skenování závislostí, oddělení vývoje, testování a produkce, MFA pro přístup k pipeline, integritu artefaktů sestavení a protokolování CI/CD.

Shromážděte identity a tajné údaje z poskytovatele identit, cloudového IAM, trezoru tajných údajů, Kubernetes, proměnných CI/CD, nastavení repozitářů, databázových uživatelů, administrátorských konzolí SaaS, nástrojů pro správu certifikátů a dodavatelské dokumentace.

Rizikově ohodnoťte identity, které mají přístup do produkce, privilegovaná oprávnění, přístup k osobním údajům, závislost na kritické nebo důležité funkci, kontrolu dodavatelem, dlouhodobé tokeny, chybějícího vlastníka, žádnou rotaci, žádné monitorování nebo pevně zakódované uložení. Použijte kritéria rizik ISO/IEC 27001:2022 ke skórování pravděpodobnosti a dopadu. Tam, kde je to použitelné, použijte analýzu kritických nebo důležitých funkcí podle DORA. Kde jsou dostupné osobní údaje, použijte úvahy o dopadu podle GDPR. Kde je pravděpodobné narušení služby nebo újma zákazníků, použijte dopad na službu podle NIS2.

U každé vysoce rizikové NHI uplatněte opatření ošetření. Přesuňte tajné údaje ze zdrojového kódu, dokumentů a proměnných CI/CD v prostém textu do trezoru nebo spravovaného úložiště tajných údajů. Nahraďte sdílené servisní účty jedinečnými identitami pracovních zátěží. Zakažte interaktivní přihlášení u servisních účtů. Uplatněte zásadu minimálních oprávnění a přihlašovací údaje specifické pro prostředí. Nakonfigurujte rotaci, expiraci a nouzovou revokaci. Navažte tajné údaje na vlastníky a správce. Přidejte protokolování autentizace, použití tokenů a citlivých akcí. Přidejte upozorňování na anomální geografii, neobvyklý čas, neobvyklý objem nebo přístup k novému zdroji. Aktualizujte smlouvy s dodavateli o nakládání s přihlašovacími údaji, podpoře při incidentech a právech na audit. Dokumentujte výjimky se schválením vlastníka rizika a datem expirace.

Politika testovacích dat a testovacích prostředí Politika testovacích dat a testovacích prostředí podporuje oddělení prostředí:

Integrace s CI/CD pipeline musí vynucovat oddělení prostředí a autentizačních údajů.

Toto ustanovení je často rozhodující. Pokud vývoj, test a produkce sdílejí tajné údaje, prostředí s nízkým rizikem se může stát cestou k narušení produkce.

Sprint má skončit balíčkem důkazů, nikoli pouze seznamem zjištění. Zahrňte export registru NHI, záznamy posouzení rizik, plán ošetření, mapování Prohlášení o použitelnosti, odkazy na politiky, snímky obrazovek trezoru, logy rotace, schválení přezkumů přístupových práv, výsledky skenování tajných údajů v CI/CD, definice monitorovacích pravidel, matici odpovědností za přihlašovací údaje dodavatelů, provozní postup pro incident a výjimky s vlastníky a daty expirace.

Protokolování a detekce: prokázání viditelnosti používání strojových identit

Strojová identita, která je dobře evidována, ale není viditelná v logech, zůstává nebezpečná. Detekce je součástí příběhu opatření.

Clarysec Politika protokolování a monitorování pro malé a střední podniky Politika protokolování a monitorování pro malé a střední podniky zahrnuje autentizační důkazy:

Autentizační logy: úspěšné a neúspěšné pokusy o přihlášení, délka relace, použití MFA

Pro NHI tento požadavek přizpůsobte strojové autentizaci. U identity pracovní zátěže možná nebudete mít použití MFA, ale měli byste mít autentizační události, použití tokenu, použití certifikátu, metadata volání API, zdrojovou pracovní zátěž, cílovou službu, dobu platnosti tokenu, události selhání a privilegované akce.

V Zenith Controls je opatření ISO/IEC 27002:2022 8.2, Privilegovaná přístupová práva, navázáno na protokolování a monitorování, protože privilegované účty vyžadují podrobné záznamy a dohled. Zenith Controls také propojuje 8.2 se správou identit, přístupovými právy, omezením přístupu k informacím a bezpečnou autentizací. Pro auditory to znamená, že privilegované strojové identity mají být přezkoumávány a monitorovány se stejnou vážností jako lidští administrátoři, někdy i vyšší.

Dobré monitorovací otázky zahrnují:

• Autentizoval se servisní účet z neočekávané pracovní zátěže nebo rozsahu IP adres?
• Přistoupil API klíč k novému koncovému bodu nebo datové sadě?
• Byl certifikát použit po nahrazení?
• Nasadil CI/CD token mimo schválenou pipeline?
• Pokusil se účet pouze pro čtení provést operace zápisu?
• Stal se neaktivní přihlašovací údaj znovu aktivním?
• Přistoupila dodavatelská integrace k datům mimo dohodnuté hodiny nebo objemy?

Když nastane upozornění ve 02:13, musíte odpovědět, jaká identita byla použita, jaký tajný údaj ji autentizoval, jaká přístupová práva byla uplatněna, jaká data nebo systémy byly dotčeny, zda byla aktivita očekávaná, který vlastník ji může ověřit a zda jsou splněny prahové hodnoty pro hlášení incidentu.

Pohled auditora: stejný proces, jiné otázky

Nejsilnější auditní pozice nezní „splňujeme všechno“. Zní: „Provozujeme jeden řízený proces, který vytváří důkazy pro více povinností.“ Různí auditoři budou tento proces prověřovat různě.

Napříč těmito pohledy se opakují předvídatelná zjištění: neexistuje jednotná evidence NHI, chybí vlastník strojových identit, tajné údaje jsou uloženy v kódu nebo dokumentaci, přihlašovací údaje jsou sdíleny napříč prostředími, chybí rotace nebo expirace, přihlašovací údaje spravované dodavatelem nejsou zahrnuty do přezkumů přístupových práv, monitorování pokrývá lidi, ale ne stroje, a provozní postupy pro incidenty ignorují únik tajných údajů.

Každé zjištění se přirozeně mapuje na opatření, politiky a šablony nápravy Clarysec. Ještě důležitější je, že každé lze převést na měřitelné důkazy v rámci ISMS.

Jak vám Clarysec pomůže připravit se na audit

Přístup Clarysec je praktický, protože začíná důkazy, které si auditoři vyžádají, a zpětně je převádí do kontrolních mechanismů, politik a provozních rutin.

V Zenith Blueprint, fáze Controls in Action, krok 19, poskytuje Clarysec přímé pokyny pro autentizaci mezi stroji:

Pro autentizaci mezi stroji, například servisní účty nebo volání API, musí být klíče, certifikáty a tokeny chráněny stejně důsledně. Nevkládejte přihlašovací údaje do kódu. Používejte systémy pro správu tajných údajů nebo trezory k jejich bezpečnému ukládání a rotaci.

Typický pracovní postup Clarysec pro strojové identity zahrnuje zjišťování NHI napříč cloudem, SaaS, CI/CD, repozitáři, trezory a databázemi, posouzení mezer v politikách vůči sadám politik Clarysec pro malé a střední podniky nebo podnikové prostředí, mapování posouzení a ošetření rizik podle ISO/IEC 27001:2022, aktualizace Prohlášení o použitelnosti, mapování důkazů pro NIS2, DORA, GDPR a NIST CSF, návrh registru NHI, sladění registru správy klíčů, skenování tajných údajů, procesy přezkumu přístupových práv, matice odpovědností za přihlašovací údaje dodavatelů, provozní postupy pro incidenty a auditní balíčky se snímky obrazovek, exporty, logy, schváleními a záznamy výjimek.

Pro malé a střední podniky je přístup přiměřený. Poskytovatel SaaS se 70 lidmi nepotřebuje stejný rozsah nástrojů jako globální banka, ale potřebuje vlastnictví, politiku, ošetření rizik a důkazy. Pro regulované finanční subjekty a poskytovatele ICT se stejný model škáluje do mapování kritických funkcí podle DORA, správy rizik třetích stran a testování odolnosti.

Pokud vás další audit čeká v roce 2026, nečekejte, až auditor objeví strojové identity za vás. Začněte jednou kritickou službou a položte si pět otázek:

1. Známe každý servisní účet, API klíč, token, certifikát a tajný údaj CI/CD používaný touto službou?
2. Má každá NHI určeného vlastníka, správce, účel a hodnocení rizika?
3. Jsou tajné údaje uložené v trezoru, rotované a chráněné před zdrojovým kódem, dokumenty, e-maily a uložením v prostém textu?
4. Jsou privilegované strojové identity přezkoumávány, monitorovány a omezeny tak, aby je nebylo možné používat interaktivně?
5. Dokážeme z jednoho řízeného procesu vytvořit důkazy pro ISO/IEC 27001:2022, NIS2, DORA a GDPR?

Použijte Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint ke strukturování cesty implementace ISMS. Použijte Zenith Controls: The Cross-Compliance Guide Zenith Controls k propojení opatření ISO/IEC 27002:2022 pro identitu, autentizaci, oprávnění, protokolování, kryptografii, bezpečný vývoj a dodavatele s regulačními důkazy. Použijte knihovnu politik Clarysec pro malé a střední podniky a podnikové prostředí, včetně Politika správy uživatelských účtů a oprávnění pro malé a střední podniky Politika správy uživatelských účtů a oprávnění pro malé a střední podniky, Politika kryptografických opatření Politika kryptografických opatření, Politika bezpečného vývoje Politika bezpečného vývoje a Politika požadavků na zabezpečení aplikací Politika požadavků na zabezpečení aplikací, abyste dobré úmysly převedli na vymahatelné požadavky.

Upozornění ve 02:13 se někde objeví. Otázkou je, zda vaše organizace dokáže na základě důkazů odpovědět, kdo držel klíč, co odemkl, proč existoval a jak rychle jej dokážete bezpečně zneškodnit.