Segurança Digital

Controle de Acesso Baseado em Atributos (ABAC)

Quatro conjuntos de atributos — sujeito, objeto, ação e ambiente — permitem que ABAC decida uma solicitação por políticas, em vez de depender apenas de papéis fixos. O NIST SP 800‑162 define o modelo e suas considerações. Uma regra pode permitir ao instalador configurar sensores da Casa A entre 09:00 e 17:00, com MFA e ticket ativo. A consequência prática é controle granular sem criar dezenas de funções; a limitação é a complexidade de políticas, qualidade dos atributos e dificuldade de explicar decisões.

🛡 Níveis de Segurança

Granular

Políticas explícitas com atributos confiáveis

ABAC é uma metodologia em que a decisão de autorização resulta da avaliação de atributos do sujeito, do objeto, da ação e, quando relevante, do ambiente contra políticas. O NIST SP 800-162 formaliza. Um sujeito pode ter `user.id`, `tenant`, `role`, `employment`, `assurance_level` e `device_trust`. O objeto pode ter `home_id`, `device_type`, `room`, `owner`, `sensitivity` e `criticality`. A ação é `read`, `control`, `unlock`, `export`, `configure`. O ambiente inclui horário, localização, rede, risco, emergência e estado. Uma política pode dizer: permitir `configure` quando `subject.company=IntegratorX`, `subject.contract_active=true`, `object.home_id` está na lista autorizada, horário 09:00–17:00, MFA forte e ticket aprovado. Isso evita criar uma função para cada casa e horário. A qualidade depende dos atributos. Eles precisam de origem, tipo, atualização e confiança. Um claim de GPS enviado pelo próprio app não deve autorizar porta sem atestação e análise. Horário vem do servidor. `home_id` vem do banco, não da URL apenas. MFA vem do IdP validado. O policy engine precisa de um schema. Atributos ausentes devem negar ou seguir regra explícita, nunca assumir favorável. O sistema registra quais atributos e política levaram à decisão, com cuidado de privacidade. A decisão deve ser determinística e testável. Políticas versionadas. A mudança passa por revisão. Deny by default. Conflitos têm algoritmo: deny-overrides, permit-overrides ou first-applicable. Definir. Para ações críticas, deny-overrides é comum. Uma política de emergência pode ter prioridade, mas exige logs. Não usar scripts livres sem sandbox. Linguagens como Rego/OPA, Cedar, XACML ou engines cloud oferecem modelos. O produto deve escolher e governar.

Equilibrado

ABAC híbrido com RBAC

Na prática, RBAC e ABAC se complementam. A função fornece responsabilidade estável; atributos refinam contexto. Morador pode controlar dispositivos da própria casa. A política verifica `role=resident`, `subject.home_ids contains object.home_id` e ação permitida. Para fechadura, exige `auth_age<300s` e `mfa=phishing-resistant`. Convidado tem baseline menor e horário. Isso evita regras que repetem cada permissão de função e evita explosão de papéis. O NIST discute trade-offs: RBAC investe em estrutura de funções e facilita revisão; ABAC transfere complexidade para atributos e políticas. Um sistema residencial pequeno pode começar com RBAC. ABAC é justificado quando existem múltiplas casas, prestadores, horários, localizações e dispositivos críticos. O projeto deve medir. Não criar um policy engine complexo apenas para Admin e Guest. Em condomínios, ABAC agrega valor. Um porteiro abre portão comum durante turno; fora, não. Um prestador entra na unidade apenas com ordem ativa. Um sensor de manutenção pode ser acessado por empresa responsável. A função e o atributo. As permissões de alto nível continuam. O policy engine recebe decisão. O PEP no API gateway e serviço aplica. Não confiar só no gateway; rotas internas podem bypass. O serviço chama biblioteca ou decisão central. Central oferece consistência, mas adiciona latência e disponibilidade. Cache de decisões precisa incluir todos os atributos e TTL curto. Uma mudança de contrato deve invalidar. Para fechadura, consulta em tempo real ou política local sincronizada. O modo offline precisa ser definido. Não permitir por cache expirado sem regra.

Contextual

Atributos de ambiente e risco para ações críticas

ABAC permite usar tempo, rede, localização, estado do dispositivo e risco. Isso é poderoso e perigoso. Uma política pode permitir desbloqueio remoto somente com passkey, dispositivo registrado, risco baixo e sessão recente. Localização pode ser um sinal, não prova. GPS pode ser falsificado. A rede Wi‑Fi de casa também pode ser clonada. Use múltiplos e evite bloquear o morador indevidamente. Políticas de risco precisam de fallback. Um alarme de incêndio pode exigir liberação de portas por sistema local certificado, não por ABAC cloud. Segurança de vida fica em controladores dedicados. ABAC pode governar interfaces administrativas. Horário precisa de timezone e NTP. Armazenar UTC e converter. Mudanças de horário de verão. Uma regra 08:00–18:00 deve usar região. O servidor é autoridade. O atributo `emergency=true` precisa de origem autenticada e lifecycle; não pode ser query parameter. O policy engine precisa distinguir valor, emissor e assurance. A decisão pode exigir obligations: registrar motivo, enviar notificação, mascarar dados, limitar duração. XACML usa obligations; outras engines têm. Um acesso a câmera pode ser permitido, mas com watermark e sem exportação. O PEP executa obrigação. Se não consegue, negar. Esse detalhe é necessário. A política não deve retornar apenas booleano quando ações adicionais importam. A consequência para o morador é controle adaptativo, mas também mais negações difíceis. A UI deve explicar de forma segura: “reautenticação necessária” em vez de revelar toda a regra ao atacante.

