Správa informačních systémů velkých firem

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Správa informačních systémů velkých firem Diplomová práce

Autor:

Bc. Jiří Drábek 2. ročník MK, Informační technologie a management

Vedoucí práce:

Praha

Ing. Vladimír Beneš

Duben, 2009

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval zcela samostatně a s použitím uvedené literatury.

Bc. Jiří Drábek V Praze, dne 15. dubna 2009

Tímto bych chtěl poděkovat panu Ing. Vladimíru Benešovi za konzultace, rady a celkové vedení, týkající se obsahové náplně mé diplomové práce.

Anotace Cílem mé diplomové práce je zmapování současných trendů ve správě informačních systémů. Moderním trendem je správa IS pomocí adresářových služeb. Dále se zde budu také zabývat organizačními složkami a jejich uspořádáním při efektivní správě informačních systémů. Zde zmiňované situace, popisy a řešení se týkají správy informačních systémů aplikované ve velkých firmách. Pokusím se zmapovat s tím související možná rizika a navrhnout jejich možné řešení, případně zmírnění dopadu těchto rizik. V závěru se pokusím tato řešení vyhodnotit.

Annotation My goal is to map present trends in administration of Information Systems. One of the modern trend is administration via directory services. Then I will deal with organisational structure of organisation which is providing IT services. I will highlite structures that can bring more efficiency to administration of information services. Here mentioned situations, descriptions and solutions target administration of information systems in large organisations and business companies. Further I will try to map possible risks and suggest its possible solution. In the closure I will try to analyze these risks.

Obsah 1. 2.

Co je to informační systém ............................................................................................ 9 Technologická architektura IS ..................................................................................... 11 2.1 High Availability Cluster .................................................................................... 14 2.2 High performance clusters ................................................................................... 15 2.3 Load Balancing Clusters...................................................................................... 15 2.4 Tenký klient ......................................................................................................... 16 2.5 Tlustý klient ......................................................................................................... 17 2.6 CITRIX XenApp ................................................................................................. 18 3. Directory Services ....................................................................................................... 19 3.1 Lightweight Directory Access Protocol .............................................................. 19 3.1.1 Struktura LDAP ........................................................................................... 20 3.1.2 Seznam LDAP řešení .................................................................................. 21 3.1.3 LDIF (LDAP Data Interchange Format) ..................................................... 22 3.1.4 LDAP Failover ............................................................................................ 22 3.2 Microsoft Active Directory ................................................................................. 23 3.2.1 Organisational Unit (OU) ............................................................................ 25 3.2.2 Site ............................................................................................................... 25 3.2.3 Doménový řadič (Domain Controller DC) .................................................. 25 3.2.4 Lesy a stromy v AD ..................................................................................... 26 3.2.5 Trust ............................................................................................................. 26 3.2.6 Group Policy ................................................................................................ 26 3.3 Protokol Kerberos ................................................................................................ 28 3.3.1 Nedostatky protokolu Kerberos ................................................................... 30 4. Bezpečnostní rizika ..................................................................................................... 31 4.1 Social engineering ............................................................................................... 31 4.1.1 Přímý postup ................................................................................................ 31 4.1.2 Žádost o technickou podporu ...................................................................... 31 4.1.3 Předstírání pracovníka ................................................................................. 31 4.1.4 Předstírání technické podpory ..................................................................... 32 4.1.5 Phishing ....................................................................................................... 32 4.1.6 Odesílání emailu .......................................................................................... 33 4.2 Enumerace ........................................................................................................... 35 4.3 Chyby uživatelů ................................................................................................... 36 4.4 Autentizace .......................................................................................................... 37 4.4.1 Autentizace heslem ...................................................................................... 37 4.4.2 Autentizace pomocí předmětu ..................................................................... 38 4.4.3 Autentizace biometrikou ............................................................................. 39 5. Správa pracovních stanic ............................................................................................. 40 5.1 Vzdálená správa................................................................................................... 40 5.2 Instalace aplikací a OS ........................................................................................ 40 5.2.1 Nastavení počítače po instalaci OS ............................................................. 41 5.2.2 Patchování serverů....................................................................................... 42 5.2.3 Software Delivery Solution pro Klienty a Servery...................................... 44 5.3 Vzdálené spouštění procesů ................................................................................ 45 5.3.1 Spouštění procesů ........................................................................................ 45 6. Monitoring serverů ...................................................................................................... 48 6.1 HP OVO Monitoring ........................................................................................... 48

6.2 Lights Out Management ...................................................................................... 49 6.2.1 Výstupy z LOM ........................................................................................... 49 6.2.2 Hardware LOMu ......................................................................................... 49 6.2.3 HP Integrated Lights Out............................................................................. 50 7. Struktura technické podpory........................................................................................ 51 7.1 Service Desk ........................................................................................................ 51 7.1.1 Callcentrum ................................................................................................. 52 7.1.2 2nd level support ......................................................................................... 52 7.1.3 Incident management................................................................................... 53 7.1.4 Vyhodnocování pomocí reportů .................................................................. 54 7.2 Remedy Action Request System ......................................................................... 54 7.2.1 Remedy user ................................................................................................ 55 7.2.2 Remedy Mid-Tier ........................................................................................ 56 7.2.3 ARS Administrator ...................................................................................... 56 7.2.4 Import dat do ARS....................................................................................... 56 7.3 HP Open View Service Desk .............................................................................. 56 7.3.1 Formulář Service Call.................................................................................. 57 7.3.2 Formulář Change ......................................................................................... 59 7.3.3 Formulář Event ............................................................................................ 60 7.3.4 Problem ticket .............................................................................................. 60 7.3.5 Technologický popis HP OVSD ................................................................. 60 7.3.6 Filtry ............................................................................................................ 61 7.3.7 Service Bridge ............................................................................................. 62 8. Závěr ............................................................................................................................ 63 9. Použitá literatura .......................................................................................................... 65

Úvod Na začátek bych chtěl čtenáře seznámit s pojmy informační systém, adresářové služby a také vysvětlit co to vlastně správa IS je a co obnáší. V dnešní době probíhá autentizace uživatele do konkrétního systému pomocí LDAP, Active Directory nebo jiné adresářové služby. To v praxi velice usnadňuje administrátorům správu uživatelů. Nemusejí složitě zavádět uživatele do každého jednotlivého IS zvlášť. Pokud se změní uživateli například heslo nebo nějaký volitelný atribut, díky tomu, že se ostatní IS dotazují na autentizaci uživatele v LDAP, není potřeba tyto údaje měnit jinde. Stejně tak bývají změny v LDAP replikovány do Active Directory. To s sebou přináší výhody pro uživatele, že si nemusí pamatovat rozličná heslo do různých informačních systémů, ale do všech IS mají jednotné heslo. Velké, nadnárodní firmy řeší správu informačních systémů ve specializovaných datacentrech. Jedná-li se o firmu s celosvětovou působností, je moderní metoda Follow the sun. To znamená, že firma má obvykle 3 hlavní datacentra rozmístěná ve 3 časových pásmech, vždy posunutém o osm hodin. Zpravidla vychází jedno datacentrum na každý kontinent (Asie, Evropa, Amerika). Jako první začíná den (pracovní doba) v Asii, hlavní podpora klíčových aplikací je tedy tam. Ve všech datacentrech funguje podpora mimo pracovní dobu (out of hour support – OOH). Mimo pracovní dobu jsou přítomni alespoň pracovníci Helpdesku, kteří předávají problémy týkající se globálních aplikací do aktuálního datacentra. Díky neustálému rozvoji technologií a zrychlování IT infrastruktury jsou servery pro daný kontinent soustřeďovány do příslušného datacentra. Servery v Asii na kterých běží globální aplikace tak obsluhují klienty v Evropě bez výraznějších časových prodlev. Co se týká bezpečnosti informačních systému, asi největším rizikem často bývají samotní zaměstnanci nebo metoda zvaná sociální engineering. Ve velkých firmách s desítkami tisíc uživatelů rozmístěných po celém kontinentu je denně několik set případů zapomenutých hesel. Hesla do běžných IS a uživatelská hesla bývají spravována nejnižší administrátorskou úrovní, Helpdeskem. Problém je, jakým způsobem ověřit identitu volajícího. Když někdo chronicky zapomíná heslo pro přihlášení do počítače, těžko si bude pamatovat PIN pro ověření na Helpdesku. V praxi vypadá ověření identity uživatele dotazem na adresu odkud volá, jméno managera, atd. Což pochopitelně zná spoustu dalších lidí. Zdali nevolá někdo jiný, kdo se třeba chce jen podívat kolegovi do

7

emailu nebo někdo s rozsáhlejším plánem jak odcizit data, případně způsobit ztrátu dat a omezit tak dočasně obchodní aktivity firmy a způsobit tak značné finanční ztráty. Identifikace volajícího by se pochopitelně dala lépe vyřešit, například pomocí otisku prstu, to ovšem v některých zemích naráží na problém s legislativou. Například ve firmě, kde pracuji já, bylo jednu dobu zavedeno to, že veškerou komunikaci s Helpdeskem, včetně žádostí o změnu hesel, vyřizoval nadřízený. Od tohoto nápadu bylo ale po chvíli upuštěno, protože se pochopitelně zjistilo, že nadřízený nedělá nic jiného, než že tráví celý den na telefonu s Helpdeskem a uživatelé místo práce shánějí nadřízeného. Veškerá data, včetně emailů zaměstnanců, jsou pochopitelně zálohovaná a vzhledem k objemu, jsou ukládána na magnetické pásky. V případě ztráty dat je tedy časově náročné z pásek data zpět nahrát. Dalo by se říct, čím větší organizace, tím lépe jsou data a infrastruktura technologicky chráněna, ale o to větším problémem je jednání člověka. V současné době je trendem autentizace do informačních systémů pomocí adresářových služeb.

8

1. Co je to informační systém Všeobecně se jedná o systém sloužící ke sběru, archivaci, zpracování a poskytování informací. V dřívější době měl informační systém často papírovou podobu. S rozvojem informačních technologií se stále častěji setkáváme s automatizovanými elektronickými IS. Nejznámějším IS v papírové podobě je asi telefonní seznam. Obecně se informační systém skládá z informací a dat. Jako informace chápeme sdělení odstraňující nejistotu nebo nevědomost. Za data považujeme zaznamenané poznatky a fakta. Informace mohou být interpretovány jako data s nějakým konkrétním významem, který k nim přiřadí člověk nebo počítač. Je to komplex informací, technologií, organizace práce, technických prostředků a metod sloužících ke sběru, přenosu, uchování a dalšímu zpracování dat za účelem tvorby a prezentace informací. V současnosti se s elektronickými IS setkáváme v běžném životě na každém kroku. Architektura informačních systémů je grafické a písemné vyjádření celkové koncepce informačního systému. Zahrnuje v sobě základní představu o struktuře IS, která by měla korespondovat s organizační strukturou firmy. Dále by měla pojednávat o funkcích které bude informační systém zabezpečovat v návaznosti na vnitropodnikové procesy. Architektura by se měla zabývat také představou o provozu a bezpečnosti celého systému a jeho vazbách na okolí. Každý informační systém má dvě části: data a operace. Data jsou základní součástí IS, tvoří databázovou základnu. Jsou pořizována, ukládána a zpracována pomocí operací, funkcí, programů a systémů řízení bází dat. Naproti tomu jsou operace prováděny programem, algoritmem a jejich cílem je zpřístupnit data uživatelům, vytvořit z dat informaci kterou lze prezentovat ve vnímatelné podobě. Uchovávání dat rozdělujeme na archivaci dat a zálohování dat. Archivace dat znamená ukládat data za účelem jejich pozdějšího zpracování. Uložená data pak slouží k získávání informací o vývoji určitých skutečností a poskytují východiska pro trendy, prognózy a plánování. Naproti tomu zálohování dat znamená jejich ukládání pro případ havárie nebo nenadálé chyby v systému. Správné zálohování dat souvisí s bezpečností systému. Další důležitou funkcí informačního systému je aktualizace dat. Je to proces kterým se údaje v systému upravují tak, aby odpovídaly skutečnosti. Aktualizace dat zahrnuje přidávání, doplňování, změnu a smazání. Databáze, která není aktualizovaná je 9

nepoužitelná. Navíc svým způsobem i nebezpečná, protože data v ní obsažená, mohou být vzhledem k uplynulé době již neaktuální a tedy chybná. Aktualizaci dat mohou provádět jen oprávněné osoby s vymezenými přístupovými právy. Aktualizace musí být konzistentní, rychlá a zodpovědná. Provádí se ručně nebo automaticky. Bezpečnostní politika musí určovat správu informačních systémů, odpovědné osoby a skupiny k tomu určené. Týká se všech zdrojů v organizaci, musí být dokumentována, prosazována a schvalována managementem podniku. Pochopitelně s bezpečnostní politikou se musí počítat již při návrhu informačního systému. Cílem bezpečnostní politiky je zajištění důvěrnosti, integrity a dostupnosti systému, autentizace uživatelů, zabezpečení dat před osobami z venku. Data musí být chráněna proti ztrátě a zničení (havárie systému, působnost viru, působnost živlu, nechtěným zásahem osoby) správným a častým zálohováním. Proti zneužití jsou data chráněna přístupovými právy. Data musíme chránit rovněž proti duplicitě, proto nesmíme při navrhování informačního systému zapomenout také na nezbytný mechanismus pro kontrolu duplicity dat. Prostředky pro ochranu informačních systémů rozdělujeme na technické, programové a organizační. Do technických patří: spolehlivý a bezpečný hardware, alarmy, hlásiče požáru, systém identifikačních a přístupových karet. Programové, kam patří: antivirový software, firewally, kódované ukládání dat, šifrovaná komunikace, autentizace heslem nebo certifikátem. Mezi organizační se řadí: organizační struktura, udělování přístupových práv, pravidla pro archivaci, kontroly zabezpečení, monitorování a vyhodnocování činnosti systému a další. Stát zabezpečuje informační systémy legislativně. Pochopitelně, tato ochrana je pasivní a tak stejně nikoho neodradí od případného nekalého úmyslu.

10

2. Technologická architektura IS V dnešní době se používá takzvaný třívrstvý model. Návrh architektury informačního systému musí počítat do budoucna se snadnou údržbou a možnou rozšiřitelností IS. Jak už název napovídá, tento model se skládá ze tří vrstev: prezentační, aplikační a databázové vrstvy. Prezentační vrstva umožňuje využívat jednotlivé aplikace s dalšími softwarovými produkty třetí strany. Aplikační vrstva tvoří prostředí aplikačních funkcí a databázová vrstva poskytuje řízení databázových operací. Moderním trendem je oddělit aplikační a prezentační logiku od přístupu k datům. Aby mohl programátor pracovat volně s daty a mohlo je třeba využívat více aplikací. Naopak aplikace jsou tím pádem snadno přístupné jiným datovým zdrojům. Při současném nasazování informačních systémů ve velkých organizacích, kde je základním požadavkem na informační systém, aby na něj současně mohlo přistupovat mnoho uživatelů, je důležité navržení vhodné architektury. Dalším základním požadavkem na informační systém je, že i ve špičkách zatížení (doba, kdy je připojeno nejvíce uživatelů a vzneseno nejvíce požadavků), musí poskytovat dostatečnou odezvu uživateli a všechny služby musí být dostupné. Důraz je také kladen na přístup z různých prostředí, třeba jen k určité části služeb a informací. Model tlustého klienta, tedy klient – server vztah, přičemž server zajišťuje pouze přístup k datům a na straně klienta probíhá zpracování, je již zastaralý. Dnes je potřeba kromě snadného přístupu a rychlosti, aby byl informační systém snadno centrálně udržovaný a spravovatelný. Varianta třívrstvého modelu, kde jako tenký klient slouží webový prohlížeč, je pochopitelně daleko náročnější na tvorbu a implementaci, navíc se nemusí povést zachovat všechny vlastnosti, které nabízel nebo nabízí tlustý klient. Přesto všechno je třívrstvá architektura ideálním řešením v prostředí s masivním využíváním informačního systému.

11

Obrázek č. 1: Architektura IS, převzato z http://is.muni.cz/clanky/2005_tvorba_sw.pl

