VPN<\/a> eller uden den.<\/p>\nNetv\u00e6rkskryptering i et distribueret Ethernet-netv\u00e6rk<\/i><\/p>\n
Selve enhederne kan v\u00e6re enten specialiserede<\/b> (kun beregnet til kryptering), eller multifunktionelle (hybrid-, konvergente<\/b>), som udf\u00f8rer andre funktioner (for eksempel en firewall eller router). Forskellige leverand\u00f8rer placerer deres enheder i forskellige klasser\/kategorier, men det er ikke det vigtigste \u2013 det vigtige er, om de kan kryptere mellemwebtrafik, og hvilke egenskaber de har i denne forbindelse.<\/p>\n
For en god ordens skyld vil jeg minde om, at \"netv\u00e6rkskryptering\", \"trafikkryptering\", \"krypter\" \u2013 disse termer er uformelle, selvom de ofte bruges. I danske retsakter (inklusive de, der indf\u00f8rer standarder) vil du nok ikke st\u00f8de p\u00e5 dem.<\/p>\n
Krypteringsniveauer og transmissionsmetoder<\/h4>\n \nF\u00f8r vi g\u00e5r i gang med at beskrive de specifikationer, der vil blive brugt til vurderingen, m\u00e5 vi f\u00f8rst afklare \u00e9n vigtig ting, nemlig \"krypteringsniveauet\". Jeg har bem\u00e6rket, at det ofte n\u00e6vnes b\u00e5de i officielle dokumenter fra leverand\u00f8rer (i beskrivelser, vejledninger osv.) og i uformelle diskussioner (under forhandlinger, p\u00e5 tr\u00e6ninger). Det vil sige, alle synes at vide, hvad der menes, men jeg har personligt v\u00e6ret vidne til noget forvirring.<\/p>\n
S\u00e5 hvad er \"krypteringsniveau\"? Det er klart, at det handler om nummeret p\u00e5 niveauet i den standardiserede netv\u00e6rksmodel OSI\/ISO, hvor krypteringen finder sted. Lad os l\u00e6se standarden ISO 7498-2\u201399 \"Informations teknologi. Sammenkobling af \u00e5bne systemer. Grundl\u00e6ggende reference model. Del 2. Arkitektur for informationsbeskyttelse\". Fra dette dokument kan man forst\u00e5, at tjenesterne til beskyttelse af privatlivets fred (hvoraf kryptering er en af mekanismerne) \u2013 det er niveauet for protokollen, hvor serviceblockdataene (\"nyttelasten\", brugerdataene) bliver krypteret. Som det ogs\u00e5 er angivet i standarden, kan tjenesten leveres b\u00e5de p\u00e5 dette niveau, \"med egne midler\", og ved hj\u00e6lp af det underliggende niveau (pr\u00e6cis som det fx ofte er realiseret i MACsec).<\/p>\n
I praksis er der to transmissionsmetoder for krypteret information gennem netv\u00e6rket (man t\u00e6nker straks p\u00e5 IPsec, men disse metoder findes ogs\u00e5 i andre protokoller). I transportmodus<\/b> (nogle gange kaldet native) krypteres kun serviceblokken<\/b> datablok, mens overskrifterne forbliver \"\u00e5bne\", usikret (nogle gange tilf\u00f8jes ekstra felter med tjenesteinformation fra krypteringsalgoritmen, mens andre felter modificeres, omberegnes). I tunnel<\/b> den samme tilstand krypteres hele protokol<\/b> datablok (det vil sige selve pakken) krypteres og kapsles ind i en tjenestedatablok af samme eller h\u00f8jere niveau, hvilket betyder, at den indrammes med nye overskrifter.<\/p>\n
I sig selv er krypteringsniveauet kombineret med en bestemt overf\u00f8rselsmetode hverken godt eller d\u00e5rligt, s\u00e5 man kan ikke sige, eksempelvis, at L3 i transporttilstand er bedre end L2 i tunneltilstand. De afh\u00e6nger simpelthen af mange egenskaber, som vurderer enhederne. For at fungere i netv\u00e6rk L1 (bitstr\u00f8m retransmission), L2 (rammeomskiftning) og L3 (paketrouting) i transporttilstand kr\u00e6ves der l\u00f8sninger, der krypterer p\u00e5 samme eller h\u00f8jere niveau (ellers vil adresseoplysningerne blive krypteret, og dataene kommer ikke frem til bestemmelsesstedet), mens tunneltilstand muligg\u00f8r at overvinde denne begr\u00e6nsning (dog p\u00e5 bekostning af andre vigtige egenskaber).<\/p>\n
Transport- og tunnelkrypteringsmetoder L2<\/i><\/p>\n
Og nu skal vi se p\u00e5 egenskaberne.<\/p>\n
Ydeevne<\/h4>\n \nFor netv\u00e6rkskryptering er ydeevne et komplekst, flerkratigt begreb. Det kan ske, at en bestemt model, der overg\u00e5r i en ydeevneegenskab, falder bagud i en anden. S\u00e5 det er altid nyttigt at overveje alle komponenter af krypteringsydelsen og deres indflydelse p\u00e5 netv\u00e6rksydelsen 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\u00e6ller, men ogs\u00e5 accelerationstiden til \"hundrede\", br\u00e6ndstofforbruget osv. Producenternes ydeevne og deres potentielle kunder l\u00e6gger stor v\u00e6gt p\u00e5 disse egenskaber. Som regel rangordnes enhederne i producentlisterne baseret p\u00e5 ydeevne.<\/p>\n
Det er klart, at ydeevnen afh\u00e6nger b\u00e5de af kompleksiteten af de netv\u00e6rks- og kryptografiske operationer, der udf\u00f8res p\u00e5 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 \u00e6ldre 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\u00e5 en universel central processor (CPU), en specialiseret anvendelsesspecifik integreret kreds (ASIC) eller p\u00e5 en programmerbar logisk integreret kreds (FPGA). Hver tilgang har sine fordele og ulemper. For eksempel kan CPU'en blive et \"flaskehals\" i krypteringen, is\u00e6r hvis processoren ikke har specialiserede instruktioner til at underst\u00f8tte krypteringsalgoritmen (eller hvis de ikke anvendes). Specialiserede chips mangler fleksibilitet, og det er ikke altid muligt at \"gentage\" dem for at forbedre ydeevnen, tilf\u00f8je nye funktioner eller rette fejl. Derudover bliver deres brug kun \u00f8konomisk rentabelt ved store produktionsvolumener. Derfor er \"den gyldne middelvej\" blevet s\u00e5 popul\u00e6r \u2013 brugen af FPGA (p\u00e5 dansk PLIS). Det er netop p\u00e5 PLIS, at de s\u00e5kaldte kryptoacceleratorer er lavet \u2013 indbyggede eller tilsluttede specialiserede hardwaremoduler til st\u00f8tte for kryptografiske operationer.<\/p>\n
Da det handler om netv\u00e6rks-<\/b> kryptering, er det logisk, at ydeevnen af l\u00f8sningerne skal m\u00e5les i de samme m\u00e5linger som for andre netv\u00e6rksenheder \u2013 b\u00e5ndbredde, pakke tab (frame loss) og forsinkelse (latency). Disse m\u00e5linger er defineret i RFC 1242. Forresten er der ikke skrevet noget i denne RFC om den ofte n\u00e6vnte variation i forsinkelse (jitter). Hvordan m\u00e5ler man disse m\u00e5linger? Jeg har ikke fundet en godkendt metode i nogen standarder (officielle eller uofficielle som RFC), der specifikt er udviklet til netv\u00e6rkskryptering. Det ville v\u00e6re logisk at bruge metoden for netv\u00e6rksenheder, som er fastlagt i standarden RFC 2544. Mange leverand\u00f8rer f\u00f8lger den \u2013 mange, men ikke alle. For eksempel sender de testtrafik kun i \u00e9n retning i stedet for begge, som anbefales<\/b> standarden. N\u00e5 ja, men.<\/p>\n
M\u00e5ling af ydeevne for netv\u00e6rk krypteringsenheder har sine egne karakteristika. For det f\u00f8rste er det vigtigt at gennemf\u00f8re alle m\u00e5linger for et par enheder: selv om krypteringsalgoritmerne er symmetriske, vil forsinkelser og pakktab ved kryptering og dekryptering ikke n\u00f8dvendigvis v\u00e6re de samme. For det andet giver det mening at m\u00e5le netop deltaen, indflydelsen af netv\u00e6rkskryptering p\u00e5 den samlede netv\u00e6rksydelse, ved at sammenligne to konfigurationer: uden krypteringsenheder og med dem. Eller, som i tilf\u00e6lde med hybrid-enheder, der kombinerer flere funktioner udover netv\u00e6rkskryptering, ved at sammenligne tilstandene med og uden kryptering. Denne indflydelse kan variere og afh\u00e6nger af forbindelsesskemaet for krypteringsenhederne, deres driftsmetoder og i sidste ende trafiktypen. Is\u00e6r afh\u00e6nger mange ydeevneparametre af pakke l\u00e6ngden, hvilket er grunden til, at grafikker der viser disse parametre i forhold til pakke l\u00e6ngde ofte anvendes til at sammenligne ydeevnen af forskellige l\u00f8sninger, eller at der anvendes IMIX \u2013 trafikfordeling efter pakke l\u00e6ngder, som omtrent reflekterer virkeligheden. Hvis vi sammenligner den samme grundl\u00e6ggende konfiguration uden kryptering, s\u00e5 kan vi sammenligne l\u00f8sninger til netv\u00e6rkskryptering, der er implementeret forskelligt, uden at g\u00e5 ind i disse forskelle: L2 med L3, 'gem og send' (store-and-forward) med gennemsk\u00e6rende (cut-through), specialiserede med konvergente, GOST med AES og s\u00e5 videre.<\/p>\n
Forbindelsesskema til testning af ydeevne<\/i><\/p>\n
Den f\u00f8rste egenskab, som man l\u00e6gger m\u00e6rke til, er \"hastigheden\" p\u00e5 krypteringsenheden, det vil sige b\u00e5ndbredde<\/b> (bandwidth) af dens netv\u00e6rksinterface, bitrate. Den bestemmes af de netv\u00e6rksstandarder, der underst\u00f8ttes af gr\u00e6nsefladerne. For Ethernet er almindelige tal \u2013 1 Gbit\/s og 10 Gbit\/s. Men, som vi ved, i ethvert netv\u00e6rk er den maksimale teoretiske kapacitet<\/b> (throughput) p\u00e5 hvert af dens niveauer er altid mindre end b\u00e5ndbredden: en del af b\u00e5ndbredden \"spises\" af mellemrammeintervaller, kontroloverskrifter og s\u00e5 videre. Hvis enheden er i stand til at modtage, behandle (i vores tilf\u00e6lde kryptere eller dekryptere) og overf\u00f8re trafik med den fulde hastighed af netv\u00e6rksgr\u00e6nssnittet, det vil sige med den maksimale teoretiske b\u00e5ndbredde for dette niveau af netv\u00e6rksmodellen, s\u00e5 siges det, at den fungerer ved linjehastighed<\/b>. For dette skal enheden ikke tabe, ikke forkaste pakker uanset deres st\u00f8rrelse og frekvens. Hvis krypteringsenheden ikke underst\u00f8tter drift ved linjehastighed, angives dens maksimale b\u00e5ndbredde normalt i gigabits per sekund (nogle gange med angivelse af l\u00e6ngden p\u00e5 pakkerne \u2013 jo kortere pakker, desto lavere er b\u00e5ndbredden). Det er meget vigtigt at forst\u00e5, at maksimal b\u00e5ndbredde er den maksimale uden tab<\/b> (selv hvis enheden kan \"pumpe\" trafik igennem sig med h\u00f8jere hastighed, men samtidig taber nogle pakker). Derudover skal man v\u00e6re opm\u00e6rksom p\u00e5, at nogle leverand\u00f8rer m\u00e5ler den samlede b\u00e5ndbredde mellem alle portpar, s\u00e5 disse tal siger ikke meget, hvis al krypteret trafik g\u00e5r gennem en enkelt port.<\/p>\n
Hvor er det is\u00e6r vigtigt at arbejde ved linjehastighed (eller, p\u00e5 anden m\u00e5de, uden tab af pakker)? I kanaler med h\u00f8j b\u00e5ndbredde og store forsinkelser (for eksempel satellitkanaler), hvor for at opretholde h\u00f8j overf\u00f8rselshastighed skal der v\u00e6re et stort TCP-vindue, og hvor tab af pakker markant reducerer netv\u00e6rkets ydeevne.<\/p>\n
Men ikke al b\u00e5ndbredde bruges til at overf\u00f8re nyttige data. Man m\u00e5 tage hensyn til de s\u00e5kaldte overheadomkostninger<\/b> (overhead) b\u00e5ndbredde. Dette er den del af enhedens krypteringsb\u00e5ndbredde (i procent eller bytes pr. pakke), som faktisk g\u00e5r tabt (ikke kan anvendes til dataoverf\u00f8rsel). Omkostningerne opst\u00e5r f\u00f8rst og fremmest p\u00e5 grund af den \u00f8gede st\u00f8rrelse (tilf\u00f8jelser, 'padding') af datakent i krypterede netv\u00e6rkspakker (afh\u00e6ngig af krypteringsalgoritmen og dens driftstilstand). For det andet, p\u00e5 grund af den \u00f8gede l\u00e6ngde af pakkeoverskrifterne (tunnelmode, protokolindstillinger for kryptering, godkendelsestekster osv., afh\u00e6ngigt af protokollen og driftstilstanden for krypteringsmetoden og overf\u00f8rselsmetoden) \u2013 disse omkostninger er normalt de mest signifikante, og de f\u00e5r f\u00f8rst opm\u00e6rksomhed. For det tredje, p\u00e5 grund af fragmenteringen af pakker, n\u00e5r den maksimale datablokst\u00f8rrelse (MTU) overskrides (hvis netv\u00e6rket kan opdele pakker, der overskrider MTU, i to ved at duplikere deres overskrifter). For det fjerde, p\u00e5 grund af dannelsen af yderligere kontroltrafik i netv\u00e6rket mellem krypteringsanordningerne (til n\u00f8gleudveksling, oprettelse af tunneler osv.). Lave omkostninger er vigtige, hvor kanalens b\u00e5ndbredde er begr\u00e6nset. Dette ses is\u00e6r i trafikken fra sm\u00e5 pakker, for eksempel i taletrafik \u2013 her kan omkostningerne '\u00e6de' mere end halvdelen af kanalens hastighed!<\/p>\n
B\u00e5ndbredde<\/i><\/p>\n
Endelig er der ogs\u00e5 indf\u00f8rt latens<\/b> \u2013 forskellen (i br\u00f8kdeler af et sekund) i netv\u00e6rkslatens (tiden det tager for data at rejse fra indgangen til netv\u00e6rket til udgangen) mellem dataoverf\u00f8rsel uden netv\u00e6rkskryptering og med det. Generelt g\u00e6lder det, at jo mindre latens ('latenstid') netv\u00e6rket har, desto mere kritisk bliver den latens, der introduceres af krypteringsenhederne. Den latens, der introduceres, kommer fra selve krypteringsoperationen (afh\u00e6nger af krypteringsalgoritmen, blokl\u00e6ngden og driftsm\u00e5den af krypteringen samt kvaliteten af dens implementering i softwaren), samt behandlingen af netv\u00e6rkspakken i enheden. Den introducerede latens afh\u00e6nger b\u00e5de af behandlingsmetoden for pakkerne (end-to-end eller 'modtag og send') og enhedens ydeevne ('hardware'-implementering p\u00e5 FPGA eller ASIC er normalt hurtigere end 'software'-implementering p\u00e5 CPU). L2-kryptering har n\u00e6sten altid en lavere introduceret latens sammenlignet med kryptering p\u00e5 L3 eller L4: Dette skyldes, at enheder, der krypterer p\u00e5 L3\/L4, ofte er konvergerende. For eksempel, i h\u00f8jspeed Ethernet-kryptere, der er implementeret p\u00e5 FPGA og krypterer p\u00e5 L2, er latensen fra krypteringsoperationen ubetydelig \u2013 nogle gange, n\u00e5r kryptering aktiveres p\u00e5 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\u00f8rrelsesnetv\u00e6rk (distrikter p\u00e5 titusinder af kilometer i diameter) kan mikrosekunder betyde meget. For eksempel for synkron databasereplikering, h\u00f8jfrekvent handel og blockchain.<\/p>\n
Introduceret latens<\/i><\/p>\nSkalering<\/h4>\n
\nStorede distribuerede netv\u00e6rk kan omfatte mange tusinde noder og netv\u00e6rksenheder samt hundredevis af segmenter af lokale netv\u00e6rk. Det er vigtigt, at krypteringsl\u00f8sninger ikke p\u00e5l\u00e6gger yderligere begr\u00e6nsninger p\u00e5 st\u00f8rrelsen og topologien af det distribuerede netv\u00e6rk. Dette g\u00e6lder is\u00e6r det maksimale antal adresser p\u00e5 noder og netv\u00e6rk. Disse begr\u00e6nsninger kan for eksempel opst\u00e5 ved implementeringen af en multipunkt topologi for et krypteret netv\u00e6rk (med uafh\u00e6ngige sikre forbindelser eller tunneler) eller ved selektiv kryptering (for eksempel efter protokolnummer eller VLAN). Hvis netv\u00e6rksadresser (MAC, IP, VLAN ID) bruges som n\u00f8gler i en tabel, hvor antallet af r\u00e6kker er begr\u00e6nset, viser disse begr\u00e6nsninger sig tydeligt her.<\/p>\n
Desuden har store netv\u00e6rk ofte flere strukturelle niveauer, herunder kerne-netv\u00e6rk, hvor der implementeres forskellige adresseringsordninger og routingpolitikker. For at realisere en s\u00e5dan tilgang anvendes der ofte specialformater for rammer (som Q-in-Q eller MAC-in-MAC) og rutingsprotokoller. For ikke at hindre opbygningen af s\u00e5danne netv\u00e6rk, skal krypteringsudstyr korrekt kunne h\u00e5ndtere s\u00e5danne rammer (det vil sige, at skalerbarhed i denne sammenh\u00e6ng vil betyde kompatibilitet \u2013 mere om dette nedenfor).<\/p>\n
Fleksibilitet<\/h4>\n \nHer handler det om st\u00f8tte til forskellige konfigurationer, forbindelsesskemaer, topologier og mere. For eksempel betyder det for switchede netv\u00e6rk baseret p\u00e5 Carrier Ethernet-teknologier st\u00f8tte til forskellige typer virtuelle forbindelser (E-Line, E-LAN, E-Tree), forskellige servicetyper (b\u00e5de pr. porte og pr. VLAN) og forskellige transportteknologier (som n\u00e6vnt tidligere). Det vil sige, at udstyret skal kunne fungere b\u00e5de i line\u00e6r ('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\u00e6lge forskellige krypteringsdriftsformer (herunder med eller uden indholdsautentifikation) og forskellige pakkeoverf\u00f8rselsmetoder giver mulighed for at sikre en balance mellem modstandskraft og ydeevne afh\u00e6ngigt af de aktuelle forhold.<\/p>\n
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.<\/p>\n
If the device is acquired for a specific scenario, then all these features may not be very important \u2013 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 \u2013 especially considering the interoperability limitations of devices from different vendors (more on this below).<\/p>\n
Simplicity and convenience<\/h4>\n \nEase 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\"<\/b> (bump-in-the-wire), eller en gennemsigtig forbindelse, hvor tilf\u00f8jelse og frakobling af krypteringsenheder ikke kr\u00e6ver nogen manuelle eller automatiske \u00e6ndringer i netv\u00e6rkskonfigurationen. Dette forenkler vedligeholdelsen af l\u00f8sningen: man kan trygt t\u00e6nde og slukke krypteringsfunktionen, og n\u00e5r det er n\u00f8dvendigt, blot \"omg\u00e5\" enheden med et netv\u00e6rkskabel (det vil sige direkte forbinde de porte i netv\u00e6rksudstyret, som den var tilsluttet). Der er dog en ulempe \u2013 det samme kan ogs\u00e5 g\u00f8res af en ondsindet akt\u00f8r. For at implementere princippet \"enhed p\u00e5 ledningen\" skal man tage hensyn til trafikken ikke kun datalag<\/b>, men ogs\u00e5 kontrol- og administrationslag<\/b> \u2013 enhederne skal v\u00e6re gennemsigtige for dem. Derfor kan s\u00e5dan trafik kun krypteres, n\u00e5r der ikke er nogen modtagere af denne type trafik mellem krypteringsenhederne i netv\u00e6rket, for hvis den kasseres eller krypteres, kan netv\u00e6rkskonfigurationen \u00e6ndre sig, n\u00e5r krypteringen t\u00e6nder og slukker. Krypteringsenheden kan ogs\u00e5 v\u00e6re gennemsigtig for signalering p\u00e5 det fysiske niveau. Is\u00e6r i tilf\u00e6lde af signaltab skal den kunne videregive denne tab (det vil sige deaktivere sine sendere) frem og tilbage (\"for sig selv\") i retning af signalet.<\/p>\n
Det er ogs\u00e5 vigtigt at underst\u00f8tte opdelingen af bef\u00f8jelser mellem afdelingerne for informationssikkerhed (IB) og IT, is\u00e6r netv\u00e6rksafdelingen. L\u00f8sningen til kryptering skal underst\u00f8tte den adgangspunktmodel, der er vedtaget i organisationen, og audit. Behovet for interaktion mellem forskellige afdelinger til udf\u00f8relse af rutineopgaver b\u00f8r minimeres. Derfor er specialiserede enheder, der kun underst\u00f8tter krypteringsfunktioner og er s\u00e5 gennemsigtige som muligt for netv\u00e6rksoperationer, en fordel i forhold til brugervenlighed. Kort sagt, ansatte i IB-afdelingen b\u00f8r ikke have grund til at kontakte \"netv\u00e6rksfolkene\" for at \u00e6ndre netv\u00e6rksindstillingerne. Og omvendt b\u00f8r de heller ikke have behov for at \u00e6ndre krypteringsindstillingerne ved netv\u00e6rksvedligeholdelse.<\/p>\n
En anden faktor er mulighederne og brugervenligheden af administrationsv\u00e6rkt\u00f8jerne. De skal v\u00e6re overskuelige, logiske, muligg\u00f8re import- og eksport af indstillinger, automatisering osv. Man skal straks v\u00e6re opm\u00e6rksom p\u00e5, hvilke administrationsmuligheder der er tilg\u00e6ngelige (normalt en egen administrationsplatform, webgr\u00e6nseflade og kommandolinje) og hvilke funktioner der findes i hver af dem (der kan v\u00e6re begr\u00e6nsninger). En vigtig funktion er underst\u00f8ttelsen af out-of-band<\/b> styring, hvilket betyder via et dedikeret administrationsnetv\u00e6rk, og in-band<\/b> styring, hvilket betyder gennem det f\u00e6lles netv\u00e6rk, som overf\u00f8rer nyttetraffik. Administrationsv\u00e6rkt\u00f8jer skal signalere om alle unormale situationer, herunder sikkerhedsh\u00e6ndelser. Rutinepr\u00e6gede, gentagne operationer skal udf\u00f8res automatisk. Dette g\u00e6lder prim\u00e6rt for administrationsn\u00f8gler. Disse b\u00f8r genereres\/distribueres automatisk. Underst\u00f8ttelse af PKI er en stor fordel.<\/p>\nKompatibilitet<\/h4>\n
\nDet vil sige enhedens kompatibilitet med netv\u00e6rksstandarder. Herunder menes ikke kun industristandarder vedtaget af autoritative organisationer som IEEE, men ogs\u00e5 propriet\u00e6re protokoller fra branchens f\u00f8rende akt\u00f8rer som Cisco. Der er to grundl\u00e6ggende m\u00e5der at sikre kompatibilitet p\u00e5: enten gennem gennemsigtighed,<\/b>eller gennem explisitte underst\u00f8ttelse<\/b> af protokoller (n\u00e5r krypteringsenheden bliver en af noderne i netv\u00e6rket for en given protokol og behandler kontroltrafikken af denne protokol). Kompatibiliteten med netv\u00e6rk afh\u00e6nger af fuldst\u00e6ndigheden og korrektheden af implementeringen af kontrolprotokoller. Det er vigtigt at underst\u00f8tte forskellige PHY-niveauer (hastigheder, transmissionsmedier, kodningsordninger), Ethernet-rammer af forskellige formater med enhver MTU, samt forskellige L3 kontrolprotokoller (prim\u00e6rt fra TCP\/IP-familien).<\/p>\n
Gennemsigtighed opn\u00e5s gennem mekanismer som mutation (midlertidig \u00e6ndring af indholdet af \u00e5bne overskrifter i trafikken mellem krypteringsenheder), bypass (n\u00e5r enkelte pakker forbliver ukrypterede) og forskydning af begyndelsen af krypteringen (n\u00e5r de normalt krypterede felter i pakkerne ikke krypteres).<\/p>\n
Hvordan sikres gennemsigtigheden<\/i><\/p>\n
Derfor skal du altid afklare, hvordan underst\u00f8ttelsen af en given protokol sikres. Ofte er underst\u00f8ttelse i gennemsigtig tilstand mere praktisk og p\u00e5lidelig.<\/p>\n
Interoperabilitet<\/h4>\n \nDette handler ogs\u00e5 om kompatibilitet, men i en anden forstand, nemlig muligheden for samarbejde med andre krypteringsenheder, herunder fra andre producenter. Meget afh\u00e6nger af tilstanden for standardisering af krypteringsprotokoller. Der findes simpelthen ikke almindeligt anerkendte krypteringsstandarder p\u00e5 L1.<\/p>\n
Til kryptering L2 i Ethernet-netv\u00e6rk findes standarden 802.1ae (MACsec), men den bruger ikke end-to-end<\/b> (end-to-end), men interport<\/b>, \"hop-by-hop\" kryptering, og i sin oprindelige version var den uegnet til brug i distribuerede netv\u00e6rk, hvorfor der opstod egne udvidelser, der overvinder denne begr\u00e6nsning (selvf\u00f8lgelig p\u00e5 bekostning af interoperabilitet med udstyr fra andre producenter). Det skal dog n\u00e6vnes, at der i 2018 blev tilf\u00f8jet underst\u00f8ttelse af distribuerede netv\u00e6rk i standarden 802.1ae, men underst\u00f8ttelse af GOST-krypteringsalgoritmer er stadig ikke til stede. Derfor adskiller propriet\u00e6re, ikke-standardiserede L2-krypteringsprotokoller sig typisk ved h\u00f8jere effektivitet (is\u00e6r mindre b\u00e5ndbreddeoverhead) og fleksibilitet (muligheden for at \u00e6ndre algoritmer og krypteringsmetoder).<\/p>\n
P\u00e5 h\u00f8jere niveauer (L3 og L4) findes der anerkendte standarder, prim\u00e6rt IPsec og TLS, men heller ikke her er alt s\u00e5 enkelt. Problemet er, at hver af disse standarder er et s\u00e6t protokoller, hvor hver enkelt har forskellige versioner samt obligatoriske eller valgfrie udvidelser. Desuden foretr\u00e6kker nogle producenter at anvende deres egne propriet\u00e6re krypteringsprotokoller ogs\u00e5 p\u00e5 L3\/L4. Derfor skal man i mange tilf\u00e6lde 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>\n
P\u00e5lidelighed<\/h4>\n \nTil sammenligning af forskellige l\u00f8sninger kan man anvende enten den gennemsnitlige tid til fejl eller tilg\u00e6ngelighedsfaktoren. Hvis disse tal ikke er tilg\u00e6ngelige (eller ikke kan stole p\u00e5), kan der udf\u00f8res en kvalitativ sammenligning. Fordelen vil v\u00e6re hos enheder med nem administration (mindre risiko for konfigurationsfejl), hos specialiserede krypteringsenheder (af samme \u00e5rsag), samt hos l\u00f8sninger med minimal tid til detektion og l\u00f8sning af fejl, herunder metoder til \"hot\" redundans af noder og enheder helt.<\/p>\n
Omkostninger<\/h4>\n \nN\u00e5r det kommer til omkostninger, er det som med de fleste IT-l\u00f8sninger 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\u00e6rkskrypteringsl\u00f8sning best\u00e5r af direkte<\/b> omkostninger til k\u00f8b eller leje af selve l\u00f8sningen, 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<\/b> omkostninger fra nedetid for l\u00f8sningen (for\u00e5rsaget af tab af produktivitet blandt slutbrugere). Der er m\u00e5ske kun \u00e9n nuance. Virkningen af l\u00f8sningens ydeevne kan vurderes p\u00e5 forskellige m\u00e5der: enten som indirekte omkostninger for\u00e5rsaget af faldende produktivitet eller som \"virtuel\" direkte omkostning til k\u00f8b\/opgradering og vedligeholdelse af netv\u00e6rksmidler, der kompenserer for faldet i netv\u00e6rksydelsen p\u00e5 grund af anvendelsen af kryptering. Under alle omst\u00e6ndigheder er det bedre at \"lade omkostningerne, som er sv\u00e6re at beregne med tilstr\u00e6kkelig pr\u00e6cision, ligge uden for\" beregningen: det vil skabe mere tillid til den endelige st\u00f8rrelse. Som s\u00e6dvanligt giver det mening at sammenligne forskellige enheder efter TCO i forhold til et konkret anvendelsesscenarie \u2013 reelt eller typisk.<\/p>\nRobusthed<\/h4>\n
\nDen sidste egenskab er robustheden af l\u00f8sningen. I de fleste tilf\u00e6lde kan robusthed kun vurderes kvalitativt ved at sammenligne forskellige l\u00f8sninger. Vi skal huske, at krypteringsenheder ikke blot er v\u00e6rkt\u00f8jer, men ogs\u00e5 beskyttelsesobjekter. De kan v\u00e6re udsat for forskellige trusler. P\u00e5 f\u00f8rstepladsen st\u00e5r trusler mod fortroligheden, reproduktion og \u00e6ndring af beskeder. Disse trusler kan realiseres gennem s\u00e5rbarheder i krypteringsalgoritmen eller dens tilstande, samt ved s\u00e5rbarheder i krypteringsprotokoller (herunder i faserne for oprettelse af forbindelse og generering\/distribution af n\u00f8gler). Fordelen vil tilkomme l\u00f8sninger, der tillader \u00e6ndring af krypteringsalgoritmen eller skift af krypteringstilstand (i det mindste gennem opdatering af firmware), hos l\u00f8sninger, der sikrer maksimal kryptering og skjuler ikke kun brugerdata, men ogs\u00e5 adresse- og anden hj\u00e6lpedata fra angriberen, samt hos de l\u00f8sninger, der ikke kun krypterer, men ogs\u00e5 beskytter beskeder mod reproduktion og \u00e6ndring. For alle moderne algoritmer til kryptering, digital signatur, n\u00f8glegenerering med videre, der er fastsat i standarderne, kan robustheden anses for at v\u00e6re ens (ellers kan man let fare vild i kryptografiens jungle). Skal det n\u00f8dvendigvis v\u00e6re GOST-algoritmer? Her er svaret enkelt: hvis anvendelsesscenariet kr\u00e6ver certificering fra FSB for SKZI (og i Rusland er det ofte tilf\u00e6ldet), for de fleste scenarier for netv\u00e6rkskryptering er det tilf\u00e6ldet), s\u00e5 v\u00e6lger vi kun mellem de certificerede. Hvis ikke \u2013 s\u00e5 er der heller ikke nogen grund til at udelukke enheder uden certificering fra overvejelserne.<\/p>\n
En anden trussel er truslen om hacking, uautoriseret adgang til enheder (herunder gennem fysisk adgang udefra og indefra kabinettet). Truslen kan realiseres gennem
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\u00f8sninger, der ofte er rettet mod erfarne \"netv\u00e6rksfolk\" og kan medf\u00f8re vanskeligheder for \"almindelige\", bredt funderede IT-specialister.<\/p>\n
Sammenfatning<\/h4>\n \nI princippet kunne der her foresl\u00e5s et eller andet integreret indeks til sammenligning af forskellige enheder, noget som<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\nhvor p er v\u00e6gten af indikatoren, og r er rangeringen af enheden efter denne indikator, idet enhver af de ovenn\u00e6vnte egenskaber kan opdeles i \"atom\u00e6re\" m\u00e5l. S\u00e5dan en formel kunne v\u00e6re nyttig, for eksempel ved sammenligning af tilbud ved hj\u00e6lp af p\u00e5 forh\u00e5nd aftalte regler. Men man kan ogs\u00e5 n\u00f8jes med en simpel tabel som<\/p>\n
Specifikation
B\u00e5ndbredde
+++<\/p>\n
Overheadomkostninger
+++<\/p>\n
Forsinkelse
++<\/p>\n
Skalering
+++<\/p>\n
Fleksibilitet
+<\/p>\n
Interoperabilitet
+<\/p>\n
Kompatibilitet
+++<\/p>\n
Simplicity and convenience
++<\/p>\n
Fejltolerance
++<\/p>\n
Omkostninger
+<\/p>\n
Robusthed
+++<\/p>\n
\nJeg vil v\u00e6re glad for at besvare sp\u00f8rgsm\u00e5l og konstruktive kritiske bem\u00e6rkninger.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