Požadavky na data z pohledu bezpečnosti

Bezpečnost je podstatnou součástí prezentačního systému. Požadavky na bezpečnost celých informačních systémů přicházejí z mnoha stran, a to hlavně od uživatelů těchto systémů a z oblasti legislativy. Jedním z úkolů prezentačního systému je tyto požadavky respektovat. Prezentační systém musí mít prostředky k tomu jak tyto požadavky zohlednit. O tom jaké tyto prostředky při prezentaci dat jsou je tato kapitola.

Bezpečnost dat z pohledu rolí v systému spadá do kompetence tvůrce SQL dotazů. Do kompetence této práce, vývoje samotného prezentačního systému, spadá pouze tvorba prostředků umožňujících předávání informací využívaných dalšími moduly k zabezpečení SQL dotazů.

Můžeme nechat koncového uživatele vytvářet SQL dotaz samostatně? Tato otázka hraje v bezpečnosti prezentačního systému podstatnou roli. Naše odpověď zní „nemůžeme“ , a to z následujících důvodů:

1. uživatelé zpravidla neznají jazyk SQL
2. uživatelé neznají strukturu databáze
3. uživatelé prezentačního systému nesmí být schopni data měnit
4. uživatelé prezentačního systému nesmí mít možnost získat data, ke kterým nejsou oprávněni

První dva důvody jsou důvody, které se vážou na předpokládané schopnosti koncových uživatelů. Jazyk SQL by byl silným komunikačním prostředkem při komunikaci s databází. Byl by zajisté silnější než náhrady, které mu budeme muset poskytnout. Schopnosti většiny koncových uživatelů, a neznalost databázové struktury však prakticky přímé využití SQL jazyka koncovými uživateli vylučují. Podstatnější jsou však třetí a čtvrý důvod, a tím je bezpečnost. Analyzovat sémantiku SQL dotazu není jednoduché. I databázové systémy nezjišťují, co po nich uživatel chce za cenné informace, nýbrž pouze reagují na jeho dotazy. Databázové systémy nejsou vhodným hlídačem korektnosti a záměrů uživatele. Ohlídat SQL dotaz z hlediska bezpečnosti, z hlediska povolení přístupu k určitým informacím je mimo rámec této práce. Problém není totiž jen v požadavcích na získání určitých polí z databáze, ale i v použití nepřímých metod využívajících např. omezení v části WHERE. Když bychom chtěli teoreticky zjistit rodné číslo uživatele XY, tak i kdyby nám někdo zabránil získat tuto informaci přímo, tak bychom se mohli tak dlouho databáze ptát na uživatele XY s rodným číslem Z, dokud by nám databázový systém nevrátil hodnotu pravda. Bezpečnost je tedy předním důvodem pro zamítnutí přímého využití SQL dotazu koncovými uživateli.

Jako důležitý předpoklad bereme, že prezentační systém bezpečnostní požadavky nevytváří, ale respektuje. To znamená, že umožňuje zohlednění vztahu uživatele a dat. Máli být prezentační systém flexibilní, pak nesmí být bezpečnostní požadavky přímo součástí implementace samotného prezentačního systému (implicitní), nýbrž musí být získávány zvnějšku (explicitně).

Zde se tedy dostáváme k tomu, co je to vnější prostředí z pohledu prezentačního systému. Protože prezentační systém je programem, tak tento pracuje jako součást určitého celku (např. jako modul informačního systému), který zase pracuje uvnitř určitého prostředí a tedy i v rámci určitých proměnných tohoto prostředí. Navíc se kolem něj nachází z jeho pohledu externí datové zdroje jako jsou např. soubory, databáze, či různé servery, které mohou nést informace potřebné k zajištění bezpečnosti. Důležité je vybrat takové zdroje údajů, na jejichž základě bude bezpečnost implementována. Tyto musí být pro všechny strany důvěryhodné. Předně je nutné zajistit, aby sám uživatel nemohl manipulovat se svými bezpečnostními oprávněními. Údaje a zdroje ovlivňující bezpečnost se mohou v různých systémech lišit, a z tohoto důvodu nejsou předmětem této práce.

Často jsou údaje podporující bezpečnost uloženy ve stejné databázi jako údaje samotné. Bezpečnost se projevuje předně tak, že požadavek na získání určitého atributu omezuje objekty, u kterých můžeme daný atribut získat. Takto určenou bezpečnost můžeme v rámci jazyka SQL interpretovat v části SELECT, ve které je zapotřebí vrátit návratovou hodnotu podle toho, zda jsou nebo nejsou splněny bezpečnostní požadavky. Ne všechny SQL databáze však takovéto podmiňování v šásti SELECT umožňují. Bezpečnost lze implementovat i přes část WHERE, ve které je možné omezit celou množinu objektů, od nichž budou informace získány. Takovýto přístup ale trpí nevýhodou, že jednotlivé atributy nemusí mít stejné zabezpečení, a že tato množina objektů pak může být příliš omezená.

Uložení bezpečnostních informací do databází, však není jedinou často se vyskytující formou řízení přístupu. Mnohdy se vyskytují omezení na celá pole, a tabulky, a to ve formě „přístup povolen/zamítnut“ . Takováto omezení nezpůsobují omezení na kvantitu získaných údajů, ve smyslu dodatku do části SELECT nebo WHERE v dotazu, ale jsou prakticky shodná s bezpečnostní politikou databázových systémů.

Závěry této kapitoly shrneme v následujících bodech:

1. Z bezpečnostních důvodů zamítáme přímé použití SQL dotazů koncovými uživateli.
2. Úkolem bezpečnosti prezentačního systému je zajistit pro každého uživatele při dotazu na určitý atribut třídy objektů, aby daný atribut získal jen od objektů, u kterých je oprávněn jej získat.
3. Bezpečnost se projevuje podmiňováním návratové hodnoty v části SELECT nebo omezujícími podmínkami v části WHERE SQL dotazu. Tyto omezující podmínky jsou většinou založeny na identifikaci uživatele vznášejícího požadavek na data.
4. Bezpečnost se může projevovat obecným zamezením přístupu k celým datovým objektům.