Roles e Permissões na Prática: 5 Cenários Reais em Sistemas de Gestão para OSCs
Equipe Nexus
Autor05 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
| Aspecto | Sem controle (planilha) | RBAC no Nexus Social |
|---|---|---|
| Acesso a dados sensíveis | Todos veem tudo | Apenas papel autorizado |
| Filtro por responsável | Inexistente | RLS no PostgreSQL |
| Voluntário vê dados de atendidos | Sim | Não |
| Trilha de auditoria | Manual, incompleta | Automática (art. 37) |
| Revogação de acesso | Manual, esquecida | Imediata ao desativar |
| Conformidade com LGPD art. 46 | Difícil de demonstrar | Auditoria exportável |
| Segregação de funções | Inexistente | Por 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
- Planalto — Lei nº 13.709/2018 (LGPD), arts. 37 e 46 — Registro de operações de tratamento e medidas de segurança (2018)
- NIST — Role-Based Access Control — RBAC como modelo predominante de controle de acesso avançado
- NIST — Least Privilege (Glossary) — Definição do princípio do menor privilégio (CNSSI 4009-2015)
- NIST SP 800-171r3 — Aplicação do menor privilégio para usuários e processos (2020)
- NIST SP 800-53 r5 (AC-2) — Account Management: definição de tipos de conta e revisão periódica (2020)
- ANPD — Guia de Segurança da Informação para Agentes de Pequeno Porte — Recomenda controle de acesso com princípio do menor privilégio (2023)
- ANPD — Resolução CD/ANPD nº 2/2022 — Regulamento para agentes de pequeno porte, incluindo OSCs (2022)
- Verizon — 2024 Data Breach Investigations Report — 68% das violações envolvem elemento humano (2024)
- IBM — Cost of a Data Breach Report 2024 — Credenciais roubadas como vetor inicial mais comum (16%) (2024)
- OPSWAT/Ponemon — Insider Threat Statistics 2025 — 61% das organizações sofreram violações por insiders (2025)
- ISO/IEC 27001:2022 — Norma mundial para sistemas de gestão de segurança da informação (2022)
- ISO/IEC 27002:2022 — Controles de segurança da informação incluindo controle de acesso (2022)
- COSO — Internal Control Integrated Framework — Segregação de funções como atividade de controle essencial (2013)
- IBGC — Guia das Melhores Práticas para Organizações do Terceiro Setor — Governança para OSCs: riscos, transparência e políticas (2016)
- Rede Filantropia — Boas Práticas de Governança em OSCs — Governança como sistema de práticas e responsabilidades (2024)
- CFESS — Código de Ética do/a Assistente Social — Arts. 15 a 17: sigilo profissional como direito e dever (1993, atualizado em 2011)
Escrito por Equipe Nexus
Equipe Nexus Social dedicada a compartilhar conhecimento e tecnologia para o fortalecimento do terceiro setor.