Um protótipo costuma pressupor bancada confiável, operador conhecido e acesso físico fácil. No campo, o dispositivo encontra redes desconhecidas, reinicializações sem supervisão, troca de proprietário e anos de atualização. “Conecta com segurança” não é plano de lançamento. Esta checklist transforma a distância em evidências que uma equipe pequena consegue verificar antes de enviar e manter depois.
Liste o que o equipamento pode afetar, quais dados trata, quem envia comandos, como alguém alcança cada interface e o que ocorre sem conexão. Um sensor de temperatura tem impacto diferente de um relé que controla aquecedor, porta ou bomba. Ajuste os controles ao risco real e ao comportamento seguro em falha.
| Camada | Verifique antes de lançar | Guarde como evidência |
|---|---|---|
| Identidade e provisionamento | Identidade única; sem senha compartilhada por toda a frota; cadastro autenticado e revogação. | Registro de provisionamento, responsável pela credencial e teste de revogação. |
| Boot e firmware | Secure boot quando suportado; validação de assinatura OTA; interfaces de depuração controladas. | Digest/assinatura, origem do build, testes e evidência de recuperação. |
| Interfaces e rede | Serviços ociosos desativados; todo comando autenticado; escopo de tópico/API validado e limites de taxa. | Inventário de portas/serviços, política e testes negativos de permissão. |
| Dados e privacidade | Coleta mínima; proteção em trânsito e repouso; prazos de retenção e exclusão definidos. | Mapa de fluxo, armazenamento de chaves e teste de exclusão/restauração. |
| Backend e operação | Autorização por cliente no servidor; segredos fora do firmware; auditoria e alertas de anomalia. | Modelo de ameaças, revisão de acesso, runbook e responsável por vulnerabilidades. |
MAC e IP mudam, podem ser falsificados ou observados; trate-os como atributos de rede, não credenciais. Provisione chave ou certificado por dispositivo com processo controlado, permissões limitadas e revogação para perda, troca ou fim de vida. Nunca grave a mesma chave privada em todas as unidades. Segredos de produção não devem aparecer no código, repositório, capturas de tela, logs ou pacote de suporte.
Não desative anti-rollback sem motivo explícito de recuperação; também não publique um caminho irreversível capaz de inutilizar a frota. Segurança e recuperabilidade precisam ser projetadas juntas.
Use TLS com validação do certificado: criptografia sem validar o par pode conectar ao impostor. Separe autenticação de clientes MQTT/API das contas de usuário. O servidor deve verificar vínculo entre dispositivo e cliente, validar tamanho e esquema das mensagens e exigir comandos com validade e ID único. Retries devem ter backoff limitado e aleatório para uma falha regional não virar ataque de negação de serviço criado pelo próprio sistema.
A segurança local precisa sobreviver à nuvem. Defina modo seguro, controle físico e limites offline para atuadores. Alarme de fumaça, corte térmico ou parada de emergência não pode depender da disponibilidade do painel.
Automatize quando possível: bloqueie release com dependência proibida, tente firmware sem assinatura, acesso de outro dispositivo a tópicos, replay de comando vencido, payload malformado, corte de rede e interrupção de OTA. Execute no hardware real. A revisão manual deve cobrir mudanças no risco, coleta de dados, perfis de acesso e suporte.
Publique contato de segurança e período de suporte do produto. Defina triagem, correção e comunicação de falhas. Mantenha versões implantadas e último contato para descobrir exposição. Na transferência ou baixa, revogue identidade, desvincule contas, apague dados conforme prometido e retenha apenas registros de auditoria justificados.
Um projeto maker se torna produto IoT sustentável quando cada unidade tem identidade única, interfaces mínimas, atualização autenticada e recuperável, autorização no servidor, ciclo de dados definido e alguém responsável por incidentes. Trate cada item como teste ou registro, não como caixa marcada sem prova.