Resposta a um Mac de desenvolvimento perdido: revogue o acesso com segurança

Um Mac de desenvolvimento desaparecido é primeiro um incidente de credenciais e só depois um incidente de hardware. O laptop pode voltar sem alterações. Também pode estar desbloqueado, offline ou nas mãos de outra pessoa, enquanto suas sessões do navegador, materiais SSH, cache da CLI da nuvem, repositórios locais e processos de agentes continuam com autoridade.

A pior resposta é esperar por certeza. Raramente você terá essa certeza. Comece por uma contenção reversível, preserve as evidências antes que mudanças ruidosas eliminem o contexto e depois troque as credenciais que poderiam permitir que um invasor ampliasse o acesso. Uma sequência calma é melhor do que trocar senhas às pressas em todos os serviços.

Trate o desaparecimento como acesso ativo até concluir a contenção

Parta do princípio de que o Mac desaparecido pode fazer solicitações autenticadas até que você interrompa os caminhos relevantes. Essa hipótese não acusa ninguém nem prevê uma invasão. Ela evita o erro comum de tratar um chamado de recuperação de dispositivo como se fosse apenas um problema de controle de acesso.

Anote imediatamente quatro horários: quando o Mac foi visto fisicamente pela última vez, quando se sabe que ele estava bloqueado pela última vez, quando seu usuário realizou pela última vez um trabalho sensível e quando a perda foi comunicada. Esses horários definem o período da análise. Não deixe a memória se deteriorar durante horas enquanto as pessoas procuram em salas de reunião.

Registre o que estava aberto no último momento conhecido como seguro. Os detalhes úteis são específicos: um terminal conectado a um host de produção, uma execução de agente editando código de implantação, uma aba do navegador em um console de nuvem, um encaminhamento de porta local, um repositório com credenciais no histórico ou um gerenciador de senhas desbloqueado para uma migração. «Trabalhando no backend» quase não informa nada a quem responde ao incidente.

Classifique a situação antes de distribuir as tarefas:

• A máquina estava bloqueada e foi perdida em um escritório controlado.
• A máquina estava desbloqueada ou não se sabe seu estado de bloqueio.
• A máquina desapareceu no transporte público, em um hotel ou em outro local sem controle.
• A máquina tinha acesso ativo à produção ou um processo de agente autônomo.
• A máquina pertencia a um administrador, engenheiro de releases ou responsável por uma conta organizacional.

Uma máquina bloqueada, com criptografia de disco e um armazenamento de segredos protegido por hardware, é uma situação melhor do que uma máquina desbloqueada. Isso não é motivo para pular a revogação. A proteção do dispositivo limita a extração do armazenamento. Ela não desfaz ações realizadas enquanto o dispositivo estava desbloqueado, não invalida sessões remotas nem informa se alguém usou a máquina antes de ela ser bloqueada.

Defina uma pessoa para tomar decisões sobre o incidente e outra para manter a linha do tempo. Em uma equipe pequena, pode ser a mesma pessoa. Quem registrar deve anotar a conta, a classe da credencial, a ação realizada, o horário, o operador e o local das evidências. Uma planilha serve durante a primeira hora. Uma conversa com emojis de reação não é um registro de incidente.

Não use o último endereço de rede do Mac desaparecido como prova de que ele está seguro. A localização de rede pode estar desatualizada, passar por proxy ou ser compartilhada. Não ligue, envie mensagens nem alerte uma possível pessoa que encontrou o equipamento usando contas que podem estar abertas na máquina. Use um canal separado.

Contenha o dispositivo sem destruir a investigação

O bloqueio e o apagamento remotos são ações sensatas, mas representam apenas um dos caminhos de contenção. Envie esses comandos pelo serviço de gerenciamento de dispositivos ou pelo serviço de localização do sistema operacional assim que os fatos relatados justificarem a ação. Registre o horário da solicitação e qualquer confirmação de entrega.

Um comando remoto espera que o dispositivo alcance o serviço. Se o Mac estiver offline, o comando pode ficar pendente. Se alguém conseguir mantê-lo offline, ele pode não ser executado por muito tempo. Por isso, a revogação de credenciais não pode esperar a confirmação do apagamento.

Peça ao administrador do dispositivo que colete os registros de gerenciamento disponíveis antes que a retenção seja alterada ou que eles desapareçam após um apagamento. Os campos úteis incluem o número de série ou ID de inventário, o usuário atribuído, o último horário de comunicação, a versão do sistema operacional, o último endereço IP informado, o status de custódia do FileVault, se sua organização o registra, e o estado da solicitação de bloqueio ou apagamento remoto. Colete o que suas ferramentas fornecerem. Não invente uma história limpa a partir de campos ausentes.

