Autentizovaný přístup a systém práv v IS MU

Autentizovaný přístup a systém práv v IS MU

Abstrakt: Tvorba autentizovaných webových systémů není jednoduchým úkolem a stále ještě vyžaduje značnou orientaci v použitých technologiích, na rozdíl od tradičních veřejných WWW serverů. V systému s desítkami tisíc uživatelů je rutinní zvládnutí jejich zabezpečeného přístupu základem úspěchu a je samozřejmě nutno počítat s tím, že existují uživatelé, kteří z titulu své pozice v organizaci potřebují širší přístup k informacím než běžní uživatelé. V tomto článku se zaměříme na principy použité při nasazování IS Masarykovy univerzity v Brně, především na použitý styl přístupových práv a práci v autentizovaném prostředí.

Vývoj IS MU

Informační systém Masarykovy univerzity, který v budoucnu pokryje informační potřeby univerzity ve studijní a vědeckovýzkumné oblasti i s adekvátními výstupy v manažerské sféře, je budován paralelně jako interní informační systém, který uživatelé používají po autentizaci, i jako veřejný WWW systém, dostupný volně pomocí protokolu HTTP.

Autentizovaná část systému je tím podstatným základem, protože to je cesta, jíž se uživatelé dostávají přímo ke svým údajům, i těm, které není možno zveřejnit, a v mnoha aplikacích mají možnost údaje přímo modifikovat a opravovat. Vytvořit z nashromážděných dat prezentace určené pro neautentizovaný přístup je úkol snadný a po několika letech vývoje WWW technologie dostatečně zvládnutý. Naproti tomu při nasazování "Intranetových" technologií stále ještě neexistují přímočaré rady a návody, které fungují stoprocentně ve všech případech a všech aplikacích.

Vzhledem k tomu, že systém byl od počátku budován tak, aby byl použitelný všemi členy univerzity (studenty, učiteli, vedením, administrativními pracovníky i externisty), byla i pro interní část zvolena technologie webových prohlížečů s tím, že se používá protokol Secure HTTP, který poskytuje šifrované spojení a tím i vyšší míru ochrany jak heslům, jimiž uživatelé systému potvrzují svou identitu, tak vlastním přenášeným datům.

Použité softwarové nástroje

IS MU je postaven nad WWW serverem Apache a relačním databázovým systémem Oracle verze 8, použitý skriptovací jazyk je Perl5. V databázi jsou uloženy jak vlastní data IS MU, tak informace nutné pro provoz autentizovaného WWW serveru, tedy v první řadě přístupová jména a hesla, jimiž se uživatelé k systému přihlašují. Aplikace jsou psány jako skripty v jazyce Perl, s využitím interně vyvinutých perlovských modulů i široké palety existujících specializovaných modulů, veřejně dostupných na CPANu. Skripty jsou v současnosti spouštěny jako běžné CGI skripty, technologie mod_perl je použita pouze k zajištění persistentního databázového spojení pro účely autentizace. Dlouhodobým cílem je ale plný přechod do prostředí mod_perl.

Databázový server firmy Oracle poskytuje všechny výhody transakčního zpracování a také možnost operativně psát části aplikací buď přímo v jazyku PL/SQL, nebo v externí aplikaci. Díky perlovskému modulu Tie::STDERR jsou navíc vývojáři a správci serveru e-mailem okamžitě informováni o všech výjimečných stavech, které při provozu nastávají. V českém prostředí nenahraditelnou možnost vyhledávání v textech s nerozlišováním diakritiky poskytuje oraclová cartridge ConText.

Na klientské straně je možno použít libovolný WWW prohlížeč, který disponuje rozumnou mírou kompatibility s existujícími standardy HTTP a HTML. V praxi nejrozšířenější jsou Netscape Navigator verze 3 a vyšší a MS Internet Explorer verze vyšší než 3. Vzhledem k tomu, že počet potenciálních uživatelů přesahuje 40 tisíc osob, je použití volně dostupných a standardních prohlížečů na klientské straně systému pravděpodobně jedinou možností, jak dosáhnout široké použitelnosti. WWW prohlížeče jsou totiž k dispozici na takřka všech platformách i operačních systémech a navíc jsou dnes již pro mnoho lidí standardním pracovním nástrojem, čímž se do jisté míry snižují problémy s nasazováním nové neznámé technologie. Podstatnou je samozřejmě také nulová marginální cena každého dalšího klienta.

