Infrastructure as Code popisuje záměr. Neprokazuje skutečný stav CIO MAG

Oficiální dokumentace Terraformu a CloudFormation počítá s driftem jako s běžným provozním stavem. Terraform porovnává konfiguraci, svůj state a skutečné vzdálené objekty. CloudFormation dokáže hledat rozdíly mezi očekávanými a aktuálními vlastnostmi podporovaných zdrojů. Oba mechanismy zároveň mají hranice.

CloudFormation například vyhodnocuje pouze podporované zdroje a vlastnosti. Výchozí hodnotu sleduje jen tehdy, pokud je explicitně uvedená v šabloně. Některé vztahy napříč stacky nebo obsah aplikačního kódu neumí přesně mapovat zpět. Výsledek bez nalezeného driftu tedy neznamená, že celé prostředí odpovídá zamýšlenému stavu.

Manažerské shrnutí

01Repozitář není inventář reality. Obsahuje deklaraci spravovaných prvků, nikoli automaticky všechny objekty, hodnoty a změny v prostředí.

02Drift detection má rozsah a slepá místa. Výsledek je platný pouze pro zdroje a vlastnosti, které nástroj umí načíst a porovnat.

03Každý rozdíl potřebuje rozhodnutí. Organizace musí změnu přijmout do kódu, vrátit prostředí k deklaraci nebo ji vyšetřit jako neoprávněný zásah.

Tři stavy musí být rozlišitelné

Infrastructure as Code pracuje nejméně se třemi obrazy. Konfigurace vyjadřuje zamýšlený stav. State nástroje zachycuje jeho znalost spravovaných objektů. Provider nebo zařízení obsahuje skutečný aktuální stav. Pro bezpečný plán musí být jasné, který rozdíl vznikl mimo workflow a který pouze odráží legitimní změnu výchozí hodnoty.

Nález	Možná příčina	Správná otázka
Objekt se liší od konfigurace	Ruční zásah, externí automatizace nebo incidentní změna	Má se změna vrátit, nebo převést do kanonického kódu?
State se liší od reality	Neúplný refresh, změněné oprávnění nebo chyba providera	Je porovnání úplné a používá správný účet i rozsah?
Nástroj hlásí shodu	Sledované hodnoty odpovídají	Které zdroje a vlastnosti nebyly vůbec kontrolované?
Plán navrhuje rozsáhlou destrukci	Špatný state, scope nebo identita	Je bezpečné pokračovat, nebo nejprve obnovit důvěryhodný obraz?

PROVOZNÍ PRAVIDLO

Každý produkční workspace musí mít pravidelné neakční porovnání reality, vlastníka nálezu a lhůtu pro rozhodnutí. Automatický návrat driftu bez klasifikace může odstranit legitimní nouzovou změnu.

Nouzová změna není selhání governance, pokud se vrátí do kanonické cesty

Během incidentu může být ruční zásah nejrychlejší bezpečnou volbou. Zakázat všechny zásahy mimo pipeline by mohlo prodloužit dopad. Problém vznikne tehdy, když změna zůstane pouze v produkci a další apply ji nečekaně odstraní, nebo když se z nouzové výjimky stane běžný paralelní způsob správy.

Dobrá provozní dohoda určuje, kdo smí break glass změnu provést, jak se auditně označí, kdy se propíše do kódu a jak se ověří její konečný stav. Cílem není předstírat, že realita se nikdy neodchýlí. Cílem je zajistit, aby každá odchylka měla dočasného vlastníka a jasný návrat do jedné kanonické cesty.

KONTROLNÍ MECHANISMUS

Spouštějte refresh only nebo ekvivalent s read only oprávněním a bez automatického apply. Report musí uvést spravované objekty, nepodporované typy, změněné vlastnosti a čas posledního úplného porovnání.

Modelový scénář z praxe: bezpečnostní pravidlo přežilo jen v cloudu

Modelový tým během incidentu ručně zpřísnil síťové pravidlo. Zásah byl správný a zastavil nežádoucí komunikaci. Ticket se však uzavřel bez změny šablony. O několik týdnů později běžné nasazení vrátilo pravidlo do původního stavu, protože plán byl vyhodnocen pouze jako očekávané sjednocení s repozitářem.

Příčinou nebyl nástroj, který udělal přesně to, co deklarace požadovala. Selhalo uzavření nouzové změny. Organizace doplnila automatické označení break glass zásahů, denní porovnání, vlastníka bezpečnostního rozdílu a pravidlo, že incident není administrativně uzavřen, dokud se přijatá změna neobjeví v kanonickém kódu nebo není řízeně vrácena.

POZNÁMKA Z PRAXE

Nejnebezpečnější drift není vždy ten, který plán ukáže červeně. Může to být zdroj mimo state, vlastnost nepodporovaná detekcí nebo legitimní ruční zásah, který nikdo nepřenesl do jediné pravdy.

Co nulový drift neprokazuje

Shoda deklarace a sledované reality neprokazuje bezpečnost, výkon ani správnost architektury. Chybné pravidlo může být dokonale konzistentní ve všech prostředích. Drift detection také neověří, zda aplikace službu používá správně nebo zda nedošlo ke změně dat a identity mimo spravovaný rozsah.

Naopak nalezený drift nemusí znamenat incident. Poskytovatel mohl doplnit výchozí hodnotu nebo legitimní automatizace upravila provozní parametr. Kontrola má dodat důkaz k rozhodnutí, nikoli automaticky přidělit vinu nebo bez posouzení přepsat realitu.

HRANICE DŮKAZU

Stav IN SYNC potvrzuje shodu podporovaných a explicitně sledovaných vlastností. Neprokazuje, že nebyly změněny nesledované zdroje, výchozí hodnoty nebo vztahy mimo rozsah stacku.

Kód je závazek, porovnání je důkaz

Governance Infrastructure as Code má rozlišit schválení změny, její provedení a průběžné ověření reality. Repozitář a review chrání záměr. Auditovaný apply chrání způsob provedení. Drift detection a inventář dokazují, že se skutečný stav později nevydal jinou cestou.

Nosná teze zní: deklarace bez pravidelného porovnání je pouze dobře verzovaný plán. Provozní důvěru vytváří až schopnost vysvětlit a uzavřít rozdíl mezi záměrem, stavem nástroje a skutečnou infrastrukturou.