Se o Mac desaparecido usava uma Apple Account pessoal, o proprietário deve cuidar da localização do dispositivo com a presença de um responsável pelo incidente. A equipe não deve pedir que ele revele credenciais pessoais. A organização precisa da confirmação de que uma solicitação de bloqueio ou apagamento foi enviada, não de acesso a dados pessoais sem relação com o caso.

Preserve o contexto de trabalho local a partir de outros sistemas. Desative a VPN do dispositivo ou a postura do dispositivo no ambiente zero trust, se o provedor permitir um bloqueio específico para esse dispositivo. Revogue o certificado, se houver um. Remova o equipamento dos grupos de gerenciamento que concedem acesso à rede. Desative os privilégios de área de trabalho remota e de sincronização associados a esse endpoint.

Este também é o momento de suspender trabalhos não supervisionados ligados à máquina. Um trabalho local agendado não continuará depois que um laptop desligado, mas um agente remoto, ambiente de desenvolvimento na nuvem, executor de CI ou automação do navegador iniciado a partir dele pode continuar de forma independente. Identifique onde a execução ocorre antes de presumir que o Mac desaparecido a controla.

Evite a recomendação popular, mas fraca, de «simplesmente trocar a senha principal do usuário». As pessoas gostam dela porque é rápida e visível. Ela pode ajudar, especialmente se a senha tiver sido observada, mas costuma deixar ativos tokens de acesso pessoal, concessões OAuth, chaves SSH, sessões do navegador, tokens de atualização da CLI e credenciais específicas de serviços. A redefinição da senha é uma tarefa dentro de um plano de contenção mais amplo.

Revogue a autoridade ativa do agente antes que ele faça outra chamada

Um agente de programação com acesso a ações externas merece a mesma urgência que um terminal interativo. Ele ainda pode chamar uma API ou abrir uma conexão SSH se o processo estiver ativo, se a sessão continuar autorizada e se a máquina puder alcançar a rede. Interrompa a autoridade do agente no gateway e em cada serviço remoto que aceitou suas credenciais.

Primeiro, identifique cada execução que poderia ter vindo do Mac desaparecido. Registre sua identidade de processo, horários de início e término da sessão, credenciais atribuídas, sistemas de destino e última ação concluída. Se o host do agente tiver uma lista de sessões, revogue as sessões afetadas em vez de esperar que expirem. Se não for possível distinguir as execuções da máquina desaparecida, revogue todas as sessões desse usuário e crie novas depois.

O diário de sessões do Sallyport pode revogar imediatamente uma execução do agente, enquanto o diário de atividades registra as chamadas individuais feitas pelo aplicativo. Use os dois registros durante a resposta à perda do dispositivo: um informa qual execução interromper e o outro mostra o que ela tentou fazer antes da interrupção.

Não confunda o nome de um agente com uma identidade confiável. «Claude Code» em um rótulo de processo ou título de terminal não prova qual executável foi usado, quem o assinou ou se um invasor iniciou uma cópia do processo. Um registro de aprovação adequado deve identificar a autoridade que assinou o código do processo chamador. Registre essa identidade junto com a sessão e compare-a com a configuração de desenvolvimento conhecida como legítima.

Um gateway pode bloquear chamadas futuras, mas não pode retirar uma solicitação que já chegou a uma API. Se um agente criou um token de implantação, adicionou um usuário, alterou uma configuração de repositório ou enviou dados, investigue o serviço diretamente. O diário do agente fornece uma pista. O serviço de destino continua sendo a autoridade sobre o sucesso da ação.

Para agentes que se conectam por um servidor MCP, revogue ou desative o caminho de conexão na identidade da estação de trabalho afetada. Depois, examine a configuração do agente armazenada em repositórios de código, perfis do shell, diretórios de projetos e configurações gerenciadas. Não restaure essa configuração em um Mac substituto antes de remover tokens antigos, revisar os hooks de comandos e verificar se ela aponta para contas pessoais ou de produção.

A aprovação por chamada traz um benefício específico nesse cenário. Ela exige uma decisão humana no momento em que a credencial é usada, o que pode reduzir o dano depois que um usuário se afasta. Ela não substitui a revogação quando um laptop desaparece. Uma aprovação já concedida a uma sessão em execução pode continuar válida para aquele processo, e qualquer token externo usado antes pode ter sido copiado ou possuir seu próprio prazo de validade.

Troque as credenciais na ordem em que um invasor as usaria

