Hoe coderingsapparaten voor Ethernet-netwerken te evalueren en te vergelijken

Ik schreef deze recensie (of, als je dat liever hebt, een vergelijkingsgids) toen ik de opdracht kreeg om verschillende apparaten van verschillende leveranciers te vergelijken. Bovendien behoorden deze apparaten tot verschillende klassen. Ik moest de architectuur en kenmerken van al deze apparaten begrijpen en een ‘coördinatensysteem’ creëren ter vergelijking. Ik zal blij zijn als mijn recensie iemand helpt:

• Begrijp de beschrijvingen en specificaties van versleutelingsapparaten
• Maak onderscheid tussen ‘papieren’ kenmerken en kenmerken die in het echte leven echt belangrijk zijn
• Ga verder dan de gebruikelijke reeks leveranciers en neem alle producten mee die geschikt zijn om het probleem op te lossen
• Stel de juiste vragen tijdens de onderhandelingen
• Opstellen aanbestedingseisen (RFP)
• Begrijp welke kenmerken moeten worden opgeofferd als een bepaald apparaatmodel wordt geselecteerd

Wat kan worden beoordeeld

In principe is de aanpak toepasbaar op alle standalone apparaten die geschikt zijn voor het coderen van netwerkverkeer tussen externe Ethernet-segmenten (cross-site encryptie). Dat wil zeggen, “boxen” in een apart geval (oké, we nemen hier ook blades/modules voor het chassis op), die via een of meer Ethernet-poorten zijn verbonden met een lokaal (campus) Ethernet-netwerk met niet-versleuteld verkeer, en via een andere poort(en) naar een kanaal/netwerk waardoor reeds gecodeerd verkeer naar andere, afgelegen segmenten wordt verzonden. Een dergelijke versleutelingsoplossing kan worden ingezet in een particulier of operatornetwerk via verschillende soorten ‘transport’ (dark fiber, apparatuur voor frequentieverdeling, geschakeld Ethernet, maar ook ‘pseudodraden’ die via een netwerk met een andere routeringsarchitectuur, meestal MPLS, worden gelegd). ), met of zonder VPN-technologie.

Netwerkcodering in een gedistribueerd Ethernet-netwerk

De apparaten zelf kunnen beide zijn gespecialiseerd (uitsluitend bedoeld voor encryptie), of multifunctioneel (hybride, convergerend), dat wil zeggen, ook andere functies uitvoeren (bijvoorbeeld een firewall of router). Verschillende leveranciers classificeren hun apparaten in verschillende klassen/categorieën, maar dit doet er niet toe - het enige belangrijke is of ze cross-site verkeer kunnen versleutelen en welke kenmerken ze hebben.

Voor het geval dat, herinner ik u eraan dat “netwerkencryptie”, “verkeersencryptie”, “encryptor” informele termen zijn, hoewel ze vaak worden gebruikt. U zult ze waarschijnlijk niet vinden in de Russische regelgeving (inclusief de regelgeving die GOST's introduceert).

Encryptieniveaus en transmissiemodi

Voordat we de kenmerken zelf gaan beschrijven die voor evaluatie zullen worden gebruikt, zullen we eerst één belangrijk ding moeten begrijpen, namelijk het ‘encryptieniveau’. Het viel mij op dat het vaak genoemd wordt, zowel in officiële leveranciersdocumenten (in beschrijvingen, handleidingen, etc.) als in informele discussies (bij onderhandelingen, trainingen). Dat wil zeggen, iedereen lijkt heel goed te weten waar we het over hebben, maar ik ben persoonlijk getuige geweest van enige verwarring.

Dus wat is een “encryptieniveau”? Het is duidelijk dat we het hebben over het nummer van de OSI/ISO-referentienetwerkmodellaag waarop encryptie plaatsvindt. We lezen GOST R ISO 7498-2–99 “Informatietechnologie. Interconnectie van open systemen. Basis referentiemodel. Deel 2. Architectuur voor informatiebeveiliging.” Uit dit document kan worden opgemaakt dat het niveau van de vertrouwelijkheidsdienst (een van de mechanismen voor het verstrekken ervan, namelijk encryptie) het niveau is van het protocol, waarvan het servicedatablok (“payload”, gebruikersgegevens) is gecodeerd. Zoals ook in de standaard staat, kan de dienst zowel op hetzelfde niveau, “op zichzelf”, als met behulp van een lager niveau worden geleverd (zo wordt deze bijvoorbeeld het vaakst geïmplementeerd in MACsec) .

In de praktijk zijn er twee manieren mogelijk om gecodeerde informatie over een netwerk te verzenden (ik denk meteen aan IPsec, maar dezelfde modi vind je ook in andere protocollen). IN vervoer (soms ook native genoemd)-modus is alleen gecodeerd dienst blok met gegevens en de headers blijven "open", niet-versleuteld (soms worden extra velden met service-informatie van het versleutelingsalgoritme toegevoegd en worden andere velden gewijzigd en opnieuw berekend). IN tunnel allemaal dezelfde modus protocol het datablok (dat wil zeggen het pakket zelf) is gecodeerd en ingekapseld in een servicedatablok van hetzelfde of een hoger niveau, dat wil zeggen dat het is omgeven door nieuwe headers.

Het encryptieniveau zelf in combinatie met een bepaalde transmissiemodus is niet goed of slecht, dus er kan bijvoorbeeld niet worden gezegd dat L3 in transportmodus beter is dan L2 in tunnelmodus. Het is gewoon zo dat veel van de kenmerken waarop apparaten worden beoordeeld ervan afhankelijk zijn. Bijvoorbeeld flexibiliteit en compatibiliteit. Om in een netwerk L1 (bitstream relay), L2 (frame-switching) en L3 (pakketroutering) in transportmodus te werken, heb je oplossingen nodig die op hetzelfde of een hoger niveau coderen (anders wordt de adresinformatie gecodeerd en worden de gegevens versleuteld). de beoogde bestemming niet bereiken), en de tunnelmodus overwint deze beperking (hoewel andere belangrijke kenmerken worden opgeofferd).

