Como implementar controles de acesso granulares para dados pessoais

O Art. 46 da LGPD exige que controladores e operadores adotem medidas técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados. De todas as medidas técnicas de segurança, o controle de acesso é a que mais diretamente determina quem pode ver, modificar e excluir dados pessoais — e, portanto, quem pode causar dano aos titulares.

Dados pessoais acessíveis a quem não precisa deles não é só uma questão de segurança: é uma violação do princípio da necessidade da própria LGPD (Art. 6º, III), que estabelece que o tratamento deve ser limitado ao mínimo necessário para a realização de suas finalidades.

O que são controles de acesso granulares?

Controles de acesso granulares são mecanismos que definem, com precisão, quem tem acesso a quais dados, em quais condições e para quais operações. A granularidade contrasta com abordagens simplistas (ex.: "todos os funcionários têm acesso ao CRM") e estabelece permissões específicas baseadas em função, contexto ou atributo.

Os três princípios que norteiam um sistema de acesso granular são:

1. Princípio do menor privilégio (Least Privilege)

Cada usuário, processo ou sistema deve ter acesso apenas ao que é estritamente necessário para executar sua função — nem mais, nem menos.

Exemplo prático: um analista de suporte ao cliente precisa ver o histórico de pedidos e dados de contato do cliente, mas não precisa ver o CPF, dados bancários ou histórico médico. O sistema deve refletir exatamente essa distinção.

2. Segregação de funções (Separation of Duties)

Funções críticas devem ser distribuídas entre múltiplas pessoas ou papéis para evitar que uma única pessoa tenha controle completo sobre um processo sensível — o que poderia facilitar fraude ou uso indevido.

Exemplo: a mesma pessoa que cadastra um novo fornecedor não deveria ter permissão de autorizar pagamentos a esse fornecedor. No contexto de dados pessoais, a pessoa que exclui dados não deveria ser a mesma que aprova a solicitação de exclusão.

3. Necessidade de saber (Need to Know)

Acesso a dados pessoais só se justifica quando existe uma necessidade funcional concreta. O acesso deve ser concedido caso a caso, baseado em demanda, não por conveniência ou por hierarquia.

Modelos de controle de acesso

RBAC — Controle de Acesso Baseado em Papéis (Role-Based Access Control)

O modelo mais amplamente adotado em ambientes corporativos. Usuários são atribuídos a papéis (roles), e os papéis têm permissões definidas. Em vez de gerenciar permissões individualmente para cada usuário, você gerencia permissões por papel.

Vantagens para gestão de dados pessoais:

Transparência: cada usuário está vinculado a um papel com permissões previamente documentadas
Escalabilidade: ao contratar ou mudar a função de um colaborador, basta alterar o papel
Auditabilidade: possível demonstrar, para a ANPD, quem tinha acesso a quais dados em qualquer momento

Exemplo de papéis em um contexto de dados pessoais:

Papel	Acesso aos dados
Atendente de SAC	Nome, e-mail, histórico de pedidos, telefone
Analista de RH	Dados completos de funcionários (incluindo dados de saúde ocupacional)
Analista de Marketing	E-mail, preferências de comunicação, histórico de compras — sem CPF ou dados financeiros
DPO	Acesso de leitura ao inventário e logs; sem acesso direto ao banco de dados de produção
Administrador de banco de dados	Acesso técnico (estrutura do banco) — sem acesso a dados pessoais em texto claro
Auditor interno	Acesso somente leitura a logs e registros de auditoria

ABAC — Controle de Acesso Baseado em Atributos (Attribute-Based Access Control)

Modelo mais granular que o RBAC, onde as decisões de acesso são baseadas em atributos do usuário, do recurso e do contexto. Permite regras como:

"Um médico pode acessar prontuários apenas de pacientes sob seus cuidados"
"Dados de clientes europeus só podem ser acessados por colaboradores com treinamento GDPR"
"Acesso a dados sensíveis é bloqueado fora do horário de trabalho"

O ABAC é mais complexo de implementar mas oferece granularidade superior em ambientes com dados sensíveis ou requisitos regulatórios específicos.

