O controlo de acesso baseado em funções (RBAC, do inglês role-based access control) é uma forma de decidir quem pode fazer o quê num sistema, associando permissões a funções e atribuindo depois as pessoas a essas funções. Ninguém recebe permissões uma a uma. Um comercial, um controller financeiro e um responsável de suporte recebem, cada um, o acesso de que o seu trabalho precisa, e nada mais. Este guia explica como funciona o RBAC, como definir funções que se mantêm geríveis, quando o controlo de acesso baseado em atributos (ABAC) é a melhor opção e o que muda quando os agentes de IA começam a ler e a escrever os dados da sua empresa.

Em resumo

Índice

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

O RBAC é um modelo para autorizar o acesso a sistemas, aplicações e dados com base na função predefinida de um utilizador. A IBM descreve-o como um administrador que atribui a cada utilizador uma ou mais funções, representando cada função um conjunto de permissões ou privilégios.

A característica essencial é que todo o acesso passa por funções. De acordo com as perguntas frequentes do NIST Computer Security Resource Center, uma função é, no essencial, um conjunto de permissões, e os utilizadores recebem permissões apenas através das funções que lhes são atribuídas ou que herdam através de uma hierarquia de funções. É isto que distingue o RBAC dos grupos comuns, em que as permissões podem estar associadas tanto a utilizadores como a grupos. O NIST observa que isto cria uma brecha que torna difícil controlar as relações entre utilizadores e permissões.

Um exemplo concreto para uma empresa de SaaS:

Função Acesso típico no CRM Acesso típico no sistema financeiro Acesso típico na administração do produto
Account Executive Contas e negócios próprios, leitura e escrita Nenhum Nenhum
Sales Manager Contas da equipa, vistas de previsão Estado das faturas, só de leitura Nenhum
Finance Controller Dados de contas, só de leitura Faturação e relatórios completos Nenhum
Customer Success Manager Contas atribuídas, campos de renovação Estado das faturas, só de leitura Definições limitadas do tenant
Support Engineer Contactos das contas, só de leitura Nenhum Diagnóstico do tenant
Administrador Configuração Configuração Completo

Quando um novo account executive se junta à equipa, atribui-se uma única função. Não é preciso recriar uma dúzia de escolhas individuais de permissões.

Como funciona o RBAC: as três regras e os quatro componentes

O modelo do NIST assenta em três regras, tal como descritas na publicação do NIST Role Engineering: Methods and Standards:

  1. Atribuição de função. Um utilizador só pode usar uma permissão se lhe tiver sido atribuída uma função.
  2. Autorização de função. A função ativa do utilizador tem de estar autorizada para esse utilizador.
  3. Autorização de permissão. Um utilizador só pode usar uma permissão se esta estiver autorizada para a função ativa do utilizador.

A mesma publicação regista que o NIST propôs um modelo RBAC unificado em 2000 e que este foi aprovado em 2004 como norma nacional dos EUA INCITS 359-2004.

Essa norma tem quatro componentes, segundo o documento ANSI INCITS 359-2004:

A separação de funções é mais importante na área financeira. A pessoa que cria um pagamento a um fornecedor não deve ser a que o aprova. A separação estática de funções garante isso no momento da atribuição, que é a forma mais simples e mais auditável de o fazer.

Como definir funções que se mantêm geríveis

É na conceção que a maioria dos projetos de RBAC tem sucesso ou falha. Um conjunto de funções que reflete o modo como a empresa trabalha é fácil de explicar e de rever. Um conjunto de funções que reflete as caixas de seleção de cada ferramenta torna-se um labirinto.

Comece pelas funções de negócio

A orientação de implementação da IBM afirma que as conceções mais robustas partem das funções e dos fluxos de trabalho do negócio, e não dos menus das aplicações. Em vez de perguntar que caixas assinalar no CRM, pergunte o que um vendedor faz realmente e depois expresse essas atividades como definições de funções que possam ser mapeadas para vários sistemas.

Este último ponto é prático. Uma função de “Customer Success Manager” deve significar o mesmo no seu CRM, na ferramenta de faturação, no helpdesk de suporte e em qualquer portal interno. Define-a uma vez como função de negócio e depois mapeia-a para cada sistema.

Uma função de negócio mapeada em quatro sistemas

Escolha uma abordagem de engenharia de funções

A publicação do NIST sobre engenharia de funções descreve três abordagens:

A documentação de identidade da Oracle também recomenda a abordagem híbrida para a descoberta de funções (role mining). Para uma empresa com 20 a 200 pessoas, a abordagem híbrida é normalmente realista. Dedique algumas horas ao responsável de cada área para esboçar as funções, depois exporte as permissões atuais do seu CRM e do sistema financeiro e veja onde a realidade difere. Combinar as duas evita funções demasiado teóricas e evita construir funções em torno de alguns casos atípicos.

