Informační bezpečnost

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

Obsah

1. Úvod
2. Databázová bezpečnost
3. Bezpečnostní modely v databázích
    3.1 Hrozba
4. Požadavky na ochranu databází
5. Kontroly bezpečnosti
    5.1 Kontrola toků
    5.2 Kontrola infrerence (odvození)
    5.3 Kontrola přístupu
        5.3.1 Bezpečnostní politika
        5.3.2 Bezpečnostní mechanismy
6. Bezpečnostní modely
    6.1 Úrovně modelů
    6.2 Discretionary kontra mandatory
    6.3 HRU - maticový přístupový model
        6.3.1 Autorizační stav
        6.3.2 Přístupová práva
        6.3.3 Administrace autorizací
        6.3.4 Implementace
        6.3.5 Rozšíření modelu
    6.4 Bell-LaPadula
        6.4.1 Stav systému
        6.4.2 Operace
        6.4.3 Axiomy
    6.5 Autorizační model ORION
        6.5.1 Subjekty
        6.5.2 Objekty
        6.5.3 Přístupová práva
        6.5.4 Oprávnění
        6.5.5 Hierarchie dědičnosti
7. Modely založené na metodách
    7.1 Model Iris
    7.2 Filtr zpráv
        7.2.1 Entity
        7.2.2 Tok informací
        7.2.3 Algoritmus filtrování zpráv
        7.2.4 Reprezentace klasifikačního požadavku
    7.3 Kontrola přístupu založená na rolích (Role-Base Access Control)
    7.4 Kontrola přístupu založená na úlohách (Task-Based Authorization Control)
8. Poznámky k bezpečnosti v OODBMS
    8.1.1 Discretionary policy
    8.1.2 Mandatory policy
9. Literatura

1. Úvod

Rychlý vývoj IT v minulých letech vedl k rozšíření informačních systémů v rozličných veřejných a soukromých organizacích. Informační systémy začaly být používány pro správu ohromného množství dat. Právě toto množství bylo důvodem vzniku speciálních prostředků a technik schopných uspokojit požadavky na rozumnou správu dat. Výsledkem byl vznik systémů řízení báze dat (DBMS).

Cílem těchto systémů byl a je efektivní přístup k požadovaným informacím uchovávaných v databázích. Velmi rychle začalo být potřeba zajištění souběžného přístupu k datům. S vývojem distribuovaného zpracování a počítačových sítí tedy vznikly distribuované databázové systémy, které opět rozšířily oblast použitelnosti informačních systémů.

S rostoucím množstvím databázových systémů a dat, jež spravovaly se ovšem objevily vážné problémy ohledně bezpečnosti dat. Poškození databáze už neovlivnilo jednoho člověka, ale např. informační systém celého podniku a dopady se staly nepředvídatelnými. Vzhledem ke zjednodušování rozhraní člověk/počítač se data staly dostupnými pro různé druhy uživatelů a tím se bezpečnostní problémy ještě zostřily.

To jsou důvody, proč je v databázových technologiích životně důležitá jednak nepřetržitost a spolehlivost, ale také ochrana před neoprávněnými vniknutími od systému, či modifikacemi a prozrazením informací.

Jestliže se tedy rozhodneme navrhnout a implementovat bezpečný informační systém, dostaneme se před velmi složitý problém, jehož řešení závisí na množství faktorů, na něž musíme brát zřetel (různorodost uživatelů, zrnitost a územní rozšíření informačních systémů, nekontrolovatelné a neočekávané následky ztráty dat a obtíže při modelování, specifikaci a ověřování bezpečnosti dat).

2. Databázová bezpečnost

Zajištění bezpečnosti dat v databázích se skládá ze tří aspektů: tajemství, integrita a dostupnost. Co tyto tři principy znamenají? Zajištění tajemství - prevence, zjištění a odstrašení subjektů od prozrazení informace. Tento aspekt se týká silně chráněných oblastí, jako jsou armáda, nebo oblasti v obchodním prostředí. Privacy (soukromí) se týká informací o jednotlivcích a může být definováno jako právo jednotlivce, skupiny, nebo organizace určovat kdy, jak a pro jaký účel jsou informace o něm shromažďovány, ukládány a zpřístupňovány dalším entitám.

Zajištění integrity - prevence, zjištění a odstrašení subjektů od nesprávných změn informace. Správná činnost každé organizace závisí na správných operacích nad správnými daty.

Dostupnost systému - znamená, že nedojde k neoprávněnému zamítnutí přístupu ke službám poskytovaných systémem.

3. Bezpečnostní modely v databázích

Výsledkem použití DBMS je, že různé aplikace a uživatelé v organizaci pracují nad jednou množinou dat. Na jednu stranu tento přístup řeší problémy jako duplikace, nekonzistence dat, nebo závislost dat na aplikacích. Na druhou stranu se stávají bezpečnostní hrozby vážnějšími a důležitějšími.

