JAK UŽITEČNĚ POŠKODIT VLASTNÍ DATA

Lidé mají rádi příběhy. Možná proto, že příběh je člověku přirozený. Lidé si vyprávěli příběhy od nepaměti. Vlastně ani není důležité, je-li příběh pravdivý, nebo smyšlený. Mnohdy je smyšlený příběh pravdivější než pravda a pravdivý příběh k neuvěření.

O čem náš příběh bude? Vymyslíme si zcela smyšlenou situaci ve zcela smyšlené bance. Ale nebude to situace pravdě zcela nepodobná. Budeme se věnovat jednomu aspektu vývoje informačních systémů v bance. Na místo smyšlené banky si můžete dosadit kteroukoli jinou smyšlenou nebo i skutečnou velkou firmu s rozsáhlými informačními systémy. Určitě najdete podobnosti čistě náhodné.

Všeobecná Fiktivní Banka a její problém

Nuže Všeobecná Fiktivní Banka ( zkratka VFB ) se rozhodla posílit své postavení na trhu. A moudré hlavy nejvyššího vedení banky rozhodly, že bude pro skvělé zítřky zapotřebí nahradit jeden z důležitých, ale již zastarávajících informačních systémů něčím novým a perspektivnějším. Není důležité, zda se jedná o core banking systém, o internetové bankovnictví nebo třeba o CRM. Rozhodně ale nejde o okrajovou aplikaci pro pár bankéřů.

VFB vyhlásila program „New Deal“ ( zkratka ND ) a najala nejlepšího manažera, jakého byla schopna sehnat na trhu práce. Ten posbíral po bance všechny dostupné lidské zdroje, najal nejlepší dodavatele, uzavřel s nimi ty nejlepší možné smlouvy a všichni vespolek se pustili k dílu.

Práce šla rychle kupředu, nečekaně rychle se podařilo posbírat všechny funkční i nefunkční požadavky na systém. V plánovaném termínu byl dokončen návrh architektury, vývojové práce se rozběhly na plné obrátky. Nastal čas připravit se na testy prvních výstupů úspěšně probíhajícího projektu.

Horečnaté přípravy

IT infrastruktura včas připravila prostředí se všemi navazujícími systémy, včetně integrační platformy. Vše plně funkční. Tedy teoreticky plně funkční. Jak známo, informační systémy pracují s daty, bez dat nedělají nic. Nadešla chvíle rozhodnout, jaká data budou k testování použita.

Architekt Georg přišel s návrhem, že pro správné otestování všech funkcí bude potřebné připravit data splňující podmínky, za jakých funkce musí pracovat. Jedině systematicky připravená umělá data umožní spolehlivě ověřit, že vše funguje tak, jak má. Analytik Spring bryskně spočítal, že pro plánovaných 1500 funkčních požadavků, které musí fungovat pro 300 různých typů produktů s desítkami různých okrajových omezení by bylo potřebné manuálně připravit přibližně 22 miliónů různých kombinací dat. Tolik jich ale ve skutečnosti neexistuje. Většina z možných kombinací se nikdy v reálném světě neobjeví.

Projektový manažer Black přišel s jednoduchou otázkou. Proč máme vymýšlet nějaká data, když jich máme v produkci spousty? Chvíli trvala diskuse na téma, zda data z produkce skutečně pokryjí všechny testovací případy ale brzy se shodli, že určitě pokryjí právě to, co je v praxi potřebné nejvíce. Pokud se pro nějakou důležitou situaci produkční data nenajdou, tak se připraví manuálně.

I šel kolem Sekyra od bezpečáků. Zaslechl, o čem se diskutuje a ihned vyhlásil poplach. Na testy si najímáme brigádníky. Je přece zcela nepřípustné, aby mohli brigádnici pracovat s produkčními daty. Z toho hrozí průšvih.

Začaly horečné aktivity. Kudy z toho ven? Rezignovat na brigádníky a testovat s pomocí kmenových zaměstnanců? Je to postačující opatření? Dovoluje nám vůbec legislativa pracovat s reálnými citlivými údaji v testovacím prostředí? Diskuse se vedla napříkad o vyhlášce ČNB č.123, která v příloze 1. uvádí, že „… banka zajistí … přístup k informacím v informačních systémech pouze uživateli, který byl pro tento přístup autorizován“. Představme si kmenového pracovníka banky, který  je v rámci svých pracovních povinností autorizován pracovat s nějakou informací v informačním systému, zatímco s jinou informací pracovat nesmí. A nyní si představme, že je tento pracovník pověřen testováním připravovaného nového řešení. Má ale za úkol testovat i další oblasti nad rámec těch, pro které stačí jeho standardní autorizace. Je testování dostatečným důvodem k rozšíření jeho práv?

