Notebook roubado: plano de resposta nas primeiras 2 horas

As primeiras 2 horas definem o tamanho do estrago

Quando um notebook corporativo é roubado ou some, o relógio começa a correr contra a empresa. Não é o hardware que importa — um equipamento de R$ 6 mil é substituível e provavelmente está segurado. O problema real são as sessões abertas no navegador, o cache do Outlook com anos de e-mail, as pastas sincronizadas do OneDrive e do SharePoint, as credenciais salvas no gerenciador de senhas do Chrome e o token de VPN que ainda está válido. Um invasor com acesso físico e algumas horas sem interferência consegue transformar um furto comum em um incidente de vazamento de dados.

A janela de duas horas não é arbitrária. Ela reflete o tempo típico entre o furto e a primeira tentativa séria de acesso ao conteúdo do disco — normalmente após o aparelho ser repassado ao comprador ou ao receptador que sabe o que está fazendo. Ladrões oportunistas costumam apenas formatar e revender. O risco maior aparece quando o alvo era a informação, e nesse cenário cada minuto de sessão ativa é uma porta aberta.

Por isso, a resposta precisa ser um procedimento pronto, não uma improvisação. O colaborador que teve o notebook levado no metrô às 19h de uma sexta-feira não pode depender de encontrar alguém do TI disponível para agir. O plano precisa estar documentado, com telefone de plantão, ordem de execução e responsáveis definidos.

Passo 1 — Revogar sessões antes de qualquer outra coisa

O erro mais comum é começar pelo wipe remoto. Parece intuitivo, mas o wipe depende de o dispositivo estar ligado e conectado à internet — e um ladrão experiente desliga o aparelho ou remove a rede antes de qualquer coisa. Já a revogação de sessão acontece do lado do servidor e funciona independentemente do estado do notebook. É a única ação com efeito garantido e imediato.

A ordem correta nos primeiros minutos:

1. Resetar a senha do usuário no Microsoft Entra ID (Azure AD) ou no Active Directory local, marcando a exigência de troca no próximo login.
2. Revogar todas as sessões ativas — no portal do Entra, a opção "Revogar sessões" invalida os refresh tokens de todos os aplicativos. Sem isso, o Outlook e o Teams continuam autenticados por dias mesmo com a senha trocada.
3. Remover os métodos MFA registrados no dispositivo perdido, especialmente o Microsoft Authenticator, e recadastrar em outro aparelho.
4. Bloquear a conta de VPN e revogar o certificado de máquina, se houver.
5. Encerrar sessões de terceiros: Google Workspace, sistemas ERP, ferramentas SaaS, gerenciador de senhas corporativo, repositórios de código.

Vale medir esse tempo. Uma empresa com o procedimento maduro executa os cinco itens em menos de dez minutos. Sem procedimento, o mesmo conjunto de ações leva de duas a seis horas, porque alguém precisa descobrir quem tem acesso ao portal, onde está a senha de administrador e qual é a lista de sistemas que o usuário acessava.

Senha trocada não encerra sessão. O token de acesso já emitido continua válido até expirar. Revogar sessões é uma ação separada e obrigatória.

Passo 2 — Wipe remoto e o que ele realmente alcança

Com as sessões cortadas, o próximo passo é tentar apagar o dispositivo. No Microsoft Intune, a ação é disparada pelo console de administração e existe em duas variações que confundem muita gente. O Wipe restaura o Windows ao estado de fábrica e apaga todos os dados, incluindo a inscrição no gerenciamento. O Retire remove apenas os dados corporativos — perfis de e-mail, aplicativos gerenciados, políticas — e preserva os arquivos pessoais, o que faz sentido em cenários BYOD, mas raramente em furto de equipamento da empresa.

A limitação é sempre a mesma: o comando fica em fila até o dispositivo aparecer online. Se o aparelho nunca mais se conectar, o wipe nunca executa. Por isso ele deve ser tratado como uma camada complementar, e não como a defesa principal. Ainda assim, dispare o comando — uma parte relevante dos aparelhos furtados é ligada nas primeiras horas por curiosidade de quem os levou, e nesses casos o wipe pega.

Enquanto o comando fica pendente, registre no console a data e o horário do disparo. Essa evidência é útil tanto para a apuração interna quanto para demonstrar diligência em uma eventual fiscalização da ANPD. Também é o momento de acionar o bloqueio por hardware, quando disponível — alguns fabricantes oferecem serviços de bloqueio em nível de firmware que impedem o boot mesmo após formatação do disco.

Passo 3 — BitLocker: a diferença entre incidente e vazamento

Se o disco estava criptografado com BitLocker e o notebook foi levado desligado ou hibernado, o conteúdo é inacessível na prática. O invasor pode remover o SSD e conectá-lo em outra máquina — vai encontrar apenas dados cifrados. Essa distinção é jurídica, não apenas técnica: um dispositivo criptografado transforma um provável vazamento de dados pessoais em um simples furto de patrimônio.

Para que isso se sustente, três condições precisam estar documentadas antes do incidente:

