Proteção de dados x segurança da informação: Qual é a diferença? (Conceitos)

 

  Bom, conforme mencionei acima, a proteção de dados tem por objeto proteger os dados relativos a pessoa natural, com um foco na privacidade, no direito à individualidade.

  A título de curiosidade, esse conceito não é exclusivo da LGPD. É o mesmo adotado no GDPR – Regulamento Geral sobre a Proteção de Dados, da União Europeia [Artigo 4º (“Definições”), (1), página 33 no link acima], bem como pelo NIST – National Institute of Standards and Technology, dos EUA, como se fosse o “Inmetro” norte-americano, que traz padrões de qualidade especialmente voltados à tecnologia e ciência – padrões adotados inclusive pelo FBI. Vocês podem verificar a definição de “personally identifiable information” neste link aqui, que é o glossário do NIST.

Segurança da informação: Vulnerabilidade, ameaça, risco, incidente, dano

 

  É importante lembrar que, mesmo que a sua casa/apartamento tenha grade, portão, portaria 24h, câmeras de segurança, ainda é possível que uma pessoa mal-intencionada entre, certo?

  O mesmo ocorre com sistemas. Por isso, estamos falando em prevenção, e não em impossibilitar ataques, blindar sistemas, impedir fraudes. Não existe 100% quando falamos de segurança. Lembre-se disso.

  Quando analisarmos o caso concreto a seguir o primeiro passo será identificar quais são as vulnerabilidades encontradas em determinado servidor ou sistema operacional, ou seja, quais portas estão abertas. E assim por diante, identificando cada um dos cinco itens que foram listados acima, para então chegar numa resposta (ou quase isso) sobre as melhores formas de prevenção

Muitas vezes focamos na ação (que é bem importante, é claro), mas a análise do objeto a ser protegido + identificação das vulnerabilidades são necessárias para que a ação (prevenção) seja efetiva.

  Pensar na ação sem antes analisar o cenário como um todo pode resultar numa escolha de ações de prevenção inadequadas, insuficientes ou não efetivas em relação às vulnerabilidades e ameaças que colocam em risco o objeto que queremos proteger.

  O exemplo pode parecer um tanto exagerado (e “bizarro”), mas tenho certeza que vocês irão lembrar dele por muito tempo (e quem sabe utilizem em aulas e palestras futuramente, ou até mesmo para explicar para um cliente ou na empresa de vocês que segurança não é sobre “usar aquele antivírus que todo mundo está usando” ou “procurar no Google “Política de Segurança da Informação’ e usar um modelo genérico”).

  Bom, a seguir, vocês verão dois infográficos com exemplos um tanto “familiares” da segurança da informação.

  Penso que concordamos que, em ambos os casos, há uma ou mais formas de evitar a concretização do incidente, certo? Vocês talvez tenham pensado em outros mecanismos de defesa/prevenção, mas, para fins didáticos irei focar nas seguintes ideias:

  Tanto no exemplo 1 quanto no 2, um backup atualizado e mantido em outro local físico poderia garantir uma recuperação em relação aos incidentes. Portanto, em ambos os exemplos seria um mecanismo efetivo que deve ser adotado.

  Mas, a recuperação por meio de um backup, infelizmente, não é tão rápida como se imagina. Pode levar semanas até que um negócio volte a operar normalmente, ainda que com um backup realizado corretamente. Portanto, ainda que necessário e aplicável nos dois casos, existem formas de prevenção que podem ser aplicadas em momentos anteriores ao incidente.

  Estas formas de prevenção devem ser focadas em: corrigir uma vulnerabilidade (ou seja, “diminuir” uma abertura que soe convidativa para determinadas ameaças); e afastar um tipo de ameaça específica de explorar as vulnerabilidades.

  No exemplo 1, podemos falar em controles físicos, como portas corta fogo, por exemplo.

  No exemplo 2, podemos falar em atualizações de software frequentes e, a depender do malware, de um firewall eficiente, por exemplo.

  Agora, vamos ao meu exemplo “ridículo”! Mas que ajuda a visualizar a ideia e a usarmos essa lógica com mais facilidade em casos mais complexos:

  No exemplo 1, uma firewall ou um update do software não faria muita diferença para prevenir um incêndio.

  No exemplo 2, uma porta corta fogo não impediria um malware de acometer o sistema da empresa.

  Essa foi a forma “caricata” que encontrei para expor um dos maiores problemas que temos hoje em questão de legislação específica e até mesmo dentro dos programas de segurança/governança (nos setores público e privado).

  Governança é sobre “fazer regras” (“como algo deve ou não deve” ser feito, usado, executado, etc.), e essas regras se tornam um imenso problema quando quem as faz não compreende o objeto sobre o qual elas dizem respeito.

  O resultado disso? Algo como procedimentos de segurança sugerindo uma instalação de antivírus para a proteção de um servidor (desconsiderando possíveis ameaças físicas, como um incêndio); ou uma política tratando um antivírus como solução para qualquer tipo de malware, desconsiderando as peculiaridades de cada subtipo de malware existentes – na realidade temos ataques como o WannaCry (ransomware), que se utilizou de uma brecha de segurança no Windows 10 e sua correção dependia da atualização do software para a correção da falha de segurança – nenhum antivírus poderia “segurar” o ataque.

  Para concluir, um dos meus objetivos aqui foi demonstrar como é bem mais simples propor uma forma de prevenção com essa esquematização, com base na ISO 27001/27002, em matéria de segurança da informação e considerando o que falei logo no início: “Nem todo incidente de segurança da informação é uma violação de dados pessoais. Mas toda violação de dados pessoais é um incidente de segurança”. Este conhecimento é importante para a proteção dos dados pessoais na sua empresa, ou seja, para a adequação à LGPD ou outra legislação/regulamento de proteção de dados aplicável.

  A minha mensagem com isso é: a atuação ideal é uma integração entre as áreas técnica e jurídica. Ambas são importantes, têm funções diferentes e, preferencialmente, devem coexistir para garantir um nível adequado de proteção de dados pessoais.

  Espero que este artigo tenha sido útil para você. Até a próxima!

