Segurança Digital

Controle de Acesso Baseado em Funções (RBAC)

Diferente de ACLs atribuídas usuário por usuário, RBAC organiza permissões em funções como Morador, Convidado, Instalador e Administrador. O modelo NIST consolidou RBAC0, hierarquias, restrições e segregação de deveres; a ANSI INCITS 359‑2004 formalizou o padrão. Em uma casa inteligente, o benefício é revisar quem pode ver câmeras, criar automações ou destravar portas sem editar cada recurso. O limite aparece quando contexto muda por horário, localização ou estado; nesses casos, ABAC ou políticas complementares evitam explosão de funções.

🛡 Níveis de Segurança

Base

RBAC com funções estáveis e menor privilégio

RBAC atribui permissões a funções e funções a usuários ou identidades. Em vez de conceder `camera.view` a cada pessoa, cria-se Morador, Convidado, Instalador, Porteiro, Administrador da Casa e Administrador da Plataforma. Cada função possui um conjunto controlado. O usuário pode ter várias. A sessão ativa um subconjunto conforme regras. O modelo NIST descreve RBAC base, hierárquico, com separação estática e dinâmica de deveres. A vantagem operacional é que mudanças de pessoal são simples: remover a função do instalador revoga todas as permissões associadas. A revisão pode listar quem tem Administrador. O desenho precisa começar pelas tarefas, não pelos cargos de marketing. Funções devem ser estáveis. `Morador` pode ver e controlar luzes; `Convidado` controla áreas comuns; `Instalador` configura dispositivos durante janela; `Visualizador de Câmeras` vê streams; `Operador de Acesso` gerencia visitantes. Permissões são atômicas: `lights.read`, `lights.control`, `automations.edit`, `cameras.live`, `cameras.export`, `locks.unlock`, `users.manage`, `firmware.update`. Não criar uma permissão `all`. O backend verifica. A UI esconder botão não autoriza. Cada endpoint e ação aplica. A hierarquia pode fazer Administrador herdar Morador, mas heranças profundas escondem privilégios. Documentar e testar. Uma função precisa de owner e revisão. O princípio do menor privilégio exige que o padrão seja nenhum acesso. Novas permissões não entram automaticamente em funções antigas sem análise. Caso contrário, um papel recebe recurso novo sem consentimento. O sistema versiona políticas e registra mudanças. O uso em OIDC pode mapear grupos do IdP para funções locais, mas não confiar em qualquer claim. O issuer e o claim são configurados. A plataforma associa tenant/casa. Um `admin` corporativo não deve virar admin de todas as residências por nome. Namespaces.

Estruturado

Hierarquia e escopo por residência ou recurso

RBAC puro em nível global é insuficiente para plataformas multi-tenant. A função precisa de escopo. O mesmo usuário pode ser Administrador na Casa A e Convidado na Casa B. O vínculo é `subject, role, scope`. O scope pode ser tenant, residence, building, floor ou resource group. As permissões são calculadas dentro. Um integrador pode ser Instalador em 20 casas durante contrato. Não deve listar outras. A API recebe device ID e busca a residência antes de avaliar. Evitar confiar apenas no home ID enviado no token. IDOR é risco. A hierarquia pode existir por escopo. `Administrador da Residência` herda `Morador`, mas não `Administrador da Plataforma`. Esses domínios são separados. Uma função global de suporte deve ser rara, just-in-time e auditada. O suporte não precisa ver vídeo por padrão. Pode ter permissão de diagnóstico sem conteúdo. Escopos de recurso reduzem. Em condomínios, Porteiro pode abrir portões comuns, não portas privadas. Funções podem ser atribuídas a grupos familiares. A herança de grupos precisa de revisão. Se um usuário sai da família, revoga. Convites expiram. O vínculo deve ter início/fim. Isso é um atributo adicional ao RBAC, mas pode ser implementado no modelo de assignment. A análise precisa considerar. Auditoria lista todas as funções efetivas, incluindo herdadas. A UI deve mostrar por que o usuário tem acesso. “Via grupo Família” ou “via papel Instalador”. Isso facilita revogar. O banco mantém histórico. O cache de autorização precisa invalidar ao mudar. Um JWT de 15 min pode conservar função até expirar; para fechaduras, consultar central ou token curto. O projeto decide.

Controle

Segregação de deveres e ativação de função

