Access management

O que é o RBAC e como resolve o problema de acessos

Alex Muntyan Aug 2, 2026

O controlo de acesso baseado em funções (RBAC) é um método de gestão de direitos de acesso que atribui permissões a funções em vez de a pessoas individuais. O utilizador obtém acesso ao ser colocado numa função, e a função tem associado um conjunto predefinido de permissões. Em vez de tomar 50 decisões individuais de permissão para um novo colaborador, toma-se uma só: «esta pessoa é contabilista». A função já sabe a que podem aceder os contabilistas.

A maioria das organizações chega ao RBAC da mesma forma: através do custo acumulado de gerir acessos sem ele. Quando entra um novo colaborador, a equipa de TI reconstrói as permissões de raiz, normalmente copia o acesso de um colaborador existente e adia a limpeza indefinidamente. Com o tempo, isto produz uma estrutura de permissões que ninguém consegue explicar por completo e que ninguém consegue auditar com confiança.

Este é o problema de acessos que o RBAC foi concebido para resolver.

O RBAC em resumo: 8 pontos principais

O RBAC existe para substituir decisões de acesso manuais e pontuais por uma estrutura definida uma só vez e reutilizada em cada contratação, saída e auditoria.
O RBAC atribui o acesso por função profissional (a função RBAC), e não por pessoa, o que reduz a integração de colaboradores de horas para um único clique.
Resolve a saída de colaboradores ao ligar a remoção de acessos à remoção da função, o que fecha a lacuna em que ex-colaboradores mantêm acesso aos sistemas.
O RBAC não é segurança automática. Exige funções definidas e manutenção contínua, caso contrário regressa ao caos.
A maioria das organizações só precisa de 5 a 10 funções para começar. Criar demasiadas funções cedo demais provoca a explosão de funções (role explosion), o que recria a complexidade que o RBAC deve eliminar.
O RBAC já funciona por baixo das ferramentas que a equipa utiliza diariamente: AWS IAM, Kubernetes, GitHub, Salesforce, Google Workspace e Microsoft 365 assentam o controlo de acesso no mesmo modelo utilizador-função-permissão.
O princípio do menor privilégio passa a ser o resultado por defeito, e não uma política que alguém tem de aplicar caso a caso.
No Passwork, as funções controlam os direitos administrativos e os grupos controlam o acesso aos cofres. Ter uma função de administrador não concede, por si só, acesso a quaisquer dados de palavras-passe.

O que é o controlo de acesso baseado em funções (RBAC)

O RBAC é um método de gestão de acessos que atribui permissões a funções em vez de a pessoas individuais. Uma pessoa obtém acesso ao ser atribuída a uma função, e a função determina o que pode ver e fazer. Quando a função muda, o acesso muda com ela, automaticamente.

Três componentes tornam isto possível:

Utilizadores são as pessoas (ou contas de serviço) que precisam de acesso.
Funções correspondem a funções profissionais: Programador, Contabilista, Gestor de RH, Visualizador só de leitura.
Permissões são as ações específicas que uma função pode executar, como ler uma base de dados ou editar um ficheiro partilhado.

O fluxo é simples: Utilizador → Função → Permissões. Atribuída a função uma só vez, o utilizador herda tudo o que lhe está associado.

Elementos de apoio e relações:

Atribuições de funções (mapeamentos) são os mapeamentos que associam utilizadores específicos às funções que estão autorizados a desempenhar.
Sessões permitem ao utilizador ativar um subconjunto das funções que lhe foram atribuídas durante um período de trabalho específico, como uma função de piquete (on-call) que só está ativa durante um turno programado.
Hierarquia de funções é uma estrutura opcional em que as funções superiores ou principais herdam automaticamente as permissões das funções inferiores ou subordinadas.
Restrições são regras que impedem permissões conflituosas, como as regras de segregação de funções (SoD) que impedem uma mesma pessoa de aprovar e processar a mesma fatura.

