O dia em que o transporte marítimo global perdeu sua memória digital: Maersk, NotPetya e responsabilidade operacional

Resumo

• O NotPetya entrou na Maersk por meio de um software usado para declaração de impostos na Ucrânia e tornou aplicativos e dados indisponíveis em um ambiente globalmente conectado. A empresa desligou sistemas adicionais como precaução, enquanto o roubo de credenciais e os múltiplos métodos de propagação do malware tornaram a correção isolada uma defesa incompleta.
• A Maersk manteve o controle de seus navios, mas seus negócios de contêineres sofreram interrupções significativas. As funções de reserva, portão de terminal e informações de carga falharam; a APM Terminals relatou que os serviços de portão ainda estavam sendo expandidos em vários portos três dias após o ataque. Os ativos físicos permaneciam presentes enquanto a autoridade digital para coordená-los desaparecia.
• A empresa implementou soluções manuais extensas e reconstruiu a infraestrutura em velocidade excepcional. O presidente da Maersk descreveu mais tarde a reinstalação de 4.000 servidores, 45.000 computadores e 2.500 aplicativos em dez dias. Uma reconstrução jornalística detalhada afirma que um controlador de domínio desconectado em Gana forneceu os dados de identidade necessários para reiniciar os serviços principais; esse relato é importante, mas não é um laudo forense oficial.
• A Maersk relatou um efeito de US$ 250-300 milhões na lucratividade, principalmente devido a negócios temporariamente perdidos em julho e agosto, além de custos de restauração e operacionais extraordinários. Esse valor mede o impacto reconhecido pela empresa, não as perdas completas de caminhoneiros, transitários, proprietários de carga, agências públicas ou pequenas empresas a jusante.
• A responsabilidade é em camadas. Os atores militares russos posteriormente atribuídos e acusados em conexão com o NotPetya são responsáveis pelo ataque destrutivo. A Maersk permaneceu responsável pela resiliência dos sistemas sob seu controle, pelas alegações de continuidade feitas aos clientes e por demonstrar que a remediação abordou os caminhos pelos quais uma dependência regional de software se tornou uma falha operacional global.
• A lição duradoura não é apenas manter backups. Um operador crítico deve ser capaz de recuperar identidade, configuração, dados operacionais e comunicações em um ambiente limpo; executar processos manuais limitados sem perder segurança ou integridade da carga; e fornecer a órgãos públicos e pequenos clientes informações oportunas e portáveis para ativar seus próprios planos de continuidade.

Um operador global perdeu a capacidade de dizer o que deveria se mover em seguida

Na terça-feira, 27 de junho de 2017, a A.P. Moller - Maersk foi uma das muitas organizações atingidas por um malware que parecia ransomware, mas se comportava como um instrumento destrutivo. As imagens imediatas eram familiares de um incidente cibernético de escritório: telas escureceram, aplicativos pararam, funcionários perderam o acesso. A consequência não se limitou aos escritórios. A Maersk conectava transporte oceânico, terminais portuários e transitários entre jurisdições e fusos horários.

Quando os aplicativos compartilhados e os serviços de identidade se tornaram indisponíveis, a interrupção alcançou os pontos onde um caminhão entra em um terminal, uma reserva se torna um movimento de carga e um manifesto eletrônico informa ao operador o que está dentro de um navio.

A apresentação aos investidores do segundo trimestre de 2017 da empresa fornece o relato conciso mais sólido. A Maersk disse que o malware entrou por meio de software usado para declarar impostos na Ucrânia, tornou aplicativos e dados indisponíveis e afetou principalmente seus negócios relacionados a contêineres: Maersk Line, APM Terminals e Damco. Afirmou que vários sistemas foram desligados como precaução, que muitas soluções manuais foram introduzidas e que o controle total dos navios foi mantido.

Também disse que houve interrupção significativa afetando funcionários e clientes, enquanto relatava não haver violação ou perda de dados de terceiros.

Essas declarações estabelecem um limite essencial. Isso não foi relatado publicamente como uma perda de navegação ou propulsão, e uma análise não deve transformar uma grave interrupção comercial e de terminal em uma emergência fictícia de controle de navios. No entanto, a sobrevivência do controle do navio não significou que o serviço de navegação sobreviveu intacto. Um navio pode ser navegável com segurança enquanto a rede ao seu redor não pode aceitar sua próxima carga, ler os arquivos necessários para trabalhar sua carga, liberar contêineres para caminhoneiros ou fornecer status confiável aos clientes.

A resiliência operacional tem várias camadas, e o estado seguro de uma camada não confere continuidade às outras.

O incidente passou rapidamente de exposição local de software a interrupção empresarial. O relato técnico contemporâneo da Microsoft sobre o surto de Petya observou um caminho inicial da cadeia de suprimentos através do atualizador M.E.Doc e descreveu movimento lateral usando roubo de credenciais e personificação, bem como exploração da vulnerabilidade SMB abordada pelo MS17-010. Uma análise de rede posterior da Microsoft caracterizou a propagação como sofisticada e bem testada. O ponto prático não é que uma correção ausente explique a Maersk. As evidências públicas não suportam essa conclusão simplista.

O NotPetya podia usar mais de uma rota, incluindo credenciais legítimas, então a exposição dependia de privilégio de identidade, alcance de rede, segmentação, confiança de software e velocidade de contenção, bem como status de vulnerabilidade.

