Denne anmeldelse (eller vejledning til sammenligning, hvis du vil) skrev jeg, da jeg fik til opgave at sammenligne flere enheder fra forskellige leverandører. Desuden tilhørte disse enheder forskellige klasser. Jeg måtte sætte mig ind i arkitekturen og specifikationerne for alle disse enheder og oprette et 'koordinatsystem' til sammenligning. Jeg vil være glad, hvis min anmeldelse kan hjælpe nogen:
- At finde ud af beskrivelserne og specifikationerne for krypteringsenheder
- At adskille 'papir'-specifikationer fra dem, der virkelig betyder noget i praksis
- At gå ud over den sædvanlige gruppe leverandører og inkludere alle produkter, der er passende til at løse det stillede problem
- At stille de rigtige spørgsmål under forhandlingerne
- At udarbejde udbudskrav (RFP)
- At forstå, hvilke specifikationer man må give afkald på, hvis man vælger en særlig model af enhed
Hvad man kan vurdere
Generelt er tilgangen anvendelig for enhver autonom (standalone) enhed, der er egnet til at kryptere netværkstrafik mellem fjerntliggende Ethernet-segmenter (inter-site kryptering). Det vil sige 'bokse' i en separat kabinet (okay, blade/moduler til chassis inkluderer vi også her), som tilsluttes via en eller flere Ethernet-porte til et lokalt (campus) Ethernet-netværk med ukrypteret trafik, og gennem en anden port(er) – til den kanal/netværk, hvor den krypterede trafik overføres til andre, fjerntliggende segmenter. En sådan krypteringsløsning kan implementeres i et privat eller operatørnetværk via forskellige slags 'transport' ('mørkt' fiberoptik, udstyr til frekvensdeling, kommuteret Ethernet-netværk samt 'pseudo-leder', der er lagt gennem et netværk med en anden rutingarkitektur, oftest MPLS), ved hjælp af teknologien VPN eller uden den.
Netværkskryptering i et distribueret Ethernet-netværk
Selve enhederne kan være enten specialiserede (kun beregnet til kryptering), eller multifunktionelle (hybrid-, konvergente), som udfører andre funktioner (for eksempel en firewall eller router). Forskellige leverandører placerer deres enheder i forskellige klasser/kategorier, men det er ikke det vigtigste – det vigtige er, om de kan kryptere mellemwebtrafik, og hvilke egenskaber de har i denne forbindelse.
For en god ordens skyld vil jeg minde om, at "netværkskryptering", "trafikkryptering", "krypter" – disse termer er uformelle, selvom de ofte bruges. I danske retsakter (inklusive de, der indfører standarder) vil du nok ikke støde på dem.
Krypteringsniveauer og transmissionsmetoder
Før vi går i gang med at beskrive de specifikationer, der vil blive brugt til vurderingen, må vi først afklare én vigtig ting, nemlig "krypteringsniveauet". Jeg har bemærket, at det ofte nævnes både i officielle dokumenter fra leverandører (i beskrivelser, vejledninger osv.) og i uformelle diskussioner (under forhandlinger, på træninger). Det vil sige, alle synes at vide, hvad der menes, men jeg har personligt været vidne til noget forvirring.
Så hvad er "krypteringsniveau"? Det er klart, at det handler om nummeret på niveauet i den standardiserede netværksmodel OSI/ISO, hvor krypteringen finder sted. Lad os læse standarden ISO 7498-2–99 "Informations teknologi. Sammenkobling af åbne systemer. Grundlæggende reference model. Del 2. Arkitektur for informationsbeskyttelse". Fra dette dokument kan man forstå, at tjenesterne til beskyttelse af privatlivets fred (hvoraf kryptering er en af mekanismerne) – det er niveauet for protokollen, hvor serviceblockdataene ("nyttelasten", brugerdataene) bliver krypteret. Som det også er angivet i standarden, kan tjenesten leveres både på dette niveau, "med egne midler", og ved hjælp af det underliggende niveau (præcis som det fx ofte er realiseret i MACsec).
I praksis er der to transmissionsmetoder for krypteret information gennem netværket (man tænker straks på IPsec, men disse metoder findes også i andre protokoller). I transportmodus (nogle gange kaldet native) krypteres kun serviceblokken datablok, mens overskrifterne forbliver "åbne", usikret (nogle gange tilføjes ekstra felter med tjenesteinformation fra krypteringsalgoritmen, mens andre felter modificeres, omberegnes). I tunnel den samme tilstand krypteres hele protokol datablok (det vil sige selve pakken) krypteres og kapsles ind i en tjenestedatablok af samme eller højere niveau, hvilket betyder, at den indrammes med nye overskrifter.
I sig selv er krypteringsniveauet kombineret med en bestemt overførselsmetode hverken godt eller dårligt, så man kan ikke sige, eksempelvis, at L3 i transporttilstand er bedre end L2 i tunneltilstand. De afhænger simpelthen af mange egenskaber, som vurderer enhederne. For at fungere i netværk L1 (bitstrøm retransmission), L2 (rammeomskiftning) og L3 (paketrouting) i transporttilstand kræves der løsninger, der krypterer på samme eller højere niveau (ellers vil adresseoplysningerne blive krypteret, og dataene kommer ikke frem til bestemmelsesstedet), mens tunneltilstand muliggør at overvinde denne begrænsning (dog på bekostning af andre vigtige egenskaber).
Transport- og tunnelkrypteringsmetoder L2
Og nu skal vi se på egenskaberne.
Ydeevne
For netværkskryptering er ydeevne et komplekst, flerkratigt begreb. Det kan ske, at en bestemt model, der overgår i en ydeevneegenskab, falder bagud i en anden. Så det er altid nyttigt at overveje alle komponenter af krypteringsydelsen og deres indflydelse på netværksydelsen og de applikationer, der bruger den. Her kan man lave en analogi til en bil, hvor det ikke kun er den maksimale hastighed, der tæller, men også accelerationstiden til "hundrede", brændstofforbruget osv. Producenternes ydeevne og deres potentielle kunder lægger stor vægt på disse egenskaber. Som regel rangordnes enhederne i producentlisterne baseret på ydeevne.
Det er klart, at ydeevnen afhænger både af kompleksiteten af de netværks- og kryptografiske operationer, der udføres på enheden (herunder hvor godt disse opgaver kan paralleliseres og pipelines), og af ydeevnen af hardwaren samt kvaliteten af den indbyggede software. Derfor anvendes der i de ældre modeller mere kraftfuld "hardware", og der er nogle gange mulighed for at opgradere med ekstra processorer og hukommelsesmoduler. Der er flere tilgange til implementering af kryptografiske funktioner: på en universel central processor (CPU), en specialiseret anvendelsesspecifik integreret kreds (ASIC) eller på en programmerbar logisk integreret kreds (FPGA). Hver tilgang har sine fordele og ulemper. For eksempel kan CPU'en blive et "flaskehals" i krypteringen, især hvis processoren ikke har specialiserede instruktioner til at understøtte krypteringsalgoritmen (eller hvis de ikke anvendes). Specialiserede chips mangler fleksibilitet, og det er ikke altid muligt at "gentage" dem for at forbedre ydeevnen, tilføje nye funktioner eller rette fejl. Derudover bliver deres brug kun økonomisk rentabelt ved store produktionsvolumener. Derfor er "den gyldne middelvej" blevet så populær – brugen af FPGA (på dansk PLIS). Det er netop på PLIS, at de såkaldte kryptoacceleratorer er lavet – indbyggede eller tilsluttede specialiserede hardwaremoduler til støtte for kryptografiske operationer.
Da det handler om netværks- kryptering, er det logisk, at ydeevnen af løsningerne skal måles i de samme målinger som for andre netværksenheder – båndbredde, pakke tab (frame loss) og forsinkelse (latency). Disse målinger er defineret i RFC 1242. Forresten er der ikke skrevet noget i denne RFC om den ofte nævnte variation i forsinkelse (jitter). Hvordan måler man disse målinger? Jeg har ikke fundet en godkendt metode i nogen standarder (officielle eller uofficielle som RFC), der specifikt er udviklet til netværkskryptering. Det ville være logisk at bruge metoden for netværksenheder, som er fastlagt i standarden RFC 2544. Mange leverandører følger den – mange, men ikke alle. For eksempel sender de testtrafik kun i én retning i stedet for begge, som anbefales standarden. Nå ja, men.
Måling af ydeevne for netværk krypteringsenheder har sine egne karakteristika. For det første er det vigtigt at gennemføre alle målinger for et par enheder: selv om krypteringsalgoritmerne er symmetriske, vil forsinkelser og pakktab ved kryptering og dekryptering ikke nødvendigvis være de samme. For det andet giver det mening at måle netop deltaen, indflydelsen af netværkskryptering på den samlede netværksydelse, ved at sammenligne to konfigurationer: uden krypteringsenheder og med dem. Eller, som i tilfælde med hybrid-enheder, der kombinerer flere funktioner udover netværkskryptering, ved at sammenligne tilstandene med og uden kryptering. Denne indflydelse kan variere og afhænger af forbindelsesskemaet for krypteringsenhederne, deres driftsmetoder og i sidste ende trafiktypen. Især afhænger mange ydeevneparametre af pakke længden, hvilket er grunden til, at grafikker der viser disse parametre i forhold til pakke længde ofte anvendes til at sammenligne ydeevnen af forskellige løsninger, eller at der anvendes IMIX – trafikfordeling efter pakke længder, som omtrent reflekterer virkeligheden. Hvis vi sammenligner den samme grundlæggende konfiguration uden kryptering, så kan vi sammenligne løsninger til netværkskryptering, der er implementeret forskelligt, uden at gå ind i disse forskelle: L2 med L3, 'gem og send' (store-and-forward) med gennemskærende (cut-through), specialiserede med konvergente, GOST med AES og så videre.
Forbindelsesskema til testning af ydeevne
Den første egenskab, som man lægger mærke til, er "hastigheden" på krypteringsenheden, det vil sige båndbredde (bandwidth) af dens netværksinterface, bitrate. Den bestemmes af de netværksstandarder, der understøttes af grænsefladerne. For Ethernet er almindelige tal – 1 Gbit/s og 10 Gbit/s. Men, som vi ved, i ethvert netværk er den maksimale teoretiske kapacitet (throughput) på hvert af dens niveauer er altid mindre end båndbredden: en del af båndbredden "spises" af mellemrammeintervaller, kontroloverskrifter og så videre. Hvis enheden er i stand til at modtage, behandle (i vores tilfælde kryptere eller dekryptere) og overføre trafik med den fulde hastighed af netværksgrænssnittet, det vil sige med den maksimale teoretiske båndbredde for dette niveau af netværksmodellen, så siges det, at den fungerer ved linjehastighed. For dette skal enheden ikke tabe, ikke forkaste pakker uanset deres størrelse og frekvens. Hvis krypteringsenheden ikke understøtter drift ved linjehastighed, angives dens maksimale båndbredde normalt i gigabits per sekund (nogle gange med angivelse af længden på pakkerne – jo kortere pakker, desto lavere er båndbredden). Det er meget vigtigt at forstå, at maksimal båndbredde er den maksimale uden tab (selv hvis enheden kan "pumpe" trafik igennem sig med højere hastighed, men samtidig taber nogle pakker). Derudover skal man være opmærksom på, at nogle leverandører måler den samlede båndbredde mellem alle portpar, så disse tal siger ikke meget, hvis al krypteret trafik går gennem en enkelt port.
Hvor er det især vigtigt at arbejde ved linjehastighed (eller, på anden måde, uden tab af pakker)? I kanaler med høj båndbredde og store forsinkelser (for eksempel satellitkanaler), hvor for at opretholde høj overførselshastighed skal der være et stort TCP-vindue, og hvor tab af pakker markant reducerer netværkets ydeevne.
Men ikke al båndbredde bruges til at overføre nyttige data. Man må tage hensyn til de såkaldte overheadomkostninger (overhead) båndbredde. Dette er den del af enhedens krypteringsbåndbredde (i procent eller bytes pr. pakke), som faktisk går tabt (ikke kan anvendes til dataoverførsel). Omkostningerne opstår først og fremmest på grund af den øgede størrelse (tilføjelser, 'padding') af datakent i krypterede netværkspakker (afhængig af krypteringsalgoritmen og dens driftstilstand). For det andet, på grund af den øgede længde af pakkeoverskrifterne (tunnelmode, protokolindstillinger for kryptering, godkendelsestekster osv., afhængigt af protokollen og driftstilstanden for krypteringsmetoden og overførselsmetoden) – disse omkostninger er normalt de mest signifikante, og de får først opmærksomhed. For det tredje, på grund af fragmenteringen af pakker, når den maksimale datablokstørrelse (MTU) overskrides (hvis netværket kan opdele pakker, der overskrider MTU, i to ved at duplikere deres overskrifter). For det fjerde, på grund af dannelsen af yderligere kontroltrafik i netværket mellem krypteringsanordningerne (til nøgleudveksling, oprettelse af tunneler osv.). Lave omkostninger er vigtige, hvor kanalens båndbredde er begrænset. Dette ses især i trafikken fra små pakker, for eksempel i taletrafik – her kan omkostningerne 'æde' mere end halvdelen af kanalens hastighed!
Båndbredde
Endelig er der også indført latens – forskellen (i brøkdeler af et sekund) i netværkslatens (tiden det tager for data at rejse fra indgangen til netværket til udgangen) mellem dataoverførsel uden netværkskryptering og med det. Generelt gælder det, at jo mindre latens ('latenstid') netværket har, desto mere kritisk bliver den latens, der introduceres af krypteringsenhederne. Den latens, der introduceres, kommer fra selve krypteringsoperationen (afhænger af krypteringsalgoritmen, bloklængden og driftsmåden af krypteringen samt kvaliteten af dens implementering i softwaren), samt behandlingen af netværkspakken i enheden. Den introducerede latens afhænger både af behandlingsmetoden for pakkerne (end-to-end eller 'modtag og send') og enhedens ydeevne ('hardware'-implementering på FPGA eller ASIC er normalt hurtigere end 'software'-implementering på CPU). L2-kryptering har næsten altid en lavere introduceret latens sammenlignet med kryptering på L3 eller L4: Dette skyldes, at enheder, der krypterer på L3/L4, ofte er konvergerende. For eksempel, i højspeed Ethernet-kryptere, der er implementeret på FPGA og krypterer på L2, er latensen fra krypteringsoperationen ubetydelig – nogle gange, når kryptering aktiveres på et par enheder, mindskes den samlede latens, de introducerer! Lav latens er vigtig, hvor den er sammenlignelig med den samlede latens i kanalen, inklusive signalets udbredelseslatens, som er cirka 5 mikrosekunder per kilometer. Det vil sige, at man kan sige, at for bystørrelsesnetværk (distrikter på titusinder af kilometer i diameter) kan mikrosekunder betyde meget. For eksempel for synkron databasereplikering, højfrekvent handel og blockchain.
Introduceret latens
Skalering
Storede distribuerede netværk kan omfatte mange tusinde noder og netværksenheder samt hundredevis af segmenter af lokale netværk. Det er vigtigt, at krypteringsløsninger ikke pålægger yderligere begrænsninger på størrelsen og topologien af det distribuerede netværk. Dette gælder især det maksimale antal adresser på noder og netværk. Disse begrænsninger kan for eksempel opstå ved implementeringen af en multipunkt topologi for et krypteret netværk (med uafhængige sikre forbindelser eller tunneler) eller ved selektiv kryptering (for eksempel efter protokolnummer eller VLAN). Hvis netværksadresser (MAC, IP, VLAN ID) bruges som nøgler i en tabel, hvor antallet af rækker er begrænset, viser disse begrænsninger sig tydeligt her.
Desuden har store netværk ofte flere strukturelle niveauer, herunder kerne-netværk, hvor der implementeres forskellige adresseringsordninger og routingpolitikker. For at realisere en sådan tilgang anvendes der ofte specialformater for rammer (som Q-in-Q eller MAC-in-MAC) og rutingsprotokoller. For ikke at hindre opbygningen af sådanne netværk, skal krypteringsudstyr korrekt kunne håndtere sådanne rammer (det vil sige, at skalerbarhed i denne sammenhæng vil betyde kompatibilitet – mere om dette nedenfor).
Fleksibilitet
Her handler det om støtte til forskellige konfigurationer, forbindelsesskemaer, topologier og mere. For eksempel betyder det for switchede netværk baseret på Carrier Ethernet-teknologier støtte til forskellige typer virtuelle forbindelser (E-Line, E-LAN, E-Tree), forskellige servicetyper (både pr. porte og pr. VLAN) og forskellige transportteknologier (som nævnt tidligere). Det vil sige, at udstyret skal kunne fungere både i lineær ('point-to-point') og multipunkt mode, oprette separate tunneler for forskellige VLAN, og tillade unordered delivery af pakker inden for en sikret kanal. Muligheden for at vælge forskellige krypteringsdriftsformer (herunder med eller uden indholdsautentifikation) og forskellige pakkeoverførselsmetoder giver mulighed for at sikre en balance mellem modstandskraft og ydeevne afhængigt af de aktuelle forhold.
Support for private networks, whose equipment is owned by one organization (or rented by it), and for operator networks, where different segments are managed by different companies, is also important. It is beneficial if the solution allows for management both by in-house resources and by an external organization (according to the managed service model). In operator networks, another important function is support for multi-tenancy (joint use by different customers) in the form of cryptographic isolation of individual customers (subscribers) whose traffic passes through the same set of encryption devices. This typically requires the use of separate sets of keys and certificates for each customer.
If the device is acquired for a specific scenario, then all these features may not be very important – one just needs to ensure that the device supports what is currently needed. But if the solution is acquired with future growth in mind, including support for future scenarios, and is chosen as a "corporate standard", then flexibility will be an advantage – especially considering the interoperability limitations of devices from different vendors (more on this below).
Simplicity and convenience
Ease of maintenance is also a multifaceted concept. It can be said that it encompasses the total time costs of specialists with a certain level of qualification needed to support the solution at various stages of its life cycle. If there are no costs and installation, configuration, and operation are completely automated, then the costs are zero and the convenience is absolute. Of course, such a scenario does not occur in the real world. A reasonable approximation is the model "node on a wire" (bump-in-the-wire), eller en gennemsigtig forbindelse, hvor tilføjelse og frakobling af krypteringsenheder ikke kræver nogen manuelle eller automatiske ændringer i netværkskonfigurationen. Dette forenkler vedligeholdelsen af løsningen: man kan trygt tænde og slukke krypteringsfunktionen, og når det er nødvendigt, blot "omgå" enheden med et netværkskabel (det vil sige direkte forbinde de porte i netværksudstyret, som den var tilsluttet). Der er dog en ulempe – det samme kan også gøres af en ondsindet aktør. For at implementere princippet "enhed på ledningen" skal man tage hensyn til trafikken ikke kun datalag, men også kontrol- og administrationslag – enhederne skal være gennemsigtige for dem. Derfor kan sådan trafik kun krypteres, når der ikke er nogen modtagere af denne type trafik mellem krypteringsenhederne i netværket, for hvis den kasseres eller krypteres, kan netværkskonfigurationen ændre sig, når krypteringen tænder og slukker. Krypteringsenheden kan også være gennemsigtig for signalering på det fysiske niveau. Især i tilfælde af signaltab skal den kunne videregive denne tab (det vil sige deaktivere sine sendere) frem og tilbage ("for sig selv") i retning af signalet.
Det er også vigtigt at understøtte opdelingen af beføjelser mellem afdelingerne for informationssikkerhed (IB) og IT, især netværksafdelingen. Løsningen til kryptering skal understøtte den adgangspunktmodel, der er vedtaget i organisationen, og audit. Behovet for interaktion mellem forskellige afdelinger til udførelse af rutineopgaver bør minimeres. Derfor er specialiserede enheder, der kun understøtter krypteringsfunktioner og er så gennemsigtige som muligt for netværksoperationer, en fordel i forhold til brugervenlighed. Kort sagt, ansatte i IB-afdelingen bør ikke have grund til at kontakte "netværksfolkene" for at ændre netværksindstillingerne. Og omvendt bør de heller ikke have behov for at ændre krypteringsindstillingerne ved netværksvedligeholdelse.
En anden faktor er mulighederne og brugervenligheden af administrationsværktøjerne. De skal være overskuelige, logiske, muliggøre import- og eksport af indstillinger, automatisering osv. Man skal straks være opmærksom på, hvilke administrationsmuligheder der er tilgængelige (normalt en egen administrationsplatform, webgrænseflade og kommandolinje) og hvilke funktioner der findes i hver af dem (der kan være begrænsninger). En vigtig funktion er understøttelsen af out-of-band styring, hvilket betyder via et dedikeret administrationsnetværk, og in-band styring, hvilket betyder gennem det fælles netværk, som overfører nyttetraffik. Administrationsværktøjer skal signalere om alle unormale situationer, herunder sikkerhedshændelser. Rutineprægede, gentagne operationer skal udføres automatisk. Dette gælder primært for administrationsnøgler. Disse bør genereres/distribueres automatisk. Understøttelse af PKI er en stor fordel.
Kompatibilitet
Det vil sige enhedens kompatibilitet med netværksstandarder. Herunder menes ikke kun industristandarder vedtaget af autoritative organisationer som IEEE, men også proprietære protokoller fra branchens førende aktører som Cisco. Der er to grundlæggende måder at sikre kompatibilitet på: enten gennem gennemsigtighed,eller gennem explisitte understøttelse af protokoller (når krypteringsenheden bliver en af noderne i netværket for en given protokol og behandler kontroltrafikken af denne protokol). Kompatibiliteten med netværk afhænger af fuldstændigheden og korrektheden af implementeringen af kontrolprotokoller. Det er vigtigt at understøtte forskellige PHY-niveauer (hastigheder, transmissionsmedier, kodningsordninger), Ethernet-rammer af forskellige formater med enhver MTU, samt forskellige L3 kontrolprotokoller (primært fra TCP/IP-familien).
Gennemsigtighed opnås gennem mekanismer som mutation (midlertidig ændring af indholdet af åbne overskrifter i trafikken mellem krypteringsenheder), bypass (når enkelte pakker forbliver ukrypterede) og forskydning af begyndelsen af krypteringen (når de normalt krypterede felter i pakkerne ikke krypteres).
Hvordan sikres gennemsigtigheden
Derfor skal du altid afklare, hvordan understøttelsen af en given protokol sikres. Ofte er understøttelse i gennemsigtig tilstand mere praktisk og pålidelig.
Interoperabilitet
Dette handler også om kompatibilitet, men i en anden forstand, nemlig muligheden for samarbejde med andre krypteringsenheder, herunder fra andre producenter. Meget afhænger af tilstanden for standardisering af krypteringsprotokoller. Der findes simpelthen ikke almindeligt anerkendte krypteringsstandarder på L1.
Til kryptering L2 i Ethernet-netværk findes standarden 802.1ae (MACsec), men den bruger ikke end-to-end (end-to-end), men interport, "hop-by-hop" kryptering, og i sin oprindelige version var den uegnet til brug i distribuerede netværk, hvorfor der opstod egne udvidelser, der overvinder denne begrænsning (selvfølgelig på bekostning af interoperabilitet med udstyr fra andre producenter). Det skal dog nævnes, at der i 2018 blev tilføjet understøttelse af distribuerede netværk i standarden 802.1ae, men understøttelse af GOST-krypteringsalgoritmer er stadig ikke til stede. Derfor adskiller proprietære, ikke-standardiserede L2-krypteringsprotokoller sig typisk ved højere effektivitet (især mindre båndbreddeoverhead) og fleksibilitet (muligheden for at ændre algoritmer og krypteringsmetoder).
På højere niveauer (L3 og L4) findes der anerkendte standarder, primært IPsec og TLS, men heller ikke her er alt så enkelt. Problemet er, at hver af disse standarder er et sæt protokoller, hvor hver enkelt har forskellige versioner samt obligatoriske eller valgfrie udvidelser. Desuden foretrækker nogle producenter at anvende deres egne proprietære krypteringsprotokoller også på L3/L4. Derfor skal man i mange tilfælde ikke forvente fuld interoperabilitet, men det er vigtigt, at der i det mindste er et samarbejde mellem forskellige modeller og generationer fra samme producent.
Pålidelighed
Til sammenligning af forskellige løsninger kan man anvende enten den gennemsnitlige tid til fejl eller tilgængelighedsfaktoren. Hvis disse tal ikke er tilgængelige (eller ikke kan stole på), kan der udføres en kvalitativ sammenligning. Fordelen vil være hos enheder med nem administration (mindre risiko for konfigurationsfejl), hos specialiserede krypteringsenheder (af samme årsag), samt hos løsninger med minimal tid til detektion og løsning af fejl, herunder metoder til "hot" redundans af noder og enheder helt.
Omkostninger
Når det kommer til omkostninger, er det som med de fleste IT-løsninger fornuftigt at sammenligne den samlede ejeromkostning. For at beregne det kan man bruge enhver passende metode (f.eks. fra Gartner) og en hvilken som helst kalkulator (f.eks. den, der allerede bruges i organisationen til at beregne TCO). Det er klart, at den samlede ejeromkostning for en netværkskrypteringsløsning består af direkte omkostninger til køb eller leje af selve løsningen, infrastruktur til hosting af udstyret og omkostninger til implementering, administration og vedligeholdelse (uanset om det er internt eller som tjenester fra en tredjepartsorganisation), samt indirekte omkostninger fra nedetid for løsningen (forårsaget af tab af produktivitet blandt slutbrugere). Der er måske kun én nuance. Virkningen af løsningens ydeevne kan vurderes på forskellige måder: enten som indirekte omkostninger forårsaget af faldende produktivitet eller som "virtuel" direkte omkostning til køb/opgradering og vedligeholdelse af netværksmidler, der kompenserer for faldet i netværksydelsen på grund af anvendelsen af kryptering. Under alle omstændigheder er det bedre at "lade omkostningerne, som er svære at beregne med tilstrækkelig præcision, ligge uden for" beregningen: det vil skabe mere tillid til den endelige størrelse. Som sædvanligt giver det mening at sammenligne forskellige enheder efter TCO i forhold til et konkret anvendelsesscenarie – reelt eller typisk.
Robusthed
Den sidste egenskab er robustheden af løsningen. I de fleste tilfælde kan robusthed kun vurderes kvalitativt ved at sammenligne forskellige løsninger. Vi skal huske, at krypteringsenheder ikke blot er værktøjer, men også beskyttelsesobjekter. De kan være udsat for forskellige trusler. På førstepladsen står trusler mod fortroligheden, reproduktion og ændring af beskeder. Disse trusler kan realiseres gennem sårbarheder i krypteringsalgoritmen eller dens tilstande, samt ved sårbarheder i krypteringsprotokoller (herunder i faserne for oprettelse af forbindelse og generering/distribution af nøgler). Fordelen vil tilkomme løsninger, der tillader ændring af krypteringsalgoritmen eller skift af krypteringstilstand (i det mindste gennem opdatering af firmware), hos løsninger, der sikrer maksimal kryptering og skjuler ikke kun brugerdata, men også adresse- og anden hjælpedata fra angriberen, samt hos de løsninger, der ikke kun krypterer, men også beskytter beskeder mod reproduktion og ændring. For alle moderne algoritmer til kryptering, digital signatur, nøglegenerering med videre, der er fastsat i standarderne, kan robustheden anses for at være ens (ellers kan man let fare vild i kryptografiens jungle). Skal det nødvendigvis være GOST-algoritmer? Her er svaret enkelt: hvis anvendelsesscenariet kræver certificering fra FSB for SKZI (og i Rusland er det ofte tilfældet), for de fleste scenarier for netværkskryptering er det tilfældet), så vælger vi kun mellem de certificerede. Hvis ikke – så er der heller ikke nogen grund til at udelukke enheder uden certificering fra overvejelserne.
En anden trussel er truslen om hacking, uautoriseret adgang til enheder (herunder gennem fysisk adgang udefra og indefra kabinettet). Truslen kan realiseres gennem
Sårbarheder i implementeringen – i hardware og i koden. Derfor vil løsninger med en minimal "angrebsflade" gennem netværket, med kabinetter beskyttet mod fysisk adgang (med brudsensorer, beskyttelse mod sondemodtagelse og automatisk nulstilling af nøg information ved åbning af kabinettet), have en fordel, ligesom dem, der tillader opdatering af firmware, når en sårbarhed i koden bliver kendt. Der er også en anden vej: hvis alle sammenlignede enheder har FSB-certifikater, kan modstandsdygtigheden mod hacking betragtes som klassen af SKZI, som certifikatet er udstedt til.
Endelig er en anden type trusler fejl ved konfiguration og drift, det rene menneskelige faktor. Her viser der sig en anden fordel ved specialiserede krypteringsenheder frem for konvergerende løsninger, der ofte er rettet mod erfarne "netværksfolk" og kan medføre vanskeligheder for "almindelige", bredt funderede IT-specialister.
Sammenfatning
I princippet kunne der her foreslås et eller andet integreret indeks til sammenligning af forskellige enheder, noget som
$$display$$K_j=∑p_i r_{ij}$$display$$
hvor p er vægten af indikatoren, og r er rangeringen af enheden efter denne indikator, idet enhver af de ovennævnte egenskaber kan opdeles i "atomære" mål. Sådan en formel kunne være nyttig, for eksempel ved sammenligning af tilbud ved hjælp af på forhånd aftalte regler. Men man kan også nøjes med en simpel tabel som
Specifikation
Enhed 1
Enhed 2
…
Enhed N
Båndbredde
+
+
+++
Overheadomkostninger
+
++
+++
Forsinkelse
+
+
++
Skalering
+++
+
+++
Fleksibilitet
+++
++
+
Interoperabilitet
++
+
+
Kompatibilitet
++
++
+++
Simplicity and convenience
+
+
++
Fejltolerance
+++
+++
++
Omkostninger
++
+++
+
Robusthed
++
++
+++
Jeg vil være glad for at besvare spørgsmål og konstruktive kritiske bemærkninger.
Kilde: habr.com