Transport- en tunnel L2-coderingsmodi

Laten we nu verder gaan met het analyseren van de kenmerken.

Производительность

Voor netwerkversleuteling zijn prestaties een complex, multidimensionaal concept. Het komt voor dat een bepaald model, hoewel superieur in één prestatiekenmerk, inferieur is in een ander prestatiekenmerk. Daarom is het altijd nuttig om alle componenten van de encryptieprestaties in overweging te nemen en hun impact op de prestaties van het netwerk en de applicaties die er gebruik van maken. Hier kunnen we een analogie trekken met een auto, waarvoor niet alleen de maximale snelheid belangrijk is, maar ook de acceleratietijd tot "honderden", het brandstofverbruik, enzovoort. Leveranciersbedrijven en hun potentiële klanten besteden veel aandacht aan prestatiekenmerken. In de regel worden versleutelingsapparaten gerangschikt op basis van de prestaties van de leveranciers.

Het is duidelijk dat de prestaties zowel afhangen van de complexiteit van de netwerk- en cryptografische bewerkingen die op het apparaat worden uitgevoerd (inclusief hoe goed deze taken kunnen worden geparalleliseerd en gepijplijnd), als van de prestaties van de hardware en de kwaliteit van de firmware. Daarom gebruiken oudere modellen productievere hardware, soms is het mogelijk om deze uit te rusten met extra processors en geheugenmodules. Er zijn verschillende benaderingen voor het implementeren van cryptografische functies: op een centrale verwerkingseenheid (CPU) voor algemeen gebruik, toepassingsspecifieke geïntegreerde schakeling (ASIC) of veldprogrammable logic Integrated Circuit (FPGA). Elke aanpak heeft zijn voor- en nadelen. De CPU kan bijvoorbeeld een knelpunt bij de codering worden, vooral als de processor niet over gespecialiseerde instructies beschikt om het coderingsalgoritme te ondersteunen (of als deze niet worden gebruikt). Gespecialiseerde chips missen flexibiliteit; het is niet altijd mogelijk om ze te ‘reflashen’ om de prestaties te verbeteren, nieuwe functies toe te voegen of kwetsbaarheden te elimineren. Bovendien wordt het gebruik ervan alleen winstgevend bij grote productievolumes. Dat is de reden waarom de “gulden middenweg” zo populair is geworden: het gebruik van FPGA (FPGA in het Russisch). Het is op FPGA's dat de zogenaamde cryptoversnellers worden gemaakt: ingebouwde of plug-in gespecialiseerde hardwaremodules ter ondersteuning van cryptografische bewerkingen.

