Roles e Permissões na Prática: 5 Cenários Reais em Sistemas de Gestão para OSCs
Voltar para o blog

Roles e Permissões na Prática: 5 Cenários Reais em Sistemas de Gestão para OSCs

E
Equipe Nexus
Autor

05 de julho de 2026

10 min de leitura

Pontos-Chave sobre Roles e Permissões em OSCs

  • 68% das violações de dados envolvem um elemento humano (erro ou engenharia social)
  • Credenciais roubadas foram o vetor de ataque inicial mais comum em 2024 (16% das violações)
  • O princípio do menor privilégio (NIST) é a base técnica para cumprir a LGPD art. 46
  • A ANPD recomenda controle de acesso com níveis de permissão na proporção da necessidade

Por Que Roles e Permissões são a Primeira Linha de Defesa

Toda OSC tem pessoas com funções diferentes: quem atende, quem coordena, quem administra, quem voluntaria. Cada uma precisa de acesso a informações diferentes — e, principalmente, não precisa de acesso ao que não usa.

O problema é que, em planilhas e sistemas sem controle de acesso granular, todo mundo vê tudo. Um voluntário de oficina acessa o histórico de saúde de um atendido. Um oficineiro vê dados financeiros de doadores. Um estagiário exporta a base completa de CPFs. Nenhum desses acessos é malicioso — mas cada um é uma violação da LGPD (art. 46), que exige "medidas de segurança, técnicas e administrativas aptas a proteger os dados pessoais de acessos não autorizados".

A Verizon, no DBIR 2024, revelou que "mais de dois terços (68%) das violações envolvem um elemento humano não malicioso, como erro ou engenharia social". A IBM, no Cost of a Data Breach 2024, identificou que "credenciais roubadas/comprometidas foram o vetor de ataque inicial mais comum, representando 16% das violações".

A primeira linha de defesa não é firewalls nem antivírus — é garantir que cada pessoa só tenha acesso ao que precisa. É o que se chama controle de acesso baseado em papéis (RBAC).

Diferencial do Nexus Social: 6 roles nativas (admin, diretor, coordenador, assistente_social, oficineiro, voluntário) com permissões granulares por módulo, aplicadas via Row Level Security no PostgreSQL — o filtro acontece no banco, não na aplicação. Conheça o controle de acesso do Nexus.

O Que RBAC e o Menor Privilégio Significam

RBAC segundo o NIST

O NIST (National Institute of Standards and Technology) define RBAC como "o modelo predominante para controle de acesso avançado porque reduz o custo e a complexidade da administração de segurança em grandes redes". Em vez de gerenciar permissões usuário por usuário, gerencia-se por papel — e cada usuário herda as permissões do papel que ocupa.

Princípio do menor privilégio

O NIST define o menor privilégio como "princípio de segurança segundo o qual um sistema deve restringir os privilégios de acesso de usuários (ou processos) ao mínimo necessário para realizar as tarefas atribuídas". A NIST SP 800-171 orienta a "permitir apenas acesso autorizado ao sistema para usuários necessário para realizar tarefas organizacionais atribuídas".

A recomendação da ANPD

A ANPD, no Guia de Segurança para Agentes de Pequeno Porte, recomenda "implementar um sistema de controle de acesso aplicável a todos os usuários, com níveis de permissão na proporção da necessidade de trabalhar com o sistema e de acessar dados pessoais". E explicita: "a premissa que deve ser aplicada é a do princípio do menos privilégio (need to know)".

A Resolução CD/ANPD nº 2/2022 aprova o regulamento para agentes de pequeno porte — categoria que inclui "pessoas jurídicas de direito privado, inclusive sem fins lucrativos" — e exige "medidas administrativas e técnicas essenciais e necessárias, com base em requisitos mínimos de segurança da informação".

Fontes: NIST — Role-Based Access Control; NIST — Least Privilege; NIST SP 800-171r3; ANPD — Guia de Segurança para Agentes de Pequeno Porte; ANPD — Resolução CD/ANPD nº 2/2022

