Tenho examinado vários pacotes de prevenção contra vazamento/perda de dados, mas, em sua documentação, não consigo descobrir como eles tratam o HTTPS.
Um dos ‘vetores de vazamento’ é o envio de informações para webapps através de HTTPS. Nesse caso, a única maneira de detectar o vazamento seria descriptografá-lo.
Mas, para fazer isso, seria necessário se passar por um servidor remoto, usando certificados falsos, como um ataque man-in-the-middle. Para evitar que os usuários suspeitem ou reclamem, acho que a corporação precisa inserir seu certificado como uma CA válida nos navegadores dos dispositivos de propriedade da empresa.
Minhas perguntas são:
- Alguém tem experiência em primeira mão nesse tipo de cenário? Você pode nos dizer como você o implementou?
- Estou certo ou existe outra maneira de gerenciar HTTPS (por exemplo, detectando os dados em uso no nível da área de trabalho com um agente)?
Responder1
Isso não é "como" um homem no meio do ataque, É um homem no meio do ataque.
Você o implementa usando um servidor proxy que substituirá seu próprio certificado pelo certificado remoto. No processo, o navegador exibirá erros sobre o certificado não ser válido. Esse é o ponto por trás do HTTPS e da certificação. Portanto, se você tiver um usuário experiente, ele saberá que você está interceptando as informações.
Você pode usar proxies que apenas registram a atividade de uma pessoa para poder registrar o que está acontecendo e onde ela está navegando, mas, na verdade, se você estiver implementando medidas draconianas para evitar opossibilidadeque alguém está roubando suas informações, você provavelmente está criando um local de trabalho que promove o tipo de atitude que justifica, para o funcionário, fazer isso em primeiro lugar. E você também terá que ter políticas de demissão de RH para telefones celulares (gravação com câmeras), drives USB e talvez garantir que eles não memorizem coisas também.
De qualquer forma, não há uma maneira "simples" de quebrar o monitoramento HTTPS sem que ele seja descoberto, a menos que você simplesmente bloqueie o acesso de saída a essa porta com uma regra de firewall ou filtro de proxy. Caso contrário, todo o objetivo do HTTPS será inútil.
Responder2
Mas, para fazer isso, teria que se passar pelo servidor remoto, usando certificados falsos
Sim - você não apenas precisaria de um certificado assinado por uma autoridade aceitável para o cliente, mas também envenenaria o DNS do cliente ou redirecionaria o fluxo de pacotes IP.
Suspeito que seja tecnicamente possível implementar um proxy HTTPS que geraria um certificado instantaneamente assinado por uma CA local e faria proxy das solicitações usando-o, mas é muito difícil.
Se você está preocupado com o vazamento de dados por HTTPS, simplesmente não permita que seus usuários acessem HTTPS.
Isso não resolve o problema de eles escreverem coisas em pedaços de papel.
A única solução prática é manter uma boa trilha de auditoria – de preferência com potes de mel.
Responder3
O problema do https é realmente resolvido pelo tipo de solução MiM. Normalmente, isso significa que um proxy está capturando sessões https de saída e as veicula ao usuário assinado por seu próprio certificado SSL, enquanto conduz as comunicações https para o mundo externo por conta própria.
A solução myDLP gratuita pode fazer isso usando sua própria configuração do squid, e as soluções mais complexas, como Websense e Symantec, iirc fazem a mesma coisa, embora um pouco mais poderosa (balanceamento de carga entre esses proxies, gerenciamento de certificados refinado, etc.). )