O que é anonimização?

 

  A palavra “anonimização”, dentro do senso comum, traz a ideia de tornar algo (ou alguém) não identificável, ou seja, tirar a possibilidade de associação de um indivíduo a um nome ou identidade.

  Falando de sua etimologia, a palavra vem do grego “anōnumos”, (an- “sem” + onoma “nome”), já trazendo em si a ideia não identificação, ainda que num contexto ligeiramente diferente da nossa atual sociedade da informação. E no contexto da proteção de dados pessoais?

  A LGPD – Lei Geral de Proteção de Dados traz a seguinte definição:

 

Utilização de meios técnicos razoáveis e disponíveis no momento do tratamento, por meio dos quais um dado perde a possibilidade de associação, direta ou indireta, a um indivíduo.

 

  Além disso, a lei também traz a definição de “dado anonimizado”:

 

Dado relativo a titular que não possa ser identificado, considerando a utilização de meios técnicos razoáveis e disponíveis na ocasião de seu tratamento.

 

  E como se dá este processo? Para trazer uma explicação de forma simplificada e mais visual, veja o infográfico abaixo.

  A anonimização consiste em um processo que tem o objetivo de impossibilitar a identificação do titular dos dados. Numa utilização prática, seria uma alternativa mais segura, por exemplo, para empresas que desejam utilizar dados pessoais para fins com viés mais “estatístico”. São atividades onde não é necessário que se identifique diretamente o titular, mas que algumas informações são relevantes para uma metrificação, análise estatística. Como exemplo: quantas mulheres estavam presentes em determinado evento?; quais são as profissões/áreas de atuação dos inscritos em determinado curso?; qual é a faixa etária média entre os usuários de determinado aplicativo?

  É importante destacar que, para que se categorize de fato ANONIMIZAÇÃO (e não pseudonimização, conforme veremos adiante) é necessário que a desassociação das informações que possam identificar diretamente o indivíduo seja um procedimento irreversível ou, pelo menos, realizado por meios técnicos exclusivamente próprios, que possam ser considerados razoáveis, seguros e suficientemente atualizados no critério espaço temporal, de modo que a sua reversão seja consideravelmente custosa e dificultada em questão de tempo despendido e habilidades técnicas necessárias para realizar o processo de reversão (reidentificação dos titulares).

  De forma geral, a forma mais segura de se realizar a anonimização seria a exclusão dos identificadores diretos (ex.: nome, RG, CPF, passaporte), de forma definitiva e buscando, inclusive, apagar possíveis registros e rastros remanescentes que possam levar à recuperação de tais dados (e, consequentemente, à reidentificação dos titulares).

  Outro artigo da LGPD que não podemos esquecer ao tratarmos de anonimização é o artigo. 12:

 

