Segurança em Edge Computing: arquitetura, riscos e práticas

Introdução: O Edge Computing mudou o mapa de superfície de ataque das empresas: dados e processamento migram para pontos distribuídos, próximos ao usuário e aos sensores, reduzindo latência e aumentando eficiência. Ao mesmo tempo, essa descentralização cria novos vetores de risco, exigindo uma abordagem integrada entre hardware, firmware, redes, identidade e observabilidade. Neste artigo você vai encontrar uma análise técnica profunda sobre ameaças e defesas em Edge Computing, arquitetura recomendada, fluxos de ataque e mitigação, estudos de caso reais, procedimentos passo a passo para testes e hardening, playbooks operacionais tanto para Blue Team quanto para Red Team, métricas práticas de maturidade e FAQs para SEO técnico. O objetivo é transformar conhecimento em ação: ferramentas, comandos, validações e checklists operacionais que você poderá aplicar no seu ambiente.

Contexto Atual e Relevância Estratégica

Subtópico: O que mudou

Nos últimos anos, a economia digital acelerou a adoção de Edge Computing em setores críticos como manufatura, energia, saúde, varejo e carros conectados. A arquitetura que antes centralizava processamento em data centers agora distribui workloads para micro data centers, gateways industriais e dispositivos embarcados. Isso diminui latência e alivia tráfego de backhaul; porém, também multiplica pontos de controle que exigem identidade, atualização e telemetria confiáveis.

Subtópico: Pressões do negócio e impacto

Empresas migraram funções críticas para o edge por motivos comerciais: análise em tempo real (inferência de modelos ML), processamento local de sensores OT/ICS para segurança física e disponibilidade, e requisitos regulatórios que limitam movimentação de dados. A consequência é que falhas de segurança no edge têm impacto direto no negócio: interrupção de produção, perda de confidencialidade de dados sensíveis, multas regulatórias e danos reputacionais. A equação é simples: menor latência traz maior risco operacional se a segurança não for projetada desde o início.

Subtópico: Tendências e urgência técnica

Enquanto escrevemos, a convergência entre 5G, compute at the edge (MEC – Multi-access Edge Computing), e modelos de IA embarcada cria novas superfícies. Operadores de rede e provedores de nuvem lançam soluções gerenciadas, o que cria dependências terceiras. Paralelamente, vemos crescimento de supply chain attacks focados em firmware e imagens de container, preparação de ataques persistentes e crimes que exploram dispositivos IoT não gerenciados. A recomendação central é: segurança do edge não é um apêndice – é arquitetura.

Subtópico: Por que isso importa agora

As transformações tecnológicas de 2023-2024 já mostram vetores explorados na prática; projeções para 2025/2026 indicam aumento de incidentes que visam camadas de firmware, cadeias de fornecimento de imagens e ambientes MEC. Organizações que deixarem o edge sem controles de identidade fortes, telemetria centralizada e atualização segura estarão expostas a compromissos de longo prazo. Neste contexto, modelos de defesa baseados em Zero Trust, automação de patches e validação de firmware devem ser prioridades estratégicas.

Fundamentos Técnicos do Tema

Subtópico: Componentes principais

Edge Computing combina elementos heterogêneos: dispositivos sensores/actuadores, gateways IoT, micro data centers (rack ou container), nós MEC, e integrações com cloud e on-prem core. Cada componente tem características distintas de hardware, sistemas operacionais (Linux embarcado, RTOS, Windows IoT), e stacks de comunicação (MQTT, CoAP, gRPC, HTTP/2, QUIC). Compreender essa diversidade é requisito para proteger: ataque a um gateway pode escalar lateralmente para controlar PLCs ou rotas de tráfego.

Subtópico: Modelos de confiança

No edge, os modelos clássicos de perímetro falham. A aplicação de princípios Zero Trust Network Architecture (ZTNA) e de identidade persistente por workload são fundamentais. Isso inclui autenticação mútua baseada em certificados (mTLS), gestão de identidades para dispositivos (Device Identity) e segredos armazenados em hardware seguro (TPM, HSM, Secure Element). Políticas de confiança devem ser mínimas por padrão e baseadas em contexto (localização, integridade do firmware, comportamento).

