A fase piloto do Projeto Atlas entrou em campo com três caminhões equipados e telemetria fluindo para a nuvem. Na manhã de terça, o NOC da LogiTrack detecta leituras de temperatura fora do padrão em dois veículos que ainda nem tinham saído do pátio. Minutos depois, um alerta automático aciona a equipe de operações para “risco de perda de carga”. Os motoristas confirmam: baús fechados, compressores estáveis, nada anormal. A discrepância não é fenômeno físico. É segurança. Alguém conseguiu publicar mensagens falsas no tópico MQTT de telemetria.

A reunião de emergência ocorre na Base Atlas. Marina, engenharia de software, projeta o diagrama atual: sensores → gateway 4G → broker MQTT gerenciado → pipeline de ingestão → banco analítico → Metabase. Pedro, TI, abre os logs: duas conexões vieram de IPs diferentes, mas com o mesmo clientId e sem mutual TLS. O broker aceitava TLS unilateral e usuário/senha simples, sem ACL por tópico. O atacante publicou em /lt/frota/SPC-023/telemetria usando credenciais vazadas do ambiente de teste.

O objetivo da aula está explícito no incidente: entender ameaças típicas em IoT e endurecer a arquitetura de ponta a ponta. Antes de falar em soluções, Juliana conduz um threat modeling rápido (STRIDE) sobre o fluxo crítico “sensor → broker → processamento”.

Spoofing: reutilização de credenciais e clientId.

Tampering: alteração de payload em trânsito se TLS for mal configurado.

Repudiation: ausência de trilhas criptograficamente verificáveis.

Information disclosure: tópicos legíveis se houver downgrade de cifra.

Denial of service: floods de publish/subscribe.

Elevation of privilege: credenciais de teste com acesso amplo.

Com o mapa de ameaças validado, o grupo define contramedidas por camada.

No dispositivo: provisionamento seguro com identidade única por hardware (UUID + certificado X.509), secure boot e firmware assinado. Chaves privadas nunca saem do microcontrolador; atualização OTA apenas se a assinatura for verificada. Telemetria inclui carimbo de tempo e nonce para mitigar replays. Leituras agregadas localmente quando offline, com fila persistente e backoff exponencial.

No gateway/comunicação: adoção obrigatória de mTLS entre gateway e broker; eliminação de senhas compartilhadas; rotacionamento de certificados com janela curta. Para campo, APN privada 4G reduz exposição pública. Tópicos reorganizados com namespace por dispositivo e regra “publish mínimo necessário”. QoS ajustado: telemetria com QoS 1, comandos com QoS 2. Retained messages só para metadados, nunca para leituras sensíveis.

No broker MQTT: troca do plano “aberto” por instância dedicada com ACL fina (publish/subscribe limitados a lt/{deviceId}/telemetria e lt/{deviceId}/cmd). Rate limiting por cliente, max inflight reduzido e session expiry curto. AuthN via mTLS; AuthZ por políticas mapeadas ao CN do certificado. Logs assinados e exportados para SIEM. Bridging para o pipeline feito por conector com assinatura de mensagens (HMAC) para verificação posterior.

No backend: validação de integridade de payload (HMAC), esquemas rígidos e rejeição de outliers físicos (temperatura impossível dado o contexto). Separação de redes: ingestão isolada da rede de analytics. Secret management centralizado, sem variáveis sensíveis em contêineres. RBAC na nuvem, princípio do menor privilégio, chaves KMS com rotação automática.

Na camada de operações: criação de um runbook de incidente específico para falsificação de telemetria, com etapas de contenção (revogação imediata do certificado, bloqueio de clientId, limpeza de retained), erradicação (rotação forçada de credenciais de teste), recuperação (validação cruzada com sensores redundantes) e pós-incidente (lições aprendidas, testes de regressão). Playbooks para testes de intrusão recorrentes: publicação não autorizada, flood, replay, downgrade de cifra.

Com as medidas definidas, o time executa uma prova de correção. Primeiro, tentam repetir o ataque com as antigas credenciais. O broker recusa na camada TLS. Em seguida, simulam replay de uma mensagem válida capturada. O backend rejeita pelo nonce já visto. Por fim, testam flood control: rate limiting entra e o cliente ofensivo é isolado. O dashboard volta a refletir apenas dados fidedignos. O NOC registra a normalização dos alertas.

A diretoria é informada em linguagem executiva: risco, impacto, mitigação, evidências. Henrique pergunta sobre custo. Pedro apresenta o incremento de OPEX com mTLS gerenciado e PKI, e Marina contrapõe com o custo evitado: uma única carga de fármacos salva paga meses de infraestrutura segura. Juliana fecha com um indicador: “falso-positivo por telemetria adulterada caiu a zero nas últimas 24 horas; mean time to detect de 2 min; mean time to contain de 9 min”.

O estudo de caso encerra com um pacto de disciplina técnica: nenhuma nova feature entra sem revisão de ameaças, e todo componente passa por checklist de segurança antes de produção. A aula entrega o que o incidente cobrou: compreensão clara das superfícies de ataque em IoT e capacidade de projetar, implementar e operar controles eficazes. Na próxima etapa, a LogiTrack volta ao campo para ampliar o piloto com coleta robusta de dados, agora sobre uma fundação segura.