Os dados anonimizados não serão considerados dados pessoais para os fins desta Lei, salvo quando o processo de anonimização ao qual foram submetidos for revertido, utilizando exclusivamente meios próprios, ou quando, com esforços razoáveis, puder ser revertido.

 

  Este artigo define que os dados anonimizados não são classificados como dados pessoais perante à LGPD; ou seja, que a Lei Geral de Proteção de Dados não se aplica a tais dados.

  Daqui, também podemos extrair a seguinte informação: caso o processo de anonimização possa ser revertido (ainda que mediante esforços razoáveis), não estamos mais falando de dados anonimizados (e, portanto, não mais falamos da não incidência da LGPD) – a não ser que, no processo de reversão, a empresa utilize exclusivamente meios próprios (estes considerados razoáveis na ocasião do tratamento).

  Por fim, temos os parágrafos que acompanham o art. 12 da LGPD:

  1º A determinação do que seja razoável deve levar em consideração fatores objetivos, tais como custo e tempo necessários para reverter o processo de anonimização, de acordo com as tecnologias disponíveis e a utilização exclusiva de meios próprios.

  2º Poderão ser igualmente considerados como dados pessoais, para os fins desta Lei, aqueles utilizados para formação do perfil comportamental de determinada pessoa natural, se identificada.

  3º A autoridade nacional poderá dispor sobre padrões e técnicas utilizados em processos de anonimização e realizar verificações acerca de sua segurança, ouvido o Conselho Nacional de Proteção de Dados Pessoais.

 

A LGPD exige anonimização?

 

  A resposta é não. A lei somente traz a anonimização como uma opção em determinadas circunstâncias, mas não é um procedimento obrigatório para quem deseja tratar dados pessoais.

  Como já pontuamos, o grande atrativo da anonimização é justamente a não incidência da LGPD sobre dados anonimizados. Portanto, caso a sua empresa/cliente não precise identificar diretamente os titulares dos dados, recomende a anonimização! É melhor para os titulares e pode ser melhor para o bolso de quem não quer correr o risco de ser sancionado pela Autoridade Nacional.

  Diferente da anonimização, a pseudonimização não exclui a incidência da LGPD aos dados pessoais tratados. Ela representa somente um meio mais seguro de tratar os dados pessoais quando ainda há um interesse em manter os identificadores diretos do titular. A ideia é que estes sejam mantidos de forma separada. É comum que os dados pessoais, como nome e números de documentos, sejam substituídos por identificadores indiretos (um número ou código alfanumérico que possa ser utilizado para reunir os dados pessoais identificáveis com aqueles que, por ora, encontram-se pseudonimizados).

  De forma bastante simplificada, a criptografia é sobre codificar e decodificar dados. Basicamente, ela consiste em uma prática na qual um dado é codificado por meio de um algoritmo (no exemplo acima, uma mensagem enviada é codificada). Esse algoritmo trabalha de forma conjunta com uma chave, que define como a mensagem será cifrada (codificada).

  Há dois tipos de criptografia:

• Simétrica – onde uma única chave é utilizada para codificar e decodificar os dados.
• Assimétrica – onde uma chave é utilizada para codificar os dados (chamada “chave pública”) e uma outra é utilizada para decodificar os dados (chamada “chave privada”). Aqui, também é possível identificar a identidade do usuário (por isso considerada mais confiável).

 

Criptografar é a mesma coisa que anonimizar?

 

  A criptografia pode ser utilizada nos processos de anonimização e pseudonimização; mas não é, necessariamente, um sinônimo.

 

A lei, em algum momento, exige a encriptação de dados?

 

  Uma pergunta frequente com a qual nos deparamos é se a lei exige que a empresa que trata dados pessoais aplique a criptografia.

  A palavra criptografia se quer aparece no texto da LGPD. Ela pode ser utilizada como uma boa prática em segurança da informação e proteção de dados, mas não existe qualquer obrigatoriedade em utilizá-la.

  Bom, por hoje é isso. Espero ter conseguido esclarecer algumas dúvidas e trazer o conteúdo de forma mais simplificada.