Aangezien we het over hebben netwerk encryptie, is het logisch dat de prestaties van oplossingen in dezelfde hoeveelheden moeten worden gemeten als voor andere netwerkapparaten: doorvoer, percentage frameverlies en latentie. Deze waarden zijn gedefinieerd in RFC 1242. Over de vaak genoemde vertragingsvariatie (jitter) wordt in deze RFC overigens niets geschreven. Hoe deze hoeveelheden te meten? Ik heb in geen enkele standaard (officieel of niet-officieel zoals RFC) een methodologie gevonden die specifiek is goedgekeurd voor netwerkversleuteling. Het zou logisch zijn om de methodologie te gebruiken voor netwerkapparaten die is vastgelegd in de standaard RFC 2544. Veel leveranciers volgen deze - veel, maar niet allemaal. Ze sturen testverkeer bijvoorbeeld slechts in één richting in plaats van in beide richtingen aanbevolen standaard. Hoe dan ook.

Het meten van de prestaties van netwerkversleutelingsapparaten heeft nog steeds zijn eigen kenmerken. Ten eerste is het correct om alle metingen voor een paar apparaten uit te voeren: hoewel de versleutelingsalgoritmen symmetrisch zijn, zullen vertragingen en pakketverliezen tijdens het versleutelen en ontsleutelen niet noodzakelijkerwijs gelijk zijn. Ten tweede is het zinvol om de delta, de impact van netwerkversleuteling op de uiteindelijke netwerkprestaties, te meten, door twee configuraties te vergelijken: zonder versleutelingsapparaten en met versleutelingsapparaten. Of, zoals het geval is bij hybride apparaten, die naast netwerkversleuteling meerdere functies combineren, waarbij versleuteling aan en uit staat. Deze invloed kan verschillend zijn en afhankelijk zijn van het verbindingsschema van de versleutelingsapparaten, van de bedrijfsmodi en ten slotte van de aard van het verkeer. In het bijzonder zijn veel prestatieparameters afhankelijk van de lengte van pakketten. Daarom worden, om de prestaties van verschillende oplossingen te vergelijken, vaak grafieken van deze parameters gebruikt, afhankelijk van de lengte van pakketten, of wordt IMIX gebruikt - de verdeling van verkeer per pakket lengtes, die ongeveer de echte weerspiegelen. Als we dezelfde basisconfiguratie zonder codering vergelijken, kunnen we oplossingen voor netwerkcodering vergelijken die anders zijn geïmplementeerd zonder op deze verschillen in te gaan: L2 met L3, store-and-forward ) met cut-through, gespecialiseerd met convergent, GOST met AES enzovoort.

Aansluitschema voor prestatietests

Het eerste kenmerk waar mensen op letten is de ‘snelheid’ van het versleutelingsapparaat bandbreedte (bandbreedte) van zijn netwerkinterfaces, bitstroomsnelheid. Dit wordt bepaald door de netwerkstandaarden die door de interfaces worden ondersteund. Voor Ethernet zijn de gebruikelijke getallen 1 Gbps en 10 Gbps. Maar zoals we weten, is in elk netwerk het maximale theoretisch doorvoer (doorvoer) op elk van zijn niveaus is er altijd minder bandbreedte: een deel van de bandbreedte wordt “opgegeten” door interframe-intervallen, serviceheaders, enzovoort. Als een apparaat in staat is verkeer te ontvangen, verwerken (in ons geval coderen of decoderen) en verzenden op de volledige snelheid van de netwerkinterface, dat wil zeggen met de maximale theoretische doorvoer voor dit niveau van het netwerkmodel, dan wordt er gezegd aan het werk zijn op lijnsnelheid. Om dit te doen is het noodzakelijk dat het apparaat geen pakketten van welke grootte en frequentie dan ook verliest of weggooit. Als het versleutelingsapparaat geen werking op lijnsnelheid ondersteunt, wordt de maximale doorvoersnelheid doorgaans gespecificeerd in dezelfde gigabits per seconde (waarbij soms de lengte van de pakketten wordt aangegeven - hoe korter de pakketten, hoe lager de doorvoersnelheid doorgaans is). Het is erg belangrijk om te begrijpen dat de maximale doorvoer het maximale is geen verlies (zelfs als het apparaat verkeer met een hogere snelheid door zichzelf kan 'pompen', maar tegelijkertijd enkele pakketten verliest). Houd er ook rekening mee dat sommige leveranciers de totale doorvoer tussen alle poortparen meten, dus deze cijfers betekenen niet veel als al het gecodeerde verkeer via één enkele poort gaat.

