VPN<\/a> o senza di essa.<\/p>\nCrittografia di rete in una rete Ethernet distribuita<\/i><\/p>\n
I dispositivi stessi possono essere sia specializzati<\/b> (destinati esclusivamente alla crittografia), sia multifunzionali (ibridi, convergenti<\/b>), cio\u00e8 che svolgono anche altre funzioni (ad esempio, di firewall o di router). I diversi fornitori classificano i loro dispositivi in vari livelli\/categorie, ma questo non \u00e8 rilevante: ci\u00f2 che conta \u00e8 se sono in grado di criptare il traffico inter-sito e quali caratteristiche possiedono.<\/p>\n
Ricordo per sicurezza che 'crittografia di rete', 'crittografia del traffico', 'crittografatore' sono termini informali, anche se utilizzati frequentemente. Negli atti normativi russi (compresi quelli che introdurranno gli standard GOST) \u00e8 probabile che non li incontriate.<\/p>\n
Livelli di crittografia e modalit\u00e0 di trasmissione<\/h4>\n \nPrima di procedere alla descrizione delle caratteristiche che saranno utilizzate per la valutazione, \u00e8 necessario chiarire una questione importante, ovvero il 'livello di crittografia'. Ho notato che viene frequentemente menzionato sia nei documenti ufficiali dei fornitori (nelle descrizioni, nei manuali, ecc.) sia nelle discussioni informali (nelle negoziazioni, nei corsi di formazione). In pratica, sembra che tutti sappiano di cosa si stia parlando, ma ho personalmente assistito a un certo grado di confusione.<\/p>\n
Quindi, cosa si intende per \"livello di crittografia\"? Si fa riferimento al numero del livello del modello di riferimento OSI\/ISO in cui avviene la crittografia. Consulta la norma \u0413\u041e\u0421\u0422 \u0420 \u0418\u0421\u041e 7498-2\u201399 \"Tecnologia dell'informazione. Interconnessione di sistemi aperti. Modello di riferimento fondamentale. Parte 2. Architettura della protezione delle informazioni\". Da questo documento si pu\u00f2 comprendere che il livello del servizio di riservatezza (uno dei meccanismi tramite i quali \u00e8 garantita appunto la crittografia) \u00e8 il livello del protocollo il cui blocco dati di servizio (\"payload\", dati dell'utente) viene crittografato. Come scritto nello standard, il servizio pu\u00f2 essere fornito sia a questo stesso livello, \"con le proprie forze\", sia con l'ausilio di un livello inferiore (\u00e8 proprio cos\u00ec che questo avviene pi\u00f9 frequentemente in MACsec).<\/p>\n
Nella pratica, esistono due modalit\u00e0 di trasmissione delle informazioni crittografate attraverso la rete (immediatamente ci viene in mente IPsec, ma queste modalit\u00e0 si riscontrano anche in altri protocolli). In modalit\u00e0 di trasporto<\/b> (a volte chiamato anche native) viene crittografato solo il servizio<\/b> il blocco dati, mentre gli header rimangono \"aperti\", non cifrati (a volte vengono aggiunti campi aggiuntivi con informazioni di servizio dell'algoritmo di cifratura, mentre altri campi vengono modificati e ricalcolati). In modalit\u00e0 tunnel<\/b> questa modalit\u00e0 protocollo<\/b> il blocco dati (cio\u00e8 il pacchetto stesso) viene cifrato e incapsulato in un blocco dati di servizio dello stesso livello o di livello superiore, cio\u00e8 viene incorniciato con nuovi header.<\/p>\n
Il livello di cifratura in s\u00e9, combinato con qualche modalit\u00e0 di trasmissione, non \u00e8 n\u00e9 buono n\u00e9 cattivo, quindi non si pu\u00f2 dire, ad esempio, che L3 in modalit\u00e0 di trasporto sia migliore di L2 in modalit\u00e0 tunnel. Dipendono da molti caratteri che vengono utilizzati per valutare i dispositivi. Ad esempio, flessibilit\u00e0 e compatibilit\u00e0. Per funzionare nelle reti L1 (ritrasmissione del flusso di bit), L2 (commutazione dei frame) e L3 (instradamento dei pacchetti) in modalit\u00e0 di trasporto sono necessarie soluzioni che cifrano a un livello uguale o superiore (altrimenti verranno cifrate le informazioni di indirizzo e i dati non arriveranno a destinazione), mentre la modalit\u00e0 tunnel consente di superare questa limitazione (per\u00f2 sacrificando altre caratteristiche importanti).<\/p>\n
Modalit\u00e0 di trasporto e tunnelizzazione della crittografia L2<\/i><\/p>\n
Ora passiamo all'analisi delle caratteristiche.<\/p>\n
Prestazioni<\/h4>\n \nLa performance nella crittografia di rete \u00e8 un concetto complesso e multidimensionale. Pu\u00f2 capitare che un certo modello, pur eccellendo in una caratteristica, ne comprometta un'altra. Pertanto, \u00e8 sempre utile considerare tutti gli elementi che influiscono sulla performance della crittografia e il loro impatto sulla performance della rete e delle applicazioni che la utilizzano. Qui si pu\u00f2 tracciare un'analogia con un'automobile, per la quale non conta solo la velocit\u00e0 massima, ma anche il tempo di accelerazione fino ai 100 km\/h, il consumo di carburante e cos\u00ec via. Le caratteristiche prestazionali sono di grande importanza sia per i fornitori che per i clienti potenziali. Di solito, la classificazione dei dispositivi di crittografia da parte dei fornitori si basa proprio sulle performance.<\/p>\n
\u00c8 chiaro che le prestazioni dipendono sia dalla complessit\u00e0 delle operazioni di rete e crittografiche eseguite sul dispositivo (inclusa la capacit\u00e0 di parallelizzazione e pipelining di tali compiti), sia dalle prestazioni dell'hardware e dalla qualit\u00e0 del software integrato. Pertanto, nei modelli superiori vengono utilizzati hardware pi\u00f9 potenti, con la possibilit\u00e0 di aggiornamenti tramite processori aggiuntivi e moduli di memoria. Ci sono diversi approcci per implementare le funzioni crittografiche: su un processore centrale (CPU) universale, un circuito integrato specifico (ASIC) o su un circuito integrato programmabile (FPGA). Ogni approccio ha i suoi vantaggi e svantaggi. Ad esempio, la CPU pu\u00f2 diventare un collo di bottiglia per la crittografia, specialmente se il processore non ha istruzioni specializzate per supportare l'algoritmo di crittografia (o se queste non vengono utilizzate). I chip specializzati mancano di flessibilit\u00e0; non sempre \u00e8 possibile aggiornarli per migliorare le prestazioni, aggiungere nuove funzionalit\u00e0 o risolvere vulnerabilit\u00e0. Inoltre, il loro utilizzo diventa economicamente vantaggioso solo per produzioni su larga scala. \u00c8 per questo che la soluzione del \"giusto mezzo\" \u00e8 diventata cos\u00ec popolare: l'uso di FPGA. Proprio su FPGA sono realizzati i cosiddetti acceleratori crittografici - moduli hardware specializzati integrati o collegabili per supportare operazioni crittografiche.<\/p>\n
Poich\u00e9 si tratta di rete<\/b> crittografia, \u00e8 logico che le prestazioni delle soluzioni debbano essere misurate con le stesse metriche utilizzate per altri dispositivi di rete: larghezza di banda, percentuale di frame persi (frame loss) e latenza. Queste metriche sono definite nella RFC 1242. A proposito, nella RFC non viene scritto nulla sulla variante di latenza spesso citata (jitter). Come misurare queste metriche? Non ho trovato metodologie approvate in standard (ufficiali o non ufficiali come la RFC) specificamente per la crittografia di rete. Sarebbe logico utilizzare la metodologia per dispositivi di rete stabilita nello standard RFC 2544. Molti fornitori la seguono, molti, ma non tutti. Ad esempio, forniscono il traffico di test solo in una direzione invece che in entrambe, come \u00e8 consigliato<\/b> stabilito dallo standard. Ma va bene.<\/p>\n
La misurazione delle prestazioni dei dispositivi di crittografia di rete ha comunque le sue peculiarit\u00e0. Innanzitutto, \u00e8 corretto eseguire tutte le misurazioni per una coppia di dispositivi: anche se gli algoritmi di crittografia sono simmetrici, i ritardi e la perdita di pacchetti durante la crittografia e la decrittografia non saranno necessariamente uguali. In secondo luogo, ha senso misurare precisamente la delta, l'impatto della crittografia di rete sulle prestazioni complessive della rete, confrontando due configurazioni: senza dispositivi di crittografia e con essi. Oppure, nel caso di dispositivi ibridi che combinano pi\u00f9 funzioni oltre alla crittografia di rete, valutando entrambi i casi, sia con crittografia attivata che disattivata. Questo impatto pu\u00f2 variare e dipendere dallo schema di connessione dei dispositivi di crittografia, dai loro modelli operativi e, infine, dalla natura del traffico. In particolare, molti parametri di prestazione dipendono dalla lunghezza dei pacchetti; ecco perch\u00e9 per confrontare le prestazioni di diverse soluzioni si utilizzano spesso grafici che mostrano la dipendenza di questi parametri dalla lunghezza dei pacchetti, oppure si utilizza IMIX, una distribuzione del traffico per lunghezze di pacchetti che riflette approssimativamente la realt\u00e0. Se confrontiamo la stessa configurazione di base senza crittografia, saremo in grado di confrontare soluzioni per la crittografia di rete implementate in modo diverso, senza entrare nei dettagli: L2 con L3, store-and-forward con cut-through, specializzati con convergenti, GOST con AES e cos\u00ec via.<\/p>\n
Schema di collegamento per il test delle prestazioni<\/i><\/p>\n
La prima caratteristica a cui prestare attenzione \u00e8 la \"velocit\u00e0\" del dispositivo di crittografia, ovvero la larghezza di banda<\/b> (bandwidth) delle sue interfacce di rete, la velocit\u00e0 di flusso dei bit. Essa \u00e8 determinata dagli standard di rete supportati dalle interfacce. Per Ethernet, i numeri comuni sono 1 Gbit\/s e 10 Gbit\/s. Tuttavia, come sappiamo, in qualsiasi rete la massima capacit\u00e0 teorica di throughput<\/b> (throughput) a ciascun livello \u00e8 sempre inferiore alla larghezza di banda: parte della larghezza viene \"consumata\" da intervalli tra i frame, intestazioni di controllo e cos\u00ec via. Se un dispositivo \u00e8 in grado di ricevere, elaborare (in questo caso crittografare o decrittografare) e trasmettere traffico alla piena velocit\u00e0 dell'interfaccia di rete, ovvero con la massima capacit\u00e0 teorica per quel livello del modello di rete, allora si dice che funziona alla velocit\u00e0 della linea<\/b>. \u00c8 fondamentale che il dispositivo non perda e non scarti pacchetti, indipendentemente dalla loro dimensione e dalla loro frequenza. Se un dispositivo di crittografia non supporta il funzionamento alla velocit\u00e0 di linea, spesso viene specificata la sua larghezza di banda massima in gigabit al secondo (a volte con l'indicazione della lunghezza dei pacchetti: pacchetti pi\u00f9 corti di solito comportano una minore larghezza di banda). \u00c8 molto importante comprendere che la larghezza di banda massima \u00e8 il massimo senza perdite<\/b> (anche se il dispositivo pu\u00f2 gestire il traffico a velocit\u00e0 superiori, ma perdendo comunque una parte dei pacchetti). Inoltre, \u00e8 necessario prestare attenzione al fatto che alcuni fornitori misurano la larghezza di banda totale fra tutte le coppie di porte, quindi questi dati dicono poco se tutto il traffico crittografato passa attraverso una sola porta.<\/p>\n
Dove \u00e8 particolarmente importante lavorare con velocit\u00e0 di linea (o, in altre parole, senza perdita di pacchetti)? Nei canali ad alta capacit\u00e0 e con elevate latenze (ad esempio, satellitari), dove per mantenere elevate velocit\u00e0 di trasmissione \u00e8 necessario impostare una grande dimensione della finestra TCP, e dove la perdita di pacchetti riduce drasticamente le prestazioni della rete.<\/p>\n
Ma non tutta la larghezza di banda \u00e8 utilizzata per la trasmissione di dati utili. \u00c8 necessario tenere conto dei cosiddetti costi operativi<\/b> (overhead) di larghezza di banda. Questa \u00e8 la parte della larghezza di banda del dispositivo di crittografia (in percentuale o in byte per pacchetto) che viene effettivamente persa (non pu\u00f2 essere utilizzata per il trasferimento dei dati delle applicazioni). Le spese generali si verificano, in primo luogo, a causa dell'aumento delle dimensioni (aggiunte, \u00abpadding\u00bb) del campo dati nei pacchetti di rete crittografati (a seconda dell'algoritmo di crittografia e della modalit\u00e0 di funzionamento). In secondo luogo, a causa dell'aumento della lunghezza delle intestazioni dei pacchetti (modalit\u00e0 tunnel, inserimento di protocollo di crittografia, inserimento di autenticit\u00e0, ecc., a seconda del protocollo e della modalit\u00e0 di funzionamento della crittografia e del modo di trasmissione) \u2013 generalmente queste spese generali sono le pi\u00f9 significative e vengono notate per prime. In terzo luogo, a causa della frammentazione dei pacchetti quando si supera la dimensione massima del blocco dati (MTU) (se la rete \u00e8 in grado di frammentare pacchetti che superano l'MTU in due, duplicando le intestazioni). In quarto luogo, a causa della comparsa di ulteriore traffico di servizio (di controllo) tra i dispositivi di crittografia (per lo scambio di chiavi, l'installazione di tunnel, ecc.). Basse spese generali sono importanti dove la larghezza di banda del canale \u00e8 limitata. Questo si manifesta soprattutto nel traffico di pacchetti piccoli, come ad esempio nel traffico vocale \u2013 l\u00ec le spese generali possono \u00abmangiare\u00bb pi\u00f9 della met\u00e0 della velocit\u00e0 del canale!<\/p>\n
Larghezza di banda<\/i><\/p>\n
Finalmente, c'\u00e8 anche latenza applicata<\/b> \u2013 la differenza (in frazioni di secondo) nella latenza di rete (tempo impiegato dai dati per passare dall'ingresso alla rete all'uscita) tra la trasmissione dei dati senza crittografia e quella con essa. In generale, minore \u00e8 la latenza (\u00ablatenza\u00bb) della rete, pi\u00f9 critica diventa la latenza introdotta dai dispositivi di crittografia. La latenza \u00e8 causata sia dall'operazione di crittografia (che dipende dall'algoritmo di crittografia, dalla lunghezza del blocco e dalla modalit\u00e0 di funzionamento della crittografia, cos\u00ec come dalla qualit\u00e0 della sua implementazione nel software), sia dall'elaborazione del pacchetto di rete nel dispositivo. La latenza introdotta dipende sia dalla modalit\u00e0 di elaborazione dei pacchetti (in transito o \u00absalva-e-invia\u00bb), sia dalla performance della piattaforma (l'implementazione \u00abhardware\u00bb su FPGA o ASIC \u00e8 generalmente pi\u00f9 veloce di quella \u00absoftware\u00bb su CPU). La crittografia L2 presenta quasi sempre una latenza introdotta inferiore rispetto alla crittografia L3 o L4: ci\u00f2 \u00e8 dovuto al fatto che i dispositivi che effettuano la crittografia su L3 \/ L4 vengono spesso realizzati in modo convergente. Ad esempio, nei crittografi Ethernet ad alta velocit\u00e0 realizzati su FPGA e che criptano su L2, la latenza causata dall'operazione di crittografia \u00e8 trascurabile: a volte, attivando la crittografia su un paio di dispositivi, la latenza totale introdotta da essi pu\u00f2 addirittura diminuire! Una bassa latenza \u00e8 importante quando \u00e8 comparabile con le latenze totali nel canale, inclusa la latenza di propagazione del segnale, che \u00e8 di circa 5 \u03bcs per chilometro. Quindi si pu\u00f2 dire che per le reti di scala urbana (decine di chilometri di diametro) i microsecondi possono fare una grande differenza. Ad esempio, per la replicazione sincrona dei database, il trading ad alta frequenza e lo stesso blockchain.<\/p>\n
Ritardo introdotto<\/i><\/p>\nScalabilit\u00e0<\/h4>\n
\nLe grandi reti distribuite possono includere migliaia di nodi e dispositivi di rete, centinaia di segmenti di reti locali. \u00c8 fondamentale che le soluzioni di crittografia non imponano limitazioni aggiuntive alle dimensioni e alla topologia della rete distribuita. Questo riguarda in particolare il numero massimo di indirizzi di nodi e reti. Tali limitazioni possono verificarsi, ad esempio, durante l'implementazione di una topologia multi-punto per una rete protetta da crittografia (con connessioni sicure indipendenti o tunnel) o la crittografia selettiva (ad esempio in base al numero di protocollo o VLAN). Se in questo contesto gli indirizzi di rete (MAC, IP, VLAN ID) vengono utilizzati come chiavi in una tabella, il numero di righe della quale \u00e8 limitato, qui si manifestano questi vincoli.<\/p>\n
Inoltre, le grandi reti spesso presentano pi\u00f9 livelli strutturali, inclusa la rete di backbone, ognuno dei quali implementa il proprio schema di indirizzamento e la propria politica di instradamento. Per realizzare questo approccio si utilizzano spesso formati speciali di frame (come Q-in-Q o MAC-in-MAC) e protocolli di determinazione dei percorsi. Affinch\u00e9 la costruzione di tali reti non sia ostacolata, i dispositivi di crittografia devono gestire correttamente tali frame (cio\u00e8, in questo senso, la scalabilit\u00e0 significher\u00e0 compatibilit\u00e0 \u2013 di cui parleremo pi\u00f9 avanti).<\/p>\n
Flessibilit\u00e0<\/h4>\n \nSi tratta del supporto per diverse configurazioni, schemi di connessione, topologie e altro ancora. Ad esempio, per le reti commutate basate su tecnologie Carrier Ethernet, questo significa supportare diversi tipi di connessioni virtuali (E-Line, E-LAN, E-Tree), vari tipi di servizio (sia per porte che per VLAN) e diverse tecnologie di trasporto (gi\u00e0 menzionate sopra). In altre parole, il dispositivo deve essere in grado di operare sia in modalit\u00e0 lineare (\u00abpunto-punto\u00bb), sia in modalit\u00e0 multipunto, stabilendo tunnel separati per diverse VLAN, consentendo la consegna non ordinata dei pacchetti all'interno di un canale protetto. La possibilit\u00e0 di scegliere tra diverse modalit\u00e0 di funzionamento della crittografia (compresa l'autenticazione del contenuto o meno) e diverse modalit\u00e0 di trasmissione dei pacchetti consente di bilanciare tra resilienza e prestazioni a seconda delle condizioni attuali.<\/p>\n
\u00c8 importante anche il supporto per reti private, il cui hardware appartiene a un'unica organizzazione (o \u00e8 in affitto presso di essa), e per reti operative, i cui segmenti sono gestiti da diverse societ\u00e0. \u00c8 vantaggioso se la soluzione consente la gestione sia da parte interna che da un'organizzazione esterna (modello di servizio gestito). In reti operative, un'altra funzione cruciale \u00e8 il supporto per la multitenancy (utilizzo condiviso da parte di diversi clienti), che prevede l'isolamento crittografico per ciascun cliente (abbonato), il cui traffico transita attraverso lo stesso set di dispositivi di crittografia. In generale, ci\u00f2 richiede l'uso di kit di chiavi e certificati separati per ciascun cliente.<\/p>\n
Se il dispositivo viene acquistato per uno specifico scenario, tutte queste funzionalit\u00e0 potrebbero non essere cos\u00ec importanti: \u00e8 sufficiente garantire che il dispositivo supporti ci\u00f2 di cui si ha bisogno al momento. Ma se la soluzione \u00e8 acquistata \"per futuro\", per supportare anche scenari futuri, e viene scelta come \"standard aziendale\", allora la flessibilit\u00e0 sar\u00e0 utile, soprattutto considerando le limitazioni di interoperabilit\u00e0 dei dispositivi di diversi fornitori (ne parliamo pi\u00f9 avanti).<\/p>\n
Semplicit\u00e0 e comodit\u00e0<\/h4>\n \nLa facilit\u00e0 di manutenzione \u00e8 anch'essa un concetto multifattoriale. Si pu\u00f2 dire che rappresenta il tempo totale necessario agli specialisti di un certo livello per supportare la soluzione nelle diverse fasi del suo ciclo di vita. Se non ci sono costi e l'installazione, la configurazione e l'operazione sono completamente automatiche, allora i costi sono nulli e la comodit\u00e0 \u00e8 assoluta. Ovviamente, nel reale non esiste una situazione del genere. Un'approssimazione ragionevole \u00e8 questo modello. \"nodo sul cavo\"<\/b> (bump-in-the-wire), o connessione trasparente, in cui l'aggiunta e la rimozione di dispositivi di crittografia non richiede modifiche manuali o automatiche alla configurazione della rete. Questo semplifica la manutenzione della soluzione: \u00e8 possibile attivare e disattivare la funzione di crittografia in modo tranquillo e, se necessario, \u00abbypassare\u00bb semplicemente il dispositivo con un cavo di rete (cio\u00e8 collegare direttamente le porte dell'equipaggiamento di rete a cui era connesso). Tuttavia, c'\u00e8 un lato negativo: lo stesso pu\u00f2 fare anche un malintenzionato. Per implementare il principio del \u00abnodo sul filo\u00bb \u00e8 necessario tenere conto del traffico non solo livello dati<\/b>, ma anche livelli di controllo e gestione<\/b> \u2013 i dispositivi devono essere trasparenti per loro. Pertanto, tale traffico pu\u00f2 essere crittografato solo quando non ci sono destinatari del traffico di questi tipi nella rete tra i dispositivi di crittografia, poich\u00e9 se viene scartato o crittografato, la configurazione della rete potrebbe cambiare durante l'attivazione o disattivazione della crittografia. Il dispositivo di crittografia pu\u00f2 essere trasparente anche per il segnalamento a livello fisico. In particolare, in caso di perdita di segnale, deve comunicare tale perdita (cio\u00e8 disattivare i propri trasmettitori) avanti e indietro (\u00abper conto proprio\u00bb) nella direzione del segnale.<\/p>\n
\u00c8 anche importante supportare la separazione dei poteri tra i reparti di sicurezza informatica e IT, in particolare quello di rete. La soluzione di crittografia deve supportare il modello di gestione degli accessi e audit adottato dall'organizzazione. \u00c8 necessario ridurre al minimo l'interazione tra i diversi reparti per svolgere operazioni di routine. Pertanto, c'\u00e8 un vantaggio in termini di convenienza per i dispositivi specializzati che supportano esclusivamente le funzionalit\u00e0 di crittografia e sono massimamente trasparenti per le operazioni di rete. In parole povere, il personale della sicurezza informatica non dovrebbe avere motivo di contattare i \"network engineer\" per modifiche alle impostazioni di rete. E, a loro volta, non dovrebbero esserci necessit\u00e0 di modificare le impostazioni di crittografia durante la manutenzione della rete.<\/p>\n
Un altro fattore \u00e8 la funzionalit\u00e0 e la comodit\u00e0 dei mezzi di gestione. Devono essere chiari, logici e offrire l'importazione e l'esportazione delle impostazioni, l'automazione e cos\u00ec via. \u00c8 importante prestare attenzione a quali opzioni di gestione sono disponibili (di solito si tratta di un ambiente di gestione proprietario, di un'interfaccia web e della linea di comando) e a quale set di funzioni ha ciascuna di esse (possono esserci limitazioni). Una funzione importante \u00e8 il supporto per la gestione<\/b> (out-of-band), cio\u00e8 tramite una rete di gestione dedicata, e per la gestione<\/b> (in-band), cio\u00e8 tramite la rete comune su cui passa il traffico utile. I mezzi di gestione devono segnalare tutte le situazioni anomale, comprese le violazioni della sicurezza. Le operazioni di routine e ripetitive devono essere eseguite automaticamente. Questo riguarda principalmente la gestione delle chiavi. Esse devono essere generate\/distribuite automaticamente. Il supporto PKI \u00e8 un grande vantaggio.<\/p>\nCompatibilit\u00e0<\/h4>\n
\nCio\u00e8, la compatibilit\u00e0 del dispositivo con gli standard di rete. Questo si riferisce non solo agli standard industriali adottati da organizzazioni autorevoli come l'IEEE, ma anche ai protocolli proprietari dei leader del settore, come ad esempio Cisco. Ci sono due modi principali per garantire la compatibilit\u00e0: o attraverso trasparenza<\/b>, o attraverso supporto esplicito<\/b> dei protocolli (quando il dispositivo di crittografia diventa per un certo protocollo uno dei nodi della rete e gestisce il traffico di controllo di quel protocollo). La compatibilit\u00e0 con le reti dipende dalla completezza e correttezza dell'implementazione dei protocolli di controllo. \u00c8 fondamentale il supporto di diverse opzioni per il livello PHY (velocit\u00e0, media di trasmissione, schemi di codifica), frame Ethernet di vari formati con qualsiasi MTU, e diversi protocolli di servizio L3 (soprattutto della famiglia TCP\/IP).<\/p>\n
La trasparenza \u00e8 garantita tramite meccanismi di mutazione (cambiamento temporaneo del contenuto delle intestazioni aperte nel traffico tra i crittografi), di bypass (quando singoli pacchetti rimangono non crittografati) e di spostamento dell'inizio della crittografia (quando i campi dei pacchetti che normalmente sono crittografati non vengono crittografati).<\/p>\n
Come si garantisce la trasparenza<\/i><\/p>\n
Quindi, assicurati sempre di chiarire come viene garantito il supporto per i vari protocolli. Spesso, il supporto in modalit\u00e0 trasparente \u00e8 pi\u00f9 comodo e affidabile.<\/p>\n
Interoperabilit\u00e0<\/h4>\n \nQuesto \u00e8 un altro tipo di compatibilit\u00e0, ma in un senso diverso, ovvero la capacit\u00e0 di collaborare con altri modelli di dispositivi di crittografia, inclusi quelli di altri produttori. Qui molto dipende dallo stato della standardizzazione dei protocolli di crittografia. Non ci sono semplicemente standard di crittografia L1 riconosciuti da tutti.<\/p>\n
Per la crittografia L2 nelle reti Ethernet esiste lo standard 802.1ae (MACsec), ma non utilizza la crittografia<\/b> (end-to-end), ma inter-port<\/b>, \u00abhop-by-hop\u00bb (a catena) crittografia, e nella sua versione originale non \u00e8 adatto per l'uso in reti distribuite, quindi sono emerse le sue estensioni proprietarie che superano questa limitazione (naturalmente, a scapito dell'interoperabilit\u00e0 con l'hardware di altri produttori). Tuttavia, nel 2018, \u00e8 stata aggiunta supporto per reti distribuite nello standard 802.1ae, ma il supporto per i set di algoritmi di crittografia GOST \u00e8 ancora assente. Pertanto, i protocolli di crittografia L2 proprietari e non standardano generalmente una maggiore efficienza (in particolare, minori costi in banda) e flessibilit\u00e0 (possibilit\u00e0 di cambiare algoritmi e modalit\u00e0 di crittografia).<\/p>\n
Ai livelli superiori (L3 e L4) esistono standard riconosciuti, in primo luogo IPsec e TLS, ma anche qui non \u00e8 tutto cos\u00ec semplice. Infatti, ognuno di questi standard \u00e8 un insieme di protocolli, ciascuno con diverse versioni e con estensioni obbligatorie o facoltative da implementare. Inoltre, alcuni produttori preferiscono utilizzare i propri protocolli di crittografia anche a L3\/L4. Pertanto, nella maggior parte dei casi, non \u00e8 realistico aspettarsi piena interoperabilit\u00e0, ma \u00e8 importante garantire almeno l'interazione tra diversi modelli e diverse generazioni dello stesso produttore.<\/p>\n
Affidabilit\u00e0<\/h4>\n \nPer confrontare diverse soluzioni, si possono utilizzare o il tempo medio di guasto, o il tasso di disponibilit\u00e0. Se queste cifre non sono disponibili (o non vi si ha fiducia), \u00e8 possibile effettuare un confronto qualitativo. I vantaggi saranno per i dispositivi con una gestione facile (minore rischio di errori di configurazione), per i crittografi specializzati (per la stessa ragione), e per le soluzioni con il minor tempo di rilevamento e ripristino del guasto, inclusi i sistemi di 'hot' failover per nodi e dispositivi completi.<\/p>\n
Costo<\/h4>\n \nPer quanto riguarda i costi, come per la maggior parte delle soluzioni IT, \u00e8 utile confrontare il costo totale di propriet\u00e0. Per il suo calcolo non \u00e8 necessario reinventare la ruota, ma si pu\u00f2 utilizzare qualsiasi metodologia adatta (ad esempio, quella di Gartner) e qualsiasi calcolatore (ad esempio, quello gi\u00e0 utilizzato nell'organizzazione per calcolare il TCO). \u00c8 chiaro che, per una soluzione di crittografia di rete, il costo totale di propriet\u00e0 \u00e8 composto da costi diretti<\/b> per l'acquisto o l'affitto della soluzione stessa, per l'infrastruttura necessaria all'hosting delle attrezzature e per le spese di implementazione, amministrazione e supporto (indipendentemente se realizzate internamente o sotto forma di servizi di terze parti), nonch\u00e9 da costi indiretti<\/b> costi derivanti dall'inattivit\u00e0 della soluzione (causati dalla perdita di produttivit\u00e0 degli utenti finali). Probabilmente, c'\u00e8 solo una sottigliezza. L'impatto delle prestazioni della soluzione pu\u00f2 essere considerato in modi diversi: o come costi indiretti causati dal calo di produttivit\u00e0, oppure come costi diretti \"virtuali\" per l'acquisto\/aggiornamento e la manutenzione di strumenti di rete, che compensano il calo delle prestazioni della rete dovuto all'uso della crittografia. In ogni caso, i costi che \u00e8 difficile calcolare con sufficiente precisione \u00e8 meglio \"escludere\" dal calcolo: cos\u00ec si avr\u00e0 maggiore fiducia nel valore finale. E, come al solito, in ogni caso, il confronto di diversi dispositivi in base al TCO ha senso farlo per uno specifico scenario di utilizzo - reale o tipico.<\/p>\nResilienza<\/h4>\n
\nL'ultima caratteristica \u00e8 la resilienza della soluzione. Nella maggior parte dei casi, la resilienza pu\u00f2 essere valutata solo qualitativamente, confrontando diverse soluzioni. Dobbiamo ricordare che i dispositivi di crittografia sono non solo strumenti, ma anche oggetti da proteggere. Possono essere soggetti a diverse minacce. Le minacce principali riguardano la violazione della riservatezza, la riproduzione e la modifica dei messaggi. Queste minacce possono realizzarsi attraverso vulnerabilit\u00e0 dell'algoritmo di crittografia o di specifici modalit\u00e0, e attraverso vulnerabilit\u00e0 nei protocolli di crittografia (inclusi i passaggi per l'instaurazione della connessione e la generazione\/distribuzione delle chiavi). I vantaggi vanno a soluzioni che permettono di cambiare l'algoritmo di crittografia o di passare a modalit\u00e0 differenti (almeno attraverso un aggiornamento del firmware), a soluzioni che garantiscono una crittografia completa, nascondendo all'attaccante non solo i dati dell'utente, ma anche informazioni di indirizzamento e altri dati di servizio, oltre a quelle soluzioni che non solo crittografano, ma proteggono anche i messaggi dalla riproduzione e modifica. Per tutti gli attuali algoritmi di crittografia, firme elettroniche, generazione di chiavi e altro, che sono stabiliti negli standard, la resilienza pu\u00f2 essere considerata equivalente (altrimenti ci si perderebbe nel labirinto della crittografia). Devono necessariamente essere algoritmi GOST? Qui \u00e8 semplice: se lo scenario di utilizzo richiede la certificazione FSB per SKZI (e in Russia \u00e8 spesso cos\u00ec, per la maggior parte degli scenari di crittografia di rete), allora si sceglie solo tra quelli certificati. Se non \u00e8 cos\u00ec, allora non ha senso escludere i dispositivi non certificati dalla considerazione.<\/p>\n
Un'altra minaccia \u00e8 quella dell'hacking, ovvero l'accesso non autorizzato ai dispositivi (incluso l'accesso fisico dall'esterno e dall'interno del case). La minaccia pu\u00f2 realizzarsi attraverso
Infine, un altro tipo di minaccia \u00e8 rappresentato dagli errori nella configurazione e nell'operativit\u00e0, il fattore umano in tutta la sua essenza. Qui emerge un ulteriore vantaggio dei codificatori specializzati rispetto alle soluzioni convergenti, che spesso si rivolgono a esperti di rete esperti e possono creare difficolt\u00e0 per i professionisti della sicurezza informatica pi\u00f9 generali.<\/p>\n
In sintesi<\/h4>\n \nIn linea di principio, si potrebbe proporre un indicatore integrale per confrontare diversi dispositivi, qualcosa come<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\ndove p \u00e8 il peso dell'indicatore e r \u00e8 il rango del dispositivo in base a tale indicatore, con la possibilit\u00e0 di suddividere ciascuna delle caratteristiche sopra menzionate in indicatori \"atomici\". Questa formula potrebbe essere utile, ad esempio, quando si confrontano offerte di gara secondo regole predefinite. Ma si potrebbe anche ricorrere a una semplice tabella del tipo<\/p>\n
Caratteristica
Larghezza di banda
+++<\/p>\n
Costi aggiuntivi
+++<\/p>\n
Latenza
++<\/p>\n
Scalabilit\u00e0
+++<\/p>\n
Flessibilit\u00e0
+<\/p>\n
Interoperabilit\u00e0
+<\/p>\n
Compatibilit\u00e0
+++<\/p>\n
Semplicit\u00e0 e comodit\u00e0
++<\/p>\n
Affidabilit\u00e0
++<\/p>\n
Costo
+<\/p>\n
Resilienza
+++<\/p>\n
\nSar\u00f2 lieto di rispondere a domande e osservazioni critiche costruttive.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