Část 25 - CW 35/97

Bezpečnost databází

Moderní systémy řízení bází dat (SŘBD) zajišťují bezpečnost uložených dat cestou všech známých bezpečnostních služeb vyjma nepopiratelnosti; jsou tedy schopny zajistit autentizaci, důvěrnost a integritu dat včetně řízení přístupu k nim. Kromě řízení přístupu jsou všechny tyto služby použitelné i pro přenos dat, naopak řízení přístupu slouží výhradně pro zabezpečení uložení dat a je službou typickou pro databáze. Opírá se navíc o své výlučné mechanismy, zatímco např. všechny ostatní bezpečnostní služby lze zajistit všeobecně používanými mechanismy (např. šifrováním nebo digitálním podpisem). Proto právě řízení přístupu bude v článku věnována hlavní pozornost. Článek neřeší všechny problémy spojené s bezpečností -- nezabývá se mj. známým problémem inference (např. ze specializace doktora lze přibližně vyvodit chorobu pacienta) ani problém agregace (např. celková suma peněz na platy není utajovaná, ale platy jednotlivých pracovníků ano), ale o těchto problémech již byla zmínka v minulých dílech našeho seriálu.

Dvě podoby řízení přístupu k databázi

Řízení přístupu k databázi má dvě podoby

-- Volitelné řízení přístupu -- Discretionary Access Control (dále jen DAC). Oprávněný uživatel přiděluje potřebná přístupová práva (privilegia) k objektu individuálně pro jednotlivé uživatele nebo jejich skupiny. Přístupová práva mohou být pružně měněna a kombinována objekt od objektu. Zatímco jeden subjekt má u jednoho objektu vyšší úroveň přístupových práv, u druhého objektu tomu může být naopak.

-- Povinné řízení přístupu -- Mandatory Access Control (dále jen MAC). Bezpečnostní úředník objekty člení do předem stanovených bezpečnostních úrovní (pomocí bezpečnostních návěští) a subjekty zařazuje do skupin s příslušnými přístupovými právy. Autorizace je zde stejným procesem pro celou bezpečnostní úroveň. Pokud má subjekt více privilegií k nějakému objektu než jiný subjekt, nemůže jich mít k jinému objektu méně.

Schéma DAC

Bezpečnostní politika musí být vyjádřena příslušnými bezpečnostními pravidly (konkrétně u databází jde o autorizační pravidla) a nad jejich vykonáním musí dohlížet bezpečnostní systém (u databází autorizační podsystém). Autorizační podsystém musí obdržet autorizační pravidla, kterým bude rozumět, tj. v podobě klauzulí jazyka SQL. Např. nové bezpečnostní pravidlo lze zavést formulí (hypotetická podoba):

CREATE SECURITY RULE pravidlo

GRANT seznam_privilegií

ON výraz

TO seznam_uživatelů

[ON ATTEMPTED VIOLATION akce]

kde pravidlo označuje jméno nového bezpečnostního pravidla, seznam_privilegií uvádí oprávnění, výraz obsahuje výraz relační algebry a akce určuje proceduru činnosti v případě porušení bezpečnostního pravidla (obvyklé je odmítnutí příkazu; může být zvoleno i ukončení programu, uzamknutí uživatelovy klávesnice, provedení zápisu do log souboru atd.).

Mějme například relaci EVIDENCE, do které jsou uloženy výsledky zkoušek na vysoké škole (položka ZNAMKA); chceme např. učiteli Beranovi povolit opravy udělených známek a všem ostatním uživatelům jakékoliv změny zakázat. Pak definujeme příslušné bezpečnostní pravidlo následujícím způsobem:

CREATE SECURITY RULE SR1