PBAC — Controle de Acesso Baseado em Políticas (Policy-Based Access Control)

Extensão do ABAC que incorpora políticas explícitas de conformidade — como "nenhum dado pessoal de menor de 18 anos pode ser acessado por usuários sem autorização específica do DPO". Adequado para organizações com múltiplos regulamentos de privacidade aplicáveis.

Implementação prática: passo a passo

Passo 1: Mapeie os sistemas que contêm dados pessoais

Antes de definir controles, saiba onde os dados estão. Os sistemas típicos em uma organização que contêm dados pessoais incluem:

CRM (dados de clientes e prospects)
ERP/folha de pagamento (dados de funcionários)
Sistema de saúde ocupacional ou benefícios
E-mail corporativo (frequentemente negligenciado)
Repositórios de arquivos (Google Drive, SharePoint, servidores de arquivos)
Bancos de dados de aplicações web
Ferramentas de suporte e helpdesk
Sistemas de analytics e BI

Passo 2: Classifique os dados por sensibilidade

Não todos os dados pessoais requerem o mesmo nível de proteção. Uma classificação prática:

Nível	Tipo de dado	Controle de acesso
Crítico	Dados sensíveis (saúde, biometria, dados financeiros detalhados, CPF+dados bancários combinados)	Acesso restritíssimo; MFA obrigatório; logs de cada acesso
Confidencial	Dados pessoais gerais com risco moderado (CPF isolado, dados de RH, endereço)	Acesso baseado em necessidade funcional documentada
Interno	Dados pessoais de baixo risco (nome, e-mail corporativo)	RBAC padrão; acesso por departamento

Passo 3: Defina os papéis e suas permissões

Para cada sistema mapeado, defina:

Quais papéis existem
Quais dados cada papel pode acessar
Quais operações cada papel pode executar (leitura, criação, edição, exclusão)
Se o acesso é permanente ou por demanda (just-in-time access)

Documente essa matriz de papéis e permissões — ela será fundamental para auditorias e para demonstrar conformidade.

Passo 4: Implemente autenticação multifator (MFA)

MFA não é um controle de acesso por si só, mas é o requisito mínimo para qualquer sistema que contenha dados pessoais. Sem MFA, uma senha comprometida concede acesso irrestrito.

Priorize MFA para:

Qualquer acesso remoto (VPN, acesso a sistemas em nuvem)
Sistemas com dados sensíveis
Contas privilegiadas (administradores, DBAs)
Acesso ao painel de gestão de identidades

Passo 5: Configure logs de auditoria de acesso

Para demonstrar conformidade com a LGPD e investigar incidentes, cada sistema com dados pessoais deve registrar:

Quem acessou (usuário identificado)
O quê foi acessado (registro ou conjunto de dados)
Quando (data e hora com precisão)
De onde (endereço IP, dispositivo)
O que foi feito (leitura, exportação, edição, exclusão)

Retenção dos logs: os logs de acesso a dados pessoais devem ser retidos por prazo suficiente para investigação de incidentes. A prática recomendada é de 6 a 12 meses para logs operacionais, com possibilidade de arquivamento de longo prazo para incidentes investigados.

Passo 6: Implemente processo de revisão periódica de acessos

Permissões acumulam. Colaboradores mudam de cargo, projetos terminam, terceiros têm seus contratos encerrados — mas os acessos frequentemente permanecem ativos. A revisão periódica é o mecanismo que corrige esse acúmulo.

Frequência recomendada:

Acessos a dados críticos: revisão trimestral
Acessos a dados confidenciais: revisão semestral
Acessos de prestadores e terceiros: revisão a cada renovação de contrato

Como conduzir a revisão:

Gere relatório de todos os usuários com acesso a cada sistema
Envie para o gestor responsável de cada área para validação
O gestor confirma quais acessos são necessários e solicita revogação dos desnecessários
TI executa as revogações e registra as alterações

Passo 7: Estabeleça processos de offboarding

O desligamento de um colaborador (demissão, transferência, encerramento de contrato de terceiro) deve acionar imediatamente a revogação de todos os acessos a sistemas com dados pessoais.