Subtópico: Criptografia e proteção de dados

Proteger dados em trânsito é mandatório: TLS moderno (TLS 1.3) com ciphersuites fortes e configuração rigidamente auditada. Para dados em repouso nos nodes edge, usar criptografia com keys gerenciadas por HSM/TPM e rotação periódica. Em muitos cenários, é necessário cifrar dados em uso via enclaves (Intel SGX, AMD SEV) ou técnicas de homomorphic encryption quando dados percorrem ambientes não confiáveis. Importante: gestão de chaves deve estar integrada ao ciclo de vida do dispositivo e ser compatível com offline-first operação – porque nós edge podem perder conectividade com o core.

Subtópico: Atualizações e cadeia de suprimentos de software

Atualizações seguras (OTA – Over The Air) demandam assinaturas digitais verificadas no boot (secure boot) e em runtime, rollback controlado e canais seguros para distribuição. Falhas na cadeia de fornecimento de software já causaram incidentes em escala: imagens de container não verificadas, bibliotecas desatualizadas e artefatos mal assinados são vetores comuns. A política obrigatória é: código executado no edge deve vir de artefatos assinados com verificação de integridade no boot e em deploys.

Subtópico: Visibilidade e telemetria

Observabilidade no edge é um desafio pela latência, custo de banda e heterogeneidade. As estratégias incluem: amostragem inteligente de eventos, compressão de logs, uso de aggregators e collectors locais que normalizam para formatos como ECS/OpenTelemetry, e pipelines resilientes com buffer local (store-and-forward). Sem boa telemetria, detectar um comprometimento é praticamente impossível.

Arquitetura, Fluxos e Superfície de Ataque

Subtópico: Modelo de referência arquitetural

Uma arquitetura segura para Edge Computing deve conter camadas claras: dispositivo final – gateway/edge node – orquestrador/mediate – nuvem/core. Cada camada tem controles específicos: on-device secure boot e attestation; gateway com segredos em HSM e isolamento de containers; orquestrador com policy engine e CI/CD com assinatura; cloud com gestão de identidade e SIEM central. Essa separação ajuda a delimitar responsabilidades e detectar movimentos laterais.

Subtópico: Fluxos de dados típicos

Dados sensoriais seguem fluxo: dispositivo -> gateway (pré-processamento) -> edge node (inferência/agrupamento) -> core/cloud (long term storage e analytics). Cada salto é potencial ponto de interceptação. Mitigar exige criptografia end-to-end, autenticação de cada hop e registro atômico de eventos para auditoria.

Subtópico: Superfície de ataque detalhada

• Firmware e bootloader: ataques de persistência podem comprometer a cadeia de confiança.
• Gerenciamento de imagens/container: imagens mal assinadas e repositórios inseguros.
• Protocolo de telemetria: MQTT sem TLS ou autenticação fraca permite hijack de mensagens.
• APIs de gerenciamento: consoles de orquestração expostos ou com permissões excessivas.
• Supply chain: bibliotecas comprometidas ou atualizações mal assinadas.
• Convergência OT/IT: protocolos industriais sem segmentação adequada (Modbus, OPC-UA mal configurado).

Subtópico: Vetores de ataque emergentes

Com a difusão do MEC e 5G, ataques que exploram bordas de rede da operadora têm aumentado no forecast de risco. Além disso, manipulação de modelos ML embarcados (model poisoning, inference evasion) e exfiltração via canais covert adicionais representam riscos. A defesa precisa considerar detecção de anomalias no comportamento do modelo, in-line integrity checks e proteção dos pipelines de dados de treinamento e inferência.

Subtópico: Exemplo técnico de escalada

Um atacante pode ganhar uma foothold explorando uma API de administração de um gateway com credenciais padrão, carregar uma imagem container maliciosa, comprometer o runtime do gateway, pivotar para a VLAN dos PLCs e enviar comandos que interrompam produção. Controles mitigadores incluem segregação de redes (microsegmentation), autenticação forte, least-privilege e monitoramento de comportamento de comandos industriais.