5 Cenários Reais: O Que Cada Papel Vê (e Não Vê)

Cenário 1: Assistente Social

Maria é assistente social de uma OSC que atende famílias em situação de vulnerabilidade. Ela acompanha 40 famílias.

O que vê:

  • Prontuários completos das 40 famílias sob sua responsabilidade
  • Histórico de atendimentos, encaminhamentos e evolução
  • Dados sensíveis (saúde, situação jurídica) dos seus casos
  • Relatórios de atendimento que ela mesma gerou

O que não vê:

  • Prontuários de famílias de outros assistentes sociais
  • Dados financeiros da OSC (doações, despesas)
  • Configurações do sistema ou gestão de usuários
  • Base completa de CPFs exportável

Por quê: o Código de Ética do CFESS (art. 17) veda revelar sigilo profissional. Maria só deve acessar casos sob sua responsabilidade. O prontuário digital deve refletir essa segregação.

Diferencial do Nexus Social: a Row Level Security no PostgreSQL garante que Maria só veja registros onde responsavel_id = seu_id. Não é filtro de tela — é filtro de banco. Mesmo uma query direta não burla.

Cenário 2: Oficineiro

João ministra oficina de marcenaria para 15 adolescentes.

O que vê:

  • Lista de participantes da sua oficina (nome, idade, contato de emergência)
  • Registro de frequência das suas turmas
  • Avaliações de resultado das atividades que coordena
  • Materiais de apoio da oficina

O que não vê:

  • Histórico de saúde ou situação social dos participantes
  • Dados financeiros da OSC
  • Prontuários de atendidos não vinculados à sua oficina
  • Outras oficinas que não coordena

Por quê: João precisa saber quem está na oficina e se compareceu — não precisa saber que o adolescente X tem laudo psiquiátrico. O acesso a dados sensíveis é proporcional à necessidade (menor privilégio).

Cenário 3: Voluntário

Ana é voluntária que ajuda em eventos pontuais (campanhas de Natal, distribuição de cestas).

O que vê:

  • Lista de tarefas do evento em que participa
  • Materiais de divulgação
  • Contato do coordenador do evento

O que não vê:

  • Qualquer dado de atendidos (CPF, endereço, situação)
  • Dados financeiros
  • Base de doadores
  • Outros módulos do sistema

Por quê: voluntários eventuais não têm relação continuada com a OSC. Conceder acesso a dados sensíveis a quem participa de 2 eventos por ano é expor dados sem necessidade — violação direta do art. 46 da LGPD. Saiba mais em nosso guia de gestão de voluntários.

Cenário 4: Coordenador

Carlos coordena o programa de assistência social, com 5 assistentes sociais sob sua supervisão.

O que vê:

  • Prontuários de todos os atendidos do programa (não só os seus)
  • Relatórios agregados do programa (número de atendidos, evolução, indicadores)
  • Gestão de equipe (exceto criar/remover admins)
  • Aprovações de nível intermediário

O que não vê:

  • Configurações técnicas do sistema
  • Gestão de roles e permissões
  • Dados de outros programas que não coordena
  • Logs de auditoria de sistema (acesso restrito a admin)

Por quê: Carlos precisa supervisionar a equipe e ver o panorama do programa. Mas não precisa configurar o sistema nem acessar logs de auditoria — isso é função de admin. A ISO/IEC 27001:2022 define requisitos de sistemas de gestão de segurança da informação que incluem segregação de funções.

Cenário 5: Admin

Patrícia é diretora da OSC e tem role de admin.

O que vê:

  • Todos os módulos do sistema
  • Gestão completa de usuários (criar, editar, remover, atribuir roles)
  • Configurações da organização (nomenclaturas, integrações)
  • Trilha de auditoria completa (quem acessou o quê, quando)
  • Relatórios executivos e financeiros

O que não vê:

  • Dados de outras OSCs no mesmo sistema (isolamento por tenant)

