Bezpečnosť databázových systémov

Bezpečnosť databázových systémov
Doc. Ing. Ladislav Hudec, CSc 1

Bezpečnosť databáz - Úvod
Databáza je súbor dát, ktoré sú zostavené nejakým významným spôsobom. Systém riadenia bázy dát (SRBD) organizuje údaje a dáva používateľom nástroje na sprístupnenie informácie. Položky v databáze nesú informácie. Používatelia databázy vykonávajú operácie, ktoré berú do úvahy obsah položiek databázy. Najtypickejším použitím databázy je prehľadávanie (dopyt). Pri prehľadávaní, pokiaľ to vyhovuje pravidlám riadenia prístupu presadzovanými SRBD, používateľovi sú sprístupnené položky databázy vyhovujúce podmienkam prehľadávania. Populárnym príkladom sú databázy platov, kde napríklad môže byť používateľovi sprístupnená položka o plate zamestnanca iba v obmedzenom prípade (iba vedúcim pracovníkom, a to iba platy ich podriadených). Útočník sa môže zaujímať o mnoho rôznych infomácií z databázy. Oblasť možných zdrojov informácií pre útočníka sú: Presné dáta: hodnoty uložené v databáze Hranice: dolná a horná hranica numerických hodnôt ako je plat, môže byť užitočná informácia Negatívny výsledok: ak databáza obsahuje počet kriminálnych činov, potom informácia, že určitá osoba nemá 0 kriminálnych činov je citlivá Existencia: existencia údaja môže byť už citlivá informácia Pravdepodobná hodnota: možnosť byť schopný uhádnuť niektoré informácie z výsledkov ostatných dopytov. Cieľom bezpečnosti je vedieť chrániť informácie v databáze proti všetkým vyššie uvedeným eventualitám. 2

Bezpečnosť databáz - Úvod
Ochrana informácií v databáze môže byť komplikovaný problém v prípade, že databáza dovoľuje štatistické dopyty. Štatistický dopyt by napríklad vrátil súčet všetkých platov alebo priemerný plat. Inteligentná kombinácia takýchto dopytov môže odhaliť informáciu, ktorú chceme chrániť. Položky databázy nesú informácie o entitách externých k databáze (zamestnanci, platy, skladové zásoby v obchodných domoch, výsledky skúšok študentov, výšku zostatku na bankovom účte alebo o voľných miestach v lietadle). Položky databázy by mali správne odrážať tieto externé fakty. Bezpečnosť databáz zahrňuje aplikačne špecifickú ochranu integrity s cieľom dosiahnuť: Internú konzistenciu – položky v databáze sa riadia predpísanými pravidlami, napríklad úroveň zásob v sklade nesmie klesnúť pod nulu. Externú konzistenciu – položky v databáze sú správne, napríklad úroveň zásob v sklade uvedený v databáze zodpovedá skutočnému množstvu zásob v sklade. SRBD môže napomôcť vyhnúť sa chybám pri aktualizácii, ale nesmieme sa spoliehať iba na samotný SRBD pri udržiavaní konzistentného stavu. Tejto vlastnosti databázy hovoríme tiež presnosť. V štruktúrovanom modeli počítačového systému môžeme SRBD umiestniť do vrstvy služieb nad vrstvu operačného systému. Okrem toho SRBD musí: Splňovať databázovo-špecifické bezpečnostné požiadavky, ktorými sa nezaoberá operačný systém. Môže presadzovať bezpečnosť v spojení s ochrannými mechanizmami v rámci operačného systému alebo musí mať implementované vlastné ochranné mechanizmy, ak ich nemá operačný systém alebo jeho využitie by bolo príliš ťažkopádne. Môže byť nástroj na definovanie bezpečnostných opatrení v aplikačnej vrstve. 3

Relačná databáza - koncept
Medzi rôznymi modelmi organizácie databázy je relačný model v súčasnosti najpoužívanejší. Relačná databáza je databáza, ktorá je chápaná svojimi používateľmi ako súbor tabuliek. Takáto definícia relačnej databázy odpovedá spôsobu chápania používateľmi a neodpovedá jej fyzickej organizácii. Tento spôsob abstrakcie je tiež vhodný na analýzu databázovej bezpečnosti. Formálne je relácia R podmnožinou kartézskeho súčtu D1 x D2 x … x Dn, kde D1, D2, .., Dn je n domén (n atribútov). Prvok relácie je n-tica (v1,v2,… vn), kde vi je prvkom Di. Prvkom v n-tici sa hovorí polia. Pokiaľ pole neobsahuje žiadnu hodnotu, túto skutočnosť reprezentujeme vložením špeciálnej hodnoty null. Význam tohoto špeciálneho znaku je ten, že v poli nie je žiadna položka a nie, že položka je neznáma. Na obrázku nižšie sú relácie, ktoré by mohli byť časťou databázy cestovnej kancelárie. Relácia Diary má štyri atribúty: Name, Day, Flight a Status Diary Flights Name Day Flight Status Alice Mon GR123 private Bob YL011 business Wed BX201 Carol Tue Thu FL9700 Flight Destination Departs Days GR123 THU 7:55 1—4--- YL011 ATL 8:10 BX201 SLA 9:20 FL9700 14:00 GR127 14:55 -2—5-- 4

