Uchrání Java drahocenná firemní data?

Dávno pryč je doba, kdy jsme si kladli otázky, zda je třeba v rámci firemní architektury IT brát v úvahu moderní komu...


Dávno pryč je doba, kdy jsme si kladli otázky, zda je třeba v rámci firemní
architektury IT brát v úvahu moderní komunikační technologie typu intranet nebo
internet. Dnes už zní otázka jinak: Jak to udělat efektivně? Pro integraci
podnikových aplikací jsou např. velmi vhodné aplikační servery založené na
Javě. Jak je to ale s jejich bezpečností?
Javové aplikační servery dnes v oblasti infrastruktury poskytují rozsáhlé
služby, které usnadňují realizaci náročných aplikací pro e-business. Zvláštním
rysem technologie Java je také vysoký stupeň standardizace. To se týká
například schopnosti pracovat ve vícekanálovém režimu, neboť k podpoře různých
distribučních cest lze použít různé typy klientů. Zatímco komunikace s klienty
na internetu se typicky provádí přes Java Server Pages (JSP) nebo web services,
klienti v intranetu mohou být realizováni například jako applety nebo aplikace
v Javě. Komponenty Enterprise JavaBeans (EJB) slouží k implementaci obchodního
modelu (business object model) a obchodních procesů (business process).
Napojení dalších systémů, například aplikací provozovaných na mainframech nebo
ERP řešení, lze realizovat pomocí již standardizované architektury Java
Connector Architecture (JCA).
U distribuovaných systémů zejména u aplikací e-businessu hrají významnou roli
také bezpečnostní aspekty. Jejich důležitost je zřejmá již na základě
skutečnosti, že nedostatečná důvěra v bezpečnost internetových aplikací dosud
bránila jejich širšímu využití. Dojde-li k chybě v aplikaci během provozu
(nedovolený přístup k chráněným datům s případným porušením právních ustanovení
na ochranu dat, výpadek systému způsobený DoS (Denial-of-Service) útoky atd.),
může to firmě způsobit vysoké finanční škody. Při tvorbě aplikací si tedy
musíme nutně položit otázku, jak zajistit bezpečný provoz obchodních procesů v
nejistém a otevřeném prostředí internetu. Je třeba také zvážit, jak lze
realizovat permanentní shodu mezi aplikačním modelem a požadovaným
bezpečnostním modelem. Nejdůležitější bezpečnostní architektury v kontextu Javy
dnes určují specifikace Java 2 Standard Edition (J2SE) a Enterprise Edition
(J2EE). J2SE verze 1.4 poskytuje rozsáhlé funkce pro autentizaci, autorizaci a
šifrování, zatímco J2EE významně rozšiřuje tyto aspekty s ohledem na vícevrstvé
aplikace.

