Início / Blog / Registry de dispositivos
Operação de frotas IoT e segurança

Registry de dispositivos ESP32: identidade, saúde e atualizações da frota

Com poucos dispositivos, uma planilha parece suficiente. Com centenas, a operação precisa responder: qual unidade física é esta, quem é responsável, qual firmware deveria executar, o que reportou por último e ainda é confiável? Registry não é lista de MAC addresses; é o registro operacional que liga identidade, ciclo de vida, configuração desejada e saúde observada.

Conecte cadastro à desativação

Identidade e estado acompanham transições controladas
1 / CadastrarAtribuir ID imutável e responsável.
2 / ProvisionarEmitir credencial única e perfil autorizado.
3 / ObservarReceber heartbeat, versão, saúde e local.
4 / OperarComparar estado desejado e reportado.
5 / EncerrarRevogar identidade, arquivar histórico e acesso.

Mantenha ID lógico estável, independente de endereço de rede. MAC, IP e nome exibido são atributos, não credenciais de autorização. O cadastro deve associar unidade física a responsável, local e revisão de hardware; emissão de credenciais ocorre em processo controlado. Nunca reutilize a identidade desativada em outra placa.

Separe inventário do estado atual

Um registry normalizado armazena identidade, modelo/revisão, local de instalação, responsável, referência de credencial, suporte e estado de ciclo de vida. Telemetria detalhada pertence a eventos ou série temporal; o registry guarda o resumo atual necessário para localizar e operar. Mantenha configuração desejada separada do estado reportado, com versões e horários próprios. Divergência é evidência útil, não dado para sobrescrever silenciosamente.

Campos úteis: primeiro cadastro, último contato autenticado, firmware e bootloader, revisão de configuração, saúde dos sensores, último erro, coorte de atualização e responsável de manutenção. Segredos ficam fora das linhas de inventário; armazene uma referência ao cofre de credenciais.

Trate heartbeat como evidência, não ponto verde

Heartbeat inclui ID, sequência monotônica, firmware, uptime ou causa do reset e flags compactas de saúde. O servidor adiciona horário próprio de recebimento. Defina intervalo esperado por classe e derive estados como saudável, atrasado, obsoleto, em quarentena ou encerrado. Estar “conectado” não prova que o sensor está amostrando ou a configuração atualizada.

Use chaves idempotentes e aceite eventos atrasados. Mantenha horário do evento e recebimento separados devido a deriva dos relógios. A visão da frota deve filtrar por local, revisão, coorte, atraso e incidentes, em vez de montar milhares de cartões.

Audite atualizações e configuração

Registre firmware e configuração desejados separadamente do que cada dispositivo confirmou. Um rollout deve indicar artefato, assinatura ou digest, coorte, autorização, início, resultado e rollback. Rollback OTA do ESP-IDF permite voltar a uma aplicação anterior funcional após nova imagem problemática; o registry deve distinguir “baixado”, “iniciado pendente de verificação” e “confirmado saudável”. Enviar comando de update não prova sucesso.

Campo/eventoPor que importaLimite de acesso
ID lógico e revisãoVínculos estáveis após troca de rede ou reparoCadastro e suporte
Referência/estado da credencialRotação, revogação e resposta a incidenteNunca mostrar chave privada na UI
Estado desejado e reportadoDetecta divergência de configuração/firmwareAlterações exigem autorização
Último contato e saúdeEncontra segmentos atrasados ou falhosEscopo por unidade e função
Estado de ciclo de vidaControla ativação, quarentena e encerramentoTransições auditadas

Controle acesso por função da frota

Separe leitura, operação local, administração de credenciais e aprovação de firmware. Suporte pode inspecionar saúde sem ver segredos ou emitir comandos de atuação. Restrinja consultas e comandos às unidades autorizadas. Registre autor, motivo, request ID e estado anterior/novo nas transições sensíveis.

Trate troca de dono e fim de vida

Coloque em quarentena dispositivo perdido, comprometido ou devolvido antes de reassociá-lo. Revogue credenciais, interrompa comandos, preserve evidência necessária e registre destino físico. Substituta recebe nova identidade ligada ao chamado, sem copiar ID antigo. Equipamento fora de suporte precisa de política explícita de acesso, atualização e retenção de dados.

Em resumo

Um registry ESP32 útil liga identidade única a ciclo de vida, acesso, configuração pretendida e saúde observada. Mantenha segredos fora do inventário, separe estado desejado do reportado, explicite resultados de OTA e audite do cadastro ao encerramento. Assim, a frota vira algo que a operação consegue entender, não uma planilha que apenas conta dispositivos.

Referências