![]() Specializovaný týdeník o výpočetní technice |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Seriál o bezpečnosti a informačním soukromí |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Část 25 - CW 35/97
Bezpečnost databázíJaroslav Dočkal
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ů:
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:
UPDATE PLATY SET PLAT = 5 000 WHERE PLATY.JMENO = Zeman se tabulka rozroste o další řádek:
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.
MLS Oracle 7.2 -- příklad víceúrovňového SŘBD
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. Seriál je rovněž dostupný na www.idg.cz/computerworld/bvsk/
| COMPUTERWORLD - seriál o bezpečnosti | COMPUTERWORLD | IDG CZ homepage | |