[GTER] LGPD

Luiz Fernando Mizael Meier lfmmeier at gmail.com
Tue Dec 22 13:55:41 -03 2020


Por fim, faltou o questionamento: Onde e como se colocar nessa seara,
protegendo o seu ambiente e dentro da lei?

Em ter., 22 de dez. de 2020 às 13:53, Luiz Fernando Mizael Meier <
lfmmeier at gmail.com> escreveu:

> Boa Tarde!
>
> Usando o quepe de administrador de firewalls, e não de rede, achei a
> discussão deveras interessante. Alguns pontos:
>
> 1) Dalton, Eu não tinha conhecimento de que a prática de inspeção SSL (em
> que interceptamos, olhamos, e depois fechamos com outro certificado),
> configura crime. Poderia, por gentileza, indicar a fonte da informação?
> 2) O lance de só controlar sites e acessos devidos/indevidos só baseado no
> SNI conforme os colegas descreveram, infelizmente, não atende mais
> (unicamente) quando pensamos em proteção. URL filtering ainda é uma das
> metodologias mais usadas para bloqueios simples por categorias e/ou regex.
> Para o chefe ficar feliz que o juquinha não vai mais acessar o pornhub
> durante o horário de expediente, funciona, mas quando vamos mais à frente,
> as coisas se complicam bastante.
> Exemplo: como permitir que seu usuário não use o Gmail, mas possa usar
> outra solução do Google, sendo que ambos possuem a mesma URL? Vários
> produtos do Google funcionam com google.com/PRODUTO. Nem sempre só a URL
> é suficiente. Hoje queremos saber aplicações.
> 3) Falando sobre a inspeção SSL, ela é hoje parte fundamental para
> conseguirmos classificar aplicações. Sem ela não consigo classificar
> produtos do Google, como no item 2, ou pegar um cara usando UltraSurf
> dentro da minha rede. Nós seguimos algumas diretrizes quanto à privacidade,
> como não inspecionar conteúdos de saúde e financeiros, por exemplo. Isso
> sem contar a ajuda da inspeção quanto à visibilidade de vulnerabilidades
> pela sua engine de IPS.
> 4) Douglas, pode explicar mais sobre essa sua questão a respeito da
> efetividade do uso do proxy explícito? Você diz, se entendi, que a
> efetividade de um proxy transparente, neste caso, é pior que um proxy
> explícito? Eu questiono (o uso, pelo menos) porque, particularmente, acho o
> proxy explícito pior de gerenciar, quando pensamos em configurações de
> browsers, GPOs e etc.
>
> Vou levar essa discussão internamente.
>
> Att,
>
> Em qui., 17 de dez. de 2020 às 19:06, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
>> Ratifico sua opinião Danton!
>>
>> Durante um tempo fiz alguns deploys de soluções de Data Loss Prevention.
>> Isso ainda no tempo que HTTPS era menos de 10% da navegação.
>>
>> Do ponto de vista técnico:
>>  - Durante um tempo a solução dourada era a interceptação SSL.
>>    Que o TLS1.3 e também o QUIC acabaram de matar nos últimos 2 anos.
>>  - Depois veio a análise de DNS queries.
>>    Que também está morrendo com o DoT e DoH.
>>  - Agora a moda é a tal I.A. de classificação de destino.
>>    Que também já está morrendo.
>>
>> Interessantemente, já naquele tempo(acho que uns 15 anos atrás) as
>> documentações daquele vendor diziam que a única forma efetiva de assegurar
>> DLP é com proxy explícito.
>> Eu relutei em aceitar isso durante um tempo... E hoje já aceitei!
>> De fato, do ponto de vista técnico, a única forma de uma empresa assegurar
>> DLP é com proxy explícito, e bloqueio geral de todo o resto.
>>
>> Porém, não é só o aspecto técnico que tem que ser considerado!
>> (P.S.:  Não confundir esse cenário, de relação de trabalho, com a relação
>> de consumo.)
>> A parte de prevenção legal é BEM IMPORTANTE E PESADA.
>> Um dos custos altos do processo de implantação da solução de DLP era uma
>> consultoria jurídica, mormente voltada a vertical trabalhista.
>> Termos de uso dos equipamentos e rede da empresa era bem profunda.
>>
>>
>> Naquela época eu inclusive acompanhei uma situação delicada...
>> Onde em uma empresa que contratou a solução de DLP, este mecanismo
>> identificou conteúdo ilegal no e-mail pessoal(webmail) de um funcionário.
>> Foi um problema SÉRISSIMO!
>> Pois, no entendimento da consultoria jurídica, depois de o mecanismo ter
>> identificado e notificado a empresa, esta passou a ser obrigada a
>> notificar
>> as autoridades competentes, sob-pena de a falta de notificação poder ser
>> encarada com cumplicidade.
>>
>>
>>
>>
>>
>> Em qui., 17 de dez. de 2020 às 16:04, Danton Nunes <
>> danton.nunes at inexo.com.br> escreveu:
>>
>> > On 17/12/2020 13:11, Edvan Lima wrote:
>> > > Estava lendo o artigo
>> > >
>> >
>> https://ftp.registro.br/pub/gter/gter49/03-LGPD-IncidentesDeSeguranca.pdf
>> > >
>> > > Com LGPD, parei de usar proxy na rede, pelo que li,  analisar o
>> tráfego
>> > > criptografado está quebrando a privacidade dos usuários, isso pode dar
>> > > problema pra gente.
>> > >
>> > > Porém seria uma mão de duas vias, afinal precisamos garantir  tudo
>> que um
>> > > usuário fizer na nossa rede, somos responsáveis e se algo acontecer,
>> > temos
>> > > como saber e mostrar quem foi ... não podemos por exemplo, permitir
>> que
>> > um
>> > > site pornográfico seja visualizado.
>> >
>> > isso é política da empresa, não lei. uma política bem naïve, se me
>> > permite,
>> > porque o protocolo IP não tem um "porn bit" que permite de maneira
>> > inequívoca
>> > distinguir o que é pornografia do que não é. (se não me engano já foi
>> > assunto de
>> > uma das RFCs de primeiro de abril).
>> >
>> > se a sua filtragem se limitar às URLs e não invadir o conteúdo, tudo
>> bem,
>> > continue usando o proxy para bloquear o que der na telha dos teus
>> chefes,
>> > mas se
>> > for fuçar o conteúdo de tráfego https, provavelmente estará violando não
>> > só a
>> > LGPD mas a lei penal, pois falsificar certificados e atuar como
>> > man-in-the-middle é crime.
>> >
>> > hoje praticamente todo navegador envia cabeçalhos SNI (nada a ver com o
>> > extinto
>> > Serviço Nacional de Informações, trata-se de Server Name Indication,
>> > RFC-4366)
>> > que transporta pelo menos o nome do servidor remoto em texto claro. Essa
>> > extensão permite criar sites virtuais em https baseados em nome e não
>> > somente em
>> > endereços IP, como nos velhos tempos e, obviamente, permite ao proxy
>> negar
>> > conexão a sites que se encontrem em uma lista negra.
>> >
>> > > *Se não posso usar proxy (squid) na rede, qual seria outra solução que
>> > está
>> > > dentro da LGPD?*
>> >
>> > minha opinião (de engenheiro, não de advogado): você pode usar proxies,
>> > desde
>> > que não falsifique certificados para analisar o conteúdo de transações
>> que
>> > deveriam ter criptografia fim-a-fim. como teu artefato não sabe
>> distinguir
>> > uma
>> > página de pornografia de uma transação bancária, veja o lamaçal em que
>> > você pode
>> > estar se metendo cacheando os dados bancários de alguém.
>> >
>> > não sei que influência você tem na elaboração da política de uso da
>> > empresa, mas
>> > se puder, recomende não imporem regras cuja implementação possa violar a
>> > lei. Se
>> > a corda quebrar, adivinha para que lado quebra.
>> >
>> > -- Danton
>> > --
>> > gter list    https://eng.registro.br/mailman/listinfo/gter
>> >
>>
>>
>> --
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>


More information about the gter mailing list