Sem vložte zadání Vaší práce

Sem vložte zadání Vaší práce.

České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství

Bakalářská práce

Datové řezy a anonymizace Petr Smítka

Vedoucí práce: Ing. Jiří Mlejnek

16. května 2013

Poděkování Na tomto místě bych chtěl poděkovat svému vedoucímu bakalářské práce Ing. Jiřímu Mlejnkovi za jeho přístup, rady a ochotu během zpracování bakalářské práce.

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.

V Praze dne 16. května 2013

.....................

České vysoké učení technické v Praze Fakulta informačních technologií © 2013 Petr Smítka. Všechna práva vyhrazena. Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.

Odkaz na tuto práci Smítka, Petr. Datové řezy a anonymizace. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.

Abstract The Bachelor’s Thesis deals with the problematic of data subsetting and anonymization. The theoretical part is focused on detail explanation of these terms and reasons for their usage. The thesis shows possible complications in case of inaccurate process. The second part is focused on existing solutions and comparison of their functionality. The last part introduce the developed WinchAddin tool and describes new implemented functionality for the purpose of this thesis. Keywords data masking, data scrambling, anonymization, data subset, data cut, data security, tools comparison, WinchAddin

Abstrakt Práce je zaměřena na problematiku Datových řezů a anonymizace. Teoretická část je věnována podrobnému vysvětlení těchto pojmů a dále se věnuje důvodům, proč tyto techniky používat a nastiňuje možné komplikace, ke kterým může dojít, pokud se techniky neprovedou správným způsobem. 9

Ve druhé části se věnuje existujícím nástrojům a porovnáním jejich funkcí. Poslední část práce je věnována vyvíjenému nástroji WinchAddin. Popisují se zde funkce, které do něho byly implementovány v rámci této práce. Klíčová slova maskování dat, anonymizace, datový řez, zabezpečení dat, porovnání nástrojů, WinchAddin

10

Obsah Úvod

17

1 Teoretická část 19 1.1 Bezpečnost informačních systémů . . . . . . . . . . . . . . . 19 1.2 Datové řezy a anonymizace . . . . . . . . . . . . . . . . . . . 21 1.3 Typy dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2 Dostupné nástroje 2.1 Data Masking Suite . . . . . . 2.2 Solix EDMS Standard Edition 2.3 Camouflage . . . . . . . . . . 2.4 Data Masker For Oracle . . . 2.5 Data Bee . . . . . . . . . . . . 2.6 Jailer . . . . . . . . . . . . . . 2.7 Další nástroje . . . . . . . . . 2.8 Porovnání nástrojů . . . . . . 3 Implementace 3.1 Popis nástroje Winch . . . . . 3.2 Architektura aplikace . . . . . 3.3 Stav projektu při jeho převzetí 3.4 Provedené úpravy . . . . . . . 3.5 Návrhy na vylepšení . . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

43 43 46 49 53 57 62 65 65

. . . . .

71 71 74 75 75 86

4 Testování

89

Závěr

91 11

Literatura

93

A Seznam použitých zkratek

97

B Obsah přiloženého CD

99

C Ukázky anonymizačních nástrojů

12

101

Seznam obrázků 1.1 1.2 1.3

Datový model . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cyklická vazba . . . . . . . . . . . . . . . . . . . . . . . . . . . Formát telefonního čísla . . . . . . . . . . . . . . . . . . . . . .

25 26 40

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22

Data Masking Suite - ukázka prostředí . . Data Masking Suite - Přidání tabulky . . . Data Masking Suite - Nastavení pravidel . Solix EDMS - Výběr tabulek . . . . . . . . Solix EDMS - Nastavení pravidel . . . . . Solix EDMS - Seznam Pravidel . . . . . . Camouflage - Hlavní okno . . . . . . . . . Camouflage - Nastavení pravidel . . . . . . Camouflage - Filtr . . . . . . . . . . . . . Camouflage - Spuštění . . . . . . . . . . . Data Masker For Oracle - Hlavní okno . . Data Masker For Oracle - Nové pravidlo . Data Masker For Oracle - Nové substituční Data Bee - Nová vazba . . . . . . . . . . . Data Bee - Omezení počtu záznamů . . . . Data Bee - Loader set, Nové pravidlo . . . Data Bee - Set Designer . . . . . . . . . . Data Bee - Set Extractor . . . . . . . . . . Data Bee - Set Loader . . . . . . . . . . . Jailer - Výběr databázového modelu . . . . Jailer - Hlavní okno nástroje . . . . . . . . Jailer - Filter Editor . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

45 45 46 48 48 49 51 51 52 52 55 56 56 59 59 60 60 61 61 63 64 64

3.1

Enterprise Architect - Požadovaná struktura . . . . . . . . . . .

72

13

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pravidlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14

Enterprise Architect - Diagram aplikace . . . Winch - Ukázka filtrovacího okna . . . . . . . Winch - Editor uživatelských proměnných . . Winch - Editační okno . . . . . . . . . . . . . Winch - Editační okno, výběr sloupce . . . . . Winch - Editační okno, výběr položky z menu Winch - Průvodce nastavením vazeb . . . . . Winch - Procházení skrz vazby . . . . . . . . Winch - Report, záložka tabulek . . . . . . . Winch - Report, záložka anonymizačních typů Winch - Report, filtr zobrazení . . . . . . . . Winch - Průvodce vytvořením nové aplikace . WinchAddin - Výběr anonymizačního typu . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

73 76 77 79 80 80 81 82 83 84 84 85 87

C.1 Solix EDMS - Vytvoření a editace připojení . . . . C.2 Solix EDMS - Výběr připojení . . . . . . . . . . . . C.3 Camouflage - Data browser . . . . . . . . . . . . . C.4 Camouflage - Okno Logu . . . . . . . . . . . . . . . C.5 Camouflage - Nastavení připojení . . . . . . . . . . C.6 Camouflage - Seznam připojení . . . . . . . . . . . C.7 Data Masker For Oracle - Enable Foreign Key Rule C.8 Data Bee - Nástroje . . . . . . . . . . . . . . . . . C.9 Data Bee - Who-Loads-What Rule . . . . . . . . . C.10 Data Bee - Tree Finder . . . . . . . . . . . . . . . . C.11 Data Bee - Chain Finder . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

101 102 102 103 103 103 104 104 105 105 106

14

. . . . . . . . . . . . .

. . . . . . . . . . . . .

Seznam tabulek 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8

Person . . . . . . . . . . . . . Address . . . . . . . . . . . . Struktura rodného čísla . . . Generování rodného čísla . . . Výpočet IČO . . . . . . . . . Rozdělení PSČ podle krajů . . Váhy pro kontrolní algoritmus Váhy pro kontrolní algoritmus

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . čísla účtu čísla účtu

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

25 25 32 33 34 36 38 39

2.1 2.2 2.3 2.4 2.5 2.6

Další nástroje . . . . . . . . . . . . . . . . Porovnání nástrojů - Instalace . . . . . . . Porovnání nástrojů - Dokumentace . . . . Porovnání nástrojů - Připojení . . . . . . . Porovnání nástrojů - Práce s nástrojem . . Porovnání nástrojů - Celkové vyhodnocení

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

65 66 67 67 68 68

15

Úvod V dnešní době si téměř každá instituce vede seznam svých klientů, zaměstnanců a dalších citlivých údajů. Tyto evidence se postupem času spolu s rozmachem IT změnily z původních papírových kartoték do digitální podoby. U větších subjektů mají data převážně podobu relačních databází, u menších firem to jsou spíše tabulky vytvořené v tabulkových procesorech, jako je např. MS Excel, OpenOffice.org Calc a další. Velkou výhodou údajů uložených v podobě relačních databází je jejich vysoká dostupnost a možnost přistupovat k nim z různých zařízení v počítačové síti. To s sebou ale zároveň nese i nové požadavky na zabezpečení těchto dat. Přístup ke všem údajům by neměl mít každý, ale jen ty osoby, které jsou k tomu skutečně oprávněny. S tím nepřímo souvisí i techniky datových řezů a anonymizace, které se používají převážně při vývoji softwarových systémů, kde většinou narážíme na nutnost poskytnutí testovacích dat vývojářům, testerům ale i dalším osobám pracujícím na vývoji aplikace. K tomu, abychom nemuseli poskytovat celý obsah produkčních dat a zbytečně nezveřejňovali citlivé údaje neoprávněným osobám nám mohou pomoci zmíněné techniky datových řezů a anonymizace, kterými se dále zabývám v této práci. První část práce se zabývá vysvětlením pojmů datových řezů a anonymizace, důvody pro použití těchto technik a jejich vztahem k zabezpečení dat. Druhá část práce rozebírá existující nástroje sloužící k uvedeným technikám a porovnává jejich funkce. V závěru práce se věnuji nástroji WinchAddin, který je stále vyvíjen a slouží k jednoduchému nastavení datových řezů a anonymizace nad datovým modelem.

17

Kapitola

Teoretická část V této kapitole se pokusím shrnout základní informace týkající se zabezpečení dat. Převážně se zaměřím na problematiku datových řezů a anonymizace. S tím pak dále souvisí různé typy dat, které lze považovat za citlivé. Dále v kapitole 1.3 je několik typů citlivých dat podrobně rozebráno.

1.1

Bezpečnost informačních systémů[18]

Na pojem bezpečnosti informačních systémů lze pohlížet mnoha způsoby. Základní pohled na zabezpečení můžeme rozdělit do tří kategorií. • Fyzické • Logické • Organizační Pod pojmem fyzické zabezpečení si můžeme představit zamezení fyzického přístupu k hardwaru. Do této kategorie by se daly zařadit zabezpečovací systémy, správa přístupů v rámci budovy nebo utajení geografické polohy datového centra. Logické zabezpečení se převážně zabývá autentifikací/autorizací přístupu k datům. Většinou jde o přihlašování do aplikace pomocí přiděleného jména a hesla. Mohou zde být ale použity i další technologie, jako jsou například tokeny nebo biometrické systémy. Do kategorie organizačního zabezpečení se zahrnuje další snaha organizace o zvýšení bezpečnosti systému. Příkladem mohou být různá personální pravidla jako jsou nařízení a směrnice, které by měl zaměstnanec dodržovat. 19

1

1. Teoretická část V České republice upravuje otázku bezpečnosti dat zákon č.101/2000 Sb. o ochraně osobních údajů.[9] Tento zákon vymezuje následující pojmy:

Osobní údaj: „informace týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze subjekt údajů přímo či nepřímo identifikovat zejména na základě čísla, kódu nebo jednoho či více prvků, specifických pro jeho fyzickou, fyziologickou, psychickou, ekonomickou, kulturní nebo sociální identitu“[9]

Citlivý údaj: „údaj vypovídající o národnostním, rasovém nebo etnickém původu, politických postojích, členství v odborových organizacích, náboženství a filozofickém přesvědčení, odsouzení za trestný čin, zdravotním stavu a sexuálním životě subjektu údajů a genetický údaj subjektu údajů; citlivým údajem je také biometrický údaj, který umožňuje přímou identifikaci nebo autentizaci subjektu údajů“[9]

Anonymní údaj: „údaj, který buď v původním tvaru nebo po provedeném zpracování nelze vztáhnout k určenému nebo určitelnému subjektu údajů, subjektem údajů fyzická osoba, k níž se osobní údaje vztahují“[9]

Správce: „každý subjekt, který určuje účel a prostředky zpracování osobních údajů, provádí zpracování a odpovídá za něj. Zpracováním osobních údajů může správce zmocnit nebo pověřit zpracovatele, pokud zvláštní zákon nestanoví jinak“[9]

Zpracovatel: „každý subjekt, který na základě zvláštního zákona nebo pověření správcem zpracovává osobní údaje podle tohoto zákona“[9]

Každý subjekt musí podle zákona učinit následující opatření.

„Správce a zpracovatel jsou povinni přijmout taková opatření, aby nemohlo dojít k neoprávněnému nebo nahodilému přístupu k osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jinému zneužití osobních údajů. Tato povinnost platí i po ukončení zpracování osobních údajů.“[9] 20

1.2. Datové řezy a anonymizace

1.2

Datové řezy a anonymizace[16]

Na tyto techniky většinou narazíme při vývoji softwarových systémů. Každý větší softwarový projekt během svého životního cyklu prochází přes několik různých prostředí. Téměř vždy to jsou vývojové, testovací a produkční prostředí. Většina firem mívá velmi dobře zabezpečené produkční prostředí, používají se zde zabezpečené protokoly, je nastaveno omezení přístupových práv pro zaměstnance, dokonce bývá řešeno i geologické umístění databázových center. Často se ale zapomíná na ostatní prostředí, přes která musí aplikace projít než se dostane až do prostředí produkčního. Podle průzkumu společností New Ponemon a Compuware z prosince roku 2007 [27] až 62% firem používá pro testování a vývoj aplikací produkční data. Právě zde hrozí velké riziko zneužití dat. Do vývojového a testovacího prostředí má často přístup velké množství lidí. Většinou jde o vývojáře, testery, konzultanty, ale i externí pracovníky. Vzhledem k dnešní ceně dat je tato mezera v zabezpečení příliš vysoké riziko, které firmu může stát i pozici na trhu. Bohužel si toto riziko firmy často vůbec neuvědomují. Techniky datových řezů a anonymizace lze zařadit do kategorie organizačního zabezpečení. Převážně anonymizace zabraňuje úniku citlivých dat z organizace. Datové řezy pak slouží k omezení množství dat, které se dále předávají do navazujících úloh. Obě zmíněné techniky jsou podrobně popsány v následujících kapitolách.

1.2.1

Datové řezy

Hlavním účelem datových řezů je minimalizace dat. Ve většině případů je objem dat, který je potřebný pro vykonání určité operace mimo produkční prostředí, minimální v porovnání s celkovou velikostí databáze. Produkční data mohou být velice objemná. Někdy klidně i několik TB. Většinou vývojáři a testeři nepotřebují celý objem produkčních dat. Proto je rozumné data „ořezat“ tak, aby stále dávala smysl, ale přenášela se jen jejich nezbytně nutná část. Datový řez je vlastně nastavení pravidel pro to, jaká data a jak velký objem těchto dat přeneseme do neprodukčního prostředí. Samozřejmě nezbytná podmínka je, aby byla dodržena integrita databáze. Další podmínky na datové řezy mohou zahrnovat zachování určitých charakteristik původních dat. Tyto podmínky jsou většinou hodně specifické a liší se dle požadavků prostředí, pro které je datový řez určen. Jedna z takových podmínek může například vyžadovat zachování procentuálního zastoupení pohlaví osob uložených v databázi. 21

1. Teoretická část Datové řezy jako takové nejsou přímo určeny k zabezpečení dat, ale jeden z úhlů pohledu může být takový, že už i omezením objemu dat v testovacím prostředí částečně chráníme data před jejich zneužitím. Další výhodou použití této techniky je snížení požadavků na hardware v neprodukčních prostředích. Není nutná tak veliká disková kapacita a zároveň má databázový stroj jednodušší práci s prováděním SQL dotazů. Tím se snižují i požadavky na procesor a velikost operační paměti.