Řekněme si něco více o výše popisované architektuře. Jednou z částí je webový prohlížeč, jenž je jedinou komponentou, která je instalovaná na klientský počítač, mobilní telefon, PDA, Blackberry, atd. V dnešní době jsou ve všech zmíněných komunikačních zařízeních webové prohlížeče instalovány již jako součást operačního systému, takže není nutná další instalace administrátorem nebo uživatelem. Informační systém jako takový je spravován tím, kdo ho provozuje. První část se skládá z prezentační, aplikační a datové vrstvy. Prezentace znamená realizaci komunikace s webovým prohlížečem a vygenerování dat na výstupu. Data jsou prezentována graficky na zobrazovacím zařízení nebo na papíře jako tisk. Prezentace a aplikace je mnohdy považována za celek, přestože je nutné jí rozdělit do několika procesů kvůli návrhu a údržbě aplikací. Datová vrstva je poslední vrstvou tohoto modelu. Jejím úkolem je zajišťovat uložení dat v rámci informačního systému a zajišťovat k datům rychlý přístup. Při realizaci podle této architektury je velice důležité přesně rozlišit 12

jednotlivé vrstvy při práci s daty. Aplikační vrstva předpokládá, že data jsou uložena v databázovém subsystému, a proto se na její úrovni neimplementuje žádný mechanismus, který by sloužil k souběžnému přístupu k datům. Jestliže data poskytuje a udržuje pouze datová vrstva, může se zátěž stejnou měrou rozdělit na více fyzických serverů v clusteru. Pro tento případ je vhodný cluster s load balancingem. Poskytování hromadného přístupu uživatelům k datům ve stejnou dobu, je dnes běžnou funkcí datové vrstvy. Databázové systémy tuto funkci poskytují na nejvyšší úrovni. Z toho důvodu se na aplikační úrovni ukládají jen ta data, která se téměř nemění. Dalším velice důležitým požadavkem je dostupnost. Přístup dvacet čtyři hodin denně je dnes již standardem. Z toho důvodu musí být infrastruktura informačního systému odolná proti výpadkům, plánované údržbě nebo dokonce plánovaným uzávěrkovým a zálohovacím operacím. Tyto plánované operace jsou spíše otázkou minulosti. Například uzávěrkové operace, které často probíhají i denně, vyžadují nejprve odhlášení všech uživatelů a teprve pak může být proveden samotný výpočet. Dnes se s takto navrženými informačními systémy můžeme ještě setkat v organizacích, které fungují přes dvacet let. Přechod na nový informační systém by bylo tak náročné, že je lepší modifikovat ten původní. Ve firmě, kde pracuji, je takováto uzávěrka denní prací unixových operátorů. Uživatelé mají pochopitelně nařízeno, že práci musí ukončit večer do určité hodiny a informační systém mohou používat zase až ráno. Nejprve operátor uzamkne aplikaci, spustí skript, který odhlásí všechny uživatele (zabije uživateli spuštěné procesy). Potom začnou denní zálohy. Jakmile zálohy doběhnou, spustí vlastní procesování dat, tedy denní uzávěrku. Až v ranních hodinách uzávěrka doběhne, opět odemkne aplikaci a uživatelé se opět mohou připojovat. Vše je řízeno pomocí spouštění unixových skriptů. Vysokou dostupnost je možné zabezpečit pouze násobením jednotlivých zdrojů, které systém používá. To znamená, jestliže dojde k výpadku jedné části systému, okamžitě začne poskytovat stejné služby další část. Oddělení částí systému, které plní stejný účel, pomáhá ve snadnějším zjištění chyby v softwaru nebo hardwaru a umožňuje provádět postupnou údržbu i za chodu. Takovéto přidávání nových zdrojů se zajišťuje na všech úrovních (od gateway až po diskové pole), zpracování formou distribuovaného procesování požadavků. Distribuované zpracování zajišťuje vyšší dostupnost, možnost snadného rozšíření systému a zejména efektivní rozložení zátěže ve špičkách vytíženosti systému. Jestliže je k datům přistupováno pouze přes datovou vrstvu, je navýšení výkonu na aplikační vrstvě velice

13

snadné z toho důvodu, že

přístup k datům je transparentní a prvky pro přidělování

vyrovnávací paměti neměnných dat je možné realizovat bez zvýšení režie i při větším distribuovaném zpracování. Znamená to, že jestliže chceme zvýšit výkon, stačí přidat další aplikační server, namísto přidávání jednotlivých zdrojů, jako je paměť a procesory ve víceprocesorových

prostředí.

Také

databázová

vrstva

umožňuje

využít

takový

distribuovaný způsob. Z toho plyne, že třívrstvá architektura webových informačních systémů se může z víceprocesorových platforem postupně přenést na model vzájemného propojení serverů na obou úrovních. Poskytnou tak stejný nebo vyšší výkon s menšími náklady. Stejně tak, jako je tomu v prostředí pro náročné vědecké výpočty, tak i na poli komerčních informačních systémů, se stále častěji používá GRID model. Tedy síť vzájemně propojených počítačů s vysokým výpočetním výkonem, zajišťující jednu službu. Zkušenosti z testovacího provozu ukazují, že model databázových clusterů se nehodí pro každou aplikaci. Není tomu tak kvůli nekompatibilitě, ale z důvodu nedostatečného výkonu za běžného provozu .

2.1 High Availability Cluster Tento název známe také pod pojmem Failover Clusters nebo zkráceně jen HA clusters. Jedná se o svazky serverů nebo počítačů. Ty jsou určeny k tomu, aby jak už název v anglickém jazyce napovídá, zajišťovaly vysokou dostupnost služeb, jenž servery poskytují. Fungují na tom principu, že mají o jeden nebo více serverů navíc. V případě selhání serveru nebo jeho operačního systému, převezme některý z nadbytečných serverů hlavní úlohu. Na HA cluster serverech se neustále zjišťují chyby hardwaru a softwaru. V případě, že dojde na jednom serveru ke zjištění nějaké chyby, dojde k okamžitému nastartování všech služeb na dalším serveru bez jakéhokoliv zásahu administrátora. Tomuto procesu se také říká Failover. Součástí procesu Failover je, že software používaný pro clustering předem nakonfiguruje filesystem, hardware, případně spustí potřebné aplikace. Využití HA clusterů nachazíme například u hostování důležitých databází, aplikací, informačních systémů nebo sdílení souborů na síti. Problém síťového výpadku je zde řešen několika nezávislými připojeními do sítě. Datové uložiště SAN (Storage Area Networks – datové uložiště jako třeba diskové pole, magnetická a optická zařízení jsou oddělena od serverů a vzdáleně připojena, přičemž se tváří pro operační systém jako lokální disky) je odděleno a několikanásobně propojeno s HA clusterem. Stav jednotlivých serverů monitoruje síťová komponenta heartbeat (v překladu srdeční pulz). Představme si

14

ale například situaci, kdy najednou spadne celá privátní síť. Servery v clusteru mohou nesprávně vyhodnotit situaci a každý z nich vyhodnotí, že ostatní servery vypadly. V tu chvíli by se mohlo stát, že servery začnou startovat služby, které současně běží na všech. Tato duplicita instancí služeb může mít za následek ztrátu nebo poškození dat na sdíleném uložišti. Tuto situaci musí clusterovací software zvládnout a zajistit vypnutím nebo správným vyhodnocením integritu dat. Ještě bych chtěl zmínit, že zdaleka ne každá aplikace je schopná běžet na serverech v HA clusteru. Musí být od začátku navržena pro nasazení v tomto prostředí. Aby mohla aplikace běžet v HA clusteru, musí splňovat alespoň tyto parametry: •

Aplikace musí být snadno nastartovatelná a zastavitelná. Musí být snadné zjistit status aplikace. To se dá vyřešit nejlépe pomocí toho, že aplikace bude možno ovládat také pomocí příkazové řádky nebo skriptů.

•

Aplikace musí být schopna pracovat se síťovými sdílenými úložišti SAN nebo NAS

•

Aplikace musí ukládat co nejvíc dat na spolehlivé sdílené úložiště na síti

•

Aplikace musí být schopná načíst nejnovější uložený stav ze sdíleného úložiště a nastartovat se na jiném serveru do stavu před výpadkem.

•

Aplikace musí zachovávat integritu dat, to znamená, že nesmí poškozovat data při selhání nebo při nahrávání z uloženého stavu.

2.2 High performance clusters Tento druh clusterů slouží ke zvýšení výpočetního výkonu pomocí více počítačů. Počítače na výpočtu vzájemně spolupracují. Takto vznikne vysoce výkonný výpočetní cluster. Ovšem jediným háčkem je, že tuto funkci musí podporovat samotná aplikace. Další limitace, jako ostatně u všech řešení za pomoci clusterů, je nutnost velmi rychlé vnitřní sítě, jenž spojuje clustery. Aby došlo opravdu k maximálnímu využití výpočetní kapacity, je nutné, aby síťové prvky mezi počítači nebo servery dosahovaly rychlosti 10gb/s.

2.3 Load Balancing Clusters Způsobem, jak využít servery v clusteru za účelem maximálního výkonu, je spustit nad nimi tzv. loadbalancing. Představme si situaci, kdy konkrétní informační systém (například internetový informační systém, IS poskytující informace o zásilkách, apod.)

15

využívají desetitisíce až stovky tisíc uživatelů v jeden okamžik. Aby uživatelé svými požadavky a operacemi nezahlcovali jeden server nebo část clusteru, spustí se na clusteru vyrovnávání zátěže (load balancing). Vyrovnavač zátěže (load balancer) je obvykle software, který naslouchá na portu, ke kterému se klienti připojují za účelem požadování služby. V podstatě předává dál požadavky serveru, který odpoví load balanceru. Tohle sebou nese velkou výhodu, co se týká bezpečnosti. Klient nezná vnitřní strukturu (IP adresy), se servery nekomunikuje přímo, přistupuje totiž jen k load balanceru. Tím se zamezí případnému útoku na samotné servery nebo síťové prvky za load balancerem. Některé load balancery nabízejí speciální funkce jako například přesměrování na záložní load balancer nebo v případě celkového výpadku zobrazí uživateli zprávu o výpadku. Dalším způsobem, jak vyřešit load balancing je dle rozdělení IP adres. V praxi to znamená, že každému serveru přidělíme určitý okruh povolených IP adres. Jen klienti s IP adresou na seznamu, se budou moci připojit k příslušnému serveru. DNS server v takovémto případě neodpovídá klientovi s jednou IP adresou, ale hned s celým seznamem IP adres serverů, jenž poskytují stejnou službu. Klienti se většinou snaží na tyto IP adresy připojovat dle jejich pořadí. Není ale výjimkou, kdy si klient znovu vyžádá seznam IP adres pro připojení, protože se snaží najít číselně bližší síť. Komunikace v číselně bližší síti je pochopitelně daleko rychlejší. Praktického využití se této metodě dostává při load balancingu na web serverech, jenž jsou teritoriálně rozmístěny. Například firma s jednou doménou a třemi web servery (A, B, C) poskytujícími stejnou službu. Klient, který se připojí jako první, dostane seznam IP adres v následujícím pořadí - A, B, C. Druhý klient dostane pořadí - B, C, A. Třetí klient dostane pořadí - C, A, B. Čtvrtý klient bude mít opět - A, B, C, atd. Zkrátka dostávají permutace pořadí IP adres.

2.4 Tenký klient V anglickém jazyce známý jako Thin Client nebo Slim Client. Tenký klient je druh aplikace, která pro server nezpracovává data, pouze přenášejí vstup a výstup mezi uživatelem a vzdáleným serverem. Veškeré zpracování dat tak leží na centrálním serveru. Tlustý klient naopak zpracuje téměř veškeré data a na server odesílá pouze data, která chce uložit. Většina tenkých klientů má v dnešní době webové rozhraní nebo využívá systému vzdálené plochy, přičemž téměř všechna důležitá zpracování dat dělá server. Ke

16

stále častějšímu řešení pomocí tenkých klientů dopomáhá fakt, že došlo ke zrychlení internetové konektivity a celkově zrychlení síťové komunikace. Hlavní výhodou užívání tenkých klientů je finanční stránka. Jako hardware pro tenkého klienta postačí průměrný počítač s operačním systémem. Nepotřebuje žádné další programové vybavení. Tím, že jsou veškeré operace s daty, včetně jejich archivace, prováděny na serveru, minimalizují se bezpečnostní rizika. Neměl by hrozit tedy únik dat a jejich ztráta, na serveru by měla být dobře zálohována. Uživatel se tedy o archivaci dat nemusí starat a nehrozí tak že by zapomněl na jejich zálohování. Tenký klient nepotřebuje ani žádnou údržbu, aktualizace, atd. Vše je prováděno na centrálním serveru. Aby došlo k maximálnímu ušetření na hardwaru, přišly některé firmy, například HP, IBM s hardwarovým tenkým klientem. Není to klasický počítač, ale zařízení s minimální nutnou výpočetní silou, neobsahující pevný disk. K bootování slouží Flash paměť, CD nebo se bootuje po lokální síti. Uživatel má k dispozici klávesnici, případně myš, výpočetní kapacita zařízení slouží pouze k zobrazování a komunikaci se serverem. Aktuálním trendem mezi tenkými klienty, zvané též ultra tenký klient je spouštění aplikací přes vzdálenou plochu. Například X Windows System, Citrix a Microsoft Terminal Services. Toto řešení umožňuje chod aplikací na centrálním virtuálním počítači. Veškeré úhozy na klávesnici jsou přenášeny z lokálního PC na virtuální. Z virtuálního jsou přenášeny snímky obrazovek na lokální. Jedná se o aplikace, které jsou velmi náročné na datový přenos a byly řešeny pomocí tlustého klienta.

2.5 Tlustý klient Je opak tenkého klienta. Není závislý na serveru, je schopen zpracovávat data samostatně. Sporadicky vyžaduje připojení k síti, serveru, aby aktualizoval data. Drtivou většinu operací provádí klient, nikoliv server, proto je při tvorbě informačního systému nutno zvážit, které úkoly bude zpracovávat server a které klient a zvolit vhodného klienta. Volba správného klienta má vliv především na náklady na vývoj IS a jeho rychlost. Výhodou tlustého klienta je například nenáročnost na výpočetní kapacitu serveru, protože data zpracovává z velké části klient. Další výhodou je, že uživatel může pracovat, i když je spojení se serverem nedostupné. Tlustý klient je vhodný pro použití multimedií, například při hraní síťových počítačových her, kdy jsou přenášeny jen údaje o pohybu hráčů, hra je přitom nainstalovaná lokálně.

17

2.6 CITRIX XenApp

Obrázek č. 2: Citrix metaframe presentation, výběr aplikací

Citrix je produkt určený pro velké firmy a instituce. Umožňuje uživatelům se vzdáleně připojit k firemním aplikacím. Spustí-li uživatel aplikaci přes Citrix v operačním systému Windows, aplikace se otevře v novém okně a vše vypadá téměř jakoby ji spouštěl ze svého počítače. Není tomu tak, aplikace spouštěné přes Citrix jsou hostované na serveru. Výhodou takovéto distribuce korporátních aplikací je, že uživatel k nim má přístup z kteréhokoliv firemního počítače bez nutnosti další instalace. V současné době tyto funkce poskytuje XenApp, jenž nahradil Citrix Metaframe a Citrix Presentation server. XenApp je založen na protokolu ICA (Independent Computing Architecture), jímž přenáší veškeré grafické informace o aktuálním okně ve velmi vysoké kvalitě. Toto je možné díky Citrix Display Driveru, ovladači, jenž je schopen zachytávat GDI (Graphics Device Interface) příkazy, které přehrává na GDI kompatibilních klientech. Klienti jsou k dispozici pro operační systémy: Windows (CE, 16, 32, 64 bit), MAC OS nebo Linux. Pakliže je zapotřebí přístup bez nutnosti instalace klienta na lokální počítač, je možné použít webového Citrix klienta, tzv. Web Interface for XenApp. V současnosti je nejnovější verze XenApp 5.0.

18