Objevil se i další aspekt. Vyhláška ČNB č. 123 uvádí také tuto větu: „Při provozování informačních systémů banka  … zejména zajistí, aby změnu v provozovaných informačních systémech bylo možno provést až po vyhodnocení vlivu této změny na bezpečnost  a aby bylo použito pouze otestované programové vybavení, u kterého výsledky testů prokázaly, že bezpečnostní funkce jsou v souladu …“. Systémy v testovacím prostředí se teprve testují. Je možné zajistit, aby byly systémy v testovacím prostředí nejdříve otestovány z pohledu bezpečnosti a teprve poté naplněny daty?

Nebudeme zde sledovat celou diskusi tak, jak probíhala. V konečném důsledku se ukázalo jako podstatným to, že nikdo z odpovědných pracovníků  nebyl ochoten riskovat únik citlivých informací do nepovolaných rukou. Zkrátka padlo rozhodnutí, že data v testovacím prostředí mohou být odvozena z produkčních dat pouze za předpokladu, že budou upravena tak, aby nebylo možné zjistit původní citlivá data. Zkrátka zadání znělo „Anonymizovat“. Poškodíme vlastní data tak, aby nikdo nepoznal, co v nich původně bylo.

Nadlidský úkol naplánovat projekt

Projektový manažer Black dostal za úkol naplánovat projekt. I požádal analytika Springa, aby odhadl pracnost. První analytikova otázka byla zřejmá. Která data jsou vlastně citlivá?

Z legislativy vyplývá, že za citlivá data je nutno považovat identifikační údaje fyzických osob. Jména, příjmení, rodná čísla. Jména se občas objevují v e-mailové adrese a v názvu účtu, tedy ty také. Pro jistotu i telefonní číslo. Co adresa? Sama o sobě je adresa veřejnou informací ale pokud víme, kdo na dané adrese bydlí, mohli bychom odhalit, kdo se za anonymizovanými daty skrývá. A co osobní číslo zaměstnance? Také může sloužit jako můstek vedoucí k odhalení pravé totožnosti. Ale podobným způsobem může sloužit řada dalších údajů jako čísla účtů, informace o tom, že je statutárním orgánem či konkurzním správcem konkrétní firmy.  Rozeznat všechna nebezpečí odhalení pravé totožnosti může být velmi náročné. A do jaké míry je to vlastně nutné? Chceme minimalizovat rizika nebo chceme zcela a beze zbytku eliminovat všechna rizika?

Anonymizace dat jako klíčový problém

Když se o anonymizaci dozvěděli zástupci korporátního segmentu, rozvířila se voda ještě více. Jisteže je název firmy nebo její identifikační číslo veřejnou informací, kterou si může kdokoli zjistit v obchodním rejstříku. Ale fakt, že je tato firma našim klientem, veřejnou informací není. A kolik má zůstatků na účtech či kolik nám dluží, to jsou velmi citlivé informace. A tak se anonymizace rozšířila i na firmy, opět se hledaly informace o firmách, které by mohly sloužit k prolomení jejich anonymity.

Ubíhal čas a odhady pracnosti stále nebyly k dispozici. Analytik Spring přišel s návrhem odložit přesný seznam anonymizovaných informací. Uděláme to parametrizovatelné tak, abychom mohli kdykoli v budoucnu doplnit další informaci, kterou bychom potřebovali zamaskovat, jakmile na takovou potřebu narazíme. „A nebude to drahé?“ zněla otázka. „A až budeme dělat příští projekt, kterého se budou účastnit další systémy a nové verze systémů, co bude dražší, nový projekt anonymizace nebo jen naparametrizovat řešení, které už budeme mít hotovo?“

Zatímco se vedly diskuse o informacích, které se mají anonymizovat, o tom, zda musí být známy předem, nebo zda mohou být průběžně doplňovány, někteří už přemýšleli, jak to vlastně techicky realizovat. Výsledek má sloužit pro potřeby testování. Co vlastně chceme testovat? Součástí projektu je integrace více systémů, uvidí-li tester v jednom systému „Pavel Novák“ a v jiném systému u stejného účtu „Jiří Růžička“, jak rozezná, zda se jedná o dopad anonymizace nebo o nesprávnou funkci systému? Není zbytí, musíme poškodit data konzistentně přes všechny systémy. Změníme-li nějak jméno v jednom sytému, musíme stejné jméno změnit v jiném systému stejně. A to platí pro všechna poškozovaná data obecně.

