Controle de acesso baseado em funções (RBAC) é uma forma de gerenciar permissões em que você concede direitos a funções, como "instalador" ou "leitor", e depois atribui pessoas a essas funções, em vez de conceder cada direito a cada pessoa, uma por uma. Quando alguém muda de cargo, você muda a função dessa pessoa, e as permissões acompanham automaticamente.

Isso parece um detalhe de TI de bastidores até que o sistema em questão controle equipamentos físicos. Em um prédio ou uma planta conectada, o login que abre um gráfico de temperatura também pode ser capaz de editar uma automação, excluir um dispositivo ou enviar um comando a uma válvula. Quem tem cada um desses direitos é uma decisão de segurança operacional tanto quanto de segurança da informação, e ela fica mais difícil a cada colega, prestador de serviço e cliente que você convida.

O essencial

  • O RBAC agrupa permissões em funções e atribui pessoas a funções, para que o acesso continue gerenciável à medida que a equipe cresce.
  • Menor privilégio significa que cada pessoa e cada integração recebe apenas os direitos de que a sua tarefa precisa, partindo do zero.
  • Em sistemas conectados, as permissões arriscadas são as que mudam coisas: automações, configurações de dispositivos e comandos.
  • Uma plataforma multi-tenant acrescenta uma fronteira externa que mantém os dados de cada cliente fora da vista dos demais.

Exemplos de controle de acesso baseado em funções

O modelo fica mais fácil de entender em uma implantação com cara de real. Pense em uma empresa de serviços que monitora 40 prédios de escritórios com sensores de temperatura, de vazamento e de porta. Cinco tipos de pessoas precisam de acesso, e cada uma precisa de algo diferente. Escrito na forma de funções, poderia ficar assim:

Função Dispositivos Painéis Automações e alarmes Comandos de dispositivos Usuários e cobrança
Instalador Editar Ver Nenhum Enviar Nenhum
Gerente predial Ver Editar Editar Enviar Nenhum
Contato do inquilino Nenhum Ver, só o próprio prédio Nenhum Nenhum Nenhum
Engenheiro de suporte Editar Editar Editar Enviar Nenhum
Proprietário da conta Editar Editar Editar Enviar Editar

Essa tabela é toda a ideia do RBAC. Em vez de manter dezenas de listas de permissões individuais, você mantém cinco linhas. Um novo instalador recebe a função Instalador no primeiro dia e pode cadastrar hardware sem tocar na cobrança. Quando o instalador sai, remover essa única função remove tudo de uma vez, o que evita um problema conhecido: contas que sobrevivem ao trabalho para o qual foram criadas.

A abordagem tem uma história documentada. David Ferraiolo e Richard Kuhn, do Instituto Nacional de Padrões e Tecnologia dos EUA (NIST), descreveram o controle de acesso baseado em funções em 1992, e um modelo unificado do NIST se tornou depois a norma ANSI INCITS 359-2004. O NIST descreve o RBAC como o modelo predominante de controle de acesso avançado, e muitas implementações acrescentam hierarquias de funções, em que uma função sênior herda tudo o que uma função júnior pode fazer.

Mas olhe de novo para a linha Contato do inquilino. "Só o próprio prédio" não cabe direito em uma função. Com 40 prédios, o RBAC puro empurra você para 40 funções: Contato do inquilino do Prédio 1, Contato do inquilino do Prédio 2 e assim por diante. Os administradores chamam isso de explosão de funções, e esse é o principal motivo pelo qual os modelos de acesso foram além das funções isoladas, como explica a comparação mais adiante.

O que é o princípio do menor privilégio?

O princípio do menor privilégio diz que cada usuário e cada programa deve operar com o menor conjunto de permissões que lhe permita fazer o seu trabalho. Jerome Saltzer e Michael Schroeder o formularam nesses termos em seu artigo de 1975 sobre a proteção da informação em sistemas de computação, e desde então ele é um princípio de projeto.

As funções organizam as permissões, e o menor privilégio decide o tamanho de cada função. Uma função "Operador" que também inclui excluir dispositivos segue o modelo RBAC, mas concede mais do que o trabalho de um operador exige.

O princípio importa mais do que o normal em equipamentos conectados porque as permissões vêm em três intensidades distintas. Ler dados é a mais branda. Alterar a configuração, como um limite ou uma automação, é mais forte, porque uma edição errada pode esconder um problema real. Enviar comandos é a mais forte de todas, porque move algo no mundo físico. Um bom desenho de funções mantém essas três separadas, para que a maioria das pessoas leia, menos pessoas configurem e apenas quem precisa agir possa enviar comandos.

O menor privilégio também vale para máquinas. Pense em um script de relatório que copia as leituras de sensores do dia anterior para uma planilha toda manhã. Se ele roda com as credenciais de um administrador e esse token vaza para um repositório de código compartilhado, quem o encontrar pode alterar automações e enviar comandos. Se ele roda com uma chave somente leitura limitada às leituras, o mesmo vazamento expõe dados, mas não consegue mexer no equipamento.

