Logování je místo, kde data unikají ze systémů

Jsem přesvědčen, že většina dobře navržených systémů zvládá osobní údaje v primární vrstvě přiměřeně dobře. Záznamy žijí v definovaných tabulkách, řízených schématy, podléhajících logice uchovávání, která odráží skutečná obchodní rozhodnutí. Můžete je dotazovat, mazat z nich a uvažovat o nich.

Logování však většinu z toho ruší, a to nikoli z nedbalosti, ale způsobem, jakým jsou systémy pro pozorovatelnost (observability) postaveny a jaká výchozí nastavení dodávají. V okamžiku, kdy se problém objeví, data již byla někde, kde jste je nechtěli.

Jak začíná druhý životní cyklus

Když požadavek dorazí, instinktem je zalogovat dostatek kontextu pro pozdější ladění. Začnete s ID požadavků a stavovými kódy. Přidáte identifikátory uživatelů, protože usnadňují sledování případů podpory. Zahrnete části datové části požadavku, protože pomáhají reprodukovat okrajové případy. Spustí se chyba a s ní jde plný kontext – tj. cokoliv bylo v danou chvíli v rozsahu. Každý krok je sám o sobě rozumný a žádný z nich se nezdá být rozhodnutím o ochraně dat.

Ale zvažte, co se děje dále. Váš pipeline pro pozorovatelnost zachytí tyto záznamy protokolu a předá je vaší platformě pro správu protokolů. Tato platforma je uchovává ve výchozím nastavení po dobu 90 dnů, nebo 365, nebo neurčitě, protože nikdo nezměnil výchozí nastavení při instalaci. Pokud používáte platformu s primárním regionem v USA, tato data také překročila hranici bez záměrného rozhodnutí o přenosu. Pokud jste nakonfigurovali předávání protokolů do SIEM nebo analytického nástroje, stejná data nyní existují na třetím místě pod svým vlastním harmonogramem uchovávání.

Nic z toho jste nerozhodli. Nakonfigurovali jste logger. Zbytek vyplynul z výchozích nastavení.

Data nyní existují paralelně. Primární kopie sleduje životní cyklus, který jste navrhli: strukturovaný, smazatelný, řízený vašimi pravidly uchovávání. Kopie protokolů sledují jiný: méně strukturovaný, uchovávaný podle provozních výchozích nastavení, rozprostřený napříč systémy, které nikdy nebyly součástí vašeho datového modelu. Tyto dva životní cykly se časem rozcházejí a mezera mezi nimi je místem, kde vzniká většina skutečných problémů s dodržováním předpisů.

Kde se to projeví

Tento rozdíl je neviditelný, dokud systém není povinen jednat s daty kontrolovaným způsobem. Mazání je nejjasnější test.

Uživatel podá žádost o výmaz. Odstraníte jeho záznam z primární databáze. Pak se někdo zeptá, zda jsou data skutečně pryč. Jeho e-mailová adresa je v protokolech požadavků napsaných před šesti měsíci. Jeho uživatelské ID se objevuje v trasách chyb napříč třemi službami. Jeho aktivita v relaci sedí v předávaném streamu událostí uchovávaném platformou třetí strany s výchozím nastavením 12 měsíců. Vaše platforma pro správu protokolů nepodporuje mazání na úrovni řádků. Otevřete servisní lístek a čekáte, zatímco tikají hodiny na vaši 30denní lhůtu pro odpověď.

Uchovávání odhaluje stejné selhání z jiného úhlu. Aplikujete 90denní pravidlo uchovávání na vaši primární databázi a považujete to za vyřešené. Váš log drain běží na výchozím nastavení platformy 12 měsíců. Stejná data mají nyní dvě doby uchovávání, aplikované nezávisle, bez ničeho, co by vynucovalo konzistenci mezi nimi. Pokud jste kdykoli povinni prokázat, že data byla smazána v rámci období, které jste zdokumentovali, nemůžete: protože dokumentace popisuje vaši databázi, nikoli váš systém.

Rozhodnutí, na kterých záleží

Definujte povolený seznam polí před zahájením instrumentace.

Výchozí chování většiny knihoven pro logování je zachytit vše v rozsahu. Toto výchozí nastavení vygeneruje osobní údaje v protokolech. Jediným spolehlivým řešením je předem rozhodnout, co záznam protokolu smí obsahovat, nikoli jako cvičení filtrování po skutečnosti, ale jako omezení aplikované od začátku na úrovni konfigurace knihovny.

Pro většinu systémů je povolený seznam krátký. Časová razítka, ID požadavků, identifikátory služeb, HTTP metody, stavové kódy, doby odezvy, strukturované chybové kódy. ID uživatelů, e-mailové adresy, IP adresy v nezkrácené podobě, tokeny relací a jakýkoli fragment vstupu dodaného uživatelem na tomto seznamu nemají co dělat bez výslovného zdokumentovaného důvodu. Pokud pole není na povoleném seznamu, neobjeví se v protokolech. Jedno rozhodnutí, aplikované všude, nevyžaduje žádnou průběžnou disciplínu k udržení.