WWW server a přístup do databáze

CGI skripty spouštěné WWW serverem, jsou prováděny pod UID jediného unixového uživatele. V rámci tohoto uživatele se přistupuje do databáze (v našem případě přečtením hesla databázového účtu z chráněného souboru), zde se teprve ověřuje platnost zadaného hesla vzdáleného uživatele a pak se provádí vlastní aplikační skript. Zavedení desetitisíců databázových účtů by nedovolilo dostatečnou variabilitu v přístupových právech, kterou nyní IS MU dosahuje řešením přístupových práv na aplikační úrovni. Omezení přístupu pouze k některým řádkům, s nimiž má uživatel právo manipulovat, by muselo být řešeno pomocí uživatelských pohledů, ovšem možnost přístupu k údajům vychází často z tak komplikovaných vztahů, že postihnout je pouhým přidělením práva SELECT či UPDATE na jisté pohledy není prakticky možné. Aplikace tedy přistupují do databáze pod jedinou uživatelskou identifikací a je na aplikaci, aby ošetření přístupu provedla sama.

Vzhledem k tomu, že na vývoji systému pracují i externí spolupracovníci, využíváme možnosti Apache spouštět CGI skripty pod cizí uživatelskou identitou pomocí SuEXEC, takže vyvíjené aplikace externích programátorů jsou spouštěny pod jejich UID a do databáze přistupují pod svou identitou. Díky tomu je možno snadno definovat přístup k jednotlivým datovým zdrojům prostředky databázového systému (GRANT, REVOKE) a dát tak vývojářům k dispozici pouze ty tabulky, které pro vývoj potřebují. Tak jsou vyvíjené aplikace od plného přístupu striktně odstíněny a teprve při předání projektu či jeho části je kód přečten a zkontrolován interním vývojářem a skript je převeden do přímého režimu, kdy je prováděn s plnými oprávněními. Zde již ovšem externí programátor nemá možnost dělat v kódu změny a případné opravy a rozšíření zasílá interním vývojářům ve formě změnových (diff) souborů.

Systém práv

Z výše uvedených důvodů vyplývá, že bylo potřeba nalézt způsob, jak flexibilně definovat přístupová práva jednotlivých uživatelů. Systém musí dovolit definovat práva dostatečně obecně, například právo měnit heslo všem zaměstnancům dané katedry, a to nikoli staticky výčtem (zaměstnanci v okamžiku přidělení práva), ale obecným popisem, který zahrne i zaměstnanecké poměry vzniklé za několik měsíců. Dále musí umožnit delegování správy práv v organizaci, a v neposlední řadě musí dovolovat automatická práva vyplývající ze vztahů mezi daty --- učitel může editovat sylabus předmětu, který učí, a student vidí svoje hodnocení, bez toho, aniž by jim někdo tato práva musel explicitně přidělovat.

Po pečlivé analýze jsme dospěli k Systému práv IS MU ve verzi 2. Práva z výše uvedeného pohledu dělíme na explicitní, tedy přidělená, a implicitní, existující automaticky díky vztahům mezi daty. Implicitní práva typicky zahrnují právo vlastníka manipulovat se svým záznamem či právo osoby vidět údaje, které o ní systém uchovává, i když samozřejmě aplikace musí ošetřit minimálně rozdíl mezi možností údaje číst a možností je měnit. Je žádoucí, aby student viděl svoje známky, ovšem nechceme, aby byl schopen hodnocení měnit, byť jde o "jeho" známku. Implicitní práva vznikají s každou novou aplikací, která podobný vztah implementuje.

