Ministerstvo zdravotnictví České republiky

Definice bezpečnostních funkcí pro předávání dat ve zdravotnictví

Verze 1.0

Petr Hanáček, Jan Staudek

OBSAH

1. Úvod

2. Vybrané aplikační služby

2.1 Virtuální terminál

2.2 Distribuované uživatelské rozhraní Unix

2.3 Služby aplikační vrstvy RM OSI

2.4 Systémy ovládání souborů v distribuovaných systémech

2.5 Adresářové služby

2.6 WWW

3. Bezpečnostní vlastnosti informačních systémů

3.1 Bezpečnost, bezpečnostní politika

3.2 Stanovení bezpečnostní politiky

3.3 Zásady komunikační bezpečnosti podle ISO

3.4 Bezpečnost sítě Internet

3.5 Rozbor vybraných problémů bezpečnosti v síti Internet

3.6 Oddělovací uzly, firewalls

4. Bezpečnostní funkce pro přenos zdravotnických informací

4.1 Výběr bezpečnostních funkcí pro přenos zdrav. informací

4.2 .Požadované bezpečnostní funkce

5. Podpůrné bezpečnostní funkce

5.1 Autentizace uživatele a personální bezpečnostní prostředí

5.2 Správa klíčů

6. Elektronický podpis

7. Požadavky na kryptografické mechanismy

7.1 Obecné požadavky na kryptografické algoritmy

7.2 Definice použitých kryptografických mechanismů

7.3 Minimální délky kryptografických klíčů

7.4 Příklady doporučených kryptografických mechanismů

8. Bezpečnostní vlastnosti některých existujících systémů

8.1 Bezpečná elektronická pošta

8.2 Srovnání PEM a PGP

9. Odkazované normy ISO a doporučení CCITT

10. Literatura

1. Úvod

Tento dokument definuje procedury pro kryptografické zabezpečení zdravotnických informací (zpráv), potřebné pro jejich bezpečný přenos po veřejných telekomunikačních a datových sítích (např. síť Internet). Procedury, definované v tomto dokumentu jsou kompatibilní se širokou škálou kryptografických a bezpečnostních standardů.

Bezpečnostní funkce, použité ve standardu (důvěrnost, autentizace, integrita zpráv a neodmítnutelnost zodpovědnosti odesílatele) jsou zajištěny pomocí kryptografických mechanismů, implementovaných v odesílajícím a přijímajícím programu. Od použité datové sítě nejsou požadovány žádné speciální bezpečnostní funkce. Tento způsob dovoluje, aby bezpečnostní funkce byly implementovány pouze u koncových uživatelů. Je také zajištěna interoperabilita uživatelů, používajících různé způsoby připojení k přenosové síti.

Tento dokument je jednou ze tří částí studie standardu pro přenost zdravotnických informací. Celá studie má následující složení:

1. Část I: Studie "Definice bezpečnostních funkcí pro předávání dat o ve zdravotnictví", což je tento dokument.

2. Část II: Studie "Klasifikace citlivosti zdravotnických dat a doporučené bezpečnostní funkce pro jejich přenos". V této studii bude provedena klasifikace jednotlivých druhů dat, předávaných mezi IS zdravotnických zařízení z hlediska bezpečnosti do několika bezpečnostních tříd. V každé třídě budou druhy dat, které při přenosu vyžadují použití stejných bezpečnostních funkcí. Požadované bezpečnostní funkce budou vycházet z metodického pokynu "Definice bezpečnostních funkcí pro předávání dat o ve zdravotnictví".

3. Část III: Standard "Formát pro přenos zabezpečených dat ve zdravotnictví" Tento standard bude definovat datový formát zabezpečené zprávy, předávané mezi IS zdravotnických zařízení. Standard bude zahrnovat pouze ty bezpečnostní funkce, které se týkají samotného přenosu dat. Standard bude nezávislý na použitém přenosovém médiu a bude použitelný pro přenos komutovanými telefonními linkami, veřejnou datovou sítí, sítí Internet, případně i pro přenos prostřednictvím magnetických médií.

2. Vybrané aplikační služby

2.1 Virtuální terminál

Všeobecně žádanou službou v distribuovaném systému je možnost, aby uživatel pracující u terminálu jednoho uzlu ovládal proces běžící v jiném uzlu, aby si otevřel relaci v jiném uzlu apod. Terminály se z hlediska svého ovládání mnohdy podstatně vzájemně liší, a proto je v mnoha počítačových sítích definován (normován) univerzální, tzv. virtuální terminál (VT). V sítích X.25 je definován doporučeními X.3, X.28 a X.29 (trojitém X) virtuální terminál PAD (Packet Assembler Disassembler), v síti INTERNET virtuální terminál telnet (TELetype across a NETwork). VT je vždy definován jako protokol, který plní následující funkce:

· navázání spojení mezi aplikačními entitami,

· řízení dialogu po navázaném spojení,

· udržování stavu VT v datových strukturách na obou stranách komunikace,

· transformace vlastností skutečného terminálu do/z vlastností VT.

Rozeznávají se 4 základní třídy virtuálních terminálů:

· řádkový,

· stránkový,

· formulářový a

· grafický.

2.1.1 Virtuální terminál telnet

Pravděpodobně nejrozšířenější VT, telnet, patří mezi řádkové VT. VT telnet je při styku se vzdáleným aplikačním procesem emulován do formy chování lokálního terminálu pro prostředí procesu odpovídajícím serverem, při styku se skutečným terminálem pak klientským procesem, který zobrazuje kanonický terminál do/z skutečného terminálu. Klientský program telnet pomocí transportního spojení komunikuje se serverem ve vzdáleném uzlu, programem telnetd.

Telnet poskytuje terminálový přístup k uzlu. Protokol telnet umožňuje terminálovou relaci konfigurovat, tj. určovat, zda se přenos bude dělat po řádcích či po znacích, zda se budou vstupní znaky zpětně opisovat (echo) apod. Pro autentizaci uživatele u terminálu se používá standardní mechanismus autentizace, v prostředí unixu jménem a heslem pomocí programu login.

Po vytvoření transportního spojení a otevření relace ve vzdáleném uzlu je klientský proces telnet ve vstupním režimu, čte data z lokálního terminálu. Uživatel může zadávat příkazy, které jsou interpretovány buďto lokálním nebo vzdáleným interpretem příkazů podle toho, zda na počátku příkazu je či není uveden změnový znak. Data přenáší sítí buď znak po znaku nebo po řádcích. Při styku se vzdáleným uzlem ve znakovém vstupním režimu je každý znak textu okamžitě posílán ke zpracování vzdálenému uzlu. V řádkovém vstupním režimu je opis textu (echo) prováděn lokálně a vysílány jsou celé řádky najednou. V obou režimech lze nastavit přepínač, kterým se určí, zda příkazy uživatele (pro ukončení relace, pro přerušení spuštěného procesu, pro vymazání vstupu ze vzdáleného systému na terminál a pro výmaz napsaných a ještě neodebraných znaků z terminálu po žádosti o přerušení procesu) se zpracují lokálně a do vzdáleného uzlu se vyšlou jako řídicí posloupnosti protokolu telnet nebo se ponechají ke zpracování až vzdálenému systému.

Server telnetd se ve svém uzlu musí chovat vůči ostatním procesům jako terminál. V systému Unix 4.3BSD je tento požadavek zabezpečený pomocí abstrakce terminálu, tzv. pseudoterminálu. Pseudoterminál je komponentou unixového systému souborů. Má dvě části — master a slave. Obě části jsou v systému souborů vedeny jako periférie (unixové speciální soubory). Část slave (podřízená) se jeví lokálnímu procesu stejně jako lokální terminál. Část master (řídicí)je určena pro styk se serverem. Server, který chce pseudoterminál použít, si musí najít volný pseudoterminál a obě jeho části standardním způsobem otevřít. Dříve než otevře slave část, nastaví parametry pseudoterminálu tak, aby se choval jako virtuální terminál žádaného typu. Po otevření pseudoterminálu vytvoří server svého potomka, který zdědí mj. i pseudoterminál. Potomek si ponechá otevřenou část slave pseudoterminálu, kterou prohlásí za svůj standardní vstup a výstup a požádá jádro, aby byl dále řízen programem volaným ze vzdáleného terminálu, který předpokládá lokální komunikaci. Ve vzdáleném uzlu je činný proces login, jehož standardní vstup a výstup je terminál. V tomto případě však terminálem není lokální terminál, ale vzdálený terminál připojený na komunikační kanál tvořený lokálním klientským procesem uživatele telnet, síťovými službami operačního systému, komunikačními prostředky a ve vzdáleném uzlu serverem telnetd a pseudoterminálem. Samostatná implementace klienta a serveru v různých operačních systémech umožňuje používat VT telnet v nehomogenním prostředí z hlediska typu operačního systému — není problém si otevřít relaci z MS–DOS v Unixu, ve VMS apod.

2.2 Distribuované uživatelské rozhraní Unix

2.2.1 Otevření relace ve vzdáleném uzlu, služba rlogin

Při otevírání relace ve vzdáleném uzlu z otevřené relace téhož uživatele v homogenním unixovém síťovém prostředí není potřeba explicitně použít emulaci VT, uživatel může použít službu rlogin (remote login) plněnou ve vzdáleném uzlu serverem rlogind a zpřístupňovanou klientem rlogin. Pokud je oprávněn k takové činnosti ve vzdáleném uzlu, nemusí opakovaně uvádět svoje jméno, heslo apod. Oprávněnost požadavku na otevření relace ve vzdáleném uzlu je ověřována na základě znalosti identity uživatele ve vzdáleném uzlu. Server rlogind pro styk s procesem login ve vzdáleném uzlu opět používá pseudoterminál, jehož část slave ovládá proces login. tj. standardní přihlašovací proces. Je-li otevření relace úspěšné, začne příkazy zadávané uživatelem u terminálu interpretovat proces shell ve vzdáleném uzlu. Poněvadž standardní vstup a výstup procesu rlogin v lokálním uzlu se považuje za standardní vstup a výstup procesů spouštěných procesem shell ve vzdáleném uzlu, je jejich standardním vstupem a výstupem nakonec uživatelský terminál lokálního uzlu. Server rlogind zůstává v činnosti na části master pseudoterminálu a pracuje jako zprostředkovatel mezi procesy login a rlogin (lokální klient). Proces login díky použití VT respektuje rychlost přenosu klientova terminálu a jeho typ. Řízení toku dat pomocí XON/XOFF zůstává zachováno, zpětný opis provádí vzdálený proces login.

2.2.2 Vzdálené zadávání příkazů řídicího jazyka, služba rsh

V homogenním prostředí je žádoucí, aby uživatel mohl zadat jeden nebo více příkazů řídicího jazyka k provedení v některém vzdáleném uzlu. Přitom uživatel nechce ve vzdáleném uzlu otevírat relaci.

V operačním systému Unix 4.3BSD slouží k tomuto účelu služba rsh, (remote shell), která předává interpretu řídicího jazyka shell ve vzdáleném uzlu jeden příkaz, jehož standardní vstup a výstup přesměruje na svůj standardní vstup a výstup a poté skončí svoji činnost. Implicitně, tj. pokud se rsh vyvolá bez zadání konkrétního příkazu, se aktivuje v uzlu uživatele proces rlogin, a tím se řešení převede na předchozí případ. Server rshd činný ve vzdáleném uzlu poskytuje služby nejen klientskému procesu rsh, ale i každému procesu (klientu), v němž se volá procedura rcmd (remote command). Oprávněnost požadavku klienta se ověřuje opět na základě toho, zda požadavek přichází od známého uživatele. Server rshd čte z linky parametry s nimiž byl příkaz rsh případně zadán. Podle jména uživatele se nastaví domovský adresář. Dalším parametrem čteným z linky je číslo portu v klientově uzlu, který server použije jako chybový výstup. Dále se přečte příkaz, který se předá interpretu řídicího jazyka shell v uzlu serveru a vytvořený proces zdědí otevřené komunikační kanály po procesu rshd. Shellovské expanzní znaky použité v příkazu se interpretují v lokálním systému nebo, jsou-li v závorkách, ve vzdáleném systému.

2.2.3 Služba rcmd

Unixová síťová služba rcmd je realizována stejným serverem jako služba rsh, je však implementací vzdáleně volané procedury, obecně nepotřebuje pro svoji implementaci VT. Procedura rcmd volaná v procesu klienta vytváří transportního spojení se vzdáleným uzlem podle těchto parametrů: adresa volajícího uzlu, číslo portu pro standardní vstup a výstup, jméno uživatele v lokálním i vzdáleném uzlu, příkaz pro vzdálený systém a číslo portu pro chybový výstup vzdáleného procesu.

Volání funkce rcmd vrací ukazatel na datovou strukturu, která je svázána s portem, jehož adresu používá vzdálený proces pro standardní vstup a výstup. Je-li uveden port pro chybový výstup, vytvoří se zvláštní kanál ke vzdálenému procesu, který pomocí tohoto kanálu bude vysílat diagnostický výstup a přijímat z něho čísla synchronizačních signálů vysílaných skupině procesů, do níž patří. V opačném případě se použije pro diagnostický výstup kanál standardního výstupu. Proces rcmd musí být spuštěn s přístupovými právy propůjčenými superuživatelem.

2.2.4 Vzdálené spouštění procesů, služba rexec

Unixová služba rexec (remote exec) slouží podobně jako služba rcmd ke spuštění procesu ve vzdáleném uzlu. Voláním této funkční procedury z lokálního procesu se provede zadaná procedura ve vzdáleném uzlu. Vrácená funkční hodnota udává ukazatel na datovou strukturu, která je svázána s portem, jehož adresu používá proces, řízený programem rexec, pro standardní vstup a výstup vzdáleného procesu. Parametrem volání může být číslo portu pro chybový výstup a číslo portu ve vzdáleném uzlu, které se má použít pro vytvoření transportního spojení. Povinnými parametry jsou jméno uživatele a heslo. Ty se používají ve vzdáleném systému k ověření identity uživatele. Odpovídající server rexecd podle nich nastaví také domovský adresář a spustí uživatelův proces shell, kterému předá příkaz k provedení. Takto vytvořený proces zdědí síťové spoje mezi procesem volajícím rexec a serverem rexecd.

2.3 Služby aplikační vrstvy RM OSI

Služby aplikační vrstvy jsou určeny pro uživatele, tj. programy nebo osoby. Tito uživatelé nejsou součástí světa OSI! Kooperace aplikacemi v síti musí probíhat funkčně správně. Proces, který typu funkce používá, věří, že fungují správně v distribuovaném prostředí. Kooperace takových funkcí pro jednu aplikaci se nazývá asociace. Funkce se nazývají prvky služby asociace, resp. prvky aplikačních služeb, ASE (Application /Association Service Element). Jsou dvou typů: specifický ASE, SASE a obecný ASE, CASE (Common ASE). SASE jsou funkce specifických aplikačních protokolů, CASE jsou funkce pro všechny protokoly a služby aplikační vrstvy.

Například prvek řídicí služby asociace, ACSE, Access Control SE, slouží pro více účelů než pro jednu distribuovanou aplikaci. Pomocí ACSE lze zavést relaci mezi aplikačními procesy. Iniciátor asociace zůstává v řídicím postavení (master). Jedním z úkolů ACSE je zaznamenání abstraktní syntaxe prezentační vrstvy, kooperující aplikace se dozví, který úkol musí být proveden podpůrnou 6. vrstvou, tj. konverze, komprese apod. Jinou funkcí je synchronizace systematické a spolehlivé funkce distribuované aplikace. Tyto funkce v rámci ACSE používají funkce relační vrstvy.

Synchronizační funkce ve vrstvě 7 tvoří protokol CCR, Commitment, Concurrency and Recovery, vazební protokol paralelních transakcí. Vázání, commitment, řídí vazby podřízených v asociaci s řídicím prvkem. Paralelismus, concurrency, řídí současnost činností. Obnova, recovery, je opravnou funkcí. Příkladem může být bankovní transakce: M žádá banku o přenos tisíce korun ze svého účtu v Brně na účet pana S v jiné bance v Praze. Požadavek je přenesen elektronicky na koordinační úřad, který řídí všechny transakce mezi bankami. Jednoduchý protokol je následující: koordinační úřad pošle zprávu oběma bankám najednou, ve které je žádá, aby korigovaly podle zprávy oba účty. Problémnastane tehdy, když korekci jedna banka neudělá a druhá udělá. Důvodem nesplnění požadavku může být porucha v síti. Je proto potřebný protokol, který zajistí, že se provedou obě akce nebo žádná. CCR řeší tento problém pomocí atomických akcí. Atomickou akcí je množina zpráv a operací, které provedou úplně nebo vůbec ne. Pokud se neprovedou, obnoví se původní stav. Atomické akce se implementují dvoufázovým vázacím protokolem, technikou, která má svůj původ v distribuovaných databázích. V první fázi řídicí element, koordinační úřad, přidělí každému podřízenému, ostatním bankám, úkol. Každý pořízený si prověří, zda může úkol provést. Jestliže ano, požadavek si zapamatuje v energeticky nezávislé paměti (disk např.), data zamkne, tak, aby ostatní požadavky od řídicího elementu je nemohly ovlivnit a oznámí, že operace bude úspěšná. Podřízený si rovněž zamkne původní stav. Pokud podřízený nemůže požadavek splnit, oznámí to a další akce nedělá. Jakmile řídicí element obdrží všechny odpovědi, zkontroluje, zda všichni podřízení splní úkol. Pokud ano, zašle pokyn k jeho provedení, jinak podřízeným přikáže se vrátit do původního stavu. Pokud se vyskytne chyba po odeslání příkazu, každý podřízený se stále může vrátit do původního stavu, má ho poznamenán v zamčené energeticky nezávislé paměti.

2.4 Systémy ovládání souborů v distribuovaných systémech

2.4.1 Možnosti řešení

Klíčovými problémy návrhu systému ovládání souborů distribuovaných systémů jsou rozhodnutí o tom, do jaké míry bude uživatel zatěžován znalostí o umístění souboru, zda budou v distribuovaném systému udržovány jedinečné kopie souborů dat nebo zda se připustí jejich násobné zobrazení ve více uzlech. Je třeba též rozhodnout, zda bude zabezpečena vzájemná konzistence těchto kopií, zda se budou udržovat distribuované soubory se záznamy rozptýlenými po různých uzlech, zda lze zpřístupňovat soubory v heterogenních sítích z různých operačních systémů apod. Problematika návrhu a implementace systému ovládání souborů v distribuovaných systémech hraničí již s návrhem a implementací distribuovaných databází.

Jednoduchý systém ovládání souborů lze v distribuovaném systému implementovat tak, že každý uzel vybavíme jeho vlastním lokálním systémem ovládání souborů. Dále definujeme takové funkce těchto lokálních systémů ovládání souborů, aby bylo možno soubory mezi uzly přesouvat pomocí příkazů řídicího jazyka. Uživatelé musí pak znát umístění každého souboru, se kterým chtějí pracovat. V různých uzlech tak může současně existovat několik kopií téhož souboru v různém stadiu modifikace. Vzájemnou konzistenci těchto kopií takový systém ovládání souborů neřeší — je třeba ji řešit v aplikačních programech. Systém ovládání souborů může pomoci udržovat konzistenci tím, že umožní přístup k souboru ve vzdáleném uzlu bez požadavku na jeho přesun do uzlu, v němž běží proces, který s tímto souborem pracuje např. pomocí vzdáleného volání procedur. Takový soubor lze chránit před vícenásobným přístupem uzamčením. Zamykání lze mnohdy provádět i na úrovni záznamů.

Povinná znalost identifikace uzlu, v němž jsou soubory umístěny, uživatele omezuje. Tento problém lze řešit tak, že soubory nesdílené více uživateli se uchovávají jen v uzlu jejich vlastníka. Naproti tomu sdílené soubory se uchovávají v uzlu distribuovaného systému, jehož funkcí je plnit službu sdílené paměti souborů (souborový server). Uvedená metoda však má charakter centralizovaného řešení. Decentralizované řešení, které umožňuje, aby procesy nemusely znát umístění souborů, vede k udržování kopií adresářů souborů v jednotlivých uzlech. Tím se problém znalosti konkrétního umístění souboru převede na problém udržování konzistence více kopií jednotlivých adresářů.

2.4.2 ISO služba FTAM

ISO definuje službu FTAM (File Transfer, Access and Management), jejíž norma ISO 8571 definuje virtuální soubor, poskytované služby a vlastní protokol. Uživatelům nabízí přístup k informacím, jejich přenos a správu. Příklady: použití vzdálených databází, zaslání souboru pomocí souborového serveru v LAN do systému, který je umístěn jinde.

FTAM definuje jednotnou strukturu souborů, virtuální souborovou paměť, kterou každý systém zná a do které zobrazuje svůj souborový systém. Soubor má jméno, a jistý počet vlastností definujících logickou strukturu souboru, rozměr, maximální rozměr, zda je to binární nebo textový soubor, šifrování, datum korekce, datum vytvoření, účtovací informace, vlastníka atd. Atributy rovněž určují relace mezi soubory a jejich uživateli, kdo je smí číst, měnit, rušit apod.

Virtuální soubor je definován ze 4 hledisek jako:

· zpřístupňovaná struktura — co je zpřístupňovaným záznamem pro čtení, zápis, rušení a vkládání, (FADU, file access data unit); základním typem souboru je hierarchický soubor, norma zná i sekvenční soubor,

· prezentační struktura — abstraktní syntaxe elementární datových jednotek (položek záznamů),

· přenosová struktura — způsob, kterým je vytvářeno pořadí záznamů pro vysílání,

· identifikační struktura — pojmenování.

Každý soubor je dále popsán svými vlastnostmi, které udávají přístupová práva (kdo smí co), datový typ (binární/textový), způsob šifrování a povolené operace nad souborem (lokalizace záznamu, čtení, zápis, modifikace apod.).

Služby definované normou FTAM jsou spojované aplikační služby. Patří mezi ně služby, které umožňují uživatelům i správci souboru vzájemně rozpoznat svoji identitu, identifikovat zpřístupňovaný soubor a autorizovat tento přístup a definovat jeho výlučnost, definovat či modifikovat atributy souboru a operovat nad soubory a jejich záznamy. Popisný jazyk je založen na prezentační normě ISO nazývané ASN.1

2.4.3 Služba ftp

Typický protokol aplikační vrstvy pro přenos souborů v heterogenním prostředí různých operačních systémů, FTP (File Transfer Protocol), musí spolupracovat se 3 entitami: musí být v interakci s uživatelem u terminálu nebo s programem řídícím proces přistupující k souboru, musí být v interakci s jinými FTP entitami v ostatních zúčastněných uzlech a konečně musí být v interakci s lokálním systémem ovládání souborů. Pro vyřešení problému heterogenního prostředí a tudíž různorodých struktur souborů lze použít analogické řešení jako v případě VT a pracovat s virtuální datovou strukturou Vzdálený přístup k souborům v uzlu zprostředkovává server ftpd činný v uzlu, v němž jsou uloženy vzdáleně zpřístupňované soubory. Lokální uživatelské interaktivní rozhraní řídí klient ftp. Princip činnosti je následující: Uživatel vyvolá pomocí příkazu jazyka shell běh procesu ftp tak, že současně s vyvoláním ftp udá i uzel, ve kterém je uchováván zpřístupňovaný soubor. V zadaném uzlu se vytvoří relace uživatele. Nejsou-li potřebné přihlašovací textové řetězce zadány v příslušných proměnných předchozí definicí, ftp je zjišťuje konverzací s uživatelem. Klient ftp v rámci existující relace v udaném uzlu vytváří transportní spojení se serverem ftpd. Příkazy zadávané klientu ftp uživatelem umožňují:

· manipulovat s lokálními i vzdálenými adresáři,

· manipulovat se soubory a případně se skupinami souborů,

· zadávat příkazy pro lokální i vzdálený shell,

· definovat a vyvolávat makropříkazy,

· definovat jméno uživatele a jeho heslo pro automatické otevření relace ve vzdáleném systému,

· definovat typ přenášených souborů (znakový v kódu ASCII, binární, znakový v kódu EBCDIC apod.),

· definovat způsob automatické úpravy jmen souborů při kopírování souborů mezi uzly,

· definovat způsob označení konců záznamů apod.

Podle definice může protokol ftp rozlišovat 4 typy souborů: obrazový (bitový), textový (ASCII), textový (EBCDIC) a binární (posloupnost slabik). Vlastní přenos může být realizován jako proud slabik nebo po případě i kompresovaných bloků slabik.

Implicitně se předpokládá znakový přenos, o binární přenos se musí požádat, úprava protokolu je věcí obou stran.

Uživatel může požádat klienta ftp o současné vytvoření relace v dalším uzlu, tj. o vytvoření tzv. sekundárního transportního spojení v jiném vzdáleném uzlu. Pak existují současně dvě spojení klienta ftp se dvěma servery ftpd a klient ftp může řídit přenos souborů mezi oběma servery, tj. uživatel může žádat o přenos souborů dat mezi dvěma vzdálenými uzly.

Ověřování oprávněnosti požadavku uživatele provádí server ftpd podle databáze uživatelů ve svém uzlu. Uživatel může vytvořit relaci i "anonymně" — jako uživatel "anonymous". Potom však jsou jeho přístupová práva k souborům silně omezena. Anonymní ftp je hlavním prostředkem pro distribuci programů a dat. Servery ftp lze nakonfigurovat tak, že vnějším klientům umožní získávat soubory z jisté předem určené oblasti bez nějaké zvláštní autorizace. Některé implementace požadují, aby se vnější klient po anonymním přihlášení autentizoval svojí poštovní adresou, což je nesmysl, ale je třeba se s tím vyrovnat. Lze říci, že ftp se stalo neustanovenou normou pro publikování software, článků, obrázků apod. Řada uzlů má veřejně dostupný ftp sklad. Vedle elektronické pošty, je tudíž ftp snad nejhodnotnější službou internetovské sítě.

