LGPD e controle de acesso: da política de privacidade ao acesso real no sistema

A maioria dos programas de privacidade no Brasil começou pelo papel. Política publicada, base legal mapeada, aviso de cookies no site, encarregado nomeado. Tudo isso é necessário. Nada disso responde à pergunta que aparece no pior dia possível: quem tinha acesso a essa base de dados pessoais e por quê.

LGPD e controle de acesso não são temas paralelos. O controle de acesso é o lugar onde o programa de privacidade encosta na operação. É o ponto em que a promessa de proteger o dado se transforma em uma permissão concedida a uma pessoa específica, por um prazo específico, com um motivo registrado. Sem isso, a política de privacidade é uma declaração de intenção.

Onde a LGPD encosta no controle de acesso

A LGPD não é uma norma técnica. Ela não traz matriz de perfis, não define quantos aprovadores um acesso privilegiado precisa e não lista controles como um framework de segurança faria. O que ela faz é impor obrigações de resultado. E três delas caem direto no colo de quem administra acesso.

O dever de adotar medidas de segurança

O art. 46 determina que os agentes de tratamento adotem medidas de segurança, técnicas e administrativas, aptas a proteger os dados pessoais de acessos não autorizados. A expressão "acessos não autorizados" está no texto da lei. Controle de acesso deixa de ser boa prática de TI e passa a ser cumprimento de obrigação legal.

O detalhe que muda tudo é a palavra "aptas". A lei não pede que sua empresa tenha uma ferramenta. Pede que a medida seja adequada ao risco do tratamento. Um sistema com dado pessoal sensível de milhares de titulares e um sistema com o cadastro de fornecedores não pedem o mesmo rigor.

O princípio da necessidade

Entre os princípios do art. 6 está a necessidade, que limita o tratamento ao mínimo necessário para a finalidade. Em segurança da informação isso tem outro nome: privilégio mínimo. São a mesma ideia vista de dois ângulos.

Quando um analista de suporte tem visão da base inteira de clientes porque o perfil dele foi copiado de outro analista, sua empresa está tratando mais dado do que a finalidade exige. O problema não é só de risco cibernético. É desvio do princípio da necessidade.

A responsabilização e prestação de contas

O art. 6 também traz a responsabilização e prestação de contas, que exige demonstrar a adoção de medidas eficazes. A palavra que importa é demonstrar. Não basta ter o controle, é preciso comprovar que ele operou. Um controle sem registro é indistinguível de um controle inexistente na hora da fiscalização.

O que a lei cobra na prática: demonstrar, não declarar

Existe uma distância grande entre "temos controle de acesso" e "podemos provar quem acessou o quê, quando, autorizado por quem e por quanto tempo". Quase toda empresa fica do lado errado dessa distância.

O art. 37 exige que controlador e operador mantenham registro das operações de tratamento que realizarem. Na leitura operacional, esse registro não sobrevive se a concessão de acesso à base que contém o dado pessoal acontece por mensagem em chat e morre ali. O registro do tratamento e a trilha do acesso são partes do mesmo dever de prestar contas.

O art. 50 vai na mesma direção quando trata de programa de governança em privacidade. Um programa que existe no slide do comitê e não aparece no fluxo de concessão de acesso não é um programa, é uma intenção documentada.

Os quatro momentos em que a LGPD cobra o seu controle de acesso

A cobrança nunca chega como uma pergunta genérica sobre conformidade. Ela chega em quatro situações concretas, e em todas o prazo é curto.

O incidente de segurança

O art. 48 obriga a comunicar incidente de segurança que possa acarretar risco ou dano relevante ao titular, à autoridade nacional e ao titular. A ANPD regulamentou essa comunicação e fixou prazo contado em dias úteis a partir do conhecimento do incidente, hoje em três dias úteis. Confirme a redação vigente com o seu jurídico, porque regulamentação muda.

Três dias úteis é o prazo para dizer o que aconteceu, quais dados foram afetados e quais medidas foram tomadas. Se descobrir quais contas tinham acesso à base comprometida exige abrir vinte planilhas e caçar aprovações em caixas de e-mail, o prazo vence antes da resposta ficar pronta. A pressa não é para achar o invasor, é para delimitar a exposição.

O pedido do titular