Estes elementos combinam-se em três modelos RBAC com nome próprio: Core RBAC (apenas utilizadores, funções e permissões), Hierarchical RBAC (acrescenta a hierarquia de funções) e Constrained RBAC (acrescenta restrições como a SoD).

A origem do RBAC
David Ferraiolo e Richard Kuhn introduziram o controlo de acesso baseado em funções num artigo apresentado na 15th National Computer Security Conference , em Baltimore. O artigo sustenta que o controlo de acesso discricionário, o modelo dominante na época, não se adequa à forma como as organizações comerciais e da administração pública civil atribuem realmente o acesso, e propõe o RBAC como alternativa não discricionária, construída em torno de funções profissionais e não de identidades individuais.
→ Ferraiolo, D.F. e Kuhn, D.R., «Role-Based Access Controls» (1992), NIST

O RBAC no mundo real: onde é mais relevante

O RBAC funciona por baixo da maioria das ferramentas que a equipa já utiliza:

AWS Identity and Access Management (IAM) atribui funções como Programador ou Auditor só de leitura para controlar quem pode iniciar servidores e quem só pode consultar logs.
Kubernetes RBAC usa objetos Role e ClusterRole para decidir quem pode fazer implementações num cluster e quem apenas o pode inspecionar.
Google Workspace e Microsoft 365 incluem níveis administrativos integrados, de Super Admin a Helpdesk Admin, para que um agente de suporte possa repor uma palavra-passe sem aceder às definições de faturação.
GitHub separa o acesso aos repositórios nas funções Read, Triage, Write, Maintain e Admin.
Salesforce usa perfis e conjuntos de permissões para decidir que registos pode ver um representante de vendas em comparação com um gestor de vendas.
Plataformas de bases de dados como o PostgreSQL e o Snowflake atribuem funções de leitura, escrita ou administração ao nível do esquema, para que um analista de dados possa consultar tabelas sem poder eliminá-las.

Estes são os mesmos três componentes abordados anteriormente (utilizadores, funções, permissões), apenas implementados de forma diferente em cada plataforma. Três situações mostram o benefício de forma mais clara.

Equipas em crescimento. Com 10 pessoas, as permissões ad hoc funcionam bem. Com 30, começam a falhar. Com 100, são um incidente de segurança à espera de acontecer. O Slack ilustra o padrão em pequena escala: as funções Owner, Admin, Member e Guest existem precisamente porque «todos podem fazer tudo» deixa de funcionar quando um espaço de trabalho ultrapassa algumas dezenas de utilizadores. Este limite de escala explica em parte por que se prevê que o mercado mundial de RBAC cresça a uma taxa de crescimento anual composta (CAGR) de cerca de 12 % até 2030, segundo a Fortune Business Insights (2024). O RBAC escala através da gestão de funções, não do número de colaboradores.
Conformidade e auditoria. Um auditor de SOC 2 pede uma revisão de acessos. Sem RBAC, isso significa exportar uma dúzia de folhas de cálculo e passar uma semana a cruzar quem tem acesso a quê. Com RBAC, um único relatório baseado em funções dá a resposta: consulta-se a função «Finanças» na plataforma de bases de dados ou na consola de IAM e obtêm-se, numa hora, todas as contas que a detêm.
Trabalho remoto e híbrido. Quando as pessoas trabalham a partir de qualquer lugar, o acesso a sistemas sensíveis exige um controlo que não dependa de estar dentro de uma rede de escritório. Este é o núcleo operacional da arquitetura zero trust, conforme definida na NIST SP 800-207: as decisões de acesso baseiam-se na identidade e na função, não na localização na rede. O RBAC cumpre essa promessa, ao associar o acesso à função profissional, independentemente do local a partir do qual alguém inicia sessão.

O problema de acessos: 5 sinais de que as permissões estão um caos