Požadavky na datové řezy Na základě specifikace požadavku můžeme datové řezy rozdělit do několika kategorií. Vetšina požadavků kladených na datový řez je poměrně specifická a vyžaduje znalost struktury dat, bez které by řez dat nebylo možné provést. Vždy musíme vědět, v jaké tabulce a v jakém sloupci je uložena identifikace na jejímž základě lze požadavek realizovat. Zachování statistických vlastností dat Jak již bylo uvedeno výše, můžeme se setkat s požadavkem na zachování určitých charakteristik původních dat. Může jít například o zachování rozložení věku osob, náboženského vyznání či jiných specifických charakteristik. Data za určitý časový úsek V mnoha případech v produkčních databázích zůstávají uložena data až několik let zpětně. Do neprodukčních prostředí pak stačí zahrnout jen data za určité časové období. Například půl roku zpětně, data za určitý rok či jiné rozsahy. Možností je v tomto případě mnoho. K vytvoření takového řezu dat je nutné, aby byl v datech sloupec, na jehož základě může být vyhodnoceno stáří záznamu. Pokud u požadovaných záznamů není uveden datum jejich vytvoření, nelze takovýto řez provést. Data vztahující se k určitému objektu či lokalitě Na základě tohoto požadavku můžeme zahrnout data vztahující se k mnoha věcem. Objektem či lokalitou může být cokoliv, záleží jen na obsahu řezaných dat. Může jít o data konkrétní pobočky, data produktu, informace o lidech žijících na určitém území a mnoho dalších. Příkladem může být požadavek na výběr osob žijících v konkrétním kraji, okresu či obci. K tomuto účelu lze využít registr adres popsaný dále v kapitole 1.3.5. Omezení velikosti datového řezu Další požadavek může být omezení výsledné velikosti databáze na určitou hodnotu. Například můžeme 22

1.2. Datové řezy a anonymizace požadovat, aby výsledný řez dat nepřesáhl 3GB. Abychom tohoto dosáhli, musíme buď předem spočítat počet záznamů, které zahrneme, nebo mohou být data přidávána postupně společně s probíhající kontrolou aktuální velikosti řezu. Velkou úsporu místa lze v některých případech docílit nahrazením binárního obsahu prázdnými dokumenty. Podobný princip lze aplikovat i u jiných nepotřebných dat. Nahrazování hodnot už ale spíše souvisí s problémy anonymizace než datových řezů. Kombinací obou technik lze docílit požadovaného efektu efektivněji.

Způsoby nastavení datových řezů Datový řez může být proveden různými způsoby. Například požadavek ořezání tabulky omezený určitým počtem záznamů lze provést hned několika způsoby. Vybrat můžeme například prvních n, posledních n nebo náhodných n záznamů. Provést lze samozřejmě i další specifické výběry, uvedené příklady jsou však nejčastější. Například pro Oracle lze omezení prvních 100 záznamů dosáhnout použitím klauzule where s podmínkou rownum <= 100. Sybase ASE používá syntaxi select top 100 * from A. Další databázové stroje mohou používat jinou specifickou syntaxi. Následující dva příklad ukazuje způsob výběru dat posledních n záznamů a náhodných n záznamů kde n = 100. Tyto příklady jsou určeny pro databázový stroj Oracle. -- Select last 100 rows SELECT * FROM (SELECT * FROM table ORDER BY rownum DESC) WHERE rownum <= 100 -- Select 100 random rows SELECT * FROM (SELECT * FROM table ORDER BY dbms_random.value) WHERE rownum <= 100 Další možností je nastavení vhodné where klauzule, pomocí které můžeme ovlivnit výsledné složení dat. Zde se dají ovlivňovat nejrůznější vlastnosti výsledných dat a zároveň specifikovat podmínky kladené na datový řez. Where klauzule poskytuje poměrně učinný způsob pro získání požadovaných dat. Převážně operátory LIKE, IN a BETWEEN spojené s poddotazy v jazyce SQL dokáží téměř zázraky. Musíme si ale také uvědomit, že pokud nevhodně nastavíme podmínky výběru dat, může nastat situace, 23

1. Teoretická část kdy jsou do výsledné množiny dat zahrnuty buď všechny záznamy z původních zdrojových dat nebo v opačném případě je výsledkem řezu dat prázdná množina.

Pro účely datových řezů můžeme tabulky dále rozlišit dle jejich účelu do několika základních typů. Zavedení typů tabulek slouží k jednodušší orientaci v datovém modelu. Na každý typ tabulky by měla být aplikována odlišná pravidla datového řezu. Prvním a nejčastějším typem jsou datové tabulky. Na tyto tabulky se aplikují pravidla, která vedou k redukci objemu dat uvedená v předchozích odstavcích. Dalším typem tabulek jsou číselníky. Z těchto tabulek by měly být přeneseny všechny záznamy. Vetšinou totiž obsahují data, která se zobrazují v různých nabídkách aplikace a jsou nezbytná pro její chod. Posledním typem jsou tabulky obsahující záznamy různých činností aplikace (logy). Do tabulek tohoto typu se ukládají operace zanamenané aplikací. Jako příklad lze uvést chyby aplikace, auditovací záznamy, protokoly komunikace nebo data podobného charakteru. Z těchto tabulek není většinou nutné přenášet žádná data. V případě nutnosti je možné zahrnout posledních n záznamů. Většinou je ale n rovno nule.

Cyklické vazby Asi největší komplikace nám při nastavování datových řezů způsobují zakzvané „cyklické vazby“. Jednoduchý příklad takovéto vazby ukazuje obrázek 1.1.

Mějme následující datový model (obr. 1.1), ve kterém evidujeme osoby a adresy. Každá osoba má vždy jedno trvalé bydliště. Na každé adrese může bydlet více osob, ale každá adresa má vždy jen jednoho vlastníka. 24


Obrázek 1.1: Datový model

Tento datový model naplníme daty uvedenými v tabulkách 1.1 a 1.2.

Person Id 1 2 3

Name Jan Nový David Kučera Radek Starý

Resident 1 3 4

Tabulka 1.1: Person

IdAddr 1 2 3 4

Address Address Praha 1 Brno Kolín Kutná Hora

Owner 3 3 1 2

Tabulka 1.2: Address

Pokud bychom v této situaci chtěli provést datový řez, například s podmínkou Address.Id = 3, to znamená adresu v Kolíně spolu s jejími souvisejícími osobami, dostáváme se do problému. Pokud budeme procházet skrz tabulky a dohledávat související záznamy, brzy se dostaneme do smyčky. Pokud bychom tuto situaci v řezacím nástroji nijak neošetřili, program by nikdy neskončil (obr. 1.2). Tento problém lze řešit několika způsoby. První a nejjednodušší z nich není příliš elegantní. Ke každé tabulce si zavedeme počítadlo průchodů. Systém pak spočívá v tom, že pokud opakovaně procházíme přes jednu tabulku, zahrneme do výsledku všechny její záznamy. Řešení sice zaručuje, že všechny vazby mezi tabulkamy zůstanou neporušeny, vznikají nám ale zbytečně „sirotci“. To jsou záznamy, na které nevede žádný odkaz z ostatních tabulek. 25

1. Teoretická část ... WHERE (Address.IdAddr = 3)

3

Kolin

1

1

Jan Novy

1

Praha 1

3

3

Radek Stary

4

2

1

Kutna Hora

David Kucera

4

2

3

Obrázek 1.2: Cyklická vazba Chytřejší řešení si zavede seznam procházení, který bude obsahovat název tabulky, název klíče, přes který jsme se k tabulce dostali, a podmínku výběru dat. Před provedením výběru dat (SQL dotazu) vždy funkce zkontroluje, zda stejný dotaz nad tabulkou nebyl proveden dříve. Pokud ano, ukončí se větev procházení. V opačném případě se pokračuje dál. Každý výběr dat pak znamená i přidání záznamu se zmíněnými hodnotami do seznamu procházení. Obě uvedená řešení však naráží na problém výkonu při velkém objemu dat. V prvním případě mohou být přenášeny celé tabulky. V nejhorší variantě je „ořezaná“ databáze ekvivalentní s původní zdrojovou. Ve druhém případě může cyklus proběhnout mnohokrát a čas potřebný k provedení řezu dat se může zněkolikanásobit. Nejlepším řešením z hlediska výkonu je provést nad každou tabulkou vždy jen jeden select s předem definovanou podmínkou výběru dat, která je nastavena již při konfiguraci datového řezu. Vytvoření správné konfigurace je ale poměrně složitý úkol, při kterém je nutné dobře znát strukturu řezané databáze. Velmi výhodné je použití operátoru IN společně s poddotazy, pomocí kterých lze zahrnout odpovídající záznamy. V některých případech může také pomoci dodržení správného pořadí při řezání tabulek. Následující příklad ukazuje, jak by tento princip mohl být realizován. SELECT * FROM sourceDatabase.table1 WHERE (id = 3); 26


SELECT * FROM sourceDatabase.table2 WHERE fkid IN ( SELECT id FROM destinationDatabase.table1); SELECT * FROM sourceDatabase.table3 WHERE fkid IN ( SELECT id FROM destinationDatabase.table2);

1.2.2

Anonymizace[17]

K tomu, abychom zamezili zneužití dat, nám pomůže anonymizace, někdy také označovaná jako maskování dat. Anonymizace je trochu jiný přístup k ochraně dat, než je například šifrování. Šifrováním data pouze převedeme do nečitelné podoby, kdežto anonymizovaná data stále vypadají jako reálná, a co je hlavní, už neobsahují žádné citlivé informace. Pokud je anonymizace provedena správně, neexistuje způsob, jak se vrátit k původním datům. Tím se pro potencionálního útočníka stávají bezvýznamná. Mezi hlavní výhody anonymizace tedy patří: • Odstranění citlivých dat. • Poskytnutí konzistentních dat pro neprodukční prostředí jako jsou například vývojové a produkční. • Pomoc ke splnění legislativních a regulačních opatření na ochranu dat. • Ochrana před zneužitím dat v neprodukčních prostředích. Typy anonymizačních funkcí: Různé funkce mohou pracovat různými způsoby. Zde se pokusím popsat několik základních způsobů (postupů) anonymizace dat. Náhodné generování znaků: Nejjednodušší způsob anonymizace je vygenerování sekvence náhodných znaků, kterými je následně nahrazena původní hodnota. U funkcí, které používají tento způsob anonymizace se ve většině případů omezí množina znaků a rozsah možných délek řetězců tak, aby výsledek co nejvíce odpovídal původní struktuře dat. Například pro generování českého křestního jména by se dala použít následující množina T = {A − Z, a − z}, ze které by se generovaly řetězce délky v rozsahu 3 − 10 znaků. 27

1. Teoretická část Výsledkem funkcí tohoto typu jsou řetězce, které na první pohled nedávají žádný smysl. Splňují sice účel dokonalé anonymizace, ale ztrácí základní vypovídající hodnotu reálných dat. Použití předpřipravených slovníků: Tento typ funkcí ke své činnosti potřebuje předem připravený slovník řetězců, ze kterých náhodně vybírá výslednou hodnotu. Funkce by měla kontrolovat, zda je výsledná hodnota různá od hodnoty původní, popřípadě musí provést nový náhodný výběr. Pro zamezení častého opakování jedné hodnoty by si funkce měla interně vést počítadlo použití jednotlivých hodnot, na jehož základě může vybírat hodnoty s větším rozptylem. Tyto funkce využijeme například při anonymizaci jmen, názvů obcí, ulic a dalších typů dat, ke kterým existuje známý seznam hodnot. Zamíchání dat (Shuffling): Tato metoda je zajímavá tím, že ke své práci používá původní data. Hlavní princip spočívá v „promíchání“ dat v jednom sloupci. Výsledek je pak takový, že žádný záznam nezůstane na svém místě. Vzhledem k tomu, že se jako nahrazované hodnoty používají původní data, pouze výsledná hodnota je vybraná z jiného náhodně vybraného záznamu, anonymizovaná data vypadají velice věrně. Tento postup se nedoporučuje u tabulek s malým množstvím záznamů. V některých případech by nemusel být problém promíchaná data zrekonstruovat do původní podoby. Aplikace pravidel pro dodržení formátu dat: Funkce z této kategorie použijeme v případě, kdy máme pevně stanovené požadavky na anonymizované hodnoty dat. Tyto funkce jsou většinou jednoúčelové a nelze je použít na jiný typ dat než pro který jsou určeny. Jako příklad můžeme uvést anonymizaci rodného čísla, kde je nutné dodržet formát data narození a správně vygenerovat koncovku tak, aby splňovala podmínky uvedené v kapitole 1.3.2. Díky funkcím z této kategorie budeme mít zaručeno, že anonymizovaná data budou vždy splňovat naše požadavky a nebude narušena aplikační logika vyvíjené aplikace. Anonymizace binárního obsahu: V mnoha případech se v datech vyskytují celé dokumenty. Může jít například o vystavené faktury, různé smlouvy, fotografie osob a spustu dalších dokumentů. Tyto dokumenty mohou v některých případech obsahovat údaje ekvivalentní s údaji v databázi. Pokud bychom tedy anonymizovali všechna data kromě binárního obsahu, 28

1.2. Datové řezy a anonymizace může se stát, že spousta údajů zůstane zpětně dohledatelná na základě těchto dokumentů. V tomto případě máme několik možností, jak data anonymizovat. Najjednodušší řešení je nahrazení všech záznamů sloupce hodnotou NULL. Toto řešení ale nelze použít vždy. Například, pokud sloupec s tímto obsahem má nastaveno NOT NULL, nebo to nedovoluje aplikační logika. V těchto připadech by měla anonymizační funkce generovat validní dokumenty odpovídajícího typu. Požadavky na anonymizační funkce Někdy se může stát, že po anonymizační funkci požadujeme víc než „jen“ odstranění citlivých údajů. Zde uvádím několik požadavků, které mohou za určitých okolností vyvstat. Generování unikátních hodnot: V případě, že anonymizujeme sloupec, který je zároveň i primárním klíčem, musí funkce zajistit, aby každá vygenerovaná hodnota byla unikátní. Toho lze dosáhnout například vytvořením seznamu již jednou vygenerovaných hodnot. V seznamu se poté zkontroluje, zda je nově vygenerovaná hodnota unikátní, pokud ne, vygeneruje se hodnota nová. Shodná anonymizace vzoru: Tento pořadavek je rozšířením předchozího. Jeho hlavní využití je při anonymizaci sloupců, které jsou součástí nějakého primárního nebo cizího klíče. Zde požadujeme, aby svázané hodnoty zůstaly svázané i po anonymizaci. To znamená, aby byly stejné vzory anonymizovány na stejný obraz. Jako příklad mohu uvést situaci, kdy je jako primární klíč použito rodné číslo osoby. V jiné tabulce máme další informace o osobě a vazba je realizována právě přes rodné číslo. Tento sloupec by měl být rozhodně anonymizován. Z důvodu existence vazby však musí být dodrženo, aby hodnota v primárním klíči byla anonymizována na stejný obraz jako hodnoty ve svázaných cizích klíčích. Pokud by toto nebylo dodrženo, byla by porušena integrita dat a původně svázané záznamy by mezi sebou ztratily propojení. Tento princip může být realizován různě. Jedno z možných řešení je použití slovníku, do kterého si funkce postupně ukládá dvojice hodnot. Každý záznam slovníku odpovídá dvojici vzoru a obrazu. Vzor je v našem případě původní hodnota v datech. Jako obraz je zde náhodně vygenerovaná hodnota, na kterou byl vzor anonymizován. Při každém dalším pokusu o anonymizaci nové hodnoty se funkce nejprve podívá do slovníku, jestli už 29

1. Teoretická část tento vzor jednou neanonymizovala. Pokud ano použije nalezený obraz, pokud ne vygeneruje novou hodnotu a přidá ji do slovníku. Použití tohoto principu není na škodu i u sloupců, které nejsou svázány s žádným klíčem. Jeden z důvodů je situace, kdy tabulky nejsou svázané pomocí klíčů na úrovni databáze, ale jejich vazby jsou realizovány na úrovni aplikační logiky. Dalším důvodem může být anonymizace více aplikací, které jsou integrovány do jednoho celku. Zde je nutné, aby datové vazby mezi aplikacemi zůstaly zachovány, jinak hrozí nekonzistence celého systému. Vzhledem k tomu, že slovník obsahuje data před i po anonymizaci je nutné, aby jeho zabezpečení bylo minimálně na stejné úrovni jako jsou produkční data. Jinak by mohlo dojít k jeho zneužití a obnově dat na stav před anonymizací. Zachování statistického rozložení dat: Někdy můžeme požadovat, aby si anonymizovaná data zachovala určité vlastnosti. Často to bývá v případech, kdy vyvíjíme aplikaci, která vytváří určité souhrny nebo statistické výpočty. Například u rodného čísla by funkce měla dodržet průměrný věk osob a zároveň zachovat i přibližný poměr obou pohlaví. Jiná funkce určená například k anonymizaci jmen by pak mohla zachovávat jejich četnost. Vždy ale záleží na konkrétních požadavcích.

