Účty, hesla a oprávnění pro softwarového robota
Softwarový robot se přihlašuje do e-mailu, portálu, účetního systému nebo databáze podobně jako člověk, ale často pracuje bez přímého dohledu a mimo pracovní dobu. Pokud používá účet kolegy nebo heslo zapsané ve skriptu, při incidentu se těžko určuje, kdo provedl konkrétní změnu a kde všude je potřeba přístup odebrat. Bezpečný návrh proto začíná identitou a oprávněními ještě před automatizací prvního kliknutí.
Sdílený lidský účet zakrývá odpovědnost
Robot spuštěný pod účtem účetní zdědí všechna její oprávnění, přestože potřebuje pouze přečíst jednu schránku a zapsat schválené faktury. Když kolegyně změní heslo nebo odejde z firmy, automatizace přestane fungovat. V logách navíc vypadají ruční i automatické kroky jako aktivita téže osoby.
Opačným extrémem je jeden technický účet pro všechny roboty. Kompromitované heslo pak otevře více systémů a odebrání přístupu zastaví nesouvisející procesy. Vhodný model závisí na možnostech cílových aplikací, ale cíl zůstává stejný: samostatně identifikovat automatizaci, omezit její dosah a dokázat přístup rychle zrušit.
Realistický příklad: faktura z e-mailu do účetního systému
Představme si robota, který sleduje vyhrazenou schránku, zkontroluje základní údaje v přijaté faktuře, uloží dokument do složky procesu a v účetním systému vytvoří návrh záznamu. Číslo návrhu vrátí do pracovního seznamu, kde fakturu posoudí člověk. Robot nemění dodavatele, neschvaluje platbu a neposílá peníze; tato rozhodnutí zůstávají mimo jeho roli.
Schránku proto čte identita omezená na jedinou adresu bez práva odesílat poštu. V úložišti může zapisovat pouze do složky procesu. V účetním systému vytvoří návrh a přečte jeho stav, ale nemá roli pro správu dodavatelů, schválení či platbu. Plánovač smí při běhu načíst potřebné tajemství, ne však spravovat celý trezor. Stejný identifikátor běhu se zapíše do logu plánovače i k návrhu faktury.
Pokud chybí povinný údaj, dodavatel není v povoleném seznamu nebo částka překročí dohodnutou hranici, robot položku přesune do fronty ke kontrole. Nežádá si širší oprávnění a nepokračuje pod účtem zaměstnance. Právě takový chybný případ ukáže, zda návrh identity funguje také mimo ideální scénář.
1. Přidělte robotovi samostatnou identitu
Pokud systém podporuje servisní účet, aplikační identitu, spravovanou identitu nebo OAuth klienta, použijte mechanismus určený pro neinteraktivní přístup. U staršího portálu může být nutný vyhrazený uživatelský účet pojmenovaný podle procesu. Nemá však patřit konkrétnímu zaměstnanci ani se používat pro běžnou lidskou práci.
U identity evidujte vlastníka procesu, technického správce, účel, prostředí a systémy, ke kterým přistupuje. Produkce a testovací prostředí mají mít oddělené identity a tajemství. Pokud platforma samostatné účty neumožňuje, omezení zdokumentujte a dohodněte náhradní kontroly; automatizace není důvodem obcházet pravidla autentizace dodavatele.
Vícefaktorové ověření (MFA) nelze bezpečně „vyřešit“ sdílením telefonu nebo automatickým potvrzováním každé výzvy. Vhodnější je platformou podporovaná aplikační autentizace nebo výslovně schválená politika pro konkrétní technickou identitu. Konkrétní řešení musí posoudit správce identity a vlastník cílového systému.
2. Udělte pouze oprávnění potřebná pro úlohu
Princip nejmenších oprávnění znamená, že identita dostane pouze zdroje a operace potřebné pro přidělenou úlohu. Robot, který stahuje přílohy z jedné schránky, nemusí číst osobní poštu ani odesílat zprávy za celou firmu. Robot zapisující faktury nemusí měnit dodavatele nebo schvalovat platby, pokud to není součástí procesu.
Oprávnění navrhněte po jednotlivých krocích: čtení vstupu, vytvoření záznamu, úprava konkrétního stavu a uložení výstupu. Rizikové operace, například platba, mazání nebo hromadná změna, mohou zůstat pod lidským schválením. Postup při běžných i chybných vstupech rozšiřuje článek Co se stane, když softwarový robot narazí na chybu.
Přístupy pravidelně porovnávejte se skutečným procesem. Oprávnění potřebné během zavádění nemusí zůstat potřebné po stabilizaci a nový krok robota se nemá potichu spoléhat na náhodně dostupnou administrátorskou roli.
Jak vybrat typ identity a rozsah oddělení
Pokud cíl nabízí podporované API a aplikační identitu, bývá vhodnější než simulování lidského přihlášení. Portál dostupný pouze přes uživatelské rozhraní může vyžadovat vyhrazený uživatelský účet. Volba se má opírat o podporované možnosti systému, způsob revokace a auditní stopu, ne o to, které přihlášení bylo nejrychlejší zapojit do skriptu.
Produkci vždy oddělte od testu. Samostatné identity pro dva procesy dávají smysl zejména tehdy, když mají jiného vlastníka, odlišná oprávnění nebo se jeden musí dát zastavit bez výpadku druhého. Jeden globální účet zbytečně zvětšuje dosah incidentu; opačný extrém s množstvím téměř stejných účtů zase komplikuje vlastnictví a revokaci. Rozhodnutí proto zdokumentujte u každé identity spolu s vlastníkem, rozsahem a způsobem zrušení.
3. Hesla a tokeny držte mimo kód
Heslo, API klíč, klientský secret nebo certifikát nepatří do skriptu, repozitáře, běžného konfiguračního souboru ani výpisu z běhu. Uložte jej do nástroje pro správu tajemství nebo schváleného trezoru a robotovi jej zpřístupněte až při spuštění. Přístup k tajemství má být oddělen od možnosti měnit kód robota, pokud to prostředí umožňuje.
Výpisy musí citlivé hodnoty maskovat. Nestačí skrýt jen proměnnou PASSWORD: token se může objevit v URL, hlavičce požadavku, chybové zprávě nebo snímku obrazovky. Současně je potřeba vědět, kdo tajemství načetl, změnil nebo zrušil, aniž by se jeho samotná hodnota uložila do auditního logu. Praktické zásady životního cyklu, auditování a rotace shrnuje OWASP Secrets Management Cheat Sheet.
Rotace není pouze naplánovaná změna hesla. Potřebujete znát všechny konzumenty, bezpečně zavést novou hodnotu, ověřit běh a následně zneplatnit starou. Krátkodobá dynamická pověření mohou být vhodnější než dlouhodobé heslo, pokud je cílový systém a provoz podporují. Frekvence i postup rotace se proto určují podle typu tajemství, rizika a možností konkrétní platformy.
4. Propojte auditní stopu napříč systémy
Užitečný záznam odpoví, který robot a verze procesu se spustily, kdo nebo co běh vyvolalo, jaké obchodní položky zpracovaly a které operace uspěly nebo selhaly. Jedinečný identifikátor běhu propojí log plánovače, přihlášení technické identity a záznam v cílové aplikaci.
Auditní log nemá kopírovat celé faktury ani tajemství. Uchovává potřebné identifikátory, výsledky a čas podle interních pravidel, přičemž přístup k logům je rovněž omezený. Neobvyklé přihlášení, použití mimo plánovaný čas nebo opakované zamítnutí oprávnění může vyvolat upozornění.
5. Připravte nouzový postup a odebrání přístupu
Pro výpadek trezoru nebo identity může existovat nouzový postup „break-glass“. Není to druhé heslo vložené v konfiguračním souboru ani běžný fallback při každém selhání. Nouzový přístup má mít určené schvalovatele, bezpečné oddělené uložení, upozornění při použití a následnou kontrolu a rotaci. Přesná implementace závisí na platformě identity a pravidlech organizace.
Stejně důležitá je revokace. Při ukončení procesu, podezření na únik nebo změně dodavatele musí být jasné, kdo zastaví plánovač, zruší tokeny a účty, odebere role a ověří, že robot již nepřistupuje. Otestovaný „kill switch“ omezí dobu, po kterou může chybný nebo kompromitovaný proces pokračovat.
Jak návrh ověřit před produkčním spuštěním
Začněte běžným testovacím případem s minimální sadou oprávnění a uložte důkaz, že robot přečetl správný vstup, vytvořil pouze návrh a zapsal identifikátor běhu. Potom cíleně zkuste zakázanou operaci, například změnu dodavatele, smazání záznamu nebo schválení platby. Očekávaným výsledkem je zamítnutí v cílovém systému a srozumitelný záznam v logu, ne úspěch díky širší roli.
Samostatně simulujte chybějící, expirované a odebrané tajemství. Robot má skončit řízenou chybou bez vypsání hodnoty do logu, snímku obrazovky či přílohy incidentu. Při zkoušce rotace zpřístupněte novou hodnotu, ověřte jeden běh a teprve poté zneplatněte starou; následný pokus se starým pověřením musí selhat. Tím se prověří postup i seznam skutečných konzumentů tajemství.
Nakonec propojte záznam plánovače, načtení tajemství a operaci v cílové aplikaci pomocí identifikátoru běhu. Aktivujte kill switch a ověřte, že se další běh nespustí nebo se již nepřihlásí, nezůstane rozpracovaný v nejasném stavu a odpovědný tým dostane upozornění. Obnovení přístupu má vyžadovat vědomé rozhodnutí určeného vlastníka. K protokolu uložte datum, prostředí, testované role, výsledky negativních scénářů a osobu, která je zkontrolovala; samotný seznam nakonfigurovaných práv není důkazem, že omezení fungují.
Hranice tohoto návrhu
Tyto kroky pomáhají bezpečně navrhnout provoz robota, ale nejsou penetračním testem, bezpečnostním auditem ani posouzením souladu. Citlivé systémy, platby a regulované údaje mohou vyžadovat samostatné posouzení bezpečnostním, právním nebo compliance týmem.
Co tím získáte
Samostatná identita a auditní stopa zlepší dohledatelnost každého běhu. Minimální oprávnění a oddělená tajemství zmenší rozsah následků při chybě nebo úniku. Plán rotace a revokace zároveň umožní měnit přístupy bez hledání hesel ve skriptech a bez odstavení nesouvisejících robotů.
Další krok
Před pilotem sestavte tabulku identit: proces, účet, vlastník, cílový systém, potřebné operace, místo uložení tajemství a způsob zrušení. Na jednom testovacím běhu ověřte minimální oprávnění, maskování logů, rotaci a kill switch. Teprve poté povolte plánované spouštění v produkci.