Se a organização apresenta dois ou mais destes cinco padrões, o modelo de acessos já falhou e está, silenciosamente, a aumentar o risco de violação de dados a cada novo colaborador e a cada saída.

A integração de colaboradores demora dias, não horas. A equipa de TI atribui as permissões manualmente, sistema a sistema, porque não existe um modelo para «o que um programador precisa». Cada novo colaborador torna-se uma nova negociação.
A saída de colaboradores é um jogo de adivinhas. Quando alguém sai, ninguém tem total confiança de que todos os pontos de acesso foram revogados. Contas antigas permanecem em ferramentas que ninguém se lembra de verificar.
«Basta copiar as permissões da Karen.» Os novos colaboradores herdam o acesso que um colaborador existente foi acumulando, incluindo anos de permissões adicionais que ninguém removeu. É assim que se propaga a acumulação indevida de privilégios (privilege creep).
O auditor pergunta quem tem acesso a determinado recurso e não é possível responder em menos de uma hora. Não existe uma fonte única de verdade. Responder implica abrir vários sistemas e fazer o cruzamento manualmente.
Todos são administradores locais nalgum sítio. Os privilégios proliferam por servidores, ferramentas SaaS e partilhas de ficheiros, até ninguém, incluindo a equipa de TI, ter uma visão completa. Este padrão é comum: o Data Breach Investigations Report de 2024 da Verizon concluiu que 74 % de todas as violações de dados envolvem o fator humano, incluindo o uso indevido de privilégios e erros de acesso.

De acordo com a Palo Alto Networks , no relatório 2026 Identity Security Landscape, 96 % dos inquiridos afirmam que as identidades humanas operam com acessos muito superiores aos que as respetivas funções exigem. Cada caixa não verificada acima é uma porta que alguém se esqueceu de trancar.

Se a organização se reconheceu nos 5 sinais de que as permissões estão um caos, é provável que o acesso a credenciais também faça parte desse quadro. Iniciar um teste gratuito do Passwork e configurar o primeiro cofre baseado em funções em menos de 10 minutos.

Como o RBAC resolve cada problema de acesso

O RBAC substitui as suposições por trás de cada problema da lista anterior por um processo definido e repetível.

A integração de colaboradores passa a ser uma única atribuição. Defina a função Programador júnior uma só vez, abrangendo o repositório do GitHub, o pipeline de CI/CD, o servidor de staging e o chat da equipa. Novo colaborador, uma função, tudo tratado.
A saída de colaboradores fica completa. Ao remover a função, todas as permissões a ela associadas desaparecem também. Acabou a busca por 15 sistemas para saber onde o ex-colaborador ainda poderá ter uma sessão ativa.
Fim da clonagem de permissões. Cada novo colaborador começa exatamente com as permissões da sua função, e não com uma cópia dos sete anos de acessos acumulados de um colega.
As auditorias tornam-se rápidas. «Quem tem acesso à base de dados financeira?» Basta executar um relatório filtrado por função. A resposta surge em segundos, com um registo de auditoria que mostra quando e porque mudou o acesso.
O princípio do menor privilégio passa a ser a regra, não a exceção. O princípio do menor privilégio consiste em dar às pessoas o acesso mínimo necessário para desempenharem o seu trabalho. As funções definem esse mínimo. Ninguém recebe acesso adicional «por precaução», porque não há nenhuma decisão caso a caso a tomar.

Começar com o RBAC: os primeiros 3 passos

Implementar o RBAC não exige um projeto de seis meses. A maioria das organizações consegue definir uma estrutura de funções operacional numa tarde e aperfeiçoá-la a partir daí.

