Cesta: Info / Tiskové centrum / Články / Přístup externích uživatelů ke GIS (ve veřejné správě)

• Manuál ServiceDesk ANECT
• HelpDesk
• ServiceDesk

• Tiskové centrum
• Zaměstnání
• Logo ke stažení

V příspěvku je diskutován obecnější problém web přístupu k aplikacím s třívrstvou architekturou a to pro několik typů uživatelů. Typ uživatele je dán jeho vztahem k poskytovaným aplikacím a datům.

Hlavním diskutovaným okruhem problému je architektura bezpečného připojení identifikovaných typů uživatelů, prostředky pro jejich autentizaci a autorizaci a zajištění bezpečného přístupu k datům.

Prezentované řešení je pak ilustrováno na konkrétním případu přístupu uživatelů ke GIS na krajských úřadech.

1. Motivace a potřeby

1.1. Motivace

GIS ve veřejné správě obsahují zpravidla data velmi důležitá nejen pro výkon státní správy (a to nejen při řešení havarijních situací), ale i pro rozhodování samosprávných orgánů. Užitečná jsou přitom jen taková data GIS, která jsou úplná, aktuální, dostupná a pokrývají příslušné území a potřebné vrstvy grafického modelu skutečnosti (např. komunikace, kanalizaci, elektrická vedení apod.). Tento požadavek přirozeně vede k situacím, kdy jsou data GIS shromažďována péčí územních orgánů veřejné správy (data přitom mohou vznikat a vznikají na různých místech, jsou však centralizována u správce příslušného GIS a dále jsou zpřístupňována všem oprávněným uživatelům).

Vzhledem k ceně a citlivosti dat GIS je nutno zajistit jejich bezpečnost, jak před neoprávněným nahlížením do GIS, tak i před možnou modifikací uložených dat. K datům GIS však potřebují přistupovat nejen pověření pracovníci daného KÚ, ale i další externí subjekty.

1.2. Zobecnění

V dalším textu zobecníme GIS na libovolnou aplikaci, která se vyznačuje tím, že za ni a její data odpovídá správce a musí tedy autorizovat všechny její uživatele. Dále budeme předpokládat, že dotčená aplikace má vícevrstvou architekturu, jak je uvedeno schématem na následujícím obrázku.

Uživatelé k přístupu k datové aplikaci využívají web prohlížeč, ten s web serverem (prezentační vrstvou aplikace) komunikuje protokolem HTTP resp. HTTPS.

Web server interně komunikuje s dalšími vrstvami aplikace (aplikační server - vrstva aplikační logiky) a databázová vrstva, v níž jsou uložena vlastní data.

Obrázek 1: Vícevrstvá architektura aplikace

Takové uspořádání má výhodu v tom, že na straně klienta stačí standardní web browser a aplikace může být dostupná stejným způsobem i vzdáleným (mobilním) uživatelům.

1.3. Typy uživatelů a jejich připojení

Připusťme nyní, že externím uživatelem aplikace a dat může být v podstatě kdokoli, komu příslušný správce IS povolí přístup. Může se jím stát občan, člen místních samospráv na příslušném území, zájmová sdružení nebo zaměstnanec jiné instituce veřejné správy (např. pověřený pracovník sousedního územního orgánu veřejné správy).

Různorodost uživatelů napovídá, že je třeba zajistit jejich připojení (a přístup k aplikaci a datům) prostřednictvím:

• veřejné sítě internet,
• neveřejné sítě státní správy GOVBONE.
• Pronajatých okruhů veřejných poskytovatelů a
• dial-up připojení (veřejná telefonní síť, ISDN, GSM...).

1.4. Potřeby uživatelů, cíle řešení

Hlavní potřebou uživatelů je dostupnost grafických dat tehdy, když je potřebují a to nezávisle na tom, jakého připojení budou využívat. Správce aplikace a dat naopak musí zajistit jejich autentizaci (zjištění a ověření totožnosti) a následnou autorizaci (ověření, zda takto identifikovaný uživatel je oprávněn a v jaké míře, aplikaci a data užívat).

Cílem diskutovaného řešení je tedy zajistit subsystém bezpečného web přístupu interních i externích uživatelů k aplikacím a datům s vícevrstvou architekturou. Řešení musí být flexibilní a škálovatelné i pro velký počet uživatelů.

2. Připojení externích uživatelů

2.1. Dial-up, GOVBONE a internet