Dobrá, tak tedy „Petr Slabý“ bude ve všech systémech „Karel Silný“. Jenže v jednom ze systémů mají ve zvyku psát jen zkratku křestního jména. Takže „P. Slabý“ busí být „K. Silný“, jinak to bude vypadat na chybu. Ale z toho plyne, že Pavel může být Kamil ale nemůže být Josef. Péťa může být Kája ale nemůže být Kryštof. Peter by měl být Karol. A překlep Ptr by se měl anonymizovat na Krel. Nějak se nám to komplikuje. A je to vůbec nutné? Kolik takových zkratek jmen, zdrobnělin a překlepů máme? Musíme je všechny správně vyřešit?

Architekti si vzpomněli, že pro nový systém bude nutné otestovat také konsolidaci klientů v datovém skladu. Ta je do jisté míry tolerantní vůči překlepům, ale ne mnoho. Proto bude nutné s překlepy nějak pracovat, aby výsledky testů odpovídaly skutečnosti. Nebo existuje jiná možnost? S citlivými daty v datovém skladu přece nikdo přímo nepracuje. Co kdybychom po cestě ze zdrojových systémů do datového skladu vrátili data zpět do jejich původní, nepoškozené podoby?

Ve chvíli, kdy se začali zabývat konsolidací v datovém skladu, vzpomněl si někdo na adresy. Pro konsolidaci se využívá identifikace adres. To znamená, že se adresy ověřují vůči seznamu všech existujících adres v ČR. Jestliže adresy poškodíme, měli bychom to udělat tak, aby adresa nadále ve skutečnosti existovala. Ale poškodit adresu tímto způsobem se ukázalo jako velmi náročné. Opět se diskuse vrátila na začátek. Je to nutné? Opravdu je nebezpečí odhalení pravé identity prostřednictvím nezměněné adresy tak vysoké aby oprávnilo enormní náklady?

Šotek v realizaci

Přestože stále nebylo jasné, která data se budou vlastně poškozovat a jak, kohosi napadlo vyzkoušet, jak by to vypadalo. Projektový manažer odouhlasil pokus, naplnili v testovacím prostředí jeden systém kopií dat z produkčního prostředí a spustili pokusně prostý update jmen. Všechna jména změnili na XXX. Nic více. Počítač se zasekl. Programátoři volali administrátorům, že databáze neběží, administrátoři oponovali, že běží. Skutečnost byla prostá - spustil se trigger, který odesílal změny integrační vrstvě. Nemělo smysl čekat, jestli to doběhne. Museli nejdříve vypnout všechny triggery, pak mohli pokus opakovat. Tentokrát to doběhlo, ale trvalo to žalostně dlouho. Programátoři navrhli řešení. Je nutné zrušit nejen triggery ale také referenční integritu na celé tabulce, indexy a materializovaná view. Poté zkopírovat celou tabulku do jiné tabulky a přitom přepsat jméno. Následně celou tabulku zrušit a opět ji celou naplnit včetně změněného jména. Pak obnovit vše, co na začátku zrušili. I přes relativně komplikovaný postup byl výsledný čas mnohem lepší, než při prostém updatu.

Ale opakovat tento postup pro všechny tabulky? A co když při obnově zapomeneme, že došlo ke změně některé definice a obnovíme původní, zastaralý stav? Programátoři samozřejmě věděli jak by se to mělo udělat. Na začátku načíst z databáze metadata, zapamatovat si, jak to bylo, podle metadat automaticky zrušit vše, co překáží, poškodit data nejrychlejším možným způsobem (typicky bývá insert rychlejší, než update, ale nemusí to platit vždy) a nakonec vrátit vše zrušené do původního stavu. To se dá naprogramovat tak, aby to proběhlo automaticky. Ale pro každý databázový server se to musí udělat jinak. Naštěstí nemáme žádné systémy, které by ukládaly data jinak, než do standardních databází.

Začalo být zřejmé, že k poškozování dat bude potřebný nový systém, který nebude dělat nic jiného, než užitečně škodit. Bude potřebovat vlastní místo v architektuře testovacího prostředí.

Závěr

Zatímco jsme sledovali diskuse a pokusy, čas plynul. Mohli bychom sledovat pokračování tohoto seriálu ale udělejme v této chvíli zkratku. Pojďme se podívat, jak to nakonec dopadlo. Inu, jestli nezemřeli, dohadují se dodnes. Nadějně rozběhnutý projekt náhrady jednoho z důležitých systému VFB novým uvíznul na mrtvém bodě. A když projektový manažer Black odcházel do důchodu, zanechal svým nástupcům moudrou radu. Nejdříve vybudujte testovací prostředí a teprve pak začněte s novým projektem. Uděláte-li to opačně, nedopadne to podle vašich přání.