Em 30 de junho, o quadro operacional estava melhorando, mas ainda irregular. Uma atualização da APM Terminals disse que estava expandindo os serviços de portão em uma lista de portos que incluía Los Angeles. Uma atualização pública desse tipo é valiosa porque expõe a unidade real de recuperação: não "TI está de volta", mas um serviço de portão ou terminal específico em um local específico. A restauração global era um portfólio de estados locais. Alguns locais podiam trabalhar carga, outros ofereciam portões limitados e os sistemas voltados ao cliente se recuperavam em seu próprio cronograma.

O relatório financeiro posterior da empresa confirma que isso foi mais do que um pequeno inconveniente técnico. Seu relatório interino do terceiro trimestre de 2017 colocou o efeito na lucratividade em US$ 250-300 milhões, com a grande maioria relacionada à Maersk Line no terceiro trimestre. Disse que os volumes transportados caíram 2,5% em relação ao trimestre comparável e foram negativamente afetados pelo ataque, e descreveu a maior parte do impacto financeiro como negócios temporariamente perdidos em julho e agosto. O capital de giro também foi afetado, enquanto a APM Terminals e a Damco registraram efeitos relacionados ao ataque.

Esse período contábil é importante. A interrupção mais visível ocorreu ao longo de dias, mas as consequências comerciais persistiram depois que os aplicativos começaram a retornar. Contêineres e cronogramas não retornam instantaneamente às suas posições anteriores quando um servidor é iniciado. Reservas perdidas durante a incerteza não são restauradas reiniciando um portal. Um cliente que desvia carga, um caminhoneiro que perde uma vez, ou um fabricante que paga por outra rota cria uma consequência que vai além da restauração técnica.

O tempo de recuperação, portanto, deve ser medido separadamente para infraestrutura, aplicativos, locais, backlogs de transações e clientes.

O ataque foi destrutivo, não uma negociação comum de resgate

Chamar o evento de ransomware pode obscurecer as decisões que defensores e executivos enfrentaram. O NotPetya exibia uma demanda de pagamento, mas seu design e a atribuição oficial posterior apoiam o tratamento como malware destrutivo. A declaração de atribuição do Reino Unido de 2018 julgou o governo russo, especificamente os militares russos, responsáveis e disse que o ataque se disfarçou de empresa criminosa enquanto seu principal propósito era a interrupção. Em 2020, o Departamento de Justiça dos Estados Unidos acusou seis oficiais do GRU russo em conexão com uma campanha que incluía o NotPetya.

Essas acusações são alegações, não condenações, mas são uma ação formal de responsabilidade e o departamento descreveu explicitamente o malware como destrutivo.

Essa distinção muda a estratégia de recuperação. Em um cenário comum de extorsão, os líderes ainda podem debater se existe um descriptografador, se os dados foram roubados e se o pagamento poderia alterar o resultado. Com um evento destrutivo, a preservação e a reconstrução limpa tornam-se centrais. Restaurar uma máquina aparentemente funcional não é suficiente se credenciais privilegiadas, caminhos de distribuição de software ou imagens confiáveis podem estar comprometidos. A organização deve estabelecer um plano de controle limpo a partir do qual possa reconstruir, redefinir a confiança e decidir quais dados são seguros para reintroduzir.

Também muda a justiça da análise de responsabilidade. A Maersk não escolheu ser atacada, e a entidade que libera um worm destrutivo é responsável pelos danos previsíveis e imprudentes que causa além de um alvo pretendido. A responsabilidade da vítima não substitui a responsabilidade do atacante. As duas coexistem porque diferentes atores controlavam diferentes partes da cadeia causal. Atores estatais controlavam a decisão de implantar código destrutivo. O fornecedor de software controlava seu ambiente de atualização.

A Maersk controlava como uma dependência de negócios ucraniana se conectava ao seu patrimônio global, como os limites privilegiados de identidade e rede eram protegidos e quão recuperáveis eram seus serviços críticos.

O registro público não é uma avaliação forense completa desses controles. Os arquivos da Maersk identificam a rota de entrada e os efeitos, mas não publicam um caminho de propagação dispositivo por dispositivo, inventário de patches, gráfico de privilégios ou descoberta independente sobre quais salvaguardas falharam. Relatos posteriores forneceram detalhes importantes, mas um argumento de responsabilidade não deve preencher as lacunas restantes com palpites confiantes. É justo perguntar por que um endpoint infectado pôde contribuir para uma perda em toda a empresa.

Não é justo afirmar, sem o registro interno, que um funcionário nomeado, uma máquina sem patch ou uma configuração de produto foi a única causa.

A melhor questão de governança é sobre domínios de falha. Uma multinacional às vezes deve executar software localmente exigido, incluindo ferramentas fiscais e alfandegárias que nunca seriam selecionadas como padrão global de tecnologia. A necessidade local não justifica a confiança global. Sistemas com propósitos regionais estreitos devem ser colocados em uma arquitetura que assume que seus canais de atualização podem falhar: privilégios restritos, egresso controlado, alcance limitado, execução monitorada, credenciais administrativas separadas e isolamento rápido.

Se o negócio não puder remover a exposição, pode reduzir a autoridade que essa exposição tem sobre todo o resto.

Capacidade física e autoridade digital foram separadas