Nahraďte identifikátory uživatelů korelačními ID.

Pokud potřebujete sledovat požadavek napříč službami (a potřebujete), nepotřebujete v každém řádku protokolu identifikátor uživatele. Vygenerujte náhodné korelační ID na okraji a propagujte ho napříč řetězcem volání. Získáte plnou end-to-end sledovatelnost bez propojení jakéhokoli záznamu protokolu s jednotlivcem. Když potřebujete rekonstruovat, ke kterému uživateli se korelační ID mapuje, toto mapování žije ve vašem primárním datovém úložišti pod vlastními pravidly uchovávání a mazání. Protokoly zůstávají provozně užitečné. Klasifikace citlivosti vašich dat protokolů se výrazně snižuje a žádosti o výmaz přestávají být vícesystémovým archeologickým cvičením.

Zacházejte s úrovněmi protokolů jako s datovými hranicemi.

Protokoly DEBUG jsou určeny pro vývoj a neměly by běžet v produkci. Když běží, obsahují všechno: stav proměnných, surové vstupy, cokoliv bylo v danou chvíli pohodlné připojit. Protokoly INFO by měly zaznamenávat, že se něco stalo, nikoli obsah toho, co se stalo. Protokoly ERROR a WARN vyžadují největší kontrolu, protože chybové podmínky jsou přesně místem, kde se s největší pravděpodobností objeví citlivý vstup: datová část, která spustila selhání validace, tělo požadavku, které způsobilo pád. Definujte, co je každé úrovni povoleno obsahovat, jako písemnou politiku a vynucujte ji při revizi kódu. Konvence se pod tlakem termínů rozpadají; politika, kterou lze revidovat, ne.

Nastavte doby uchovávání pro každé cílové místo protokolů, nikoli pro každou službu.

Pro každé cílové místo protokolů ve vašem systému (primární drain, předávané streamy, integrace SIEM, analytické nástroje) nastavte explicitní dobu uchovávání spojenou se zdokumentovaným účelem. Provozní protokoly pro ladění zřídka potřebují více než 30 dní. Bezpečnostní protokoly událostí mohou vyžadovat delší uchovávání, ale to vyžaduje účel a právní základ, nikoli výchozí nastavení ponechané od počátečního nastavení. Tam, kde vaše platforma nepodporuje automatické mazání na úrovni záznamů, je to mezera k vyhodnocení při výběru dodavatele, nikoli omezení, které je třeba tiše absorbovat.

Mapujte svou platformu pro správu protokolů jako zpracovatele dat.

Pokud vaše protokoly obsahují osobní údaje – byť i náhodně – vaše platforma pro správu protokolů je zpracovává vaším jménem. To vyžaduje Dohodu o zpracování dat (DPA), pochopení toho, kde jsou data geograficky uložena, viditelnost do jejich řetězce subzpracovatelů a potvrzení, že jejich DPA je kompatibilní s vašimi vlastními závazky vůči zákazníkům. Pro systémy fungující podle odvětvových předpisů standardní DPA platformy kliknutím často nebude dostatečná bez vyjednávání.

Rezidence dat je zde specifickou a běžnou mezerou. Většina hlavních platforem nabízí regiony EU, ale nenastavuje je jako výchozí. Kde jsou vaše protokoly skutečně uloženy, je konfigurační otázka s právním důsledkem: neověřený předpoklad o rezidenci v EU je jedním z nejjednodušších selhání při dodržování předpisů, kterým se lze vyhnout, a jedním z nejčastěji přehlížených.

Výchozí nastavení jsou politika

Pokud váš systém loguje celé datové části požadavků, uchovává je na výchozích nastaveních platformy a předává je bez definovaných hranic, je to vaše politika zpracování dat – bez ohledu na to, co říká vaše oznámení o ochraně osobních údajů. Rozhodnutí, která formují, jak váš systém logování skutečně funguje, jsou učiněna při konfiguraci prvního drainu, psaní prvního handleru a nastavení doby uchovávání nebo ponechání výchozího nastavení.

Logování je nejběžnějším místem, kde se dobře navržený primární datový model rozpadá. Nevyžaduje to chybu. Vyžaduje pouze to, aby pozorovatelnost byla považována za inženýrský problém a datový životní cyklus za problém někoho jiného (a aby nikdo nevlastnil překryv).

Proč to všechno? Kromě právního zdůvodnění existuje ještě jeden aspekt: systém, který běží, když se nikdo nedívá, je systém, který je auditován. Věřte mi, neaudituji okázalou novou věc – kopu do starého systému, nedotčeného kusu vybavení, kterému každý říká spolehlivé. Protože tam jsou problémy.