1.3

Typy dat

V této části práce se zaměřím na popis běžně používaných dat, které jsou ve většině případů považovány za citlivé a měly by být anonymizovány. Popisuji zde jejich strukturu a pravidla, podle kterých se tvoří v České republice, popřípadě v rámci Evropské unie. U některých z nich dále uvádím postup anonymizace.

1.3.1

Jméno a příjmení[7]

Jméno a příjmení jsou údaje, které slouží k občanskoprávní identifikaci osoby. Tyto údaje jsou zapsány v matriční knize a v rodném listě osoby. Pravidla a nároky na jméno a příjmení jsou specifikována v zákoně č. 301/2000 Sb. o matrikách, jménu a příjmení a o změně některých souvisejících zákonů. Jméno a příjmení nejsou jednoznačné identifikátory osoby. Běžně nalezneme velké množství osob se stejným jménem a příjmením. Nicméně v rámci omezeného území (např. jedné obce) je tato idetifikace většinou dostatečná. Vzhledem k tomu, že se jméno a příjmení skládá z několika částí, velmi často se setkáváme s různými způsoby jeho uložení v databázi. Společně se 30

1.3. Typy dat jménem se zde mohou vyskytovat i další údaje, jako jsou například získané tituly. Celé jméno se pak může skládat z následujících položek. • Titul(y) před jménem • Křestní jméno(a) • Příjmení • Titul(y) za jménem Všechny tyto položky jsou pak ukládány v různých kombinacích. Zde uvádím nejběžnější varianty, se kterými se můžeme setkat. Kombinací může být samozřejmě mnohem více, vždy totiž záleží na konkrétním návrhu databáze. • Všechny uvedené položky jsou uloženy v jednom sloupci, spojeny do jednoho řetězce. V tomto případě je dobré na začátku určit pořadí položek a to dodržet pro všechny záznamy. • Jméno(a) a příjmení jsou uloženy společně v jednom sloupci, tituly jsou pak uloženy v samostatném sloupci. • Pro každou položku je vytvořen samostatný sloupec. Titul(y) před jménem, jméno, příjmení i titul(y) za jménem jsou uloženy odděleně. Na způsobu uložení dat v databázi závisí i výběr správné anonymizační funkce. Teprve na základě způsobu uložení dat můžeme vybrat správnou anonymizační funkci. Ve všech uvedených případech lze k anonymizaci použít jak funkce s náhodným generováním znaků tak i funkce používající slovníky. V tomto případě je ale s ohledem na srozumitelnost výsledku lepší variantou použití slovníkových funkcí. Výsledná data pak vypadají mnohem více reálná. Funkce by měla mít pro každou položku vlastní slovník a musíme zde ale nadefinovat, z jakých částí se má výsledná hodnota skládat, aby co nejvíce odpovídala původní struktuře dat. Chytřejší funkce by pak mohla rozpoznávat pohlaví osoby dle dalšího parametru a na jeho základě pak pracovat jen se jmény, která odpovídají rozpoznamému pohlaví.

1.3.2

Rodné číslo[1]

Rodné číslo slouží k jednoznačné identifikaci osoby v rámci České republiky. Jeho specifikace je uvedena v předpisu č. 302/2004 Sb. §13. Jednotlivé části rodného čísla zobrazuje tabulka 1.3. 31

1. Teoretická část „(3)Rodné číslo je desetimístné číslo, které je dělitelné jedenácti beze zbytku. První dvojčíslí vyjadřuje poslední dvě číslice roku narození, druhé dvojčíslí vyjadřuje měsíc narození, u žen zvýšené o 50, třetí dvojčíslí vyjadřuje den narození. Čtyřmístná koncovka je rozlišujícím znakem obyvatel narozených v tomtéž kalendářním dnu. (4)Rodná čísla přidělená fyzickým osobám narozeným před 1. lednem 1954 mají stejnou strukturu jako rodná čísla uvedená v odstavci 3, jsou však devítimístná s třímístnou koncovkou a nesplňují podmínku dělitelnosti jedenácti. (5)V případě, že jsou výdejovými místy rodných čísel (dále jen "výdejové místo") pro daný kalendářní den v příslušném kalendářním roce vyčerpána veškerá určená rodná čísla, určí ministerstvo pro tento den novou, dodatečnou sestavu rodných čísel, pro niž platí, že rodné číslo je desetimístné číslo, které je dělitelné jedenácti beze zbytku. První dvojčíslí vyjadřuje poslední dvě číslice roku narození, druhé dvojčíslí vyjadřuje měsíc narození, u mužů zvýšené o 20, u žen zvýšené o 70, třetí dvojčíslí vyjadřuje den narození. Čtyřmístná koncovka je rozlišujícím znakem obyvatel narozených v tomtéž kalendářním dnu.“[1] Z výše uvedených pravidel existují ještě další výjimky. Do roku 1985 bylo přiděleno cca 1000 rodných čísel, která nejsou dělitelná 11. Jde o čísla, u kterých je výsledek operace modulo roven číslu 10. Jako kontrolní číslice se v tomto případě použila 0 a celé číslo pak není beze zbytku dělitelné 11. Vydávání těchto čísel bylo zrušeno v roce 1985. Druhá výjimka spočívá v tom, že i rodná čísla před rokem 1954 mohou obsahovat 10 cifer. A to v případě, pokud se jednalo o dodatečně přidělená rodná čísla. (např. při získání občanství). Vzhledem tomu, že jsou v rodném čísle uvedeny pouze poslední dvě cifry roku narození, nelze rozlišit století ani tisíciletí narození. Pokud bude tento formát rodného čísla zachován beze změny i po roce 2054 přestane být rodné číslo jednoznačným identifikátorem. Pozice 1-2 3-4 5-6 7-9 10

Význam Rok narození Měsíc narození Den narození Pořadí v daném dni Kontrolní číslice

Tabulka 1.3: Struktura rodného čísla

32

1.3. Typy dat Postup generování rodného čísla • Vygenerujeme první 2 cifry odpovídající roku narození z intervalu S h00,aktuální rok−1i h54, 99i. Pokud bychom neomezili interval, mohli bychom vygenerovat rodné číslo ještě nenarozené osoby. • Cifry 3 a 4 vygenerujeme z intervalu h01, 12i. V tomto kroku lze ovlivnit pohlaví, pro které bude výsledné číslo vygenerováno. Ponecháním výsledku beze změny nebo přičtením hodnoty 20 dostaneme mužské rodné číslo, přičtením hodnoty 50 nebo 70 dostaneme rodné číslo určené ženám. • Cifry 5 a 6 vygenerujeme z intervalu h01,počet dní v měsícii. Funkce musí zajistit, aby se do rodného čísla nedostal neexistující den (například 30. únor). Funkce by také měla ošetřit přestupné roky. • Vygenerujeme první tři cifry koncovky. Zde je jediná nepřípustná hodnota „000“. K dispozici je interval h001, 999i. • Všechny části poskládáme za sebe v pořadí, v jakém byly generovány. Celé číslo se pak vydělí 11 a zbytek po dělení se použije jako kontrolní číslice (poslední znak koncovky). V případě, že by se výsledek kontrolní číslice rovnal 10, musíme se vrátit k předchozímu bodu a zopakovat výpočet koncovky rodného čísla. Dle odstavce 1.3.2 postupně vygenerujeme jednotlivé části rodného čísla. Vygenerované části zobrazuje tabulka 1.4. rok 85

měsíc 07

den 15

pořadí 123

Tabulka 1.4: Generování rodného čísla Spojením jednotlivých částí z tabulky 1.4 dostaneme hodnotu 850715123. Z té na závěr vypočteme kontrolní číslici. (850715123 mod 11) = 5 Výsledné vygenerované rodné číslo má tedy následující hodnotu: 8507151235. 33

1. Teoretická část

1.3.3

Identifikační číslo osoby (IČO)[5], [23]

Identifikační číslo osoby slouží k jednoznačné identifikační ekonomického subjektu. Musí ho mít přidělené každá právnická, podnikající fyzická osoba i organizační složky státu. Výjimkou jsou fyzické osoby vykonávající duševní nebo tvůrčí činnost podle autorského zákona, která nenaplňuje znaky podnikání podle obchodního zákoníku, a fyzické osoby provádějícím zprostředkovatelskou činnost pro stavební spořitelny. Tyto osoby se identifikují rodným číslem. IČO je osmimístné číslo, jehož poslední cifra je kontrolní číslice. Vzhledem k tomu, že některé fyzické osoby namísto identifikačního čísla používají rodné číslo, musíme se tomu přispůsobit i v databázi. Nejjednodušší varianta je použít jeden sloupec pro IČO i rodné číslo a v jiném sloupci mít uloženou informaci o typu identifikátoru. Postup generování IČO Náhodně vygenerujeme prvních sedm cifer. 1, 8, 5, 3, 6, 9, 0 Vygenerované cifry postupně vynásobíme odpovídajícími hodnotami ni , které jsou uvedeny v tabulce 1.5. i IČOi ni = 9 − i hi = IČOi ∗ ni

1 1 8 8

2 8 7 56

3 5 6 30

4 3 5 15

5 6 4 24

6 9 3 27

7 0 2 0

Tabulka 1.5: Výpočet IČO Podle následujícího vzorce dopočítáme zbytek po dělení 11. z=

7 X

hi mod 11

i=1

V tomto bodě mohou nastat následující tři varianty na jejichž základě určíme výslednou kontrolní číslici x. z = 0 ⇒ x = 1, z = 1 ⇒ x = 0, z ∈ h2, 10i ⇒ x = 11 − z Pro uvedené hodnoty bude výpočet vypadat následovně: 34

1.3. Typy dat

z = (8 + 56 + 30 + 15 + 24 + 27 + 0) mod 11 z = 6 ⇒ x = 11 − 6 x=5 Výsledné vygenerované IČO má tedy následující hodnotu: 18536905.

1.3.4

DIČ[8]

Daňové identifikační číslo (DIČ) slouží k jednoznačné identifikaci plátce daně. Zákon č.337/1992 Sb. §33 specifikuje daňové identifikační číslo následujícím způsobem. „Daňové identifikační číslo obsahuje kód "CZ"a kmenovou část, kterou tvoří obecný identifikátor. Obecným identifikátorem je u fyzické osoby rodné číslo, popřípadě jiný obecný identifikátor, stanoví-li tak zvláštní zákon, a u právnické osoby identifikační číslo. Není-li obecný identifikátor daňovému subjektu přidělen, přidělí správce daně vlastní identifikátor.“[8] Postup generování DIČ Pro výpočet DIČ použijeme postupy uvedené v odstavcích, IČO 1.3.3 a rodné číslo1.3.2. Podle typu subjektu vybereme požadovanou funkci. Pro fyzickou osobu budeme generovat rodné číslo a pro ostatní subjekty IČO. Jako poslední krok před vygenerovanou hodnotu připojíme řetězec „CZ“.

1.3.5

Adresa

Adresa je údaj, podle kterého by měl být člověk fyzicky dohledatelný. Existuje několik druhů adres, například jeden člověk může mít adresu trvalého pobytu, korespondenční adresu, ... Adresu trvalého pobytu musí mít každý z nás, je uvedena v občanském průkazu a existuje databáze všech osob žijících v ČR. V rámci projektu eGoverment v ČR vznikl Systém základních registrů. Jedním ze základních registrů je Registr územní identifikace, adres a nemovitostí - RUIAN. V tomto registu jsou vedena všechna známá adresní místa v ČR a od 1. července 2012 slouží jako náhrada registru UIR-ADR. Adresa se skládá z několika údajů. Patří mezi ně ulice, číslo popisné, číslo orientační, název obce, název části obce, a poštovní směrovací číslo. Údaje, které by měla adresa obsahovat, specifikuje norma ČSN 01 6910[29]. 35

1. Teoretická část Poštovní směrovací číslo (PSČ): PSČ slouží k jednoznačné identifikaci adresy pro doručování zásilek. Případně může být PSČ přiděleno organizaci (takzvaný P.O.BOX). PSČ bylo zavedeno kvůli potřebě automatizace třídění poštovních zásilek. V České republice je poštovní směrovací číslo pěti místné číslo. Zpravidla se uvádí ve tvaru „xxx xx“. Aktuální číselník existujících směrovacích čísel je zveřejněn na webu České pošty společně s odpovídajícími poštami. První cifra určuje kraj, další číslice identifikují obec, část obce až jednotlivé obvody. Tabulka 1.6 ukazuje základní rozdělení podle krajů. První cifra PSČ 1 2 3 4 5 6 7

Kraj Praha Středočeský kraj Jihočeský a Západočeský kraj Severočeský kraj Východočeský kraj a části Jihomoravského kraje Jihomoravský kraj Severomoravský kraj

Tabulka 1.6: Rozdělení PSČ podle krajů

Obec: Pro účely adresy můžeme obec specifikovat jako část obydleného území. Název obce není unikátní, v ČR existuje velké množství obcí se stejným názvem. V datech se většinou vyskytuje v samostatném sloupci. Často se ale vyskytují i další varianty. Například může být v jednom sloupci obec spojena s částí obce. Tato varianta pak vypadá například takto „Praha 9 - Prosek“. Další možností je uložení společně s číslem popisným. V tomto případě jde převážně o menší obce, které nejsou dělené do menších celků jako jsou části obce a ulice. V datech pak tato varianta může vypadat následovně „Nová Ves 33“. Část obce: Tento pojem je specifikován v zákoně o obcích 128/2000 Sb. §27. „Část obce je evidenční jednotka vytvářená budovami s čísly popisnými a čísly evidenčními přidělenými v jedné číselné řadě, která leží v jednom souvislém území. Názvy částí obce jsou zpravidla převzaty z názvu zaniklých obcí, osad nebo z názvů historicky vzniklých území, na nichž se tyto části obce nacházejí.“[6] 36

1.3. Typy dat V datech se tento údaj používá většinou u větších obcí. Často je pro něho vyhrazen samostatný sloupec. Pokud pak obec nemá žádnou část, zůstává udaj nevyplněný. Další variantou je sloučení části obce s obcí do jednoho sloupce jak je uvedeno v odstavci 1.3.5. Ulice, číslo popisné, číslo orientační: Ulice je komunikace v zastavěné části obce. Jednotlivé objekty v ulici jsou identifikovány pomocí čísla popisného a čísla orientačního. Číslo popisné se přiděluje z číselné řady v rámci katastrálního území. Čísla orientační označují objekt v rámci ulice a nejsou povinná. V datech se opět můžeme setkat s několika způsoby uložení těchto hodnot. • Ulice je uložena společně s číslem popisným i orientačním do jednoho sloupce. V tomto případě se většinou používá formát „Název ulice č.o./č.p.“. Zde je příklad takového zápisu „Poštovní 123/5“. • Ulice je uložena v samostatném sloupci, číslo popisné je uloženo společně s číslem orientačním. • Pro každý údaj je vyhrazen samostatný sloupec. Souřadnicový systém: Alternativní způsob zadání adresního místa je využití souřadnicového systému. Tento údaj je například společně s ostatními uvedenými veden v registru RÚIAN, který je veřejně dostupný. Je zde použit formát S-JTSK[31]. Tento souřadnicový systém lze jednoznačně převést do systému WGS84, který používá například technologie GPS.