Dosáhnutí bezpečnosti znamená identifikaci hrozeb a výběr správných politik (co je od bezpečnostního systému očekáváno) a mechanismů (jak se toho má dosáhnout). S tím souvisí i zajištění důvěryhodnosti bezpečnostního systému (jak dobře uspokojuje bezpečnostní systém kladené požadavky).

3.1 Hrozba

Hrozba může být definována jako nepřátelský činitel, který buď náhodně, nebo použitím specializovaných technik může získat, nebo změnit informace v IS. Bezpečnostní hrozby mohou být klasifikovány podle různých hledisek. Nyní bych použil rozdělení na podvodné a nepodvodné (náhodné).

přírodní, nebo náhodné pohromy - zemětřesení, poškození vodou, nebo oheň. Zde dochází k poškození zařízení i dat a z toho vyplývající porušení integrity a odmítnutí služby.
chyby a závady v zařízení a programech - to může vést k nesprávné aplikaci bezpečnostních politik.
lidské chyby - neúmyslné poruchy, jako nesprávný vstup, nebo nesprávné použití aplikací.

U úmyslných hrozeb rozlišujeme dvě třídy uživatelů:

oprávnění uživatelé - kteří mohou zneužít svá oprávnění
nepřátelští činitelé - různé typy nepřátelských programů - viry, trojské koně, skrytá vrátka

4. Požadavky na ochranu databází

Ochrana před neoprávněným přístupem - přidělení přístupu do databáze pouze oprávněným uživatelům. Kontrola je činěna na menší objekty (záznam, atribut, hodnota).
Ochrana před inferencí - odvození důvěrné informace z přístupných dat. Toto se týká hlavně statistických databází.
Ochrana integrity databáze - částečně je zajištěna systémovými kontrolami DBMS (např. atomičnost transakcí) a různými zálohovacími a zotavovacími procedurami a částečně bezpečnostními procedurami.
Ochrana operační integrity dat - logická konzistence dat během souběžných transakcí (cuncurrency manager), serializovatelnost a izolovanost transakcí (zamykací techniky).
Ochrana sémantické integrity dat - zajištění hodnot atributů v povolených rozsazích. Kontrola je dána integritními omezeními.
Odpovědnost a audit - požadavek se skládá z možnosti záznamu všech přístupů k datům.
Ověření uživatele - jednoznačná identifikace uživatelů databáze. Identifikace uživatele je základem každého autorizačního mechanismu.
Správa a ochrana citlivých dat - přístup je umožněn jen úzkému okruhu uživatelů.
Víceúrovňová ochrana - například rozdělení dat podle jejich citlivosti a podle toho řídit přístup k těmto datům.
Oddělení subjektů - nutnost při snaze zabránit nepovolenému přenosu dat mezi programy (autorizované kanály, paměťové kanály, skryté kanály).

5. Kontroly bezpečnosti

Databázová ochrana může být zajištěna pomocí bezpečnostních opatření pro

kontrolu toků
kontrolu inferencí
kontrolu přístupu

K těmto kontrolám je možno přidat kryptografické techniky, které sestávají z kódování uložených dat pomocí tajného šifrovacího klíče.

5.1 Kontrola toků

Kontrola toků reguluje distribuci (tok) informací mezi dostupnými objekty. Např. čtení informace z objektu X a její přímý zápis do objektu Y.

Politiky kontroly toků požadují seznam, nebo omezení přípustných toků. Často jsou problémy s tímto spojené řešeny klasifikací prvků systému a následnou definicí povolených toků mezi kategoriemi.

5.2 Kontrola infrerence (odvození)

Cílem této kontroly je zabránit nepřímému odhalení. To znamená, že množinu dat X, jež může uživatel číst je možno použít ke zjištění množiny dat Y (Y=f(X)). Způsoby neoprávněného získání informace jsou tři:

souvztažná data - typický kanál, kdy viditelná data X jsou sémanticky spojena s neviditelnými daty Y.
chybějící data - při dotazu, se místo neviditelných dat objeví hodnoty null, které maskují citlivá data. Tím můžeme zjistit existenci takových dat.
statistické odvození - typické pro databáze, které poskytují statistické informace a entitách.

Přístup k jednotlivým datům není povolen a dotazovat se lze pouze pomocí statistických dat. Útokům můžeme čelit dvěma typy kontrol:

rozrušením dat - konkrétní data jsou nahrazeny výsledky statistických funkcí
kontrolami dotazů - více používané, většinou je založena na minimálním a maximálním množství položek, jichž se dotaz týká. Napříč uspokojivým výsledkům je tato technika drahá a obtížná na správu.

5.3 Kontrola přístupu

Kontrola přístupu je odpovědná za dodržení pravidel určených ochrannými politikami pro všechny přímé přístupy k objektům v systému. Systém kontroly přístupu pracuje s pojmy subjekty, objekty a operace. Funkčně se skládá ze dvou částí:

Množina přístupových politik a pravidel - informace o povolených přístupech
Množina kontrolních procedur (bezpečnostních mechanismů) - kontrolují požadavky na přístup vzhledem k pravidlům

5.3.1 Bezpečnostní politika