Segregação estática impede que a mesma pessoa acumule funções incompatíveis. Por exemplo, quem aprova novos instaladores não deve auditar sozinho seus próprios acessos. Em residência comum, a necessidade é menor, mas em condomínio e controle de acesso é relevante. Segregação dinâmica impede ativar duas funções na mesma sessão ou transação. Um operador pode cadastrar um visitante, mas outro aprova acesso permanente. A função de suporte pode ser ativada por 30 minutos após aprovação do morador. Just-in-time reduz privilégio permanente. O sistema registra motivo, ticket, aprovador e ações. RBAC do NIST inclui constraints. Implementar não é apenas tabela role-permission. Cardinalidade pode limitar número de administradores. Prerequisite roles exigem que um técnico tenha treinamento antes de Instalador Avançado. Sessões podem ativar mínimo. Em CLI, `sudo` é analogia. Um usuário autenticado como admin não precisa usar privilégios todo o tempo. Para ações críticas, reautenticar e ativar. Isso reduz dano de sessão roubada. O papel deve expirar. Um prestador recebe de 09:00 a 17:00 por sete dias; o horário é atributo, mas a atribuição temporal pode ser incorporada. Se regras contextuais proliferam, ABAC é mais adequado. Não criar `Instalador-Segunda-Manhã` e `Instalador-Terça`. Isso é explosão. RBAC fornece base; políticas complementam.

Risco

Funções excessivas ou genéricas

Role explosion ocorre quando cada combinação de casa, horário, dispositivo e exceção vira uma função. Cem recursos e dez condições podem gerar milhares. A administração fica pior que ACL. O oposto é `Admin` para todos. Ambos falham. O desenho deve limitar funções a responsabilidades humanas estáveis e usar escopos/atributos para contexto. Uma função `MoradorFilhoSemCameraDepois22` é sinal de regra ABAC. Uma função `Dispositivo-123-Leitor` é ACL disfarçada. Permissões precisam ser nomeadas por ação e recurso lógico. Funções não devem ser usadas como feature flags comerciais sem separar. Um plano Premium não é papel de segurança. Pode influenciar entitlement, mas não misturar. O backend calcula ambos. Outra falha é confiar em claims de função longos em JWT por horas. Revogação atrasa. Tokens curtos, introspecção ou version claim. O sistema pode manter `permissions_version`; se mudou, invalida. Acesso crítico consulta. A função não substitui autenticação forte. Um Admin com senha fraca é risco maior. Exigir MFA/passkey. Não conceder admin por e-mail de domínio automaticamente sem aprovação. Funções de serviço e usuário são distintas. Um dispositivo não precisa `Admin`; recebe identidade de máquina e escopos mínimos.

🖥 Aplicações em Hardware

🔒

Plataforma de casa inteligente

Funções por residência e permissões por ação

O backend mantém tabelas de roles, permissions e assignments com scope da casa. APIs chamam um serviço de autorização. A função Administrador tem `users.manage`, `integrations.manage`, `automations.edit`, mas `locks.unlock` pode exigir step-up. Morador tem controle diário. Convidado limita. O serviço retorna decisão e razão. Cache por segundos, invalidado por evento. Logs registram subject, role, permission, resource e resultado. A UI usa a mesma API para mostrar, mas o backend é autoridade. Migrações de banco versionam. Novas permissões começam não atribuídas. Testes unitários usam matriz de papéis. Testes negativos. Multi-tenant exige filtro em toda consulta.

🔒

NVR e câmeras

Separação entre visualização, exportação e administração

Visualizar ao vivo, reproduzir gravação, exportar, apagar, configurar retenção e administrar câmeras são permissões diferentes. Um porteiro pode ver câmeras comuns ao vivo, não quartos privados nem exportar. Um morador vê suas câmeras. Um investigador temporário recebe exportação específica. RBAC define funções e escopos de grupos de câmera. A API de stream valida antes de emitir URL/token curto. Não entregar URL RTSP permanente. O NVR registra. A conta de serviço do analytics pode ler frames específicos, não administrar. A função de técnico acessa saúde, sem vídeo. Isso demonstra menor privilégio e privacidade.

🔒

Controle de acesso físico

Papéis para operadores, moradores e auditoria

Um sistema de portas possui Morador, Porteiro, Gestor de Credenciais, Auditor e Administrador Técnico. Porteiro abre portões comuns e registra visitantes; não cria credencial permanente. Gestor cria, mas uma política pode exigir aprovação. Auditor lê logs e não abre. Técnico configura leitor, não exporta dados pessoais. As funções são separadas. O controlador local recebe políticas e funciona offline. Revogações sincronizam. Uma ação crítica exige MFA e motivo. O relé não aceita comando direto da rede geral. A API valida. Logs são imutáveis. Em emergência, break-glass é registrado e revisado. A norma física continua; RBAC não substitui egress.

🔒

Home Assistant e ferramentas

Perfis de usuário e acesso administrativo

Uma plataforma pode oferecer usuários normais, somente leitura e administradores. Add-ons, YAML, terminal e secrets são permissões administrativas, não devem ser concedidos a todos. Dashboards podem ser por função, mas esconder não basta. Integrações precisam de backend. Tokens de longa duração herdam permissões e devem ser revisados. Contas de automação recebem função de serviço com acesso a entidades específicas quando possível. Não usar token admin em scripts. O integrador usa conta individual temporária. Backups e logs protegidos. Se a plataforma não suporta granularidade, compensar com instância separada, proxy ou rede, reconhecendo limitação.