Existuje několik způsobů, jak externí uživatele připojit. Přehledné schéma na následujícím obrázku znázorňuje celkem tři situace - externí uživatel připojený přes dial-up (typicky pracovník veřejné správy z míst, kde je dostupný pouze tento typ konektivity), externí uživatel pracující ve své vnitřní síti, propojené s vnitřní sítí aplikace a dat prostřednictvím buď pronajatých okruhů, neveřejné propojovací sítě veřejné správy GOVBONE nebo veřejné sítě internet (typicky pracovník jiné organizace veřejné správy) a konečně externí uživatel připojený přes internet (typicky občan).

Obrázek 2: Způsoby připojení externích uživatelů

Komunikace mezi organizacemi veřejné správy je přednostně směrována přes propojovací síť GOVBONE.

Vnitřní sítě jak externích uživatelů, tak správce aplikace a dat jsou z hlediska bezpečnosti považovány za tzv. privátní sítě a jejich připojení k sítím poskytovatelů musí být navrženo tak, aby byla zajištěna jejich bezpečnost. Z tohoto důvodu se osvědčila modulová architektura a jedním ze standardních modulů je i modul připojení na poskytovatele (hraniční modul). Na jediném propojení vnitřní sítě s tímto modulem a jeho prostřednictvím se všemi externími sítěmi pak lze snadno kontrolovat bezpečnost vnitřní sítě.

2.2. Hraniční modul

Hraniční modul musí zajistit několik funkcí. Na prvním místě je to IP konektivita, dále pak řízení přístupu do vnitřní sítě a kontrolu přípustnosti obsahu, který jím prochází. Obvyklou součástí hraničních modulů jsou směrovače, AAA servery pro řízení přístupu, firewally, DMZ, proxy servery, antivirové brány, IDS a další bezpečnostní prvky.

Na následujících obrázcích budeme postupně vytvářet hraniční modul tak, aby splňoval bezpečnostní požadavky pro připojení externích uživatelů jednotlivých typů. Základní topologie diskutovaného řešení hraničního modulu je tvořena soustavou směrovačů, firewallů a sadou DMZ.

Obrázek 3: Hraniční modul pro řízení přístupu

Hraniční modul obsahuje (na obrázku zleva doprava, shora dolů) přístupový směrovač pro dial-up externí uživatele a pro externí uživatele připojené pevným okruhem, dále hraniční směrovače pro GOVBONE a internet. Vnitřní síť je od přístupových směrovačů a od GOVBONE oddělena firewallem FW2 pro GOVBONE. Ten je součástí kaskádové soustavy firewallů (druhým firewallem je firewall FW1 pro internet).

Další součástí hraničního modulu je (zatím jedna) DMZ, v níž je umístěn AAA server, který řídí přístup dial-up externích uživatelů do sítě vůbec. Přístupový směrovač a AAA server spolu komunikují protokolem RADIUS.

Poznámka: Zkratka AAA vyjadřuje tři základní bezpečnostní principy - autentizaci, autorizaci a accounting (provádění záznamů o činnostech).

3. Adresářové služby

Nedílnou součástí diskutovaného řešení jsou i adresářové služby.

AAA server si totiž může udržovat seznam (externích) uživatelů ve svých vnitřních strukturách. Stejný seznam externích uživatelů pro autentizaci a autorizaci však rovněž musí udržovat aplikace sama (např. web server, aplikační server). Proto je vhodné využít adresářových služeb a jejich pomocí zřídit tzv. externí autorizační databázi (EAD), kterou budou používat všechny bezpečnostní prvky řešení.

Využití adresářových služeb rovněž v maximální možné míře zjednoduší správu uživatelských účtů i pro jejich větší počet. Aktuálně dostupné adresářové služby jsou dostatečně robustní, rozšiřitelné a pro práci s adresářovou strukturou využívají standardního protokolu LDAP.

Obsah EAD respektuje normu adresářových služeb X.500. Základní entitou je objekt, který je jednoznačně identifikován svoji polohou ve stromu X.500, která je popsána pomocí X.500 adresy (DN).

Každý objekt má atributy. Každý atribut může být prázdný nebo nabývat jednu či více hodnot. Typ hodnoty je svázán s atributem. V X.500 stromu může být více tříd objektů. Pro autorizaci externích uživatelů aplikace se používá objekt typu ApplUser. Počet potřebných atributů, jejich typ a hodnoty vycházejí z povahy a potřeb vlastní aplikace. Příklad atributů objektu ApplUser je uveden v následující tabulce.

tabulka 1: Atributy objektu ApplUser v EAD

