Návrh bezpečných databázových systémů

Daniel Cvrček
ÚIVT FEI VUT Brno
cvrcek@dcse.fee.vutbr.cz

Abstrakt
V této přednášce se budu věnovat logické databázové bezpečnosti. Logický návrh a bezpečnostních pravidel zahrnuje jak bezpečný OS, tak i bezpečný databázový systém a další bezpečnostní procedury.

Celá přednáška je rozdělena na dvě části. V první části bych stručně zrekapituloval mechanismy, různé architektury bezpečných databází. Ve druhé částí bude rozebrán celý proces návrhu databázového systému.

Obsah

1. Bezpečnostní požadavky
    1.1 Tajemství
    1.2 Integrita
2. Architektury bezpečných databázových systémů
    2.1 Trusted Subject Architecture
    2.2 The Woods Hole Architecture
        2.2.1 Integrity Lock Architecture
        2.2.2 Kernelized Architecture
        2.2.3 Replicated Architecture
        2.2.4 Poznámky
3. Návrh bezpečného DBMS
    3.1 Úvodní analýza (preliminary analysis)
    3.2 Analýza požadavků a výběr politik
        3.2.1 Kritéria pro výběr politik
    3.3 Konceptuální návrh
    3.4 Logický návrh
    3.5 Fyzický návrh
        3.5.1 Implementace bezpečnostních mechanismů
    3.6 Verifikace a testování
4. Literatura

1. Bezpečnostní požadavky

Návrh databázového systému by měl brát bezpečnostní otázky v úvahu už od počátku. Důvodem je cena, protože upravit existující systém na bezpečný je řádově náročnější a dražší, než zakomponování bezpečnostních prvků již ve fázi návrhu, kdy jsou tyto náklady velmi nízké.

1.1 Tajemství

Jestliže budeme na databázi požadovat zachování tajemství v ní uchovávaných informací, pak bychom měli brát v úvahu následující požadavky:

1.2 Integrita

Tak jako existují požadavky na zajištění tajemství informace, tak existují i obecné principy pro zajištění integrity dat, které jsou nezávislé na kontextu DBMS, nebo na charakteristice aplikací.

2. Architektury bezpečných databázových systémů

Bezpečné databázové systémy mohou pracovat ve dvou různých režimech: system-high a multilevel. V prvním případě mají všichni uživatelé maximální bezpečnostní úroveň a odpovědná osoba musí kontrolovat nová data před tím, než budou uvolněna do systému.

Pro druhou možnost existuje několik typů architektur, které jsou založeny jak na důvěryhodných, tak i na nedůvěryhodných DBMS. Základní dvě architektury jsou Trusted subject architecture a Woods Hole Architecture. Tu druhou je možno rozdělit na Integrity Lock, Kernalized architectures a Replicated architectures.
 
 
Typ architektury
Výzkumný prototyp
Komerční produkt
Integrity Lock
Mitre
TRUDATA
Kernelized
SeaView
Oracle
Replicated
NRL
 
Trusted Subject
A1 secure DBMS
Sybase, Informix, Ingres, Oracle, DEC, Rubix
 

2.1 Trusted Subject Architecture

Nedůvěryhodná rozhraní jsou použita k připojení uživatelů na určité bezpečnostní úrovni. Samotný DBMS už je důvěryhodný, tak jako i OS. Databázový a operační systém jsou jedna entita a tvoří TCB.

2.2 The Woods Hole Architecture

Tato architektura vznikla v roce 1982 a je rozdělena na tři už zmiňované podtřídy. Obecné schéma je na obrázku.

Uživatele pracují s množinou nedůvěryhodných rozhraní pro různé bezpečnostní úrovně. Ty komunikují s důvěryhodným rozhraním (front end), které funguje jako referenční monitor. samotný databázový systém je opět nedůvěryhodný.

2.2.1 Integrity Lock Architecture

Nedůvěryhodná rozhraní jsou odpovědná za zpracování dotazu, optimalizaci a projekce. Důvěryhodný filtr má za úkol vynucovat bezpečnostní funkce a víceúrovňovou ochranu (ekvivalent TCB).
 Víceúrovňovou ochranu zabezpečuje přidáváním bezpečnostních štítků k objektům - stamps. Ty obsahují kontrolní data v zašifrované podobě (mechanismu se říká Integrity Lock). Při přístupu k datům jsou tyto “pečeti” zkontrolovány a na jejich základě se rozhodne o povolení přístupu. Při tomto uspořádání se zabrání nebezpečí změny klasifikace Trojskými koňmi. Systém ovšem není odolný proti inferenčním útokům a proti úniku informací přes Trojské koně.