O art. 18 dá ao titular o direito de confirmação de tratamento, acesso aos dados e informação sobre compartilhamento. O art. 19 fixa prazos curtos para atender. Na prática, o time recebe um pedido e precisa saber quais sistemas guardam aquele dado e quem tinha permissão de olhar.

A fiscalização e a auditoria

Aqui vale o mesmo raciocínio que sustenta uma auditoria de SOC 2 ou ISO 27001. Quem fiscaliza não aceita declaração, pede amostra. É o mesmo tipo de teste descrito em evidência de controle de acesso para SOC 2 e ISO 27001, aplicado a bases com dado pessoal.

O contrato com o operador

O art. 39 estabelece que o operador realize o tratamento segundo as instruções do controlador. Se sua empresa contrata um operador e concede a ele acesso amplo e sem prazo à base de clientes, a instrução contratual e o acesso real deixaram de coincidir. A cláusula diz uma coisa e o Active Directory diz outra.

O cruzamento que quase ninguém faz

Muitas empresas têm duas listas maduras e desconectadas. O jurídico e a privacidade mantêm o inventário de dados, com sistema, base legal, finalidade, categoria de titular e retenção. A TI mantém o inventário de acessos, com usuário, grupo e permissão.

O valor está no cruzamento. Sem ele, ninguém sabe responder qual é a lista de pessoas com acesso a dado pessoal sensível hoje. Essa é a pergunta mais simples que a LGPD suscita e a que mais empresas erram.

O caminho prático é classificar cada sistema pelo tipo de dado que ele trata e usar essa classificação como critério de aprovação. Acesso a sistema que trata dado pessoal sensível não pode seguir o mesmo rito de acesso a uma ferramenta de gestão de tarefas.

Privilégio mínimo como controle de privacidade

O privilégio mínimo costuma ser tratado como assunto de segurança. Sob a LGPD, ele é também um controle de finalidade. Cada permissão a mais é um tratamento de dado que ninguém justificou.

Três mecanismos sustentam o privilégio mínimo no dia a dia, e nenhum deles funciona sozinho:

1. 1Concessão por papel, não por cópia. Copiar o acesso de um colega replica privilégio excessivo e o histórico de exceções dele. O caminho é modelar perfis por função, como descrito em modelagem de papéis em RBAC.
2. 2Vigência compulsória. Todo acesso a base com dado pessoal nasce com data de término. Renovação exige nova justificativa de finalidade. É o que impede o cenário de acessos órfãos e privilégio excessivo.
3. 3Revisão periódica com owner. O dono da base confirma quem ainda precisa acessar. Sem isso, a lista só cresce. O desenho dessas campanhas está em recertificação de acessos.

Acesso de terceiro e a cadeia de operadores

O acesso de terceiro é o ponto mais frágil da maioria dos programas. O prestador entra por demanda de projeto, o contrato é assinado pelo jurídico, o acesso é liberado pela TI e ninguém une as duas pontas. Quando o projeto acaba, o contrato encerra e o acesso permanece.

Três regras simples resolvem a maior parte do problema. Todo acesso de terceiro precisa de um owner interno nomeado, que responde por ele. Todo acesso de terceiro nasce com prazo alinhado ao contrato. E o encerramento do contrato precisa disparar revogação, não um pedido informal de que alguém lembre de revogar.

Como estruturar isso em oito passos

1. 1Classifique os sistemas pelo tipo de dado pessoal que tratam, junto com a privacidade e o jurídico.
2. 2Nomeie um owner responsável por cada base que contém dado pessoal.
3. 3Cruze o inventário de dados com o inventário de acessos e gere a lista atual de quem acessa o quê.
4. 4Trate os achados óbvios primeiro: conta ativa sem vínculo, acesso de projeto encerrado, perfil administrativo sem justificativa.
5. 5Feche o canal informal de solicitação. Todo pedido de acesso passa a exigir finalidade declarada e prazo.
6. 6Defina rito diferenciado para dado pessoal sensível, com aprovação adicional e vigência curta.
7. 7Estabeleça revisão periódica com o owner, priorizando as bases mais críticas.
8. 8Documente o processo e guarde a evidência de cada etapa, porque prestação de contas é obrigação e não gentileza.

Checklist prático