3. Directory Services Ve většině velkých organizacích je správa uživatelů v informačních systémech řešena pomocí adresářových služeb. Pod pojmem adresářová služba si představme něco jako vyhledávání ve slovníku. Ke každému jménu je přiřazena nějaká informace nebo několik informací. Adresářová služba je tedy software, který má na starosti uložení a správu těchto dat. Jednou z adresářových služeb, kterou využívá dnes téměř každý je DNS (Domain Name System). Záznamy ke každé doméně nebo www adrese obsahují IP adresu, pomocí které se počítač k serveru skutečně připojuje. Adresář, jenž používá síťový operační systém obsahuje položky, jenž operační systém spravuje. Těmito položkami jsou uživatelé, počítače, tiskárny, atd. V minulosti bylo používáno mnoho typů adresářových služeb, dnes se řídí souborem standardů X.500. Podle těchto standardů má adresářová struktura pravidla, podle kterých jsou jednotlivé položky pojmenovány a identifikovány. Jméno musí být jedinečné a nezaměnitelné. Název položky se nazývá Distinguished Name, značí se (DN) a znamená rozlišovací jméno. Jednotlivé položky mohou obsahovat například informace o uživateli, jako je jeho přihlašovací jméno, emailová adresa, země původu, lokace, atd. O položce počítač obsahuje například informaci, který uživatel se tam může přihlásit, kde se počítač nachází, atd. Velké organizace používají i několik adresářových serverů. Aby se na každý z nich nemusel záznam nové položky zapisovat manuálně nebo upravovat manuálně, je nutné mezi nimi nastavit replikaci. Jestliže správce změní uživateli přihlašovací jméno nebo heslo v AD a nebude-li správně, nebo zcela fungovat replikace mezi LDAP serverem a ACTIVE directory, nezreplikuje se do LDAP a uživatel se nebude moci přihlásit do systémů jenž používají autentizaci LDAP.

3.1 Lightweight Directory Access Protocol LDAP je druh adresářové služby, která poskytuje klientům přístup ke strukturovaným datovým záznamům. Pro představu má podobnou strukturu jako telefonní seznam. Adresář většinou obsahuje seznam uživatelů, jejich jméno, emailovou adresu, telefon, informace o účtu, informace o pracovních stanicích, tiskárnách a v jaké místnosti se daný hardware nachází. Skladba informací není pevně definovaná, můžeme si sami určit o jaký druh

19

informací u jednotlivých položek máme zájem. Oproti předešlým adresářovým službám je zde kladen hlavně důraz na rychlost vyhledávání. Jedná se o aplikační protokol, který slouží k vyhledávání a upravování položek v adresářových službách. Tento protokol využívá TCP/IP. Jak jsem již uvedl u adresářových služeb, adresář obsahuje záznamy (objekty), seřazené logicky nebo hierarchicky. V dnešní době se v LDAPu používá hierarchické rozdělení podle domén, pod nimiž dále nalezneme uživatele, tiskárny, počítače například dále rozdělené do organizačních složek (OU = organisational unit). LDAP vychází z modelu X.500.

3.1.1 Struktura LDAP Adresář se skládá ze stromu objektů neboli záznamů, jenž tvoří tzv. Directory information tree (DIT). Objekt neboli záznam je tvořen atributy. Každý atribut má jméno, typ, popis a minimálně jednu hodnotu. Na jedné úrovni má každý objekt jiné Relative Distinguished Name (RDN). Každý objekt je v celé stromové hierarchii jednoznačně určen svým Distinguished Name (DN), které se skládá z RDN objektu a RDN předcházejících objektů. Klient začíná LDAP session tím, že se připojí na LDAP server. Klient odešle požadavek na operaci a server v zápětí odpoví. Až na pár vyjímek, klient nemusí čekat na to, než mu server odpoví, aby mohl poslat další požadavek. Klient může požadovat následující operace: •

Start TLS

Požaduje zabezpečené spojení pomocí TLS (Transport Layer Security). Toto zabezpezpečení je provedeno pomocí šifrovacího protokolu TLS, který přenášená data kóduje a chrání je tak proti nežádoucím stranám, například, aby třetí strana nemohla data přečíst. Také se může stát, že třetí strana data zfalšuje a cíli pošle podvržená data. O tohle se TLS protokol také stará a ověřuje integritu dat. Předchůdce tohoto protokolu, protokol SSL a jeho verze se denně používají při emailové komunikaci, využívají ho hlasové služby (VoIP), instant messaging, atd. Oba protokoly, TLS i SSL kódují síťovou komunikaci na transportní vrstvě. •

Bind

Ověří a specifikuje verzi protokolu LDAP, dále se stará o autentizaci uživatelů, jako plaintext posílá uživatelské jméno a heslo, takže je dobré, vyhledat záznamy v adresáři,

20

porovnat, jestli záznam obsahuje daný atribut, vložit nový záznam, smazat záznam, změnit záznam, změnit celý DN, čímž přejmenuje záznam nebo ho přesune, přerušit předcházející požadavek, rozpojit spojení se serverem. •

Extended operations

Rozšířená operace je více složených operací do sebe. Tím vzniká nová, rozšířená operace. Rozšířenou operaci si můžeme sami nadefinovat. •

Abandon

Tato operace požaduje od serveru ukončení jiné operace. Vzkaz, který serveru pošle, má stejné ID, jako operace, která má být ukončena. Jestli server zpracoval požadavek a opravdu nějakou operaci ukončil, se u Abandon operace nikdy nedozvíme, protože tento typ operace neposílá odpověď. Proto byla vytvořena rozšířená operace Cancel, která byla rozšířena právě o zasílání odpovědí, jestli byla daná operace ukončena či nikoliv. Problém je, že ne všechna LDAP řešení počítají s operací Cancel. •

Unbind

Tato operace ukončí jakoukoliv jinou operaci a přeruší spojení, tím pádem nemá ani žádnou odezvu. Klienti mohou zrušit otevřenou session natvrdo rozpojením spojení. Měli by ale použít operaci Unbind. Pomocí této operace server normálně ukončí spojení a uvolní zdroje. V případě náhlého rozpojení jsou ještě zdroje po nějakou dobu reservovány, než server zjistí, že klient ukončil spojení.

Administrace LDAP se liší podle poskytovatele řešení. Například v Open LDAP, který je zdarma ke stažení z www.openldap.org a běží na operačním systému Linux, se spravují uživatelé pomocí příkazů zadávaných do konzole. Naproti tomu, ve Windows Server 2003, slouží ke správě grafické uživatelské rozhraní. Existují také univerzální grafická uživatelská rozhraní, jako například Apache directory studio, které komunikuje s adresářovým serverem, lze v něm exportovat a importovat LDIF soubory, vyhledávat a provádět další operace.

3.1.2 Seznam LDAP řešení Pro úplnost uvádím seznam řešení LDAP.

21

OpenLDAP, Apache Directory Server, CA eTrust Directory, Fedora Directory Server, Red Hat Directory Server, Novell eDirectory, Sun Directory Server Enterprise Edition IBM SecureWay Directory, IBM Tivoli Directory Server, Windows Server 2003 Active Directory, Siemens DirX, Oracle Internet Directory, tinyldap...

3.1.3 LDIF (LDAP Data Interchange Format) Jedná se o klasický plaintextový soubor, který zapisuje svůj obsah do LDAP. Může obsahovat dotazy na vkládání objektů, jejich modifikaci, mazání objektů a jejich přejmenování. Využití LDIFu je zejména při hromadných změnách dat, u kterých by změna byla pouze mechanickou prací administrátora nebo při přenosu dat ze server na server. Záznamy v LDIFu jsou od sebe odděleny prázdnou řádkou. Jednotlivé atributy záznamu jsou uvedené vždy na jednom řádku. LDIF soubor je možné snadno vytvořit v jakémkoliv textovém editoru. Nesmíme přitom zapomenout na povinnou strukturu a pochopitelně musíme mít znalost struktury adresáře. Každé LDAP řešení obsahuje nástroj pro import a export LDIF souborů. K dispozici je také řešení od třetích stran, například Appache Directory Studio. Minimální struktura jednoduchého LDIF souboru. dn: objectClass: ... <jména atributů>:

3.1.4 LDAP Failover Při replikaci se pracuje se dvěma typy adresářů: Master a Replika. Ldap Master, neboli primární LDAP server, znamená hlavní server LDAPu a je pouze jeden. Ostatní servery se nazývají Repliky. Veškeré změny, které jsou v LDAPu prováděny se nejprve provedou na LDAP Masteru a postupně jsou replikovány na ostatní LDAP repliky. Databáze každé LDAP repliky serveru obsahuje naprosto stejná data, jako jsou na LDAP masteru. Adresářové změny mohou být prováděny vždy pouze na masteru, který se vždy používá pro zapisovací operace do adresáře. Jak LDAP master (primární LDAP server) tak LDAP repliky umožňují čtecí operace. Co se týká síťové infrastruktury, bývají repliky umístěny v blízkosti koncových služeb.

22

Mezi LDAP repliky je distribuovaná zátěž z LDAP masteru, vytvářejí také redundanci v případě výpadku. Jestliže dojde k výpadku LDAP masteru, není možné zapisovat do adresářů, takže veškeré write operace (vytvoření nového uživatele, modifikace atributů uživatele, změna hesla, atd.) není možné provádět. Provedeny mohou být pouze čtecí read operace (autentizace a přihlašování uživatelů do informačních systémů) z LDAP replik. Výpadek write operací je pochopitelně velmi nepříjemný, uživatelé si nemohou měnit hesla a správa uživatelů informačních systémů vyžadujících autentizaci uživatelů přes LDAP je na mrtvém bodě. Pakliže je delší dobu výpadek LDAP masteru, může být některý z LDAP replik serverů určen jako master a write operace mohou pokračovat. Failover LDAP masteru pro read a write operace zabezpečuje například komplexní řešení od IBM s názvem IBM Tivoli Access Manager.

3.2 Microsoft Active Directory Active directory je řešení adresářových služeb od firmy Microsoft poskytující řadu služeb. Adresářové služby v AD se podobají LDAPu. Velkou výhodou Active Directory je, že umožňuje administrátorům přiřazovat tzv. skupinovou politiku, řídit přístup k softwaru, vytvářet skupiny uživatelů s různými oprávněními, atd. Často se uvádí, že AD se používá pro distribuci softwaru. To je omyl, pouze nabízí mechanismus pro řízení přístupu k softwaru, jako je možnost přidávat uživatele do citrixových skupin a na Citrix serveru pak nastavit aplikace pro příslušnou skupinu. Samotný přístup a spouštění softwaru pak umožňují další aplikace, například Citrix Metaframe Presentation. Řešení Active Directory je vhodné pro všechny organizace. Od několika málo uživatelů, počítačů a tiskáren až po tisíce od každého. Je možné v něm spravovat několik domén i serverů současně. Právě i díky této podpoře více domén a serverů najednou, je Active Directory využívaný u firem s celosvětovou působností a pobočkami po celém světě. Domény a servery rozmístěné kdekoliv na světě se dají částečně spravovat z jednoho místa. K představení na veřejnosti Active Directory došlo v roce 1999. Původně měl název NTDS (NT Directory Service). Později byl AD vydán jako součást Microsoft Windows 2000 Server. K pozdějším změnám a rozšířením možností administrace došlo s příchodem Windows Server 2003, následně pak druhé edice Windows Server 2003 R2. Další vylepšení přibyla ve Windows Server 2008.

23

Obrázek č. 3: Příklad uspořádání objektů v AD

Smyslem Active Directory je ukládat, poskytovat informace o síťových zdrojích v doméně, řídit k nim přístup a nastavit bezpečnostní opatření. Základním prvkem v AD je objekt. Objekty dělíme na tři základní kategorie: zdroje (tiskárny, počítače), služby (email) a uživatele (patří sem i skupiny). Každý objekt představuje jedinečnou entitu a její atributy. Některé objekty mohou být kontejnerem pro další objekty. To, jaké informace a atributy mohou být objektu nastaveny a jak mohou být objekty uspořádány, obsahuje schéma. Ve schématu existují dva druhy objektů. Schema Classes určuje možné objekty a je souhrnem atributů. Schema Attributes určuje jednotlivé atributy objektu. Jsou to v podstatě data o datech, nazývají se metadata. Pro správu schématu slouží nástroj Active Directory Schema. Jestliže se schéma změní, automaticky se aplikuje na celý Active Directory a jakmile je takové schéma vytvořeno, nelze ho smazat, pouze deaktivovat. Změna schématu se musí předem pečlivě naplánovat.

24

3.2.1 Organisational Unit (OU) OU jsou v Active Directory kontejnery, do kterých můžeme umisťovat uživatele, počítače, skupiny a další organizační jednotky. Organizační jednotka nemůže obsahovat objekty z jiných domén a je zároveň nejmenší jednotkou, na kterou lze uplatnit skupinovou politiku nebo delegovat administrační práva. Díky organizačním jednotkám lze strukturu domény snadno uspořádat podle hierarchické struktury organizace. Lze tak například spravovat uživatele nebo počítače podle oddělení nebo geografické polohy. Jak již bylo řečeno, organizační jednotky mohou obsahovat další organizační jednotky a hierarchie kontejnerů může být rozšiřována dle libosti. Tímto se také dá minimalizovat počet domén. Také administrační práva lze přidělovat dle organizačních jednotek. Může třeba existovat administrátor, který má na starosti jedinou OU.

3.2.2 Site Site je kombinace jednoho a více subnetů, jenž jsou vzájemně spojeny vysokorychlostními linkami. Site obsahují doménové řadiče (DC – domain controller) a mají velký význam pro firmy s více pobočkami kdekoliv po světě. V logické struktuře Active Directory se Site nikdy nezobrazují. Site mají význam hlavně pro replikace. Pro správu Site se používá nástroj Active Directory Site and Services.

3.2.3 Doménový řadič (Domain Controller DC) Je počítač, server na kterém běží operační systém Windows Server 2000/2003/2008 obsahující repliku doménového adresáře. Doménový řadič slouží k autentizaci uživatelů. Na jednom řadiči se může nacházet pouze jediná doména. Naopak v doméně může být více doménových řadičů. Každý řadič v doméně obsahuje úplnou repliku adresáře dané domény.

Jestliže provedeme změnu na jakémkoliv doménovém řadiči, provede se

automatická replikace na ostatní řadiče ve stejné doméně. Replikace se provádí u důležitých údajů automaticky, u méně důležitých se provádí periodicky. Máme dva druhy replikací. Replikace typu multimaster, kde všechny řadiče jsou si rovny a do kopie adresáře lze zapisovat. Některé hodnoty nelze tímto způsobem zapsat a používá se model singlemaster, který má pouze jeden hlavní řadič, na němž se provádějí změny.

25

3.2.4 Lesy a stromy v AD Slovo les (forest) vyjadřuje v Active Directory souhrn všech objektů, jejich atributů a pravidel. Les, strom a doména jsou logické části struktury Active Directory. Častým důvodem na dělení struktury, je rozdělení administračních oprávnění.. Na úrovni Organisational Unit lze vyřešit správu uživatelů a počítačů, pro vyšší úkony je zapotřebí domény. Strom je seskupení nebo hierarchická organizace jedné a více domén. K vytvoření stromu dochází tak, že ke kořenové doméně (root domain neboli parent domain) přidáme podřízenou doménu (child domain). Domény mají ve stromu společný jmenný prostor (namespace), schéma a hierarchické spojení doménových jmen. K pojmenovávání podřízených domén (child domain) se používá DNS standard, takže jméno podřízené domény se skládá z jejího relativního jména, doplněné za tečkou jménem jeho rodičovské domény. Uvádím malý příklad, jako parent domain máme doménu s názvem domena.com, přidáme-li dvě podřízené domény, mohou mít název například praha.domena.com

a

brno.domena.com. Naproti tomu les (forest) je seskupení jednoho a více nezávislých stromů. Domény v lese mají stejné schéma, globální katalog a jsou vzájemně v trustu (dvoucestný vztah důvěry). Stromy v lese mají vlastní pojmenování - DNS jméno (oddělený jmenný prostor podle domén). Domény v lese pracují nezávisle, ale díky lesu je umožněna vzájemná komunikace přes celou organizaci (autorizace). Root domain je důležitá pro les, protože je standardně držitelem dvou speciálních rolí.

3.2.5 Trust Abychom umožnili uživatelům domény A využívat zdroje z domény B, používá Active Directory tzv. trusty (důvěru). Trusty v lese se vytváří automaticky, když se vytvoří nové domény. Les vytváří výchozí nastavení trustu, nikoliv doména. Windows Server 2000 podporuje pouze dva druhy trustů: jednosměrný a obousměrný trust. Další trusty musí vytvořit administrátor. Windows Server 2003 přináší nový druh trustu, tzv. Forest Root Trust. Tento typ trustu se používá ke spojení mezi Windows 2003 foresty. K autentizaci se v tomto trustu používá protokol Kerberos.