Waar is het vooral belangrijk om op lijnsnelheid te werken (of, met andere woorden, zonder pakketverlies)? Bij verbindingen met hoge bandbreedte en hoge latentie (zoals satelliet), waar een groot TCP-venster moet worden ingesteld om hoge transmissiesnelheden te behouden, en waar pakketverlies de netwerkprestaties dramatisch vermindert.

Maar niet alle bandbreedte wordt gebruikt om nuttige gegevens over te dragen. We moeten rekening houden met de zogenaamde overheadkosten (overhead) bandbreedte. Dit is het deel van de doorvoer van het versleutelingsapparaat (als percentage of bytes per pakket) dat feitelijk verloren gaat (kan niet worden gebruikt om applicatiegegevens over te dragen). Overheadkosten ontstaan ​​in de eerste plaats door een toename van de omvang (toevoeging, “stuffing”) van het dataveld in gecodeerde netwerkpakketten (afhankelijk van het coderingsalgoritme en de werkingsmodus ervan). Ten tweede, vanwege de toename van de lengte van pakketheaders (tunnelmodus, service-invoeging van het encryptieprotocol, simulatie-invoeging, enz., afhankelijk van het protocol en de werkingsmodus van de coderings- en transmissiemodus) - zijn deze overheadkosten meestal de belangrijkste, en zij letten eerst op. Ten derde, als gevolg van fragmentatie van pakketten wanneer de maximale data-eenheidgrootte (MTU) wordt overschreden (als het netwerk in staat is een pakket dat de MTU overschrijdt in tweeën te splitsen, waarbij de headers ervan worden gedupliceerd). Ten vierde vanwege het optreden van extra service(controle)verkeer op het netwerk tussen encryptie-apparaten (voor sleuteluitwisseling, tunnelinstallatie, enz.). Lage overhead is belangrijk als de kanaalcapaciteit beperkt is. Dit is vooral duidelijk bij verkeer van kleine pakketjes, bijvoorbeeld spraak – waarbij overheadkosten meer dan de helft van de kanaalsnelheid kunnen “opeten”!

Doorvoer

Tot slot is er meer vertraging geïntroduceerd – het verschil (in fracties van een seconde) in netwerkvertraging (de tijd die gegevens nodig hebben om het netwerk binnen te komen en het te verlaten) tussen gegevensoverdracht zonder en met netwerkversleuteling. Over het algemeen geldt dat hoe lager de latentie (“latency”) van het netwerk, hoe kritischer de latentie wordt die door encryptie-apparaten wordt geïntroduceerd. De vertraging wordt veroorzaakt door de codering zelf (afhankelijk van het coderingsalgoritme, de bloklengte en de werkingsmodus van het cijfer, evenals van de kwaliteit van de implementatie ervan in de software) en de verwerking van het netwerkpakket in het apparaat . De geïntroduceerde latentie hangt af van zowel de pakketverwerkingsmodus (pass-through of store-and-forward) als de prestaties van het platform (hardware-implementatie op een FPGA of ASIC is over het algemeen sneller dan software-implementatie op een CPU). L2-versleuteling heeft bijna altijd een lagere latentie dan L3- of L4-versleuteling, vanwege het feit dat L3/L4-versleutelingsapparaten vaak geconvergeerd zijn. Met snelle Ethernet-encryptors die zijn geïmplementeerd op FPGA's en encryptie op L2, is de vertraging als gevolg van de encryptiebewerking bijvoorbeeld verdwijnend klein. Wanneer encryptie op een paar apparaten is ingeschakeld, neemt de totale vertraging die daardoor wordt geïntroduceerd zelfs zelfs af! Een lage latentie is belangrijk als deze vergelijkbaar is met de totale kanaalvertragingen, inclusief voortplantingsvertraging, die ongeveer 5 μs per kilometer bedraagt. Dat wil zeggen dat we kunnen zeggen dat voor netwerken op stedelijke schaal (tientallen kilometers in doorsnee) microseconden veel kunnen beslissen. Voor synchrone databasereplicatie, hoogfrequente handel, dezelfde blockchain.

Vertraging geïntroduceerd

Schaalbaarheid

Grote gedistribueerde netwerken kunnen vele duizenden knooppunten en netwerkapparaten omvatten, en honderden lokale netwerksegmenten. Het is belangrijk dat encryptieoplossingen geen extra beperkingen opleggen aan de omvang en topologie van het gedistribueerde netwerk. Dit geldt vooral voor het maximale aantal host- en netwerkadressen. Dergelijke beperkingen kunnen bijvoorbeeld optreden bij het implementeren van een op meerdere punten gecodeerde netwerktopologie (met onafhankelijke beveiligde verbindingen of tunnels) of selectieve codering (bijvoorbeeld op protocolnummer of VLAN). Als in dit geval netwerkadressen (MAC, IP, VLAN ID) worden gebruikt als sleutels in een tabel waarin het aantal rijen beperkt is, verschijnen deze beperkingen hier.

