AAA em redes OT: RADIUS, TACACS+, LDAP e acesso de contingência
Separe autenticação, autorização e accounting, compare RADIUS, TACACS+ e LDAP e projete fallback, perfis, logs e disponibilidade para administração de ativos OT.
Comparação funcional de identidade em OT
| Tecnologia | Papel principal | Ponto de atenção |
|---|---|---|
| RADIUS | acesso e atributos de autorização | segredo por cliente e atributos |
| TACACS+ | administração e possível comando a comando | suporte real do equipamento |
| LDAP | diretório de usuários e grupos | mapeamento feito pela aplicação |
| Conta local | contingência e bootstrap | cofre, alarme e rotação |
| Accounting | registro de sessão/ação | horário, origem e retenção |
A autorização precisa ser provada com ações reais de cada perfil, não inferida do login.
AAA separa três perguntas operacionais
AAA significa Authentication, Authorization and Accounting. Autenticação confirma a identidade apresentada; autorização decide o que ela pode fazer; accounting registra início, fim e ações conforme o protocolo e equipamento. Um login centralizado sem perfis continua podendo conceder privilégio excessivo. Um log sem horário e origem não produz atribuição confiável.
Em OT, essas funções protegem acesso a switches, firewalls, servidores, IEDs e aplicações. O desenho deve considerar indisponibilidade do serviço central, isolamento de zona e necessidade de operação emergencial. Centralizar sem fallback testado pode bloquear manutenção; fallback irrestrito pode anular o controle.
RADIUS integra acesso, mas autorização varia
RADIUS transporta solicitações e respostas de autenticação e atributos de autorização, tradicionalmente sobre UDP. É comum em acesso à rede, VPN e gestão. O segredo compartilhado protege partes da troca, mas não substitui segmentação nem versões protegidas quando suportadas. A origem do cliente RADIUS e o segredo precisam ser definidos por dispositivo.
Atributos padrão e de fabricante podem mapear perfis. Um Access-Accept sem atributo esperado pode resultar em privilégio padrão inesperado. Teste usuário de cada função e comando permitido/negado no equipamento real, não apenas resposta do servidor.
TACACS+ separa funções administrativas com granularidade
TACACS+ é usado especialmente para administração de dispositivos e separa autenticação, autorização e accounting. Pode autorizar comandos conforme suporte do fabricante. A especificação atual do IETF documenta o protocolo, mas compatibilidade e atributos continuam dependentes da implementação.
Não presuma que “TACACS habilitado” registra cada alteração. Valide comando, nível, modo de configuração, origem e resultado. Uma conta que cai em privilégio máximo após erro de autorização é risco crítico e deve ser testada em laboratório.
LDAP é diretório, não substituto automático de AAA de rede
LDAP consulta e modifica entradas de diretório. Aplicações podem usá-lo para localizar usuários e grupos e depois aplicar autorização própria. Ele não equivale diretamente ao fluxo RADIUS ou TACACS+ de gestão de dispositivo. O mapeamento grupo–função pertence à aplicação e precisa de teste.
Use proteção TLS conforme arquitetura e valide certificado. Bind account deve ter leitura mínima e segredo gerenciado. Consultas, base DN, filtros e grupos aninhados podem produzir login correto com perfil errado ou alto tempo de resposta.
Ordem de servidores e timeout afetam disponibilidade
Equipamentos podem tentar servidores em sequência, repetir e só então recorrer a conta local. Timeouts longos transformam falha central em minutos de espera; curtos demais causam fallback durante congestionamento. Defina primário, secundário, número de tentativas e comportamento para reject versus timeout.
Reject explícito não deve normalmente acionar fallback que aceita a mesma credencial local, pois isso contorna política. Timeout de infraestrutura pode permitir conta break-glass conforme risco. Documente a máquina de estados e prove cada caminho.
Conta break-glass precisa ser utilizável e controlada
A conta local de emergência deve existir quando a continuidade exigir, com segredo forte guardado, acesso limitado, alarme de uso e renovação posterior. Não pode depender do mesmo diretório indisponível. Teste em janela planejada para evitar descobrir senha inválida durante crise.
Mantenha também console físico ou canal independente quando necessário. A emergência deve recuperar administração sem abrir acesso persistente a todas as origens. Depois do uso, revise accounting e configuração alterada.
Diagnóstico por decisão AAA
Diferencie ausência de resposta, reject, usuário desconhecido, segredo incorreto, atributo não aceito e autorização negada. Correlacione horário e identificadores no dispositivo e servidor. Se login abre mas comando falha, a autenticação terminou e o foco é autorização; se accounting falta, a ação pode ter ocorrido sem registro.
Capture metadados sem expor segredos. Verifique rota de ida e volta, ACL, porta, origem e sincronismo. Mudança de IP de gestão pode fazer servidor rejeitar o cliente mesmo com usuário correto.
Comissionamento de perfis e falhas
Crie matriz operador, manutenção, engenharia e auditoria. Para cada perfil, teste login, comandos permitidos, negados e registro. Pare um servidor de teste, valide secundário, timeout e break-glass. Teste também rejeição explícita para garantir que não vira acesso local indevido.
Após restauração, confirme que o equipamento volta ao servidor preferido e que não mantém sessão com privilégio residual. Remova usuários de teste e atualize cofre e inventário. O aceite termina quando identidade, privilégio, evidência e recuperação estão demonstrados. Registre também a latência de autenticação normal e em contingência, pois um fallback correto, mas lento, pode exceder o timeout do cliente e parecer indisponível ao operador.
Referências técnicas e normas
As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.
- IEC 62443-3-3:2013 — System security requirements and security levels — IEC. Requisitos técnicos de segurança para sistemas de automação e controle industrial.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security — NIST. Arquiteturas, ameaças e controles aplicáveis a ambientes OT.
- RFC 1122 — Requirements for Internet Hosts — Communication Layers — RFC Editor / IETF. Requisitos de IP, ICMP e camadas de comunicação em hosts.
- RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification — RFC Editor / IETF. Especificação vigente do IPv6.
- RFC 9110 — HTTP Semantics — RFC Editor / IETF. Semântica atual de métodos, campos e códigos HTTP.
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 — RFC Editor / IETF. TLS 1.3, handshake, autenticação e proteção do transporte.
- RFC 9325 — Recommendations for Secure Use of TLS and DTLS — RFC Editor / IETF. Recomendações atuais para versões, algoritmos e configuração TLS.
- RFC 4251 — The Secure Shell (SSH) Protocol Architecture — RFC Editor / IETF. Arquitetura SSH e separação entre transporte, autenticação e conexão.
- RFC 5424 — The Syslog Protocol — RFC Editor / IETF. Formato, facility, severity, timestamp e dados estruturados de Syslog.
- RFC 3411 — Architecture for Describing SNMP Management Frameworks — RFC Editor / IETF. Arquitetura do framework SNMP.
- RFC 3414 — User-based Security Model (USM) for SNMPv3 — RFC Editor / IETF. Autenticação e privacidade do SNMPv3 USM.
- IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery — IEEE Standards Association. LLDP e descoberta de conectividade em camada 2.
- RFC 2865 — Remote Authentication Dial In User Service (RADIUS) — RFC Editor / IETF. Autenticação e autorização RADIUS.
- RFC 8907 — The TACACS+ Protocol — RFC Editor / IETF. Especificação do TACACS+ para controle administrativo de dispositivos.
- RFC 4511 — Lightweight Directory Access Protocol (LDAP) — RFC Editor / IETF. Operação e mensagens do LDAP.
- RFC 5607 — RADIUS Authorization for Network Access Server Management — RFC Editor / IETF. Atributos para autorização granular de gestão de dispositivos.
Continue estudando
Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.