Ezt a felülvizsgálatot (vagy ha úgy tetszik, összehasonlító útmutatót) akkor írtam, amikor az volt a feladatom, hogy összehasonlítsak több eszközt különböző gyártóktól. Ráadásul ezek az eszközök különböző osztályokba tartoztak. Meg kellett értenem az összes eszköz architektúráját és specifikációját, és létre kellett hoznom egy "koordináta rendszert" az összehasonlításhoz. Örömmel fogom, ha az én áttekintésem segít valakinek:
- Megérteni a titkosító eszközök leírásait és specifikációit
- Különböztetni meg a „papíralapú” specifikációkat a való életben tényleg fontosaktól
- Túllépni a megszokott gyártók listáján, és figyelembe venni bármilyen terméket, amely alkalmas a kitűzött feladat megoldására
- Megkérdezni a megfelelő kérdéseket a tárgyalások során
- Tender követelmények (RFP) kidolgozása
- Megérteni, hogy milyen jellemzőkről kell lemondani, ha egy adott eszközmodellt választanak
Mit lehet értékelni
Alapvetően a megközelítés alkalmazható bármely önálló (standalone) eszközre, amely alkalmas az Ethernet között zajló forgalom titkosítására (lokációk közötti titkosítás). Tehát olyan „dobozt” jelent, amely különálló házban van (na jó, a blades/modulek a chassissal együtt ide is beletartozik), amely egy vagy több Ethernet porton keresztül csatlakozik a helyi (campus) Ethernet hálózathoz titkosítatlan forgalommal, és egy másik porton (portokon) keresztül kapcsolódik a csatornához/hálózathoz, amelyen a titkosított forgalom más, távoli szegmensekbe jut. Az ilyen titkosító megoldásokat magán- vagy szolgáltatói hálózatban különböző típusú "szállítással" ("sötét" optikai rost, frekvenciaközi berendezések, Ethernet kapcsolt hálózatok, és "pseudocsövek", amelyeken keresztül a különböző, MPLS architektúrával rendelkező hálózatokban terjeszkedik) lehet végrehajtani, a technológia felhasználásával VPN vagy anélkül.
Hálózati titkosítás elosztott Ethernet hálózaton
Maguk az eszközök lehetnek specializáltak (kizárólag titkosításra tervezettek), vagy multifunkcionálisak (hibrid, konvergens), azaz további funkciókat is ellátnak (például tűzfal vagy router). Különböző gyártók saját eszközeiket különböző osztályokba/kategóriákba sorolják, de ez lényegtelen – a fontos az, hogy képesek-e titkosítani a helyszínek közötti forgalmat, és hogy milyen jellemzőkkel rendelkeznek ezen a téren.
Mindenesetre emlékeztetlek, hogy a „hálózati titkosítás”, a „forgalom titkosítása”, a „titkosító” kifejezések informálisak, bár gyakran használják őket. Az orosz szabályozásokban (beleértve a GOST-ok bevezetésével kapcsolatosakat is) valószínűleg nem fogsz velük találkozni.
Titkosítási szintek és adatátviteli módok
Mielőtt rátérnénk a jellemzők leírására, amelyeket az értékeléshez fogunk használni, először is egy fontos dologgal kell foglalkozni, nevezetesen a „titkosítási szinttel”. Megfigyeltem, hogy ezt gyakran említik a gyártók hivatalos dokumentumaiban (leírások, útmutatók stb.), valamint informális megbeszéléseken (tárgyalásokon, képzéseken). Úgy tűnik, mindenki tudja, miről van szó, de személyesen tanúja voltam némi zűrzavarnak.
Tehát mi is az a „titkosítási szint”? Nyilvánvaló, hogy az OSI/ISO referencia hálózati modell szintszámáról van szó, ahol a titkosítás zajlik. Olvassuk el a GOST R ISO 7498-2–99 „Információs technológia. Nyitott rendszerek kölcsönhatása. Alapvető referencia modell. 2. rész. Információvédelmi architektúra” dokumentumot. Ebből a dokumentumból világossá válik, hogy a titkossági szolgáltatás szintje (amelynek egyik mechanizmusa pontosan a titkosítás) – az a protokoll szint, amelynek adatblokkja („hasznos terhelés”, felhasználói adatok) titkosítva van. Amint a szabványban is meg van írva, a szolgáltatás ilyen szinten „saját erőből” is biztosítható, és az alsó szinten keresztül is (például a MACsec esetében gyakran így valósítják meg).
A gyakorlatban két módja van a titkosított adatok hálózaton keresztüli átvitelének (az IPsec jut eszembe, de ezek a módok más protokolloknál is előfordulnak). A szállítási (néha natív módnak is hívják) módban csak a szolgáltatási adatblokk titkosítódik, míg a fejlécek „nyitva” maradnak, azaz nincsenek titkosítva (néha további mezők kerülnek hozzáadásra a titkosítási algoritmus szolgáltatási információival, és egyes mezők módosítódnak, újraszámítódnak). A alagútmódban azonban az egész protokoll adatblokk (tehát maga a csomag) titkosítva van, és beágyazódik az azonos vagy magasabb szintű adatblokkba, azaz új fejlécekkel keretezik.
A titkosítási szint önmagában, egy adott átvitel üzemmóddal együtt sem jó, sem rossz, így nem állítható, hogy például az L3 átvitel üzemmódban jobb, mint az L2 alagút üzemmódban. Egyszerűen sok jellemző függ tőlük, amelyek alapján az eszközöket értékelik. Például a rugalmasság és a kompatibilitás. Az L1 (bitfolyam továbbítása), L2 (keretek kapcsolása) és L3 (csomagok irányítása) hálózati működéséhez olyan megoldások szükségesek, amelyek azonos vagy magasabb szinten titkosítanak (különben a címadatok titkosítva lesznek, és az adatok nem jutnak el a célhelyre), míg az alagút üzemmód lehetővé teszi ennek a korlátozásnak a megkerülését (igaz, más fontos jellemzők rovására).
L2 titkosítási üzemmódok: átvitel és alagút
Most nézzük meg a jellemzők részleteit.
Teljesítmény
Hálózati titkosítás szempontjából a teljesítmény egy komplex, többdimenziós fogalom. Előfordulhat, hogy egy adott modell egy teljesítményjellemzőben jobb, mint a másikban, de a másikban gyengébben teljesít. Ezért mindig hasznos figyelembe venni a titkosítás teljesítményének összetevőit és azok hatását a hálózati teljesítményre és a hálózatot használó alkalmazásokra. Itt hasonló párhuzamot lehet vonni egy autóval, ahol nemcsak a maximális sebesség fontos, hanem a 100 km/h-ra való gyorsulási idő, az üzemanyag-fogyasztás és így tovább. A gyártók és potenciális megrendelőik nagy figyelmet fordítanak a teljesítmény jellemzőire. Általában a teljesítmény szerint rangsorolnak a gyártók titkosító eszközöinek termékpalettáján.
Nyilvánvaló, hogy a teljesítmény függ a készüléken végzett hálózati és kriptográfiai műveletek bonyolultságától (beleértve, hogy mennyire könnyen párhuzamosíthatók és csőbe állíthatók ezek a feladatok), valamint a hardver teljesítményétől és a beépített szoftver minőségétől. Ezért a magasabb modellváltozatokban erősebb "vasat" használnak, és néha lehetőség van további processzorokkal és memóriamodulokkal bővíteni a rendszert. Különböző megközelítések léteznek a kriptográfiai funkciók megvalósítására: az általános központi processzoron (CPU), speciális, egyedi integrált áramkörben (ASIC) vagy programozható logikai integrált áramkörben (FPGA). Minden megközelítésnek megvannak a maga előnyei és hátrányai. Például a CPU a titkosítás "palacknyaka" lehet, különösen akkor, ha a processzor nem rendelkezik a titkosítási algoritmusok támogatásához szükséges speciális utasításokkal (vagy ha ezeket nem alkalmazzák). A speciális mikroschémák hiányolják a rugalmasságot, és nem mindig lehet őket "újraprogramozni" a teljesítmény javítása, új funkciók hozzáadása vagy sebezhetőségek megszüntetése érdekében. Ezen kívül csak nagy mennyiségű gyártás esetén válnak gazdaságossá. Ezért lett annyira népszerű a "közepes megoldás" - az FPGA (magyarul PLI) alkalmazása. A PLI-n készültek az úgynevezett kripto-gyorsítók - beépített vagy csatlakoztatható, speciális hardveres modulok a kriptográfiai műveletek támogatására.
Mivel éppen hálózati titkosításról van szó, logikus, hogy a megoldások teljesítményét azonos mértékegységekben kell mérni, mint más hálózati eszközökét - sávszélesség, csomagveszteségi arány (frame loss) és késleltetés (latency). Ezek az értékek az RFC 1242-ben vannak meghatározva. Egyébként, a késleltetés variációjáról (jitter) gyakran említett információk az RFC-ben nincsenek megemlítve. Hogyan mérjük ezeket az értékeket? Semmilyen hivatalos (vagy nem hivatalos, mint az RFC) szabványban nem találtam kifejezetten hálózati titkosításra kidolgozott módszert. Logikus lenne a hálózati eszközökre vonatkozó RFC 2544-ben rögzített módszert használni. Sokan követik ezt, de nem mindenki. Például tesztforgalmat csak egy irányba bocsátanak ki ahelyett, hogy mindkét irányba, ahogyan azt ajánlott a szabvány előírja. Na de ez már mindegy.
A hálózati titkosítóeszközök teljesítményének mérésének vannak sajátosságai. Először is, helyes az összes mérést egy pár eszközre végezni: noha a titkosítási algoritmusok szimmetrikusak, a késések és a csomagveszteségek titkosításnál és visszafejtésnél nem feltétlenül lesznek egyenlőek. Másodszor, érdemes kifejezetten a delta mérése, a hálózati titkosítás hatása a végső teljesítményre, összehasonlítva két konfigurációt: titkosítóeszközök nélkül és azokkal. Vagy, ahogy a hibrid eszközöknél van, amelyek több funkciót ötvöznek a hálózati titkosításon kívül, titkosítás ki- és bekapcsolt állapotában. Ez a hatás változó lehet, és függ a titkosítóeszközök csatlakozási sémájától, a működési módoktól, végül pedig a forgalom jellegétől. Különösen számos teljesítményparaméter függ a csomagok hosszától, ezért a különböző megoldások teljesítményének összehasonlítására gyakran grafikonokat használnak, amelyek azt mutatják, hogy ezek a paraméterek hogyan függnek a csomagok hosszától, vagy IMIX-et használnak - a forgalom eloszlását csomaghossz alapján, ami nagyjából a valósat tükrözi. Ha ugyanazt az alapkonfigurációt vesszük forrázként, titkosítás nélkül, akkor össze tudjuk hasonlítani a különböző, formailag eltérő megoldásokat a hálózati titkosításra anélkül, hogy ezekbe a különbségekbe mélyebben belemerülnénk: L2 és L3, „tárolj-és-továbbíts” (store-and-forward) és vágott átvitel (cut-through), szakosított vs. konvergált, GOST és AES, és így tovább.
A teljesítménytesztelés csatlakozási sémája
Az első jellemző, amire figyelni kell, a titkosítóeszköz "sebessége", azaz sávszélesség (bandwidth) a hálózati interfészein, a bitfolyam sebessége. Ezt a hálózati szabványok határozzák meg, amelyek támogatottak az interfészek által. Ethernet esetén a szokásos számok 1 Gbit/s és 10 Gbit/s. De, ahogy tudjuk, bármilyen hálózatban a maximális elméleti átviteli kapacitás (átháram) mindegyik szintjén mindig alacsonyabb, mint a sávszélesség: a sávszélesség egy része „megeszi” a keretközi időket, a címeket és így tovább. Ha az eszköz képes fogadni, feldolgozni (jelen esetben titkosítani vagy visszafejteni) és továbbítani a forgalmat a hálózati interfész teljes sebességén, azaz a hálózati modell szintjén maximális elméleti kapacitással, akkor azt mondják, hogy az eszköz működik vonalsebességgel. Ehhez az szükséges, hogy az eszköz ne veszítsen, ne dobjon el csomagokat, bármilyen méretben és bármilyen követési frekvenciával. Ha a titkosító eszköz nem támogatja a vonalsebességet, általában a maximális sávszélességét gigabitben adják meg másodpercenként (néha a csomagok hosszúságával együtt - minél rövidebbek a csomagok, annál általában alacsonyabb a sávszélesség). Nagyon fontos megérteni, hogy a maximális sávszélesség a maximális veszteségmentes (még akkor is, ha az eszköz képes „átpumpálni” a forgalmat nagyobb sebességgel, de közben csomagokat veszít). Ezen kívül figyelni kell arra is, hogy egyes gyártók az összes portpár közötti összesített sávszélességet mérik, így ezek a számok nem sokat mondanak, ha az összes titkosított forgalom egyetlen porton keresztül megy.
Hol különösen fontos a vonalsebesség (más néven csomagvesztés nélküli működés)? Magas sávszélességű és nagy késleltetésű csatornákban (például műholdas) ahol a magas átviteli sebesség fenntartása érdekében nagy TCP ablakméretet kell beállítani, és ahol a csomagvesztés drasztikusan csökkenti a hálózat teljesítményét.
De nem minden sávszélesség használható hasznos adatok továbbítására. Figyelembe kell venni a úgynevezett többletköltségeket (overhead) átvitel. Ez az eszköz titkosításának átvitelének (százalékban vagy bájtban) azon része, amely valójában elveszik (nem használható az alkalmazási adatok továbbítására). Az átvitel elsősorban a titkosított hálózati csomagok adatmezőjének méretének növekedéséből (kiegészítések, „párnázás”) ered, ami a titkosítási algoritmustól és működési módjától függ. Másodszor, a csomagok fejléceinek hosszának emelkedéséből (alagút üzemmód, titkosító protokoll szolgáltatói beszúrása, hamisítványos beszúrás stb., a protokolltól és a titkosítási mód működésétől függően) - általában ezek az átvitel jelentős részét képezik, és ezekre figyelnek először. Harmadszor, a csomagok fragmentációjából, ha a maximális adatlengyelet (MTU) meghaladja (ha a hálózat képes a MTU-t meghaladó csomagot két részre bontani, megkettözve annak fejléceit). Negyedszer, a titkosító eszközök közötti kiegészítő szolgáltatói (ellenőrző) forgalomból (kulcsok cseréjére, alagutak létrehozására stb.). Alacsony átvitelre van szükség ott, ahol a csatorna átvitelének kapacitása korlátozott. Ez különösen a kis csomagokból, például a hangforgalomból származó forgalomnál nyilvánvaló - itt az átvitel több mint a sávszélesség felét „elfogyaszthatja”!
Sávszélesség
Végül, van még beviteli késleltetés – a hálózati késleltetés (az adatainak hálózaton való átjutásáig eltelt idő) különbsége (másodperc törtrészekben) az adatok hálózati titkosítása nélküli és azzal titkosított átadása között. Általánosságban elmondható, hogy minél alacsonyabb a késleltetés („latencia”) a hálózatban, annál kritikusabbá válik a titkosító eszközök által okozott késleltetés. A késleltetést maga a titkosítási művelet hozza létre (ez függ a titkosítási algoritmustól, a blokk hosszától és a titkosítási mód működésétől, valamint a szoftver megvalósításának minőségétől), valamint a hálózati csomag feldolgozása is az eszközben. A bevezetett késleltetés függ a csomagok feldolgozási módjától (átfolyós vagy „tartsd meg-és-átadd”), valamint a platform teljesítményétől (az FPGA vagy ASIC „hardveres” megvalósítás általában gyorsabb, mint a CPU-n végzett „szoftveres” megoldás). Az L2 titkosítás szinte mindig alacsonyabb bevezetett késleltetéssel jár, mint az L3 vagy L4 titkosítás: ez azzal magyarázható, hogy az L3/L4-en titkosító eszközök gyakran konvergens megoldásként vannak végrehajtva. Például a magasan sebességű Ethernet titkosítók, amelyek FPGA-ba vannak megvalósítva és L2-n titkosítanak, a titkosítási műveletből adódó késleltetés elhanyagolhatóan csekély – néha, ha két eszközön aktiváljuk a titkosítást, a közösen okozott késleltetés még csökken is! Az alacsony késleltetés fontos, ahol az összevont késleltetések a csatornában, beleértve a jel terjedési késleltetését is, az egy kilométernyi távolságra körülbelül 5 mikrosekundum. Tehát elmondható, hogy városi méretű hálózatok (több kilométer átmérőjű) esetében a mikrosekundumok sokat jelenthetnek. Például adatbázisok szinkron replikálásakor, nagyfrekvenciás kereskedésnél vagy ugyanazon blokkláncnál.
Bevezetett késleltetés
Skálázhatóság
A nagy elosztott hálózatok akár több ezer csomópontot és hálózati eszközt, valamint száz helyi hálózati szegmenst is tartalmazhatnak. Fontos, hogy a titkosítási megoldások ne rakjanak további korlátokat az elosztott hálózat méretére és topológiájára. Ez elsősorban a csomópontok és hálózatok maximális címzésére vonatkozik. Ilyen korlátokkal találkozhatunk például a titkosítással védett hálózat többpontos topológiájának megvalósításakor (független védett kapcsolatok, vagy alagutak) vagy a szelektív titkosítás (például protokollszám vagy VLAN alapján) esetén. Ha közben a hálózati címek (MAC, IP, VLAN ID) kulcsként használatosak egy táblában, amelynek sorainak száma korlátozott, akkor itt fognak megjelenni ezek a korlátok.
Ezen kívül a nagy hálózatok gyakran több struktúrális szinttel rendelkeznek, beleértve a gerinchálózatot, mindegyiken saját címzési rendszert és irányítási politikát alkalmaznak. Az ilyen megközelítés megvalósításához gyakran használnak speciális keretformátumokat (például Q-in-Q vagy MAC-in-MAC) és útvonal-határozó protokollokat. Ahhoz, hogy ne akadályozzák az ilyen hálózatok kiépítését, a titkosító eszközöknek helyesen kell kezelniük ezeket a kereteket (tehát ebben az értelemben a skálázhatóság kompatibilitást jelent – erről lentebb lesz szó).
Rugalmasság
Ez különböző konfigurációk, csatlakozási séma, topológiák és egyéb dolgok támogatásáról szól. Például a Carrier Ethernet technológián alapuló kapcsolt hálózatok esetében ez különböző típusú virtuális kapcsolatok támogatását jelenti (E-Line, E-LAN, E-Tree), különböző szolgáltatási típusokat (portok és VLAN alapján) és különböző szállítási technológiákat (ezeket már fentebb felsorolták). Tehát az eszköznek képesnek kell lennie arra, hogy egyaránt működjön vonali („pont-pont”) és többpontos üzemmódban, külön alagutakat állítva be különböző VLAN-ok számára, és lehetővé kell tennie a csomagok rendezetlen kézbesítését a védett csatornán belül. A különböző titkosítási üzemmódok (a tartalom hitelesítésével vagy anélkül) és a csomagátviteli üzemmódok kiválasztásának lehetősége egyensúlyt biztosít a tartósság és a teljesítmény között a jelenlegi körülmények függvényében.
A privát hálózatok támogatása is fontos, amelyek berendezései egyetlen szervezet birtokában vannak (vagy azt bérelik), és az üzemeltetői hálózatok, amelyek különböző szegmensei különböző cégek irányítása alatt állnak. Jó, ha a megoldás lehetővé teszi a saját erőforrásokkal, valamint egy harmadik fél által történő irányítást (kezelési szolgáltatás modell). Az üzemeltetői hálózatok esetében egy másik fontos funkció a többbérlős támogatás (különböző megrendelők közötti közös használat) a különböző megrendelők (előfizetők) titkosított elkülönítésének formájában, akiknek forgalma ugyanazon titkosító berendezések egy csoportján halad át. Általában ez különálló kulcs- és tanúsítványkészletek használatát követeli meg minden egyes megrendelő számára.
Ha a készülék egy konkrét tervhez készül, akkor ezek a lehetőségek nem feltétlenül kritikusak – csak annyit kell biztosítani, hogy a készülék támogassa, amit most szükséges. De ha a megoldás „jövőbeli növekedésre” van szánva, hogy a jövőbeli forgatókönyveket is támogassa, és „vállalati szabványnak” választják, akkor a rugalmasság nem árt – különösen figyelembe véve a különböző gyártók eszközeinek interoperabilitására vonatkozó korlátozásokat (erről később).
Egyszerűség és kényelem
A karbantartás kényelme is egy soktényezős fogalom. Hozzávetőlegesen elmondható, hogy ez a különböző szakképzettségű szakemberek időbeli költségeinek összessége, amelyek a megoldás támogatásához szükségesek annak életciklusának különböző szakaszaiban. Ha nincsenek költségek, és a telepítés, beállítás, üzemeltetés teljesen automatikus, akkor a költségek nullák, a kényelem pedig abszolút. Természetesen a valóságban ilyesmi nem létezik. Egy ésszerű megközelítés a modell „csomópont a vezetéken” (bump-in-the-wire), vagy átlátszó csatlakozás, ahol titkosító eszközök hozzáadása és eltávolítása nem igényel manuális vagy automatikus változtatásokat a hálózat konfigurációjában. Ez egyszerűsíti a megoldás karbantartását: nyugodtan bekapcsolhatjuk és kikapcsolhatjuk a titkosítást, és ha szükséges, egyszerűen "körbejárhatjuk" az eszközt egy hálózati kábellel (tehát közvetlenül összekapcsoljuk azokat a portokat, amelyekhez csatlakozott). Az igazság az, hogy ennek is van egy hátránya – ugyanezt megteheti egy támadó is. Az "eszközön a vezetéken" elv megvalósításához figyelembe kell venni a forgalmat nemcsak adatrétegen, hanem ellenőrzési és vezérlési rétegeken – az eszközöknek átláthatónak kell lenniük számukra. Ezért ezt a forgalmat csak akkor lehet titkosítani, ha a titkosító eszközök között nincsenek olyan forgalom célpontok, mert ha ezt eldobjuk vagy titkosítjuk, a titkosítás bekapcsolása és kikapcsolása esetén megváltozhat a hálózat konfigurációja. A titkosító eszköznek átláthatónak kell lennie a fizikai szintű jelzés szempontjából is. Különösen, ha jelvesztés történik, ennek a hiányt vissza kell jelentenie (tehát le kell kapcsolnia az adóit) magának és előre a jel irányába.
Ugyanakkor fontos támogatnia a hatáskörök elkülönítését az IT és az IT biztonsági osztályok között, különösen a hálózati osztály esetében. A titkosítási megoldásnak támogatnia kell a szervezeten belüli elfogadott hozzáférés- és auditkezelési modellt. Minimálisra kell csökkenteni a szükséges interakciót a különböző osztályok között a rutinszerű műveletek végrehajtásához. Ezért a titkosítási funkciókat kizárólag támogató, maximálisan átlátszó speciális eszközök képesek biztosítani a kényelmet. Egyszerűen fogalmazva, az IT biztonsági osztály munkatársainak nem kellene okot adniuk arra, hogy a "hálózatosokhoz" forduljanak a hálózati beállítások módosítása miatt. És a hálózatosoknak sem lenne szükségük a titkosítási beállítások módosítására a hálózat karbantartása során.
Egy másik tényező a kezelési eszközök lehetősége és kényelme. Ezeknek átláthatóknak, logikusnak kell lenniük, biztosítaniuk kell a beállítások importálását és exportálását, automatizálást és így tovább. Azonnal figyelmet kell fordítani arra, hogy milyen kezelési lehetőségek állnak rendelkezésre (általában saját kezelőfelület, webes felület és parancssor) és milyen funkciókkal rendelkezik mindegyik (vannak korlátozások). Fontos funkció a támogatás kivülről (out-of-band) kezelés, vagyis egy dedikált kezelőhálózaton keresztül, és belülről (in-band) kezelés, vagyis a közös hálózaton, amelyen a hasznos forgalom is áthalad. A kezelési eszközöknek jelezniük kell minden rendellenes helyzetet, beleértve az informatikai biztonsági incidenseket. A rutinszerű, ismétlődő műveleteket automatikusan kell végrehajtani. Elsősorban ez vonatkozik a kulcskezelésre. Ezeknek automatikusan kell generálódniuk/elosztódniuk. A PKI támogatása nagy előny.
Kompatibilitás
Ez a készülék kompatibilitását jelenti a hálózati szabványokkal. Nemcsak az ipari szabványokról van szó, amelyeket olyan elismert szervezetek fogadtak el, mint az IEEE, hanem az iparág vezetőinek saját protokolljairól is, például a Ciscóról. Két alapvető módja van a kompatibilitás biztosításának: vagy a áttetszőség, vagy a kifejezett támogatás protokollokhoz (amikor a titkosító eszköz egy protokoll számára a hálózat egyik csomópontjává válik, és kezeli az adott protokoll ellenőrző forgalmát). A kontroll protokollok teljes érvényesítése és helyessége határozza meg a hálózatokkal való kompatibilitást. Fontos a különböző PHY szintű variációk támogatása (sebességek, közvetítési környezet, kódolási sémák), különböző formátumú Ethernet keretek bármilyen MTU-val, valamint különböző L3 szolgáltatási protokollok (elsősorban a TCP/IP családból).
Az áttetszőség pedig a mutációs mechanizmusok (az üzenetek nyílt fejlécének ideiglenes módosítása a titkosítók közötti forgalomban), átengedés (amikor a különböző csomagok nem titkosítva maradnak) és a titkosítási kezdeti eltolása (amikor a rendszerint titkosított mezők nem titkosítva maradnak) révén biztosított.
Hogyan biztosítják az áttetszőséget
Ezért mindig tisztázza, hogyan garantálják egy adott protokoll támogatását. Gyakran a támogatás átlátható üzemmódban kényelmesebb és megbízhatóbb.
Interoperabilitás
Ez is kompatibilitás, de más értelemben, nevezetesen a lehetőséget jelenti, hogy együtt működjön más titkosító eszközmodellekkel, beleértve más gyártók termékeit is. Itt sok minden a titkosítási protokollok standardizálásának állapotától függ. Az L1-es szinten egyszerűen nincsenek elismert titkosítási standardok.
Ethernet hálózatokban az L2 titkosításhoz van egy 802.1ae (MACsec) standard, de ez nem végpontok közötti (end-to-end), hanem portok közötti, „ugrás-ugrás” (hop-by-hop) titkosítást használ, és eredeti formájában nem volt alkalmas elosztott hálózatokban való használatra, ezért születtek a gyártói bővítmények, amelyek áthidalták ezt a korlátozást (természetesen a más gyártók berendezéseivel való interoperabilitás rovására). Igaz, hogy 2018-ban az 802.1ae standardhoz hozzáadták az elosztott hálózatok támogatását, de a GOST titkosítási algoritmusok támogatása továbbra sincs. Ezért a gyártói, nem standard L2 titkosítási protokollok általában nagyobb hatékonysággal (különösen alacsonyabb sávszélességi költségekkel) és rugalmassággal (titkosító algoritmusok és üzemmódok megváltoztatásának lehetősége) bírnak.
Magasabb szinten (L3 és L4) elismert standardok léteznek, elsősorban az IPsec és TLS, de itt sem minden olyan egyszerű. Az a helyzet, hogy mindkét standard egy protokollkészlet, amelyek mindegyike különböző verziókkal és kötelező vagy nem kötelező bővítményekkel rendelkezik. Ezen kívül egyes gyártók a saját gyártói titkosítási protokolljaikat is előnyben részesítik az L3/L4 szinten. Ezért a legtöbb esetben nem érdemes teljes interoperabilitásra számítani, de fontos, hogy legalább a különböző modellek és azonos gyártó különböző generációi közötti interakció biztosítva legyen.
Megbízhatóság
A különböző megoldások összehasonlítására használható vagy a meghibásodási zónák átlagos működési ideje, vagy a rendelkezésre állási tényező. Ha ezek az adatok nem állnak rendelkezésre (vagy nem megbízhatóak), akkor minőségi összehasonlítást lehet végezni. Előnyben részesülnek a könnyen kezelhető eszközök (kevesebb a konfigurációs hibák kockázata), a speciális titkosítók (ugyanezért), valamint azok a megoldások, amelyek minimális meghibásodás- és hibaelhárítással rendelkeznek, beleértve a teljes csomópontok és eszközök „forró” tartalékait.
Ár
Ami a költségeket illeti, ugyanúgy, mint a legtöbb IT-megoldás esetében, célszerű összehasonlítani az összköltséget. Ennek meghatározásához nem szükséges újra feltalálni a kereket, bármilyen megfelelő módszert (például a Gartner-től) és bármilyen kalkulátort (például azt, amelyet már használnak a szervezetnél az összköltség számításához) használhatunk. Nyilvánvaló, hogy a hálózati titkosítás esetén az összköltség az alábbiakból áll össze közvetlen kiadásokból, amelyek a megoldás megvásárlására vagy bérlésére, a berendezések elhelyezésére szolgáló infrastruktúrára, valamint a telepítési, adminisztrációs és karbantartási költségekből adódnak (függetlenül attól, hogy ezt saját erőforrásokkal végzik, vagy külső szolgáltatóként), valamint közvetett költségekből, amelyek a megoldás leállásából adódnak (a végfelhasználók termelékenységének elvesztése miatt). Valószínűleg csak egy apróság van. A megoldás teljesítményének hatását eltérően lehet figyelembe venni: vagy mint a termelékenység csökkenéséből eredő közvetett költségeket, vagy mint "virtuális" közvetlen kiadásokat a hálózati eszközök vásárlására/frissítésére és karbantartására, amelyek kompenzálják a hálózati teljesítmény csökkenését a titkosítás alkalmazása miatt. Mindenesetre a nehezen kiszámítható költségeket érdemes "kivenni a számításból": így nagyobb bizalom kíséri a végső értéket. Mint általában, különböző eszközök TCO szerinti összehasonlítása mindig érdemes, egy adott használati forgatókönyv alapján – legyen az valós vagy tipikus.
Megbízhatóság
És az utolsó jellemző a megoldás ellenállása. A legtöbb esetben az ellenállás kvalitativ módon értékelhető, különböző megoldások összehasonlításával. Emlékeznünk kell arra, hogy a titkosító eszközök nemcsak eszközök, hanem védett objektumok is. Különböző fenyegetéseknek lehetnek kitéve. Az elsődleges fenyegetések közé tartozik a bizalmasság megsértése, az üzenetek visszaélése és módosítása. Ezek a fenyegetések a titkosítás gyengeségein vagy a titkosítási protokollok (a kapcsolatfelépítés és a kulcsgenerálás/elosztás szakaszában) sebezhetőségein keresztül valósulhatnak meg. Az előny azoknál a megoldásoknál lesz, amelyek lehetővé teszik a titkosítási algoritmus váltását vagy a titkosítási mód átváltását (legalábbis az beágyazott szoftver frissítése révén), azoknál a megoldásoknál, amelyek maximális titkosítást biztosítanak, elrejtve a támadó elől nemcsak a felhasználói adatokat, hanem a címzési és egyéb segédinformációkat is, valamint azoknál a megoldásoknál, amelyek nemcsak titkosítanak, hanem védik az üzeneteket a visszaélésektől és módosításoktól is. Minden modern titkosító algoritmusra, elektronikus aláírásra, kulcsgenerálásra és egyebekre, amelyek a normákban rögzítettek, az ellenállás azonosnak tekinthető (különben egyszerűen el lehet tévedni a kriptográfia dzsungelében). Kell-e szükségszerűen a GOST algoritmusoknak lennie? Itt minden egyszerű: ha az alkalmazási forgatókönyv megköveteli az FSB általi tanúsítást a titkosítási eszközöknél (Oroszországban ez a legtöbb esetben így van), a hálózati titkosítási forgatókönyvek többségében ez így van), akkor csak a tanúsítottak között válasszunk. Ha nem – akkor nincs értelme a tanúsítvány nélküli eszközöket kizárni a megfontolásból.
Egy másik fenyegetés a hackelés, az eszközökhöz való jogosulatlan hozzáférés (beleértve a fizikális hozzáférést kívülről és a házon belül). A fenyegetés megvalósulhat a
A sebezhetőségek a hardvereszközök és a kód megvalósításában találhatók. Ezért előnyben lesznek azok a megoldások, amelyeknek minimális "támadási felületük" van a hálózaton, fizikailag védett házakkal (feltörést jelző szenzorokkal, behatolás ellen védő megoldásokkal és automatikus kulcsinformáció-visszaállítással a ház feltörésekor), valamint azok, amelyek lehetővé teszik a beágyazott szoftver frissítését, amikor a kódban sebezhetőség merül fel. Van még egy lehetőség: ha az összes összehasonlított eszköz rendelkezik FSB tanúsítvánnyal, akkor a betöréssel szembeni ellenállás mutatója a KSZI osztály, amely alapján a tanúsítványt kiadták.
Végül egy másik fenyegetéstípus – a konfigurálási és üzemeltetési hibák, a tényező, amely teljesen emberi. Itt egy másik előny mutatkozik meg a speciális titkosítókkal szemben a konvergáló megoldásokkal, amelyek gyakran tapasztalt „hálózati szakemberekre” támaszkodnak, és nehézségeket okozhatnak a „normál”, széleskörű IT-szakemberek számára.
Összefoglalva
Alapvetően itt fel lehetne ajánlani egy integrált mutatót különböző eszközök összehasonlítására, valami ilyesmit:
$$display$$K_j=∑p_i r_{ij}$$display$$
ahol p – a mutató súlya, r – az eszköz rangja ezen a mutatón, és bármelyik fenti jellemzőt „atomtartalmú” mutatókra lehet bontani. Ez a képlet például hasznos lehet a tenderajánlatok összehasonlításakor, előre megállapított szabályok alapján. De elég lenne egy egyszerű táblázat is, mint például:
Jellemzők
Eszköz 1
Eszköz 2
…
Eszköz N
Sávszélesség
+
+
+++
Költségek
+
++
+++
Késleltetés
+
+
++
Skálázhatóság
+++
+
+++
Rugalmasság
+++
++
+
Interoperabilitás
++
+
+
Kompatibilitás
++
++
+++
Egyszerűség és kényelem
+
+
++
Hibatűrés
+++
+++
++
Ár
++
+++
+
Megbízhatóság
++
++
+++
Örömmel válaszolok a kérdésekre és a konstruktív kritikai megjegyzésekre.
Forrás: habr.com