A rotação de credenciais é um exercício ordenado para remover caminhos até a elevação de privilégios. Troque primeiro as credenciais que podem criar mais acesso e só depois aquelas que apenas leem um serviço de desenvolvimento de baixo risco. Se inverter a ordem, você pode passar uma hora redefinindo tokens menores enquanto um token de administrador da nuvem continua utilizável.

Comece pelo acesso à identidade e ao plano de controle: sessões do provedor de identidade, contas de proprietário da organização, funções de administrador da nuvem, acesso ao gerenciador de segredos, administração da organização no controle de código-fonte, contas de controle de implantação e administração do gerenciamento de dispositivos. Se uma só pessoa for responsável por tudo isso, há um problema de arquitetura a corrigir depois da contenção, mas resolva primeiro o incidente imediato.

Depois, troque os acessos que podem movimentar código ou executar cargas de trabalho: credenciais de CI, tokens de publicação em registros de pacotes, credenciais de assinatura, chaves de implantação, tokens de cargas de trabalho na nuvem, tokens de registros de contêineres e chaves SSH usadas por bastions ou hosts de produção. Por fim, trate rastreadores de tarefas, ferramentas de documentação, tokens de API de menor privilégio e senhas individuais de serviços.

Use esta planilha para cada credencial. Ela evita o erro comum de trocar um segredo e esquecer os sistemas que ainda confiam nele.

Não troque credenciais apenas sobrescrevendo um segredo e torcendo. Revogue o item antigo quando o provedor oferecer revogação separada. Crie o substituto com o menor escopo que mantenha o fluxo de trabalho desejado. Atualize os consumidores autorizados. Depois, confirme que a credencial antiga falha. Registre no incidente o identificador da credencial e o horário, nunca o valor do segredo.

Para um token bearer, a validação pode ser um endpoint autenticado inofensivo que deve rejeitar o token antigo e aceitar o substituto. Para SSH, remova a chave pública antiga de todos os caminhos autorizados, teste uma conexão com essa chave e espere uma recusa. Para uma concessão OAuth, revogue-a no provedor de identidade e verifique as sessões ativas ou a lista de tokens do aplicativo.

Um teste pela linha de comando pode deixar isso explícito. Substitua por um endpoint seguro que retorne a identidade autenticada e execute-o somente a partir de uma máquina limpa:

curl -i -H "Authorization: Bearer $OLD_TOKEN" https://api.example.internal/whoami

Após a revogação, o resultado esperado é uma falha de autenticação, como HTTP/1.1 401 Unauthorized ou a resposta documentada pelo provedor para token inválido. Uma resposta 200 significa que o token antigo ainda funciona. Não aceite «nós trocamos no gerenciador de segredos» como prova, porque o serviço remoto pode continuar aceitando a credencial antiga.

O SSH merece atenção especial. Desenvolvedores costumam lembrar de ~/.ssh/id_ed25519 e esquecer chaves de implantação, chaves protegidas por hardware, certificados SSH, agentes encaminhados, chaves registradas em provedores de controle de código-fonte, chaves armazenadas no CI e chaves públicas copiadas para bastions. Pesquise o lado do controle de acesso, não apenas o disco perdido. Todo local que aceita a chave pública precisa deixar de aceitá-la.

Verifique a atividade antes e depois do período do desaparecimento

A análise de auditoria deve responder se houve acesso, qual autoridade foi usada, o que mudou e se essa mudança criou uma nova rota de retorno. Ler os logs apenas em busca de comandos destrutivos óbvios deixa passar o trabalho de preparação que invasores costumam fazer primeiro.

Defina o período da análise a partir do último horário conhecido como seguro até o momento em que todas as credenciais de alta autoridade foram revogadas. Estenda-o para trás se o dispositivo tiver apresentado atividade inexplicada antes da perda. Estenda-o para a frente enquanto sessões ou credenciais antigas continuarem ativas. Mantenha os horários em um único fuso no registro do incidente.

Examine primeiro os eventos do provedor de identidade. Procure logins bem-sucedidos e malsucedidos, novos métodos de MFA, alterações de recuperação, consentimento OAuth, novas concessões de aplicativos, criação de sessões, registros incomuns de dispositivos e mudanças em funções administrativas. Um login malsucedido não é necessariamente inofensivo se aparecer entre atualizações bem-sucedidas ou uma nova sessão no mesmo contexto.