1.3.6

Číslo účtu[4]

Definici čísla účtu nalezneme ve vyhlášce č. 169/2011 Sb. „(1) Číslo účtu je jedinečným identifikátorem podle § 2 odst. 3 písm. h) zákona o platebním styku, který slouží v platebním styku k jednoznačné identifikaci účtu klienta vedeného poskytovatelem platebních služeb působícím v České republice, který užívá pro tento účet číslo v souladu s mezinárodní normou).“[4] „Číslo účtu v národním formátu je tvořeno identifikátorem účtu klienta (§ 5) a kódem platebního styku (§ 6).“[4] 37

1. Teoretická část „První a druhá část identifikátoru účtu klienta v čísle účtu v národním formátu musí být v písemné podobě zřetelně odděleny.“[4] „Kód platebního styku obsahuje 4 číselné znaky a musí být od identifikátoru účtu klienta v písemné podobě zřetelně oddělen.“[4] Číslo účtu může mít maximálně 16 číslic, a to bez kódu platebního styku. Pro první část (předčíslí) je to maximálně 6 číselných znaků. Pro druhou část to je minimálně 2 a maximálně 10 číselných znaků. Jednotlivé části čísla účtu se od sebe zpravidla oddělují znakem „-“. Kód platebního styku (kód banky) se od čísla účtu odděluje znakem „/“. V databázích se většinou setkáme s číslem účtu uloženým jako celek, tzn. předčíslí, číslo účtu i kód banky v jednom sloupci. Může být ale i rozděleno po jednotlivých částech. Algoritmus pro výpočet čísla účtu Algoritmus je popsán v příloze k vyhlášce č. 169/2011 Sb. „První část a druhá část identifikátoru účtu klienta se vytvářejí tak, aby každá samostatně vyhovovala kontrolnímu algoritmu s váhami uvedenými v následující tabulce: Číslice části identifikátoru n Váhy

A 10 6

B 9 3

C 8 7

D 7 9

E 6 10

F 5 5

G 4 8

H 3 4

I 2 2

J 1 1

Tabulka 1.7: Váhy pro kontrolní algoritmus čísla účtu kde n je pozice číslice v příslušné části identifikátoru účtu klienta (počítáno zprava). Váhy se k číslicím na jednotlivých pozicích příslušné části identifikátoru účtu klienta přiřazují zprava. Příslušná část identifikátoru klienta ABCDEFGHIJ je správně vytvořena, pokud je součet S beze zbytku dělitelný 11, přičemž S = J ∗ 1 + I ∗ 2 + H ∗ 4 + G ∗ 8 + F ∗ 5 + E ∗ 10 + D ∗ 9 + C ∗ 7 + B ∗ 3 + A ∗ 6 .“[3] Postup generování čísla účtu Náhodně vygenerujeme délku čísla účtu n v rozsahu 2 − 10. n=8 38

1.3. Typy dat Následně vygenerujeme n − 1 číselných znaků. 1357890 Výsledek doplníme zprava nulami do délky 10 − 1 cifer 001357890 a výsledek následně namapujeme do tabulky 2.1, ze které vynecháme poslední číslici (J). Číslice části identifikátoru n Váhy

A 0 10 6

B 0 9 3

C 1 8 7

D 3 7 9

E 5 6 10

F 7 5 5

G 8 4 8

H 9 3 4

I 0 2 2

Tabulka 1.8: Váhy pro kontrolní algoritmus čísla účtu Z tabulky následně dosadíme do vzorce, ve kterém vynecháme pozici J: S = I ∗ 2 + H ∗ 4 + G ∗ 8 + F ∗ 5 + E ∗ 10 + D ∗ 9 + C ∗ 7 + B ∗ 3 + A ∗ 6 S = 0 ∗ 2 + 9 ∗ 4 + 8 ∗ 8 + 7 ∗ 5 + 5 ∗ 10 + 3 ∗ 9 + 1 ∗ 7 + 0 ∗ 3 + 0 ∗ 6 S = 219 Vypočítáme zbytek po dělení 11: z = S mod 11 z = 219 mod 11 z = 10 V tomto bodě mohou nastat následující tři varianty na jejichž základě určíme cifru J. z ∈ h2, 10i ⇒ J = 11 − z, z = 0 ⇒ J = 0, z = 1 ⇒ Musíme vygenerovat nové číslo. V našem případě je to J = 11 − z, J = 11 − 10, J = 1 Výsledné číslo účtu tedy bude 0013578901. Pro předčíslí účtu by postup vypadal naprosto stejně s tím rozdílem, že jeho maximální délka je 6 cifer namísto 10. Jako kód banky je možné vygenerovat libovolné 4 ciferné číslo nebo ho náhodně vybrat ze slovníku s existujícími kódy.

1.3.7

IBAN[28]

„IBAN (International Bank Account Number) je formát čísla účtu definovaný mezinárodní normou ISO 13616. 39

1. Teoretická část IBAN má následující strukturu: • 2 znaky - kód země (CZ pro Českou republiku) • 2 znaky - kontrolní číslice - umožňuje programovou kontrolu čísla ochrana proti chybně zadanému číslu účtu (např. z důvodu překlepu) • Max. 30 znaků - kód banky a číslo účtu v rámci banky Číslo účtu ve formátu IBAN má dvě podoby - elektronickou (bez mezer) a písemnou (s mezerou za každou čtveřicí znaků pro lepší orientaci)“[28]

1.3.8

Telefonní číslo[2]

Telefonní číslo slouží k jednoznačné identifikaci účastníka v telefonní síti. Mezinárodní formát telefonního čísla je specifikován v doporučení E.164 ITU - International Telecommunication Union. „Předepsaná struktura mezinárodních telekomunikačních čísel účastníků geografických oblastí je následující:[30]“

Obrázek 1.3: Formát telefonního čísla Číslo země (CC) přidělené ČR je 420. „Národní (významové) číslo ve veřejných mobilních telefonních sítích ČR má jednotnou délku 9 číslic. Účastnické číslo (SN) má délku 6 až 7 číslic. Výjimku tvoří pouze čísla začínající „1“, „01“ (doplňkové telefonní služby), které mohou mít kratší délku, avšak minimálně 3 číslice (viz Příloha B).“[30]

1.3.9

E-mailová adresa[10]

Formát emailové adresy je specifikován v RFC 5322 Internet Message Format[10], které aktualizuje původní RFC 822 Standard for the Format of ARPA Internet Text Messages[11] tak, aby byla zohledněna současná praxe a přírůstkové změny, které byly uvedeny v jiných dokumentech RFC. 40

1.3. Typy dat Emailová adresa se dělí na dvě části. Oddělovačem je znak „@“. Lokální část: V této části adresy se mohou vyskytovat následující znaky.: • Znaky veklé a malé abecedy (a–z, A–Z) (ASCII: 65–90, 97–122). • Číslice 0 - 9 (ASCII: 48–57). • Znaky ASCII: 33, 35–39, 42, 43, 45, 47, 61, 63, 94–96, 123–126. • Znak tečka (ASCII: 46) nesmí být na začátku adresy a také nesmí být použit vícekrát po sobě. • Speciální znaky (ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91–93) jsou povoleny s restrikcemi. Speciální znaky jsou povoleny za předpokladu, že jsou uzavřeny v uvozovkách. Například tato emailová adresa je stále platná "()<>[]:,;@!#$%&’*+/=?_ {}"@domain.cz. Doménová část: Druhá část emailové adresy je klasické doménové jméno. Někdy může být nahrazeno i IP adresou uzavřenou do hranatých závorek „address@[192.168.0.1]“. V obou částech adresy je povoleno používání komentářů. Komentář je řetězec uzavřený v kulatých závorkách. Komentáře se mohou vyskytovat na začátku a na konci každé části adresy. Například tato adresa je stále validní „(c1)local(c2)@(c3)domain(c4).(c5)cz(c6)“, a je ekvivalentní s adresou „[email protected]“. Následující adresa už ale validní není, komentář nesmí být uprostřed „local(comment)[email protected]“.

1.3.10

Další osobní a citlivé údaje

Mezi citlivé údaje lze zařadit velké množství dalších údajů. Většinou to jsou informace o náboženském vyznání, příslušnosti k různým skupinám, sektám nebo hnutím. Zneužitelné však mohou být i údaje jako je například rodinný stav, věk, sexuální orientace, povolání nebo dokonce i informace o pohlaví.

41

Kapitola

Dostupné nástroje V této kapitole se pokusím popsat existující nástroje určené k datovým řezům a anonymizaci. Některé nástroje podrobněji popíši a pokusím se shrnout klady a zápory každého z popsaných nástrojů. V poslední části této kapitoly tyto nástroje porovnám a vyhodnotím jejich celkovou použitelnost. V této kategorii softwaru je výběr poměrně omezen. Jedná se o velmi specifickou kategorii uživatelů. Většina existujících řešení je placená a také testovací trial verze není dostupná ke každému produktu. Proto zde budu popisovat jen ty nástroje, u kterých lze získat minimálně trial licenci.

2.1

Data Masking Suite

Výrobce: Orpheus GmbH Web produktu: http://www.data-masking-tool.com/ Tento nástroj umožňuje pouze anonymizaci. Free licence se vztahuje jen na tabulky do 500 záznamů a maximálně dva datové zdroje, nad tento limit už je třeba jedna z vyšších placených verzí. Další omezení free verze je vytvoření pouze jednoho projektu. Instalace: Během instalace nenastal žádný problém. Společně s aplikací se nainstaloval i Access runtime environment, bez kterého by aplikace nefungovala. Celá aplikace je vytvořena v prostředí Microsoft Access. Dokumentace: K dispozici je dokument s popisem základních funkcí aplikace „A quick how to guide“[22]. Je zde uveden jen hodně stručný popis jednotlivých oken aplikace a možných akcí v daném okně. 43

2

2. Dostupné nástroje Práce s nástrojem Uživatelské prostředí je poměrně jednoduché (obr. 2.1), nicméně uživatelská přívětivost není příliš vysoká. Nejvíce mi práci znepříjemňoval layout aplikace, který je pevně nastavený na poměrně vysoké rozlišení. Na menším display se pak musí velmi často rolovat. Připojení k databázi: Nástroj podporuje načtení dat ze souborů MS Excelu, MS Accessu a CSV souborů. Dále je zde možnost připojení na Sharepoint. Další datové zdroje jsou k dispozici přes rozhraní ODBC. Možnosti výstupního připojení jsou téměř shodné se vstupním, chybí zde pouze možnost exportu dat na Sharepoint. Import tabulek v tomto případě znamená opravdu stažení celé vybrané tabulky do interní databáze aplikace. Tento proces může při velkých oběmech dat trvat poměrně dlouho. Při importu tabulek z Excelu, Accesu i CSV souboru, proběhlo vše v pořádku. Problémy nastaly až při pokusu o import tabulek z Oracle serveru přes rozhraní ODBC. Ve výpisu tabulek ze serveru se nezobrazuje vše. Abecední výpis zobrazených tabulek je omezen odhadem na 1000 položek (obr. 2.2). Tabulky, které jsem chtěl anonymizovat, se ve výpisu nezobrazily vůbec, většina zobrazených tabulek patřila systémovým vlastníkům jako jsou exfsys, olapsys a další. Při připojení přes jiného uživatele, který je abecedně zařazen před ostatními vlastníky se podařilo požadované tabulky zobrazit ve výpisu. Import vybraných tabulek se ale ani v tomto případě nepodařil. Zajímavé ale je, že systémové tabulky se importovat podařilo. Nastavení pravidel: Nejprve se vytvoří nový projekt. Do projektu se naimportují tabulky (stahují se celá data). V každé tabulce se označí sloupce, které se mají anonymizovat a následně se u nich vybere způsob anonymizace a případné další parametry (obr. 2.3). Pokud je vše nastaveno, může se provést operace anonymizace. Poté je ještě potřeba anonymizovaná data exportovat zpět do vybraného datového zdroje, ten může být odlišný od zdrojového. Export dat proběhl bez problémů do všech datových zdrojů, dokonce i na Oracle server přes rozhraní ODBC. Po dokončení anonymizace stále v projektů zůstávají uložena jak původní tak anonymizavaná data do doby než odstraníme celý projekt. To může být v mnoha případech poměrně velká bezpečnostní mezera. Použití nástroje bych směřoval spíše k anonymizaci samostatně stojících tabulek. Vůbec se zde neřeší vazby mezi tabulkami a tak může dojít k různé 44

2.1. Data Masking Suite anonymizaci sloupců, které jsou zahrnuty do primárních a cizích klíčů a porušit tím vazby mezi tabulkami.

Obrázek 2.1: Data Masking Suite - ukázka prostředí

Obrázek 2.2: Data Masking Suite - Přidání tabulky 45

2. Dostupné nástroje

Obrázek 2.3: Data Masking Suite - Nastavení pravidel

2.2

Solix EDMS Standard Edition

Výrobce: Solix Technologies, Inc. Web produktu: http://www.solix.com/solix-edms-se/data_masking_se.php Tento nástroj je určen převážně k anonymizaci dat. Navíc obsahuje funkcionalitu pro validaci dat. Tento popis se zaměřuje pouze na funkcionalitu anonymizace. V rámci free licence lze maskovat maximálně 10 sloupců. Instalace: Aplikace je k dispozici ve formě zip archivu. Po jejím rozbalení se spouští skript, který nastartuje vlastní lokální webový server a zobrazí v prohlížeči úvodní stránku. Veškeré požadavky na systém jsou uvedeny v instalační příručce[24]. Dokumentace: K aplikaci je k dispozici velmi propracovaný manuál[25]. Na více jak 150 stranách jsou popsány všechny důležité funkce nástroje doplněné vždy o náhled okna, kterého se popis týká. Práce s nástrojem Připojení k databázi: Ve free verzi je k dispozici možnost připojení se na Oracle, Microsoft SQL Server a Sybase ASE databázi. Pro testování jsem použil databázi Oracle. Připojení proběhlo naprosto bez problémů. Pro zpříjemnění práce s připojením je zde k dispozici uživatelský profiler, kde je možné připojení vytvářet, editovat a mazat. (viz. obr. C.1 a C.2) Vytvořené profily připojení je pak možné kdykoliv v budoucnu bez jakéhokoliv dalšího zásahu použít. V průvodci na obrázku C.2 se nejprve vybírá připojení cílové databáze. 46

2.2. Solix EDMS Standard Edition Zdrojová databáze se vybírá následně až v okně s výběrem tabulek (obr. 2.4). Výběr tabulek Výběr tabulek je v případě rozsáhlých databází velmi zdlouhavý. Tabulky, se kterými chceme dále pracovat, se musí vybírat po jedné (viz obr. 2.4). Nepříjemné je i to, že po přidání nové tabulky musíme znovu vybrat vlastníka, aby bylo možné přidat další tabulku. Dále lze u každé tabulky zobrazit její sloupce. Je zde možnost dodatečně editovat, které sloupce patří do primárního klíče. Tabulku, která nemá primární klíč, nelze anonymizovat bez dotatečného označení některého z jejich sloupců jako primární klíč. Takto označené sloupce pak ale nelze dále anonymizovat. Nastavení pravidel: Obrázek 2.5 ukazuje okno určené k nastavení pravidel. V horní části okna se postupně vybere tabulka, sloupec, typ operace a konkrétní funkce. Tlačítkem „Add“ se pravidlo přidá do seznamu. K dispozici jsou následující typy operací: • Nahrazení všech hodnot konstantou, • šifrování/ dešifrování, • maskování dat (k dispozici je velké množství funkcí dle datového typu sloupce), • nahrazení všech hodnot hodnotou NULL, • náhodné zamíchání hodnot v rámci jednoho sloupce, • Truncate data (Odstraní všechna data z tabulky). Po nastavení pravidel je možné set pouze uložit nebo ho uložit a rovnou spustit (obr. 2.6). Jednotlivé sety pravidel je možné dále seskupovat pod další vytvořené sety pravidel. K dispozici je i jednoduchý plánovač, přes který lze úlohu naplánovat na určitý datum a čas. Ke každé naplánované úloze lze přidat pouze jeden set pravidel. To ale ničemu nevadí díky možnosti seskupování setů. Další příjemnou funkcí je možnost importu a exportu pravidel. Ty se ukládají ve formátu xml. Aplikace umožňuje práci více uživatelů s různě nadefinovynými právy. Těch je na výběr velké množství. Jeden uživatel například může pouze definovat pravidla ale už nemusí mít oprávnění je spouštět.