Domény relácie Diary sú: Name: všetky platné mená zákazníkov Day: dni v týždni Mon, Tue, Wed, Thu, Fri, Sat, Sun Flight: čísla letov, dve veľké písmená a najviac štyri číslice Status: typ cesty služobný (business) alebo súkromný (private) Štandardným jazykom na zapísanie ako informáciu z relačnej databázy vybrať alebo aktualizovať je jazyk SQL (Structured Query Language). SQL operácie na manipuláciu s datami sú: SELECT: vyberá data z relácie. Napríklad operácia SELECT Name, Status FROM Diary WHERE Day = ‘Mon’ vráti výsledok ako záznamy z databázy, kde budú zobrazené iba atribúty Name a Status z tých relácií, ktoré majú v poli atribútu Day hodnotu Mon Name Day Flight Status Alice Mon GR123 private Bob YL011 business Wed BX201 Carol Tue Thu FL9700 Name Status Alice private Bob business 5

UPDATE: aktualizuje pole v relácii. Napríklad operácia UPDATE Diary SET Status = private WHERE Day = ‘Sun’ označí všetky cesty v nedeľu (Sunday) ako súkromné typy cesty (v uvedenej relácii Diary nie je taký prípad) DELETE: vymaže n-tice z relácie. Napríklad operácia DELETE FROM Diary WHERE Name = ‘Alice’ vymaže všetky Alicine cesty z relácie Diary Name Day Flight Status Alice Mon GR123 private Bob YL011 business Wed BX201 Carol Tue Thu FL9700 Name Day Flight Status Bob Mon YL011 business Wed BX201 Carol Tue 6

INSERT: pridá n-ticu do relácie. Napríklad operácia INSERT INTO Flights (Flight, Destination, Days) VALUES (‘GR005’, ‘GOH’, ‘ ’) vloží novú n-ticu do relácie Flights, kde pole Departs je stále nešpecifikované Flight Destination Departs Days GR123 THU 7:55 1—4--- YL011 ATL 8:10 BX201 SLA 9:20 FL9700 14:00 GR127 14:55 -2—5-- Flight Destination Departs Days GR123 THU 7:55 1—4--- YL011 ATL 8:10 BX201 SLA 9:20 FL9700 14:00 GR127 14:55 -2—5-- GR005 GOH 7

Vo všetkých prípadoch SQL operácií sú možné komplikovanejšie konštrukcie. Na demonštráciu sa ukáže príklad, ktorý má z databázy nájsť toho, kto poletí do Thule: SELECT Name FROM Diary WHERE Flight IN ( SELECT Flight FROM Flights WHERE Destination = ‘THU’) Relácie sú často vizualizované ako tabuľky. Atribúty odpovedajú stĺpcom tabuľky, meno stĺpca je označené atribútom. Riadky v tabuľke odpovedajú záznamom (n-ticiam). V relačnom modele nemôže relácia obsahovať linku alebo ukazovateľ do inej tabuľky. Vzťah medzi tabuľkami (reláciami) môže byť daný iba ďalšou reláciou. V relačnej databáze môžu existovať rôzne typy relácií: Základné relácie: tiež sa nazývajú reálne relácie, sú pomenované a autonómne relácie, existujú plnohodnotne a nie sú odvodené zo žiadnych iných relácií, majú svoje vlastné uložené dáta. Pohľady: sú pomenované, odvodené relácie, definované vo výrazoch ostatných pomenovaných relácií, nemajú svoje vlastné uložené dáta. Snapshots: podobne ako pohľady sú pomenované, odvodené relácie, definované vo výrazoch ostatných pomenovaných relácií, majú svoje vlastné uložené dáta. Výsledky dopytu: výsledok dopytu (query) môže alebo nemusí mať meno, samo o sebe nemá stálu existenciu v databáze. vnorený SELECT 8

Príklad snapshotu z tabuľky Diary, ktorý hovorí kto kedy cestuje, je definovaný takto CREATE SNAPSHOT Travellers AS SELECT name, day FROM Diary Databázové kľúče: V každej relácii musíme byť schopný identifikovať všetky n-tice jedinečným spôsobom. Niekedy môže byť použitý jednoduchý atribút ako identifikátor. Dokonca môže byť výber atribútov, z ktorých by každý mohol slúžiť na tento účel. Na druhej strane sa môže stať, že potrebujeme viac ako jeden atribút na konštrukciu takéhoto identifikátora. Primárny kľúč relácie je jedinečný a minimálny identifikátor pre túto reláciu. Primárny kľúč K relácie R musí splňovať tieto podmienky: Jedinečnosť. Žiadne dve n-tice z R nemajú tú istú hodnotu kľúča K. Minimálnosť. Ak K je zložené, žiadny komponent z K nemôže byť vypustený bez zrušenia vlastnosti jedinečnosti. V relácii Diary kombinácia atribútu Name a Day môže slúžiť ako primárny kľúč (za predpokladu, že zákazník bude cestovať iba jeden krát za deň). V relácii Flights je Flight number primárnym kľúčom. Každá relácia musí mať primárny kľúč, pretože žiadna relácia nesmie obsahovať duplikáciu n-tice. Toto vyplýva priamo z formálnej definície relácie. Keď primárny kľúč jednej relácie je použitý ako atribút v ďalšej relácii, potom hovoríme, že je cudzí kľúč v tejto relácii. V našom príklade je číslo letu Flight primárnym kľúčom v relácii Flights a je cudzím kľúčom v relácii Diary. 9

