VPN<\/a> ili bez nje.<\/p>\nMre\u017eno \u0161ifriranje u distribuiranoj Ethernet mre\u017ei<\/i><\/p>\n
Sami ure\u0111aji mogu biti ili specijalizirani<\/b> (namijenjeni isklju\u010divo za \u0161ifriranje), ili multifunkcionalni (hibridni, konvergenti<\/b>), tj. obavljaju jo\u0161 i druge funkcije (na primjer, vatrozida ili usmjeriva\u010da). Razli\u010diti dobavlja\u010di klasificiraju svoje ure\u0111aje u razli\u010dite klase\/kategorije, ali to nije va\u017eno \u2013 va\u017eno je samo to, znaju li \u0161ifrirati promet izme\u0111u lokacija, i koje specifikacije pritom imaju.<\/p>\n
Samo da podsjetim da su \u201emre\u017eno \u0161ifriranje\u201c, \u201e\u0161ifriranje prometa\u201c i \u201e\u0161ifriratelj\u201c neformalni termini, iako se \u010desto koriste. Vjerojatno ih ne\u0107ete na\u0107i u ruskim zakonodavnim aktima (uklju\u010duju\u0107i one koji uvode GOST-ove).<\/p>\n
Razine \u0161ifriranja i na\u010dini prijenosa<\/h4>\n \nPrije nego \u0161to zapo\u010dnem s opisivanjem samih karakteristika koje \u0107e se koristiti za ocjenu, prvo se moram pozabaviti jednim va\u017enim pitanjem, odnosno \u201erazinom \u0161ifriranja\u201c. Primijetio sam da se \u010desto spominje kako u slu\u017ebenim dokumentima dobavlja\u010da (u opisima, priru\u010dnicima itd.), tako i u neformalnim raspravama (na pregovorima, na obukama). Kao da svi znaju o \u010demu se radi, ali osobno sam svjedo\u010dio odre\u0111enoj konfuziji.<\/p>\n
Dakle, \u0161to je zapravo \u201erazina \u0161ifriranja\u201c? Jasno je da se radi o broju razine referentnog modela OSI\/ISO, na kojoj se odvija \u0161ifriranje. Pro\u010ditajte GOST R ISO 7498-2\u201399 \u201eInformacijska tehnologija. Umre\u017eenost otvorenih sustava. Osnovni referentni model. Dio 2. Arhitektura za\u0161tite informacija\u201c. Iz ovog dokumenta mo\u017eemo shvatiti da je razina usluge povjerljivosti (jedan od mehanizama za\u0161tite je \u0161ifriranje) razina protokola, a servisna jedinica podataka (\u201ekorisni teret\u201c, podaci korisnika) koja se \u0161ifrira. Kako je napisano u standardu, usluga se mo\u017ee osigurati na istoj razini, \u201esvojim snagama\u201c, kao i pomo\u0107u ni\u017ee razine (tako se naj\u010de\u0161\u0107e to implementira u MACsec-u).<\/p>\n
U praksi postoje dva na\u010dina prijenosa \u0161ifriranih informacija kroz mre\u017eu (odmah pada na pamet IPsec, ali ti na\u010dini se susre\u0107u i u drugim protokolima). U transportnom<\/b> (ponekad se naziva i native) na\u010dinu \u0161ifriraju se samo servisni<\/b> blok podataka, dok naslovi ostaju \u201eotvoreni\u201c, ne\u0161ifrirani (ponekad se dodaju dodatna polja s informacijama o algoritmu \u0161ifriranja, a druga polja se modificiraju, ponovno izra\u010dunavaju). U tunelskom<\/b> na\u010dinu cijeli protokolni<\/b> blok podataka (tj. sama paketa) se \u0161ifrira i inkapsulira u servisni blok podataka iste ili vi\u0161e razine, tj. obavijen je novim naslovima.<\/p>\n
Sama razina \u0161ifriranja u kombinaciji s nekim prijenosnim re\u017eimom nije ni dobra ni lo\u0161a, pa se ne mo\u017ee re\u0107i, na primjer, da je L3 u transportnom re\u017eimu bolji od L2 u tunelskom. Samo od njih ovise mnoge karakteristike koje ocjenjuju ure\u0111aje. Na primjer, fleksibilnost i kompatibilnost. Za rad u mre\u017ei L1 (ponovno prijenos bitnog toka), L2 (komutacija okvira) i L3 (usmjeravanje paketa) u transportnom re\u017eimu potrebna su rje\u0161enja koja \u0161ifriraju na istoj ili vi\u0161oj razini (ina\u010de \u0107e biti \u0161ifrirana adresa i podaci ne\u0107e sti\u0107i na odredi\u0161te), a tunelski re\u017eim omogu\u0107ava prevladavanje ovog ograni\u010denja (iako \u017ertvuje druge va\u017ene karakteristike).<\/p>\n
Transportni i tunelski re\u017eimi \u0161ifriranja L2<\/i><\/p>\n
A sada prije\u0111imo na analizu karakteristika.<\/p>\n
Performanse<\/h4>\n \nZa mre\u017eno \u0161ifriranje, performanse su kompleksan, vi\u0161edimenzionalan pojam. Dogodi se da odre\u0111eni model, nadma\u0161uju\u0107i u jednoj karakteristici performansi, zaostaje u drugoj. Stoga je uvijek korisno razmotriti sve sastavnice performansi \u0161ifriranja i njihov utjecaj na performanse mre\u017ee i aplikacija koje je koriste. Ovdje se mo\u017ee provu\u0107i analogija s automobilom, kojem nije va\u017ena samo maksimalna brzina, ve\u0107 i vrijeme ubrzanja do 'stotke', potro\u0161nja goriva i tako dalje. Karakteristikama performansi tvrtke ponu\u0111a\u010di i njihovi potencijalni naru\u010ditelji pridaju veliku pozornost. Kao pravilo, upravo se prema performansama vr\u0161i rangiranje u linijama ponu\u0111a\u010da ure\u0111aja za \u0161ifriranje.<\/p>\n
Jasno je da performanse ovise o slo\u017eenosti mre\u017enih i kriptografskih operacija izvr\u0161enih na ure\u0111aju (uklju\u010duju\u0107i koliko dobro se ovi zadaci mogu paralelizirati i konvencionalno obraditi), kao i o performansama hardvera i kvaliteti ugra\u0111enog softvera. Stoga se u vi\u0161im modelima koristi performasniji hardver, a ponekad postoji mogu\u0107nost nadogradnje dodatnim procesorima i memorijskim modulima. Postoji nekoliko pristupa za implementaciju kriptografskih funkcija: na op\u0107em centralnom procesoru (CPU), specijaliziranoj ugra\u0111enoj integriranoj cirkvi (ASIC) ili programabilnoj logi\u010dkoj integriranoj cirkvi (FPGA). Svaki pristup ima svoje prednosti i nedostatke. Na primjer, CPU mo\u017ee postati \"usko grlo\" enkripcije, osobito ako procesor nema specijalizirane instrukcije za podr\u0161ku algoritmu enkripcije (ili ako se ne koriste). Specijaliziranim \u010dipovima nedostaje fleksibilnosti; \"flashing\" ih za pobolj\u0161anje performansi, dodavanje novih funkcija ili otklanjanje ranjivosti nije uvijek mogu\u0107e. Osim toga, isplativi su samo pri velikim serijama proizvodnje. Zato je \"zlatna sredina\" postala toliko popularna \u2013 kori\u0161tenje FPGA (na hrvatskom PLIS). Upravo su na PLIS-u razvijeni takozvani kriptoakceleratori \u2013 ugra\u0111eni ili priklju\u010dni specijalizirani hardverski moduli za podr\u0161ku kriptografskim operacijama.<\/p>\n
Budu\u0107i da se radi o mre\u017enom<\/b> enkripciji, logi\u010dno je da performanse rje\u0161enja treba mjereni u istim jedinicama kao i za druga mre\u017ena ure\u0111aja \u2013 propusnosti, postotku izgubljenih paketa (frame loss) i latenciji. Ove jedinice definirane su u RFC 1242. Ina\u010de, u tom RFC-u nije ni\u0161ta spomenuto o \u010desto spominjanoj varijaciji latencije (jitter). Kako mjeriti ove veli\u010dine? Nisam prona\u0161ao metodologiju koja bi bila odobrena u bilo kojim standardima (slu\u017ebenim ili neslu\u017ebenim poput RFC-a) posebno za mre\u017eno enkripciju. Logi\u010dno bi bilo koristiti metodologiju za mre\u017ene ure\u0111aje, utvr\u0111enu u standardu RFC 2544. Mnogi dobavlja\u010di se dr\u017ee nje \u2013 mnogi, ali ne svi. Na primjer, predaju testni promet samo u jednom smjeru umjesto u oba, kao \u0161to je preporu\u010deno<\/b> standardom. No, dobro.<\/p>\n
Mjerenje performansi ure\u0111aja za mre\u017eno \u0161ifriranje ima svoje specifi\u010dnosti. Prvo, ispravno je provesti sva mjerenja za par ure\u0111aja: iako su algoritmi \u0161ifriranja simetri\u010dni, latencije i gubici paketa tijekom \u0161ifriranja i de\u0161ifriranja ne moraju nu\u017eno biti jednaki. Drugo, ima smisla mjeriti upravo deltu, utjecaj mre\u017enog \u0161ifriranja na kona\u010dne performanse mre\u017ee, uspore\u0111uju\u0107i izme\u0111u dviju konfiguracija: bez ure\u0111aja za \u0161ifriranje i s njima. Ili, kao u slu\u010daju hibridnih ure\u0111aja koji kombiniraju nekoliko funkcija uz mre\u017eno \u0161ifriranje, u isklju\u010denom i uklju\u010denom stanju \u0161ifriranja. Ovaj utjecaj mo\u017ee varirati i ovisiti o na\u010dinu povezivanja ure\u0111aja za \u0161ifriranje, o radnim re\u017eimima, a naposljetku i o karakteru prometa. Konkretnije, mnogi parametri performansi ovise o duljini paketa, zbog \u010dega se za usporedbu performansi razli\u010ditih rje\u0161enja \u010desto koriste grafovi koji prikazuju ovisnost tih parametara o duljini paketa, ili se koristi IMIX \u2013 raspodjela prometa po duljinama paketa koja otprilike odra\u017eava stvarno stanje. Ako za usporedbu uzmemo istu osnovnu konfiguraciju bez \u0161ifriranja, mo\u0107i \u0107emo uspore\u0111ivati rje\u0161enja za mre\u017eno \u0161ifriranje koja su implementirana na razli\u010dite na\u010dine, ne ulaze\u0107i u te razlike: L2 s L3, \u201espremi-i-prosledi\u201c (store-and-forward) s premo\u0161\u0107enim (cut-through), specijalizirana s konvergiranima, GOST s AES i tako dalje.<\/p>\n
Shema povezivanja za testiranje performansi<\/i><\/p>\n
Prva karakteristika na koju se obra\u0107a pa\u017enja je \"brzina\" ure\u0111aja za \u0161ifriranje, to jest propusnost<\/b> (bandwidth) njegovih mre\u017enih su\u010delja, brzina protoka bitova. Ona se odre\u0111uje mre\u017enim standardima koje podr\u017eavaju su\u010delja. Za Ethernet uobi\u010dajeni brojevi su 1 Gbit\/s i 10 Gbit\/s. No, kao \u0161to znamo, u svakoj mre\u017ei maksimalna teorijska propusnost<\/b> (propusnost) na svakom njenom nivou je uvek manja od propusnosti: deo propusnosti \u201ese gubi\u201c u me\u0111ukadrovskim intervalima, kontrolnim zaglavljima i sli\u010dno. Ako ure\u0111aj mo\u017ee primiti, obraditi (u na\u0161em slu\u010daju enkriptovati ili dekriptovati) i preneti saobra\u0107aj punom brzinom mre\u017enog interfejsa, tj. sa maksimalnom teorijskom propusno\u0161\u0107u za ovu razinu mre\u017enog modela, onda se ka\u017ee da radi na brzini linije<\/b>. Za to je potrebno da ure\u0111aj ne gubi, ne odbacuje pakete bez obzira na veli\u010dinu i u\u010destalost. Ako ure\u0111aj za enkripciju ne podr\u017eava rad na brzini linije, obi\u010dno se navodi njegova maksimalna propusnost u istim gigabitima u sekundi (ponekad sa naznakom du\u017eine paketa \u2013 \u0161to su paketi kra\u0107i, obi\u010dno je manja propusnost). Veoma je va\u017eno razumeti da maksimalna propusnost predstavlja maksimalnu bez gubitaka<\/b> (\u010dak i ako ure\u0111aj mo\u017ee \u201epropu\u0161tati\u201c saobra\u0107aj ve\u0107em brzinom, ali pri tome gubi deo paketa). Tako\u0111e, treba obratiti pa\u017enju na to da neki dobavlja\u010di mere ukupnu propusnost izme\u0111u svih parova portova, tako da te cifre malo zna\u010de, ako sav enkriptovani saobra\u0107aj prolazi kroz jedan port.<\/p>\n
Gde je posebno va\u017ean rad na brzini linije (ili ina\u010de, bez gubitka paketa)? U kanalima sa visokom propusno\u0161\u0107u i velikim ka\u0161njenjima (na primer, satelitskim), gde je za odr\u017eavanje visoke brzine prenosa potrebno postaviti veliku TCP veli\u010dinu prozora, i gde gubici paketa drasti\u010dno smanjuju performanse mre\u017ee.<\/p>\n
Ali ne koristi se svaka propusnost za prenos korisnih podataka. Mora se ra\u010dunati sa takozvanim prekoracima<\/b> (overhead) propusnosti. To je dio propusnosti ure\u0111aja za \u0161ifriranje (u postotcima ili bajtovima po paketu) koja se zapravo gubi (ne mo\u017ee se koristiti za prijenos podataka aplikacija). Naknade nastaju prvenstveno zbog pove\u0107anja veli\u010dine (dodaci, \u201epunjenje\u201d) polja podataka u \u0161ifriranim mre\u017enim paketima (ovisno o algoritmu \u0161ifriranja i na\u010dinu rada). Drugo, zbog pove\u0107anja duljine zaglavlja paketa (tunel mod, uslu\u017eni umetak protokola \u0161ifriranja, imitacija umetka i sl. ovisno o protokolu i na\u010dinu rada \u0161ifriranja i na\u010dinu prijenosa) \u2013 obi\u010dno su ti tro\u0161kovi najzna\u010dajniji, i na njih se prvo obra\u0107a pa\u017enja. Tre\u0107e, zbog fragmentacije paketa kada se prekora\u010di maksimalna veli\u010dina bloka podataka (MTU) (ako mre\u017ea mo\u017ee podijeliti paket koji prema\u0161uje MTU na dva, dupliciraju\u0107i njegova zaglavlja). \u010cetvrto, zbog pojave dodatnog uslu\u017enog (kontrolnog) prometa u mre\u017ei izme\u0111u ure\u0111aja za \u0161ifriranje (za razmjenu klju\u010deva, uspostavljanje tunela itd.). Niski tro\u0161kovi su va\u017eni tamo gdje je propusnost kanala ograni\u010dena. To je posebno izra\u017eeno na prometu malih paketa, poput glasovnog \u2013 tamo tro\u0161kovi mogu \u201epojesti\u201d vi\u0161e od polovice brzine kanala!<\/p>\n
Propusnost<\/i><\/p>\n
Na kraju, postoji jo\u0161 uzrokovana ka\u0161njenjem<\/b> \u2013 razlika (u dijelovima sekunde) u mre\u017enoj latenciji (vremenu prijenosa podataka od ulaza u mre\u017eu do izlaza iz nje) izme\u0111u prijenosa podataka bez mre\u017enog \u0161ifriranja i s njim. Op\u0107enito govore\u0107i, \u0161to je manja latencija (\u201elatencija\u201d) mre\u017ee, to postaje kriti\u010dnija latencija koju unose ure\u0111aji za \u0161ifriranje. Latenciju unosi sama operacija \u0161ifriranja (ovisno o algoritmu \u0161ifriranja, duljini bloka i na\u010dinu rada \u0161ifriranja, kao i o kvaliteti njegove implementacije u softveru), kao i obrada mre\u017enog paketa u ure\u0111aju. Unesena latencija ovisi i o re\u017eimu obrade paketa (kroz ili \u201espremi-i-po\u0161alji\u201d), kao i o performansama platforme (\u201ehardverska\u201d implementacija na FPGA ili ASIC, obi\u010dno je br\u017ea od \u201esoftverske\u201d na CPU). \u0160ifriranje L2 gotovo uvijek ima manju unesenu latenciju u usporedbi sa \u0161ifriranjem na L3 ili L4: to je posljedica toga \u0161to ure\u0111aji koji \u0161ifriraju na L3\/L4 \u010desto izvode konvergencijske funkcije. Na primjer, kod visok brzi \u0161ifratore Ethernet, implementirane na FPGA i \u0161ifrirane na L2, latencija zbog operacije \u0161ifriranja je vrlo mala \u2013 ponekad, kada se uklju\u010di \u0161ifriranje na paru ure\u0111aja, ukupna latencija koju oni unose \u010dak se smanjuje! Mala latencija je va\u017ena kada je usporediva s ukupnim latencijama u kanalu, uklju\u010duju\u0107i latenciju \u0161irenja signala, koja je otprilike 5 \u03bcs po kilometru. Dakle, mo\u017ee se re\u0107i da za gradske mre\u017ee (deseci kilometara u promjeru) mikroseunde mogu zna\u010diti mnogo. Na primjer, za sinkronu replikaciju baza podataka, visokofrekventno trgovanje, isti blockchain.<\/p>\n
Unesena latencija<\/i><\/p>\nSkalabilnost<\/h4>\n
\nVelike distribuirane mre\u017ee mogu uklju\u010divati tisu\u0107e \u010dvorova i mre\u017enih ure\u0111aja, stotine segmenta lokalnih mre\u017ea. Va\u017eno je da rje\u0161enja za enkripciju ne postavljaju dodatna ograni\u010denja na veli\u010dinu i topologiju distribuirane mre\u017ee. To se prvenstveno odnosi na maksimalni broj adresa \u010dvorova i mre\u017ea. Takva ograni\u010denja mogu se pojaviti, na primjer, prilikom implementacije vi\u0161e to\u010daka topologije za\u0161ti\u0107ene enkripcijom mre\u017ee (s neovisnim za\u0161ti\u0107enim vezama ili tunelima) ili selektivne enkripcije (na primjer, prema protokolu ili VLAN broju). Ako se pritom mre\u017ene adrese (MAC, IP, VLAN ID) koriste kao klju\u010devi u tablici, \u010diji je broj redaka ograni\u010den, tada se ovdje javljaju ta ograni\u010denja.<\/p>\n
Osim toga, velike mre\u017ee \u010desto imaju nekoliko strukturalnih razina, uklju\u010duju\u0107i osnovnu mre\u017eu, na svakoj od kojih se provode vlastita shema adresiranja i pravila usmjeravanja. Za implementaciju takvog pristupa \u010desto se koriste posebni formati okvira (poput Q-in-Q ili MAC-in-MAC) i protokoli za odre\u0111ivanje ruta. Kako ne bi ometali izgradnju takvih mre\u017ea, ure\u0111aji za enkripciju moraju ispravno obra\u0111ivati takve okvire (tj. u ovom smislu, skalabilnost \u0107e zna\u010diti kompatibilnost \u2013 o tome vi\u0161e u nastavku).<\/p>\n
Fleksibilnost<\/h4>\n \nOvdje se radi o podr\u0161ci razli\u010ditim konfiguracijama, shemama povezivanja, topologijama i ostalom. Na primjer, za preklopne mre\u017ee temeljene na Carrier Ethernet tehnologijama to zna\u010di podr\u0161ku za razli\u010dite tipove virtualnih veza (E-Line, E-LAN, E-Tree), razli\u010dite tipove usluga (kako po portovima, tako i po VLAN-ima) i razli\u010dite transportne tehnologije (koje su ve\u0107 navedene). To jest, ure\u0111aj mora biti sposoban raditi kako u linearnom (\"to\u010dka-to\u010dka\"), tako i u vi\u0161eto\u010dkovnom re\u017eimu, uspostaviti pojedina\u010dne tunela za razli\u010dite VLAN-ove, dopu\u0161tati neurednu isporuku paketa unutar za\u0161ti\u0107enog kanala. Mogu\u0107nost odabira razli\u010ditih re\u017eima rada \u0161ifri (uklju\u010duju\u0107i s autentifikacijom sadr\u017eaja ili bez nje) i razli\u010ditih re\u017eima prijenosa paketa omogu\u0107uje postizanje ravnote\u017ee izme\u0111u otpornosti i performansi ovisno o trenutnim uvjetima.<\/p>\n
Tako\u0111er je va\u017ena podr\u0161ka privatnim mre\u017eama \u010dija oprema pripada jednoj organizaciji (ili je iznajmljena od nje), kao i operaterskim mre\u017eama, \u010diji su razli\u010diti segmenti pod upravom razli\u010ditih kompanija. Dobro je ako rje\u0161enje omogu\u0107ava upravljanje kako vlastitim resursima, tako i vanjskom organizacijom (po modelu upravljane usluge). U operaterskim mre\u017eama va\u017ena je jo\u0161 jedna funkcija \u2013 podr\u0161ka multitenantnosti (zajedni\u010dkog kori\u0161tenja od strane razli\u010ditih korisnika) u obliku kriptoizolacije pojedinih korisnika (pretplatnika), \u010diji promet prolazi kroz isti set ure\u0111aja za \u0161ifriranje. To obi\u010dno zahtijeva kori\u0161tenje posebnih setova klju\u010deva i certifikata za svakog korisnika.<\/p>\n
Ako se ure\u0111aj kupuje za neki odre\u0111eni scenarij, mo\u017eda sve te mogu\u0107nosti i nisu toliko va\u017ene \u2013 potrebno je samo osigurati da ure\u0111aj podr\u017eava ono \u0161to je trenutno potrebno. No, ako se rje\u0161enje kupuje \"za budu\u0107nost\", kako bi se tako\u0111er podr\u017eali budu\u0107i scenariji, a bira se kao \"korporativni standard\", tada fleksibilnost ne\u0107e biti suvi\u0161na \u2013 posebno uzimaju\u0107i u obzir ograni\u010denja u interoperabilnosti ure\u0111aja razli\u010ditih dobavlja\u010da (o tome malo ni\u017ee).<\/p>\n
Jednostavnost i prakti\u010dnost<\/h4>\n \nPrakti\u010dnost odr\u017eavanja tako\u0111er je multifaktorski koncept. Otprilike se mo\u017ee re\u0107i da su to ukupni tro\u0161kovi vremena stru\u010dnjaka odre\u0111ene kvalifikacije, potrebni za podr\u0161ku rje\u0161enju u razli\u010ditim fazama njegovog \u017eivotnog ciklusa. Ako nema tro\u0161kova, a instalacija, pode\u0161avanje, i eksploatacija su potpuno automatski, tada su tro\u0161kovi nulti, a prakti\u010dnost apsolutna. Naravno, u stvarnom svijetu takvo ne\u0161to ne postoji. Razumno pribli\u017eavanje je model \u201e\u010dvor na \u017eici\u201c<\/b> (bump-in-the-wire), ili transparentno povezivanje, pri kojem dodavanje i uklanjanje ure\u0111aja za \u0161ifriranje ne zahtijeva nikakve ru\u010dne ili automatske promjene u konfiguraciji mre\u017ee. Ovo pojednostavljuje odr\u017eavanje rje\u0161enja: mo\u017eete mirno uklju\u010divati i isklju\u010divati funkciju \u0161ifriranja, a po potrebi jednostavno \"obi\u0107i\" ure\u0111aj mre\u017enim kablom (tj. izravno spojiti one portove mre\u017ene opreme na koje je bio priklju\u010den). Me\u0111utim, postoji i jedan nedostatak \u2013 isto to mo\u017ee u\u010diniti i napada\u010d. Za realizaciju principa \"\u010dvora na \u017eici\" potrebno je uzeti u obzir promet ne samo sloja podataka<\/b>, ve\u0107 i slojeva kontrole i upravljanja<\/b> \u2013 ure\u0111aji moraju biti transparentni za njih. Stoga se takav promet mo\u017ee \u0161ifrirati samo kada u mre\u017ei izme\u0111u ure\u0111aja za \u0161ifriranje nema primatelja prometa ovih vrsta, jer \u0107e, ako ga odbacuju ili \u0161ifriraju, prilikom uklju\u010divanja ili isklju\u010divanja \u0161ifriranja do\u0107i do promjene u konfiguraciji mre\u017ee. Ure\u0111aj za \u0161ifriranje mo\u017ee biti transparentan i za signalizaciju na fizi\u010dkoj razini. Konkretno, u slu\u010daju gubitka signala trebao bi prenositi taj gubitak (tj. isklju\u010diti svoje predajnike) unatrag i naprijed (\"za sebe\") u smjeru signala.<\/p>\n
Tako\u0111er je va\u017ena podr\u0161ka u odvojenju ovlasti izme\u0111u odjela IB i IT, posebno mre\u017enog odjela. Rje\u0161enje za \u0161ifriranje treba podr\u017eavati usvojeni model upravljanja pristupom i revizijom u organizaciji. Potrebno je svesti na minimum potrebu za interakcijom izme\u0111u razli\u010ditih odjela za obavljanje rutinskih operacija. Stoga, u smislu udobnosti, prednost imaju specijalizirani ure\u0111aji koji podr\u017eavaju isklju\u010divo funkcije \u0161ifriranja i maksimalno su transparentni za mre\u017ene operacije. Drugim rije\u010dima, zaposlenici slu\u017ebe IB ne bi trebali imati razloga obra\u0107ati se \"mre\u017earima\" za promjene u mre\u017enim postavkama. A oni, zauzvrat, ne bi trebali imati potrebu mijenjati postavke \u0161ifriranja prilikom odr\u017eavanja mre\u017ee.<\/p>\n
Jo\u0161 jedan faktor su mogu\u0107nosti i jednostavnost kori\u0161tenja upravlja\u010dkih alata. Trebali bi biti pregledni, logi\u010dni i omogu\u0107iti uvoz-izvoz postavki, automatizaciju i sli\u010dno. Omah treba obratiti pa\u017enju na to koje opcije upravljanja su dostupne (obi\u010dno je to vlastito upravlja\u010dko okru\u017eenje, web su\u010delje i komandna linija) i koji skup funkcija nude svaki od njih (mogu postojati ograni\u010denja). Va\u017ena funkcija je podr\u0161ka izvanpoli\u010dnog<\/b> (out-of-band) upravljanja, \u0161to zna\u010di preko odvojene mre\u017ee za upravljanje, i unutarpoli\u010dnog<\/b> (in-band) upravljanja, \u0161to zna\u010di kroz zajedni\u010dku mre\u017eu, putem koje prolazi korisni promet. Upravlja\u010dki alati trebali bi signalizirati sve izvanredne situacije, uklju\u010duju\u0107i incidente informacijske sigurnosti. Rutinske, ponavljaju\u0107e operacije trebaju se izvoditi automatski. Prvo i osnovno to se odnosi na upravljanje klju\u010devima. Oni trebaju biti generirani\/raspodijeljeni automatski. Podr\u0161ka PKI je veliki plus.<\/p>\nKompatibilnost<\/h4>\n
\nDakle, kompatibilnost ure\u0111aja sa mre\u017enim standardima. Pri tome se ne misli samo na industrijske standarde, koje su utvrdile autoritativne organizacije poput IEEE, ve\u0107 i na brendirane protokole lidera u industriji, poput onih koje nudi Cisco. Postoje dva osnovna na\u010dina osiguravanja kompatibilnosti: ili kroz prozirnost<\/b>, ili kroz izravnu podr\u0161ku<\/b> protokola (kada ure\u0111aj za \u0161ifriranje postaje \u010dvor u mre\u017ei za neki protokol i obra\u0111uje kontrolni promet tog protokola). Od potpunosti i ispravnosti implementacije kontrolnih protokola ovisi kompatibilnost s mre\u017eama. Va\u017ena je podr\u0161ka razli\u010ditim varijantama PHY razine (brzina, medij za prijenos, sheme kodiranja), Ethernet okvirima razli\u010ditih formata s bilo kojim MTU-om, razli\u010ditim servisnim L3 protokolima (prije svega iz porodice TCP\/IP).<\/p>\n
Prozirnost se osigurava putem mehanizama mutacije (privremena promjena sadr\u017eaja otvorenih zaglavlja u prometu izme\u0111u \u0161ifrirnika), propu\u0161tanja (kada pojedini paketi ostaju neza\u0161ti\u0107eni) i odgode po\u010detka \u0161ifriranja (kada se obi\u010dno \u0161ifrirana polja paketa ne \u0161ifriraju).<\/p>\n
Kako se osigurava prozirnost<\/i><\/p>\n
Stoga uvijek provjerite kako se to\u010dno osigurava podr\u0161ka odre\u0111enom protokolu. \u010cesto je podr\u0161ka u prozirnom re\u017eimu prakti\u010dnija i pouzdanija.<\/p>\n
Interoperabilnost<\/h4>\n \nTo je tako\u0111er kompatibilnost, ali u drugom smislu, odnosno mogu\u0107nost suradnje s drugim modelima ure\u0111aja za \u0161ifriranje, uklju\u010duju\u0107i i ure\u0111aje drugih proizvo\u0111a\u010da. Ovdje mnogo ovisi o stanju standardizacije protokola za \u0161ifriranje. Na L1 jednostavno ne postoje me\u0111unarodno priznati standardi \u0161ifriranja.<\/p>\n
Za \u0161ifriranje L2 u Ethernet mre\u017eama postoji standard 802.1ae (MACsec), ali on ne koristi krajnje<\/b> (end-to-end), ve\u0107 me\u0111uportnu<\/b>, \u201eskakanje\u201c (hop-by-hop) \u0161ifriranje, i u svojoj izvornoj verziji nije prikladan za kori\u0161tenje u distribuiranim mre\u017eama, stoga su se pojavile njegove vlasni\u010dke ekstenzije koje prevazilaze ovo ograni\u010denje (naravno, na ra\u010dun interoperabilnosti s opremom drugih proizvo\u0111a\u010da). Istina, 2018. godine je standard 802.1ae dobio podr\u0161ku za distribuirane mre\u017ee, ali podr\u0161ke za skupove \u0161ifriraju\u0107ih algoritama GOST i dalje nema. Stoga se vlasni\u010dki, nestandardni protokoli \u0161ifriranja L2 obi\u010dno odlikuju ve\u0107om efikasno\u0161\u0107u (konkretno, manjim preklapanjem propusnosti) i fleksibilno\u0161\u0107u (mogu\u0107no\u0161\u0107u promjene algoritama i re\u017eima \u0161ifriranja).<\/p>\n
Na vi\u0161im razinama (L3 i L4) postoje priznati standardi, prije svega IPsec i TLS, ali ni tu nije sve jednostavno. Naime, svaki od ovih standarda predstavlja skup protokola, svaki s razli\u010ditim verzijama i obaveznim ili neobaveznim ekstenzijama za implementaciju. Osim toga, neki proizvo\u0111a\u010di preferiraju kori\u0161tenje svojih vlasni\u010dkih protokola za \u0161ifriranje i na L3\/L4. Stoga se u ve\u0107ini slu\u010dajeva ne treba o\u010dekivati punu interoperabilnost, ali va\u017eno je da se osigura barem suradnja izme\u0111u razli\u010ditih modela i razli\u010ditih generacija jednog proizvo\u0111a\u010da.<\/p>\n
Pouzdanost<\/h4>\n \nZa usporedbu razli\u010ditih rje\u0161enja mo\u017ee se koristiti ili prosje\u010dno vrijeme do kvara, ili koeficijent dostupnosti. Ako tih vrijednosti nema (ili im se ne vjeruje), tada se mo\u017ee provesti kvalitetna usporedba. Prednost \u0107e imati ure\u0111aji s lakim upravljanjem (manji rizik od gre\u0161aka u konfiguraciji), specijalizirani \u0161ifratore (iz istog razloga), kao i rje\u0161enja s minimalnim vremenom otkrivanja i ispravljanja kvara, uklju\u010duju\u0107i sredstva za \u201evru\u0107e\u201c rezerviranje \u010dvorova i ure\u0111aja u cjelini.<\/p>\n
Cena<\/h4>\n \n\u0160to se ti\u010de tro\u0161kova, kao i kod ve\u0107ine IT rje\u0161enja, preporu\u010duje se usporediti ukupne tro\u0161kove vlasni\u0161tva. Za njihovu procjenu nije potrebno izmi\u0161ljati bicikl, ve\u0107 mo\u017eete koristiti bilo koju prikladnu metodologiju (npr. onu od Gartnera) i bilo koji kalkulator (npr. onaj koji se ve\u0107 koristi u organizaciji za izra\u010dun TCO). Jasno je da se za rje\u0161enje mre\u0161nog \u0161ifriranja ukupni tro\u0161kovi vlasni\u0161tva sastoje od izravnih<\/b> tro\u0161kova kupnje ili najma samog rje\u0161enja, tro\u0161kova infrastrukture za smje\u0161taj opreme, kao i tro\u0161kova implementacije, administracije i odr\u017eavanja (neovisno o tome jesu li ti tro\u0161kovi internalni ili u obliku usluga tre\u0107e strane), a tako\u0111er i od neizravnih<\/b> tro\u0161kova uslijed prekida rada rje\u0161enja (uzrokovanih gubitkom produktivnosti krajnjih korisnika). Vjerojatno postoji samo jedna suptilnost. Utjecaj performansi rje\u0161enja mo\u017ee se sagledati na razli\u010dite na\u010dine: ili kao neizravni tro\u0161kovi uzrokovani padom produktivnosti, ili kao \u201evirtualni\u201c izravni tro\u0161kovi za kupnju\/modernizaciju i odr\u017eavanje mre\u017enih sredstava koja kompenziraju pad performansi mre\u017ee uslijed primjene \u0161ifriranja. U svakom slu\u010daju, tro\u0161kovi koje je te\u0161ko izra\u010dunati s dovoljnom to\u010dno\u0161\u0107u bolje je \u201eizbaciti iz ra\u010duna\u201c kako bi se pove\u0107alo povjerenje u kona\u010dnu vrijednost. I, kao \u0161to je obi\u010dno slu\u010daj, usporedba razli\u010ditih ure\u0111aja prema TCO ima smisla raditi za konkretan scenarij njihove upotrebe \u2013 stvarni ili tipi\u010dni.<\/p>\nIzdr\u017eljivost<\/h4>\n
\nI posljednja karakteristika je otpornost rje\u0161enja. U ve\u0107ini slu\u010dajeva otpornost se mo\u017ee ocijeniti samo kvalitativno, uspore\u0111uju\u0107i razli\u010dita rje\u0161enja me\u0111u sobom. Moramo imati na umu da ure\u0111aji za \u0161ifriranje nisu samo sredstva, ve\u0107 i objekti za\u0161tite. Oni mogu biti podlo\u017eni razli\u010ditim prijetnjama. U prvom planu su prijetnje neovisnosti, reprodukcije i modifikacije poruka. Ove prijetnje mogu se ostvariti kroz ranjivosti \u0161ifara ili pojedinih njihovih modusa, kroz ranjivosti u protokolima \u0161ifriranja (uklju\u010duju\u0107i faze uspostave veze i generiranja\/raspodjele klju\u010deva). Prednost \u0107e imati rje\u0161enja koja dopu\u0161taju promjenu algoritma \u0161ifriranja ili prebacivanje na\u010dina rada \u0161ifre (barem putem nadogradnje ugra\u0111enog softvera), rje\u0161enja koja osiguravaju maksimalno \u0161ifriranje, skrivaju\u0107i od napada\u010da ne samo korisni\u010dke podatke, nego i adresne i druge operativne informacije, kao i ona rje\u0161enja koja ne samo da \u0161ifriraju, ve\u0107 i \u0161tite poruke od reprodukcije i modifikacije. Za sve moderne algoritme \u0161ifriranja, elektroni\u010dki potpis, generiranje klju\u010deva i druge, koje su navedene u standardima, otpornost se mo\u017ee smatrati jednakom (ina\u010de se mo\u017ee lako izgubiti u labirintima kriptografije). Trebaju li to biti nu\u017eno algoritmi GOST? Ovdje je sve jednostavno: ako scenarij primjene zahtijeva certifikaciju FSB-a za SKZI (\u0161to je u Rusiji naj\u010de\u0161\u0107e slu\u010daj) za ve\u0107inu scenarija mre\u017enog \u0161ifriranja, onda biramo samo izme\u0111u certificiranih. Ako ne \u2013 onda nema smisla isklju\u010divati ure\u0111aje bez certifikata iz razmatranja.<\/p>\n
Druga prijetnja je prijetnja hakiranja, neovla\u0161tenog pristupa ure\u0111ajima (uklju\u010duju\u0107i fizi\u010dki pristup s vanjske i unutarnje strane ku\u0107i\u0161ta). Prijetnja se mo\u017ee ostvariti kroz
Na kraju, jo\u0161 jedna vrsta pretnji \u2013 to su gre\u0161ke u konfiguraciji i eksploataciji, ljudski faktor u \u010distom obliku. Ovde se manifestuje jo\u0161 jedna prednost specijalizovanih \u0161ifratore naspram konvergentanih re\u0161enja, koja su \u010desto usmerena na iskusne \"mre\u017ene\" stru\u010dnjake i mogu izazvati pote\u0161ko\u0107e obi\u010dnim, \u0161irokoprofiltim stru\u010dnjacima za IT.<\/p>\n
Zaklju\u010dak<\/h4>\n \nU principu, ovde bi se mogao predlo\u017eiti neki integralni pokazatelj za pore\u0111enje razli\u010ditih ure\u0111aja, ne\u0161to poput<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\ngde je p \u2013 te\u017eina pokazatelja, a r \u2013 rang ure\u0111aja po tom pokazatelju, pri \u010demu se bilo koja od nabrojanih karakteristika mo\u017ee razlo\u017eiti na \"atomarne\" pokazatelje. Ova formula bi mogla biti korisna, na primer, prilikom pore\u0111enja tender ponuda prema unapred dogovorenim pravilima. No, mo\u017ee se pro\u0107i i uz jednostavnu tabelu tipa<\/p>\n
Zna\u010dajka
Propusnost
+++<\/p>\n
Operativni tro\u0161kovi
+++<\/p>\n
Ka\u0161njenje
++<\/p>\n
Skalabilnost
+++<\/p>\n
Fleksibilnost
+<\/p>\n
Interoperabilnost
+<\/p>\n
Kompatibilnost
+++<\/p>\n
Jednostavnost i prakti\u010dnost
++<\/p>\n
Otpornost na gre\u0161ke
++<\/p>\n
Cena
+<\/p>\n
Izdr\u017eljivost
+++<\/p>\n
\nBi\u0107u sre\u0107an da odgovorim na pitanja i konstruktivne kriti\u010dke komentare.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042d\u0442\u043e\u0442 \u043e\u0431\u0437\u043e\u0440 (\u0438\u043b\u0438, \u0435\u0441\u043b\u0438 \u0445\u043e\u0442\u0438\u0442\u0435, \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0441\u0442\u0432\u043e \u0434\u043b\u044f \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u044f) \u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043b, \u043a\u043e\u0433\u0434\u0430 \u043c\u043d\u0435 \u043f\u043e\u0440\u0443\u0447\u0438\u043b\u0438 \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u044c \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 \u0440\u0430\u0437\u043d\u044b\u0445 \u0432\u0435\u043d\u0434\u043e\u0440\u043e\u0432. \u041a \u0442\u043e\u043c\u0443 \u0436\u0435 \u044d\u0442\u0438 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u043f\u0440\u0438\u043d\u0430\u0434\u043b\u0435\u0436\u0430\u043b\u0438 \u043a \u0440\u0430\u0437\u043d\u044b\u043c \u043a\u043b\u0430\u0441\u0441\u0430\u043c. \u041f\u0440\u0438\u0448\u043b\u043e\u0441\u044c \u0440\u0430\u0437\u0431\u0438\u0440\u0430\u0442\u044c\u0441\u044f \u0432 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u0438 \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0438\u0441\u0442\u0438\u043a\u0430\u0445 \u0432\u0441\u0435\u0445 \u044d\u0442\u0438\u0445 \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 \u0438 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u00ab\u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u043e\u043e\u0440\u0434\u0438\u043d\u0430\u0442\u00bb \u0434\u043b\u044f \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u044f. \u042f \u0431\u0443\u0434\u0443 \u0440\u0430\u0434, \u0435\u0441\u043b\u0438 \u043c\u043e\u0439 \u043e\u0431\u0437\u043e\u0440 \u043f\u043e\u043c\u043e\u0436\u0435\u0442 \u043a\u043e\u043c\u0443-\u0442\u043e: \u0420\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u0432 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u044f\u0445 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52834","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t