47


Obrázek 2.4: Solix EDMS - Výběr tabulek

Obrázek 2.5: Solix EDMS - Nastavení pravidel 48

2.3. Camouflage

Obrázek 2.6: Solix EDMS - Seznam Pravidel

2.3

Camouflage

Výrobce: Camouflage Software Inc. Web produktu: http://www.datamasking.com/solutions/products/datamasking Nástroj primárně slouží k anonymizaci dat. Součástí nástroje je i funkcionalita datových řezů, ta ale bohužel není dostupná v demo verzi. Demo licence je platná 15 dní od registrace na webu produktu. Instalace: Instalace probíhá přes klasického instalačního průvodce. Během instalace se zobrazí výzva k výběru licenčního souboru. Dále je možné zvolit jdbc ovladače, které se nainstalují společně s aplikací. K dispozici jsou zde ovladače pro ORACE 9, 10 a MS SQL server 2005, 2008. Celý proces instalace nástroje je popsán v přehledné instalační příručce[14]. Dokumentace: Dokumentace k nástroji je přehledná a obsahuje podrobný popis všech funkcí aplikace [15]. Práce s nástrojem Po spuštění aplikace se objeví hlavní okno (obr. 2.7) a okno logu (obr. C.4), kam se vypisují všechny zprávy. Nejprve je nutné vytvořit nový projekt a k němu nadefinovat připojení k databázi. Bez těchto kroků nelze pokračovat žádnou jinou akcí. V nástroji se namísto pojmu „maskování dat“ používá pojem „transformace“. 49

2. Dostupné nástroje Připojení k databázi: Pro vytvoření připojení je k dispozici jednoduchý profiler (obr. C.5). Většinu hodnot automaticky předvyplňuje a na uživateli je jen doplnit vlastní hodnoty. Připojení lze vytvořit více (obr. C.6) a pak už jen vybírat požadované. Samozřejmostí je možnost ověření úspěšného připojení. Dále je zde možnost procházení dat v databázi přes integrovaný prohlížeč (obr. C.3).

Výběr tabulek a nastavení transformačních pravidel: K dispozici je velké množství předpřipravených transformací. Nástroj nabízí i možnost vytvářet nová transformační pravidla. Výběr tabulek se provádí přímo v okně s nastavením transformačních pravidel (obr. 2.8). Součástí každého transformačního pravidla je vždy celá tabulka. U pravidla se vždy definuje, které sloupce budou do transformace zahrnuty. Pro každou tabulku můžeme vytvořit více transformačních pravidel a tím docílit toho, aby byla použita různá pravidla nad jednou tabulkou.

Tento nástroj jako první z uvedených podporuje anonymizaci přes primární a cizí klíče. Zatržením volby „Cascade“ u sloupce je řečeno, že stejný způsob anonymizace se má použít i na sloupce z tabulek spojených touto relací. V nástroji je dokonce možné vazby nadefinovat ručně. To se hodí v případě, kdy jsou vazby tabulek řešeny až na úrovni aplikační logiky a ne přímo v databázi.

V každém transformačním pravidlu lze dále nastavit filtr (obr. 2.9) a omezit tak výslednou množinu anonymizovaných dat. Filtr se zadává formou SQL where klauzule.

Po nastavení všech pravidel lze zvolit, které operace chceme nad databází provést (obr. 2.10). Pak už zbývá jen vybrané operace spustit.

Tento nástroj poskytuje opravdu komplexní možnosti pro nastavení anonymizace a výčet všech jeho funkcí je opravdu dlouhý. Pro hlubší seznámení s nástrojem doporučují velice dobře zpracovanou dokumentaci[15]. 50

2.3. Camouflage

Obrázek 2.7: Hlavní okno

Obrázek 2.8: Nastavení pravidel 51


Obrázek 2.9: Filtr

Obrázek 2.10: Spuštění 52

2.4. Data Masker For Oracle

2.4

Data Masker For Oracle

Výrobce: Net 2000 Ltd. Web produktu: http://www.datamasker.com/index.html Tento nástroj je určen k anonymizaci. Trial licence je omezena na 30 dní. Instalace: Instalace probíhá formou průvodce. V jednom z kroků průvodce je možné zvolit komponenty, které se budou instalovat. Mezi ně patří například soubory nápovědy, ukázkové příklady, tutoriály a další. Během instalace nenastal žádný problém. Dokumentace: V instalačním adresáři nástroje je dostupný manuál v podobě HTML stránek. Vždy, když je stisknuto tlačítko help v nějakém okně nástroje, tak se v internetovém prohlížeči zobrazí odpovídající stránka manuálu. K dispozici je zde ještě několik tutoriálů, ve kterých je přehledně ukázána práce s nástrojem. Tyto tutoriály jsou dostupné i online[20]. Práce s nástrojem Základem jsou v tomto nástroji takzvané sety. Každý set je kolekce pravidel společně s informacemi o tabulkách obsažených v databázi a také s informacemi o připojení. Hlavní okno aplikace se skládá z několika záložek (obr. 2.11). Na každé záložce je přehledná tabulka s obsahem. Pro nás je nejdůležitější záložka „Rules in set“, ve které se nastavují anonymizační pravidla. Ostatní záložky obsahují statistiky, možnosti nastavení a několik dalších užitečných nástrojů. Mezi nejzajímavější z nich patří nástroj pro porovnání načteného schématu vůči databázi, nástroj s náhledem dat a nástroj pro vyhledávání sloupce podle názvu. Připojení k databázi: Připojení k databázi probíhá formou jednoduchého průvodce. Definice tabulek se načítá přímo z databáze. V průvodci lze vybrat tabulky, které budou zahrnuty do dalšího zpracování (setu). Pro běh programu je nutné vytvořit v databázi novou auditovací tabulku, ve které jsou uložena pravidla během provádění procesu anonymizace. Tuto operaci lze jednoduše provést v jednom z kroků průvodce. Do jednoho setu lze zahrnout více zdrojů dat. Všechny úpravy dat se ale provádějí přímo ve zdrojových databázích. Před anonymizací je tedy nutné nejprve vytvořit kopii databáze, která má být anonymizována a nad touto kopií teprve vytvářet sety. 53

2. Dostupné nástroje Nastavení anonymizačních pravidel V každém nově vytvořeném setu jsou předpřipravena dvě pravidla, která slouží k vypnutí triggerů v databázi před anonymizací a jejich opětovnému zapnutí po dokončení anonymizace. Další pravidla se vytváří přes tlačítko „New Rule...“. Zde je na výběr z několika typů pravidel (obr. 2.12). Pravidla jsou zde rozdělena do 3 skupin: • Masking Rules • Utility Rules • Speciality Rules Masking Rules: Tento druh pravidel je určen přímo k maskování dat. V této kategorii nalezneme substitution, shuffle, insertion a search-replace rules. Pro substituční pravidla je zde na výběr velké množství předpřipravených typů dat, kterými lze původní data nahradit (obr. 2.13). „Insertion Rule“ je druh pravidla, který použijeme v případě, kdy máme prázdnou tabulku a potřebujeme ji naplnit nějakým množstvím dat. Jako parametr se zde nastavuje počet vložených záznamů. Ke každému sloupci lze dále vybrat maskovací pravidlo. Seznam maskovacích pravidel je zde shodný jako u substitučních pravidel. Další možností jsou pravidla typu „SearchReplace“. Tento druh pravidla umožňuje nahrazení jen těch záznamů, které odpovídají určitému vzoru. Vyhledávat odpovídající záznamy je možné na základě jedné konkrétní hodnoty, slovníku hodnot nebo regulárního výrazu. K maskování jsou zde k dispozici stejné možnosti jako u substitučních pravidel. Utility Rules: V této kategorii jsou pravidla, která převážně umožňují synchronizovat již zamaskované sloupce s dalšími. „Row-Internal Sync.“ je pravidlo, díky kterému lze složit výraz z libovolných částí stejného záznamu. Například pokud zamaskujeme sloupce FIRST_NAME a LAST_NAME můžeme pomocí tohoto pravidla dosáhnout toho, že do sloupce FULL_NAME vložíme odpovídající hodnotu složenou z předchozích sloupců. Pravidlo typu „Table-Internal Synch.“ umožňuje synchronizovat více sloupců s jiným zamaskovaným sloupcem v rámci jedné tabulky. Dalším užitečným pravidlem je Table-To-Table Synch rule. Díky tomuto pravidlu je možné dosáhnout shodné anonymizace sloupců v různých tabulkách. U tohoto pravidla je nutné specifikovat vazbu, přes kterou jsou záznamy z tabulek spojeny a které sloupce mají být synchronizovány. 54

2.4. Data Masker For Oracle Poslední v této kategorii je typ pravidla umožňující spuštění libovolného PL SQL skriptu.

Speciality Rules: Pravidla v této kategorii slouží k vypnutí či zapnutí omezení tabulek. Je zde možné definovat, která omezení (constraints) budou aktivní a na které nebude brán ohled (obr. C.7). Dále se zde nachází pravidla pro vypnutí a zapnutí triggerů.

Celkově je nástroj velice dobře zpracovaný. Je zde k dispozici velké množství typů dat, kterými lze maskovat původní data. Jako nevýhodu bych viděl snad jen nutnost vytváření kopie databáze před procesem anonymizace.

Obrázek 2.11: Hlavní okno 55


Obrázek 2.12: Nové pravidlo

Obrázek 2.13: Nové substituční pravidlo 56

2.5. Data Bee

2.5

Data Bee

Výrobce: Net 2000 Ltd. Web produktu: http://www.databee.com/ Tento nástroj slouží k datovým řezům. Pochází od stejné společnosti jako předchozí anonymizační nástroj Data Masker For Oracle 2.4. Demo licence je zde omezena na 30 dní. Instalace: Instalace probíhá formou průvodce a je shodná s instalací nástroje Data Masker For Oracle 2.4. Dokumentace: Dokumentace je zde opět řešena stejným způsobem jako v nástroji Data Masker For Oracle 2.4, tzn. formát HTML. Navíc je k tomuto nástroji k dispozici pdf dokument „A Quick Start Guide to the DataBee Software“[19], kde jsou popsány všechny funkce nástroje. Práce s nástrojem Nástroj se skládá ze tří aplikací. Každá z těchto aplikací slouží vždy jen k určité části celého procesu. Aplikace jsou pojmenované následovně: • Set Designer • Set Extractor • Set Loader Všechny aplikace pracují s takzvanými sety. Ty obsahují definice tabulek, jejich propojení, nastavená pravidla a informace o připojení k databázi. Společně s vytvořeným setem se v databázi vytváří několik tabulek nutných pro další zpracování. Existují zde dva druhy setů, které dále popisuji. Připojení k databázi Způsob připojení k databázi je zde opět řešen stejným způsobem jako u předchozího nástroje 2.4. Jediným rozdílem je to, že se v databázi vytváří více tabulek nutných pro chod nástroje. Druhy setů: Oba druhy setů se vytváří v aplikaci Set Designer. Pro jejich následné spuštění už ale každý vyžaduje jinou aplikaci. 57

2. Dostupné nástroje Extraction set: Tento druh setu se používá pro nastavení pravidel, která se aplikují na zdrojová data. Po vytvoření připojení k databázi se v setu automaticky vygenerují pravidla reprezentující vazby mezi tabulkami, a to směrem od cizího klíče k primárnímu. Další vazby lze přidávat přes volbu „Table-To-Table Extraction Rule“ (obr. 2.14). Jako další je zde možné definovat pravidla pro omezení velikosti tabulek. Omezení lze provést pomocí SQL where klauzule nebo omezením počtu záznamů (obr. 2.15). Počet záznamů lze omezit buď zadáním absolutní hodnoty počtu záznamů nebo procentuálním vyjádřením. Poslední druh pravidla je možnost vytvořit PL SQL skript, který se spustí v určené fázi procesu. Loader set: Tento typ setu pracuje s výstupní databází. Zde se definují pravidla, která ovlivňují způsob vytváření kopie dat (obr. 2.16). Je zde možné povolovat nebo zakazovat triggery a omezení cizích klíčů jednotlivých tabulek. Další z pravidel umožňuje provedení operace „Truncate table“ nad vybranými tabulkami. Dále je zde možné definovat PL SQL skript, který se spustí po provedení vybraného pravidla. Pokud chceme vytvořit datový řez v jiné databázi než je zdrojová je nutné vytvořit „Database Link“. Rozdělení nástroje do jednotlivých aplikací Set Designer (obr. 2.17) Tato část nástroje slouží k vytváření výše uvedených setů. Veškerá pravidla se definují zde. Součástí aplikace je i řada užitečných nástroju (obr. C.8). Velice užitečné pro orientaci ve schématu jsou nástroje „Who-Loads-What“ (obr. C.9), „Tree Finder“ (obr. C.10) nebo „Chain Finder“ (obr. C.11). Set Extractor (obr. 2.18) Tato aplikace primárně slouží ke spuštění nastavených pravidel z extarction setu. Pravidla zde lze měnit, nelze už však přidávat nová pravidla, ani provedené změny uložit do setu. Výstupem této aplikace je vytvoření záznamů v tabulkách, které si nástroj vytvořil ve zdrojové databázi. Jejich obsahem jsou indexy záznamů, které mají být přeneseny do výstupní databáze. Set Loader (obr. 2.19) Tato aplikace slouží k přenesení záznamů do cílové databáze. Spouští se zde pravidla vytvořená v loader setu. Stejně jako v předchozí aplikaci lze pravidla upravovat ale není možné přidávat nová a ukládat změny. 58

2.5. Data Bee Celkově nástroj umožňuje přehledné nastavení pravidel. Přehlednosti je zde dosaženo převážně separací různých funkcionalit do samostatných aplikací.

Obrázek 2.14: Nová vazba

Obrázek 2.15: Omezení počtu záznamů 59


Obrázek 2.16: Loader set, Nové pravidlo

Obrázek 2.17: Set Designer 60

2.5. Data Bee

Obrázek 2.18: Set Extractor

Obrázek 2.19: Set Loader 61


2.6

Jailer