GRANT UPDATE (EVIDENCE#, ZNAMKA)

ON EVIDENCE WHERE EVIDENCE.PREDMET=FYZIKA

TO Beran

ON ATTEMPTED VIOLATION REJECT;

Kdo je vlastně ten "oprávněný uživatel", uvedený při zavádění pojmu DAC? To závisí na konkrétním SŘBD, protože administraci autorizace lze řešit různými politikami; vše může určovat administrátor databáze, administrovat objekt může také ten, kdo ho vytvořil, anebo kdokoliv, kdo obdrží povolení od jeho vlastníka (delegování práv). V každém případě je schéma DAC založeno na principu vlastnictví objektu. Výsledkem je velká pružnost schématu DAC.

Použití schématu DAC přináší několik omezení a rizik:

-- Nevýhody plynoucí z koncepce "vlastnictví informace". Jde hned o dvě nevýhody: Jednak lze každé vlastnictví odcizit a za druhé je zde problém s centrálním monitorováním stavu zodpovědnosti.

-- Kaskádování autorizace předáváním vlastnictví vede k problémům s "revokací", což znejisťuje vlastníky. Příklad: Vlastník Beran předal přístupové právo na čtení objektu uživatelům Noha a Zeman. Uživatel Noha předá totéž právo Zemanovi. Pak se ale rozhodne, že mu ho odebere. Nemůže si však být vůbec jist, že o toto právo uživatel Zeman přišel.

-- Riziko útoků typu Trojský kůň. Například uživatel Beran může získat neoprávněně přístupové právo k objektu, jehož vlastníkem je uživatel Noha, následujícím postupem: Vytvoří si svou verzi třídicího programu tak, že standardní program doplní o instrukce čtení příslušného objektu. Pak stačí třídicí program nahradit upravenou verzí a v klidu čekat, až se pustí uživatel Noha do třídění.

-- Problémy s view (předzpracované pohledy na databázi). Že má každý uživatel přiděleno své view je z jedné strany velká výhoda; například nastoupí nová operátorka a dostane přiděleno standardní view vytvořené pro operátory. Z druhé strany je to však také nevýhoda: operátorka může pořizovat data pouze v rozsahu svého view, ale ne v rozsahu view např. ředitele. Konkrétně pak ředitel musí pořizovat všechny údaje o platech sám, i když jsou tajné jen některé.

Schéma MAC

Schéma MAC je aplikací principu víceúrovňové bezpečnosti (multilevel security - MLS, viz 22. část seriálu) do databázového prostředí. Toto schéma je vhodné pro databáze, ve kterých mají data spíše statický a rigidní charakter -- tj. pro prostředí armády a dalších státních institucí.

Zatímco známá Orange Book amerického ministerstva obrany definuje množinu bezpečnostních požadavků pro libovolný TCB (Trusted Computing Base), interpretaci požadavků na TCB databázových systémů popisuje tzv. Lavender Book (zde je obal levandulové, tj. modročervené barvy). Zatímco schéma DAC je charakteristické pro systémy úrovně C, resp. D, schéma MAC najdeme u systémů úrovně B, resp. A. V rámci schémat MAC by mělo platit v souladu s modelem Bell-LaPadula (viz 3. a 22. díl seriálu) No-read-up, No-write-down, v praxi se však většinou připouští zápis pouze na vlastní úrovni. Je zřejmé, že zde nejde jen o ochranu před neautorizovaným přístupem jako u schématu DAC, ale i o řízení toku dat v databázi -- neboli o ochranu před útoky typu Trojský kůň.

Co je vlastně poskytnuto uživateli nižší úrovně při dotazu na relaci, obsahující údaje různých bezpečnostních úrovní? Nechť je například relace dána následující tabulkou platů:

JMENO	BU-J	FIRMA	BU-F	PLAT	BU-P	BU-Z
Beran	N Korona N 6 000 N N
Noha	V	Security AB	V	45 000	V	V
Zeman	N	Korona	N	7 000	V	V

Zde BU-J označuje bezpečnostní úroveň položky jméno, BU-F bezpečnostní úroveň položky FIRMA atd. až BU-Z označuje bezpečnostní úroveň záznamu s primárním klíčem JMENO, N nízkou úroveň bezpečnosti, V vysokou úroveň bezpečnosti (pro jednoduchost se omezíme na dva stupně). Výpis tabulky se pro uživatele nižší úrovně zredukuje následujícím způsobem:

JMENO	BU-J	FIRMA	BU-F	PLAT	BU-P	BU-Z
Beran	N	Korona	N	6 000	N	N
Zeman	N	Korona	N	0	N	V

Neboli z tabulky zmizí řádky s položkami výhradně vyšší bezpečnostní úrovně a řádky s položkami obou úrovní v tabulce zůstanou, ale s vynulovanými položkami, které byly v původní tabulce vyšší úrovně. Aby zde nedošlo k vytvoření skrytého kanálu typu "tato položka má utajovanou hodnotu", musí být daná položka zaplněna běžnou nulovou hodnotou.

V relacích vytvořených dle schématu MAC se lze setkat s něčím, co by se dalo česky nazvat problém vícenásobného výskytu (polyinstantiation). Původcem může být

-- uživatel nižší úrovně, který doplňuje tabulku o data vyšší úrovně (výsledek nemůže vidět),

-- uživatel vyšší úrovně, který přesouvá data již uložená v tabulce z nižší na vyšší úroveň (ten výsledek samozřejmě uvidí).

Důsledkem mohou být dvě situace:

-- vícenásobné řádky -- více řádků má stejný primární klíč,

-- vícenásobné položky -- ke stejnému primárnímu klíči jsou vztaženy hodnoty atributů s různými úrovněmi.

Například uživatel nižší úrovně provede operaci

INSERT INTO PLATY VALUE (Noha, Korona, 5 000)

Ačkoliv záznam o Nohovi již v tabulce existuje, uživatel nižší třídy ho nevidí a řádek je do tabulky doplněn, viz následující tabulka:

JMENO	BU-J	FIRMA	BU-F	PLAT	BU-P	BU-Z
Beran	N	Korona	N	6 000	N	N
Noha	V	Security AB	V	45 000	V	V
Zeman	N	Korona	N	7 000	V	V
Noha	N	Korona	N	5 000	N	N

Obdobně je vložen nový řádek, pokud je uživatelem nižší úrovně aktualizována hodnota vyšší úrovně, například příkazem

UPDATE PLATY SET PLAT = 5 000 WHERE PLATY.JMENO = Zeman

se tabulka rozroste o další řádek:

JMENO	BU-J	FIRMA	BU-F	PLAT	BU-P	BU-Z
Beran	N	Korona	N	6 000	N	N
Noha	V	Security AB	V	45 000	V	V
Zeman	N	Korona	N	7 000	V	V
Noha	N	Korona	N	45 000	N	N
Zeman	N	Korona	N	5 000	N	V

Vícenásobné řádky se mohou vztahovat ke stejné nebo k různým entitám; hovoříme pak o položkové anebo řádkové vícenásobnosti. Moderní modely (např. SeaView) umožňují oba přístupy.

Schéma MAC má však také své problémy:

-- Granualita bezpečnostních objektů. Existuje široká škála názorů na to, na jaké úrovni přidělovat bezpečnostní návěští: zda celé databázi, souborům, relacím, atributům nebo dokonce i hodnotám atributů. Čím je však zvolen detailnější přístup, tím obtížněji se uživateli specifikuje bezpečnostní úroveň. Navíc to u rozsáhlé databáze musí být opravdu pracný proces.

-- Těžkopádnost pravidel Bell-LaPadulova modelu: Například bezpečnostní pravidla organizace vyžadují, aby uživatel vyšší úrovně podepsal dokument zpracovaný pracovníkem nižší úrovně (uplatnění "principu čtyř očí"). Ale podle pravidel Bell-LaPadulova modelu zapisovat na nižší úroveň nelze (integrita zde dostává na frak na úkor důvěrnosti).

Bezpečnost objektově-orientovaných databází

Relační modely se ukazují jako vhodné pro realizaci víceúrovňové bezpečnosti, zatímco objektově-orientovaný přístup se zatím setkává s celou řadou problémů. Protože je přístup řízený k celé třídě objektů, dotaz na jeden z nich si vyžaduje autorizaci na celou třídu. Koncepce vlastnictví také nemá jednoznačnou interpretaci v kontextu objektově-orientovaných databází. Kdo je vlastně vlastníkem instance vytvořené jiným uživatelem, než je vlastník třídy? A nakonec -- u objektově-orientovaných modelů jsou jednotkou přístupu instance objektů a bylo by logické, aby autorizace byla vztažena právě k nim. To by však často mohlo vést k neúměrné zátěži na databázi.

Problémy jsou také s vytvořením MAC modelů pro objektově-orientované databáze. Aby mohl být z důvodu verifikovatelnosti splněn požadavek na co nejmenší bezpečnostní monitor, je vhodné, aby všechny atributy objektu byly stejné úrovně. Pro řadu objektů je však toto omezení nepřijatelné. Vypořádání se s rozporuplnými požadavky na zabezpečení objektově-orientovaných databází je dodnes aktuální téma vědeckého výzkumu.

Závěrem

V oblasti systémů MLS jsou dnes na trhu pro třídu B1 (viz Orange Book) certifikované produkty firem Oracle a Informix; podmínky ekvivalentní bezpečnostní třídy E3 (evropská klasifikace) splňuje navíc i verze produktu INGRES firmy Computer Associates. Z bezpečnostního, výkonového i uživatelského hlediska poskytuje dlouhodobě nejlepší řešení nejspíše Oracle -- jejímu systému MLS se vyplatí

věnovat pozornost.

Jde o již třetí certifikovanou verzi MLS systému této firmy, je tedy zřejmé, že firma Oracle má v oblasti MLS systému nejvíce zkušeností. Z hlediska bezpečnosti má proto tento produkt řadu předností:

-- Ačkoliv práce v MLS prostředí bývá obvykle těžkopádná, firma Oracle poskytuje takové prostředí, ve kterém je práce relativně snadná a pružná.

-- MLS systémy je náročné realizovat pro práci v distribuovaném prostředí. Zde je tomu naopak, zvláště efektivně jsou u MLS Oracle realizovány replikace.

-- V rámci Secure Network Services lze zajistit šifrování pro veškerý síťový provoz. Konverze dat mezi různými síťovými protokoly probíhá bez jejich rozšifrování. Šifruje se pomocí RC4 resp. DES, pro kontrolu integrity slouží algoritmus MD5. Distribuce klíčů je založena na algoritmu Diffie-Hellmana.

-- Zašifrované relace lze umisťovat do datových zdrojů mimo Oracle. Interoperabilita s jinými šifrovacími systémy je zajištěna pomocí mechanismu dojednávání.

-- Pro autentizaci lze použít Smart Cards (např. SecureID firmy Security Dynamic), biometrické zařízení (např. Touch Safe II firmy Identix) anebo softwarové autentizační systémy (např. Kerberos od verze 5.4 anebo Sezame). Od konce roku 1996 lze ověřovat totožnost uživatele kartou Fortezza.

-- Více databází Oracle lze administrovat z jednoho místa pomocí DCE (Distributed Computing Environment). Integrace se službami DCE je velmi pružná, například si lze vybrat pouze integraci s bezpečnostními službami.

V prodeji je tato verze již od října roku 1996. Nyní přichází firma Oracle s verzí 8 svého systému a dá se tedy po jisté době očekávat její MLS provedení. Projektanti systémů s vysokými nároky na bezpečnost se proto mají na co těšit.