Bovendien hebben grote netwerken vaak meerdere structurele lagen, waaronder het kernnetwerk, die elk hun eigen adresseringsschema en hun eigen routeringsbeleid implementeren. Om deze aanpak te implementeren, worden vaak speciale frameformaten (zoals Q-in-Q of MAC-in-MAC) en routebepalingsprotocollen gebruikt. Om de constructie van dergelijke netwerken niet te belemmeren, moeten encryptie-apparaten dergelijke frames correct verwerken (dat wil zeggen dat schaalbaarheid in deze zin compatibiliteit betekent - daarover hieronder meer).

flexibiliteit

Hier hebben we het over het ondersteunen van verschillende configuraties, verbindingsschema's, topologieën en andere dingen. Voor geschakelde netwerken op basis van Carrier Ethernet-technologieën betekent dit bijvoorbeeld ondersteuning voor verschillende soorten virtuele verbindingen (E-Line, E-LAN, E-Tree), verschillende soorten diensten (zowel per poort als VLAN) en verschillende transporttechnologieën (ze zijn hierboven al vermeld). Dat wil zeggen dat het apparaat in zowel lineaire (“point-to-point”) als multipoint-modi moet kunnen werken, afzonderlijke tunnels voor verschillende VLAN’s tot stand moet kunnen brengen en het in de verkeerde volgorde afleveren van pakketten binnen een beveiligd kanaal mogelijk moet maken. Dankzij de mogelijkheid om verschillende coderingsmodi (inclusief met of zonder inhoudauthenticatie) en verschillende pakkettransmissiemodi te selecteren, kunt u een balans vinden tussen kracht en prestaties, afhankelijk van de huidige omstandigheden.

Het is ook belangrijk om zowel particuliere netwerken, waarvan de apparatuur eigendom is van één organisatie (of daaraan verhuurd), als operatornetwerken, waarvan verschillende segmenten door verschillende bedrijven worden beheerd, te ondersteunen. Het is goed als de oplossing beheer zowel intern als door een derde partij mogelijk maakt (met behulp van een beheerd servicemodel). In operatornetwerken is een andere belangrijke functie de ondersteuning van multi-tenancy (delen door verschillende klanten) in de vorm van cryptografische isolatie van individuele klanten (abonnees) wier verkeer door dezelfde set encryptie-apparaten gaat. Dit vereist doorgaans het gebruik van afzonderlijke sets sleutels en certificaten voor elke klant.

Als een apparaat voor een specifiek scenario wordt gekocht, zijn al deze functies misschien niet erg belangrijk: u hoeft er alleen maar voor te zorgen dat het apparaat ondersteunt wat u nu nodig heeft. Maar als een oplossing wordt aangeschaft ‘voor groei’, om ook toekomstige scenario’s te ondersteunen, en wordt gekozen als ‘bedrijfsstandaard’, dan zal flexibiliteit niet overbodig zijn – vooral als we rekening houden met de beperkingen op de interoperabiliteit van apparaten van verschillende leveranciers ( meer hierover hieronder).

Eenvoud en gemak

Servicegemak is ook een multifactorieel concept. Bij benadering kunnen we zeggen dat dit de totale tijd is die specialisten met een bepaalde kwalificatie nodig hebben om een ​​oplossing in verschillende stadia van de levenscyclus te ondersteunen. Als er geen kosten aan verbonden zijn en installatie, configuratie en bediening volledig automatisch gebeuren, dan zijn de kosten nul en is het gemak absoluut. Natuurlijk gebeurt dit niet in de echte wereld. Een redelijke benadering is een model "knoop aan een draad" (bump-in-the-wire), of transparante verbinding, waarbij het toevoegen en uitschakelen van encryptie-apparaten geen handmatige of automatische wijzigingen aan de netwerkconfiguratie vereist. Tegelijkertijd is het onderhoud van de oplossing vereenvoudigd: u kunt de coderingsfunctie veilig in- en uitschakelen en, indien nodig, het apparaat eenvoudigweg "omzeilen" met een netwerkkabel (dat wil zeggen, rechtstreeks de poorten van de netwerkapparatuur aansluiten waarop het was aangesloten). Toegegeven, er is één nadeel: een aanvaller kan hetzelfde doen. Om het "node on a wire" -principe te implementeren, moet niet alleen rekening worden gehouden met het verkeer gegevenslaagMaar controle- en managementlagen – apparaten moeten voor hen transparant zijn. Daarom kan dergelijk verkeer alleen worden gecodeerd als er geen ontvangers van dit soort verkeer in het netwerk tussen de coderingsapparaten zijn. Als het wordt weggegooid of gecodeerd, kan de netwerkconfiguratie veranderen wanneer u codering in- of uitschakelt. Het versleutelingsapparaat kan ook transparant zijn voor fysieke laagsignalering. In het bijzonder, wanneer een signaal verloren gaat, moet het dit verlies (dat wil zeggen de zenders uitschakelen) heen en weer (“voor zichzelf”) in de richting van het signaal verzenden.