A logística de contêineres torna a diferença entre ativos e autoridade excepcionalmente visível. Navios, guindastes, contêineres, chassis, portões e armazéns são físicos. Sua operação eficiente depende de registros digitais que respondem a perguntas básicas, mas consequentes: Qual caixa é esta? Está liberada? Para onde deve ir? É seguro levantar? Qual cliente tem autoridade para coletá-la? Qual navio e viagem devem recebê-la? Quais condições perigosas, refrigeradas ou sensíveis ao tempo se aplicam?

Uma reconstrução posterior da WIRED sobre o NotPetya e a recuperação da Maersk relatou que 17 dos 76 terminais da APM Terminals foram afetados, que os portões e algumas operações de guindaste pararam, e que o site central de reservas estava indisponível. Descreveu terminais perdendo acesso a arquivos eletrônicos que identificavam o conteúdo dos navios, filas de caminhões em Elizabeth, Nova Jersey, e clientes lutando para localizar ou redirecionar cargas. Esta é uma evidência narrativa profundamente relatada com base em entrevistas, não um relatório forense de um regulador.

Suas alegações internas específicas devem ser atribuídas de acordo, enquanto seu relato amplo é consistente com as divulgações da Maersk de interrupção significativa do cliente e volumes perdidos.

A falha revela por que "o porto permaneceu aberto" é uma medida de continuidade inadequada. Uma autoridade portuária, alfândega, operador de terminal, linha de navegação, operador ferroviário e caminhoneiro podem estar tecnicamente disponíveis enquanto um movimento de carga permanece impossível. A transação requer várias permissões e registros para concordar. Se um participante controla o estado autoritativo da carga e esse estado está indisponível, a capacidade física sobressalente em outro lugar pode não ajudar.

Por outro lado, a disponibilidade digital sem estado confiável pode ser perigosa. Um terminal não deve mover um contêiner apenas porque um guindaste pode alcançá-lo. O manuseio manual deve preservar restrições de peso, mercadorias perigosas, alfândega, reefer, propriedade e estivagem. A pressão para "manter a carga em movimento" não pode substituir as informações necessárias para o movimento seguro e legal. Um modo manual resiliente não é, portanto, uma instrução genérica para usar papel.

É um serviço deliberadamente restrito com transações definidas, dados de referência disponíveis independentemente, verificações duplas, identificadores de reconciliação e condições de parada claras.

A Maersk relatou que introduziu um grande número de soluções manuais. O relato da WIRED descreve e-mail pessoal, mensagens, planilhas e papel presos a contêineres. Tal improvisação pode ser uma ponte racional durante uma emergência sem precedentes, e fala da engenhosidade dos funcionários. Também cria riscos de integridade, privacidade, autorização e reconciliação. Uma mensagem recebida em uma conta de emergência pode ser autêntica, enganosa ou maliciosa. Uma planilha pode preservar uma reserva, mas omitir um campo de carga perigosa.

Uma liberação em papel pode permitir o movimento enquanto cria transações duplicadas ou não faturadas posteriormente.

A lição de responsabilidade não é proibir a improvisação. É transformar as melhores práticas de emergência em capacidade controlada antes do próximo incidente. Um serviço mínimo viável de terminal deve especificar quais classes de carga podem se mover, quais dados independentes devem estar presentes, quem pode aprovar uma exceção, como cada ação manual obtém um registro único, como as autoridades públicas são contatadas e como os registros serão reconciliados quando os sistemas retornarem. A capacidade deve ser testada em caminhões ou contêineres por hora, não descrita apenas como "fallback manual disponível".

A recuperação dependia da reconstrução da confiança

A parte mais memorável da história da Maersk diz respeito ao Active Directory. Na reconstrução da WIRED, aproximadamente 150 controladores de domínio haviam sincronizado entre si e foram apagados, enquanto nenhum backup utilizável separado dessa camada de identidade pôde ser encontrado inicialmente. Um controlador de domínio em Gana havia sido desconectado durante uma queda de energia e sobreviveu. A largura de banda limitada tornou a transferência remota impraticável, então os funcionários teriam retransmitido uma unidade através da Nigéria para o centro de recuperação na Inglaterra.

Este relato tem sido frequentemente reduzido a uma anedota sobre sorte. Seu significado mais profundo é que a identidade era um pré-requisito para tudo acima dela. Uma empresa pode possuir backups de dados de aplicativos e ainda ser incapaz de restaurar as operações se não puder recriar usuários confiáveis, máquinas, permissões, contas de serviço e autoridade administrativa. O sistema de identidade não é apenas outro aplicativo. Faz parte da maquinaria que declara quais componentes restaurados têm permissão para se comunicar e agir.

A história também distingue replicação de backup. Múltiplos controladores de domínio sincronizados melhoram a disponibilidade contra falhas comuns de hardware. Eles não criam recuperação independente se o estado destrutivo puder alcançar todas as réplicas. Redundância responde "outro nó ativo pode servir?". Backup responde "a organização pode retornar a um estado anterior bom conhecido depois que todos os nós ativos se tornarem não confiáveis?". Uma cópia que compartilha o mesmo plano administrativo, conectividade e caminho destrutivo pode ser redundante, mas não recuperável.

A orientação moderna torna essa independência explícita. O Centro Nacional de Segurança Cibernética do Reino Unido recomenda backups offline ou segregados, várias cópias, restauração testada e recuperação limpa. A orientação de planejamento de contingência do NIST trata a recuperação como uma combinação coordenada de planos, procedimentos e medidas técnicas, incluindo equipamentos alternativos, processamento manual e locais alternativos. Nenhum documento prova o que a Maersk tinha em 2017. Eles fornecem uma maneira disciplinada de avaliar o que o evento mostrou.