• Criptografia ativa e verificada — o comando manage-bde -status deve retornar "Protection On" e 100% de conclusão. Discos em processo de criptografia não protegem nada.
• Chave de recuperação em custódia — armazenada no Entra ID ou no Active Directory, nunca em um arquivo de texto na área de trabalho do próprio notebook.
• Evidência com data anterior ao furto — relatório de compliance do Intune ou consulta ao Entra provando que aquele serial específico estava cifrado. Afirmar que "todos os notebooks têm BitLocker" não é evidência.

Um detalhe frequentemente ignorado: se o notebook foi furtado ligado e desbloqueado, o BitLocker não ajuda. O volume já está montado e descriptografado em memória. Daí a importância de políticas de bloqueio automático de tela em cinco minutos e de suspensão com exigência de PIN ao retomar. Configuração pequena, impacto enorme no pior cenário.

Passo 4 — Boletim de ocorrência e o registro do incidente

O boletim de ocorrência é obrigatório e deve ser registrado no mesmo dia, mesmo que a empresa não pretenda acionar o seguro. Ele estabelece a data oficial do evento, é exigido pela seguradora e sustenta a posição da empresa caso o equipamento reapareça envolvido em outro crime. Na maioria dos estados o registro pode ser feito pela delegacia eletrônica, sem deslocamento.

No boletim, inclua o número de série e o service tag do equipamento, o modelo, a data e o local aproximado da ocorrência e — importante — a menção de que o dispositivo continha dados corporativos protegidos por criptografia. Essa frase costuma ser omitida e depois faz falta na composição do dossiê do incidente.

Paralelamente, abra um registro interno de incidente com linha do tempo minuto a minuto: horário do furto informado pelo colaborador, horário da comunicação ao TI, horário de cada ação de contenção, evidências coletadas e decisões tomadas. Essa cronologia é o documento central de qualquer apuração posterior e precisa ser construída durante o incidente, não reconstruída de memória três semanas depois.

Passo 5 — Avaliação LGPD e comunicação

A LGPD não obriga a comunicar todo incidente. O artigo 48 exige comunicação à ANPD e aos titulares quando o incidente puder acarretar risco ou dano relevante. A avaliação é da empresa, mas precisa ser fundamentada e registrada — e é justamente aí que a documentação do BitLocker se torna decisiva.

O raciocínio prático fica assim:

• Disco criptografado, aparelho desligado, chave em custódia da empresa — risco baixo. Registre a avaliação com as evidências e, em geral, não há dever de comunicação. Guarde a análise por prazo indeterminado.
• Disco sem criptografia ou aparelho furtado desbloqueado — presuma acesso possível. Mapeie que dados pessoais estavam armazenados localmente: planilhas de RH, bases de clientes, contratos, prontuários.
• Dados sensíveis envolvidos (saúde, biometria, dados de crianças, origem racial, opinião política) — o patamar de risco sobe e a comunicação passa a ser a conduta esperada.

Se a comunicação for necessária, o prazo de referência adotado pela ANPD é de 3 dias úteis a partir do conhecimento do incidente, com informações sobre a natureza dos dados afetados, os titulares envolvidos, as medidas técnicas de proteção já aplicadas e as ações de mitigação em curso. Comunicar rápido com informação parcial e complementar depois é preferível a atrasar em busca de um relatório completo.

Comunique também internamente: o gestor da área, o jurídico, o encarregado de dados (DPO) e, se houver contrato exigindo, os clientes cujos dados possam estar no equipamento. Silêncio interno costuma custar mais caro que o incidente em si.

Como a Duk estrutura esse plano nos clientes

Na prática, quase nenhuma empresa executa bem essa sequência na primeira vez. O que separa uma resposta de dez minutos de uma de seis horas não é conhecimento técnico — é preparo: dispositivos inscritos no Intune antes do incidente, BitLocker aplicado por política e auditado mensalmente, chaves de recuperação em custódia, inventário de equipamentos com serial associado a usuário e um runbook de resposta com telefone de plantão que o colaborador tem salvo no celular.

Com mais de 18 anos de mercado, 550+ empresas atendidas e a condição de Microsoft Gold Partner, a Duk Informática & Cloud implanta esse conjunto como padrão nos contratos de suporte gerenciado: enrollment automático dos notebooks, política de criptografia com relatório de conformidade, bloqueio de tela por GPO ou Intune, revogação de sessão documentada em runbook e suporte com SLA para acionamento fora do horário comercial. Quando o incidente acontece, a equipe já sabe qual é o serial, quem é o usuário, se o disco estava cifrado e qual botão apertar primeiro.

Se sua empresa ainda não consegue responder com segurança à pergunta "o notebook do comercial está com BitLocker ativo agora?", esse é o ponto de partida. Um diagnóstico de conformidade do parque leva poucos dias e costuma revelar máquinas fora da política, chaves de recuperação sem custódia e usuários com sessões ativas em dispositivos que já saíram da empresa — todos problemas baratos de corrigir antes do incidente e caros depois dele.