Práva explicitní pak osobám přidělují správci práv a ve skriptech jsou opět aplikačně testována a vyhodnocována. Každé explicitní právo má dvě strany: subjekt, tedy osobu, jíž je právo přiděleno, a objekt určující na co/koho se právo vztahuje. Subjektem může být pouze osoba/uživatel, protože pouze uživatel je schopen činit akce. Objektem může být podle typu práva buď opět osoba, nebo obecně pracoviště univerzity. Je zřejmé, že například právo měnit přístupové heslo do IS MU je právo vztahující se na osoby --- správce, který novým uživatelům a zapomnětlivcům nastavuje heslo, uplatňuje své právo na fyzické osoby. Pro některé aplikace, například Katalog předmětů MU, je nutné mít možnost definovat jako objekt práva celé pracoviště, bez jakéhokoli vztahu k osobám tomuto pracovišti příslušejícím. Předmět v katalogu je záznamem příslušejícím fakultě či katedře, která za něho odpovídá, nikoli osobám na těchto útvarech.

Osoba může být v definici práva zadána buď přímo svou identifikací v systému (tzv. učo, univerzitní číslo osoby), v notaci systému práv IS MU například I/2644, příslušností do výčtové skupiny osob (G/43 znamená skupinu číslo 43), případně obecnějším zařazením osoby do kategorie student či zaměstnanec (S/1433 jsou studenti Fakulty informatiky MU, Z/14 jsou všichni zaměstnanci univerzity). Pro práva, která se vztahují na pracoviště, je opět pracoviště identifikováno číslem z hierarchického číselníku pracovišť MU.

Systém práv je databázově řešen tabulkou k_prava, která uchovává definiční popisy vztahů mezi subjekty a objekty --- záznam obsahuje typy a hodnoty subjektů a objektů a atribut, který určuje, zda je právo přiděleno ke čtení či pro zápis nebo dává možnost právo dále udělovat. V tabulce je ještě několik dalších servisních informací včetně toho, kdo a kdy právo přidělil. Řádky v tabulce k_prava mohou tedy vypadat přibližně následovně (zobrazujeme pouze podstatné údaje):

Nad definiční tabulkou k_prava jsou vytvořeny databázové pohledy, které provádějí "expanzi" těchto pravidel podle aktuálního stavu systému (seznam studentů či přiřazení zaměstnanců na pracovištích) a dovolují klást dotazy na konkrétní instance subjektu a objektu. Typický dotaz, který aplikace potřebuje vyhodnotit, zní: "má uživatel 2644 právo 15 pro čtení na osobu 47362"? Pokud je osoba 47362 studentem fakulty 1433, pak díky prvnímu řádku z výše uvedeného příkladu bude mít osoba 2644 právo s ní právem 15 pro čtení manipulovat. Je ale možné, že osoba 47362 je zaměstnanecem katedry 14311030 a osoba 2644 členem výčtové skupiny 43, a uplatní se čtvrté pravidlo (neboť 14311030 je podpracovištěm 1431).

Systém také dovoluje nalezení seznamu objektů, se kterými může subjekt s daným právem pracovat, kupříkladu "se kterými osobami může osoba s číslem 2116 manipulovat právem 16, a to pro zápis", a také důležitý dotaz "existuje pravidlo, které by dávalo uživateli 2116 právo 15 pro některý objekt pro čtení?" --- ten se používá při rozhodování, zda uživateli zobrazit odkaz na další aplikaci. Uživatel může samozřejmě přistoupit na libovolné URL systému, je ale rozumné ho nemást odkazy, které vedou na aplikace, ve kterých nemá žádná práva a které jsou tak pro něho slepé.

Vyhodnocení uvedených dotazů se provádí vždy znovu proti aktuální databázi a zkušenosti ukazují, že většina pravidel v k_prava je buď rychle zavržena nebo vede na průchod databází pomocí primárních klíčů, a odpověď je tudíž velmi rychlá a použitý přístup je funkční i v on-line transakčním systému.

Přidělování a další správa práv

Kromě aplikačních atributů r a w (právo pro čtení a zápis) existují i atributy s a S, které umožňují osobě právo dále udělovat --- s dává právo udělit pouze atributy r či w, S navíc i možnost přidělit atributy s či S, tedy dále delegovat správcovství. Podstatné přitom je, že při udělování práva je toto možno dále udělit pouze na podmnožinu objektu, na který má osoba právo s atributem s/S. Tedy pokud má správce práv právo s atributem S pro všechny zaměstnance fakulty Z/1433, může toto právo přidělit na objekt Z/143398 či na celou fakultu Z/1433 nebo kupříkladu na osobu I/49283, pokud je tato zaměstnancem fakulty 1433, ale nikoli na objekt S/1456. Tak je zajištěno, že po primárním rozdělení práv po jednotlivých fakultách či jiných organizačních strukturách nejvyšší úrovně již lokální správci nemohou zasahovat a přisvojit sobě či někomu jinému právo na objekty, s nimiž nedisponují.

