Jak si usnadnit odhalení uživatelů

Ten den, kdy londýnská firma Egg zahájila svou činnost, očekávali její představitelé přibližně 5 000 telefonickýc...


Ten den, kdy londýnská firma Egg zahájila svou činnost, očekávali její
představitelé přibližně 5 000 telefonických kontaktů s jejich telefonickou
"bankovní přepážkou". Ve skutečnosti však byl zájem přibližně desetinásobný.
Naštěstí bylo v té chvíli již na spadnutí i spuštění systému pro přístup k
účtům z Webu. Potýkal se však ještě s problémy autorizace uživatelů.
Vedení firmy již dva roky před zmíněným dnem "D" najalo konzultanta Laina
Hunneybella, jehož úkolem bylo vyvinout pro banku komplexní strategii vhodnou
pro Internet. Měl také navrhnout konkrétní softwarové a hardwarové řešení.
Hunneybell mj. potřeboval najít nějaký bezpečnostní mechanismus, který by se
sám přizpůsoboval rozsahu a objemu práce v souvislosti s rychlým růstem počtu
zákazníků, který by uměl reagovat na změny účtů a byl schopen absorbovat
možnosti nabízené novými aplikacemi.
Nakonec se rozhodl pro koncept autorizační infrastruktury (authorization
infrastructure), což byl v té době koncept tak nový, že se mu podařilo nakonec
najít pouze jedinou firmu, která byla schopna něco takového dodat.
"Jakmile jsme se ocitli na Webu, bylo jedním z našich prvních problémů zajistit
opravdu jemně rozlišující systém řídící a kontrolující přístupová práva," říká
Hunneybell. "Nebylo to vůbec snadné. Strávili jsme spousty hodin na budování
autorizačního mechanismu, systému ochrany zdrojů a mechanismů kontrolujících
přístup. To vše muselo být integrováno do celkové infrastruktury."
Hunneybell učinil velmi moudré rozhodnutí. Celá autorizační infrastruktura
nejenže zvládá množinu 1,2 milionu uživatelů, ale je schopna také komunikovat s
novými aplikacemi a za chodu realizovat nová přístupová pravidla.
Klíč k bezpečnosti
Autorizační infrastruktura adresáře uchovávající uživatelské atributy a
mechanismy pravidel, které realizují jednotlivé konkrétní politiky se rychle
stává klíčovým bezpečnostním prvkem při zavádění elektronického businessu. To
tvrdí např. analytik John Pescatore, který pracuje pro firmu GartnerGroup ze
Stanfordu.
Systémy pro správu autorizačních procesů jdou při schvalování přístupu
uživatelů k informačnímu bohatství firem v současné době mnohem dále za
tradiční schvalovací mechanismy (hesla, smart cards, veřejné a privátní klíče).
"Jedna věc je, abychom věděli, kdo jste (to souvisí s určením identity osoby),
ale my rovněž musíme vědět, co máte dovoleno dělat (to souvisí s vaší
autorizací, pověřením, schválením pro určité činnosti)," říká Pescatore. "To do
celého procesu zatahuje další věci včetně celé soustavy identifikačních
mechanismů, například při přístupu pomocí bezdrátových zařízení."
Až do roku 1998 byly společnosti, které zaváděly jakýkoli náročnější
autorizační systém, nuceny se o celou věc postarat výhradně samy a spoléhat jen
na své možnosti a schopnosti. Počínaly si přitom většinou tak, že míchaly
dohromady přístupové seznamy v adresářích LDAP (Lightweight Directory Access
Protocol), databázích Oracle nebo na SQL serverech a naprogramovaly každou
jednotlivou aplikaci tak, aby byla schopna s těmito adresáři komunikovat.
Problém ale spočíval v tom, že tyto systémy měly být schopny rozlišovat velmi
jemně odstupňovaná pověření, například zda Honza (nákupní agent) má či nemá
právo schválit nákup v hodnotě převyšující 1 000 dolarů nebo zda Jana (z
účtárny) má přístup k pohledávkám, ale nemá přístup k výplatním účtům. V reakci
na tyto jemné požadavky několik dodavatelů vyvinulo nástroje, které se řadí do
nově vznikající třídy nástrojů pro řízení autorizačních procesů a které dokáží
mnohé z těchto úkonů účelně automatizovat. Různí dodavatelé přitom při řešení
tohoto úkolu používají navzájem odlišných metod a přístupů.
Firma Egg si vybrala za dodavatele společnost Entrust z Virginie a její produkt
getAccess. Integrovala celofiremní přístupová práva do svého webového serveru.
Produkt zašifruje relace mezi firmou Egg a zákazníky do formy velmi bezpečného
tokenu, který pak putuje se zákazníkem od stránky ke stránce a který povoluje
nebo zakazuje přístup podle pravidel obsažených ve firemní databázi zákazníků.
Egg patří k nevelké skupině firem, které si nástroj na řízení a automatizaci
schvalovacího procesu koupily od dodavatele. Většina ostatních tvrdí, že tyto
koupené nástroje vyžadují příliš náročné přeprogramování přístupových pravidel,
spojených s jednotlivými již existujícími aplikacemi používanými v rámci firmy.
Bez takového přeprogramování by si aplikace se zakoupeným nástrojem nerozuměly.
Přes uvedenou okolnost Pescatore tvrdí, že tyto nástroje jsou slibným počinem a
že tak, jak se budou zdokonalovat a jednotlivé firmy budou modifikovat své
aplikace, aby byly schopny pracovat na Webu, jejich užívání se bude rozšiřovat.
Firma Egg je přitom živým příkladem dlouhé cesty, kterou již tyto nástroje
ušly. "V průběhu plánování celého projektu v roce 1998 byl getAccess jediným
skutečně komerčně dostupným produktem na celém trhu," říká Hunneybell.
Když se koncem minulého roku konečně dočkal své praktické implementace,
existoval getAccess již ve verzi 3.6. Ta disponuje zjednodušeným programováním
aplikací a podle Hunneybella poskytla jeho týmu velký prostor pro pružné
přístupy k řešení mnoha věcí, zejména pokud se týče změn přístupových práv za
běhu.
Ochrana zdrojů
Aby mohl celý systém úspěšně pracovat, museli pracovníci firmy Egg definovat
chráněné zdroje na webovém serveru. Jakmile uživatel požádá o přístup k
informacím, getAccess vyloví jeho popis z firemní databáze zákazníků a připojí
jeho práva ve formě přístupových pravidel k této konkrétní zákazníkově relaci.
"Naším celkovým cílem bylo separovat bezpečnost od konkrétní webové aplikace,
neboť se tím zjednodušuje naprogramování aplikace a zároveň se sníží riziko
vzniku náhodných a nechtěných chyb souvisejících s bezpečností jako takovou,"
říká Hunneybell. "Nyní můžeme rušit anebo měnit úrovně zákaznického přístupu a
můžeme přidávat aplikace k zákaznickému portfoliu."
"Ta část aplikace pro autorizační management, která je uložena na webovém
serveru, může být připojena k hlídacímu programu, který kontroluje vše již u
"vstupních dveří" a povoluje průchod pouze určitým žádostem," vysvětluje Eric
Olden, hlavní technolog a spoluzakladatel začínající společnosti Securant
Technologies ze San Franciska. Tato firma nyní rovněž dodává svůj systém pro
automatické řízení autorizačních procedur.
"Vše se točí kolem řízení vztahů mezi uživateli a zdroji," říká Olden. "Můžete
například procházet údaji o uživatelích a definovat jejich role v databázi nebo
můžete probrat zdroje a vybavit je pravidly, které určí, jaké musí být splněny
podmínky, aby tento zdroj byl přístupný."
"Možnost přesně definovat tyto podmínky je nezbytné proto, aby se podařilo
vytvořit reálný systém jemně odstupňovaných přístupových pravidel," pokračuje
Olden. Pravidla, jako např. "povol přístup pouze přednostním zákazníkům s účtem
u nás, přesahujícím hodnotu 10 000 dolarů," náš systém zapojí do činnosti a
prohlásí, že "tato webová stránka je chráněná", přičemž provede kontrolu
uživatelova profilu, aby se zjistilo, zda se jedná o uživatele příslušného
ražení, nebo nikoli. Teprve potom je přístup umožněn, nebo odmítnut," pokračuje
Olden.
Jako mnoho jiných společností typu .com provozuje také firma Egg síť s daty, ke
kterým se přistupuje prostřednictvím prohlížečů. Avšak pro organizace se
smíšeným prostředím a různými staršími systémy zděděnými z minulosti je toto
dědictví z hlediska integrace do jednotného systému úplnou noční můrou. Aby
tyto nástroje bylo možno použít, musejí systémoví integrátoři nejprve
přeprogramovat své aplikace tak, aby byly schopny akceptovat HTML. Potom musejí
přeprogramovat a překódovat specificky vytvořená přístupová pravidla uvnitř
těchto aplikací tak, aby všechny měly standardizovaný formát, odpovídající
formátu automatizovaného autorizačního nástroje. Z toho plyne, že od okamžiku,
kdy padne volba na určitý automatizovaný autorizační nástroj, není již možná
žádná cesta zpátky.
Nejen plusy
Pescatore připouští, že žádný z těchto nástrojů není procházkou růžovým sadem.
Ale zároveň říká, že práce s nimi stojí za námahu. "Jakmile se podnikové
aplikace přizpůsobí práci na síti, tyto nástroje (pro řízení autorizačního
procesu) se stanou celkem jednoduchou záležitostí. Výhodou těchto nových
nástrojů je, že s nimi můžete měnit identifikační mechanismy počínaje hesly a
konče certifikáty nebo chytrými kartami, aniž by bylo nutno cokoli
přeprogramovat. Další výhodou je konzistentnost zákaznického přístupu k většímu
počtu různých aplikací, ale to vyžaduje, abyste vaše aplikace napsali tak, aby
akceptovaly dodavatelova API (Application Programming Interface)."
Koupit nebo udělat?
Jeden z lidí, kteří soudí, že celý ten zmatek související s integrací nových
nástrojů stojí za to prodělat, je John Voss, ředitel celosvětových e-business
operací firmy Philips Semiconductors ze Sunnyvale.
Podobně jako Hunneybell také Voss byl pověřen vybudováním pružné bezpečnostní
infrastruktury, která by měla podporovat extranety a aplikace pro uživatele
přicházejících na webových stránek. Jedna z aplikací, odměňovací program, který
dával úvěr distributorům pro tvorbu konstrukcí se součástmi pocházejícími přímo
od firmy Philips, vyžadovala velmi jemně odstupňovaná pravidla. Cílem bylo
přidělit tyto zdroje použitím jediného připojení, které by bylo schopno
obsloužit a podporovat až 10 000 uživatelů.
Voss se rozhodl použít nástroje SiteMinder od firmy Netegrity. Nejsložitější
částí celého procesu podle Vosse bylo navržení firemních aplikací tak, aby
předávaly informace programu SiteMinder a naopak. Také to znamenalo zahodit
některé nepříliš důležité aplikace Philipsu, jako například Delegated Admin v
Unified User Management Suite od firmy Netscape.
Voss říká, že to byl dlouhý proces a vyžadovalo to spoustu programování v
jazyce Java a mnoho práce v oblasti reengineeringu. "Zbavili jsme se programu
Delegated Admin a napsali jsme si svou vlastní podobnou aplikaci, integrovali
jsme ji se SiteMinderem a začali jsme ji používat k řízení identifikačních
procesů a k řízení přístupových práv."
Voss říká, že se systémem, který byl oživen v dubnu, je spokojen. A to i
přesto, že se o fungování systému vyjadřuje ve smyslu, že se jedná o stále
pokračující práci. Přál by si, aby strávil více času s dodavateli a vyjasnil si
lépe, jak bude fungovat součinnost mezi aplikačními programy a programem
SiteMinder bez lidských zásahů.