Aby bylo možno zabránit těmto nebezpečím, je nutné, aby všechny operace nad daty (selekce, projekce, zpracování poddotazů, optimalizace a statistické operace) byly v TFE, nebo v UFE, zatímco databáze je odpovědná pouze za uložení a získání dat. Tak může TFE eliminovat data s vyšší klasifikací. Denning navrhl úpravu, kdy mezi uživateli a DBMS je komunikační filtr, který pokrývá inferenční rizika.

Původ tohoto řešení je ovšem v přístupu Maximal authorized view. Každý dotaz je vyhodnocen podle pohledu, který obsahuje všechna data, která uživatel může vidět. Tak je vytvořen qsec a je zabráněno inferenci. Zadní filtr (back-end filter) je odpovědný za definici tohoto maximálního pohledu (vyjmutí neoprávněných položek).

Tato architektura byla zahrnuta do produktů TRUDATA a do relačního databázového stroje Sharebase.

2.2.2 Kernelized Architecture

Je použit důvěryhodný operační systém, který je odpovědný za fyzický přístup k databázi a za vynucení povinného řízení přístupu. Jak je vidět, tak uživatel s vysokým oprávněním pracuje nad “vysokou” databází přes TFE a uživatelé s nízkým oprávněním nad “nízkou”. Dotazy jsou poslány do OS, který získá správná data z databáze. Data z databáze musí být rozděleny do OS objektů podle bezpečnostní úrovně.
 
Je nutné implementovat dekompozici víceúrovňových relací a obnovu. Obnovou se myslí opětné vytvoření víceúrovňových relací ze získaných jednoúrovňových. Všechny operace jsou zaznamenávány na úrovni OS v auditním záznamu (vysoký bezpečnostní stupeň).

Přístup je implementován v systému Oracle.

2.2.3 Replicated Architecture

V této metodě jsou použity dvě databáze. Jedna pro nízké objekty, druhá pro nízké a vysoké objekty. Problémem je, kromě vysoké ceny, vytvoření bezpečných synchronizačních algoritmů pro konzistentní replikaci dat. Cena těchto algoritmů samozřejmě roste se zvětšováním svazu bezpečnostních úrovní.
 

2.2.4 Poznámky

Volba architektury závisí na prostředí. Kernelized architecture vyhovuje tam, kde jsou jednoúrovňové tabulky, protože je nejlevnější a snadno implementovatelná. Jestliže ovšem potřebujeme velkou pružnost bezpečnostních označení a vysoký stupeň integrity mezi DBMS a OS, tak použijeme Integrity Lock architecture. Architektura tructed subject je vhodná, jestliže jsme schopni zajistit bezpečnou cestu mezi aplikacemi a DBMS.

Co se týká ohodnocení modelů, tak nejjednodušší je to u Integrity lock, zatímco u Trusted subject musíme kontrolovat i funkce, jež jsou jinak součástí bezpečného OS.

3. Návrh bezpečného DBMS

Bezpečnost databázového systému je buď prvořadým cílem, který je uvažován už při návrhu systému, nebo je nutno upravit již existující systém tak, aby vyhovoval nově vzniklým bezpečnostním požadavkům. Obvykle je uplatňován druhý postup, kdy jsou k existujícímu systému přidávány bezpečnostní programové balíky.

Vhodnou referencí pro klasifikaci bezpečných systémů, ale také šablonou pro vývoj nových systémů je orange book, nebo evropský “skoro ekvivalent” ITSEC. Tyto dokumenty je možno použít na zjištění všech klíčových požadavků, které by měli být vzaty v úvahu.

Platným nástrojem při tvorbě databáze je několika stupňová metodologie, která je v souladu s moderními principy návrhu programových systémů. Metodologie, jež je navržena v rámci doporučení DoD má následující fáze:

Tento postup umožňuje, aby bezpečnostní návrh byl včleněn do návrhu databáze jako takové. Výhody takového přístupu jsou již dnes celkem známé. Co se týká bezpečnosti tak nejdůležitější je oddělení mechanismů od politik, což nám umožňuje:

3.1 Úvodní analýza (preliminary analysis)

Úkolem je provést studii proveditelnosti pro bezpečnostní systém (po rozhodnutí na strategické úrovni). Tato studie se skládá z ohodnocení rizik a z odhadu ceny jak návrhu, tak samotného systému. Také jsou definovány aplikace, jež je nutno vytvořit a jejich priorita. V úvahu je nutno brát: Výsledkem této fáze je: množina hrozeb, kterým bude systém vystaven podle priority a dále vyhodnocení použitelnosti existujících mechanismů spolu se specifikací těch mechanismů, jež je třeba vytvořit.

Jestliže analýza ceny a zisku je kladná, tak se pokračuje další fází.

3.2 Analýza požadavků a výběr politik

Prvním krokem je přesná studie všech možných hrozeb, kterým může být systém vystaven. Požadavky na ochranu se mohou velmi lišit. Prvním měřítkem je citlivost dat. Dále je možno rozdělit systémy na vysoce rizikové a nízko rizikové v závislosti na úrovni korelace mezi daty, sdílení dat uživateli, přístupnosti dat (kdo může přistupovat k jakým datům a za jakým účelem), schopnostech a množství uživatelů a vybraných technologiích (certifikované nebo dostatečně testované produkty kontra nedůvěryhodní tvůrci programů).

Během tohoto kroku by měl být určen stupeň zranitelnosti systému podle útoků na prostředí budoucího nasazení systému. Systematický přístup se skládá z kroků

Výsledkem je definice přístupových práv, tříd uživatelů s povolenými oprávněními k databázi a bezpečností požadavky ve formě neformálních vět.

3.2.1 Kritéria pro výběr politik

3.3 Konceptuální návrh

V této fázi jsou požadavky a politiky z předchozí části formalizovány. Implementace ještě stále není uvažována. Konceptuální bezpečnostní model je definován: Model by měl reprezentovat sémantiku databázové bezpečnosti, měl by podporovat analýzu toků oprávnění a také by měl být oporou pro administrátora při tvorbě dotazů na aktuální stav oprávnění.

Základními vlastnostmi konceptuálního modelu jsou kompletnost a konzistence a neredundance. V této fázi je možné ověřovat vlastnosti bezpečnostního systému.

Jelikož je tento krok velmi obtížný, je nutné vždy na závěr provést jak validaci, tak verifikaci.

3.4 Logický návrh

Konceptuální bezpečnostní model je transformován do logického modelu, jež je použit v daném databázovém systému. Navíc je nutno brát ohled na mechanismy OS. Účelem je identifikovat bezpečnostní požadavky, jež mohou zajistit existující prostředky. Závěrem této části návrhu je určení, které požadavky může plnit OS, které DBMS a pro které je nutno vytvořit nové mechanismy.

3.5 Fyzický návrh

V této fázi jsou rozpracovány detaily ohledně organizace paměti, vlastní implementace, případně integrace požadovaných mechanismů. Fyzická struktura přístupových pravidel, jejich vztah k fyzickým strukturám databáze.

Zpětná vazba při problémech je na konceptuální a logický návrh.

3.5.1 Implementace bezpečnostních mechanismů

Tady se zmíním jen o základních pravidlech pro vytváření nových bezpečnostních mechanismů.

3.6 Verifikace a testování

Cílem této poslední fáze je ověření správnosti implementace zvolených bezpečnostních požadavků a politik. Metody pro tento účel můžeme rozdělit na formální a neformální.

Neformální:

Jejich výhodou je rychlá aplikovatelnost, ale není možno provést kontrolu chování programu ve všech situacích.

Formální metody jsou dokonalejší, díky základnímu matematickému modelu. Příkladem může být dokazování bezpečnostních axiomů pro ověření formálního modelu požadavků. Nejabstraktnější formální specifikace jsou zjemňovány až do specifikací na úrovni vývoje programu. Verifikace pak probíhá odzdola nahoru.

4. Literatura

[1] Castalo S., Fugini M. G., Martella G., Samarati P.: Database security. Addison-Wesley & ACM Press, 1995