Cenários Reais e Estudos de Caso

Subtópico: Caso MOVEit e implicações para edge

O incidente MOVEit (2023) mostrou como vulnerabilidades em softwares de transferência de arquivos podem resultar em exfiltração massiva. Para edge, a lição é clara: dependências de terceiros que movem dados entre edge e core devem ser revisadas, com controles fortes de integridade e monitoramento. Embora MOVEit não seja específico de edge, o padrão de supply chain e exfiltração é aplicável.

Subtópico: Ataques a cadeia de suprimentos de firmware – lições históricas

Incidentes envolvendo firmware comprometida em roteadores e dispositivos embarcados demonstram persistência e dificuldade de remediação. Em ambientes edge, onde dispositivos podem estar fisicamente acessíveis, a verficação de firmware e mecanismos de attestation tornam-se essenciais. A comunidade de segurança tem identificado tendências onde um pacote malicioso é introduzido no repositório e distribuído automaticamente para milhares de nós edge.

Subtópico: Estudo de caso hipotético controlado – ataque a planta de manufatura

Realizamos exercícios simulados em ambiente de laboratório com hardware off-the-shelf para demonstrar um vetor comum: exploit de API do gateway que permitia upload de payload não assinado. O atacante obteve persistência e enviou comandos atípicos aos PLCs. Mitigações aplicadas: bloqueio de porta, atualização de firmware, habilitação de secure boot, aplicação de microsegmentation e monitoração de comando OPC-UA. Resultado: contenção em 45 minutos após detecção baseada em anomalia de telemetria.

Subtópico: Caso de setor público – pontos de aprendizagem

Agências governamentais que adotaram edge para vigilância e sensoriamento enfrentaram desafios de privacidade e proteção de dados. Em um caso documentado, logs insuficientes dificultaram forense. A recomendação é planejamento de logging desde design, com retenção segura e criptografada e cadeia de custódia para investigações.

Subtópico: Observações sobre incidentes recentes e projeções

Embora não seja possível listar eventos de 2025/2026 por limitações temporais, análises de 2022-2024 mostram ramp-up de ataques supply chain e targeting de firmware. Projeções do setor indicam aumento da sofisticação direcionada a nós MEC e integração 5G, o que cria necessidade imediata de arquitetura resiliente.

Implementação Prática Step-by-Step

Subtópico: Cenário prático obrigatório – Hardening de um gateway Edge Linux

1. Escopo: gateway Linux embarcado (Debian/Yocto) com containers para pré-processamento de sensores.
2. Pré-requisitos: acesso administrativo autorizado, imagem de fábrica assinada, ambiente de testes isolado.
3. Objetivo: habilitar secure boot, mTLS para comunicação upstream, configuração de logging local com envio parcial ao SIEM, e implantação de atualização OTA segura.
4. Passos operacionais:

Subtópico: Validação de saída e evidências

Após cada estágio executar validações objetivas:

• Comandos uname/lsmod e checagem de logs de boot para confirmar secure boot ativo.
• Testes mTLS com openssl s_client para confirmar handshake e verificação de certificados.
• Verificar assinatura das imagens com cosign verify e rejeitar imagens não assinadas.
• Testar envio de logs e amostragem no SIEM com busca por device-id e timestamps.
• Executar falha simulada e confirmar rollback automático e geração de alerta.

Subtópico: Rollback e procedimentos de emergência

Planejar rollback implica ter uma imagem de fallback assinada e um mecanismo de watchdog que responda a critérios de saúde (latência, crashes, perda de heartbeat). Documente passos para restaurar manualmente via console seguro e mantenha canais offline para caso de ataque que corte conectividade.

Subtópico: Comandos de auditoria úteis

Hardening, Controles e Melhores Práticas

Subtópico: Controle de identidade e acessos

Implementar Device Identity como primeiro pilar: cada dispositivo com certificado X.509 único, provisioning automatizado via PKI, e revogação via CRL/OCSP. Evite credenciais estáticas; use certificados com rotação automática. Para operadores humanos, autenticação forte com MFA e just-in-time privilege elevation para tarefas sensíveis.

