VPN<\/a> ou sem ela.<\/p>\nCriptografia de rede em uma rede Ethernet distribu\u00edda<\/i><\/p>\n
Os pr\u00f3prios dispositivos podem ser especializados<\/b> (destinados exclusivamente \u00e0 criptografia), ou multifuncionais (h\u00edbridos, convergentes<\/b>), ou seja, que tamb\u00e9m executam outras fun\u00e7\u00f5es (por exemplo, de firewall ou roteador). Diferentes fornecedores categorizam seus dispositivos em diferentes classes\/categorias, mas isso n\u00e3o \u00e9 o mais importante \u2013 o que realmente importa \u00e9 se conseguem criptografar o tr\u00e1fego entre sites e quais caracter\u00edsticas possuem ao faz\u00ea-lo.<\/p>\n
Apenas para lembrar, o termo \"criptografia em rede\", \"criptografia de tr\u00e1fego\", \"cript\u00f3grafo\" - s\u00e3o termos informais, embora frequentemente utilizados. Nos atos normativos russos (incluindo aqueles que introduzem os padr\u00f5es \u0413\u041e\u0421\u0422s), voc\u00ea provavelmente n\u00e3o os encontrar\u00e1.<\/p>\n
N\u00edveis de criptografia e modos de transmiss\u00e3o<\/h4>\n \nAntes de come\u00e7ar a descrever as caracter\u00edsticas que ser\u00e3o usadas para a avalia\u00e7\u00e3o, \u00e9 necess\u00e1rio esclarecer uma coisa importante, nomeadamente o \"n\u00edvel de criptografia\". Notei que ele \u00e9 frequentemente mencionado tanto nos documentos oficiais dos fornecedores (em descri\u00e7\u00f5es, manuais etc.) quanto em discuss\u00f5es informais (em negocia\u00e7\u00f5es, em treinamentos). Assim, parece que todos parecem saber do que se trata, mas eu fui testemunha de alguma confus\u00e3o.<\/p>\n
Ent\u00e3o, o que \u00e9 exatamente o \"n\u00edvel de criptografia\"? Est\u00e1 claro que refere-se ao n\u00famero do n\u00edvel do modelo de refer\u00eancia de rede OSI\/ISO em que ocorre a criptografia. Vamos ler o \u0413\u041e\u0421\u0422 \u0420 \u0418\u0421\u041e 7498-2\u201399 \"Tecnologia da informa\u00e7\u00e3o. Interconex\u00e3o de sistemas abertos. Modelo de refer\u00eancia b\u00e1sico. Parte 2. Arquitetura de seguran\u00e7a da informa\u00e7\u00e3o\". Desse documento pode-se entender que o n\u00edvel do servi\u00e7o de confidencialidade (um dos mecanismos para garantir isso \u00e9 a criptografia) - \u00e9 o n\u00edvel do protocolo, onde o bloco de dados de servi\u00e7o (\"carga \u00fatil\", dados do usu\u00e1rio) \u00e9 criptografado. Como est\u00e1 escrito no padr\u00e3o, o servi\u00e7o pode ser fornecido tanto neste mesmo n\u00edvel, \"com seus pr\u00f3prios meios\", quanto com a ajuda do n\u00edvel inferior (e \u00e9 assim, por exemplo, que \u00e9 frequentemente implementado no MACsec).<\/p>\n
Na pr\u00e1tica, pode haver dois modos de transmiss\u00e3o de informa\u00e7\u00f5es criptografadas pela rede (me vem \u00e0 mente o IPsec, mas esses modos tamb\u00e9m aparecem em outros protocolos). Em transporte<\/b> (\u00e0s vezes chamado de modo native) o bloco de dados de servi\u00e7o<\/b> \u00e9 criptografado, enquanto os cabe\u00e7alhos permanecem \"abertos\", n\u00e3o criptografados (\u00e0s vezes s\u00e3o adicionados campos adicionais com informa\u00e7\u00f5es de servi\u00e7o do algoritmo de criptografia, e outros campos s\u00e3o modificados, recalculados). No modo de t\u00fanel<\/b> todo o bloco de dados de protocolo<\/b> (ou seja, o pr\u00f3prio pacote) \u00e9 criptografado e encapsulado em um bloco de dados de servi\u00e7o do mesmo n\u00edvel ou de um n\u00edvel mais alto, ou seja, \u00e9 envolto em novos cabe\u00e7alhos.<\/p>\n
O n\u00edvel de criptografia em si, combinado com um modo de transmiss\u00e3o, n\u00e3o \u00e9 bom nem ruim, portanto, n\u00e3o se pode afirmar, por exemplo, que L3 em modo de transporte \u00e9 melhor do que L2 em modo de t\u00fanel. Muitas caracter\u00edsticas, que avaliam os dispositivos, dependem deles. Por exemplo, flexibilidade e compatibilidade. Para operar na rede L1 (retransmiss\u00e3o de fluxo de bits), L2 (comuta\u00e7\u00e3o de quadros) e L3 (roteamento de pacotes) em modo de transporte, s\u00e3o necess\u00e1rias solu\u00e7\u00f5es que criptografam em um n\u00edvel igual ou superior (caso contr\u00e1rio, as informa\u00e7\u00f5es de endere\u00e7o ficar\u00e3o criptografadas e os dados n\u00e3o chegar\u00e3o ao destino), enquanto o modo de t\u00fanel permite superar essa limita\u00e7\u00e3o (embora sacrifique outras caracter\u00edsticas importantes).<\/p>\n
Modos de criptografia em L2: transporte e t\u00fanel<\/i><\/p>\n
Agora, vamos analisar as caracter\u00edsticas.<\/p>\n
Desempenho<\/h4>\n \nPara a criptografia em rede, o desempenho \u00e9 um conceito complexo e multidimensional. \u00c0s vezes, um determinado modelo, superando em uma caracter\u00edstica de desempenho, pode ficar atr\u00e1s em outra. Por isso, \u00e9 sempre \u00fatil 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\u00e3o \u00e9 apenas a velocidade m\u00e1xima que importa, mas tamb\u00e9m o tempo de acelera\u00e7\u00e3o at\u00e9 a 'centena', o consumo de combust\u00edvel e assim por diante. As caracter\u00edsticas de desempenho recebem grande aten\u00e7\u00e3o tanto de fornecedores quanto de seus potenciais clientes. Normalmente, a classifica\u00e7\u00e3o nas linhas de dispositivos de criptografia \u00e9 feita com base no desempenho.<\/p>\n
\u00c9 claro que o desempenho depende tanto da complexidade das opera\u00e7\u00f5es de rede e criptogr\u00e1ficas realizadas no dispositivo (incluindo qu\u00e3o bem essas tarefas podem ser paralelizadas e pipelineadas), quanto do desempenho do hardware e da qualidade do software embarcado. Portanto, em modelos mais avan\u00e7ados, \u00e9 aplicado um hardware mais potente, e \u00e0s vezes h\u00e1 a possibilidade de equip\u00e1-lo com processadores adicionais e m\u00f3dulos de mem\u00f3ria. Existem v\u00e1rias abordagens para a implementa\u00e7\u00e3o de fun\u00e7\u00f5es criptogr\u00e1ficas: em um processador central universal (CPU), em um circuito integrado personalizado (ASIC) ou em um circuito integrado de l\u00f3gica program\u00e1vel (FPGA). Cada abordagem tem suas vantagens e desvantagens. Por exemplo, a CPU pode se tornar um<\/p>\n
estrangulamento\" da criptografia, especialmente se o processador n\u00e3o tiver instru\u00e7\u00f5es especializadas para suportar o algoritmo de criptografia (ou se elas n\u00e3o forem utilizadas). Circuitos integrados especializados carecem de flexibilidade; \"reprogram\u00e1-los\" para aumentar o desempenho, adicionar novas fun\u00e7\u00f5es ou corrigir vulnerabilidades nem sempre \u00e9 vi\u00e1vel. Al\u00e9m disso, seu uso se torna rent\u00e1vel apenas em grandes volumes de produ\u00e7\u00e3o. \u00c9 por isso que o \"meio-termo\" se tornou t\u00e3o popular - a aplica\u00e7\u00e3o de FPGA (em russo, \u041f\u041b\u0418\u0421). Na verdade, \u00e9 nos FPGAs que s\u00e3o feitos os chamados aceleradores criptogr\u00e1ficos - m\u00f3dulos de hardware especializados que suportam opera\u00e7\u00f5es criptogr\u00e1ficas, embutidos ou conect\u00e1veis. Quando se trata exatamente de<\/b> criptografia de rede, \u00e9 l\u00f3gico que o desempenho das solu\u00e7\u00f5es deve ser medido nas mesmas magnitudes que para outros dispositivos de rede - largura de banda, percentual de perda de quadros (frame loss) e lat\u00eancia (latency). Essas magnitudes s\u00e3o definidas no RFC 1242. A prop\u00f3sito, sobre a varia\u00e7\u00e3o de lat\u00eancia (jitter) frequentemente mencionada, nada \u00e9 dito neste RFC. Como medir essas magnitudes? N\u00e3o encontrei uma metodologia estabelecida em quaisquer padr\u00f5es (oficiais ou n\u00e3o oficiais, como RFC) especificamente para criptografia de rede. Seria l\u00f3gico usar a metodologia para dispositivos de rede, consagrada no padr\u00e3o RFC 2544. Muitos fornecedores a seguem \u2013 muitos, mas n\u00e3o todos. Por exemplo, enviam tr\u00e1fego de teste apenas em uma dire\u00e7\u00e3o ao inv\u00e9s de ambas, como recomendamos<\/b> previsto pelo padr\u00e3o. Mas tudo bem.<\/p>\n
A medi\u00e7\u00e3o do desempenho dos dispositivos de criptografia de rede possui suas particularidades. Primeiro, \u00e9 fundamental realizar todas as medi\u00e7\u00f5es em pares de dispositivos: embora os algoritmos de criptografia sejam sim\u00e9tricos, as lat\u00eancias e perdas de pacotes durante a criptografia e descriptografia nem sempre ser\u00e3o iguais. Em segundo lugar, \u00e9 importante medir a delta, ou seja, o impacto da criptografia de rede no desempenho final da rede, comparando duas configura\u00e7\u00f5es: uma sem dispositivos de criptografia e outra com eles. Ou, como no caso de dispositivos h\u00edbridos que combinam v\u00e1rias fun\u00e7\u00f5es al\u00e9m da criptografia de rede, quando a criptografia est\u00e1 desligada e quando est\u00e1 ligada. Esse impacto pode variar e depender da configura\u00e7\u00e3o dos dispositivos de criptografia, dos modos de opera\u00e7\u00e3o e, em \u00faltima an\u00e1lise, da natureza do tr\u00e1fego. Em particular, muitos \u00edndices de desempenho dependem do tamanho dos pacotes, por isso, para comparar o desempenho de diferentes solu\u00e7\u00f5es, gr\u00e1ficos de depend\u00eancia desses \u00edndices em rela\u00e7\u00e3o ao tamanho dos pacotes s\u00e3o frequentemente utilizados, ou utiliza-se o IMIX \u2013 uma distribui\u00e7\u00e3o de tr\u00e1fego por tamanhos de pacotes que reflete aproximadamente a realidade. Se tomarmos como refer\u00eancia a mesma configura\u00e7\u00e3o base sem criptografia, poderemos comparar solu\u00e7\u00f5es de criptografia de rede implementadas de maneiras diferentes, sem nos aprofundar nessas diferen\u00e7as: L2 com L3, armazenamento e encaminhamento (store-and-forward) com encaminhamento direto (cut-through), especializadas com convergentes, GOST com AES e assim por diante.<\/p>\n
Diagrama de conex\u00e3o para teste de desempenho<\/i><\/p>\n
A primeira caracter\u00edstica a ser observada \u00e9 a \"velocidade\" do dispositivo de criptografia, ou seja, a largura de banda<\/b> (bandwidth) de suas interfaces de rede, a velocidade de fluxo de bits. Isso \u00e9 determinado pelos padr\u00f5es de rede suportados pelas interfaces. Para Ethernet, os n\u00fameros comuns s\u00e3o 1 Gbps e 10 Gbps. Mas, como sabemos, em qualquer rede, a capacidade te\u00f3rica m\u00e1xima de transmiss\u00e3o<\/b> (throughput) em cada um de seus n\u00edveis \u00e9 sempre menor que a largura de banda: parte da largura de banda \u00e9 'consumida' pelos intervalos entre quadros, cabe\u00e7alhos de controle, e assim por diante. Se o dispositivo \u00e9 capaz de aceitar, processar (neste caso, criptografar ou descriptografar) e transmitir tr\u00e1fego na velocidade total da interface de rede, ou seja, com a m\u00e1xima capacidade te\u00f3rica dessa camada do modelo de rede, diz-se que ele est\u00e1 operando na velocidade da linha<\/b>. Para isso, \u00e9 necess\u00e1rio que o dispositivo n\u00e3o perca e n\u00e3o descarte pacotes, independentemente de seu tamanho e da frequ\u00eancia de sua chegada. Se o dispositivo de criptografia n\u00e3o suporta opera\u00e7\u00e3o na velocidade da linha, geralmente \u00e9 indicada sua capacidade m\u00e1xima em gigabits por segundo (\u00e0s vezes com a men\u00e7\u00e3o do tamanho dos pacotes \u2013 quanto menores os pacotes, geralmente menor \u00e9 a largura de banda). \u00c9 muito importante entender que a capacidade m\u00e1xima \u00e9 o m\u00e1ximo sem perda<\/b> (mesmo que o dispositivo possa 'gerar' tr\u00e1fego em uma velocidade maior, mas perdendo parte dos pacotes). Al\u00e9m disso, \u00e9 preciso prestar aten\u00e7\u00e3o ao fato de que alguns fornecedores medem a capacidade total entre todos os pares de portas, ent\u00e3o esses n\u00fameros dizem pouco, se todo o tr\u00e1fego criptografado passar por uma \u00fanica porta.<\/p>\n
Onde a opera\u00e7\u00e3o na velocidade da linha (ou, de outra forma, sem perda de pacotes) \u00e9 particularmente importante? Em canais de alta largura de banda e alta lat\u00eancia (por exemplo, via sat\u00e9lite), onde, para manter uma alta velocidade de transmiss\u00e3o, \u00e9 necess\u00e1rio definir um grande tamanho de janela TCP, e onde perdas de pacotes reduzem drasticamente o desempenho da rede.<\/p>\n
Mas nem toda a largura de banda \u00e9 usada para transmitir dados \u00fateis. \u00c9 preciso considerar os chamados custos operacionais<\/b> (overhead) da largura de banda. Esta \u00e9 a parte da largura de banda do dispositivo de criptografia (em porcentagem ou em bytes por pacote) que \u00e9 efetivamente perdida (n\u00e3o pode ser utilizada para a transmiss\u00e3o de dados de aplica\u00e7\u00f5es). As sobrecargas ocorrem, em primeiro lugar, devido ao aumento do tamanho (acr\u00e9scimos, 'padding') do campo de dados em pacotes de rede criptografados (dependendo do algoritmo de criptografia e do modo de opera\u00e7\u00e3o). Em segundo lugar, devido ao aumento do comprimento dos cabe\u00e7alhos dos pacotes (modo de t\u00fanel, inser\u00e7\u00e3o de cabe\u00e7alho do protocolo de criptografia, inser\u00e7\u00e3o de integridade, etc., dependendo do protocolo e do modo de opera\u00e7\u00e3o do cifrador e do modo de transmiss\u00e3o) \u2014 geralmente, essas sobrecargas s\u00e3o as mais significativas, e s\u00e3o as que recebem mais aten\u00e7\u00e3o primeiro. Em terceiro lugar, devido \u00e0 fragmenta\u00e7\u00e3o dos pacotes quando ultrapassam o tamanho m\u00e1ximo do bloco de dados (MTU) (se a rede consegue dividir pacotes que excedem o MTU em dois, duplicando seus cabe\u00e7alhos). Em quarto lugar, devido \u00e0 gera\u00e7\u00e3o de tr\u00e1fego adicional de controle na rede entre dispositivos de criptografia (para troca de chaves, estabelecimento de t\u00faneis, etc.). Baixas sobrecargas s\u00e3o importantes onde a largura de banda do canal \u00e9 limitada. Isso se manifesta especialmente no tr\u00e1fego de pacotes pequenos, como o de voz \u2014 onde as sobrecargas podem<\/p>\n
Largura de banda<\/i><\/p>\n
consumir mais da metade da velocidade do canal!<\/b> \u2013 a diferen\u00e7a (em fra\u00e7\u00f5es de segundo) na lat\u00eancia da rede (tempo que os dados levam para passar da entrada da rede at\u00e9 a sa\u00edda) entre a transfer\u00eancia de dados sem criptografia de rede e com ela. De modo geral, quanto menor a lat\u00eancia da rede, mais cr\u00edtica se torna a lat\u00eancia introduzida pelos dispositivos de criptografia. A lat\u00eancia \u00e9 causada pela pr\u00f3pria opera\u00e7\u00e3o de criptografia (que depende do algoritmo de criptografia, do tamanho do bloco e do modo de opera\u00e7\u00e3o do cript\u00f3grafo, bem como da qualidade da sua implementa\u00e7\u00e3o no software), assim como pelo processamento do pacote de rede no dispositivo. A lat\u00eancia introduzida depende tanto do modo de processamento dos pacotes (em linha ou 'salvar-e-enviar'), quanto da performance da plataforma (a implementa\u00e7\u00e3o 'hardware' em FPGA ou ASIC, normalmente, \u00e9 mais r\u00e1pida do que a 'software' em CPU). A criptografia L2 quase sempre apresenta uma lat\u00eancia introduzida menor em compara\u00e7\u00e3o com a criptografia em L3 ou L4: isso se deve ao fato de que dispositivos que criptografam em L3\/L4 muitas vezes s\u00e3o realizados de forma convergente. Por exemplo, em criptografadores Ethernet de alta velocidade, implementados em FPGA e que criptografam em L2, a lat\u00eancia causada pela opera\u00e7\u00e3o de criptografia \u00e9 desprezivelmente baixa \u2013 \u00e0s vezes, ao ativar a criptografia em um par de dispositivos, a lat\u00eancia total que eles introduzem at\u00e9 diminui! Uma baixa lat\u00eancia \u00e9 importante onde \u00e9 compar\u00e1vel \u00e0s lat\u00eancias totais no canal, incluindo a lat\u00eancia de propaga\u00e7\u00e3o do sinal, que \u00e9 de aproximadamente 5 \u03bcs por quil\u00f4metro. Ou seja, pode-se afirmar que para redes de escala urbana (dezenas de quil\u00f4metros de di\u00e2metro) microsegundos podem fazer uma grande diferen\u00e7a. Por exemplo, para a replica\u00e7\u00e3o s\u00edncrona de bancos de dados, trading de alta frequ\u00eancia, ou mesmo blockchain.<\/p>\n
Lat\u00eancia introduzida<\/i><\/p>\nEscalabilidade<\/h4>\n
\nGrandes redes distribu\u00eddas podem incluir milhares de n\u00f3s e dispositivos de rede, bem como centenas de segmentos de redes locais. \u00c9 importante que as solu\u00e7\u00f5es de criptografia n\u00e3o imponham restri\u00e7\u00f5es adicionais ao tamanho e \u00e0 topologia da rede distribu\u00edda. Isso diz respeito principalmente ao n\u00famero m\u00e1ximo de endere\u00e7os de n\u00f3s e redes. Limita\u00e7\u00f5es desse tipo podem surgir, por exemplo, ao implementar uma topologia multiponto em uma rede criptografada (com conex\u00f5es protegidas independentes ou t\u00faneis) ou criptografia seletiva (por exemplo, por n\u00famero de protocolo ou VLAN). Se os endere\u00e7os de rede (MAC, IP, VLAN ID) forem utilizados como chaves em uma tabela, onde o n\u00famero de linhas \u00e9 limitado, essas restri\u00e7\u00f5es se manifestam.<\/p>\n
Al\u00e9m disso, grandes redes frequentemente possuem m\u00faltiplos n\u00edveis estruturais, incluindo a rede backbone, em cada um dos quais s\u00e3o implementados seus pr\u00f3prios esquemas de endere\u00e7amento e pol\u00edticas 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\u00e7\u00e3o de rotas. A fim de n\u00e3o prejudicar a constru\u00e7\u00e3o dessas redes, os dispositivos de criptografia devem lidar corretamente com esses quadros (ou seja, neste sentido, escalabilidade significar\u00e1 compatibilidade \u2013 que ser\u00e1 abordada adiante).<\/p>\n
Flexibilidade<\/h4>\n \nAqui estamos falando sobre o suporte a diferentes configura\u00e7\u00f5es, esquemas de conex\u00e3o, topologias e mais. Por exemplo, para redes comutadas baseadas em tecnologias Carrier Ethernet, isso significa suporte a diferentes tipos de conex\u00f5es virtuais (E-Line, E-LAN, E-Tree), diferentes tipos de servi\u00e7os (tanto por portas quanto por VLAN) e diferentes tecnologias de transporte (que j\u00e1 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\u00faneis separados para diferentes VLANs e permitir a entrega n\u00e3o ordenada de pacotes dentro de um canal protegido. A capacidade de escolher diferentes modos de opera\u00e7\u00e3o de criptografia (inclusive com autentica\u00e7\u00e3o de conte\u00fado ou sem) e diferentes modos de transmiss\u00e3o de pacotes permite equilibrar a resist\u00eancia e o desempenho, dependendo das condi\u00e7\u00f5es atuais.<\/p>\n
O suporte a redes privadas, cujo equipamento pertence a uma \u00fanica organiza\u00e7\u00e3o (ou \u00e9 alugado por ela), e a redes operacionais, cujos diferentes segmentos est\u00e3o sob a responsabilidade de diferentes empresas, tamb\u00e9m \u00e9 importante. \u00c9 prefer\u00edvel que a solu\u00e7\u00e3o permita a gest\u00e3o tanto por recursos pr\u00f3prios quanto por uma organiza\u00e7\u00e3o externa (no modelo de servi\u00e7o gerenciado). Em redes operacionais, outra fun\u00e7\u00e3o importante \u00e9 o suporte \u00e0 multiten\u00e2ncia (uso compartilhado por diferentes clientes), na forma de isolamento criptogr\u00e1fico entre clientes (assinantes), cujo tr\u00e1fego passa pelo mesmo conjunto de dispositivos de criptografia. Normalmente, isso requer o uso de conjuntos distintos de chaves e certificados para cada cliente.<\/p>\n
Se o dispositivo \u00e9 adquirido para um cen\u00e1rio espec\u00edfico, todas essas funcionalidades podem n\u00e3o ser t\u00e3o importantes \u2013 \u00e9 necess\u00e1rio apenas garantir que o dispositivo suporte o que \u00e9 necess\u00e1rio no momento. Por\u00e9m, se a solu\u00e7\u00e3o \u00e9 comprada para o futuro, para atender tamb\u00e9m a cen\u00e1rios futuros, e \u00e9 escolhida como padr\u00e3o corporativo, a flexibilidade ser\u00e1 bem-vinda \u2013 especialmente considerando as limita\u00e7\u00f5es de interoperabilidade entre dispositivos de diferentes fornecedores (sobre isso adiante).<\/p>\n
Simplicidade e comodidade<\/h4>\n \nA facilidade de manuten\u00e7\u00e3o \u00e9 um conceito multifatorial. Pode-se dizer aproximadamente que s\u00e3o os custos totais de tempo que especialistas de determinada qualifica\u00e7\u00e3o precisam para manter a solu\u00e7\u00e3o em diferentes etapas do seu ciclo de vida. Se n\u00e3o h\u00e1 custos e a instala\u00e7\u00e3o, configura\u00e7\u00e3o e opera\u00e7\u00e3o s\u00e3o totalmente autom\u00e1ticas, os custos s\u00e3o zero e a conveni\u00eancia \u00e9 absoluta. Claro, no mundo real isso n\u00e3o ocorre. Uma aproxima\u00e7\u00e3o razo\u00e1vel \u00e9 o modelo \u00abn\u00f3 na linha\u00bb<\/b> (bump-in-the-wire), ou conex\u00e3o transparente, na qual a adi\u00e7\u00e3o e remo\u00e7\u00e3o de dispositivos de criptografia n\u00e3o requer altera\u00e7\u00f5es manuais ou autom\u00e1ticas na configura\u00e7\u00e3o da rede. Isso simplifica a manuten\u00e7\u00e3o da solu\u00e7\u00e3o: \u00e9 poss\u00edvel ativar e desativar o recurso de criptografia com tranquilidade e, se necess\u00e1rio, simplesmente \"contornar\" o dispositivo com um cabo de rede (ou seja, conectar diretamente as portas do equipamento de rede \u00e0s quais ele estava conectado). No entanto, h\u00e1 um ponto negativo \u2013 um invasor pode fazer o mesmo. Para implementar o princ\u00edpio do \"n\u00f3 no fio\", \u00e9 preciso considerar o tr\u00e1fego n\u00e3o apenas camada de dados<\/b>, mas tamb\u00e9m camadas de controle e gerenciamento<\/b> \u2013 os dispositivos devem ser transparentes para eles. Portanto, esse tr\u00e1fego s\u00f3 pode ser criptografado quando na rede entre os dispositivos de criptografia n\u00e3o h\u00e1 destinat\u00e1rios para esses tipos de tr\u00e1fego, pois se ele for descartado ou criptografado, a configura\u00e7\u00e3o da rede pode mudar ao ativar ou desativar a criptografia. O dispositivo de criptografia pode ser transparente tamb\u00e9m para sinaliza\u00e7\u00f5es no n\u00edvel f\u00edsico. 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\u00e7\u00e3o do sinal.<\/p>\n
Apoio \u00e0 separa\u00e7\u00e3o de poderes entre os departamentos de seguran\u00e7a da informa\u00e7\u00e3o e TI, particularmente o departamento de rede, tamb\u00e9m \u00e9 importante. A solu\u00e7\u00e3o de criptografia deve apoiar o modelo de gerenciamento de acesso e auditoria adotado pela organiza\u00e7\u00e3o. A necessidade de intera\u00e7\u00e3o entre diferentes departamentos para a realiza\u00e7\u00e3o de opera\u00e7\u00f5es rotineiras deve ser minimizada. Portanto, o benef\u00edcio em termos de conveni\u00eancia reside em dispositivos especializados que apoiam exclusivamente fun\u00e7\u00f5es de criptografia e s\u00e3o o mais transparentes poss\u00edvel para as opera\u00e7\u00f5es de rede. Em termos simples, os funcion\u00e1rios da equipe de seguran\u00e7a da informa\u00e7\u00e3o n\u00e3o devem ter motivos para contatar os \"especialistas em redes\" para alterar as configura\u00e7\u00f5es da rede. E, por sua vez, estes n\u00e3o devem ter a necessidade de modificar as configura\u00e7\u00f5es de criptografia durante a manuten\u00e7\u00e3o da rede.<\/p>\n
Outro fator \u00e9 a capacidade e a conveni\u00eancia das ferramentas de gerenciamento. Elas devem ser intuitivas, l\u00f3gicas, proporcionar importa\u00e7\u00e3o e exporta\u00e7\u00e3o de configura\u00e7\u00f5es, automa\u00e7\u00e3o, etc. \u00c9 importante observar quais op\u00e7\u00f5es de gerenciamento est\u00e3o dispon\u00edveis (geralmente um ambiente de gerenciamento pr\u00f3prio, uma interface web e linha de comando) e quais funcionalidades est\u00e3o inclu\u00eddas em cada uma (podem haver restri\u00e7\u00f5es). Uma fun\u00e7\u00e3o importante \u00e9 o suporte de gerenciamento fora de banda<\/b> (out-of-band), ou seja, atrav\u00e9s de uma rede de gerenciamento dedicada, e de gerenciamento em banda<\/b> (in-band), ou seja, atrav\u00e9s da rede comum pela qual o tr\u00e1fego \u00fatil \u00e9 transmitido. As ferramentas de gerenciamento devem sinalizar todas as situa\u00e7\u00f5es an\u00f4malas, incluindo incidentes de seguran\u00e7a da informa\u00e7\u00e3o (IB). Opera\u00e7\u00f5es rotineiras e repetitivas devem ser realizadas automaticamente. Isso se aplica principalmente ao gerenciamento de chaves. Elas devem ser geradas\/distribu\u00eddas automaticamente. O suporte a PKI \u00e9 uma grande vantagem.<\/p>\nCompatibilidade<\/h4>\n
\nIsso se refere \u00e0 compatibilidade do dispositivo com os padr\u00f5es de rede. E n\u00e3o se trata apenas de padr\u00f5es industriais aceitos por organiza\u00e7\u00f5es reconhecidas, como o IEEE, mas tamb\u00e9m de protocolos propriet\u00e1rios de l\u00edderes do setor, como a Cisco. Existem duas maneiras principais de garantir a compatibilidade: ou atrav\u00e9s da transpar\u00eancia<\/b>, ou atrav\u00e9s do suporte expl\u00edcito<\/b> aos protocolos (quando o dispositivo de criptografia se torna um dos n\u00f3s da rede para um determinado protocolo e processa o tr\u00e1fego de controle desse protocolo). A plenitude e a corre\u00e7\u00e3o na implementa\u00e7\u00e3o dos protocolos de controle dependem da compatibilidade com as redes. \u00c9 importante o apoio a diferentes variantes do n\u00edvel PHY (velocidades, meios de transmiss\u00e3o, esquemas de codifica\u00e7\u00e3o), quadros Ethernet de diferentes formatos com qualquer MTU, e diferentes protocolos de servi\u00e7o L3 (principalmente da fam\u00edlia TCP\/IP).<\/p>\n
A transpar\u00eancia \u00e9 garantida por meio de mecanismos de muta\u00e7\u00e3o (mudan\u00e7a tempor\u00e1ria do conte\u00fado dos cabe\u00e7alhos abertos no tr\u00e1fego entre os criptografadores), omiss\u00e3o (quando pacotes individuais permanecem n\u00e3o criptografados) e desvio do in\u00edcio da criptografia (quando campos normalmente criptografados dos pacotes n\u00e3o s\u00e3o criptografados).<\/p>\n
Como \u00e9 garantida a transpar\u00eancia<\/i><\/p>\n
Portanto, sempre verifique como o suporte a um determinado protocolo \u00e9 garantido. Muitas vezes, o suporte em modo transparente \u00e9 mais conveniente e confi\u00e1vel.<\/p>\n
Interoperabilidade<\/h4>\n \nEsta tamb\u00e9m \u00e9 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\u00e7\u00e3o dos protocolos de criptografia. N\u00e3o h\u00e1 padr\u00f5es de criptografia amplamente reconhecidos no L1.<\/p>\n
Para criptografia L2 em redes Ethernet, existe o padr\u00e3o 802.1ae (MACsec), mas ele n\u00e3o utiliza criptografia de ponta a ponta<\/b> (end-to-end), mas sim criptografia entre portas<\/b>, chamada de criptografia hop-by-hop, e na sua edi\u00e7\u00e3o original era inadequada para uso em redes distribu\u00eddas, portanto surgiram suas extens\u00f5es propriet\u00e1rias que superam essa limita\u00e7\u00e3o (naturalmente, \u00e0 custa da interoperabilidade com equipamentos de outros fabricantes). De fato, em 2018, o padr\u00e3o 802.1ae recebeu suporte para redes distribu\u00eddas, mas ainda n\u00e3o h\u00e1 suporte para os conjuntos de algoritmos de criptografia \u0413\u041e\u0421\u0422. Assim, os protocolos de criptografia L2 propriet\u00e1rios e n\u00e3o padronizados geralmente se destacam por maior efici\u00eancia (particularmente, menores sobrecargas de largura de banda) e flexibilidade (capacidade de troca de algoritmos e modos de criptografia).<\/p>\n
Em n\u00edveis mais altos (L3 e L4), h\u00e1 padr\u00f5es reconhecidos, principalmente IPsec e TLS, mas aqui tamb\u00e9m n\u00e3o \u00e9 t\u00e3o simples. O fato \u00e9 que cada um desses padr\u00f5es \u00e9 um conjunto de protocolos, cada um com diferentes vers\u00f5es e extens\u00f5es obrigat\u00f3rias ou n\u00e3o obrigat\u00f3rias para implementa\u00e7\u00e3o. Al\u00e9m disso, alguns fabricantes preferem aplicar seus pr\u00f3prios protocolos de criptografia tamb\u00e9m no L3\/L4. Portanto, na maioria dos casos, n\u00e3o se deve esperar plena interoperabilidade, mas \u00e9 importante que haja ao menos intera\u00e7\u00e3o entre diferentes modelos e diferentes gera\u00e7\u00f5es de um mesmo fabricante.<\/p>\n
Confiabilidade<\/h4>\n \nPara comparar diferentes solu\u00e7\u00f5es, pode-se usar o tempo m\u00e9dio de falha ou o coeficiente de disponibilidade. Se esses n\u00fameros n\u00e3o estiverem dispon\u00edveis (ou se n\u00e3o houver confian\u00e7a neles), pode-se fazer uma compara\u00e7\u00e3o qualitativa. A vantagem ser\u00e1 para dispositivos com gerenciamento f\u00e1cil (menor risco de erros na configura\u00e7\u00e3o), para criptografadores especializados (pelo mesmo motivo), bem como para solu\u00e7\u00f5es com o menor tempo de detec\u00e7\u00e3o e corre\u00e7\u00e3o de falhas, incluindo meios de reserva quente de n\u00f3s e dispositivos inteiros.<\/p>\n
Custo<\/h4>\n \nQuanto ao custo, assim como na maioria das solu\u00e7\u00f5es de TI, faz sentido comparar o custo total de propriedade. Para essa avalia\u00e7\u00e3o, n\u00e3o \u00e9 necess\u00e1rio reinventar a roda, basta usar qualquer m\u00e9todo apropriado (por exemplo, da Gartner) e qualquer calculadora (como a que j\u00e1 \u00e9 utilizada na organiza\u00e7\u00e3o para calcular o TCO). \u00c9 evidente que, para uma solu\u00e7\u00e3o de criptografia de rede, o custo total de propriedade \u00e9 composto por custos diretos<\/b> com a compra ou aluguel da pr\u00f3pria solu\u00e7\u00e3o, a infraestrutura para abrigar o equipamento e os custos com implementa\u00e7\u00e3o, administra\u00e7\u00e3o e manuten\u00e7\u00e3o (n\u00e3o importa se com recursos pr\u00f3prios ou na forma de servi\u00e7os terceirizados), al\u00e9m de custos indiretos<\/b> provocados pela inatividade da solu\u00e7\u00e3o (devido \u00e0 perda de produtividade dos usu\u00e1rios finais). Provavelmente, h\u00e1 apenas um detalhe. O impacto da performance da solu\u00e7\u00e3o pode ser contabilizado de diferentes maneiras: ou como custos indiretos, resultantes da diminui\u00e7\u00e3o da produtividade, ou como custos diretos \"virtuais\" com a compra\/moderniza\u00e7\u00e3o e manuten\u00e7\u00e3o de recursos de rede que compensam a diminui\u00e7\u00e3o da performance da rede devido \u00e0 ado\u00e7\u00e3o da criptografia. De qualquer forma, os custos que s\u00e3o dif\u00edceis de calcular com precis\u00e3o suficiente devem ser \"exclu\u00eddos\" da conta: assim haver\u00e1 mais confian\u00e7a no valor final. E, como de costume, a compara\u00e7\u00e3o de diferentes dispositivos com base no TCO deve ser feita considerando cen\u00e1rios espec\u00edficos de uso - reais ou t\u00edpicos.<\/p>\nResili\u00eancia<\/h4>\n
\nE a \u00faltima caracter\u00edstica \u00e9 a resist\u00eancia da solu\u00e7\u00e3o. Na maioria dos casos, a resist\u00eancia pode ser avaliada apenas qualitativamente, comparando diferentes solu\u00e7\u00f5es entre si. Devemos lembrar que os dispositivos de criptografia s\u00e3o n\u00e3o apenas meios, mas tamb\u00e9m objetos de prote\u00e7\u00e3o. Eles podem estar sujeitos a diversas amea\u00e7as. As amea\u00e7as \u00e0 privacidade, \u00e0 reprodu\u00e7\u00e3o e \u00e0 modifica\u00e7\u00e3o de mensagens est\u00e3o em primeiro plano. Essas amea\u00e7as podem ser ativadas atrav\u00e9s de vulnerabilidades do algoritmo de criptografia ou de modos espec\u00edficos, assim como vulnerabilidades nos protocolos de criptografia (incluindo nas etapas de estabelecimento de conex\u00e3o e gera\u00e7\u00e3o\/distribui\u00e7\u00e3o de chaves). A vantagem ser\u00e1 das solu\u00e7\u00f5es que permitem a troca do algoritmo de criptografia ou a altera\u00e7\u00e3o do modo de cifragem (pelo menos atrav\u00e9s de uma atualiza\u00e7\u00e3o de firmware), das solu\u00e7\u00f5es que oferecem a criptografia mais completa, ocultando do invasor n\u00e3o apenas os dados do usu\u00e1rio, mas tamb\u00e9m informa\u00e7\u00f5es de endere\u00e7o e outras informa\u00e7\u00f5es operacionais, assim como aquelas que n\u00e3o apenas criptografam, mas tamb\u00e9m protegem as mensagens contra reprodu\u00e7\u00e3o e modifica\u00e7\u00e3o. Para todos os algoritmos modernos de criptografia, assinatura digital, gera\u00e7\u00e3o de chaves e outros que est\u00e3o estabelecidos em normas, a resist\u00eancia pode ser considerada igual (caso contr\u00e1rio, pode-se simplesmente se perder na complexidade da criptografia). Devem ser, necessariamente, os algoritmos GOST? Aqui tudo \u00e9 simples: se o cen\u00e1rio de aplica\u00e7\u00e3o exigir certifica\u00e7\u00e3o da FSB para SKZI (o que na R\u00fassia geralmente \u00e9 o caso), para a maioria dos cen\u00e1rios de criptografia em rede, ent\u00e3o escolhemos apenas entre os certificados. Se n\u00e3o, n\u00e3o faz sentido excluir dispositivos n\u00e3o certificados da considera\u00e7\u00e3o.<\/p>\n
Outra amea\u00e7a \u00e9 a amea\u00e7a de invas\u00e3o, acesso n\u00e3o autorizado aos dispositivos (incluindo atrav\u00e9s de acesso f\u00edsico de fora e de dentro do gabinete). A amea\u00e7a pode se concretizar atrav\u00e9s de
Finalmente, outro tipo de amea\u00e7a s\u00e3o os erros na configura\u00e7\u00e3o e opera\u00e7\u00e3o, o fator humano em sua ess\u00eancia. Aqui se manifesta mais uma vantagem dos criptografadores especializados em rela\u00e7\u00e3o \u00e0s solu\u00e7\u00f5es convergentes, que frequentemente s\u00e3o voltadas para \"especialistas em redes\" experientes e podem causar dificuldades para especialistas de ciberseguran\u00e7a mais generalistas.<\/p>\n
Resumo<\/h4>\n \nBasicamente, poder\u00edamos sugerir um indicador integral para comparar diferentes dispositivos, algo como<\/p>\n
$$display$$K_j=\u2211p_i r_{ij}$$display$$<\/p>\n
\nonde p \u00e9 o peso do indicador, e r \u00e9 a classifica\u00e7\u00e3o do dispositivo com base nesse indicador, podendo qualquer uma das caracter\u00edsticas listadas acima ser quebrada em indicadores \"at\u00f4micos\". Essa f\u00f3rmula poderia ser \u00fatil, por exemplo, ao comparar propostas de licita\u00e7\u00e3o com regras previamente acordadas. Mas tamb\u00e9m podemos nos contentar com uma tabela simples do tipo<\/p>\n
Caracter\u00edsticas
Largura de banda
+++<\/p>\n
Custos adicionais
+++<\/p>\n
Lat\u00eancia
++<\/p>\n
Escalabilidade
+++<\/p>\n
Flexibilidade
+<\/p>\n
Interoperabilidade
+<\/p>\n
Compatibilidade
+++<\/p>\n
Simplicidade e comodidade
++<\/p>\n
Resili\u00eancia
++<\/p>\n
Custo
+<\/p>\n
Resili\u00eancia
+++<\/p>\n
\nFico \u00e0 disposi\u00e7\u00e3o para responder perguntas e cr\u00edticas construtivas.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