Para um operador logístico global, o conjunto recuperável tem pelo menos quatro partes. Primeiro, identidade e o plano de controle administrativo. Segundo, configuração de infraestrutura: definições de rede, segurança, nuvem, endpoint e plataforma que podem ser reconstruídas sem confiar no patrimônio danificado. Terceiro, estado operacional: reservas, manifestos, localização de contêineres, status alfandegário, atributos de mercadorias perigosas, atribuições de equipamentos e instruções do cliente.

Quarto, o mapa de relacionamento externo: contatos e canais verificados para portos, autoridades, fornecedores, clientes, bancos e parceiros de emergência.

Cada parte precisa de seu próprio objetivo de ponto de recuperação e tempo de recuperação. Um backup de servidor de três dias pode ser aceitável para um serviço de referência estático e inaceitável para eventos de contêineres que mudam a cada minuto. Um backup de identidade limpo pode restaurar o acesso, mas não informar a um terminal quais transações ocorreram manualmente durante a interrupção. Uma lista de contatos de clientes armazenada atrás do provedor de identidade com falha pode estar completa, mas inútil. "Backups bem-sucedidos" é, portanto, uma métrica de conselho pobre.

A evidência útil é se serviços representativos foram reconstruídos a partir de entradas protegidas dentro de um ambiente limpo, em escala, dentro do período que a rede operacional e seus clientes podem tolerar.

Dez dias foi uma conquista, não um veredito completo de resiliência

No Fórum Econômico Mundial em janeiro de 2018, o presidente da Maersk, Jim Hagemann Snabe, descreveu um esforço notável: reconstruir 4.000 servidores, 45.000 computadores pessoais e 2.500 aplicativos em dez dias. A escala é amplamente citada porque captura o trabalho e a urgência da resposta. O relato posterior da WIRED diz que algum trabalho de recuperação continuou por muito mais tempo, o que é compatível com uma distinção entre reconstruir o patrimônio central e completar cada restauração de aplicativo ou usuário.

O relatório anual de 2017 da própria Maersk chamou a recuperação de rápida e relatou US$ 250-300 milhões em perdas cobrindo receita, restauração de TI e custos operacionais extraordinários. Disse que iniciativas imediatas e de longo prazo foram implementadas ou planejadas para proteger o negócio digital, fortalecer a plataforma de infraestrutura, melhorar a continuidade e recuperação dos serviços de TI e reforçar os planos de continuidade de negócios. A empresa também adquiriu seguro cibernético.

Essa é uma resposta de gestão credível, mas não torna a velocidade de recuperação um veredito suficiente sobre a resiliência pré-incidente ou a garantia pós-incidente. Recuperação heroica e resiliência projetada são qualidades diferentes. A recuperação heroica depende de pessoas excepcionais, compras de emergência, ampla autoridade executiva, suporte do fornecedor e esforço sustentado. A resiliência projetada torna os resultados críticos menos dependentes de condições excepcionais.

Ela reduz o raio de explosão, preserva material de recuperação confiável, pré-arranja capacidade e fornece decisões praticadas antes que a fadiga e a incerteza se instalem.

A distinção é importante para a responsabilidade dos funcionários. O elogio ao trabalho extraordinário pode normalizar silenciosamente um modelo operacional que exige trabalho extraordinário. Os conselhos devem perguntar quantas pessoas trabalharam horas inseguras, quais funções não tinham substituto treinado, quais etapas de recuperação dependiam de conhecimento pessoal e se a autoridade de emergência foi documentada após o fato. Um programa de resiliência deve preservar o conhecimento improvisacional revelado por uma crise, reduzindo a necessidade de repetir o fardo físico e psicológico.

Também é importante para a responsabilidade financeira. A estimativa de US$ 250-300 milhões não é um total de danos global. A Maersk descreveu o que o ataque custou à sua própria lucratividade. Não captura cada volta de caminhão não compensada, reserva de armazém, slot de produção perdido, item estragado, compra pública atrasada ou pressão de capital de giro experimentada por clientes e provedores de serviços. O relatório da WIRED cita caminhoneiros e empresas de logística que disseram ter sofrido perdas substanciais, mas nenhum conjunto de dados auditado suporta adicionar essas anedotas em um número único para toda a economia.

O seguro também transfere apenas consequências financeiras específicas. Não restaura um carregamento de medicamentos, preserva o cliente de um pequeno importador ou dá a uma autoridade portuária visibilidade de carga em tempo real. Um conselho que relata limites de seguro sem relatar evidências de recuperação operacional está medindo a proteção do balanço patrimonial, não a resiliência do serviço. Ambos são importantes, mas não são substitutos.

Responsabilidade segue controle, não proximidade ao malware

A frase "a Maersk foi uma vítima" é verdadeira e incompleta. Também "a Maersk deveria estar preparada" o é. Uma alocação útil de responsabilidade identifica as decisões que cada ator poderia tomar antes, durante e depois do evento.