Levá strana pravidla, subjekt, není při dalším přidělování práva nijak omezena. Osoba s možností přidělovat právo může v principu právo měnit známky studentům dané fakulty přidělit všem lidem z MU. Pokud má správce práv či obecně uživatel právo s danými objekty manipulovat a má možnost toto právo udělovat dále, není možno vyloučit, že právo udělí chybně, ať již záměrně či nedopatřením. Síla, kterou tímto uživatelé v IS MU dostávají do ruky, vyvolává často nejednoznačné reakce --- často se ozývají požadavky, aby systém takovým chybám zabránil. Ovšem systém nemůže bránit něčemu, co v principu je naprosto korektní chování. Osoba s pravomocí může tuto zneužít bez ohledu na to, zda má svěřeny klíče od trezoru, může editovat sylabus předmětu či výši mezd či spravuje přístupová práva. IS MU pouze podporuje postupy, které jsou v neelektronické podobě naprosto běžné.

Atomickým právem, s nímž systém pracuje, je právo k provedení jisté množiny operací. Jedno právo může ovlivňovat chování několika aplikací, naopak jedna aplikace může mít více částí a zpřístupnit je uživateli podle toho, jaká práva má přidělena. Neexistují zde práva přidělená funkcím v organizaci --- například systém nezná nic jako "právo pracovnice studijního oddělení". Práva, která studijní oddělení a jejich zaměstnanci mají, se totiž na jednotlivých fakultách mohou lišit. Navíc personalisticky mohou být studijní referentky vedeny na jiných pracovištích nebo naopak je třeba zpřístupnit část systému osobě, která personalisticky není vůbec podchycena (student na brigádě, který pomáhá se zápisem nově přijatých). Podobně neexistuje třeba "právo vedoucího katedry".

Samozřejmě že jisté skupiny práv jsou typicky přiděleny jistým skupinám osob, ovšem přidělení, které perspektivně dává osobě relativně rozsáhlé možnosti, musí být nutně provedeno odpovědnou osobou (na fakultě děkanem či jím pověřeným správcem práv), nikoli vzejít z ne zcela bezpečného (neboť určeného k jiným účelům) zdroje. Pokud se pak správce práv rozhodne personálním datům věřit, má možnost je využít a explicitně napříkald právo subjektu Z/19331011 přidělit. Takto je zajištěna jednak flexibilita systému, který si jednotlivá pracoviště mohou vyladit přesně podle svých potřeb, jednak zodpovědnost za učiněná rozhodnutí. V systému je právě zaváděn nástroj, kterým bude správce práv na pracovišti moci práva sdružovat do rolí a tak jednak překonat fakt neexistence práva přiděleného funkci, jednak tak v oblasti své působnosti zadefinovat jistou "firemní politiku", neboť bude moci přidělit či odebrat celou roli a převod odpovídajících práv zajistí již systém sám.

Vývojáři se navíc snaží pružně reagovat i na požadavky případných zjemnění systému práv (vytvoření speciálních práv i pro malé aplikace) v okamžiku, kdy se ukáže, že existující systém nedovoluje v konkrétní situaci tak přesné přidělení přístupu, jak by bylo žádoucí. IS MU je systém budovaný modulárně a inkrementálně a vylepšení založená na požadavcích uživatelů jsou kromě základní vize a analýzy úkolu jedním z klíčových hnacích motorů jeho kvality. Velkou pomocí jsou při tom právě správci práv na jednotlivých pracovištích.

Autentizovaný přístup a překážky v implementaci

