Secure transactions

Secure transactions (bezpečné transakce): označení pro takový druh on-line transakcí, které kromě své základní charakteristiky (nedělitelnosti) vykazují dalsí vlastnosti bezpečnostního charakteru: je u nich například zajistěna privátnost, integrita, autentikace apod. Jde zejména o transakce určené pro prostředí veřejných sítí s nízkou úrovní zabezpečení, typicky pro prostředí Internetu.

Definovat pojem "transakce" není nijak snadné - v různých oborech lidské činnosti můze mít tento termín poněkud jiný obsah. Nejjednodussí je to zřejmě v oblasti peněznictví, alias ve finančním sektoru: pod "finanční transakcí" si snad kazdý dokáze představit operace typu převodu určité částky z jedné kapsy do druhé, resp. z jednoho účtu na druhý. Jiz zde, při takto jednoduché představě "finanční transakce", vsak lze velmi názorně popsat základní aspekt, který je charakteristický a společný pro chápání transakcí i v jin 555d318f ých oborech: transakce je něčím, co by "nikdy nemělo být roztrzeno". Jen si zkuste představit právě bankovní převod určité finanční částky, prováděný na počítači a tvořený dvěma po sobě jdoucími operacemi: odečtením příslusné částky z jednoho účtu, a jejím přičtením k účtu druhému. Teď si ale představte, ze po provedení první operace (odečtení částky z prvního účtu) dojde k výpadku systému, například k úplnému zhroucení příslusného počítače, takze druhá z operací se jiz nestihla provést. Jak potom pokračovat, po obnově funkceschopnosti celého systému - má být celá transakce povazována za dokončenou? To asi ne. Nebo má být provedena znovu? Stejně spatně! Jedinou spravedlivou mozností by bylo pokračovat od místa jejího přerusení. To ale nemusí být zdaleka vzdy realizovatelné, například uz jen proto, ze větsinou nejde dostatečně přesně (a také dostatečně snadno) zjistit, kam az se vlastně při zpracovávání transakce dospělo, a odkud by se tedy mělo pokračovat. Vzato z čistě technického hlediska by tedy transakce měla být něčím, co se buď provede úplně celé (resp. vsechno), nebo se to neprovede vůbec (resp. neprovede se nic), přičemz zádné "mezi" jednoduse neexistuje.

Pokud bychom chtěli pojem transakce poněkud zobecnit, pak by se zřejmě jednalo o určitou skupinu dílčích operací, které spolu nějak logicky souvisí (tvoří logický celek), a jejich provedení sleduje určitý konkrétní společný cíl. Nemusí se nutně jednak o finanční transakci typu převodu penězní částky, ale můze jít například i o podání závazné objednávky, o dodání zbozí (například programu, jde-li o prodej softwaru), o rezervaci místenky na konkrétní dopravní spoj, rezervaci zájezdu či ubytování v hotelu apod. Základní pozadavek na "neroztrzitelnost" (nedělitelnost) těchto transakcí je pak doprovázen i vcelku zřejmým pozadavkem na to, aby bylo vzdy jasné, zda se transakce provedla či nikoli - coz dále souvisí s tím, ze větsina transakcí nemá vlastnost, v matematice označovanou pikantním termínem "být idempotentní". Idempotentní operace je totiz taková, která můze být vícekrát opakována (tj. musí být provedena alespoň jednou, ale můze být provedena i dvakrát, třikrát atd.), přičemz její celkový efekt je nezávislý na počtu opakování. Například u finanční transakce typu převodu určité částky z jednoho účtu na jiný je snad dostatečně jasné, ze idempotentní není (a proto je nutné se spolehlivě dozvědět, zda se jednou vyzádanou transakce podařilo úspěsně dokončit či nikoli, a teprve v tomto druhém případě má smysl ji opakovat).

Ve světě počítačů nastěstí nejsou transakce ničím novým - pozadavky na jejich podporu se vyskytují jiz delsí dobu, a lidé uz se naučili jak je správně implementovat. Snad nejvíce je tzv. transakční zpracování zvládnuto v oblasti databází a nejrůznějsích rezervačních systémů, kde se zrodila celá "disciplína" nesoucí označení OLTP (On-line Transaction Processing). Zajímavý je zde přívlastek "on-line", který naznačuje ze můze jít o transakce probíhající "zivě" (v reálném čase, on-line) mezi vzájemně distribuovanými slozkami - například mezi databází bězící na databázovém serveru a jejím klientem bězícím na pracovní stanici v téze lokální síti, nebo můze jít o transakci probíhající mezi rezervačním terminálem v cestovní kanceláři a velkou centrální databází bězící na vzdáleném hostitelském počítači na jiném kontinentu apod. Pro takovéto "klasické" transakční zpracování, které je dnes v zásadě dostatečně zvládnuté, je přitom charakteristické pouzití privátních (či "neveřejných") komunikačních kanálů, které mohou být uzpůsobeny pozadavkům samotného transakčního zpracování, a mohou jim také vycházet v mnohém vstříc.