Uma sequência prática

  1. Inventarie os sistemas e os dados. Liste os sistemas que contêm dados de clientes, de receitas e de produto e assinale quais os registos sensíveis.
  2. Esboce as funções por área. Comece por categorias amplas. A IBM observa que as organizações começam frequentemente por separar administradores, especialistas ou utilizadores avançados e utilizadores finais.
  3. Exporte as permissões reais. Extraia o acesso atual de cada pessoa em cada sistema e agrupe padrões semelhantes.
  4. Concilie. Quando alguém tem muito mais acesso do que a sua função esboçada, decida se a função está errada ou se a pessoa acumulou acessos que deve perder.
  5. Nomeie um responsável para cada função. Uma pessoa responde pelo que a função contém.
  6. Aplique e depois reveja. Passe as pessoas para funções, remova as permissões diretas e agende a primeira revisão.

Boas práticas de RBAC a longo prazo

A orientação da IBM é que a saúde de longo prazo do RBAC depende da governação: revisões periódicas de acessos centradas em exceções e casos atípicos, processos de entradas, mudanças e saídas (joiner-mover-leaver) que alteram as funções automaticamente a partir de eventos de RH, e exceções aprovadas e limitadas no tempo para acessos fora do comum.

Aplique o privilégio mínimo através da conceção

Um guia de boas práticas de RBAC empresarial da Avatier enumera quatro mecanismos que produzem o privilégio mínimo:

O segundo é o mais frequentemente esquecido. As pessoas que mudam de equipa vão acumulando acessos. Após duas ou três mudanças, um customer success manager pode ter direitos sobre o pipeline de vendas e a faturação que ninguém pretendia.

Evite a explosão de funções

A mesma fonte descreve a explosão de funções como o modo de falha dominante: uma nova função à medida para cada caso excecional. Prevenir é mais barato do que limpar. Atribua um responsável a cada função, prefira combinar funções existentes a criar novas e recertifique de acordo com um calendário. Um teste útil: se uma função proposta tiver apenas um titular, provavelmente é uma exceção e não uma função. Trate-a como uma exceção aprovada e limitada no tempo.

Mantenha a manutenção reduzida

A Okta salienta que o RBAC não exige uma manutenção intensiva: as permissões seguem as funções, pelo que uma nova função profissional passa a ser uma nova função atribuída a muitas pessoas com pouco esforço de administração. Isto só se verifica se o conjunto de funções se mantiver pequeno e limpo, razão pela qual a atribuição de responsáveis e a revisão são importantes.

Uma lista de verificação curta

RBAC vs ABAC: de qual precisa?

O ABAC decide o acesso avaliando, face a uma política, atributos do utilizador, do recurso, da ação e, por vezes, do ambiente. A NIST SP 800-162 define-o assim e observa que as ACL e o RBAC são, em certa medida, casos particulares do ABAC quanto aos atributos utilizados.

Em termos simples: o RBAC pergunta “qual é a sua função?”. O ABAC pergunta “qual é a sua função, em que está a mexer, quanto está em jogo e a partir de onde?”

A comparação da Okta indica que o RBAC se adequa a grupos de trabalho pequenos e de estrutura simples e a ambientes com funções profissionais claramente definidas. O ABAC adequa-se a grupos de trabalho geograficamente dispersos ou definidos no tempo, e a casos em que as necessidades de acesso mudam por documento e não por função.

Pergunta RBAC ABAC
Base da decisão Função Atributos do utilizador, do recurso, da ação e do contexto
O mais fácil de explicar a um auditor Sim Exige mais esforço
Trata “apenas negócios abaixo de um valor definido” Difícil, tende a acrescentar funções Natural
Trata “apenas contas da sua região” Exige uma função por região Natural
Esforço de configuração Menor Maior

A maioria das empresas de SaaS em crescimento não escolhe um só. A equipa de identidade da Okta observa que muitas organizações usam um modelo híbrido: RBAC para níveis de acesso amplos e ABAC para controlos mais granulares. A Avatier faz a mesma observação a partir do outro lado: o RBAC é a base, e as decisões sensíveis ao contexto, como hora, localização, montante ou dispositivo, pertencem ao ABAC aplicado por cima. A regra prática é começar com RBAC e acrescentar regras de atributos apenas onde o número de funções, de outro modo, se multiplicaria, como nos limites regionais ou por dimensão do negócio.

Ferramentas internas e RBAC

As ferramentas internas são onde o controlo de acessos falha silenciosamente. Uma exportação de folha de cálculo do CRM, um painel de administração criado por um só engenheiro, um painel financeiro partilhado por ligação: cada um é um ponto onde as funções são contornadas. Três hábitos ajudam:

Se criar ou comprar portais internos, pergunte como são definidas as funções, quem as pode alterar e se as alterações ficam registadas. São as perguntas que um revisor de segurança ou um questionário de cliente irá colocar.

O RBAC quando entram em cena os agentes de IA