Mapeie as funções. Liste todas as funções profissionais da organização. Evite a tentação de sobrecomplicar. Comece com 5 a 10 funções: Engenharia, Finanças, RH, Administração de TI, Só de leitura. As funções podem ser subdivididas mais tarde, quando surgirem padrões.
Passo 2. Defina o que cada função exige. Para cada função, liste o acesso mínimo necessário para desempenhar o trabalho. Em caso de dúvida, deixe de fora. Acrescentar acesso mais tarde é uma tarefa pequena. Descobrir que alguém tinha acesso que não devia ter é um problema muito maior.
Passo 3. Audite o que existe. Compare as permissões atuais com as novas definições de funções. A diferença entre o que as pessoas têm e o que a sua função deveria conceder é a lista de limpeza.

Para as equipas que gerem credenciais partilhadas, palavras-passe de servidores, chaves de API e painéis de administração, o Passwork aplica este mesmo modelo RBAC ao cofre de palavras-passe. Defina uma função Programadores com acesso às credenciais de desenvolvimento e de staging. Defina uma função Finanças com acesso às credenciais bancárias e de faturação. Ninguém vê tudo, e o acesso muda automaticamente quando as funções mudam.

Como o Passwork implementa o RBAC: funções, grupos e tipos de cofre

O Passwork divide o controlo de acesso baseado em funções em duas camadas distintas:

As funções controlam o que um utilizador pode configurar no sistema
Os grupos controlam os dados que um utilizador pode ver

Um utilizador pode ter uma função administrativa e, ainda assim, não ter qualquer acesso a um determinado cofre, porque o acesso aos cofres resulta exclusivamente da pertença a grupos, não da função.

Funções: permissões administrativas

Uma função no Passwork define direitos administrativos ao nível do sistema, não acesso a dados. As três funções predefinidas são Proprietário, Administrador, que gere utilizadores, definições de autenticação, integrações e licenciamento, e Utilizador, que não tem privilégios administrativos. As funções personalizadas podem restringir ainda mais este âmbito, por exemplo uma função de Auditor que pode consultar registos de segurança e gerar relatórios de acesso sem poder criar utilizadores nem alterar definições do sistema.

É importante notar que ter a função de Administrador não concede automaticamente acesso ao conteúdo de qualquer cofre. No modo Zero-Knowledge , os administradores não conseguem ler dados de palavras-passe, a menos que sejam adicionados separadamente a um cofre através de um grupo ou de uma atribuição individual.

Grupos: acesso aos dados

Um grupo é o que determina, na prática, os cofres e as pastas que um utilizador pode ver e utilizar. Em vez de atribuir um cofre a 12 programadores individuais, um a um, o administrador atribui-o uma só vez ao grupo Programadores, e todos os membros atuais e futuros herdam esse acesso automaticamente.

Este é o mecanismo que corresponde diretamente ao modelo RBAC descrito anteriormente neste artigo: o grupo é a função, no sentido do controlo de acesso, e as permissões do cofre são as permissões associadas a essa função.

Os grupos podem ser criados manualmente ou sincronizados a partir do Active Directory ou do LDAP, pelo que um grupo de segurança Finanças existente no AD corresponde a um grupo equivalente no Passwork, com as alterações de pertença a propagarem-se sem trabalho manual de ambos os lados.

Isto responde diretamente à questão anterior sobre grupos do AD versus RBAC: um grupo do Passwork associado a uma estrutura de cofres definida confere a esse grupo do AD uma finalidade explícita e auditável, em vez de o deixar como um conjunto de permissões sem etiqueta que ninguém consegue explicar.

Tipos de cofre: onde residem os limites de acesso

Um cofre é um contentor cifrado para palavras-passe e segredos, organizado numa estrutura de pastas com vários níveis. Todos os cofres são criados como privados por defeito, visíveis apenas para o proprietário, e passam a ser partilhados quando o proprietário lhes adiciona outros utilizadores ou grupos. Os administradores também podem marcar cofres como ocultos, para manter a navegação organizada para os utilizadores que não precisam de os ver com regularidade.