Pravidlá integrity: V relačnej databáze je možné definovať pravidlá integrity, ktoré presadzujú internú konzistentosť a napomáhajú udržovať externú konzistentnosť (presnosť). Väčšina týchto pravidiel bude špecifická aplikácii, ale existujú dve pravidlá, ktoré sú inherentné modelu relačnej databázy. Pravidlo integrity entity - Žiadny komponent primárneho kľúča základnej relácie nesmie akceptovať nulls. Toto pravidlo nám umožňuje nájsť všetky n-tice v základnej relácii. N-tity v základných reláciách korešpondujú s „reálnymi“ entitami a nereprezentovali by sme v databáze takúto identitu, ak by sme ju nedokázali identifikovať. Pravidlo integrity referencie (referenčná integrita) – pre cudzí kľúč databáza nesmie obsahovať neodpovedajúce (unmatched) hodnoty. Hodnota cudzieho kľúča reprezentuje referenciu na položku v nejakej ďalšej tabuľke. Neodpovedajúca hodnota cudzieho kľúča je hodnota, ktorá sa neobjaví ako primárny kľúč v referencovanej tabuľke. To je referencia na neexistujúcu n-ticu. K vyšie uvedeným dvom pravidlám môžu existovať ďalšie aplikačne špecifické pravidlá. Pravidlá integrity sú dôležité, pretože udržujú v databáze užitočný stav. Typicky môžu byť použité na zabezpečenie: Kontrola poľa – ochrana dát v poli pred chybami. V našom prípade môžeme chrániť proti vloženiu ľubovoľnej hodnoty do atribútu Status v relácii Diary. Prostredníctvom pravidla kontrolujúceho, či vložená hodnota je alebo business alebo private. Kontrola rozsahu – v databázach so štatistickými operáciami môže byť pravidlo pri kontrole dopytu, že výsledok je vypočítaný z dostatočne veľkej vzorky. Ak sa podívame na reláciu Student (obrázok nasleduje), je možné definovať pravidlo, ktoré vráti priemer známok iba vtedy, ak veľkosť vzorky (počet záznamov, z ktorých sa počíta priemer) je väčšia ako 3. 10

Student Name Sex Program Units Grade Ave. Alma F MBA 8 63 Bill M CS 15 58 Carol 16 70 Don MIS 22 75 Errol 66 Flora 81 Gala 23 68 Homer 7 50 Igor 21 11

Kontrola konzistencie – položky v rôznych reláciách môžu odpovedať tomu istému aspektu externého sveta a mali by teda mať konzistentný stav s týmto aspektom. V našom prípade môžeme kontrolovať deň zákazníkovej cesty oproti dňom plánovaných odchodov ich letov. Alicin let v pondelok linkou GR123 je konzistentný so skutočnosťou, že tento let sa vykonáva v pondelky a vo štvrtky. Karolinina rezervácia letu BX201 nie je konzistentná so skutočnosťou, že linka operuje v pondelok, stredu a piatok. Pravidlo integrity porovnávajúce uvedené polia môžu zastaviť agenta (cestovnej kancelárie) pri vykonaní takejto chyby. Pravidlá integrity uvedeného typu sú opatrenia na aplikačnej úrovni. SRBD poskytuje infraštruktúru na špecifikovanie a presadzovanie takýchto pravidiel. Napríklad integritný spúšťač (integrity trigger) je program, ktorý môže byť pripojený k objektu v databáze, aby kontroloval jednotlivé integritné vlastnosti tohoto objektu. V prípade, že operácia UPDATE, INSERT alebo DELETE sa pokúša modifikovať objekt, tento program je spustený a vykoná takúto integritnú kontrolu. Keď pri vyhodnocovaní pravidiel integrity sa požaduje prístup k údajom (napr. citlivým údajom) je treba rozhodnúť, či sa pravidlo integrity vyhodnotí neúplne (a nesprávne) z dôvodu zamedzenia prístupu k (citlivým) položkám alebo sa uvoľní citlivá informácie pre potrebu udržania konzistencie v databáze. 12

Riadenie prístupu Riadenie prístupu:
Na zaistenie ochrany citlivých informácií musí SRBD riadiť prístup používateľov do databázy. Aby sme ukázali ako môžu byť opatrenia implementované, pripomenieme, že prístup do databázy môže byť uvažovaný na dvoch úrovniach: Operácie manipulácie s dátami v základnej relácii Zložené operácie ako sú pohľady alebo snapshot. Na riadenie prístupu sa môžeme podívať z dvoch pohľadov: Obmedzením operácií dostupných používateľovi Definovaním ochranných požiadaviek pre každú individuálnu dátovú položku. V SRBD ochrany na zložené operácie regulujú spôsob, ako môže používateľ pracovať s databázou. Na druhej strane kontroly na manipuláciu so základnými reláciami chránia položky v databáze. Na základe rozhodnutia, ktoré typy prístupových operácií chceme kontrolovať, tiež ovplyvníme zameranie presadzovaných politík. Naopak, zameranie našich politík podmieňuje, ktoré typy operácií sa budú kontrolovať. Nech si vyberieme ktorúkoľvek variant, mali by sme docieliť dve vlastnosti: Úplnosť – všetky polia v databáze sú primerane chránené Konzistentnosť – neexistujú žiadne rozporné pravidlá vedúce k prístupu k dátovej položke. Bezpečnostná politika je konzistentná, ak neexistuje v databáze element, ktorý môže byť prístupný rôznymi spôsobmi a tieto spôsoby majú rôzne výsledky rozhodnutia o riadení prístupu. Legitímnym žiadostiam o prístup by nemalo byť bránené a nemali by existovať žiadne spôsoby obídenia špecifikovanej politiky prístupu. 13

