Jeg skrev denne anmeldelsen (eller, hvis du foretrekker det, en sammenligningsguide) da jeg fikk i oppgave å sammenligne flere enheter fra forskjellige leverandører. I tillegg tilhørte disse enhetene forskjellige klasser. Jeg måtte forstå arkitekturen og egenskapene til alle disse enhetene og lage et "koordinatsystem" for sammenligning. Jeg blir glad hvis anmeldelsen min hjelper noen:
- Forstå beskrivelsene og spesifikasjonene til krypteringsenheter
- Skille "papir" egenskaper fra de som er virkelig viktige i det virkelige liv
- Gå utover det vanlige settet med leverandører og ta med i betraktning alle produkter som er egnet for å løse problemet
- Still de riktige spørsmålene under forhandlinger
- Utarbeide anbudskrav (RFP)
- Forstå hvilke egenskaper som må ofres hvis en bestemt enhetsmodell velges
Hva kan vurderes
I prinsippet er tilnærmingen anvendelig for alle frittstående enheter som er egnet for kryptering av nettverkstrafikk mellom eksterne Ethernet-segmenter (kryptering på tvers av nettsteder). Det vil si «bokser» i en egen sak (ok, vi tar også med blader/moduler for chassiset her), som kobles via en eller flere Ethernet-porter til det lokale (campus) Ethernet-nettverket med ukryptert trafikk, og gjennom en annen port(er) til kanal/nettverk som allerede kryptert trafikk blir overført til andre, eksterne segmenter. En slik krypteringsløsning kan distribueres i et privat eller operatørnettverk gjennom forskjellige typer "transport" (mørk fiber, frekvensdelingsutstyr, svitsjet Ethernet, samt "pseudowires" lagt gjennom et nettverk med en annen rutingarkitektur, oftest MPLS ), med eller uten VPN-teknologi.
Nettverkskryptering i et distribuert Ethernet-nettverk
Selve enhetene kan være enten spesialisert (eksklusive ment for kryptering), eller multifunksjonell (hybrid, konvergent), det vil si også utføre andre funksjoner (for eksempel en brannmur eller ruter). Ulike leverandører klassifiserer enhetene sine i ulike klasser/kategorier, men dette spiller ingen rolle – det eneste viktige er om de kan kryptere trafikk på tvers av nettsteder, og hvilke egenskaper de har.
Bare i tilfelle minner jeg deg på at "nettverkskryptering", "trafikkkryptering", "kryptering" er uformelle termer, selv om de ofte brukes. Du vil sannsynligvis ikke finne dem i russiske forskrifter (inkludert de som introduserer GOST-er).
Krypteringsnivåer og overføringsmoduser
Før vi begynner å beskrive selve egenskapene som skal brukes til evaluering, må vi først forstå en viktig ting, nemlig "krypteringsnivået". Jeg la merke til at det ofte blir nevnt både i offisielle leverandørdokumenter (i beskrivelser, manualer osv.) og i uformelle diskusjoner (ved forhandlinger, opplæring). Det vil si at alle ser ut til å vite veldig godt hva vi snakker om, men jeg var personlig vitne til litt forvirring.
Så hva er et "krypteringsnivå"? Det er tydelig at vi snakker om nummeret på OSI/ISO-referansenettverksmodelllaget der kryptering skjer. Vi leser GOST R ISO 7498-2–99 “Informasjonsteknologi. Sammenkobling av åpne systemer. Grunnleggende referansemodell. Del 2. Informasjonssikkerhetsarkitektur." Fra dette dokumentet kan det forstås at nivået på konfidensialitetstjenesten (en av mekanismene for å gi som er kryptering) er nivået på protokollen, hvis tjenestedatablokk ("nyttelast", brukerdata) er kryptert. Som det også er skrevet i standarden, kan tjenesten leveres både på samme nivå, "på egen hånd", og ved hjelp av et lavere nivå (slik er det for eksempel oftest implementert i MACsec) .
I praksis er to moduser for overføring av kryptert informasjon over et nettverk mulig (IPsec kommer umiddelbart til tankene, men de samme modusene finnes også i andre protokoller). I transportere (noen ganger også kalt native)-modus er kun kryptert service blokk med data, og overskriftene forblir "åpne", ukrypterte (noen ganger legges tilleggsfelt med tjenesteinformasjon for krypteringsalgoritmen til, og andre felt endres og beregnes på nytt). I tunnel samme modus alle protokoll datablokken (det vil si selve pakken) er kryptert og innkapslet i en tjenestedatablokk på samme eller høyere nivå, det vil si at den er omgitt av nye overskrifter.
Selve krypteringsnivået i kombinasjon med en eller annen overføringsmodus er verken bra eller dårlig, så det kan for eksempel ikke sies at L3 i transportmodus er bedre enn L2 i tunnelmodus. Det er bare at mange av egenskapene som enheter evalueres av avhenger av dem. For eksempel fleksibilitet og kompatibilitet. For å jobbe i et nettverk L1 (bitstrømrelé), L2 (rammesvitsjing) og L3 (pakkerouting) i transportmodus trenger du løsninger som krypterer på samme eller høyere nivå (ellers vil adresseinformasjonen krypteres og dataene vil ikke når den tiltenkte destinasjonen), og tunnelmodusen overvinner denne begrensningen (selv om den ofrer andre viktige egenskaper).
Transport- og tunnel L2-krypteringsmoduser
La oss nå gå videre til å analysere egenskapene.
Производительность
For nettverkskryptering er ytelse et komplekst, flerdimensjonalt konsept. Det hender at en viss modell, selv om den er overlegen i en ytelseskarakteristikk, er dårligere i en annen. Derfor er det alltid nyttig å vurdere alle komponentene i krypteringsytelsen og deres innvirkning på ytelsen til nettverket og applikasjonene som bruker det. Her kan vi tegne en analogi med en bil, der ikke bare maksimal hastighet er viktig, men også akselerasjonstid til "hundrevis", drivstofforbruk og så videre. Leverandørselskaper og deres potensielle kunder legger stor vekt på ytelsesegenskaper. Som regel rangeres krypteringsenheter basert på ytelse i leverandørlinjer.
Det er klart at ytelsen avhenger både av kompleksiteten til nettverks- og kryptografiske operasjoner som utføres på enheten (inkludert hvor godt disse oppgavene kan parallelliseres og overføres), så vel som av ytelsen til maskinvaren og kvaliteten på fastvaren. Derfor bruker eldre modeller mer produktiv maskinvare; noen ganger er det mulig å utstyre den med ekstra prosessorer og minnemoduler. Det er flere tilnærminger til å implementere kryptografiske funksjoner: på en generell sentral prosesseringsenhet (CPU), applikasjonsspesifikk integrert krets (ASIC) eller feltprogrammerbar logisk integrert krets (FPGA). Hver tilnærming har sine fordeler og ulemper. For eksempel kan CPU-en bli en krypteringsflaskehals, spesielt hvis prosessoren ikke har spesialiserte instruksjoner for å støtte krypteringsalgoritmen (eller hvis de ikke brukes). Spesialiserte brikker mangler fleksibilitet; det er ikke alltid mulig å "reflash" dem for å forbedre ytelsen, legge til nye funksjoner eller eliminere sårbarheter. I tillegg blir bruken lønnsom bare med store produksjonsvolumer. Det er derfor den "gyldne middelvei" har blitt så populær - bruken av FPGA (FPGA på russisk). Det er på FPGAer at de såkalte kryptoakseleratorene lages - innebygde eller plug-in spesialiserte maskinvaremoduler for å støtte kryptografiske operasjoner.
Siden vi snakker om Nettverk kryptering er det logisk at ytelsen til løsninger skal måles i samme mengder som for andre nettverksenheter - gjennomstrømning, prosentandel av rammetap og latens. Disse verdiene er definert i RFC 1242. Det er forresten ikke skrevet noe om den ofte nevnte forsinkelsesvariasjonen (jitter) i denne RFC. Hvordan måle disse mengdene? Jeg har ikke funnet en metodikk godkjent i noen standarder (offisielle eller uoffisielle som RFC) spesielt for nettverkskryptering. Det ville være logisk å bruke metodikken for nettverksenheter som er nedfelt i RFC 2544-standarden. Mange leverandører følger den – mange, men ikke alle. For eksempel sender de testtrafikk i bare én retning i stedet for begge, som anbefales standard. Uansett.
Måling av ytelsen til nettverkskrypteringsenheter har fortsatt sine egne egenskaper. For det første er det riktig å utføre alle målinger for et par enheter: selv om krypteringsalgoritmene er symmetriske, vil forsinkelser og pakketap under kryptering og dekryptering ikke nødvendigvis være like. For det andre er det fornuftig å måle deltaet, virkningen av nettverkskryptering på den endelige nettverksytelsen, ved å sammenligne to konfigurasjoner: uten krypteringsenheter og med dem. Eller som tilfellet er med hybridenheter, som kombinerer flere funksjoner i tillegg til nettverkskryptering, med kryptering skrudd av og på. Denne påvirkningen kan være forskjellig og avhenge av tilkoblingsskjemaet til krypteringsenhetene, på driftsmodusene og til slutt, av typen trafikk. Spesielt avhenger mange ytelsesparametere av lengden på pakkene, og det er derfor, for å sammenligne ytelsen til forskjellige løsninger, ofte grafer av disse parameterne avhengig av lengden på pakkene brukes, eller IMIX brukes - distribusjonen av trafikk etter pakke lengder, som omtrent gjenspeiler den virkelige. Hvis vi sammenligner den samme grunnleggende konfigurasjonen uten kryptering, kan vi sammenligne nettverkskrypteringsløsninger implementert annerledes uten å komme inn på disse forskjellene: L2 med L3, store-and-forward ) med cut-through, spesialisert med konvergent, GOST med AES og så videre.
Tilkoblingsskjema for ytelsestesting
Den første egenskapen folk legger merke til er "hastigheten" til krypteringsenheten, det vil si båndbredde (båndbredde) til nettverksgrensesnittene, bitstrømningshastighet. Det bestemmes av nettverksstandardene som støttes av grensesnittene. For Ethernet er de vanlige tallene 1 Gbps og 10 Gbps. Men, som vi vet, i ethvert nettverk den maksimale teoretiske gjennomstrømning (gjennomstrømning) på hvert av nivåene er det alltid mindre båndbredde: en del av båndbredden "spises opp" av interframe-intervaller, serviceoverskrifter og så videre. Hvis en enhet er i stand til å motta, behandle (i vårt tilfelle, kryptere eller dekryptere) og overføre trafikk med full hastighet til nettverksgrensesnittet, det vil si med maksimal teoretisk gjennomstrømning for dette nivået av nettverksmodellen, så sies det å jobbe ved linjehastighet. For å gjøre dette er det nødvendig at enheten ikke mister eller forkaster pakker uansett størrelse og frekvens. Hvis krypteringsenheten ikke støtter drift ved linjehastighet, er dens maksimale gjennomstrømning vanligvis spesifisert i samme gigabit per sekund (noen ganger indikerer lengden på pakkene - jo kortere pakkene er, jo lavere er gjennomstrømningen vanligvis). Det er veldig viktig å forstå at maksimal gjennomstrømning er maksimal ingen tap (selv om enheten kan "pumpe" trafikk gjennom seg selv i høyere hastighet, men samtidig miste noen pakker). Vær også oppmerksom på at noen leverandører måler den totale gjennomstrømningen mellom alle portpar, så disse tallene betyr ikke mye hvis all kryptert trafikk går gjennom en enkelt port.
Hvor er det spesielt viktig å operere med linjehastighet (eller med andre ord uten pakketap)? I koblinger med høy båndbredde og høy latens (som satellitt), der en stor TCP-vindustørrelse må stilles inn for å opprettholde høye overføringshastigheter, og hvor pakketap reduserer nettverksytelsen dramatisk.
Men ikke all båndbredden brukes til å overføre nyttige data. Vi må regne med den såkalte driftskostnader (overhead) båndbredde. Dette er den delen av krypteringsenhetens gjennomstrømning (som en prosentandel eller byte per pakke) som faktisk er bortkastet (kan ikke brukes til å overføre applikasjonsdata). Overheadkostnader oppstår for det første på grunn av en økning i størrelsen (tillegg, "stuffing") av datafeltet i krypterte nettverkspakker (avhengig av krypteringsalgoritmen og dens driftsmodus). For det andre, på grunn av økningen i lengden på pakkehoder (tunnelmodus, tjenesteinnsetting av krypteringsprotokollen, simuleringsinnsetting, etc. avhengig av protokollen og driftsmåten for chiffer- og overføringsmodusen) - vanligvis er disse overheadkostnadene mest betydningsfulle, og de tar hensyn først. For det tredje, på grunn av fragmentering av pakker når den maksimale dataenhetsstørrelsen (MTU) overskrides (hvis nettverket er i stand til å dele en pakke som overskrider MTUen i to, ved å duplisere overskriftene). For det fjerde, på grunn av utseendet til ekstra tjeneste (kontroll) trafikk på nettverket mellom krypteringsenheter (for nøkkelutveksling, tunnelinstallasjon, etc.). Lav overhead er viktig der kanalkapasiteten er begrenset. Dette er spesielt tydelig i trafikk fra små pakker, for eksempel tale – der overheadkostnader kan «spise opp» mer enn halvparten av kanalhastigheten!
båndbredde
Endelig er det mer innført forsinkelse – forskjellen (i brøkdeler av et sekund) i nettverksforsinkelse (tiden det tar før data går fra det kommer inn i nettverket til det går ut) mellom dataoverføring uten og med nettverkskryptering. Generelt sett, jo lavere latens ("latens") til nettverket, desto mer kritisk blir ventetiden introdusert av krypteringsenheter. Forsinkelsen introduseres av selve krypteringsoperasjonen (avhengig av krypteringsalgoritmen, blokklengden og driftsmåten til chifferen, samt kvaliteten på implementeringen i programvaren), og behandlingen av nettverkspakken i enheten . Den introduserte latensen avhenger av både pakkebehandlingsmodus (pass-through eller store-and-forward) og ytelsen til plattformen (maskinvareimplementering på en FPGA eller ASIC er generelt raskere enn programvareimplementering på en CPU). L2-kryptering har nesten alltid lavere ventetid enn L3- eller L4-kryptering, på grunn av det faktum at L3/L4-krypteringsenheter ofte er konvergerte. For eksempel, med høyhastighets Ethernet-krypteringer implementert på FPGA-er og kryptering på L2, er forsinkelsen på grunn av krypteringsoperasjonen forsvinnende liten - noen ganger når kryptering er aktivert på et par enheter, reduseres til og med den totale forsinkelsen som de introduserer! Lav latens er viktig der den kan sammenlignes med generelle kanalforsinkelser, inkludert forplantningsforsinkelse, som er omtrent 5 μs per kilometer. Det vil si at vi kan si at for nettverk i byskala (ti titalls kilometer på tvers) kan mikrosekunder avgjøre mye. For eksempel, for synkron databasereplikering, høyfrekvent handel, samme blokkjede.
Innført forsinkelse
Skalerbarhet
Store distribuerte nettverk kan omfatte mange tusen noder og nettverksenheter, hundrevis av lokale nettverkssegmenter. Det er viktig at krypteringsløsninger ikke legger ytterligere begrensninger på størrelsen og topologien til det distribuerte nettverket. Dette gjelder først og fremst maksimalt antall verts- og nettverksadresser. Slike begrensninger kan oppstå, for eksempel når du implementerer en flerpunktskryptert nettverkstopologi (med uavhengige sikre tilkoblinger eller tunneler) eller selektiv kryptering (for eksempel etter protokollnummer eller VLAN). Hvis i dette tilfellet nettverksadresser (MAC, IP, VLAN ID) brukes som nøkler i en tabell der antall rader er begrenset, vises disse begrensningene her.
I tillegg har store nettverk ofte flere strukturelle lag, inkludert kjernenettverket, som hvert implementerer sitt eget adresseringsskjema og sin egen rutingpolicy. For å implementere denne tilnærmingen brukes ofte spesielle rammeformater (som Q-in-Q eller MAC-in-MAC) og rutebestemmelsesprotokoller. For ikke å hindre konstruksjonen av slike nettverk, må krypteringsenheter håndtere slike rammer på riktig måte (det vil si i denne forstand vil skalerbarhet bety kompatibilitet - mer om det nedenfor).
Fleksibilitet
Her snakker vi om å støtte ulike konfigurasjoner, tilkoblingsskjemaer, topologier og andre ting. For eksempel, for svitsjede nettverk basert på Carrier Ethernet-teknologier, betyr dette støtte for forskjellige typer virtuelle tilkoblinger (E-Line, E-LAN, E-Tree), forskjellige typer tjenester (både ved port og VLAN) og forskjellige transportteknologier (de er allerede oppført ovenfor). Det vil si at enheten må kunne operere i både lineær ("punkt-til-punkt") og flerpunktsmodus, etablere separate tunneler for forskjellige VLAN-er og tillate levering av pakker i en sikker kanal. Muligheten til å velge forskjellige chiffermoduser (inkludert med eller uten innholdsautentisering) og forskjellige pakkeoverføringsmoduser lar deg finne en balanse mellom styrke og ytelse avhengig av gjeldende forhold.
Det er også viktig å støtte både private nettverk, hvis utstyr eies av én organisasjon (eller leies ut til den), og operatørnettverk, hvor ulike segmenter administreres av ulike selskaper. Det er bra hvis løsningen tillater administrasjon både internt og av en tredjepart (ved hjelp av en administrert tjenestemodell). I operatørnettverk er en annen viktig funksjon støtte for multi-tenancy (deling av ulike kunder) i form av kryptografisk isolering av individuelle kunder (abonnenter) hvis trafikk går gjennom samme sett med krypteringsenheter. Dette krever vanligvis bruk av separate sett med nøkler og sertifikater for hver kunde.
Hvis en enhet er kjøpt for et spesifikt scenario, kan det hende at alle disse funksjonene ikke er veldig viktige - du må bare sørge for at enheten støtter det du trenger nå. Men hvis en løsning kjøpes "for vekst", for å støtte fremtidige scenarier også, og velges som en "bedriftsstandard", vil fleksibilitet ikke være overflødig - spesielt tatt i betraktning restriksjonene på interoperabiliteten til enheter fra forskjellige leverandører ( mer om dette nedenfor).
Enkelhet og bekvemmelighet
Brukervennlighet er også et multifaktorielt konsept. Omtrent kan vi si at dette er den totale tiden brukt av spesialister med en viss kvalifikasjon som kreves for å støtte en løsning på forskjellige stadier av livssyklusen. Hvis det ikke er noen kostnader, og installasjon, konfigurasjon og drift er helt automatisk, er kostnadene null og bekvemmeligheten er absolutt. Dette skjer selvfølgelig ikke i den virkelige verden. En rimelig tilnærming er en modell "knute på en ledning" (bump-in-the-wire), eller transparent tilkobling, der det å legge til og deaktivere krypteringsenheter ikke krever noen manuelle eller automatiske endringer i nettverkskonfigurasjonen. Samtidig er vedlikehold av løsningen forenklet: du kan trygt slå krypteringsfunksjonen av og på, og om nødvendig ganske enkelt "omgå" enheten med en nettverkskabel (det vil si direkte koble de portene til nettverksutstyret som den var tilkoblet). Riktignok er det en ulempe - en angriper kan gjøre det samme. For å implementere "node på en ledning"-prinsippet, er det nødvendig å ta hensyn til ikke bare trafikk datalagetMen kontroll- og styringslag – enheter må være transparente for dem. Derfor kan slik trafikk bare krypteres når det ikke er mottakere av denne typen trafikk i nettverket mellom krypteringsenhetene, siden hvis den blir forkastet eller kryptert, så kan nettverkskonfigurasjonen endres når du aktiverer eller deaktiverer kryptering. Krypteringsenheten kan også være gjennomsiktig for fysisk lagsignalering. Spesielt når et signal går tapt, må det overføre dette tapet (det vil si slå av senderne) frem og tilbake ("for seg selv") i retning av signalet.
Støtte i myndighetsdeling mellom informasjonssikkerhets- og IT-avdelingen, spesielt nettverksavdelingen, er også viktig. Krypteringsløsningen skal støtte organisasjonens tilgangskontroll- og revisjonsmodell. Behovet for samhandling mellom ulike avdelinger for å utføre rutineoperasjoner bør minimeres. Derfor er det en fordel i form av bekvemmelighet for spesialiserte enheter som utelukkende støtter krypteringsfunksjoner og er så transparente som mulig for nettverksoperasjoner. Enkelt sagt, ansatte i informasjonssikkerhet skal ikke ha noen grunn til å kontakte "nettverksspesialister" for å endre nettverksinnstillinger. Og de skal på sin side ikke ha behov for å endre krypteringsinnstillinger når de vedlikeholder nettverket.
En annen faktor er funksjonene og bekvemmeligheten til kontrollene. De skal være visuelle, logiske, gi import/eksport av innstillinger, automatisering og så videre. Du bør umiddelbart være oppmerksom på hvilke administrasjonsalternativer som er tilgjengelige (vanligvis deres eget administrasjonsmiljø, webgrensesnitt og kommandolinje) og hvilket sett med funksjoner hver av dem har (det er begrensninger). En viktig funksjon er støtte utenfor bandet (out-of-band) kontroll, det vil si gjennom et dedikert kontrollnettverk, og i bandet (in-band) kontroll, det vil si gjennom et felles nettverk som nyttig trafikk overføres gjennom. Styringsverktøy skal signalisere alle unormale situasjoner, inkludert informasjonssikkerhetshendelser. Rutinemessige, repeterende operasjoner bør utføres automatisk. Dette gjelder først og fremst nøkkelledelse. De skal genereres/distribueres automatisk. PKI-støtte er et stort pluss.
Kompatibilitet
Det vil si enhetens kompatibilitet med nettverksstandarder. Dessuten betyr dette ikke bare industrielle standarder vedtatt av autoritative organisasjoner som IEEE, men også proprietære protokoller fra industriledere, som Cisco. Det er to hovedmåter å sikre kompatibilitet: enten gjennom gjennomsiktighet, eller gjennom eksplisitt støtte protokoller (når en krypteringsenhet blir en av nettverksnodene for en bestemt protokoll og behandler kontrolltrafikken til denne protokollen). Kompatibilitet med nettverk avhenger av fullstendigheten og riktigheten av implementeringen av kontrollprotokoller. Det er viktig å støtte ulike alternativer for PHY-nivået (hastighet, overføringsmedium, kodeskjema), Ethernet-rammer i forskjellige formater med en hvilken som helst MTU, forskjellige L3-tjenesteprotokoller (primært TCP/IP-familien).
Åpenhet sikres gjennom mekanismene for mutasjon (midlertidig endring av innholdet i åpne overskrifter i trafikk mellom krypteringer), hopping (når individuelle pakker forblir ukrypterte) og innrykk av begynnelsen av kryptering (når normalt krypterte felt med pakker ikke er kryptert).
Hvordan åpenhet sikres
Sjekk derfor alltid nøyaktig hvordan støtte for en bestemt protokoll tilbys. Ofte er støtte i gjennomsiktig modus mer praktisk og pålitelig.
Interoperabilitet
Dette er også kompatibilitet, men i en annen forstand, nemlig muligheten til å jobbe sammen med andre modeller av krypteringsenheter, inkludert de fra andre produsenter. Mye avhenger av standardiseringen av krypteringsprotokoller. Det er rett og slett ingen generelt aksepterte krypteringsstandarder på L1.
Det er en 2ae (MACsec)-standard for L802.1-kryptering på Ethernet-nettverk, men den bruker ikke ende til ende (ende-til-ende), og interport, "hop-by-hop"-kryptering, og i sin originalversjon er uegnet for bruk i distribuerte nettverk, så det har dukket opp proprietære utvidelser som overvinner denne begrensningen (selvfølgelig på grunn av interoperabilitet med utstyr fra andre produsenter). Riktignok i 2018 ble støtte for distribuerte nettverk lagt til 802.1ae-standarden, men det er fortsatt ingen støtte for GOST-krypteringsalgoritmesett. Derfor kjennetegnes proprietære, ikke-standard L2-krypteringsprotokoller som regel ved større effektivitet (spesielt lavere båndbreddeoverhead) og fleksibilitet (evnen til å endre krypteringsalgoritmer og -moduser).
På høyere nivåer (L3 og L4) er det anerkjente standarder, først og fremst IPsec og TLS, men også her er det ikke så enkelt. Faktum er at hver av disse standardene er et sett med protokoller, hver med forskjellige versjoner og utvidelser som kreves eller valgfrie for implementering. I tillegg foretrekker noen produsenter å bruke sine proprietære krypteringsprotokoller på L3/L4. Derfor bør du i de fleste tilfeller ikke regne med fullstendig interoperabilitet, men det er viktig at minst interaksjon mellom ulike modeller og ulike generasjoner av samme produsent er sikret.
Pålitelighet
For å sammenligne ulike løsninger kan du bruke enten gjennomsnittlig tid mellom feil eller tilgjengelighetsfaktor. Hvis disse tallene ikke er tilgjengelige (eller det ikke er tillit til dem), kan det gjøres en kvalitativ sammenligning. Enheter med praktisk administrasjon vil ha en fordel (mindre risiko for konfigurasjonsfeil), spesialiserte krypteringer (av samme grunn), samt løsninger med minimal tid for å oppdage og eliminere en feil, inkludert midler for "hot" backup av hele noder og enheter.
Koste
Når det kommer til kostnad, som med de fleste IT-løsninger, er det fornuftig å sammenligne de totale eierkostnadene. For å beregne det, trenger du ikke å finne opp hjulet på nytt, men bruke en hvilken som helst passende metodikk (for eksempel fra Gartner) og en hvilken som helst kalkulator (for eksempel den som allerede brukes i organisasjonen for å beregne TCO). Det er klart at for en nettverkskrypteringsløsning består den totale eierkostnaden av direkte kostnader ved kjøp eller leie av selve løsningen, infrastruktur for hosting av utstyr og kostnader til utplassering, administrasjon og vedlikehold (enten internt eller i form av tredjepartstjenester), samt fra indirekte kostnader fra nedetid for løsning (forårsaket av tap av sluttbrukerproduktivitet). Det er sannsynligvis bare en subtilitet. Løsningens ytelsespåvirkning kan betraktes på forskjellige måter: enten som indirekte kostnader forårsaket av tapt produktivitet, eller som "virtuelle" direkte kostnader ved kjøp/oppgradering og vedlikehold av nettverksverktøy som kompenserer for tap av nettverksytelse på grunn av bruk av kryptering. Uansett er det best å utelate utgifter som er vanskelige å beregne med tilstrekkelig nøyaktighet fra regnestykket: På denne måten blir det mer tillit til sluttverdien. Og, som vanlig, er det i alle fall fornuftig å sammenligne forskjellige enheter etter TCO for et spesifikt scenario for deres bruk - ekte eller typisk.
holdbarhet
Og den siste egenskapen er utholdenheten til løsningen. I de fleste tilfeller kan holdbarhet kun vurderes kvalitativt ved å sammenligne ulike løsninger. Vi må huske at krypteringsenheter ikke bare er et middel, men også et objekt for beskyttelse. De kan være utsatt for ulike trusler. I spissen er truslene om brudd på konfidensialitet, reproduksjon og modifikasjon av meldinger. Disse truslene kan realiseres gjennom sårbarheter i chifferen eller dens individuelle moduser, gjennom sårbarheter i krypteringsprotokoller (inkludert i stadiene med å etablere en forbindelse og generere/distribuere nøkler). Fordelen vil være for løsninger som gjør det mulig å endre krypteringsalgoritmen eller bytte chiffermodus (i det minste gjennom en fastvareoppdatering), løsninger som gir den mest komplette krypteringen, og skjuler for angriperen ikke bare brukerdata, men også adresse og annen tjenesteinformasjon , samt tekniske løsninger som ikke bare krypterer, men også beskytter meldinger mot reproduksjon og modifikasjon. For alle moderne krypteringsalgoritmer, elektroniske signaturer, nøkkelgenerering osv., som er nedfelt i standarder, kan styrken antas å være den samme (ellers kan du rett og slett gå deg vill i kryptografiens villmark). Bør disse nødvendigvis være GOST-algoritmer? Alt er enkelt her: Hvis applikasjonsscenarioet krever FSB-sertifisering for CIPF (og i Russland er dette oftest tilfelle; for de fleste nettverkskrypteringsscenarier er dette sant), så velger vi bare mellom sertifiserte. Hvis ikke, er det ingen vits i å utelukke enheter uten sertifikater fra vurdering.
En annen trussel er trusselen om hacking, uautorisert tilgang til enheter (inkludert gjennom fysisk tilgang utenfor og inne i saken). Trusselen kan gjennomføres gjennom
sårbarheter i implementering - i maskinvare og kode. Derfor vil løsninger med minimal "angrepsflate" via nettverket, med kabinetter beskyttet mot fysisk tilgang (med inntrengningssensorer, sonderingsbeskyttelse og automatisk tilbakestilling av nøkkelinformasjon når kabinettet åpnes), samt de som tillater fastvareoppdateringer ha en fordel i tilfelle en sårbarhet i koden blir kjent. Det er en annen måte: Hvis alle enhetene som sammenlignes har FSB-sertifikater, kan CIPF-klassen som sertifikatet ble utstedt for, betraktes som en indikator på motstand mot hacking.
Til slutt, en annen type trussel er feil under oppsett og drift, den menneskelige faktoren i sin reneste form. Dette viser en annen fordel med spesialiserte krypteringer fremfor konvergerte løsninger, som ofte er rettet mot erfarne "nettverksspesialister" og kan forårsake vanskeligheter for "vanlige", generelle informasjonssikkerhetsspesialister.
Oppsummering
I prinsippet vil det her være mulig å foreslå en slags integrert indikator for å sammenligne forskjellige enheter, noe som
$$display$$K_j=∑p_i r_{ij}$$display$$
hvor p er vekten til indikatoren, og r er rangeringen til enheten i henhold til denne indikatoren, og alle egenskapene som er oppført ovenfor kan deles inn i "atomare" indikatorer. En slik formel kan for eksempel være nyttig ved sammenligning av anbudsforslag etter forhåndsavtalte regler. Men du kan klare deg med et enkelt bord som
Karakterisering
Enhet 1
Enhet 2
...
Enhet N
båndbredde
+
+
+ + +
Overhead
+
++
+ + +
Forsinkelse
+
+
++
Skalerbarhet
+ + +
+
+ + +
Fleksibilitet
+ + +
++
+
Interoperabilitet
++
+
+
Kompatibilitet
++
++
+ + +
Enkelhet og bekvemmelighet
+
+
++
feiltoleranse
+ + +
+ + +
++
Koste
++
+ + +
+
holdbarhet
++
++
+ + +
Jeg svarer gjerne på spørsmål og konstruktiv kritikk.
Kilde: www.habr.com