Ook ondersteuning bij de bevoegdheidsverdeling tussen de afdelingen informatiebeveiliging en IT, in het bijzonder de netwerkafdeling, is van belang. De encryptieoplossing moet het toegangscontrole- en auditmodel van de organisatie ondersteunen. De noodzaak voor interactie tussen verschillende afdelingen om routinematige handelingen uit te voeren moet tot een minimum worden beperkt. Daarom is er een voordeel in termen van gemak voor gespecialiseerde apparaten die uitsluitend encryptiefuncties ondersteunen en zo transparant mogelijk zijn voor netwerkactiviteiten. Simpel gezegd: informatiebeveiligingsmedewerkers zouden geen reden moeten hebben om contact op te nemen met “netwerkspecialisten” om netwerkinstellingen te wijzigen. En die zouden op hun beurt niet de noodzaak moeten hebben om de encryptie-instellingen te wijzigen bij het onderhouden van het netwerk.

Een andere factor zijn de mogelijkheden en het gemak van de bedieningselementen. Ze moeten visueel en logisch zijn, import-export van instellingen, automatisering, enzovoort bieden. U moet onmiddellijk letten op welke beheeropties beschikbaar zijn (meestal hun eigen beheeromgeving, webinterface en opdrachtregel) en welke reeks functies elk van hen heeft (er zijn beperkingen). Een belangrijke functie is ondersteuning buiten de band (out-of-band) controle, dat wil zeggen via een speciaal controlenetwerk, en in-band (in-band) controle, dat wil zeggen via een gemeenschappelijk netwerk waarlangs nuttig verkeer wordt verzonden. Managementtools moeten alle abnormale situaties signaleren, inclusief informatiebeveiligingsincidenten. Routinematige, repetitieve handelingen moeten automatisch worden uitgevoerd. Het gaat hierbij vooral om het sleutelbeheer. Ze moeten automatisch worden gegenereerd/gedistribueerd. PKI-ondersteuning is een groot pluspunt.

Verenigbaarheid

Dat wil zeggen, de compatibiliteit van het apparaat met netwerkstandaarden. Bovendien betekent dit niet alleen industriële standaarden die zijn overgenomen door gezaghebbende organisaties zoals IEEE, maar ook eigen protocollen van marktleiders, zoals Cisco. Er zijn twee manieren om compatibiliteit te garanderen: via transparantie, of via expliciete ondersteuning protocollen (wanneer een versleutelingsapparaat een van de netwerkknooppunten voor een bepaald protocol wordt en het controleverkeer van dit protocol verwerkt). Compatibiliteit met netwerken hangt af van de volledigheid en juistheid van de implementatie van besturingsprotocollen. Het is belangrijk om verschillende opties te ondersteunen voor het PHY-niveau (snelheid, transmissiemedium, coderingsschema), Ethernet-frames van verschillende formaten met elke MTU, verschillende L3-serviceprotocollen (voornamelijk de TCP/IP-familie).

Transparantie wordt verzekerd door de mechanismen van mutatie (tijdelijk veranderen van de inhoud van open headers in verkeer tussen encryptors), overslaan (wanneer individuele pakketten niet-versleuteld blijven) en inspringen van het begin van de versleuteling (wanneer normaal versleutelde velden van pakketten niet worden versleuteld).

Hoe transparantie wordt gewaarborgd

Controleer daarom altijd precies hoe ondersteuning voor een bepaald protocol wordt geboden. Vaak is ondersteuning in de transparante modus handiger en betrouwbaarder.

Interoperabiliteit