Esta alocação evita tornar o administrador mais próximo o centro moral de um evento sistêmico. Se um funcionário local era obrigado a usar software fiscal ucraniano, essa pessoa não decidiu a arquitetura global de confiança. Se um funcionário do terminal usou um canal pessoal para resgatar uma remessa, essa ação deve ser revisada quanto ao risco e aprendida, não isolada das condições que a tornaram necessária. A responsabilidade sênior começa onde reside a autoridade sobre arquitetura, orçamento, aceitação de risco e promessas de serviço.

Também evita desculpar organizações a jusante. Uma agência pública ou pequeno importador não pode redesenhar o sistema de identidade de uma transportadora. Pode decidir se seu próprio plano de continuidade assume que o portal, a equipe de contas e o terminal da transportadora permanecerão todos disponíveis juntos. Pode manter identificadores de remessa e documentos essenciais fora do portal do provedor, concordar com contatos de emergência, classificar quais mercadorias justificam roteamento alternativo e entender quanto tempo seu inventário ou compromisso de serviço pode absorver um atraso.

A responsabilidade deve permanecer proporcional. Uma pequena empresa não pode manter economicamente reservas duplicadas em todas as rotas ou reservar frete aéreo para carga comum. Um comprador municipal não pode comandar a sequência de recuperação de uma transportadora global. O padrão não é redundância infinita. É a seleção consciente de medidas de continuidade com base na consequência, sensibilidade ao tempo, substituibilidade e recursos disponíveis.

Portos transformam falha privada em um problema de continuidade pública

Os portos são ecossistemas institucionais. Autoridades portuárias públicas, alfândega e agências de fronteira, polícia, inspetores de saúde e agricultura, terminais operados privadamente, transportadoras, ferrovias, caminhoneiros e transitários compartilham o mesmo espaço físico e informacional. Uma falha originada na rede empresarial de uma empresa pode, portanto, criar tarefas públicas mesmo quando nenhum sistema governamental é comprometido.

A revisão de 2025 do Government Accountability Office dos EUA sobre segurança cibernética marítima usa o NotPetya como um exemplo proeminente, relatando que os computadores da Maersk desligaram, as operações portuárias, incluindo as operações dos EUA, foram interrompidas e os navios ficaram ociosos no mar. O relatório também encontrou lacunas mais amplas no processo de registro de incidentes da Guarda Costeira, planejamento estratégico e práticas da força de trabalho cibernética.

O significado é institucional: o setor público não pode cumprir as responsabilidades de segurança marítima e continuidade apenas assumindo que cada operador privado gerenciou suas próprias dependências.

A linha de base da política internacional já estava se movendo quando o NotPetya atingiu. Dez dias antes do ataque, a Organização Marítima Internacional adotou a Resolução MSC.428(98), incentivando o risco cibernético a ser abordado nos sistemas de gestão de segurança até a primeira verificação anual após 1º de janeiro de 2021. As diretrizes de risco cibernético marítimo de 2017 associadas organizaram a ação em torno de identificar, proteger, detectar, responder e recuperar, com envolvimento da alta administração e continuidade das operações de navegação.

Esses instrumentos não devem ser mal aplicados. São orientações de segurança marítima de alto nível, não uma conclusão retrospectiva de que a Maersk violou uma regra específica de TI de terminal em junho de 2017. Sua temporização mostra que o risco cibernético para a navegação não foi inventado pelo NotPetya. O incidente acelerou uma questão de responsabilidade que o setor já estava enfrentando: como conectar a governança cibernética aos sistemas de segurança e continuidade que os líderes marítimos já entendem.

Orientações posteriores tornaram-se mais operacionais. As diretrizes de risco cibernético portuário da Agência da União Europeia para a Segurança Cibernética mapeiam práticas de risco para processos de segurança portuária e enfatizam um ciclo de avaliação adaptável. O guia de resiliência portuária da UNCTAD trata transportadoras, alfândega, transitários, proprietários de carga e operadores logísticos terrestres como partes interessadas colaboradoras. Observa que as mercadorias containerizadas representam uma parcela muito maior do comércio marítimo em valor do que em volume e que os portos podem se tornar pontos únicos de falha.

O planejamento de continuidade pública deve traduzir esses princípios em questões operacionais. Quais dados mínimos de carga a alfândega e um terminal podem usar se a plataforma da transportadora estiver indisponível? Um porto pode autenticar instruções de emergência através de um canal independente do sistema de identidade do operador afetado? Quem gerencia as filas de caminhões quando os sistemas de agendamento e portão falham? Como as cargas refrigeradas, perigosas, médicas, alimentícias e de serviço público são priorizadas sem permitir que a prioridade autodeclarada sobrecarregue o processo?

Quando as regras de armazenamento, estadia ou acesso serão suspensas, e quem pode anunciar essa decisão?

A resposta correta raramente é uma planilha compartilhada gigante esperando um desastre. Uma central de fallback pode se tornar outra falha comum e uma fonte tentadora de dados comerciais confidenciais. Uma melhor continuidade usa conjuntos mínimos de dados acordados, formatos interoperáveis, extratos locais protegidos, autoridade legal clara, caminhos de comunicação testados e uma maneira federada de reconciliar eventos. O papel do setor público é convocar e testar as interfaces que nenhuma empresa possui individualmente.

A digitalização portuária torna isso mais urgente. O Banco Mundial descreve os sistemas de comunidade portuária como plataformas colaborativas que conectam alfândega, administração portuária, transportadoras, empresas de logística e transitários. Tais sistemas podem reduzir custos e melhorar a resiliência, especialmente para participantes menores, mas seu valor aumenta a consequência de falha ou má integração. A arquitetura de eficiência precisa de arquitetura de degradação: uma resposta para o que cada participante ainda pode ver e fazer quando a plataforma compartilhada ou um grande contribuinte desaparece.