• Existe lista atualizada de sistemas que tratam dado pessoal, com classificação por sensibilidade.
• Cada base com dado pessoal tem owner nomeado, e não apenas um time genérico responsável.
• Toda concessão de acesso a essas bases registra finalidade, aprovador e data de término.
• É possível listar, em minutos, quem tem acesso a uma base específica hoje.
• É possível reconstruir quem tinha acesso a uma base em uma data passada.
• Acesso de terceiro tem owner interno, prazo contratual e gatilho de revogação.
• Desligamento e mudança de cargo disparam revisão de acesso a dado pessoal.
• A revisão periódica das bases críticas acontece e deixa registro da decisão.
• O encarregado consegue obter essas informações sem depender de favor pessoal na TI.
• As exceções aprovadas têm dono, prazo e justificativa registrada.

Onde entra uma camada de governança de acessos

Nada do que está acima exige ferramenta para ser verdade. Exige ferramenta para ser sustentável. Em ambiente com centenas de usuários, dezenas de sistemas e rotatividade normal, o controle manual perde a corrida em poucos meses.

O AuditAcesso atua exatamente nesse recorte. Ele estrutura a solicitação com justificativa e escopo obrigatórios, aplica decisão baseada em criticidade, executa o provisionamento via ITSM ou API, impõe data de término compulsória e organiza a revisão periódica com o owner da aplicação. O resultado é a informação que a LGPD cobra disponível como subproduto do processo: quem solicitou, quem aprovou, por quê e por quanto tempo.

A integração com Active Directory e com ITSM importa aqui por um motivo específico. Ela preserva o vínculo entre a decisão de negócio e a permissão técnica, que é justamente o elo que se perde quando o pedido nasce em um e-mail e a execução acontece em outro lugar. O desenho completo está no ciclo de governança em cinco etapas, e os riscos ocultos da gestão de acessos descrevem o cenário que antecede essa camada.

Nenhuma ferramenta entrega conformidade com a LGPD. Conformidade depende de processo, de decisão de negócio e da avaliação do seu jurídico. O que uma camada de governança faz é tornar o controle executável e a evidência disponível.

Perguntas frequentes

A LGPD exige uma ferramenta de controle de acesso?

Não. A lei exige medidas de segurança aptas a proteger o dado pessoal de acesso não autorizado, sem determinar tecnologia. A escolha entre processo manual e plataforma é da empresa. O que a lei cobra é o resultado: acesso limitado à finalidade e capacidade de demonstrar que o controle funciona.

O que a LGPD fala especificamente sobre acesso não autorizado?

O art. 46 trata do dever de adotar medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou difusão. É o artigo que conecta privacidade e controle de acesso de forma mais direta.

Qual o prazo para comunicar um incidente que envolveu acesso indevido?

A comunicação à autoridade nacional e ao titular está prevista no art. 48, e a regulamentação da ANPD fixou prazo contado em dias úteis a partir do conhecimento, hoje em três dias úteis. Como regulamentação muda, confirme a redação vigente com o seu jurídico antes de desenhar o processo interno.

Log de acesso é suficiente para comprovar controle?

Não. O log mostra o que aconteceu no sistema, não mostra que aquilo estava autorizado. A comprovação exige as duas camadas: a trilha da decisão, com solicitante, aprovador, finalidade e prazo, e o registro técnico do acesso. Sem a primeira, o log prova atividade e não conformidade.

Como tratar acesso de fornecedor a base com dado pessoal?

Com owner interno nomeado, finalidade declarada, prazo alinhado ao contrato e gatilho de revogação no encerramento. O art. 39 espera que o operador trate o dado conforme instrução do controlador, então o acesso concedido precisa refletir o que o contrato autoriza, nada além.

Quem deve aprovar acesso a dado pessoal sensível?

O owner da base, com validação da área de privacidade. Dado sensível pede rito mais rígido: justificativa de finalidade explícita, vigência curta e revisão frequente. Deixar essa decisão apenas com a TI transfere responsabilidade de negócio para quem só executa a permissão.

Próximo passo

Se sua empresa não consegue listar em minutos quem tem acesso às bases com dado pessoal, o problema não é de política, é de processo de concessão. Estruturar governança de acessos resolve os dois lados: limita o acesso ao necessário e produz a evidência que a prestação de contas exige.

Solicitar demonstração do AuditAcesso e ver o ciclo completo aplicado às suas bases críticas.

==============================================================