Riadenie prístupu - Model bezpečnosti SQL
Základný model bezpečnosti SQL sleduje známy vzor. Implementuje politiku DAC (Discretionary Access Control), ktorá je založená na troch entitách: Používatelia – používatelia databázy, používateľova identita je autentizovaná počas procesu prihlásenia, SRBD môže vykonávať svoj proces prihlásenia alebo akceptovať používateľovu identitu autentizovanú operačným systémom Akcie – zahrňujú SELECT, UPDATE, DELETE a INSERT Objekty – tabuľky, pohľady a stĺpce (atribúty) tabuliek a pohľadov. Používateľ vyvolá akciu nad objektami a SRBD musí rozhodnúť či dovolí požadovanú akciu. Pokiaľ je vytvorený objekt, používateľ je určený za jeho vlastníka a iniciálne iba vlastník má prístup k objektu. Ostatným používateľom musí byť pridelené privilégium na prístup k objektu. Komponenty privilégia sú: (postupiteľ privilégia - grantor, preberateľ privilégia - grantee, objekt, akcia postupiteľná na privilégium - grantable). SQL bezpečnosť stojí na dvoch základných pilieroch: privilégiá a pohľady. Poskytujú rámec na definovanie aplikačne orientovaných bezpečnostných politík. Postúpenie a odvolanie privilégií: V SQL sú privilégiá spravované operáciami GRANT a REVOKE. Privilégiá odpovedajúce jednotlivým akciám môžu byť obmedzené na určité atribúty v tabuľke. V našom prípade dovolíme dvom cestovným agentom Artovi a Zoe, aby prehľadávali a aktualizovali časti tabuľky Diary operácie: GRANT SELECT, UPDATE (Day, Flight) ON TABLE Diary TO Art, Zoe 14

Postúpenie a odvolanie privilégií: Privilégiá môžu byť selektívne odvolané: REVOKE UPDATE ON TABLE Diary FROM Art Ďalšou črtou je postúpenie práva na postúpenie privilégia. V SQL je to implementované operáciou GRANT OPTION. Napríklad: GRANT SELECT ON TABLE Diary TO Art WITH GRANT OPTION Cestovný agent Art môže postúpiť privilégiá Zoe pre tabuľku Diary GRANT SELECT ON TABLE Diary TO Zoe WITH GRANT OPTION V prípade, že vlastník tabuľky Diary odvolá privilégiá postúpené Artovi, potom všetky privilégiá postúpené Artom musia byť tiež odvolané. To znamená, že odvolanie vytvára kaskádu a informácie nevyhnutné na vykonanie kaskády sú udržiavané databázovým systémom. Je potrebné poznamenať, že pokiaľ ďalšiemu používateľovi boli postúpené privilégiá na prístup k dátam, vlastník dát nie je schopný kontrolovať ako sú použité informácie odvodené z týchto dát, dokonca aj keď je stále nejaká kontrola nad originálnymi dátami. Používateľ môže čítať dáta z tabuľky a kopírovať tieto dáta do ďalšej tabuľky bez toho, aby žiadal nejaký prístup zápisu do originálnej tabuľky. 15

Riadenie prístupu cez pohľady: Pohľady sú odvodené relácie. Operácia SQL na vytvorenie pohľadu má takýto formát: CREATE VIEW view_name [ (column [, column] ) ] AS subquery [ WITH CHECK OPTION] ; Je možné implementovať riadenie prístupu v relačnej databáze postúpením privilégií priamo položkám v základnej relácii. Samozrejme, veľa bezpečnostných politík sú lepšie vyjadrené cez pohľady a cez privilégiá týchto pohľadov. Subquery v definícii predchádzajúceho pohľadu môže opísať celkom zložité prístupové podmienky. Ako jednoduchý príklad skonštruujeme pohľad, ktorý zahrňuje všetky služobné cesty v tabuľke Diary CREATE VIEW business_trip AS SELECT * FROM Diary WHERE Status = ‘business’ WITH CHECK OPTION ; Name Day Flight Status Bob Mon YL011 business Carol Tue BX201 Alice Thu FL9700 16

Riadenie prístupu cez pohľady: Riadenie prístupu cez pohľady môže byť vhodne umiestnené do aplikačnej vrstvy. SRBD iba zabezpečí nástroje na implementáciu kontroly. Pohľady sú atraktívne pre viacero dôvodov: Pohľady sú flexibilné a dovoľujú, aby politika riadenia prístupu bola definovaná na úrovni opisu, ktorý je blízko aplikačným požiadavkám Pohľady dokážu presadiť kontextovo-závislé a dátovo-nezávislé bezpečnostné politiky Pohľady sú schopné implementovať riadené vyvolanie Bezpečné pohľady sú schopné nahradiť bezpečnostné návestia Dáta môžu byť ľahko reklasifikované Aplikačne orientované riadenie prístupu sa dá vyjadriť cez pohľady ako: CREATE VIEW Top_of_the_Class AS subquery SELECT * FROM Students WHERE Grade Ave < (SELECT Grade Ave FROM Students WHERE Name = current_user ()) ; na zobrazenie iba tých študentov, ktorých priemerná známka je menšia ako osoby používajúcej pohľad, alebo CREATE VIEW My_Journeys AS SELECT * FROM Diary ( WHERE Customer = current_user ()) ; na zobrazenie iba rezervovaných ciest toho zákazníka, ktorý používa pohľad. Politika DAC sa dá implementovať doplnením tabuľky riadenia prístupu (matice riadenia prístupu) do databázy. Pohľady potom možno referencovať do tejto tabuľky. Takýmto spôsobom sa dá vyjadriť riadenie prístupu založené na skupinovom členstve rovnako ako politiky regulujúce používateľské práva postúpiť a odvolať prístupové práva. 17