Subtópico: Isolamento e segmentação

Microsegmentação é essencial: segregar tráfego de gerência do tráfego operacional e criar ACLs por role e serviço, usando soluções como eBPF, iptables/nftables hardening, ou SDN overlays. Para ambientes OT, mantenha gateways application protocol gateways que façam tradução e filtragem, expondo apenas as APIs necessárias.

Subtópico: Proteção de firmware e boot

Secure Boot, measured boot e remote attestation devem fazer parte do ciclo de vida. Isso exige integração com TPM e políticas que validem assinaturas de imagens. Para dispositivos sem TPM, considere Secure Elements ou mecanismos de tamper-evidence fisicamente protegidos.

Subtópico: Gestão de patches e CI/CD seguro

Adote pipelines de CI/CD que assinem artefatos, incluam scanners SCA (Software Composition Analysis) para dependências e testes de segurança automatizados. Para edge, a distribuição de patches deve ser incremental e possibilitar rollback seguro. Utilize repositórios imutáveis (registries com políticas RBAC) e verificação de assinatura em cada nó.

Subtópico: Observabilidade e detecção

Normalizar telemetria com OpenTelemetry e enviar eventos de integridade (attestation results, heartbeats, firmware version) ao SIEM. Implantar detecção baseada em regras e ML para anomalias de comportamento (picos de CPU, padrões de rede incomuns, comandos OPC-UA fora do padrão). Estruture alertas com playbooks previamente testados para acelerar resposta.

Subtópico: Resiliência e disponibilidade

Planeje degradação graciosa: nós edge devem operar em modo offline com políticas locais de ação quando o link para o core falhar. Mecanismos de quorum e failover locais ajudam a garantir continuidade. Documente RTOs e RPOs para cada workload crítico e teste-os periodicamente.

Playbooks Operacionais para Blue Team e Red Team

Subtópico: Playbook Blue Team – Detecção e contenção

• Inventário contínuo: manter CMDB de dispositivos edge com atributos: hardware, firmware, certs, localização física.
• Baseline comportamental: colher telemetria por 30 dias para definir padrões de normalidade.
• Regras de detecção específicas: ruptura de mTLS handshake, alteração de versão de firmware, comandos OPC-UA não autorizados, build de imagens não assinadas.
• Fluxo de contenção: isolar VLAN, bloquear certificados comprometidos via CRL/OCSP, descarregar configuração do node para análise forense.
• Comunicação: notificar times de OT/IT, registrar evidências (hashes, PCAPs, logs) com cadeia de custódia.
• Remediação: aplicar rollback para imagem segura, atualizar chaves, reiniciar serviços com integridade validada.
• Lessons learned: conduzir postmortem técnico e atualizar playbooks e runbooks.

Subtópico: Playbook Red Team – Execução ética e hipóteses

• Escopo autorizado: delimitar ativos, janelas de teste e fallback para reboot e rollback.
• Hipóteses de ataque: credenciais default, portas de gerenciamento expostas, imagens não assinadas, falta de microsegmentação.
• Fases de execução: reconnaissance passivo, scan controlado (nmap com rate-limits), exploit de API com payloads não destrutivos, escalada lateral mínima para comprovar vetor.
• Evidência: logs de exploração, captura de telas, hashes de arquivos colocados, PCAPs e PoC controlado.
• Relatório: impacto técnico, risco de negócio, passos de reprodução, correções recomendadas, e testes de validação pós-remediação.
• Contingência: em caso de pane, ativar rollback automático e comunicação imediata ao proprietário do ambiente.

Subtópico: Exemplos de regras Sigma/Elastic para detecção

Exemplo conciso (pseudo-regra): detectar upload de imagens para registry sem assinatura.

Métricas, KPIs e Auditoria Técnica

Subtópico: Métricas operacionais essenciais

