As 6 principais perguntas que devem ser feitas ao selecionar soluções de proteção SSL

0
265

This post is also available in: Inglês Francês Alemão Italiano Espanhol Russo

Atualmente, 99% do tráfego da Internet é criptografado. Com os recentes regulamentos do GDPR, as organizações são forçadas a usar HTTPS, tornando a comunicação criptografada o método padrão. Embora a criptografia de tráfego seja importante para manter a segurança e a privacidade do usuário, ela também abre a porta para uma nova geração de ataques DDoS agressivos que podem exigir até 15 vezes mais recursos do servidor de destino do que o host solicitante.

A identificação de tráfego mal-intencionado dentro do tráfego criptografado é a parte complicada. É equivalente a encontrar uma agulha num palheiro, e por isso é um método vantajoso para invasores, pois coloca uma tensão computacional significativa na rede e nas infraestruturas de aplicações que eles visam.

Por fim, não existe uma solução única para a proteção SSL. Cada organização tem suas próprias prioridades, necessidades comerciais, sensibilidades e necessidades de privacidade. No entanto, ao selecionar uma solução de proteção SSL, há algumas perguntas de orientação que devem ser consideradas para ajudar você a encontrar a melhor solução para sua organização.

Une image contenant texte, rideau, corbeille

Description générée automatiquement

1. Você tem acesso ao certificado SSL?

No caso de algumas organizações, não há acesso ao certificado. Os motivos podem ser restrições de regulamentações ou privacidade, preocupações com a arquitetura de rede e segurança, ou modelos de Segurança como serviço (SaaS). Quando se trata de Managed Security Service Provider (MSSP) ou de serviços de depuração, o certificado do cliente final pode não estar disponível.

Outras organizações que tenham acesso ao certificado SSL podem descriptografar o tráfego SSL e obter visibilidade do tráfego.

2. Se houver acesso ao certificado, onde o tráfego deve ser descriptografado?

Ter acesso ao certificado é uma coisa; a próxima consideração diz respeito à topologia da rede e à segurança desejada.

Em algumas topologias de rede, a descriptografia do tráfego SSL é feita mais perto dos servidores e, em algumas implantações, é preferível descriptografar o tráfego mais cedo e eliminar as ameaças logo no início. Quando a descriptografia é realizada mais perto do servidor, a proteção normalmente depende de soluções de proteção de aplicações. Neste caso, deve-se ter em mente os riscos adicionais, como ataques DDoS, que são mais bem mitigados no início da rede.

3. Se houver acesso ao certificado, quando o tráfego deve ser descriptografado?

A descriptografia constante de todo o tráfego SSL permite visibilidade total, mas tem o custo de computação e latência. Para alguns, não é possível aumentar a latência, o que significa que a descriptografia constante de todas as sessões não é uma opção. As organizações preferem uma solução de segurança que descriptografe apenas sob certas condições, somente algumas das sessões ou, em alguns cenários, que não realize descriptografia alguma. Descriptografar menos tráfego SSL é a chave para alcançar a segurança SSL ao mesmo tempo em que se equilibra a latência e a experiência legítima do usuário.

[Você também pode se interessar por:Detectando e mitigando inundações de HTTPS… sem chaves de descriptografia]

4. Se houver acesso ao certificado, qual parte da sessão deve ser descriptografada?

Da mesma forma, para determinar quando descriptografar, você pode querer selecionar o nível de descriptografia. Descriptografar apenas parte da sessão SSL em vez da sessão inteira tem alto valor para a proteção contra ataques específicos. Assim como a flexibilidade de quando descriptografar sessões SSL, o nível de descriptografia pode ajudar ainda mais as organizações a equilibrar entre os níveis de segurança desejados e uma experiência de usuário otimizada.

5. Seus serviços são excessivamente sensíveis à latência?

A descriptografia de todo o tráfego SSL oferece visibilidade total, mas envolve sobrecarga de computação significativa, aumentando assim a latência do serviço. Existem organizações e serviços que não podem arcar com a latência adicional da descriptografia SSL. Essas organizações precisarão de uma solução SSL que não exija qualquer descriptografia ou descriptografia mínima, somente sob certas condições e apenas parte das sessões.

6. Você usa redes de distribuição de conteúdo (Content Delivery Networks, CDNs) para seus serviços?

Ao usar uma CDN, ela repassa o tráfego em nome da organização. Neste caso, o endereço IP real pode ser encontrado apenas dentro dos cabeçalhos HTTP criptografados, portanto, não há como saber quem é o cliente real sem descriptografar todo o tráfego SSL. Com CDNs, a solução de segurança deve descriptografar sessões SSL completas, identificar o cliente real nos cabeçalhos HTTP e aplicar medidas de segurança direcionadas.

Principais considerações

De acordo com o Relatório trimestral de DDoS do 2º trimestre de 2021 da Radware, os ataques criptografados na web representam 20% do volume total informado para todos os eventos mal-intencionados do trimestre. Uma coisa é certa, as soluções tradicionais não oferecem as proteções necessárias.  Soluções baseadas em rede, como detectores Netflow, são cegas para o tráfego SSL, tornando a rede em que operam vulnerável a ataques criptografados.

Se você estiver usando uma Rede de distribuição de conteúdo (CDNs), ela repassa o tráfego em nome da organização. O endereço IP real só pode ser encontrado dentro dos cabeçalhos HTTP criptografados, portanto, não há como saber quem é o cliente real sem descriptografar todo o tráfego SSL.

Outras soluções exigem a descriptografia completa de pacotes HTTPS, prejudicando a privacidade do usuário, aumentando a latência e exigindo um processo caro de gerenciamento de chaves.

[Gostou desta publicação? Inscreva-se agora para receber o conteúdo mais recente da Radware na sua caixa de entrada, toda semana, além de acesso exclusivo ao conteúdo premium da Radware.]

LEAVE A REPLY

Please enter your comment!
Please enter your name here