Escrevi esta revisão (ou, se preferir, um guia de comparação) quando me pediram para comparar vários dispositivos de diferentes fornecedores. Além disso, esses dispositivos pertenciam a diferentes classes. Tive que entender a arquitetura e as especificações de todos esses dispositivos e criar um "sistema de coordenadas" para comparação. Ficarei feliz se minha revisão ajudar alguém:
- Compreender as descrições e especificações dos dispositivos de criptografia
- Diferenciar as características "papel" das realmente importantes na vida real
- Ir além do conjunto habitual de fornecedores e incluir na consideração quaisquer produtos adequados para resolver a tarefa em questão
- Fazer as perguntas certas nas negociações
- Elaborar requisitos de licitação (RFP)
- Compreender quais características terão que ser sacrificadas se um determinado modelo de dispositivo for escolhido
O que pode ser avaliado
Basicamente, a abordagem é aplicável a quaisquer dispositivos autônomos (standalone) adequados para criptografar o tráfego de rede entre segmentos Ethernet remotos (criptografia entre sites). Ou seja, unidades em um gabinete separado (bem, lâminas/módulos para chassi também serão incluídos aqui), que se conectam através de uma ou várias portas Ethernet à rede local (campus) Ethernet com tráfego não criptografado, e através de outra porta(s) – ao canal/rede, pela qual o tráfego já criptografado é transmitido para outros segmentos remotos. Tal solução de criptografia pode ser implementada em uma rede privada ou de operadora através de diferentes tipos de "transporte" (fibra óptica "escura", equipamentos de divisão de frequência, rede Ethernet comutável, assim como "pseudo-cabos" implementados em uma rede com outra arquitetura de roteamento, mais frequentemente MPLS), utilizando a tecnologia VPN ou sem ela.
Criptografia de rede em uma rede Ethernet distribuída
Os próprios dispositivos podem ser especializados (destinados exclusivamente à criptografia), ou multifuncionais (híbridos, convergentes), ou seja, que também executam outras funções (por exemplo, de firewall ou roteador). Diferentes fornecedores categorizam seus dispositivos em diferentes classes/categorias, mas isso não é o mais importante – o que realmente importa é se conseguem criptografar o tráfego entre sites e quais características possuem ao fazê-lo.
Apenas para lembrar, o termo "criptografia em rede", "criptografia de tráfego", "criptógrafo" - são termos informais, embora frequentemente utilizados. Nos atos normativos russos (incluindo aqueles que introduzem os padrões ГОСТs), você provavelmente não os encontrará.
Níveis de criptografia e modos de transmissão
Antes de começar a descrever as características que serão usadas para a avaliação, é necessário esclarecer uma coisa importante, nomeadamente o "nível de criptografia". Notei que ele é frequentemente mencionado tanto nos documentos oficiais dos fornecedores (em descrições, manuais etc.) quanto em discussões informais (em negociações, em treinamentos). Assim, parece que todos parecem saber do que se trata, mas eu fui testemunha de alguma confusão.
Então, o que é exatamente o "nível de criptografia"? Está claro que refere-se ao número do nível do modelo de referência de rede OSI/ISO em que ocorre a criptografia. Vamos ler o ГОСТ Р ИСО 7498-2–99 "Tecnologia da informação. Interconexão de sistemas abertos. Modelo de referência básico. Parte 2. Arquitetura de segurança da informação". Desse documento pode-se entender que o nível do serviço de confidencialidade (um dos mecanismos para garantir isso é a criptografia) - é o nível do protocolo, onde o bloco de dados de serviço ("carga útil", dados do usuário) é criptografado. Como está escrito no padrão, o serviço pode ser fornecido tanto neste mesmo nível, "com seus próprios meios", quanto com a ajuda do nível inferior (e é assim, por exemplo, que é frequentemente implementado no MACsec).
Na prática, pode haver dois modos de transmissão de informações criptografadas pela rede (me vem à mente o IPsec, mas esses modos também aparecem em outros protocolos). Em transporte (às vezes chamado de modo native) o bloco de dados de serviço é criptografado, enquanto os cabeçalhos permanecem "abertos", não criptografados (às vezes são adicionados campos adicionais com informações de serviço do algoritmo de criptografia, e outros campos são modificados, recalculados). No modo de túnel todo o bloco de dados de protocolo (ou seja, o próprio pacote) é criptografado e encapsulado em um bloco de dados de serviço do mesmo nível ou de um nível mais alto, ou seja, é envolto em novos cabeçalhos.
O nível de criptografia em si, combinado com um modo de transmissão, não é bom nem ruim, portanto, não se pode afirmar, por exemplo, que L3 em modo de transporte é melhor do que L2 em modo de túnel. Muitas características, que avaliam os dispositivos, dependem deles. Por exemplo, flexibilidade e compatibilidade. Para operar na rede L1 (retransmissão de fluxo de bits), L2 (comutação de quadros) e L3 (roteamento de pacotes) em modo de transporte, são necessárias soluções que criptografam em um nível igual ou superior (caso contrário, as informações de endereço ficarão criptografadas e os dados não chegarão ao destino), enquanto o modo de túnel permite superar essa limitação (embora sacrifique outras características importantes).
Modos de criptografia em L2: transporte e túnel
Agora, vamos analisar as características.
Desempenho
Para a criptografia em rede, o desempenho é um conceito complexo e multidimensional. Às vezes, um determinado modelo, superando em uma característica de desempenho, pode ficar atrás em outra. Por isso, é sempre útil considerar todos os componentes do desempenho da criptografia e seu impacto no desempenho da rede e nos aplicativos que a utilizam. Aqui, pode-se fazer uma analogia com um carro, para o qual não é apenas a velocidade máxima que importa, mas também o tempo de aceleração até a 'centena', o consumo de combustível e assim por diante. As características de desempenho recebem grande atenção tanto de fornecedores quanto de seus potenciais clientes. Normalmente, a classificação nas linhas de dispositivos de criptografia é feita com base no desempenho.
É claro que o desempenho depende tanto da complexidade das operações de rede e criptográficas realizadas no dispositivo (incluindo quão bem essas tarefas podem ser paralelizadas e pipelineadas), quanto do desempenho do hardware e da qualidade do software embarcado. Portanto, em modelos mais avançados, é aplicado um hardware mais potente, e às vezes há a possibilidade de equipá-lo com processadores adicionais e módulos de memória. Existem várias abordagens para a implementação de funções criptográficas: em um processador central universal (CPU), em um circuito integrado personalizado (ASIC) ou em um circuito integrado de lógica programável (FPGA). Cada abordagem tem suas vantagens e desvantagens. Por exemplo, a CPU pode se tornar um
estrangulamento" da criptografia, especialmente se o processador não tiver instruções especializadas para suportar o algoritmo de criptografia (ou se elas não forem utilizadas). Circuitos integrados especializados carecem de flexibilidade; "reprogramá-los" para aumentar o desempenho, adicionar novas funções ou corrigir vulnerabilidades nem sempre é viável. Além disso, seu uso se torna rentável apenas em grandes volumes de produção. É por isso que o "meio-termo" se tornou tão popular - a aplicação de FPGA (em russo, ПЛИС). Na verdade, é nos FPGAs que são feitos os chamados aceleradores criptográficos - módulos de hardware especializados que suportam operações criptográficas, embutidos ou conectáveis. Quando se trata exatamente de criptografia de rede, é lógico que o desempenho das soluções deve ser medido nas mesmas magnitudes que para outros dispositivos de rede - largura de banda, percentual de perda de quadros (frame loss) e latência (latency). Essas magnitudes são definidas no RFC 1242. A propósito, sobre a variação de latência (jitter) frequentemente mencionada, nada é dito neste RFC. Como medir essas magnitudes? Não encontrei uma metodologia estabelecida em quaisquer padrões (oficiais ou não oficiais, como RFC) especificamente para criptografia de rede. Seria lógico usar a metodologia para dispositivos de rede, consagrada no padrão RFC 2544. Muitos fornecedores a seguem – muitos, mas não todos. Por exemplo, enviam tráfego de teste apenas em uma direção ao invés de ambas, como recomendamos previsto pelo padrão. Mas tudo bem.
A medição do desempenho dos dispositivos de criptografia de rede possui suas particularidades. Primeiro, é fundamental realizar todas as medições em pares de dispositivos: embora os algoritmos de criptografia sejam simétricos, as latências e perdas de pacotes durante a criptografia e descriptografia nem sempre serão iguais. Em segundo lugar, é importante medir a delta, ou seja, o impacto da criptografia de rede no desempenho final da rede, comparando duas configurações: uma sem dispositivos de criptografia e outra com eles. Ou, como no caso de dispositivos híbridos que combinam várias funções além da criptografia de rede, quando a criptografia está desligada e quando está ligada. Esse impacto pode variar e depender da configuração dos dispositivos de criptografia, dos modos de operação e, em última análise, da natureza do tráfego. Em particular, muitos índices de desempenho dependem do tamanho dos pacotes, por isso, para comparar o desempenho de diferentes soluções, gráficos de dependência desses índices em relação ao tamanho dos pacotes são frequentemente utilizados, ou utiliza-se o IMIX – uma distribuição de tráfego por tamanhos de pacotes que reflete aproximadamente a realidade. Se tomarmos como referência a mesma configuração base sem criptografia, poderemos comparar soluções de criptografia de rede implementadas de maneiras diferentes, sem nos aprofundar nessas diferenças: L2 com L3, armazenamento e encaminhamento (store-and-forward) com encaminhamento direto (cut-through), especializadas com convergentes, GOST com AES e assim por diante.
Diagrama de conexão para teste de desempenho
A primeira característica a ser observada é a "velocidade" do dispositivo de criptografia, ou seja, a largura de banda (bandwidth) de suas interfaces de rede, a velocidade de fluxo de bits. Isso é determinado pelos padrões de rede suportados pelas interfaces. Para Ethernet, os números comuns são 1 Gbps e 10 Gbps. Mas, como sabemos, em qualquer rede, a capacidade teórica máxima de transmissão (throughput) em cada um de seus níveis é sempre menor que a largura de banda: parte da largura de banda é 'consumida' pelos intervalos entre quadros, cabeçalhos de controle, e assim por diante. Se o dispositivo é capaz de aceitar, processar (neste caso, criptografar ou descriptografar) e transmitir tráfego na velocidade total da interface de rede, ou seja, com a máxima capacidade teórica dessa camada do modelo de rede, diz-se que ele está operando na velocidade da linha. Para isso, é necessário que o dispositivo não perca e não descarte pacotes, independentemente de seu tamanho e da frequência de sua chegada. Se o dispositivo de criptografia não suporta operação na velocidade da linha, geralmente é indicada sua capacidade máxima em gigabits por segundo (às vezes com a menção do tamanho dos pacotes – quanto menores os pacotes, geralmente menor é a largura de banda). É muito importante entender que a capacidade máxima é o máximo sem perda (mesmo que o dispositivo possa 'gerar' tráfego em uma velocidade maior, mas perdendo parte dos pacotes). Além disso, é preciso prestar atenção ao fato de que alguns fornecedores medem a capacidade total entre todos os pares de portas, então esses números dizem pouco, se todo o tráfego criptografado passar por uma única porta.
Onde a operação na velocidade da linha (ou, de outra forma, sem perda de pacotes) é particularmente importante? Em canais de alta largura de banda e alta latência (por exemplo, via satélite), onde, para manter uma alta velocidade de transmissão, é necessário definir um grande tamanho de janela TCP, e onde perdas de pacotes reduzem drasticamente o desempenho da rede.
Mas nem toda a largura de banda é usada para transmitir dados úteis. É preciso considerar os chamados custos operacionais (overhead) da largura de banda. Esta é a parte da largura de banda do dispositivo de criptografia (em porcentagem ou em bytes por pacote) que é efetivamente perdida (não pode ser utilizada para a transmissão de dados de aplicações). As sobrecargas ocorrem, em primeiro lugar, devido ao aumento do tamanho (acréscimos, 'padding') do campo de dados em pacotes de rede criptografados (dependendo do algoritmo de criptografia e do modo de operação). Em segundo lugar, devido ao aumento do comprimento dos cabeçalhos dos pacotes (modo de túnel, inserção de cabeçalho do protocolo de criptografia, inserção de integridade, etc., dependendo do protocolo e do modo de operação do cifrador e do modo de transmissão) — geralmente, essas sobrecargas são as mais significativas, e são as que recebem mais atenção primeiro. Em terceiro lugar, devido à fragmentação dos pacotes quando ultrapassam o tamanho máximo do bloco de dados (MTU) (se a rede consegue dividir pacotes que excedem o MTU em dois, duplicando seus cabeçalhos). Em quarto lugar, devido à geração de tráfego adicional de controle na rede entre dispositivos de criptografia (para troca de chaves, estabelecimento de túneis, etc.). Baixas sobrecargas são importantes onde a largura de banda do canal é limitada. Isso se manifesta especialmente no tráfego de pacotes pequenos, como o de voz — onde as sobrecargas podem
Largura de banda
consumir mais da metade da velocidade do canal! – a diferença (em frações de segundo) na latência da rede (tempo que os dados levam para passar da entrada da rede até a saída) entre a transferência de dados sem criptografia de rede e com ela. De modo geral, quanto menor a latência da rede, mais crítica se torna a latência introduzida pelos dispositivos de criptografia. A latência é causada pela própria operação de criptografia (que depende do algoritmo de criptografia, do tamanho do bloco e do modo de operação do criptógrafo, bem como da qualidade da sua implementação no software), assim como pelo processamento do pacote de rede no dispositivo. A latência introduzida depende tanto do modo de processamento dos pacotes (em linha ou 'salvar-e-enviar'), quanto da performance da plataforma (a implementação 'hardware' em FPGA ou ASIC, normalmente, é mais rápida do que a 'software' em CPU). A criptografia L2 quase sempre apresenta uma latência introduzida menor em comparação com a criptografia em L3 ou L4: isso se deve ao fato de que dispositivos que criptografam em L3/L4 muitas vezes são realizados de forma convergente. Por exemplo, em criptografadores Ethernet de alta velocidade, implementados em FPGA e que criptografam em L2, a latência causada pela operação de criptografia é desprezivelmente baixa – às vezes, ao ativar a criptografia em um par de dispositivos, a latência total que eles introduzem até diminui! Uma baixa latência é importante onde é comparável às latências totais no canal, incluindo a latência de propagação do sinal, que é de aproximadamente 5 μs por quilômetro. Ou seja, pode-se afirmar que para redes de escala urbana (dezenas de quilômetros de diâmetro) microsegundos podem fazer uma grande diferença. Por exemplo, para a replicação síncrona de bancos de dados, trading de alta frequência, ou mesmo blockchain.
Latência introduzida
Escalabilidade
Grandes redes distribuídas podem incluir milhares de nós e dispositivos de rede, bem como centenas de segmentos de redes locais. É importante que as soluções de criptografia não imponham restrições adicionais ao tamanho e à topologia da rede distribuída. Isso diz respeito principalmente ao número máximo de endereços de nós e redes. Limitações desse tipo podem surgir, por exemplo, ao implementar uma topologia multiponto em uma rede criptografada (com conexões protegidas independentes ou túneis) ou criptografia seletiva (por exemplo, por número de protocolo ou VLAN). Se os endereços de rede (MAC, IP, VLAN ID) forem utilizados como chaves em uma tabela, onde o número de linhas é limitado, essas restrições se manifestam.
Além disso, grandes redes frequentemente possuem múltiplos níveis estruturais, incluindo a rede backbone, em cada um dos quais são implementados seus próprios esquemas de endereçamento e políticas de roteamento. Para implementar tal abordagem, costumam ser usados formatos de quadros especiais (como Q-in-Q ou MAC-in-MAC) e protocolos de determinação de rotas. A fim de não prejudicar a construção dessas redes, os dispositivos de criptografia devem lidar corretamente com esses quadros (ou seja, neste sentido, escalabilidade significará compatibilidade – que será abordada adiante).
Flexibilidade
Aqui estamos falando sobre o suporte a diferentes configurações, esquemas de conexão, topologias e mais. Por exemplo, para redes comutadas baseadas em tecnologias Carrier Ethernet, isso significa suporte a diferentes tipos de conexões virtuais (E-Line, E-LAN, E-Tree), diferentes tipos de serviços (tanto por portas quanto por VLAN) e diferentes tecnologias de transporte (que já foram mencionadas anteriormente). Ou seja, o dispositivo deve ser capaz de operar tanto em modo linear ('ponto a ponto') quanto em modo multiponto, estabelecer túneis separados para diferentes VLANs e permitir a entrega não ordenada de pacotes dentro de um canal protegido. A capacidade de escolher diferentes modos de operação de criptografia (inclusive com autenticação de conteúdo ou sem) e diferentes modos de transmissão de pacotes permite equilibrar a resistência e o desempenho, dependendo das condições atuais.
O suporte a redes privadas, cujo equipamento pertence a uma única organização (ou é alugado por ela), e a redes operacionais, cujos diferentes segmentos estão sob a responsabilidade de diferentes empresas, também é importante. É preferível que a solução permita a gestão tanto por recursos próprios quanto por uma organização externa (no modelo de serviço gerenciado). Em redes operacionais, outra função importante é o suporte à multitenância (uso compartilhado por diferentes clientes), na forma de isolamento criptográfico entre clientes (assinantes), cujo tráfego passa pelo mesmo conjunto de dispositivos de criptografia. Normalmente, isso requer o uso de conjuntos distintos de chaves e certificados para cada cliente.
Se o dispositivo é adquirido para um cenário específico, todas essas funcionalidades podem não ser tão importantes – é necessário apenas garantir que o dispositivo suporte o que é necessário no momento. Porém, se a solução é comprada para o futuro, para atender também a cenários futuros, e é escolhida como padrão corporativo, a flexibilidade será bem-vinda – especialmente considerando as limitações de interoperabilidade entre dispositivos de diferentes fornecedores (sobre isso adiante).
Simplicidade e comodidade
A facilidade de manutenção é um conceito multifatorial. Pode-se dizer aproximadamente que são os custos totais de tempo que especialistas de determinada qualificação precisam para manter a solução em diferentes etapas do seu ciclo de vida. Se não há custos e a instalação, configuração e operação são totalmente automáticas, os custos são zero e a conveniência é absoluta. Claro, no mundo real isso não ocorre. Uma aproximação razoável é o modelo «nó na linha» (bump-in-the-wire), ou conexão transparente, na qual a adição e remoção de dispositivos de criptografia não requer alterações manuais ou automáticas na configuração da rede. Isso simplifica a manutenção da solução: é possível ativar e desativar o recurso de criptografia com tranquilidade e, se necessário, simplesmente "contornar" o dispositivo com um cabo de rede (ou seja, conectar diretamente as portas do equipamento de rede às quais ele estava conectado). No entanto, há um ponto negativo – um invasor pode fazer o mesmo. Para implementar o princípio do "nó no fio", é preciso considerar o tráfego não apenas camada de dados, mas também camadas de controle e gerenciamento – os dispositivos devem ser transparentes para eles. Portanto, esse tráfego só pode ser criptografado quando na rede entre os dispositivos de criptografia não há destinatários para esses tipos de tráfego, pois se ele for descartado ou criptografado, a configuração da rede pode mudar ao ativar ou desativar a criptografia. O dispositivo de criptografia pode ser transparente também para sinalizações no nível físico. Especificamente, em caso de perda de sinal, ele deve transmitir essa perda (ou seja, desativar seus transmissores) de forma retroativa e para frente ("por si mesmo") na direção do sinal.
Apoio à separação de poderes entre os departamentos de segurança da informação e TI, particularmente o departamento de rede, também é importante. A solução de criptografia deve apoiar o modelo de gerenciamento de acesso e auditoria adotado pela organização. A necessidade de interação entre diferentes departamentos para a realização de operações rotineiras deve ser minimizada. Portanto, o benefício em termos de conveniência reside em dispositivos especializados que apoiam exclusivamente funções de criptografia e são o mais transparentes possível para as operações de rede. Em termos simples, os funcionários da equipe de segurança da informação não devem ter motivos para contatar os "especialistas em redes" para alterar as configurações da rede. E, por sua vez, estes não devem ter a necessidade de modificar as configurações de criptografia durante a manutenção da rede.
Outro fator é a capacidade e a conveniência das ferramentas de gerenciamento. Elas devem ser intuitivas, lógicas, proporcionar importação e exportação de configurações, automação, etc. É importante observar quais opções de gerenciamento estão disponíveis (geralmente um ambiente de gerenciamento próprio, uma interface web e linha de comando) e quais funcionalidades estão incluídas em cada uma (podem haver restrições). Uma função importante é o suporte de gerenciamento fora de banda (out-of-band), ou seja, através de uma rede de gerenciamento dedicada, e de gerenciamento em banda (in-band), ou seja, através da rede comum pela qual o tráfego útil é transmitido. As ferramentas de gerenciamento devem sinalizar todas as situações anômalas, incluindo incidentes de segurança da informação (IB). Operações rotineiras e repetitivas devem ser realizadas automaticamente. Isso se aplica principalmente ao gerenciamento de chaves. Elas devem ser geradas/distribuídas automaticamente. O suporte a PKI é uma grande vantagem.
Compatibilidade
Isso se refere à compatibilidade do dispositivo com os padrões de rede. E não se trata apenas de padrões industriais aceitos por organizações reconhecidas, como o IEEE, mas também de protocolos proprietários de líderes do setor, como a Cisco. Existem duas maneiras principais de garantir a compatibilidade: ou através da transparência, ou através do suporte explícito aos protocolos (quando o dispositivo de criptografia se torna um dos nós da rede para um determinado protocolo e processa o tráfego de controle desse protocolo). A plenitude e a correção na implementação dos protocolos de controle dependem da compatibilidade com as redes. É importante o apoio a diferentes variantes do nível PHY (velocidades, meios de transmissão, esquemas de codificação), quadros Ethernet de diferentes formatos com qualquer MTU, e diferentes protocolos de serviço L3 (principalmente da família TCP/IP).
A transparência é garantida por meio de mecanismos de mutação (mudança temporária do conteúdo dos cabeçalhos abertos no tráfego entre os criptografadores), omissão (quando pacotes individuais permanecem não criptografados) e desvio do início da criptografia (quando campos normalmente criptografados dos pacotes não são criptografados).
Como é garantida a transparência
Portanto, sempre verifique como o suporte a um determinado protocolo é garantido. Muitas vezes, o suporte em modo transparente é mais conveniente e confiável.
Interoperabilidade
Esta também é uma forma de compatibilidade, mas em outro sentido, ou seja, a capacidade de trabalhar em conjunto com outros modelos de dispositivos de criptografia, incluindo de outros fabricantes. Aqui, muito depende do estado de padronização dos protocolos de criptografia. Não há padrões de criptografia amplamente reconhecidos no L1.
Para criptografia L2 em redes Ethernet, existe o padrão 802.1ae (MACsec), mas ele não utiliza criptografia de ponta a ponta (end-to-end), mas sim criptografia entre portas, chamada de criptografia hop-by-hop, e na sua edição original era inadequada para uso em redes distribuídas, portanto surgiram suas extensões proprietárias que superam essa limitação (naturalmente, à custa da interoperabilidade com equipamentos de outros fabricantes). De fato, em 2018, o padrão 802.1ae recebeu suporte para redes distribuídas, mas ainda não há suporte para os conjuntos de algoritmos de criptografia ГОСТ. Assim, os protocolos de criptografia L2 proprietários e não padronizados geralmente se destacam por maior eficiência (particularmente, menores sobrecargas de largura de banda) e flexibilidade (capacidade de troca de algoritmos e modos de criptografia).
Em níveis mais altos (L3 e L4), há padrões reconhecidos, principalmente IPsec e TLS, mas aqui também não é tão simples. O fato é que cada um desses padrões é um conjunto de protocolos, cada um com diferentes versões e extensões obrigatórias ou não obrigatórias para implementação. Além disso, alguns fabricantes preferem aplicar seus próprios protocolos de criptografia também no L3/L4. Portanto, na maioria dos casos, não se deve esperar plena interoperabilidade, mas é importante que haja ao menos interação entre diferentes modelos e diferentes gerações de um mesmo fabricante.
Confiabilidade
Para comparar diferentes soluções, pode-se usar o tempo médio de falha ou o coeficiente de disponibilidade. Se esses números não estiverem disponíveis (ou se não houver confiança neles), pode-se fazer uma comparação qualitativa. A vantagem será para dispositivos com gerenciamento fácil (menor risco de erros na configuração), para criptografadores especializados (pelo mesmo motivo), bem como para soluções com o menor tempo de detecção e correção de falhas, incluindo meios de reserva quente de nós e dispositivos inteiros.
Custo
Quanto ao custo, assim como na maioria das soluções de TI, faz sentido comparar o custo total de propriedade. Para essa avaliação, não é necessário reinventar a roda, basta usar qualquer método apropriado (por exemplo, da Gartner) e qualquer calculadora (como a que já é utilizada na organização para calcular o TCO). É evidente que, para uma solução de criptografia de rede, o custo total de propriedade é composto por custos diretos com a compra ou aluguel da própria solução, a infraestrutura para abrigar o equipamento e os custos com implementação, administração e manutenção (não importa se com recursos próprios ou na forma de serviços terceirizados), além de custos indiretos provocados pela inatividade da solução (devido à perda de produtividade dos usuários finais). Provavelmente, há apenas um detalhe. O impacto da performance da solução pode ser contabilizado de diferentes maneiras: ou como custos indiretos, resultantes da diminuição da produtividade, ou como custos diretos "virtuais" com a compra/modernização e manutenção de recursos de rede que compensam a diminuição da performance da rede devido à adoção da criptografia. De qualquer forma, os custos que são difíceis de calcular com precisão suficiente devem ser "excluídos" da conta: assim haverá mais confiança no valor final. E, como de costume, a comparação de diferentes dispositivos com base no TCO deve ser feita considerando cenários específicos de uso - reais ou típicos.
Resiliência
E a última característica é a resistência da solução. Na maioria dos casos, a resistência pode ser avaliada apenas qualitativamente, comparando diferentes soluções entre si. Devemos lembrar que os dispositivos de criptografia são não apenas meios, mas também objetos de proteção. Eles podem estar sujeitos a diversas ameaças. As ameaças à privacidade, à reprodução e à modificação de mensagens estão em primeiro plano. Essas ameaças podem ser ativadas através de vulnerabilidades do algoritmo de criptografia ou de modos específicos, assim como vulnerabilidades nos protocolos de criptografia (incluindo nas etapas de estabelecimento de conexão e geração/distribuição de chaves). A vantagem será das soluções que permitem a troca do algoritmo de criptografia ou a alteração do modo de cifragem (pelo menos através de uma atualização de firmware), das soluções que oferecem a criptografia mais completa, ocultando do invasor não apenas os dados do usuário, mas também informações de endereço e outras informações operacionais, assim como aquelas que não apenas criptografam, mas também protegem as mensagens contra reprodução e modificação. Para todos os algoritmos modernos de criptografia, assinatura digital, geração de chaves e outros que estão estabelecidos em normas, a resistência pode ser considerada igual (caso contrário, pode-se simplesmente se perder na complexidade da criptografia). Devem ser, necessariamente, os algoritmos GOST? Aqui tudo é simples: se o cenário de aplicação exigir certificação da FSB para SKZI (o que na Rússia geralmente é o caso), para a maioria dos cenários de criptografia em rede, então escolhemos apenas entre os certificados. Se não, não faz sentido excluir dispositivos não certificados da consideração.
Outra ameaça é a ameaça de invasão, acesso não autorizado aos dispositivos (incluindo através de acesso físico de fora e de dentro do gabinete). A ameaça pode se concretizar através de
vulnerabilidades na implementação - em hardware e em código. Portanto, a vantagem será para soluções com uma "superfície de ataque" mínima através da rede, com caixas protegidas contra acesso físico (com sensores de violação, proteção contra sondagem e reinicialização automática das informações-chave ao abrir a caixa), bem como para aquelas que permitem a atualização do firmware quando uma vulnerabilidade no código se torna conhecida. Há também outra abordagem: se todos os dispositivos em comparação possuem certificados do FSB, então o indicador de resistência a invasões pode ser considerado a classe SKZI, para a qual o certificado foi emitido.
Finalmente, outro tipo de ameaça são os erros na configuração e operação, o fator humano em sua essência. Aqui se manifesta mais uma vantagem dos criptografadores especializados em relação às soluções convergentes, que frequentemente são voltadas para "especialistas em redes" experientes e podem causar dificuldades para especialistas de cibersegurança mais generalistas.
Resumo
Basicamente, poderíamos sugerir um indicador integral para comparar diferentes dispositivos, algo como
$$display$$K_j=∑p_i r_{ij}$$display$$
onde p é o peso do indicador, e r é a classificação do dispositivo com base nesse indicador, podendo qualquer uma das características listadas acima ser quebrada em indicadores "atômicos". Essa fórmula poderia ser útil, por exemplo, ao comparar propostas de licitação com regras previamente acordadas. Mas também podemos nos contentar com uma tabela simples do tipo
Características
Dispositivo 1
Dispositivo 2
…
Dispositivo N
Largura de banda
+
+
+++
Custos adicionais
+
++
+++
Latência
+
+
++
Escalabilidade
+++
+
+++
Flexibilidade
+++
++
+
Interoperabilidade
++
+
+
Compatibilidade
++
++
+++
Simplicidade e comodidade
+
+
++
Resiliência
+++
+++
++
Custo
++
+++
+
Resiliência
++
++
+++
Fico à disposição para responder perguntas e críticas construtivas.
Fonte: habr.com