Jak to funguje: Tři různé přístupy k řešení problémů řízení autorizačních
procesů

U tohoto systému je uživatel, pokud žádá přístup ke chráněným informacím,
nasměrován na log-in obrazovku přístupového serveru. Tento server předá žádost
o identifikaci serveru s registrem, který vrátí uživatelovo ověření a
profilovou informaci zpět na přístupový server společně s cookie, které
obsahuje seznam schválených zdrojů, uživatelovy role a další informace o
uživateli. Přístupový server zakóduje cookies a vrátí uživateli
personalizovanou navigační nabídku. Když si uživatel zvolí některou aplikaci,
potom provozní služba na webovém serveru pozastaví žádost, dekóduje cookies a
ověří si akci u serveru s registrem. Server s registrem pak předá uživatelovu
identifikaci, preference, role a aplikačně-specifická data do aplikace na
webovém serveru, takže ten pak může předat příslušně schválené a přefiltrované
informace uživateli. Mobilní proxy server řídí relace pro počítače bez cookies,
jako jsou například bezdrátová zařízení.

V architektuře nástroje SiteMinder, když uživatel požaduje přístup ke
chráněnému zdroji na webovém serveru, webový agent vytáhne uživatelova pověření
z prohlížeče a předá je serveru s přístupovou politikou SiteMinderu. Ten pak
provede identifikaci (a konfrontaci) uživatele s uloženými pověřeními v
databázích adresářových nebo identifikačních služeb. Server s politikami potom
předá informaci příslušné aplikaci, která personalizuje obsah na základě
uživatelových pověření. Netegrity se integruje s existujícími adresáři a
databázemi a nevytváří své vlastní struktury tohoto druhu.

Konstrukce autorizačního nástroje Securant se vyhýbá komplikacím s integrací
tím, že odděluje obsah a aplikace jejich umístěním na různé servery.
Administrátor vytvoří obchodní pravidlo pro každý zdroj na chráněné webové
stránce. To definuje, jací uživatelé jsou oprávněni pracovat s jakými
aplikacemi. Když uživatel požádá o užití chráněného zdroje vůbec poprvé,
plug-in ClearTrustu na serveru s aplikacemi si vyžádá uživatelova pověření.
Potom předá výsledky šetření na autorizační server, který vyzpovídá databázi
oprávnění Securantu a vrátí uživatelovy pověřovací informace zpět na plug-in.
Nakonec plug-in otevře přístup ke zdroji. Prohlížeči je předáno zakódované
cookie, které umožňuje přístup při použití téhož zdroje v budoucnu.
0 2740 / pen









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