Risco

Atributos inconsistentes e políticas impossíveis de auditar

ABAC falha quando cada serviço inventa nomes, tipos e fontes. `role=Admin`, `role=admin`, `isAdmin=true` e grupo `admins` podem divergir. Um catálogo de atributos é obrigatório: definição, tipo, valores, fonte autoritativa, atualização, confiança, retenção e owner. A política deve usar. Atributos derivados precisam de lógica versionada. `device_trust=high` depende de quê? Secure boot, patch, MDM? Documentar. Se um atributo fica stale, a decisão pode permitir. O sistema precisa de TTL e evento de revogação. Políticas podem crescer e se contradizer. Usar testes unitários, simulação, lint, revisão e análise de impacto. Cada mudança tem exemplos permitidos e negados. Uma política que ninguém consegue explicar não é segura. A auditoria precisa reconstruir decisão histórica com versão e atributos relevantes. Não registrar localização exata indefinidamente se não necessário. Hash ou categoria. A privacidade é parte. Outra falha é usar ABAC para mascarar falta de modelo de recursos. Se não se sabe qual casa pertence ao dispositivo, nenhuma regra resolve. Integridade de dados. Um atacante pode alterar atributo do objeto via API; essa operação precisa de autorização ainda mais forte. Attribute administration é privilégio. Separar quem edita política e quem edita atributos. Segregação de deveres. Em caso de falha do PDP, negar por padrão para ações críticas; para iluminação local, pode existir política cached. A disponibilidade e segurança precisam ser balanceadas.

🖥 Aplicações em Hardware

🔒

Motor de políticas

OPA, Cedar ou serviço de autorização central

A plataforma modela recursos e ações e envia ao PDP um input JSON tipado: subject, resource, action, context. O engine avalia políticas versionadas e retorna allow, reason e obligations. O serviço usa mTLS. O PEP no backend aplica. O cache dura segundos e usa key com policy version. Mudanças publicam evento. A política é testada em CI com casos positivos e negativos. Revisão por duas pessoas para portas/câmeras. O repositório é assinado. Rollback. O engine não chama APIs externas durante decisão para evitar latência e side effects; atributos são pré-carregados por PIP confiável. Se falta, deny. Métricas não expõem dados. O sistema pode usar OPA/Rego ou Cedar, mas a linguagem não substitui modelo.

🔒

Hub local

Políticas offline sincronizadas para funções essenciais

O hub recebe uma versão assinada de política e atributos mínimos: usuários, papéis, escopos e validade. Ele decide localmente quando cloud falha. Ações de luz e clima funcionam. Acesso remoto não, porque o canal caiu. Fechaduras usam política local e credenciais offline autorizadas. Revogações chegam por fila e versão. Se o hub fica offline por longo período, credenciais temporárias expiram pelo relógio seguro. NTP e RTC. A política assinada impede alteração. O hub verifica. O admin não edita arquivo. Um break-glass físico existe. Logs sincronizam depois. O escopo é limitado. Não copiar localização e dados desnecessários. A consistência precisa ser documentada.

🔒

Controle de acesso

Decisão por credencial, porta, horário e estado

Um pedido de acesso inclui credential ID, subject, door, action, timestamp e contexto. A política verifica vínculo à unidade, janela, anti-passback, bloqueio, nível e condição. O controlador local executa em milissegundos. A cloud não pode ser necessária. ABAC é compilado para regras locais ou sincronizado. O sistema de incêndio possui lógica independente e autoridade. Atributos de porta, como área comum/privada e nível, são protegidos. Apenas admin autorizado altera. A decisão registra. Credenciais móveis usam prova criptográfica, não apenas ID. O motor não aceita GPS do telefone como único sinal. Em condomínio, prestador tem ordem de serviço ativa. Ao expirar, nega. O porteiro pode aprovar temporariamente, com log.

🔒

IoT e API

Autorização de dispositivos por identidade e postura

Um dispositivo com certificado solicita publicar telemetria. A política verifica `device_id`, fabricante, residência, tipo, firmware mínimo, status não revogado e tópico. Permite apenas `homes/A/sensors/123/telemetry`. Não permite comandos. Um gateway pode publicar. Atributo de firmware vem do inventário/attestation, não do próprio campo sem validação. Se vulnerável, limita. Isso é ABAC de máquina. O broker MQTT usa plugin ou gateway. Certificados têm ACL dinâmica. O dispositivo não recebe papel `admin`. A decisão pode ser cacheada. Revogação de certificado é adicional. Logs. A política evita que um sensor comprometido publique estado de fechadura. Atributos de tópico e recurso precisam de parsing seguro.

