Den hÀr översikten (eller, om du vill, en jÀmförelsesguiden) skrev jag nÀr jag fick i uppdrag att jÀmföra flera enheter frÄn olika leverantörer. Dessutom tillhörde dessa enheter olika klasser. Jag var tvungen att sÀtta mig in i arkitekturen och specifikationerna för alla dessa enheter och skapa ett "koordinatsystem" för jÀmförelsen. Jag hoppas att min översikt kan hjÀlpa nÄgon:
- Bli förtrogen med beskrivningarna och specifikationerna för krypteringsenheter
- Att sÀrskilja "pappersegenskaper" frÄn de som verkligen Àr viktiga i verkliga livet
- Att gÄ bortom det vanliga utbudet av leverantörer och inkludera produkter som Àr lÀmpliga för att lösa den givna uppgiften
- Att stÀlla rÀtt frÄgor under förhandlingarna
- Att sammanstÀlla kravspecifikationen (RFP)
- Att förstÄ vilka specifikationer man mÄste kompromissa med om en viss modell av enheten vÀljs
Vad som kan bedömas
Principen Ă€r tillĂ€mplig pĂ„ alla fristĂ„ende (standalone) enheter som Ă€r lĂ€mpliga för att kryptera nĂ€tverkstrafik mellan avlĂ€gsna Ethernet-segment (inter-site-kryptering). Det vill sĂ€ga "lĂ„dor" i ett separat chassi (okej, vi inkluderar ocksĂ„ blades/moduler för chassit hĂ€r), som ansluts via en eller flera Ethernet-portar till det lokala (campus) Ethernet-nĂ€tverket med okrypterad trafik, och via en annan port (portar) â till kanalen/nĂ€tverket genom vilket den krypterade trafiken överförs till andra, avlĂ€gsna segment. En sĂ„dan krypteringslösning kan implementeras i ett privat eller operatörsnĂ€tverk via olika typer av "transport" ("mörk" fiberoptik, frekvensdelningsutrustning, kommuterat Ethernet-nĂ€tverk samt "pseudoleder" som Ă€r dragna genom ett nĂ€tverk med en annan routningsarkitektur, oftast MPLS), med anvĂ€ndning av teknik VPN eller utan den.
NÀtverkskryptering i ett distribuerat Ethernet-nÀtverk
SjĂ€lva enheterna kan antingen vara specialiserade (enbart avsedda för kryptering), eller multifunktionella (hybrida, konvergenta), vilket innebĂ€r att de ocksĂ„ utför andra funktioner (till exempel som brandvĂ€gg eller router). Olika leverantörer klassificerar sina enheter i olika klasser/kategorier, men det spelar ingen roll â det viktiga Ă€r bara att de kan kryptera webbtrafik och vilka egenskaper de har.
Som en pĂ„minnelse vill jag nĂ€mna att "nĂ€tverkskryptering", "trafikkryptering", "krypterare" â Ă€r informella termer, Ă€ven om de ofta anvĂ€nds. I ryska lagtexter (inklusive de som införliva GOST-standarder) kommer du förmodligen inte att stöta pĂ„ dem.
KrypteringsnivÄer och överföringslÀgen
Innan vi gÄr in pÄ beskrivningen av de specifikationer som kommer att anvÀndas för utvÀrdering mÄste vi först förstÄ en viktig sak, nÀmligen "krypteringsnivÄn". Jag har noterat att den ofta nÀmns bÄde i officiella dokument frÄn leverantörer (i beskrivningar, manualer etc.) och i informella diskussioner (under förhandlingar, pÄ trÀningar). AlltsÄ verkar det som om alla vet vad det handlar om, men jag har personligen bevittnat viss förvirring.
SĂ„ vad Ă€r egentligen "krypteringsnivĂ„"? Det Ă€r klart att det handlar om nivĂ„n i den referensmodell för nĂ€tverk OSI/ISO dĂ€r krypteringen sker. LĂ„t oss lĂ€sa GOST R ISO 7498-2â99 "Informations teknologi. SammanlĂ€nkning av öppna system. GrundlĂ€ggande referensmodell. Del 2. Arkitektur för informationsskydd". FrĂ„n detta dokument kan vi förstĂ„ att konfidentialitetsservicenivĂ„n (ett av de mekanismer som sĂ€kerstĂ€lls genom kryptering) Ă€r nivĂ„n av protokollet, datatjĂ€nstblockets (âpayloadâ, anvĂ€ndardata) som krypteras. Som det stĂ„r i standarden kan tjĂ€nsten tillhandahĂ„llas antingen pĂ„ samma nivĂ„, "pĂ„ egen hand", eller med hjĂ€lp av en underliggande nivĂ„ (det Ă€r faktiskt sĂ„ hĂ€r som detta oftast realiseras i MACsec).
I praktiken finns det dock tvÄ överföringslÀgen för krypterad information över nÀtverket (IPsec kommer genast till tankarna, men dessa lÀgen förekommer ocksÄ i andra protokoll). I transportlÀge (ibland kallat native) krypteras endast tjÀnsten datablock, medan rubrikerna förblir "öppna", okrypterade (ibland lÀggs ytterligare fÀlt med information om krypteringsalgoritmen till, medan andra fÀlt modifieras och rÀknas om). I tunnellÀge Àr hela protokoll datablocket (det vill sÀga sjÀlva paketet) krypteras och inkapslas i en servicemanöverblock av samma eller högre nivÄ, det vill sÀga det omges av nya rubriker.
KrypteringsnivÄn i sig, i kombination med nÄgot överföringslÀge, Àr varken bra eller dÄlig, sÄ man kan inte sÀga att L3 i transportlÀge Àr bÀttre Àn L2 i tunnelÀge. De pÄverkar helt enkelt mÄnga egenskaper som bedömer enheter. Till exempel flexibilitet och kompatibilitet. För arbete i nÀtverk L1 (bithastighetsomkoppling), L2 (ramomkoppling) och L3 (paketrouting) i transportlÀge behövs lösningar som krypterar pÄ samma eller högre nivÄ (annars kommer adressinformationen att krypteras, och data nÄr inte sina destinationer), medan tunnelÀge gör det möjligt att övervinna denna begrÀnsning (sjÀlvklart pÄ bekostnad av andra viktiga egenskaper).
Transport- och tunnelkrypteringslÀgen L2
Nu gÄr vi vidare för att analysera egenskaperna.
Performance
För nÀtverkskryptering Àr prestanda ett komplext, mÄngdimensionellt begrepp. Ibland kan en specifik modell övertrÀffa i en prestandakarakteristik men underprestera i en annan. DÀrför Àr det alltid fördelaktigt att ta hÀnsyn till alla aspekter av krypteringsprestanda och deras pÄverkan pÄ nÀtverksprestanda och de tillÀmpningar som anvÀnder den. HÀr kan vi dra en analogi med en bil, dÀr det inte bara Àr den maximala hastigheten som rÀknas, utan Àven tiden för att nÄ "hundra", brÀnsleförbrukningen och sÄ vidare. Prestandakarakteristik tilldelar företag och deras potentiella kunder stor uppmÀrksamhet. Som regel Àr det just prestanda som avgör rangordningen i leverantörernas produktlinjer för krypteringsenheter.
Det Àr tydligt att prestanda beror pÄ bÄde komplexiteten av de nÀtverks- och kryptografiska operationerna som utförs pÄ enheten (inklusive hur vÀl dessa uppgifter kan parallelliseras och pipelinas) samt prestandan hos hÄrdvaran och kvaliteten pÄ den inbyggda programvaran. DÀrför anvÀnds kraftfullare "hÄrdvara" i de Àldre modellerna, och det finns ibland möjlighet att utrusta dem med ytterligare processorer och minnesmoduler. Det finns flera tillvÀgagÄngssÀtt för att implementera kryptografiska funktioner: pÄ en universell centralprocessor (CPU), en specialiserad anpassad integrerad krets (ASIC) eller pÄ en programmerbar logisk integrerad krets (FPGA). Varje tillvÀgagÄngssÀtt har sina för- och nackdelar. Till exempel kan CPU bli en "flaskhals" vid kryptering, sÀrskilt om processorn saknar specialiserade instruktioner för att stödja krypteringsalgoritmen (eller om de inte anvÀnds). Specialiserade kretsar saknar flexibilitet, och att "omprogrammera" dem för att öka prestandan, lÀgga till nya funktioner eller ÄtgÀrda sÄrbarheter Àr inte alltid möjligt. Dessutom blir deras anvÀndning lönsam endast vid stora produktionsvolymer. Det Àr dÀrför den "gyllene medelvÀgen" har blivit sÄ populÀr - anvÀndningen av FPGA. Det Àr faktiskt pÄ FPGA som sÄ kallade kryptohastare Àr gjorda - inbyggda eller externa specialiserade hÄrdvarumoduler för stöd av kryptografiska operationer.
Eftersom vi pratar om nĂ€tverks- kryptering Ă€r det logiskt att mĂ€ta prestandan hos lösningarna i samma enheter som för andra nĂ€tverksenheter â genomströmningskapacitet, procentuell paketförlust (frame loss) och latens. Dessa vĂ€rden definieras i RFC 1242. För övrigt, om varianter av latens (jitter) som ofta nĂ€mns, stĂ„r det inget om detta i denna RFC. Hur mĂ€ter man dessa vĂ€rden? Jag har inte funnit nĂ„gra godkĂ€nda metoder i nĂ„gra standarder (officiella eller inofficiella som RFC) specifikt för nĂ€tverkskryptering. Det skulle vara logiskt att anvĂ€nda en metod för nĂ€tverksenheter, faststĂ€lld i standarden RFC 2544. MĂ„nga leverantörer följer den - mĂ„nga, men inte alla. Till exempel levererar de testtrafik endast i en riktning istĂ€llet för bĂ„da, som rekommenderas i standarden. NĂ„vĂ€l.
MĂ€tning av prestanda för nĂ€tverkskrypteringsenheter har sina egna specifikationer. För det första Ă€r det korrekt att göra alla mĂ€tningar för ett par av enheter: Ă€ven om krypteringsalgoritmerna Ă€r symmetriska, Ă€r det inte nödvĂ€ndigt att fördröjningar och paketförluster vid kryptering och dekryptering Ă€r lika. För det andra Ă€r det meningsfullt att mĂ€ta just delförĂ€ndringen, pĂ„verkan av nĂ€tverkskryptering pĂ„ den slutgiltiga nĂ€tverksproduktiviteten, genom att jĂ€mföra tvĂ„ konfigurationer: utan krypteringsenheter och med dem. Alternativt, i fall med hybridenheter som kombinerar flera funktioner utöver nĂ€tverkskryptering, vid avstĂ€ngt och pĂ„slaget kryptering. Denna pĂ„verkan kan vara olika och bero pĂ„ hur krypteringsenheterna Ă€r kopplade, frĂ„n arbetslĂ€gen och dessutom frĂ„n trafikens karaktĂ€r. MĂ„nga prestandaparametrar beror sĂ€rskilt pĂ„ paketlĂ€ngden, vilket Ă€r anledningen till att man ofta anvĂ€nder grafer som visar beroendet av dessa parametrar frĂ„n paketlĂ€ngden för att jĂ€mföra prestanda av olika lösningar, eller sĂ„ anvĂ€nder man IMIX â trafikfördelning efter paketlĂ€ngd som ungefĂ€r speglar verkligheten. Om vi tar samma grundkonfiguration utan kryptering för vĂ„rt exempel, kan vi jĂ€mföra nĂ€tverkskrypteringslösningar som implementerats pĂ„ olika sĂ€tt utan att gĂ„ in pĂ„ dessa skillnader: L2 med L3,
Kopplingsschema för prestandatestning
Den första egenskapen som uppmĂ€rksammas Ă€r "hastigheten" pĂ„ krypteringsenheten, det vill sĂ€ga bandbredden (bandwidth) för dess nĂ€tverksgrĂ€nssnitt, bitflödeshastigheten. Den bestĂ€ms av de nĂ€tverksstandarder som stöds av grĂ€nssnitten. För Ethernet Ă€r vanliga siffror â 1 Gbit/s och 10 Gbit/s. Men, som vi vet, i vilket nĂ€tverk som helst Ă€r den maximala teoretiska kapaciteten (genomströmning) pĂ„ varje av dess nivĂ„er Ă€r alltid lĂ€gre Ă€n bandbredden: en del av bandbredden "Ă€ts upp" av mellanrum, kontrollhuvuden och sĂ„ vidare. Om en enhet kan ta emot, bearbeta (i vĂ„rt fall kryptera eller dekryptera) och överföra trafik med full hastighet pĂ„ nĂ€tverksgrĂ€nssnittet, det vill sĂ€ga med den maximala teoretiska genomströmningen för den nĂ€tverksmodellen, sĂ„ sĂ€gs det att den fungerar vid linjens hastighet. För att detta ska vara möjligt mĂ„ste enheten inte förlora eller kasta bort paket oavsett deras storlek och hur ofta de kommer. Om krypteringsenheten inte stödjer arbete vid linjens hastighet, anges oftast dess maximala genomströmning i samma gigabit per sekund (ibland med angivande av pakets lĂ€ngd - ju kortare paketen Ă€r, desto lĂ€gre Ă€r oftast genomströmningen). Det Ă€r mycket viktigt att förstĂ„ att den maximala genomströmningen Ă€r den maximala utan förluster (Ă€ven om enheten kan "pumpa" trafik med högre hastighet, men tappar paket under tiden). Dessutom Ă€r det viktigt att notera att vissa leverantörer mĂ€ter den totala genomströmningen mellan alla portpar, sĂ„ dessa siffror sĂ€ger lite om det ifall all krypterad trafik gĂ„r genom en enda port.
Var Àr det sÀrskilt viktigt att fungera vid linjens hastighet (eller, annorlunda uttryckt, utan paketförluster)? I kanaler med hög genomströmning och stora fördröjningar (till exempel satellitkanaler), dÀr man mÄste stÀlla in en stor TCP-fönsterstorlek för att upprÀtthÄlla hög överföringshastighet, och dÀr paketförluster kraftigt minskar nÀtverkets prestanda.
Men inte all bandbredd anvĂ€nds för att överföra nyttiga data. Man mĂ„ste ta hĂ€nsyn till sĂ„ kallade överhettningskostnader (överhead) bandbredd. Detta Ă€r den del av en krypteringsenhets bandbredd (i procent eller byte per paket) som faktiskt gĂ„r förlorad (inte kan anvĂ€ndas för att överföra applikationsdata). Overhead uppstĂ„r frĂ€mst pĂ„ grund av den ökade storleken (utfyllnad, 'padding') av datadelen i krypterade nĂ€tverkspaket (beroende pĂ„ krypteringsalgoritm och dess lĂ€ge). För det andra pĂ„ grund av ökad lĂ€ngd pĂ„ paketens rubriker (tunnellĂ€ge, serviceinsertion av krypteringsprotokoll, integritetsinsertion etc., beroende pĂ„ protokoll och lĂ€ge för chiffer och överföringslĂ€ge) â dessa overheadkostnader Ă€r vanligtvis de mest betydande och det Ă€r de som uppmĂ€rksammas först. För det tredje, pĂ„ grund av fragmentering av paket vid överskridande av max storlek pĂ„ datablokkar (MTU) (om nĂ€tverket kan dela ett paket som överskrider MTU i tvĂ„, duplicera dess rubriker). För det fjĂ€rde, pĂ„ grund av förekomsten av extra service (kontroll) trafik mellan krypteringsenheterna (för nyckelutbyte, tunnelskapande etc.). LĂ„ga overheadkostnader Ă€r viktiga dĂ€r kanalens bandbredd Ă€r begrĂ€nsad. Detta Ă€r sĂ€rskilt tydligt för trafik med smĂ„ paket, sĂ„som rösttrafik â dĂ€r kan overheadkostnader
Bandbredd
Slutligen finns det ocksĂ„ inledd fördröjning â skillnaden (i delar av en sekund) i nĂ€tverksfördröjning (tiden det tar för data att gĂ„ frĂ„n ingĂ„ng till utgĂ„ng i nĂ€tverket) mellan datatransmission utan nĂ€tverkskryptering och med den. Generellt gĂ€ller att ju lĂ€gre fördröjning ("latens") i nĂ€tverket, desto mer kritisk blir den fördröjning som tillförs av krypteringsenheterna. Fördröjningen orsakas bĂ„de av sjĂ€lva krypteringsoperationen (beroende av krypteringsalgoritm, blocklĂ€ngd och lĂ€ge för krypteringen, samt kvaliteten pĂ„ implementationen i programvaran) och av hanteringen av nĂ€tverkspaketet i enheten. Den tillförda fördröjningen beror bĂ„de pĂ„ paketbehandlingslĂ€get (genomströmnings- eller "lagra-och-skicka") och plattformens prestanda ("hĂ„rdvaruimplementation" pĂ„ FPGA eller ASIC Ă€r vanligtvis snabbare Ă€n "programvaru" pĂ„ CPU). L2-kryptering har nĂ€stan alltid en mindre tillförd fördröjning jĂ€mfört med L3- eller L4-kryptering: detta beror pĂ„ att enheter som krypterar pĂ„ L3/L4 ofta implementeras konvergenta. Till exempel har högkapacitetskrypterare för Ethernet, som Ă€r implementerade pĂ„ FPGA och krypterar pĂ„ L2, en negligibel fördröjning pĂ„ grund av krypteringsoperationen â ibland, nĂ€r kryptering aktiveras pĂ„ ett par enheter, minskar den totala fördröjningen de bidrar med! LĂ„g fördröjning Ă€r viktigt dĂ€r den Ă€r jĂ€mförbar med de totala fördröjningarna i kanalen, inklusive signalens spridningsfördröjning, som Ă€r cirka 5 ”s per kilometer. Det vill sĂ€ga att man kan sĂ€ga att för stadsnĂ€t (som Ă€r tiotals kilometer i diameter) kan mikrosekunder göra stor skillnad. Till exempel för synkron replikering av databaser, högfrekvent handel, eller blockchain.
Tillförd fördröjning
Skalbarhet
Stora distribuerade nÀtverk kan omfatta mÄnga tusen noder och nÀtverksenheter samt hundratals segment av lokala nÀtverk. Det Àr viktigt att lösningar för kryptering inte inför ytterligare begrÀnsningar pÄ storlek och topologi för det distribuerade nÀtverket. Detta gÀller framför allt det maximala antalet adresser för noder och nÀtverk. SÄdana begrÀnsningar kan uppstÄ, till exempel, vid implementeringen av en multipunkt-topologi i ett krypterat nÀtverk (med oberoende skyddade anslutningar eller tunnlar) eller selektiv kryptering (till exempel baserat pÄ protokollnummer eller VLAN). Om nÀtverksadresser (MAC, IP, VLAN ID) anvÀnds som nycklar i en tabell som har ett begrÀnsat antal rader, framtrÀder dessa begrÀnsningar hÀr.
Dessutom har stora nĂ€tverk ofta flera strukturella nivĂ„er, inklusive kĂ€rnnĂ€tverk, dĂ€r varje nivĂ„ implementerar sin egen adresseringsschema och routingpolicy. För att implementera en sĂ„dan strategi anvĂ€nds ofta speciella ramformat (som Q-in-Q eller MAC-in-MAC) och routingprotokoll. För att inte hindra uppbyggnaden av sĂ„dana nĂ€tverk mĂ„ste krypteringsenheter korrekt hantera sĂ„dana ramar (det vill sĂ€ga att skalbarhet i det hĂ€r avseendet kommer att innebĂ€ra kompatibilitet â mer om detta nedan).
Flexibilitet
Det handlar om stöd för olika konfigurationer, anslutningsscheman, topologier och mer. Till exempel, för switchade nĂ€tverk baserade pĂ„ Carrier Ethernet-teknologier innebĂ€r detta stöd för olika typer av virtuella anslutningar (E-Line, E-LAN, E-Tree), olika servicenivĂ„er (bĂ„de per portar och per VLAN) och olika transportteknologier (de har redan nĂ€mnts ovan). Det innebĂ€r att enheten ska kunna fungera bĂ„de i linjĂ€rt (âpunkt-till-punktâ) och multipunktlĂ€ge, etablera separata tunnlar för olika VLAN, och tillĂ„ta oordnad leverans av paket inom den skyddade kanalen. Möjligheten att vĂ€lja mellan olika krypteringslĂ€gen (inklusive med eller utan innehĂ„llsautentisering) och olika paketöverföringslĂ€gen gör det möjligt att uppnĂ„ en balans mellan robusthet och prestanda beroende pĂ„ aktuella förhĂ„llanden.
Det Àr ocksÄ viktigt att stödja privata nÀtverk, vars utrustning Àgs av en organisation (eller hyrs av den), och operativa nÀtverk, dÀr olika segment förvaltas av olika företag. Det Àr fördelaktigt om lösningen tillÄter hantering bÄde med egna resurser och av en extern organisation (enligt modellen för hanterad tjÀnst). I operativa nÀtverk Àr en annan viktig funktion att stödja multitenant-miljöer (gemensamt utnyttjande av olika kunder) genom kryptografisk isolering av individuella kunder (abonnenter), vars trafik passerar genom samma uppsÀttning krypteringsapparater. Detta krÀver vanligtvis anvÀndning av separata nycklar och certifikat för varje kund.
Om en enhet köps för ett specifikt scenario, kan alla dessa funktioner vara mindre viktiga â det Ă€r bara nödvĂ€ndigt att sĂ€kerstĂ€lla att enheten stöder det som behövs just nu. Men om lösningen köps "för framtiden", för att ocksĂ„ stödja framtida scenarier, och vĂ€ljs som "företagsstandard", kommer flexibilitet vara en fördel â sĂ€rskilt med tanke pĂ„ begrĂ€nsningarna för interoperabilitet mellan enheter frĂ„n olika leverantörer (mer om detta lĂ€ngre ner).
Enkelhet och bekvÀmlighet
BekvĂ€mligheten i underhĂ„llet Ă€r ocksĂ„ ett multifaktoriellt begrepp. Man kan ungefĂ€r sĂ€ga att det handlar om den sammanlagda tidskostnaden för specialister med viss kompetens, behövlig för att stödja lösningen i olika faser av dess livscykel. Om det inte finns nĂ„gra kostnader och installation, konfiguration och drift Ă€r helt automatiska, Ă€r kostnaderna noll och bekvĂ€mligheten absolut. SjĂ€lvklart finns det inget sĂ„dant i verkligheten. En rimlig approximation Ă€r modellen ânod pĂ„ kabelnâ (bump-in-the-wire), eller en transparent anslutning dĂ€r tillĂ€gg och borttagning av krypteringsenheter inte krĂ€ver manuella eller automatiska Ă€ndringar i nĂ€tverkskonfigurationen. Detta förenklar underhĂ„llet av lösningen: man kan enkelt slĂ„ pĂ„ eller av krypteringsfunktionen, och vid behov bara "bypassa" enheten med en nĂ€tverkskabel (det vill sĂ€ga direkt ansluta de portar pĂ„ nĂ€tverksutrustningen som den var ansluten till). Dock finns det en nackdel â samma sak kan göras av en angripare. För att implementera principen om "nod pĂ„ kabel" mĂ„ste man ta hĂ€nsyn till trafiken inte bara dataskiktetoch Ă€ven kontroll- och administrationsskikten â enheterna mĂ„ste vara transparanta för dem. DĂ€rför kan sĂ„dan trafik endast krypteras nĂ€r det inte finns nĂ„gra mottagare av dessa typer av trafik i nĂ€tverket mellan krypteringsenheterna, eftersom om den filtreras eller krypteras kan nĂ€tverkskonfigurationen Ă€ndras vid aktivering eller inaktivering av krypteringen. Krypteringsenheten kan ocksĂ„ vara transparent för signalering pĂ„ fysisk nivĂ„. Specifikt, vid signalbortfall mĂ„ste den vidarebefordra denna förlust (det vill sĂ€ga stĂ€nga av sina sĂ€ndare) bakĂ„t och framĂ„t ("för sig sjĂ€lv") i riktning mot signalen.
Det Àr ocksÄ viktigt att stödja uppdelningen av befogenheter mellan avdelningarna för informationssÀkerhet och IT, sÀrskilt nÀtverksavdelningen. Krypteringslösningen mÄste stödja den tillÀmpade Ätkomsthanterings- och revisionsmodellen i organisationen. Behovet av samarbete mellan olika avdelningar för att utföra rutinoperationer bör minimeras. DÀrför har specialiserade enheter, som enbart stöder krypteringsfunktioner och Àr sÄ transparenta som möjligt för nÀtverksoperationer, en fördel ur anvÀndarvÀnlighetssynpunkt. Med andra ord, sÀkerhetspersonalen bör inte ha anledning att kontakta "nÀtverksfolk" för att Àndra nÀtverksinstÀllningar. Och Ä sin sida bör de inte behöva Àndra krypteringsinstÀllningar vid underhÄll av nÀtverket.
En annan faktor Àr hanteringsmöjligheter och anvÀndarvÀnlighet. De ska vara tydliga, logiska, möjliggöra import- och export av instÀllningar, automatisering och sÄ vidare. Det Àr viktigt att genast uppmÀrksamma vilka alternativ för hantering som Àr tillgÀngliga (vanligtvis finns det en egen hanteringsmiljö, webbgrÀnssnitt och kommandorad) och vilken uppsÀttning funktioner som finns i varje (det förekommer begrÀnsningar). En viktig funktion Àr stödet för out-of-band (out-of-band) hantering, det vill sÀga genom ett dedikerat hanteringsnÀtverk, och in-band (in-band) hantering, det vill sÀga genom det gemensamma nÀtverket dÀr nyttotrafiken överförs. Hanteringsverktygen ska signalera alla incidenter, inklusive IT-sÀkerhetsincidenter. Rutinarbeten, upprepade operationer ska utföras automatiskt. Det hÀr gÀller sÀrskilt hantering av nycklar. Dessa ska genereras/fördelas automatiskt. Stöd för PKI Àr en stor fördel.
Kompatibilitet
Det vill sÀga enhetskompatibilitet med nÀtverksstandarder. Detta avser inte bara industristandarder som antagits av auktoritativa organisationer som IEEE utan Àven företagsprotokoll frÄn branschledare som Cisco. Det finns tvÄ grundlÀggande sÀtt att sÀkerstÀlla kompatibilitet: antingen genom genomskinlighet, eller genom uttryckligt stöd för protokoll (nÀr krypteringsenheten blir en av noderna i nÀtverket för ett visst protokoll och bearbetar kontrolltrafiken för detta protokoll). Kompatibiliteten med nÀtverken beror pÄ fullstÀndigheten och korrektheten i genomförandet av kontrollprotokollen. Stöd för olika varianter av PHY-nivÄ (hastigheter, överföringsmedia, kodningsscheman), Ethernet-ramar av olika format med valfri MTU, samt olika L3-tjÀnsteprotokoll (sÀrskilt familjen TCP/IP) Àr viktigt.
Genomskinlighet sÀkerstÀlls genom mekanismer för mutation (temporella förÀndringar av innehÄllet i öppna huvuden i trafiken mellan krypterare), förbigÄende (nÀr vissa paket förblir okrypterade) och fördröjning av krypteringsstart (nÀr vanligtvis krypterade fÀlt i paket inte krypteras).
Hur genomskinlighet sÀkerstÀlls
Det Àr alltid vÀrt att klargöra hur stödet för ett visst protokoll sÀkerstÀlls. Ofta Àr stödet i genomskinligt lÀge mer bekvÀmt och pÄlitligt.
Interoperabilitet
Det hÀr Àr ocksÄ kompatibilitet, men i en annan mening, nÀmligen möjligheten till samarbete med andra modeller av krypteringsenheter, inklusive andra tillverkare. Mycket beror pÄ tillstÄndet av standardiseringen av krypteringsprotokoll. PÄ L1 finns det helt enkelt inga allmÀnt erkÀnda krypteringsstandarder.
För kryptering av L2 i Ethernet-nÀt finns standard 802.1ae (MACsec), men den anvÀnder inte slut-till-slut (end-to-end), utan mellanport, "hop-by-hop"-kryptering, och i sin ursprungliga version Àr den olÀmplig för anvÀndning i distribuerade nÀtverk, dÀrför har det kommit till egna utökningar som övervinner denna begrÀnsning (naturligtvis pÄ bekostnad av interoperabilitet med utrustning frÄn andra tillverkare). Det Àr sant att stöd för distribuerade nÀtverk lades till standarden 802.1ae 2018, men stöd för GOST-krypteringsalgoritmer finns fortfarande inte. DÀrför kÀnnetecknas egna, icke-standardiserade L2-krypteringsprotokoll vanligtvis av högre effektivitet (speciellt lÀgre bandbreddsöverhead) och flexibilitet (möjlighet att Àndra algoritmer och kryptolÀgen).
PÄ högre nivÄer (L3 och L4) finns erkÀnda standarder, först och frÀmst IPsec och TLS, men det Àr inte sÄ enkelt hÀr heller. FrÄgan Àr att varje av dessa standarder Àr en uppsÀttning protokoll, var och en med olika versioner och obligatoriska eller valfria utökningar. Dessutom föredrar vissa tillverkare att tillÀmpa sina egna krypteringsprotokoll Àven pÄ L3/L4. DÀrför kan man i de flesta fall inte rÀkna med full interoperabilitet, men det Àr viktigt att det Ätminstone finns en viss interaktion mellan olika modeller och generationer frÄn samma tillverkare.
PĂ„litlighet
För att jÀmföra olika lösningar kan man anvÀnda antingen det genomsnittliga driftstiden fram till fel eller tillgÀnglighetsgraden. Om dessa siffror saknas (eller om man inte litar pÄ dem) kan man göra en kvalitativ jÀmförelse. Fördel kommer att ges till enheter med anvÀndarvÀnlig hantering (mindre risk för konfigurationsfel), till specialiserade krypterare (av samma anledning), samt till lösningar med minimal tid för att upptÀcka och ÄtgÀrda fel, inklusive medel för "hot-swap" av noder och enheter helt och hÄllet.
Kostnad
NĂ€r det gĂ€ller kostnader Ă€r det, precis som för de flesta IT-lösningar, vettigt att jĂ€mföra den totala Ă€gandekostnaden. För att berĂ€kna detta behöver man inte uppfinna hjulet pĂ„ nytt, utan kan anvĂ€nda en lĂ€mplig metod (till exempel den frĂ„n Gartner) och en kalkylator (som den som redan anvĂ€nds i organisationen för att berĂ€kna TCO). Det Ă€r sjĂ€lvklart att den totala Ă€gandekostnaden för en nĂ€tverksskyddslösning bestĂ„r av direkta kostnader för att köpa eller hyra sjĂ€lva lösningen, för infrastrukturen för placering av utrustningen samt kostnader för utbyggnad, administration och support (oavsett om detta görs internt eller som en tjĂ€nst frĂ„n en extern organisation), samt indirekta kostnader frĂ„n driftstopp (orsakat av förlorad produktivitet hos slutanvĂ€ndarna). Det finns nog bara en liten detalj. PĂ„verkan av lösningens prestanda kan beaktas pĂ„ olika sĂ€tt: antingen som indirekta kostnader orsakade av minskad produktivitet, eller som "virtuella" direkta kostnader för inköp/uppgradering och underhĂ„ll av nĂ€tverksmedium som kompenserar för den minskade prestandan i nĂ€tverket till följd av anvĂ€ndning av kryptering. I alla fall bör de kostnader som Ă€r svĂ„ra att berĂ€kna med tillrĂ€cklig noggrannhet "uteslutas frĂ„n berĂ€kningen": sĂ„ blir det mer förtroende för det slutgiltiga beloppet. Och som vanligt bör man i vilket fall jĂ€mföra olika enheter baserat pĂ„ TCO för det specifika anvĂ€ndningsscenariot â verkligt eller typiskt.
MotstÄndskraft
Den sista egenskapen Àr lösningens motstÄndskraft. I de flesta fall kan motstÄndskraft endast utvÀrderas kvalitativt genom att jÀmföra olika lösningar sinsemellan. Vi mÄste komma ihÄg att krypteringsanordningar inte bara Àr medel utan ocksÄ objekt som ska skyddas. De kan utsÀttas för olika hot. PÄ första plats finns hot mot konfidentialitet, Ätergivning och modifiering av meddelanden. Dessa hot kan realiseras genom sÄrbarheter i krypteringsalgoritmer eller specifika lÀgen, genom sÄrbarheter i krypteringsprotokoll (inklusive under tolkningen av anslutningar och genereringen/fördelningen av nycklar). Fördel har de lösningar som tillÄter byte av krypteringsalgoritm eller vÀxling av krypteringslÀge (Ätminstone genom uppgradering av inbyggd programvara), de lösningar som tillhandahÄller sÄ fullstÀndig kryptering som möjligt, dÀr de döljer inte bara anvÀndardata för angripare, utan ocksÄ adress- och annan stödinformation, samt de lösningar som inte bara krypterar, utan ocksÄ skyddar meddelanden mot Ätergivning och modifiering. För alla moderna krypteringsalgoritmer, elektroniska signaturer, nyckelgenerering och mer, som faststÀlls i standarder, kan motstÄndskraften antas vara densamma (annars kan man bara gÄ vilse i kryptografins snÄr). MÄste det nödvÀndigtvis vara GOST-algoritmer? HÀr Àr det enkelt: om tillÀmpningsscenariot krÀver certifiering frÄn FSB för SKZI (och i Ryssland Àr det oftast sÄ för de flesta scenarier för nÀtverkskryptering), vÀljer vi endast mellan certifierade. Om inte, sÄ finns det ingen anledning att utesluta enheter utan certifikat frÄn övervÀgande.
Ett annat hot Àr hotet om intrÄng, obehörig Ätkomst till enheter (inklusive genom fysisk Ätkomst utifrÄn och inuti chassit). Hotet kan realiseras genom
SĂ„rbarheter i implementering â i hĂ„rdvaran och i koden. DĂ€rför kommer lösningar med minimal "angreppsyta" genom nĂ€tverket, med skyddade höljen mot fysisk Ă„tkomst (med larm vid öppning, skydd mot avlyssning och automatisk Ă„terstĂ€llning av nyckelinformation vid öppning av höljet), samt de som tillĂ„ter uppdatering av firmware nĂ€r en sĂ„rbarhet i koden blir kĂ€nd, att ha en fördel. Det finns ocksĂ„ en annan vĂ€g: om alla jĂ€mförda enheter har certifikat frĂ„n FSB, kan man betrakta klassen SKZI enligt vilken certifikatet utfĂ€rdades som en indikator pĂ„ intrĂ„ngsskydd.
Slutligen Ă€r en annan typ av hot â fel vid instĂ€llning och drift, den mĂ€nskliga faktorn i sin renaste form. HĂ€r framtrĂ€der ytterligare en fördel med specialiserade krypterare framför konvergerande lösningar, som ofta Ă€r riktade mot rutinerade "nĂ€tverksproffs" och kan orsaka problem för "vanliga", bredspektrum IT-specialister.
Sammanfattningsvis
I princip skulle man hÀr kunna föreslÄ en slags integrerad indikator för att jÀmföra olika enheter, nÄgot i stil med
$$display$$K_j=âp_i r_{ij}$$display$$
dĂ€r p â Ă€r vikten av indikatorn och r â Ă€r rangordningen av enheten efter denna indikator, dĂ€r varje av de ovan nĂ€mnda egenskaperna kan brytas ner i "atomiska" indikatorer. En sĂ„dan formel skulle kunna vara anvĂ€ndbar, till exempel vid jĂ€mförelse av anbud enligt pĂ„ förhand överenskomna regler. Men man kan ocksĂ„ nöja sig med en enkel tabell som
Egenskap
Enhet 1
Enhet 2
âŠ
Enhet N
Bandbredd
+
+
+++
Ăvergripande kostnader
+
++
+++
Fördröjning
+
+
++
Skalbarhet
+++
+
+++
Flexibilitet
+++
++
+
Interoperabilitet
++
+
+
Kompatibilitet
++
++
+++
Enkelhet och bekvÀmlighet
+
+
++
Fel-tolerans
+++
+++
++
Kostnad
++
+++
+
MotstÄndskraft
++
++
+++
Jag ser fram emot att besvara frÄgor och konstruktiv kritik.
KĂ€lla: habr.com
