Secure transactions

Secure transactions (bezpečné transakce): označení pro takový druh on-line transakcí, které kromě své základní charakteristiky (nedělitelnosti) vykazují další vlastnosti bezpečnostního charakteru: je u nich například zajiště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ůže mít tento termín poněkud jiný obsah. Nejjednodušší je to zřejmě v oblasti peněžnictví, alias ve finančním sektoru: pod "finanční transakcí" si snad každý dokáže představit operace typu převodu určité částky z jedné kapsy do druhé, resp. z jednoho účtu na druhý. Již zde, při takto jednoduché představě "finanční transakce", však lze velmi názorně popsat základní aspekt, který je charakteristický a společný pro chápání transakcí i v jiných oborech: transakce je něčím, co by "nikdy nemělo být roztrženo". 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říslušné částky z jednoho účtu, a jejím přičtením k účtu druhému. Teď si ale představte, že po provedení první operace (odečtení částky z prvního účtu) dojde k výpadku systému, například k úplnému zhroucení příslušného počítače, takže druhá z operací se již nestihla provést. Jak potom pokračovat, po obnově funkceschopnosti celého systému - má být celá transakce považována za dokončenou? To asi ne. Nebo má být provedena znovu? Stejně špatně! Jedinou spravedlivou možností by bylo pokračovat od místa jejího přerušení. To ale nemusí být zdaleka vždy realizovatelné, například už jen proto, že většinou nejde dostatečně přesně (a také dostatečně snadno) zjistit, kam až 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. všechno), nebo se to neprovede vůbec (resp. neprovede se nic), přičemž žádné "mezi" jednoduše 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ěžní částky, ale může jít například i o podání závazné objednávky, o dodání zboží (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í požadavek na "neroztržitelnost" (nedělitelnost) těchto transakcí je pak doprovázen i vcelku zřejmým požadavkem na to, aby bylo vždy jasné, zda se transakce provedla či nikoli – což dále souvisí s tím, že většina transakcí nemá vlastnost, v matematice označovanou pikantním termínem "být idempotentní". Idempotentní operace je totiž taková, která může být vícekrát opakována (tj. musí být provedena alespoň jednou, ale může být provedena i dvakrát, třikrát atd.), přičemž 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é, že idempotentní není (a proto je nutné se spolehlivě dozvědět, zda se jednou vyžádanou transakce podařilo úspěšně dokončit či nikoli, a teprve v tomto druhém případě má smysl ji opakovat).

Ve světě počítačů naštěstí nejsou transakce ničím novým – požadavky na jejich podporu se vyskytují již delší dobu, a lidé už 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ější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 že může jít o transakce probíhající "živě" (v reálném čase, on-line) mezi vzájemně distribuovanými složkami – například mezi databází běžící na databázovém serveru a jejím klientem běžícím na pracovní stanici v téže lokální síti, nebo může jít o transakci probíhající mezi rezervačním terminálem v cestovní kanceláři a velkou centrální databází běží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é použití privátních (či "neveřejných") komunikačních kanálů, které mohou být uzpůsobeny požadavků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ější služby 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 služby spadající do oblasti elektronického obchodování, které by měly být provozovány v prostředí Internetu, nejlépe na platformě služby World Wide Web. Problém je zde především v tom, že 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áší všelijaká 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ážit, jaké další požadavky by na transakce v prostředí Internetu měly být kladeny. Navíc je zde nutné vzít do úvahy i to, že požadované transakce zde mohou probíhat mezi subjekty, které mají mezi sebou mnohem volnější vazby než v případě "klasického" on-line transakčního zpracování: zde spolu obvykle komunikují dvě strany, které se "již znají a ví o sobě", zatímco v prostředí otevřeného Internetu něco takového většinou nebude splněno.

K základnímu požadavku, kterým je "neroztržitelnost" (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 obsažené v transakci neskončily v rukou někoho nepovolaného (například číslo kreditní karty v rukou člověka, který tuto informaci následně zneužije a nechá si z cizí karty zaplatit vlastní nákup). Nebo tzv. autentikace (authentication), neboli ověření identity všech stran, vstupujících do transakce – tak aby například kupující měl jistotu, že se skutečně "baví" se seriózním obchodníkem, a stejně tak obchodník měl jistotu, že se "baví" se skutečným kupujícím. Důležitá je i tzv. integrita transakce, neboli požadavek aby ji někdo "po cestě" nezměnil, a neuvedl například sebe jako příjemce zboží, které platí skutečný kupující. Nebo pro zadávání závazných objednávek je nutné, aby jejich autor měl jistotu že byly přijaty, a stejně tak jejich příjemce měl jistotu, že jsou autentické, a že se například nestane, že si to druhá strana časem rozmyslí a jednoduše popře, že kdy jakou objednávku poslala (tzv. nemožnost popření, non-repudiation). Ve specifikaci požadavků na "bezpečné transakce" bychom takto mohli ještě nějakou chvíli požadovat, ale to by bylo spíše na další povídání, zaměřené již specificky na oblast bezpečnosti a možných způsobů ohrožení. Důležitý je spíše závěr: požadavků je opravdu hodně, tolik že není možné je v praxi splnit beze zbytku všechny, optimálně pro všechny druhy transakcí, které by lidé chtěli prostřednictvím Internetu provádět. V praxi se proto můžeme setkat spíše s konkrétními řešeními, která jsou šita 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ětší. Příkladem takovéhoto řešení, šité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 ještě 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 liší v názoru na to, kdo všechno bude podporu bezpečných transakcí potřebovat. Jeden přístup počítá s tím, že ji bude potřebovat spíše většina aplikací, a tudíž dochází k závěru, že je rozumnější implementovat potřebné mechanismy jako samostatnou vrstvu, dostupnou k využití všem aplikacím (ale na druhé straně univerzálním, a tudíž i méně efektivním způsobem, který by vyhověl všem aplikacím). Druhý přístup naopak vychází z předpokladu, že podporu zabezpečených transakcí budou potřebovat jen některé specifické aplikace (nejvíce služba WWW a elektronická pošta), a že se tudíž vyplatí příslušné mechanismu "ušít na míru" příslušný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ětšinou významnějších browserů (i mnoha WWW servery. Problém tohoto řešení je ale v jeho malé "zabezpečovací síle" – první verze SSL byla implementována tak nešťastně, že ji bylo možné prolomit na běžném PC již za 25 sekund. Novější, opravená verze SSL v browserech netscape však 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 poštu).

Protokol SET, zmiňovaný výše, pak představuje ještě další kategorii řešení – jde vlastně o samostatné řešení 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).