V Internetu se transportní spojení ftp se řídí protokolem TCP. Klient ftp i jeho server ftpd mohou pracovat i v režimu ladění komunikace (uživatel získá detailní přehled o jednotlivých akcích, které proběhly během přenosu na spojové až transportní úrovni). Relaci, během níž je uživatel např. 15 minut nečinný, server ftpd automaticky ukončí.

Výměna příkazů a odpovědí na ně mezi klientem a serverem probíhá po prvotním řídicím kanálu, data se posílají po zvláštním datovém kanálu. Server pro něj používá port 20, klient pro něj používá implicitně tentýž port, ze kterého požádal o službu..

2.4.4 Služba tftp

Služba sítě tftp (Trivial File Transfer Protocol) umožňuje přistupovat ke vzdáleným souborům podobně jako služba ftp. Uživateli poskytuje ve srovnání se službou ftp menší pohodlí a omezenější přístup k souborům, pracuje však rychleji. Vzdálený server se nazývá tftpd, klient tftp. Pro přenos souborů se nevytváří mezi klientem a serverem transportní spojení, oba partneři používají protokol datagramového typu. Služba tftp je určena především pro kopírování souborů mezi lokálním a vzdáleným uzlem. Uživatel ve vzdáleném uzlu neotevírá relaci a vzdálený server tftpd má implementována značná omezení při přístupu k souborům. Vysílá pouze soubory, které mohou číst všichni uživatelé, zapisovat smí pouze do souborů, které už existují a jsou přístupné pro zápis všem uživatelům. Součástí protokolu tftp není žádná autentizace účastníků.

2.4.5 Služba rcp

V unixovém prostředí je implementovaná služba rcp (remote copy), která kopíruje mezi vzájemně si důvěřujícími uzly soubory nebo adresáře včetně obsahu podadresářů. Přístupová práva a vlastník se zachovává, pokud se volbou parametru v příkazovém řádku nenastaví jinak. Uživatel nezadává žádné jméno pro otevření relace, protože je ve vzdáleném uzlu přihlášen stejně, jako se přihlásil při otevření relace v lokálním uzlu. Kromě základního schématu přenosu mezi lokálním a jedním vzdáleným uzlem může uživatel žádat i o přenos souborů mezi dvěma vzdálenými uzly.

2.4.6 Služba NFS

V současné době je NFS, (Network File System), jedna s široce používaných služeb, která bude zřejmě používaná ještě po mnoho let. Jejím cílem je vytvoření z logického hlediska celistvé adresářové struktury v rámci sítě, která umožní bez ohledu na fyzické uložení jednotlivých souborů dat řešit přístup k souborům klasickou cestou udáním relativních nebo absolutních přístupových cest k nim.

Aby byla taková služba dostatečně robustní, je implementována na základě mechanismu volání vzdálených procedur, pomocí protokolu UDP a server NFS je bezstavový. Tzn., že každý požadavek na NFS server, uzel vlastnící reálnou diskovou kapacitu, je samostatný, neudržuje se žádný kontext. Každá operace musí být autentizována samostatně. To není triviální situace.

Aby byl NFS systém dostatečně robustní z hlediska možných opakovaných zavádění systémů v jednotlivých uzlech a z hlediska možného dělení sítě na samostatné, izolované celky, musí se stav udržovat v klientech. Servery to nedělají. Bázovým nástrojem je souborová identifikace, file handle, — jednoznačný řetězec, který identifikuje každý soubor nebo adresář na disku. Všechny požadavky na NFS jsou specifikovány v pojmech souborová identifikace, jméno operace, parametry operace. Souborové identifikace získává klient na základě svého požadavku na takové operace, jakými jsou open, close apod. Souborové identifikace klienti neinterpretují. Vytváří je server s takovou strukturou, aby v ní měl dostatečný prostor pro svoji činnost.

Počáteční identifikaci pro kořenový adresář souborového systému se získá při připojování podadresáře do užívané logické adresářové struktury. V tomto okamžiku klientovo jméno uzlu, požadovaný souborový systém a režim operace (čtení a/nebo zápis, pouze zápis apod.) kontroluje připojovací démon proti seznamu, který dodal správce systému. Je-li vše v pořádku, vrátí se klientovi souborová identifikace kořenového adresáře souborového systému.

2.4.7 Elektronická pošta

Na elektronickou poštu, e-mail, lze nahlížet jako na "store-and-forward" přenos elektronických objektů heterogenním síťovým prostředím. Zahrnuje jak textovou komunikaci mezi lidmi, tak i komunikaci mezi aplikačními entitami (systémy). Požadovaná úroveň propojitelnosti komunikujících účastníků vyžaduje dostupnost adekvátních nástrojů pro správu propojených sítí — adresářové služby, řízení přístupu, přihlašování, účtování, monitorování apod. Teprve pomocí takových nástrojů lze budovat aplikační systémy založené na použití e-mail.

Zpoždění dopravy zprávy pomocí e-mail se pohybuje v intervalu minut až hodin. Předností e-mail je její nevtíravost: uživatel je informován o příchodu zprávy, ale on rozhoduje o jejím přebrání z poštovní schránky. E-mail tak nabývá asynchronní charakter, což je její výraznou předností např. při komunikaci přes vzdálená časová pásma. Zprávou e-mail může být libovolná datová struktura, takže e-mail lze použít pro komunikaci mezi libovolnými aplikačními systémy, včetně multimediálních. Komunikovat mohou mezi sebou osoby, aplikační systémy a osoby s aplikačními systémy.

V současné době se používá celá řada poštovních služeb, postavení de jure normy mají služby definované ISO doporučením X.400, stále ale rozšířenější jsou služby sítě INTERNET, definované normou protokolu smtp (simple mail transfer protocol). Výměna zpráv mezi aplikacemi se nazývá elektronická výměna dokumentů výměna dokumentů elektronická, EDI (Electronic Data Interchange). EDI v současné době se bouřlivě rozvíjí a normalizuje, v Evropě uplatňovaná norma EDIFACT (EDI For Administration, Commerce and Trade) se buduje na bázi normy X.400.

Běžný poštovní systém je tvořen dvěma podsystémy, uživatelským agentem, UA a poštovním agentem, MTA (Message Transfer Agent). Uživatelský agent umožňuje uživatelům číst a posílat elektronické dopisy, poštovní agenti dopravují dopisy od odesílatele k příjemci. Uživatelští agenti poskytují rozhraní ovládané textovými příkazy, nabídkami, ikonami apod. Poštovní agenti jsou typicky implementovaní jako procesy — démoni, kteří běží trvale.

Běžný poštovní systém plní následujících pět funkcí:

1. vytváření — zpráv a odpovědí pomocí editorů odpovídajícího typu, vč. takových pomocných operací, jakými jsou automatické kopírování adresy odesílatele do odpovědi na dopis apod.

2. přenos — zpráv od odesílatele k příjemci typicky pomocí navázání transportního spojení,

3. zpravodajství — o nedoručitelnosti zprávy, důvodech nedoručitelnosti apod.

4. zobrazování — zpráv na uživatelské rozhraní případně i pomocí speciálních prohlížečů (grafických, postscriptových atd.)

5. manipulace — se zprávami, jejich ukládání do pořadačů, organizování doručené a odeslané pošty apod.

Poštovní systém udržuje poštovní schránku, do které ukládá doručené zprávy. Zprávy uložené v poštovní schránce umožňuje prohlížet, tisknout, ukládat do pořadačů apod. Poštovní systémy umožňují udržovat seznamy poštovních adres a zprostředkovávat rozeslání totožných kopií zprávy všem uživatelům uvedeným v takovém seznamu. Některé poštovní systémy umožňují získat doručenku potvrzující doručení dopisu příjemci. Mezi běžné služby dále patří zasílá kopií zprávy určeným příjemcům, případně zasílání slepých kopií, o jejichž příjemcích se řádní příjemci nedoví, utajování zpráv, prioritní přenos označených zpráv, označování náhradních příjemců pro případ nedostupnosti řádného příjemce zprávy apod.

Dopisy většiny poštovních systémů jsou strukturovány na tělo a záhlaví zprávy. Záhlaví zprávy bývá určeno pro uživatelského agenta, odpovídá něčemu jako hlavičkovému dopisnímu papíru. Tělo zprávy obsahuje vlastní zprávu pro uživatele. Informace potřebné pro přenos a doručení zprávy, tj. cílová adresa, priorita, stupeň utajení apod., jsou obsaženy v obálce. Tělo a záhlaví jsou do obálky vnořeny. Obálka je určeno pro poštovní agenty.

Posílaný dopis uživatel vytvoří, izolovaně nebo pomocí uživatelského agenta, předá ho uživatelskému agentovi spolu s potřebnými parametry (adresa příjemce, priorita, utajení, určení příjemců kopií, ) a požádá o vyslání.

O doručení dopisu je uživatel informován obvykle výpisem obsahu poštovní schránky, ve kterém jsou vhodnou formou označeny nové, dosud nepřečtené zprávy. O příchodu zprávy může být rovněž informován vykreslením nějaké ikony na obrazovce terminálu. Typická identifikace zprávy v takovém výpisu obsahuje jméno nebo adresu odesílatele, datum podání dopisu, příznak urgentnosti, novosti, subjektovou identifikace (o čem zpráva je) apod.

Uživatel má k dispozici příkazy pro zobrazení vybrané zprávy, její výpis na tiskárnu, pro odeslání odpovědi, zprávy dalšímu příjemci, pro odstranění zprávy, její uložení do určené registratury apod.

2.4.8 E-mail, ISO norma X.400

Systém výměny zpráv, MHS (Message Handling System) definovaný normou X.400 je vybudován na modelu, který rozpoznává 2 entity:

· Uživatelův agent, UA, (User Agent), je modul aplikační úrovně, který pracuje podle pokynů uživatele a pomáhá mu poskytovanými službami IPMS (Interpresonal Messaging Service):

· připravit zprávu a předat ji přenosovému systému zpráv, MTS (Message Transfer System) k doručení,

· zapamatovat došlé zprávy do vyzvednutí,

· předkládat zprávy uživateli,

· zasílat odpovědi.

Uživatelští agenti jsou podle typu ovládaných zpráv seskupováni do tříd.

· Druhou entitou je prvek MTS nazývaný poštovní agent, MTA (Message Transfer Agent). MTA je poštovní server, který je zodpovědný za bezpečné uchovávání a předávání zpráv. Při doručování zprávy si MTA zprávu postupně předávají zprávu mezi sebou.

Každý uživatelův agent má svého poštovního agenta, poštovní agent může obsluhovat i více uživatelských agentů. Uživatelský agent může být implementován jako samostatný aplikační modul nebo jakou součást MTA.

UA i jeho MTA mohou být součásti jediného uzlu nebo mohou být vzájemně vzdáleni v různých uzlech sítě, pak je UA obsluhován pomocí MTA plnícího funkci SDE, (Submission/Delivery Entity). V případě víceuživatelského uzlu lze v uzlu umístit jak MTA, tak i všechny jeho UA.

Pokud není samostatný uživatelský agent schopen si dlouhodobě pamatovat zprávy, případ bezdiskové stanice, může mu jeho poštovní agent udržovat poštovní schránku (box), MS (Message Store).

Norma X.400 nedefinuje ani směrování zpráv mezi MTA, ani styk uživatele s agentem. Specifikuje protokoly komunikace UA–MTA(SDE) (protokol pro předložení a odebrání zprávy, protokol P3), MTA–MTA ("store-and-forward" protokol, protokol P1) a UA–UA (protokol koncových entit, P2) a UA–MS (protokol P7).

Protokol P1 definuje 3 datové jednotky:

· zpráva, (tělo zprávy, záhlaví uživatelského agenta a obálka),

· návratka, (záhlaví a tělo)

· testovací zpráva, která prověřuje dostupnost cíle, o které informuje návratkou.

Obálka obsahuje síťové jméno adresáta podle kterého se řeší směrování, jednoznačný ID zprávy a informaci o tam, jak zpracovat zprávu — zda poslat návratku, její prioritu apod. Návratka obsahuje např. účtovací informaci úspěšně doručené zprávy.

Služby MTA definované normou X.400 typicky plní např. následující funkce:

· podávání a doručování zpráv,

· časové razítkování zpráv,

· typování těl zpráv (ASCII text, analogový FAX, digitální FAX, digitalizovaný hlas, videotex, telex, jiný),

· identifikování zpráv jednoznačným ID,

· informování o nedoručení zprávy apod.

Pro plné pochopení architektury X.400 je třeba pochopit princip identifikace v rámci e-mail systému. Poštovní agenti se svými uživatelskými agenty jsou sdružováni do správních domén, MD (Management Domain). Každou správní doménu spravuje administrátor — správa spojů apod. Administrátor je organizace, která je členem ITU, v daném státě má výsadní postavení. MD spravovaná administrátorem se nazývá ADMD. ADMD vždy leží v jedné zemi, v jedné zemi může být více ADMD. Vedle oficiálních MD mohou být provozovány privátní domény (např. v rámci vysokých škol), ty jsou nazývány PRMD. PRMD neexistuje v rámci nějaké ADMD, spíše je k nějaké ADMD připojena. Podle normy X.400 by entity v různých PRMD neměly komunikovat přímo mezi sebou, ale prostřednictvím svých ADMD. Administrátor je zodpovědný za jednoznačné pojmenovávání svých uživatelů, za používané směrování apod.

Pro identifikaci komunikujících entit zavádí norma X.400 pojmenovávací systém hierarchických jmen, které mohou vystupovat v následujících variantách:

· Stát, ADMD, (PRMD), (osoba), (organizace),(oddělení v organizaci), (doménově orientované vlastnosti)

· Stát, ADMD, (identifikátor UA), (doménově orientované vlastnosti)

· Stát, ADMD, adresa podle X.121, (doménově orientované vlastnosti)

Například:

C= CZ/ADMD = TELECOM/PRMD = VS/O= MUNI/OU= FI/S= Staudek

2.4.9 Elektronická pošta sítě INTERNET

Poštovní protokol je nazýván SMTP (Simple Mail Transfer Protocol). Podporuje přenos pouze ASCII textů. Nerozlišuje mezi obálkou a zprávou, obě tyto části jsou kontinuální součástí jednoho souboru. Každé pole v záhlaví je uvozeno klíčovým slovem odděleným od hodnoty dvojtečkou:

From:staudek@fi.muni.cz

Záhlaví lze tedy opravovat jediným editorem současně s vlastní zprávou, což v systému X.400 není možné (tam je záhlaví kódováno binárně pomocí ASN.1)

Adresování je hierarchické, je založeno na principu domén. Hierarchicky nejvyšší domény reprezentují jednotlivé státy a vybrané oblasti v USA, domény na nižších úrovních se organizují samostatně. Záhlaví zprávy SMTP má následující položky:

To: adresa příjemce

Cc: adresy pro zaslání kopií

Bcc: adresy pro zaslání slepých kopií

From: jméno odesílatele — šéf

Sender: adresa odesílatele — sekretářka

Received: řádek přidaný každým poštovním agentem

Return-Path: adresa odesílatele — 'Sender'

Date: kdy byla zpráva odeslána

Reply-To: adresa pro zaslání odpovědi

Message-ID: identifikátor zprávy

In-Reply-To: identifikátor zprávy na kterou se odpovídá

References: ostatní relevantní zprávy

Subject: o čem zpráva je

Keywords: klíčová slova

Comments: definováno uživatelem

Při každém přenosu zprávy mezi sousedními uzly se k záhlaví přidají řádky Received a údaj o čase. Lze tak rekonstruovat cestu, po které zpráva přišla.

Pro použití SMTP odesílající uzel naváže TCP/IP spojení se sousedním nebo s cílovým uzlem, potom identifikuje odesílatele a příjemce a konečně pomocí příkazu poštovní zprávu odešle. SMTP poskytuje řadu příkazů pro ověřování adres, vytváření a udržování seznamů adresátů, pro uzavření spojení apod. Protokol SMTP bývá implementován ve dvojici klient–server. Klient se stará o vysílání zpráv, server o jejich příjem.

Současná řešení poštovních bran umí řešit transformaci elektronické pošty mezi světem SMTP a X.400.

Organizace provozující elektronickou poštu by měl mít alespoň jednoho poštovního "guru". Umožní to soustředit zkušenosti pošťáka na poštovní bránu, i když vnitřní sítě jsou plně propojeny se sítí Internet. Administrátoři vnitřních sítí mohou pak předat jejich poštu pošťákovi činnému na poštovní bráně. Poštovní brána zaručí, že odesílaná pošta bude mít záhlaví odpovídající normám. Problémy s poštou lze oznamovat na jedno místo a zde je rovněž řešit. Poštovní brána j rovněž ideální místo pro udržování náhradních jmen, alias, uživatelů v organizaci.

Ve většině unixových implementací je SMTP implementován v programu sendmail. Je to ovšem velmi primitivní a přitom obrovský nástroj svým rozsahem — desítky tisíc řádků v C jazyku často běžících pod vlastnictvím správce systému, superuživatele. Je obtížně konfigurovatelný, konfigurace je předepsána spoustou pravidel a knihy popisující konfiguraci jsou rozsáhlé. Existují i jiné poštovní programy. Je potřeba používat nějaký program pro řízení koncového rozhraní SMTP, které by nemělo být rozhraním superuživatele a z hlediska bezpečnosti by nemělo používat žádné příkazy, které usnadňují útok proti vnitřnímu systému.

2.4.10 MIME

MIME (Multipurpose Internet Mail Extension) je standardní rozšíření SMTP pošty o možnost přenosu textových zpráv vyjádřených v jiných abecedách než ASCII, obrázků, audio informace, video informace, postscriptových souborů, formátovaných zpráv v SGML jazyce (Standard Generalized Markup Language), segmentovaných zpráv do více dopisů, externích zprávy z určeného ftp serveru, téže zprávy více způsoby zakódované, paralelně zpřístupňovaných zpráv apod.

Základním nástrojem pro přenos jiných než ASCII textů systémem MIME je kódování označované jako base64. Princip je velmi jednoduchý: Skupiny 24 bitů se rozdělí na šestice, které se zakódují znaky ASCII abecedy. Hodnotě 0 odpovídá A, 1 odpovídá B, pak se pokračuje přes Z, a,, 0,, 9, +, /. Pokud zpráva končí 16 nebo 8 biticí, indikuje se to znaky ==, resp. =.

Systém MIME umožňuje používat ještě čtyři další kódovací systémy textu. Obrázky jsou přenášeny ve formátu GIF nebo JPEG, video ve formátu MPEG.

2.4.11 PGP

Systém elektronické pošty PGP je poštovní systém, který poskytuje svým uživatelům služby utajení, autentizace (pomocí asymetrické kryptografie veřejným a privátním klíčem), nepopiratelnosti činnosti (pomocí digitálních podpisů) a komprese dat při přenosu. Jedná se o nenormovaný poštovní systém, bezplatně dostupný jako sdílený softwarový modul.

2.4.12 PEM

Systém elektronické pošty PEM je poštovní systém, který poskytuje svým uživatelům služby utajení, autentizace (pomocí asymetrické kryptografie veřejným a privátním klíčem), nepopiratelnosti činnosti (pomocí digitálních podpisů). Jedná se o normovaný poštovní systém sítě Internet. Ve srovnání se systémem PGP je dostupný na méně platformách, nepodporuje jako PGP kompresi dat. Více se opírá o standardní postupy, zná adresování poštovního systému X.400 apod. Pro utajování používá sice standardnějších postupů, ale ne tak silných jako systém PGP.

2.5 Adresářové služby

2.5.1 Kdo je kdo, finger, whois

Základní informační službou o jedincích, uživatelích registrovaných jednotlivých uzlech jsou služby finger a whois. Podle dodaných parametrů poskytnou informaci volajícímu o adresách jednotlivců, jejich aktivitách, tj. zda jsou nebo kdy byli přihlášení do relace, kdy si odebrali naposled poštu apod.

2.5.2 NIS, žluté stránky

Aplikací, opřenou o volání vzdálených procedur firmy SUN Microsystem, je služba původně nazývaná YP, (Yellow Pages), nyní NIS (Network Information Service). Princip NIS je založen na distribuci důležitých bází dat z centrálního serveru k jeho klientům. Mezi takové informace patří soubor s hesly, tabulka adres uzlů, databáze tajných šifrovacích klíčů použitých pro zabezpečení vlastního RPC apod. K takovým strukturám lze přistupovat na bázi použití vyhledávání podle klíče nebo lze přenášet celé soubory.

2.5.3 Doménové adresování

Doménové adresování DNS, Domain Name Service, je technika zobrazování symbolických jmen uzlů v síti Internet na jejich síťové adresy a naopak. Zobrazení je implementováno tak, že uzel zasílá UDP datagramový dotaz na DNS server. Server odpovídá buďto odpovědí na dotaz nebo identifikací chytřejšího DNS serveru. Dotazy lze klást rovněž pomocí TCP spojení, ale TCP spojení jsou vyhrazena spíše pro zónové přenosy.

Zónový přenos používá záložní DNS server při získávání kopie jeho části prostoru jmen.

Prostor jmen DNS je strukturovaný do hierarchické formy - z do topologického hlediska stromu. Aby se s ním dalo snáze manipulovat, lze péči o podstromy delegovat na samostatné DNS servery. Používají se logické odlišné stromy. První zobrazuje jména typu fi.muni.cz na adresy typu 190.20.225.3. K tomuto zobrazení lze přičlenit řadu volitelných informací o jednotlivých uzlech, o tom jak zacházet s elektronickou poštou pro tyto uzly apod. Druhý strom je určen pro zpětné dotazy na síťové adresy odpovídající daným doménovým jménům. Mezi oběma stromy není podporován žádný vztah, i když je pravda, že existují snahy u některých služeb takové vazby udržovat.

· V DNS databázi se pamatuje více rozličných informací. Jako příklad lze uvést:

· A: adresa uzlu,

· NS: jméno DNS serveru, deleguje podstrom na jiný server,

· SOA: vrchol jisté (pod)hierarchie, start of authority; označuje začátek
podstromu, obsahuje cashe paměť a konfigurační parametry, uvádí
adresu osoby odpovědné za danou zónu doménového prostoru,

· MX: poštovní ústředna; jméno uzlu, který zpracovává došlou poštu pro
udaný uzel — udaný uzel lze u dat zástupným znakem, např.
*.muni.cz, pak MX položka přesměrovává elektronickou poštu pro
celý podstrom,

· HINFO: informace o hardware a software uzlu,

· CNAME: náhradní jméno uzlu (alias),

· PTR: pro zobrazování IP adres na DNS jména.

2.5.4 Distribuovaný adresář, ISO norma X.500

Cílem normy X.500 je poskytnout definici platformy vhodné pro tvorbu běžných telematických seznamů, zlatých stránek, e-mailových adresářů, podpory marketingových a inzertních nástrojů, knižních katalogů apod.

Jedná se o mimořádně rozsáhlý globální celosvětový adresář, ke kterému mají přístup jak distribuované aplikační systémy, tak i individuální uživatelé. Je budován na objektově orientované základně jako logická báze dat, jejíž objekty jsou spravovány celosvětově, s rozdělitelnou správní pravomocí s jazykem pro styk typu dotaz-odpověď. Je navržen a budován tak, aby zajistil potřebnou úroveň služeb z hlediska kvality, dá odpověď bez ohledu na lokalitu znalosti, z hlediska konzistentnosti, je optimalizován z hlediska čtecích operací, konektivity, je nezávislý na použité komunikační platformě LAN, WAN apod., je definován jako aplikace v 7. vrstvě RM OSI.

Nijak neomezuje hloubku hierarchie identifikace objektů. Atributy objektů lze definovat dynamicky. Distribuci dat řeší jak rozdělením do samostatných fyzických lokalit, tak i replikací frekventovaně použitých dat. Pro údržbu kopií jsou definovány odpovídající protokoly, konzistence se může udržovat jak explicitním změnovým řízením, tak i periodicky. V definici je řečeno, že se akceptuje dočasná částečná nekonzistence dat. Uživatelům se poskytují jejich adresářoví agenti, DUA, Directory User Agent, kteří plní funkci obsluhy rozhraní uživatele a mohou řídit proces vyhledávání. Vlastní báze dat je implementována v distribuovaných adresářových agentech, DSA, Directory Service Agent. Je definován protokol pro styk adresářových agentů a protokol pro styk adresářového agenta s uživatelským agentem. Na řešení dotazu se může podílet i více adresářových agentů. Definice struktury dat je opřena o prezentační principy dané normou ASN.1. Norma X.500 umožňuje dodržovat principy řízení přístupu k objektům a jejich atributům na základě identifikace a autentizace dotazujícího se subjektu.

2.6 WWW

Hypertextový systém World Wide Web je distribuovaným hypertextovým informačním systémem. Je tvořen dokumenty v různých formátech, programy, které tyto dokumenty zpřístupňují — servery, a programy, které je umožňují prohlížet — klienty. Dokumenty mohou obsahovat odkazy na jiné dokumenty, obrázky, multimediální záznamy, databázové aplikace, informační servery, apod. Odkazy mohou být jak lokální, v rámci jednoho serveru, tak vzdálené, na jiné dokumenty jiných WWW serverů. Prohlížeče podporují nejen přístup k serverům WWW, ale také přístup k jiným službám, jako jsou ftp, e-mail, NetNews, gopher, apod. Mnoho serverů umožňuje dokumenty prohledávat a klást dotazy v jednoduchém dotazovacím jazyce.

2.6.1 Architektura

Systém WWW je tvořen servery a klienty. Server WWW je program, přijímající požadavky klienta na dokumenty a odesílající požadované dokumenty klientovi v tom tvaru, jak jsou uloženy. Klient je zobrazovací program, který dovede inteligentně zobrazit dokumenty různých typů. Dokumentem budeme dále rozumět i netextové záznamy, jako jsou zvukový záznam nebo obrázek. Klient a server systému WWW mezi sebou komunikují protokolem http (HyperText Transfer Protocol). Protokol http je v současné době implementován pouze nad protokolem TCP, ale obecně vystačí s libovolným protokolem, který poskytuje spojované služby.