1 – Agora é real, oficial: A LGPD entra em vigor em agosto de 2020

  Não há mais dúvida: o prazo de entrada em vigor da LGPD é agosto de 2020 (segundo os cálculos do Fabricio Mota, mais especificamente, no dia 16 de agosto de 2020). Assim, as empresas ganharam mais seis meses no prazo de adequação à lei.

  Mas isso não significa que dá para deixar o programa de implementação de proteção de dados para a última hora. Um programa efetivo exige várias etapas e uma verdadeira mudança de cultura – e isso não é possível fazer do dia para a noite.

  Apesar de algumas críticas quanto à dilação do prazo, pensando que no Brasil, diferente da União Europeia, não havia uma lei específica anterior sobre o tema, é razoável que as empresas tenham um prazo maior para uma compreensão da lei e planejamento de como se dará a implementação dentro das peculiaridades do modelo de negócio (core business, quantidade e sensibilidade dos dados processados, faturamento anual, número de áreas e colaboradores, etc.).

 

2 – ANPD possivelmente autônoma – em 2 anos

  Uma das maiores críticas que fizemos à LGPD foi a questão da autonomia da Autoridade Nacional de Proteção de Dados, apresentada num primeiro momento como agência reguladora – o que comprometia a entrada do Brasil na lista de livre transferência internacional de dados da União Europeia (nela estão, inclusive, os nossos vizinhos Argentina e Uruguai). Um dos requisitos para estar nesta lista, além de possuir uma legislação considerada adequada para a proteção de dados, é a existência de autoridade supervisora independente.

  Essa ausência de autonomia significaria para o Brasil um atraso em diversos sentidos, uma vez que vivemos numa economia baseada em dados e considerando que a União Europeia é um parceiro comercial estratégico.

  Mas a boa notícia foi que o texto final trouxe um novo formato para a nossa Autoridade, que já representa um avanço rumo à livre circulação de dados com a União Europeia: agora, ela será órgão da administração pública federal direta, vinculada ao Presidente da República e podendo, no período de dois anos, tornar-se “entidade de regime autárquico especial”.

  Entidade o que? Bom, traduzindo do “juridiquês”, seria um tipo de autarquia que pode contar com privilégios específicos e maior autonomia para um pleno desempenho de suas finalidades. Alguns exemplos desse tipo de autarquia são o Banco Central do Brasil e a OAB.

  Ainda temos muito a esperar quanto à ANPD.

 

3 – DPO pode ser pessoa física ou jurídica – e não tem mais obrigatoriedade de conhecimento jurídico-regulatório

  A  primeira alteração quanto ao DPO – Data Protection Officer (ou encarregado) da MP foi um tanto bem recebida: a LGPD que trazia a definição do DPO como pessoa física, passou a definir esta figura como “pessoa física ou jurídica”.

  E o que isso quer dizer? Que agora podemos falar em opções mais razoáveis tanto em questões econômicas como técnicas. Com essa mudança, podemos falar em “DPO as a service”, que seria a contratação de uma pessoa jurídica (empresa, consultoria, escritório de advocacia, etc.) especializada para assumir as responsabilidades de um DPO.

  Isto é interessante por não obrigar uma empresa a contratar um encarregado via CLT (o que pode ser um tanto desproporcional para startups ou pequenas e médias empresas, por exemplo, devido ao custo de manter um funcionário), como traz a possibilidade de contratação de um serviço completo envolvendo um time com um excelente nível de conhecimentos técnicos e jurídicos, com formação multidisciplinar.

  Mas outra modificação vem dividindo opiniões: na MP o DPO precisava ter conhecimento jurídico-regulatório. E, junto à sanção, o Presidente Jair Bolsonaro vetou esta especificação.

  Sabemos que para diversas das atividades listadas na LGPD, o conhecimento jurídico-regulatório será sim necessário (bem como, para tantas outras, conhecimentos técnicos específicos). Independentemente da inserção, ou do veto posterior, é necessário conhecimentos multidisciplinares e interdisciplinares para o desempenho das funções de DPO. Portanto, não entendo que o veto representou qualquer prejuízo ou mudança significativa no cenário fático.

  Além disso, o veto a este detalhe pode representar um ponto positivo para evitar que os nichos de mercado do meio jurídico acabem “monopolizando” a função.

 