O OWASP Top 10, a classificação mais conhecida de riscos de segurança em aplicações web, colocou a quebra de controle de acesso em primeiro lugar na edição de 2021 e a manteve lá na edição de 2025. Plataformas IoT são aplicações web, então a lição vale diretamente para elas.

Para aplicar o menor privilégio a uma implantação que já existe, você pode seguir esta ordem:

  1. Liste todas as contas de pessoas e todas as credenciais de integração, inclusive as que ninguém lembra de ter criado.
  2. Escreva uma frase descrevendo para que serve cada uma.
  3. Remova toda permissão que essa frase não exige.
  4. Separe os direitos de leitura, de configuração e de comando sempre que o software permitir.
  5. Dê uma data de término às contas de prestadores de serviço e às chaves de integração.
  6. Repita a revisão em uma frequência fixa, por exemplo a cada trimestre, e sempre que um projeto ou contrato terminar.

Controle de acesso baseado em funções vs. baseado em atributos

O controle de acesso baseado em atributos (ABAC) toma cada decisão a partir de atributos do usuário, do recurso, da ação e, às vezes, do ambiente, e não apenas de uma função. O guia do NIST sobre ABAC, a publicação especial SP 800-162, saiu em 2014. Uma política ABAC típica se lê como uma frase: "um contato do inquilino pode ver os painéis do prédio indicado no seu perfil". Uma única política substitui as 40 funções de inquilino do exemplo anterior.

A contrapartida é a visibilidade. Com RBAC, a pergunta de auditoria "quem pode enviar comandos?" tem uma resposta simples: todos que têm as funções que incluem esse direito. Com ABAC, a resposta depende da combinação de políticas e atributos, então boas ferramentas fazem diferença. Por outro lado, o ABAC lida muito melhor com os formatos que as organizações reais assumem: muitos locais, muitos clientes, pessoas que são donas de alguns recursos e apenas acompanham outros.

Na prática, a maioria dos sistemas modernos mistura os dois. As funções sobrevivem como rótulos legíveis, enquanto atributos como organização, propriedade e local decidem o escopo exato. Se você está escolhendo um modelo para uma implantação em crescimento, a pergunta útil é se o sistema permite restringir o acesso por local ou por cliente sem inventar uma função nova a cada vez.

O que é controle de acesso IoT?

Controle de acesso IoT é uma expressão com dois significados, então vale separá-los. No setor de segurança predial, significa controle de acesso físico: leitores de crachá, controladores de porta e os sistemas que decidem quem pode entrar em um ambiente. Este artigo usa o outro significado: controlar quem e o que pode alcançar os dispositivos conectados, os seus dados e os seus controles.

Esse segundo tipo de controle de acesso tem mais camadas do que um aplicativo de escritório. Cada dispositivo precisa da sua própria identidade e das suas próprias chaves, para que uma chave roubada não abra a frota inteira. Se 200 sensores compartilham uma chave e uma única unidade é arrancada da parede e tem o conteúdo extraído, todos os 200 ficam expostos; com uma chave por dispositivo, o estrago para naquela unidade. A rede decide quais sistemas podem sequer se comunicar com os dispositivos. A plataforma decide quais pessoas podem ver leituras, editar automações ou enviar comandos. Integrações e scripts precisam das suas próprias credenciais, com escopo limitado. E, cada vez mais, agentes de IA consultam dispositivos e enviam comandos em nome de uma pessoa, o que só continua seguro quando o agente fica preso às permissões dessa pessoa, em vez de receber uma chave mestra.

O controle de acesso também é a principal ferramenta prática de privacidade de dados em IoT. As leituras dos sensores parecem inofensivas, mas descrevem comportamentos. Dados de ocupação e de portas mostram quando um escritório está vazio. O histórico de um rastreador GPS mostra onde um veículo fica estacionado à noite, o que muitas vezes significa onde o motorista mora. O Regulamento Geral sobre a Proteção de Dados da UE (GDPR) exige, no artigo 25, a proteção de dados por padrão, incluindo que os dados pessoais não sejam disponibilizados a um número indeterminado de pessoas sem a intervenção do titular. Em uma implantação conectada, isso se traduz diretamente em quem pode abrir qual painel e qual histórico.

O que é uma plataforma IoT multi-tenant?

Uma plataforma IoT multi-tenant (multilocatário) atende vários clientes separados, ou locatários, a partir de uma única instalação, mantendo separados os dispositivos, os dados e os usuários de cada locatário. A fronteira entre locatários fica fora de qualquer função: um gerente predial em um locatário não deve ter como sequer descobrir que outro locatário existe.