Bezpečnostní politiky systému jsou abstraktními směrnicemi ohledně návrhu a správy autorizačných systémů. Obecně vyjadřují základní volby pro bezpečnost dat. Politiky můžeme rozdělit na dva základní typy - minimálního (armáda) a maximálního (univerzity) oprávnění. Podle toho dělíme systémy na uzavřené, nebo otevřené.

Politiky by také měli určit, jak budou spravována autorizační pravidla. Autorizační pravidla jsou vyjádřením bezpečnostních politik - určují chování systému při běhu.

Důležitým aspektem je správa oprávnění (autorizačních pravidel):

hierarchická decentralizovaná - centrální autorizátor opravňuje dílčí autorizátory.
vlastnictví - vlastník objektu (autor) určuje oprávnění k objektu
"spolupracující autorizace" - s přidělením zvláštních práv na určité zdroje musí souhlasit všichni členové předdefinované skupiny.

Podle kritéria, na jehož základě se řídí přístup k objektům systému můžeme definovat několik typů řízení přístupu:

discretionary - podle identity (názvu entity)
mandatory - podle jiné vlastnosti, než je identita (klasifikace entity)
role based - podle role, v jaké entita v systému vystupuje
task based - úloha po spuštění sama přiděluje a odebírá přístupová práva subjektům tak, aby umožnila své úspěšné dokončení

5.3.2 Bezpečnostní mechanismy

Mechanismy můžeme rozdělit na vnější (vně či uvnitř databázového systému):

administrativní kontroly
fyzické kontroly

a na vnitřní:

autentizace - založená na znalosti (heslo), vlastnictví (karta), fyzické charakteristice (otisk)
kontrola přístupu
mechanismy auditu - ten má dvě fáze - záznam a zpráva (report)

Na následujícím obrázku je celkový přehled DBMS včetně bezpečnostních prvků.

6. Bezpečnostní modely

První dva modely byly vyvinuty a jsou určeny pro relační databázové systémy. Než se k nim dostanu, chtěl bych definovat úrovně bezpečnostních modelů obecně.

6.1 Úrovně modelů

Následující rozdělení do několika úrovní navrhli LaPadula a Williams. Úrovně postupují od nejobecnějších:

trust objectives - obecné cíle, týkající se důvěry informačního systému
požadavky na vnější rozhraní - bezpečnostní požadavky na rozhraní systém-okolí
vnitřní požadavky - požadavky, jež musí být splněny uvnitř komponent systému
operační pravidla - popisují zajištění vnitřních požadavků
funkční návrh - funkcionální popis chování komponent systému

Modely, jež jsou dále popisovány spadají do úrovně 3

6.2 Discretionary kontra mandatory

Předmětem bezpečnostního modelování je vytvořit abstraktní, programově nezávislý, koncepční model, počínaje specifikací požadavků, které popisují požadavky na ochranu systému.

Bezpečnostní model by měl poskytovat bohatou sémantickou reprezentaci, která umožňuje popis funkčních a strukturních vlastností bezpečnostního systému. Taktéž by měl poskytovat definici ochranných požadavků a systémových politik. Měl by také obsahovat důkaz splnění popisovaných bezpečnostních požadavků.

Bezpečnostní modely je možno rozdělit na discretionary a non-discretionary. Dříve jmenované řídí přístup uživatelů k informacím na základě jejich identity a podle pravidel, která definují typy přístupů každého uživatele ke všem informacím, uložených v systému. Nejběžnější forma správy autorizací je na základě vlastnictví objektu, kdy vlastník může přidělovat/odebírat práva k přístupu na daný objekt. To činí tuto politiku velmi pružnou pro různé požadavky ochrany.

Ostatní politiky řídí přístup k informacím na základě klasifikace subjektů (aktivní entity) a objektů (pasivní entity) v systému.

Bezpečnostní modely je možné klasifikovat podle různých aspektů. Např. cílový systém - (OS, DB, ...), typ politiky (discretionary, mandatory, ...), adresované bezpečnostní aspekty (tajemství, integrita) a typ kontroly (přímá kontrola přístupu, kontrola nepřímého přístupu, nebo kontrola toku informací).

Někdy použití jednoho modelu není dostatečné a jsou vytvářeny tzv. ad-hoc modely, které jsou spojením, nebo rozšířením existujících modelů.

6.3 HRU - maticový přístupový model

Tento model je možno použít jak pro OS, tak i pro databáze. Vznikl již v roce 1971 a v roce 1976 byl formalizován.

6.3.1 Autorizační stav

Je odvozován z matice vztahů mezi objekty a subjekty. Tyto vztahy popisují práva subjektů na jednotlivé objekty.

Autorizační stav je definován jako trojice Q=(S, O, A), kde S je množina subjektů (uživatelé, skupiny uživatelů, procesy, domény (prostředí pro běh procesů)), O je množina objektů (dělíme je na pasivní (systémové zdroje) a aktivní (subjekty)) a A je přístupová matice (řádky - S a sloupce - O), A[s, o] = r.

