VyÜlo v t²denφku: | CHIPweek |
╚φslo: | 36/96 |
Datum: | 4. zß°φ 1996 |
Strana: | 13 |
Rubrika/kategorie: | Principy poΦφtaΦov²ch sφtφ |
Modul: | Sφ¥ov² model TCP/IP |
Dφl: | 8 |
O problematice bezpeΦnosti by se dalo povφdat velmi dlouho, a bude to vd∞Φn² nßm∞t na n∞kter² z dalÜφch modul∙ tohoto serißlu. Zde, v tomto modulu o TCP/IP, vÜak mßme k dispozici jen jeden dφl, a tak se musφme omezit jen na vzßjemn² vztah protokol∙ TCP/IP a bezpeΦnosti. V²tka o malΘ bezpeΦnosti, citovanß v podtitulu dneÜnφho dφlu a adresovanß Internetu, je toti₧ ve skuteΦnosti urΦena protokol∙m TCP/IP, na kter²ch je dneÜnφ Internet postaven a na kter²ch funguje.
P°ed odpov∞dφ na tuto v²tku je velmi d∙le₧itΘ uv∞domit si, ₧e vztah protokol∙ TCP/IP k bezpeΦnosti nebyl p∙vodn∞ ₧ßdn². V tom smyslu, ₧e p°i jejich vzniku nebyly otßzky bezpeΦnosti souΦßstφ zadßnφ, a tak ani nebyly °eÜeny. Auto°i TCP/IP se proto soust°edili na jinΘ otßzky (celkovou efektivnost a flexibilitu, viz p°edchozφ dφly), a nenφ p°φliÜ na mφst∞ jim to vyt²kat. Podφvejme se rad∞ji na to, v Φem doopravdy spoΦφvß äabsence bezpeΦnostnφho cφt∞nφ" v protokolech TCP/IP.
Snad nejvφce b²vß zd∙raz≥ovßn fakt, ₧e p°enosovΘ sφt∞ na bßzi TCP/IP p°edstavujφ pouze nezabezpeΦen² p°enosov² kanßl. To je pravda, nebo¥ takovΘto sφt∞ (a₧ do ·rovn∞ sφ¥ovΘ vrstvy, a to vΦetn∞) negarantujφ:
Prvnφ aspekt jsme v tomto modulu ji₧ vφcekrßt diskutovali. Je °eÜiteln² pom∞rn∞ snadno (p°φmo v rßmci TCP/IP nap°φklad protokolem TCP na ·rovni transportnφ vrstvy), a z hlediska bezpeΦnosti nenφ p°φliÜ äbolestiv²". Zato druh² aspekt je mnohem äbolestiv∞jÜφ" - po technickΘ strßnce neb²vß p°φliÜ t∞₧kΘ änapφchnout" n∞jakou p°enosovou cestu a monitorovat po nφ p°enßÜenß data. Samotn² protokol IP, kter² se starß o p°enos t∞chto dat na ·rovni sφ¥ovΘ vrstvy, se nesna₧φ je n∞jak k≤dovat, Üifrovat Φi jinak upravovat. Pokud se pak takovßto data dostanou do nepovolan²ch rukou, je relativn∞ snadnΘ odvodit si jejich v²znam.
Obrana proti tomu je ale v principu jednoduchß - äkdy₧ vφm, ₧e mßm k dispozici pouze nezabezpeΦen² p°enosov² kanßl, nep°enßÜφm po n∞m nezabezpeΦenΘ zprßvy". Mφsto toho je t°eba p°enßÜet citlivΘ zprßvy v takovΘ podob∞, aby bylo v zßsad∞ jedno, jestli se dostanou n∞komu nepovolanΘmu do rukou Φi nikoli. Tedy zprßvy vhodn²m zp∙sobem zak≤dovanΘ, tak aby pro p°φpadnΘho nepovolanΘho p°φjemce nem∞ly ₧ßdnou cenu.
Dnes ji₧ existuje velmi mnoho technik, kterΘ dokß₧φ zajistit dostateΦn∞ ·ΦinnΘ zak≤dovßnφ jak²chkoli dat. DostateΦn∞ ·ΦinnΘ v tom smyslu, ₧e p°φpadnΘmu nepovolanΘmu p°φjemci by dalo ne·nosn∞ mnoho prßce, ne₧ by je dokßzal rozluÜtit. O principech a myÜlenkßch, na kter²ch jsou tyto techniky postaveny, si ale budeme moci pov∞d∞t a₧ v samostatnΘm modulu. Zde jen malou poznßmku o tom, ₧e jde obecn∞ o tzv. Üifrovßnφ, angl. encryption.
DalÜφm faktorem, kter² protokol∙m TCP/IP nep°idßvß na bezpeΦnosti, je jejich dosti velkß äd∙v∞°ivost", zvlßÜt∞ pak na aplikaΦnφ ·rovni. Nap°φklad u elektronickΘ poÜty je relativn∞ velmi snadnΘ odeslat urΦitou zprßvu jmΘnem n∞koho jinΘho, nebo t°eba i pod ·pln∞ smyÜlen²m jmΘnem. DalÜφm p°φkladem m∙₧e b²t tolik oblφbenß slu₧ba WWW, kterß sice pamatuje na pot°ebu ov∞°ovßnφ identity u₧ivatele (tzv. authentizaci) a v p°φpad∞ pot°eby podporuje prßci s u₧ivatelsk²mi hesly a jmΘny, ale p°enßÜφ je po sφti v nezak≤dovanΘ podob∞!
Dokud byly aplikaΦnφ protokoly TCP/IP pou₧φvßny p°edevÜφm v akademickΘm sv∞t∞, nebyla p°φpadnß bezpeΦnostnφ rizika zase a₧ tak v²znamnß. Jakmile se ale Internet, fungujφcφ na bßzi TCP/IP, zaΦal pou₧φvat i ke komerΦnφm ·Φel∙m, situace se radikßln∞ zm∞nila. Nap°φklad u d∙le₧it∞jÜφ obchodnφ korespondence (ale nejen tΘ) je jist∞ velmi pot°ebnΘ mφt jistotu, ₧e konkrΘtnφ zprßva pochßzφ od toho, kdo se vydßvß za jejφho autora (a stejn∞ tak je ₧ßdoucφ mφt mo₧nost mu prokßzat, ₧e tuto zprßvu skuteΦn∞ odeslal - co kdy₧ se t°eba jednß o zßvaznou objednßvku). Nehled∞ pak na po₧adavky, kterΘ na souΦasn² Internet kladou r∙znΘ strategie placenφ elektronickou cestou.
I v tΘto oblasti dnes existujφ mechanismy a techniky, kterΘ jsou schopnΘ uspokojit i relativn∞ velmi p°φsnΘ nßroky na zabezpeΦenφ. Jejich praktickΘmu nasazenφ vÜak stojφ v cest∞ celß °ada p°ekß₧ek, charakteru:
Podφvejme se nynφ podrobn∞ji na tuto poslednφ otßzku, kterß se tΘmatu tohoto dφlu t²kß nejvφce.
Ve sv∞t∞ TCP/IP se a₧ dosud objevily dva zßkladnφ p°φstupy k implementaci zabezpeΦovacφch mechanism∙. Hlavnφ rozdφl mezi nimi p°itom znovu o₧ivuje zßkladnφ filosofickΘ dilema, kterΘ ji₧ jednou museli vy°eÜit jak auto°i TCP/IP, tak i auto°i referenΦnφho modelu ISO/OSI. Jde o otßzku zda urΦitΘ prost°edky (zde: zabezpeΦovacφ mechanismy) majφ b²t k dispozici vÜem, nebo jen t∞m, kte°φ je skuteΦn∞ pot°ebujφ.
Prvnφ p°φpad - zabezpeΦovacφ mechanismy pro vÜechny - nutn∞ vede na zavedenφ samostatnΘ äzabezpeΦovacφ vrstvy". Takov²to nßvrh pochßzφ od firmy Netscape, a jmenuje se SSL (Secure Sockets Layer). Je zalo₧en na myÜlence, ₧e do rozhranφ mezi sφtφ a aplikacφ se vlo₧φ novß vrstva, kterß p°ekryje p∙vodnφ nezabezpeΦen² p°enosov² subsystΘm, sama zajistφ pot°ebnΘ zabezpeΦovacφ mechanismy, a sv²m u₧ivatel∙m (tj. jednotliv²m aplikacφm) nabφdne iluzi ₧e pracujφ v prost°edφ zabezpeΦenΘ sφt∞. V²hodou je skuteΦnost, ₧e aplikace se nemusφ m∞nit (a nemusφ si samy uv∞domovat existenci zabezpeΦovacφch mechanism∙, resp. vychßzet jim vst°φc). Podpora rozhranφ SSL je dnes ji₧ standardn∞ zabudovßvßna nap°φklad do vÜech browser∙ Navigator firmy Netspace.
Alternativnφm p°φstupem, ve stylu äbezpeΦnost jen pro n∞koho", je zabudovat p°φsluÜnΘ zabezpeΦovacφ mechanismy p°φmo do konkrΘtnφ aplikace, kterß zabezpeΦenφ vy₧aduje. V²hodou je pak to, ₧e p°φsluÜnΘ mechanismy mohou b²t lΘpe !uÜity na mφru" pot°ebßm p°φsluÜnΘ aplikace a jejφm specifick²m po₧adavk∙m. P°φkladem m∙₧e b²t protokol S-HTTP (Secure HTTP), pochßzejφcφ od firmy EIT (Enterprise Integration Technology), a dnes prosazovan² sdru₧enφm TERISA. Zde jde ve svΘ podstat∞ o nadstavbu nad protokolem HTTP, resp. o rozÜφ°enφ jeho stßvajφcφ verze.
P°edpovφdat, zda se v budoucnosti jedna z uveden²ch variant prosadφ tak, aby druhou zcela vytlaΦila, je prakticky nemo₧nΘ. SouΦasn² stav, kdy v²znamnφ producenti softwaru oznamujφ svou podporu ob∞ma variantßm souΦasn∞, sv∞dΦφ spφÜe o mo₧nΘ koexistenci.
Jednou z velmi aktußlnφch skupin aplikacφ, kterΘ se zabezpeΦenφm doslova stojφ a padajφ, jsou aplikace umo₧≥ujφcφ provßd∞t nejr∙zn∞jÜφ transakce v on-line re₧imu, prost°ednictvφm Internetu. NejΦast∞ji pak transakce finanΦnφ, kterΘ by umo₧≥ovaly nap°φklad nakupovßnφ a p°φmΘ placenφ prost°ednictvφm Internetu, provßd∞nφ bankovnφch operacφ na dßlku atd. Tato oblast byla a₧ dosud reprezentovßna zejmΘna aplikacemi umo₧≥ujφcφmi placenφ prost°ednictvφm b∞₧n²ch kreditnφch karet (i kdy₧ ve skuteΦnosti Ülo jen o p°enos pot°ebn²ch ·daj∙ typu Φφsla karty a jejφho PIN-u, zatφmco vlastnφ transakce probφhala jin²mi kanßly). JeÜt∞ nep°φliÜ dßvno se v tΘto oblasti prosazovaly dv∞ alternativnφ koncepce (za jednou z nich stßla firma VISA, a za druhou firma Mastercard). Dnes se ale zdß, ₧e doÜlo k velmi d∙le₧itΘmu posunu - ob∞ v∞tve se slouΦily v jednu jedinou technologii, nazvanou SET (Secure Electronic Transactions). Äe by prßv∞ zde byla budoucnost vÜech bezpeΦn²ch on-line transakcφ?
Zatφm je navrhovanß technologie SET samostatnou technologiφ, kterß formßln∞ nenφ souΦßstφ rodiny protokol∙ TCP/IP. Pokud se ale skuteΦn∞ prosadφ, lze oΦekßvat ₧e se jejφ souΦßstφ stane - ₧e jejφ specifikace ·sp∞Ün∞ projdou ästandardizaΦnφ maÜinΘriφ" sv∞ta TCP/IP, a ten tuto technologii p°ijme za svou.