Pequenas empresas absorvem atrasos de forma diferente

A interrupção da Maersk atingiu pequenas empresas em várias funções: transitários organizando remessas, empresas de caminhões servindo terminais, despachantes aduaneiros, operadores de armazéns, exportadores, importadores e empresas esperando por insumos. Alguns eram clientes diretos; outros eram economicamente dependentes do throughput do terminal sem um contrato que prometesse compensação. Seu problema de continuidade diferia do da Maersk. Eles não precisavam reconstruir milhares de servidores. Precisavam de status autoritativo, acesso à carga, uma alternativa credível e dinheiro suficiente para sobreviver à espera.

Pequenas empresas estão estruturalmente expostas à incerteza logística. O trabalho da OCDE sobre PMEs e comércio observa que as empresas menores têm menos recursos para atender aos custos transfronteiriços e podem ser desproporcionalmente afetadas pelas barreiras comerciais, enquanto a facilitação do comércio e a conectividade ajudam a apoiar a entrega pontual. Uma interrupção que adiciona telefonemas, armazenamento, documentação duplicada, transporte de emergência e datas de liberação incertas impõe mais do que um atraso de tempo. Adiciona custos fixos de coordenação que são mais difíceis de distribuir pelo volume.

A concentração de provedores tem dois significados para uma PME. Pode haver apenas uma transportadora ou terminal comercialmente sensato para uma rota, e vários serviços aparentemente separados podem depender do mesmo plano de controle digital do operador. Comprar transporte oceânico através de um transitário não cria necessariamente uma rota independente se a reserva, o terminal e a cadeia de status do cliente convergirem na mesma transportadora. O mapeamento de continuidade deve seguir o caminho real de movimento e informação, não o número de faturas ou intermediários.

A resposta prática começa com a custódia dos dados. Um pequeno importador deve manter referências de reserva, conhecimentos e documentos comerciais, números de contêiner e lacre, status alfandegário, requisitos perigosos ou refrigerados, contatos e marcos prometidos em um local que não exija a abertura do portal da transportadora. Isso não é uma tentativa de duplicar o banco de dados operacional do provedor. É o pacote mínimo necessário para identificar a remessa, provar autoridade e pedir ajuda a outra parte.

Em seguida vem a triagem. As empresas devem decidir antecipadamente qual carga pode esperar, qual pode usar outra viagem, qual ameaça a produção ou um compromisso público, e qual pode justificar substituição cara por via aérea ou rodoviária. A resposta deve incluir uma autoridade de gastos. Durante o evento da Maersk, alternativas escassas e informações incertas forçaram decisões sob pressão. Um limite pré-acordado permite que um líder de operações aja antes que um fundador, diretor financeiro ou cliente público possa ser contatado.

A comunicação precisa da mesma independência que o backup. O Centro Nacional de Segurança Cibernética do Reino Unido oferece um guia de resposta e recuperação para pequenas empresas que enfatiza preparação, funções, contatos, resolução, relatório e aprendizado. Para um evento de dependência logística, a folha de contatos deve se estender além dos respondedores cibernéticos internos. Deve incluir a rota de emergência da transportadora, terminal, transitário, corretor, armazém, seguradora, banco, clientes críticos e a autoridade pública relevante.

Uma cópia impressa ou armazenada independentemente é importante quando o e-mail ou o logon único faz parte da falha.

Finalmente, o contrato deve dizer como é a justiça operacional. Canais de notificação, acesso a dados, isenção de taxas durante portões inacessíveis, responsabilidades de preservação de carga, documentação para reclamações e rotas de escalada são mais úteis do que uma promessa ampla de alta disponibilidade. Nem todo pequeno cliente pode negociar termos personalizados, e é por isso que as autoridades portuárias, reguladores, associações comerciais e grandes provedores de logística têm um papel na padronização das proteções. O objetivo não é compensação garantida para cada atraso.

É um processo previsível que não force a parte menos poderosa a provar uma interrupção que o operador já sabe que ocorreu.

Recursos gerais de preparação permanecem relevantes. O Ready Business combina comunicações, recuperação de TI, planos de continuidade, treinamento e exercícios, em vez de tratar a recuperação cibernética como um plano técnico isolado. A orientação da CISA para líderes corporativos diz similarmente para focar o investimento em resiliência em funções críticas de negócios e testar a continuidade após a intrusão.

Para uma pequena empresa, o exercício pode ser modesto: uma hora em que a equipe assume que o portal da transportadora, o representante de contas e o terminal principal estão indisponíveis, depois tenta localizar duas remessas prioritárias e tomar uma decisão documentada de redirecionamento.

A continuidade manual deve ter um limite de design

As soluções manuais da Maersk são justamente admiradas porque preservaram grande parte do serviço enquanto o patrimônio digital estava sendo reconstruído. Elas também mostram por que a continuidade manual não pode ser descrita como um substituto ilimitado. O throughput humano é menor, os erros são mais difíceis de detectar e os registros necessários para reconciliação posterior se multiplicam rapidamente. Quanto mais tempo o modo degradado dura, mais seu próprio backlog e dívida de controle se tornam um problema de recuperação.

