VPN<\/a> eller utan den.<\/p>\nN\u00e4tverkskryptering i ett distribuerat Ethernet-n\u00e4tverk<\/i><\/p>\n
Sj\u00e4lva enheterna kan antingen vara specialiserade<\/b> (enbart avsedda f\u00f6r kryptering), eller multifunktionella (hybrida, konvergenta<\/b>), vilket inneb\u00e4r att de ocks\u00e5 utf\u00f6r andra funktioner (till exempel som brandv\u00e4gg eller router). Olika leverant\u00f6rer klassificerar sina enheter i olika klasser\/kategorier, men det spelar ingen roll \u2013 det viktiga \u00e4r bara att de kan kryptera webbtrafik och vilka egenskaper de har.<\/p>\n
Som en p\u00e5minnelse vill jag n\u00e4mna att \"n\u00e4tverkskryptering\", \"trafikkryptering\", \"krypterare\" \u2013 \u00e4r informella termer, \u00e4ven om de ofta anv\u00e4nds. I ryska lagtexter (inklusive de som inf\u00f6rliva GOST-standarder) kommer du f\u00f6rmodligen inte att st\u00f6ta p\u00e5 dem.<\/p>\n
Krypteringsniv\u00e5er och \u00f6verf\u00f6ringsl\u00e4gen<\/h4>\n \nInnan vi g\u00e5r in p\u00e5 beskrivningen av de specifikationer som kommer att anv\u00e4ndas f\u00f6r utv\u00e4rdering m\u00e5ste vi f\u00f6rst f\u00f6rst\u00e5 en viktig sak, n\u00e4mligen \"krypteringsniv\u00e5n\". Jag har noterat att den ofta n\u00e4mns b\u00e5de i officiella dokument fr\u00e5n leverant\u00f6rer (i beskrivningar, manualer etc.) och i informella diskussioner (under f\u00f6rhandlingar, p\u00e5 tr\u00e4ningar). Allts\u00e5 verkar det som om alla vet vad det handlar om, men jag har personligen bevittnat viss f\u00f6rvirring.<\/p>\n
S\u00e5 vad \u00e4r egentligen \"krypteringsniv\u00e5\"? Det \u00e4r klart att det handlar om niv\u00e5n i den referensmodell f\u00f6r n\u00e4tverk OSI\/ISO d\u00e4r krypteringen sker. L\u00e5t oss l\u00e4sa GOST R ISO 7498-2\u201399 \"Informations teknologi. Sammanl\u00e4nkning av \u00f6ppna system. Grundl\u00e4ggande referensmodell. Del 2. Arkitektur f\u00f6r informationsskydd\". Fr\u00e5n detta dokument kan vi f\u00f6rst\u00e5 att konfidentialitetsserviceniv\u00e5n (ett av de mekanismer som s\u00e4kerst\u00e4lls genom kryptering) \u00e4r niv\u00e5n av protokollet, datatj\u00e4nstblockets (\u201cpayload\u201d, anv\u00e4ndardata) som krypteras. Som det st\u00e5r i standarden kan tj\u00e4nsten tillhandah\u00e5llas antingen p\u00e5 samma niv\u00e5, \"p\u00e5 egen hand\", eller med hj\u00e4lp av en underliggande niv\u00e5 (det \u00e4r faktiskt s\u00e5 h\u00e4r som detta oftast realiseras i MACsec).<\/p>\n
I praktiken finns det dock tv\u00e5 \u00f6verf\u00f6ringsl\u00e4gen f\u00f6r krypterad information \u00f6ver n\u00e4tverket (IPsec kommer genast till tankarna, men dessa l\u00e4gen f\u00f6rekommer ocks\u00e5 i andra protokoll). I transportl\u00e4ge<\/b> (ibland kallat native) krypteras endast tj\u00e4nsten<\/b> datablock, medan rubrikerna f\u00f6rblir \"\u00f6ppna\", okrypterade (ibland l\u00e4ggs ytterligare f\u00e4lt med information om krypteringsalgoritmen till, medan andra f\u00e4lt modifieras och r\u00e4knas om). I tunnell\u00e4ge<\/b> \u00e4r hela protokoll<\/b> datablocket (det vill s\u00e4ga sj\u00e4lva paketet) krypteras och inkapslas i en serviceman\u00f6verblock av samma eller h\u00f6gre niv\u00e5, det vill s\u00e4ga det omges av nya rubriker.<\/p>\n
Krypteringsniv\u00e5n i sig, i kombination med n\u00e5got \u00f6verf\u00f6ringsl\u00e4ge, \u00e4r varken bra eller d\u00e5lig, s\u00e5 man kan inte s\u00e4ga att L3 i transportl\u00e4ge \u00e4r b\u00e4ttre \u00e4n L2 i tunnel\u00e4ge. De p\u00e5verkar helt enkelt m\u00e5nga egenskaper som bed\u00f6mer enheter. Till exempel flexibilitet och kompatibilitet. F\u00f6r arbete i n\u00e4tverk L1 (bithastighetsomkoppling), L2 (ramomkoppling) och L3 (paketrouting) i transportl\u00e4ge beh\u00f6vs l\u00f6sningar som krypterar p\u00e5 samma eller h\u00f6gre niv\u00e5 (annars kommer adressinformationen att krypteras, och data n\u00e5r inte sina destinationer), medan tunnel\u00e4ge g\u00f6r det m\u00f6jligt att \u00f6vervinna denna begr\u00e4nsning (sj\u00e4lvklart p\u00e5 bekostnad av andra viktiga egenskaper).<\/p>\n
Transport- och tunnelkrypteringsl\u00e4gen L2<\/i><\/p>\n
Nu g\u00e5r vi vidare f\u00f6r att analysera egenskaperna.<\/p>\n
Performance<\/h4>\n \nF\u00f6r n\u00e4tverkskryptering \u00e4r prestanda ett komplext, m\u00e5ngdimensionellt begrepp. Ibland kan en specifik modell \u00f6vertr\u00e4ffa i en prestandakarakteristik men underprestera i en annan. D\u00e4rf\u00f6r \u00e4r det alltid f\u00f6rdelaktigt att ta h\u00e4nsyn till alla aspekter av krypteringsprestanda och deras p\u00e5verkan p\u00e5 n\u00e4tverksprestanda och de till\u00e4mpningar som anv\u00e4nder den. H\u00e4r kan vi dra en analogi med en bil, d\u00e4r det inte bara \u00e4r den maximala hastigheten som r\u00e4knas, utan \u00e4ven tiden f\u00f6r att n\u00e5 \"hundra\", br\u00e4nslef\u00f6rbrukningen och s\u00e5 vidare. Prestandakarakteristik tilldelar f\u00f6retag och deras potentiella kunder stor uppm\u00e4rksamhet. Som regel \u00e4r det just prestanda som avg\u00f6r rangordningen i leverant\u00f6rernas produktlinjer f\u00f6r krypteringsenheter.<\/p>\n
Det \u00e4r tydligt att prestanda beror p\u00e5 b\u00e5de komplexiteten av de n\u00e4tverks- och kryptografiska operationerna som utf\u00f6rs p\u00e5 enheten (inklusive hur v\u00e4l dessa uppgifter kan parallelliseras och pipelinas) samt prestandan hos h\u00e5rdvaran och kvaliteten p\u00e5 den inbyggda programvaran. D\u00e4rf\u00f6r anv\u00e4nds kraftfullare \"h\u00e5rdvara\" i de \u00e4ldre modellerna, och det finns ibland m\u00f6jlighet att utrusta dem med ytterligare processorer och minnesmoduler. Det finns flera tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r att implementera kryptografiska funktioner: p\u00e5 en universell centralprocessor (CPU), en specialiserad anpassad integrerad krets (ASIC) eller p\u00e5 en programmerbar logisk integrerad krets (FPGA). Varje tillv\u00e4gag\u00e5ngss\u00e4tt har sina f\u00f6r- och nackdelar. Till exempel kan CPU bli en \"flaskhals\" vid kryptering, s\u00e4rskilt om processorn saknar specialiserade instruktioner f\u00f6r att st\u00f6dja krypteringsalgoritmen (eller om de inte anv\u00e4nds). Specialiserade kretsar saknar flexibilitet, och att \"omprogrammera\" dem f\u00f6r att \u00f6ka prestandan, l\u00e4gga till nya funktioner eller \u00e5tg\u00e4rda s\u00e5rbarheter \u00e4r inte alltid m\u00f6jligt. Dessutom blir deras anv\u00e4ndning l\u00f6nsam endast vid stora produktionsvolymer. Det \u00e4r d\u00e4rf\u00f6r den \"gyllene medelv\u00e4gen\" har blivit s\u00e5 popul\u00e4r - anv\u00e4ndningen av FPGA. Det \u00e4r faktiskt p\u00e5 FPGA som s\u00e5 kallade kryptohastare \u00e4r gjorda - inbyggda eller externa specialiserade h\u00e5rdvarumoduler f\u00f6r st\u00f6d av kryptografiska operationer.<\/p>\n
Eftersom vi pratar om n\u00e4tverks-<\/b> kryptering \u00e4r det logiskt att m\u00e4ta prestandan hos l\u00f6sningarna i samma enheter som f\u00f6r andra n\u00e4tverksenheter \u2013 genomstr\u00f6mningskapacitet, procentuell paketf\u00f6rlust (frame loss) och latens. Dessa v\u00e4rden definieras i RFC 1242. F\u00f6r \u00f6vrigt, om varianter av latens (jitter) som ofta n\u00e4mns, st\u00e5r det inget om detta i denna RFC. Hur m\u00e4ter man dessa v\u00e4rden? Jag har inte funnit n\u00e5gra godk\u00e4nda metoder i n\u00e5gra standarder (officiella eller inofficiella som RFC) specifikt f\u00f6r n\u00e4tverkskryptering. Det skulle vara logiskt att anv\u00e4nda en metod f\u00f6r n\u00e4tverksenheter, fastst\u00e4lld i standarden RFC 2544. M\u00e5nga leverant\u00f6rer f\u00f6ljer den - m\u00e5nga, men inte alla. Till exempel levererar de testtrafik endast i en riktning ist\u00e4llet f\u00f6r b\u00e5da, som rekommenderas<\/b> i standarden. N\u00e5v\u00e4l.<\/p>\n
M\u00e4tning av prestanda f\u00f6r n\u00e4tverkskrypteringsenheter har sina egna specifikationer. F\u00f6r det f\u00f6rsta \u00e4r det korrekt att g\u00f6ra alla m\u00e4tningar f\u00f6r ett par av enheter: \u00e4ven om krypteringsalgoritmerna \u00e4r symmetriska, \u00e4r det inte n\u00f6dv\u00e4ndigt att f\u00f6rdr\u00f6jningar och paketf\u00f6rluster vid kryptering och dekryptering \u00e4r lika. F\u00f6r det andra \u00e4r det meningsfullt att m\u00e4ta just delf\u00f6r\u00e4ndringen, p\u00e5verkan av n\u00e4tverkskryptering p\u00e5 den slutgiltiga n\u00e4tverksproduktiviteten, genom att j\u00e4mf\u00f6ra tv\u00e5 konfigurationer: utan krypteringsenheter och med dem. Alternativt, i fall med hybridenheter som kombinerar flera funktioner ut\u00f6ver n\u00e4tverkskryptering, vid avst\u00e4ngt och p\u00e5slaget kryptering. Denna p\u00e5verkan kan vara olika och bero p\u00e5 hur krypteringsenheterna \u00e4r kopplade, fr\u00e5n arbetsl\u00e4gen och dessutom fr\u00e5n trafikens karakt\u00e4r. M\u00e5nga prestandaparametrar beror s\u00e4rskilt p\u00e5 paketl\u00e4ngden, vilket \u00e4r anledningen till att man ofta anv\u00e4nder grafer som visar beroendet av dessa parametrar fr\u00e5n paketl\u00e4ngden f\u00f6r att j\u00e4mf\u00f6ra prestanda av olika l\u00f6sningar, eller s\u00e5 anv\u00e4nder man IMIX \u2013 trafikf\u00f6rdelning efter paketl\u00e4ngd som ungef\u00e4r speglar verkligheten. Om vi tar samma grundkonfiguration utan kryptering f\u00f6r v\u00e5rt exempel, kan vi j\u00e4mf\u00f6ra n\u00e4tverkskrypteringsl\u00f6sningar som implementerats p\u00e5 olika s\u00e4tt utan att g\u00e5 in p\u00e5 dessa skillnader: L2 med L3,<\/p>\n
Kopplingsschema f\u00f6r prestandatestning<\/i><\/p>\n
Den f\u00f6rsta egenskapen som uppm\u00e4rksammas \u00e4r \"hastigheten\" p\u00e5 krypteringsenheten, det vill s\u00e4ga bandbredden<\/b> (bandwidth) f\u00f6r dess n\u00e4tverksgr\u00e4nssnitt, bitfl\u00f6deshastigheten. Den best\u00e4ms av de n\u00e4tverksstandarder som st\u00f6ds av gr\u00e4nssnitten. F\u00f6r Ethernet \u00e4r vanliga siffror \u2013 1 Gbit\/s och 10 Gbit\/s. Men, som vi vet, i vilket n\u00e4tverk som helst \u00e4r den maximala teoretiska kapaciteten<\/b> (genomstr\u00f6mning) p\u00e5 varje av dess niv\u00e5er \u00e4r alltid l\u00e4gre \u00e4n bandbredden: en del av bandbredden \"\u00e4ts upp\" av mellanrum, kontrollhuvuden och s\u00e5 vidare. Om en enhet kan ta emot, bearbeta (i v\u00e5rt fall kryptera eller dekryptera) och \u00f6verf\u00f6ra trafik med full hastighet p\u00e5 n\u00e4tverksgr\u00e4nssnittet, det vill s\u00e4ga med den maximala teoretiska genomstr\u00f6mningen f\u00f6r den n\u00e4tverksmodellen, s\u00e5 s\u00e4gs det att den fungerar vid linjens hastighet<\/b>. F\u00f6r att detta ska vara m\u00f6jligt m\u00e5ste enheten inte f\u00f6rlora eller kasta bort paket oavsett deras storlek och hur ofta de kommer. Om krypteringsenheten inte st\u00f6djer arbete vid linjens hastighet, anges oftast dess maximala genomstr\u00f6mning i samma gigabit per sekund (ibland med angivande av pakets l\u00e4ngd - ju kortare paketen \u00e4r, desto l\u00e4gre \u00e4r oftast genomstr\u00f6mningen). Det \u00e4r mycket viktigt att f\u00f6rst\u00e5 att den maximala genomstr\u00f6mningen \u00e4r den maximala utan f\u00f6rluster<\/b> (\u00e4ven om enheten kan \"pumpa\" trafik med h\u00f6gre hastighet, men tappar paket under tiden). Dessutom \u00e4r det viktigt att notera att vissa leverant\u00f6rer m\u00e4ter den totala genomstr\u00f6mningen mellan alla portpar, s\u00e5 dessa siffror s\u00e4ger lite om det ifall all krypterad trafik g\u00e5r genom en enda port.<\/p>\n
Var \u00e4r det s\u00e4rskilt viktigt att fungera vid linjens hastighet (eller, annorlunda uttryckt, utan paketf\u00f6rluster)? I kanaler med h\u00f6g genomstr\u00f6mning och stora f\u00f6rdr\u00f6jningar (till exempel satellitkanaler), d\u00e4r man m\u00e5ste st\u00e4lla in en stor TCP-f\u00f6nsterstorlek f\u00f6r att uppr\u00e4tth\u00e5lla h\u00f6g \u00f6verf\u00f6ringshastighet, och d\u00e4r paketf\u00f6rluster kraftigt minskar n\u00e4tverkets prestanda.<\/p>\n
Men inte all bandbredd anv\u00e4nds f\u00f6r att \u00f6verf\u00f6ra nyttiga data. Man m\u00e5ste ta h\u00e4nsyn till s\u00e5 kallade \u00f6verhettningskostnader<\/b> (\u00f6verhead) bandbredd. Detta \u00e4r den del av en krypteringsenhets bandbredd (i procent eller byte per paket) som faktiskt g\u00e5r f\u00f6rlorad (inte kan anv\u00e4ndas f\u00f6r att \u00f6verf\u00f6ra applikationsdata). Overhead uppst\u00e5r fr\u00e4mst p\u00e5 grund av den \u00f6kade storleken (utfyllnad, 'padding') av datadelen i krypterade n\u00e4tverkspaket (beroende p\u00e5 krypteringsalgoritm och dess l\u00e4ge). F\u00f6r det andra p\u00e5 grund av \u00f6kad l\u00e4ngd p\u00e5 paketens rubriker (tunnell\u00e4ge, serviceinsertion av krypteringsprotokoll, integritetsinsertion etc., beroende p\u00e5 protokoll och l\u00e4ge f\u00f6r chiffer och \u00f6verf\u00f6ringsl\u00e4ge) \u2013 dessa overheadkostnader \u00e4r vanligtvis de mest betydande och det \u00e4r de som uppm\u00e4rksammas f\u00f6rst. F\u00f6r det tredje, p\u00e5 grund av fragmentering av paket vid \u00f6verskridande av max storlek p\u00e5 datablokkar (MTU) (om n\u00e4tverket kan dela ett paket som \u00f6verskrider MTU i tv\u00e5, duplicera dess rubriker). F\u00f6r det fj\u00e4rde, p\u00e5 grund av f\u00f6rekomsten av extra service (kontroll) trafik mellan krypteringsenheterna (f\u00f6r nyckelutbyte, tunnelskapande etc.). L\u00e5ga overheadkostnader \u00e4r viktiga d\u00e4r kanalens bandbredd \u00e4r begr\u00e4nsad. Detta \u00e4r s\u00e4rskilt tydligt f\u00f6r trafik med sm\u00e5 paket, s\u00e5som r\u00f6sttrafik \u2013 d\u00e4r kan overheadkostnader<\/p>\n
Bandbredd<\/i><\/p>\n
Slutligen finns det ocks\u00e5 inledd f\u00f6rdr\u00f6jning<\/b> \u2013 skillnaden (i delar av en sekund) i n\u00e4tverksf\u00f6rdr\u00f6jning (tiden det tar f\u00f6r data att g\u00e5 fr\u00e5n ing\u00e5ng till utg\u00e5ng i n\u00e4tverket) mellan datatransmission utan n\u00e4tverkskryptering och med den. Generellt g\u00e4ller att ju l\u00e4gre f\u00f6rdr\u00f6jning (\"latens\") i n\u00e4tverket, desto mer kritisk blir den f\u00f6rdr\u00f6jning som tillf\u00f6rs av krypteringsenheterna. F\u00f6rdr\u00f6jningen orsakas b\u00e5de av sj\u00e4lva krypteringsoperationen (beroende av krypteringsalgoritm, blockl\u00e4ngd och l\u00e4ge f\u00f6r krypteringen, samt kvaliteten p\u00e5 implementationen i programvaran) och av hanteringen av n\u00e4tverkspaketet i enheten. Den tillf\u00f6rda f\u00f6rdr\u00f6jningen beror b\u00e5de p\u00e5 paketbehandlingsl\u00e4get (genomstr\u00f6mnings- eller \"lagra-och-skicka\") och plattformens prestanda (\"h\u00e5rdvaruimplementation\" p\u00e5 FPGA eller ASIC \u00e4r vanligtvis snabbare \u00e4n \"programvaru\" p\u00e5 CPU). L2-kryptering har n\u00e4stan alltid en mindre tillf\u00f6rd f\u00f6rdr\u00f6jning j\u00e4mf\u00f6rt med L3- eller L4-kryptering: detta beror p\u00e5 att enheter som krypterar p\u00e5 L3\/L4 ofta implementeras konvergenta. Till exempel har h\u00f6gkapacitetskrypterare f\u00f6r Ethernet, som \u00e4r implementerade p\u00e5 FPGA och krypterar p\u00e5 L2, en negligibel f\u00f6rdr\u00f6jning p\u00e5 grund av krypteringsoperationen \u2013 ibland, n\u00e4r kryptering aktiveras p\u00e5 ett par enheter, minskar den totala f\u00f6rdr\u00f6jningen de bidrar med! L\u00e5g f\u00f6rdr\u00f6jning \u00e4r viktigt d\u00e4r den \u00e4r j\u00e4mf\u00f6rbar med de totala f\u00f6rdr\u00f6jningarna i kanalen, inklusive signalens spridningsf\u00f6rdr\u00f6jning, som \u00e4r cirka 5 \u00b5s per kilometer. Det vill s\u00e4ga att man kan s\u00e4ga att f\u00f6r stadsn\u00e4t (som \u00e4r tiotals kilometer i diameter) kan mikrosekunder g\u00f6ra stor skillnad. Till exempel f\u00f6r synkron replikering av databaser, h\u00f6gfrekvent handel, eller blockchain.<\/p>\n
Tillf\u00f6rd f\u00f6rdr\u00f6jning<\/i><\/p>\nSkalbarhet<\/h4>\n
\nStora distribuerade n\u00e4tverk kan omfatta m\u00e5nga tusen noder och n\u00e4tverksenheter samt hundratals segment av lokala n\u00e4tverk. Det \u00e4r viktigt att l\u00f6sningar f\u00f6r kryptering inte inf\u00f6r ytterligare begr\u00e4nsningar p\u00e5 storlek och topologi f\u00f6r det distribuerade n\u00e4tverket. Detta g\u00e4ller framf\u00f6r allt det maximala antalet adresser f\u00f6r noder och n\u00e4tverk. S\u00e5dana begr\u00e4nsningar kan uppst\u00e5, till exempel, vid implementeringen av en multipunkt-topologi i ett krypterat n\u00e4tverk (med oberoende skyddade anslutningar eller tunnlar) eller selektiv kryptering (till exempel baserat p\u00e5 protokollnummer eller VLAN). Om n\u00e4tverksadresser (MAC, IP, VLAN ID) anv\u00e4nds som nycklar i en tabell som har ett begr\u00e4nsat antal rader, framtr\u00e4der dessa begr\u00e4nsningar h\u00e4r.<\/p>\n
Dessutom har stora n\u00e4tverk ofta flera strukturella niv\u00e5er, inklusive k\u00e4rnn\u00e4tverk, d\u00e4r varje niv\u00e5 implementerar sin egen adresseringsschema och routingpolicy. F\u00f6r att implementera en s\u00e5dan strategi anv\u00e4nds ofta speciella ramformat (som Q-in-Q eller MAC-in-MAC) och routingprotokoll. F\u00f6r att inte hindra uppbyggnaden av s\u00e5dana n\u00e4tverk m\u00e5ste krypteringsenheter korrekt hantera s\u00e5dana ramar (det vill s\u00e4ga att skalbarhet i det h\u00e4r avseendet kommer att inneb\u00e4ra kompatibilitet \u2013 mer om detta nedan).<\/p>\n
Flexibilitet<\/h4>\n \nDet handlar om st\u00f6d f\u00f6r olika konfigurationer, anslutningsscheman, topologier och mer. Till exempel, f\u00f6r switchade n\u00e4tverk baserade p\u00e5 Carrier Ethernet-teknologier inneb\u00e4r detta st\u00f6d f\u00f6r olika typer av virtuella anslutningar (E-Line, E-LAN, E-Tree), olika serviceniv\u00e5er (b\u00e5de per portar och per VLAN) och olika transportteknologier (de har redan n\u00e4mnts ovan). Det inneb\u00e4r att enheten ska kunna fungera b\u00e5de i linj\u00e4rt (\u2018punkt-till-punkt\u2019) och multipunktl\u00e4ge, etablera separata tunnlar f\u00f6r olika VLAN, och till\u00e5ta oordnad leverans av paket inom den skyddade kanalen. M\u00f6jligheten att v\u00e4lja mellan olika krypteringsl\u00e4gen (inklusive med eller utan inneh\u00e5llsautentisering) och olika paket\u00f6verf\u00f6ringsl\u00e4gen g\u00f6r det m\u00f6jligt att uppn\u00e5 en balans mellan robusthet och prestanda beroende p\u00e5 aktuella f\u00f6rh\u00e5llanden.<\/p>\n
Det \u00e4r ocks\u00e5 viktigt att st\u00f6dja privata n\u00e4tverk, vars utrustning \u00e4gs av en organisation (eller hyrs av den), och operativa n\u00e4tverk, d\u00e4r olika segment f\u00f6rvaltas av olika f\u00f6retag. Det \u00e4r f\u00f6rdelaktigt om l\u00f6sningen till\u00e5ter hantering b\u00e5de med egna resurser och av en extern organisation (enligt modellen f\u00f6r hanterad tj\u00e4nst). I operativa n\u00e4tverk \u00e4r en annan viktig funktion att st\u00f6dja multitenant-milj\u00f6er (gemensamt utnyttjande av olika kunder) genom kryptografisk isolering av individuella kunder (abonnenter), vars trafik passerar genom samma upps\u00e4ttning krypteringsapparater. Detta kr\u00e4ver vanligtvis anv\u00e4ndning av separata nycklar och certifikat f\u00f6r varje kund.<\/p>\n
Om en enhet k\u00f6ps f\u00f6r ett specifikt scenario, kan alla dessa funktioner vara mindre viktiga \u2013 det \u00e4r bara n\u00f6dv\u00e4ndigt att s\u00e4kerst\u00e4lla att enheten st\u00f6der det som beh\u00f6vs just nu. Men om l\u00f6sningen k\u00f6ps \"f\u00f6r framtiden\", f\u00f6r att ocks\u00e5 st\u00f6dja framtida scenarier, och v\u00e4ljs som \"f\u00f6retagsstandard\", kommer flexibilitet vara en f\u00f6rdel \u2013 s\u00e4rskilt med tanke p\u00e5 begr\u00e4nsningarna f\u00f6r interoperabilitet mellan enheter fr\u00e5n olika leverant\u00f6rer (mer om detta l\u00e4ngre ner).<\/p>\n
Enkelhet och bekv\u00e4mlighet<\/h4>\n \nBekv\u00e4mligheten i underh\u00e5llet \u00e4r ocks\u00e5 ett multifaktoriellt begrepp. Man kan ungef\u00e4r s\u00e4ga att det handlar om den sammanlagda tidskostnaden f\u00f6r specialister med viss kompetens, beh\u00f6vlig f\u00f6r att st\u00f6dja l\u00f6sningen i olika faser av dess livscykel. Om det inte finns n\u00e5gra kostnader och installation, konfiguration och drift \u00e4r helt automatiska, \u00e4r kostnaderna noll och bekv\u00e4mligheten absolut. Sj\u00e4lvklart finns det inget s\u00e5dant i verkligheten. En rimlig approximation \u00e4r modellen \u201enod p\u00e5 kabeln\u201c<\/b> (bump-in-the-wire), eller en transparent anslutning d\u00e4r till\u00e4gg och borttagning av krypteringsenheter inte kr\u00e4ver manuella eller automatiska \u00e4ndringar i n\u00e4tverkskonfigurationen. Detta f\u00f6renklar underh\u00e5llet av l\u00f6sningen: man kan enkelt sl\u00e5 p\u00e5 eller av krypteringsfunktionen, och vid behov bara \"bypassa\" enheten med en n\u00e4tverkskabel (det vill s\u00e4ga direkt ansluta de portar p\u00e5 n\u00e4tverksutrustningen som den var ansluten till). Dock finns det en nackdel \u2013 samma sak kan g\u00f6ras av en angripare. F\u00f6r att implementera principen om \"nod p\u00e5 kabel\" m\u00e5ste man ta h\u00e4nsyn till trafiken inte bara dataskiktet<\/b>och \u00e4ven kontroll- och administrationsskikten<\/b> \u2013 enheterna m\u00e5ste vara transparanta f\u00f6r dem. D\u00e4rf\u00f6r kan s\u00e5dan trafik endast krypteras n\u00e4r det inte finns n\u00e5gra mottagare av dessa typer av trafik i n\u00e4tverket mellan krypteringsenheterna, eftersom om den filtreras eller krypteras kan n\u00e4tverkskonfigurationen \u00e4ndras vid aktivering eller inaktivering av krypteringen. Krypteringsenheten kan ocks\u00e5 vara transparent f\u00f6r signalering p\u00e5 fysisk niv\u00e5. Specifikt, vid signalbortfall m\u00e5ste den vidarebefordra denna f\u00f6rlust (det vill s\u00e4ga st\u00e4nga av sina s\u00e4ndare) bak\u00e5t och fram\u00e5t (\"f\u00f6r sig sj\u00e4lv\") i riktning mot signalen.<\/p>\n
Det \u00e4r ocks\u00e5 viktigt att st\u00f6dja uppdelningen av befogenheter mellan avdelningarna f\u00f6r informationss\u00e4kerhet och IT, s\u00e4rskilt n\u00e4tverksavdelningen. Krypteringsl\u00f6sningen m\u00e5ste st\u00f6dja den till\u00e4mpade \u00e5tkomsthanterings- och revisionsmodellen i organisationen. Behovet av samarbete mellan olika avdelningar f\u00f6r att utf\u00f6ra rutinoperationer b\u00f6r minimeras. D\u00e4rf\u00f6r har specialiserade enheter, som enbart st\u00f6der krypteringsfunktioner och \u00e4r s\u00e5 transparenta som m\u00f6jligt f\u00f6r n\u00e4tverksoperationer, en f\u00f6rdel ur anv\u00e4ndarv\u00e4nlighetssynpunkt. Med andra ord, s\u00e4kerhetspersonalen b\u00f6r inte ha anledning att kontakta \"n\u00e4tverksfolk\" f\u00f6r att \u00e4ndra n\u00e4tverksinst\u00e4llningar. Och \u00e5 sin sida b\u00f6r de inte beh\u00f6va \u00e4ndra krypteringsinst\u00e4llningar vid underh\u00e5ll av n\u00e4tverket.<\/p>\n
En annan faktor \u00e4r hanteringsm\u00f6jligheter och anv\u00e4ndarv\u00e4nlighet. De ska vara tydliga, logiska, m\u00f6jligg\u00f6ra import- och export av inst\u00e4llningar, automatisering och s\u00e5 vidare. Det \u00e4r viktigt att genast uppm\u00e4rksamma vilka alternativ f\u00f6r hantering som \u00e4r tillg\u00e4ngliga (vanligtvis finns det en egen hanteringsmilj\u00f6, webbgr\u00e4nssnitt och kommandorad) och vilken upps\u00e4ttning funktioner som finns i varje (det f\u00f6rekommer begr\u00e4nsningar). En viktig funktion \u00e4r st\u00f6det f\u00f6r out-of-band<\/b> (out-of-band) hantering, det vill s\u00e4ga genom ett dedikerat hanteringsn\u00e4tverk, och in-band<\/b> (in-band) hantering, det vill s\u00e4ga genom det gemensamma n\u00e4tverket d\u00e4r nyttotrafiken \u00f6verf\u00f6rs. Hanteringsverktygen ska signalera alla incidenter, inklusive IT-s\u00e4kerhetsincidenter. Rutinarbeten, upprepade operationer ska utf\u00f6ras automatiskt. Det h\u00e4r g\u00e4ller s\u00e4rskilt hantering av nycklar. Dessa ska genereras\/f\u00f6rdelas automatiskt. St\u00f6d f\u00f6r PKI \u00e4r en stor f\u00f6rdel.<\/p>\nKompatibilitet<\/h4>\n
\nDet vill s\u00e4ga enhetskompatibilitet med n\u00e4tverksstandarder. Detta avser inte bara industristandarder som antagits av auktoritativa organisationer som IEEE utan \u00e4ven f\u00f6retagsprotokoll fr\u00e5n branschledare som Cisco. Det finns tv\u00e5 grundl\u00e4ggande s\u00e4tt att s\u00e4kerst\u00e4lla kompatibilitet: antingen genom genomskinlighet<\/b>, eller genom uttryckligt st\u00f6d<\/b> f\u00f6r protokoll (n\u00e4r krypteringsenheten blir en av noderna i n\u00e4tverket f\u00f6r ett visst protokoll och bearbetar kontrolltrafiken f\u00f6r detta protokoll). Kompatibiliteten med n\u00e4tverken beror p\u00e5 fullst\u00e4ndigheten och korrektheten i genomf\u00f6randet av kontrollprotokollen. St\u00f6d f\u00f6r olika varianter av PHY-niv\u00e5 (hastigheter, \u00f6verf\u00f6ringsmedia, kodningsscheman), Ethernet-ramar av olika format med valfri MTU, samt olika L3-tj\u00e4nsteprotokoll (s\u00e4rskilt familjen TCP\/IP) \u00e4r viktigt.<\/p>\n
Genomskinlighet s\u00e4kerst\u00e4lls genom mekanismer f\u00f6r mutation (temporella f\u00f6r\u00e4ndringar av inneh\u00e5llet i \u00f6ppna huvuden i trafiken mellan krypterare), f\u00f6rbig\u00e5ende (n\u00e4r vissa paket f\u00f6rblir okrypterade) och f\u00f6rdr\u00f6jning av krypteringsstart (n\u00e4r vanligtvis krypterade f\u00e4lt i paket inte krypteras).<\/p>\n
Hur genomskinlighet s\u00e4kerst\u00e4lls<\/i><\/p>\n
Det \u00e4r alltid v\u00e4rt att klarg\u00f6ra hur st\u00f6det f\u00f6r ett visst protokoll s\u00e4kerst\u00e4lls. Ofta \u00e4r st\u00f6det i genomskinligt l\u00e4ge mer bekv\u00e4mt och p\u00e5litligt.<\/p>\n
Interoperabilitet<\/h4>\n \nDet h\u00e4r \u00e4r ocks\u00e5 kompatibilitet, men i en annan mening, n\u00e4mligen m\u00f6jligheten till samarbete med andra modeller av krypteringsenheter, inklusive andra tillverkare. Mycket beror p\u00e5 tillst\u00e5ndet av standardiseringen av krypteringsprotokoll. P\u00e5 L1 finns det helt enkelt inga allm\u00e4nt erk\u00e4nda krypteringsstandarder.<\/p>\n
F\u00f6r kryptering av L2 i Ethernet-n\u00e4t finns standard 802.1ae (MACsec), men den anv\u00e4nder inte slut-till-slut<\/b> (end-to-end), utan mellanport<\/b>, \"hop-by-hop\"-kryptering, och i sin ursprungliga version \u00e4r den ol\u00e4mplig f\u00f6r anv\u00e4ndning i distribuerade n\u00e4tverk, d\u00e4rf\u00f6r har det kommit till egna ut\u00f6kningar som \u00f6vervinner denna begr\u00e4nsning (naturligtvis p\u00e5 bekostnad av interoperabilitet med utrustning fr\u00e5n andra tillverkare). Det \u00e4r sant att st\u00f6d f\u00f6r distribuerade n\u00e4tverk lades till standarden 802.1ae 2018, men st\u00f6d f\u00f6r GOST-krypteringsalgoritmer finns fortfarande inte. D\u00e4rf\u00f6r k\u00e4nnetecknas egna, icke-standardiserade L2-krypteringsprotokoll vanligtvis av h\u00f6gre effektivitet (speciellt l\u00e4gre bandbredds\u00f6verhead) och flexibilitet (m\u00f6jlighet att \u00e4ndra algoritmer och kryptol\u00e4gen).<\/p>\n
P\u00e5 h\u00f6gre niv\u00e5er (L3 och L4) finns erk\u00e4nda standarder, f\u00f6rst och fr\u00e4mst IPsec och TLS, men det \u00e4r inte s\u00e5 enkelt h\u00e4r heller. Fr\u00e5gan \u00e4r att varje av dessa standarder \u00e4r en upps\u00e4ttning protokoll, var och en med olika versioner och obligatoriska eller valfria ut\u00f6kningar. Dessutom f\u00f6redrar vissa tillverkare att till\u00e4mpa sina egna krypteringsprotokoll \u00e4ven p\u00e5 L3\/L4. D\u00e4rf\u00f6r kan man i de flesta fall inte r\u00e4kna med full interoperabilitet, men det \u00e4r viktigt att det \u00e5tminstone finns en viss interaktion mellan olika modeller och generationer fr\u00e5n samma tillverkare.<\/p>\n
P\u00e5litlighet<\/h4>\n \nF\u00f6r att j\u00e4mf\u00f6ra olika l\u00f6sningar kan man anv\u00e4nda antingen det genomsnittliga driftstiden fram till fel eller tillg\u00e4nglighetsgraden. Om dessa siffror saknas (eller om man inte litar p\u00e5 dem) kan man g\u00f6ra en kvalitativ j\u00e4mf\u00f6relse. F\u00f6rdel kommer att ges till enheter med anv\u00e4ndarv\u00e4nlig hantering (mindre risk f\u00f6r konfigurationsfel), till specialiserade krypterare (av samma anledning), samt till l\u00f6sningar med minimal tid f\u00f6r att uppt\u00e4cka och \u00e5tg\u00e4rda fel, inklusive medel f\u00f6r \"hot-swap\" av noder och enheter helt och h\u00e5llet.<\/p>\n
Kostnad<\/h4>\n \nN\u00e4r det g\u00e4ller kostnader \u00e4r det, precis som f\u00f6r de flesta IT-l\u00f6sningar, vettigt att j\u00e4mf\u00f6ra den totala \u00e4gandekostnaden. F\u00f6r att ber\u00e4kna detta beh\u00f6ver man inte uppfinna hjulet p\u00e5 nytt, utan kan anv\u00e4nda en l\u00e4mplig metod (till exempel den fr\u00e5n Gartner) och en kalkylator (som den som redan anv\u00e4nds i organisationen f\u00f6r att ber\u00e4kna TCO). Det \u00e4r sj\u00e4lvklart att den totala \u00e4gandekostnaden f\u00f6r en n\u00e4tverksskyddsl\u00f6sning best\u00e5r av direkta<\/b> kostnader f\u00f6r att k\u00f6pa eller hyra sj\u00e4lva l\u00f6sningen, f\u00f6r infrastrukturen f\u00f6r placering av utrustningen samt kostnader f\u00f6r utbyggnad, administration och support (oavsett om detta g\u00f6rs internt eller som en tj\u00e4nst fr\u00e5n en extern organisation), samt indirekta<\/b> kostnader fr\u00e5n driftstopp (orsakat av f\u00f6rlorad produktivitet hos slutanv\u00e4ndarna). Det finns nog bara en liten detalj. P\u00e5verkan av l\u00f6sningens prestanda kan beaktas p\u00e5 olika s\u00e4tt: antingen som indirekta kostnader orsakade av minskad produktivitet, eller som \"virtuella\" direkta kostnader f\u00f6r ink\u00f6p\/uppgradering och underh\u00e5ll av n\u00e4tverksmedium som kompenserar f\u00f6r den minskade prestandan i n\u00e4tverket till f\u00f6ljd av anv\u00e4ndning av kryptering. I alla fall b\u00f6r de kostnader som \u00e4r sv\u00e5ra att ber\u00e4kna med tillr\u00e4cklig noggrannhet \"uteslutas fr\u00e5n ber\u00e4kningen\": s\u00e5 blir det mer f\u00f6rtroende f\u00f6r det slutgiltiga beloppet. Och som vanligt b\u00f6r man i vilket fall j\u00e4mf\u00f6ra olika enheter baserat p\u00e5 TCO f\u00f6r det specifika anv\u00e4ndningsscenariot \u2013 verkligt eller typiskt.<\/p>\nMotst\u00e5ndskraft<\/h4>\n
\nDen sista egenskapen \u00e4r l\u00f6sningens motst\u00e5ndskraft. I de flesta fall kan motst\u00e5ndskraft endast utv\u00e4rderas kvalitativt genom att j\u00e4mf\u00f6ra olika l\u00f6sningar sinsemellan. Vi m\u00e5ste komma ih\u00e5g att krypteringsanordningar inte bara \u00e4r medel utan ocks\u00e5 objekt som ska skyddas. De kan uts\u00e4ttas f\u00f6r olika hot. P\u00e5 f\u00f6rsta plats finns hot mot konfidentialitet, \u00e5tergivning och modifiering av meddelanden. Dessa hot kan realiseras genom s\u00e5rbarheter i krypteringsalgoritmer eller specifika l\u00e4gen, genom s\u00e5rbarheter i krypteringsprotokoll (inklusive under tolkningen av anslutningar och genereringen\/f\u00f6rdelningen av nycklar). F\u00f6rdel har de l\u00f6sningar som till\u00e5ter byte av krypteringsalgoritm eller v\u00e4xling av krypteringsl\u00e4ge (\u00e5tminstone genom uppgradering av inbyggd programvara), de l\u00f6sningar som tillhandah\u00e5ller s\u00e5 fullst\u00e4ndig kryptering som m\u00f6jligt, d\u00e4r de d\u00f6ljer inte bara anv\u00e4ndardata f\u00f6r angripare, utan ocks\u00e5 adress- och annan st\u00f6dinformation, samt de l\u00f6sningar som inte bara krypterar, utan ocks\u00e5 skyddar meddelanden mot \u00e5tergivning och modifiering. F\u00f6r alla moderna krypteringsalgoritmer, elektroniska signaturer, nyckelgenerering och mer, som fastst\u00e4lls i standarder, kan motst\u00e5ndskraften antas vara densamma (annars kan man bara g\u00e5 vilse i kryptografins sn\u00e5r). M\u00e5ste det n\u00f6dv\u00e4ndigtvis vara GOST-algoritmer? H\u00e4r \u00e4r det enkelt: om till\u00e4mpningsscenariot kr\u00e4ver certifiering fr\u00e5n FSB f\u00f6r SKZI (och i Ryssland \u00e4r det oftast s\u00e5 f\u00f6r de flesta scenarier f\u00f6r n\u00e4tverkskryptering), v\u00e4ljer vi endast mellan certifierade. Om inte, s\u00e5 finns det ingen anledning att utesluta enheter utan certifikat fr\u00e5n \u00f6verv\u00e4gande.<\/p>\n
Ett annat hot \u00e4r hotet om intr\u00e5ng, obeh\u00f6rig \u00e5tkomst till enheter (inklusive genom fysisk \u00e5tkomst utifr\u00e5n och inuti chassit). Hotet kan realiseras genom
Slutligen \u00e4r en annan typ av hot \u2013 fel vid inst\u00e4llning och drift, den m\u00e4nskliga faktorn i sin renaste form. H\u00e4r framtr\u00e4der ytterligare en f\u00f6rdel med specialiserade krypterare framf\u00f6r konvergerande l\u00f6sningar, som ofta \u00e4r riktade mot rutinerade \"n\u00e4tverksproffs\" och kan orsaka problem f\u00f6r \"vanliga\", bredspektrum IT-specialister.<\/p>\n
Sammanfattningsvis<\/h4>\n \nI princip skulle man h\u00e4r kunna f\u00f6resl\u00e5 en slags integrerad indikator f\u00f6r att j\u00e4mf\u00f6ra olika enheter, n\u00e5got i stil med<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\nd\u00e4r p \u2013 \u00e4r vikten av indikatorn och r \u2013 \u00e4r rangordningen av enheten efter denna indikator, d\u00e4r varje av de ovan n\u00e4mnda egenskaperna kan brytas ner i \"atomiska\" indikatorer. En s\u00e5dan formel skulle kunna vara anv\u00e4ndbar, till exempel vid j\u00e4mf\u00f6relse av anbud enligt p\u00e5 f\u00f6rhand \u00f6verenskomna regler. Men man kan ocks\u00e5 n\u00f6ja sig med en enkel tabell som<\/p>\n
Egenskap
Bandbredd
+++<\/p>\n
\u00d6vergripande kostnader
+++<\/p>\n
F\u00f6rdr\u00f6jning
++<\/p>\n
Skalbarhet
+++<\/p>\n
Flexibilitet
+<\/p>\n
Interoperabilitet
+<\/p>\n
Kompatibilitet
+++<\/p>\n
Enkelhet och bekv\u00e4mlighet
++<\/p>\n
Fel-tolerans
++<\/p>\n
Kostnad
+<\/p>\n
Motst\u00e5ndskraft
+++<\/p>\n
\nJag ser fram emot att besvara fr\u00e5gor och konstruktiv kritik.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