Dokumentem může být prostý textový soubor bez jakýchkoli dodatečných pokynů pro formátování, ale také hypertextový dokument, který obsahuje formátovací pokyny ve formě značek jazyka HTML (HyperText Markup Language). Jazyk HTML je úzce svázán se systémem WWW, většina dostupných dokumentů je zapsána v tomto jazyce. Základním kamenem, na kterém spočívá hypertextovost systému WWW, je značka , která vkládá do textu odkaz na jiný dokument:

<a href="anotherdoc.html">Tato část textu tvoří hypertextový odkaz</a>

Vymezenou část textu zobrazí klient zvýrazněně a uživatel je tím informován, že stisknutím tlačítka myši nad tímto textem aktivuje jiný dokument. Odkazy mohou směřovat na dokumenty, umístěné na jiných serverech. U těchto odkazů musí být uvedena rovněž adresa serveru a jméno přenosového protokolu pro získání dokumentu. Pro tento účel byl zaveden zápis jména ve tvaru URL.

2.6.2 URL

URL (Uniform Resource Locator) je jednoznačným popisem umístění informace v počítačové síti. Zápis obsahuje všechny informace potřebné pro přístup k dokumentu, včetně přístupového protokolu, kterým jej lze vyžádat. Formát URL je definován takto:

scheme:scheme-specific-part

kde scheme je identifikace přístupového protokolu a scheme-specific-part je část závislá na typu protokolu Pro protokoly, používané v prostředí sítě Internet, má protokolově závislá část tvar:

//user:password@host/path

V odkazech na hypertextové dokumenty se většinou vyskytuje část host (jméno serveru) a path (přístupová cesta k dokumentu). Jméno (user) a heslo (password) bývá používáno při přístupu k poštovním schránkám nebo při přenosu souborů protokolem ftp. Význam části path závisí na protokolu. Pro protokol ftp je zde přímo jméno souboru, pro news jméno konference, apod. U protokolu http je zde úplné jméno souboru dle běžných konvencí systémů Unix s tím, že vrchol stromu dokumentů začíná v adresáři, který je dán konfigurací serveru (neodpovídá tedy vrcholu adresářového stromu). Server neumožní přímý přístup k souborům, které se nacházejí mimo strukturu uvedeného adresáře a jeho podadresářů.

Normou je definován pouze absolutní URL, tedy odkazy, které obsahují plnou adresu umístění. U absolutního odkazu musí být uvedeno minimálně jméno uzlu host a přístupová cesta path, začínající lomítkem. V hypertextových dokumentech jsou však běžně používány zkrácené odkazy, u kterých se předpokládá, že odkaz směřuje relativně vzhledem k umístění dokumentu, ve kterém je odkaz použit. Relativním odkazem lze zkrátit zápis odkazu a zároveň učinit dokument nezávislým na konkrétním umístění. Pokud jsou odkazy na všechny návazné soubory relativní, není problém přesunout kompletní podstrom někam jinam.

Dokument může být dostupný různými protokoly, například file, http, ftp a při použití relativního odkazu je pak použit stejný protokol, jako byl použit pro získání dokumentu, ze kterého odkaz vede. Pokud by byly odkazy absolutní, mohly by být odkazované dokumenty nedostupné.

2.6.3 Jazyk HTML

Hypertextové dokumenty systému WWW jsou psány v jazyce HyperText Markup Language (HTML). Dokument v jazyce HTML obsahuje kromě vlastního textu dodatečné informace potřebné pro jeho zobrazování, odkazy na obrázky vložené přímo do textu a odkazy mimo zobrazovaný dokument.

Jazyk HTML je stále ve vývoji a každý měsíc se objevují nové a nové návrhy na rozšíření jazyka. Otázkou zůstává, které z nich se uchytí a budou podporovány většinou dodavatelů prohlížečů. Původně jednoduchý jazyk se postupně stává stále složitějším a tím se také stává stále náročnějším vývoj nových prohlížečů, které navíc nabývají na velikosti a vyžadují silnější hardware. Zatímco v počátcích vývoje systému WWW stály velké firmy stranou, dnes se zapojují do vývoje a také do konkurenčního boje o trh. Tím jsou dány některé snahy o úzce firemní řešení na úkor široké kompatibility a přenositelnosti dokumentů, která byla původním cílem projektu.

3. Bezpečnostní vlastnosti informačních systémů

3.1 Bezpečnost, bezpečnostní politika

3.1.1 Základní pojmy

Nejprve si vysvětlíme problematiku bezpečnosti informačního systému, dále jen IS obecně, v následujících článcích se pak zaměříme na prostředí počítačových sítí. Informační systém se bude pro počátek skládat z následujících komponent

· hardware — procesor, paměti, terminály, telekomunikace,

· software — aplikační programy, operační systém,

· data — pamatovaná v databázi, výsledky,

· lidé — uživatelé, personál.

Prvé tři z nich nazveme aktiva. Aktivy IS tedy je tedy vše, co můžeme charakterizovat jako hardware, software nebo data.

Problém bezpečnosti IS budeme probírat bez ohledu na jeho interpretaci, není podstatné, zda je IS orientován na výzkum a vývoj, řízení burzy, bankovní systém, získávání dat, personální agendu, konstrukční systém, knihovní systém, regulační systém, systém řízení podniku nebo na něco jiného. Pojmem bezpečnostní politika značujeme souhrn norem, pravidel a praktik definujících způsob správy, ochrany, distribuce citlivé informace a jiných aktiv v rámci činnosti IS. Citlivé informace mají z hlediska chodu organizace zásadní význam, jejich kompromitací, zneužitím apod. by vznikla organizaci škoda. Je třeba si uvědomit, že každý IS je zranitelný, bezpečnostní politika pouze snižuje pravděpodobnost úspěchu útoku proti IS nebo nutí útočníka vynakládat více peněz nebo času. Absolutně bezpečný systém neexistuje. Když analyzujeme IS z hlediska potřeb jeho zabezpečení, rozpoznáváme

· objekt IS — pasivní entita, která obsahuje/přijímá informace, je zpřístupňovaná subjekty IS (udělováním práv přístupu subjektům)

· subjekt IS — aktivní entita (osoba, proces nebo zařízení činné na základě příkazu uživatele) autorizovatelná pro získání informace z objektu, vydávání příkazů ovlivňujících udělení práv přístupu k objektu, změnu stavu objektu apod.

Pojmem autorizace rozumíme určení, zda subjekt je důvěryhodný pro jisté činnosti. Důvěryhodný IS, subjekt nebo objekt je taková entita, o které se věří (je o tom podán důkaz), že je implementovaná tak, že splňuje svoji specifikaci vypracovanou v souladu s bezpečnostní politikou. Na důvěryhodnou entitu se můžeme spolehnout, chová se tak, jak očekáváme, že se bude chovat.

Slabinu IS využitelná ke způsobení škod, ztrát útokem na IS nazýváme zranitelné místo. Existence zranitelných míst je důsledek chyb v analýze, v návrhu a/nebo v implementaci IS, důsledek vysoké hustoty pamatovaných informací, složitosti software, existence skrytých kanálů pro přenos informace jinou než zamýšlenou cestou apod. Podstata zranitelného místa může být

· fyzická — umístění dostupné sabotáži a/nebo vandalismu

· přírodní — objektivní důvody vyvolané záplavou, požárem, zemětřesením, bleskem, výpadkem napětí,

· v hardware (fyzická) nebo v software (logická)— poruchou ochrany paměti softwarová "zadní vrátka", špatným propojením bezpečných komponent, ztrátou, poškozením, zničením média nebo nedokonalým zrušením informace na něm,

· fyzikální — vyzařováním, při komunikaci, útokem na zprávy, na spoje v lidském faktoru — největší zranitelnost ze všech možných variant.

Jako příklady typických zranitelných míst v operačních systémech lze uvést:

· okamžik identifikace a autentizace — podvržený program login (trojský kůň) umí ukrást heslo,

· nedokonalá implementace bezpečnostního mechanismu,

· chybný předpoklad důvěryhodnosti — předpokládá se správnost jiného programu, místo aby se pečlivě testovala správnost jím dodávaných parametrů,

· skryté sdílení — systém může ukládat kritické informace do adresových prostorů procesů, aniž by to bylo definováno, v manuálu (tajné usnadnění implementace, chyba návrhu, )

· komunikace mezi procesy — testování zasíláním a čtením zpráv až do získání odpovědi "OK",

· přerušení komunikačního spojení — vetřelec nahradí původní spoj svým spojem,

· rezidua (nezničená informace v uvolněných prostředcích),

· nekontrolované počty opakování pokusů.

Hrozbou je potenciální možnost využití zranitelného místa k útoku, ke způsobení škody na aktivech. Existence hrozby představuje riziko. Hrozby lze kategorizovat na:

· přírodní, fyzické hrozby — požár, povodeň, výpadek napětí, poruchy,, u kterých je prevence obtížná, u kterých je třeba řešit spíše minimalizaci dopadů vhodným plánem obnovy, tj. je třeba vypracovat havarijní plán havarijní,

· neúmyslné hrozby neškolený uživatel / správce,

· úmyslné hrozby

· vnější útočníci — špióni, teroristi, kriminální živly, konkurent, nabourávači (hackeři),

· vnitřní útočníci — 80 útoků je vedeno zevnitř - propuštěný, rozzlobený, vydíraný, chamtivý zaměstnanec,

· kombinace obou typů útočníků je velmi efektivní z hlediska vedení útoku.

Útokem, který nazýváme rovněž bezpečnostní incident rozumíme využití zranitelného místa ke způsobení škod/ztrát na aktivech IS. Rizikem rozumíme pravděpodobnost, že se využije zranitelnost IS a uplatní se hrozba útokem.

Abychom mohli vybudovat zabezpečený IS, je třeba znát:

· jeho typická zranitelná místa,

· jak je lze využít, formy útoků,

· kdo je využívá, kdo jsou vetřelci, útočníci,

· s jakou pravděpodobností dojde k útoku,

· jak se lze proti útokům bránit,

· jaké lze útoky způsobit škody.

Jako příklady útoků na operační systém lze uvést

· využití asynchronnosti multitaskingu, kdy řádný proces provede kontrolu parametrů, pak v přerušeném procesu vetřelec nahradí parametry a poté teprve se pokračuje ve zpracování,

· prohlížení pamětí, systému souborů,

· využití neodstraněných ladících vstupních bodů,

· způsobení odmítnutí služeb autorizovaným uživatelům, monopolizací aktiv IS, např. rekursivním generováním procesů,

· maškaráda, vystupování vetřelce v identitě autorizovaného uživatele,

· podplacení/podvedení operátora/obsluhy,

· využití časových limitů pro indikaci rozpadu spojení.

Obranným prostředkem jsou protiopatření, která mohou být

· administrativní,

· fyzická,

· logická, může jím být nějaký

· mechanismus — administrativní akce, zařízení, procedura apod.

Protiopatření mohou dáke být

· preventivní, odstraňující zranitelná místa,

· heuristická, snižující riziko dané hrozbou,

· detekční a opravná, minimalizující účinek útoku.

Pod pojmem počítačová bezpečnost rozumíme ochranu informace pamatované v počítači. Vedle toho je součástí bezpečnosti IS i komunikační bezpečnost, tj. ochrana informace přenášené mezi počítači, fyzická bezpečnost, tj. ochrana před přírodními hrozbami a fyzickými útočníky personální bezpečnost, tj. ochrana před vnitřními útočníky apod. ISO a ECMA definuje bezpečnost jako

· zajištěnost proti nebezpečím, minimalizaci rizik a jako

· komplex administrativních, logických, technických a fyzických opatření pro prevenci, detekci a opravu nesprávného použití IS.

Bezpečný IS je IS zajištěný fyzicky, administrativně, logicky i technicky. IS je třeba zabezpečovat, protože se jedná o ochranu investic, neboť informace je zboží, nutí k tomu právní a/nebo morální pravidla, činnost konkurence a zákonné úpravy pro ochranu dat. Bezpečnost IS je dána

· zajištěním důvěrnosti — k aktivům IS mají přístup pouze autorizované subjekty

· zajištěním integrity, autenticity — aktiva IS smí modifikovat pouze autorizované subjekty a je ověřitelný původ informace

· zajištěním dostupnosti — aktiva IS jsou autorizovaným subjektům do určité doby dostupná, nedojde tedy k odmítnutí služby, kdy subjekt nedostane to na co má právo

Možné formy útoků jsou:

· přerušením — útok na dostupnost, ztrátou, znepřístupněním, poškozením aktiva, porucha periférie, vymazání programu, vymazání dat, porucha OS,

· odposlechem — útok na důvěrnost, neautorizovaná strana si zpřístupní aktiva, okopírování programu, okopírování dat,

· změnou — útok na integritu, případ, kdy neautorizovaná entita zasáhne do aktiva změna pamatovaných a/nebo přenášených dat, přidání funkce do programu,

· přidáním hodnoty — útok na integritu, autenticitu, případ, kdy neautorizovaná strana něco vytvoří, podvržení transakce, dodání dat.

Útok může být

· úmyslný,

· náhodný.

Útok může být charakterizován jako

· útok s velkou škodou — je-li častý, pak si organizace vypracovává bezpečnostní politiku, jinak škodu řeší pojištěním,

· útok s malou škodou— způsobené škody jsou přijatelným rizikem.

Útok může být jemněji charakterizován rovněž jako

· útok nevýznamný,

· útok významný nebo jako

· útok katastrofický, jehož následky znamenají zhroucení organizace, trestní odpovědnost apod.

Útok lze dále hodnotit jako

· útok pasivní — kdy se provádí de facto pouze odposlech, kdy je vhodná prevence, protože detekce takových útoků je obtížná, nebo jako

· útok aktivní — pak se jedná o útok přerušením, modifikací dat, přidáním hodnoty apod.

Absolutní prevence útoků není možná, typický postup ochrany je založen na detekci útoku, na následné obnově činnosti a nakonec je třeba si zapamatovat poučení. Útok může být veden

· na důvěrnost,

· na integritu útok nebo

· na dostupnost, např. na odmítnutí služby.

Rozpoznáváme

· útok na hardware

· přerušením — přírodní havárie, neúmyslné útoky kouřením, údery, úmyslné útoky krádeží, destrukcí apod.,

· odposlechem — krádež času procesoru, místa v paměti,

· změnou režimu činnosti,

· útok na software

· přerušením — mezi neúmyslné útoky patří vymazání software, protože není k dispozici konfigurační systém a/nebo archivační systém, použití neotestovaných programů, chyby, mezi úmyslné útoky patří např. vymazání programu,

· odposlechem — kam se řadí provedení neoprávněné kopie programu,

· změnou — programu, využitím zadních vrátek,

· přidáním hodnoty — vir, červ, trojský kůň, logická bomba,

· útok na data — zatímco útok na hardware lze vyřešit bezpečnostními systémy, strážemi apod. a útok na software znamená především únik jen mezi profesionály, tak útok na data, je mnohem nebezpečnější, poněvadž umí číst a interpretovat kdokoli. Pro hodnotu dat je charakteristická dočasnost hodnoty. Tržní hodnota obsahu není jedinou cenou dat, do té se musí zahrnout cena rekonstrukce, cena jejich opětovného vytvoření. Útoky na data lze vést

· přerušením — mezi neúmyslné útoky lze zařazovat jejich vymazání, poněvadž není k dispozici jejich archivační systém, mezi úmyslné útoky pak úmyslné vymazání, sabotáž,

· odposlechem — jedná se o porušení důvěrnosti, krádež kopií,

· změnou — porušení integrity, neautorizované modifikace dat.

· přidáním hodnoty — salámový útok, generování transakcí atd.

Důležité je si uvědomit kdo může útočit? Útočník může být vnější, ale často se vyskytuje i vnitřní útočník v organizaci. Podle znalosti a vybavenosti rozeznáváme:

· útočníky slabé síly — amatéři, náhodní útočníci, využívající náhodně objevená zranitelná místa při běžné práci, jedná se náhodné/neúmyslné útoky, útočníci mají omezené znalosti, příležitosti i prostředky, stačí přijmout relativně slabá, ale zato levná protiopatření

· útočníky střední síly — hackeři, koumáci, hračičkové, typicky VŠ/SŠ studenti, "psychopati", jejichž krédem je dostat se k tomu, na co nejsem autorizován, to přece musím rozluštit (puzzles); jedná se běžné útoky, útočníci mají mnohdy hodně znalosti, ochranu proti nim se přijímají protiopatření střední síly,

· útočníky velké síly — to jsou profesionální zločinci, kteří mají původ obvykle mezi počítačovými profesionály, je pro ně typická neomezenost znalostí, mají dostatek prostředků (peněz), a mnohdy i dost času, provádějí útoky vymykající se běžné praxi, je nutno přijímat silná protiopatření.

Když zabezpečujeme IS, je třeba nejprve stanovit bezpečnostní cíle a způsob jejich dosažení. Bezpečnostní cíle jsou dílčí přínosy k bezpečnosti, kterou dosahuje IS z hlediska udržení důvěrnosti, integrity a pohotovosti, resp. dostupnosti. Při jejich plnění se používají funkce prosazující bezpečnost. Patří mezi ně každá jednotlivá funkce IS, která bezprostředně přispívá ke splnění některého bezpečnostního cíle. Jako příklady si můžeme uvést funkce

· identifikace a autentizace,

· autorizace, tj. určování pravomocí,

· utajování, tj. zajištění, že objekt je známý pouze autorizované množině subjektů,

· řízení přístupu k objektům a subjektům,

· řízení opakovaného užívání objektů,

· účtovatelnosti, tj. získání záruky, že lze učinit subjekty zodpovědné za své aktivity,

· auditu, manuální nebo automatické zkoumání auditního záznamu, tj., protokolu o relevantních událostech v IS z hlediska bezpečnosti,

· nepopiratelnost vykonání akce a/nebo doručení zprávy,

· zajištění integrity atd.

Pro implementaci funkcí prosazujících bezpečnost se používají bezpečnostní mechanismy. Bezpečnostní mechanismus je logika nebo algoritmus, který hardwarově nebo softwarově implementuje funkci prosazující bezpečnost. Rozpoznáváme

· bezpečnostní mechanismy slabé síly — pro ochranu před amatéry, proti náhodným útokům, lze je narušit kvalifikovaným útokem, tj. útokem střední síly

· bezpečnostní mechanismy střední síly — pro ochranu před síly hackery, proti úmyslným útokům s omezenými příležitostmi a možnostmi,

· bezpečnostní mechanismy velké síly — ochrana před profesionály, ochrana proti útočníkům s vysokou úrovní znalostí, s velkými příležitostmi, s velkými prostředky, používajících útoky vymykající se běžné praxi.

Podle okamžiku uplatnění klasifikujeme funkce prosazující bezpečnost a bezpečnostní mechanismy na

· preventivní,

· heuristické a

· detekční a

· zotavující.

Podle způsobu implementace rozeznáváme

· logické bezpečnostní mechanismy (princip řízení přístupu v daném operačním systému, kryptografie — symetrická (s tajným klíčem), asymetrická (s veřejným a privátním klíčem), normy pro návrh, kódování, testování, údržbu programů, ochranné nástroje v operačních systémech, např. ochrana paměti, ochrana souborů řízením přístupu, obecná ochrana objektů, tj. přístupové matice, přístupové seznamy, hesla, autentizace přístupu k terminálu), mechanismy určené pro autentizaci zpráv, administrativní bezpečnostní mechanismy (výběr důvěryhodných osob, hesla, právní normy, zákony, vyhlášky, předpisy), etické normy,

· technické bezpečnostní mechanismy ( šifrovače a autentizační a identifikační karty) a

· fyzické bezpečnostní mechanismy (stínění, trezory, zámky, protipožární ochrana, generátory náhradní energie, chráněná místa pro záložní kopie dat a programů).

Mezi bezpečnostní mechanismy patří pochopitelně i ochranné nástroje v aplikačních systémech.

3.1.2 Řešení bezpečnostní problematiky

Příští článek je věnován systematickému výkladu stanovení bezpečnostní politiky organizace provozující informační systém. V tomto článku si uvedeme zjednodušený příklad.

Bezpečnostní politika vymezuje:

· co chráníme

· proti čemu to chráníme?

· jak to budeme chránit?

Představme si vloupání do počítače, což je analogické vloupání do domácnosti. Ke vloupání do počítače dojde tehdy, když někdo nezákonně vnikne do položky chráněného dokumentu.

· Je to nezákonné, ví se, že to není povoleno.

· Došlo ke vniknutí, příslušná osoba musí vynaložit jistou úroveň intelektuálního výkonu pro získání přístupu.

· Položka je chráněná, systém musí být bezpečný podle nějaké minimální normy bezpečnosti.

Požadavky na bezpečnost mohou vypadat následovně:

1. Požadavkem je, aby počítačové systémy byly optimálně chráněny před přístupem neautorizovaných osob a proti odposlechu.

Počítačovým systémem může být:

· střediskový počítač, server s odpovídajícím komunikačním zařízením a LAN,

· osobní počítače, např. PC v rámci oddělení se strategicky důležitými údaji. Mohou to být ovšem i PC ostatních zaměstnanců, na kterých jsou uchovávána data o síti, statistická data o zařízeních apod.

· Dále platí, že neautorizované osoby lze kategorizovat na vnitřní a vnější vetřelce,

· vnitřní vetřelci jsou z hlediska počítačového zločinu největším nebezpečím, očekávají se od nich podvody; vhodným řešením je vhodné organizační schéma, např. separace řídicích činností a zodpovědností,

· vnějšími vetřelci jsou vesměs hackeři, kteří se snaží narušit přístupová práva, vhodným řešením jsou obvykle technická opatření.

Odposlechem se rozumí vstup neautorizované osoby do komunikačního systému LAN nebo využití elektromagnetického vyzařování z terminálu apod.

· Odposlech Ethernet je možné provést v každém PC pomocí desky rozhraní Ethernet. Odpovídající software je v mnohých verzích mezi veřejně přístupným software. Shromažďováním všech procházejících ethernetovských paketů a jejich následnou analýzou lze získat heslo. Tomu lze zabránit častou změnou hesla a instalací šifrovacích zařízení. Důležitým prostředkem jsou i mosty.

· Všechny terminály vyzařují elektromagnetickou energii. Toto vyzařování lze sledovat relativně jednoduchými elektronickými přístroji. Lze tomu zabránit instalací "temptest-ovaných" terminálů (terminálů, které vyhovují americké normě TEMPEST, Transient Electro Magnetic Pulse Emanation Standard. Tato norma říká, jak velká energie smí vyzařovat.)

2. Je přijata směrnice k postupu náhrady kapacity pro případ kalamity. Detailní popis postupu definuje havarijní plán.

Co to je vlastně kalamita? Jde o narušení takové podstaty, že nelze použít dále normální řízení činnosti. Kalamitou je např. havárie systémového disku. Kalamitou je rovněž náhlý výpadek centrálního serveru resp. LAN. Kalamitou s mnohem menší pravděpodobností, ale s mnohem dalekosáhlejšími dopady je požár v oblasti počítače. Směrnice stanovuje, že se musí udělat cokoli, aby se zabezpečila kontinuita činnosti.

3. Jsou definovány pokyny pro pravidelné hodnocení a audit bezpečnosti.

Cílem je upřesňování bezpečnostní politiky. Lze zavčas rozpoznat problémy a úzké profily. Půlroční interval je z hlediska postupného upřesňován dostatečný. Konec měsíce je dobrý z psychologického hlediska. Upřesňování lze provádět na konci října z hlediska stanovování rozpočtu pro příští rok a na konci dubna z hlediska upřesňování rozpočtu pro stávající investice. Obsah zprávy bezpečnostních problémech by mohl být následující:

· žurnál: co se stalo,

· přijatá opatření,

· zanesené problémy, úzké profily,

· doporučení pro zlepšení.

4. Do plánu je třeba zahrnout analýzu rizik

Analýza rizik dává odpovědi typicky na následující otázky:

· co se má chránit a proti čemu?

· jaké jsou priority?

5. Odkaz na havarijní plán, který je pravidelně modifikován.

Havarijní plán popisuje jak reagovat na bezpečnostní incidenty, útoky. V pravidelných intervalech se musí testovat všechny definované havarijní postupy. Takové testy lze provádět o víkendech nebo jakou součást instalace důležitého software.

V bezpečnostní politice je uvedeno sdělení o archivačních a záložních prostředcích jak technických, tak i programových. Při koupi osobních počítačů je třeba vzít do úvahy jak problém zálohování, tak i problém virů.

Zálohovací postupy je třeba pečlivě kontrolovat alespoň jedenkrát za rok a vždy po každé důležité změně konfigurace systému. Patří sem:

· přesnost strategických postupů,

· obnova kteréhokoli, libovolného disku,

· odstartování v případě, že je porušen systémový disk,

· přenos jedné nebo několika důležitých aplikací na jiný

· střediskový počítač u jiné společnosti.

6. Indikace, jak jsou dodrženy právní normy z hlediska ochrany osobních dat.

Právní normy týkající se osobních dat mohou po společnosti požadovat jistá opatření. Informace musí být dostatečně chráněna proti úniku. Zvláštní pozornost musí být věnována přesnosti takových dat. Jen taková bezpečnostní politika dává dostatečné záruky za dodržení právních norem.

7. Prevence, detekce a zvládnutí virů.

Viry jsou konkrétní hrozbou malých i velkých počítačů. Virus může způsobit mnoho a mnoho různých událostí. Může např.:

· zrušit soubory na disku,

· změnit některé databázové soubory,

· změnit data na disku tak, že PC nelze dále použít,

· paralyzovat odbočkovou síť kdekoli ve světě.