Takto koncipované řešení má několik výhod. K nim patří zejména možnost uložit do stejné adresářové struktury i seznam interních uživatelů aplikace. Dále údržba a správa adresářových služeb, která je nezávislá na aplikaci a adresářové služby tak mohou být použity i pro více aplikací.

Změny v adresářových službách se tak dynamicky projeví ve všech dotčených aplikacích a jsou tedy vyloučeny bezpečnostně nepříjemné situace, kdy v různých "zapomenutých" systémech a aplikacích přetrvávají "platné" uživatelské účty i bývalých zaměstnanců.

4. Autentizace a autorizace

4.1. Požadavky na bezpečnost

Vzhledem k výše uvedené citlivosti a ceně dat je logickým požadavkem, aby jejich bezpečnost byla dostatečně zajištěna.

Standardní řešení těchto požadavků spočívá v umístění serverů s aplikací a skutečnými daty do vnitřní sítě, kde jsou chráněny firewallem (soustavou firewallů).

Do příslušné demilitarizované zóny na firewallu pak stačí umístit pouze tu část systému, která zprostředkovává komunikaci s koncovými uživateli a zajišťuje jejich autentizaci a autorizaci. Úpravou pravidel komunikace na firewallu je pak zajištěna dostupnost dat při zachováni bezpečnosti vnitřní sítě.

4.2. Reverzní proxy

Diskutované řešení vkládá do procesu komunikace http dotaz a odpověd tzv. reverzní proxy, která zprostředkuje ověření uživatele (autentizaci) a v druhém kroku pak v závislosti na přidělených právech (autorizaci) vygeneruje dotaz na web server aplikace. Odpověď aplikace (po zpracování aplikačním serverem a databází) pak vrátí zpět uživateli.

Průběh komunikace je znázorněn pro externího uživatele z organizace A, která s organizací B komunikuje prostřednictvím propojovací sítě GOVBONE.

Obrázek 4: Komunikace s reverzní proxy

Komunikace mezi koncovým uživatelem, reverzní proxy a aplikací probíhá v těchto krocích:

1. Externí uživatel - klient (web prohlížeč) pošle HTTP požadavek na reverzní proxy v DMZ; tento požadavek bude směrován po neveřejné síti GOVBONE, dále reverzní proxy si od uživatele vyžádá HTTP autentizaci a uživatel vrátí svoje username a password.
2. Reverzní proxy provede autentizaci v externí autorizační databázi EAD pomocí protokolu LDAP a dále zjistí oprávnění přístupu (ověří autorizaci) rovněž v EAD.
3. Reverzní proxy po obdržení odpovědi od EAD buď požadavek odmítne (a informuje o tom klienta - na obrázku není znázorněno), nebo předá požadavek i uživatelská data do vnitřní sítě na web server aplikace, kde bude zpracován aplikačním serverem (a dalšími částmi aplikace) a odpověď bude pomocí protokolu HTTP poslána zpět externímu uživateli (na obrázku již není pro zachování přehlednosti uvedeno). Vnitřní web server aplikace bude komunikovat s EAD, ze kterého bude zjišťovat oprávnění uživatele k jednotlivým operacím s daty.

Pro zvýšení bezpečnosti lze veškerou komunikaci probíhající po síti GOVBONE nahradit jejími šifrovanými variantami, tj. místo protokolu HTTP použít HTTPS a místo LDAP LDAPS.

Reverzní proxy odstíní web server aplikace od uživatelů, tj. zajistí jejich prvotní autentizaci a autorizaci, nepropustí dále neoprávněné uživatele a sníží tak zátěž web serveru aplikace.

Další případná autorizace je věcí konkrétní aplikace a je řešena jejími prostředky. Využití standardních prostředků a protokolů, jako jsou adresářové služby a LDAP, je přitom principiálně výhodné. Adresářové služby zajistí jednotné místo pro data potřebná k autentizaci a autorizaci, jsou robustní a rozšiřitelná i pro velký počet uživatelů, umožňují delegovat správu záznamů i na spolupracující organizace, postup autentizace a autorizace lze použít i pro interní uživatele aplikace.

4.3. LDAP proxy

Představme si nyní situaci, kdy externí uživatelé z organizace A využívají aplikace z organizace B, C, D,...(tedy více než jednu aplikaci v několika dalších organizacích). Pak jsou jejich uživatelské účty vedeny v několika adresářových službách (u používaných aplikací), tedy uživatelské účty jsou vedeny aplikačně-centricky. To je pro velký počet aplikací z hlediska externích uživatelů a organizací, které za jejich jednání odpovídají, administrativně náročné.