Zkušenosti ukazují, že plné zpřístupnění všech možností spolu se zveřejněním zodpovědnosti za daný stav (například uvedením, kdo a kdy údaj naposledy změnil) přispívá k efektivnějšímu využití informačních technologií i ke správnějším údajům, neboť je větší šance, že na chybu se přijde dříve, než když jsou uzavřeny v systému a pracovat s nimi může jen omezená skupina lidí. Všechny změny stejně jako jiné aktivity jsou samozřejmě logovány a fyzicky uchovávány na jiném stroji, je tedy možno dohledat odpovědnost dané osoby.

Zde je nutno připomenout, že systém odvozuje identitu vzdáleného uživatele od správného přístupového jména a loginu. Pokud tedy někdo "půjčí" svoje heslo cizí osobě, je u provedených akcí uvedena stále původní osoba. Přístup pod cizím heslem je u elektronických systémů velkým problémem, kterému se vývojáři snaží čelit jednak flexibilitou přístupových práv, aby takové chování nebylo pro rozumnou práci potřebné, jednak osvětou, a také sledováním vzorků přístupů k systému. Poslední dva uvedené přístupy jsou užitečné také při zjištění a boji s faktickými pokusy o průnik do systému. Jedině zodpovědný přístup uživatelů ke svým heslům a vědomí, že jsou za systém do jisté míry zodpovědní, vede dlouhodobě k jeho bezpečnému fungování. Systém vyžaduje, aby nově zadávané heslo nebylo snadno uhodnutelné, ovšem hlídat, aby si uživatel heslo na papírku nenalepil na svůj monitor, je již mimo možnosti správců.

Při vývoji IS MU bylo nutno vyřešit a překonat i jiné problémy. Bylo nutné, aby se uživatelé sžili s některými vlastnostmi, které systém budovaný nad WWW technologií nutně přináší. Uveďme zde proto pro příklad tři často opakované uživatelské představy, které v reálném životě nejsou pravdivé. První se týká "stavovosti" práce. Systém postavený nad protokolem HTTP je z definice bezestavový. Jedna akce se typicky skládá z odeslání požadavku z klientského prohlížeče (zadáním URL či kliknutím na tlačítko ve formuláři, které odešle data na server) a načtením odpovědi od serveru a zobrazením nové HTML stránky, většinou opět formuláře, s aktualizovanými hodnotami. Toto je jediná do jisté míry atomická akce, o které má smysl v HTTP mluvit. Uživatel ale akci chápe v širším měřítku, do jednoho přístupu zahrnuje i čas strávený úpravami formulářů a často za jednu akci považuje mnoho svých přístupů k serveru, při nichž údaje opakovaně odesílá na server a dostává odpověď.

Takto chápané pojetí, známé například z terminálových informačních systémů, kdy akce často začíná přihlášením a trvá přes dlouhou sérii změn na mnoha obrazovkách (na WWW je ekvivalentem přístup klikáním na odkazy či odeslání formuláře) pak vede k nepochopení některých vlastností systému. Může se totiž například stát, že dva uživatelé načtou ze serveru (z databáze) údaje, opraví je každý jinak a odešlou zpět k uložení. Aplikace pak dle závažnosti údajů buď zapíše poslední zadanou verzi, nebo uživatele upozorní, že od jeho posledního přístupu k serveru došlo jiným uživatelem ke změně.

Otázka, kterou pak uživatelé kladou, zní: proč server vůbec dovolí druhému uživateli načíst a editovat údaje, když musí vědět, že je opravuje osoba, která k systému přistoupila před minutou? Odpověď vyplývající z principů použitého protokolu zní: nic jako otevření údajů k úpravám neexistuje. Server nemůže vědět, zda uživatel ve svém prohlížeči data aktivně upravuje a je připraven je v nejbližších sekundách odeslat zpět, nebo již odešel domů. Navíc, zobrazený formulář s opravenými údaji může uživatel odeslat zpět třeba po několika dnech. Atomickou operací je totiž získání dat ze serveru po odeslaném požadavku, a nikoli získání dat a jejich následná editace až do následujícího odeslání. Z toho důvodu nemá smysl uvažovat o uzamčení údajů poté, co je první uživatel ve svém prohlížeči zobrazil, protože vůbec není zajištěno, že od daného prohlížeče kdy přijde nějaká odpověď.