Depois, examine as trilhas de auditoria da nuvem e da infraestrutura em busca de ações que criam persistência: novas chaves de acesso, entidades de serviço, tokens de API, atribuições de funções, alterações de políticas, mudanças de firewall, criação de instâncias de computação, leituras de segredos, exportações de snapshots e alterações na configuração dos logs de auditoria. Um token com permissão apenas de leitura ainda pode expor configuração suficiente para localizar uma credencial mais poderosa.

Os registros do controle de código-fonte merecem o mesmo cuidado. Verifique adições de chaves de implantação, eventos de tokens de acesso pessoal, alterações de chaves SSH, edições de proteção de branches, webhooks, transferências de repositórios, instalações de aplicativos, publicação de releases, publicação de pacotes e alterações em arquivos de workflow. Um workflow de CI modificado pode conceder a uma execução futura mais acesso do que o Mac roubado jamais teve.

Para destinos SSH, analise logs de autenticação, logs de comandos se você os coletar, históricos do shell apenas como evidência de apoio, registros de comandos privilegiados e novas entradas em authorized_keys. Um login bem-sucedido com uma chave depois do horário informado para a perda exige explicação, mesmo que o endereço de origem pareça familiar. A saída de uma VPN corporativa pode fazer muitas pessoas parecerem vir do mesmo endereço.

O Sallyport mantém um log de auditoria criptografado, cego para gravação e encadeado por hashes, atrás de seus diários. Em um Mac limpo, preserve o material de auditoria disponível e execute a verificação de integridade offline antes de tratar as entradas como evidência:

sp audit verify

Uma verificação bem-sucedida deve informar que a cadeia foi validada. Em caso de falha, preserve os arquivos afetados, registre o erro e investigue o motivo. O comando verifica a cadeia sobre o texto cifrado e não precisa da chave do cofre. Ele confirma que a sequência registrada não foi alterada, mas não que toda ação remota foi concluída com sucesso.

Monte uma tabela curta de eventos em vez de colar logs brutos em um canal de conversa. Inclua horário, ator ou ID da credencial, origem, ação, destino, resultado, referência da evidência e encaminhamento. Classifique os eventos como esperados, suspeitos, comprovadamente prejudiciais ou não resolvidos. A coluna de não resolvidos é importante. As equipes costumam encerrar incidentes porque encontraram uma explicação inofensiva, enquanto várias alterações de contas continuam sem análise.

Procure persistência, não apenas roubo

Um invasor que consegue usar uma máquina de desenvolvimento pode preferir uma forma discreta de voltar em vez de alterar a produção imediatamente. Procure novas credenciais, automações alteradas e mudanças de controle que sobrevivam à troca de senha.

Inspecione cada plano de controle em busca de acessos criados recentemente: novos usuários, tokens de API, aplicativos OAuth, chaves públicas SSH, chaves de implantação, contas de serviço, tokens de acesso pessoal, métodos de recuperação, registros de dispositivos e funções administrativas delegadas. Compare com uma linha de base, se tiver uma. Se não tiver, peça ao responsável pelo serviço que valide manualmente cada entrada recente em vez de declarar a lista normal.

Pesquise alterações de código em busca de definições de CI modificadas, scripts de compilação, configurações de publicação de pacotes, URLs de dependências, endpoints de webhook e referências a segredos. Um workflow malicioso muitas vezes se esconde em um pull request pequeno ou em uma alteração de configuração que parece manutenção de rotina. Revise mudanças incorporadas e branches abertas durante o período analisado.

Examine também a movimentação de dados. Verifique downloads de artefatos, clones de repositórios quando o provedor os registra, exportações de sistemas de clientes, eventos de listagem e recuperação em armazenamento de objetos e documentos compartilhados recentemente. Talvez você não tenha visibilidade completa, especialmente no caso de um clone local feito antes do incidente. Declare essa limitação claramente no registro, em vez de presumir que nenhuma exportação ocorreu.

Não reaja de forma exagerada a toda anomalia. Uma implantação em horário incomum pode ter um chamado aprovado. Confirme-a com a pessoa ou conta de automação que a realizou, usando um canal de comunicação sem relação com o laptop desaparecido. Não envie uma solicitação de confirmação para uma conta cuja sessão possa estar exposta e aceite a resposta como prova.

Se encontrar persistência, amplie o escopo. Uma nova chave SSH em um bastion exige a inspeção de todos os hosts acessíveis por ele. Um novo aplicativo no controle de código-fonte exige a inspeção dos repositórios concedidos e dos workflows que usam seu token. Uma nova função na nuvem exige a inspeção de suas atribuições e atividades. Remova primeiro a persistência, preserve as evidências e depois troque todas as credenciais que ela poderia ter lido.