Dit is ook compatibiliteit, maar in een andere zin, namelijk de mogelijkheid om samen te werken met andere modellen versleutelingsapparaten, ook die van andere fabrikanten. Veel hangt af van de mate van standaardisatie van encryptieprotocollen. Er zijn eenvoudigweg geen algemeen aanvaarde encryptiestandaarden op L1.

Er bestaat een 2ae (MACsec)-standaard voor L802.1-codering op Ethernet-netwerken, maar deze maakt geen gebruik van eind tot eind (end-to-end), en interporteren, “hop-by-hop”-codering, en is in de oorspronkelijke versie niet geschikt voor gebruik in gedistribueerde netwerken, dus zijn er eigen extensies verschenen die deze beperking overwinnen (uiteraard vanwege de interoperabiliteit met apparatuur van andere fabrikanten). Het is waar dat in 2018 ondersteuning voor gedistribueerde netwerken is toegevoegd aan de 802.1ae-standaard, maar er is nog steeds geen ondersteuning voor GOST-coderingsalgoritmen. Daarom onderscheiden propriëtaire, niet-standaard L2-encryptieprotocollen zich in de regel door grotere efficiëntie (in het bijzonder lagere bandbreedte-overhead) en flexibiliteit (de mogelijkheid om encryptie-algoritmen en -modi te veranderen).

Op hogere niveaus (L3 en L4) zijn er erkende standaarden, vooral IPsec en TLS, maar ook hier is het niet zo eenvoudig. Feit is dat elk van deze standaarden een reeks protocollen is, elk met verschillende versies en uitbreidingen die vereist of optioneel zijn voor implementatie. Bovendien geven sommige fabrikanten er de voorkeur aan hun eigen encryptieprotocollen te gebruiken op L3/L4. Daarom moet u in de meeste gevallen niet rekenen op volledige interoperabiliteit, maar het is belangrijk dat in ieder geval de interactie tussen verschillende modellen en verschillende generaties van dezelfde fabrikant gewaarborgd is.

Betrouwbaarheid

Om verschillende oplossingen te vergelijken, kunt u de gemiddelde tijd tussen storingen of de beschikbaarheidsfactor gebruiken. Als deze cijfers niet beschikbaar zijn (of er geen vertrouwen in is), kan een kwalitatieve vergelijking worden gemaakt. Apparaten met handig beheer zullen een voordeel hebben (minder risico op configuratiefouten), gespecialiseerde encryptors (om dezelfde reden), evenals oplossingen met minimale tijd om een ​​storing te detecteren en te elimineren, inclusief middelen voor ‘hot’ back-up van volledige knooppunten en apparaten.

kosten

Als het om de kosten gaat, is het, zoals bij de meeste IT-oplossingen, zinvol om de totale eigendomskosten te vergelijken. Om dit te berekenen, hoeft u het wiel niet opnieuw uit te vinden, maar gebruikt u een geschikte methodologie (bijvoorbeeld van Gartner) en een rekenmachine (bijvoorbeeld degene die al in de organisatie wordt gebruikt om de TCO te berekenen). Het is duidelijk dat voor een netwerkversleutelingsoplossing de totale eigendomskosten bestaan ​​uit: direct kosten voor het kopen of huren van de oplossing zelf, infrastructuur voor het hosten van apparatuur en kosten voor inzet, beheer en onderhoud (hetzij intern of in de vorm van diensten van derden), evenals indirect kosten als gevolg van downtime van oplossingen (veroorzaakt door verlies van productiviteit van de eindgebruiker). Er is waarschijnlijk maar één subtiliteit. De prestatie-impact van de oplossing kan op verschillende manieren worden beschouwd: hetzij als indirecte kosten veroorzaakt door productiviteitsverlies, hetzij als ‘virtuele’ directe kosten voor de aanschaf/upgrade en het onderhoud van netwerktools die het verlies aan netwerkprestaties compenseren als gevolg van het gebruik van encryptie. In ieder geval kunnen uitgaven die lastig met voldoende nauwkeurigheid te berekenen zijn, het beste buiten de berekening gelaten worden: zo ontstaat er meer vertrouwen in de uiteindelijke waarde. En zoals gewoonlijk is het in ieder geval zinvol om verschillende apparaten op TCO te vergelijken voor een specifiek scenario van hun gebruik - reëel of typisch.

duurzaamheid

