Auditovatelnost by se neměla přidávat dodatečně
Složka, která dorazila příliš pozdě
Jednací místnost nesla obvyklé znaky institucionální vážnosti: skleněné stěny, kávovar, který se statečně tvářil jako tlaková nádoba, a na sdílené obrazovce složku s názvem evidence pack. Posuzovaný systém běžel devět měsíců. Směroval interní případy, doporučoval další kroky, některé z nich postupoval specialistům a jiné tiše zamítal, protože tak nastavené prahové hodnoty určovaly. Nikdo v místnosti systém při zadávání zakázky neoznačil za vysoce rizikový. Byl to nástroj pro zvýšení produktivity, což je označení, které organizace používají pro rozhodovací infrastrukturu, dokud se někdo nezeptá, koho se to dotklo.
Auditor položil drobnou otázku. Která verze politiky byla v tomto případě aktivní ve chvíli, kdy bylo doporučení vytvořeno. Produktový vlastník se podíval na architekta. Architekt se podíval na vedoucího dat. Vedoucí dat otevřel dashboard, pak export logů, pak ticket. Jeden vývojář si vzpomněl, že verze politik se v první verzi ukládaly do proměnné prostředí a po lednové migraci do databázové tabulky. Někdo řekl, že změna byla pravděpodobně neškodná. To není věta, která by auditora uklidnila.
Nic nebylo postaveno se zlým úmyslem. Tým měl logy, monitoring, řízení přístupu, zálohy, incidentové tickety a interní wiki s dostatkem stránek na to, aby poškodila tiskárnu. Ale důkazy nebyly vlastností systému. Byly výsledkem rekonstrukce provedené dodatečně lidmi, kteří si nasazení ještě pamatovali. To není auditovatelnost. To je orální historie s časovými razítky.
Auditovatelnost by se neměla přidávat později, protože později je přesně ta chvíle, kdy se z paměti stává politická záležitost. Lidé jsou nervózní. Systém se změnil. Dodavatelé se vystřídali. Dashboardy byly přepracovány. Jediný inženýr, který rozuměl původnímu importu dat, má dnes jinou pracovní pozici a o té době mluví s klidem člověka, který přežil havárii vodovodu. Pokud záznam nevznikl ve chvíli, kdy se práce dělala, bude pozdější vyprávění vždy obsahovat více interpretace než důkazů.
Auditovatelnost je vlastnost návrhu
Mnoho týmů považuje auditovatelnost za dokumentaci. Představují si ji jako soubor diagramů, kontrol, schválení, tlačítek pro export a prohlášení o politikách, které lze sestavit, jakmile se systém blíží vydání. Tento pohled je lákavý, protože dokumentace se zdá levnější než návrh. Projekt může pokračovat, zatímco governance zdvořile čeká na chodbě se složkou. Účet dorazí později, s úroky.
Auditovatelnost má blíže k trvanlivosti než k dokumentaci. Trvanlivý systém se nestane trvanlivým proto, že někdo napíše zprávu, že střecha by pravděpodobně přežila déšť. Střecha buď vodu odvádí, nebo ne. Auditovatelný systém buď uchovává fakta potřebná k prozkoumání svého chování, nebo ne. Fakta mohou být nudná: verze, zdroj, časové razítko, aktér, pravidlo, práh, výjimka, schválení, identifikátor modelu, šablona promptu, rozsah dat, stav uchovávání. Nuda je v pořádku. Most také drží pohromadě nudné části. Ozdobné lampy nejsou nosnou konstrukcí.
Obtížné je, že auditní fakta musí být zachycena na stejné úrovni, na které se rozhoduje. Pokud pracovní postup používá pravidlo zásad, verze pravidla patří do události. Pokud je výstup modelu přijat do spisu případu, verze modelu, spolehlivost, rozsah zdroje a pravidlo přijetí patří do záznamu. Pokud člověk přepíše doporučení, důvod přepsání patří k akci, ne do zápisu ze schůzky o dva týdny později. Systém by neměl vyžadovat historika, aby odvozoval, co stroj již v době běhu věděl.
Proto auditovatelnost není totéž co logování. Logy jsou užitečné, ale jejich první věrnost obvykle patří provozu. Vysvětlují selhání, časy, opakování, výjimky a výkon. Auditovatelnost klade jinou sadu otázek: jaká autorita byla použita, jaké důkazy byly zváženy, jaký stav se změnil, kdo nebo co to způsobil, a lze sekvenci ověřit bez důvěry v aktuální službu. Logy tuto práci mohou podporovat. Málokdy ji zvládnou samy.
Prvním rozhodnutím je, co se počítá
Než může být systém auditovatelný, musí se organizace rozhodnout, co se počítá jako auditovatelná událost. Zní to administrativně, ale zde začíná skutečná architektura. Pokud je každé kliknutí událostí, záznam se stane skládkou. Pokud jsou událostmi pouze konečné výsledky, záznam se stane kouzelnickým trikem. Užitečný střed je zachytit okamžiky, kdy si autorita, důkazy nebo stav mění ruce.
Příjem případu je takový okamžik. Zdrojový dokument vstupující do rozsahu je další. Doporučení modelu je jedním, pokud může ovlivnit práci. Spuštění brány zásad je jedním. Lidské schválení je jedním. Odmítnutí, eskalace, výjimka, oprava dat, změna uchovávání, žádost o výmaz a odvolání jsou všichni kandidáti. Smyslem není uchovat každý dech systému. Smyslem je uchovat spoje, kde by se pozdější recenzent oprávněně zeptal: proč se systém přesunul odtud tam.
Tento výběr musí být explicitní. Jinak tým během přezkumu zjistí, že důležitá událost žila ve stínu mezi dvěma komponentami. Frontend ví, že uživatel viděl varování. Backend ví, že případ změnil stav. Služba modelu ví, že vrátila skóre. Nástroj pracovního postupu ví, že byla zvolena větev. Žádný jednotlivý záznam neříká, že varování, skóre, pravidlo a větev patřily ke stejnému rozhodnutí. Každý má kus vázy. Stůl je stále mokrý.
Jakmile je sada událostí pojmenována, mohou inženýři navrhnout kontrakty kolem ní. Každá událost může mít povinná pole. Každé pole může mít vlastníka. Každá změna schématu může být verzovaná. Každé pravidlo uchovávání může být vázáno na právní a provozní potřebu. Toto není papírování sedící vedle systému. Je to součást hranice systému. Záznam se stává produktem pracovního postupu, ne omluvou napsanou pracovním postupem po obědě.
Čas není dekorace
Auditní práce se časem zabývá z dobrého důvodu. Rozhodnutí učiněné před změnou pravidla není totéž co rozhodnutí učiněné po ní. Výstup modelu vytvořený před opravou dat není totéž co výstup vytvořený po ní. Případ eskalovaný po termínu se liší od případu eskalovaného před termínem. Čas není metadata rozsypaná na události. Je součástí významu události.
Distribuované systémy dělají čas nepohodlným. Hodiny se rozcházejí. Fronty mění pořadí. Dochází k opakování. Pracovníci zpracovávají zprávy se zpožděním. Dávky se načítají v noci úlohami, které byly v roce 2021 označeny jako dočasné a nyní jsou kulturně trvalé. Pokud návrh auditu předpokládá jedinou úhlednou časovou osu, první incident ho poučí. To poučení obvykle probíhá v tabulce, což je drahá učebna.
Auditovatelný návrh rozlišuje čas události, čas zpracování, čas účinnosti a čas kontroly tam, kde rozdíl záleží. Čas události říká, kdy se věc stala v obchodním procesu. Čas zpracování říká, kdy ji komponenta zpracovala. Čas účinnosti říká, kdy se pravidlo nebo stav staly platnými. Čas kontroly říká, kdy je někdo později zkontroloval nebo opravil. Tato rozlišení mohou připadat úzkostlivá, dokud jeden případ nepřekročí půlnoc, jedno pravidlo se nezmění v 09:00 a jedna fronta se nevyprázdní pomalu, protože někdo změnil velikost fondu pracovníků s jistotou a bez důkazů.
Stejná péče platí pro identitu. Aktérem může být osoba, služba, agent, plánovaná úloha, delegovaný uživatel nebo externí systém. Systém by měl říci, kdo to je. Neměl by se schovávat za administrátora uživatele, protože tam žije integrační účet. Když je autorita delegována, delegace by měla být viditelná. Když služba jedná automaticky, měly by být viditelné vlastnická služba a pravidlo. Auditovatelnost vyžaduje pojmenovanou odpovědnost, i když jméno není lidská bytost.
Rekonstrukce není přehrávání
Když týmy přidávají auditovatelnost pozdě, často se spokojí s rekonstrukcí. Shromažďují protokoly, snímky databází, tickety, zprávy z chatu a poznámky k vydání. Sestaví věrohodnou časovou osu. Někdy je časová osa správná. Někdy je to velmi úhledná fikce s upřímnými autory. Problém není v tom, že lidé lžou. Problém je v tom, že rekonstrukce žádá lidi, aby vyplnili mezery pod tlakem, a instituce jsou mimořádně dobré v tom, aby mezery vypadaly jako záměrné, jakmile začne porada vedení.
Replay je jiný standard. Replay znamená, že si systém uchoval dostatek strukturované historie, aby bylo možné celou sekvenci znovu projít. Neznamená to, že je nutné znovu volat původní model, ani že lze obnovit každou externí závislost. Znamená to, že ze záznamu lze vyčíst, jaký vstup byl přijat, která verze pravidla se použila, jaký výstup byl vytvořen, jaká akce byla provedena a jaký stav z toho vznikl. Recenzent by měl být schopen prozkoumat celý řetězec, aniž by se musel spoléhat na to, že mu současná aplikace podá lichotivé vyprávění o svém mladším já.
Replay mění chování při vývoji. Pokud tým ví, že rozhodnutí mohou být přehrávána, je těžší schovávat politiku do cest v kódu s názvy jako helper2. Je těžší nechat prahy volně plavat, aniž by bylo zaznamenáno, kdo je změnil. Je těžší zacházet se šablonami promptů jako s lokálními řemeslnými výrobky na notebooku. Replay vyžaduje, aby každá důsledná akce nesla svůj vlastní kontext. To je otravné podobně jako bezpečnostní pásy: většinou jen před nehodou.
Replay také umožňuje, aby se správa stala rutinou. Místo čekání na incident mohou týmy vzorkovat případy, zkoumat řetězce, porovnávat výsledky napříč verzemi politik a odhalovat chybějící záznamy. Auditní stopa se stává něčím, co organizace používá, ne něčím, co vytváří jen tehdy, když je zahnána do kouta. Tento rozdíl je důležitý. Kontroly, které se používají jen ve strachu, mají ve zvyku být jen dekorativní.
Cena za přidání později
Pozdní auditovatelnost má velmi specifický pach. Pach nových tabulek s názvy jako audit_log_final. Pach datového exportu, který má většinu sloupců, ale ne ty, které souvisejí s danou otázkou. Pach konzultanta, který se ptá, zda existuje zdroj pravdy, a dostane prohlídku pěti systémů. Pach, především, zpětného odvozování záměru z vedlejších účinků.
Přímé náklady jsou čas na vývoj. Týmy musí identifikovat, kde k rozhodnutím došlo, přidat zachytávání událostí, doplnit historické záznamy, zalepit mezery, zdokumentovat předpoklady a vytvořit exportní rozhraní. Tato práce obvykle přichází ve chvíli, kdy systém už nese uživatele, incidenty, požadavky na funkce a očekávání. Nepřímé náklady jsou horší: klesá důvěra. Pokud organizace nedokáže odpovědět na základní otázky o vlastním systému, je každá pozdější odpověď přijímána s podezřením, i ta správná.
Existuje také návrhová cena. Jakmile je systém postaven bez auditovatelnosti, jeho hranice nemusí odpovídat potřebám důkazů. Rozhodnutí může být rozděleno mezi komponenty. Stav může být přepsán místo toho, aby byl připojen. Důvody mohou být počítány pro zobrazení, ale neukládány. Vstupy modelu mohou být transformovány a zahozeny. Lidské zásahy mohou žít v komentářích. Dodatečné zavádění auditovatelnosti se pak stává méně jako přidání okna a více jako zjištění, že zeď je nosná.
Náklad není pouze technický. Pozdní auditovatelnost vytváří politické spory o tom, co se skutečně stalo. Lidé brání své týmy. Dodavatelé brání svá rozhraní. Manažeři brání rozhodnutí o uvedení na trh. Každý se stává amatérským filozofem kauzality. To je pochopitelné a většinou zbytečné. Dobrý záznam snižuje potřebu pravdy řízené osobností. Umožňuje instituci vést spory o politice a zlepšování místo sporů o tom, zda minulost existuje.
Dobré záznamy nejsou divadlo dohledu
Existuje oprávněný strach, že se auditovatelnost stane dohledem. Některé organizace uslyší zaznamenávejte vše a chovají se, jako by každé lidské zaváhání mělo mít časové razítko. To není auditovatelnost. To je institucionální úzkost s připojeným úložištěm. Dobrý návrh auditu je selektivní, přiměřený a vázaný na zásadní změny. Zaznamenává oprávnění a stav, ne soukromý šum.
Pro zaměstnance na tomto rozlišení záleží. Operátor, který schvaluje výjimku, by měl očekávat, že schválení bude zaznamenáno. Neměl by očekávat, že se každý pohyb kurzoru stane součástí trvalého morálního dramatu. Specialista, který přepíše doporučení modelu, by měl zanechat kód důvodu a poznámku, když rozhodnutí ovlivní případ. Neměl by být trestán za nesouhlas s automatizací, která byla od počátku nejistá. Auditovatelnost by měla zviditelnit profesionální úsudek, ne učinit profesionály nesmělými.
Pro občany, zákazníky, pacienty nebo studenty by auditovatelnost měla podporovat práva. Měla by umožnit vysvětlit rozhodnutí, opravit špatná data, napadnout výsledek, prokázat výmaz nebo ukázat, že zdroj nebyl použit. Záznam, který chrání pouze instituci, je neúplný. Stopa auditu by neměla být jednosměrné zrcadlo. Pokud systém ovlivňuje lidi, měl by záznam pomáhat odpovídat i na jejich oprávněné otázky.
Zde se setkávají minimalizace dat a auditovatelnost. Odpovědí není uchovávat vše navždy. Odpovědí je uchovávat správná fakta po správnou dobu, s jasným účelem, pravidly přístupu a logikou výmazu nebo uchování. Řídký, dobře strukturovaný záznam je často ohleduplnější a užitečnější než obrovská hromada zachycených výfukových plynů. Hromada se zdá bezpečná, dokud se někdo nezeptá, co v ní je. Pak se stane závazkem s vyhledáváním.
Registr rizik by měl komunikovat se schématem událostí
Registr rizik často žije v dokumentech správy, zatímco schémata událostí žijí v inženýrských repozitářích. Toto oddělení je pohodlné a nebezpečné. Registr rizik říká, že existuje riziko neoprávněné eskalace. Schéma událostí by proto mělo zaznamenávat, kdo eskaloval, na základě jakého oprávnění, z jakého stavu, do jakého stavu a zda byla eskalace automatická nebo ruční. Pokud schéma tyto skutečnosti nezachycuje, je kontrola aspirační. Aspirace jsou levnější než kontroly, což vysvětluje jejich popularitu.
Totéž platí pro riziko modelu. Pokud registr říká, že doporučení s nízkou spolehlivostí musí být přezkoumána, měl by systém zaznamenávat spolehlivost, práh, požadavek na přezkum, přezkoumávající osobu, výsledek a důvod uvolnění nebo odmítnutí. Pokud registr říká, že rozsah zdrojů je důležitý, měly by události zaznamenávat rozsah zdrojů. Pokud je uchování rizikem, měly by události zaznamenávat změny stavu uchování. Registr rizik by neměl být prózou vznášející se nad softwarem. Měl by být souborem tvrzení, která může runtime pomoci ověřit.
To neznamená, že se každý požadavek governance okamžitě stane kódem. Některé kontroly jsou lidské, smluvní nebo organizační. Ale i lidské kontroly potřebují důkazy. Ruční přezkum může stále vytvořit záznam. Smluvní povinnost může stále odpovídat požadované atestaci. Dodavatelský proces může být stále reprezentován přijatou událostí, podepsanou zprávou nebo stavem chybějícího důkazu. Jde o to propojit jazyk rizik s jazykem důkazů dříve, než systém začne vytvářet důsledky.
Tichým přínosem je lepší konverzace. Inženýři přestanou vnímat governance jako opožděné kárání. Týmy governance přestanou vnímat inženýrství jako festival okrajových případů. Obě strany se mohou dívat na stejné schéma událostí a ptát se, zda nese fakta potřebná ke zvládnutí rizika. To je méně efektní než workshop o strategii umělé inteligence. Je to také méně pravděpodobné, že vznikne PDF, které nikdo nedokáže uvést do praxe.
Auditovatelnost mění konverzaci o vývoji
Když je auditovatelnost přítomna od začátku, designové přezkumy jsou konkrétnější. Tým se neptá jen na to, zda funkce funguje. Ptá se, jaký záznam funkce zanechává. Ptá se, kdo může záznam prohlížet, jak dlouho žije, co lze opravit, co se nikdy nesmí přepsat a na jakou budoucí otázku by měl umět odpovědět. Tyto otázky funkci zlepšují, protože odhalují skrytý stav a nejasnou autoritu.
Změní se také nákup. Místo otázky dodavatelům, zda podporují auditní protokoly, na kterou téměř každý odpoví nadšeným ano, může organizace požadovat konkrétní schopnosti v oblasti důkazů. Lze exportovat verze politik spolu s každým rozhodnutím. Lze zahrnout identifikátory modelů a rozsahy zdrojů. Lze odlišit lidské zásahy od automatizovaných akcí. Lze záznamy uchovávat, mazat, podepisovat nebo přehrávat podle našich pravidel. Můžeme prozkoumat stopu, aniž bychom platili za hrdinské profesionální služby. Poslední bod je často místem, kde se místnost stává poučnou.
Změní se také provoz. Reakce na incidenty je méně spekulativní. Tým může identifikovat dotčené případy, porovnat je se známými verzemi politik, najít chybějící záznamy a ukázat cestu od signálu k akci. Práce na shodě je méně sezónní. Zlepšování produktu je upřímnější, protože tým vidí nejen to, co systém udělal, ale za jakých podmínek to udělal. Auditovatelnost není brzdou dodávání. Je jednou z věcí, které brání tomu, aby se dodávání stalo budoucím archeologickým výzkumem.
Nic z toho nedělá systém dokonalým. Auditovatelný systém může stále dělat špatná rozhodnutí. Může stále zakotvovat špatnou politiku, používat slabá data nebo být provozován lidmi, kteří mají velmi lidský den. Auditovatelnost nezaručuje moudrost. Zaručuje, že instituce má větší šanci vidět, co se stalo, poučit se z toho a dokázat, že si odpověď jednoduše nevymyslela dodatečně.
Poučení
Zásadní chybou je domněnka, že auditovatelnost patří na konec, protože audity probíhají na konci. Není tomu tak. Audity probíhají po důsledcích, ale auditovatelnost musí existovat před důsledky. Záznam se musí narodit společně s akcí. Událost musí nést svůj kontext, dokud je kontext stále pravdivý. Systém musí zachovat rozdíl mezi faktem, odvozením, politikou, přepsáním a opravou.
Toto není výzva k těžkým procesům kolem každého malého nástroje. Je to výzva k proporcionalitě. Čím více systém mění práva, přístup, peníze, bezpečnost, způsobilost, pracovní zátěž nebo institucionální paměť, tím více musí zanechávat strukturované důkazy. Začněte u hraničních případů s důsledky. Pojmenujte události. Verzujte pravidla. Uchovávejte čas a identitu. Provádějte opravy aditivně. Testujte přehrání, než do místnosti vstoupí strach.
Na té disciplíně je něco téměř komického. Budoucnost důvěryhodné automatizace závisí méně na velkolepé inteligenci než na zapamatování si, které pravidlo se spustilo ve vlhkém únorovém dni. Ale vážné instituce jsou postaveny na takové paměti. Nedůvěřují systémům proto, že systémy znějí sebejistě. Důvěřují jim proto, že je lze zkontrolovat, když sebejistota už nestačí.
Takže přidávejte důkazy, dokud je práce stále obyčejná. Před oslavou spuštění, před incidentem, před migrací, než tým zapomene, proč bylo to pole nepovinné. Později přijde. Později vždy přijde, s složkou nazvanou balíček důkazů a otázkou, která si zaslouží lepší odpověď než pravděpodobně.