• Time to Detect (TTD) para eventos edge – meta: < 1 hora para ativos críticos.
• Time to Contain (TTC) – tempo desde detecção até isolamento efetivo.
• Percentual de nodes com firmware atualizado e assinado.
• Percentual de tráfego do edge com criptografia end-to-end.
• Coverage de logs e telemetria: percentil de eventos capturados por dispositivo versus eventos gerados.
• Taxa de false positives por regra crítica – objetivo reduzir com tuning contínuo.

Subtópico: Auditoria técnica e compliance

Auditorias devem validar: chain of custody das assinaturas, rotação de chaves, políticas de acesso, e conformidade com políticas como NIST CSF, ISO 27001 e frameworks para OT (ISA/IEC 62443). Para ambientes regulados, documente controles técnicos e processos de auditoria contínua com evidências automatizadas (reports de compliance gerados pelo CI/CD e orquestrador).

Subtópico: Exemplos de queries para auditoria no SIEM

Subtópico: Benchmarking e maturidade

Use um modelo de maturidade com níveis (Inicial, Básico, Gerenciado, Otimizado) e alinhamento com CIS Controls, MITRE DEFENSES, e NIST. Para each level defina requisitos técnicos mensuráveis: inventário coberto, percentil de nodes com attestation, frequência de testes de penetração, e integração com SIEM/Orquestração. Isso facilita roadmap e investimentos prioritários.

Erros Comuns, Armadilhas e Correções

Subtópico: Erro 1 – Confiar em credenciais embarcadas

Muitos dispositivos chegam de fábrica com credenciais padrão. Isso é um vetor trivial, explorado massivamente. Correção: mudança forçada de credenciais no provisioning, uso de PKI e eliminação de backdoors conhecidos. Automatize a rotação inicial de credenciais no primeiro boot.

Subtópico: Erro 2 – Falta de proteção de firmware

Edge devices muitas vezes executam firmware assinado? Nem sempre. Falha em impor secure boot permite backdoor persistente. Correção: exigir assinaturas digitais verificadas pelo bootloader e habilitar mecanismos de measured boot com envio de TPM quotes ao orquestrador.

Subtópico: Erro 3 – Telemetria insuficiente

Sem logs, não há detecção. Armadilha comum: enviar apenas amostras para reduzir custos, sem estratégia de amostragem inteligente. Correção: balancear telemetria via compressão, edge collectors e regras de amostragem para eventos anômalos; priorizar alertas de integridade e eventos de segurança.

Subtópico: Erro 4 – Atualizações inseguras

Atualizações via HTTP ou sem assinatura são um convite para compromissos. Correção: OTA com TLS mTLS, imagens assinadas e verificação de assinatura no dispositivo. Implementar rollback seguro e validação atomica de transações.

Subtópico: Erro 5 – Falha na segmentação entre OT/IT

Muitos ambientes permitem confluência entre redes IT e OT sem inspeção. Correção: aplicar firewalls de aplicação, gateways protocolares e políticas que limitem comandos ao mínimo necessário. Testar cenários de falha e rota alternativa para garantir disponibilidade.

FAQ Técnico para Busca Orgânica

Subtópico: Como proteger dados em trânsito no Edge?

Resposta: Use TLS 1.3 com ciphersuites modernas, mTLS para autenticação entre dispositivos e gateways, e proteção adicional por IPsec quando adequado. Reforce com WAFs e inspeção de tráfego criptografado na borda, preferindo terminação segura no gateway com políticas de least-privilege.

Subtópico: O que é device attestation e por que é importante?

Resposta: Device attestation é o processo de provar que um dispositivo executa firmware e software esperados, frequentemente usando TPM ou Secure Elements. É crítico para evitar impostores e detectar compromissos persistentes, permitindo automação de bloqueio se o dispositivo falhar na verificação.

Subtópico: Como fazer atualizações OTA seguras?

Resposta: Implementar assinatura de imagens, verificação no boot, mTLS para canal de distribuição, rollback automatizado, e repositórios com controle de acesso. Testes de integridade e verificação de cadeia de suprimento são essenciais.

Subtópico: Quais ferramentas usar para monitorar edge?

Resposta: Coletors baseados em OpenTelemetry, Filebeat/Winlogbeat para logs, Zeek para rede (em gateways), Elastic/Opensearch para indexação, e soluções NDR (Network Detection and Response) para tráfego lateral. Para env. industrial, integradores de protocolo OPC-UA com monitoramento específico.

