Questa recensione (o, se preferite, guida al confronto) l'ho scritta quando mi è stato affidato il compito di confrontare diversi dispositivi di vari fornitori. Inoltre, questi dispositivi appartenevano a classi diverse. Ho dovuto approfondire l'architettura e le caratteristiche di tutti questi dispositivi e creare un "sistema di coordinate" per il confronto. Sarò felice se la mia recensione potrà aiutare qualcuno:
- Comprendere le descrizioni e le specifiche dei dispositivi di crittografia
- Distinguere le caratteristiche "teoriche" da quelle realmente importanti nella vita reale
- Andare oltre il consueto insieme di fornitori e includere nella valutazione qualsiasi prodotto idoneo a risolvere il problema
- Porre le domande giuste durante le trattative
- Elaborare i requisiti di gara (RFP)
- Capire quali caratteristiche si dovranno sacrificare se verrà scelta una certa modello di dispositivo
Cosa si può valutare
In linea di principio, l'approccio si applica a qualsiasi dispositivo autonomo (standalone) adatto per la crittografia del traffico di rete tra segmenti Ethernet remoti (cifratura intersito). Si tratta quindi di "scatole" in un'apposita scocca (d'accordo, includiamo anche i blade/moduli per chassis), che si collegano tramite una o più porte Ethernet a una rete Ethernet locale (campus) con traffico non crittografato, e attraverso un'altra porta(e) – al canale/rete, attraverso cui il traffico già crittografato viene trasferito ad altri segmenti remoti. Questa soluzione per la crittografia può essere implementata in una rete privata o operativa attraverso diversi tipi di "trasporto" (fibra ottica "dark", apparecchiature di divisione in frequenza, rete Ethernet commutata, oltre a "pseudo-conduttori" posati attraverso una rete con un'architettura di routing differente, di solito MPLS), utilizzando la tecnologia VPN o senza di essa.
Crittografia di rete in una rete Ethernet distribuita
I dispositivi stessi possono essere sia specializzati (destinati esclusivamente alla crittografia), sia multifunzionali (ibridi, convergenti), cioè 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 è rilevante: ciò che conta è se sono in grado di criptare il traffico inter-sito e quali caratteristiche possiedono.
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) è probabile che non li incontriate.
Livelli di crittografia e modalità di trasmissione
Prima di procedere alla descrizione delle caratteristiche che saranno utilizzate per la valutazione, è 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.
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 ГОСТ Р ИСО 7498-2–99 "Tecnologia dell'informazione. Interconnessione di sistemi aperti. Modello di riferimento fondamentale. Parte 2. Architettura della protezione delle informazioni". Da questo documento si può comprendere che il livello del servizio di riservatezza (uno dei meccanismi tramite i quali è garantita appunto la crittografia) è il livello del protocollo il cui blocco dati di servizio ("payload", dati dell'utente) viene crittografato. Come scritto nello standard, il servizio può essere fornito sia a questo stesso livello, "con le proprie forze", sia con l'ausilio di un livello inferiore (è proprio così che questo avviene più frequentemente in MACsec).
Nella pratica, esistono due modalità di trasmissione delle informazioni crittografate attraverso la rete (immediatamente ci viene in mente IPsec, ma queste modalità si riscontrano anche in altri protocolli). In modalità di trasporto (a volte chiamato anche native) viene crittografato solo il servizio 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à tunnel questa modalità protocollo il blocco dati (cioè il pacchetto stesso) viene cifrato e incapsulato in un blocco dati di servizio dello stesso livello o di livello superiore, cioè viene incorniciato con nuovi header.
Il livello di cifratura in sé, combinato con qualche modalità di trasmissione, non è né buono né cattivo, quindi non si può dire, ad esempio, che L3 in modalità di trasporto sia migliore di L2 in modalità tunnel. Dipendono da molti caratteri che vengono utilizzati per valutare i dispositivi. Ad esempio, flessibilità e compatibilità. Per funzionare nelle reti L1 (ritrasmissione del flusso di bit), L2 (commutazione dei frame) e L3 (instradamento dei pacchetti) in modalità 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à tunnel consente di superare questa limitazione (però sacrificando altre caratteristiche importanti).
Modalità di trasporto e tunnelizzazione della crittografia L2
Ora passiamo all'analisi delle caratteristiche.
Prestazioni
La performance nella crittografia di rete è un concetto complesso e multidimensionale. Può capitare che un certo modello, pur eccellendo in una caratteristica, ne comprometta un'altra. Pertanto, è 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ò tracciare un'analogia con un'automobile, per la quale non conta solo la velocità massima, ma anche il tempo di accelerazione fino ai 100 km/h, il consumo di carburante e così 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.
È chiaro che le prestazioni dipendono sia dalla complessità delle operazioni di rete e crittografiche eseguite sul dispositivo (inclusa la capacità di parallelizzazione e pipelining di tali compiti), sia dalle prestazioni dell'hardware e dalla qualità del software integrato. Pertanto, nei modelli superiori vengono utilizzati hardware più potenti, con la possibilità 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ò 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à; non sempre è possibile aggiornarli per migliorare le prestazioni, aggiungere nuove funzionalità o risolvere vulnerabilità. Inoltre, il loro utilizzo diventa economicamente vantaggioso solo per produzioni su larga scala. È per questo che la soluzione del "giusto mezzo" è diventata così popolare: l'uso di FPGA. Proprio su FPGA sono realizzati i cosiddetti acceleratori crittografici - moduli hardware specializzati integrati o collegabili per supportare operazioni crittografiche.
Poiché si tratta di rete crittografia, è 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 è consigliato stabilito dallo standard. Ma va bene.
La misurazione delle prestazioni dei dispositivi di crittografia di rete ha comunque le sue peculiarità. Innanzitutto, è 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ù funzioni oltre alla crittografia di rete, valutando entrambi i casi, sia con crittografia attivata che disattivata. Questo impatto può 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é 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à. 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ì via.
Schema di collegamento per il test delle prestazioni
La prima caratteristica a cui prestare attenzione è la "velocità" del dispositivo di crittografia, ovvero la larghezza di banda (bandwidth) delle sue interfacce di rete, la velocità di flusso dei bit. Essa è 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à teorica di throughput (throughput) a ciascun livello è sempre inferiore alla larghezza di banda: parte della larghezza viene "consumata" da intervalli tra i frame, intestazioni di controllo e così via. Se un dispositivo è in grado di ricevere, elaborare (in questo caso crittografare o decrittografare) e trasmettere traffico alla piena velocità dell'interfaccia di rete, ovvero con la massima capacità teorica per quel livello del modello di rete, allora si dice che funziona alla velocità della linea. È 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à 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ù corti di solito comportano una minore larghezza di banda). È molto importante comprendere che la larghezza di banda massima è il massimo senza perdite (anche se il dispositivo può gestire il traffico a velocità superiori, ma perdendo comunque una parte dei pacchetti). Inoltre, è 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.
Dove è particolarmente importante lavorare con velocità di linea (o, in altre parole, senza perdita di pacchetti)? Nei canali ad alta capacità e con elevate latenze (ad esempio, satellitari), dove per mantenere elevate velocità di trasmissione è necessario impostare una grande dimensione della finestra TCP, e dove la perdita di pacchetti riduce drasticamente le prestazioni della rete.
Ma non tutta la larghezza di banda è utilizzata per la trasmissione di dati utili. È necessario tenere conto dei cosiddetti costi operativi (overhead) di larghezza di banda. Questa è la parte della larghezza di banda del dispositivo di crittografia (in percentuale o in byte per pacchetto) che viene effettivamente persa (non può essere utilizzata per il trasferimento dei dati delle applicazioni). Le spese generali si verificano, in primo luogo, a causa dell'aumento delle dimensioni (aggiunte, «padding») del campo dati nei pacchetti di rete crittografati (a seconda dell'algoritmo di crittografia e della modalità di funzionamento). In secondo luogo, a causa dell'aumento della lunghezza delle intestazioni dei pacchetti (modalità tunnel, inserimento di protocollo di crittografia, inserimento di autenticità, ecc., a seconda del protocollo e della modalità di funzionamento della crittografia e del modo di trasmissione) – generalmente queste spese generali sono le più 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 è 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 è limitata. Questo si manifesta soprattutto nel traffico di pacchetti piccoli, come ad esempio nel traffico vocale – lì le spese generali possono «mangiare» più della metà della velocità del canale!
Larghezza di banda
Finalmente, c'è anche latenza applicata – 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 è la latenza («latenza») della rete, più critica diventa la latenza introdotta dai dispositivi di crittografia. La latenza è causata sia dall'operazione di crittografia (che dipende dall'algoritmo di crittografia, dalla lunghezza del blocco e dalla modalità di funzionamento della crittografia, così come dalla qualità della sua implementazione nel software), sia dall'elaborazione del pacchetto di rete nel dispositivo. La latenza introdotta dipende sia dalla modalità di elaborazione dei pacchetti (in transito o «salva-e-invia»), sia dalla performance della piattaforma (l'implementazione «hardware» su FPGA o ASIC è generalmente più veloce di quella «software» su CPU). La crittografia L2 presenta quasi sempre una latenza introdotta inferiore rispetto alla crittografia L3 o L4: ciò è 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à realizzati su FPGA e che criptano su L2, la latenza causata dall'operazione di crittografia è trascurabile: a volte, attivando la crittografia su un paio di dispositivi, la latenza totale introdotta da essi può addirittura diminuire! Una bassa latenza è importante quando è comparabile con le latenze totali nel canale, inclusa la latenza di propagazione del segnale, che è di circa 5 μs per chilometro. Quindi si può 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.
Ritardo introdotto
Scalabilità
Le grandi reti distribuite possono includere migliaia di nodi e dispositivi di rete, centinaia di segmenti di reti locali. È 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 è limitato, qui si manifestano questi vincoli.
Inoltre, le grandi reti spesso presentano più 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é la costruzione di tali reti non sia ostacolata, i dispositivi di crittografia devono gestire correttamente tali frame (cioè, in questo senso, la scalabilità significherà compatibilità – di cui parleremo più avanti).
Flessibilità
Si 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à menzionate sopra). In altre parole, il dispositivo deve essere in grado di operare sia in modalità lineare («punto-punto»), sia in modalità multipunto, stabilendo tunnel separati per diverse VLAN, consentendo la consegna non ordinata dei pacchetti all'interno di un canale protetto. La possibilità di scegliere tra diverse modalità di funzionamento della crittografia (compresa l'autenticazione del contenuto o meno) e diverse modalità di trasmissione dei pacchetti consente di bilanciare tra resilienza e prestazioni a seconda delle condizioni attuali.
È importante anche il supporto per reti private, il cui hardware appartiene a un'unica organizzazione (o è in affitto presso di essa), e per reti operative, i cui segmenti sono gestiti da diverse società. È 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 è 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ò richiede l'uso di kit di chiavi e certificati separati per ciascun cliente.
Se il dispositivo viene acquistato per uno specifico scenario, tutte queste funzionalità potrebbero non essere così importanti: è sufficiente garantire che il dispositivo supporti ciò di cui si ha bisogno al momento. Ma se la soluzione è acquistata "per futuro", per supportare anche scenari futuri, e viene scelta come "standard aziendale", allora la flessibilità sarà utile, soprattutto considerando le limitazioni di interoperabilità dei dispositivi di diversi fornitori (ne parliamo più avanti).
Semplicità e comodità
La facilità di manutenzione è anch'essa un concetto multifattoriale. Si può 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à è assoluta. Ovviamente, nel reale non esiste una situazione del genere. Un'approssimazione ragionevole è questo modello. "nodo sul cavo" (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: è possibile attivare e disattivare la funzione di crittografia in modo tranquillo e, se necessario, «bypassare» semplicemente il dispositivo con un cavo di rete (cioè collegare direttamente le porte dell'equipaggiamento di rete a cui era connesso). Tuttavia, c'è un lato negativo: lo stesso può fare anche un malintenzionato. Per implementare il principio del «nodo sul filo» è necessario tenere conto del traffico non solo livello dati, ma anche livelli di controllo e gestione – i dispositivi devono essere trasparenti per loro. Pertanto, tale traffico può essere crittografato solo quando non ci sono destinatari del traffico di questi tipi nella rete tra i dispositivi di crittografia, poiché se viene scartato o crittografato, la configurazione della rete potrebbe cambiare durante l'attivazione o disattivazione della crittografia. Il dispositivo di crittografia può essere trasparente anche per il segnalamento a livello fisico. In particolare, in caso di perdita di segnale, deve comunicare tale perdita (cioè disattivare i propri trasmettitori) avanti e indietro («per conto proprio») nella direzione del segnale.
È 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. È necessario ridurre al minimo l'interazione tra i diversi reparti per svolgere operazioni di routine. Pertanto, c'è un vantaggio in termini di convenienza per i dispositivi specializzati che supportano esclusivamente le funzionalità 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à di modificare le impostazioni di crittografia durante la manutenzione della rete.
Un altro fattore è la funzionalità e la comodità dei mezzi di gestione. Devono essere chiari, logici e offrire l'importazione e l'esportazione delle impostazioni, l'automazione e così via. È 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 è il supporto per la gestione (out-of-band), cioè tramite una rete di gestione dedicata, e per la gestione (in-band), cioè 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 è un grande vantaggio.
Compatibilità
Cioè, la compatibilità 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à: o attraverso trasparenza, o attraverso supporto esplicito 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à con le reti dipende dalla completezza e correttezza dell'implementazione dei protocolli di controllo. È fondamentale il supporto di diverse opzioni per il livello PHY (velocità, 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).
La trasparenza è 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).
Come si garantisce la trasparenza
Quindi, assicurati sempre di chiarire come viene garantito il supporto per i vari protocolli. Spesso, il supporto in modalità trasparente è più comodo e affidabile.
Interoperabilità
Questo è un altro tipo di compatibilità, ma in un senso diverso, ovvero la capacità 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.
Per la crittografia L2 nelle reti Ethernet esiste lo standard 802.1ae (MACsec), ma non utilizza la crittografia (end-to-end), ma inter-port, «hop-by-hop» (a catena) crittografia, e nella sua versione originale non è adatto per l'uso in reti distribuite, quindi sono emerse le sue estensioni proprietarie che superano questa limitazione (naturalmente, a scapito dell'interoperabilità con l'hardware di altri produttori). Tuttavia, nel 2018, è stata aggiunta supporto per reti distribuite nello standard 802.1ae, ma il supporto per i set di algoritmi di crittografia GOST è ancora assente. Pertanto, i protocolli di crittografia L2 proprietari e non standardano generalmente una maggiore efficienza (in particolare, minori costi in banda) e flessibilità (possibilità di cambiare algoritmi e modalità di crittografia).
Ai livelli superiori (L3 e L4) esistono standard riconosciuti, in primo luogo IPsec e TLS, ma anche qui non è tutto così semplice. Infatti, ognuno di questi standard è 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 è realistico aspettarsi piena interoperabilità, ma è importante garantire almeno l'interazione tra diversi modelli e diverse generazioni dello stesso produttore.
Affidabilità
Per confrontare diverse soluzioni, si possono utilizzare o il tempo medio di guasto, o il tasso di disponibilità. Se queste cifre non sono disponibili (o non vi si ha fiducia), è 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.
Costo
Per quanto riguarda i costi, come per la maggior parte delle soluzioni IT, è utile confrontare il costo totale di proprietà. Per il suo calcolo non è necessario reinventare la ruota, ma si può utilizzare qualsiasi metodologia adatta (ad esempio, quella di Gartner) e qualsiasi calcolatore (ad esempio, quello già utilizzato nell'organizzazione per calcolare il TCO). È chiaro che, per una soluzione di crittografia di rete, il costo totale di proprietà è composto da costi diretti 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é da costi indiretti costi derivanti dall'inattività della soluzione (causati dalla perdita di produttività degli utenti finali). Probabilmente, c'è solo una sottigliezza. L'impatto delle prestazioni della soluzione può essere considerato in modi diversi: o come costi indiretti causati dal calo di produttività, 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 è difficile calcolare con sufficiente precisione è meglio "escludere" dal calcolo: così si avrà 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.
Resilienza
L'ultima caratteristica è la resilienza della soluzione. Nella maggior parte dei casi, la resilienza può 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à dell'algoritmo di crittografia o di specifici modalità, e attraverso vulnerabilità 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à 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ò essere considerata equivalente (altrimenti ci si perderebbe nel labirinto della crittografia). Devono necessariamente essere algoritmi GOST? Qui è semplice: se lo scenario di utilizzo richiede la certificazione FSB per SKZI (e in Russia è spesso così, per la maggior parte degli scenari di crittografia di rete), allora si sceglie solo tra quelli certificati. Se non è così, allora non ha senso escludere i dispositivi non certificati dalla considerazione.
Un'altra minaccia è quella dell'hacking, ovvero l'accesso non autorizzato ai dispositivi (incluso l'accesso fisico dall'esterno e dall'interno del case). La minaccia può realizzarsi attraverso
vulnerabilità nella realizzazione – sia nell'hardware che nel codice. Pertanto, avrà la meglio chi adotta soluzioni con una "superficie di attacco" ridotta attraverso la rete, dotate di case protetti contro l'accesso fisico (con sensori di manomissione, protezione da sondaggio e ripristino automatico delle informazioni chiave in caso di apertura del case), così come quelle che consentono l'aggiornamento del firmware nel caso in cui venga scoperta una vulnerabilità nel codice. C'è anche un altro approccio: se tutti i dispositivi confrontati possiedono certificati FSB, il livello di resistenza all'hacking può essere considerato in base alla classe SKZI, per la quale è stato rilasciato il certificato.
Infine, un altro tipo di minaccia è rappresentato dagli errori nella configurazione e nell'operatività, 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à per i professionisti della sicurezza informatica più generali.
In sintesi
In linea di principio, si potrebbe proporre un indicatore integrale per confrontare diversi dispositivi, qualcosa come
$$display$$K_j=∑p_i r_{ij}$$display$$
dove p è il peso dell'indicatore e r è il rango del dispositivo in base a tale indicatore, con la possibilità 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
Caratteristica
Dispositivo 1
Dispositivo 2
…
Dispositivo N
Larghezza di banda
+
+
+++
Costi aggiuntivi
+
++
+++
Latenza
+
+
++
Scalabilità
+++
+
+++
Flessibilità
+++
++
+
Interoperabilità
++
+
+
Compatibilità
++
++
+++
Semplicità e comodità
+
+
++
Affidabilità
+++
+++
++
Costo
++
+++
+
Resilienza
++
++
+++
Sarò lieto di rispondere a domande e osservazioni critiche costruttive.
Fonte: habr.com