Restaure o acesso a partir de um endpoint limpo, não de uma imagem de backup

Um Mac substituto deve receber novas autoridades de forma deliberada. Restaurar um backup completo pode restaurar tokens antigos, chaves SSH, cookies do navegador, configuração do agente, hooks do shell e arquivos desconhecidos junto com o código-fonte. Essa conveniência custa caro durante uma investigação ativa.

Inscreva o novo Mac no gerenciamento normal de dispositivos, aplique as atualizações do sistema operacional, ative a criptografia de disco e o bloqueio de tela e instale ferramentas de desenvolvimento aprovadas de fontes confiáveis. Restaure o código-fonte a partir dos repositórios remotos depois de revisar o acesso às contas. Recrie as configurações locais a partir de configurações versionadas e revisadas sempre que possível.

Use uma conta ou um perfil de navegador separado para o trabalho administrativo durante a resposta. Mantenha o acesso diário de desenvolvimento mais restrito. Essa separação reduz o dano quando um ambiente de desenvolvimento finalmente executar uma extensão não confiável, um script de pacote ou uma instrução de agente.

Emita novas credenciais SSH para o dispositivo novo. Prefira um certificado SSH gerenciado pela organização ou uma chave distinta por máquina quando sua infraestrutura permitir. Uma chave privada compartilhada entre laptops transforma cada perda de dispositivo em uma migração ampla. Convenções de nomes de chaves públicas que identifiquem a máquina e o proprietário tornam a remoção futura mais rápida.

Crie novos tokens de API somente quando uma ferramenta realmente precisar deles. Dê ao sistema de compilação sua própria credencial em vez de copiar um token de desenvolvedor para o CI. Defina uma validade quando o serviço permitir. Documente quem é responsável pelo token e onde ele é usado. Um segredo que ninguém consegue atribuir será um problema no próximo incidente.

Restaure o acesso do agente por último. Confirme qual executável fará a conexão, qual autoridade de assinatura de código ele apresenta, quais canais pode usar e quais credenciais pode solicitar. Comece com credenciais de leitura ou de desenvolvimento quando possível. Observe as primeiras ações em vez de conceder uma aprovação ampla porque a equipe está atrasada.

Não coloque credenciais em prompts do agente, textos de configuração, comentários de issues ou comandos do shell que ficarão no histórico. Um gateway de ações deve manter o segredo e injetá-lo somente quando realizar a solicitação. Essa barreira impede que o agente receba credenciais em texto puro, mas não justifica autorizar as próprias ações de forma descuidada.

Encerre o incidente somente depois que os caminhos antigos falharem de forma comprovada

Você pode encerrar um incidente de Mac desaparecido quando o endpoint perdido não tiver mais um caminho utilizável até um acesso relevante, quando o período analisado tiver sido investigado e quando a configuração substituta não recriar a exposição antiga. Encontrar o Mac fisicamente não basta. Um dispositivo recuperado ainda pode exigir novo registro ou apagamento se a custódia tiver sido incerta.

Confira cada linha da planilha de credenciais. Toda credencial de alta autoridade precisa ter um resultado de revogação ou troca registrado. Toda sessão ativa do agente ligada ao dispositivo precisa ter um resultado de encerramento. Todo evento suspeito precisa de uma explicação, uma correção ou uma decisão documentada de aceitar o risco residual.

Faça testes negativos a partir de um ambiente controlado para os caminhos de acesso removidos. Confirme que o acesso à VPN desativada rejeita a identidade antiga do dispositivo. Confirme que as chaves SSH revogadas falham. Confirme que os tokens de API antigos falham. Confirme que as sessões antigas da organização não conseguem acessar páginas administrativas, caso o provedor ofereça inspeção de sessões. Esses testes detectam os casos em que uma credencial antiga continuou válida em uma região secundária, em um bastion esquecido ou em outro tenant de identidade.

Escreva uma nota curta pós-incidente enquanto os detalhes ainda estão frescos. Inclua a linha do tempo, o impacto, as credenciais afetadas, as evidências analisadas, as ações realizadas, as incertezas abertas e as mudanças que você fará. Evite culpas. Se a resposta dependeu de uma pessoa se lembrar de onde um token estava armazenado, o processo precisa de inventário e responsabilidade, não de uma bronca.

O teste prático é simples: se alguém ligasse o Mac desaparecido amanhã, que ações ele ainda poderia realizar? Continue trabalhando até que a resposta verdadeira seja «nenhuma que importe». Esse padrão é mais rigoroso do que um recibo de apagamento remoto e é ele que protege seus sistemas.