Service account se stává aktérem change managementu CIO MAG

V sobotu ve 02:13 se změnila konfigurace clusteru, oprávnění k úložišti a DNS záznam. V auditním logu nebylo jméno člověka, ale účet deploy-prod. Change ticket odkazoval na standardní release. Teprve při vyšetřování se ukázalo, že stejnou identitu používají tři pipeline, integrační služba a jeden administrátorský skript.

Firma tedy dokázala říct, který účet změnu technicky provedl. Nedokázala ale spolehlivě doložit, která aplikace jej použila, kdo daný běh autorizoval, proč měla identita právě tato oprávnění a zda bylo možné její mandát okamžitě ukončit.

Service account bývá stále spravován jako credential: někdo jej založí, uloží secret a přidělí roli. V automatizovaném prostředí je však něčím víc. Je samostatným vykonavatelem změn. Může nasazovat artefakty, měnit IAM, DNS, feature flags, databázové schéma, cloudovou konfiguraci i data. Change management proto musí řídit nejen změnu samotnou, ale také strojovou identitu, která ji smí provést.

Service account není jen technický účet

V tomto článku používám pojem service account jako praktickou zkratku pro ne-lidskou neboli workload identity. Jednotlivé platformy používají rozdílné názvy: service principal, managed identity, IAM role, workload identity nebo service account. Společné je, že software získává identitu a s ní oprávnění jednat vůči dalším systémům.

Microsoft upozorňuje, že workload identities nemohou provádět vícefaktorové ověření a často pro ně neexistuje formální lifecycle. NIST zároveň staví zero trust pro cloud-native prostředí na identity-centric pravidlech pro uživatele i služby. Rozdíl proti člověku je praktický: zaměstnanec má manažera, pracovní vztah a offboarding. Service account může přežít projekt, vlastníka i aplikaci, pro kterou původně vznikl.

ROZHODOVACÍ PRAVIDLO
Každá machine identity, která může zapisovat do produkce, musí mít interního vlastníka, jediný popsaný účel, povolený rozsah, způsob expirace nebo pravidelné revize a ověřený postup okamžitého odebrání přístupu.

Otázka „kdo změnu udělal?“ už nestačí

U lidské změny se často předpokládá, že osoba v logu je současně původcem záměru, držitelem oprávnění i vykonavatelem. U automatizace jsou tyto role rozdělené. Jeden člověk změnu požaduje, jiný schválí pull request, workflow ji spustí, cloud vydá dočasný token a service account provede několik desítek API operací.

Vrstva odpovědnosti	Příklad	Co musí být dohledatelné
Obchodní mandát	Opravit zranitelnou komponentu nebo nasadit schválenou verzi.	Kdo cíl schválil, na jaký rozsah a s jakým přijatým rizikem.
Iniciátor běhu	Merge, release event, plánovač nebo ruční spuštění.	Který člověk či systém běh vyvolal a z jakého důvodu.
Workflow a artefakt	Konkrétní pipeline, commit, image a run ID.	Co přesně bylo ověřeno a které důkazy vznikly.
Machine identity	Service account, role nebo managed identity.	Jaký token použila, jak dlouho platil a která policy jej omezovala.
Vedlejší účinek	Změna konfigurace, dat, IAM, DNS nebo nasazení.	Co se v cílovém systému skutečně změnilo a zda byl výsledek zdravý.

Sdílený service account tento řetězec rozbíjí. Google výslovně upozorňuje, že auditní log může ukázat název účtu, ale nikoliv aplikaci, která jej použila; pokud jednu identitu sdílí více workloadů, nemusí být možné připsat aktivitu správnému systému. Více úzce vymezených identit proto může být bezpečnější než jeden „centrální“ účet s širokými právy.

Oprávnění není mandát ke změně

IAM role odpovídá na otázku, co může identita technicky provést. Change governance musí odpovědět na jinou otázku: co smí provést v tomto konkrétním běhu, v jakém prostředí, v jakém objemu a za jakých stop podmínek. Účet může mít z historických důvodů právo měnit DNS. To ale neznamená, že každá pipeline, která jej umí použít, získala autorizaci DNS skutečně změnit.