✓

Compartilhamento claro da casa

O morador consegue convidar alguém como Convidado, Morador ou Administrador e entender o alcance. A UI descreve ações concretas. Convidado controla luzes e climatização, mas não vê câmeras nem gerencia usuários. Administrador pode. Funções predefinidas reduzem erros. Para necessidades especiais, permissões customizadas podem existir, mas com cautela. O convite tem validade e escopo. Ao remover, o acesso é revogado e sessões são encerradas. O sistema mostra usuários, funções e último acesso. Uma revisão mensal ou alerta de convidado antigo ajuda. O morador não precisa editar 50 dispositivos. A função se aplica a grupo, com exceções explícitas quando necessário.

✓

Acesso temporário de instaladores e suporte

Um técnico recebe função Instalador por período e apenas na residência. Pode adicionar dispositivos e ver diagnósticos, mas não exportar vídeos ou gerenciar moradores. A ativação exige aprovação e MFA. O sistema registra cada mudança. Ao final, remove automaticamente. Isso reduz credenciais permanentes de prestadores. O acesso remoto pode ser just-in-time. Em caso de suporte, o morador autoriza por 30 minutos. Funções são desenhadas para tarefas. Se o técnico precisa ver uma câmera para alinhar, uma permissão temporária específica é concedida. Não usar conta compartilhada `installer`. Cada pessoa tem identidade. A auditoria atribui. O morador pode interromper.

ℹ

Mudanças podem demorar até o token expirar

Se funções são embutidas em JWT, remover um usuário pode não surtir em tokens já emitidos. O sistema precisa de access tokens curtos, revogação ou consulta. Para luzes, 10 minutos pode ser aceitável; para fechaduras, não. A plataforma deve encerrar sessões e invalidar refresh. Uma versão de política pode ser checada. A UI não deve prometer “imediato” sem mecanismo. O morador precisa saber. Em hub offline, sincronização pode atrasar. Convites e revogações devem chegar localmente. O controle físico mantém lista. O projeto decide consistência. Logs mostram. Uma ação após revogação é incidente.

ℹ

Função não substitui contexto

RBAC diz o que um Morador pode fazer em geral. Não responde sozinho “pode abrir esta porta às 02:00 estando fora do país?”. Horário, localização, risco e estado são atributos. Podem ser regras adicionais. Tentar codificar tudo em funções cria confusão. Para casas simples, RBAC é suficiente. Para condomínios e segurança, combinar ABAC. A UI precisa explicar. Uma negação contextual não significa que a função sumiu. Mostrar “permitido apenas até 22:00”. A política é transparente. Exceções de emergência precisam de processo e logs.

⚠️

Nota Técnica

RBAC foi desenvolvido em modelos formais pelo NIST e pesquisadores, consolidando core RBAC, hierarchical RBAC, static separation of duty e dynamic separation of duty. ANSI INCITS 359-2004 formalizou um padrão de RBAC. O núcleo usa conjuntos Users, Roles, Permissions, Operations, Objects e Sessions, com relações User Assignment e Permission Assignment. Uma permissão associa operação a objeto. A sessão liga usuário a funções ativadas, subconjunto das atribuídas. A hierarquia define senior role herdando permissões de junior, com semântica que precisa ser clara. Constraints limitam. Em implementação moderna, acrescenta-se scope/tenant. Isso é essencial para SaaS. O banco deve impor integridade. A avaliação de autorização deve ser deny by default. A decisão ocorre no servidor. UI, gateway e serviço podem aplicar defesa em profundidade, mas precisam de fonte consistente. PAP administra políticas; PDP decide; PEP aplica, conceitos mais comuns em ABAC, mas úteis. O cache precisa invalidar. Logs de decisão são dados sensíveis. Retenção. Mudanças em função exigem revisão e aprovação. Uma função deve ter descrição, owner, permissões, escopos permitidos e data de revisão. Entitlements devem ser recertificados. Contas órfãs removidas. MFA para privilegiadas. Just-in-time e Privileged Access Management complementam. A integração OIDC pode receber groups/roles, mas claims são inputs. Mapear por issuer e nomes. Não aceitar `role=admin` de token externo sem confiança. Em JWT, funções podem ficar obsoletas; usar curta vida ou consulta. RBAC não substitui ABAC quando condições ambientais são centrais. Um modelo híbrido é comum: função define baseline, atributos refinam. Evitar explosão. ACL é melhor para exceção pontual, mas precisa de governança. Em casa inteligente, papéis humanos são compreensíveis e devem ser mostrados. Dispositivos e serviços podem usar scopes/capabilities em vez de papéis. Não atribuir humano a identidade de máquina. A autorização precisa cobrir leitura, comando, configuração, dados, exportação e administração. Testar caminhos indiretos: uma pessoa sem `locks.unlock` pode criar automação que abre? Então `automations.edit` é privilégio equivalente e deve ser limitado. Esse tipo de análise é obrigatório.