Pro DBMS může být autorizační stav rozšířen o podmínky, jež musí být splněny, aby přístupová práva platila. Tyto podmínky mohou být závislé na datech, času, kontextu a na historii.

Pro správu autorizačního stavu jsou v modelu definováno 6 primitivních operací:

přidej právo r do A[s, o]
odeber právo r od A[s, o]
vytvoř subjekt s
zruš subjekt s
vytvoř objekt o
zruš objekt o

Tyto operace slouží k vytváření příkazů pro modifikaci autorizačního stavu. Harrison předpokládá, že tyto příkazy se skládají ze dvou částí - podmínková část a výkonná část. Jestiže je první část splněna, tak je ta druhá provedena.

6.3.2 Přístupová práva

Množina možných přístupových práv závisí na objektu. Obecně jsou to read, write, append, (execute,) own. Posledně jmenovaný mod určuje vlastníka, který spravuje autorizace nad objektem.

6.3.3 Administrace autorizací

Vlastník objektu ( má právo own) může přidělovat/odebírat jakékoliv právo (kromě own) na vlastněný objekt ostatním subjektům. A to dokonce i taková práva, která sám momentálně nevlastní. Což porušuje tzv. princip zeslabování práv (attenuation of priviledges).

V některých systémech existují práva, jež i jiným subjektům kromě vlastníka umožňují předávat přístupová práva dále. Jde o explicitní příznak grant pro daný přístupové právo.

Tento příznak grant má dvě verze:

copy flag - značený * - m* v A[s₁, o] umožňuje předat právo m na objekt o dalším subjektům, práva subjektu s₁ se nezmění a subjekt s₂ má právo m na objekt o

transfer flag - značený + - subjekt s₁ předá právo m na objekt o subjektu s₂, subjekt s₁ tímto o právo m přijde, subjekt s₁ má nyní právo m⁺ (může toto právo dál předávat)

6.3.4 Implementace

Model je přímo předurčen k implementaci pomocí tabulek:

tabulka všech relevantních trojic Q_i
tabulka subjektů, z nichž každý má ukazatel na tabulku objektů, na které má právo (nebo obráceně - zaměnit subjekt/objekt).

6.3.5 Rozšíření modelu

Tento model je velmi pružný na vyjádření a kontrolu přístupových práv k informacím. Hlavním problémem je tzv. otázka bezpečí (existuje k danému počátečnímu stavu dosažitelný stav, ve kterém určitý subjekt získá určité právo na daný objekt) je nerozhodnutelná, tento problém souvisí se zranitelností DAC na trojské koně.

Pro rozhodnutelnost bezpečnostního problému byl model různě rozšiřován

Schematic protection model (Sandhu)
Extended schematic protection model (Ammann a Sandhu)
Typed access matrix (TAM) model (Sandhu) - každý subjekt a objekt má typ, který mu je přiřazen při jeho vytvoření a po dobu života se nemění

6.4 Bell-LaPadula

Jde o rozšíření předchozího modelu, jenž je orientováno na definici bezpečnostních požadavků v komplexních systémech, kde mohou být systémové prvky klasifikovány (bezpečnostní úrovně). Model vznikl v roce 1973 a původně byl určen pro OS.

Tento model se stal referenčním pro ochranu dat v politikách nepovinného řízení přístupu (mandatory policies).

Model je založen na klasifikaci systémových prvků, jež je vyjádřena bezpečnostními úrovněmi. Každá bezpečnostní úroveň má dvě části: klasifikaci + množinu kategorií.

Klasifikace je úplně uspořádaná množina čtyř prvků - top secret, secret, confidential, unclassified (TS>S>C>U). Množina kategorií, což je podmnožina nehierarchické množiny prvků (odpovídá aplikační oblasti a prostředí).

Vzniklé bezpečnostní úrovně vytváří svaz. L₁=(C₁, S₁) >= L₂=(C₂, S₂) <=> C₁ >= C₂ a zároveň S₂ je podmožinou S₁ (podobně pro > a < a <> ).

Subjekt-objekt paradigma - subjekty jsou aktivní, objekty jsou pasivní.

Každý uživatel má oprávnění (clearance) a může se do systému přihlásit na jakékoliv úrovni, která je menší (nebo rovna) příslušnému oprávnění.

Každý objekt má přiřazenu bezpečnostní úroveň podle citlivosti obsahu.

Přístupová práva

read-only
append - přidání informace do objektu bez viditelnosti obsahu
execute - provedení (programu)
read-write - do objektu je možno psát a přitom vidět obsah

Decentralizovaná administrace privilegií dle vlastnictví

6.4.1 Stav systému

Stav systému je popsán čtveřicí (b, M, f, H), kde:

b - aktuální přístupová množina - množina trojic <subjekt, objekt, přístupový mod>
M - přístupová matice, která popisuje práva přístupu subjektů k jednotlivým objektům (viz. předchozí modely)
f - úrovňová funkce spojuje s každým objektem a subjektem v systému jeho bezpečnostní úroveň f: (O sjednoceno s S) -> L