BEZPEČNOSTNÍ HRANICE
Autentizovaný service account není automaticky autorizovaná změna. Mandát musí být užší než maximální technické oprávnění a musí být vynutitelný politikou, ne pouze názvem pipeline nebo komentářem v ticketu.

Dlouhodobý klíč mění výjimku v trvalou schopnost

Statický secret nebo klíč je pohodlný, protože funguje dlouho a téměř odkudkoliv. Právě proto je nebezpečný. Bývá kopírován mezi nástroji, přežívá změny vlastníků a jeho skutečný počet uživatelů se obtížně zjišťuje. Rotace klíče sice mění credential, ale sama neřeší, kdo smí identitu používat a zda její původní účel ještě existuje.

AWS doporučuje workloadům používat dočasné credentials prostřednictvím rolí. Google preferuje krátkodobé tokeny a dedicated service accounts. Microsoft nabízí managed identities a workload identity federation bez správy statických secrets. GitHub Actions může přes OIDC získat token platný pouze pro konkrétní job a po jeho skončení automaticky expirující.

PRAKTICKÉ PRAVIDLO
Produkční pipeline nemá uchovávat dlouhodobý cloudový secret, pokud lze stejný přístup realizovat federací, managed identity nebo krátkodobým tokenem. Každá výjimka potřebuje vlastníka, důvod a datum ukončení.

Machine change contract: co musí být schváleno před během

Pro významné automatizované změny se mi osvědčuje oddělit identitu od jejího mandátu. Service account může existovat dlouhodobě, ale každý typ běhu musí mít strojově čitelný change contract. Nejde o další formulář. Jde o soubor podmínek, které pipeline, IAM a cílové prostředí skutečně vynutí.

Povinné pole	Co musí být určeno
Vlastník a sponzor	Technický vlastník identity, obchodní důvod změny a autorita, která mandát schválila.
Workload a prostředí	Konkrétní pipeline, aplikace, runner a prostředí, z nichž lze identitu použít.
Rozsah a zákaz	Povolené účty, subscription, projekty, namespaces, typy zdrojů a výslovně zakázané akce.
Spouštěč a approval	Událost, která smí běh zahájit, povinné review a hranice vyžadující nové lidské rozhodnutí.
Credential a životnost	Federace nebo role, maximální délka session, podmínky vydání a zákaz dalšího delegování.
Blast radius	Limit počtu objektů, souběhu, datového objemu, prostředí, nákladů a času.
Důkazy	Commit, artefakt, run ID, identita, session, API akce, policy výsledek a zdravotní signály.
Stop a ukončení	Automatické stop podmínky, kill switch, vlastník obnovy a datum revize či expirace kontraktu.

Auditní log není auditní stopa, pokud chybí důvod

Cloudové platformy umějí zaznamenat přihlášení service principals, použití service accounts i API volání. Azure má samostatné sign-in logy pro service principals a managed identities, Google poskytuje auditní záznamy pro správu a použití service accounts a AWS umožňuje do role session přenést source identity, která zůstává viditelná v CloudTrail.

Samotný technický log ale neřekne, proč byla změna legitimní. Kompletní stopa musí spojit nejméně: change nebo kampaň, schválený mandát, iniciátora, workflow run, artefakt, machine identity a session, provedené API operace, cílové objekty a ověřený výsledek. Bez této vazby organizace při incidentu ví, který účet jednal, ale neví, zda jednal oprávněně.

KONTROLNÍ VĚTA
„V logu je service account“ není odpověď na otázku odpovědnosti. Audit musí doložit, kdo účtu delegoval autoritu, pro který běh, v jakém rozsahu a s jakým výsledkem.

Životní cyklus machine identity nekončí rotací credentialu

Service account musí mít lifecycle stejně jako člověk: vznik, změnu role, používání, revizi, omezení a zánik. Spouštěčem revize není jen bezpečnostní incident. Může jím být přesun aplikace, změna vlastníka, ukončení repozitáře, nový deployment mechanismus, odchod dodavatele nebo fakt, že identita nebyla několik měsíců použita.