En het laatste kenmerk is de volharding van de oplossing. In de meeste gevallen kan de duurzaamheid alleen kwalitatief worden beoordeeld door verschillende oplossingen met elkaar te vergelijken. We moeten niet vergeten dat encryptieapparatuur niet alleen een middel is, maar ook een object van bescherming. Ze kunnen worden blootgesteld aan verschillende bedreigingen. Op de voorgrond staan ​​de dreigingen van schending van de vertrouwelijkheid, reproductie en wijziging van berichten. Deze bedreigingen kunnen worden gerealiseerd door kwetsbaarheden in de code of de individuele modi ervan, door kwetsbaarheden in encryptieprotocollen (inclusief in de fasen van het tot stand brengen van een verbinding en het genereren/distribueren van sleutels). Het voordeel zal liggen bij oplossingen die het mogelijk maken het versleutelingsalgoritme te wijzigen of de coderingsmodus te wijzigen (tenminste via een firmware-update), oplossingen die de meest complete versleuteling bieden en niet alleen gebruikersgegevens voor de aanvaller verbergen, maar ook adres- en andere service-informatie , evenals technische oplossingen die berichten niet alleen versleutelen, maar ook beschermen tegen reproductie en wijziging. Voor alle moderne versleutelingsalgoritmen, elektronische handtekeningen, het genereren van sleutels, enz., die in standaarden zijn vastgelegd, kan worden aangenomen dat de sterkte hetzelfde is (anders kun je eenvoudigweg verdwalen in de wildernis van de cryptografie). Moeten dit noodzakelijkerwijs GOST-algoritmen zijn? Alles is hier eenvoudig: als het toepassingsscenario FSB-certificering voor CIPF vereist (en in Rusland is dit meestal het geval; voor de meeste scenario's voor netwerkversleuteling is dit waar), dan kiezen we alleen tussen gecertificeerde scenario's. Als dat niet het geval is, heeft het geen zin om apparaten zonder certificaten van overweging uit te sluiten.

Een andere bedreiging is de dreiging van hacking, ongeautoriseerde toegang tot apparaten (ook via fysieke toegang buiten en binnen de behuizing). De dreiging kan worden uitgevoerd via
kwetsbaarheden bij de implementatie - in hardware en code. Daarom zullen oplossingen met een minimaal ‘aanvalsoppervlak’ via het netwerk, met behuizingen beschermd tegen fysieke toegang (met inbraaksensoren, bescherming tegen sondes en automatische reset van sleutelinformatie wanneer de behuizing wordt geopend), evenals oplossingen die firmware-updates mogelijk maken, een voordeel in het geval dat een kwetsbaarheid in de code bekend wordt. Er is een andere manier: als alle apparaten die worden vergeleken FSB-certificaten hebben, kan de CIPF-klasse waarvoor het certificaat is uitgegeven worden beschouwd als een indicator van weerstand tegen hacking.

Een ander type bedreiging zijn ten slotte fouten tijdens de installatie en bediening, de menselijke factor in zijn puurste vorm. Dit toont nog een voordeel aan van gespecialiseerde encryptors ten opzichte van geconvergeerde oplossingen, die vaak gericht zijn op doorgewinterde “netwerkspecialisten” en problemen kunnen veroorzaken voor “gewone”, algemene informatiebeveiligingsspecialisten.

Samenvattend

In principe zou het hier mogelijk zijn om een ​​soort integrale indicator voor te stellen voor het vergelijken van verschillende apparaten, zoiets

$$display$$K_j=∑p_i r_{ij}$$display$$

waarbij p het gewicht van de indicator is, en r de rangorde van het apparaat volgens deze indicator, en elk van de hierboven genoemde kenmerken kan worden onderverdeeld in "atomaire" indicatoren. Een dergelijke formule kan bijvoorbeeld nuttig zijn bij het vergelijken van aanbestedingsvoorstellen volgens vooraf afgesproken regels. Maar je kunt rondkomen met een eenvoudige tabel zoals

Kenschetsing
Apparaat 1
Apparaat 2
...
Apparaat N

Doorvoer
+
+

+ + +

Algemene kosten
+
++

+ + +

Vertraging
+
+

++

Schaalbaarheid
+ + +
+

+ + +

flexibiliteit
+ + +
++

+

Interoperabiliteit
++
+

+

Verenigbaarheid
++
++

+ + +

Eenvoud en gemak
+
+

++

fout tolerantie
+ + +
+ + +

++

kosten
++
+ + +

+

duurzaamheid
++
++

+ + +

Ik beantwoord graag vragen en opbouwende kritiek.

Bron: www.habr.com