A IA altera a questão do acesso de uma forma específica: um assistente ou agente consegue chegar a muitos sistemas num único pedido. Se estiver ligado através de uma conta de serviço abrangente, pode devolver dados que a pessoa que perguntou nunca esteve autorizada a ver.

A solução não é um novo modelo de segurança. É aplicar o que já tem:

Há também um domínio em que a IA não deve intervir: decidir quem obtém acesso. Atribuir, alterar e aprovar funções deve continuar a cargo de pessoas identificadas, que seguem a sua política. Um agente pode preparar uma lista de revisão ou assinalar valores atípicos, mas a decisão pertence a uma pessoa.

A regulamentação segue na mesma direção. O GDPR, a NIS2 e o EU AI Act dizem todos respeito à forma como os dados e os sistemas são controlados, e um controlo de acesso bem concebido é um dos elementos de base habituais quando as empresas trabalham nestes temas. O RBAC não torna, por si só, uma empresa conforme, e este artigo não constitui aconselhamento jurídico. Pergunte ao seu consultor jurídico o que se aplica ao seu caso.

Para saber mais sobre como a governação e a IA se articulam, consulte o nosso quadro de governação de IA para empresas B2B SaaS.

Perspetiva

Vemos o mesmo padrão em empresas SaaS com 20 a 200 pessoas. As funções nunca foram desenhadas. O acesso foi crescendo a cada nova ferramenta e, depois, chegou a IA e começou a ler tudo isso.

É por isso que construímos numa ordem fixa. Primeiro, a base de dados: os seus dados de CRM e financeiros como fonte de verdade acordada, com funções que significam o mesmo em todos os sistemas. Depois, a camada de IA, que liga esses dados ao assistente que a sua equipa já utiliza. A seguir, os agentes por departamento, para Finance, Sales e Customer Success. Cada camada herda as regras de acesso da que está por baixo.

A nossa posição é que um agente nunca deve merecer mais confiança do que a pessoa que o utiliza. Funciona dentro das permissões dessa pessoa, pede aprovação quando uma ação é relevante e deixa um registo de auditoria. A definição de funções não é uma tarefa secundária de um projeto de IA. É a primeira peça.

Claus Nielsen

Onde a NordOps Consulting se enquadra

Se a sua equipa já utiliza IA, mas ninguém é responsável pela forma como esta toca nos seus dados, o desenho de acessos é um bom primeiro ponto de partida. A NordOps Consulting atua como Fractional Chief AI Officer para empresas B2B SaaS na Europa: uma pessoa identificada que decide onde a IA compensa, estabelece a base de dados e constrói agentes que as suas equipas usam em linguagem corrente, dentro das permissões e com registo de auditoria.

O AI Readiness Assessment é um ponto de partida definido, a partir de €4,500. Para uma responsabilidade contínua, o contrato Fractional CAIO começa em €1,500 por mês. Pode também começar com uma chamada de descoberta gratuita de 30 minutos através do nosso site. Para perceber como o trabalho é faseado, leia como funciona, ou veja o Admin Portal, onde as funções e os acessos dos utilizadores são geridos a par dos agentes.

FAQ

Qual é a diferença entre uma função e uma permissão?

Uma permissão é uma única ação autorizada sobre um recurso, como ler uma fatura ou editar um negócio. Uma função é um conjunto designado de permissões que corresponde a uma função profissional. Os utilizadores recebem funções, e as funções transportam as permissões.

O RBAC é suficiente, ou preciso de ABAC?

Para a maioria das equipas, o RBAC é o ponto de partida certo, por ser simples de explicar e de auditar. Acrescente regras ABAC apenas quando o contexto for relevante, por exemplo para limitar o acesso por região, dimensão do negócio ou hora. Muitas organizações usam ambos: RBAC para níveis amplos e ABAC para o detalhe fino.

Quantas funções deve ter uma empresa?

Não existe um número padrão. Mantenha as funções ligadas a funções profissionais reais, atribua um responsável a cada uma e trate necessidades pontuais como exceções com prazo limitado. Se uma função tiver um único titular, é sinal de que é uma exceção e não uma função.

Com que frequência se devem rever as funções e os acessos?

Defina um calendário regular e faça revisões adicionais sempre que alguém mudar de funções ou sair da empresa. As orientações da IBM recomendam revisões periódicas de acessos centradas em exceções e valores atípicos, e alterações automáticas desencadeadas por eventos de RH. Escolha um ritmo que a sua equipa consiga manter, pois uma revisão falhada é pior do que uma mais leve.

Como devem ser tratados os agentes de IA num modelo RBAC?

Trate-os como agindo em nome de uma pessoa, com a função dessa pessoa e nada mais. Separe as permissões de leitura e de escrita, exija aprovação para ações sensíveis e mantenha um registo de todas as ações. As decisões sobre quem obtém acesso devem continuar a cargo de pessoas.

Fontes