Událost	Povinná reakce	Důkaz ukončení
Vznik workloadu	Vytvořit dedikovanou identitu a nejmenší potřebný mandát.	Vlastník, účel, policy a expirace jsou evidované.
Změna rozsahu	Znovu posoudit oprávnění a change contract, nikoliv pouze přidat další roli.	Starý a nový rozsah jsou porovnatelné a schválené.
Změna vlastníka	Potvrdit, že nový vlastník rozumí použití a akceptuje odpovědnost.	Předání je zaznamenané, nikoliv pouze změněný kontakt.
Ukončení služby	Zakázat vydávání nových tokenů, odstranit role a zkontrolovat navázané delegace.	Identita, keys, trust vztahy a sessions již nejsou použitelné.
Dlouhá neaktivita	Pozastavit nebo odebrat oprávnění do nového potvrzení potřeby.	Last-used evidence a schválená výjimka, pokud identita zůstává.

Modelový příklad: jeden účet, šest systémů

V modelové firmě používaly tři produkční pipeline stejný účet automation-admin. Účet mohl nasazovat do Kubernetes, číst secrets, měnit DNS, spouštět databázové migrace a upravovat cloud IAM. Tým jej považoval za provozně praktický: při změně nástroje stačilo přenést jeden secret. Z pohledu auditu však nebylo možné rozlišit jednotlivé workloady a každý kompromitovaný runner získal celý rozsah oprávnění.

Náprava nevytvořila jeden lépe chráněný superúčet. Rozdělila autoritu. Každá pipeline dostala vlastní federovanou identitu, oddělenou pro test a produkci. DNS a IAM se přesunuly do samostatného workflow s novým approval bodem. Databázová migrace získala jinou roli než běžný deployment. Token se vydával pouze pro konkrétní run a log nesl identifikátor repozitáře, prostředí a změny.

Počet machine identities vzrostl. Provozní riziko kleslo, protože bylo možné přesně určit, která identita smí měnit který typ objektu, samostatně ji zastavit a rekonstruovat její skutečné použití. Cílem tedy není co nejméně účtů. Cílem je co nejméně nejasné a sdílené autority.

Co má sledovat vedení IT

• podíl produkčních machine identities s aktuálním vlastníkem, účelem a datem revize;

• podíl workloadů používajících federované nebo krátkodobé credentials místo statických keys;

• počet identit sdílených více aplikacemi, pipeline nebo prostředími;

• počet neaktivních, orphaned a default service accounts s ponechanými oprávněními;

• podíl změn s úplnou vazbou mandát; workflow; machine identity; API akce; výsledek;

• nejvyšší skutečný blast radius jednotlivé identity a počet oprávnění, která nikdy nepoužila;

• čas potřebný k zastavení workloadu, zablokování vydávání tokenů a odebrání produkčního přístupu.

Třicetidenní přechod od technických účtů k řízeným aktérům

Období	Práce	Výstup
1. týden	Zmapovat všechny machine identities s právem zápisu do produkce, jejich keys, role, vlastníky a poslední použití.	Inventář skutečných vykonavatelů změn.
2. týden	Označit shared účty, dlouhodobé secrets, orphaned identity a role s nevyužitými oprávněními.	Prioritizovaný risk backlog.
3. týden	Vybrat jednu produkční pipeline a zavést federaci, dedikovanou identitu, change contract a korelační ID.	Ověřený referenční vzor.
4. týden	Otestovat kill switch, auditní rekonstrukci a offboarding identity; nastavit povinnou expiraci výjimek.	Nová governance a měřitelné kontrolní body.

ZÁVĚR PRO VEDENÍ
Service account není pouze způsob přihlášení. Je to delegovaná change authority. Organizace proto nemá řídit jen to, zda se účet úspěšně autentizoval, ale také pod čím mandátem jednal, v jakých hranicích, jak dlouho jeho oprávnění platilo a zda lze každou změnu spojit s konkrétním rozhodnutím a výsledkem.