Web produktu: http://jailer.sourceforge.net/ Tento nástroj je jako jediný z uvedených zcela zdarma. Nástroj je primárně určen k datovým řezům, nabízí však i určité možnosti jak data zároveň anonymizovat. Instalace: Pro běh nástroje je nutné mít nainstalavné prostředí Java JRE 6 nebo vyšší. Nástroj je distribuován ve formě zip archivu, který lze rozbalit do libovolného adresáře na disku. V adresáři lib jsou uloženy JDBC drivery, které zprostředkovávají připojení k databázi. Součástí instalace je jen několik základních driverů, proto je většinou nutné podle typu databáze stáhnout odpovídající JDBC driver. Dokumentace: Dokumentace k nástroji není téměř žádná. Na stánkách produktu[12] je k dispozici jen velmi stručný popis nástroje a pár krátkých tutoriálů. Jako zdroj informací o nástroji lze dodatečně využít fórum[13], kde je možné nalézt řešené problémy. Práce s nástrojem Připojení k databázi: JDBC driver pro Oracle není součástí instalace. Vzhledem k velkému počtu verzí JDBC ovladačů pro Oracle nějaký čas zabralo dohledání správné verze ovladače. Následně už vše fungovalo bez problémů. Nastavení pravidel Po spuštění se objeví okno, ve kterém lze vybrat existující, nebo vytvořit nový databázový model (obr. 2.20). Po instalaci jsou k dispozici dva demo modely. Model obsahuje informace o tabulkách a vazbách mezi nimy. Tyto informace lze do modelu doplnit buď ručně přes tlačítko „Edit“, nebo je lze stáhnout přímo z databáze (tlačítko „Analyze database“). Stažené informace lze poté editovat. Po vytvoření modelu a jeho výběru lze přejít k samotnému nastavení datových řezů. Hlavní okno aplikace (obr. 2.21) je rozděleno do několika částí: • Nastavení výchozí tabulky pro řez, • zobrazení vazeb mezi tabulkami, 62

2.6. Jailer • nastavení restrikcí k vazbám mezi tabulkami, • grafický náhled datového modelu. Pro nastavení datového řezu je nutné vybrat výchozí tabulku, od které začíná procházení skrz vazby. Výchozí tabulka lze omezit where klauzulí. Veškerá další omezení se nenastavují přímo tabulkám ale vazbám spojujících tabulky. Každé vazbě lze nastavit vlastní where klauzuli. Další možností jak omezit počet záznamů je zakázání některé z vazeb. V grafickém náhledu jsou červeně zvýrazněny vazby směrem od cizího klíče k primárnímu. Zakázáním takovéto vazby lze narušit referenční integritu výsledné databáze. Hodnoty závislé na primárním klíči z této vazby by zůstaly sirotky. Jak již bylo zmíněno na začátku popisu, nástroj poskytuje částečnou podporu pro anonymizaci dat. K tomuto účelu jsou zde takzvané filtry, které jsou dostupné přes menu „Edit/Filter editor...“ (obr. 2.22). Následující text filtru zachová poslední tři znaky z příjmení, které zřetězí za text „abc“. Pro příjmení „Nováková“ by výsledek vypadal „abcová“. REPLACE(PRIJMENI, SUBSTR(PRIJMENI, 1, LENGTH(PRIJMENI) - 3), ’abc’) Výstupem nástroje je insert skript, který obsahuje přímo data načtená ze zdrojové databáze. Součástí výstupního skriptu není DDL. Proto je nutné před spuštěním vygenerovaného skriptu v cílové databázi vytvořit požadovanou strukturu tabulek. Velkou slabinou tohoto nástroje je téměř neexistující dokumentace. Některé části aplikace nejsou vůbec popsány. Vzhledem k OpenSource licenci je ale nástoj zajímavou alternativou ke komerčním produktům.

Obrázek 2.20: Výběr databázového modelu 63


Obrázek 2.21: Hlavní okno nástroje

Obrázek 2.22: Filter Editor 64

2.7. Další nástroje

2.7

Další nástroje

Zde uvádím seznam dalších dostupných nástrojů. K těmto nástrojům se mi nepodařilo získat demo licenci, proto zde uvádím pouze odkazy weby, kde je možné nalézt jejich specifikaci (tab. 2.1). Výrobce: Produkt: Web produktu: Výrobce: Produkt: Web produktu: Výrobce: Produkt: Web produktu: Výrobce: Produkt: Web produktu: Výrobce: Produkt: Web produktu: Výrobce: Produkt: Web produktu:

Innovative Routines International (IRI), Inc. CoSort - SortCL http://www.iri.com/products/CoSort/SortCL Grid-Tools Datamaker™ http://www.grid-tools.com/products/ datamaker.php Direct Computer Resources, Inc. Data Vantage Global® http://www.datavantage.com/products/cs/ index.html Compuware Corporation MainFrame solutions File-AID http://www.compuware.com/mainframe-solutions/ file-aid-data-management.html Oracle Oracle Data Masking http://www.oracle.com/us/products/database/ data-masking/overview/index.html Camouflage Software Inc. Camouflage DATABASE SUBSETTING http://www.datamasking.com/solutions/products/ subsetting Tabulka 2.1: Další nástroje

2.8

Porovnání nástrojů

V této kapitole jsem se zaměřil na porovnání kvality nástrojů převážně na základě jejich uživatelské přívětivosti, dostupnosti a kvality dokumentace a několika daších kritétií. Neporovnávám zde nástroje na základě ceny ani jejich licenčních podmínek. Porovnání je založeno na hodnocení dílčích kritérií, které jsou uvedeny dále. Při porovnávání těchto kritérií vycházím ze 65

2. Dostupné nástroje subjektivního názoru na jednotlivé nástroje. Tato kritéria jsou v závěru této kapitoly vyhodnocena. Hodnocení každého kritéria je v rozsahu 1 - 10, kde 1 znamená nejhorší a 10 nejlepší výsledek. Dále je každému kritériu přiřazena váha, kterou je určena důležitost každého kritéria. Výsledná známka je určena na základě vzorce Y =

n X

Ki ∗ Vi

i=1

kde Y znamená výslednou známku, Ki je hodnotící kritérium a Vi je váha hodnotícího kritéria. Pro porovnání jsem použil základní kritéria hodnotící průběh instalace nástroje, dokumentaci, možnosti připojení k databázi a celkový komfort práce s nástrojem. Instalace nástroje: Instalace je proces, který je nutné provést vždy před prvním použitím nějakého nástroje. Vždy je nutné vykonat nějaké prvotní úsilí ke zprovoznění nástroje. Toto kritérium hodnotí průběh instalaci jako celek. Jsou zde zahrnuty všechny operace, které je nutné provést, k tomu, aby byl nástroj plně zprovozněn. Vzhldem k tomu, že je instalace jednorázový úkon a provádí se s minimální četností v případě potřeby, stanovil jsem váhu tohoto kritéria na hodnotu 0,3. Nástroj Data Masking Suite Solix EDMS Standard Edition Camouflage Data Masker For Oracle Data Bee Jailer

Hodnocení 10 9 10 10 10 6

Vážené hodnocení 3 2,7 3 3 3 1,8

Tabulka 2.2: Porovnání nástrojů - Instalace

Dokumentace: Tímto kritériem hodnotím kvalitu a dostupnost dokumentace k nástrojům. Bez kvalitní dokumentace může být i sebelepší nástroj hůře použitelný než ostatní průměrné nástroje. Pokud uživatel neví, 66

2.8. Porovnání nástrojů jak nástroj použít, může se jednoduše dostat do slepé uličky a nástroj zavrhnout. Z tohoto důvodu je váha tohoto kritéria poměrně vysoká. Její hodnotu jsem stanovil na 0.7. Nástroj Data Masking Suite Solix EDMS Standard Edition Camouflage Data Masker For Oracle Data Bee Jailer

Hodnocení 6 10 10 8 9 4

Vážené hodnocení 4,2 7 7 5,6 6,3 2,8

Tabulka 2.3: Porovnání nástrojů - Dokumentace Připojení k databázi: Do tohoto kritéria jsem zahrnul možnosti související s připojením k databázi. Jde zde převážně o možnost oddělení vstupní a výstupní databáze, možnost uložení připojovacího řetězce pro další použití a dále pak uživatelskou přívětivost všech souvisejících operací. Nehodnotím zde možnosti připojení k datovým zdrojům různého typu. Některé z nástrojů jsou vytvořeny pro konkrétní databázový stroj a byly by tímto značně znevýhodněny. Všechny nástroje jsem testoval nad datovým zdrojem Oracle Database 11g Enterprise Edition. Váhu tohoto kritéria jsem stanovil na hodnotu 0.6. Nástroj Data Masking Suite Solix EDMS Standard Edition Camouflage Data Masker For Oracle Data Bee Jailer

Hodnocení 7 10 10 6 10 9

Vážené hodnocení 4,2 6 6 3,6 6 5,4

Tabulka 2.4: Porovnání nástrojů - Připojení

Práce s nástrojem Toto hodnotící kritérium je zaměřeno na celkový dojem z nástroje. Je zde zahrnuta uživatelská přívětivost, intuitivnost nastavení a další aspekty, které ovlivnily pozitivní či negativní pohled na nástroj. V tomto kritériu jsou částečně zahrnuta i předchozí kritéria. Je zde například hodnoceno vynaložené úsilí nutné k dokončení celého procesu anonymizace či datového řezu nebo doba nutná k vyřešení určité komlikace. A to 67

2. Dostupné nástroje buď vyčtením správného postupu z dokumentace, či nutnosti zkoušet různé kombinace dokud se nedostaví požadovaný výsledek. Toto kritérium je nejvíce ovlivněno subjektivním dojmem z nástroje, proto jsem jeho váhu nastavil na hodnotu 0,5. Nástroj Data Masking Suite Solix EDMS Standard Edition Camouflage Data Masker For Oracle Data Bee Jailer

Hodnocení 6 8 9 9 9 8

Vážené hodnocení 3 4 4,5 4,5 4,5 4

Tabulka 2.5: Porovnání nástrojů - Práce s nástrojem

Dokumentace

Připojení

Práce s nástrojem

Celkové vyhodnocení

Nástroj Data Masking Suite Solix EDMS Standard Edition Camouflage Data Masker For Oracle Data Bee Jailer

Instalace

Celkové vyhodnocení Tabulka 2.6 ukazuje celkový výsledek hodnocení všech uvedených kritérií. Mezi výsledky některých nástrojů jsou značné rozdíly. Tyto rozdíly jsou převážně způsobené kritériem hodnotícím dokumentaci nástroje. V hodnocení nejlépe dopadl nástroj Camouflage, který umožňuje poměrně jednoduchým způsobem nastavit požadované pravidla ale hlavně disponuje velice podrobnou a dobře zpracovanou dokumentací.

3 2,7 3 3 3 1,8

4,2 7 7 5,6 6,3 2,8

4,2 6 6 3,6 6 5,4

3 3 4,5 4,5 4,5 4

14,4 18,7 20,5 16,7 19,8 14

Tabulka 2.6: Porovnání nástrojů - Celkové vyhodnocení

Konfigurace systému: Pro otestování všech nástrojů jsem použil operační systém Windows 7 x64 nainstalovaný jako virtuální stroj v apli68

2.8. Porovnání nástrojů kaci VMware Player. Tomuto stroji bylo přiřazeno jedno jádro CPU Intel(R) Core(TM)2 Duo T9600 2,8GHz a 1GB operační paměti. S touto konfigurací neměl žádný z nástrojů problém, vše fungovalo rychle a bez problémů.

69

Kapitola

Implementace V rámci týmového projektu předmětů SP1 a SP2 vznikl nástroj Winch, který je rozšířením aplikace Enterprise Architect. Na jeho vývoji jsem se podílel s dalšími kolegy. V rámci této práce jsem se následně soustředil na refaktorizaci kódu a dále na uživatelské rozhraní. Mým cílem bylo co nejvíce zpříjemnit nastavení metadat k modelu a upravit prostředí tak, aby umožnilo intuitivní a komfortní práci ale zároveň aby co nejvíce zapadlo do prostředí hostující aplikace Enterprise Architect. Web produktu Enterprise Architect: http://www.sparxsystems.com/ products/ea/

3.1

Popis nástroje Winch

Nástroj slouží k jednoduchému nastavení datových řezů a anonymizace nad datovým modelem. Celý proces se skládá z několika částí. Nejprve je nutné vytvořit datový model a v něm vytvořit strukturu dle popisu v odstavci „Příprava datového modelu“ (3.1). Nad vytvořeným datovým modelem lze následně nastavovat metadata, která představují pravidla pro datové řezy a anonymizaci. Po dokončení nastavení metadat se generuje PL SQL skript, který se následně spouští v anonymizačním a řezacím prostředí. Všechny části procesu jsou dále podrobněji vysvětleny. Vytvoření datového modelu: Tato operace se provádí přímo v aplikaci Enterprise Architect a není závislá na nástroji Winch. Datový model je možné vytvořit „ručně“ tabulku po tabulce a u každé specifikovat sloupce, 71

3

3. Implementace jejich datové typy, klíče, vazby atd. Tento postup je u větších databází velmi pracný a může snadno dojít k chybě. Proto aplikace Enterprise architect nabízí možnost stáhnout datový model přímo z databáze přes ODBC rozhraní. Pro kontrolu datového modelu umožňuje nástroj Winch porovnat vytvořený model v aplikaci Enterprise Architect proti aktuálnímu stavu databáze.

Příprava datového modelu Nástroj Winch pracuje s určitou strukturou objektů v aplikaci Enterprise Architect. Tato struktura je zobrazena na obrázku 3.1. Základem je zde takzvaná aplikace. Ta je tvořena objektem „Package“, který musí mít nastevený stereotyp na hodnotu „aplikace“. Další podmínkou je vytvoření diagramu se se stejným názvem jako má aplikace.

Obrázek 3.1: Požadovaná struktura

Aplikace dále obsahuje schémata. Schéma je „Package“ s nastaveným sterotypem „schema“. Každé schéma může obsahovat libovolný počet tabulek. Schéma, které má být zařazeno do prcesu anonymizace a datových řezů musí být obsaženo v diagramu aplikace (obr.3.2). 72

3.1. Popis nástroje Winch

Obrázek 3.2: Diagram aplikace Nastavení pravidel pro datové řezy a anonymizaci: Samotné nastavení pravidel lze provést dvěma způsoby. První možností je nastavení přímo v aplikaci Enterprise Architect doplněním takzvaných tagů. Tag je rozšiřující mechanizmus UML obsahující název a hodnotu[21]. Ke každému objektu v EA lze doplnit libovolné množství tagů. Pro nastavení datových řezů a anonymizace se používají následující tagy: • anonym.where - Může se vyskytnout u tabulky nebo u sloupce. V obou případech slouží k datovým řezům a obsahuje SQL where klauzuli. Hodnoty ze všech sloupců a tabulky jsou do výstupního skriptu spojeny logickým operátorem AND. • anonym.limit - Tento tag slouží také k datovým řezům. Může se vyskytovat pouze u tabulky a určuje maximální počet záznamů, které budou přeneseny ze zdrojové tabulky. • anonym.order - Vyskytuje se pouze u tabulky a určuje pořadí zpracování tabulky. • anonym.fce - Tento tag slouží k anonymizaci a nastavuje se u sloupců. Jeho hodnota určuje způsob, jakým bude vybraný sloupec anonymizován, případně lze specifikovat další parametr, který řídí anonymizaci vybraného sloupce. K dispozici je několik základních anonymizačních funkcí. Jako hodnota tagu se však nenastavuje přímo funkce, ale anonymizační typ, který odpovídá typu dat. Typem dat může být například jméno, rodné číslo a další. Každý typ dat může obsahovat libovolné množství anonymizačních funkcí. Díky tomu lze jednoduše změnit způsob anonymizace pro určitý typ dat 1.2.2. Při procesu anonymizace je vždy aktivní pouze jedna funkce pro každý anonymizační typ. 73

3. Implementace • anonym.type - Tento tag je pouze pomocný. Lze nastavit pouze u tabulky a specifikuje její typ. Momentálně nástroj umí pracovat se třemi typy tabulek (Datová tabulka, Číselník, Log). • anonym.state - Tento tag je stejně jako předchozí také pomocný. S jeho pomocí mužeme specifikovat v jakém stavu se tabulka nachází. Máme na výběr ze tří stavů (Nenastavená, Rozpracovaná, Dokončená). • owner - Tento tag specifikuje vlastníka tabulky. Na jeho základě jsou tabukly přiřazeny do schémat. Pokud tento tag neexistuje, přiřadí se tabulce nadřazené schéma.

