VPN<\/a> of zonder.<\/p>\nNetwerk encryptie in een gedistribueerd Ethernet-netwerk<\/i><\/p>\n
De apparaten zelf kunnen ofwel gespecialiseerd zijn<\/b> (exclusief bedoeld voor encryptie), of multifunctioneel zijn (hybride, convergent<\/b>), dat wil zeggen ook andere functies vervullen (bijvoorbeeld als firewall of router). Verschillende leveranciers classificeren hun apparaten in verschillende klassen\/categorie\u00ebn, maar dat is niet belangrijk \u2013 het enige dat telt is of ze in staat zijn inter-site verkeer te versleutelen, en welke specificaties ze daarbij hebben.<\/p>\n
Voor de zekerheid herinner ik u eraan dat de termen \"netwerkversleuteling\", \"verkeer versleuteling\" en \"versleutelaar\" informeel zijn, hoewel ze vaak worden gebruikt. In de Russische regelgeving (inclusief die waarin de GOST's worden ge\u00efntroduceerd) komt u deze termen waarschijnlijk niet tegen.<\/p>\n
Versleutelingsniveaus en overdrachtsmodi<\/h4>\n \nVoordat we beginnen met het beschrijven van de kenmerken die gebruikt zullen worden voor evaluatie, moeten we eerst een belangrijke zaak ophelderen, namelijk het \"versleutelingsniveau\". Ik heb opgemerkt dat het vaak wordt vermeld in zowel offici\u00eble documenten van aanbieders (in beschrijvingen, handleidingen, enz.) als in informele discussies (bij onderhandelingen, op trainingen). Het lijkt erop dat iedereen goed weet waar het over gaat, maar ik was persoonlijk getuige van enige verwarring.<\/p>\n
Wat is nu precies een \"versleutelingsniveau\"? Het is duidelijk dat het gaat om het nummer van het niveau in het referentiemodel voor netwerken OSI\/ISO waarop de versleuteling plaatsvindt. Laten we GOST R ISO 7498-2\u201399 \"Informatie technologie. Relaties tussen open systemen. Basisreferentiemodel. Deel 2. Architectuur voor informatiebescherming\" lezen. Uit dit document blijkt dat het niveau van de vertrouwelijkheidsdienst (waarbij een van de mechanismen die ervoor zorgen versleuteling is) het protocolniveau is waarvan het serviceblok van gegevens (\"nuttige lading\", gebruikersgegevens) wordt versleuteld. Zoals in de standaard is geschreven, kan de dienst zowel op dit niveau, \"met eigen middelen\", als met behulp van het lagere niveau worden geboden (dit wordt bijvoorbeeld het meest ge\u00efmplementeerd in MACsec).<\/p>\n
In de praktijk zijn er echter twee modi voor het verzenden van versleutelde informatie via het netwerk (ik denk meteen aan IPsec, maar deze modi komen ook voor in andere protocollen). In de transportmodus<\/b> (soms ook wel native-modus genoemd) worden alleen het serviceblok<\/b> gegevens versleuteld, terwijl de koppen \"open\" blijven, ongecodeerd (er kunnen soms extra velden met informatie over het encryptie-algoritme worden toegevoegd, en andere velden worden gemodificeerd of herberekend). In de tunnelingmodus<\/b> wordt daarentegen het gehele protocolblok<\/b> gegevens versleuteld en ingekapseld in het serviceblok van dezelfde of een hoger niveau, wat betekent dat het wordt omgeven door nieuwe koppen.<\/p>\n
Het encryptieniveau op zich, in combinatie met een bepaalde transmissiemodus, is noch goed noch slecht, zodat je niet kunt zeggen dat L3 in de transportmodus beter is dan L2 in de tunnelmodus. Het hangt simpelweg af van veel kenmerken waarop apparaten worden beoordeeld, zoals flexibiliteit en compatibiliteit. Voor het functioneren in netwerken van L1 (hertransmissie van de bitstroom), L2 (frame-switching) en L3 (pakketrouting) in transportmodus zijn oplossingen nodig die een vergelijkbaar of hoger niveau van encryptie bieden (anders wordt adresinformatie versleuteld, en komen de gegevens niet op de bestemming), terwijl de tunnelmodus deze beperking kan omzeilen (hoewel ten koste van andere belangrijke kenmerken).<\/p>\n
Transport- en tunnelmodi van L2-encryptie<\/i><\/p>\n
Laten we nu de specificaties behandelen.<\/p>\n
Prestaties<\/h4>\n \nBij netwerken is prestatie een complex en veelzijdig begrip. Soms geldt dat een bepaald model in \u00e9\u00e9n prestatiekenmerk superieur is, terwijl het in een ander tekortschiet. Daarom is het altijd nuttig om alle onderdelen van encryptieprestaties en hun impact op de netwerkkapaciteit en de applicaties die deze gebruiken te overwegen. Dit kan worden vergeleken met een auto, waar niet alleen de maximale snelheid belangrijk is, maar ook de acceleratietijd naar de 'honderd', brandstofverbruik, enzovoorts. Fabrikanten besteden veel aandacht aan prestatiekenmerken, en doorgaans wordt rangschikking binnen de productlijnen van fabrikanten van encryptieapparatuur gebaseerd op deze prestaties.<\/p>\n
Het is duidelijk dat de prestaties afhankelijk zijn van zowel de complexiteit van de netwerk- en cryptografische bewerkingen die op het apparaat worden uitgevoerd (waaronder hoe goed deze taken kunnen worden parallel verwerkt en gepipeline), als van de prestaties van de hardware en de kwaliteit van de firmware. Daarom wordt in de geavanceerdere modellen krachtigere hardware toegepast, en soms is het mogelijk om deze uit te breiden met extra processoren en geheugenchips. Er zijn verschillende benaderingen voor de realisatie van cryptografische functies: op een algemene centrale verwerkingseenheid (CPU), een op maat gemaakte gespecialiseerde ge\u00efntegreerde schakeling (ASIC) of op een programmeerbare logische ge\u00efntegreerde schakeling (FPGA). Elke benadering heeft zijn eigen voor- en nadelen. Bijvoorbeeld, de CPU kan een 'bottleneck' zijn voor de encryptie, vooral als de processor geen gespecialiseerde instructies heeft ter ondersteuning van het encryptie-algoritme (of als deze niet worden gebruikt). Gespecialiseerde chips missen flexibiliteit; het is niet altijd mogelijk om ze opnieuw te programmeren voor betere prestaties, om nieuwe functies toe te voegen of kwetsbaarheden op te lossen. Bovendien wordt hun gebruik pas rendabel bij grote productievolumes. Daarom is de 'gulden middenweg' \u2013 het gebruik van FPGA's \u2013 zo populair geworden. Juist op FPGA's zijn de zogenaamde cryptoversnellers gemaakt \u2013 ingebouwde of aangesloten gespecialiseerde hardwaremodules ter ondersteuning van cryptografische bewerkingen.<\/p>\n
Aangezien het gaat om netwerk-<\/b> encryptie, is het logisch dat de prestaties van oplossingen moeten worden gemeten in dezelfde eenheden als voor andere netwerkapparaten \u2013 bandbreedte, percentage pakketverlies (frame loss) en latentie. Deze eenheden zijn gedefinieerd in RFC 1242. Over de vaak genoemde variatie in latentie (jitter) staat in deze RFC echter niets geschreven. Hoe meet je deze eenheden? Ik heb geen goedgekeurde methodologie in enige standaard (offici\u00eble of niet-offici\u00eble zoals RFC) speciaal voor netwerkcryptografie kunnen vinden. Het zou logisch zijn om de methodologie voor netwerkapparaten te gebruiken die is vastgelegd in de standaard RFC 2544. Veel leveranciers volgen deze ook \u2013 veel, maar niet allemaal. Bijvoorbeeld, zij sturen testverkeer alleen in \u00e9\u00e9n richting in plaats van beide, zoals aanbevolen wordt<\/b> de standaard vereist. Maar goed.<\/p>\n
De prestatiemeting van netwerkaffichage-apparaten heeft toch zijn eigen bijzonderheden. Ten eerste is het correct om alle metingen uit te voeren voor een paar apparaten: hoewel de encryptie-algoritmen symmetrisch zijn, zullen vertragingen en pakketverlies tijdens het versleutelen en ontsleutelen niet noodzakelijk gelijk zijn. Ten tweede is het zinvol om juist de delta te meten, de impact van netwerkaffichage op de uiteindelijke netwerkprestaties, door twee configuraties met elkaar te vergelijken: zonder encryptieapparaten en met hen. Of in het geval van hybride apparaten, die verschillende functies combineren naast netwerkaffichage, wanneer de encryptie is uitgeschakeld en ingeschakeld. Deze invloed kan verschillend zijn en afhangen van de aansluitingsschema's van de encryptieapparaten, van de werkmodi, en uiteindelijk van de aard van het verkeer. In het bijzonder hangen veel prestatieparameters af van de pakketlengte, daarom worden bij het vergelijken van de prestaties van verschillende oplossingen vaak grafieken gebruikt die deze parameters in relatie tot de pakketlengte tonen, of IMIX - een verkeersverdeling over pakketlengtes die de werkelijkheid ongeveer weerspiegelt. Wanneer we dezelfde basisconfiguratie zonder encryptie voor vergelijking nemen, kunnen we oplossingen voor netwerkaffichage die op verschillende manieren zijn ge\u00efmplementeerd met elkaar vergelijken, zonder in deze verschillen te duiken: L2 met L3, 'bewaar-en-verzend' (store-and-forward) met doorvoer (cut-through), gespecialiseerde met convergente, GOST met AES, enzovoort.<\/p>\n
Aansluitingsschema voor prestatiemeting<\/i><\/p>\n
Het eerste kenmerk waar aandacht aan wordt geschonken, is de 'snelheid' van het encryptieapparaat, dat wil zeggen de bandbreedte<\/b> (bandwidth) van zijn netwerkinterfaces, de bitsnelheid. Deze wordt bepaald door de netwerkenstandaarden die door de interfaces worden ondersteund. Voor Ethernet zijn gangbare cijfers 1 Gbit\/s en 10 Gbit\/s. Maar zoals we weten, is in elk netwerk de maximale theoretische doorvoercapaciteit<\/b> (doorvoersnelheid) op elk van haar niveaus is altijd minder dan de bandbreedte: een deel van de bandbreedte wordt 'opgegeten' door inter-frame intervallen, control headers, enzovoort. Als een apparaat in staat is om verkeer op volledige snelheid van de netwerkinterface te ontvangen, te verwerken (in ons geval te versleutelen of te ontsleutelen) en door te geven, dat wil zeggen met de maximale theoretische doorvoersnelheid voor dit niveau van het netwerkmodel, dan wordt gezegd dat het functioneert op lijn snelheid<\/b>. Hiervoor moet het apparaat geen pakketten verliezen of weggooien, ongeacht hun grootte en frequentie. Als een versleutelingsapparaat geen ondersteuning biedt voor werking op lijn snelheid, wordt meestal zijn maximale doorvoersnelheid aangegeven in dezelfde gigabits per seconde (soms met vermelding van de pakketlengte - hoe korter de pakketten, hoe lager doorgaans de doorvoersnelheid). Het is erg belangrijk om te begrijpen dat de maximale doorvoersnelheid de maximale is zonder verlies<\/b> (ook al kan het apparaat verkeer met een hogere snelheid 'doorlaten', maar daarbij delen van pakketten verliest). Bovendien is het belangrijk om op te letten dat sommige verkopers de totale doorvoersnelheid tussen alle paar poorten meten, zodat deze cijfers weinig zeggen als al het versleutelde verkeer via \u00e9\u00e9n enkele poort gaat.<\/p>\n
Waar is het vooral belangrijk om op lijn snelheid te werken (of anders, zonder pakketverlies)? In kanalen met hoge doorvoersnelheid en grote vertragingen (bijvoorbeeld satellietverbindingen), waar om een hoge overdrachtsnelheid te ondersteunen een grote TCP-venstergrootte moet worden ingesteld, en waar pakketverlies de netwerkprestaties aanzienlijk verlaagt.<\/p>\n
Maar niet alle bandbreedte wordt gebruikt voor het verzenden van nuttige gegevens. Men moet rekening houden met de zogenaamde overhead<\/b> (overhead) bandbreedte. Dit is het deel van de bandbreedte van het encryptieapparaat (in procenten of bytes per pakket) dat daadwerkelijk verloren gaat (niet kan worden gebruikt voor de overdracht van applicatiegegevens). Overhead ontstaat in de eerste plaats door de toename van de grootte (aanvullingen, 'padding') van het gegevensveld in versleutelde netwerkpakketten (afhankelijk van het encryptie-algoritme en de modus van werking). Ten tweede, door de toename van de lengte van de header van pakketten (tunnelmodus, protocolinvoeging van protocolversleuteling, imitatieve invoeging, enzovoort, afhankelijk van het protocol en de modus van de werking van de versleuteling en de overdracht) - gewoonlijk zijn deze overheadkosten het meest significant en krijgen ze de meeste aandacht. Ten derde, door de fragmentatie van pakketten bij overschrijding van de maximale datagrootte (MTU) (als het netwerk in staat is om een pakket dat groter is dan de MTU in twee\u00ebn te splitsen, met duplicatie van de headers). Ten vierde, door het ontstaan van extra overhead (control) verkeer in het netwerk tussen encryptieapparaten (voor sleuteluitwisseling, tunnelinstellingen, enzovoort). Lage overhead is belangrijk waar de bandbreedte van de kanaal beperkt is. Dit wordt vooral merkbaar bij verkeer van kleine pakketten, bijvoorbeeld spraakverkeer - daar kunnen overheadkosten meer dan de helft van de kanaalsnelheid 'opeten'!<\/p>\n
Doorvoersnelheid<\/i><\/p>\n
Ten slotte is er nog toegevoegde vertraging<\/b> \u2013 het verschil (in fracties van een seconde) in netwerklatentie (de tijd die nodig is voor gegevens om van het netwerk te komen en het te verlaten) tussen gegevensoverdracht zonder netwerkversleuteling en met. Over het algemeen geldt: hoe lager de latentie van het netwerk, des te kritischer wordt de vertraging die door versleutelingsapparaten wordt veroorzaakt. De vertraging wordt veroorzaakt door de versleutelingsoperatie zelf (afhankelijk van het versleutelingsalgoritme, de blokgrootte en de werkmodi, evenals de kwaliteit van de implementatie in de software), en de verwerking van het netwerkpakket in het apparaat. De toegevoegde vertraging is afhankelijk van de verwerkingsmodus van de pakketten (doorlatend of 'bewaar-en-verzend') en de prestaties van het platform (de 'hardware'-implementatie op FPGA of ASIC is meestal sneller dan de 'software'-implementatie op CPU). L2-versleuteling heeft bijna altijd een lagere toegevoegde vertraging in vergelijking met versleuteling op L3 of L4: dit wordt be\u00efnvloed door het feit dat apparaten die op L3\/L4 versleutelen vaak convergent zijn. Bijvoorbeeld, bij high-speed Ethernet-versleutelaars, ge\u00efmplementeerd op FPGA en die op L2 versleutelen, is de latentie door de versleuteling verwaarloosbaar klein \u2013 soms, wanneer versleuteling op een paar apparaten wordt ingeschakeld, wordt de totale toegepaste latentie zelfs minder! Lage latentie is belangrijk waar deze vergelijkbaar is met de totale latenties in de verbinding, inclusief de signaalverspreidingslatentie, die ongeveer 5 microseconden per kilometer bedraagt. Dat wil zeggen, voor stedelijke netwerken (tientallen kilometers in doorsnede) kunnen microseconden veel betekenen. Bijvoorbeeld voor synchrone databasereplicatie, high-frequency trading en blockchain.<\/p>\n
Toegevoegde latentie<\/i><\/p>\nSchaalbaarheid<\/h4>\n
\nGrote gedistribueerde netwerken kunnen duizenden knooppunten en netwerkapparaten omvatten, evenals honderden segmenten van lokale netwerken. Het is belangrijk dat encryptieoplossingen geen extra beperkingen opleggen aan de grootte en topologie van het gedistribueerde netwerk. Dit betreft vooral het maximale aantal adressen van knooppunten en netwerken. Dergelijke beperkingen kunnen zich voordoen bij de implementatie van een multipoint topologie van een netwerk dat is beveiligd met encryptie (met onafhankelijke beveiligde verbindingen of tunnels) of selectieve encryptie (bijvoorbeeld op protocollonummer of VLAN). Wanneer netwerkadressen (MAC, IP, VLAN ID) worden gebruikt als sleutels in een tabel waarvan het aantal rijen beperkt is, komen deze beperkingen naar voren.<\/p>\n
Bovendien hebben grote netwerken vaak verschillende structurele niveaus, inclusief de backbone, waarbij op elk niveau een eigen adresseringschema en routingbeleid wordt toegepast. Voor de implementatie van een dergelijke aanpak worden vaak speciale frameformaten (zoals Q-in-Q of MAC-in-MAC) en routingsprotocols gebruikt. Om de opbouw van dergelijke netwerken niet te belemmeren, moeten encryptieapparaten correct omgaan met dergelijke frames (in die zin betekent schaalbaarheid compatibiliteit \u2013 hierover later meer).<\/p>\n
Flexibiliteit<\/h4>\n \nHier gaat het om het ondersteunen van verschillende configuraties, aansluitchema's, topologie\u00ebn en meer. Voor geswitchte netwerken op basis van Carrier Ethernet-technologie betekent dit bijvoorbeeld de ondersteuning van verschillende soorten virtuele verbindingen (E-Line, E-LAN, E-Tree), verschillende serviceniveaus (zowel per poort als per VLAN) en verschillende transporttechnologie\u00ebn (die eerder al zijn genoemd). Dit betekent dat het apparaat in staat moet zijn om zowel in lineaire ('point-to-point') als multipoint-modus te werken, afzonderlijke tunnels voor verschillende VLANs op te zetten en ongeordende levering van pakketten binnen een beveiligd kanaal toe te laten. De mogelijkheid om verschillende werkmodi van de encryptie (inclusief met of zonder inhoudsverificatie) en verschillende pakketoverdrachtsmodi te kiezen, maakt het mogelijk om een balans te vinden tussen veerkracht en prestaties, afhankelijk van de huidige omstandigheden.<\/p>\n
Ook belangrijk is de ondersteuning van particuliere netwerken, waarvan de apparatuur eigendom is van \u00e9\u00e9n organisatie (of door deze wordt gehuurd), en operatornetwerken, waarvan de verschillende segmenten worden beheerd door verschillende bedrijven. Het is goed als de oplossing zowel eigen beheer als beheer door een externe organisatie (in een beheerd service-model) mogelijk maakt. In operatornetwerken is nog een functie belangrijk \u2013 ondersteuning van multi-tenancy (gezamenlijk gebruik door verschillende klanten) in de vorm van cryptografische isolatie van afzonderlijke klanten (abonnees), wiens verkeer via dezelfde set versleutelingsapparatuur loopt. Dit vereist doorgaans het gebruik van afzonderlijke sets sleutels en certificaten voor elke klant.<\/p>\n
Als het apparaat wordt aangeschaft voor een specifieke scenario, zijn al deze mogelijkheden mogelijk niet zo belangrijk \u2013 het is alleen nodig om ervoor te zorgen dat het apparaat ondersteunt wat momenteel nodig is. Maar als de oplossing wordt aangeschaft voor toekomstige groei, ter ondersteuning van ook toekomstige scenario's, en wordt gekozen als 'corporate standaard', dan is flexibiliteit geen overbodige luxe \u2013 vooral met het oog op de beperkingen in interoperabiliteit van apparaten van verschillende leveranciers (hierover later meer).<\/p>\n
Eenvoudig en gebruiksvriendelijk<\/h4>\n \nGebruiksgemak is ook een meervoudig begrip. Algemeen kan worden gezegd dat dit de totale tijdskosten zijn van specialisten met een bepaalde kwalificatie, die nodig zijn voor het ondersteunen van de oplossing in verschillende fasen van de levenscyclus. Als er geen kosten zijn en installatie, configuratie en exploitatie volledig automatisch zijn, dan zijn de kosten nul en is het gemak absoluut. Natuurlijk komt dat in de echte wereld niet voor. Een redelijke benadering is het model \u2018knoop op de draad\u2019<\/b> (bump-in-the-wire), of een transparante verbinding waarbij het toevoegen en loskoppelen van encryptieapparaten geen handmatige of geautomatiseerde wijzigingen in de netwerkinstellingen vereist. Dit vereenvoudigt het onderhoud van de oplossing: je kunt de encryptiefunctie eenvoudig in- of uitschakelen en indien nodig het apparaat eenvoudig 'omzeilen' met een netwerkkabel (wat betekent dat je de poorten van het netwerkapparaat direct verbindt waarop het was aangesloten). Er is echter \u00e9\u00e9n nadeel - hetzelfde kan ook door een aanvaller worden gedaan. Voor de implementatie van het 'knooppunt op de draad'-principe moet het verkeer niet alleen worden beschouwd van de datalaag<\/b>maar ook van de controle- en beheersingslagen<\/b> - apparaten moeten transparant voor hen zijn. Daarom kan dergelijk verkeer alleen worden versleuteld als er tussen de encryptieapparaten geen ontvangers van dit soort verkeer in het netwerk zijn, omdat als het wordt afgewezen of versleuteld, de netwerkinstellingen kunnen veranderen wanneer encryptie wordt in- of uitgeschakeld. Een encryptieapparaat kan ook transparant zijn voor signalering op fysiek niveau. In het bijzonder moet het, bij verlies van signaal, deze verlies (d.w.z. zijn zenders uitschakelen) terug en vooruit doorgeven ('voor zichzelf') in de richting van het signaal.<\/p>\n
Ook is het belangrijk om de scheiding van bevoegdheden tussen de afdelingen van IB en IT, in het bijzonder de netwerkafdeling, te ondersteunen. De oplossing voor encryptie moet het toegangs- en auditmodel dat in de organisatie is aangenomen ondersteunen. De noodzaak voor interactie tussen verschillende afdelingen moet tot een minimum worden beperkt voor routinematige operaties. Daarom hebben gespecialiseerde apparaten die uitsluitend encryptiefuncties ondersteunen en zo transparant mogelijke netwerkmogelijkheden een voordeel op het gebied van gebruiksvriendelijkheid. Met andere woorden, medewerkers van de IB-dienst zouden geen reden moeten hebben om 'netwerkbeheerders' te benaderen voor wijzigingen in netwerkinstellingen. En vice versa, zij hoeven de encryptie-instellingen niet te wijzigen tijdens het onderhoud van het netwerk.<\/p>\n
Een andere factor zijn de mogelijkheden en het gebruiksgemak van de beheertools. Ze moeten overzichtelijk en logisch zijn, import- en exportfunctionaliteit van instellingen bieden, automatisering, enzovoorts. Let vooral op welke beheermogelijkheden beschikbaar zijn (dit omvat meestal een eigen beheersysteem, een webinterface en de commandoregel) en met welke set functies elk van hen wordt geleverd (er kunnen beperkingen zijn). Een belangrijke functie is de ondersteuning van out-of-band<\/b> beheer, dat wil zeggen via een dedicat netwerk voor beheer, en in-band<\/b> beheer, dat wil zeggen via het gedeelde netwerk dat ook nuttige data transporteert. De beheertools moeten al het ongewone signaleren, inclusief beveiligingsincidenten. Routine- en repetitieve taken moeten automatisch worden uitgevoerd. Dit betreft vooral het beheer van sleutels. Ze moeten automatisch worden gegenereerd\/gedistribueerd. Ondersteuning van PKI is een groot pluspunt.<\/p>\nCompatibiliteit<\/h4>\n
\nDit houdt in de compatibiliteit van het apparaat met netwerknormen. Hierbij gaat het niet alleen om industriestandaarden die zijn aangenomen door gezaghebbende organisaties zoals IEEE, maar ook om proprietary protocollen van marktleiders, zoals Cisco. Er zijn twee fundamentele manieren om compatibiliteit te waarborgen: ofwel via transparantie<\/b>, of via expliciete ondersteuning<\/b> van protocollen (wanneer het versleutelingsapparaat voor een bepaald protocol een van de knooppunten in het netwerk wordt en het controledataverkeer van dat protocol verwerkt). De volledigheid en correctheid van de implementatie van controlegemechanismen bepaalt de compatibiliteit met netwerken. Ondersteuning van verschillende PHY-niveaus (snelheden, overdrachtsmedia, coderingsschema's), van Ethernet-frames in verschillende formaten met elke MTU en van verschillende L3-protocollen (vooral van de TCP\/IP-familie) is belangrijk.<\/p>\n
Transparantie wordt bereikt door middel van mutatiemechanismen (tijdelijke wijziging van de inhoud van open headers in het verkeer tussen encryptors), doorlaatopties (wanneer afzonderlijke pakketten ongecodeerd blijven) en het uitstel van het begin van de versleuteling (wanneer normaal gesproken versleutelde velden van pakketten niet versleuteld worden).<\/p>\n
Hoe transparantie wordt gewaarborgd<\/i><\/p>\n
Zorg er daarom altijd voor dat je verduidelijkt hoe de ondersteuning van een bepaald protocol precies wordt geboden. Vaak is de ondersteuning in transparante modus handiger en betrouwbaarder.<\/p>\n
Interoperabiliteit<\/h4>\n \nDit is ook compatibiliteit, maar in een andere zin, namelijk de mogelijkheid om samen te werken met andere modellen van encryptieapparaten, inclusief die van andere fabrikanten. Veel hangt af van de staat van standaardisatie van encryptieprotocollen. Op L1 zijn er gewoon geen algemeen erkende encryptiestandaarden.<\/p>\n
Voor L2-encryptie in Ethernet-netwerken is er de standaard 802.1ae (MACsec), maar deze gebruikt geen eind-tot-eind<\/b> (end-to-end), maar tussenpoort<\/b>, 'hopsgewijze' (hop-by-hop) encryptie, en in zijn oorspronkelijke versie is deze niet geschikt voor gebruik in gedistribueerde netwerken, daarom zijn er merkgebonden extensies verschenen die deze beperking overwinnen (uiteraard ten koste van interoperabiliteit met apparatuur van andere fabrikanten). In 2018 werd echter ondersteuning voor gedistribueerde netwerken aan de standaard 802.1ae toegevoegd, maar de ondersteuning voor de GOST encryptie-algoritmen ontbreekt nog steeds. Daarom kenmerken merkgebonden, niet-standaard L2-encryptieprotocollen zich doorgaans door een hogere effici\u00ebntie (met name lagere overhead op bandbreedte) en flexibiliteit (de mogelijkheid om encryptie-algoritmen en -modi te wijzigen).<\/p>\n
Op hogere niveaus (L3 en L4) zijn er erkende standaarden, voorop staan IPsec en TLS, maar ook hier is het niet zo eenvoudig. Het probleem is dat elk van deze standaarden een set protocollen is, elk met verschillende versies en verplichte of facultatieve extensies. Bovendien geven sommige fabrikanten de voorkeur aan hun eigen merkprotocollen voor encryptie ook op L3\/L4. Daarom is het in de meeste gevallen niet realistisch om volledige interoperabiliteit te verwachten, maar het is belangrijk dat er in ieder geval enige samenwerking tussen verschillende modellen en generaties van dezelfde fabrikant mogelijk is.<\/p>\n
Betrouwbaarheid<\/h4>\n \nVoor het vergelijken van verschillende oplossingen kan ofwel de gemiddelde tijd tot falen of de beschikbaarheidsgraad worden gebruikt. Als deze cijfers ontbreken (of als er geen vertrouwen in bestaat), kan er een kwalitatieve vergelijking worden gemaakt. Voordeel zal zijn voor apparaten met gebruiksvriendelijke bediening (minder kans op configuratiefouten), voor gespecialiseerde encryptors (om dezelfde reden), evenals voor oplossingen met minimale detectie- en herstelduur bij uitval, inclusief middelen voor 'hot' redundantie van knooppunten en apparaten in het geheel.<\/p>\n
Cost<\/h4>\n \nWat de kosten betreft, is het, zoals bij de meeste IT-oplossingen, verstandig om de totale eigendomskosten te vergelijken. Voor de berekening hoeft men het wiel niet opnieuw uit te vinden, maar kan men gebruikmaken van een geschikte methode (bijvoorbeeld van Gartner) en een calculator (bijvoorbeeld degene die al binnen de organisatie wordt gebruikt voor het berekenen van TCO). Het is duidelijk dat voor een netwerk encryptieoplossing de totale eigendomskosten bestaan uit directe<\/b> kosten voor de aankoop of huur van de oplossing zelf, de infrastructuur voor het plaatsen van de apparatuur en de kosten voor implementatie, administratie en ondersteuning (ongeacht of dit intern of in de vorm van diensten van een externe organisatie gebeurt), alsook uit indirecte<\/b> kosten door uitval van de oplossing (veroorzaakt door verlies van productiviteit van eindgebruikers). Waarschijnlijk is er maar \u00e9\u00e9n nuance. De impact van de prestaties van de oplossing kan op verschillende manieren worden beoordeeld: als indirecte kosten, veroorzaakt door een daling van de productiviteit, of als 'virtuele' directe kosten voor de aankoop \/ modernisering en onderhoud van netwerkmiddelen die de daling van de prestaties van het netwerk door encryptie compenseren. In elk geval is het beter om kosten, die moeilijk met voldoende nauwkeurigheid te berekenen zijn, 'buiten beschouwing' te laten in de berekening: dat vergroot het vertrouwen in het eindresultaat. En zoals gewoonlijk is het in ieder geval zinvol om de TCO van verschillende apparaten te vergelijken voor een specifiek gebruiksscenario - re\u00ebel of typisch.<\/p>\nWeerbaarheid<\/h4>\n
\nDe laatste eigenschap is de weerstand van de oplossing. In de meeste gevallen kan weerstand alleen kwalitatief worden beoordeeld door verschillende oplossingen met elkaar te vergelijken. We moeten ons herinneren dat encryptieapparaten niet alleen middelen zijn, maar ook objecten van bescherming. Ze kunnen onderhevig zijn aan verschillende bedreigingen. Op de eerste plaats staan de bedreigingen van schending van de vertrouwelijkheid, reproductie en wijziging van berichten. Deze bedreigingen kunnen zich manifesteren via kwetsbaarheden in de encryptie of in specifieke modi ervan, evenals via kwetsbaarheden in encryptieprotocollen (inclusief tijdens de fases van verbinding totstandbrengen en sleutelgeneratie\/distributie). Voordeel zal zijn voor oplossingen die het mogelijk maken om het encryptie-algoritme te wijzigen of de modus van de cipher om te schakelen (minstens via een firmware-update), voor oplossingen die maximale encryptie bieden en niet alleen gebruikersgegevens verbergen voor aanvallers, maar ook adres- en andere metadata, evenals voor die oplossingen die niet alleen coderen, maar ook berichten beschermen tegen reproductie en wijziging. Voor alle moderne encryptie-algoritmen, digitale handtekeningen, sleutelgeneratie en dergelijke die zijn vastgelegd in normen, kan de weerstand als gelijkwaardig worden beschouwd (anders kun je eenvoudig verdwalen in de jungle van cryptografie). Moeten dit per se GOST-algoritmen zijn? Hier is het eenvoudig: als het toepassingsscenario certificering door de FSB voor encryptiehulpmiddelen vereist (en in Rusland is dat vaak zo), voor de meeste scenario's van netwerkencryptie is dat het geval), dan kiezen we alleen tussen gecertificeerde apparaten. Als dat niet zo is, heeft het geen zin om apparaten zonder certificaten uit overwegingen uit te sluiten.<\/p>\n
Een andere bedreiging is de dreiging van inbraak, ongeoorloofde toegang tot apparaten (zowel via fysieke toegang van buitenaf als binnenin de behuizing). De dreiging kan zich manifesteren via
Ten slotte is er nog een ander type bedreiging - fouten bij de configuratie en exploitatie, de menselijke factor in zijn puurste vorm. Hier komt een ander voordeel van gespecialiseerde encryptieoplossingen naar voren ten opzichte van convergerende oplossingen, die vaak gericht zijn op doorgewinterde 'netwerkprofessionals', en die problemen kunnen veroorzaken voor 'gewone', veelzijdige specialisten op het gebied van informatiebeveiliging.<\/p>\n
In summary<\/h4>\n \nIn principe zou men hier een bepaalde integrale indicator kunnen voorstellen voor het vergelijken van verschillende apparaten, iets als<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\nwaarbij p het gewicht van de indicator is en r de rang van het apparaat op deze indicator, waarbij elke van de hierboven genoemde kenmerken kan worden onderverdeeld in 'atomische' indicatoren. Zo'n formule zou nuttig kunnen zijn, bijvoorbeeld bij het vergelijken van aanbestedingsvoorstellen volgens vooraf overeengekomen regels. Maar men kan ook volstaan met een eenvoudige tabel zoals<\/p>\n
Kenmerken
Doorvoersnelheid
+++<\/p>\n
Overheadkosten
+++<\/p>\n
Vertraging
++<\/p>\n
Schaalbaarheid
+++<\/p>\n
Flexibiliteit
+<\/p>\n
Interoperabiliteit
+<\/p>\n
Compatibiliteit
+++<\/p>\n
Eenvoudig en gebruiksvriendelijk
++<\/p>\n
Resilience
++<\/p>\n
Cost
+<\/p>\n
Weerbaarheid
+++<\/p>\n
\nIk beantwoord graag vragen en constructieve kritische opmerkingen.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