3.2.6 Group Policy Jedná se o funkci v operačních systémech Windows NT. Tato funkce zabezpečuje vzdálenou centralizovanou správu a konfiguraci počítačů a uživatelů v prostředí Active

26

Directory. Jinými slovy určuje co uživatelé smějí dělat na síti a co ne. Group policy se využívají ve všech možných organizacích (malých, velkých i nadnárodních firmách, úřadech, školách, atd.) za účelem omezit uživatelské aktivity, které představují určité bezpečnostní riziko. Například blokace Task Managera ve Windows, znemožnění kliknutí pravým tlačítkem na plochu, zamezení přístupu k určitým složkám nebo blokace spustitelných souborů, atd. Tato funkce značně snižuje náklady na správu uživatelů, jak lidské zdroje, tak finanční náklady. Mezi objekty, s kterými se dá manipulovat pomocí group policy patří: registry, NTFS zabezpečení, auditové a bezpečnostní policy, příhlašovací a odhlašovací skripty, nastavení Internet Exploreru, přesměrování složek a instalace softwaru. Nastavení skupinové politiky se ukládá do GPO objektů (Group Policy Objects). GPO vnitřně ukazují na GUID (Globallz Unique Identifier), které pak mohou být spojeny s několika doménami nebo organizačními jednotkami (OU). Toto umožňuje, aby byla jakákoliv skupinová politika (GPO), uplatněna na několik (jednotky až tisíce) počítačů nebo uživatelů zároveň. V případě, že na uživatele uplatníme nějakou skupinovou politiku, tak je zapotřebí aktualizovat nastavení místní zásady skupiny a nastavení zásad skupiny uložené ve službě Active Directory, včetně nastavení zabezpečení. Tohle provedeme příkazem gpupdate, který spustíme vzdáleně nebo lokálně na počítači uživatele. Spustíme-li příkaz s parametrem gpupdate /force, gpupdate ignoruje veškerou optimalizaci zpracování a znovu použije všechna nastavení. Parametrem: /target:počítač | uživatel spustí příkaz na vzdáleném počítači. Parametr: /boot po dokončení aktualizace restartuje počítač. Tento postup je vyžadován u těch rozšíření zásad skupiny na straně klienta, která neprovádějí zpracování v průběhu cyklu obnovení na pozadí, provádějí je však při spuštění počítače. Jedná se například o rozšíření Instalace softwaru zásad skupiny. Tato možnost se nijak neprojeví, pokud nejsou volána žádná rozšíření vyžadující restartování počítače. Chceme-li s rebootem, aktualizací GPO nebo s odlogováním počkat, využijeme parametr /wait:60. Za číslo 60 dosadíme libovolný počet sekund, kolik chceme čekat, než se příkaz vykoná. Pro zajímavost uvádím, že pokud nezadáme nic, výchozí hodnota je 600 sekund. Pokud dosadíme zápornou hodnotu -1, budeme čekat nekonečně dlouho. Hodnota 0 začne se zpracováním příkazu okamžitě. Parametr /logoff provede po aktualizaci odhlášení. Tento postup je vyžadován u těch rozšíření zásad skupiny na straně klienta, která neprovádějí zpracování v průběhu cyklu

27

obnovení na pozadí, provádějí je však při přihlášení uživatele. Jedná se například o rozšíření instalace softwaru, zásad skupiny a přesměrování složek. Tato možnost se nijak neprojeví, pokud nejsou volána žádná rozšíření vyžadující odhlášení uživatele. Pro úplnost uvádím příklad syntaxe: gpupdate /target:počítač | uživatel /force /wait:Hodnota /logoff /boot

3.3 Protokol Kerberos Kerberos je síťový autentizační protokol, který umožňuje jednotlivcům komunikovat přes nezabezpečenou síť bezpečným způsobem. S jeho vývojem začal Massachusetts Institute of Technology (MIT). První tři verze byly pouze interní. Verzi 4 představili v roce 1980, Kerberos ve verzi 5 byl vydán v roce 1993, později následovalo ještě několik vylepšení a změn. Operační systémy Windows od firmy Microsoft ve verzi 2000 a vyšší, používají protokol Kerberos jako výchozí autentizační metodu. Tento autentizační protokol využívají také další operační systémy: Mac OS X, Sun Solaris, Red Hat Enterprise Linux 4 a vyšší. Jako šifrovací algoritmus se v Kerberos verzi 5 používá AES (Advanced Encryption Standard). Funguje na principu prokazování identity, že klient je opravdu tím, za koho se vydává. Server i klient si ověřují vzájemně identitu. Rozšíření Kerberosu umožňuje použití veřejného klíče v průběhu některých fází autentizace. Zabezpečení pomocí Kerberos funguje tak, že šifruje data pomocí symetrického klíče. Jen pro informaci uvádím, jak funguje šifrování pomocí symetrického klíče. Použití symetrického klíče vytváří druh autentizace, kdy server i klient se shodne na použití jediného klíče. Používá se při přenosu dat. Při přáci s klíčem jsou detaily zaslány do klíčového distribučního centra (KDC – Key Distribution Center). Nejsou tedy zasílány přímo mezi počítači navzájem. Celý proces zahrnuje osm kroků. Nejprve uživatel zadá uživatelské jméno a heslo na klientském počítači. Klient má společný klíč se službou Kerberos. Tento klíč je odvozen jednosměrnou funkcí od hesla uživatele (hash). 1. krok AS – authentication service (autentizační služba) přijímá žádost klienta a ověřuje, že počítač klienta je tím, za koho se vydává. Toto je řešeno vyhledáním uživatelského jména v databázi. Heslo není zasíláno, pouze hash hesla. Autentizační služba porovná zaslaný hash s vlastní databází (například s Active Directory)

28

2. krok Po ověření vydá autentizační služba (server) časovou známku (timestamp). Do uživatelské relace (session) je vložen momentální čas spolu s datem vypršení. Výchozí hodnota pro vypršení časové známky je osm hodin. Potom je vytvořen klíč sloužící k zašifrování. Jedná se o klíč odvozený z hesla uživatele, hash. Zná ho pouze uživatel a Kerberos. Funkce časové známky je zabezpečit, že po vypršení limitu (výchozí nastavení 8 hodin), je šifrovací klíč nepoužitelný. Toto má zajistit, aby nebylo možné se pokoušet případná zachycená data dešifrovat. Pochopitelně většina klíčů je prolomitelná, ale ne v tak krátké době. 3. krok Klíč je následně odeslán zpět ke klientovi ve formě TGT (Ticket - Granting Ticket). Jedná se o tiket vydaný autentizační službou a používá se pro budoucí autentizaci uživatele. TGT obsahuje informaci o identitě uživatele (jeho IP adresu), časové razítko a je zašifrován klíčem, který zná pouze Kerberos. 4 .krok Klient odešle Ticket – Granting ticket na TGS (Ticket - Granting Server), aby mohlo dojít k autentizaci. 5. krok Ticket - Granting Server vytvoří zašifrovaný klíč s časovou známkou a poskytne klientovi služební tiket. 6. krok Klient dešifruje tiket a sdělí Ticket - Granting Serveru, že ho dešifroval a potom pošle vlastní šifrovaný klíč službě (Service Serveru). 7. krok Služba dešifruje klíč a ujistí se, že časová známka je stále platná. V případě, že je platná, služba kontaktuje KDC, aby přijala relaci, kterou vrátí klientovi. 8. krok Klient dešifruje tiket. Jestliže jsou klíče stále platné, je zahájena komunikace mezi serverem a klientem. Jakmile je navázána komunikace, již neprobíhá přenášení přihlašovacích údajů. Klient je autentizován, dokud nevyprší relace.

29

3.3.1 Nedostatky protokolu Kerberos Zabezpečení pomocí Kerberosu má také své nedostatky a systémoví administrátoři by je měli brát v úvahu. Prvním zřejmým nedostatkem je, že Kerberos vyžaduje vlastní server, který bude vykonávat všechny funkce potřebné pro autentizaci. Jestliže server z nějakého důvodu spadne, nebude se moct nikdo přihlásit do všech systémů vyžadujících autentizaci pomocí Kerberos. Tento „nedostatek“ lze vyřešit přidáním dalších Kerberos serverů a nastavit failover. Takové řešení je ale finančně náročné a každá organizace není do zabezpečení ochotná investovat tolik peněz. Další základní podmínkou musí být synchronizace systémových hodin na všech počítačích a serverech kterých se autentizace týká. Tím, že Kerberos používá časové známky, všechny hodiny na všech systémech musí být synchronizovány s časem na Kerberos serveru. Jako výchozí nastavení je povolená odchylka od času na Kerberos serveru 10 minut. Jestliže dojde ke zvětšení časového rozdílu mezi jednotlivými stanicemi a Kerberos serverem, dojde k selhání a uživatelé nebudou autentizováni. I tomuto problému se dá předejít tak, že budeme pravidelně kontrolovat nastavení hodin nebo použijeme NTP (Network Time Protocol) protokol pro synchronizaci času na síti.

30

4. Bezpečnostní rizika 4.1 Social engineering Jedná se o metodu, kterou se hacker snaží vyzjistit od uživatelů nebo technických pracovníků informace, které by mu mohly pomoci k proniknutí do systému. Na lidi působí milým a sebevědomým dojmem a snaží se je vmanipulovat do situace aby mu pomohli, případně něco prozradili. V zásadě je několik způsobů, jak takovýto útočník postupuje.

4.1.1 Přímý postup Může postupovat přímo, to znamená, že se svým požadavkem jde rovnou na věc. Například se nečekaně zeptá recepční na uživatelské jméno a heslo, k tomuto požadavku přidá na vysvětlenou jednoduchý důvod. Někteří lidé bez přemýšlení nebo po krátké úvaze tyto informace opravdu sdělí.

4.1.2 Žádost o technickou podporu Další způsob je ten, že to útočník zkouší přímo na technické pracovníky firmy. Předstírá, že je někdo z vedení firmy a má urgentní problém. Pracovník technické podpory rád pomůže a útočník tak má velkou šanci se dozvědět co potřebuje. Může tak učinit osobně nebo například zatelefonuje na Helpdesk, kde požaduje informace o konfiguraci VPN, vydání certifikátu, reset doménového nebo emailového hesla, atd. Jestliže je útočník znalý prostředí, je nejjednodušší směrovat svůj útok přes Callcentrum, protože ve velkých firmách s mezinárodní technickou podporou je velmi stížená identifikace volajícího.

4.1.3 Předstírání pracovníka Další fintou útočníka může být předstírání nešikovného a bezmocného pracovníka. Například předstírá, že se nemůže dostat do počítače nebo potřebuje odeslat důležitý email a zapomněl heslo. Najde-li se někdo ochotný, kdo pomůže útočníkovi, snadno se stane, že útočník získá jeho heslo. Buď útočníka přihlásí do sítě pod svým uživatelským jménem nebo si útočník připraví logovací obrazovku, ze které bude odchytávat úhozy, takže ho sice ochotný zaměstnanec napoprvé do sítě nepřihlásí, ale útočník už bude znát jeho uživatelské jméno a heslo.

31

4.1.4 Předstírání technické podpory Nejjednodušší způsob, jak vymámit z uživatelů jejich přihlašovací údaje, je vydávat se za pracovníka technické podpory. Zkrátka si vyhlédnout uživatele, kterému útočník zatelefonuje a představí se jako pracovník technické podpory a požádá ho o sdělení přihlašovacích údajů, ať už pro kontrolu, nebo z důvodu instalace nové aplikace či provedení nějaké jiné technické změny. Já osobně pracuji již 3 roky jako technická podpora koncových uživatelů v jedné logistické firmě. Z vlastní zkušenosti mohu říct, že 90% uživatelů sdělí osobě, která se představí jako technická podpora své přihlašovací údaje a hesla do všech aplikací které uživatel zná. Se 4/10ti uživatelů by jistě ani nebyl problém se domluvit na zaslání VPN certifikátu na jakoukoliv emailovou adresu tvářící se alespoň trochu důvěryhodně. Další metodu, kterou útočník může zvolit je, že naaranžuje události tak, aby se sama osoba na něj obrátila s žádostí o pomoc. Například pošle email s tím, že dojde k výměně bezpečnostních certifikátů do VPN, aby tedy osoba poslala svůj certifikát a obratem ji bude na emailovou adresu doručen nový.

4.1.5 Phishing Pro maximální důvěryhodnost není problém zfalšovat emailovou hlavičku a email se bude tvářit jako od pracovníka technické podpory. Poslat takovýto zfalšovaný email je velice snadné, existuje k tomu řada aplikací nebo ho útočník může poslat manuálně sám. Stačí si zjistit SMTP server, který podporuje anonymní přístup. SMTP server se zjistí pomocí standardního nástroje nslookup pro zjišťování informací o name serverech. Stačí spustit příkazovou řádku a napsat: nslookup set type=mx (tímto určíme že chceme vyhledat na zadané doméně, mail exchanger) inbox.lv (doména na které chceme vyhledat mail exchanger) jako odpověď se nám zobrazí seznam SMTP serverů Celá komunikace se serverem vypadá v příkazové řádce následovně: set type=mx inbox.lv Neautorizovana odpoved: inbox.lv

MX preference = 1, mail exchanger = b.mx.inbox.lv

32

Inbox lv je freemailový server, se dvěma mail exchangery. V dnešní době jsou téměř všechny freemailové servery zabezpečené proti anonymnímu odesílání. Občas se může stát, že někdo nebo něco blokaci open relay vypne, jako se to stalo jednou na Seznam.cz, potom může kdokoliv posílat falešné emaily. Aby mohl útočník úspěšně odeslat email, musí si vyhlédnout open relay SMTP server. Takovýto SMTP server umožní komukoliv odeslat emailovou zprávu, aniž by se dotyčný musel nějak autentizovat. Těchto serverů již není moc, navíc pokud se mu nějaký takový povede najít, tak cílový server, pakliže si ověří že server podporuje open relay, nemusí email vůbec přijmout. Útočník tedy vše vyřeší tak, že si zprovozní svůj vlastní SMTO server, kde si může odesílat, co chce. Takovýto virtuální SMTP server si vytvoří buď pomocí aplikací volně přístupných na internetu, nebo si do Windows doinstaluje Internetové Informační Služby. V položce Nástroje pro správu pak přibude položka Internetová Informační Služba. Po rozkliknutí už vidíme nastavení virtuálního SMTP serveru, který si upravíme dle vlastních potřeb. Dalším řešením je využít nezabezpečenou mailovou gateway nějaké firmy. Tyto gatewaye bývají často nezabezpečené pro přístup zevnitř. V případě, že útočník nemá přístup do vnitřní sítě firmy, je mu to k ničemu.

4.1.6 Odesílání emailu Samotné manuální odesílání emailu pomocí SMTP serveru vypadá následovně. Aplikace nebo webový klient pochopitelně pracuje se stejnými příkazy a parametry.

Obrázek č. 4: Manuální odesílání emailu telnetem

33

telnet domena.xx 25 (SMTP servery naslouchají na portu 25) ehlo / helo cokoliv.xx (tímto se SMTP serveru představíme jako doména, pro důvěryhodnost napíšeme cílový server) mail from: [email protected] (zde uvádíme jméno odesilatele, může být i fiktivní) rcpt to: [email protected] (zde uvádíme adresu na kterou má být email doručen) data (datová část emailu obsažená v hlavičce) from: [email protected] (zfalšovaná emailová hlavička, když dá adresát v emailovém klientu odpovědět, tak na tuto adresu přijde odpověď) to: [email protected] subject: cokoliv (v emailové hlavičce nebo v emailovém klientu se nám zobrazí jako předmět) received: xxx.xxx.xxx.xxx (napíšeme cizí ip adresu odesilatele pro větší důvěryhodnost a stíženou identifikaci) x-header: xxx.xxx.xxx.xxx

Obrázek č. 5: Webmail Seznam.cz, přijatý email

34