Riadenie prístupu cez pohľady: Navyše, pohľady môžu definovať alebo odkazovať na bezpečnostné návestia. V našom príklade, služobná cesta do Thule môže byť označená ako dôverná vytvorením pohľadu: CREATE VIEW Fligths_ge_CONFIDENTIAL AS SELECT * FROM Diary WHERE Destination = ‘THU’ AND Status = “business” ; Riadenie prístupu čítania cez pohľady nepredstavuje žiadny technický problém. Situácia je však odlišná v prípade, že pohľady sú použité operáciami INSERT alebo UPDATE na zápis do databázy. Poprvé, existujú pohľady, ktoré nie sú aktualizovateľné, pretože neobsahujú informácie potrebné na udržanie integrity odpovedajúcej základnej relácii. Napríklad, pohľad, ktorý neobsahuje primárny kľúč odpovedajúci základnej relácii, nemôže byť použitý na aktualizáciu. Podruhé, ak aj pohľad je aktualizovateľný , zostávajú niektoré zaujímavé bezpečnostné problémy. Cestovný agent, ktorý má prístup do databázy Diary iba cez pohľad business_trip vidí pohľad ako je na predchádzajúcom obrázku. Malo by byť cestovnému agentovi dovolené aktualizovať pohľad operáciou? UPDATE business_trip SET Status = ‘private’ WHERE Name = ‘Alice’ AND Day = ‘Thu’ Položka Alica by potom vypadla z pohľadu. Samozrejme v tomto prípade aktualizácia nebude dovolená, pretože v definícii pohľadu je špecifikovaná voľba CHECK. Pokiaľ definícia pohľadu obsahuje WITH CHECK OPTION, potom UPDATE a INSERT môžu zapísať iba položky databázy, ktoré splňujú definíciu pohľadu. Ak voľba CHECK je vypustená, je dovolený zápis naslepo (blind writes). 18

Riadenie prístupu cez pohľady: Pohľad nie je iba objekt v bezpečnostnom modeli SQL, môžeme na pohľad nazerať aj ako na program. Keď je pohľad vyhodnocovaný skôr s privilégiami svojho vlastníka než s privilégiami používateľa vyvolávajúceho pohľad, potom máme ďalšiu metódu na implementáciu kontrolovaného vyvolania. Podmienky prístupu v pohľade musia byť špecifikované v rámci obmedzení SQL. Pokiaľ sa ukazujú ako veľmi reštriktívne, je možné poskytnúť ďalšiu možnosť SRBD na zabezpečenie kontroly prístupu do databázy, a to softvérovým balíkom (uložené procedúry) napísanom v inom jazyku. Doposiaľ sme prezentovali aspekty, ktoré poskytujú pohľadom užitočné bezpečnostné mechanizmy. Samozrejme, pohľady majú aj svoje nevýhody: Kontrola prístupu sa môže stať dosť komplikovanou a pomalou Definície pohľadov musia byť kontrolované na „správnosť“, či skutočne realizujú zamýšľanú bezpečnostnú politiku Dosiahnutie úplnosti a konzistencie sa nedosahuje automaticky. Pohľady môžu presahovať alebo môžu zlyhať pri pokrytí celej databázy Bezpečnostná časť SRBD (TCB – Trusted Computer Base) sa stane veľmi rozsiahla. Pohľady sú vhodné v bežnom komerčnom prostredí. Môžu byť ušité na mieru aplikácii a nemusia požadovať modifikáciu SRBD. Definície pohľadov sú potom časťou všeobecného procesu definovania štruktúry databázy, a teda najlepšie splňujú komerčné požiadavky. V prípade pohľadov môže byť obťažné určovať prístup k individuálnym dátovým položkám. Preto sú pohľady menej vhodné v situáciách, kde je viac požadované chrániť dátové položky než kontrolovanie používateľových aktivít. 19

Bezpečnosť databázy pri štatistických operáciách
Databázy so štatistickými operáciami priniesli nové bezpečnostné problémy. Odlišnou črtou databázy so štatistickými operáciami je to, že informácie sú sprístupňované nástrojmi štatistických (agregovaných) dopytov na atribúty v stĺpcoch. Agregované funkcie v SQL sú: COUNT: počet hodnôt v stĺpci SUM: súčet hodnôt v stĺpci AVG: priemer hodnôt v stĺpci MAX: najväčšia hodnota v stĺpci MIN: najmenšia hodnota v stĺpci. Databázy so štatistickými operáciami prinášajú tieto bezpečnostné problémy: Databáza obsahuje položky dát, ktoré sú individuálne citlivé. Priamy prístup k dátovej položke je preto nedovolený. Štatistické dopyty do databázy sú dovolené. Tieto dopyty však čítajú individuálne dátové položky. V databázach so štatistickými operáciami musí byť nejaký tok informácií z dátových položiek na ich agregáciu. Musíme však tok informácií redukovať na akceptovateľnú úroveň. Na nasledujúcom obrázku je databáza Student. Štatistické dopyty na všetky atribúty sú dovolené, ale individuálne položky v stĺpcoch Units a Grade Ave nemôžu byť priamo čítané. Štatistický dopyt: Q1 : SELECT AVG(Grade Ave) FROM Students WHERE Programme = ‘MBA’ 20