Subtópico: Como reduzir latência sem sacrificar segurança?

Resposta: Offload de processamento crítico para edge nodes, usar criptografia acelerada por hardware e caches locais para políticas. Utilize políticas locais (policy-as-code) para decisões de segurança imediatas, enquanto sincroniza com o core para política global.

Subtópico: Quando usar enclaves (SGX/SEV)?

Resposta: Quando for necessário proteger dados em uso em ambientes potencialmente não confiáveis – por exemplo, inferência de modelos que processam dados sensíveis. Avalie overhead e compatibilidade e combine com outros controles de proteção de dados.

Subtópico: Edge pode usar container orchestration?

Resposta: Sim, com adaptações: Kubernetes distribuído com orquestradores leves (k3s, microk8s), imagens assinadas, e policies de implantação que considerem conectividade intermitente. O orquestrador deve suportar drift detection, e as atualizações devem ser orquestradas com mecanismos de rollback e assinaturas.

Subtópico: Como auditar fornecedores de hardware/firmware?

Resposta: Solicite SBOM (Software Bill Of Materials), políticas de patch management, resultados de pentests e logs de supply chain. Exija contratos com cláusulas de segurança e planos de resposta a incidentes. Realize testes independentes sempre que possível.

Subtópico: O que é SBOM e por que é relevante para edge?

Resposta: SBOM é um inventário detalhado de componentes de software presentes em um artefato. No edge, onde dependências de terceiros são comuns, SBOMs ajudam a identificar rapidamente componentes vulneráveis e acelerar resposta e patching.

Subtópico: Como balancear custo de conectividade e necessidade de logs?

Resposta: Use estratégia store-and-forward: coletar localmente e enviar amostras relevantes. Configure thresholds para eventos críticos que devem ser enviados imediatamente e rotinas de compressão e deduplicação para dados volumosos.

Considerações Finais

Segurança em Edge Computing exige uma nova mentalidade: não adianta replicar controles do datacenter sem adaptação para os desafios de escala, heterogeneidade e conectividade intermitente. Projetar identidade, integridade de firmware, telemetria eficiente, e pipelines de atualização seguros é tão importante quanto monitorar anomalias. A estratégia vencedora integra arquitetura, processos e automação – e coloca observabilidade e defesa em camadas. Lembre-se: a defesa eficaz é construída antes do ataque. Se você resolver apenas as urgências, estará sempre um passo atrás. Invista em inventário, em zero trust para dispositivos e em testes regulares. E, sobretudo, trate o edge como parte estratégica da infraestrutura, não um periférico opcional.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

• MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
• CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
• NIST Cybersecurity Framework – figuras oficiais e referências de controles.
• ENISA – relatórios anuais com gráficos e mapas de ameaça.
• Kali Linux – documentação oficial com fluxos práticos.
• Parrot Security – documentação oficial com arquitetura modular.

Referências

• https://www.nist.gov/publications/zero-trust-architecture
• https://attack.mitre.org/
• https://www.cisa.gov/
• https://www.iso.org/standard/54534.html (ISO/IEC 27001)
• https://www.iso.org/standard/75610.html (ISA/IEC 62443)
• https://owasp.org/www-project-internet-of-things/
• https://www.etsi.org/technologies/mec (ETSI MEC)
• https://docs.microsoft.com/azure/iot-edge/
• https://aws.amazon.com/wavelength/
• https://opentelemetry.io/
• https://www.elastic.co/what-is/siem
• https://github.com/sigstore/cosign
• https://www.us-cert.gov/ (CISA Alerts and Advisories)
• https://www.kb.cert.org/vuls/ (CERT Vulnerability Notes)
• https://www.sbomframework.org/
• https://www.mitre.org/publications/technical-papers/mitre-attack-defensive-coverage (MITRE DEFENSES)