Nejlepším řešením by bylo soustředit uživatelské účty podle organizací, k nimž uživatelé náleží (např. podle pracovní smlouvy, služebního poměru apod.). To by ale znamenalo, že reverzní proxy, předřazené před aplikace by musela LDAP protokolem hledat autentizační a autorizační údaje pro externí uživatele v několika adresářových službách. To však přináší složitější konstrukci reverzní proxy.

Stejná pravidla by samozřejmě platila i pro vnitřní web server aplikace. Tento požadavek by mohl za určitých podmínek vést až k nutnosti přepracování AAA modulu aplikace.

Optimálním řešením je použití virtuálních adresářových služeb, tzv. LDAP proxy, jak je naznačeno schématem na následujícím obrázku.

Obrázek 5: LDAP proxy a jeho zařazení v hraničním modulu

Komunikace mezi koncovým uživatelem, reverzní proxy, LDAP proxy, EAD a aplikací probíhá v těchto krocích:

1. Externí uživatel - klient (web prohlížeč) pošle HTTP požadavek na reverzní proxy v DMZ; tento požadavek bude směrován po neveřejné síti GOVBONE, dále si reverzní proxy od uživatele vyžádá HTTP autentizaci a uživatel vrátí svoje username a password.
2. Reverzní proxy provede autentizaci a autorizaci v externí autorizační databázi EAD pomocí protokolu LDAP tak, že se obrátí na LDAP proxy.
3. LDAP proxy vyhledá a zprostředkuje příslušné údaje a operace v příslušné EAD organizace externího uživatele (v našem případě OVS A).
4. Reverzní proxy po obdržení odpovědi od EAD buď požadavek odmítne (a informuje o tom klienta - na obrázku není znázorněno) nebo předá požadavek i uživatelská data do vnitřní sítě na web server aplikace, kde bude zpracován aplikačním serverem (a dalšími částmi aplikace) a odpověď bude pomocí protokolu HTTP poslána zpět externímu uživateli (na obrázku již není pro zachování přehlednosti uvedeno).

Pro zvýšení bezpečnosti lze rovněž veškerou komunikaci nahradit jejími šifrovanými variantami, tj. místo protokolu HTTP použít HTTPS a místo LDAP LDAPS.

Toto řešení je otevřené pro všechny (i různorodé) implementace adresářových služeb v jednotlivých organizacích.

Je věcí LDAP proxy, aby přitom zajistila případné konverze. Dostupné LDAP proxy zajišťují konverze z mnoha různých formátů dat adresářových služeb (např. relační DB, jako Oracle, MS SQL, Sybase, DB2, DSMLv2, X.500 adresářové služby jako Novell NDS, SunONE iDirectory Services, MS Active Directory, OpenLDAP...) a to nejen protokolem LDAPv3, ale i SQL (přes JDBC), SOAP (DSML/XSLT/HTML) a UDDI.

5. Bezpečnostní rysy řešení

5.1. Bezpečnostní architektura

Diskutované řešení využívá kaskádové soustavy firewallů a vhodného rozmístění jednotlivých komponent do více DMZ. Přístup do každé z nich je povolen jen potřebným typům komunikací (všechny ostatní jsou zakázány).

Aplikace a data jsou uloženy ve vnitřní síti a jsou od uživatelů odstíněny reverzní proxy, která provádí autentizaci a autorizaci externích uživatelů.

Pro uložení a správu uživatelských účtů se využívají adresářové služby, které umožňují delegaci správy na jednotlivé zúčastněné subjekty.

Komunikaci lze šifrovat s využitím SSL.

5.2. Bezpečnostní politika firewallu

Komunikace mezi externími uživateli a aplikací jsou řízeny firewallovou soustavou. Z hlediska bezpečnostní politiky je ovlivněn jen firewall, v jehož DMZ se nachází reverzní proxy, který zajišťuje autentizaci a (de-facto) autorizaci externích uživatelů aplikace (FW2 pro GOVBONE). Jeho bezpečnostní politika povoluje následující druhy komunikací:

tabulka 2: Pravidla bezpečnostní politiky pro autorizovaný web přístup k aplikaci

Velmi důležitým aspektem, který má vliv na celkovou bezpečnost řešení, kromě nastavení soustavy firewall, je konfigurace a zabezpečení serveru, plnícího funkci reverzní proxy. Jde především o volbu OS, jeho konfiguraci, aplikaci bezpečnostních oprav, správu a dohled, dále o volbu proxy a její konfiguraci.

5.3. IDS

Senzory jsou principiálně dvou typů, síťové (network) a serverové (host).