Student Name Sex Programme Units Grade Ave. Alma F MBA 8 63 Bill M CS 15 58 Carol 16 70 Don MIS 22 75 Errol 66 Flora 81 Gala 23 68 Homer 7 50 Igor 21 21

Vypočíta priemernú známku všetkých MBA študentov. Dopytovací predikát v tomto prípade je Program = ‘MBA’. Agregácia a inferencia Sú dva dôležité koncepty v bezpečnosti databáz so štatistickými operáciami a to agregácia a inferencia: Agregácia odpovedá zisteniu, že citlivostná úroveň agregácie počítanej cez skupinu hodnôt v databáze sa môže líšiť od citlivostnej úrovni individuálnych elementov. Najčastejšie sa stretávame so scenárom, kde citlivostná úroveň agregácie je nižšia ako úrovne individuálnych elementov. Agregácia je ďalšou reláciou v databáze, tj. pohľad, a tak je možné použiť bezpečnostné mechanizmy navrhnuté pre pohľad. Útočník môže využiť rozdielnosť v citlivostných úrovniach na získanie prístupu k citlivejším položkám. Problém inferencie odpovedá odvodeniu citlivých informácií z necitlivých dát. V databázach pri štatistických operáciách musíme brať do úvahy tieto typy útokov: Priamy útok: agregácia je počítaná nad malou vzorkou a informácia o individuálnej dátovej položke sa zistí (presiakne). Nepriamy útok: útok kombinuje informácie majúce súvis s niekoľkými agregáciami. Stopársky útok (Tracker attack): zvlášť efektívny typ nepriameho útoku. Lineárna systémové zranitelnosť: tento útok posúva stopársky útok o krok ďalej, použitím algebraických vzťahov medzi dopytmi možno zostaviť rovnice, z ktorých sa získa požadovaná informácia. Stopársky útok Ukážeme si príklad, ako využiť štatistické dopyty na odvodenie citlivých informácií z relácie Students. Predpokladajme, že vieme, že Carol je ženského pohlavia a študuje program CS. Kombinovaním dvoch legitímnych dopytov: Q1 : SELECT COUNT(*) FROM Students WHERE Sex = ‘F’ AND Program = ‘CS’ 22

Stopársky útok Q2 : SELECT AVG(Grade Ave) FROM Students WHERE Sex = ‘F’ AND Programme = ‘CS’ z dopytu Q1 zistíme, že je iba jedna študentka programu CS, a teda hodnota 70 vrátená dopytom Q2 je presne jej priemer. Problémom je, že výberové kritérium definuje množinu obsahujúcu iba jeden element. To znamená, že treba dovoliť štatistický dopyt iba vtedy, ak pokrýva dostatočne veľkú podmnožinu. Avšak môžeme jednoducho vytvoriť komplementárny dopyt negovaním výberového kritéria a získame rovnaký výsledok ako predtým a to z rozdielu medzi výsledkom dopytu aplikovanom na celú databázu a výsledkom dopytu aplikovanom na komplement množiny, ktorá nás v skutočnosti zaujíma. To znamená, že je potrebné požadovať, aby aj komplement množiny mal dostatočný počet elementov. Bohužiaľ ani táto podmienka nie je postačujúca. Predpokladajme, že každá dopytovaná množina a jej komplement musia obsahovať aspoň tri elementy. Sekvencia dopytov: Q3 : SELECT COUNT(*) FROM Students WHERE Program = ‘CS’ Q4 : SELECT COUNT(*) FROM Students WHERE Program = ‘CS’ AND Sex = ‘M’ Q5 : SELECT AVG(Grade Ave) FROM Students WHERE Program = ‘CS’ Q6 : SELECT AVG(Grade Ave) FROM Students WHERE Program = ‘CS’ AND Sex = ‘M’ 23

Stopársky útok Vráti hodnoty Q3: 4, Q4: 3, Q5: 61, Q6: 58. Všetky uvedené dopyty mali dostatočne veľkú množinu n-tíc, a preto boli dovolené. Ale kombinovaním týchto štyroch výsledkov môžeme vypočítať Karolínin priemer známok ako 4x61 – 3x58 = 70. Môže sa nám zdať, že sme mali pri zisťovaní Korolíninho priemeru šťastie, pretože Karolína je jediná žena na CS. Dá sa však ukázať, že je možné skonštruovať útok systematickým spôsobom. Najprv potrebujme stopára: Dopytovací predikát R, ktorý dovoľuje zistiť informáciu o jedinej n-tici sa nazýva individuálny stopár pre túto n-ticu. Všeobecný stopár je predikát G, ktorý sa môže použiť na nájdenie odpovede pre lubovoľný neprípustný dopyt. Nech G je všeobecný stopár a nech R je predikát (individuálny stopár), ktorý jednoznačne identifikuje n-ticu r, ktorú hľadáme. V našom prípade je predikát R: Name=’Carol’. Do databázy vytvoríme dva dopyty pomocou predikátov R OR G a R OR NOT(G). Náš cieľ r je jediná n-tica použitá v obidvoch dopytoch. Vybrali sme predikát G, aby sme zabezpečili, že oba dopyty sú prípustné z pohľadu dostatočného počtu položiek dopytovacej množiny a jej komplementu. Posledný dopyt v databáze nám dá všetky dáta na dokončenie útoku. Predikát Program = ’MIS’ je jedným z viacerých všeobecných stopárov. Budeme pokračovať dopytmi: Q7 : SELECT SUM(Units) FROM Students WHERE Name = ‘Carol’ OR Program = ‘MIS’ Q8 : SELECT SUM(Units) FROM Students WHERE Name = ‘Carol’ OR NOT (Program = ‘MIS’) Q9 : SELECT SUM(Units) FROM Students A dostaneme Q7: 75, Q8: 78 a Q9: 136. To znamená, že Karolína musela absolvovať (75+77) – 136 = 16 jednotiek. Skúsenosť ukazuje, že skoro všetky štatistické databázy majú všeobecného stopára. 24