Zmíněné události se často vyskytnou v nějakém konkrétním okamžiku, např. 1. dubna nebo v pátek třináctého. To jsou nebezpečná data. Velký počet PC najednou přestane pracovat, to může být chápáno jako kalamita. Opatření proti virům často leží v oblasti preventivních opatření, jsou založena na jejich detekci a jejich odstranění. Prevence může být realizována informováním vlastníků PC. Musí se pamatovat na vlastníky soukromých PC. Je třeba upozornit na tuto problematiku na všech uživatelských kursech. Užitečné jsou informace sdělované ve zpravodaji společnosti. Uživatelům může pomoci zpřístupnění antivirového software. Pro sledování problémů s viry je třeba udržovat přehled obsahující datum, typ viru a místo infekce.

8. Existují speciální opatření, která nespadají do výše zmíněných bodů.

Data, zprávy a jiné dokumenty mohou mít důvěrný charakter. Nikdo si není jistý, co se může stát s klasifikovanou dokumentací. Pojem tajný může znamenat například, že daný materiál nesmí být kopírovaný, nesmí se zpřístupnit třetí straně, musí být v případě potřeby zničitelný ve skartovacím zařízení. Pokud dokument není tajný a není to na něm vyznačeno, je chápán jako veřejný. To je velmi jednoduchá, ale často velmi praktická a často dostatečná klasifikace. Dokumenty osobního rázu jsou, na druhé straně, automaticky důvěrné. Klasifikovaná data se musí po odpovídajícím využití zničit. Z tohoto hlediska je důležitý nástroj pro skartování papírových dokumentů.

Velkou předností výměnných magnetických médií je, že je lze opakovaně používat. Z tohoto důvodu je ale třeba definovat standardní mazací procedury tak, aby prázdná média byla skutečně prázdná. Za určitých podmínek lze totiž z média, která byla použita pro nahrání dat a poté vymazána, data opětovně přečíst. Média je potřeba podle bezpečnostních postupů po použití přemagnetizovat.

Někdy je třeba dát pevný disk do opravy mimo organizaci. Disk musí být v takovém případě být vymazán velmi přesně specifikovaným čistícím postupem. Nelze toho dosáhnout běžnými softwarovými postupy. Stejný problém se vyskytne v případě, kdy je předáván do opravy osobní počítač.

Magnetické nosiče informací nejsou nesmrtelná. Informace zapsaná na nich po čase mizí, nelze ji přečíst. V pravidelných intervalech musí být proto obnovována. Musí být definován postup, kterým se taková procedura provádí. Důsledky nejsou zanedbatelné. Přepisování může trvat i hodiny a spotřebovává se mnoho člověko-hodin operátora.

Jakmile zaměstnanec končí svůj pracovní poměr, je třeba provést řadu opatření:

· jeho účast na vlastnictví klíčů,

· jeho účast na informačních oběžnících,

· jeho účast na přenosech informací,

· změna hesel,

· zrušení účtů.

To je zvláště důležité, pokud daná osoba měla účet s jistými privilegii. Osoba zodpovědná za bezpečnost musí takové situace velmi pečlivě sledovat.

9 Všechna opatření budou z hlediska této politiky vyhodnocována.

Revizi je třeba provádět periodicky. Opakovaním prováděním analýzy rizik lze bezpečnostní politiku upřesňovat. Lze využít hodnocení zavedené ve třetím bodu výčtu.

3.1.2.1 Závěry

1. Počítačový systém je třeba optimálně chránit před přístupem neautorizovaných osob a proti úniku informace.

2. Je třeba přijmout stanovisko k zálohování pro případ kalamity.

3. Jsou definovány pokyny pro pravidelná hodnocení a audit.

4. Provádí se podle plánu analýza rizik.

5. Je znám odkaz na havarijní plán, který je pravidelně upřesňován.

6. Je dáno najevo, jak jsou z právního hlediska dodržovány předpisy o ochraně osobních dat.

7. Jsou navržena opatření pro prevenci, detekci a odstranění virů.

8. Jsou přijata další speciální opatření.

9. Všechna opatření jsou vyhodnocována z hlediska dosažení cílů stanovených bezpečnostní politikou.

3.2 Stanovení bezpečnostní politiky

Potřebné znalostí týmu pracovníků pracujících na projektu bezpečnostní politiky lze přehledně uvést v následujících bodech:

· řízení přístupu — mechanismy pro zajištění autorizovaného přístupu, omezování vlivu subjektu na chování, užívání, obsah IS, vhodné pro zajištění integrity a důvěrnosti,

· kryptografie — srozumitelný text se převádí na nesrozumitelný a naopak, vhodné pro zajištění integrity a důvěrnosti,

· zvládnutí rizik — proces určování nejistých (nepředvídatelných) událostí ovlivňujících škody na aktivech a určování adekvátních reakcí, identifikace a ohodnocení aktiv, analýza rizik, výběr protiopatření a hodnocení,

· tvorba havarijních plánů — činnost organizace po incidentu,

· klasifikace — určení stupně ochrany před neautorizovaným odhalením informace, určení co je klasifikovaný objekt, citlivý objekt, citlivá informace (jejím neautorizovaným zničením, modifikací, odhalením vzniká škoda),

· bezpečnostní uvědomění — vědomí odpovědnosti, zainteresovanosti zaměstnanců na bezpečnosti organizace,

· počítačová bezpečnost — ochranná opatření zajišťující principy důvěrnosti, integrity, dostupnosti a prokazatelné zodpovědnosti,

· komunikační bezpečnost — integrita a důvěrnost při přenosu dat, využitelnost kapacity spojů,

· architektury bezpečných organizací — vnitřní organizační řád organizace uplatňující bezpečností politiku,

· právní hlediska — zákony, vyhlášky,

· vyšetřování — určování příčin, původu incidentů, hodnocení / analýza bezpečnostních vlastností IS s cílem určení stupně bezpečnosti,

· bezpečnost aplikačních systémů — databáze; údržba, instalace,

· fyzická bezpečnost — opatření nutná pro vytvoření bezpečného

· prostředí pro zpracování informací,

· provozní bezpečnost — bezpečnost provozu, zacházení s médii, činnosti operátorů, správců a uživatelů,

· etika,

· stanovení bezpečnostní politiky,

· hodnocení.

Zásadní požadavky na kvalifikaci projekčního týmu bezpečnostní politiky informačního systému můžeme shrnout do následujících bodů. Projekční tým musí znát:

· bezpečné architektury výpočetních (distribuovaných) systémů,

· struktury bezpečných personálních organizací,

· zásady udržení fyzické bezpečnosti,

· příslušné zákony, vyhlášky, nařízení,

· zásady etiky chování z hlediska manipulace s informacemi,

· způsob zainteresování zaměstnanců organizace na bezpečnosti IS,

· klasifikaci důvěrnosti dat v IS,

· mechanismy řízení přístupu k objektům,

· kryptografické metody zabezpečení integrity a důvěrnosti,

· metody zabezpečení integrity a důvěrnosti při přenosu dat,

· potenciální hrozby a odpovídající rizika, tj. příčiny incidentů

· zásady tvorby havarijního plánu, tj. plánu činností po incidentech.

Při vypracovávání bezpečnostní politiky se musí se získat znalost

· o tom co se chrání,

· proti čemu se to chrání,

· proč se to chrání,

· jakou to má hodnotu a

· kolik jsme ochotni zaplatit za bezpečnost.

Výsledkem vypracování bezpečnostní politiky musí být mj. stanovené jednoznačné zodpovědnosti a jednoznačně pravomoci.

Vlastní bezpečnostní politika je dokument přijatý vedením organizace, jehož cílem je ochrana majetku, pověsti a činnosti organizace. Musí to být závazný dokument, musí býtpřijat jako vnitroorganizační norma. Musí to být veřejný dokument, normu chování nelze tajit a vystavení bezpečnostní politiky veřejné kritice a útokům může mít jen kladný dopad na její periodické inovace. Je žádoucí, aby to byl stručný, srozumitelný a úplný dokument, veškeré otázky a konflikty musí být možné vyřešit odkazem na paragrafy bezpečnostní politiky. V bezpečnostní politice je potřeba

· jasně stanovit hierarchické vazby zodpovědností a pravomocí,

· specifikovat povinnosti a práva jak pro lidi, tak i pro data.

Bezpečnostní politika neobsahuje jména lidí, jména produktů, jména dílčích norem apod. Je dobře, když obsahuje:

· jasné stanovení účelu,

· kdo klasifikuje data a přístupové cesty,

· kdo (funkce) dělá audit,

· kdo (funkce) za co odpovídá,

· kdo (funkce) definuje cíle a použité normy,

· kdo (funkce) smí ke kterým datům přistupovat,

· kdo (funkce) autorizuje přístup,

· havarijní plán.

Bezpečnostní politika bývá strukturalizovaná do dvou časových rovin:

· Celková bezpečnostní politika — globální popis cílů organizace, jejího IS a zabezpečení, nadčasový dokument vypracovaný pro horizont 5 až 10 let,

· Systémová bezpečnostní politika — popis jak chránit, organizovat, distribuovat aktiva IS, výčet konkrétních bezpečnostních cílů, popis konkrétních hrozeb zjištěných analýzou rizik, popis konkrétních bezpečnostních protiopatření

· fyzická, technická, personální, komunikační bezpečnostní politika — se vypracovávají jako samostatné politiky, pokud si to rozsah a význam odpovídající oblasti vyžaduje,

· specifikace funkcí prosazujících bezpečnost — autorizace, autentizace, audit, klasifikace dat, řízení přístupu atd.,

· kategorie minimální síly bezpečnostních mechanismů — jak implementovat funkce pro prosazení bezpečnosti (šifrování, elektronické podpisy, autentizace zpráv),

· ohodnocení úrovně bezpečnosti — uvedení třídy funkčnosti podle evropských kritérií pro hodnocení bezpečnosti ITSEC Information Technology Security Evaluation Criteria, případně podle oranžové knihy kritérií TCSEC - Trusted Computer System Evaluation Criteria amerického ministerstva národní obrany,

Na dokumentu by měl pracovat bezpečnostní výbor — tým tvořený 5 až 9 lidmi a bezpečnostním ředitelem. V týmu by měl být někdo za systémové programátory, kdo šifrování, protokoly, bezpečnost v OS a sítích, někdo za aplikační programátory, kdo zná bezpečnost na úrovni aplikací, někdo za fyzickou ostrahu organizace, kdo umí řešit reakce na živelné pohromy, terorismus, někdo za uživatele IS, kdo umí posoudit použitelnost přijatých protiopatření a umí vysvětlit, resp. pochopit, co se vlastně žádá, někdo za hardweráře, někdo za oddělení vstupu dat, určitě někdo za management organizace.

Stanovení bezpečnostní politiky není jednorázová záležitost, kvalita bezpečnostní politiky roste s její periodickou inovací. Fáze vývoje bezpečnostní politiky lze shrnout do následujících bodů, které se v tomto pořadí periodicky opakovaně provádějí znovu a znovu:

1. Posouzení vstupních vlivů;

2. Analýza rizik;

3. Stanovení bezpečnostní politiky;

4. Stanovení, provádění a kontrola uplatnění protiopatření,

5. Vyslovení závěrů.

3.2.1 Analýza rizik

Nejdůležitější etapou stanovení bezpečnostní politiky je analýza rizik. Jejím cílem je zjištění hrozeb a rizik, kterým hrozbám je IS vystaven, která proti opatření hrozby odstraní, jaké škody mohou vzniknout a co stojí jednotlivá opatření. Projektant bude v této fázi pracovat s pojmy hrozba, bezpečnostní protiopatření, výše potenciálně způsobených škod, cena bezpečnostního opatření. Především ho bude zajímat jaká jsou rizika jednotlivých hrozeb.

Proč vlastně se musí, resp. je vhodné, zjišťovat rizika? U zaměstnanců podílejících se na analýze se tím zvýší se pocit sounáležitosti s firmou a s informačním systémem. Explicitně se identifikují aktiva IS, zranitelná místa a protiopatření. Inventura dostupných aktiv je v zásadě přínosná. Upřesní se požadavky na bezpečnostní opatření v IS a opodstatní se pořízení některých ochranných opatření. Mnohdy se zjistí nutnost vývoje nových ochranných opatření. Ověří se, zda výše nákladů na zabezpečení IS je úměrná. Postup při analýze rizik lze shrnout do následujících bodů:

1. identifikace a ocenění aktiv,

2. nalezení se zranitelných míst,

3. odhad pravděpodobností využití zranitelných míst,

4. výpočet očekávaných (ročních) ztrát,

5. přehled použitelných opatření a jejich cen,

6. odhad ročních úspor aplikací zvolených opatření.

3.3 Zásady komunikační bezpečnosti podle ISO

Zásady komunikační bezpečnosti podle ISO RM OSI specifikuje dodatek normy ISO 7498 Open System Interconnection nazvaný Security Architecture, RM OSI SA. Základní myšlenkou této architektury je, že veškerá bezpečnostní opatření je třeba přijmout nejníže na úrovni transportu dat, neboť nižší vrstvy, tj. směrování, datový spoj a přenos médiem, nemusí být důvěryhodné. V takovém prostředí podle OSI SA existují následující hrozby:

· maškaráda — skrytí útočníka za cizí identitu,

· odmítnutí služby autorizovanému subjektu,

· zapuzení zprávy — popření zaslání / přijetí právy,

· únik informace porušením důvěrnosti,

· modifikace dat porušením integrity,

· modifikace toku zpráv — změna pořadí zpráv, pořadí odpovědí,

· změna software — Trojský kůň, červ,

· analýza toku zpráv — zjišťování délek zpráv, frekvence jejich zasílání, adresy příjemců a odesílatelů,

· dedukce informace — z veřejných zpráv apod.

· neautorizovaný přístup — porušení autentizační politiky.

3.3.1 Klasifikace bezpečnostních služeb podle ISO/OSI

Mezinárodní standard ISO 7498-2 ISO/OSI Security Architecture definuje základní bezpečnostní služby pro komunikační sítě. Bezpečnostní služby, popsané ve standardu, mohou být v praxi implementovány na různých vrstvách komunikačního protokolu. V souladu se standardem ISO/OSI budeme bezpečnostní služby dělit do následujících skupin:

· služby pro autentizaci,

· služby pro řízení přístupu,

· služby pro zajištění důvěrnosti,

· služby pro zajištění integrity a

· služby pro neodmítnutelnost zodpovědnosti.

3.3.1.1 Autentizace

V počítačových sítích je mnoho typů subjektů, které musí nebo mohou být identifikovány a autentizovány. Jde především o fyzické subjekty (například uzly sítě, směrovače atd.), logické subjekty (typicky procesy) a lidské subjekty (např. uživatele a správce). Identifikací rozumíme určení jednoznačné identity subjektu bez jejího ověřování. Autentizací rozumíme ověření proklamované identity subjektu.

Služby pro autentizaci mají za úkol provádět autentizaci (ověření totožnosti) jedné nebo obou stran při komunikaci. Služby pro autentizaci se dělí na služby Autentizace odesílatele a služby Autentizace spojení. Služby Autentizace odesílatele autentizují pouze odesílatele zprávy a nemusí poskytovat ochranu před duplikováním zpráv útočníkem. Služby Autentizace spojení poskytují autentizaci platnou během celého navázaného spojení a zabraňují duplikování zpráv útočníkem.

3.3.1.2 Služby pro řízení přístupu

Služby, poskytující Řízení přístupu, zajišťují ochranu před neautorizovaným použitím prostředků, dostupných prostřednictvím distribuovaného systému. Tyto služby však bývají málokdy součástí síťových protokolů a často jsou implementovány až v operačním systému nebo aplikaci.

3.3.1.3 Služby pro zajištění důvěrnosti

Tato skupina služeb poskytuje ochranu přenášených dat před neautorizovaným odhalením. Služba pro Důvěrnost přenosu zpráv poskytuje ochranu před neautorizovaným odhalením bez ohledu na navázaná spojení. Proto je tato služba vhodná pro bezkontextové aplikace. Služba pro Důvěrnost spojení zajišťuje ochranu před neautorizovaným odhalením v rámci navázaného spojení. Tato služba vyžaduje navázání spojení. Služba Důvěrnost toku dat (Traffic Flow Confidentiality) má za úkol zabránit útočníkovi, aby ze znalosti toku dat (adresy přenášených zpráv, délky přenášených zpráv, časové intervaly mezi přenášenými zprávami atd.) dokázal odvodit důvěrné informace o přenášených datech. Služba Selektivní důvěrnost má za úkol zajistit důvěrnost pouze některých částí přenášené zprávy.

3.3.1.4 Služby pro zajištění integrity

Tato skupina služeb poskytuje ochranu přenášených dat před neautorizovanou modifikací. Služba Integrita přenosu zpráv poskytuje ochranu před neautorizovanou modifikací bez ohledu na navázaná spojení. Služba Integrita spojení zajišťuje ochranu před neautorizovanou modifikací v rámci navázaného spojení. Tato služba vyžaduje navázání spojení. Služby Selektivní integrita spojení a Selektivní integrita zpráv mají za úkol zajistit integritu pouze některých částí přenášené zprávy.

3.3.1.5 Služby pro neodmítnutelnost zodpovědnosti

Služby Neodmítnutelnost zodpovědnosti odesílatele a Neodmítnutelnost zodpovědnosti doručení slouží k tomu, aby příjemce (odesílatel) mohl prokázat protistraně odeslání (přijetí) zprávy a tím zabránil pozdějšímu popření této akce protistranou.

3.3.2 Implementace bezpečnostních služeb v jednotlivých vrstvách OSI

Následující tabulka ukazuje, ve kterých vrstvách referenčního modelu ISO OSI by měly být jednotlivé bezpečnostní služby implementovány. V této tabulce písmeno A znamená, že tato vrstva je vhodná pro implementaci odpovídající bezpečnostní služby. Z tabulky je zřejmé, že samotná aplikační vrstva 7 může teoreticky implementovat všechny bezpečnostní služby. Z ostatních vrstev jsou nejvhodnější pro implementaci bezpečnostních funkcí vrstvy 3 a 4.

	Vrstva, na které může být služba zajišťována
Bezpečnostní služba	1	2	3	4	5	6	7
Autentizace spojení			A	A			A
Autentizace odesílatele			A	A			A
Řízení přístupu			A	A			A
Důvěrnost spojení	A	A	A	A		A	A
Důvěrnost přenosu zpráv		A	A	A		A	A
Selektivní důvěrnost						A	A
Důvěrnost toku dat	A		A				A
Integrita spojení s opravou				A			A
Integrita spojení bez opravy			A	A			A
Selektivní integrita spojení							A
Integrita přenosu zpráv			A	A			A
Selektivní integrita zpráv							A
Neodmítnutelnost zodpovědnosti odesílatele							A
Neodmítnutelnost zodpovědnosti doručení							A

V dokumentech ISO jsou mimo výše uvedené bezpečnostní služby také definovány bezpečnostní mechanismy, kterými se služby mají implementovat. Jedná se o následující mechanismy:

· šifrování (kryptografické zabezpečení)

· elektronický podpis

· mechanismy řízení přístupu

· integritní mechanismy (kryptografické)

· kryptografická autentizace

· zarovnávání zpráv

· řízení směrování

· notářské služby

Přiřazení bezpečnostních mechanismů jednotlivým službám je následující:

Mechanismus Služba	Šifrování	El. podpis	Řízení přístupu	Integritní mechanismy	Krypt. autentizace	Zarovnávání zpráv	Řízení směrování	Notářské služby
Autentizace spojení	A	A			A
Autentizace odesílatele	A	A
Řízení přístupu			A
Důvěrnost spojení	A						A
Důvěrnost přenosu zpráv	A						A
Selektivní důvěrnost	A
Důvěrnost toku dat	A					A	A
Integrita spojení s opravou	A			A
Integrita spojení bez opravy	A			A
Selektivní integrita spojení	A			A
Integrita přenosu zpráv	A	A		A
Selektivní integrita zpráv	A	A		A
Neodmítnutelnost zodpovědnosti odesílatele	A	A		A				A
Neodmítnutelnost zodpovědnosti doručení	A	A		A				A

3.3.3 Použití ISO služeb pro bezpečnou komunikaci

Bezpečná komunikace v OSI SA je definována tak, že lze důvěřovat, že oba komunikující partneři komunikují se skutečně oznámeným partnerem, byla tedy provedena vzájemná autentizace nebo alespoň autentizace zdroje dat při použití nespojované, datagramové služby, že

· nikdo nemůže provádět odposlech, poněvadž je zajištěna důvěrnost,

· nikdo nemůže přenášenou informaci měnit, poněvadž jsou přijata opatření zajišťující integritu,

· komunikační služby jsou dostupné jen pro autorizované uživatele a bylo tedy aplikováno odpovídající řízení přístupu,

· nikdo nemůže popřít komunikaci, a to tak že je zajištěna jak nepopiratelnost vyslání, tak i nepopiratelnost příjmu.

Bezpečná spojovaná relace podle OSI SA je tvořena následujícími kroky:

1. Navázání spojení se zaručenou vzájemnou autentizací pomocí asymetrické kryptografie, tj. veřejným a privátním klíčem.

2. Při navázání spojení se získají se klíče pro symetrické šifrování tajnými klíči zabezpečujícími integritu a důvěrnost následující fáze.

3. Proběhne přenos informace se zabezpečenou integritou a důvěrností.

4. Spojení se zruší tak, aby v síti nezůstala žádná data.

5. Ověří se ty podepsané informace, u nichž je to předepsáno nebo vyvolána podezřením apod.

Integrita spojení se zajišťuje tak, že buďto postačí tzv.

· slabá integrita, aplikují se kontrolní součty, CRC, číslování zpráv apod. — slabá integrita zajišťuje ochranu proti modifikaci zpráv šumem, proti náhodné změna pořadí, náhodným duplicitám apod., nebo v případě hrozby útoku aktivním vetřelcem se musí použít tzv.

· silná integrita, která je zaručena prostředky pro zajištění slabé integrity doplněné o aplikaci prostředků kryptografie symetrickým klíčem — zabezpečení je důvěrné.

Podíváme-li se na problém, kde lze implementovat funkce a mechanismy OSI SA, pak lze vyslovit následující závěry.

· Pro autentizaci je vhodné využít mechanismy z oblasti asymetrické kryptografie. Oba komunikační partneři se autentizují při vzájemné spojované komunikaci, při nespojované komunikaci se autentizují pouze původce dat. Autentizaci lze implementovat prakticky v aplikační — 7. vrstvě RM OSI.

· Zajišťuje se slabá nebo silná integrita, silná využívá pro utajení kontrolních informací prostředků symetrické kryptografie společně sdíleným tajným klíčem. Integrita se může zajišťovat i s opravami nebo může být bez oprav, pouze detekční. Lze integritně zabezpečovat celé zprávy nebo jen vybraná pole zpráv. Provádět ji lze prakticky nejníže ve 4., transportní vrstvě, vybraná pole zpráv se musí integritně zabezpečovat v 7., aplikační vrstvě

· Pro utajování se opět používá z důvodu rychlosti symetrická kryptografie tajným sdíleným klíčem, může se provádět utajování jak celých zpráv, tak i vybraných polí zpráv, nebo i utajování toku zpráv. Utajování se smí de facto dělat nejníže ve 4., transportní vrstvě, pokud se má uplatnit na vybraná pole zpráv, pak se musí realizovat v 7., aplikační vrstvě

· Neodmítnutelnost, resp. nepopiratelnost se zajišťuje jednak s prokázáním původu a jednak s prokázáním doručení. Princip je opřen o existenci třetí, nezávislé strany, notáře. Je třeba si uvědomit, že autentizace znamená, že vím s kým komunikuji, a nepopiratelnost, resp. neodmítnutelnost, znamená, že vím s kým komunikuji a navíc to mohu dokázat. Implementace nepopiratelnosti je záležitost 7., aplikační vrstvy.

· Pro řízení přístupu se obvykle používají dostupné mechanismy použitých podpůrných operačních systémů, případně se doplňují mechanismy v 7., aplikační vrstvě.