Nyní píšeme text emailu, text a celé psaní emailu ukončíme zvláštním ukončovacím znakem, kterým je (.) tečka na samostatném řádku a dvakrát odentrujeme. V tu chvíli se odešle celý email. Podotýkám, že anonymita je jen zdánlivá, protože pochopitelně na cílovém serveru jsou logy se záznamem o komunikaci se SMTP serverem, z kterého byl email odeslán. Což je buď přímo útočníkův počítač, nebo cizí SMTP server, kam se připojil a kde se s největší pravděpodobností opět nachází záznam o komunikaci. Útočník je tedy anonymní pouze před uživatelem, nikoliv před úřady. Na mysli mám úřady ve vyspělých zemích. Pokud bude útočník operovat ze zemí třetího světa, je opravdu anonymní a prakticky nedohledatelný.

Obrázek č. 6: Webmail Seznam.cz – hlavička podvrženého emailu

4.2 Enumerace K proniknutí do systémů firmy nestačí jen vylákat z uživatelů pár hesel. Je to daleko komplexnější práce vyžadující technické zázemí a znalosti IT prostředí firmy. Útočník nejprve provede Enumeraci. To znamená, nejprve zjistit, jaké servery se v organizaci 35

nachází, jejich adresy, jaký operační systém na nich běží. Zjistit přibližný počet uživatelů, jejich jména, zjistit, jak jsou tvořeny emailové adresy a uživatelské účty. Pak až se rozhodne, jakým způsobem útok provede. Správa informačních systémů ve velké organizaci je nesmírně náročnou prací a také náchylnou na chybu nebo opomenutí administrátorů. Informační systémy spravují a užívají lidé a každý dříve nebo později udělá nějakou chybu. Útočník často hřeší na takovéto chybky nebo opomenutí. Například se stává, že administrátor zapomene změnit výchozí heslo na routeru, v operačním systému, atd. Seznam těchto výchozích hesel je volně dostupný na internetu http://www.phenoelit.de/dpl/dpl.html.

4.3 Chyby uživatelů Ve velkých organizacích je obtížné uhlídat veškerá bezpečnostní opatření. Častým nešvarem bývá, že jeden uživatelský účet používá více uživatelů, ne-li celé oddělení, přihlašovací údaje jsou tak veřejným tajemstvím. Mezi další časté nešvary patří tvorba elektronického nebo psaného seznamu hesel a uživatelských jmen. Tvorba takovýchto seznamů není ničím neobvyklým také u správců informačních systémů. Například Helpdesk (první administrátorská linie) vytváří uživatelské účty a resetuje hesla do většiny informačních systémů používaných v organizaci. I zde tedy bývá takový seznam super userů nebo administrátorských přihlašovacích údajů. Trendem ve správě IS je, aby se tento seznam hesel neustále ztenčoval. Dosahuje se toho tím, že se do informačního systému přidá každý jednotlivý pracovník (super user nebo běžný uživatel) a nastaví se mu práva. Aby si správci nemuseli pamatovat desítky hesel, použije se autentizace pomocí LDAP nebo AD. Tímto se dá i snadno zjistit, kdo a kdy prováděl změny. Velkým problémem, o kterém jsem se nedávno sám přesvědčil je resetování hesla a jeho sdělení telefonicky. Hesla do různých informačních systémů není problém poslat emailem. Co když ale uživatel heslo do emailu nebo doménové heslo zapomene. Nezbývá než zavolat technickou podporu, aby ho resetovali. Kvůli bezpečnosti jsou tato hesla komplexní a složitá na zapamatování a občas i špatně telefonicky interpretovatelná. Dochází pak k tomu, že heslo je hláskováno nebo odříkáváno dokola administrátorem a zpětně pak uživatelem. To sice vede k tomu, že si heslo uživatel nacvičí a snadno zapamatuje, ale může také uvíznout v paměti někoho v okruhu obou volajících a ten ho následně zneužije.

36

4.4 Autentizace Pod pojmem autentizace se skrývá proces ověření identity uživatele. V dnešní době se setkáváme u většiny informačních systémů s jednofaktorovou autentizací, tedy že uživatel musí mít pouze znalosti. Musí znát svoje přihlašovací jméno (username, UID, emailová adresa) a heslo. V podstatě máme tři možnosti, jak provést autentizaci do systému. •

Znalost – uživatel se musí prokázat nějakou znalostí, kterou by měl vědět pouze on, většinou heslo nebo PIN.

•

Vlastnictví – úspěšně se může autentizovat pouze ten, kdo vlastní nějaký předmět potřebný pro autentizaci (čipová karta, usb token nebo autentizační kalkulátor).

•

Biometrika – jedná se o měření biometrických vlastností uživatele, běžných podmínkách se jedná o otisk prstu nebo měření geometrie ruky nebo rozpoznávání řeči. Méně často se setkáváme s finančně nákladnými zařízeními na skenování oční sítnice, tvaru obličeje nebo dokonce testování DNA.

4.4.1 Autentizace heslem Autentizace pomocí znalosti hesla s sebou přináší řadu nevýhod a bezpečnostních rizik. Uživatelé často volí hesla typu: jméno oblíbeného fotbalového klubu, jméno dětí a manželky nebo jméno domácího mazlíčka. S bezpečností hesla na tom nejsme o moc lépe, když naše heslo obsahuje nebo je nějaké obyčejné slovo, například: Zima2009, Leden2009, jezevec, Smichov, atd. Když bude chtít někdo prolomit takové slovní heslo, použije k tomu slovníkový útok. Útočník si pořídí slovník se 30 000 slovy a aplikace bude zkoušet jedno heslo po druhém, prohazovat čísla a písmena u slov. To je daleko rychlejší, než zkoušet jednotlivé kombinace, když uvážíme že například u sedmi znakového hesla bychom museli vyzkoušet 3521 (62 miliard kombinací když beru v úvahu znaky a-z, 0-9 a všechny velká písmena. Heslo se dá také velice snadno odpozorovat, když ho uživatel zadává na klávesnici, ať už pouhým okem (zejména u toho kdo píše pomalu a nepíše všemi prsty) nebo v dnešní době pokročilých technologií nějakou miniaturní kamerou. Dalším problémem je odchytávání hesel přímo z klávesnice, když mají k počítači přístup i jiné osoby nebo je počítač špatně zabezpečen, chybí nebo není nastaven firewall nebo antivirový program. Není problém si takový program stáhnout. Stačí na google zadat do vyhledávání slovo Key Logger.

37

Obrázek č. 7: Windows 2000 – nastavení Smart card

Ve většině systémů je funkce, aby administrátor nastavil povinné vlastnosti hesla. Aby bylo heslo opravdu bezpečné, mělo by mít 14 znaků a nemělo by to být smysluplné známé slovo, ideálně kombinace písmen a číslic, jeli to možné tak přidat i zvláštní znak. Takovéto heslo by si asi nikdo nepamatoval, proto se ve většině systémů nastavuje minimální požadavek na heslo osm znaků. Mezi další požadavky na komplexnost hesla se většinou stanovuje povinnost obsahovat alespoň jedno velké písmeno a minimálně tři číslice. Takové heslo je schopna si zapamatovat většina uživatelů. Lze také nastavit, že pokud uživatel zadá třeba třikrát špatné heslo, účet se automaticky zamkne a jedině administrátor systému ho může odblokovat. Jestliže autentizace probíhá přes Active Directory, lze to bezproblému nastavit tam.

4.4.2 Autentizace pomocí předmětu Autentizace pomocí vlastnictví nějakého předmětu vyžaduje přítomnost (připojení nebo přiložení) čipové karty, autentizačního kalkulátoru nebo USB tokenu s privátním klíčem a certifikátem. Autentizace pomocí autentizačního kalkulátoru probíhá tak, že uživatel zadá heslo nebo pin a kalkulátor vygeneruje jednorázové přístupové heslo které je se s každým přístupem mění. Čipová karta nebo USB token je ještě chráněn heslem aby neodšlo ke zneužití při krádeži nebo ztrátě. Uživatel, pokud se chce zalogovat ať už do počítače nebo nějakého informačního systému, neustále potřebuje mít tuto kartu nebo USBtoken vložený ve čtečce. Jsou li bezpečnostní prvky správně nastavené, mělo by dojít okamžitě po vytažení z počítače nebo čtečky k uzamknutí počítače nebo k odlogování z informačního systému. Tato technologie byla představena již v operačním systému Windows 2000. Pro zajímavost ještě doplním, že digitální ID na USB tokenu nebo čipové kartě zabírá okolo 3KB. Dnes jsou k dostání čipové karty a USB tokeny o velikosti 32KB

38

4.4.3 Autentizace biometrikou Co se týká využití biometriky za účelem autentizace uživatelů, tak tato metoda se dnes v praxi moc nepoužívá. Zejména kvůli finanční náročnosti snímacích přístrojů. Zařízení pro snímání otisku prstu má dnes kdejaký notebook, ovšem kvalita tohoto zařízení je vzhledem k ceně notebooku velice pochybná. Navíc snímání a následné vyhodnocení biometrických údajů je daleko složitější než porovnání hesel. Jde li o kvalitní přístroj a jsou správně nastaveny znaky otisku, uživatel musí otisk zadávat několikrát. Celá autentizace se tak nepříjemně protáhne.

39

5. Správa pracovních stanic Pro zajímavost přiblížím, jak vypadá správa pracovních stanic v organizaci o tisíci stanicích. V dnešní době, se jako operační systém na běžných pracovních stanicích, používá operační systém Windows 2000/XP/Vista. Pro organizaci o tisíci počítačích by jednotlivá instalace operačního systému z CD nebo DVD, jako to děláme doma, případně přeinstalace počítače, z důvodu poruchy nebo výměny harddisku, znamenala značné náklady na technický personál a zbytečnou ztrátu času. Dnešním trendem je, instalovat počítače po síti. Lépe řečeno, rozbalit na disk obraz harddisku. Za tímto účelem je potřeba mít sjednocen hardware v počítačích. Protože operační systém neinstalujeme, ale kopírujeme ho z obrazu disku už předinstalovaný, v případě, že bychom měli například základní desky od několika výrobců, navíc ještě jiné modely, operační systém by pak nemusel správně nabíhat. Zkrátka ve velkých organizacích je nutné mít sjednocený hardware i podle modelů komponentů.

5.1 Vzdálená správa Komerční službu vzdálené instalace neboli reimagingu harddisku nabízí několik firem. Například Microsoft se svým Remote Installation Services. Jedná se o server běžící na operačním systému Windows 2000/2003 server, pomocí kterého se instalují vzdáleně další počítače. Firma Symantec nabízí vlastní řešení Norton Ghost, aktuálně ve verzi 14. Špičkou na trhu je firma Altiris se svým řešením Altiris Deployment Solution. Tuto firmu nedávno koupila firma Symantec. Altiris Deployment Solution se používá k hromadné instalaci nových počítačů, k přechodu na nové softwarové verze, dodatečné instalace softwaru, ke správě počítačů přes vzdálenou plochu, atd. Instaluje se přes jednoduché a intuitivní grafické rozhraní Altiris Console, která se z Altiris Serveru spouští jako tenký klient v Internet Exploreru. Altiris Server využívá v případě hromadné instalace multicast, aby nedocházelo k nežádoucímu zatěžování sítě. Všechny výše zmiňované funkce Altirisu mohou být použity jako samostatné aplikace.

5.2 Instalace aplikací a OS Nahrávání operačního systému do počítače vypadá následovně. Na jeden počítač se nainstaluje operační systém a sada běžně používaných aplikací jako je Microsoft Office,

40

alternativní webový prohlížeč, antiviru, program pro práci s archivy, FTP klient, atd. Tyto aplikace se alespoň částečně nakonfigurují, například se nastaví antiviru aktualizační server, jedná-li se například o instalaci pro Callcentrum, nastaví se aplikace komunikující s IP telefonem, atd. Po veškerém nastavení se obsah pevného disku zazálohuje. Vytvoří se image disku. Z tohoto obrazu disku se pak imagují nebo reimagují počítače bez operačního systému nebo s nefunkčním OS. Proces kopírování obrazu disku na cílový počítač vypadá následovně. Počítač, na který se bude kopírovat, musí být připojen k síti a jeho síťový adaptér a základní deska musí umět funkce „boot on lan“ a „wake on lan“. Čipová sada musí podporovat prostředí PXE (Preboot eXecutin Environment), jedná se o technologii podporovanou firmou Intel. Prostředí PXE využívá hned několik protokolů: Internet Protocol (IP), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP) a Trivial File Transfer Protocol (TFTP). Protokol DHCP využívá k lokalizaci dostupných Boot serverů. PXE vyšle DHCPDISCOVER paket, který je specifický pouze pro PXE, to znamená, že na něj neodpovídají běžné DHCP servery v síti. Tento paket je odeslán na port 67/UDP, na kterém běžně naslouchají DHCP servery. Pakliže firmware (BIOS) obdrží DHCPOFFER, sám se nakonfiguruje podle obdržené konfigurace. Pomocí protokolu TFTP stáhne inicializační bootstrap a realizuje další datový přenos. Aby mohl být zahájen přenos dat z PXE Boot Serveru, musí mít firmware přidělenou IP adresu

a nakonfigurován z DHCPOFFER paketu. Nyní, po zjištění

správného Boot Serveru, firmware odešle paket DHCPREQUEST (opět rozšířený o PXE specifika). Pakliže server obdrží tento paket a konfigurace vyhovuje, odešle klientovi rozšířený DHCPACK, což je potvrzovací paket, který obsahuje cestu k NBP (Network Bootstrap Program). NBP se nahraje do operační paměti (RAM) a je spuštěn, dále je provedeno nahrání obrazu disku na cílový počítač. Výše popsanou technologii PXE používá Altiris Deployment Solution, pro počítače, jenž nepodporují PXE slouží Bootworks.

5.2.1 Nastavení počítače po instalaci OS Po nabootování počítače s novým operačním systémem čekají administrátora ještě další důležité kroky. Jako první musí nastavit síťové jméno počítače. Zatímco doma si pojmenováváme počítače podle svého jména nebo místnosti, kde se počítač nachází, pojmenovávání počítačů ve velkých organizací má svou hlubší logiku. Jedná-li se o mezinárodní firmu, obsahují většinou kód země, lokaci (město nebo část města), jaký

41

operační systém na nich běží a jestli se jedná o stolní počítač nebo notebook, případně další popisné informace. Na konec názvu se připojuje číselný identifikační kód. Název počítače může vypadat následovně CZPRGWN00001. Nyní je už počítač připraven k užívání. Jeho další správa je prováděna přes správu vzdálené plochy. Tuto službu opět poskytuje Altiris, Dameware nebo lze použít integrovanou službu Remote Desktop přímo ve Windows. Správa přes vzdálenou plochu se používá většinou při nějakém řešení problému u uživatele. První linie uživatelské podpory tuto službu využívají v jednotlivých případech k instalaci nového software nebo hardware. Altiris Deployment Solution je ve verzi jak pro klienty tak servery a zvládne instalovat operační systémy Windows, Linux, MAC OS. Výčet některých funkcí Deployment Serveru: •

Vlastní nástroj pro vytvoření image a jeho distribuci

•

Tvorba bootovacích profilů (DOS, FreeDos, Linux)

•

Tvorba univerzálního image

•

Editor .MSI a .EXE balíčků

•

Image editor

•

Tvorba samorozbalovacího image – (.EXE na DVD)

•

PC Transplant - balíček pro migraci profilu a instalovaného prostředí uživatele

•

Vytvoření PXE server(ů) instalace a vytvoření infrastruktry

•

Možnost spouštění skriptu (.bat,.cmd, .scr, .vbs)

•

Remote control – převzetí plochy uživatelského počítače

•

Chat s uživatelem

5.2.2 Patchování serverů Informační systémy ve velkých organizacích jsou hostovány na serveru s různým operačním systémem. Stejně jako je potřeba updatovat operační systém pracovních stanic, tak se instalují i bezpečnostní patche a updaty na servery. S restartem serveru by pochopitelně došlo k výpadku informačních systémů, které běží na serveru. Je proto žádoucí, aby takových restartů za účelem updatu operačního systému bylo co nejméně a pokud budou nutné, naplánovat je tak, aby neomezovaly uživatele v práci. Z tohoto důvodu je vhodné naplánovat tuto údržbu serverů na mimopracovní dobu. Jestliže uživatelé informačního systému končí v pátek v 18:00 a o víkendu nepracují, ideální je začít hned v pátek večer. Kdyby nastaly neočekávané komplikace, ať je celý víkend na případné 42