Součástí IDS systému je dále řídící stanice IDS, která nastavuje pravidla senzorům a dohlíží je. Výše uvedené schéma dodržuje bezpečnostní doporučení (např. Cisco SAFE), které lze interpretovat jako "úplné pokrytí" všech síťových segmentů síťovými IDS senzory a všech serverů serverovými IDS senzory.

5.4. AAA

První dva bezpečnostní principy AAA, tj. autentizace a autorizace již byly pojednány, poslední bezpečnostní princip je zajištěn důsledným ukládáním log záznamů na několika místech.

První takové místo je AAA server pro ověřování totožnosti dial-up externích uživatelů.

Dalšími takovými místy, kde je vhodné vést log záznamy a které souvisejí s aplikací, jsou reverzní proxy, EAD nebo LDAP proxy, web server a aplikační server, případně databáze aplikace.

6. Konkrétní realizace

Diskutované obecné principy byly ve spolupráci s firmou ARCDATA Praha použity v projektu web přístupu ke GIS datům KÚ. Použitá aplikace je systém ArcIMS, vybavený web serverem Application Servlet Connector, která umožňuje zveřejňování grafických dat pomocí protokolu HTTP/HTTPS.

6.1. Architektura aplikace

Použitý GIS má vícevrstvou architekturu. Pro uživatele je představován těmito vrstvami:

• Prezentační vrstva - klientské prohlížeče nebo web prohlížeč.
• Vrstva (business) aplikační logiky, sestávající z několika modulů:
• HTTP server s ArcIMS Application Servlet Connectorem - prezentační vrstva,
• ArcIMS Application Server - zajišťuje komunikaci mezi Spatial Serverem a prezentačními nástroji,
• ArcIMS Spatial Server - obsahuje business logiku celého systému.
• Datová vrstva - databázový server, uložená geografická data.

Obrázek 7: Komponenty ArcMIS

Z hlediska zajištění webového přístupu k datům je nejdůležitější HTTP server, na kterém je umístěn ArcIMS Application Servlet Connector. Tato komponenta provádí autentizaci a autorizaci uživatelů a zpracovává jejich dotazy.

6.2. HTTP autentizace, autorizace a audit

ArcIMS Application Servlet Connector je javový servlet, který zajišťuje AAA služby pro webový přístup. Autentizace a autorizace je řešena vlastním Connectorem, audit přístupu použitým javovým aplikačním serverem.

Veřejný přístup k datům v GIS není žádoucí, proto je použita metoda Basic Authentication podle RFC 2616.

ArcIMS Application Servlet Connector může provádět autorizaci uživatelů buď pomocí statických XML souborů na serveru nebo pomocí rozhraní JDBC (dynamicky).

6.3. Reverzní proxy

Jako reverzní proxy je použit server Apache, který využívá modul auth_ldap pro autentizaci uživatelů vůči LDAP serveru v EAD a modul mod_proxy pro reverzní HTTP proxy.

Vzhledem k tomu, že Apache je portován na většinu platforem, není kladen žádný požadavek na použitý operační systém. Vzhledem k větší stabilitě Apache na platformě Unix je však použita platforma Linux.

6.4. IDS

Jako síťové IDS senzory jsou použity Snort IDS.

6.5. Accounting

Ukládání záznamů o činnosti externích uživatelů se provádí jako log reverzní proxy, dále jako log ArcIMS Servlet Connectoru a konečně jako log ArcIMS Application Serveru.

7. Závěr

Diskutované řešení je pružné, rozšiřitelné, dovoluje i v budoucnu integrovat další požadavky na přístup k aplikacím a datům ve vnitřní chráněné síti organizace.

Zajišťuje požadovaný bezpečný web přístup ke GIS datům. Stejný mechanismus však lze použít i pro jiné aplikace, které se organizace rozhodne zveřejnit (přes internet pro veřejnost, přes GOVBONE pro další organizace veřejné správy).

Princip autentizace a autorizace založený na EAD umožní jednotlivým organizacím mezi sebou sdílet data bez nároků na další investice. Při jednotném návrhu EAD jednotlivých organizací je možné použít i LDAP proxy, případně kořenovou EAD.

Bezpečnost systému je zajištěna vhodnou architekturou návrhu kdy v DMZ jsou umístěny pouze servery zajišťující komunikaci s klienty, samotná data aplikace zůstávají v bezpečí ve vnitřní síti organizace.

Použité otevřené standardy jsou zárukou dalšího vývoje aplikací a garantují nezávislost na firemních proprietárních řešeních.