Snahou tvůrců systému je vytvořit rozumné prostředí, které uživatele od vlastností HTTP odstíní. Důraz je tedy kladen na rozumné ošetření kolizních stavů. Vlastní řešení vždy velmi závisí na konkrétní aplikaci, neboť nadbytek informačních a chybových hlášení bude uživatele spíše mást než jim pomáhat v práci.

Další často otevíranou otázkou, obzvláště při snaze propojit systém z externími informačními (byť perspektivně autentizovanými) zdroji je způsob, jakým autentizace v protokolu HTTP probíhá. Uživatel zadává heslo pouze při prvním přístupu, poté, co klient od serveru obdrží odpověď Not Authorized. Přihlašovací jméno (login) a heslo si ale prohlížeč zapamatuje a odesílá při každém dalším přístupu k danému serveru. Tento způsob práce plyne z výše zmíněné bezestavovosti HTTP a je nutné s ním počítat při propojování s jinými interními informačními systémy.

Třetí často zmiňovaná představa říká, že autentizace v zabezpečeném WWW systému má probíhat pomocí tzv. cookies, dodatečné informace, kterou si server a klient mohou vyměňovat. Mnohé systémy, obzvláště veřejné poštovní servery, tento způsob k vytvoření autentizovaného a pseudostavového prostředí používají, jedná se ale o použití možností technologie na zcela jiný účel, než na který byla určena. Jak již vyplývá z názvu, cookies, cukroví, jsou dodatečnou, nadstandardní informací, která byla tvůrci protokolu zamýšlena především pro uživatelské doladění používaného prostředí, například optimální počet barev, s nimiž má server počítat, rozhodnutí, zda chce klient obdržet pouze základní textovou informaci či plně grafickou stránku, atp.

Protokol HTTP již ve své základní definici poskytuje robustní způsob autentizace, tedy typicky oznámení identity uživatele a její prokázání zadáním hesla. Pouze použití autentizačních funkcí HTTP poskytují takovou úroveň zabezpečení, že je možné je použít pro tvorbu seriózního rozsáhlého informačního systému. Prohlížeč není povinnen cookies podporovat a jeho nakládání s nimi odpovídá jejich zamýšlenému účelu (zobrazování, ukládání). Je nutno si uvědomit, že cookie popisující tzv. session, již jednou autentizovaný přístup, přebírá roli loginu a hesla, tedy zásadní informaci, s níž může kdokoli jiný do systému proniknout. Navíc je mnoho uživatelů, kteří cookies mají z bezpečnostních důvodů na klientské straně vypnuty. Z tohoto důvodu i IS MU provádí autentizaci uživatelů standardními prostředky HTTP a cookies jsou rezervovány pro svůj původní účel, tedy customizaci pracovního prostředí.

Závěr

Zkušenosti z přibližně půlročního nasazování IS MU ukazují, že implementace přístupových práv na aplikační úrovni přináší rozumnou míru flexibility při zajištění bezpečnosti dat. Vyhodnocení typických dotazů vede na minimální zátěž diskovými operacemi, neboť v prostředí WWW aplikací se často opakují ty samé dotazy se stejnými hodnotami, které RDBMS díky cachování vyhodnocuje přímo v RAM. Systém dovolil delegovat pravomoc ve správě hesel na lokální správce práv a dovoluje tak vyladění podmínek práce na jednotlivých pracovištích podle aktuálních potřeb.

Systém práv jde ruku v ruce s rutinním zvládnutím problematiky autentizovaného přístupu k systému i obecných problémů, které nasazení systému postaveného na tomto principu a v obdobném rozsahu přináší. Budovaný IS MU je důkazem, že i systém s mnoha uživateli je možno tvořit s využitím otevřených a dostupných technologií a softwarových nástrojů i klientských prostředků (prohlížečů).

Odkazy, literatura

Brandejs, Michal: Úplná elektronizace studijních agend vysoké školy, RUFIS99, tento sborník

Pazdziora, Jan: Informační systémy, výzkum a univerzity, Odborný seminář Nymburk99

Jan Pazdziora, *1974; v roce 1997 absolvoval Fakultu informatiky Masarykovy univerzity v Brně, nyní je postgraduálním studentem na téže fakultě a analytikem na CVT FI.