H - aktuální hierarchie objektů - orientovaný kořenový strom, jehož uzly reprezentují objekty v systému; nepřístupné objekty v této hierarchii nejsou (vlastnost kompatibility - syn má vyšší bez. úroveň než jeho otec

6.4.2 Operace

Stav systému se mění prováděním operací:

získat přístup - zahajuje přístup v požadovaném modu, mění aktuální přístupovou množinu b přidáním odpovídající trojice
uvolnit přístup - ukončuje přístup (opak získat), odnímá z b odpovídající trojici
dát přístup - dává subjektu přístupový mod k objektu, umožňuje přenos práv mezi subjekty, mění přístupovou matici vložením nové položky odpovídajícímu subjektu a objektu, musí odpovídat mandatory politice
zrušit přístup - opak dát, subjekt musí mít právo write na otce daného objektu v H; mění M odebráním odpovídající položky a také mění množinu b
vytvořit objekt - přidá neaktivní objekt do hierarchie, objekt může být buď neaktivní (některé přístupy nejsou povoleny), nebo aktivní; operace mění hierarchii objektů H
zničit objekt - deaktivuje aktivní objekt, odebere uzel z hierarchie H a také upraví množinu b
změnit bezpečnostní úroveň subjektu - mění funkci f asociovanou se subjektem na novou úroveň, která musí být nižší, než je clearance subjektu
změnit bezpečnostní úroveň objektu - mění bezpečnostní úroveň objektu, objekt musí být neaktivní, mění funkci f a to jedině směrem k vyšší úrovni a navíc musí být nová úroveň nižší, než je clearance subjektu, který operaci provádí f_s >= f_o

Pozn: přístup = jakékoli z definovaných přístupových práv

6.4.3 Axiomy

Systém je bezpečný právě když jsou dodrženy definované vlastnosti. Jejich platnost kontroluje referenční monitor. Model používá pojem důvěryhodný subjekt (trusted subject), což je takový subjekt, o němž se domníváme, že nepoškodí bezpečnost. (naproti tomu nedůvěryhodný subjekt)

Simple security (ss) property

Subjekt může číst, nebo zapisovat objekt právě když jeho oprávnění dominuje bezpečnostní úrovni objektu.
Stav systému v=(b, M, f, H) splňuje ss-vlastnost, jestliže pro každý prvek M[s, o] vlastnící právo read, nebo write platí nerovnost f_s(s) >= f_o(o).

Star (*) property

Nedůvěryhodný subjekt smí vlastnit právo append na objekt, jestliže bezpečnostní úroveň objektu dominuje úrovni subjektu. Tento subjekt smí mít právo write, jestliže úroveň objektu je právě rovna aktuální úrovni subjektu a tento subjekt smí mít právo read na objekt, jestliže úroveň objektu je menší než aktuální úroveň subjektu.
Systém splňuje *-vlastnost, právě když s Î S, SÍ S je množina nedůvěryhodných subjektů a append je prvkem M[s, o] => f_c(s) <= f_o(o)
write je prvkem M[s, o] => f_c(s) = f_o(o)
read je prvkem M[s, o] => f_c(s) >= f_o(o) Tyto dvě vlastnosti byly shrnuty v následujících dvou principech. No read-up - mohu číst pouze objekty, které mají nižší bezpečnostní úroveň, než je mé oprávnění.
No write-down - mohou zapisovat do objektů, které mají vyšší bezpečnostní úroveň, než je mé oprávnění.

Princip klidu

Žádný subjekt nemůže měnit klasifikaci aktivního objektu. Tento princip byl později zrušen.

Discretionary security property (ds-property)

Každý aktuální přístup musí být v přístupové matici, také jinak, subjekt může provádět pouze ty přístupy, ke kterým je oprávněn. Stav systému zaručuje ds-vlastnost právě když pro všechny subjekty, objekty a přístupová práva platí:
<s, o, m> je prvkem b => m je prvkem M[s, o]

rozšíření Feiertag (1977) přidává

Nepřístupnost neaktivních objektů

Subjekt nemůže číst obsah neaktivního objektu. Objekty, které nejsou v H, nejsou přístupné pro čtení a zápis.

6.5 Autorizační model ORION

Tento model popsal Rabitti v roce 1991. Vynucuje discretionary controls a bere v úvahu charakteristiky OO systémů - dědičnost, složené objekty a objekty s verzemi.

6.5.1 Subjekty

Subjekty jsou skupiny uživatelů (rolí), do nichž jsou uživatelé zařazováni dle činnosti v organizaci. Uživatel může mít současně více rolí.

Role tvoří svaz - role je v implikaci s jinou rolí, právě když autorizace druhé jsou podmnožinou autorizací první role (např. zaměstnanec - úředník).

Role tvoří svazovou strukturu, jejímž vrcholem je superuživatel a spodní uzel tvoří zaměstnanec.

6.5.2 Objekty

Objektem může být databáze, třídy v databázích, instance tříd a jejich komponenty (atributy, hodnoty a metody), a také množiny instancí dané třídy, nebo množiny hodnot atributů.
Objekty jsou opět uspořádány implikací. Nejvýš je systém, pod ním databáze, třídy, .... Tak dostaneme authorization object schema (AOS), jehož instancemi jsou authorization object lattice (AOL).

6.5.3 Přístupová práva

Jako přístupová práva se předpokládají: a)write - zapisovat do objektu
b)write_any - analogický k write, dovoluje objektu, aby do něj bylo zapisováno