Num cofre partilhado, a cada grupo ou utilizador é atribuído um de vários níveis de acesso: Proibido, Só de leitura, Ler e editar, Acesso total ou Administrador. Um grupo de prestadores de serviços externos pode ter acesso Só de leitura a uma única pasta, enquanto o grupo da equipa principal tem Acesso total a tudo o resto, sem ser necessário separar as credenciais num cofre distinto.

O resultado é uma separação clara que reflete, em geral, um bom desenho de RBAC: as funções regem o sistema, os grupos regem os dados e os cofres definem o limite onde esses dados residem.

Ultrapassar o caos

Cada integração de colaboradores não planeada custa tempo real: as duas horas que a equipa de TI gasta a adivinhar permissões para cada novo colaborador e a hora dedicada a reconstituir o histórico de acessos quando um auditor pergunta quem consegue aceder a quê. O RBAC transforma esse custo recorrente numa configuração única. Defina as funções uma só vez e cada contratação, saída e auditoria assenta numa estrutura que já tem a resposta.

As funções exigem revisão periódica para se manterem corretas à medida que as equipas e as responsabilidades mudam. Começar com 5 a 10 funções esta semana dá à maioria das organizações uma estrutura funcional que um ano de correções de permissões ad hoc nunca produz.

As equipas que partilham palavras-passe entre ferramentas, servidores e serviços podem aplicar este mesmo modelo às credenciais. Os cofres baseados em funções do Passworkatribuem o acesso às palavras-passe por grupo, de modo que cada equipa veja exatamente as credenciais de que a sua função necessita.

Configurar o primeiro cofre baseado em funções no Passwork e verificar a rapidez com que uma estrutura definida substitui as verificações manuais de permissões. Iniciar um teste gratuito.

FAQ: Respostas rápidas a perguntas comuns sobre RBAC

Qual é a diferença entre o RBAC e o ABAC?

O RBAC atribui acesso por função (ou função profissional). O ABAC (controlo de acesso baseado em atributos) atribui acesso com base em atributos como a hora, a localização ou o dispositivo. A maioria das organizações deve começar pelo RBAC. É mais simples e abrange a maioria dos casos de utilização. Mais tarde, pode acrescentar-se o ABAC para regras de granularidade fina, como o acesso apenas por VPN durante o horário de expediente.

De quantas funções preciso?

Comece com 5 a 10 funções, uma por cada função profissional distinta: RH, Engenharia, Finanças, Administração de TI, Só de leitura. É sempre possível acrescentar mais. O erro comum é criar centenas de funções cedo demais, a chamada explosão de funções (role explosion), que anula o propósito do RBAC ao recriar a mesma complexidade que se pretendia eliminar.

Qual é a diferença entre o RBAC e simplesmente colocar pessoas em grupos do AD?

Os grupos do Active Directory podem implementar o RBAC, mas por si só não são RBAC. O RBAC exige funções associadas explicitamente a permissões definidas, com uma justificação documentada. Um grupo do AD sem uma definição clara daquilo a que dá acesso, ou porquê, é apenas caos com outra etiqueta.

O RBAC funciona numa pequena empresa de 15 pessoas?

Sim. As equipas pequenas são, muitas vezes, as que mais beneficiam, uma vez que é mais fácil definir funções antes de a proliferação de acessos se instalar. Comece com 3 a 5 funções abrangentes que cubram as principais áreas. O erro é esperar até a empresa chegar às 50 pessoas e o acesso já estar emaranhado.

Como justificar o RBAC perante a direção?

Apresente-o em termos de risco e de tempo, não de tecnologia. Refira o custo médio de uma violação de dados de 4,88 milhões de dólares (IBM, 2024) e o facto de 74 % das violações envolverem erro humano ou uso indevido de privilégios (Verizon DBIR, 2024). Em seguida, mostre o tempo atualmente gasto em integração e saída de colaboradores manuais e na preparação de auditorias. O RBAC reduz ambos.