Um único colaborador desligado com acesso ativo ao CRM ou ao banco de dados de clientes representa um risco regulatório e reputacional concreto.

Checklist de offboarding:

Revogação de acesso a todos os sistemas (CRM, ERP, e-mail, repositórios, VPN)
Desativação de conta de usuário no Active Directory / provedor de identidade
Revogação de tokens de API ou credenciais de serviço associadas ao usuário
Verificação de dispositivos (notebooks, smartphones) com dados pessoais — wipe corporativo
Confirmação de que nenhuma cópia de dados pessoais foi retida indevidamente

Gestão de acessos privilegiados (PAM)

Contas de administrador — de sistemas, de bancos de dados, de infraestrutura — representam o maior risco em qualquer ambiente. Uma conta de DBA com acesso irrestrito ao banco de clientes, comprometida, pode expor milhões de registros.

Boas práticas para acessos privilegiados

Contas de administrador separadas das contas pessoais: o DBA usa uma conta comum para e-mail e outra para acesso ao banco de dados
Just-in-time access: acessos privilegiados são concedidos apenas pelo tempo necessário para a tarefa, não permanentemente
Gravação de sessão: sessões de acesso privilegiado são gravadas e arquivadas para auditoria
Dupla aprovação: ações críticas (exclusão em massa, alteração de estrutura de banco) exigem aprovação de segundo administrador
Gestão centralizada de credenciais: uso de cofres de senha (PAM — Privileged Access Management) em vez de senhas individuais não gerenciadas

Privacy by Design: construindo controles de acesso desde o início

O Art. 49 da LGPD estabelece que os sistemas utilizados para o tratamento de dados pessoais devem ser estruturados de forma a atender aos requisitos de segurança e proteção de dados desde a concepção — o princípio do Privacy by Design.

Na prática, isso significa que novos sistemas e funcionalidades devem ser projetados com controles de acesso adequados antes da entrada em produção, não como adaptação posterior. Checklist para novos sistemas:

Quais dados pessoais o sistema irá armazenar ou processar?
Quais papéis precisam de acesso a quais dados?
O sistema suporta RBAC nativo?
Existe mecanismo de log de acesso?
MFA está disponível e habilitado?
Dados sensíveis são criptografados em repouso?

Erros comuns e como corrigi-los

Erro	Risco	Correção
Acesso administrativo compartilhado ("senha genérica do sistema")	Impossível rastrear responsabilidade; comprometimento afeta todos	Contas individuais nominais para cada administrador
Colaboradores com acesso a dados pessoais de todos os clientes quando só precisam dos seus	Exposição desnecessária; violação do menor privilégio	RBAC com escopo por carteira ou território
Logs inexistentes ou sobrescritos em poucos dias	Impossível investigar incidentes; sem evidência de compliance	Implementar retenção mínima de 6 meses para logs
Terceiros com acesso permanente a sistemas	Risco após encerramento do contrato	Contas temporárias com data de expiração automática
Sem revisão periódica de acessos	Acúmulo de permissões obsoletas	Processo formal de revisão semestral
Dados de desenvolvimento com dados pessoais reais	Dados pessoais em ambiente não produtivo, com controles menores	Usar dados mascarados ou sintéticos em dev/teste

Conclusão

Controles de acesso granulares não são apenas uma boa prática de segurança da informação — são uma obrigação legal sob a LGPD. O Art. 46 exige medidas técnicas adequadas; o Art. 6º exige que o tratamento seja limitado ao mínimo necessário; o Art. 49 exige privacidade desde a concepção.

A implementação correta de RBAC, MFA, logs de auditoria, revisão periódica de acessos e gestão de offboarding traduz esses princípios legais em realidade operacional — e, em caso de fiscalização da ANPD ou de incidente de segurança, demonstra que a organização tomou medidas concretas e razoáveis para proteger os dados sob sua custódia.

A Confidata foi desenvolvida com controles de acesso granulares nativos: cada usuário acessa apenas o que precisa, com trilha de auditoria completa de todas as ações. Conheça como nossa plataforma protege os dados da sua organização.