read - čtení objektu, aplikováno na metodu znamená, že metoda může být provedena

generate - vytvořit instance objektu

read_definition - čtení definice objektu

Navíc existuje access authorization matrix AAM, která definuje, které operace jsou možné na kterém typu objektů.

Přístupové práva jsou opět uspořádána ve svazu - authorization type lattice ATL, z něhož jsou odvozovány implicitní přístupové mody.

Oprávnění jsou uspořádány do tří skupin podle možností jejich rozšiřování

a) A.up - práva jsou propagována z nízkých objektů na vysoké, A.up={WA, RD}
b) A.down - práva propagované z vysokých objektů na nízké A.down={W, R}
c) A.nil - přístupová práva bez propagace A.nil={G}

6.5.4 Oprávnění

Oprávnění jsou specifikovány uživateli, neexistují administrativní oprávnění, takže určité přístupové právo implikuje administraci tohoto oprávnění.

Z explicitních autorizací odvozuje systém automaticky implicitní autorizace podle vztahu mezi subjekty, objekty a přístupovými právy.

Přístupová práva jsou pozitivní/negativní a silná/slabá. Poslední dvojice tvoří dvě množiny (authorization base X weak authorization base)

Silná autorizační báze (AB)

Silná autorizační báze je definována funkce i: S x O x A -> (True, False, Undecided) poslední výsledek, jestliže stav (s, a, o) není definován.
vlastnost konzistence AB - existuje-li (s, o, a): (s, o, a) -> (s₁, o₁, a₁), pak neexistuje (s₂, o₂, a₂): (s₂, o₂, a₂) -> (s₁, o₁, a₁)
vlastnost neredundance AB - jestliže existuje (s, o, a): (s, o, a) -> (s₁, o₁, a₁), pak (s₁, o₁, a₁) není v AB

Slabá autorizační báze (WAB)

Oprávnění mohou být přepsána silnými pravidly, nebo specifičtějšími slabými oprávněními.

Funkce nad WAB je definována d: S x O x A -> (True, False)

vlastnost kompletnosti WAB - pro každé oprávnění [s, o, a] existuje [s₁, o₁, a₁] z WAB: [s₁, o₁, a₁] -> [s, o, a]

vlastnost konzistence WAB - pro každé oprávnění [s, o, a] existuje-li [s₁, o₁, a₁] z WAB: [s, o, a] -> [s₁, o₁, a₁], pak v WAB není [s₂, o₂, a₂]: [s₂, o₂, a₂] -> [s₁, o₁, -a₁]

vlastnost koexistence AB a WAB: pro libovolnou autorizaci [s, o, a] z WAB nesmí existovat (s₁, o₁, a₁) z AB: [s₁, o₁, a₁] -> [s, o, -a]

6.5.5 Hierarchie dědičnosti

Existují dva přístupy k právům autora třídy na instance podtříd.

autor třídy nemá automaticky přístupová práva na instance podtříd
autor třídy má implicitně oprávnění na všechny instance všech podtříd vytvořené jakýmkoli uživatelem

Pro model je implicitní první přístup.

7. Modely založené na metodách

Modely dosud uvedené nevyužívají vlastnost zapouzdření a nevyužívají možností metod.

7.1 Model Iris

Tento model je založen na oprávněních provádět metody - Ahad (1992). Každý subjekt má specifikovány metody, které může spouštět. Takovým subjektem může být uživatel, nebo skupina uživatelů (jeden uživatel může být ve více skupinách).

Platí princip vlastnictví - vlastník (tvůrce) metody určuje, kdo ji smí používat, případně, zda smí oprávnění předávat dál (opět volání funkce).

Funkce mohou být static (potřebné funkce jsou volány bez kontroly oprávnění) X dynamic (na všechny potřebné metody musí mít uživatel oprávnění).

Jestliže je oprávnění závislé na datech, tak jsou použity derivované metody.

Model uvažuje i polymorfismus a late binding.

Existují tzv. guard functions pro metody, na jejichž výsledku závisí provedení samotné metody.

Dalším z pojmů jsou tzv. proxy functions, kdy při volání metody je podle uživatele vybrána jedna z proxy funkcí, čímž se může měnit výsledek.

7.2 Filtr zpráv

Jajodia a Kogan navrhly obdobu referenčního monitoru z BLP pro OO modely - filtr zpráv. Tento model využívá zapouzdření a zasílání zpráv (jediný způsob výměny informací v systému), jejichž sledováním je prováděna kontrola datového toku v systému.

7.2.1 Entity