1. Cenário prático completo – Teste de deploy seguro e rollback
2. Preparação:
   1. Ambiente de testes isolado com 1 gateway, 1 edge node, 1 registry privado.
   2. Ferramentas: cosign, docker/k3s, openssl, tcpdump, filebeat, SIEM de teste (ELK).
3. Procedimento:
   1. Gerar CA local e emitir certificados para device e orquestrador:
      
      openssl genpkey -algorithm RSA -out ca.key -pkeyopt rsa_keygen_bits:4096 openssl req -x509 -new -key ca.key -out ca.crt -days 3650 -subj "/CN=Edge-CA"

      1 2	openssl genpkey -algorithm RSA -out ca.key -pkeyopt rsa_keygen_bits:4096 openssl req -x509 -new -key ca.key -out ca.crt -days 3650 -subj "/CN=Edge-CA"

   2. Assinar image com cosign:
      
      cosign generate-key-pair docker build -t registry.local/edge/app:1.0 . docker push registry.local/edge/app:1.0 cosign sign --key cosign.key registry.local/edge/app:1.0

      1 2 3 4

      cosign generate-key-pair docker build -t registry.local/edge/app:1.0 . docker push registry.local/edge/app:1.0 cosign sign --key cosign.key registry.local/edge/app:1.0

   3. No gateway, configurar verificação pré-execução:
      
      cosign verify --key cosign.pub registry.local/edge/app:1.0 # Se falhar, abortar deploy e acionar rollback

      1 2	cosign verify --key cosign.pub registry.local/edge/app:1.0 # Se falhar, abortar deploy e acionar rollback

   4. Testar cenário de imagem inválida: inserir imagem sem assinatura e confirmar que deploy é bloqueado e alerta gerado no SIEM.
   5. Testar rollback: provocar crash do serviço e verificar ativação do watchdog que reverte para imagem anterior assinada.
4. Validação:
   1. Logs: grep por eventos de assinatura e alertas no SIEM.
   2. Rede: pcap para comprovar handshake mTLS entre edge e orquestrador.
   3. Integridade: checar hash da imagem e assinatura.
5. Rollback:
   1. Se o deploy falhar e não houver rollback automático, restaurar snapshot H:
      
      # Exemplo de restauração manual docker pull registry.local/edge/app:0.9 docker tag registry.local/edge/app:0.9 registry.local/edge/app:latest systemctl restart edge-service

      1 2 3 4

      # Exemplo de restauração manual docker pull registry.local/edge/app:0.9 docker tag registry.local/edge/app:0.9 registry.local/edge/app:latest systemctl restart edge-service

6. Documentar evidências e atualizar playbooks.

Checklist Blue Team

• Inventário completo de dispositivos com atributos e firmware versão
• Remote attestation habilitado e testado
• mTLS entre todos os hops críticos
• Assinatura de imagens e verificação local (cosign ou similar)
• Telemetria padronizada e pipeline resiliente com store-and-forward
• Regras de detecção para handshake TLS falho, uploads sem assinatura, alterações de firmware
• Playbooks de contenção e rollback testados
• Procedimentos de cadeia de custódia para evidências

Checklist Red Team

• Escopo e autorização formal para testes
• Inventário de alvos e janelas de teste
• Hipóteses de ataque documentadas
• Métodos de exploração não destrutivos e planos de rollback
• Coleta de evidências: logs, PCAP, captura de tela, hashes
• Relatório técnico com passos de reprodução, risco e mitigação
• Coordenação com Blue Team para validação pós-remediação

Recursos Visuais Sugeridos

• ETSI MEC Architecture Overview – https://www.etsi.org/technologies/mec
• NIST Zero Trust Architecture – https://www.nist.gov/publications/zero-trust-architecture
• MITRE ATT&CK for ICS – https://collaborate.mitre.org/attackics/index.php/Main_Page
• OWASP IoT Top Ten – https://owasp.org/www-project-internet-of-things/
• Sigstore and cosign docs – https://github.com/sigstore/cosign
• OpenTelemetry architecture – https://opentelemetry.io/docs/
• AWS Wavelength docs – https://aws.amazon.com/wavelength/
• Azure IoT Edge documentation – https://learn.microsoft.com/azure/iot-edge/