Protiopatrenia Niektoré agregačné problémy sa dajú potlačiť starostlivým návrhom databázovej schémy. Statická analýza štruktúry databázy môže odhaliť citlivé vzťahy medzi atribútmi. Preto takéto atribúty sa uložia do oddelených tabuliek. Používateľ s prístupom iba do jednej tabuľky nie je ďalej schopný korelovať atribúty. Samozrejme, používateľ s prístupom do všetkých relevantných tabuliek je stále v pozícii to urobiť, ale manažér databázy tomu môže zamedziť nastavením presných privilégií. V našom príklade je citlivý vzťah medzi menom a priemernou známkou. Nahradíme teda tabuľku Students dvomi tabuľkami, ktoré sú prepojené študentským identifikačným číslom (ID). Prvá tabuľka je teraz klasifikovaná na dostatočne vysokej úrovni a iba autorizovaní používatelia môžu spojiť mená s priemernou známkou. Inferenčné problémy nie sú spôsobené jedným dopytom, ale inteligentnou kombináciou niekoľkých dopytov. Preto je potrebné sledovať, čo používateľ pozná. Toto nám poskytne asi najlepšiu bezpečnosť, ale je to tiež najdrahší prístup. Používateľove akcie sa zaznamenávajú do auditných logov a je potrebné vykonať analýzu dopytov a zistiť, či sa nevykonáva podozrivá sekvencia dopytov. Samozrejme je potrebné v prvom rade špecifikovať, čo sú podozrivé sekvencie dopytov. Ďalšie utesnenie ochrany je možné tak, že analýza dopytov bude brať do úvahy a zisťovať, čo vedia dvaja používatelia alebo skupina používateľov dohromady. 25

Rozdelenie tabuľky Student do dvoch tabuliek Name ID Alma B13 Bill C25 Carol C23 Don M38 Errol C12 Flora M22 Gala B36 Homer C10 Igor M20 ID Sex Programme Units Grade Ave. B13 F MBA 8 63 C25 M CS 15 58 C23 16 70 M38 MIS 22 75 C12 66 M22 81 B36 23 68 C10 7 50 M20 21 26

Integrácia s operačným systémom
Pokiaľ sa podívame na databázu z pozície operačného systému, vidíme množstvo procesov operačného systému a pamäťových zdrojov, ktoré ukladajú dátové položky. Z mnohých pohľadov má SRDB podobné povinnosti voči operačnému systému. Musí zastaviť používateľov od zasahovania jedného s druhým a so SRDB. Ak nechceme zdvojnásobiť úsilie, môžeme dať tieto úlohy operačnému systému. V takýchto nastaveniach SRDB beží ako množina procesov operačného systému. Existujú procesy systému na všeobecný manažment databázových úloh a každý používateľ databázy je mapovaný do oddeleného procesu operačného systému (viď pbrázok nižšie – Izolácia databázových používateľov operačným systémom). Teraz operačný systém je schopný rozlíšiť medzi používateľmi, a ak uložíme každý databázový objekt do vlastného súboru, potom operačný systém je schpný vykonať všetky riadenia prístupu. SRDB musí iba preložiť používateľove dopyty do operácií, ktorým rozumie oparačný systém. Art Zoe SRDB DB systém Art Zoe 27 procesy operačného systému

Integrácia s operačným systémom
Pridelením individuálneho procesu operačného systému každému databázovému používateľovi sa plytvá pamäťovými zdrojmi a nedá sa naškálovať na veľký počet používateľov. Preto sú potrebné procesy, ktoré narábajú s databázovými žiadosťami viacerých používateľov (viď obrázok nižšie – Izolácia databázových používateľov pomocou SRDB). Týmto prístupom ušetríme pamäť, ale zodpovednosť za riadenie prístupu teraz zostane napevno na SRDB. Podobné úvahy sa dajú aplikovať aj na úložisko databázových objektov. Plytvá sa, ak sú objekty príliš malé a majú oddelené súbory pre každý objekt. Akonáhle operačný systém nemá prístup k funkciám riadenia prístupu z pohľadu databázových používateľov, je môžné vyzbierať niekoľko databázových objektov do jedného súboru operačného systému. Art Zoe SRDB users: Art Zoe other Users: DB systém procesy operačného systému 28