Všechno jsou objekty v OO systému, které jak obsahují informace, tak i provádějí akce. Bezpečnostní úroveň získá každý objekt při vytvoření a nemění se, značíme ji L(o) a platí: L(o) >= L(c), kde o je objekt dané třídy c
L(c_i) >= L(c_j), kde c_j je podtřídou c_i Tyto vlastnosti jsou potřebné pro správnou funkci systému.

Uživatel je v systému reprezentován objektem user session, narozdíl od ostatních objektů může spouštět metody z vlastní iniciativy.

7.2.2 Tok informací

Existují dva zdroje toku dat:

Přijetí zprávy neznamená datový tok, dokud nejsou změněny datové položky příjemce.

Typy primitivních zpráv v modelu:

₁

7.2.3 Algoritmus filtrování zpráv

Všechny zprávy mezi objekty jdou přes filtr, jenž každé zprávě přiřadí klasifikaci rlevel (bezpečnostní úroveň nejvyššího objektu), přičemž jsou dodržována následující pravidla:

1. neprimitivní zpráva, o₁ -> o₂

a) L(o₁)=L(o₂), zpráva i odpověď nejsou omezeny
b) L(o₁)<>L(o₂), zpráva zablokována a odpověď je prázdná
c) L(o₁)<L(o₂), zpráva poslána, odpověď je prázdná
d) L(o₁)>L(o₂), zpráva a odpověď jsou nezměněny 2. primitivní zpráva a) READ - bez omezení
b) WRITE - provedeno pouze, jestliže provedení zaslané zprávy není omezeno
c) CREATE - provedeno pouze, jestliže provedení zaslané zprávy není omezeno

7.2.4 Reprezentace klasifikačního požadavku

Všechny objekty musí být jednoúrovňové, takže je nutno víceúrovňové objekty transformovat

Následující dva modely, nebo spíše rodiny modelů jsou obecnější než předcházející. Nevyjadřují sami žádnou politiku, ale vytvářejí rámec, který je schopen vyjádřit nejrůznější bezpečnostní politiky podle našich požadavků.

7.3 Kontrola přístupu založená na rolích (Role-Base Access Control)

Hlavní myšlenkou této rodiny modelů je to, že přístupová práva jsou administrativně přidělována rolím, jejímiž členy se opět administrativní operací stávají určití uživatelé. Tento přístup velmi zjednodušuje administraci přístupových práv. Uživatelé se mohou členy jednotlivých rolí stát podle toho, jaký post zaujímají v dané společnosti a z jedné role do jiné mohou být přemísťováni jednoduchými operacemi. Tímto umožňují vhodnou abstrakci, která je mnohem bližší způsobu, jakým si komerční společnosti provádějí vnitřní politiku. Jedním z důvodů je i to, že v mnoha společnostech není vlastníkem objektů ten, kdo je vytvořil, ale společnost.

Jelikož přístupová práva jsou dána organizací a nezávisí na vůli uživatelů, jsou tyto modely řazeny mezi non-discretionary. RBAC podporují několik politik důležitých pro neklasifikované, ale citlivé informace: určení kompetence pro provádění jednotlivých úloh, vynucují princip nejnižších práv pro administrátory a specifikaci konfliktů zájmů mezi rolemi. Bylo ukázáno, že tato kontrola přístupu je schopna vyjádřit různé variace přístupových modelů založených na svazové hierarchii, která se používá pro klasifikaci entit systému. Dokonce, že LBAC modely jsou podmnožinou mnohem obecnějších RBAC modelů.

Možná si vzpomenete na příklad Nicholasa Leesona (zaměstnance Baring PLC, bankrot, mohl provádět obchody s deriváty cenných papírů a také v kanceláři, kde byly obchody domlouvány) právě tomuto konfliktů zájmů je schopen RBAC zabránit.

Další vlastností modelu je, že umožňuje omezit datový tok na jednosměrný (obdoba simple security property a star property), což je nutný předpoklad pro klasifikaci informací.

Obecně lze říci, že RBAC je neutrální vzhledem k politice. Může vyjadřovat určitou politiku, místo aby ji přímo obsahoval.

7.4 Kontrola přístupu založená na úlohách (Task-Based Authorization Control)

U těchto modelů se místo klasického vztahu subjekt-objekt objevuje nový, orientovaný na úlohy. Přidělení přístupu jsou součástí různých fází provádění úlohy při dodržování určité aplikační logiky. TBAC pokládá základ pro "aktivní" bezpečnostní modely, požadované při distribuovaných výpočtech a workflow managementu.

Za aktivní bezpečnostní modely jsou považovány ty, jež k bezpečnostní správě přistupují z pohledu aktivity úloh a poskytují abstrakce a mechanismy pro správu autorizací za běhu.

Jestliže vezmeme klasické bezpečnostní modely, tak jejich nevýhodou je, že jsou orientovány velmi centralisticky (centrální společné zdroje), přístupová práva jsou definována na velmi primitivní úrovni bez vztahu na okamžitý stav systému a neexistují záznamy o využívání přístupových práv.

Ve skutečném světě je autorizace vyjádřena jako podepsání nějakého formuláře. Tím daná osoba bere odpovědnost za akce, které svým podpisem umožnila. Po vypršení platnosti povolení jsou automaticky všechny relevantní akce zakázány.

