# Como implementar controle de acesso baseado em função (RBAC) para dados de CPF > Aprenda a implementar controle de acesso baseado em função (RBAC) para proteger dados de CPF. Exemplos práticos e boas práticas conforme a LGPD. **Publicado:** 26/02/2025 **Autor:** Redação CPFHub.io **URL:** https://cpfhub.io/blog/como-implementar-controle-de-acesso-baseado-em-funcao-rbac-para-dados-de-cpf --- Implementar RBAC para dados de CPF significa atribuir permissões a papéis — não a usuários individuais — garantindo que apenas colaboradores e sistemas autorizados consultem, visualizem ou gerenciem CPFs, em conformidade com o artigo 46 da LGPD. ## Introdução O controle de acesso baseado em função (RBAC — Role-Based Access Control) é uma das estratégias mais eficazes para proteger dados pessoais em sistemas corporativos. Quando aplicado a dados de CPF, o RBAC garante que apenas os colaboradores e sistemas que realmente precisam acessar essas informações tenham permissão para fazê-lo. A LGPD exige que empresas adotem medidas técnicas para proteger dados pessoais contra acessos não autorizados. O RBAC é uma dessas medidas, e sua implementação é especialmente relevante para empresas que utilizam APIs de consulta de CPF. A [ANPD](https://www.gov.br/anpd) recomenda controles de acesso granulares como parte das medidas técnicas adequadas ao nível de risco do tratamento. --- ## O que é RBAC e por que aplicar a dados de CPF O RBAC é um modelo de controle de acesso em que as permissões são atribuídas a funções (roles), e os usuários são associados a essas funções. Em vez de conceder permissões diretamente a cada usuário, a empresa define papéis com permissões específicas. ### Por que aplicar a dados de CPF * **Princípio do menor privilégio** -- Nem todos os colaboradores precisam ver CPFs completos. O RBAC restringe o acesso ao mínimo necessário. * **Rastreabilidade** -- Com papéis definidos, é mais fácil auditar quem acessou dados de CPF e por qual motivo. * **Conformidade LGPD** -- O artigo 46 da LGPD exige medidas de segurança que incluem controle de acesso. * **Redução de riscos** -- Limitar o acesso reduz a superfície de ataque em caso de comprometimento de credenciais. --- ## Definindo papéis e permissões para dados de CPF ### Papéis sugeridos | Papel | Permissão sobre CPF | Exemplo de colaborador | | --- | --- | --- | | admin | Acesso total, configuração de API keys | CTO, líder de engenharia | | compliance | Visualização de logs de auditoria | Analista de compliance | | atendimento | Visualização mascarada (123.***.***-00) | Analista de suporte | | operacional | Consulta via API (com registro) | Sistema de onboarding | | analista | Dados anonimizados/agregados | Analista de dados | | desenvolvedor | Acesso ao ambiente de testes apenas | Desenvolvedor | ### Matriz de permissões | Ação | admin | compliance | atendimento | operacional | analista | desenvolvedor | | --- | --- | --- | --- | --- | --- | --- | | Consultar CPF via API | Sim | Não | Não | Sim | Não | Não | | Ver CPF completo | Sim | Sim | Não | Não | Não | Não | | Ver CPF mascarado | Sim | Sim | Sim | Não | Não | Não | | Gerenciar API keys | Sim | Não | Não | Não | Não | Não | | Acessar logs de auditoria | Sim | Sim | Não | Não | Não | Não | | Acessar dados anonimizados | Sim | Sim | Não | Não | Sim | Não | --- ## Implementação prática em Python ### Estrutura básica de RBAC ```python import requests from functools import wraps # Definicao de papeis e permissoes PERMISSOES = { 'admin': ['consultar_cpf', 'ver_cpf_completo', 'ver_cpf_mascarado', 'gerenciar_keys', 'ver_logs', 'ver_anonimizados'], 'compliance': ['ver_cpf_completo', 'ver_cpf_mascarado', 'ver_logs', 'ver_anonimizados'], 'atendimento': ['ver_cpf_mascarado'], 'operacional': ['consultar_cpf'], 'analista': ['ver_anonimizados'], 'desenvolvedor': [] } def requer_permissao(permissao): """Decorador que verifica se o usuario tem a permissao necessaria.""" def decorator(func): @wraps(func) def wrapper(usuario, *args, **kwargs): papel = usuario.get('papel', '') permissoes_do_papel = PERMISSOES.get(papel, []) if permissao not in permissoes_do_papel: raise PermissionError( f'Usuario com papel "{papel}" nao tem permissao ' f'para "{permissao}".' ) return func(usuario, *args, **kwargs) return wrapper return decorator @requer_permissao('consultar_cpf') def consultar_cpf_api(usuario, cpf: str) -> dict: """Consulta CPF via API -- requer permissao 'consultar_cpf'.""" url = f'https://api.cpfhub.io/cpf/{cpf}' headers = { 'x-api-key': 'SUA_CHAVE_DE_API', 'Accept': 'application/json' } response = requests.get(url, headers=headers, timeout=10) return response.json() @requer_permissao('ver_cpf_mascarado') def ver_cpf_mascarado(usuario, cpf: str) -> str: """Retorna CPF mascarado -- requer permissao 'ver_cpf_mascarado'.""" return f'{cpf[:3]}.***.**{cpf[8]}-{cpf[9:]}' # Exemplos de uso usuario_operacional = {'nome': 'Sistema Onboarding', 'papel': 'operacional'} usuario_atendimento = {'nome': 'Ana Suporte', 'papel': 'atendimento'} # Operacional pode consultar CPF resultado = consultar_cpf_api(usuario_operacional, '12345678900') print(resultado) # Atendimento pode ver CPF mascarado cpf_mascara = ver_cpf_mascarado(usuario_atendimento, '12345678900') print(cpf_mascara) # 123.***.***-00 ``` --- ## Protegendo a chave de API com RBAC A chave de API (`x-api-key`) da CPFHub.io deve ser tratada como credencial sensível e seu acesso controlado pelo mesmo modelo de papéis. Apenas o papel `admin` deve ter acesso à chave de produção; o papel `desenvolvedor` deve operar exclusivamente com chaves de ambiente de testes. ### Boas práticas para gestão de API keys * **Armazene em variáveis de ambiente** -- Nunca inclua a chave no código-fonte. * **Use chaves diferentes por ambiente** -- Separe chaves de produção, staging e desenvolvimento. * **Rotação periódica** -- Altere as chaves regularmente e revogue chaves comprometidas. * **Monitore o uso** -- Acompanhe o consumo de consultas pelo dashboard da CPFHub.io em app.cpfhub.io. --- ## RBAC no nível do banco de dados Além do controle na aplicação, implemente RBAC no banco de dados para proteção em múltiplas camadas: ### PostgreSQL ```sql -- Criar papel com acesso apenas a CPF mascarado CREATE ROLE atendimento_role; GRANT SELECT (id, nome, cpf_mascarado) ON clientes TO atendimento_role; -- Criar papel com acesso completo para compliance CREATE ROLE compliance_role; GRANT SELECT ON clientes TO compliance_role; GRANT SELECT ON logs_auditoria TO compliance_role; -- Atribuir papeis aos usuarios do banco GRANT atendimento_role TO usuario_suporte; GRANT compliance_role TO usuario_compliance; ``` Essa abordagem garante que, mesmo que um usuário acesse o banco diretamente (via ferramenta de administração), as restrições de papel sejam respeitadas. --- ## Auditoria e monitoramento O RBAC é mais eficaz quando combinado com auditoria: * **Registre cada acesso a dados de CPF** -- Quem acessou, quando, qual papel e qual a finalidade. * **Alertas para acessos atípicos** -- Configure alertas para consultas fora do padrão (ex.: volume incomum de consultas por um usuário). * **Revisão periódica de papéis** -- Verifique trimestralmente se os papéis atribuídos ainda são adequados. * **Remoção imediata de acesso** -- Quando um colaborador muda de função ou sai da empresa, revogue o acesso imediatamente. --- ## Erros comuns na implementação de RBAC * **Papéis muito amplos** -- Um papel com permissões excessivas anula o benefício do RBAC. * **Não aplicar RBAC a sistemas legados** -- Sistemas antigos frequentemente concedem acesso irrestrito a dados de CPF. * **Esquecer de APIs e integrações** -- O RBAC deve ser aplicado também a serviços automatizados que consomem a API. * **Não auditar** -- RBAC sem auditoria dificulta a detecção de acessos indevidos. * **Papéis estáticos** -- Revisar e atualizar papéis conforme a organização evolui é parte essencial da governança de dados. --- ## Perguntas frequentes ### Qual é a diferença entre RBAC e listas de controle de acesso (ACL) para dados de CPF? No modelo ACL, permissões são atribuídas diretamente a cada usuário sobre cada recurso — o que se torna inviável em equipes grandes. No RBAC, as permissões são definidas no papel, e usuários herdam as permissões ao serem associados a um papel. Para dados de CPF, o RBAC escala melhor e facilita auditorias de conformidade com a LGPD. ### Como o RBAC ajuda a cumprir o artigo 46 da LGPD? O artigo 46 exige medidas técnicas e administrativas aptas a proteger dados pessoais de acessos não autorizados. O RBAC implementa exatamente isso: restringe o acesso ao CPF ao mínimo necessário para cada função, registra quem acessou e quando, e permite revogar permissões imediatamente ao detectar uso indevido ou encerramento de vínculo. ### É possível aplicar RBAC apenas na camada de aplicação, sem mudar o banco de dados? Sim, mas a proteção é menor. Se um desenvolvedor ou DBA tiver acesso direto ao banco, as restrições da aplicação são contornadas. O ideal é aplicar RBAC em duas camadas: na aplicação (controle lógico de permissões) e no banco de dados (GRANT/REVOKE por papel), garantindo que nem acessos diretos ao banco exponham CPFs sem autorização. ### Como tratar o acesso emergencial a dados de CPF sem violar o RBAC? Implemente um fluxo de "break glass": um papel temporário com permissões elevadas, ativado mediante aprovação de dois administradores, com validade de tempo limitada (ex.: 4 horas) e auditoria reforçada de cada ação. Todo acesso emergencial deve ser revisado no próximo ciclo de auditoria para verificar se houve necessidade real ou desvio. ### Leia também - [LGPD: CPF é dado pessoal sensível ou não? Entenda a classificação correta](https://cpfhub.io/blog/lgpd-cpf-e-dado-pessoal-sensivel-ou-nao-entenda-a-classificacao-correta) - [KYC no Brasil: quais setores são obrigados a validar CPF por lei](https://cpfhub.io/blog/kyc-no-brasil-quais-setores-sao-obrigados-a-validar-cpf-por-lei) - [SLA de API de CPF: níveis de disponibilidade e o que exigir do seu provedor](https://cpfhub.io/blog/sla-api-cpf-niveis-disponibilidade) - [Golpe do CPF clonado em compras online: como detectar e prevenir](https://cpfhub.io/blog/golpe-cpf-clonado-compras-online-detectar-prevenir) --- ## Conclusão Implementar RBAC para dados de CPF é uma medida técnica fundamental para conformidade com a LGPD e para a proteção real dos dados dos titulares. A definição clara de papéis e permissões, combinada com auditoria e monitoramento, garante que apenas as pessoas e sistemas autorizados acessem dados de CPF. Cadastre-se em [cpfhub.io](https://www.cpfhub.io/) — 50 consultas mensais gratuitas, sem cartão de crédito — e integre a validação de CPF ao seu modelo RBAC com controle granular de acesso desde o primeiro dia.