VPN<\/a> o senza di essa.<\/p>\nCrittografia di rete in una rete Ethernet distribuita<\/i><\/p>\n
I dispositivi possono essere specializzati<\/b> (destinati esclusivamente alla crittografia), oppure multifunzionali (ibridi, convergenti<\/b>), cio\u00e8 svolgono anche altre funzioni (ad esempio, firewall o router). Diversi fornitori classificano i loro dispositivi in diverse classi\/categorie, ma questo non \u00e8 importante: l'importante \u00e8 se sanno crittografare il traffico inter-sito e quali caratteristiche possiedono in questo caso.<\/p>\n
Per ogni evenienza, ricordo che \u00abcrittografia di rete\u00bb, \u00abcrittografia del traffico\u00bb, \u00abcrittografatore\u00bb sono termini informali, anche se usati frequentemente. Negli atti normativi russi (compresi quelli che introducono le norme GOST) probabilmente non li incontrerete.<\/p>\n
Livelli di crittografia e modalit\u00e0 di trasmissione<\/h4>\n \nPrima di iniziare a descrivere le caratteristiche stesse che saranno utilizzate per la valutazione, \u00e8 necessario chiarire una questione importante, ovvero il \u00ablivello di crittografia\u00bb. Ho notato che viene spesso menzionato sia nei documenti ufficiali dei fornitori (nelle descrizioni, manuali, ecc.) sia nei dibattiti informali (durante le trattative, nei corsi di formazione). Insomma, sembra che tutti sappiano di cosa si stia parlando, ma sono stato testimone di una certa confusione.<\/p>\n
Quindi, cos'\u00e8 esattamente il \u00ablivello di crittografia\u00bb? \u00c8 chiaro che si tratta del numero del livello del modello di riferimento OSI\/ISO in cui avviene la crittografia. Leggiamo lo GOST R ISO 7498-2\u201399 \u00abTecnologia dell'informazione. Interconnessione dei sistemi aperti. Modello di riferimento base. Parte 2. Architettura per la protezione delle informazioni\u00bb. Da questo documento si comprende che il livello del servizio di riservatezza (uno dei meccanismi di cui \u00e8 responsabile la crittografia) \u00e8 il livello del protocollo, dove il blocco di dati del servizio (\u00abpayload\u00bb, dati dell'utente) viene crittografato. Come altro scritto nello standard, il servizio pu\u00f2 essere fornito sia a questo stesso livello, \u00abcon le proprie forze\u00bb, che con l'ausilio del livello inferiore (proprio come viene implementato nel MACsec).<\/p>\n
Tuttavia, nella pratica, possono esserci due modalit\u00e0 di trasmissione delle informazioni crittografate attraverso la rete (in mente ci viene subito IPsec, ma queste modalit\u00e0 sono presenti anche in altri protocolli). Nel modo di trasporto<\/b> (a volte chiamato anche in modo nativo) viene crittografato solo il blocco di servizio<\/b> , mentre le intestazioni rimangono \u00abaperte\u00bb, non crittografate (a volte vengono aggiunti campi supplementari con informazioni di servizio sull'algoritmo di crittografia, e altri campi vengono modificati e ricalcolati). Nella modalit\u00e0 tunnel<\/b> , invece, l'intero blocco protocollo<\/b> di dati (cio\u00e8 l'intero pacchetto) viene crittografato e incapsulato in un blocco di servizio dello stesso o di un livello superiore, quindi viene racchiuso in nuove intestazioni.<\/p>\n
Il livello di crittografia da solo, combinato con un certo regime 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. Molte caratteristiche dipendono da esse, le quali vengono utilizzate per valutare i dispositivi, come la flessibilit\u00e0 e la compatibilit\u00e0. Per operare in rete L1 (riedistribuzione del flusso di bit), L2 (commutazione dei frame) e L3 (instradamento dei pacchetti) in modalit\u00e0 di trasporto sono necessarie soluzioni che crittografano a un livello uguale o superiore (altrimenti le informazioni degli indirizzi saranno crittografate e i dati non arriveranno a destinazione), mentre la modalit\u00e0 tunnel permette di superare questa limitazione (sacrificando per\u00f2 altre caratteristiche importanti).<\/p>\n
Modalit\u00e0 di crittografia L2 e tunnel<\/i><\/p>\n
Ora passiamo all'analisi delle caratteristiche.<\/p>\n
Prestazioni<\/h4>\n \nPer la crittografia di rete, le prestazioni sono un concetto complesso e multidimensionale. Pu\u00f2 accadere che un certo modello, pur superando in una caratteristica delle prestazioni, ne perda in un'altra. Pertanto, \u00e8 sempre utile considerare tutti gli elementi delle prestazioni di crittografia e il loro impatto sulle prestazioni della rete e delle applicazioni che la utilizzano. Qui si pu\u00f2 fare un'analogia con un'automobile, per la quale non \u00e8 importante solo la velocit\u00e0 massima, ma anche il tempo necessario per accelerare fino a \"cento\", il consumo di carburante e cos\u00ec via. Le aziende fornitrici e i loro potenziali clienti prestano grande attenzione alle caratteristiche delle prestazioni. Di norma, il ranking dei dispositivi di crittografia avviene proprio in base alle prestazioni.<\/p>\n
\u00c8 chiaro che le prestazioni dipendono sia dalla complessit\u00e0 delle operazioni di rete e crittografiche eseguite sul dispositivo (incluso quanto bene queste attivit\u00e0 si prestano a parallelizzazione e pipeline), sia dalle prestazioni dell'hardware e dalla qualit\u00e0 del software integrato. Pertanto, nei modelli pi\u00f9 avanzati vengono utilizzati hardware pi\u00f9 performante e talvolta c'\u00e8 la possibilit\u00e0 di potenziarlo con processori e moduli di memoria aggiuntivi. Ci sono diversi approcci per implementare funzioni crittografiche: su una CPU (central processing unit) universale, su un circuito integrato specifico (ASIC) o su un circuito integrato a logica programmabile (FPGA). Ogni approccio ha i suoi pro e contro. Ad esempio, una CPU pu\u00f2 diventare un<\/p>\n
dato che si parla di rete<\/b> cifratura, \u00e8 logico che le prestazioni delle soluzioni debbano essere misurate nelle stesse grandezze utilizzate per altri dispositivi di rete - larghezza di banda, percentuale di perdita di pacchetti (frame loss) e latenza (latency). Queste grandezze sono definite nel RFC 1242. A proposito, nel documento RFC non viene menzionata affatto la variazione della latenza (jitter) spesso citata. Come si misurano queste grandezze? Non ho trovato una metodologia approvata in alcun standard (ufficiale o non ufficiale come RFC) specificamente per la cifratura 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, alcuni inviano traffico di test solo in una direzione invece che in entrambe, come si raccomanda<\/b> stabilito dallo standard. Comunque, va bene.<\/p>\n
La misurazione delle prestazioni dei dispositivi di crittografia di rete presenta comunque delle peculiarit\u00e0. In primo luogo, \u00e8 corretto eseguire tutte le misurazioni per una coppia di dispositivi: sebbene gli algoritmi di crittografia siano simmetrici, i ritardi e le perdite di pacchetti durante la crittografia e la decrittografia non saranno necessariamente uguali. In secondo luogo, ha senso misurare proprio la delta, l'impatto della crittografia di rete sulle prestazioni complessive della rete, confrontando due configurazioni: senza dispositivi di crittografia e con essi. Oppure, come nel caso di dispositivi ibridi che combinano diverse funzioni oltre alla crittografia di rete, quando la crittografia \u00e8 attivata e disattivata. Questo impatto pu\u00f2 variare e dipendere dalla configurazione dei dispositivi di crittografia, dai modi di lavoro, infine, dalla natura del traffico. In particolare, molti parametri di prestazione dipendono dalla lunghezza dei pacchetti, ed \u00e8 per questo che 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 l'IMIX \u2013 una distribuzione del traffico per lunghezze di pacchetti che riflette circa la realt\u00e0. Se consideriamo per il confronto la stessa configurazione di base senza crittografia, saremo in grado di confrontare le soluzioni per la crittografia di rete realizzate in modi diversi, senza addentrarci in queste differenze: L2 con L3,<\/p>\n
Schema di collegamento per il test delle prestazioni<\/i><\/p>\n
La prima caratteristica a cui si presta attenzione \u00e8 la \"velocit\u00e0\" del dispositivo di crittografia, ovvero larghezza di banda<\/b> (bandwidth) delle sue interfacce di rete, la velocit\u00e0 del flusso di bit. Essa \u00e8 definita dagli standard di rete supportati dalle interfacce. Per l'Ethernet, i numeri comuni sono 1 Gbit\/s e 10 Gbit\/s. Ma, come sappiamo, in qualsiasi rete la massima capacit\u00e0 teorica di throughput<\/b> (throughput) a ciascuno dei suoi livelli \u00e8 sempre inferiore alla larghezza di banda: parte della larghezza di banda viene \"consumata\" da intervalli tra i fotogrammi, intestazioni di servizio e cos\u00ec via. Se un dispositivo \u00e8 in grado di ricevere, elaborare (nel nostro caso crittografare o decrittografare) e trasmettere il traffico alla massima velocit\u00e0 dell'interfaccia di rete, cio\u00e8 con la massima capacit\u00e0 teorica di questo livello del modello di rete, si dice che funziona alla velocit\u00e0 della linea<\/b>. Per questo \u00e8 necessario che il dispositivo non perda, non scarti pacchetti di qualsiasi dimensione e qualsiasi frequenza di sequenza. Se un dispositivo di crittografia non supporta il funzionamento alla velocit\u00e0 della linea, di solito viene indicata la sua capacit\u00e0 massima in gigabit al secondo (a volte con indicazione della lunghezza dei pacchetti - pi\u00f9 i pacchetti sono corti, generalmente pi\u00f9 bassa \u00e8 la larghezza di banda). \u00c8 molto importante capire che la capacit\u00e0 massima di larghezza di banda \u00e8 senza perdita<\/b> (anche se il dispositivo pu\u00f2 \"far passare\" il traffico a una velocit\u00e0 maggiore, perdendo parte dei pacchetti nel processo). Inoltre, \u00e8 necessario prestare attenzione al fatto che alcuni fornitori misurano la capacit\u00e0 totale di larghezza di banda tra tutte le coppie di porte, quindi queste cifre dicono poco se tutto il traffico crittografato passa attraverso una sola porta.<\/p>\n
Dove \u00e8 particolarmente importante il funzionamento alla velocit\u00e0 della linea (o, altrimenti, senza perdita di pacchetti)? Nei canali ad alta larghezza di banda e con alte latenze (ad esempio, satellitari), dove per mantenere alta la velocit\u00e0 di trasmissione \u00e8 necessario impostare una grande dimensione della finestra TCP, e dove le perdite di pacchetti riducono drasticamente le prestazioni della rete.<\/p>\n
Ma non tutta la larghezza di banda \u00e8 utilizzata per la trasmissione di dati utili. Si devono considerare i cosiddetti costi generali<\/b> (overhead) della capacit\u00e0 di trasmissione. Questa \u00e8 la parte della capacit\u00e0 di trasmissione del dispositivo di crittografia (in percentuali o in byte per pacchetto) che viene effettivamente persa (non pu\u00f2 essere utilizzata per la trasmissione dei dati delle applicazioni). Le spese generali si verificano, innanzitutto, a causa dell'aumento delle dimensioni (aggiunte, 'padding') del campo dati nei pacchetti di rete crittografati (dipende dall'algoritmo di crittografia e dalla modalit\u00e0 di funzionamento). In secondo luogo, a causa dell'aumento della lunghezza degli header dei pacchetti (modalit\u00e0 tunnel, inserimento di servizi del protocollo di crittografia, inserimento di autenticit\u00e0, ecc., a seconda del protocollo e della modalit\u00e0 di funzionamento del cifrario e del modo di trasmissione) \u2013 generalmente \u00e8 proprio questa spesa generale quella pi\u00f9 significativa, e su cui si pone maggiore attenzione. 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 un pacchetto che supera l'MTU in due, duplicando i suoi header). In quarto luogo, a causa dell'emergere nella rete 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 capacit\u00e0 di trasmissione del canale \u00e8 limitata. Questo \u00e8 particolarmente evidente nel traffico di piccoli pacchetti, ad esempio, del traffico vocale \u2013 qui le spese generali possono 'mangiare' pi\u00f9 della met\u00e0 della velocit\u00e0 del canale!<\/p>\n
Larghezza di banda<\/i><\/p>\n
Infine, c'\u00e8 ancora ritardo introdotto<\/b> \u2013 la differenza (in frazioni di secondo) nel ritardo di rete (tempo di percorrenza dei dati dall'ingresso alla rete fino all'uscita) tra la trasmissione dei dati senza crittografia di rete e con essa. In generale, minore \u00e8 il ritardo (\u00ablatenza\u00bb) della rete, maggiore diventa il ritardo causato dai dispositivi di crittografia. Il ritardo \u00e8 causato sia dall'operazione di crittografia (che dipende dall'algoritmo di crittografia, dalla lunghezza del blocco e dalla modalit\u00e0 operativa del cifrario, oltre che dalla qualit\u00e0 della sua implementazione nel software), sia dal trattamento del pacchetto di rete nel dispositivo. Il ritardo causato dipende sia dalla modalit\u00e0 di elaborazione dei pacchetti (pass-through o \u00absalva e trasmetti\u00bb), sia dalle prestazioni della piattaforma (l'implementazione \u00abhardware\u00bb su FPGA o ASIC \u00e8 generalmente pi\u00f9 veloce rispetto a quella \u00absoftware\u00bb su CPU). La crittografia L2 presenta quasi sempre un ritardo causato inferiore rispetto alla crittografia su L3 o L4: ci\u00f2 \u00e8 dovuto al fatto che i dispositivi che eseguono la crittografia su L3\/L4 sono spesso realizzati in modo convergente. Ad esempio, nei crittografi Ethernet ad alta velocit\u00e0, realizzati su FPGA e che eseguono la crittografia su L2, il ritardo dovuto all'operazione di crittografia \u00e8 trascurabile: a volte, attivando la crittografia su una coppia di dispositivi, il ritardo totale che essi introducono diminuisce persino! Un ritardo ridotto \u00e8 importante nelle situazioni in cui \u00e8 comparabile con i ritardi totali nel canale, inclusi i ritardi di propagazione del segnale, che equivalgono a circa 5 \u03bcs per chilometro. Dunque, si pu\u00f2 dire che per le reti di dimensioni urbane (decine di chilometri di diametro) i microsecondi possono fare una grande differenza. Ad esempio, per la replicazione sincrona di database, il trading ad alta frequenza, 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 importante che le soluzioni di crittografia non impongano ulteriori limitazioni sulle dimensioni e sulla topologia della rete distribuita. Questo riguarda principalmente il numero massimo di indirizzi dei nodi e delle reti. Limitazioni di questo tipo possono manifestarsi, ad esempio, durante l'implementazione di una topologia a multipunto in una rete protetta da crittografia (con connessioni protette indipendenti, o tunnel) o durante la crittografia selettiva (ad esempio, in base al numero di protocollo o VLAN). Se gli indirizzi di rete (MAC, IP, VLAN ID) vengono utilizzati come chiavi in una tabella, il numero di righe della quale \u00e8 limitato, allora qui si manifestano queste limitazioni.<\/p>\n
Inoltre, le grandi reti hanno spesso pi\u00f9 livelli strutturali, inclusa una rete backbone, in ciascuno dei quali viene implementato un proprio schema di indirizzamento e una propria politica di instradamento. Per implementare questo approccio, vengono spesso utilizzati formati di frame speciali (come Q-in-Q o MAC-in-MAC) e protocolli di determinazione del percorso. Per non ostacolare la costruzione di tali reti, i dispositivi di crittografia devono gestire correttamente tali frame (cio\u00e8 in questo senso la scalabilit\u00e0 significher\u00e0 compatibilit\u00e0 \u2013 di cui si parler\u00e0 di seguito).<\/p>\n
Flessibilit\u00e0<\/h4>\n \nQui si parla del supporto per diverse configurazioni, schemi di connessione, topologie e altro. Ad esempio, per le reti commutate basate su tecnologie Carrier Ethernet ci\u00f2 significa supportare diversi tipi di connessioni virtuali (E-Line, E-LAN, E-Tree), diversi tipi di servizio (sia per porte che per VLAN) e diverse tecnologie di trasporto (gi\u00e0 menzionate sopra). Ci\u00f2 significa che il dispositivo deve essere in grado di operare sia in modalit\u00e0 lineare (\"point-to-point\"), che 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 diverse modalit\u00e0 di funzionamento della crittografia (compresa l'autenticazione del contenuto o meno) e diverse modalit\u00e0 di trasmissione dei pacchetti consente di garantire un equilibrio tra robustezza e prestazioni a seconda delle condizioni attuali.<\/p>\n
\u00c8 importante anche il supporto alle reti private, il cui hardware appartiene a un'unica organizzazione (o \u00e8 in affitto da essa), e alle reti operatori, i cui vari segmenti sono gestiti da diverse aziende. \u00c8 vantaggioso se la soluzione consente la gestione sia interna che da parte di un'organizzazione esterna (secondo il modello del servizio gestito). In reti operatori, un'altra funzione importante \u00e8 il supporto alla multitenancy (utilizzo condiviso da parte di diversi clienti) attraverso l'isolamento crittografico di singoli clienti (abbonati), il cui traffico transita attraverso lo stesso set di dispositivi di crittografia. In genere, ci\u00f2 richiede l'uso di set separati di chiavi e certificati per ciascun cliente.<\/p>\n
Se il dispositivo viene acquistato per uno scenario specifico, tutte queste funzionalit\u00e0 potrebbero non essere particolarmente rilevanti: \u00e8 sufficiente assicurarsi che il dispositivo supporti ci\u00f2 di cui si ha bisogno al momento. Ma se la soluzione viene acquistata \u00abper crescita\u00bb, per supportare anche scenari futuri, e viene scelta come \u00abstandard aziendale\u00bb, la flessibilit\u00e0 sar\u00e0 un vantaggio, soprattutto considerando le limitazioni in termini di interoperabilit\u00e0 tra dispositivi di diversi fornitori (di questo parleremo tra poco).<\/p>\n
Semplicit\u00e0 e comodit\u00e0<\/h4>\n \nLa facilit\u00e0 di manutenzione \u00e8 un concetto multifattoriale. In linee generali, si pu\u00f2 dire che si tratta del tempo totale necessario ai professionisti con determinata competenza per supportare una soluzione in diverse fasi del suo ciclo di vita. Se non ci sono costi e l'installazione, la configurazione e l'operativit\u00e0 sono completamente automatiche, i costi sono nulli e la comodit\u00e0 \u00e8 assoluta. Ovviamente, nel mondo reale questo non avviene. Un'analisi ragionevole \u00e8 il modello \u00abnodo su cavo\u00bb<\/b> (bump-in-the-wire), o collegamento trasparente, in cui l'aggiunta e la disconnessione dei dispositivi di crittografia non richiede modifiche manuali o automatiche alla configurazione della rete. In questo modo, la gestione della soluzione diventa pi\u00f9 semplice: \u00e8 possibile attivare e disattivare la funzione di crittografia senza problemi, e se necessario, semplicemente \u00abbypassare\u00bb il dispositivo con un cavo di rete (cio\u00e8 collegando direttamente le porte dell'hardware di rete a cui era connesso). Tuttavia, c'\u00e8 anche uno svantaggio: lo stesso potrebbe farlo anche un malintenzionato. Per implementare il principio \u00abnodo sul filo\u00bb, \u00e8 necessario tenere conto del traffico non solo del livello dati<\/b>, ma anche dei livelli di controllo e gestione<\/b> \u2013 i dispositivi devono essere trasparenti per essi. Pertanto, tale traffico pu\u00f2 essere crittografato solo quando nella rete, tra i dispositivi di crittografia, non ci sono destinatari di traffico di questi tipi, dal momento che se viene scartato o crittografato, la configurazione della rete potrebbe cambiare durante l'attivazione o la disattivazione della crittografia. Il dispositivo di crittografia pu\u00f2 essere trasparente anche per il segnale a livello fisico. In particolare, in caso di perdita di segnale, deve trasmettere questa perdita (cio\u00e8 disattivare i propri trasmettitori) avanti e indietro (\u00abper se stesso\u00bb) in direzione del segnale.<\/p>\n
\u00c8 inoltre importante il supporto nella separazione dei poteri tra i reparti di sicurezza informatica e IT, in particolare il reparto di rete. La soluzione per la crittografia deve supportare il modello di gestione degli accessi e di audit adottato nell'organizzazione. Deve essere ridotto al minimo il bisogno di interazione tra i diversi reparti per eseguire operazioni di routine. Pertanto, gli dispositivi specializzati, che supportano esclusivamente le funzioni di crittografia e sono massimamente trasparenti per le operazioni di rete, hanno un vantaggio dal punto di vista della comodit\u00e0. In parole semplici, gli addetti alla sicurezza informatica non devono avere motivo di contattare i \u00abnetworker\u00bb per modificare le impostazioni della rete. E questi ultimi, a loro volta, non devono avere la necessit\u00e0 di modificare le impostazioni di crittografia durante la manutenzione della rete.<\/p>\n
Un altro fattore sono le possibilit\u00e0 e la praticit\u00e0 degli strumenti di gestione. Devono essere chiari, logici, garantire l'import-export delle impostazioni, l'automazione e cos\u00ec via. \u00c8 fondamentale prestare attenzione a quali opzioni di gestione sono disponibili (di solito si tratta di un ambiente di gestione dedicato, di un'interfaccia web e della riga di comando) e quali funzioni sono incluse in ciascuna di esse (possono esserci limitazioni). Una funzione importante \u00e8 il supporto gestione fuori banda<\/b> (out-of-band), cio\u00e8 attraverso una rete di gestione dedicata, e gestione in banda<\/b> (in-band), cio\u00e8 attraverso la rete condivisa, attraverso la quale viene inviato il traffico utile. Gli strumenti di gestione devono segnalare tutte le situazioni anomale, inclusi gli incidenti di sicurezza informatica. Le operazioni routinarie e ripetitive devono essere eseguite automaticamente. Ci\u00f2 riguarda in particolare la gestione delle chiavi. 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 organismi 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 tramite trasparenza<\/b>, o tramite 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 completezza e la correttezza dell'implementazione dei protocolli di controllo determinano la compatibilit\u00e0 con le reti. \u00c8 importante il supporto di diverse opzioni del livello PHY (velocit\u00e0, mezzi di trasmissione, schemi di codifica), frame Ethernet di vari formati con qualunque MTU, e diversi protocolli di servizio L3 (soprattutto della famiglia TCP\/IP).<\/p>\n
La trasparenza \u00e8 garantita tramite meccanismi di mutazione (modifica temporanea del contenuto degli header aperti nel traffico tra i crittografi), bypass (quando singoli pacchetti rimangono non crittografati) e offset dell'inizio della crittografia (quando campi di pacchetti normalmente crittografati non vengono crittografati).<\/p>\n
Come viene garantita la trasparenza<\/i><\/p>\n
Pertanto, \u00e8 sempre utile chiarire come viene garantito il supporto di un determinato protocollo. Spesso, il supporto in modalit\u00e0 trasparente \u00e8 pi\u00f9 conveniente e affidabile.<\/p>\n
Interoperabilit\u00e0<\/h4>\n \nQuesta \u00e8 anche compatibilit\u00e0, ma in un'altra accezione, ovvero la possibilit\u00e0 di cooperare con altri modelli di dispositivi di crittografia, inclusi quelli di altri produttori. Qui molto dipende dallo stato di standardizzazione dei protocolli di crittografia. A L1 non ci sono standard di crittografia ampiamente riconosciuti.<\/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 la crittografia<\/b>, \u00aba salto\u00bb (hop-by-hop), e nella sua versione iniziale non \u00e8 adatta per l'uso in reti distribuite, motivo per cui 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 allo standard 802.1ae il supporto per le reti distribuite, ma non c'\u00e8 ancora supporto per i set di algoritmi di crittografia GOST. Pertanto, i protocolli di crittografia L2 proprietari e non standard, per lo pi\u00f9, si distinguono per maggiore efficienza (in particolare, minori sovraccarichi di banda) e flessibilit\u00e0 (la possibilit\u00e0 di cambiare algoritmi e modalit\u00e0 di crittografia).<\/p>\n
A livelli pi\u00f9 alti (L3 e L4) ci sono standard riconosciuti, in particolare IPsec e TLS, ma anche qui non \u00e8 tutto semplice. Il problema \u00e8 che ognuno di questi standard \u00e8 un insieme di protocolli, ognuno con diverse versioni e estensioni obbligatorie o facoltative per l'implementazione. Inoltre, alcuni produttori preferiscono applicare i propri protocolli di crittografia anche a L3\/L4. Pertanto, nella maggior parte dei casi, non ci si pu\u00f2 aspettare piena interoperabilit\u00e0, ma \u00e8 importante garantire almeno l'interazione tra diversi modelli e diverse generazioni di uno stesso produttore.<\/p>\n
Affidabilit\u00e0<\/h4>\n \nPer confrontare diverse soluzioni, si pu\u00f2 utilizzare il tempo medio di guasto o il fattore di disponibilit\u00e0. Se questi numeri non ci sono (o non si ha fiducia in essi), si pu\u00f2 eseguire un confronto qualitativo. Avranno un vantaggio i dispositivi con una gestione semplice (minor rischio di errori nella configurazione), i crittografi specializzati (per lo stesso motivo), nonch\u00e9 le soluzioni con il minor tempo di rilevamento e risoluzione dei guasti, inclusi i mezzi di \u00abhot\u00bb backup di nodi e dispositivi nel loro complesso.<\/p>\n
Prezzo<\/h4>\n \nPer quanto riguarda il costo, come per la maggior parte delle soluzioni IT, \u00e8 opportuno confrontare il costo totale di possesso. Per calcolarlo non c'\u00e8 bisogno di reinventare la ruota, \u00e8 possibile utilizzare qualsiasi metodologia appropriata (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 possesso \u00e8 composto da costi<\/b> diretti per l'acquisto o l'affitto della soluzione stessa, per l'infrastruttura necessaria a ospitare l'hardware e per le spese di implementazione, amministrazione e supporto (che sia eseguito internamente o come servizio di un'organizzazione esterna), oltre a costi<\/b> indiretti derivanti dall'interruzione della soluzione (causata 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 della produttivit\u00e0, oppure come costi \"virtuali\" diretti per l'acquisto\/miglioramento e manutenzione dei mezzi di rete, che compensano il calo delle prestazioni della rete dovuto all'uso della crittografia. In ogni caso, le spese che \u00e8 difficile calcolare con sufficiente precisione \u00e8 meglio \"escludere dal calcolo\": in questo modo ci sar\u00e0 maggiore fiducia nell'importo finale. E, come al solito, in ogni caso \u00e8 sensato confrontare diversi dispositivi in base al TCO per uno specifico scenario di utilizzo \u2013 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 varie soluzioni tra loro. Dobbiamo ricordare che i dispositivi di crittografia non sono 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 manifestarsi attraverso vulnerabilit\u00e0 nel cifrario o in singoli modi di operare, nonch\u00e9 attraverso vulnerabilit\u00e0 nei protocolli di crittografia (inclusi quelli nelle fasi di stabilizzazione della connessione e generazione\/distribuzione delle chiavi). Le soluzioni che consentono la sostituzione dell'algoritmo di crittografia o il cambio del modo del cifrario (anche semplicemente tramite aggiornamento del firmware) avranno un vantaggio, cos\u00ec come quelle che garantiscono una crittografia il pi\u00f9 completa possibile, nascondendo non solo i dati degli utenti, ma anche informazioni di indirizzamento e altre informazioni di servizio agli aggressori, e quelle soluzioni che non solo criptano, ma proteggono anche i messaggi dalla riproduzione e dalla modifica. Per tutti gli algoritmi di crittografia moderni, la firma elettronica, la generazione delle chiavi e altri standard, la resilienza pu\u00f2 essere considerata equivalente (altrimenti si rischia di perdersi nei meandri della crittografia). Devono necessariamente essere algoritmi GOST? Qui la risposta \u00e8 semplice: se lo scenario di applicazione richiede la certificazione della FSB per i dispositivi di crittografia (il che \u00e8 spesso il caso in Russia) per la maggior parte degli scenari di crittografia di rete, allora sceltiamo solo tra quelli certificati. Se non \u00e8 cos\u00ec, non ha senso escludere i dispositivi privi di certificazione dalla considerazione.<\/p>\n
Un'altra minaccia \u00e8 quella dell'hacking, dell'accesso non autorizzato ai dispositivi (anche tramite accesso fisico dall'esterno e dall'interno del dispositivo). La minaccia pu\u00f2 realizzarsi attraverso
Infine, un altro tipo di minaccia \u00e8 l'errore di configurazione e di gestione, il fattore umano in senso stretto. Qui si manifesta un ulteriore vantaggio dei crittografi specializzati rispetto alle soluzioni convergenti, che spesso si rivolgono a esperti \"di rete\" e possono creare difficolt\u00e0 ai professionisti della sicurezza informatica pi\u00f9 generali.<\/p>\n
Riassumiamo<\/h4>\n \nIn linea di principio, qui si potrebbe proporre un certo 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 questo indicatore, in cui ciascuna delle caratteristiche sopra elencate pu\u00f2 essere suddivisa in indicatori \"atomici\". Tale formula potrebbe essere utile, ad esempio, nel confronto delle offerte di gara secondo regole previamente concordate. Ma si potrebbe anche optare per una semplice tabella come<\/p>\n
Caratteristiche
Larghezza di banda
+++<\/p>\n
Costi aggiuntivi
+++<\/p>\n
Ritardo
++<\/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
Resilienza
++<\/p>\n
Prezzo
+<\/p>\n
Resilienza
+++<\/p>\n
\nSar\u00f2 felice di rispondere a domande e commenti critici costruttivi.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