odstranění následků, obnovu dat a uvedení serveru do provozu. Komerční produkt Patch Management Solution pro klienty nebo servery od firmy Altiris slouží k řízené a automatizované aplikaci patchů operačních systémů Microsoft a některých linuxových distribucí. Generuje přehledné reporty o verzích a také sleduje úspěšnost instalace těchto záplat (patchů) a updatů. Patchování probíhá tak, že vybereme dostupné updaty a security patche a označíme servery které chceme patchovat. Celá tato operace zabere jen několik málo kliknutí myší. V případě security patchů se servery jeden po druhém samy rebootují. Jistě nás napadne, co když nainstalovaný patch způsobí, že poškodí operační systém a server nepoběží nebo nově nainstalovaný patch na klientských stanicích smaže nebo modifikuje z registrů například nastavení Citrix Metaframe Konsole a uživatelé se pak nedostanou do informačních systémů potřebných pro jejich práci.

Obrázek č. 8: Altiris software updates, přehled instalovaných patchů

K této situaci by nemělo dojít, protože všechny dostupné patche pro Patch Management Solution by měly být nejprve otestovány firmou Symantec Altiris. Jedná se o garantované funkční patche. Pochopitelně nelze tyto patche dokonale odzkoušet na všech možných hardwarových a softwarových konfiguracích. Viz příklad, který uvádím níže, že po instalaci security patche, uživatelům nefungovalo spouštění aplikací přes Citrix Metaframe Presentation se stal minulý rok ve firmě, kde pracuji. Došlo k tomu, že se na počítače nainstaloval nový security patch, který tento výpadek způsobil. Přišlo se na to, že problém

43

vznikl jen na několika počítačích a lze ho vyřešit přemapováním síťových tiskáren. Jelikož to byl řešitelný problém malého rozsahu, stačilo počkat na opravný patch od Microsoftu.

5.2.3 Software Delivery Solution pro Klienty a Servery Dalším produktem, který stojí za zmínku je Software Delivery Solution. Představme si, že z důvodu spuštění dalšího informačního systému ve firmě, je potřeba na pracovní stanice přidat knihovny, nainstalovat novou verzi Flash Playeru nebo Javy. I samotné rozšíření, mnohdy již zaběhnutého informačního systému, často vyžaduje doinstalování nové verze nějaké aplikace třetí strany. Ve velkých organizacích celkem běžná praxe. Uživatelé si tyto aplikace sami instalovat nemohou, protože nemají na svých počítačích práva nic instalovat a zapisovat do registrů. Jednak kvůli bezpečnostním rizikům spojeným se svévolnou instalací čehokoliv a také kvůli sjednocení verzí aplikací. Zkrátka, aby celá firma používala jednu verzi aplikace a zamezila se tak nekompatibilita mezi soubory vytvořenými ve vyšších verzích. Software Delivery Solution je nástrojem pro hromadnou, lokální i vzdálenou instalaci aplikací a instalačních balíčku (mají příponu .msi). Masová instalace není opět nic složitého, během několika kliknutí nainstalujeme nebo nakopírujeme na skupiny počítačů požadovaný software. Obrovskou výhodou je, že administrátor je informován o průběhu instalace a vidí na kterých počítačích se instalace z jakéhokoliv důvodu nezdařila. Administrátor také vidí, zdali je nainstalovaná aplikace funkční. Instalace probíhá na pozadí a neruší uživatele při práci, ani nehrozí, že by uživatel instalaci stornoval nebo nějak do ní zasahoval. Distribuovat můžeme hned několik aplikací v řadě, nemusí to být jen jedna. Toto není možné pomocí skriptované instalace doménovou politikou, kde se často stává, že uživatel instalaci přeruší nebo z jiného důvodu neproběhne a administrátor se to ani nedozví. Velké organizace mají pochopitelně dostatek peněz na kvalitní řešení od Altirisu. Jako zajímavost bych chtěl zmínit pracnější, ale komerčně úsporné řešení, vhodné spíše pro menší organizace nebo doplněk pro 1st level podporu na Helpdesku. Jedná se o utilitu s názvem PsExec, aktuálně ve verzi 1.94, která slouží ke spouštění aplikací na vzdálených počítačích. Výhodou je, že na vzdálené systémy nemusíme instalovat žádný klientský software jako je tomu u většiny RDP aplikací.

44

5.3 Vzdálené spouštění procesů PsExec spustí na vzdáleném systému interaktivní příkazovou řádku, ve které například proběhne námi naprogramovaný skript. Samozřejmě se dají spouštět libovolné aplikace. Dokonce i umožňuje spouštět aplikace z vlastního počítače na vzdáleném systému. K tomu, abychom mohli aplikace nebo skripty vzdáleně spouštět, potřebujeme mít práva pro přístup ke vzdálenému systému. V prostředí Windows tedy potřebujeme na vzdáleném systému lokální účet s administrátorskými právy. Já osobně tuto aplikaci využívám při řešení jednoduchých mnou vytvořených skriptů. Některé aplikace, jako třeba HP Openview Servicedesk, Citrix Metaframe Presentation nebo Cisco VPN klient si vytvářejí adresáře, kam si odkládají dočasná data, konfigurační soubory nebo, jako je tomu v případě Cisco VPN klienta, informace o certifikátech. Často se stává, že při abnormálním ukončení aplikace se dočasná data nesmažou, konfigurační soubory špatně uloží a to má za následek totální nefunkčnost celé aplikace a uživatel tak nemůže nahlížet do informačních systémů a aplikací potřebných k práci.

5.3.1 Spouštění procesů V případě Cisco VPN klienta se tomu děje při reimportu certifikátu, zůstávají tam uloženy informace o starém certifikátu, který již na počítači není přítomen. Skripty, které jsem vytvořil, slouží k promazání těchto souborů, případně k vytvoření nového konfiguračního souboru. Skripty se spouští z klasických dávkových souborů s příponou *.bat, za použití příkazů DOSu a miniaplikací, které jsou součástí příkazové řádky ve Windows XP/Vista. Některé miniaplikace nejsou součástí OS nebo balíčku PsExec, musíme si je nakopírovat do pracovního adresáře a jsou to aplikace sloužící například k přesměrování práv. Vysvětlím níže. Vytvoříme si spouštěcí soubor s názvem Sdel_rem.bat. Moje vysvětlivky ke každé řádce dávkového souboru jsou odděleny lomítkem („/“). Spouštěcí neboli přihlašovací dávkový soubor se spouští se dvěma parametry (například Sdel_rem.bat CZPRGD1234 jdrabek) a má následující složení: REM %1 Zadej nazev pocitace / jedná se o vysvětlení prvního parametru, se kterým je nutno dávku spouštět. Tento první parametr je název počítače, na který se chceme připojit. Příkaz REM se používá ke vkládání komentářů, text za ním se nebere jako příkazy. REM %2 Zadej jmeno uzivatele / vysvětlivka k parametru 2, kde zadáme jméno uživatele, na jehož počítač se budeme připojovat, tento parametr potřebujeme z důvodu, že některé 45

aplikace si dočasné soubory ukládají do profilu uživatele (C:\Documents and Settings\jdrabek\Application Data\Hewlett-Packard\OpenView\Service Desk\cache) start /wait psexec -i \\%1 -u %1\localadmin -p Admin123 -c sdelete.bat %2 Spustí v nové instanci miniaplikaci PsExec a počká na dokončení, pak se okno zavře. PsExec se připojí vzdáleně k námi zadanému počítači s právy lokálního admina a pod zadaným uživatelem spusí další námi vytvořený soubor sdelete.bat který obsahuje sérii delete příkazů na promazání odkládacího adresáře aplikace Service Desk. Takto jednoduše vypadá první soubor. Druhý soubor s názvem sdel.bat, který musí být uložen ve stejném adresáři, obsahuje v podstatě jen souborové a adresářové operace. del “C:\Documents and Settings\jdrabek\Application Data\Hewlett-Packard\OpenView\ Service Desk\cache\*.*“ Výše uvedený příkaz smaže všechny soubory v adresáři. A to je celé, stačí jen pár řádek dávkového souboru a na vzdáleném systému můžeme provést téměř jakoukoliv souborovou operaci. V dávce, sloužící pro souborové operace, můžeme snadno vytvořit i nový konfigurační soubor, který využívají informační systémy, které nepoužívají tenkého klienta. Uvedu malý příklad, chceme vytvořit konfigurační soubor Citrix Metaframe presentation. Řádek po řádku naplníme soubor pn.ini. echo [Program Neighborhood] > "c:\documents and settings\%1\Application Data\ ICAClient\pn.ini" echo TransportDriver=TCP/IP >> "c:\documents and settings\%1\Application Data\ ICAClient\pn.ini" echo SSLEnable=Off >> "c:\documents and settings\%1\Application Data\ICAClient\ pn.ini" echo SSLProxyHost=*:443 >> "c:\documents and settings\%1\Application Data\ ICAClient\pn.ini" atd. Příkaz echo vypisuje na obrazovku text uvedený za ním, což je pak v pořadí, v jakém jdou jednotlivé echo příkazy, následně uloženo do souboru pn.ini. Pakliže potřebujeme pracovat s registry, musíme do prního spouštěcího souboru (v tomto případě je to sdel_rem.bat) zadat, aby se nám přidala oprávnění lokálního administrátora pro práci s registry. Provedeme to pomocí nástroje SetACL (set access control list). SetACL slouží pro práci 46

s oprávněními ve Wndows NT, přesněji řečeno s tak zvanými SD (Security Descriptors – Bezpečnostní popisovač). Každý objekt ve Windows, který může mít SD je zabezpečitelný objekt. Popravdě řečeno, nevím ani o žádném programu s grafickým uživatelským rozhraním, který by umožňoval manipulaci se všemi SD. Oprávnění ve Windows 2000, XP, Vista můžeme nastavovat u objektů: soubory systému NTFS, klíče v registrech, objekty z Active Directory, tiskárny, služby, síťové disky, procesy. Uvedu malý příklad za využití aplikace PsExec pro vzdálené spouštění aplikací, jestliže setacl spouštíme na vzdáleném systému pro úpravu registru. start /wait psexec -i \\%1 -u %1\localadmin -p Admin123 -c setacl -on "HKEY_LOCAL_MACHINE\software\microsoft\" -ot reg -actn ace -ace "n:%1\everyone;p:full"

Výše uvedený příklad poskytne plné (read, write, delete, change) oprávnění do specifikovaného úlu registru, komukoliv na počítači určeném parametrem %1. SetACL.exe -on "C:\Program Files" -ot file -actn ace -ace "n:prg-dc\jdrabek;p:full"

Výše uvedený příklad se spouští lokálně z příkazové řádky a přiřadí uživateli jdrabek všechna oprávnění pro adresář Program Files.

47

6. Monitoring serverů Jestliže požadujeme od informačních systémů dostupnost 99,999% roku, musíme hlídat servery a celou IT infrastrukturu, na které informační systém běží. Nemůžeme čekat, než server spadne nebo dojde místo na diskovém poli. Těmto problémům musíme předcházet. K tomuto účelu nám slouží monitorovací systémy serverů. Jedním z produktů, který je určen k monitorování serverů je HP Open View Operations. Tento systém od firmy Hewlett-Packard používá k monitorování takzvaných agentů a podporuje následující platformy: Unix (AIX, HP-UX, Solaris, TRU64 UNIX), Microsoft Windows, Linux (Red Hat, SuSE, Turbo Linux, Debian), AS400, Open VMS, Novell Netware.

6.1 HP OVO Monitoring OVO Monitroring je určen jak pro monitorování serverů, tak aplikací. S hardwarem komunikuje pomocí SNMP protokolu (Simple Network Management Protocol). Tento monitorovací systém má aktivní softwarovou komponentu, které se říká agent. Ta musí být nainstalována na každém serveru, který má být monitorován. Jestliže agent vyhodnotí nějakou událost za chybu, odešle report na centrální server, tzv. Management Server. Agenti, krom monitorování, poskytují také automatizované podpůrné funkce. Jednou z těchto funkcí je například integrace do HP Open View Service Desk nebo Remedy Action Request System. Dojde-li na nějakému serveru například k tomu, že procesor je po dobu 20ti minut zatěžován na 100%, je-li to tak nastaveno, OVO Monitoring vytvoří Event v aplikaci Service Desk s přednastavenou prioritou pro tento případ. Event potom pošle na příslušnou skupinu. Je-li to požadováno, zašle emailovou notifikaci nebo SMS vlastníkovi serveru nebo vlastníkovi služby, kterou server poskytuje. Způsobů, jak OVO monitoruje, je několik. Prochází logy serverů a hledá v nich mimořádné události nebo chyby, spouští naplánované akce v předem určené době a reaguje podle toho, jestli akce selhala nebo byla provedena úspěšně. Zjišťuje také, jestli na serveru běží správné procesy ve správném počtu. Kontrola síťové konektivity k serveru je samozřejmostí. V OVO Monitoringu je již základní přednastavený set monitorovacích testů, stejně tak si správci mohou vytvářet vlastní nebo uzpůsobovat již existující. Všechny události jsou asociovány s OVO zprávou a odesílají se na Management Server. Administrátoři nebo operátoři se potom logují do OVa přes java konzoli. Každý

48

z operátorů může vykonávat svou specifickou funkci. Podle toho, jak má nastaveny filtry, vidí svůj základní pohled. Pakliže operátor vidí nějakou podezřelou událost, na kterou nebyl automaticky vygenerován Event v Open View Service Desk nebo Remedy, může ho za pomoci pár kliknutí vyrobit. Ještě pro zajímavost uvádím, že v roce 2007 došlo k přejmenování tohoto produktu na pouhé HP Operations. Ve všech déle fungujících firmách se tento produkt ale stále používá pod názvem HP Open View Operations.

6.2 Lights Out Management Představme si situaci, kdy OVO Monitoring vytvoří Event, že server s IP adresou 77.77.77.77 neodpovídá na příkaz ping a přitom na síti není žádný výpadek. Nebo situaci, kdy spadne víc důležitých procesů najednou a administrátor se nemůže k serveru připojit pomocí vzdálené plochy. Ani velké firmy v dnešní době nemají v datacentrech přítomnou podporu na všechny servery. Nebo může být server mimo datacentrum na nějaké pobočce firmy a momentálně k němu není fyzický přistup. Administrátoři v nočních hodinách pracují z domova, takže nemají k serverům fyzický přístup. Od toho je tu řešení Lights Out Management. Součástí tohoto řešení je hardwarová komponenta, takzvaný LOM modul a aplikace, která monitoruje fyzický chod serveru (teplota, zátěž, využití paměti, atd.). Aplikace za pomoci hardwarového modulu umožňuje provádět reboot serveru, vypnutí serveru, nastavení různých alarmů, umožňuje nastavení rychosti větráků a reinstalaci operačního systému.

6.2.1 Výstupy z LOM Výstupy z LOMu bývají odesílány do HP Operations, BMC nebo Tivoli od IBM. V minulosti toto bývalo řešeno pomocí Console serveru. Ten poskytuje mnoho seriových portů, které se připojí na seriové porty ostatních zařízení, v tomto případě do hardware LOMu. Pomocí Console serveru, který podporuje připojení přes dial-up modem nebo síťový adapter, za použití telnetu nebo ssh, se může administrátor připojit do systémové konzole serveru (případně do boot loader console pro změnu boot parametrů) a přes tu ho dále ovládat.

6.2.2 Hardware LOMu V dnešní době nejpoužívanějším hardwarovým řešením pro LOM je RAC karta (Remote Access Card, v překladu karta pro vzdálený přístup). Karta, která se připojuje na sběrnici

49

serveru, obsahuje vlastní procesor, paměť, baterii a síťový adaptér. Pro úplnost ještě uvádím malý výčet firem a názvů jejich řešení, které nabízejí Lights Out Management. Dell – Dell Remote Access Controler, IBM Remote Supervisor Adapter, Intel - Active Management Technology, Apple – Xserve.