Mezi podporované síťové služby a aplikace z hlediska bezpečnosti patří elektronická pošta X.400, někdy nazývaná rovněž MHS (Message Handling System) nebo MOTIS (Message Oriented Text Interchange System), distribuovaný adresář X.500, systém ovládání souborů FTAM (File Transfer, Access and Management) a elektronická výměna dokumentů EDI{EDIFACT (Electronic Data Interchange). Při použití elektronické pošty X.400 a distribuovaného adresáře X.500 lze počítat s aplikací služeb:

· Autentizace

· autentizace původu zprávy — příjemce může autentizovat odesílatele

· autentizace původu dotazu na doručitelnost zprávy — příjemce získá nepadělatelný důkaz odesílatele (služebního) dotazu

· autentizace původu služební zprávy — odesílatel může autentizovat původce služební zprávy doručeno/nedoručeno

· důkazu odeslání zprávy — odesílatel získá nepadělatelný důkaz, že zprávu odeslal

· důkazu doručení zprávy — odesílatel získá nepadělatelný důkaz, že zpráva byla doručena

· Utajení dat

· Řízení přístupu

· Integrity dat z hlediska obsahu a pořadí zpráv

· Nepopiratelnosti — záruka třetí stranou, notářem, který se neúčastní komunikace

· původu — příjemce získá nepadělatelný důkaz původu, obsahu a klasifikace zprávy

· převzetí do MTS — odesílatel získá nepadělatelný důkaz předání dané zprávy do MTS, tj. svému poštovnímu agentovi

· doručení — odesílatel získá nepadělatelný důkaz doručení zprávy adresátovi

Ve stávajících implementacích X.400 nelze dosud zabezpečit ochranu proti analýze toku zpráv, dát důkaz doručení tajné zprávy do off-line poštovní schránky udržované u poštovního agenta MTA, převzetí zprávy poštovním agentem, je-li zasílána z privátní do veřejné správní domény elektronické pošty.

Adresářový systém X.500 má definovánu normu X.509 pro specifikaci autentizačního prostředí. Umožňuje se slabá autentizace heslem nebo silná autentizace na bázi dokladu vypracovaného pomocí asymetrické kryptografie (veřejným a privátním klíčem).

3.4 Bezpečnost sítě Internet

Síť Internet byla původně navržena jako nástroj určený pro výzkum, ne pro komerční a o legislativu opřenou činnost. Její provoz se tudíž odehrává v jedné úrovni důvěryhodnosti. Bezpečnost z hlediska přístupu vzdálených uživatelů k citlivým a kritickým informacím je opřena o opatření založená na r-příkazů operačního systému BSD Unix (rlogin, rsh apod.). Bezpečnost obecně spoléhá na vzájemné úctě a cti uživatelů a na jejich znalosti potřebného chování se v síti. Jsou dostupné minimální bezpečnostní funkce ve formě heslem chráněných přístupů do uzlů sítě, ty byly do síťových návrhů dodělány dodatečně.

Jak Internet postupně rostla, internetovská komunita se postupně rozšiřovala a bezpečnostní prostředí se ukázalo být nedostatečným. Uplatněné a registrované útoky z posledních několika let využily jednoduchých zranitelných míst, jejichž existence byla a je dána špatně konfigurovanými systémy, chudou funkční bezpečnostní vybaveností software, nedokonalou správou systémů a/nebo opomenutími uživatelů. Znalost možnosti uplatnění těchto útoků vede k použití síťových bezpečnostních mechanismů, jakými jsou oddělovací uzly, firewalls, které chrání individuální síť před nimi.

Propracovanější útoky využily vrozených slabin internetovské infrastruktury. Ty jsou dány především tím, že protokolová sestava TCP/IP, která je použita pro směrování toku informací a jejich případně spolehlivé doručování, je z hlediska vybavenosti bezpečnostními službami velmi chudá. Většina jasných opominutí z hlediska bezpečnosti se vyskytuje v nižších vrstvách protokolové sestavy, včetně v typických hostitelských sítích, jakými jsou ethernetovské sítě, a tudíž tato opominutí ovlivňují všechny aplikace, které používají transportní služby.

Je jasné, že ta zranitelná místa internetovského prostředí, která se vyskytují v poštovních aplikací typu sendmail, která jsou dána implicitní důvěrou předpokládanou v r-příkazech BSD unixu, špatnými konfiguračními technikami v mnohých softwarových balících apod., nejsou těmi nejzávažnějšími problémy z hlediska zajištění bezpečnosti. Zásadní problémy lze shrnout do následujících bodů:

· Odposlouchávání v nízkých vrstvách — Většina protokolů nízkých vrstev, vč. Ethernetu, jsou založeny na přímém všesměrovém vysílání informace. V takovém případě může každý uzel připojený do takové LAN odposlouchávat přenos určený pro jiný uzel ve stejné LAN. V některých případech může odposlouchávat i kterýkoli uzel, který v síti typu WAN leží mezi komunikujícími partnery, např. při styku se vzdáleným poskytovatelem služby. I když většina odposlechů je orientována na odcizení hesla, lze tento útok uplatnit na kterákoli data.

· Autentizace — Žádný protokol v sestavě TCP/IP protokolů neobsahuje autentizaci komunikujících partnerů. Nic neopravňuje věřit pravosti adres uvedených v datových paketech. Aplikovat útok formou maškarády - vydávání se za jinou entitu je snadné.

· Nelze ani autentizovat obsah paketů.—Uplatňují se jednoduché kontrolní součty, ty lze ovšem obelstít velmi snadno. Lze tudíž obsah paketů modifikovat, což může mít katastrofické následky.

· Pořadová čísla — Některé implementace TCP používají snadno odhadnutelné pořadové číslování paketů. Pokud může útočník snadno předpovědět pořadové číslování paketů, pak, ve spojení s nedostatečnou autentizací v TCP, lze snadno udržovat falešná spojení k nepodezřelým systémům, aniž by to způsobilo u legitimních systémů nějaký poplach. Tato spojení mohou využít zranitelná místa systémů a implementovat různá zadní vrátka - back door, která bude možno v budoucnosti využít pro útok.

V prostředí zpracování dat, jejichž citlivost je dána legislativou či komerčními zájmy, lze vznikají problémy ilustrovat následujícími příklady:

· Odposlech — Útok v síti směrovaný na zcizení informace, kterou může být číslo kreditní karty, číslo účtu zákazníka, stav účtu zákazníka, platební příkaz apod. Odposlech lze dále použít pro zcizení informací, které jsou určeny pouze určitou uzavřenou skupinu uživatelů, předplatitelů. V některých případech je bezpečnostním incidentem skutečnost, že se pouze zjistí uskutečnění nějaké transakce mezi zúčastněnými partnery, aniž se potřebuje zpřístupnění jejího obsahu. Lze takto odvodit charakter profilu napadených komunikujících partnerů, dojde k narušení soukromí. Znalost frekvence výměny zpráv mezi dvěmi organizacemi, umožňuje třetí organizaci se nekale chovat na trhu apod.

· Vyhledávání hesel — Vyhledání hesla umožní přístup k systému, ve kterém je uchovávána citlivá informace. Stále šířeji se používají silnější a silnější kryptografické algoritmy a to má za následek, že útoky na zpřístupnění dat se stále více zaměřují spíše než na rozlomení utajovacího systému, tak na zpřístupnění nešifrované informace v chudě chráněném systému.

· Modifikace dat — Útok modifikací dat lze použít pro modifikaci obsahu určitých transakcí, lze změnit informaci o platící straně na elektronickém šeku nebo změnit hodnotu platebního příkazu apod. Modifikaci dat lze uplatnit na objednávky služeb, zboží apod.

· Podvody — Při podvodu jedna strana použije princip maškarády, aby se vydávala za jinou stranu. Lze takto shromáždit tisíce i milióny čísel kreditních karet od důvěřivých zákazníků, vystupovat jako finanční organizace, zdravotnická organizace apod. a shromáždit citlivé / kritické informace od mnoha zákazníků.

· Odmítnutí, popření — Možnost odmítnutí popření účasti na transakci může způsobit zásadní problémy při zpracování citlivých dat. Následkem může být odstoupení od smlouvy apod.

Zatímco oddělovací uzly jsou dobrým nástrojem pro zabezpečení individuálních sítí propojených v rámci Internetu, nezaručí bezpečnost transakcí koncových uživatelů a z hlediska zpracování komerčních a legislativou určených citlivých dat je nelze považovat za adekvátní bezpečnostní funkcionalitu či mechanismus. Ostatní mechanismy, jakými jsou např. jednorázová hesla, řeší pouze část problému (zcizení hesla apod.), ale neřeší bezpečnost celkově. Robustní řešení bezpečnosti v síti Internet musí splnit všechny aspekty bezpečnosti, především:

· Důvěrnost — Veškerá komunikace mezi zúčastněnými stranami je dostupná pouze těmto stranám. Tato důvěrnost má z hlediska zachování soukromí zásadní význam, stejně jako ho má i v oblasti ochrany proprietárních informací a jako odstrašující prostředek proti zcizení informačních služeb. Důvěrnost se obvykle implementuje pomocí kryptografických mechanismů.

· Autentizace — Obě komunikující strany by měly důvěřovat tomu, že komunikují s tím partnerem, se kterým komunikovat chtěly. K tak silné autentizaci je třeba obvykle použít mechanismů elektronického podpisu a certifikátů.

· Integrita dat — Data při přenosu nemohou být změněna. Data nelze modifikovat ani v místě jejich uložení v paměti. Pro zajištění integrity dat lze použít mechanismů kryptografických kontrolních součtů a elektronického podpisu a certifikátů na bázi asymetrické kryptografie.

· Nepopiratelnost — Žádná z komunikujících stran nesmí mít možnost popřít svoji účast v transakci po jejím ukončení.

· Výběrové řízení přístupu — Mnohdy může být žádoucí, aby část transakce byla ``neviditelná'', zatímco její zbytek může být veřejný.

Prakticky všechna uvedená hlediska bezpečnosti v síti Internet jsou přirozenými standardními požadavky na bezpečnost zpracování komerčních a legislativně citlivých informací. Výběrové řízení přístupu k transakcím umožní např. zákazníkovi svoje identifikační informace o kreditní kartě zabalit do elektronické obálky, kterou může otevřít pouze jeho banka, tuto přiložit k objednávce a zaslat oboje prodejci. Prodejce obálku předá bance, která solventnost zákazníka prodejci autorizuje, a tento může pokračovat v prodeji, aniž by mu zákazník zpřístupňoval svoje privátní data.

Pro implementaci uvedených vlastností se obvykle používají kryptografické mechanismy. Existují snahy tyto mechanismy uplatňovat na síťové, IP vrstvě. Existují snahy, o jejich uplatnění i nad transportní vrstvou, z hlediska modelu RM OSI v relační vrstvě. Služby typu ftp, HTTP, telnet apod. bezpečnost uplatňují ve speciálních aplikačních protokolech. Existují řešení pro zabezpečení obsahu dokumentů (např. aplikačně nezávislé platební protokoly), které sídlí nad existujícími aplikačními protokoly.

Optimální volba místa uplatnění bezpečnostních prvků do protokolové sestavy je sporná. Pokud jsou volena v nízkých vrstvách, mohou být uživatelům transparentní, zabije se tak více much jednou ranou. Musí se však na této úrovni dělat mnoho činností a řešení na úrovni aplikace (chráněná vybraná pole, individuální metody např. v HTTP apod.) je mnohdy výkonnější. Základním myšlenkám vybraných metod zabezpečení sítě Internet budeme věnovat následující odstavce.

3.4.1.1 Implementace bezpečnosti v síťové vrstvě Internet

Byly zahájeny práce na definici protokolů příští generace, např. na protokolu IPv6. Ve stávajících IP protokolech se uplatnily následující mechanismy:

· Autentizační záhlaví IP paketu, AH, které zabezpečuje autenticitu a integritu pomocí hašovacího algoritmu MD5.

· Důvěrnost prostřednictvím uplatnění algoritmu DES Data Encryption Standard, řešení nazvané ESP, Encapsulating Security Payload.

3.4.1.2 Implementace bezpečnosti v relačních vrstvách

Z hlediska protokolové sestavy je lépe hovořit spíše o implementaci bezpečnostních služeb těsně nad transportní vrstvou, neboť model TCP/IP jako takovou relační vrstvu nezná.

Netscape v r. 1994 uvedla protokol SSL - Secure Socket Layer, který poskytuje bezpečnost právě nad TCP službami pomocí kombinace asymetrické a symetrické kryptografie. Zabezpečuje důvěrnost, integritu dat, autentizaci serveru a volitelně i klienta. Proč volitelnost u klienta? Poněvadž podpora klientské autentizace požaduje použití individuálních dvojic klíčů asymetrické kryptografie pro každého klienta a poněvadž podpora SSL je zabudována do programu Netscape Navigator, snad nejpopulárnějšího prohlížeče internetovské sítě, a poněvadž pro klientskou autentizaci je potřeba zahrnout distribuci certifikátů veřejných klíčů pro každého Netscape uživatele na Internetu. Krátce řečeno, věřilo se, že méně kritický problémem je nejistota zákazníků s kým jsou vlastně ve styku, než řešení, které nedá takové záruky prodejcům. Dále, poněvadž počet serverů na Internetu je mnohem menší než počet klientů, je snažší vybavit potřebnými nástroji pro správu digitálních podpisů a správu klíčů servery. Podpora klientských dvojic klíčů ovšem stále roste a uplatňuje se ve stále více implementacích SSL. V této době podporují SSL i jiné webovské prohlížeče. Internetovská norma popisující SSL je dostupná od konce r. 1995.

Koncem r. 1995 zavedl podobný protokol jako SSL i Microsoft. Nazývá se PCT - Private Communication Technology, provozně je s SSL kompatibilní, řeší některé nedostatky SSL.

IETF (Internet Engineering Task Force) navrhla několik protokolů pro distribuci klíčů v Internetu v rámci TCP/IP aplikací. Pro tyto protokoly je charakteristické zavedení bezpečné relace, security association, mezi dvěma uživateli nebo systémy. Protokoly jsou stále v procesu vývoje. Lze uvést příklady:

· SKIP — Simple Key Exchange for Internet Protocol. SKIP používá pro výměnu dlouhodoběji používaných klíčů symetrické kryptografie mezi dvěma komunikujícími partnery mechanismus asymetrické kryptografie. Certifikáty se získávají pomocí zvláštního protokolu opřeného o přenos datagramů, tj. o protokol UDP.

· Photuris — jestliže někdo rozlomí SKIP klíč pro symetrickou kryptografii, může si zpřístupnit veškerou informaci zašifrovanou tímto klíčem. Photuris proto používá dlouhodobý klíč pouze pro získání autentizace klíče jedné relace, zaručuje tak dlouhodobou bezpečnost. Za cenu jistého snížení efektivnosti SKIP systému.

· ISAKMP — Internet Security Association and Key Management Protocol. Jedná se, narozdíl od systémů SKIP a Photuris, o generické prostředí pro správu klíčů, ani ne tak o protokol správy klíčů. Není vázáno na konkrétní kryptografické algoritmy či protokoly. Jedná se o obecnější přístup.

SSL je konkrétní řešení, není obecné z hlediska dalšího vývoje, neumožňuje modifikaci individuálních aplikačních protokolů. Morálně zestárne, s modernějšími architektonickými řešeními bezpečnosti v Internetu však bude dlouhodobě kooexistovat.

3.4.1.3 Implementace bezpečnosti v aplikačních vrstvách

Do této oblasti patří standard Internet pro bezpečnou elektronickou poštu PEM, definovaný v r. 1993. Asi se moc nerozšíří. Dále do této oblasti patří rozšíření MIME poštovního systému, MOSS - MIME Object Security Services. MIME pracuje i s netextovými zprávami. Výrazně se rozšiřuje uplatnění poštovního systému PGP. V r. 1995 vydala další normu bezpečné pošty RSA, S/MIME. Podporu S/MIME vyjádřilo už mnoho výrobců poštovního software.

Další aplikační oblastí jsou služby WWW, kde pro zabezpečení připadají do úvahy dva standardy. Nad SSL je definován standard HTTPS, jedná se o implementaci HTTP nad SSL. Dalším standardem je S-HTTP, z r. 1994. S-HTTP poskytuje stejně jako SSL důvěrnost, integritu dat, autenticitu serverů a volitelně klientů. Jedná se o rozšíření HTTP protokolu, zabudovává bezpečnost do standardního prostředí HTTP.

3.4.1.4 Internetovské platební protokoly

Dosud popsaná řešení zabudovávají bezpečnost do protokolové sestavy TCP/IP. Další třída protokolů se snaží zabezpečit bezpečný přenos privátních informací (čísla kreditních karet, výše účtů apod.) mezi čtyřmi partnery:

· zákazníkem,

· bankou zákazníka, která udržuje jeho účet s kreditní kartou,

· prodejcem a

· bankou prodejce.

Pro tyto protokoly je charakteristické zabezpečení přenosu privátních informací nezávisle na použitých transportních službách, lze je použít v rámci webovských prohlížečů pomocí HTTP, v rámci elektronické pošty na bázi protokolu SMTP apod. Vždy se jedná o bezpečný přenos nezabezpečeným přenosovým systémem. Útočník může získat nejvýše zlomek dat. Typickými příklady jsou:

· SEPP — Secure Electronic Payment Protocol, podporovaný Netscape, IBM a MasterCard SEPP,

· STT — Secure Transaction Technology, podporovaný Visa a Microsoftem STT.

V r. 1996 Visa a Microsoft se domluvily na společném standardu SET, Secure Electronic Transactions.

3.4.1.5 Závěry

Jistou perspektivu mají protokoly SSL a S-HTTP a SET. Výrazným přínosem bude implementace síťového protokolu IPv6, kterou však lze očekávat až za několik let.

3.5 Rozbor vybraných problémů bezpečnosti v síti Internet

3.5.1 Bezpečnostní problematika směrování

Směrovací informace vytváří ve skutečnosti dvě cesty: jednu od volajícího uzlu k cílovému, jednu zpět. Druhá cesta je obvykle reverzí cesty prvé. Pokud se druhá cesta neustanoví, jedná se o asymetrickou cestu cesta asymetrická. Princip asymetrických cest je v zásadě špatný, z hlediska bezpečnosti je zpětná cesta často důležitější než dopředná. Pokud je cílový uzel napaden, kterou cestu k útočícímu uzlu volí zpětně tekoucí pakety? Může-li útočník nějak zničit směrovací algoritmus, může být cílový uzel přelstěn, může si myslet, že útočící uzel je důvěryhodný uzel. Podaří-li se to, selže autentizační mechanismus, který je plně opřen o práci se zdrojovou adresou.

Standardní směrovací algoritmy lze napadnout více způsoby. Nejsnažším způsobem je využití volby v IP paketu označené jako loose source route. Jestliže se při zahájení TCP spojení použije taková volba, lze určit explicitní cestu do cíle, což přebije obvyklý směrovací proces. Podle normy RFC 1122 musí cílový uzel v takovém případě použít jako zpětnou cestu inverzi této cesty, ať to má či nemá nějaký smysl. To má ovšem za důsledek, že útočník se může vydávat za důvěryhodný uzel. Takovému útoku se lze bránit např. zásadním odmítáním přijetí IP paketů s takovou volbou. To dělá řada směrovačů. Jde však o to, že použití této volby může být legitimní, např. při ladění některých síťových problémů. Odmítnutí této volby ztěžuje život jinde. Někdy odmítají tyto pakety pouze některé servery unixových aplikačních funkcí rlogin nebo rshd. Jedná se o slabší ochranu, poněvadž mohou existovat i jiné protokoly s uvedenou zranitelností, které žádné protiopatření nepřijímají.

Útočník se může rovněž zaměřit přímo na směrovací protokol. Je relativně snadné generovat falešné RIP pakety, kterým budou uzly a směrovače věřit. Jestliže je útočící stroj blíže k cíli než originální zdrojový uzel, lze takto snadno změnit tok přenosu IP paketů. Mnohé implementace RIP akceptují určení cest k udaným uzlům, které lze mnohem hůře detekovat.

Některé směrovací protokoly, např. RIP 2 a OSFP podporují používání autentizačního pole. S autentizačními poli však souvisí některé problémy:

· Jediným dosud definovaným autentizačním mechanismem je heslo. Kdokoli kdo je schopen manipulovat se směrovacími protokoly je rovněž schopen shromažďovat hesla např. při jejich přenosu Ethernetovským prostředím.

· Jestliže byl zničen legitimní zdroj ve směrovacím dialogu, potom nelze důvěřovat jeho zprávám, i když správně a legitimně podepsaným původním zdrojem.

· Většina směrovacích protokolů v každém uzlu hovoří pouze se svými bezprostřednímu sousedy, budou tedy nekriticky opakovat to, co ji bylo řečeno. Podvod se tak rozšíří.

Není pravdou, že všechny směrovací protokoly musí mít uvedené nedostatky. Hůře lze napadnout ty, které vedou dialog mezi páry uzlů. Útoku vedenému na pořadová čísla, se však takto zamezit nedá. Silnější ochrana je topologická. Směrovače v takovém případě mohou a musí být konfigurovány tak, že znají přípustné cesty. Není to snadné, tato technika se používá v oddělovacích uzlech.

V IP paketech lze aplikovat bezpečnostní volbu, bezpečnostní návěští. Ta je v současnosti používána především v oblasti vojenství, v oblasti obchodní se prosazuje pomalu. Každý paket je po zavedení této volby označen úrovní citlivostí informace, kterou obsahuje. Toto bezpečnostní návěští dat má jak hierachickou komponentu (tajné, přísně tajné, atd.), tak i volitelné horizontální kategorie (nukleární zbraně, kryptografie apod.). Návěští umožní implementaci jedné z funkcí pro prosazení bezpečnosti funkce pro prosazení bezpečnosti, která se nazývá povinné řízení přístupu. Krátce, její princip je následující:

Bezpečnostní úroveň vysílajícího a přijímajícího procesu je dána klasifikační úrovní procesu - bezpečnostními návěštími procesů. Proces nemůže posílat informaci na nižší úroveň, poněvadž by mohl odkrýt důvěrnou informaci. Dále, proces nemůže číst informace z vyšší úrovně, než na které je klasifikován. Kombinace těchto dvou omezujících podmínek bude obvykle předepisovat, že proces na druhé straně spojení musí být na stejné úrovni klasifikace.

Varianta Unixu Unix System V/MLS udržuje bezpečnostní úroveň pro každý proces. Takové procesy pak mohou ke každému paketu připojovat odpovídající pole volby. Pokud se používají univerzálnější operační systémy, může tuto volbu k paketům přicházejícím z daného uzlu připojovat směrovač.

Uvnitř sítě je hlavním smyslem bezpečnostních návěští omezování směrovacích rozhodnutí. Paket označený jako přísně tajný nesmí např. být vysílán přes nezabezpečený spoj určený pouze pro zasílání důvěrných zpráv. Používají se dále pro řízení kryptografie. Ty stejné pakety lze vysílat přes nezabezpečené spoje, pokud budou šifrovány algoritmem a klíčem, který odpovídá kategorii přísně tajné.

3.5.2 Bezpečnostní problematika doménového pojmenovávání

Pro rychlé získání seznamu cílů útočníci používají zónové přenosy. Dvojí logický strom v DNS databázi může být příčinou problémů. Hacker, který získá přístup k části inverzního stromu, může jej zfalšovat. Inverzní záznam by mohl obsahovat zfalšované jméno uzlu, kterému váš uzel věří. Útočník se pak pokusí vzdáleně přihlásit, rlogin, na stroj, který důvěřuje záznamu a volání bude akceptovat.

Většina novějších systémů je vůči takovým útokům imunní. Po získání údajného DNS jména použijí jméno pro získání množiny IP adres. Není-li na tomto seznamu adresa použitá pro spojení, volání se zruší a provede se záznam o bezpečnostním incidentu.

Lze implementovat kontrolu křížovými dotazy buďto v knihovních podprogramech, které generují jména uzlů ze síťových adres (gethostname v mnoha systémech) nebo v démonech, systémových procesech, které se starají o důvěryhodnost na základě jmen uzlů. Pokud není známo, jak provádí kontrolu operační systém, nelze snadno nahradit jeho části. Nicméně platí, že když kterákoli komponenta detekuje anomálii, měla by to někde poznamenat.

Existuje nebezpečnější varianta tohoto útoku: útočník kontaminuje cashe paměť DNS odpovědí v cílovém uzlu dříve, než se volání zahájí. Když v takovém případě cílový uzel provede kontrolu, vše vypadá úspěšně a vetřelec získá přístup.

Autentizace prováděná pouze na základě jmen je slabá, silnější autentizace je založena na síťových adresách.

Hrozbou je vlastnost mnohých implementací DNS serverů, která umožňuje uživatelům udávat jména bez vyšších hierarchických složek, pokud adresují uzel ve společné zóně. Např. někdo v doméně

kpsk.fi.muni.cz

se pokouší spojit s někým v doméně big.edu. DNS služba se bude pokoušet o

big.edu.fi.muni.cz, big.edu.muni.cz, big.edu.cz

a teprve nakonec o big.edu, což je správná varianta. Jestliže někde vytvořili doménu edu.cz, mohli by přijímat přenos určený pro kohokoli v edu. A pokud se použijí zástupné znaky (*) v udání adresy v DNS databázi, je situace ještě horší.

Autentizace není jediným problémem DNS služby. DNS databáze obsahuje bohatou informaci o každém uzlu: jméno, adresu, organizační strukturu apod. Představte si radost špióna, který by zjistil informace o uzlu xxx.mno.cz a pak by byl schopen získat celou doménu mno.cz, aby se dozvěděl kolik počítačů se používá v rámci Ministerstva národní obrany. Přílišné utajování těchto informací také není dobré. Dobrým řešením jsou zónové přesuny do autorizovaných sekundárních serverů. Chytrý útočník ovšem může použít útok hrubou silou a vyčerpávajícím způsobem prohledávat adresový prostor dotazy inverzními DNS dotazy, které mu budou dávat jména uzlů. Ty pak může prohledávat a získávat pro něj užitečné informace.

3.5.3 Bezpečnostní problematika ARP

3.5.3.1 Co to je ARP

Internetovské adresy identifikují entity na síťové úrovni, protokoly datových spojů protokoly řízení přístupu k médiu LAN je neznají. Každé ethernetovské rozhraní je výrobcem identifikováno jednoznačnou 48-bitovou adresou platnou na úrovni datového spoje a na tuto adresu je třeba zasílat rámce. 32-bitovou IP adresu Ethernet nezná.

Zobrazování IP adres v rámci jedné LAN na ethernetovské adresy řeší protokol ARP (Address Resolution Protocol). V ethernetovském prostředí sběrnice, ve které se signál vysílaný uzlem šíří ke všem ostatním uzlům, předepisuje protokol ARP vyslat zvláštní, typem charakterizovaný, rámec ARP s dotazem Kdo vlastní IP adresu W.X.Y.Z?. Tento rámec dorazí i do uzlu s IP adresou W.X.Y.Z, ten zná adresu přidělenou svému ethernetovskému rozhraní a odpoví rozesláním opět rámce speciálního typu ARP, ve kterém sděluje, že internetovská adresa W.X.Y.Z je zobrazována na ethernetovskou adresu a.b.c.d.e.f. Nic nebrání ostatním uzlům sítě, které ještě toto zobrazení neznají, aby si vazbu mezi oběma adresami zapamatovaly. Hromadnému zapamatování zobrazení konkrétní IP adresy na adresu LAN v datovém spoji napomůže, když odpovídající informaci každý uzel rozešle při svém počátečním zavádění, tj. při spouštění.

Někdy je třeba řešit reverzní problém. Bezdisková pracovní stanice nemá možnost si zapamatovat svoji IP adresu i po vypnutí, ethernetovskou adresu má však pamatovánu na úrovni technických prostředků, tedy energeticky nezávisle. Po svém spuštění bude tedy klást dotaz na všechny uzly v síti Moje etherenetovská adresa je a.b.c.d.e.f, zná někdo moji IP adresu?. Jestliže se v lokální síti udržuje v pohotovosti odpovídající RARP Server, dotaz k němu posléze dorazí a on může odpovědět. Pokud má být takový dotaz směrován i za hranici směrovačů, tam se už výše uvedený dotaz přirozeně nešíří, musí bezdisková stanice raději použít protokol BOOTP, který místo rámců používá klasické datagramy na transportní úrovni.

3.5.3.2 Poznámky k bezpečnosti ARP

Jistým rizikem je, jestliže nedůvěryhodné uzly mají přístup do lokální sítě s povolení zápisu. Takový uzel by mohl emitovat falešné zprávy a změnit tok zpráv na sebe. Mohl by pak vystupovat jako jiný uzel nebo tok dat modifikovat.

3.5.4 Bezpečnostní problematika TCP a UDP

3.5.4.1 Co to je TCP a UDP

Protokol TCP (Transmission Control Protocol) je protokol spolehlivé spojované služby pro koncové komunikační partnery. O spolehlivosti hostitelské sítě se nepředpokládá nic, úroveň kvality je zaručena protokolem TCP a ne podpůrnými službami. Protokol UDP (User Datagram Protocol) je protokol nespojované služby, v podstatě se jedná o síťový protokol IP, datové struktury jsou doplněny o menší záhlaví, a to je vše.

Přesto bude vhodné si protokolovou sestavu TCP/IP krátce popsat. Nejvyšší protokolová vrstva je aplikační. Jsou zde řešeny aplikační služby zasílání elektronické pošty a přihlašování terminálových relací, běží na této úrovni videoservery, souborové servery atd. Když tyto služby potřebují získat, odebrat nebo odeslat data, volají služby nižší úrovně. Takovou službou je např. spojovaná služba TCP nebo nespojovaná služba UDP. Aplikační data se získávají, resp. odesílají po částech, transportních segmentech. Transportní segment obsahuje aplikační data doplněná v záhlaví o transportní řídicí informace. Pro přenos sítí jsou doplňovány o síťové záhlaví. Vzniká tak paket, který je přenášen sítí samostatně. Multiplexorem paketů v dostupném komunikačním podsystému je služba další nižší úrovně — IP (Internet Protocol). Pro IP vysílají, resp. přijímají pakety ovladače zařízení v hostitelském operačním systému.

Základem protokolové sestavy TCP/IP jsou IP pakety. Každý IP paket obsahuje 32-bitovou adresu zdroje a 32-bitovou adresu cíle, pak nějaké bity určující použité volitelné vlastnosti, zabezpečení záhlaví a pak vlastní datovou zátěž, transportní segment. Typický paket má délku řádově stovky bytů. Denní počty přenesených IP paketů ve světě jsou jistě v řádu miliard. Na IP úrovni se neudržuje žádná spojovaná služba, pojem virtuálních kanálů je zde neznámý. IP je nespojovanou datagramovou službou — IP nezaručuje doručení v pořadí, beze ztrát a duplikátů. Nic se nedělá ani se zabezpečením paketů, kontrolní součet uvedený v IP paketu chrání pouze záhlaví. Neexistuje ani žádná záruka, že IP paket je skutečně odeslán z místa, které udává zdrojová adresa. Každý uzel může teoreticky odesílat IP pakety s jakoukoli zdrojovou adresou. Jakákoli bezpečnostní záruka, např. autentizace, musí používat mechanismy uplatněné ve vyšších vrstvách.

IP pakety se přenáší posloupností dílčích přenosů, skoků. Cílem skoku je obvykle buďto cílový uzel (hostitelský počítač) nebo směrovač. Směrovač IP paket předává dalším skokem příštímu cílovému místu určenému směrovacím algoritmem. Pokud jsou pro konkrétní skok IP pakety příliš dlouhé, mohou být děleny na menší části. Dojde-li k zahlcení směrovače, může směrovač IP pakety ztrácet. Pakety mohou do cíle docházet v libovolném pořadí, mohou být i duplikovány. S tím si není třeba dělat starosti, vyšší vrstva (TCP) se s tím dokáže vypořádat. Pokud to aplikace požaduje, může obdržet spolehlivý virtuální kanál.

Příliš dlouhé IP pakety, z hlediska možnosti jistého skoku, lze dělit. Vznikají tak další IP pakety, každý z nich má svoje IP záhlaví a každý nese část transportního segmentu. Rovněž tyto dílčí pakety mohou dorazit do cíle samostatnými cestami, mohou být pochopitelně dále děleny. V cílovém místě se původní IP pakety sestaví znovu. Po cestě po jednotlivých skocích opětovně sestavovány nejsou.

Vrstva TCP poskytuje procesům spojovanou službu — službu virtuálních kanálů. Ztracené nebo zničené pakety se odvysílají znovu, přicházející pakety se uspořádají do posloupnosti shodné s posloupností, ve které byly odvysílány.

Řazení paketů je udržováno pomocí pořadových čísel. Každá poslaná slabika, každý požadavek na otevření nebo zavření spojení se samostatně číslují. Všechny pakety, s výjimkou prvního vysílaného během konverzace, obsahují potvrzovací číslo. Udává pořadové číslo posledního správného přijatého bytu. Úvodní paket má nahozen bit SYN, vysílá počáteční pořadové číslo na dané straně. Počáteční pořadové číslo má náhodnou hodnotu. Všechny ostatní pakety mají nahozen bit ACK. Nahozením bitu FIN se oznamuje uzavření spojení. Spojení uzavírají obě komunikující strany. Uzavření spojení se potvrzuje.

Každý TCP transportní segment je označen čtveřicí určující zdrojový uzel a port v něm a cílový uzel a port v něm. Taková čtveřice jednoznačně identifikuje virtuální kanál. Je nejen možné, ale je i často používanou praxí, udržovat na lokální straně více virtuálních kanálů vycházejících z jednoho portu. Musí se lišit adresou vzdáleného uzlu nebo portu.

Servery jsou procesy, které prostřednictvím TCP poskytují nějakou službu. Servery poslouchají, listen, na daném portu. Podle konvence jsou porty serverů číslovány odspodu. Tato konvence se vždy nedodržuje, což může vyvolávat problémy z hlediska bezpečnosti. Čísla portů všech standardních služeb volající strany znají. Port, na kterém server poslouchá, je v jistém smyslu v polootevřeném stavu. Striktně řečeno, nemusí být známa ani adresa lokálního uzlu. Uzly mohou mít i více IP adres a požadavky na spojení mohou být adresovány na libovolnou síťovou adresu uzlu serveru. Když na port serveru dorazí paket s žádostí o spojení, vyplní se zbývající pole.

Pokud je to vhodné, lokální operační systém přidělí spojení stínový port, aby mohly být během provádění služby uspokojovány další požadavky. Požadavek na službu může být plněn kopií procesu serveru.

Klient používá nabízené služby. Klienti obvykle nepožadují konkrétní port na své lokální straně, i když to smějí dělat. Místo toho akceptují jakýkoli port, který jim lokální operační systém přidělí.

Většina verzí TCP a UDP pro UNIXové systémy dodržují pravidlo, že s porty číslovanými do 1024 může pracovat pouze superuživatel, root. Hovoří se o privilegovaných portech. Smysl je v tom, že vzdálený systém může autenticitě informace přicházející z takových portů důvěřovat. Omezení je pouze konvencí, specifikace protokolu ho nepožaduje. Je jedno, jestli se jedná o jednouživatelský stroj typu PC. Implikace je jasná: svatosti čísla portu lze důvěřovat pouze tehdy, když je jisté, že originální systém má takové pravidlo a dodržuje ho a je adekvátně spravován.

Poněvadž počáteční pořadové číslo se pro každé spojení mění, je možné, že TCP detekuje přestárlé pakety z předchozích spojení, která byla definována stejnou čtveřicí. Spojení nemůže být plně ustanovené, dokud si obě strany vzájemně nepotvrdí svá počáteční pořadová čísla.

Protokol UDP v podstatě zpřístupňuje službu přenosu IP paketů aplikačním procesům. Doručování se děje na principu vyvinutí co nejlepší snahy paket doručit. Neprovádí se žádné opravy, žádná opakovaná vysílání, žádné detekce ztrát, duplikací, změn pořadí. Volitelně UDP dělá detekci chyb.

Zmíněnými nedostatky se získá snížení režijních ztrát. Nemusí se ustanovovat spojení. UDP se hodí pro aplikace typu dotaz/odpověď, ve kterých se vyměňuje podstatně méně zpráv než v TCP spojeních.

Při velkých přenosech se UDP nechová dobře. Protokol trpí nedostatkem řídicích vlastností. Může uzly a směrovače zaplavit a ty budou další pakety ztrácet.

UDP používá stejný mechanismus práce s porty a stejnou techniku implementace serverů, jako TCP. Pracuje však v jiném adresovém prostoru. Servery obvykle, ale ne vždy, okupují porty s nižšími čísly. Virtuální kanál se nezná. Všechny pakety doručené na daný port jsou předávány jedinému procesu, bez ohledu na adresu a port vzdáleného uzlu.

Koncové body komunikace jsou reprezentovány pro procesy jsou např. realizovány knihovními podprogramy. Typickým příkladem jsou koncová místa reprezentovaná unixovskými schránkami.

3.5.4.2 Poznámky k bezpečnosti TCP

Jestliže útočník je schopen uhodnout volby počátečních pořadových čísel při uzavírání spojení, může cílový uzel ošálit, bude si myslet že komunikuje s důvěryhodným uzlem. Protokoly typu TCP, které z hlediska autentizace se spoléhají na zdrojové IP adresy, mohou být využity pro napadení cílového útoku. Hovoříme o útoku přes pořadová čísla.

Je třeba se zmínit o dvou věcech. Útok přes pořadová čísla musí mít možnost využít legitimní spojení na vzdálený uzel. Pokud tomu tak není, např. při použití oddělovacích uzlů, útok neuspěje. Obráceně, brána, která je příliš důvěřivá, může být snáze zranitelná. Dále, forma útoku přes pořadová čísla může být generalizována. Takto je zranitelná řada i jiných protokolů než TCP. Útoku se lze bránit třífázovým navazováním spojení, které TCP provádí.

3.5.4.3 Poznámky k bezpečnosti UDP

UDP pakety lze mnohem snadněji podfouknout než TCP pakety. Nepoužívá se žádné potvrzování, pakety se nečíslují. Existuje pouze zdrojová adresa. Pokud aplikace musí dělat autentizaci, musí si ji dělat ve vlastní režii.

3.5.5 Bezpečnostní problematika ICMP

3.5.5.1 Co to je ICMP

Činnost Internetu je monitorována směrovači. Směrovače komunikují pomocí protokolu ICMP (Internet Control Message Protocol). Protokol ICMP definuje řadu zpráv zasílaných jako IP pakety. Tyto zprávy sdělují, že nelze nalézt cílový uzel, že paket bylo třeba zničit, protože existuje již příliš dlouho, že testovaný uzel je činný apod.

ICMP je nástroj nízké úrovně, kterým lze řídit chování transportních spojení TCP a protokolu UDP. Lze pomocí něho rovněž informovat o dobré cestě do cíle, o zrušení spojení z důvodů nestandardního chování sítě apod. Podporuje rovněž jediný, nejdůležitější monitorovací nástroj nízké úrovně — tím je program ping.

3.5.5.2 Poznámky k bezpečnosti ICMP

Mnohé ICMP zprávy, které přijme daný uzel, se týkají konkrétního spojení nebo jsou vyvolány paketem odeslaným z daného uzlu. V takovém případě jsou ICMP zprávě obsaženy IP záhlaví a prvních 64 bytů transportního záhlaví. Cílem je omezit dopad ICMP zprávy. Takže zpráva redirect nebo zpráva destination unreachable by se měly týkat konkrétního spojení (přesměrování, nedosažitelnost). Starší implementace ICMP však tuto zvláštní informaci nevyužívají. Takové zprávy pak ovlivňují všechna spojení mezi všemi páry komunikujících uzlů. Dojde-li zpráva o nedosažitelnosti uzlu fi.muni.cz, budou zrušena všechna spojení s fi.muni.cz. K tomu dojde i když původní zprávu vyvolal filtr oddělovacího uzlu orientovaný na konkrétní port. Oddělovací uzly musí proto opatrně generovat zprávy, které by mohly zrušit všechna spojení mající původ v jednom uzlu. Bohužel možnost zneužití ICMP odhalili hackeři. Byl již zachycen program, který takto útočil.

Horší je situace se zprávou redirect. Je jisté, že kdokoli, kdo může padělat s vaší znalostí správnou cestu do cíle, může pravděpodobně napadnout váš uzel. Zprávu redirect by měly poslechnout pouze uzly, nikoli směrovače a navíc pouze v případě, že tato zpráva dojde ze směrovače přímo zapojeného do stejné sítě, do které je zapojen uzel. Bohužel všechny směrovače, resp. jejich správci, nejsou tak obezřetní. Pak lze ICMP zneužít pro vytvoření nových cest do cíle. Uživatel se tak ocitne v těžké situaci.

3.5.6 Bezpečnostní problémy elektronické pošty

Elektronická pošta v síti Internet je řízena protokolem SMTP. Uzel vysílající elektronický dopis udává podle protokolu SMTP v příkazu MAIL FROM návratovou adresu. Lokální uzel nemá k dispozici spolehlivý způsob, jak ověřit, zda návratová adresa není podvrh. Nikdy si nemůžete být jisti tím, kdo vám pomocí SMTP posílá zprávu. Pro ověření důvěryhodnosti je třeba použít nějaký bezpečnostní mechanismus na vyšší úrovni.

Z hlediska bezpečnostní politiky je samotný protokol SMTP docela neškodný. Může být ovšem nástrojem pro vedení útoku formou odmítnutí služby. Útok je orientován tak, aby legitimní uživatelům znemožnil používat uzel řádným způsobem. Jestliže útočník zařídí, aby 50 uzlů vašemu uzlu poslalo 1000 zpráv o délce 1 MB, je otázkou konfigurace vašeho uzlu, jak se s takovou situací vypořádá.

Náhradní jména v poště mohou hackerům poskytnout pro ně užitečnou informaci. Ověřovací příkazy typu VRFY <postmaster> (poštovní guru), VRFY <root> (superuživatel, správce) často překládají poštovní náhradní jméno na přihlašovací jméno (login). Tak se hacker dozví kdo je administrátor a na který účet má smysl útočit. Je otázkou bezpečnostní politiky, zda se jedná nebo nejedná o citlivou informaci. Detailnější informaci může hackerovi poskytnout taková služba, jako je např. služba finger.

Ve většině unixových implementací je SMTP implementován v programu sendmail. Je to ovšem velmi primitivní nástroj. Desítky tisíc řádků v C jazyku často běžících pod vlastnictvím správce systému, superuživatele. Přímo zdroj zranitelných míst. Jedno z nich konec konců bylo využito i dnes již klasickým útokem z konce 80.let — Internet worm (internetovský červ), který dočasně vyřadil z činnosti stovky uzlů Internetu. Privilegované programy, tj. programy správců, by měly být malé a modulární. Démon SMTP nemusí být privilegovaný. Jestliže nedělá koncové doručování, např. když je činný v poštovní bráně, nemusí běžet ve vlastnictví správce. Musí mít právo zápisu do nějaké společné spoolovací fronty, právo zjištění velikosti zátěže apod., a to je vše.

Hrozbou může být i obsah zpráv. Z tohoto hlediska je zvlášť nebezpečné automatické provádění zakódovaných zpráv podle protokolu MIME. Strukturovaná informace zakódovaná v takových zprávách může indikovat akce, které je potřeba udělat. Následující zpráva je výňatek z oznámení o nové internetovské normě:

Content-Type: Message/External-body;

name=rfc1480.txt";

site="ds.internic.net";

access-type="anon-ftp";

directory="rfc"

Content-Type: text/plain

Koncový poštovní systém, který rozumí protokolu MIME, automaticky získá dpovídající normu, RFC 1480. Hacker však může poslat vymyšlenou zprávu typu:

Content-Type: Message/External-body;

name=.rhosts";

site="ftp.fi.muni.cz";

access-type="anon-ftp";

directory="."

Content-Type: text/plain

Může MIME agent lehce přepsat důležitý konfigurační soubor .rhosts, který určuje, které uzly jsou z hlediska daného uzlu důvěryhodné? MIME umožňuje posílat provedení schopné programy, postscriptové soubory apod. To vše muže být hrozbou pro daný uzel.

3.5.7 Bezpečnostní problematika aplikačních služeb

Většina relací typu telnet je uzavíraná z nedůvěryhodných uzlů. Jako důvěryhodnou entitu nelze označit ani volající proces, ani volající operační systém ani síť, ze které přichází volání. Zvědavec má přístup k celé terminálové relaci, k heslu apod. Lokální program telnet lze kompromitovat tak, aby zaznamenával přihlašovací jména a hesla nebo aby zaznamenával celé relace.

Tradiční hesla přestávají být spolehlivá, jakmile lze některou část komunikace odposlouchávat. Toto hackeři dělají a zaměřují se především na páteřové sítě. Lze silně doporučit používání jednorázových hesel, případně založených na používání autentizačních smart karet apod. Problematika tvorby aplikačních bezpečnostních bran přesahuje možný rámec této publikace. Snad jen poznámka: server řešící požadavky na spojení via telnet by nikdy neměl volat pro ověření identity program login. S programem login se nedoporučuje si hrát. Jednodušší autentizační server je vhodnější řešení. Autentizátory dobře ochrání vlastní zahájení relace, nepomohou však při zabezpečení zbytku relace. Ten může být odposloucháván, do relace lze vsouvat útočící příkazy, spojení lze udržet i po ukončení relace apod. Telnetovskou relaci lze jako takovou sice šifrovat, ale šifrování nám k ničemu není, když není možné důvěryhodně autentizovat partnera. Může to přinést více škody jak užitku, pokud se nám podaří předat tajný šifrovací klíč nedůvěryhodnému partnerovi. Klíč se takto kompromituje.

Pro útok lze využít NTP službu. Cílem je změnit představu cílového uzlu o přesném času. Představme si např. autentizační protokol, který je závislý na časové informaci. Pokud se útočníkovi podaří posunout v cílovém uzlu čas zpět, může použít pro útok maškarádou, pro vystupování v identitě autorizovaného uživatele, nějakou odposlechnutou, starší, nyní už neplatnou autentizační informaci.

Novější verze NTP proto poskytují šifrované autentizační zprávy. Autentizace je však dělána po jednotlivých skocích. Útočník, který nemůže v přímo napadnout váš NTP server, může napadnout NTP servery od kterých se váš NTP server učí, kolik je vlastně hodin. Musíte si tedy prověřit, že celá hierarchie NTP serverů se autentizuje.

Užitečným nástrojem pro útočníka je identifikační služba finger. Poskytne mu totiž velmi důležité informace, které lze využít při inteligentním útoku na heslo, informaci o tam jak často se účet používá (nepoužívaný účet asi obsahuje informace, které nestojí za to zjišťovat). Velmi důležitou informací je zobrazení mezi čitelným symbolickým jménem a adresou pro elektronickou poštu. Mnohé organizace proto váhají při rozhodování, zda povolit používání služby finger.

Jestliže se použije oddělovací uzel, brány nebudou mít přístupné přihlašování, bude data zpřístupňovat přes finger. Dobrým řešením je instalace stínového démona finger, který bude vybaven vyčistěnou bází dat z hlediska citlivých informací. Např. místo poskytnutí detailní informace o jedinci sdělí takový finger generickou odpověď —

pokud chcete zaslat poštu někomu na tomto uzlu, použijte formát krestni.prijmeni@fi.muni.cz.

Identifikační služba whois není tak nebezpečná, poněvadž dodává pouze kontaktní informaci.

Velké riziko sebou přináší používání služeb NIS/YP. Útočník může získat soubor s hesly, databázi kryptografických klíčů apod. Existuje řada vykonstruovaných postupů jak bránit útokům via NIS/YP, nejlepší řešení je však nepoužívat takovou službu na exponovaných uzlech, s vysokou pravděpodobností napadení.

Řada hrozeb souvisí s používáním služby NFS. Každý klient, který si uchovává souborovou identifikaci má trvalý přístup k odpovídajícímu souborovému systému. Zatímco standardní klientský software si opakované potvrzuje přístup při každém připojování souborového systému, typicky při opakovaném zavádění systému, při používání NFS není k tomuto nikdo tlačen. Jádro operačního systému by mělo mít svůj vlastní seznam přístupových práv, ve jménu výkonnosti to však typické implementace nedělají. Nástroje pro řízení přístupu NFS založené na bázi připojování jsou zcela nedostatečné. Nelze ani měnit politiku přístupu a zamykat sice existující, ale nedůvěryhodné klienty, ani neexistuje způsob jak se chránit před uživateli, kteří obcházejí souborovou identifikaci kořenového souboru. Některé souborové operace, např. zamykání záznamů, požadují uchovávání stavu v serveru, bez ohledu na architekturu NFS. Tyto vlastnosti se pak udržují prostřednictvím pomocných procesů pomocí mechanismu RPC. Servery používají tento mechanismus pro udržování přehledu klientů, kteří mají u nich připojeny svoje soubory. Tato data pochopitelně nemusí být konzistentní s realitou a systém je pro nic důležitého nepoužívá. NFS se obecně spoléhá na numerické identifikace uživatelů a skupin uživatelů, které musí být v rámci všech obsluhovaných strojů konzistentní. Při lokálním použití to nečiní problém, v síťovém rozsahu je to problém netriviální. Některé implementace poskytují funkci zobrazování. NFS servery normálně poslouchají na portu 2049. To je ovšem port mimo rozsah privilegovaných portů, patří mezi porty, které lze normálně přidělovat aplikačním procesům. Klientům rovněž hrozí některá nebezpečí. Kdo má privilegovaný přístup k serveru, může vytvořit programy s oprávněním superuživatele, a posléze je vyvolávat z klientského prostředí. Někteří klienti nedovolují import takových věcí. Jestliže se takové nástroje používají v okamžiku, kdy z nedůvěryhodného prostředí připojí souborový systém, zvyšuje se riziko.

Další kategorie hrozeb souvisí s použitím souborových služeb. Je příliš jednoduché zaútočit na soubor s hesly jeho zpřístupněním službou tftp. Uzel a jeho partner, kteří by zpřístupnili takovou neautentizující službou soubor z hesly, jsou jasnými kandidáty smrti. Služba tfpt se používá tehdy, je-li to nevyhnutně nutné a musí se navíc udělat řada dalších opatření. tftp používají některé směrovače pro načtení svých programů a konfiguračních souborů. Čtení konfiguračního souboru je zvlášť riskantní, a to ani ne proto, že by zkušený hacker byl schopen vytvořit falešný konfigurační soubor, ale proto, poněvadž konfigurační soubory často obsahují hesla.

Používání ftp z hlediska systémové bezpečnostní politiky znamená především to, že v dostupné oblasti z relace ftp nesmí být žádné soubory nebo adresáře s povoleným zápisovým přístupem nebo s vlastnictvím ftp přihlášení, poněvadž anonymní ftp běží právě s tímto uid. Jinak by byl možný následující útok: zapsal by se do domovského adresáře relace ftp soubor .rhosts, tedy soubor identifikující důvěryhodné uzly, a použil by se pro autorizace rsh spojení jako ftp na cílový uzel. Jinak je jasné, že vnější anonymní nedůvěryhodný klient nemá právo měnit nějaká přístupová práva, ftp relace by proto neměla nic vlastnit. V oblast přístupné via ftp by nikdy neměl ležet soubor s hesly byť zašifrovaný.

Z hlediska používání služeb typu WWW lze upozornit na následující problémy. Vrácené formáty dokumentů mohou obsahovat příznaky programů, které se mají použít na zpracování dokumentu. Velmi nebezpečná vlastnost, jejíž variantu jsme zmínili již při výkladu MIME pošty. Existuje hrozba i z hlediska serveru, pokud tento slepě akceptuje ukazatele. Tyto ukazatelé mají v sobě často zabudovaná jména souborů.

I když se servery pokoušejí ověřit, zda jsou soubory autorizované pro přenos, verifikační proces se může provádět chybně (což se také stalo); v takovém případě má vnější uživatel přístup k čemukoli. Bylo by dobře v rámci syntaxe ukazatel použít volitelné pole pro kryptografický kontrolní součet, tedy pro součet nečitelný a nepřipravitelný bez znalosti kryptografického klíče. Největší nebezpečí představují dotazy. Nejzajímavější dotazovací programy nejsou pouhými jednoduchými prohlížeči adresářů. Spíše jsou řízeny připravenou dávkou příkazů, tzv. scriptem. Script sám je síťový server a jako takový je vystaven všem možným útokům. Většina scriptů je psána v jazyku PERL a ne v shellu, takže v prostoru síťové služby musí být tyto rozsáhlé interprety k dispozici. Jiné řešení není a scripty je třeba psát velmi uvážlivě.

3.6 Oddělovací uzly, firewalls

Dokonalá izolace sítě od okolí, je ideální technikou implementace účinných ochran před útoky. Postavíme-li však vysokou hradbu okolo sídliště, je potřeba občas použít nějaký "padací most", který umožní občas zajít pro potraviny, občas zajít se na něco optat apod. Stejnou roli hrají oddělovací uzly, firewalls , na okraji síťové oblasti chráněné přísnou systémovou komunikační bezpečnostní politikou. V dané společnosti se může propojovat libovolné množství LAN mezi sebou, do okolního světa je však přístup pouze přes explicitně zabudované elektronické padací mosty — oddělovací uzly, v přísnějším překladu "požární zdi" (firewalls).

Oddělovací uzel má dvě komponenty, paketové filtry, kteréfiltrují pakety a aplikační bránu. Existují i jednodušší implementace, předností uvedené struktury je, že každý paket jak po cestě ven, tak i dovnitř, musí projít dvěma filtry a aplikační bránou. Jiná cesta neexistuje.

Paketový filtr je standardní směrovač vybavený speciálními funkcemi. Ty mu umožňují zkoumat přicházející a vystupující pakety. Pakety, které splňují předem daná kritéria se normálně směrují dál. Ty, které je nesplňují, se ničí.

Paketový filtr umístěný na straně vnitřní LAN kontroluje vystupující pakety, paketový filtr umístěný na straně vnější LAN kontroluje přicházející pakety. Pakety, které překonají první kontroly, přicházejí do aplikační brány, kde jsou dále zkoumány. Provozováním dvou samostatných paketových filtrů na samostatných LAN se získá záruka, že všechny pakety jistě projdou přes aplikační bránu, jiná cesta ven či dovnitř nevede.

Paketové filtry jsou typicky řízeny tabulkami, které konfiguruje systémový administrátor. Poskytují seznam přípustných zdrojů a cílů paketů, zakázaných zdrojů a cílů a implicitní pravidla o zacházení s výstupními a s přicházejícími pakety.

V unixovém prostředí s TCP/IP určení zdroje a cíle se provede uvedením IP adresy a čísla portu. Port indikuje požadovanou službu, 23 pro telnet, 79 pro finger atd. Organizace může blokovat přicházející pakety na všechny IP adresy v kombinaci s některým z uvedených portů. Důsledek — z vnějšího prostředí nebude mít nikdo možnost se přihlásit pomocí služby telnet nebo se optat na vlastnosti jedinců pomocí služby finger apod. Jestliže se zakáže přístup na port odpovídající usenetovským news, bude mít organizace jistotu, že si je nikdo v práci nečte.

Blokování výstupních paketů je obtížnější, poněvadž konvence se nemusí dodržovat. Navíc, některé služby používají dynamicky přidělované porty, např. ftp. To je případ TCP spojení. Pro případ UDP provozu je situace na výstupu ještě těžší, poněvadž o tom, co budou dělat, se neví de facto vůbec nic. Některé výstupní filtry proto zakazují UDP provoz jako takový.

Druhou částí oddělovacího uzlu je aplikační brána. Ta obvykle pracuje už na aplikační úrovni, paketovou část už nekontroluje. Poštovní brána může např. kontrolovat odeslanou i doručovanou poštu a může rozhodovat o likvidaci pošty na základě polí v záhlaví, délky zprávy a případně i na základě obsahu.Aplikačních bran se může provozovat i více současně. Typické nasazení bran je v oblasti elektronické pošty a případně v oblasti WWW.

Poslední poznámka: pokud se v organizaci někde používá přímé spojení, pak nasazení oddělovacích uzlů postrádá smysl.

4. Bezpečnostní funkce pro přenos zdravotnických informací

4.1 Výběr bezpečnostních funkcí pro přenos zdrav. informací

Tato kapitola definuje bezpečnostní funkce, které jsou určeny pro zajištění bezpečnosti zdravotnických informací (zpráv), přenášených po veřejných telekomunikačních a datových sítích (např. síť Internet). Bezpečnostní funkce, použité ve standardu (důvěrnost, autentizace, integrita zpráv a neodmítnutelnost zodpovědnosti odesílatele) jsou zajištěny pomocí kryptografických mechanismů, implementovaných v odesílajícím a přijímajícím programu. Od použité datové sítě nejsou požadovány žádné speciální bezpečnostní funkce.

Pokud odesílatel použije bezpečnostní funkce, definované v tomto standardu, na odeslanou zprávu, budou všechny vybrané bezpečnostní funkce aplikovány na celou odeslanou zprávu. Funkce autentizace, integrita a neodmítnutelnost zodpovědnosti jsou aplikovány na všechny přenášené zprávy. Funkce důvěrnosti je aplikována pouze na vybrané zprávy. Zprávy, na které je aplikována i funkce důvěrnosti, jsou definovány ve studii "Klasifikace citlivosti zdravotnických dat a doporučené bezpečnostní funkce pro jejich přenos".

Bezpečnostní funkce, definované v této kapitole, jsou definovány značně obecně a jsou aplikovatelné na širokou škálu platforem. Zvláště jsou dodržována tyto zásady:

· Mechanismy, definované v tomto standardu, nejsou definovány pro konkrétní hardware nebo pro konkrétní operační systém, ale dovolují implementaci prakticky na všech platformách. Všechny funkce jsou implementovány na aplikační úrovni a nejsou závislé na jakýchkoli bezpečnostních vlastnostech nižších úrovní přenosového protokolu.

· Bezpečnostní funkce nejsou závislé na jiných komponentách použité datové sítě. Jsou implementovány způsobem end-to-end, což znamená, že nejsou ovlivněny a neovlivňují mezilehlé uzly sítě. Odesílatel zprávy je pouze zodpovědný za to, že příjemce zprávy má potřebné vybavení pro zpracování takto zabezpečené zprávy.

· Definované bezpečnostní funkce kladou minimální nároky na použitý přenosový protokol. Pro všechny bezpečnostní funkce je postačující nespojovaná (connectionless) cesta, tedy elektronická pošta.

· Definované bezpečnostní funkce jsou poměrně snadno zabudovatelné do koncových aplikačních programů a mohou být vybaveny odpovídajícím uživatelským rozhraním. Bezpečnostní funkce je možno implementovat přímo do komunikačního programu (např. do klienta elektronické pošty) nebo je možno je implementovat do samostatného programu a zabezpečení provádět na úrovni souborů.

· Definované bezpečnostní funkce dovolují implementaci zabezpečení v rámci osobního počítače bez ohledu na to, jakým způsobem (prostřednictvím jakého systému) je provedeno připojení uživatele na datovou síť. Pokud uživatel používá pro připojení k datové síti pomoc jiného počítače (například víceuživatelského), bezpečnost přenášených dat nezávisí na bezpečnosti tohoto zprostředkujícího počítače.

· Definované bezpečnostní funkce jsou kompatibilní s mnoha způsoby správy a distribuce kryptografických klíčů, včetně manuální distribuce klíčů a centralizované distribuce, založené na certifikátech veřejných klíčů.

· Aby bylo umožněno urychlené zavedení těchto bezpečnostních funkcí pro přenos dat do zdravotnictví bez náročných modifikací stávajícího hardware a software, byla při jejich návrhu dodržována následující pravidla:

· Bezpečnostní funkce jsou implementovány pouze v koncových bodech přenosu dat a jsou zabudovatelné do existujících přenosových protokolů na aplikační úrovni. Nevyžadují modifikaci konkrétního použitého přenosového protokolu ani integraci na nižší protokolové úrovni.

· Sada bezpečnostních funkcí neomezuje uživatele v používání jeho systému, ale rozšiřuje jeho možnosti. Navržené funkce nezabraňují uživateli v používání přenosu dat s jinými uživateli (tj. těmi, kteří nepoužívají bezpečný přenos dat) původním, nezabezpečeným způsobem.

· Sada navržených bezpečnostních funkcí se soustředí na funkce, které umožňují výrazné zvýšení bezpečnosti při nepříliš velkém implementačním úsilí.

Na základě prozkoumání relevantních rizik a bezpečnostních požadavků a při respektování výše uvedených principů byly navrženy následující bezpečnostní funkce pro zabezpečení přenosu zdravotnických informací:

1. autentizace odesílatele zprávy,

2. důvěrnost zpráv (ochrana proti prozrazení zpráv),

3. integrita zpráv,

4. neodmítnutelnost zodpovědnosti odesílatele zprávy,

5. ale nejsou poskytovány tyto bezpečnostní funkce

6. řízení přístupu,

7. důvěrnost toku dat,

8. správnost zaslání podle adresy,

9. zabezpečení správného směrování,

10. zabezpečení osobního počítače před zneužitím jiným uživatelem téhož počítače,

11. neodmítnutelnost zodpovědnosti příjmu zprávy,

12. automatické bezpečné potvrzování přijetí zpráv,

13. detekce zrušení zprávy, ochrana před opakovaným zasláním téže zprávy

4.2 .Požadované bezpečnostní funkce

Požadované bezpečnostní funkce pro přenos zdravotnických informací (důvěrnost, autentizace, integrita zpráv a neodmítnutelnost zodpovědnosti odesílatele) jsou definovány následovně:

Autentizace odesílatele zprávy. Autentizace (prokázání totožnosti) odesílatele zprávy zajišťuje bezpečné ověření proklamované totožnosti odesílatele zprávy příjemcem. Vzhledem k bezpečnostním požadavkům musí být tato funkce implementována kryptografickými mechanismy pomocí symetrického nebo asymetrického šifrovacího mechanismu. V rámci této funkce se nepožaduje ochrana proti duplikaci zpráv, která musí být řešena na aplikační úrovni.

Důvěrnost zpráv (ochrana proti prozrazení zpráv, utajení zpráv). Tato funkce zajišťuje, že žádná třetí osoba nemá možnost přístupu k přenášeným informacím. Vzhledem k bezpečnostním požadavkům musí být tato funkce implementována kryptografickými mechanismy pomocí symetrického šifrovacího mechanismu šifrováním zpráv náhodným klíčem relace.

Integrita zpráv (celistvost zpráv). Tato funkce zajišťuje, že přenášené informace být neodhaleně modifikovány (změněny) ani podvrženy případným útočníkem. Vzhledem k bezpečnostním požadavkům musí být tato funkce implementována kryptografickými mechanismy pomocí symetrického nebo asymetrického šifrovacího mechanismu.

Neodmítnutelnost zodpovědnosti odesílatele zprávy. Tato funkce zajišťuje, že odesílatel zprávy je zodpovědný za odeslanou zprávu a nemůže se této odpovědnosti zbavit. Příjemce zprávy může tuto skutečnost prokázat třetímu nezávislému subjektu. Tato funkce musí být implementována kryptografickými mechanismy pomocí asymetrického šifrovacího mechanismu. Tato implementace neodmítnutelnosti zodpovědnosti se nazývá také elektronický podpis.

5. Podpůrné bezpečnostní funkce

Bezpečnostní funkce, definované v této kapitole, se netýkají samotného přenosu dat, ale slouží pro zabezpečení prostředí obou účastníků přenosu (odesílatele i příjemce). Mezi tyto funkce patří především autentizace uživatele a personální bezpečnostní prostředí a správa kryptografických klíčů.

5.1 Autentizace uživatele a personální bezpečnostní prostředí

Tato funkce má za úkol zabezpečit klíče uživatele (především jeho soukromý klíč) v prostředí jeho osobního počítače před prozrazením nebo zneužitím jinými osobami. Tato bezpečnostní funkce představuje následující požadavky:

· Systém musí svázat každý kryptografických klíč, který je uživatelsky přístupný s konkrétních algoritmem a s parametry konkrétního algoritmu. Tam, kde se jedná o veřejné klíče, musí systém zajišťovat jejich svázání s vlastníkem veřejného klíče a s případnými časovými údaji (datum generování a/nebo datum konce platnosti).

· Systém musí chránit kryptografické klíče před neoprávněným prozrazením, modifikací a podvržením. Systém musí zajistit, že soukromé klíče osob jsou chráněny před neoprávněným přístupem jiných osob.

· Systém musí zajistit, že soukromé klíče jsou v době, kdy nejsou používány, udržovány pouze v zašifrované podobě.

5.2 Správa klíčů

Systém musí zajistit bezpečnou distribuci veřejných klíčů jednotlivých uživatelů buď způsobem manuálním nebo pomocí distribuce kryptograficky certifikovaných veřejných klíčů.

6. Elektronický podpis

Jedním z nejdůležitějších bezpečnostních požadavků, kladených na proces zpracování, ukládání a přenášení zdravotnických informací je požadavek na zajištění integrity těchto dat. tj. požadavek na zabránění neodhalené a neoprávněné modifikaci dat. U samostatných dokumentů je toho obvykle dosahováno tím, že se k datům připojí jistá informace, která příjemci autentizuje (tj. prokazuje totožnost) odesílatele nebo tvůrce těchto dat a to pouze v tom případě, že ji příjemce přijal spolu s daty neporušenou. Někdy nastává situace, že nepostačuje, aby příjemce byl přesvědčen o autentičnosti dat, ale aby také byl schopen prokázat tuto skutečnost nezávislé třetí straně. Tato vlastnost se nazývá neodmítnutelnost zodpovědnosti.

Lékaři a jiný zdravotnický personál je osobně zodpovědný za lékařskou péči, věnovanou pacientovi. Proto zdravotnické informační systémy by měly být schopny zajišťovat autentičnost elektronických záznamů o pacientech po značně dlouhou dobu (obvykle 20 až 30 let). Potřeba autentičnosti se týká nejen dokumentů, umístěných v centralizované části zdravotnického informačního systému, ale také dokumentů, přenášených počítačovými sítěmi nebo veřejnými datovými sítěmi.

Technická realizace zajištění autentičnosti dat vychází z předpokladu, že u dat na papírových médiích je autentičnost zajišťována pomocí manuálního podpisu. To přináší potřebu spolehlivé a efektivní náhrady manuálního podpisu podpisem elektronickým (digitálním). Elektronický podpis může být, stejně jako manuální podpis, použit pro identifikaci a autentizaci původce informace. Elektronický podpis může být také použit pro kontrolu, že informace nebyla po podepsání změněna. Tím lze zajistit integritu informace. Na rozdíl od manuálního podpisu však nelze pomocí elektronického podpisu rozlišit originál informace od její kopie.

6.1.1 Vlastnosti elektronického podpisu

Elektronický podpis lze použít pro podepsání elektronického dokumentu (např. souboru) libovolné délky a libovolného obsahu. elektronický podpis je tvořen řetězcem bajtů, který je připojen k podepisovanému dokumentu. Délka tohoto řetězce bývá obvykle 50 až 300 bajtů podle použitého algoritmu a požadovaného stupně bezpečnosti a nezávisí na délce podepisovaného dokumentu. Elektronický podpis poskytuje příjemci dokumentu následující funkce:

· Zajišťuje autenticitu dokumentu. Příjemce dokumentu bezpečně ví, kdo je autorem dokumentu.

· Zajišťuje integritu dokumentu. Příjemce dokumentu má jistotu, že obsah dokumentu dokument nebyl během přenosu nebo zpracování modifikován.

· Zajišťuje neodmítnutelnost zodpovědnosti autora elektronického podpisu. Autor dokumentu nemůže popřít autorství dokumentu ani jeho obsah.

Elektronický podpis má následující vlastnosti:

· Je spojen s jedním konkrétním elektronickým dokumentem (tj. potvrzuje pravost a autenticitu tohoto dokumentu) a nemůže být použit pro podepsání jiného dokumentu.

· Může být vytvořen pouze tím, kdo zná jisté tajemství (nazývané soukromý klíč).

· Je nemožné vytvořit jiný dokument, sebeméně odlišný od původního dokumentu pro který by byl původní elektronický podpis stále platný.

· Jakmile je jednou elektronický podpis dokumentu vytvořen, kdokoli si může ověřit pravost tohoto podpisu a to bez nutnosti znát tajemství (soukromý klíč), kterým byl podpis vytvořen.

Jak je vidět, elektronický podpis zachovává téměř všechny vlastnosti manuálního podpisu vyjma jediné - u dokumentu, podepsaného manuálním podpisem lze rozlišit jeho kopii od originálu. U dokumentu, podepsaného elektronickým podpisem kopii od originálu rozlišit nelze.

6.1.2 Kryptografie a elektronický podpis

Pro elektronický podpis se používají kryptografické algoritmy s veřejným klíčem. Nejvíce se používají algoritmy RSA (Rivest Shamir Adleman) a DSS (Digital Signature Standard). Proces podepsání zprávy (dokumentu) probíhá v obou případech následovně: Nejdříve se spočte kryptografický kontrolní součet zprávy, který je vlastně zkrácenou charakteristikou zprávy. Tento kryptografický kontrolní součet se spočte vhodnou, kryptograficky bezpečnou, jednocestnou rozptylovací funkcí (v případě algoritmu RSA se používá MD5, v případě algoritmu DSS se používá SHS). Z kryptografického kontrolního součtu se pak pomocí soukromého klíče SK spočte elektronický podpis zprávy, který se připojí ke zprávě. Kdokoli, kdo zná odpovídající veřejný klíč VK odesílatele, si může ověřit platnost elektronického podpisu. Pokud je elektronický podpis v pořádku, příjemce má jistotu, že zpráva byla podepsána vlastníkem soukromého klíče a že po podepsání nebyla modifikována.

Obr. 1 Podepsání dokumentu elektronickým podpisem

Příjemce navíc může předložit nezávislé třetí straně zprávu, její elektronický podpis a doklad o veřejném klíči odesílatele jako důkaz o tom, že odesílatel tuto zprávu odeslal a odesílatel tuto skutečnost nemůže popřít. Tato vlastnost se nazývá neodmítnutelnost zodpovědnosti. Elektronický podpis na druhé straně nezajišťuje důvěrnost (utajení) zprávy. Pokud si odesílatel přeje zprávu při přenosu utajit, musí ji ještě navíc zašifrovat (například algoritmem DES).

6.1.3 Aplikace elektronického podpisu

Jelikož elektronický podpis zajišťuje jak identitu autora, tak i integritu podepsané zprávy, může být použit v nejrůznějších aplikacích. Může být použit například v systému elektronické pošty. Jakmile odesílatel vytvoří zprávu, může ji podepsat svým soukromým klíčem. Podepsaná zpráva pak může být zaslána příjemci. Jakmile příjemce přijme zprávu a zkontroluje její elektronický podpis, má jistotu, že zpráva byla skutečně odeslána výše zmíněným odesílatelem. Má však také jistotu, že zpráva nebyla po podepsání modifikována.

V právních systémech se často vyskytuje požadavek přiřadit dokumentu časové razítko, které určuje datum a čas, kdy byl dokument vyřízen nebo kdy vstoupil v platnost. K dokumentu v elektronické podobě může být připojeno časové razítko rovněž v elektronické podobě a celý dokument může být podepsán elektronickým podpisem. Použití elektronického podpisu zajistí integritu dokumentu i připojeného časového razítka.

Elektronický podpis může být také použit v systémech pro elektronické provádění plateb (EFT, Electronic Fund Transfer). Předpokládejme, že v systému EFT je vytvořena zpráva, která má provést převod 1000,- Kč z jednoho účtu na druhý. Pokud je tato zpráva zaslána přes nechráněnou datovou síť, může být útočníkem změněna tak, aby převáděná částka byla 10 000,- Kč. Bez dodatečné informace je pro příjemce velmi obtížné (pokud ne nemožné) určit, zda zpráva byla nebo nebyla modifikována. Pokud je však zpráva před odesláním podepsána elektronickým podpisem, příjemce bezpečně pozná, že zpráva byla modifikována a odmítne její zpracování.

Elektronický podpis může být také zabudován do velkého množství obchodních aplikací, které požadují elektronickou náhradu manuálního podpisu. Jedním z příkladů je elektronická výměna dat (EDI, Electronic Data Interchange). EDI je systém výměny elektronických informací mezi počítači, ve kterém přenášené informace představují obchodní dokumenty (doklady). EDI lze použít například pro bezhotovostní platební styk nebo pro elektronický styk s finančním ústavem. Při přenosu dokladu pomocí EDI je elektronický podpis využíván jako přímá náhrada manuálního podpisu přenášených dokladů. Při správné implementaci má elektronický podpis stejnou právní sílu a průkaznost jako podpis manuální.

Uveďme příklad uzavření kontraktu mezi státní správou a dodavatelem pomocí EDI. Orgán státní správy vytvoří poptávkový dokument, podepsaný elektronickým podpisem. Dodavatel, který má zájem odpovědět, si před odpovědí ověří elektronický podpis poptávkového dokumentu. Tím získá jistotu, že poptávkový dokument nebyl během přenosu modifikován a že skutečně pochází od orgánu státní správy. Pak dodavatel vytvoří svou nabídku a podepíše ji elektronickým podpisem. Jakmile orgán státní správy přijme nabídku, zkontroluje její elektronický podpis a ověří si, že nabídka nebyla modifikována a skutečně pochází od dodavatele. Je-li nabídka přijata, orgán státní správy s dodavatelem sjedná smlouvu, která je oběma účastníky podepsána elektronickým podpisem a také oběma účastníky archivována. Pokud by později došlo ke sporu, obsah smlouvy a elektronické podpisy mohou být prověřený nezávislou třetí stranou (například soudem).

Elektronický podpis může být také užitečný při distribuci programového vybavení (software). Software může být po schválení pro distribuci podepsáno elektronickým podpisem. Před instalací software na počítači může být elektronický podpis zkontrolován, aby se zajistilo, že se software nebyla provedena žádná změna (jako je například infekce virem nebo úmyslná modifikace). Elektronický podpis může být později periodicky kontrolován a tím se zajistí, že ani později během činnosti nebylo software modifikováno.

V databázových aplikacích je často velmi důležitá integrita informací, uložených v databázi. Proto v nejrůznějších databázových aplikacích může být použit elektronický podpis pro zajištění integrity. Dokument může být například podepsán před jeho vložením do databáze. Po pozdějším vyhledání dokumentu v databázi je elektronický podpis zkontrolován. Je-li elektronický podpis správný, uživatel má jistotu, že dokument nebyl modifikován ani podvržen neautorizovaným subjektem. Systém také může ukládat podpisy do auditního záznamu, čímž se získá přehled o uživatelích, kteří informaci v databázi modifikovali.

6.1.4 Bezpečnost elektronického podpisu

Bezpečnost každého kryptografického systému s veřejným klíčem závisí na několika faktorech. Mezi ně patří zejména matematická bezespornost použitého algoritmu, bezpečná správa použitých kryptografických klíčů a bezpečnost implementace systému v konkrétní aplikaci. Například bezpečnost algoritmu DSS je dána množstvím práce, nezbytné k nalezení nebo vypočtení diskrétního logaritmu velmi velkého čísla. V současné době je jediným prostředkem pro zrychlení nalezení diskrétního logaritmu pouze zvyšování výpočetní síly počítačů, které má inkrementální charakter. Parametry zvoleného algoritmu jsou navrženy tak, že zrychlování výpočetní techniky nemůže bezpečnost elektronického podpisu v potřebném časovém horizontu (desítky let) ohrozit. Z toho plyne, že útočník, který nezná soukromý klíč subjektu, nemůže vypočíst elektronický podpis subjektu. To znamená, že elektronický podpis nemůže být podvržen.

Elektronický podpis bývá někdy zaměňován s digitalizovaným podpisem. Digitalizovaný podpis se vytvoří tak, že se manuální podpis zkonvertuje do podoby elektronického obrazu. Nejenže však digitalizovaný podpis nemůže nahradit elektronický podpis, nemůže dokonce nahradit ani samotný manuální podpis. Digitalizovaný podpis může být podvržen. Může být duplikován nebo připojen k jinému dokumentu. A nemůže být ani použit ke kontrole, zda dokument nebyl po podepsání modifikován.

6.1.5 Podpůrné funkce

Mezi funkce, které jsou nezbytné pro použití elektronického podpisu patří:

· Funkce pro vytvoření kryptografického kontrolního součtu zprávy. Kryptografický kontrolní součet je zhuštěnou reprezentací informace, která má být podepsána. Použitý algoritmus kryptografického kontrolního součtu musí zajistit, že je výpočetně nezvládnutelné nalézt k danému kontrolnímu součtu odpovídající zprávu nebo nalézt dvě různé zprávy, které mají stejný kryptografický kontrolní součet. Mezi vhodné algoritmy patří zejména MD5 a SHS.

· Pro generování páru veřejný klíč/soukromý klíč je nezbytný kryptograficky bezpečný generátor náhodných čísel. Lze použít buď hardwarový šumový generátor náhodných čísel nebo softwarový generátor pseudonáhodných čísel.

· Pro rutinní používání elektronického podpisu je nezbytný mechanismus spojení veřejného klíče a jeho vlastníka. To znamená, že musí existovat bezpečný způsob, jak ke každé identifikaci subjektu zjistit jeho veřejný klíč. Mechanismus může být založen například na certifikační autoritě, která generuje certifikáty, obsahující identifikaci subjektu a jeho veřejný klíč.

· Pro úspěšnou implementaci je však třeba zvládnout i některé systémové, organizační a právní otázky. Například může být nezbytné zajišťovat centrální registraci veřejných klíčů uživatelů v adresáři nebo získávání časových razítek obecných dokumentů. Zde musí být vzaty v úvahu právní náležitosti, jako například zodpovědnost certifikační autority, přijímání elektronicky podepsaných dokumentů orgány státní správy a důkazní síla elektronického podpisu u soudu. V konkrétní aplikaci je rovněž třeba vyřešit některé technické detaily, jako například mechanismy generování a distribuce certifikátů a mechanismy rušení platnosti certifikátů.

6.1.6 Příklad aplikace elektronického podpisu ve státní správě

Ve státní správě mnoha zemí je elektronický podpis běžně používán. Zde uvedeme pouze několik příkladů z USA. Všechny federální orgány USA (včetně orgánů ministerstva obrany) mohou požívat elektronický podpis (implementovaný na základě standardů DSS a SHS) pro podepisování neklasifikovaných informací. Ministerstvo obrany ve vybraných aplikacích používá DSS i pro podepisování klasifikovaných dat. Ústřední účetní úřad (GAO) vydal rozhodnutí, že elektronický podpis může být použit pro vytváření platných hospodářských smluv a závazků. Tento úřad rovněž rozhodl, že dokumenty, vytvářené v systémech EDI (Electronic Data Interchange), které jsou podepsány pomocí DSS, budou chápány jako platné důkazní materiály.

7. Požadavky na kryptografické mechanismy

Tato kapitola definuje kryptografické mechanismy (algoritmy), které jsou třeba k zajištění bezpečnostních funkcí, potřebných pro zabezpečení přenosu zdravotnických informací. Kryptografické mechanismy slouží pro zašifrování a dešifrování zprávy. Zašifrováním rozumíme převedení čitelné podoby zprávy (otevřený text) do nečitelné podoby (zašifrovaný text). Dešifrování je proces opačný - převádí zašifrovaný text na otevřený text. Protože v moderní kryptografii platí, že bezpečnost kryptografického mechanismu nesmí záviset na utajení algoritmu, musíme jak šifrování, tak i dešifrování parametrizovat tajným parametrem - šifrovacím klíčem. Podle toho, zda při šifrování a při dešifrování použijeme stejný klíč, se dělí kryptografie na kryptografii tajným klíčem a kryptografii veřejným klíčem. Pro implementaci systému zabezpečení přenosu zdravotnických informací jsou potřebné následující kryptografické mechanismy:

· Mechanismus pro utajení zprávy - symetrický šifrovací mechanismus s tajným klíčem.

· Mechanismus pro hash zprávy - kryptografický kontrolní součet.

· Mechanismus pro výměnu klíčů - asymetrický šifrovací mechanismus s veřejným klíčem.

· Mechanismus pro zajištění integrity, autentizace a elektronický podpis - asymetrický šifrovací mechanismus s veřejným klíčem.

7.1 Obecné požadavky na kryptografické algoritmy

Kryptografický algoritmus, použitý pro zabezpečení přenosu zdravotnických informací, musí splňovat následující bezpečnostní požadavky:

1. Všechny kryptografické algoritmy, používající tajný nebo soukromý klíč, musí být navrženy a implementovány tak, aby zajistili, že zjištění vztahu mezi jejich vstupem (otevřeným textem) a jejich výstupem (zašifrovaným textem) je mimo možnosti útočníka, který nezná tento tajný nebo soukromý klíč.

2. Všechny kryptografické algoritmy, používající tajný nebo soukromý klíč, musí zajišťovat utajení tohoto klíče. Útočník nesmí být schopen využít kryptografického algoritmu pro zjištění tajného nebo soukromého klíče.

3. Kryptografický algoritmus včetně jeho režimů použití musí být úplně specifikován a musí být zveřejněn.

4. Kryptografický algoritmus musí pokud možno vyhovovat relevantním mezinárodním a národním standardům.

7.2 Definice použitých kryptografických mechanismů

Při zabezpečení přenosu zdravotnických informací se používají tři základní kryptografické mechanismy: symetrický šifrovací mechanismus s tajným klíčem, asymetrický algoritmus s veřejným klíčem, kryptografický kontrolní součet.

7.2.1 Symetrický kryptografický mechanismus s tajným klíčem

Tento mechanismus používá jediný šifrovací klíč, který znají obě komunikující strany. Aby byla kryptografie tajným klíčem účinná, sdílený klíč musí být udržován v naprosté tajnosti. Kryptografie tajným klíčem je při zabezpečení přenosu zdravotnických informací použita pro zajištění důvěrnosti (tj. utajení) přenášených dat. Kryptografické algoritmy s tajným klíčem jsou poměrně rychlé a běžně se u nich dosahuje rychlosti desítek až stovek KB za sekundu při softwarové implementaci. Délka klíče kryptografického algoritmu musí být dostatečná, aby byl vyloučen tzv. útok silou, při kterém útočník zkouší všechny možné klíče. Typické kryptografické algoritmy s tajným klíčem jsou DES, 3-DES, IDEA.

7.2.2 Asymetrický kryptografický mechanismus s veřejným klíčem

Kryptografie veřejným klíčem používá dvojici klíčů: veřejný klíč a soukromý klíč. Tyto dva klíče jsou spolu matematicky svázány, avšak soukromý klíč není možné odvodit z veřejného klíče. V systémech, používajících kryptografii veřejným klíčem, každá ze stran má svou dvojici veřejný klíč/soukromý klíč. Veřejný klíč je znám komukoli, avšak nikdo nesmí mít možnost jej modifikovat. Soukromý klíč je stranou udržován v tajnosti. Jeho použití je v moci jeho vlastníka a tento klíč musí být chráněn před modifikací i před odhalením. Algoritmus s veřejným klíčem se dá obecně použít dvojím způsobem - pro zajištění důvěrnosti a pro elektronický podpis.

Při zabezpečení přenosu zdravotnických informací se tento mechanismus používá pro zajištění důvěrnosti, autentizace, integrity a neodmítnutelnosti zodpovědnosti. Je přípustné jak použití jediného algoritmu pro zajištění všech těchto funkcí, tak i použití rozdílných algoritmů pro zajištění důvěrnosti a pro zajištění autentizace, integrity a neodmítnutelnosti zodpovědnosti.

Typické algoritmy s veřejným klíčem jsou algoritmy RSA (Rivest Shamir Adleman), DSA (Digital Signature Algorithm), DIffie-Hellman a ECA (Elliptic Curve ALgorithms).

7.2.3 Kryptografický kontrolní součet (hash zprávy)

Jiným typem kryptografického algoritmu je kryptografický kontrolní součet, nazývaný také jednocestná funkce, nebo hash funkce. Jeho vstupem je zpráva libovolné délky (která je chápána jako posloupnost bajtů) a jeho výstupem je kryptografický kontrolní součet této zprávy o pevné délce (128 bitů nebo více). K kryptografický kontrolní součet splňuje následující podmínky:

· K danému kryptografickému kontrolnímu součtu je nemožné nalézt odpovídající zprávu.

· K dané zprávě je nemožné nalézt jinou zprávu, která má stejný kryptografický kontrolní součet.

Při zabezpečení přenosu zdravotnických informací se tento mechanismus používá pro zajištění integrity a neodmítnutelnosti zodpovědnosti.

7.3 Minimální délky kryptografických klíčů

Pro zabezpečení přenosu zdravotnických informací jsou požadováni následující minimální délky kryptografických klíčů:

· Symetrický kryptografický mechanismus s tajným klíčem

Minimální efektivní délka klíče pro tento kryptografický algoritmus je 80 bitů. Produkty, které obsahují mechanismy s délkou klíče 40 bitů (tj. produkty exportované z USA) jsou z hlediska bezpečnosti nevyhovující. U algoritmů s volitelnou délkou klíče nemá smysl zvětšovat délku klíče nad 128 bitů.

· Asymetrický kryptografický mechanismus s veřejným klíčem

Minimální délka klíče závisí na použitém kryptografickém algoritmu. Pro nejčastěji používaná algoritmus RSA jsou minimální požadované délky klíčů následující: 768 bitů pro běžné klíče uživatelů, 1024 bitů pro klíče organizací a 2048 bitů pro zvláště důležité klíče (např. klíč certifikační autority). V počáteční etapě zavádění systému lze povolit minimální délku uživatelského klíče 512 bitů s podmínkou, že software uživatele je schopen ověřovat i delší klíče podle výše uvedených požadavků.

· Kryptografický kontrolní součet (hash zprávy)

Tento kryptografický mechanismus nemá klíč a proto ze není předepsána minimální délka klíče. Požadavkem pouze je to, že velikost kryptografického kontrolního součtu zprávy je minimálně 128 bitů.

7.4 Příklady doporučených kryptografických mechanismů

Příklady doporučených kryptografických algoritmů a přehled relevantních standardů bude uveden v druhé části studie "Formát pro přenos zabezpečených dat ve zdravotnictví".

8. Bezpečnostní vlastnosti některých existujících systémů

8.1 Bezpečná elektronická pošta

Pro bezpečnou elektronickou poštu se v síti Internet používají dva různé systémy - PEM a PGP. PEM (Privacy Enhanced Mail - bezpečná elektronická pošta) je návrh standardu, definující procedury pro šifrování a autentizaci zpráv s cílem poskytnout služby pro přenos zpráv elektronické pošty při zlepšení bezpečnosti (zajištěním důvěrnosti a důvěryhodnosti) v rámci sítě Internet. Procedury by měly být slučitelné s širokou třídou přístupů správy klíčů, včetně symetrického (soukromý klíč) a asymetrického (veřejný klíč) šifrování dat. PEM je definována dokumenty RFC 1421 až 1424 a je souběžně vyvíjena na mnoha místech celého světa. Diskusi kolem vývoje je věnován mailing list pem-dev@tis.com. PEM existuje například v implementacích TIS/PEM (Privacy Enhanced Mail od firmy Trusted Information Systems) nebo RIPEM.

PGP (Pretty Good Privacy) je aplikační software s kryptografickými vlastnostmi, vykazujícími vysoký stupeň bezpečnosti. Je určen pro celou škálu platforem a využívá kryptografických technik, používajících veřejný klíč. Uživatelům umožňuje pohodlnou výměnu zpráv nebo souborů při zajištění bezpečnosti (utajení) a autentizace. PGP verze 1 definoval a vyvinul Philip Zimmerman z Pretty Good Software. Verze 2 byla vyvinuta pod jeho vedením.

Na následujících dvou obrázcích je znázorněn proces kryptografického zabezpečení zprávy v systému PGP.

Obr. 2 Zašifrování (utajení) zprávy v PGP

Na prvním obrázku je nakreslen proces zašifrování (utajení) zprávy. Nejdříve je vygenerován náhodný klíč relace, kterým je pomocí algoritmu IDEA zašifrována celá zpráva. Tento klíč relace je pak zašifrován pomocí algoritmu RSA veřejným klíčem příjemce a je zaslán příjemci spolu se zprávou. Příjemce svým soukromým klíčem dešifruje algoritmem RSA klíč relace a pomocí něj pak algoritmem IDEA dešifruje zprávu.

Obr. 3 Podepsání zprávy v PGP elektronickým podpisem

Na druhém obrázku je nakreslen proces podepsání zprávy elektronickým podpisem. Nejdříve odesílatel spočte kryptografický kontrolní součet zprávy algoritmem MD5. Tento kryptografický kontrolní součet pak zašifrován pomocí algoritmu RSA soukromým klíčem odesílatele a je zaslán jako elektronický podpis příjemci spolu se zprávou. Příjemce veřejným klíčem odesílatele dešifruje algoritmem RSA elektronický podpis a porovná jej s kryptografickým kontrolním součtem zprávy.

8.2 Srovnání PEM a PGP

PEM (Privacy Enhanced Mail - bezpečná elektronická pošta) je návrh standardu, definující procedury pro šifrování a autentizaci zpráv s cílem poskytnout služby pro přenos zpráv elektronické pošty při zlepšení bezpečnosti (zajištěním důvěrnosti a důvěryhodnosti) v rámci sítě Internet. Procedury by měly být slučitelné s širokou třídou přístupů správy klíčů, včetně symetrického (soukromý klíč) a asymetrického (veřejný klíč) šifrování dat. PEM je definována dokumenty RFC 1421 až 1424 a je souběžně vyvíjena na mnoha místech celého světa. Diskusi kolem vývoje je věnován mailing list pem-dev@tis.com. PGP (Pretty Good Privacy) je aplikační software s kryptografickými vlastnostmi, vykazujícími vysoký stupeň bezpečnosti. Je určen pro celou škálu platforem a využívá kryptografických technik, používajících veřejný klíč. Uživatelům umožňuje pohodlnou výměnu zpráv nebo souborů při zajištění bezpečnosti (utajení) a autentizace. PGP verze 1 definoval a vyvinul Philip Zimmerman z Pretty Good Software. Verze 2 byla vyvinuta pod jeho vedením. O vývoji směrem k tomuto systému (spíše než o vývoji tohoto systému) se diskutuje v Usenet skupině alt.security.pgp.

8.2.1 Uložení klíčů

PGP udržuje dva okruhy klíčů (key-ring) - okruh veřejných klíčů, který obsahuje všechny veřejné klíče známé uživateli, a okruh soukromých klíčů, který obsahuje soukromý klíč (nebo klíče) uživatele. Soukromé klíče jsou chráněny heslovou frází (pass-phrase).

Dokumenty RFC k PEM nenařizují implementační detaily, takže nedefinují přímou analogii.

8.2.2 Generování, distribuce a rušení klíče

Uživatel PGP generuje svou dvojici klíčů (veřejný/soukromý) pomocí dodávaného software. Certifikace je založena na:

· náhodném ASCII řetězci (typicky “jméno <e-mail adresa>”),

· náhodném čísle, odvozeném z příznaků získaných analýzou psaní náhodného textu prostřednictvím klávesnice.

Uživatel chrání svůj soukromý klíč heslovou frází (pass-phrase), která musí být zadána pokaždé, když PGP přistupuje k soukromému klíči. Tento postup zmenšuje problémy v situacích, kdy uživatel ponechá svůj počítač bez dozoru.

Náhodný ASCII řetězec, který je definován uživatelem, se používá jako jméno uživatele při práci s jeho veřejným klíčem. Jeho prostřednictvím se ostatní odkazují na jeho veřejný klíč. Pokud postupujeme podle doporučení, je zaručena jeho unikátnost, což ale není podmínkou. V PEM jsou certifikáty X.509 generovány buď uživatelem nebo určenou osobou nebo hardwarovým zařízením. Veřejný klíč je podepsán CA uživatele a je uložen na adresářovém serveru (directory server). Detaily kolem udržování soukromého klíče se liší v závislosti na implementaci. Při použití hardwarového podpisového zařízení (například SafeKeyper nebo Tessara) je soukromý klíč uložen v čipové kartě. Na uživatelův veřejný klíč se odkazujeme pomocí jeho jednoznačného jména definovaného X.500. U tohoto rozlišovacího jména je zaručena jednoznačnost a je navrženo tak, aby bylo popisné a rozšiřitelné. Veřejné klíče PGP se typicky šíří prostřednictvím elektronické pošty, BBS nebo prostřednictvím klíčových serverů, založených na elektronické poště. Aby bylo zabráněno jejich zneužití, budou klíče potvrzovány třetí stranou. Každý uživatel PGP se může rozhodnout, které třetí straně důvěřuje a které nedůvěřuje (podporuje se i omezená důvěra - limited trust). Veřejný klíč člověka, kterému důvěřuje, musí uživatel obdržet bezpečným způsobem (verifikace “by word of mouth” je podporována prostřednictvím elektronických podpisů klíče).

Pokud uživatel získá veřejný klíč podepsaný důvěryhodným subjektem, považuje jej za důvěryhodný veřejný klíč. Veřejné klíče se šíří prostřednictvím tzv. “trusted introducer” (důvěrníků). Důvěryhodnost není přenositelná (tranzitivní). Jestliže A důvěřuje B a B důvěřuje C, pak A nemusí důvěřovat C. B samozřejmě může důvěřovat C do té míry, že je ochotný znovu podepsat klíče, které před tím podepsal C, čímž zajišťuje přenos důvěryhodnosti.

Veřejné klíče PEM mohou být šířeny libovolným způsobem, obvykle elektronickou poštou nebo pomocí adresářových služeb X.500. Jsou podepsány soukromým klíčem CAutority odesílajícího, takže mohou být verifikovány odpovídajícím veřejným klíčem. Ten můžeme získat od CAutorit, které se nacházejí výše v hierarchii.

PEM klíče v sobě obsahují dobu platnosti, po jejímž uplynutí se považují za vypršené. Používání dlouhé doby platnosti se nedoporučuje (jde o obdobu doporučení časté změny přihlašovacího hesla), protože při podezření ze zkompromitování klíče musí být klíč zrušen. Tato zásada vyvolává problémy s archivovanými zprávami (poštou), které nemohou být po vypršení platnosti klíče verifikovány.

Certificate Revocation Lists (CRL - seznamy zrušených certifikátů) se udržují v adresářích X.500 nebo v poštovních schránkách udržovaných každým PCA. Pokud tedy používáme prostředky pro přístup k CRL databázím, mohou být kompromitované certifikáty rychle zrušeny. CRL musí být distribuovány všem uživatelům, kteří udržují lokální seznamy (cache) certifikátů.

Klíče PGP nemají definovánu dobu platnosti a jejich rušení (zneplatnění) není obecně možné. Protože se klíče šíří ad hoc, často “by word of mouth”, je nemožné zajistit zrušení nebo certifikaci v případě kompromitování. Uživatel sice může rozeslat “certifikát o zrušení klíče” (“key revocation certificate”), ale neexistují žádné záruky, že se tato zpráva dostane ke všem, kteří udržují kompromitovaný veřejný klíč ve svém okruhu veřejných klíčů (public key-ring).

Certifikát o zrušení veřejného klíče je podepsán soukromým klíčem uživatele. V případě současné ztráty soukromého klíče je zrušení veřejného klíče tímto způsobem nemožné, protože nezbytný certifikát o zrušení nemůže být podepsán.

8.2.3 Model důvěry (trust model)

PEM předpokládá hierarchickou distribuci klíčů. Existuje centralizované řízení zabezpečené malým počtem kořenových (root) serverů (TLCA), na kterých je vybudována veškerá důvěryhodnost. Důvěra v tyto servery je povinná. “Vím kdo jste, protože vaše CA potvrdila vaši identitu, odpovídající PCA potvrdila identitu vaší CA, a TLCA potvrdila identitu PCA.”

PGP předpokládá rozšíření důvěry prostřednictvím sítě. “Vím kdo jste, protože znám někoho jiného (komu věřím), kdo říká, že jste tím, kým říkáte že jste.” Ale stranu, která ručí za ostatní uživatele, si uživatel vybírá sám. Uživatel dokonce nemusí věřit nikomu a může získat všechny potřebné klíče přímo. Každý uživatel se tak stává svým vlastním TLCA a každá důvěryhodná třetí strana se stává důvěryhodným CA. Neexistuje žádný ekvivalent PCA.

Porovnáme-li výsledný efekt, pak PEM předpokládá, že uživateli nelze věřit při verifikaci certifikačního řetězce u podepsané zprávy (sémantická důvěra v protikladu k syntaktické správnosti), zatímco PGP předpokládá, že pouze uživatel je oprávněn k rozhodnutí, komu bude důvěřovat.

8.2.4 Cílové aplikace

PEM byla vždy navrhována s přihlédnutím k práci s elektronickou poštou. Autentizace je zde důležitější než utajení, soukromí (není možné zaslat PEM zprávu, která není autentizována).

PGP považuje utajení (soukromí) za důležitější, než autentizaci. Systém PGP byl původně navržen pro zabezpečení libovolných binárních souborů. Aplikace pro elektronickou poštu byly přidány později prostřednictvím kódování base-64. PGP navíc binární soubory před šifrováním komprimuje. Tím se redukuje velikost zasílaných dat kódovaných pomocí base-64. Návrhářům PEM šlo více o identitu než o stupeň důvěryhodnosti. PGP je založeno na pragmatičtějším pohledu a zavádí mnohem pružnější model důvěry. Někdy jsou si ovšem identita a důvěryhodnost rovny.

Bezpečnostní funkce	Typ zabezpečení v terminologii PEM	Parametry na příkazovém řádku PGP
Čistý text, podepsaný	MIC-CLEAR	-sta +clearsig=on
podepsaný	MIC-ONLY	-sta
podepsaný a šifrovaný	ENCRYPTED	-stea
pouze šifrovaný	<nepoužívá se>	-tea

Tabulka 1: Porovnání zabezpečení PEM a PGP

Pokud má být zpráva posílána dál (forward), může ji PGP redukovat do podoby ClearSigned (MIC-CLEAR). Dokumenty RFC k PEM navíc specifikují, že každá implementace musí být schopná snížit zabezpečení zpráv. Nicméně ne všechny implementace tento rys podporují.

8.2.5 Shrnutí

PEM byla vyvinuta souběžně s pečlivě psanou specifikací. PGP byl původně napsán jedním člověkem (RFC definující formát zpráv se připravuje). PEM představuje pouze protokol pro výměnu zpráv, zatímco k PGP patří řada spustitelných souborů (programů), které zahrnují řadu funkcí, které bychom nalezli na uživatelské straně implementací PEM (user agent). Obrovská výhoda PGP vyplývá ze skutečnosti, že existuje jedna (konzistentní) sada programů, kterou všichni používají a která je vyvíjená malým týmem.

Jedním z návrhových cílů PEM byl návrh systému s dlouhodobou perspektivou, využívaného stovkami milionů uživatelů a miliony společností. Jednou z překážek v zavádění PEM je nedostatečná infrastruktura pro podporu této rozšiřovatelnosti.

Rozšíření PGP v širokém měřítku mohou bránit následující rysy:

· neexistující způsob vyjádření certifikační politiky;

· chybějící zaručené rušení certifikátů;

· chybějící přísná správa prostoru jmen.

První dva rysy působí proti zavádění PGP v komerčních a státních aplikacích, zatímco třetí rys přináší potenciální problémy související s rozšiřovatelností.

Krátce, PGP je pragmatické praktické řešení problému, které se vyvíjí v okamžicích, kdy jsou nalezeny hranice. PEM představuje mnohem elegantnější řešení, ale požadavky na infrastrukturu jej činí mnohem těžkopádnějším. Každý ze systémů má své odbytiště a ze vzájemného propojení (interoperability) obou mohou vyplynout značné výhody.

9. Odkazované normy ISO a doporučení CCITT

ISO 7498-1, X.200

Information Processing Systems, Open Systems Interconnection, 1: Basic Reference Model, 1984

ISO 7498-2

Information Processing Systems, Open Systems Interconnection, 2: Security Architecture, 1988

ISO 8073

Information Processing Systems, Open Systems Interconnection, Connection Oriented Transport Protocol Specification, Add.2: Class 4 Operation over Connectionless Network Services

ISO 8208, X.25

Information Processing Systems, Open Systems Interconnection, X.25 Packet Level Protocol for Date Terminal Equipment

ISO 8473

Information Processing Systems, Open Systems Interconnection, Protocol for Providing the Connectionless-mode Network Service (Internetwork Protocol)

ISO 8650

Information Processing Systems, Open Systems Interconnection, Peer Entity Authentication During Association Establishment, 1989

ISO 8802-2

Information Processing Systems, Open Systems Interconnection, Local Area Networks, Part 2: Logical Link Control

ISO 8802-3

Information Processing Systems, Open Systems Interconnection, Local Area Networks, Part 3: Carrier Sense Multiple Access with Collision Detection, Access Method and Physical Layer Specifications, 1989

ISO 8823, X.226

Information Processing Systems, Open Systems Interconnection, Connection Oriented Presentation Protocol Specification, 1988

ISO 9594 8, X.509

Information Processing Systems, Open Systems Interconnection, The Directory, Part 8: Authentication Framework, 1988

ISO 9594-1, X.500

Information Processing Systems, Open Systems Interconnection, Part 1: The Directory - Overview of Concepts, Models and Services, 1989

ISO 9594-2, X.509

Information Processing Systems, Open Systems Interconnection, Part 2: The Directory, Part 8: Authentication Framework, 1989

X.21

Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data ntwork, 1989

X.400

Message Handling, 1989

10. Literatura

[BLP76] Bell, D. E. - LaPadula, L. J.: Secure Computer Systems: Unified Exposition and Multics Interpretation, Report MTR-2997 Rev. 1, MITRE Corporation, Bedford, Mass, 1976.

[Cur90] Curry D. A.: Improving the Security of your UNIX System, ITSTD-721-FR-90-21, SRI International, April 1990

[DES77] Data Encryption Standard, FIPS Publ. 46, NBS Wash., 1977.

[DSF89] DTI Commercial Computer Security Centre: Security Functionality Manual, V21, Department of Trade and Industry, United Kingdom, February 1989.

[FC] Federal Criteria for Information Technology Security, Volume I and II, US National Institute of Standards and Technology & National Security Agency, December 1992

[ISO90a] Proposed Draft for End System to End System Security Protocol, ISO/IEC JTC1/SC6, 1990

[ISO90b] Apendix B to UK Proposal for Network Layer End System to End System Security Protocol, ISO/IEC JTC1/SC6, 1990

[ISO90b] Working Draft Non-Repudation Framework, ISO/IEC JTC1/SC21 N5046, 1990

[ITSEC] Information Technology Security Evaluation Criteria (ITSEC), Office for Official Publications of the European Communities, Luxembourg 1991, ISBN 92-826-3004-8

[Lam90] Lampson, B.W.: Requirements and Technology for Computer Security, preliminary report, 1990

[LHM84] Landwehr, C. E - Heitmeyer, C. L. - McLean, J.: A Security Model for Military Message Systems, ACM Transactions on Computer Systems, Vol. 2 No. 3, August 1984, pp. 198-222.

[Mor78] Morris R., Thompson K.: Password Security: A Case History, in UNIX System Manager's Manual, 4.3 Berkeley Software Distribution, University of California, Berkeley, April 1986

[MSFR] Minimum Security Functionality Requirements for Multi-User Operating Systems, Computer Security Division, Computer Systems Laboratory, US National Institute of Standards and Technology, Issue 1, January 28, 1992

[MSR] Minimum Security Requirements for Multi-User Operating Systems, NISTIR-5153, Computer Security Division, Computer Systems Laboratory, US National Institute of Standards and Technology, March 1993

[PAS92] Roe. M.: PASSWORD R2.5: Certification Authority Requirements, Cambridge University Computer Laboratory, Computer Security Group, Version 1.0, November 1992

[RSA78] Rivest, R. — Shamir, A. — Adleman, L.: A method for obtaining digital signatures and public key cryptosystems, CACM 21, 2 (Feb.), 120-126.

[TCSEC] Trusted Computer Systems Evaluation Criteria, DOD 5200.28-STD, Department of Defense, United States of America, December 1985.

[ZSIEC] Criteria for the Evaluation of Trustworthiness of Information Technology (IT) Systems, ISBN 3-88784-200-6, German Information Security Agency (Bundesamt für Sicherheit in der Informationstechnik), Federal Republic of Germany, January 1989.

.