Druhá možnost, jak nastavit pravidla je použití nástroje Winch. Nástroj je integrován do aplikace Enterprise Architect a přes jednoduchou prezentační vrstvu zprostředkovává pohodlné nastavení vyše zmíněných tagů k datovému modelu.

Generování PL SQL skriptu Výstupem nástroje je PLSQL skript, který se následně používá v anonymizačním a řezacím prostředí. Tento skript obsahuje definice pravidel, které byly nastaveny nad datovým modelem.

Spuštění PL SQL skriptu Výsledný skript se spouští v řezacím a anonymizačním prostředí. Toto prostředí obsahuje implementaci anonymizačních funkcí a veškerou aplikační logiku související s provedením požadovaných operací definovaných v PL SQL skriptu. Toto prostředí nemám k dispozici, proto ho nebudu více popisovat.

3.2

Architektura aplikace

Aplikace Enterprise Architect vystavuje COM rozhraní[26] pro přístup ke svým objektům a umožňuje integraci formou rozšíření své funkčnosti. Tohoto rozhraní využívá i nástroj Winch. Pro vývoj nástroje je použit jazyk .NET C# společně s technologií .NET Win Forms. Pro běh nástroje je nutné mít nainstalované rozhraní .NET Framework 4. 74

3.3. Stav projektu při jeho převzetí

3.3

Stav projektu při jeho převzetí

Při převzetí projektu byl addin funkční, nicméně struktura některých částí kódu byla značně nepřehledná a oprava jakýchkoliv chyb obnášela poměrně dost úsilí a času.

3.4

Provedené úpravy

3.4.1

Refaktorizace kódu

V rámci refaktorizace kódu jsem se hlavně zaměřil na přiřazení odpovědnosti správným objektů, ve správných vrstvách aplikace. Nejvíce takovýchto chybných přiřazení odpovědnosti bylo mezi datovou vrstvou a business vrstvou. Zde jsem narážel na situace, kdy business vrstva řešila problémy datové vrstvy. Například se zde řešilo ukládání tagů přímo do EA ale i mnohé další. Třída generátoru byla kompletně přepracována. Původní řešení při operaci generování skriptu přistupovalo přímo do objektů EA a všechny údaje načítalo znovu. V rámci regaktorizace byla business objektům App, SliceTypeTable a AnonymObj implementována metoda „Generate“.

3.4.2

Lokalizace

Jedna z důležitých vlastností přívětivého uživatelského prostředí je jazyková lokalizace. Prostředí WinForms .NET poskytuje poměrně jednoduchou možnost, jak celou aplikaci lokalizovat. Formuláře obsahují vlastnost „Localizable“, která je ve výchozím stavu false. Jejím nastavením na hodnotu true se u formuláře vyrvoří nový resource file pro každý jazyk. Do těchto souborů se pak ukládají texty ovládacích prvků v odpovídajícím jazyce. Některé prvky ale nejsou přímo obsahem formuláře a musí se pro ně použít jiný postup. Jde převážně o message boxy a jiné texty, které se načítají až za běhu programu. Pro tyto texty byl vytvořen speciální resource soubor a třídě Winch byla implementována statická vlastnost ResourceManager. Objekt ResourceManager je napojený na vytvořený soubor zdrojů a obsahuje metodu string GetString(string name); díky které lze po zadání identifikátoru textu „name“ předaného parametrem získat požadovaný překlad. 75

3. Implementace

Obrázek 3.3: Ukázka filtrovacího okna Výchozí jazyk aplikace je angličtina a nástroj je plně lokalizován do češtiny. Výběr jazyka se momentálně řídí nastavením národnostního prostředí Windows. Vše je ale vytvořeno tak, aby se v případě potřeby dala doimplementovat funkcionalita výběru jazyka i za běhu aplikace.

3.4.3

Filtrování zobrazení

Další funkce, která byla v rámci práce implementována je možnost nastavení filtru pro aktuální zobrazení. Uživatel má možnost volby na základě různých možností. • Možnost zobrazit pouze vybranou aplikaci/aplikace, • zobrazit vybrané schéma nebo schémata, • tabulku/tabulky, • sloupec/sloupce, • objekty, které mají nastavenou určitou vlastnost (where klauzuli, order, limit, určitou anonymizační funkci nebo parametr anonymizační funkce). Filtr číselných hodnot, kam patří Order a Limit nad tabulkou lze zatím filtrovat pouze na rovnost. U ostatních filtrů je možné používat regulární výrazy jazyka C#. Ukázka filtrovacího okna viz. (obr. 3.3).

3.4.4

Automatický filtr aplikace

Tato funkce umožňuje uživateli mít zobrazené pouze položky k aplikaci, ve které se zrovna nachází. Výběr aplikace se vyhodnocuje na základě vybraného objektu v project browseru. Od něho se ve stromové struktuře vyhledá nadřazená aplikace a na ní se nastaví filtr. Pokud vybraný objekt nemá žádnou nadřazenou aplikaci, nezobrazí se nic. 76

3.4. Provedené úpravy Tato volba je při spuštění addinu vypnuta. Při velkých datových modelech znatelně zpomaluje práci v EA. Její zapnutí není trvalé a při ukončení a novém spuštění aplikace bude opět neaktivní.

3.4.5

Uživatelské proměnné

Možnost vytvářet uživatelské proměnné značně zpříjemní nastavování v případě, že potřebujeme provést datový řez a chceme omezit více tabulek stejnou hodnotou. Například pokud požadujeme věk osoby větší nebo rovno 65, museli bychom ve všech zainteresovaných tabulkách nastavit následující where klauzuli „age >= 65“. Uživatelské proměnné se nastavují vždy k aplikaci a jejich počet je neomezený. Pro uvedený příklad stačí vytvořit proměnnou s názvem #Age a nastavit jí požadovanou hodnotu. Where klauzule by pak vypadala takto „age >= #Age“. Do proměnné lze také uložit celý výraz. Do where klauzule pak stačí uvést jen název proměnné „#Age“. Where klauzuli samozřejmě musíme nastavit ke všem zainteresovaným tabulkám. Výhodou zde ale je, že hodnota proměnné lze kdykoliv změnit, tudíž změna požadovaného věku ve více tabulkách je pak velice jednoduchý úkol. K nastavení proměnných slouží editor uživatelských proměnných (obr. 3.4), který je dostupný z hlavního menu nástroje a z editačního okna.

Obrázek 3.4: Editor uživatelských proměnných

3.4.6

Typ a stav tabulky

Pro snadnější orientaci v datovém modelu je dobré tabulky rozdělit na několik základních typů a evidovat v jakém stavu (fázi) nastavení se nachází. 77

3. Implementace Podrobnější vysvětlení této problematiky je uvedeno v kapitole 1.2.1. Toto vylepšení umožňuje rozlišovat mezi třemi typy tabulek. U každé tabulky lze dále nastavit stav. Ty jsou k dispozici také tři. Na základě nastavených hodnot můžeme například jednoduše určit, kterými tabulkami bychom se ještě měli zabývat a které jsou již nastaveny. Společně s tímto vylepšením přibyly dva nové tagy anonym.type a anonym.state. Tyto dva tagy lze nastavit přes editační okno nástroje (obr. 3.5). Stav tabulky může nabývat tří hodnot (Unset - nenastavená, Elaborated - rozpracovaná, Completed - dokončená). Pokud u tabulky neexistuje tag anonym.state je její stav vyhodnocen automaticky na základě existence dalších nastavenách tagů. jedná se o tagy anonym.where, anonym.limit a anonym.order. V případě, že není nastaven žádný z uvedených tagů, je stav tabulky vyhodnocen jako Unset, pokud je ale například nastaven tag anonym.where, je stav tabulky vyhodnocen jako Elaborated. Stavy Elaborated a Completed lze vynutit přímo jejich nastavením k tabulce. Výběrem stavu Unset se z tabulky odstraní tagy zmíněné v tomto odstavci. Druhý tag je o něco jednodušší. V případě, že není nastaven, je tabulka vyhodnocena jako datová. V opačném případě se použije nastavená hodnota. Dostupné hodnoty jsou DataTable, List a Log. Na datové tabulky se aplikují pravidla, která vedou k redukci objemu dat. Číselník je typ tabulky, který by měl být přenášen celý a z logu není většinou nutné přenášet žádná data.

3.4.7

Automatické doplňování textů (Autocomplete/Intelisence)

Jazyk C# nabízí základní funkcionalitu umožňující použití autocomplete v textovém poli. Ta je ale značně omezena a pro účely nástroje téměř nepoužitelná. Lze použít pouze k výběru prvního výrazu zadávaného do textového pole a dále pak nelze vůbec použít s textovými poli, které mají nastavenou vlastnost MultiLine na hodnotu true. Tato základní funkcionalita je v nástroji použita pouze u výběru schématu tabulky v editačním okně (obr. 3.5). Vzhledem k potřebě vyššího komfortu práce byl v editačním okně nahrazen ovládací prvek textboxu určený k zadávání where klauzule. Nový ovládavé prvek je schopen zvýrazňovat SQL syntaxi a po zadání názvu tabulky nabízet seznam dostupných 78

3.4. Provedené úpravy

Obrázek 3.5: Editační okno sloupců (obr. 3.6). Editační okno bylo dále rozšířeno o menu, přes které lze vkládat požadované hodnoty do nového ovládacího prvku (obr. 3.7). Pro toto řešení byl použit existující ovládací prvek „CodeTextBox“. V tomto prvku bylo provedeno několik drobných úprav, tak aby co nejvíce odpovídal požadovaným potřebám. Ideálním řešením by v tomto případě bylo vytvoření vlastního opvládacího prvku, který by kopíroval gramatiku jazyka sql rozšířenou o možnost zadávání uživatelských proměnných definovaných v aplikaci. Toto řešení by však časově přesahovalo rozsah této práce. Z toho důvodu jsem vybral existující řešení, které je schopno nabídnout velkou část požadované funkcionality.

3.4.8

Průvodce nastavením vazeb

Pro zvýšení komfortu práce s nástrojem byl implementován průvodce umožňující procházení vazeb tabulek (obr. 3.8). Toto vylepšení by mělo usnadnit nastavení tabulek tak, aby bylo na první pohled vidět, které sloupce by měly 79

3. Implementace

Obrázek 3.6: Editační okno, výběr sloupce

Obrázek 3.7: Editační okno, výběr položky z menu

být anonymizovány stejnými anonymizačními typy. Stejným způsobem lze u svázaných tabulek nastavit podmínky výběru dat.

Průvodce se automaticky zobrazí vždy, když je v editačním okně změněna některá z hodnot u sloupce, který je součástí buď cizího nebo primárního klíče. V horní části okna jsou zobrazeny všechny vazby vedoucí z nebo do tabulky. Vazby, které obsahují sloupec, u kterého byla změněna některá z hodnot, jsou označeny ikonou vykřičníku a měla by jim být věnována pozornost. V tomto okně lze provádět většina úprav jako v editačním okně a to jak u zdrojové, tak i u cílové tabulky. Provedené upravy je poté možné uložit nebo obnovit původní hodnoty. 80

3.4. Provedené úpravy

Obrázek 3.8: Průvodce nastavením vazeb

Tlačítka „Manage source table“ a „Manage destination table“ slouží k otevření nového okna stejného průvodce (obr. 3.9). V novém okně jsou pak zobrazeny vazby zdrojové nebo cílové tabulky dle stisknutého tlačítka. Vždy je možné použít jen jedno ze zmíněných tlačítek. Tímto způsobem se lze pohybovat přes všechny dostupné relace a postupně nastavit požadované hodnoty. 81

3. Implementace

Obrázek 3.9: Procházení skrz vazby

3.4.9

Report

Report slouží k přehlednému zobrazení stavu nastavení aplikace. Okno reportu (obr. 3.10) se skládá ze dvou částí. Levá část okna obsahuje ovládací prvky určené k výběru aplikace a jednoduchému výběru zobrazených schémat. Dále je zde souhrn vybraných položek. Pravá část okna obsahuje dvě záložky. První záložka (obr. 3.10) zobrazuje všechny tabulky a jejich sloupce korespondující s vybranými schématy aplikace. U každé tabulky a sloupce jsou zobrazeny jejich nastavené hodnoty. Druhá záložka (obr. 3.11) obsahuje seznam dostupných anonymizačních typů a k nim přiřazené sloupce s nastaveným odpovídajícím anonymizačním typem. Pro přehlednost je zde zaškrtávací políčko umožňující zobrazit pouze anonymizační typy, které jsou nastaveny u některého ze sloupců. 82

3.4. Provedené úpravy Report funguje interaktivně. Dvojklikem nad vybranou položkou lze otevřít editační okno vybrané tabulky. Obě záložky lze jednoduše filtrovat (obr. 3.12) dle libovolného výrazu zadaného do textového pole v pravém horním rohu okna. Počet vyfiltrovaných položek se zobrazuje ve stavovém řádku okna. Zobrazené údaje lze libovolně řadit kliknutím na hlavičku sloupce.

Obrázek 3.10: Report, záložka tabulek 83

3. Implementace

Obrázek 3.11: Report, záložka anonymizačních typů

Obrázek 3.12: Report, filtr zobrazení Hlavním prvkem okna reportu je ovládací prvek „ObjectListView“. Tento ovládací prvek podporuje velké množství užitečných funkcí. Přes pravé tla84

3.4. Provedené úpravy čítko je například k dispozici menu s možností výběru zobrazených sloupců a nastavení filtrování podobné aplikaci MS Excel.

3.4.10

Průvodce vytvořením nové aplikace

Průvodce je v tomto případě trochu nadsazený výraz, nicméně plní svůj účel. V případě, že uživatel začínal s nastavením modelu úplně od začátku, musel nejprve vytvořit následující strukturu v EA, aby addin pracovál spávně. • Vytvořit package a nastavit mu stereotyp „aplikace“, • ve vytvořeném package vytvořit nový diagram se stejným názvem, • dále v něm vytvořit nový package a nastavit mu stereotyp „schema“, • do tohoto package už lze stáhnout definice tabulek ze serveru, • pokud má ale fungovat generování, musí se schéma „přetáhnout“ na diagram. Všechny tyto kroky jsou zahrnuty v novém průvodci vytvořením aplikace (obr. 3.13). Společně s aplikací se vytvoří i jedno schéma pojmenováné stejně jako aplikace. Už je jen na uživateli, jestli jeho název ponechá, nebo změní podle sebe.

Obrázek 3.13: Průvodce vytvořením nové aplikace

3.4.11

Výběr zobrazovaných sloupců

Dále uživateli přibyla možnost zvolit si zobrazené sloupce v oknech nastavených tabulek a sloupců. Ty sloupce, které uživatel zrovna nepotřebuje lze jednoduše skrýt. Toto nastavení je uloženo v uživatelském nastavení registru windows. 85

3. Implementace

3.4.12

Další vylepšení

• Doplnění komentářů z EA do nastavovacího formuláře – komentáře k tabulkám se zobrazují v textovém poli v dolní části formuláře – komentáře ke sloupcům jsou zobrazeny jako tooltiptext nad názvem sloupce • Nastavení vlastností AcceptButton a CancelButton na všech formulářích Pro větší uživatelskou přívětivost byly nastaveny uvedené vlastnosti. Slouží k provedení akce při stisknutí kláves „Enter“ (potvrzení změn na formuláři) nebo „Escape“ (zavření formuláře beze změn). • Byla opravena chyba vyskytující se při změně projektu v EA. Při této změně addin nezareagoval a stále měl načtená data z předchozího projektu. Téměř jakákoliv operace v addinu pak způsobila jeho pád.

3.5

Návrhy na vylepšení

V této kapitole popisuji další možnosti vylepšení nástroje WinchAddin na které jsou nad rámec této práce.