6.2.3 HP Integrated Lights Out Firma Hewlett-Packard dává do svých serverů integrované řešení pomocí RAC karty s názvem Integrated Lights Out (ILO). Karta ILO má vlastní síťové připojení a také vlastní IP adresu kterou ji přiřadí buď DHCP server nebo může být i statická. Ke kartě se připojuje přes web, pomocí https protokolu. Poskytuje veškeré standardní funkce LOM zařízení jako reboot a vypnutí serveru. Dále nabízí možnost server vzdáleně zapnout, připojit CD/DVD nebo obraz disku, umožňuje také vzdálený přenos obrazovek. Aby administrátoři mohli k ILu vzdáleně přistupovat musí být na ILu vytvořeny uživatelské účty. Potom už stačí, na jakémkoliv počítači připojeném v lokální síti nebo připojeném do sítě, přes VPN zadat ve webovém prohlížeči IP adresu ILO. Zobrazí se přihlašovací obrazovka, po zadání uživatelského jmén a hesla naběhne ILO konzole. V současnosti existuje ILO2, která v sobě mají integrované servery ProLiant Blade 300/500. Hardwarový modul ILO doznal vylepšení o hardwarový akcelerátor pro zachytávání obrazovek, což významně urychlilo situace, kdy administrátor vzdáleně převezme kontrolu nad obrazovkou. Novinkou je také šifrovaná síťová komunikace.

50

7. Struktura technické podpory Každá velká firma nebo organizace má svou technickou podporu. Má-li uživatel nějaký problém s počítačem, nemůže se přihlásit do informačního systému nebo IS neplní požadovanou funkci, uživatel chce nahlásit výpadek systému, atd. Takovýto běžný uživatel nikdy nekontaktuje odpovědnou skupinu, ale jeho první kontakt je s Callcentrem Helpdesku. V dnešní době je pojem Helpdesk nahrazen pojmem Service Desk. Takto je nazýván také v příručce ITIL (Information Technology Infrastructure Library).

7.1 Service Desk Cílem Service Desku je zajistit prvotní kontakt se zákazníkem a zajistit veškerou komunikaci mezi uživateli a IT podporou, za účelem uspokojit požadavky zákazníka. Označení uživatel v tomto případě znamená konkrétní osobu, která využívá danou službu. Zákazník je osoba, oddělení nebo jiná firma, která platí za poskytovanou službu. Service Desk je tedy komunikačním bodem mezi IT podporou na jedné straně a zákazníkem nebo uživatelem na straně druhé. V zahraničí i v České Republice pracuje ve velkých IT firmách mnoho cizinců, navíc se v drtivé většině jedná o zahraniční firmy. Z tohoto důvodu si firma zvolí jazyk, ve kterém probíhá veškerá komunikace. Nejčastěji je to angličtina. Jakmile se uživatel dovolá na Callcentrum, musí pracovník správně vyhodnotit, čeho se daný problém vůbec týká a jaká skupina odborníků ho bude řešit. Pracovník Callcentra tento problém musí pochopitelně nějak sumarizovat v elektronické podobě. Od toho je na trhu několik informačních systému pro technickou podporu. Firma může zakoupit buď řešení od Hewlett-Packard: Open View Service Desk nebo BMC: Remedy ARS. Může používat také vlastní řešení, což se dle mého názoru finančně ani časově nevyplatí, protože obě výše zmíněná komerční řešení jsou na trhu již řadu let. Jsou velice dobře uzpůsobitelná jakékoliv IT organizaci přesně na míru, jsou integrovaná na monitorovací systémy, a mohou příjímat standardizovaná data v xml formátu z jiných aplikací. Malým organizacím postačí místo drahého komerčního řešení sdílený soubor v excelu, ideálně malá sdílená databáze v MS Access. Informační systémy Open View Service Desk i Remedy používají k vytvoření požadavku na technickou asistenci nebo pomoc takzvaný Service Call neboli tiket. Tento tiket obsahuje povinná pole k vyplnění, jako je jméno volajícího, název služby, o kterou se jedná, stručný 51

popis problému, detailní popis problému, prioritu, jak rychle je třeba problém vyřešit, název skupiny, kam se má tiket odeslat. Jakmile pracovník Callcentra vytvoří nový tiket, okamžitě ho odešle na přislušné IT oddělení, které danou službu podporuje.

7.1.1 Callcentrum Service Desk bývá zpravidla rozdělen na tři části. Callcentrum, které přijímá hovory od zákazníků a uživatelů a následně vytváří nové tikety. Odpovídá na emaily od zákazníků a uživatelů a dle potřeby vytvoří nový tiket. Případně může být Callcentrum také komunikačním bodem mezi uživateli nebo zákazníky a dodavateli třetích stran. Například vyřízení objednávky toneru do tiskárny nebo problém s aplikací, kterou poskytuje třetí strana. Callcentrum funguje v podstatě i jako firemní ústředna, protože mnoho hovorů přepojuje na vyšší úroveň IT podpory.

7.1.2 2nd level support Další částí Service Desku je podpora Callcentra neboli backline či 2nd level support (druhá úroveň podpory). Pracovníci druhé úrovně

Service Desku většinou vykonávají

usermanagement informačních systémů a adresářových služeb. Zakládají nové emailové schránky uživatelům a řeší drobné uživatelské problémy, které se dají vyřešit pomocí vzdálené plochy. Jestliže uživatel potřebuje okamžitě reset doménového hesla v Active Directory nebo nastavit lokální účet Outlooku na svém počítači, může ho pracovník Callcentra přepojit na pracovníky 2. úrovně, kteří mu okamžitě mohou pomoct. V současné době je trendem přesunout na Service Desk co nejvíce usermanagementu (vytváření nových uživatelských účtů, reset hesla, změna a smazání uživatelského účtu) všech inforamačních systémů a usermanagement na unixových serverech a AS400 serverech, zakládání emailových schránek, atd. Zkrátka veškeré opakující se činnosti, u kterých není potřeba pokročilejších technických znalostí. Pro usnadnění práce mohou všichni pracovníci Service Desku používat tzv. Knowledgebase (znalostní databáze, obsahující pracovní instrukce). Jedná se o informační systém, který poskytuje uživatelům pracovní instrukce, jako například, jak vytvořit novou emailovou schránku nebo jak smazat uživatele na systému Unix a mnoho dalšího. V podstatě taková obdoba Wikipedie. Ve firmě, ve které pracuji, se používá více knowledgebase, pro technické návody a znalosti se používá komerční řešení Service Ware a pro informace o firemních procesech a skupinách, které podporují jednotlivé služby,

52

máme informační systém vlastní produkce. Oba tyto znalostní informační systémy fungují jako weboví klienti.

7.1.3 Incident management Třetí částí Service Desku je Incident Management (řízení incidentů). Představme si situaci, kdy dojde k výpadku nějakého pro činnost organizace důležitého informačního systému, adresářové služby nebo síťovému výpadku. Uživatelé pak hromadně volají na Callcentrum a hlásí svůj problém. Jedná-li se o problém, který se dotýká více uživatelů (alespoň celého oddělení), je potřeba reagovat co nejdříve a takovýto incident uvést co nejrychleji do původního stavu. Pro takovéto incidenty se vytvářejí v Open View Service Desk nebo Remedy tikety s vysokou prioritou. Jejich řešení musí zabrat maximálně hodinu nebo pár hodiny. Náplní práce pracovníků Incident Managementu je postarat se o každý takový nově příchozí tiket a monitoring již existujících tiketů, které jsou v řešení. Celý proces vypadá následovně. Nejprve Callcentrum vyrobí nový tiket s vysokou prioritou, předá ho Incident Managementu, jehož pracovnící následně kontaktují příslušnou osobu, která se v daném časovém úseku stará o příslušnou službu. Této odpovědné osobě telefonicky předají tiket a uloží ho pod skupinou odpovědné osoby. Komu tiket přiřadit se dočtou v knowledgbase informačním systému. Tam musí být jasně definováno, která skupina podporuje Windows servery, jednotlivé informační systémy, unixové servery, adresářové služby atd. Dále tam musí být uveden telefonický kontakt na odpovědnou osobu, která musí být v daném časovém okně dostupná na telefonu. Mělo by být také uvedeno podle SLA (service level agreement - dohodnutá úroveň poskytované služby), v jakém časovém úseku je služba podporovaná, zdali je podporovaná i mimo pracovní dobu a jaká může být nejvyšší priorita tiketu. Pakliže osoba z aplikační podpory převezme tiket a řeší ho, je úlohou Incident Managementu pravidelně tento tiket kontrolovat a zjišťovat informace od aplikační podpory, jak vypadá průběh řešení a tyto informace pravidelně do tiketu zapisovat. Skupina aplikační podpory nebo vyšší úroveň technické podpory by neměla mít pro řešení incidentů určeného jen jednoho člověka. Může se z jakéhokoliv důvodu stát, že jeho telefon nebude, ať už v pracovní době, nebo mimo ni, dostupný. Proto by měl existovat pořadník, v jakém jednotlivé osoby příslušné skupiny obvolávat. Zákazník automaticky dostává emaily, jakmile v tiketu přibude nový zápis nebo ho musí Incident Management 53

telefonicky informovat. To proto, aby zákazník alespoň tušil, kdy asi bude problém vyřešen a také viděl, že technická podpora dělá maximum pro řešení jeho problému. Jakmile je problém vyřešen, uživatel nebo zákazník potvrdí, že vše opět funguje jak má a tiket se zavře, pokud nedošlo k překročení maximální možné doby pro jeho řešení, k tiketu se zpravidla nevrací.

7.1.4 Vyhodnocování pomocí reportů Každý měsíc by se měl dělat report tiketů, jejichž řešení překročilo maximální povolenou dobu. Obě zmíněné řešení HP OVSD i Remedy nabízejí spousty vyhledávacích filtrů, takže lze vyhledávat tikety dle všech možných kritérií. Tyto tzv. Overdue tikety (tikety u nichž byla překročena maximální doba pro řešení) slouží k poučení se z vlastních chyb. Je potřeba analyzovat, proč došlo ke zpoždění. Jestli něco zanedbal nějaký pracovník nebo byly některé úkony jen procesně zdlouhavé, případně se na řešení problému mělo podílet víc techniků, atd. Každá organizace se snaží docílit, aby řešení jednotlivých incidentů bylo co nejkratší, vždyť každou minutou, kdy je používaný systém nefunkční, přichází firma o peníze, ne-li o zákazníky. Dalším důležitým měsíčním reportem je vyfiltrovat incidenty podle skupin aplikační a technické podpory. Zjistit, jestli se některé incidenty příliš často neopakují a jak zamezit tomu, aby se opakovaly. Takovýchto vyhledávacích reportů a kriterií je potřeba pravidelně udělat desítky. Zmínil jsem jen dva důležité. Informační systémy pro správu incidentů a požadavků (HP OVSD, BMC Remedy) dávají firmě dokonalý přehled o tom, co se děje v její IT infrastruktuře.

7.2 Remedy Action Request System Jedná se o aplikaci vyvinutou firmou BMC Software, dříve Remedy Corp. Je to aplikace typu Klient-Server. Nemá vlastní databázi, ale používá databázi třetích stran: Sybase, Oracle, MS SQL. Databáze ukládá sadu metatabulek známou též jako datový slovník. Metatabulky obsahují kód který říká aplikaci, jak nakládat s uživateli a daty. Aplikace Remedy ARS má otevřené API (application programming interface). To umožňuje uživatelům si uzpůsobit klienta podle svého přání a tvorbu skriptů, které přímo zasahují do aplikace. Aby mohli uživatelé a administrátoři komunikovat a pracovat s ARS serverem, je již předpřipraveno několik klientských aplikací, kde každá z nich se používá na něco jiného. Mezi základní objekty ARS systému patří formuláře, které se v systému používají pro zadávání nebo prohlížení dat.

54

Obrázek č. 9: ARS, Remedy user formulář

Data každého formuláře se ukládají do tabulky v databázi. Tabulky jsou provázány odkazy mezi sebou. Objekty Active Links jsou v podstatě sekvence automatických operací, které spouští klient. Příkladem takovýchto operací je extrakce dat z jiných tabulek a vkládání dat do tabulek, případně spouštění externích procesů. Filtry jsou objektem na straně serveru, je-li nastaveno více filtrů, jedná se také o sekvenci automatických operací. Objekty Guides umožňují administrátorovi spárovat objekty Active Links a filtry do funkcí. Objekt Aplikace umožňuje administrátorovi spojovat formuláře a sekvence operací, ty se pak snadno dají přenášet na jiný server.

7.2.1 Remedy user Pro běžného uživatele je tu BMC Remedy user, což je aplikace která uživateli umožňuje vkládat, měnit záznamy a vyhledávat v Remedy ARS. BMC Remedy user není tenký klient, jedná se o aplikaci, která musí být lokálně nainstalovaná do operačního systému Windows. Klient umožňuje připojení hned k několika Action Request System serverům a může brát informace z jednoho serveru, modifikovat je a ukládat na jiný. Remedy User umožňuje uživatelům vytvoření maker a nastavit si vlastní proměnné, za účelem zautomatizování

55

často se opakujících úkolů. Krom toho se Remedy User používá pro usermanagement, tedy vytváření nových uživatelů, reset hesla, změna uživatelského oprávnění.

7.2.2 Remedy Mid-Tier Alternativou k tomuto tlustému klientovy je Remedy Mid-Tier, což je serverová komponenta webového prohlížeče. Nejedná se o klasického webového klienta (tenkého klienta), Mid-Tier se připojuje na ARS server který obsahuje aplikaci a s tím spojená data. Pouze překládá požadavky klienta, interpretuje odezvu serveru, spravuje požadavky webových služeb. Nemůže fungovat odděleně od ARS Serveru. Klientem Mid-Tieru jsou webové prohlížeče. Administrátor nemusí vytvářet GUI, tedy webové stránky pro MidTier. Grafické rozhraní Mid-Tieru se zobrazuje úplně stejně, jak ho administrátor nastaví v aplikaci AR System Administratoru.

7.2.3 ARS Administrator AR Systém Administrator je další aplikací klienta Remedy ARS, sloužící ke správě a úpravám celého Remedy AR Systému. V ARS Administrátorovi se vytvářejí nové formuláře (template nebo jen čisté s názvy polí), odkazy, filtry pro vyhledávání nebo zobrazování, celé menu, případně miniaplikace. Za zmínku stojí fakt, že od verze 7.5 byl AR Systém Administrátor nahrazen aplikací Developer Studio.

7.2.4 Import dat do ARS Další součástí celého balíku je nástroj pro import. AR Systém Import je tlustý klient který importuje data do Remedy ARS. Jedná se o nástroj který je určen pouze administrátorům za účleme importu dat z .csv a .arx souborů. Pod pojmem kopírování dat si představme například import informací o uživateli. Miniaplikace, formuláře a metadata se importují v AR Systém Administrátorovi.

7.3 HP Open View Service Desk HP OVSD je, dle mého názoru, nejlepší softwarové řešení pro moderní Service Desk. Tato aplikace je dokonale škálovatelná a úzpůsobitelná každé organizaci přesně na míru. Vychází z nejlepších praktik pro správu IT služeb ITIL (IT Infrastructure Library). Open View Service Desk je vhodná pro velké organizace a dokáže zajistit správu klíčových procesů při správě IT služeb, také dokáže pokrýt celý životní cyklus správy IT služeb a

56

jejich dodávek. Já se této aplikaci budu věnovat z hlediska využití Callcentra a jak tímto zlepšit správu informačních systémů. Jak jsem již výše zmiňoval, Callcentrum Service Desku, přijímající požadavky od zákazníku musí tyto požadavky, problémy, incidenty, atd. nějak zaznamenat v elektronické podobě. Řešení dodávané firmou Hewlett-Packard je ve své základní podobě holé. Firma si ho musí uzpůsobit sama sobě na míru. Jednak musí přednastavit všechny pole formulářů. Základní pracovní objekt pro OVSD je formulář, ten může mít libovolný charakter. Podle osvědčených praktik v poskytování IT služeb jsou druhy formulářů zpravidla: Service Call, Change reqest, Work order, Event, Complaint, Problem.