Um plano manual credível tem um escopo e duração máximos. Identifica as funções que devem continuar, aquelas que podem pausar e aquelas que não devem ser tentadas sem sistemas. Aloca capacidade escassa de acordo com a segurança e a consequência. Estabelece como uma transação é autorizada, registrada e verificada. Mantém um relógio e sequência de incidentes únicos, mesmo que as equipes locais usem ferramentas diferentes. Reserva pessoas para reconciliação, porque todo registro temporário eventualmente terá que encontrar o sistema restaurado.

O plano também deve sobreviver à perda da tecnologia comum do local de trabalho. Formulários de emergência armazenados no mesmo compartilhamento de arquivos, listas de contatos atrás do mesmo provedor de identidade e pontes de conferência dependentes da mesma rede não são ativos de continuidade. A orientação de resposta técnica do NCSC aconselha as organizações a manter backups limpos, dispositivos sobressalentes e logs utilizáveis; o princípio mais amplo é que os respondedores precisam de um conjunto mínimo independente de ferramentas.

Para uma empresa de logística distribuída, isso pode incluir laptops limpos, comunicações separadas, identidades externas pré-aprovadas, repositórios de configuração protegidos e kits regionais de recuperação.

As operações manuais devem ser exercitadas com as partes que as recebem. Um terminal pode produzir uma liberação em papel, mas não tem valor de continuidade se a equipe do portão, a alfândega ou um caminhoneiro não puder validá-la. Uma transportadora pode aceitar uma reserva por e-mail de emergência, mas a reserva é insegura se as declarações de mercadorias perigosas não puderem ser seguidas. Uma autoridade pública pode criar uma lista prioritária, mas falhará se não houver uma maneira verificada de corresponder essa lista aos contêineres.

Exercícios conjuntos descobrem essas falhas de interface antes que um incidente crie pressão comercial para ignorá-las.

As métricas de capacidade devem ser honestas. "Terminais podem operar manualmente" diz pouco. Uma declaração mais forte é que um local especificado pode processar com segurança uma categoria definida de movimentos a uma porcentagem medida do throughput normal por um certo número de horas, com um ônus conhecido de reconciliação e exclusões claras. Publicar todos os detalhes pode criar risco de segurança ou comercial, mas os conselhos e as autoridades relevantes devem ver as evidências.

O que um conselho deve pedir para ver

Após o NotPetya, a Maersk disse que fortaleceu a resiliência cibernética, a infraestrutura, a continuidade do serviço, a recuperação e a continuidade dos negócios. Os relatórios públicos não divulgam detalhes suficientes para verificar independentemente o estado atual de cada medida, e a ausência de detalhes não é evidência de que o trabalho não foi feito. Significa que os leitores externos devem distinguir um programa declarado de resultados testados.

O primeiro artefato do conselho deve ser um mapa de serviços, não uma contagem de ativos. Deve começar com resultados como aceitar uma reserva, admitir um caminhão, ler dados de carga do navio, liberar um contêiner, monitorar um reefer e comunicar status. Para cada resultado, deve identificar dependências de identidade, rede, aplicativo, dados, instalação, fornecedor e agência pública. O mapa deve expor quando vários resultados compartilham um plano administrativo ou caminho de confiança de software local.

O segundo artefato deve ser evidência de recuperação destrutiva. A organização pode construir um ambiente de identidade limpo sem qualquer serviço empresarial ativo? Credenciais, chaves, confiança de dispositivo, configuração e estações de trabalho privilegiadas são restauradas em uma ordem controlada? Os backups são inacessíveis a administradores comprometidos, retidos por tempo suficiente, escaneados e testados? Um terminal ou serviço de reservas representativo foi reconstruído a partir de entradas protegidas em escala operacional?

O terceiro deve ser evidência de operação degradada. Quais serviços podem funcionar manualmente, com que capacidade e com quais controles de segurança? Quando a empresa para de aceitar novos trabalhos para proteger a carga já em sua custódia? Como os registros manuais serão reconciliados? Quais canais de comunicação permanecem se a identidade corporativa e a telefonia forem perdidas juntas? Quando o plano foi exercitado pela última vez com um porto, autoridade aduaneira, grande cliente e pequeno provedor de logística?

O quarto deve ser dados de consequência de terceiros. Deve mostrar não apenas o tempo de inatividade corporativo, mas movimentos de portão rejeitados, reservas perdidas, carga não localizada, exceções refrigeradas, atrasos de status do cliente, disputas de taxas e reclamações. Deve distinguir grandes clientes com suporte dedicado de clientes menores e operadores indiretos. Um programa de recuperação que restaura a receita enquanto deixa os clientes incapazes de obter status autoritativo não completou a recuperação do serviço.

O quinto deve ser evidência de encerramento. Cada remediação deve identificar o caminho de falha observado, proprietário, data de vencimento, teste, exceção e revisor independente. Controles que reduzem a probabilidade, como correção e segmentação, devem ser separados de controles que reduzem a consequência, como recuperação de identidade limpa e modos manuais de terminal. O seguro cibernético deve ser relatado como transferência financeira, não remediação técnica.

