Důvěryhodné informace v databázi
Obsah jakkoliv citlivých (senzitivních) dat v databázi není pochopitelně nic nepřirozeného, stejně tak důvodů proč to či ono chránit může být několik. Může jít o údaj utajovaný jaksi z principu (typicky konkrétní plat), o údaj utajovaný z důvodu ochrany třetí strany (typicky zdoj informace) nebo o údaj který sám o sobě není nebezpečný, ovšem jeho utajení je vázáno na některá již zveřejněné skutečnosti. Jak jsem již zmiňoval, možnost co "nejjemnějšího" nastavení přístupových práv je vždy žádaná vlastnost.
Naprosto největší bezpečnostní problémy vznikají v situaci, kdy senzitivní jsou pouze některé informace. Systém totiž musí volit mezi dvěma požadavky, která jdou přímo proti sobě : na jedné straně máme bezpečnost, kdy je potřeba některé dotazy striktně odmítnout. Jak již bylo a ještě bude zmíněno, někdy je možné se šikovně zeptat na několik jiných věcí, přičemž v odpovědi najdu i údaj, který je systémem považovaný za tajný a přímý dotaz na něj by skončil odmítnutím. Na druhé straně je zde požadavek na co největší dostupnost veřejných dat, ovšem při větším "tlaku" na zmiňované nepřímé dotazy v sítu nutně uvízne spousta dotazů nevinných.
Problém odvoditelnosti dat
Mějme tabulku zaměstnanců imaginátní společnosti, ve které budeme uchovávat : jméno, pohlaví, oddělení zaměstnance, jeho plat, hodnocení a nějaké prohřešky (např. pozdní příchody).
Zaměst. Pohlaví Oddělení Plat Hodnoc. Prohřešky
=================================================================
Durych Muž Provozní 5000 1 5
Adámek Muž Provozní 6000 1 1
Liborec Žena Ekonomické 14000 2 0
Ottová Žena Provozní 12500 1 1
Dostál Muž Personální 9000 3 4
Novák Muž Provozní 6000 2 1
Bareš Muž Reklamní 8000 1 0
Červená Žena Ekonomické 15000 1 0
Smetana Muž Personální 11000 2 0
Cejlová Žena Reklamní 8000 1 2
Majer Muž Ekonomické 18000 1 0
Patera Muž Provozní 8000 3 0
Hájková Žena Poradenské 10000 1 0
Hrubý Muž Provozní 11000 2 2
Tučný Muž Provozní 6000 1 0
Látal Muž Reklamní 10000 1 1
Všechny sloupce kromě pohlaví a oddělení považujme za tajné (včetně jména), na druhou stranu povolme čtení sumárních hodnot jako je počet, součet, průměr a medián (tajných numerických sloupců). Pokud se někomu zdá tento příklad poněkud primitivní, má pravdu jen z části. Kouzlo nepřímých dotazů pravda daleko více vynikne při demonstraci na podstatně delší tabulce, na to ovšem není prostor a je to pro demonstrační účely zbytečné. Ještě lepších výsledků může útočník dosáhnout při určitém stupni "sociálního inženýrství", tedy pokud má přibližně rozhled o podmínkách ve společnosti (viz některé dotazy).
Tak například podívejme se na následující dotaz : "chci součet platů jednotlivých oddělení dle pohlaví". Jak je z tabulky patrno, tento zdánlivě nevinný dotaz jednoznačně odhalí plat zaměstnankyně Hájkové. Dále jsme nedávno odešli z postu pana Látala, tedy máme víceméně přesné pojetí o jeho platu. Jelikož jeho dva podřízení (z reklamního oddělení) dělají úplně totéž, budou mít stejný plat, který je roven (27000-11000)/2=8000 Kč. Pokud k dotazu přidáme požadavek na počet pracovníků, rázem odhalíme, že šéf ekonomického oddělení má 18ti tisícový plat. Jelikož pan Smetana nastoupil nedávno, dotaz na průměrný počet prohřešků na jednotlivých odděleních vede přímo k hodnotě 4 v případě pana Dostála.
Další problémy může představovat medián, střední hodnota znaků seřazených podle velikosti. Vždy totiž máme jistotu, že existuje alespoň jeden řádek, který ji nabývá, což může být v kombinaci s průměrem silný zjišťovací nástroj. Při vyhodnocování auditního záznamu nespoléhejte na přímost dotazů, není vždy nutné se zeptat databáze na plat nového zaměstnance, pokud se mohu zeptat na průměrný plat v organizaci před a po jeho přijetí. Uživatelé tedy mohou zjistit konkrétní hodnotu bez explicitního dotazu na ní.
Proti útoku nepřímými dotazy existuje mnoho útoku, bohužel většinou mají opět vlastnost dvojsečné zbraně. Pokud přidáme na bezpečnosti, systém rázem některé právoplatné dotazy odmítne odpovědět, nebo odpoví zkresleně. To může jít až do takového "extrému", kdy se k výsledku připočítává náhodná hodnota (tzv. Náhodné zmatení ,random data perturbation), popřípadě se místo na celém výběru sloupce se statistické hodnota spočítá pouze na náhodném výběru. Musí se pochopitelně zajistit, aby při stejných dotazech systém vracel stejné výsledky.
Otázka redundance dat
V příručkách pro začátečníky se často uvádí, že relační databáze nesmí obsahovat redundantní, tedy opakovaná data. Platnost této zásady je pro relativně "menší" databáze nesporná, neboť umístění jedněch hodnot na více místech představuje markantní problémy při modifikaci, porovnávání a pokud se jaksi "stejné hodnoty liší" (tj. nechtěně, vlivem nějaké chyby), odhalení problému bývá skutečně detektivní práce.
Na druhou stranu existují podmínky, ve kterých má ta či ona redundance uplatnění. Je to například za předpokladu že potřebujeme docílit potřebnou rychlost, neboť spojování tabulek s velkým počtem řádků klade nemalé nároky na výpočetní výkon. Proto je někdy uchovávat informace vícekrát užitečné, počet tabulek které s budou spojovat se sníží. Dále je možné opakováním odhalit některé chyby, pokud například nová hodnota prochází složitým procesem mimo náš systém. Její porovnání s hodnotou starou může být velmi užitečný diagnostický nástroj. Zcela přímým příkladem jsou tzv. Shadow fields, tedy prosté "stíny" jiných datových polí, v případě nedostupnosti originálu nebo chyby v něm je tak použita takováto záložní kopie.
Vedle prostých kopií stojí za uvážení, zda do některých míst databázového systému nezapracovat detekční a/nebo samoopravné kódy. To jsou krátké řetězce, která, jak je asi jasné, dokáží určitý omezený počet chyb v objektu ke kterému se vztahují odhalit, popřípadě i opravit. K dispozici bývá často velké množství algoritmů, od prostých kontrolních součtů až po kryptograficky bezpečné hashe (MD5, SHA1...) Pokud je proces správně zautomatizován, měl by vždy být při ukládání nových dat kód spočten a při čtení spočten + porovnán s uloženou hodnotou. Velmi šikovně se tím zamezí náhodné modifikaci dat.