7.3.1 Formulář Service Call Service Call se zpravidla používá pro logování incidentů, žádostí o informace nebo žádost o standardní změnu (Request For Standard Change). Pod pojmem incident si představme například situaci, když uživatel / zákazník hlásí výpadek informačního seznamu nebo poruchu svého počítače. Žádost o informace nemá cenu vysvětlovat. Typ Service Callu Request For Standard Change znamená jakýkoliv případ, kdy žádá uživatel / zákazník o provedení rutinního úkolu, který se běžňe vyskytuje. Například je to vytvoření lokálního účtu Outlook Express, přidání do distribučního listu, vytvoření uživatele v jakémkoliv informačním systému, který firma používá nebo reset hesla do informačních systémů či adresářových služeb, atd. Některé druhy Service Callu se často opakují a mají stejné znění, proto je vhodné vytvořit v HP OVSD template (vzor) Service Callu. Například vypozorujeme, že do EDI (electronic data interchange – převádí data z jednoho informačního systému do unifikovaného tvaru a ty potom odesílá druhému IS) často nepřicházejí data z nějakého konkrétního informačního systému. Vyrobíme si tedy template, kde budeme mít už přednastaven popis problému a na jakou skupinu zabývající se podporou aplikace Service Call odeslat.

57

Obrázek č. 10: HP OVSD formulář Servis call

Zbývá tedy pouze zadat jméno toho, kdo problém nahlásil a dobu, kdy měly data přijít. Stejně tak je vhodným příkladem reset doménového hesla v Active Directory. V tomto případě stačí jen vyplnit jméno uživatele / zákazníka, maximálně název domény. Úspora času a smysluplnost využití template je tedy v tomto případě evidentní. Vytváření těchto template a následné jejich používání podstatně ušetří čas pracovníkům Callcentra při zvedání telefonátů od uživatelů / zákazníků. Při správném výběru vhodného template jim trvá vytvořit Service Call dvojnásobně rychleji, než při jeho vytváření od začátku. Template všech formulářů (Service Call, Change ticket, Event, atd.) musí být intuitivně setříděny ve složkách. V opačném případě zabere vyhledávání správné template daleko víc času než vytvoření zbrusu nového Service Callu.

58

7.3.2 Formulář Change

Obrázek č. 11: HP OVSD – formulář Change

Change ticket je druh tiketu, který se používá, když je potřeba implementovat nějakou změnu, která se skládá z více pracovních úloh, takzvaných Work Orderů (pracovní úkoly). Představme si situaci, kdy do firmy přichází nový zaměstnanec. Krom jiného bude potřebovat: přístup do domény, emailovou schránku, legitimaci, přístup do patřičných informačních systémů, přístup do intranetu. Vytvoří se tedy hlavní Change ticket, který bude obsahovat jednotlivé Work Ordery: nová emailová schránka, přístup do domény, legitimace, atd. Jakmile jsou všechny Work Ordery splněny, Change ticket se zavře a žadatel uvedený v Change ticketu je automaticky vyrozuměn emailem. Použití template Change ticketů je naprosto totožné, jako u výše zmíněného užití v případě Service Callu. Jediný rozdíl je v tom, že v tomto případě si můžeme přednastavit libovolná pole u formulářů Work Order. Jedná-li se o změnu zasahující do IT infrastruktury, musí ji nejprve

59

posoudit oddělení Change Management, teprve pak může být příslušnou skupinou změna zapracovaná.

7.3.3 Formulář Event Event v HP OVSD je zvláštní druh tiketu, zpravidla ho generuje monitorovací systém HP Open View Operations Monitoring. Nebo přes HP OVO ho manuálně vytvářejí operátoři. Event zpravidla indikuje nějakou událost, změnu (většinou nežádoucí), podle toho, jak je monitorovací systém nastaven na serverech, operačních a informačních systémech. Monitorovat se dá těměř cokoliv, počínaje fyzickým stavem serveru, zatížení procesorů, využití paměti, volného místa ve file systemu nebo proces denních záloh dat informačních systémů.

7.3.4 Problem ticket V rychosti zmíním ještě k čemu slouží Problem ticket. Představme si situaci, kdy se řešení nějakého vysoce prioritního problému protáhne. Dalším příkladem je, když spadne celá podniková síť nebo přestane fungovat důležitý informační systém. Tato událost pochopitelně dočasně negativně ovlivní obchodní činnost firmy a způsobí firmě finanční ztrátu. V takovýchto případech se vytvoří Problem tiket, příslušné oddělení musí zjistit příčinu, vypracovat analýzu, co vedlo k takovéto události a vypracovat a implementovat řešení, jak takovému kolapsu předejít do budoucna.

7.3.5 Technologický popis HP OVSD V současné době je k dispozivi Open View Service Desk ve verzi 5.0. Usermanagement je zde řešen vlastním systémem, administraci uživatelských účtů lze provádět přímo v OVSD nebo lze napojit na adresářovou službu LDAP nebo Microsoft Active Directory. Co se týká serverové technologie, je vhodné použít High Availability Cluster s load balancingem. Standardně se používá klientská aplikace pro operační systém MS Windows 2000/XP/Vista nebo systém přenášení obrazovek Citrix Metaframe. Firma HP také nabízí webového klienta. Ten je ovšem pro práci zcela nepoužitelný. Smysl jeho využití je pouze v případě, když nám nejde klientská aplikace z jakéhokoliv důvodu, tak můžeme nahlédnout do tiketu přes webového rozhraní, pakliže potřebujeme nějakou informaci.

60

7.3.6 Filtry Velkou výhodou této aplikace jsou dokonale škálovatelné filtry, které si můžeme ukládat. Filtry si uskupujeme do tzv. pohledů, které klientská aplikace ukládá do souboru VIEWS.DAT. Tento soubor je přenositelný, lze ho nakopírovat na jakýkoliv počítač s klientem a uživatel pak uvidí přednastavené pohledy s pomocí filtrů. Filtry nám v podstatě slouží k tomu, abychom si vyhledali a zobrazili všechny formuláře, osoby, atd. podle námi zadaných kritérií (filtrů), například: priorita tiketu, druh tiketu (Service Call, Change, Event, atd.), název skupiny, které byl tiket přidělen, datum, atd. Mezi jednotlivými druhy pohledy si můžeme přepínat. Jen pro zajímavost uvádím, čeho se můžou jednotlivé pohledy týkat: Tikety (vyplněné formuláře Service Callu, Change, Event, atd.) přiřazené pod moje jméno, na skupinu, které jsem členem. Další pohled může obsahovat jen tikety s vysokou prioritou, které ještě nejsou uzavřené, atd. Pro úplnost dodávám, že k některým druhům formulářů (Service Call, Change) lze přidávat souborové přílohy.

Obrázek č. 12: HP OVSD – vytváření pohledu

Pohledy jsou také manažerským nástrojem. Vedoucí Service Desku je mohou používat jako metriku. Vyrobí si pohled, který ukazuje, kolik který pracovník uzavřel tiketů za měsíc, den či týden a na základě toho může porovnávat výkonnost jednotlivých pracovníků Service Desku. Další množina filtrů může vyhledat všechny uzavřené tikety, kterým prošla maximální povolená doba pro řešení, což je pro pracovníky naopak negativní hodnocení.

61

7.3.7 Service Bridge Vynikající funkcí je pak speciální rozhraní s názvem Service Bridge. Toto rozhraní je schopné přijímat a odesílat zprávy v xml formátu a vyrábět z nich nové tikety. Tuto funkci můžeme využít, chceme-li pro uživatele vytvořit webový portál, kde by si mohli tikety vytvářet sami. Díky tomuto rozhraní je možné HP OVSD integrovat do každého webového informačního systému. Například, je-li výpadek nějakého důležitého informačního systému, HP OVSD automaticky odešle na intranet tělo tiketu a všichni uživatelé mohou sledovat průběh odstraňování problému.

62

8. Závěr Jestliže chceme docílit účinnější správy informačních systémů z hlediska správy uživatelů, nejjednodušší cestou je napojení na adresářové služby. Jak jsem se již zmínil, adresářové služby nabízejí v tomto ohledu řadu výhod. S autentizací uživatelů pomocí adresářových služeb je nutné počítat již od vývoje informačního systému a uzpůsobit tak architekturu informačního systému. Přes jednu adresářovou službu lze zabezpečit autentizaci do více informačních systémů. Přes adresářové služby nemusí nutně probíhat jen autentizace. Informační systém si odtud může brát informace o uživateli (emailovou adresu, telefonní číslo, adresu a název pobočky kam uživatel patří, atd.). V případě, že firma používá mnoho informačních systémů bez tenkého klienta, je vhodným řešením kombinace například adresářové služby od Microsoftu Active Directory a Citrix Metaframe (poskytuje klientský přístup k aplikacím běžícím přímo na serveru). Pomocí řešení Citrix Metaframe Presentation dosáhneme toho, že uživatelům nebudeme muset hromadně instalovat na počítače klienta informačního systému. Tím získáme výhodu, že uživatel bude moci pracovat z jakéhokoliv počítače, protože veškerá data, včetně nastavení vzhledu klienta se uchovávají na serveru. Navíc nehrozí reinstalace klienta z důvodu nejrůznějších updatů operačního systému. Klient běží ve stabilním prostředí na serveru a uživatel nemůže nijak narušit jeho chod. Další výhodou je, že máme snadnou kontrolu nad správou uživatelů. Uživatele si rozdělíme do citrixových skupin podle toho, ke kterým informačním systémům nebo nástrojům mají mít přístup. Tyto skupiny jim pak přiřadíme v Active Direktory. Další otázkou je, jak zlepšit zabezpečení informačních systémů z hlediska uživatelů. V každodenním provozu je běžnou věcí, že uživatel potřebuje reset hesla do informačního systému, případně do celé domény. V organizacích o tisících zaměstnancích nebo s IT podporou mimo pobočku nebo tzv. outsource podporou (svěření technické podpory jiné firmě) je fyzická autentizace uživatelů / zákazníků značně složitá. Mnohdy se jedná o uživatele, kteří s informačními technologiemi nemají téměř žádné zkušenosti. Nejenže si nepamatují heslo, často zapomenou i UID login do informačního systému. Každá firma nebo organizace má pravidla pro vytváření UID (uživatelské jméno pro přihlášení do systému). Například se stanoví, že veškerá uživatelská jména mohou obsahovat maximálně 8 znaků, z toho maximálně 4 mohou být čísla a jsou povolena pouze malá písmena a čísla.

63

Způsob vytváření může být například první písmeno z křestního jména, zbytek z příjmení, atd. Pochopitelně i tohle si uživatelé často popletou a zkoušejí mnohdy až neuvěřitelné kombinace svého jména. V případě, že se jedná o reset emailového, respektive doménového hesla, pracovník Callcentra nemá šanci ověřit identitu volajícího. Podobně, jako když voláme na linku internetového poskytovatele, ověřují si číslo z kterého voláme, datum narození nebo číslo faktury, lze i v tomto případě použít takovýchto netechnických opatření. Pracovník Callcentra se může vyptávat a ověřovat jméno nadřízeného, adresu oddělení, zaměstnanecké číslo, číslo výplatní pásky a tak dále. Ani ověření těchto informací nezajišťuje ověření identity uživatele, protože výše zmíněné informace o uživateli si může s trochou úsilí zjistit kdokoliv. Řešením je dvoufaktorová autentizace pomocí uživatelského jména, hesla a USB tokenu nebo čipové karty. Již v operačním systému Windows 2000 jsme mohli vidět něco, co se USB tokenu podobá, funkce se jmenovala Smart Card Logon. Uživatel potřeboval k přihlášení čipovou kartu nebo USB token se svým privátním klíčem a certifikátem a pin tokenu (funguje jako ochrana pří ztrátě nebo krádeži USB tokenu). Jestliže uživatel chce někam odejít a vyjme ze čtečky čipovou kartu, stanice se okamžitě uzamkne. Nevýhodou čipové karty je, že uživatel s sebou musí neustále nosit čtečku karet, kdežto USB konektor má v dnešní době každý počítač. Mezi výhody čipové karty zase patří, že se dá použít také k řízení přístupu do budov a po budovách. Její povrch lze potisknout podobně jako moderní řidičský průkaz například fotkou a jménem držitele. Jak jsem již dříve zmínil, existuje také třífaktorová autentizace za využití biometriky uživatele. Ta ovšem nemá smysl jako zabezpečení informačních systémů u běžných uživatelů. Jednak kvůli pracné administraci a aktualizaci databáze s biometrickými údaji a také kvůli finanční náročnosti snímacích zařízení. Jen pro informaci uvádím, že zařízení na snímání sítnice oka stojí okolo 2 000 dolarů a je určeno do prostředí s cejchem “přísně tajné”. Například snímač geometrie ruky má smysl použít jako autentizaci do serverovny, abychom ochránili citlivá data a infrastrukturu.

64

9. Použitá literatura 1. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Kerberos (protocol) [online]. 2009, [cit. 2009-02-1] Dostupný z WWW: < http://en.wikipedia.org/wiki/Kerberos_(protocol) > .

2. Kolektiv autorů Microsoft Technet: Microsoft Technet: Gpupdate command [online]. 2009, [cit. 2009-03-12] Dostupný z WWW: .

3. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Active Directory [online]. 2009, [cit. 2009-02-10] Dostupný z WWW: < http://en.wikipedia.org/wiki/Active_Directory > .

4. Kolektiv autorů Microsoft Technet: Microsoft Technet: Organizational unit [online]. 2009, [cit. 2009-03-17] Dostupný z WWW: .

5. Kolektiv autorů Learn-Networking.com: Network security: How Kerberos Authentication Works [online]. 2007, [cit. 2009-03-17] Dostupný z WWW: .

6. BAY Robin: Svět sítí: Čipové karty a USB tokeny, aneb bezpečnější autentizace a šifrování [online]. 30.6. 2003, [cit. 2009-03-21] Dostupný z WWW: .

7. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Phishing [online]. 2009, [cit. 2009-02-12] Dostupný z WWW: .

65

8. Kolektiv autorů firmy Multima.cz: firma Multima.cz: Produkty Altiris [online]. 2005-2008, [cit. 2009-02-25] Dostupný z WWW: <www.multima.cz/reseni/altiris-produkty.htm> .

9. DVOŘÁK, Radek. Databáze v prostředí webu. Sborník konference Tvorba software 2004. Ostrava: Tanger s.r.o., 2004, s.38.43.

10. MOLHANEC, Martin. Kritika některých výkladů objektově orientovaného paradigmatu. Sborník konference Tvorba software 2004. Ostrava: Tanger s.r.o., 2004, s.163.172.

11. SMITH, Gordon. Oracle RAC 10g Overview. An Oracle White Paper, Oracle Corporation, November 2003.

12. WOODACRE, M., ROBB, D., ROE, D., FEIND, K. The SGI AltixTM 3000 Global Shared-Memory Architecture. Technical whitepaper, Silicon Graphics, Inc., 2003.

13. KŘIPAČ, Miroslav. Oracle Database & Real Application Clusters 10g on SGI Altix 350 Servers. Technická zpráva prototypového řešení, 2005

14. RUSSINOVICH Mark: Ps Exec 1.4 [online]. January 4, 2008, [cit. 2009-04-05] Dostupný z WWW: .

15. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Remedy Corp [online]. 2009, [cit. 2009-04-05] Dostupný z WWW: .

16. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Remedy Action Request System [online]. 2009, [cit. 2009-04-11] Dostupný z WWW: .

17. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: HP Open 66

View Service Desk [online]. 2009, [cit. 2009-04-11] Dostupný z WWW: .

18. Kolektiv autorů firmy Hewlett-Packard: HP Service Manager Software [online]. 2009, [cit. 2009-04-11] Dostupný z WWW: .

19. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: HP Operations Manager [online]. 2009, [cit. 2009-04-11] Dostupný z WWW: < http://en.wikipedia.org/wiki/OpenView_Operations> .

20. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Citrix Metaframe Presentation [online]. 2009, [cit. 2009-03-23] Dostupný z WWW: < http://en.wikipedia.org/wiki/Citrix> .

21. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Directory Services [online]. 2009, [cit. 2009-04-01] Dostupný z WWW: .

22. Kolektiv autorů Wikipedie: internetová encyklopedie Wikipedia: Lightweight Directory Access Protocol [online]. 2009, [cit. 2009-03-07] Dostupný z WWW: .

23. Kolektiv autorů informačního systému Masarykovy univerzity: Is.Muni.CZ: Víceúrovňové databázové klastry v prostředí rozsáhlých webových informačních systémů [online]. 1. - 3. června 2005, [cit. 2009-03-07] Dostupný z WWW: < http://is.muni.cz/clanky/2005_tvorba_sw.pl> .

67