✓

Acesso temporário e contextual sem criar papéis novos

O morador autoriza um instalador apenas para a própria residência, durante dois dias, das 09:00 às 17:00 e somente para sensores e hubs. A plataforma grava atributos de contrato, escopo e validade. A função Instalador fornece baseline; ABAC refina. Ao expirar, a decisão nega automaticamente sem remover manualmente dezenas de permissões. O morador vê a autorização e pode cancelar. O técnico usa conta individual e MFA. A política não permite câmeras nem fechaduras. A auditoria lista ações. Isso reduz contas compartilhadas. Se o relógio ou serviço de política falha, o acesso remoto fecha. O trabalho local pode exigir aprovação no hub. O sistema explica.

✓

Proteção adaptativa para câmeras e fechaduras

Visualizar câmera externa pode exigir autenticação normal; câmera interna, passkey recente. Destravar remotamente exige dispositivo registrado, MFA forte, sessão com menos de 5 minutos e residência correta. O policy engine avalia. Uma conta comprometida com senha apenas não basta. O morador ganha camada. Porém, sinais podem falhar. Deve existir caminho de recuperação seguro e controle físico local. Não depender de geofencing para emergência. A política deve ser testada em viagem, troca de telefone e Internet ruim. A UI solicita step-up. A decisão é server-side. O app não envia `mfa=true`; o IdP fornece claim validada.

ℹ

Decisões podem ser mais difíceis de entender

RBAC simples diz “Convidado não pode”. ABAC pode negar por horário, risco, dispositivo, localização ou contrato. A plataforma deve fornecer reason codes seguros: `MFA_REQUIRED`, `OUTSIDE_ALLOWED_WINDOW`, `SCOPE_MISMATCH`, `POLICY_DENY`. Não revelar lógica sensível a usuário não autenticado. Administradores recebem detalhes. O morador precisa saber como corrigir. Um log de decisões ajuda suporte. A política deve evitar combinações inesperadas. Testes de experiência. Não transformar segurança em bloqueio arbitrário. Exceções precisam de governança, não botão “ignorar tudo” permanente.

ℹ

Privacidade dos atributos contextuais

Localização, dispositivo, padrão de uso e horários são dados pessoais. Coletar apenas o necessário. Se a regra só precisa saber “na residência”, não armazenar GPS exato. Processar localmente quando possível. Retenção curta. O morador vê e consente. Atributos não devem aparecer em tokens longos se mudam. Consultar. Logs podem guardar categoria e resultado. A LGPD e contratos aplicam. A segurança não justifica coleta ilimitada. Um atributo de risco pode ser pseudônimo. O provedor deve explicar. Ao remover usuário, apagar conforme política. Parceiros não recebem atributos não necessários.

⚠️

Nota Técnica

O NIST SP 800-162 define ABAC como metodologia em que autorização a operações é determinada pela avaliação de atributos associados ao sujeito, objeto, operações e, em alguns casos, ambiente contra políticas, regras ou relações. A atualização final de 2019 incorpora errata. ABAC não é uma linguagem única. XACML, Rego, Cedar e políticas de nuvem são implementações distintas. Uma arquitetura comum possui Policy Enforcement Point, PEP; Policy Decision Point, PDP; Policy Administration Point, PAP; Policy Information Point, PIP. O PEP intercepta e aplica. O PDP decide. PAP gerencia. PIP fornece atributos. A confiança no PIP é crítica. Atributos precisam de provenance e freshness. O modelo de decisão precisa definir combinações. Deny by default. Políticas negativas e positivas podem conflitar. Deny-overrides é seguro, mas pode bloquear exceções. Definir. Obligations/advice podem exigir log, MFA ou mascaramento. O PEP precisa cumprir. O sistema deve ser resistente a TOCTOU: atributos podem mudar entre decisão e ação. Para destravar, decisão e comando precisam ser próximos e vinculados a nonce/recurso. Não usar decisão genérica por minutos. Para leitura de lista, filtrar recursos no backend, não retornar tudo e esconder. Isso é importante. A política deve evitar side channels: contagens e erros podem revelar. Testar. O desempenho precisa. Decisões locais ou cache. Cache key inclui subject, action, resource, context relevante e policy version. TTL. Invalidação. Políticas como código permitem CI, mas acesso ao repositório é privilegiado. Assinatura e pipeline. Análise estática. Simulação antes. Auditoria registra policy ID/version, decision, subject pseudônimo, resource, action e reason; atributos sensíveis minimizados. A revisão de acesso em ABAC é mais difícil que listar funções. Ferramentas precisam responder “quem pode fazer X?” e “por que Y teve acesso?”. Isso exige análise e materialização. Um modelo híbrido com RBAC melhora explicabilidade. Não usar atributos de baixa confiança para decisões de alto impacto. Geolocalização e IP são sinais. MFA e identidade criptográfica têm maior. Em casa inteligente, ABAC é útil para acessos temporários, multi-residência e ações críticas, mas deve preservar controles locais de segurança e egress. A cloud não pode atrasar uma porta de emergência. A política cibernética não substitui norma física.