Por quê: admin tem acesso amplo, mas não irrestrito. O isolamento por tenant (multitenancy) garante que nem o admin acessa dados de outra organização. A ISO/IEC 27002:2022 orienta sobre controles de acesso incluindo segregação. Entenda o multitenancy seguro.

A Base Técnica: Segregação de Funções e Auditoria

Segregação de funções (SoD)

O COSO Internal Control Framework define segregação de funções como atividade de controle essencial para mitigar riscos de fraude e erro. Em OSCs, isso significa: quem cadastra não aprova, quem aprova não executa, quem executa não audita.

Trilha de auditoria (LGPD art. 37)

A LGPD art. 37 determina que "o controlador e o operador devem manter registro das operações de tratamento de dados pessoais que realizarem". A NIST SP 800-53 (AC-2) estabelece controles de gerenciamento de contas incluindo "definir e documentar os tipos de contas permitidas" e "revisar contas periodicamente".

A trilha deve registrar: quem acessou, o quê visualizou, quando, de onde (IP), e a ação (consulta, edição, exportação). Sem trilha, é impossível investigar incidentes ou responder à ANPD. Veja como o prontuário digital integra a trilha de auditoria.

Governança no terceiro setor

O IBGC, no Guia de Melhores Práticas para Organizações do Terceiro Setor, aborda "gerenciamento de riscos, transparência e políticas de uma associação ou fundação". A Rede Filantropia reforça que "governança não deve ser entendida apenas como um conjunto de regras formais ou exigências legais. Trata-se, sobretudo, de um sistema de práticas que orienta a forma como decisões são tomadas, responsabilidades são distribuídas e informações são compartilhadas".

Comparativo: Acesso Sem Controle vs RBAC

AspectoSem controle (planilha)RBAC no Nexus Social
Acesso a dados sensíveisTodos veem tudoApenas papel autorizado
Filtro por responsávelInexistenteRLS no PostgreSQL
Voluntário vê dados de atendidosSimNão
Trilha de auditoriaManual, incompletaAutomática (art. 37)
Revogação de acessoManual, esquecidaImediata ao desativar
Conformidade com LGPD art. 46Difícil de demonstrarAuditoria exportável
Segregação de funçõesInexistentePor role e por módulo

Perguntas Frequentes

Quantas roles minha OSC precisa?

Depende do tamanho e da complexidade. O Nexus Social oferece 6 roles nativas (admin, diretor, coordenador, assistente_social, oficineiro, voluntário) que cobrem a maioria das OSCs pequenas e médias. OSCs maiores podem criar roles personalizadas. O importante é aplicar o princípio do menor privilégio — cada papel vê apenas o necessário.

Como revogo o acesso de quem saiu da OSC?

No Nexus Social, basta desativar o usuário no painel de administração. O acesso é revogado imediatamente, em todos os módulos. A NIST SP 800-53 (AC-2) recomenda revisão periódica de contas para garantir que não haja acessos órfãos.

Um voluntário pode ter acesso a dados de atendidos?

Não por padrão. Se houver necessidade excepcional (ex.: voluntário médico em campanha pontual), crie uma role temporária com escopo limitado e prazo de expiração. O acesso deve ser revogado ao término da atividade.

RBAC atende à LGPD?

Sim. A LGPD art. 46 exige medidas de segurança técnicas e administrativas. A ANPD recomenda explicitamente controle de acesso com princípio do menor privilégio. RBAC é a implementação técnica dessa recomendação. Veja nosso guia completo de controle de acesso.


Controle de acesso não é luxo de empresa grande — é obrigação da LGPD e proteção direta para as famílias que sua OSC atende. O Nexus Social entrega 6 roles nativas com RLS no PostgreSQL, trilha de auditoria automática e revogação imediata — pronto para usar, sem configurar segurança do zero. Agende uma demonstração e garanta que cada pessoa veja apenas o que deve.


Fontes e Referências


E
Escrito por Equipe Nexus

Equipe Nexus Social dedicada a compartilhar conhecimento e tecnologia para o fortalecimento do terceiro setor.