Automatizace
nesmí zjednodušit
i bezpečnost.

Z čeho vycházím: V projektech s přihlášeným prohlížečem, externími API a plánovanými operacemi řeším oddělení tajných údajů, limity, historii a místa, kde je nutné ruční potvrzení.

Tajný údaj není konfigurace jako každá jiná

Tokeny, hesla, cookies a session data nepatří do repozitáře, screenshotu ani běžného logu. Aplikace je potřebuje načíst z bezpečně spravovaného prostředí a měla by mít jen taková oprávnění, která skutečně vyžaduje.

Pokud nástroj používá přihlášenou relaci prohlížeče, je potřeba řešit také její životnost, odhlášení a možnost bezpečného obnovení.

Oprávnění omezují dopad chyby

Automatizace by neměla mít větší pravomoc jen proto, že je to pohodlnější. U API používám oddělené klíče podle prostředí a operace, limity částek nebo počtu požadavků a pokud možno i povolené zdroje.

U desktopového nástroje navíc jasně odděluji lokální nastavení, data uživatele a tajné hodnoty, které nemají být součástí exportu ani diagnostiky.

Log má vysvětlit, ne prozradit

Dobrá diagnostika dokáže říct, která úloha selhala a na jakém kroku. Nemusí kvůli tomu ukládat celý request, odpověď externí služby nebo hodnotu tokenu.

• identifikátor úlohy místo citlivého obsahu,
• typ operace a výsledek validace,
• čas a bezpečný popis chyby,
• počet pokusů a předání člověku.

Citlivé operace potřebují brzdu

U plateb, nákupů, mazání nebo změny oprávnění není cílem odstranit člověka za každou cenu. Smysl může mít automatická příprava, kontrola podmínek a ruční potvrzení posledního kroku.

Součástí návrhu je také ochrana proti duplicitě, zkušební běh, limity a evidence toho, co už bylo provedeno.

Co proberu s klientem před spuštěním

Před nasazením potřebuji vědět, kdo smí automatizaci spustit, co se stane při ztrátě přístupu, jak se token zneplatní a kdo řeší bezpečnostní incident. Pokud tyto odpovědi neexistují, je to riziko projektu, ne detail k doplnění později.