Privátnosť Veľa organizácií z oprávnených dôvodov ukladajú osobné údaje o svojich zákazníkoch ako sú: meno, vek, číslo kreditnej karty, obľúbené jedlá alebo iné zvyky zákazníka. Údaje takéhoto typu sú zvyčajne chránené zákonom. Pri narábaní s takýmito údajmi je dôležitou otázkou súlad s právnymi a regulačnými obmedzeniami. Medzinárodné odporúčania na ochranu osobných údajov je odporúčanie OECD „Návody na ochranu privátnosti a cezhraničný tok osobných údajov“. Tieto návody stanovujú osem princípov ochrany, v ktorých údajový subjekt (data subject) je jednotlivec a údaje jemu odpovedajúce a ovládač údajov (data controller) udržuje databázu. Princíp obmedzenia zberu: Mali by existovať obmedzenia na zber osobných údajov. Údaje smú byť získané zákonným a férovým spôsobom a kde je to možné, so znalosťou alebo súhlasom údajového subjektu. Princíp kvality údajov: Osobné údaje by mali byť relevantné účelu, na ktorý sa idú použiť, presné, kompletné a aktuálne. Princíp špecifikácie účelu: Mali by byť špecifikované účely, na ktoré sú osobné údaje zbierané. Princíp obmedzeného použitia: Osobné údaje by nemali byť zverejnené alebo použité na iné účely ako je určené, okrem súhlasu údajového subjektu alebo súdnych orgánov. Princíp bezpečnostných opatrení: Osobné údaje by mali byť chránené opodstatnenými bezpečnostnými opatreniami. Princíp otvorenosti: Mala by existovať všeobecná politika otvorenosti o vytvorení, praktík a politík vo vzťahu k osobným údajom. 29

Privátnosť Princíp účasti jednotlivca: Jednotlivec by mal mať právo získať potvrdenie či ovládač údajov má alebo nemá údaje vo vzťahu k nemu, spochybniť údaje vztiahnuté na neho a dostať zdôvodnenie, prečo je takáto žiadosť odmietnutá. Princíp účtovateľnosti: Ovládač údajov by mal byť zodpovedný za súlad opatrení, ktoré uskutočnia princípy uvedené vyššie. Ďalším dôležitým dokumentom je Regulácia EU č. 2016/679 of the European Parliament and the Council of 27 April 2016 o ochrane jednotlivcov s ohľadom na spracovanie osobných údajov a o voľnom pohybe takýchto údajov. Direktívy EU nie sú zákony, ale musia byť transformované do národného práva členských štátov EU. Direktíva kladie silný dôraz na súhlas jednotlivca (používateľa). Používatelia sa môžu pridať (opt-in), čím indikujú súhlas s uložením svojich údajov. Alternatívnou politikou je nepridať sa (opt-out), v ktorej údajové subjekty musia explicitna udať, že údaje by nemali byť uložené. V USA je ochrana údajov vykonávaná sektorovými zákonmi. Napríklad zákon HIPAA z roku 1996 „Prenositeľnosť zdravotného poistenia a účtovateľnosť“ (the Health Insurance Portability and Accountability Act“) je federálny zákon ochraňujúci pacientove medicínske záznamy a iné zdravotné informácie poskytované zdravotnými programami, doktormi, nemocnicami a ďalšími poskytovateľmi zdravotnej starostlivosti. Zákon vstúpil do platnosti v roku 2003 a mal významný dopad na databázovú bezpečnosť a IT bezpečnosť všeobecne. 30

Privátnosť – platforma pre preferencie privátnosti
Webové sídla môžu oznamovať svoju politiku privátnosti. Používatelia môžu, teoreticky, overiť tieto politiky pred vydaním osobných údajov. V praxi sa to ťažko stane. Platforma pre preferencie privátnosti bola vydaná preto, aby automatizovala proces kontroly preferencií používateľovej privátnosti voči stanovenej politike webového sídla. Webové sídla by mali vyjadriť ich praktiky zbierania a používania údajov v štandardizovanom strojovo čitateľnom formáte XML známom ako politika P3P. Politiky by mali vysvetliť ako sú údaje zbierané, na aký účel budú údaje použité a každú voľbu s pridaním sa (opt-in) lebo nepridaním sa (opt-out) pre používanie údajov. Na strane klienta by mal byť vstavaný do prehliadača alebo plugg-inu prehliadača alebo vykonávavať sa na proxy serveri používateľovi agenti P3P. Používateľovi agenti by mali automaticky vykonať rozhodnutie v zastúpení používateľa porovnaním politiky P3P sídla s preferenciami privátnosti nastavených používateľom. Používatelia nepotrebujú čítať politiky privátnosti každého sídla, ktoré navštívia. P3P je deskriptívny jazyk. Používatelia musia „veriť“, že webové sídlo dodržuje svoje stanovené politiky. Zákony na ochranu údajov si môžu vyhradiť, že sídlo to dodržovať musí. Existuje samozrejme fundamentálna obava. Môžu automatizované akcie používateľovho agenta vôbec vyjadrovať používateľov súhlas ako je to požadované zákonmi na ochranu údajov? A nakoniec, P3P nenašiel dostatočnú podporu zo strany dodávateľov prehliadačov, aby bol široko akceptovaný. 31

Bezpečnosť databázových systémov

Similar presentations

Presentation on theme: "Bezpečnosť databázových systémov"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Bezpečnosť databázových systémov

Similar presentations

Presentation on theme: "Bezpečnosť databázových systémov"— Presentation transcript:

Similar presentations

About project

Feedback