3.5.1

Definice nových anonymizačních funkcí v nástroji

Na základě tohoto vylepšení by uživatel získal možnost nadefinovat si vlastní způsob anonymizace pro různé typy dat. V nástroji je momentálně možné definovat nové anonymizační typy a k nim přiřazovat funkce. Problém je v tom, že tělo nově vytvořené funkce musí být definováno v anonymizačním prostředí. Účelem tohoto vylepšení je umožnit vytvoření těla funkce přímo v nástoji a v případě nutnosti ho přenést do anonymizačního prostředí jako součást vygenerovaného PL SQL skriptu.

3.5.2

Integrace anonymizačního a řezacího prostředí do nástroje Winch

Momentální stav je takový, že po nastavení všech pravidel je nutné vygenerovat PL SQL skript, který se přenáší do anonymizačního a řezacího 86

3.5. Návrhy na vylepšení prostředí, kde je následně spuštěn. Tento mezikrok by se dal do budoucna odbourat implementací rozhraní mezi nástrojem a databází. Nástroj by měl k dispozici informace o připojení ke zpracovávané databázi, ve které by byl schopen spustit operaci anonymizace a datového řezu přímo bez uvedeného mezikroku. Jedná se o poměrně složitý krok, ke kterému je nutné nejprve vytvořit důkladnou analýzu.

Obrázek 3.14: WinchAddin - Výběr anonymizačního typu

3.5.3

Filtr anonymizačních typů na základě datového typu sloupce

Momentálně se při výběru anonymizačního typu pro každý sloupec zobrazují všechny dostupné anonymizační typy. (viz obr. 3.14) Ne všechny anonymizační typy lze ale vždy použít. Můžeme se dostat do situace kdy například pro numerický sloupec vybereme anonymizační typ, který umí pracovat pouze s řetězci. Tuto skutečnost pak většinou zjistíme příliš pozdě, pravděpodobně až při samotném procesu anonymizace, kdy nám nástroj ohlásí chybu. Tomuto problému se lze vyhnout tím, že se ke každému anonymizačnímu typu doplní informace o tom, na jaké datové typy lze anonymizační typ použít. V GUI nástroje pak stačí zjistit datový typ nastavovaného sloupce a podle něho vyfiltrovat použitelné anonymizační typy odpovídající vybranému sloupci. Uživateli se pak zobrazí seznam, ve kterém nebude muset přemýšlet nad tím, který anonymizační typ může použít.

87

Kapitola

Testování Pro účely testování byl vytvořen projekt, obsahující třídy určené k tomuto účelu. Pro některé třídy nástroje byly již dříve vytvořeny jednotkové testy. Většina z nich se ale po provedení refaktorizace stala nepoužitelnými. Většina těchto testů fungovala na principu nastav hodnotu, přečti hodnotu a to i objektů, které neprováděli žádné výpočty. Vzhledem k tomu, že nástroj ke své činnosti využívá rozhraní aplikace Enterprise Architect. Rozhodl jsem se nevytvářel nové jednotkové testy ale zaměřil jsem se na vytvoření integračních testů určených k otestování celkové funkcionality nástroje a jeho komunikace s aplikací Enterprise Architect. Pro účely integračního testování byla vytvořena třída TestPrepare která implementuje všechny potřebné metody. Metoda string PrepareModel(string model); zkopíruje soubor předaný parametrem do tempového adresáře. Návratem z funkce je plná cesta ke zkopírovanému souboru. Soubor předaný parametrem nemusí být vždy model s příponou eap. Takto si lze připravit jakýkoliv jiný soubor. Metoda void OpenModel(string modelFile); otevře model předaný parametrem. Repozitář modelu je pak plně k dispozici. Metoda void ClearModel(string model); odstraní soubor předaný parametrem z tempového adresáře. Pokud je předán název souboru s plnou cestou, metoda použije pouze název souboru a ten se pokusí odstranit z tempového adresáře. 89

4

4. Testování Zde je ukázka zdrojového kódu integračního testu s použitím pomocné třídy TestPrepare. private const string TESTMODEL_1 = @"D:\path\TestModel.eap"; TestPrepare helper = new TestPrepare(); [TestInitialize()] public void WhereEditTestInitialize() { string testModel = helper.PrepareModel(TESTMODEL_1); helper.OpenModel(testModel); } [TestMethod()] public void WhereEditTest() { //TODO: test your functionality EA.App eaApp = new EA.App(); EA.IDualRepository r = eaApp.Repository; // ... Assert.AreEqual(value1, value2); } [TestCleanup()] public void WhereEditTestCleanup() { helper.ClearModel(TESTMODEL_1); } Mimo integračních testů byly průběžně prováděny jednoduché usability testy. Tyto testy postupně odhalily několik nedostatků v uživatelské přívětivosti nástroje. Díky těmto testům například vznikla funkce „New Application“, která usnadňuje vytvoření požadované struktury datového modelu v aplikaci Enterprise Architect.

90

Závěr V této práci se mi podařilo úspěšně shrnout informace o technikách datových řezů a anonymizace. V první kapitole se zabývám obecným úvodem, který má za cíl seznámit čtenáře s danou problematikou a případnými komplikacemi. Dále se zde pokouším objasnit důležitost těchto technik v oblasti vývoje softwaru. Součástí této kapitoly je také přehled běžně se vyskytujících datových typů vhodných k anonymizaci s jejich podrobnou specifikací. Druhá kapitola se zabývá existujícími nástroji. V této části práce se mi podařilo otestovat několik dostupných nástrojů a vytvořit jednoduché porovnání jejich uživatelské přívětivosti. Na základě tohoto porovnání by pro čtenáře mělo být jednodušší vybrat si vhodný nástroj dle jeho potřeb. Poslední část této práce je věnována nástroji WinchAddin, do kterého se mi podařilo implementovat řadu užitečných funkcí. Při implementaci nových funkcí jsem se snažil, aby uživatelská přívětivost nástroje byla co nejvyšší. To si myslím, že se mi převážně podařilo. Díky nově implementovaným funkcím je nyní nástroj lépe použitelný. A to především díky vytvoření reportu, který zobrazuje stav nastavení datového modelu, a díky vytvoření průvodce umožňujícího jednoduše řešit nastavení svázaných tabulek. Mezi další vylepšení patří překlad nástroje do českého jazyka a zavedení podpory nápovědy při zadávání hodnot (Intelli-Sense). Nástroj je funkční a jednoduše použitelný. Pro otestování funkčnosti jsem použil integrační testy a jednoduché usability testy. Tímto byly splněny všechny body zadání práce.

Nástroj Winch zatím není na tak vysoké úrovni jako některé komerční nástroje, má však do budoucna velký potenciál se těmto nástrojům vyrovnat. Dalším krokem ve vývoji nástroje bych viděl hlavně v integraci anonymizačního a řezacího prostředí přímo do nástroje Winch. 91

Závěr V průběhu psaní této práce se mi nepodařilo nalézt ucelený zdroj informací, který by se komplexně zabýval technikami datových řezů anonymizce. To může být jeden z důvodů, proč jsou tyto techniky často opomíjeny a citlivé údaje se mohou jednoduše dostat do nesprávných rukou. Tato práce by se mohla stát chybějícím zdrojem informací a motivovat některé čtenáře k zavedení těchto technik do praxe.

92

Literatura [1] Předpis č. 302/2004 Sb., Úplné znění zákona č. 133/2000 Sb., o evidenci obyvatel a rodných číslech a o změně některých zákonů (zákon o evidenci obyvatel), jak vyplývá z pozdějších změn. [2] Předpis č. 117/2007 Sb., Vyhláška o číslovacích plánech sítí a služeb elektronických komunikací. [3] Příloha k vyhlášce č. 169/2011 Sb. [4] Vyhláška č. 169/2011 Sb., o stanovení pravidel tvorby čísla účtu v platebním styku. [5] Zákon č. 111/2009 Sb., o základních registrech. [6] Zákon č. 128/2000 Sb., o obcích. [7] Zákon č. 301/2000 Sb., o matrikách, jménu a příjmení a o změně některých souvisejících zákonů. [8] Zákon č. 337/1992 Sb., o správě daní a poplatků. [9] Zákon č. 101/2000 Sb., o ochraně osobních údajů a o změně dalších zákonů. [10] RFC 5322 Internet Message Format. [online]. [cit. 2013-03-22]. Dostupné z WWW: http://tools.ietf.org/html/rfc5322 [11] RFC 822 Standard for the Format of ARPA Internet Text Messages. [online]. [cit. 2013-03-22]. Dostupné z WWW: http:// tools.ietf.org/html/rfc822 93

Literatura [12] Jailer Database Subsetting Tool. [online]. [cit. 2013-05-03]. Dostupné z WWW: http://jailer.sourceforge.net/ [13] Jailer SourceForge forum. [online]. [cit. 2013-05-03]. Dostupné z WWW: http://sourceforge.net/p/jailer/discussion/ [14] Camouflage Software Inc.: Camouflage Quick Installation Overview. [online]. [cit. 2013-02-11]. Dostupné z WWW: http:// www.datamasking.com/trial [15] Camouflage Software Inc.: Camouflage User Guide. [online]. [cit. 201302-11]. Dostupné z WWW: http://www.datamasking.com/trial [16] CLEVER AND SMART: Vývojové-testovací-produkční prostředí a rizika. [online]. [cit. 2013-04-07]. Dostupné z WWW: http://www.cleverandsmart.cz/vyvojove-testovaci-produkcniprostredi-a-rizika/ [17] INFA Partner, s.r.o: Maskování dat (Data Masking). [online]. [cit. 2013-04-07]. Dostupné z WWW: http://www.infapartner.cz/ datamasking/ [18] Knopová, M.: Bezpečnost dat v informačních systémech. IKAROS Elektronický časopis o informační společnosti, [online]. [cit. 2013-0407]. Dostupné z WWW: http://www.ikaros.cz/node/6946/ [19] Net 2000 Ltd.: A Quick Start Guide to the DataBee Software. [online]. [cit. 2013-02-11]. Dostupné z WWW: http://www.databee.com/ DataBee_QuickStart.pdf [20] Net 2000 Ltd.: The Data Masker for Oracle Online Tutorials. [online]. [cit. 2013-03-24]. Dostupné z WWW: http://www.datamasker.com/ dmo_Tutorial.htm [21] Object Management Group: OMG Unified Modeling Language Specification. [online]. [cit. 2013-05-09]. Dostupné z WWW: http:// www.omg.org/cgi-bin/doc?formal/2001-09-67.pdf [22] Orpheus GmbH: DataMaskingSuite A QUICK HOW TO GUIDE. [online]. [cit. 2013-03-24]. Dostupné z WWW: http://www.data-masking-tool.com/images/stories/ Quick_User_Guide_for_Data_Masking.pdf [23] RAK, Roman: Unikátní objektové identifikátory (základy teorie v bezpečnostní praxi). Kriminalistika 3/1999. 94

Literatura [24] Solix Technologies, Inc.: Solix Enterprise Data Management Suite 5.6 (Standard Edition) Prerequisites & Installation Guide. [online]. [cit. 2013-04-15]. Dostupné z WWW: http://www.solix.com/solix-edmsse/documentation.php [25] Solix Technologies, Inc.: Solix Enterprise Data Management Suite (Standard Edition) 5.6 Product User Manual. [online]. [cit. 201304-15]. Dostupné z WWW: http://www.solix.com/solix-edms-se/ documentation.php [26] Sparx Systems Pty Ltd: ENTERPRISE ARCHITECT Software Developers’ Kit. [online]. [cit. 2013-04-09]. Dostupné z WWW: http://www.sparxsystems.com.au/downloads/resources/ booklets/enterprise_architect_sdk.pdf [27] The Ponemon Institute(C) and Compuware Communications: New Ponemon and Compuware Research Reveals Use of Sensitive Consumer Data in Application Testing Widespread. [online]. [cit. 2013-04-07]. Dostupné z WWW: http://www.prnewswire.com/news-releases/new-ponemon-andcompuware-research-reveals-use-of-sensitive-consumerdata-in-application-testing-widespread-58657857.html/ [28] Česká národní banka: IBAN – mezinárodní číslo účtu. [online]. [cit. 2013-03-22]. Dostupné z WWW: http://www.cnb.cz/cs/ platebni_styk/iban/iban_mezinar_cislo_uctu.html [29] Český normalizační institut: ČSN 01 6910 Úprava písemností zpracovaných textovými editory. [online]. [cit. 2013-03-22]. Dostupné z WWW: http://typotypo.wz.cz/csn016910.pdf [30] Český telekomunikační úřad: Číslovací plán veřejných telefonních sítí. [online]. [cit. 2013-04-09]. Dostupné z WWW: http://www.ctu.cz/1/download/cislovaci-plan-verejnychtelefonnich-siti_1114435245.pdf [31] Český úřad zeměměřický a katastrální: FAQ – výměnný formát RÚIAN (VFR). [online]. [cit. 2013-05-14]. Dostupné z WWW: http: //www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-VFR_FAQ_0_4_PDF

95

Příloha

Seznam použitých zkratek ASCII American Standard Code for Information Interchange ASE Adaptive Server Enterprise COM Component Object Model CSV Comma-separated values DDL Data definition language DIČ Daňové identifikační číslo EA Enterprise Architect GPS Global Positioning System GUI Graphical user interface HTML HyperText Markup Language IBAN International Bank Account Number IČO Identifikační číslo osoby ISO International Organization for Standardization IT Information technology ITU International Telecommunication Union JDBC Java Database Connectivity ODBC Open Database Connectivity 97

A

A. Seznam použitých zkratek PL SQL Procedural Language/Structured Query Language RFC Request for Comments RUIAN Registr územní identifikace, adres a nemovitostí S-JTSK Systém Jednotné trigonometrické sítě katastrální SQL Structured query language UIR-ADR Územně identifikační registr adres UML Unified Modeling Language WGS World Geodetic System

98

Příloha

Obsah přiloženého CD Přiložené CD obsahuje text práce v elektronické podobě. Je zde k dispozici poslední verze nástroje WinchAddin, společně s kompletními zdrojovými kódy. Vzhledem k tomu, že nástroj začal vznikat jako týmový projekt, nejsem autorem všech přiložených zdrojových kódů.

readme.txt ................................ stručný popis obsahu CD exe.....................adresář se spustitelnou formou implementace WinchAddin_x64.msi...instalační soubor nástroje WinchAddin pro 64bitový systém WinchAddin_x86.msi...instalační soubor nástroje WinchAddin pro 32bitový systém src impl.................................zdrojové kódy implementace Winch.7z........kompletní zdrojové kódy nástroje WinchAddin thesis BP_Smitka_Petr_2013.tex ...zdrojová forma práce ve formátu LATEX BP_Smitka_Petr_2013.7z ...kompletní zdrojové soubory práce text.....................................................text práce BP_Smitka_Petr_2013.pdf............text práce ve formátu PDF 99

B

Příloha

Ukázky anonymizačních nástrojů

Obrázek C.1: Solix EDMS - Vytvoření a editace připojení 101

C

C. Ukázky anonymizačních nástrojů

Obrázek C.2: Solix EDMS - Výběr připojení

Obrázek C.3: Camouflage - Data browser 102

Obrázek C.4: Camouflage - Okno Logu

Obrázek C.5: Camouflage - Nastavení připojení

Obrázek C.6: Camouflage - Seznam připojení 103


Obrázek C.7: Data Masker For Oracle - Enable Foreign Key Rule

Obrázek C.8: Data Bee - Nástroje 104

Obrázek C.9: Data Bee - Who-Loads-What Rule

Obrázek C.10: Data Bee - Tree Finder 105


Obrázek C.11: Data Bee - Chain Finder

106

Sem vložte zadání Vaší práce

Recommend Documents