O sexto deve ser aprendizado sobre as pessoas. Quais decisões foram atrasadas porque a autoridade não estava clara? Quais respondedores detinham conhecimento único? Quais ferramentas improvisadas provaram ser úteis, e quais criaram risco inaceitável? Como a empresa preservará a competência de emergência sem assumir que centenas de pessoas podem novamente sustentar uma reconstrução 24 horas por dia, 7 dias por semana? A resiliência operacional inclui pessoal, mobilização de fornecedores, vistos, viagens, instalações, alimentação, descanso e sucessão, porque um design de recuperação limpo ainda tem que ser executado por humanos.

A regulamentação está alcançando a realidade operacional

A governança cibernética marítima tornou-se mais concreta desde 2017. Nos Estados Unidos, a regra de Segurança Cibernética no Sistema de Transporte Marítimo da Guarda Costeira entrou em vigor em 16 de julho de 2025. Ela exige que navios e instalações de bandeira dos EUA cobertos relatem incidentes e introduzam treinamento, um oficial de segurança cibernética designado, avaliação e um plano de segurança cibernética aprovado. A regra não torna impossível uma repetição do NotPetya. Cria propriedade nomeada e planejamento auditável onde a confiança na maturidade voluntária não era mais considerada suficiente.

As conclusões do GAO de 2025 são um lembrete de que a regulamentação também precisa de capacidade operacional. Os requisitos funcionam apenas se a autoridade puder entender incidentes, manter uma base de evidências confiável, coordenar localmente e testar se os planos abordam dependências reais. A resiliência cibernética portuária não é alcançada quando cada entidade submete separadamente um documento. Ela emerge quando os planos se conectam nas interfaces compartilhadas onde a carga, as informações de segurança e a autoridade pública cruzam as organizações.

Os reguladores também devem preservar a proporcionalidade. Uma transportadora global e um pequeno despachante aduaneiro não podem carregar cargas de controle idênticas. Grandes operadores podem razoavelmente ser esperados para produzir evidências de recuperação independentes, manter capacidade de sala limpa e apoiar exercícios conjuntos. Pequenas empresas precisam de segurança básica, planos de continuidade utilizáveis e acesso a canais comuns. Os órgãos públicos podem reduzir o custo coletivo definindo conjuntos mínimos de dados, terminologia comum de incidentes, políticas de taxas modelo e formatos de exercício.

A transparência também deve ser calibrada. Publicar uma arquitetura completa de rede ou identidade criaria novos riscos. Publicar apenas que "os sistemas foram restaurados" cria pouca responsabilidade. A divulgação útil inclui serviços e locais afetados, estados de recuperação com prazo, ações do cliente, se a segurança da carga ou a integridade dos dados está em questão, as categorias de causa raiz e falha de controle, e como a remediação será garantida independentemente. Detalhes específicos confidenciais podem permanecer com reguladores ou auditores.

A medida final é se a dependência se tornou governável

A resposta da Maersk em 2017 demonstrou uma formidável capacidade de recuperação. Os funcionários mantiveram o controle dos navios, improvisaram canais de serviço e reconstruíram um vasto patrimônio tecnológico sob condições extremas. A empresa absorveu um grande impacto financeiro e subsequentemente relatou investimento em resiliência cibernética e continuidade. Esses fatos merecem peso.

Eles não apagam o sinal central de responsabilidade. Uma relação de software localmente exigida adquiriu alcance prático suficiente para ajudar a interromper as operações de contêineres em todo o mundo. A infraestrutura de identidade replicada não fornecia necessariamente recuperabilidade independente. Clientes e parceiros de terminal perderam não apenas o acesso a um site, mas as informações necessárias para coordenar o comércio físico. Operadores menores e instituições públicas tiveram que gerenciar consequências fora da perda relatada pela Maersk.

A resiliência operacional é frequentemente descrita como a capacidade de se recuperar. A frase é muito passiva para infraestrutura da qual outros dependem. Um operador crítico deve decidir antecipadamente o que preservará, o que pode fazer com segurança sem seus sistemas principais, cujas necessidades serão priorizadas, como a verdade será comunicada e que evidências provarão a recuperação. Seus clientes e parceiros públicos devem decidir o que farão quando o próprio operador for a dependência indisponível.

O valor duradouro do caso Maersk não é, portanto, o espetáculo de 45.000 computadores sendo reinstalados. É a exposição de uma hierarquia oculta. A identidade teve que retornar antes que os aplicativos pudessem confiar uns nos outros. Os dados de carga tiveram que retornar antes que a capacidade física pudesse ser usada com segurança. O status autoritativo teve que retornar antes que os clientes pudessem tomar decisões racionais. A reconciliação teve que continuar depois que os sistemas estavam nominalmente disponíveis. Cada camada tinha um relógio diferente.

Um regime de responsabilidade maduro segue esses relógios. Não declara vitória no primeiro servidor restaurado, ou atribui culpa ao primeiro escritório infectado, ou pede a pequenos clientes que infiram continuidade a partir de uma estimativa financeira corporativa. Pergunta se a autoridade destrutiva foi limitada, se a confiança de recuperação existe fora do domínio de falha, se o serviço manual é seguro e mensurável, se as dependências públicas e de PME são visíveis, e se a remediação foi testada por alguém capaz de desafiá-la.

NotPetya foi um ato de agressão destrutiva. O dever da Maersk não era tornar tal agressão impossível. Era, e continua sendo, tornar a dependência da empresa na confiança digital governável: limitada antes da falha, sobrevivível durante a falha, reconstruível após a falha, e legível para as instituições e empresas que precisam continuar operando quando o transporte marítimo global perde sua memória.