No a cílem TBAC modelů je snížit náročnost správy autorizací ve velkých a složitých systémech a přiblížit tuto správu uvedené představě. Proto je zaveden nový pojem - autorizační krok, který je obdobou podepsání formuláře. Jde vlastně o změnu přístupových práv (někomu nějaké dávám) a to na omezenou dobu a na daný, určitý autorizační krok. Klasický autorizační stav můžeme vyjádřit následujícím vztahem:

P je podmnožinou S x O x A U TBAC modelů je tento vztah upraven a jsou přidány další dvě položky P je podmnožinou S x O x A x U x AS Kromě subjektů, objektů a práv se v něm vyskytují také maximální počet použití (U) a autorizační krok (AS).

Každý autorizační krok má svůj autorizační stav. Počáteční hodnota tohoto stavu je množina práv, jež jsou přidělena ve chvíli, kdy se autorizační krok stane platným. V průběhu tohoto kroku se množina práv může pouze zmenšovat.

Jelikož v systému nejsou autorizační kroky samy o sobě, jsou v TBAC modelech definovány závislostní vztahy, které mohou být použity pro vyjádření bezpečnostní politiky.

A₁^state1 Ž A₂^state2 jestliže A₁ přejde do state1, A₂ musí přejít do stavu state2
A₁^state1 < A₂^state2 jestliže A₁ přejde do state1 a A₂ přejde do stavu state2, tak A₁ to musí udělat dřív
A₁^state1 # A₂^state2 jestliže je A₁ ve stavu state1, tak A₂ nesmí být ve stavu state2 a naopak
A₁^state1 ||| A₂^state2 A₁ musí být ve stavu state1, jestliže A₂ je ve stavu state2

8. Poznámky k bezpečnosti v OODBMS

V této kapitole jsou hlavní problémy, které je nutno řešit jak pro discretionary, tak i pro mandatory politiku.

8.1.1 Discretionary policy

Typy oprávnění - v relačních modelech jsou přístupová práva celkem jasná - read, write, execute. Jelikož všechny tyto operace v OO modelu jsou v podstatě spuštěním metody, je třeba vybudovat abstraktnější systém autorizací.

Subjekty oprávnění - zdá se, že i metody by měly být uvažovány při přidělování práv.

Objekty oprávnění - dalším zajímavým aspektem může být s jakým rozlišením se rozhodneme přidělovat práva - třída, objekt, metoda, ...

Kontrola přístupu - určuje, zda požadavek o přístup bude povolen, nebo zamítnut. V OO modelech má uživatel práva na spouštění metod. Otázka stojí. Má mít práva na všechny metody potřebné k provedení požadované metody, nebo ne?

Správa autorizací - někdo vytvoří třídu a další uživatelé vytváří jednotlivé instance. Určitým problémem je jakým způsobem dát do souladu práva těchto subjektů. Jak může vlastník třídy ovlivňovat práva, jež mohou ostatní uživatelé získat na jednotlivé instance?

Propagace práv - v OO systémech je běžná dědičnost tříd. Jaká práva má vlastník třídy na nově vzniklé podtřídy?

Vnitřně příbuzná oprávnění - v případě sémanticky příbuzných objektů je třeba pro provedení dané metody provést nějakou akci na dalších objektech.

Záporná a kladná oprávnění - v modelu by měla existovat možnost zadávat oba typy oprávnění a z toho plyne potřeba existence příslušné politiky pro řešení konfliktů.

Organizační aspekty - role based access models

8.1.2 Mandatory policy

Reprezentace entit reálného svět - víceúrovňové objekty X jednoúrovňové objekty

Vynucení klasifikačních požadavků - agregace, derivace, dat

Podpůrné prostředky- např. pro generování OO schématu, klasifikací entit

Bezpečný update/delete - reference mezi různými bezpečnostními úrovněmi

Polyinstantiation - duplicita dat, cover stories,

Sanitization - vrácení "nízkých" dat při dotazu na "vysoká" - potřeba uvolnění mandatory politiky

Identifikace důvěryhodných prvků - množství důvěryhodného kódu by mělo zůstat nízké

Formální model - opět potřeba vytvoření formálního modelu, jenž je problémem, vzhledem k nejednotnosti OO datového modelu.

9. Literatura

[1] Silvana Castalo, Maria Grazia Fugini, Giancarlo Martella, Pierangela Samarati, 1995. Database security. Addison-Wesley & ACM Press
[2] Thomas R.K., Sandhu R.S. 1997. Task-based Authorization Controls: A Family of Models for Active and Enterprise-oriented Authorization Management. Chapman & Hall
[3] Ferraiolo D.F., Cugini J.A., Kuhn R.D. 1995. Role-Based Access Control: Features and Motivations. Proceedings of the 11th Annual Computer Security Applications Conference (CSAC '95)
[4] Olivier M.S., Von Solms S.H., 1994, A taxonomy for Secure Object-Oriented Databases. ACM Transactions on Database Systems, March 1994, pgs. 3-46