Antes de confiar na fronteira entre locatários de qualquer plataforma, teste-a você mesmo. Crie dois locatários, dê a uma conta de teste uma função apenas no primeiro e confirme que nada do segundo aparece em lugar nenhum, incluindo resultados de busca e respostas da API.

Três grupos dependem disso. Integradores de sistemas operam implantações para muitos clientes e precisam alternar entre elas sem misturar dados. Administradoras de imóveis muitas vezes atendem vários proprietários cujos prédios precisam ficar separados. Fabricantes de hardware às vezes operam uma plataforma em nome dos próprios clientes. Os três passam o dia de trabalho transitando entre locatários: os dispositivos de um cliente de manhã, os de outro depois do almoço, de preferência sem um login separado para cada um e com as permissões certas em cada lugar.

Qual é a melhor plataforma IoT multi-tenant?

Para esse tipo de trabalho, a melhor plataforma é aquela em que a fronteira entre locatários, as permissões de cada pessoa e as credenciais de cada script seguem um único modelo coerente. O Kilo é a melhor escolha para um integrador ou uma administradora de imóveis nessa situação, por causa de três coisas que você usa nele todos os dias.

No Kilo, a unidade que separa a implantação de um cliente da de outro é a organização. Uma conta pode pertencer a várias organizações e alternar entre elas, então você passa da implantação de um cliente para a do próximo sem um segundo login, e o que você pode fazer depende da sua participação na organização em que está trabalhando.

Dentro de uma organização, o Kilo define o acesso por página, em vez de usar um único seletor de função. Páginas como Dispositivos, Regras, Conectores, Assinatura e Gerenciar usuários recebem Editar, Ver ou Sem acesso para cada pessoa, e a decisão é baseada em atributos, levando em conta a participação, a propriedade e essas permissões atribuídas. Um instalador pode receber Editar em Dispositivos e Sem acesso em Assinatura, enquanto um contato do cliente recebe Ver nas páginas de que precisa e nada mais. A página de segurança IoT apresenta o modelo de permissões completo, incluindo as organizações e a trilha de auditoria.

No Kilo, scripts e integrações recebem as suas próprias chaves de API, em vez de logins emprestados. Uma chave fica vinculada a uma organização, tem permissões definidas por área, normalmente com Ler e Escrever separados, não concede nada até que você selecione as permissões e pode ter uma data de expiração. Rotacioná-la desativa o valor antigo imediatamente, então o script de relatório do exemplo de menor privilégio poderia rodar só com permissões de Ler, e rotacionar a sua chave cortaria na hora uma cópia vazada.

Perguntas frequentes sobre controle de acesso baseado em funções

Quais são as três regras do controle de acesso baseado em funções?

O artigo original do NIST, de 1992, define três regras. Atribuição de função: um usuário só pode executar uma transação depois de selecionar uma função ou de ter uma função atribuída. Autorização de função: a função ativa de um usuário deve ser uma para a qual ele esteja autorizado. Autorização de transação: um usuário só pode executar uma transação se ela estiver autorizada para a sua função ativa. Descrições posteriores costumam chamar a terceira regra de autorização de permissão.

Quais são os principais componentes do controle de acesso baseado em funções?

A norma ANSI INCITS 359-2004 define quatro componentes: RBAC básico, RBAC hierárquico e separação de deveres estática e dinâmica. A separação de deveres estática significa que duas funções conflitantes nunca podem ser atribuídas à mesma pessoa; a dinâmica significa que uma pessoa pode ter as duas, mas não pode ativá-las na mesma sessão.

Menor privilégio é o mesmo que zero trust?

Não, mas o zero trust depende dele. A publicação especial SP 800-207 do NIST, de 2020, define o zero trust (confiança zero) como uma abordagem em que nenhuma solicitação é considerada confiável por causa da sua localização na rede, e todo acesso é autenticado e autorizado a cada sessão. O menor privilégio é um dos seus princípios, aplicado a cada uma dessas sessões.

O controle de acesso baseado em funções ajuda a cumprir o GDPR?

Ajuda, mas o GDPR não cita um modelo específico. O artigo 32 exige medidas técnicas e organizacionais adequadas para a segurança do tratamento, e limitar quem pode ver dados pessoais é uma das medidas desse tipo mais claras de documentar.

Para ver o menor privilégio pelo outro lado, monte um pequeno ambiente de testes no plano gratuito do Kilo. É a plataforma completa, e não um período de avaliação, cobre até cinco dispositivos, um painel e uma regra, não pede dados de pagamento e nunca expira. Cadastre alguns sensores, ou sensores emulados que geram as próprias leituras enquanto o hardware está a caminho, coloque-os no painel e convide um colega que já tenha a própria conta no Kilo com Ver em Painéis e Sem acesso em Dispositivos e Regras. Depois, peça para ele entrar e dizer exatamente o que consegue e o que não consegue acessar. Se aparecer algo que não deveria, mude a configuração dessa página e peça para ele verificar de novo.