VPN<\/a> v\u00f5i ilma selleta.<\/p>\nV\u00f5rgu kr\u00fcptimine jaotatud Etherneti v\u00f5rgus<\/i><\/p>\n
Seadmed v\u00f5ivad olla kas spetsialiseeritud<\/b> (ainult kr\u00fcptimiseks m\u00f5eldud) v\u00f5i mitmeotstarbelised (h\u00fcbriid- konvergentsed<\/b>), ehk ka teisi funktsioone t\u00e4itvad (n\u00e4iteks tulem\u00fc\u00fcr v\u00f5i ruuter). Erinevad tootjad liigitavad oma seadmed erinevate klasside\/kategooriate alla, kuid see ei ole oluline \u2013 t\u00e4htis on, kas nad suudavad kr\u00fcpteerida veebitransporti ning millised on nende omadused.<\/p>\n
Tuletan meelde, et terminid \u201ev\u00f5rgukr\u00fcptimine\u201d, \u201etrafiku kr\u00fcptimine\u201d, \u201ekr\u00fcptija\u201d on mitteametlikud, kuigi neid kasutatakse sageli. Venemaa \u00f5igusaktides (sealhulgas GOSTide kehtestamise seadustes) ei pruugi te neid t\u00f5en\u00e4oliselt kohata.<\/p>\n
Kr\u00fcptimise tasemed ja edastamisre\u017eiimid<\/h4>\n \nEnne kui hakata kirjeldama omadusi, mida kasutatakse hindamiseks, tuleb esmalt selgeks teha \u00fcks oluline asi, nimelt \u201ekr\u00fcptimise tase\u201d. Olen m\u00e4rganud, et see mainitakse sageli nii ametlikes tootjate dokumentides (kirjeldustes, juhendites jne) kui ka mitteametlikus arutelus (l\u00e4bir\u00e4\u00e4kimistel, koolitustel). Tundub, et k\u00f5igil on \u00fcldiselt arusaam, millest jutt k\u00e4ib, kuid olen isiklikult olnud tunnistajaks m\u00f5ningale segadusele.<\/p>\n
Mis on \"kr\u00fcpteerimise tase\"? Selge, et see viitab OSI\/ISO mudeli numbrile, millel toimub kr\u00fcpteerimine. Loe \u0413\u041e\u0421\u0422 \u0420 \u0418\u0421\u041e 7498-2\u201399 \"Infotehnoloogia. Avatud s\u00fcsteemide seosed. P\u00f5hialusmudel. Osa 2. Teabe kaitse arhitektuur\". Sellest dokumendist v\u00f5ib aru saada, et konfidentsiaalsuse teenuse tase (mille tagamiseks kasutatakse ka kr\u00fcpteerimist) on protokolli tase, mille andmete teenus (\"kasulik koormus\", kasutaja andmed) kr\u00fcpteeritakse. Nagu standardis veel \u00f6eldakse, v\u00f5ib teenust tagada nii sellel tasemel \"oma j\u00f5ududega\" kui ka alumise taseme abil (just nii, nagu n\u00e4iteks MACsecis enamikul juhtudel toimub).<\/p>\n
Praktikas on v\u00f5imalikud kaks re\u017eiimi kr\u00fcpteeritud teabe edastamiseks v\u00f5rgus (m\u00f5tted l\u00e4hevad kohe IPsecile, kuid neid re\u017eiime kohtab ka teistes protokollides). transport<\/b> (m\u00f5nikord nimetatakse seda ka native) re\u017eiimis kr\u00fcpteeritakse ainult teenus<\/b> andmed on plokis, samas kui p\u00e4ised j\u00e4\u00e4vad \"avatuks\", kr\u00fcptimata (m\u00f5nikord lisatakse t\u00e4iendavaid v\u00e4lju kr\u00fcptimise algoritmi teenuseteabe jaoks, samas kui teised v\u00e4ljad modifitseeritakse, arvutatakse uuesti). tunnel<\/b> re\u017eiimis kogu protokoll<\/b> andmeplokk (st ise pakett) kr\u00fcptitakse ja kapseldatakse sama v\u00f5i k\u00f5rgema taseme teenuse andmeplokki, st see on uute p\u00e4istega \u00fcmbritsetud.<\/p>\n
Kr\u00fcptimise tase ise koos mingi edastusre\u017eiimiga ei ole ei hea ega halb, nii et ei saa \u00f6elda, et L3 transportre\u017eiimis oleks parem kui L2 tunnelre\u017eiimis. Lihtsalt neid vajadusi m\u00e4\u00e4ravad paljude omaduste j\u00e4rgi, mille alusel seadmeid hinnatakse. N\u00e4iteks paindlikkus ja \u00fchilduvus. L1 (bitivoogude edastamine), L2 (raamide vahetus) ja L3 (pakettide marsruutimine) t\u00f6\u00f6s transportre\u017eiimis on vaja lahendusi, mis kr\u00fcpteerivad sama v\u00f5i k\u00f5rgema taseme, vastasel juhul kr\u00fcpteeritakse aadressiteave ja andmed ei j\u00f5ua sihtkohta, samas kui tunnelre\u017eiim v\u00f5imaldab selle piirangu \u00fcletada (kuid ohverdades muid olulisi omadusi).<\/p>\n
L2 kr\u00fcpteerimise transport- ja tunnelire\u017eiimid<\/i><\/p>\n
Liigume n\u00fc\u00fcd omaduste arutelu juurde.<\/p>\n
Tootlikkus<\/h4>\n \nV\u00f5rgu kr\u00fcpteerimise puhul on j\u00f5udlus keeruline ja mitmem\u00f5\u00f5tmeline m\u00f5iste. Juhtub, et teatud mudel \u00fcletab j\u00f5udluses \u00fches osas, kuid kaotab teises. Seet\u00f5ttu on alati kasulik arvesse v\u00f5tta k\u00f5iki kr\u00fcpteerimise j\u00f5udluse komponente ja nende m\u00f5ju v\u00f5rgu ja selle rakenduste j\u00f5udlusele. Siin v\u00f5ib teha analoogia autoga, mille puhul ei ole oluline mitte ainult maksimaalne kiirus, vaid ka aeg, mille jooksul auto kiirus t\u00f5useb 100 km\/h, k\u00fctusekulu jne. J\u00f5udluse omadustele p\u00f6\u00f6ravad suurt t\u00e4helepanu nii tootjad kui ka nende potentsiaalsed kliendid. Reeglina toimub just j\u00f5udluse p\u00f5hjal seadmestike j\u00e4rjestamine.<\/p>\n
On selge, et s\u00f5iduki sooritusv\u00f5ime s\u00f5ltub nii seadmes teostatavate v\u00f5rgut\u00f6\u00f6tluse ja kr\u00fcptograafiliste operatsioonide keerukusest (sealhulgas sellest, kui h\u00e4sti need \u00fclesanded suudavad paralleelset t\u00f6\u00f6tlemist ja torustikku toetada), kui ka riistvara j\u00f5udlusest ja sisseehitatud tarkvara kvaliteedist. Seet\u00f5ttu kasutatakse k\u00f5rgemates mudelites t\u00f5husamat 'rauda', m\u00f5nikord on v\u00f5imalik sellele lisada t\u00e4iendavaid protsessoreid ja m\u00e4lu mooduleid. Kr\u00fcptograafiliste funktsioonide rakendamiseks on mitmeid l\u00e4henemisi: tavaline keskprotsessor (CPU), spetsialiseeritud kohandatud integraalskeem (ASIC) v\u00f5i programmeeritav loogika integraalskeem (FPGA). Igal l\u00e4henemisel on oma plusse ja miinuseid. N\u00e4iteks v\u00f5ib CPU muutuda kr\u00fcptimise 'kitsaskohaks', eriti kui protsessoril ei ole spetsialiseeritud k\u00e4ske kr\u00fcptimisalgoritmi toetamiseks (v\u00f5i kui neid ei kasutata). Spetsialiseeritud mikrokiipidel puudub paindlikkus, nende '\u00fcmberprojekteerimine' j\u00f5udluse suurendamiseks, uute funktsioonide lisamiseks v\u00f5i haavatavuste k\u00f5rvaldamiseks ei pruugi alati \u00f5nnestuda. Lisaks muutub nende kasutamine tasuvaks ainult suurtes tootmismahtudes. Seet\u00f5ttu on 'kuldne kesktee' \u2013 FPGA (eesti keeles PLI\u0421) \u2013 saanud nii populaarseks. Just nende p\u00f5hjal on loodud nn kr\u00fcpto-kiirendid \u2013 integreeritud v\u00f5i v\u00e4lised spetsialiseeritud riistvaramoodulid, mis toetavad kr\u00fcptograafiliste operatsioonide l\u00e4biviimist.<\/p>\n
Kuna tegemist on v\u00f5rgus<\/b> kr\u00fcpteerimisega, on loogiline, et lahenduste tulemuslikkust tuleb m\u00f5\u00f5ta samades suurustes nagu teiste v\u00f5rguseadmete puhul \u2013 l\u00e4bilaskev\u00f5ime, kadude protsent (frame loss) ja latentsus (latency). Need suurused on m\u00e4\u00e4ratletud RFC 1242-s. Muide, sageli mainitud viivitusvariatsiooni (jitter) kohta ei ole selles RFC-s midagi \u00f6eldud. Kuidas neid suurusi m\u00f5\u00f5ta? \u00dckski tunnustatud standard (olgu need ametlikud v\u00f5i mitte, n\u00e4iteks RFC) ei paku spetsiaalset meetodit v\u00f5rgu kr\u00fcpteerimise jaoks. Loogiliselt oleks m\u00f5istlik kasutada v\u00f5rgu seadmete meetodit, mis on fikseeritud standardis RFC 2544. Paljud tarnijad j\u00e4rgivad seda \u2013 paljud, kuid mitte k\u00f5ik. N\u00e4iteks edastavad nad testimisliiklust ainult \u00fches suunas, mitte m\u00f5lemas, nagu soovitatud<\/b> standardi j\u00e4rgi. Aga mis seal ikka.<\/p>\n
Ver \u0441\u0435\u0442meede seadmete tulemuslikkuse m\u00f5\u00f5tmine omab siiski oma erip\u00e4rasid. Esiteks, k\u00f5ik m\u00f5\u00f5tmised tuleks l\u00e4bi viia paari seadme kohta: ehkki kr\u00fcpteerimisalgoritmid on s\u00fcmmeetrilised, ei pea kr\u00fcpteerimise ja dekodeerimise viivitused ning pakettide kadud tingimata olema v\u00f5rdsed. Teiseks, on m\u00f5istlik m\u00f5\u00f5ta just delfi, v\u00f5rreldes kahte konfiguratsiooni: ilma kr\u00fcpteerimis seadmeteta ja nendega. V\u00f5i nagu h\u00fcbriids\u00fcsteemide puhul, mis \u00fchendavad mitmeid funktsioone koos v\u00f5rgu kr\u00fcpteerimisega, kr\u00fcpteerimise v\u00e4lja ja sisse l\u00fclitamise korral. Selle m\u00f5ju v\u00f5ib olla erinev ja s\u00f5ltuda kr\u00fcpteerimisseadmete \u00fchendusskeemist, t\u00f6\u00f6skeemidest ning l\u00f5puks ka liikluslaadi iseloomust. Erity, paljud tulemuslikkuse parameetrid s\u00f5ltuvad pakettide pikkusest, seet\u00f5ttu kasutatakse erinevate lahenduste tulemuslikkuse v\u00f5rdlemiseks sageli graafikuid, mis n\u00e4itavad nende parameetrite s\u00f5ltuvust pakettide pikkusest, v\u00f5i kasutatakse IMIX-i \u2013 liikluse jaotust pakettide pikkuse j\u00e4rgi, mis peegeldab enam-v\u00e4hem reaalsust. Kui v\u00f5tame v\u00f5rdluseks sama alus konfiguratsiooni ilma kr\u00fcpteerimiseta, suudame v\u00f5rrelda v\u00f5rgu kr\u00fcpteerimise lahendusi, mis on rakendatud erineval viisil, s\u00fcvenemata sellesse erinevusse: L2 L3, 'salvesta-j\u00e4ta' (store-and-forward) l\u00f5ppkasutusele (cut-through), spetsialiseeritud konvergente, GOST ja AES ja nii edasi.<\/p>\n
\u00dchenduse skeem j\u00f5udluse testimiseks<\/i><\/p>\n
Esimene omadus, millele t\u00e4helepanu p\u00f6\u00f6ratakse, on kr\u00fcpteerimise seadme \"kiirus\", st l\u00e4bip\u00e4\u00e4s<\/b> (bandwidth) selle v\u00f5rgu liideste bittide edastuskiirus. See m\u00e4\u00e4ratletakse v\u00f5rgustiku standarditega, mida liidesed toetavad. Etherneti puhul on tavalised numbrid 1 Gbit\/s ja 10 Gbit\/s. Kuid nagu me teame, on igas v\u00f5rgus maksimaalne teoreetiline l\u00e4bip\u00e4\u00e4s<\/b> (throughput) igas selle tasemes alati v\u00e4iksem kui l\u00e4bilaskev\u00f5ime: osa l\u00e4bis\u00f5idust \"kasutab\" vahekaartide, juhtmete pealkirjade jne jaoks. Kui seade suudab vastu v\u00f5tta, t\u00f6\u00f6delda (meie puhul kr\u00fcpteerida v\u00f5i dekodeerida) ja edastada liiklust t\u00e4ieliku v\u00f5rgu liidese kiirusel, st maksimaalse teoreetilise l\u00e4bip\u00e4\u00e4suga selle taseme v\u00f5rgu mudelis, siis \u00f6eldakse, et see toimib liini kiirusel<\/b>. Selleks peab seade olema suuteline pakkumisi kaotamata v\u00f5i v\u00e4lja viskama, olenemata nende suurusest v\u00f5i esinemise sagedusest. Kui kr\u00fcpteerimisseade ei toeta liinikiirusel t\u00f6\u00f6tamist, tuuakse tavaliselt v\u00e4lja selle maksimaalne l\u00e4bilaskev\u00f5ime gigabittides sekundis (m\u00f5nikord koos paketipikkuse m\u00e4rkega \u2013 mida l\u00fchemad on paketid, seda tihti on madalam l\u00e4bilaskev\u00f5ime). On v\u00e4ga oluline m\u00f5ista, et maksimaalne l\u00e4bilaskev\u00f5ime on maksimaalne ilma kaotusteta<\/b> (isegi kui seade suudab edastada liiklust suurema kiirusena, kuid kaotades samas teatud osa paketist). Samuti tuleb p\u00f6\u00f6rata t\u00e4helepanu sellele, et m\u00f5ned m\u00fc\u00fcjad m\u00f5\u00f5davad k\u00f5igi portide paaride vahelist kogul\u00e4bilaskev\u00f5imet, nii et need numbrid \u00fctlevad v\u00e4he, kui kogu kr\u00fcpteeritud liiklus k\u00e4ib l\u00e4bi \u00fche porta.<\/p>\n
Kus on eriti oluline kiirus (v\u00f5i muul viisil, pakettide kaotuse v\u00e4ltimine)? Suure l\u00e4bilaskev\u00f5imega ja suure latentsusega kanalites (nt satelliitides), kus k\u00f5rge andmeedastuse kiirus n\u00f5uab suurt TCP akna suurust, ja kus pakettide kaotus v\u00e4hendab oluliselt v\u00f5rgu j\u00f5udlust.<\/p>\n
Kuid mitte kogu l\u00e4bilaskev\u00f5ime ei kasutata kasulike andmete edastamiseks. Tuleb arvestada nn \u00fclekande kulusid.<\/b> (\u00fclekande) l\u00e4bilaskvus. See on osa kr\u00fcpteerimise seadme l\u00e4bilaskvusest (protsentides v\u00f5i baitides paketi kohta), mis tegelikult kaob (ei saa rakenduste andmete edastamiseks kasutada). \u00dclekandekulud tekivad k\u00f5igepealt andmepakettide kr\u00fcpteerimise t\u00f5ttu suurenenud suurusest (t\u00e4iendused, 't\u00e4idised') kr\u00fcpteeritud andmepakkides (s\u00f5ltuvalt kr\u00fcpteerimisalgoritmist ja selle t\u00f6\u00f6re\u017eiimist). Teiseks, pakettide pealkirjade suurenenud pikkuse t\u00f5ttu (tunnelire\u017eiim, kr\u00fcpteerimisprotokolli teenuse sisestamine, autentimise sisestamine jms, s\u00f5ltuvalt kr\u00fcpteerimise ja edastusre\u017eiimi protokollist) \u2014 tavaliselt on need \u00fclekandekulud k\u00f5ige olulisemad ning nendele p\u00f6\u00f6ratakse esmaj\u00e4rjekorras t\u00e4helepanu. Kolmandaks, pakettide fragmentatsiooni t\u00f5ttu \u00fcle maksimaalse andmeploki suuruse (MTU) (kui v\u00f5rk suudab MTU \u00fcletava paketi kaheks jagada, dubleerides selle pealkirjad). Neljandaks, lisateenuse (kontrolli) liikluse tekkimise t\u00f5ttu seadmete vahel kr\u00fcpteerimise ajal (v\u00f5tmete vahetamiseks, tunnelite seadmiseks jne). Madalad \u00fclekandekulud on olulised kohas, kus kanalite l\u00e4bilaskev\u00f5ime on piiratud. See kajastub eriti v\u00e4ikeste pakettide liikluses, n\u00e4iteks h\u00e4\u00e4ltegevuses \u2014 seal v\u00f5ivad \u00fclekandekulud 'neelata' rohkem kui poole kanalite kiirusest!<\/p>\n
L\u00e4bivool<\/i><\/p>\n
L\u00f5puks on veel kahjustatud viivitus<\/b> \u2013 erinevus (millisekundites) v\u00f5rgu viivitusest (andmete edastamisest, alates sisenemisest v\u00f5rku kuni lahkumiseni) andmete edastamisel ilma v\u00f5rgu kr\u00fcpteerimiseta ja kr\u00fcpteerimisega. \u00dcldiselt, mida v\u00e4iksem on v\u00f5rgu viivitus (\u201elatenstus\u201d), seda kriitilisemaks muutub kr\u00fcpteerimise seadmete poolt tekitatud viivitus. Viivitust tekitab nii kr\u00fcpteerimise operatsioon (mis s\u00f5ltub kr\u00fcpteerimisalgoritmist, ploki pikkusest ja kr\u00fcpteerimise re\u017eiimist, samuti tarkvara kvaliteedist), kui ka v\u00f5rgupaketi t\u00f6\u00f6tlemine seadmes. Tehtud viivitus s\u00f5ltub nii pakettide t\u00f6\u00f6tlemise re\u017eiimist (otse- v\u00f5i \u201esalvesta ja edasta\u201d), kui ka platvormi j\u00f5udlusest (FPGA v\u00f5i ASIC-l p\u00f5hinev \u201eriistvaraline\u201d lahendus on tavaliselt kiirem kui CPU-l p\u00f5hinev \u201etarkvaraline\u201d lahendus). L2 kr\u00fcpteerimine p\u00f5hjustab peaaegu alati v\u00e4iksemat viivitust v\u00f5rreldes L3 v\u00f5i L4 kr\u00fcpteerimisega: see tuleneb sellest, et L3\/L4-l kr\u00fcpteerivad seadmed on sageli konvergentsed. N\u00e4iteks k\u00f5rge ribalaiusega Etherneti kr\u00fcpteerijatel, mis on rakendatud FPGA-l ja kr\u00fcpteerivad L2-tasandil, on kr\u00fcpteerimise operatsiooni p\u00f5hjustatud viivitus t\u00fchiselt v\u00e4ike \u2013 m\u00f5nikord v\u00f5ib isegi kahte seadet kr\u00fcpteerimise aktiveerimisel m\u00f5ned viivituse kogusumma v\u00e4heneda! V\u00e4hene viivitus on oluline seal, kus see on v\u00f5rreldav kana koguviipe s\u00fcsteemiga, sealhulgas signaali leviku viivitus, mis on ligikaudu 5 \u00b5s kilomeetri kohta. Seega v\u00f5ib \u00f6elda, et linnam\u00f5\u00f5tmelistes v\u00f5rkudes (k\u00fcmmekond kilomeetrit v\u00f5i rohkem) v\u00f5ivad mikrosekundid m\u00e4ngida suurt rolli. N\u00e4iteks andmebaaside s\u00fcnkroonimise replikatsioon, k\u00f5rge sagedusega kauplemine, sama plokiahel.<\/p>\n
Sissetoodud viivitus<\/i><\/p>\nSkaleeritavus<\/h4>\n
\nSuured jaotatud v\u00f5rgud v\u00f5ivad sisaldada mitmeid tuhandeid s\u00f5lmi ja v\u00f5rgu seadmeid, sadu kohalike v\u00f5rkude segmente. On oluline, et kr\u00fcpteerimise lahendused ei seaks mingeid piiranguid jaotatud v\u00f5rgu suuruse ja topoloogia osas. See puudutab eelk\u00f5ige maksimaalset s\u00f5lme ja v\u00f5rgu aadresside arvu. Selliste piirangutega v\u00f5ib kokku puutuda n\u00e4iteks kr\u00fcpteeritud v\u00f5rgu mitme punkti topoloogia rakendamisel (iseseisvate, kr\u00fcpteeritud \u00fchenduste ehk tunnelite kaudu) v\u00f5i valikuline kr\u00fcptimine (n\u00e4iteks protokolli v\u00f5i VLAN numbrite j\u00e4rgi). Kui v\u00f5rgu aadresse (MAC, IP, VLAN ID) kasutatakse tabelis v\u00f5tmetena, mille ridade arv on piiratud, siis ilmnevad need piirangud.<\/p>\n
Lisaks on suured v\u00f5rgud sageli mitme struktuuriastme, sealhulgas p\u00f5hiv\u00f5rgu, omanikud, kus igas rakendatakse oma aadressimise skeemi ja marsruutimise poliitikat. Sellise l\u00e4henemise rakendamiseks kasutatakse sageli spetsiaalseid kaadriformaate (nt Q-in-Q v\u00f5i MAC-in-MAC) ja marsruutimisprotokolle. Selliste v\u00f5rkude loomist mitte takistamiseks peavad kr\u00fcpteerimisseadmed neid kaadreid \u00f5igesti k\u00e4sitlema (st selles osas t\u00e4hendab skaleeritavus \u00fchilduvust \u2013 sellest allpool).<\/p>\n
Paindlikkus<\/h4>\n \nSiin k\u00e4sitletakse erinevate konfiguratsioonide, \u00fchendusskeemide, topoloogiate ja muude aspektide toetust. N\u00e4iteks kaubanduslikel Etherneti p\u00f5hinevates v\u00f5rguv\u00f5rkudes t\u00e4hendab see erinevat t\u00fc\u00fcpi virtuaalsete \u00fchenduste (E-Line, E-LAN, E-Tree), erinevate teenuste (nii portide kui VLAN-ide p\u00f5hiselt) ja erinevate transporttehnoloogiate toetust (need on juba eespool loetletud). Seega peab seade suutma t\u00f6\u00f6tada nii jooneliselt (\u201epunkt-punkt\u201d) kui ka mitme punkti re\u017eiimis, seadma eraldi tunnelid erinevate VLAN-ide jaoks ning v\u00f5imaldama pakettide j\u00e4rjestuse eiramist kaitstud kanali sees. Erinevate kr\u00fcptore\u017eiimide (sealhulgas sisu autentimisega v\u00f5i ilma) ja paketivahetusre\u017eiimide valimise v\u00f5imalus aitab tagada tasakaalu vastupidavuse ja j\u00f5udluse vahel s\u00f5ltuvalt praegustest tingimustest.<\/p>\n
Ka er oluline ka privaatsete v\u00f5rgu\u00fchenduste tugi, mille seadmed kuuluvad \u00fchele organisatsioonile (v\u00f5i on selle kasutuses), ja operaatorv\u00f5rgud, mille erinevad segmendid kuuluvad eri ettev\u00f5tetele. Hea, kui lahendus v\u00f5imaldab haldamist nii enda j\u00f5ududega kui ka kolmanda osapoole organisatsiooniga (haldamise teenuse mudel). Operaatorv\u00f5rkudes on oluline veel \u00fcks funktsioon \u2013 mitme kasutaja toimetamine (multitenancy) kr\u00fcptograafilise isoleerimise abil, et v\u00f5imaldada eri tellijate (abonentide) jagatud kasutamist, kelle liiklus l\u00e4bib sama seadmete komplekti. See n\u00f5uab tavaliselt iga tellija jaoks eraldi v\u00f5tmete ja sertifikaatide komplekti kasutamist.<\/p>\n
Kui seade soetataks konkreetse stsenaariumi jaoks, ei pruugi k\u00f5ik need omadused olla \u00fclimalt olulised \u2014 oluline on lihtsalt veenduda, et seade toetab praegu vajalikke funktsioone. Kuid kui lahendust soetataks tuleviku nimel, et toetada ka tulevasi stsenaariume, ja see valitakse 'ettev\u00f5tte standardiks', siis ei ole paindlikkus \u00fcleliigne \u2014 eriti arvestades erinevate tootjate seadmete vahelisi \u00fchilduvuspiiranguid (sellest r\u00e4\u00e4gime natuke hiljem).<\/p>\n
Lihtsus ja mugavus<\/h4>\n \nTeenindusmugavus on samuti mitme aspektiga m\u00f5isted. \u00dcldiselt v\u00f5ib \u00f6elda, et see on kokku kulutatud aega teadlikult kvalifitseeritud spetsialistide poolt, mis on vajalik lahenduse toetamiseks selle eluts\u00fckli erinevatel etappidel. Kui kulusid pole, ja paigaldamine, seadistamine, kasutamine on t\u00e4ielikult automatiseeritud, siis on kulud null ja mugavus absoluutne. Loomulikult ei toimu seda reaalmaailmas. M\u00f5istlik l\u00e4henemine on mudel \u00abahel punktis\u00bb<\/b> (bump-in-the-wire), v\u00f5i l\u00e4bipaistev \u00fchendus, kus kr\u00fcpteerimis seadmete lisamine ja eemaldamine ei eelda mingeid k\u00e4sitsi ega automaatseid muudatusi v\u00f5rgu konfiguratsioonis. See lihtsustab lahenduse haldamist: kr\u00fcpteerimisfunktsiooni saab vabalt sisse ja v\u00e4lja l\u00fclitada, ning vajadusel on v\u00f5imalik seade lihtsalt \u201e\u00fcmbersuunata\u201d v\u00f5rgu kaabli kaudu (s.t. otse \u00fchendada need ports v\u00f5rgu seadmetest, kuhu see oli \u00fchendatud). T\u00f5si, on ka \u00fcks miinus \u2013 sama saab teha ka r\u00fcndaja. Principi \u201eseade kaablis\u201c rakendamiseks tuleb arvestada mitte ainult andmekihiga<\/b>, vaid ka kontrolli- ja halduskihte<\/b> \u2013 seadmed peavad olema nende jaoks l\u00e4bipaistvad. Seet\u00f5ttu saab sellist liiklust kr\u00fcpteerida ainult siis, kui seadmete vahelise v\u00f5rgu kr\u00fcpteerimise s\u00fcsteemis ei ole nende liikluse vastuv\u00f5tjaid, sest kui seda tagasi l\u00fckata v\u00f5i kr\u00fcpteerida, v\u00f5ib kr\u00fcpteerimise sisse- ja v\u00e4ljal\u00fclitamisel v\u00f5rgu konfiguratsioon muutuda. Kr\u00fcpteerimise seade v\u00f5ib olla l\u00e4bipaistev ka f\u00fc\u00fcsilise taseme signaalide jaoks. Eelk\u00f5ige signaali kadumise korral peab see edastama selle kadumise (st v\u00e4lja l\u00fclitama oma saatjad) tagasi ja ettepoole (\u201eoma suunas\u201d) signaali suunas.<\/p>\n
Oluline on ka toetada volituste jagamist IT ja turbeosakondade vahel, sealhulgas v\u00f5rguosakond. Kr\u00fcpteerimislahendus peab toetama organisatsioonis kehtivat juurdep\u00e4\u00e4su ja auditi mudelit. Tuleb minimeerida erinevate osakondade koost\u00f6\u00f6 vajadust rutiinsete toimingute tegemisel. Seet\u00f5ttu on spetsialiseeritud seadmetel, mis toetavad ainult kr\u00fcpteerimise funktsioone ja on v\u00f5rguoperatsioonide suhtes maksimaalselt l\u00e4bipaistvad, suurem mugavuse eelis. Teisis\u00f5nu, turbeosakonna t\u00f6\u00f6tajatel ei peaks olema p\u00f5hjust p\u00f6\u00f6rduda \u201ev\u00f5rkude spetsialisti\u201c poole v\u00f5rgu seadete muutmiseks. Ja vastavalt ei peaks neil viimasele olema vajadust muuta kr\u00fcpteerimise seadistusi v\u00f5rgu hooldamise ajal.<\/p>\n
Veel oluline tegur on haldust\u00f6\u00f6riistade v\u00f5imalused ja mugavus. Need peavad olema visuaalselt arusaadavad, loogilised, v\u00f5imaldama seadete importimist ja eksportimist, automatiseerimist jne. Tuleb kohe t\u00e4helepanu p\u00f6\u00f6rata hallatavate variantide kergusele (tavaliselt on see oma haldustarkvara, veebiliides ja k\u00e4surida) ning sellele, milliste funktsioonidega need igas variandis tulevad (piirangud v\u00f5ivad esineda). Oluline funktsioon on toimetamine v\u00e4lisr\u00fcnnakute<\/b> (out-of-band) haldamine, st eraldiseisva haldamise v\u00f5rgu kaudu, ja sisehaldus<\/b> (in-band) haldamine, st tavalise v\u00f5rgu kaudu, kus edastatakse kasulikku liiklust. Haldust\u00f6\u00f6riistad peavad signaalima k\u00f5ikidest ebasoodsatest olukordadest, sealhulgas I\u0411 juhtumitest. Rutiinseid, korduvaid toiminguid tuleb teha automaatselt. Eriti see kehtib v\u00f5tmete haldamise kohta. Need peavad olema automaatselt genereeritud ja jagatud. PKI tugi on suur pluss.<\/p>\n\u00dchilduvus<\/h4>\n
\nSee, the device's compatibility with network standards. This refers not only to industrial standards set by authoritative organizations like IEEE, but also to proprietary protocols from industry leaders such as Cisco. There are two fundamental ways to ensure compatibility: either through transparency<\/b>, or through explicit support<\/b> of protocols (when the encryption device becomes one of the nodes in the network for a specific protocol and processes the control traffic of that protocol). The completeness and correctness of protocol implementation directly influence interoperability with networks. It's essential to support various PHY layer options (speed, transmission medium, coding schemes), Ethernet frames of different formats with any MTU, and various L3 control protocols (primarily from the TCP\/IP family).<\/p>\n
Transparency is ensured through mutative mechanisms (temporary modifications of the contents of open headers in traffic between encryptors), pass-through (when individual packets remain unencrypted), and offsets to the start of encryption (when normally encrypted fields in packets are left unencrypted).<\/p>\n
How transparency is ensured<\/i><\/p>\n
Seet\u00f5ttu t\u00e4psustage alati, kuidas teatud protokolli tuge tagatakse. Sageli on l\u00e4bipaistev toetus mugavam ja usaldusv\u00e4\u00e4rsem.<\/p>\n
Interoperatiivsuse<\/h4>\n \nSee on samuti \u00fchilduvus, kuid teises m\u00f5ttes, nimelt v\u00f5imalus suhelda teiste tootjate kr\u00fcptimisvahenditega. Siin s\u00f5ltub palju kr\u00fcptimisprotokollide standardiseerimise seisukorrast. L1-tasandil puuduvad \u00fcldtunnustatud kr\u00fcptimisstandardid.<\/p>\n
Etherneti L2 kr\u00fcptimiseks on standard 802.1ae (MACsec), kuid see ei kasuta otsest<\/b> (end-to-end), vaid portidevahelist<\/b>, \u201ehop-by-hop\u201c kr\u00fcptimine ning algses toimetuses ei olnud see jagatud v\u00f5rkudes kasutamiseks sobiv, mist\u00f5ttu tekkisid sellel p\u00f5hinevad laiendused, mis \u00fcletavad selle piirangu (loomulikult teiste tootjate seadmete \u00fchilduvuse arvelt). T\u00f5si, 2018. aastal lisati standardisse 802.1ae jagatud v\u00f5rkude tugi, kuid siiski puudub tugi GOST kr\u00fcptimisalgoritmide komplektidele. Seet\u00f5ttu on kohandatud, mitte-standardsetel L2 kr\u00fcptimisprotokollidel tavaliselt suurem efektiivsus (eriti madalam riba laius) ja paindlikkus (kr\u00fcptimisalgoritmide ja re\u017eiimide vahetamine).<\/p>\n
K\u00f5rgematel tasemetel (L3 ja L4) on tunnustatud standardid, eelk\u00f5ige IPsec ja TLS, kuid siin ei ole k\u00f5ik nii lihtne. Fakt on see, et iga\u00fchel neist standarditest on protokollide kogum, millest iga\u00fchel on erinevad versioonid ning kohustuslikud v\u00f5i valikulised laiendused. Lisaks eelistavad m\u00f5ned tootjad rakendada oma kaubam\u00e4rgiga kr\u00fcpteerimisprotokolle ka L3\/L4 tasandil. Seet\u00f5ttu ei tasu t\u00e4ieliku \u00fchilduvuse suhtes lootust panna, kuid oluline on, et erinevad mudelid ja eri p\u00f5lvkonnad sama tootja toodete vahel tagatakse v\u00e4hemalt mingi koost\u00f6\u00f6.<\/p>\n
Usaldusv\u00e4\u00e4rsus<\/h4>\n \nErinevate lahenduste v\u00f5rdlemiseks v\u00f5ib kasutada kas keskmist t\u00f6\u00f6lekulumise aega v\u00f5i valmiduskoefitsienti. Kui neid n\u00e4itajaid ei ole (v\u00f5i neisse ei saa usaldust), saab teha kvalitatiivset v\u00f5rdlust. Eelis on seadmetel, mille haldamine on mugav (v\u00e4iksem riski seadistamisvigade jaoks), spetsialiseeritud kr\u00fcptograafidel (samal p\u00f5hjusel) ning lahendustel, millel on minimaalne rikke tuvastamise ja k\u00f5rvaldamise aeg, sealhulgas \u201ekuumade\u201c varundamistehnoloogiate abil s\u00f5lmede ja seadmete t\u00e4ielikud varukoopiad.<\/p>\n
Hind<\/h4>\n \nMis tuleb kulude suhtesse, siis nagu enamik IT-lahendusi, on m\u00f5istlik v\u00f5rrelda kogu omamiskulu. Selle arvutamiseks pole vaja jalgratast uuesti leiutada, vaid kasutada mis tahes sobivat metoodikat (n\u00e4iteks Gartneri oma) ja igasuguseid kalkulaatoreid (nt neid, mida organisatsioon juba kasutab TCO arvutamiseks). On selge, et v\u00f5rgu\u0161ifreerimise lahenduse kogukulu koosneb otsestest<\/b> ostu- v\u00f5i rendikuludest lahendusele endale, infrastruktuurist seadmete majutamiseks ning k\u00e4ivitamise, haldamise ja toetamise kuludest (olgu need siis tehtud oma j\u00f5ududega v\u00f5i kolmanda osapoole teenusena), samuti kaudsetest<\/b> lahenduse seiskamise kulud (alates l\u00f5ppkasutajate tootlikkuse kadumisest). T\u00f5en\u00e4oliselt on \u00fcks n\u00fcanss. Lahenduse j\u00f5udluse m\u00f5ju saab arvestada erinevalt: kas kaudsete kuludena, mis on tingitud tootlikkuse v\u00e4henemisest, v\u00f5i kui 'virtuaalsed' otsesed kulud v\u00f5rgu vahendite ostmiseks\/uutele seadmetele ja hoolduseks, et kompenseerida v\u00f5rgu j\u00f5udluse v\u00e4henemist kr\u00fcpteerimise kasutuse t\u00f5ttu. Igatahes on kulud, mille t\u00e4pset hindamist on keeruline saavutada, parem j\u00e4tta arvestusest v\u00e4lja: nii suureneb usaldus l\u00f5ppm\u00e4\u00e4rast. Ja nagu ikka, on igal juhul m\u00f5istlik v\u00f5rrelda erinevaid seadmeid TCO osas konkreetse kasutusstsenaariumi \u2014 reaalsete v\u00f5i t\u00fc\u00fcpiliste \u2014 alusel.<\/p>\nVastupidavus<\/h4>\n
\nViimane omadus on lahenduse vastupidavus. Enamikul juhtudel saab vastupidavust hinnata vaid kvalitatiivselt, v\u00f5rreldes erinevaid lahendusi. Peame meeles pidama, et kr\u00fcpteerimisseadmed on mitte ainult vahend, vaid ka kaitseobjekt. Need v\u00f5ivad olla erinevate ohtude eesm\u00e4rgiks. Eelk\u00f5ige on ohtudeks eraelu kaitse rikkumine, s\u00f5numite taastamine ja muutmine. Need ohud v\u00f5ivad realiseeruda kr\u00fcpti v\u00f5i selle \u00fcksikute re\u017eiimide haavatavuste kaudu ning kr\u00fcptimise protokollide haavatavuste kaudu (sealhulgas \u00fchenduse loomise ja v\u00f5tmete genereerimise\/jaotamise etappidel). Eelis on neil lahendustel, mis v\u00f5imaldavad kr\u00fcpteerimisalgoritmi vahetamist v\u00f5i kr\u00fcptore\u017eiimi \u00fcleminekut (v\u00e4hemalt sisseehitatud tarkvara v\u00e4rskenduse kaudu), ning neil lahendustel, mis tagavad maksimaalse kr\u00fcpteerimise, peites kurjategijatelt mitte ainult kasutajaandmeid, vaid ka aadressi ja muid teenindusinfot, samuti neil lahendustel, mis mitte ainult ei kr\u00fcpteeri, vaid kaitsevad s\u00f5numeid taastamise ja muutmise eest. K\u00f5ikide t\u00e4nap\u00e4evaste kr\u00fcptimise, digitaalse allkirja, v\u00f5tmete genereerimise jms, mis on m\u00e4\u00e4ratletud standardites, puhul v\u00f5ib vastupidavust pidada \u00fchesuguseks (vastasel juhul v\u00f5ib lihtsalt eksida kr\u00fcptograafia metsades). Kas need peavad olema tingimata GOST-algoritmid? Siin on k\u00f5ik lihtne: kui rakendusskeem n\u00f5uab FSB sertifitseerimist SKZI jaoks (ja Venemaal on see enamasti nii) enamikul v\u00f5rgu kr\u00fcpteerimise stsenaariumidel, siis valime ainult sertifitseeritud lahenduste vahel. Kui ei, siis pole m\u00f5tet arvesse v\u00f5tta seadmeid ilma sertifikaatideta.<\/p>\n
Teine oht on h\u00e4kkimise oht, volitamata juurdep\u00e4\u00e4s seadmetele (sealhulgas f\u00fc\u00fcsilise juurdep\u00e4\u00e4su kaudu nii seest kui v\u00e4ljast). Oht v\u00f5ib realiseeruda l\u00e4bi
L\u00f5puks on veel \u00fcks ohut\u00fc\u00fcp - vale seadistamine ja kasutamine, mis on puhas inimfaktor. Siin ilmutab end veel \u00fcks spetsialiseeritud \u0161ifreerijate eelis konvergentssete lahenduste \u00fcle, mis on tihti suunatud kogenud \"v\u00f5rguhaldusele\", kuid v\u00f5ivad tekitada raskusi \"tavalisetele\" laiaprofii infotehnoloogia spetsialistidele.<\/p>\n
Kokkuv\u00f5te<\/h4>\n \nP\u00f5him\u00f5tteliselt v\u00f5iks siin pakkuda mingit integreeritud n\u00e4itajat erinevate seadmete v\u00f5rdlemiseks, midagi sellist nagu<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\nkus p on n\u00e4itaja kaal ja r seadme j\u00e4rjestus selle n\u00e4itaja j\u00e4rgi, ning igas eeltoodud omaduses v\u00f5iks jagada \"aatomi\" n\u00e4itajateks. Tootis see valem v\u00f5iks olla kasulik n\u00e4iteks pakkumiste v\u00f5rdlemisel eelnevalt kokkulepitud reeglite j\u00e4rgi. Kuid saab hakkama ka lihtsa tabeliga nagu<\/p>\n
Omadus
L\u00e4bivool
+++<\/p>\n
\u00dclekandetasud
+++<\/p>\n
Viivitus
++<\/p>\n
Skaleeritavus
+++<\/p>\n
Paindlikkus
+<\/p>\n
Interoperatiivsuse
+<\/p>\n
\u00dchilduvus
+++<\/p>\n
Lihtsus ja mugavus
++<\/p>\n
Katastroofitaluvus
++<\/p>\n
Hind
+<\/p>\n
Vastupidavus
+++<\/p>\n
\nOlen r\u00f5\u00f5mus vastata k\u00fcsimustele ja konstruktiivsetele kriitilistele m\u00e4rkustele.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