V současné době ale velmi sílí tlak na to, aby nejrůznějsí sluzby vykazující "transakční charakter" byly provozovány i nad takovými komunikačními infrastrukturami, které transakčnímu zpracování nevychází dvakrát vstříc - jde například o sluzby spadající do oblasti elektronického obchodování, které by měly být provozovány v prostředí Internetu, nejlépe na platformě sluzby World Wide Web. Problém je zde předevsím v tom, ze Internet je veřejnou sítí, která sama o sobě nenabízí dostatečné zabezpečení například pro placení elektronickou formou, a naopak přinásí vselijaká potenciální rizika, se kterými je nutné předem počítat. Není nutné kvůli tomu Internet zatracovat, ani jej předem vylučovat z celé sféry elektronického obchodování - pouze je třeba pečlivě zvázit, jaké dalsí pozadavky by na transakce v prostředí Internetu měly být kladeny. Navíc je zde nutné vzít do úvahy i to, ze pozadované transakce zde mohou probíhat mezi subjekty, které mají mezi sebou mnohem volnějsí vazby nez v případě "klasického" on-line transakčního zpracování: zde spolu obvykle komunikují dvě strany, které se "jiz znají a ví o sobě", zatímco v prostředí otevřeného Internetu něco takového větsinou nebude splněno.

K základnímu pozadavku, kterým je "neroztrzitelnost" (resp. nedělitelnost) transakcí by tedy v prostředí Internetu nutně měla přibýt i podpora jejich celkového zabezpečení. Co si ale pod tím představit?

Například tzv. privátnost (privacy), která zajistí aby údaje obsazené v transakci neskončily v rukou někoho nepovolaného (například číslo kreditní karty v rukou člověka, který tuto informaci následně zneuzije a nechá si z cizí karty zaplatit vlastní nákup). Nebo tzv. autentikace (authentication), neboli ověření identity vsech stran, vstupujících do transakce - tak aby například kupující měl jistotu, ze se skutečně "baví" se seriózním obchodníkem, a stejně tak obchodník měl jistotu, ze se "baví" se skutečným kupujícím. Důlezitá je i tzv. integrita transakce, neboli pozadavek aby ji někdo "po cestě" nezměnil, a neuvedl například sebe jako příjemce zbozí, které platí skutečný kupující. Nebo pro zadávání závazných objednávek je nutné, aby jejich autor měl jistotu ze byly přijaty, a stejně tak jejich příjemce měl jistotu, ze jsou autentické, a ze se například nestane, ze si to druhá strana časem rozmyslí a jednoduse popře, ze kdy jakou objednávku poslala (tzv. nemoznost popření, non-repudiation). Ve specifikaci pozadavků na "bezpečné transakce" bychom takto mohli jestě nějakou chvíli pozadovat, ale to by bylo spíse na dalsí povídání, zaměřené jiz specificky na oblast bezpečnosti a mozných způsobů ohrození. Důlezitý je spíse závěr: pozadavků je opravdu hodně, tolik ze není mozné je v praxi splnit beze zbytku vsechny, optimálně pro vsechny druhy transakcí, které by lidé chtěli prostřednictvím Internetu provádět. V praxi se proto můzeme setkat spíse s konkrétními řeseními, která jsou sita na míru specifickým potřebám - například otázce placení prostřednictvím Internetu, kde je asi "poptávka" po zabezpečených transakcích největsí. Příkladem takovéhoto řesení, sitého na míru právě potřebám bezpečného placení po Internetu, je protokol SET (Secure Electronic Transactions), ke kterému se jestě vrátíme v samostatném dílu této rubriky.

Zajímavým momentem je také rozhodnutí, jakým způsobem (a na jaké úrovni) má být podpora bezpečných transakcí v prostředí Internetu realizována. Zde existují dva základní přístupy, které se lisí v názoru na to, kdo vsechno bude podporu bezpečných transakcí potřebovat. Jeden přístup počítá s tím, ze ji bude potřebovat spíse větsina aplikací, a tudíz dochází k závěru, ze je rozumnějsí implementovat potřebné mechanismy jako samostatnou vrstvu, dostupnou k vyuzití vsem aplikacím (ale na druhé straně univerzálním, a tudíz i méně efektivním způsobem, který by vyhověl vsem aplikacím). Druhý přístup naopak vychází z předpokladu, ze podporu zabezpečených transakcí budou potřebovat jen některé specifické aplikace (nejvíce sluzba WWW a elektronická posta), a ze se tudíz vyplatí příslusné mechanismu "usít na míru" příslusným aplikacím, resp. podporu bezpečných transakcí zabudovat přímo do těchto aplikací.

Konkrétním příkladem uplatnění prvního přístupu je mechanismus SSL (Secure Sockets Layer), vyvinutý firmou Netscape, a podporovaný větsinou významnějsích browserů (i mnoha WWW servery. Problém tohoto řesení je ale v jeho malé "zabezpečovací síle" - první verze SSL byla implementována tak nesťastně, ze ji bylo mozné prolomit na bězném PC jiz za 25 sekund. Novějsí, opravená verze SSL v browserech netscape vsak nedávno byla prolomena také.

Příkladem druhého přístupu jsou protokoly S-HTTP (Secure HTTP, neboli upravený protokol HTTP pro komunikaci mezi WWW serverem a jeho klientem), a protokol S-MIME (Secure MIME, pro elektronickou postu).

Protokol SET, zmiňovaný výse, pak představuje jestě dalsí kategorii řesení - jde vlastně o samostatné řesení na aplikační úrovni, které teprve musí být "posazeno" na nějakou vhodnou platformu a zde implementováno (počítá se hlavně s platformou Web-u).