Bezpečnostní model
Počínaje J2SE verze 1.2 (JDK 1.2) je podporován podrobně členěný bezpečnostní
model. To znamená, že každý kód v Javě, který se má provést, může být sdružen s
určitou bezpečnostní politikou (Security Policy). Ta definuje množství práv,
která mají být kódu poskytnuta, například přístup k určitému zdroji. Kontrola
se provádí v rámci provozu JVM (Java Virtual Machine). J2SE verze 1.4 (JDK 1.4)
přináší z hlediska úplnosti bezpečnostní architektury novou kvalitu. Vybrané
bezpečnostní koncepty lze realizovat již výhradně standardními prostředky JDK
1.4:
Java Authentication and Authorization Service (JAAS) zdokonaluje bezpečnostní
model založený na stanovené strategii bezpečnosti dat do té míry, že v úrovni
autentizace uživatelů je možné udělovat přístupová práva. Dále se zavádí
koncept tzv. login modulů, kterými se standardizují rozhraní pro přihlášení.
Java Cryptography Extension (JCE) rozšiřuje pomocí JDK 1.2 zavedenou
architekturu Java Cryptography Architecture (JCA). JCA společně s JCE definují
rozsáhlé frameworky pro oblasti šifrování, tvorbu a správu šifer, certifikáty a
digitální podpisy.
Java Secure Socket Extension (JSSE) poskytuje funkce, jimiž lze realizovat
bezpečnou komunikaci v prostředí internetu. K tomu obsahuje především
implementaci protokolů SSL (Secure Sockets Layer) a TLS (Transport Layer
Security).
Celkově se tedy dá říci, že v JDK 1.4 jsou k dispozici rozsáhlé bezpečnostní
funkce. Tak je například možné se základními prostředky JDK 1.4 vytvářet PKI
(Public Key Infrastructure) způsobem, který nezávisí na platformě. Dalším
plusem je jednoduchá rozšiřitelnost. I když JDK 1.4 již dnes nabízí řadu
základních algoritmů, lze navíc do bezpečnostní architektury bez problémů
zaintegrovat alternativní implementace jiných produktů.
Nakonec je třeba ještě vyzdvihnout možnost konfigurace oprávnění. Určitá
rozhodnutí relevantní k bezpečnosti (například: "Smí uživatel Novák vstoupit do
souboru secret.txt?") se nemusejí psát do kódu uživatelského programu dodržení
bezpečnostní politiky zajistí samo prostředí Java. V bezpečnostní architektuře
J2EE je podstatným cílem využít jednoduchým způsobem základní služby IT. Mají
být takové, aby se daly nakonfigurovat a jejich konkrétní implementace by měla
být snadno nastavitelná. To platí zejména pro bezpečnostní funkce, jimiž mají
být webové a EJB komponenty chráněny před nedovoleným přístupem, a kde má být
komunikace mezi komponentami spolehlivá.

Autentizace
Autentizace webových klientů se provádí buď na základě jména a hesla uživatele,
nebo pomocí certifikátu. V prvním případě lze zvolit, zda se má ke sběru dat
použít standardní dialogové okno pro přihlášení, které browser nabídne, nebo
zda se má použít formulář zadaný aplikací ve formě JSP. Protože se jméno
uživatele a heslo ve fázi přihlášení zadávají nekódovaně, měl by být tento
způsob bezpodmínečně kombinován s bezpečnostími funkcemi pro přenos.
Autentizace s certifikáty tento problém nemá, avšak vyžaduje vyšší náklady na
správu a konfiguraci. Specifikace se provádí nejprve při instalaci. Správa
přihlašovací relace, která zaručuje, že se každý uživatel musí na server
přihlásit jen jednou (single-sign-on), je úkolem serveru. Zpravidla k tomu
používá cookies. K autentizaci klientů požadujících využití některých aplikací
používají aplikační servery ve stále větší míře přihlašovací moduly JAAS. Ty
jsou pro běžné adresáře uživatelů obsaženy buď v rámci instalace, nebo se
musejí implementovat samostatně. Ve firmách bývají k dispozici rozsáhlé
adresáře uživatelů ve formě adresářů LDAP, databázových tabulek nebo přímo v
úrovni operačního systému (NT-domény, Unix NIS). Ty lze v běžných aplikačních
serverech použít pro autentizaci. Připojení však dosud nebylo standardizováno.

Oprávnění
Povolení přístupu uživatele k určitým zdrojům závisí na konceptu požadované
úlohy. K tomu, aby uživatel mohl aktivovat určitý zdroj, například stránku HTML
nebo kód v Javě, musí mít přidělenou určitou roli. Pokud tomu tak není, systém
odmítne přístup ke zpracování programů. Úlohy, které uživatele opravňují k
přístupu, je třeba specifikovat ve standardizovaném konfiguračním souboru v
průběhu instalace. Přiřazení uživatelů k úlohám se provádí vybraným způsobem.
Zdroje, které lze chránit ve webovém containeru, jsou stránky HTML, servlety a
JSP, zdroji EJB jsou metody Enterprise Beans. Tento způsob konfigurace
oprávnění je jednoduchý a v mnoha případech postačí. Pokud ale chceme při
rozhodování o přístupu do určité skupiny povolených úloh zahrnout konkrétní
parametry ("pokladník smí převést maximálně 10 000 eur"), nebo stav nějaké
entity v kódu ("zákazník smí vidět pouze stav svého vlastního účtu"), je třeba
začlenit požadované přístupové testy do programového kódu. Pro tento účel J2EE
standardizuje rozhraní, které nabízí přístup k zadání identity uživatele ve
fázi přihlášení a jeho příslušnost k úlohám. Testy oprávnění přístupu zadané v
programovém kódu pak nelze konfigurovat v průběhu vlastní instalace.

Integrita dat
Kromě autentizace a autorizace přístupu má podstatný význam také zabezpečení
dat při přenosu. J2EE zde používá standard SSL, který slouží k šifrování
komunikace mezi klientem a serverem. Konfigurací systému se dá navolit, zda se
má zabezpečit pouze utajení dat nebo i jejich integrita. Pro budoucí podobu
standardu J2EE se plánuje zlepšení v oblastech kontroly přístupu založené na
entitě, auditing, managementu a dynamické registraci uživatelů. Oprávnění k
přístupu, autorizaci a bezpečnost přenosu lze nakonfigurovat do určitého
rozsahu. Webové, resp. EJB containery se při provozu starají o to, aby se
nakonfigurované restrikce skutečně dodržely. To vede k velmi jednoduchému
programovacímu modelu a k velké flexibilitě. V praxi však bude třeba často
programovat dodatečné podmínky ručně. Standard J2EE k tomu definuje potřebná
rozhraní. Aplikační servery J2EE tyto standardní činnosti nabízejí, ale je
třeba brát ohled na to, že jen málokteré produkty splňují podmínky aktuální
verze 1.3. Potřebujeme-li použít specializované funkce, musíme přejít na
speciální bezpečnostní nástroje dodávané prodejci, kteří spolupracují s výrobci
aplikačních serverů. Některé funkce zatím ještě zůstávají v oblasti nesplněných
přání. Např. MDB (Message Driven Beans), které jsou nově obsaženy ve
specifikaci EJB 2.0, ještě nejsou vůbec zaintegrovány do bezpečnostní
architektury. Kromě toho chybí například i větší množství tipů a příkladů,
které by ukázaly správné použití bezpečnostního modelu v tomto kontextu.
Referenční příklad J2EE Petstore firmy Sun používá kontrolu přístupu na webové
úrovni jen v malé míře a na úrovni EJB vůbec ne. To odkrývá dvě podstatné
slabiny bezpečnostního modelu J2EE. Za prvé je velmi obtížné koordinovat
kontroly přístupu mezi webovou úrovní a úrovní EJB. Omezíme-li se na webovou
úroveň, jsou komponenty EJB otevřeny přístupům aplikačních klientů nebo klientů
webových služeb. Soustředíme-li se na úroveň EJB, bude obtížné vytvořit vhodná
uživatelská rozhraní. Použijeme-li obě úrovně, bude problematické dosáhnout
odpovídající souhry.

Slabý web
Ještě větší slabinou je to, že se současný webový bezpečnostní model ukazuje
pro velkou skupinu webových aplikací nedostatečný. Většina webových aplikací,
kromě jiného zmíněný Petstore, používá architekturu s front-controllerem ve
formě servletů, které přijímají došlé výzvy a přesměrují je na příslušný JSP.
Nynějším bezpečnostním modelem J2EE lze však chránit konfigurací pouze
front-controller, nikoliv komponenty umístěné za ním, což znemožňuje jemně
členěnou kontrolu přístupu. Pokud se této vlastnosti nechceme vzdát, musí se do
komponent naprogramovat příslušné testy.

Objekty chránící bezpečnostV rámci tzv. MDA (Model-Driven Architecture)
zpracovává v současné době skupina OMG (Object Management Group) standard,
kterým mohou být popsány architektura a vlastnosti aplikačního systému
nezávisle na konkrétní platformě a prostředí. Základní myšlenka jejich přístupu
spočívá v tom, aby se pomocí vhodného modelového jazyka, jakým je například
UML, dal vytvořit model plánovaného, na platformě nezávislého aplikačního
systému. Takový model je pak automaticky převeden do softwarového systému,
specifického pro platformu, který může být realizován v technickém prostředí,
například v aplikačním serveru J2EE/EJB. Použití přístupu MDA pro bezpečnostní
oblast pro MDS (Model-Driven Security) spočívá v tom, že jsou bezpečnostní
požadavky explicitně popsány na modelové úrovni a pomocí generování kódů
realizovány na cílové platformě. V čem spočívá užitečnost Model-Driven
Security? Vedle výhod modularity (například větší nezávislost na platformě,
opakované použití v úrovni modelu a růst produktivity) lze ve prospěch tohoto
přístupu uvést především tyto argumenty:
Kontrolu konzistence lze realizovat již v úrovni modelu, která umožňuje
okamžitou identifikaci bezpečnostních mezer.
Je tu lepší souhra mezi uživatelským modelem a požadovaným bezpečnostním
modelem.
Bezpečnostní informace lze vyjádřit způsobem, který je pro běžného uživatele
příjemný a srozumitelný.
Je možné snadné generování kódů pro různé bezpečnostní infrastruktury. Na
praktickém využití přístupu MDS pracuje např. v sousedním Německu Spolkové
ministerstvo hospodářství a techniky.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.