4  – Compartilhamentos de dados de saúde com maiores restrições

  Os dados referentes à saúde não podem ser compartilhados para fins de obtenção de vantagem econômica.

  A MP determina que esta categoria de dados só poderá ter o seu compartilhamento dentro de algumas hipóteses específicas: para fins de portabilidade (solicitada pelo titular dos dados) ou no âmbito de transações resultantes da prestação de serviços de saúde, assistência farmacêutica e assistência de saúde.

 

5 – Revisão de decisões automatizadas

  Anteriormente à Medida Provisória, caso o titular requisitasse a revisão de decisões automatizadas que afetassem os seus interesses era assegurado pela Lei que a revisão deveria ser realizada por pessoa física. Já na nova redação, não há qualquer especificação sobre a obrigatoriedade de que a revisão seja realizada por pessoa natural ou com a sua intervenção.

  Ainda que haja críticas sobre esta modificação, devemos pensar que a revisão realizada por algoritmo (de forma automatizada) pode ser bem mais precisa do que a feira por pessoa natural. Ainda é preciso lembrar dos alto custo às empresas para que cada solicitação de revisão (em matéria de credit score, profiling e outros tipos de enquadramento automatizado e massificado) seja verificada por pessoa natural, que também necessita de determinados conhecimentos técnicos para realizar uma revisão algorítmica razoável.

  Em casos específicos, pode ser plausível tal exigência, mas, num contexto geral, de fato é um dispositivo desproporcional e sem um real benefício ao titular dos dados.

Controlador

 

  É ele que MANDA. Nas palavras da própria lei, o controlador pode ser classificado como “pessoa natural ou jurídica, de direito público ou privado, a quem compete as decisões referentes ao tratamento de dados pessoais”. Seria a figura equivalente ao responsável GDPR, ou seja, a empresa que demanda o tratamento, podendo ela mesma realizá-lo ou contratar um operador (que veremos logo a seguir). A lei brasileira, no entanto, traz uma peculiaridade: o controlador pode sim, ser pessoa natural – na GDPR essa classificação é limitada a pessoa jurídica. De certa forma, é um viés interessante, já que inibe condutas criminosas como colocar “laranjas” desempenhando o papel de controlador; caso a pessoa física desrespeite a lei, haverá sanções também.

  Cabe ao controlador, por óbvio, seguir o disposto na LGPD, devendo realizar o tratamento de acordo com os princípios ou orientar corretamente o operador, para que este realize um tratamento lícito. Um ponto interessante é a responsabilidade do controlador de elaborar o relatório de impacto (nas hipóteses aplicáveis).

  Ele responde pelos danos patrimoniais, morais, individuais ou coletivos, tal como violações à legislação (dever de reparação). Ainda, responde solidariamente pelos danos causados pelo operador, se diretamente envolvido no tratamento que resultar em danos.

Encarregado

 

  Por último, mas não menos importante, temos a figura do encarregado: “pessoa indicada pelo controlador para atuar como canal de comunicação entre o controlador, os titulares dos dados e a Autoridade Nacional de Proteção de Dados”. Equipara-se à figura do já conhecido DPO, da GDPR, e tem como responsabilidade legal estabelecer comunicação com os titulares e autoridade nacional, esclarecimentos, providências, orientações internas. Na redação original da lei brasileira, havia a exigência de que o encarregado fosse pessoa física; mas a redação foi alterada com a MP 869/2018.

  Na LGPD, pelo menos por enquanto, o encarregado deve ser indicado pelo controlador, não havendo previsão expressa de indicação por parte do operador.

  Ainda que o encarregado seja uma figura que ganhou lugar nos holofotes em ambas legislações, é importante lembrar: em momento algum há previsão sobre esta figura responder legalmente – entende-se, portanto, que cabe ao controlador a sua fiscalização, que pode ser seu funcionário ou prestador de serviços por meio contratual, pois, a quem interessa se o encarregado está desenvolvendo as suas atividades adequadamente é a própria empresa que o contratou. A responsabilidade, em caso de incidente, é do controlador ou operador (a depender do caso concreto); mas jamais do DPO/encarregado.