Os cofres de agentes do Migration Assistant precisam de um início a frio

Uma transferência de Mac não é uma simples mudança de endereço quando agentes autônomos podem acessar APIs e hosts SSH. Ela cria uma nova máquina, um novo limite de segurança de hardware, novos processos em execução e um novo momento em que alguém precisa decidir quais autoridades ainda merecem ser mantidas. Se os agentes recuperarem o acesso externo porque a área de trabalho parece familiar, a migração terá ignorado justamente a parte mais importante.

O Migration Assistant pode transferir documentos, aplicativos, contas de usuário e ajustes de outro Mac, PC ou backup. Isso é útil para voltar a trabalhar rapidamente. Não significa que todas as propriedades de segurança da máquina de origem devam sobreviver. A Apple documenta explicitamente que chaves do Secure Enclave e itens do chaveiro marcados como ThisDeviceOnly não migram para outro dispositivo.

A regra segura de operação é simples: transfira o que ajuda você a investigar e reconstruir, depois exija uma nova comprovação antes que qualquer agente possa usar uma credencial ou abrir uma sessão remota. Um cofre que se recusa a abrir depois de uma transferência pode estar fazendo exatamente aquilo para o qual foi criado.

Um Mac transferido é um novo endpoint

Um novo Mac pode ter o mesmo nome de usuário, o mesmo caminho do diretório pessoal, os mesmos aplicativos e o mesmo checkout do projeto. Nenhum desses fatos faz dele o mesmo endpoint de segurança. O processador, o Secure Enclave, o cadastro biométrico, o contexto da criptografia do disco, o estado do sistema instalado, a conexão de rede e o histórico dos processos locais mudaram.

As equipes costumam fazer a comparação errada. Elas perguntam se a máquina de destino tem os mesmos arquivos. Deveriam perguntar se o destino consegue provar que possui a mesma autoridade sem copiar uma autoridade que deveria permanecer local. Quando o cofre usa proteção vinculada ao dispositivo, esses objetivos são opostos.

A documentação de segurança da Apple traça essa linha com clareza. Uma chave privada do Secure Enclave é criada dentro do enclave, não pode importar uma chave privada preexistente e só pode ser usada pelo enclave que a criou. A Apple também informa que um item do chaveiro que usa kSecAttrAccessibleWhenUnlockedThisDeviceOnly não migra para um novo dispositivo.

Esse comportamento pode parecer inconveniente durante a troca apressada de um laptop. Ele impede que um contêiner de aplicativo copiado, um backup ou uma transferência de migração se transforme em um token portátil para acesso externo. Não contorne a falha exportando segredos para um arquivo de notas, uma variável de ambiente, o histórico do shell ou uma entrada genérica de gerenciador de senhas. Você substituiria um limite de hardware deliberado por um arquivo capaz de se espalhar muito mais do que o laptop antigo jamais poderia.

Defina a expectativa da troca antes de abrir o Migration Assistant:

• O Mac antigo continua sendo a fonte oficial do acesso existente até que o destino passe nos testes.
• O novo Mac começa com a execução dos agentes bloqueada ou desconectada das credenciais de produção.
• Um arquivo transferido é uma evidência para inspeção, não uma permissão para agir.
• Toda aprovação e todo vínculo de credencial precisam ter um resultado esperado explícito.

Isso é um novo cadastro controlado, mesmo quando a maior parte dos dados do aplicativo é copiada com sucesso. Chamá-lo de transferência não muda o trabalho de segurança.

Quatro tipos de estado falham de maneiras diferentes

Dados do aplicativo, aprovações, registros de auditoria e vínculos de credenciais costumam ficar armazenados próximos uns dos outros. Eles não devem ser tratados como uma coisa só. Cada um responde a uma pergunta diferente, e uma migração pode produzir um resultado diferente para cada um.

Dados do aplicativo são o estado local comum: preferências, definições de endpoints, rótulos, metadados não secretos e possivelmente blobs de cofres criptografados. Eles podem ser transferidos intactos. A presença deles informa apenas que a operação de cópia os encontrou.

Aprovações são decisões com duração limitada sobre um processo de agente específico. Elas respondem: «Este processo pode agir durante esta execução?» Uma aprovação que continua visível em um banco de dados local depois da transferência não deve autorizar um processo em um novo Mac. O processo tem uma nova cadeia de processos pai, um novo local do executável, um novo ambiente e possivelmente um estado de assinatura diferente.

Registros de auditoria são evidências do que aconteceu. Eles podem e devem sobreviver se a transferência preservar os arquivos criptografados relevantes. Devem manter suas propriedades de ordenação e integridade, não apenas continuar legíveis em uma tela de diário.

Vínculos de credenciais respondem se o hardware de destino pode usar a proteção criptográfica aplicada a um segredo. O blob criptografado pode ser copiado enquanto a capacidade local de descriptografá-lo não é. Essa é a distinção que confunde até engenheiros cuidadosos: a disponibilidade do texto cifrado não é a disponibilidade da credencial.

Registre esses quatro estados em uma planilha de migração antes da transferência. Não anote um resultado vago como «cofre migrado». Registre um resultado para cada estado:

O caso mais incômodo é o sucesso parcial. O aplicativo abre, os ajustes aparecem, o histórico antigo de auditoria está presente e o cofre não pode ser desbloqueado. Isso não é uma migração malsucedida. É uma migração que preservou evidências e configuração enquanto se recusou a transferir uma autoridade vinculada ao dispositivo. Aceite esse resultado e cadastre as credenciais novamente.

Congele o acesso dos agentes antes de copiar qualquer coisa

Não comece pelo Migration Assistant. Comece verificando que nenhum agente possa emitir uma solicitação enquanto não estiver claro qual Mac possui a autoridade.

Primeiro, interrompa as execuções ativas de agentes no Mac de origem. Se o agente for gerenciado por um multiplexador de terminal, uma extensão de editor, uma tarefa em segundo plano ou um iniciador local semelhante a CI, interrompa cada ponto de entrada. Feche as sessões de terminal que os iniciaram. Fechar uma janela não prova que um processo filho terminou.

Segundo, registre o estado da origem fora do aplicativo. Anote a data e a hora, o número de série ou a identificação interna do ativo do Mac de origem, a conta de usuário, os processos de agente que estavam ativos e os nomes dos sistemas remotos que os agentes podiam acessar. Não coloque segredos nesse registro. Você precisa de uma linha do tempo que explique as evidências posteriores, não de uma cópia do cofre.

Terceiro, desconecte o destino das redes importantes até o primeiro teste controlado. Isso pode significar remover um perfil de VPN de produção da sequência de configuração inicial, negar uma regra de firewall ou simplesmente manter o novo Mac fora da rede até concluir as verificações locais. Um laptop que não consegue alcançar uma API externa não pode demonstrar acidentalmente que uma autorização antiga foi aceita.

Quarto, decida quem tem autoridade para aceitar novas aprovações. Isso importa mais do que as equipes costumam admitir. Uma migração muitas vezes acontece enquanto outra pessoa configura a nova máquina, restaura backups ou conserta um laptop danificado. Quem clicar em um cartão de aprovação deve saber qual binário de agente está aprovando e por que ele precisa desse recurso.

Use um registro breve de transferência como este:

Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator

A data exibida é um exemplo de formato, não um identificador mágico. O importante é poder relacionar depois o final do log de auditoria da origem, a primeira aprovação no destino e a primeira ação bem-sucedida a um único registro de troca.

Arquivos do aplicativo podem ser movidos sem mover a confiança

Inspecione o estado do aplicativo em duas etapas: primeiro a integridade, depois a autoridade. Não misture as duas. A integridade informa o que restaurar. A autoridade informa o que deve ser rejeitado ou reconstruído.

Depois da transferência, abra o aplicativo enquanto o destino ainda não consegue alcançar os serviços de produção. Confirme se a configuração visível faz sentido: nomes de endpoints, rótulos, detalhes de roteamento não secretos e qualquer visualização esperada do diário local. Compare esses dados com o Mac de origem enquanto ele ainda existe. Se um endpoint estiver ausente, reconstrua-o deliberadamente. Se aparecer um endpoint que ninguém reconhece, remova-o e descubra de onde veio.

Depois, procure qualquer estado capaz de provocar uma ação automática. Exemplos incluem integrações de agentes iniciadas automaticamente, entradas em perfis do shell que iniciam um conector, tarefas do editor, launch agents, modelos de comandos salvos e preferências do aplicativo que reabrem sessões anteriores. Uma migração pode preservar ajustes de conveniência inofensivos para um editor de texto e perigosos para um agente que consegue chamar APIs de produção.

A Apple diz que o Migration Assistant transfere aplicativos, contas, documentos e ajustes. Essa categoria ampla explica por que essa revisão é necessária, em vez de presumir que apenas arquivos pessoais foram movidos.

Não use a presença de um diretório como condição de aprovação. Um projeto de segurança pode transferir deliberadamente um arquivo de cofre criptografado e deixar para trás o material usado para descriptografá-lo. Um cofre que parece vazio também pode estar correto se o aplicativo decidir não copiar o estado de segurança local. A única pergunta útil é se o resultado corresponde ao projeto esperado.

No Sallyport, o cofre é criptografado dentro do aplicativo e o controle do cofre é absoluto. Em Macs com o caminho de hardware compatível, o controle usa Secure Enclave e Touch ID, e bloqueado significa que toda ação é negada. Portanto, um payload de cofre copiado não prova que o destino pode usar a autoridade do Mac de origem.

Documente cada resultado observado com linguagem exata. Escreva «estado criptografado presente; controle do destino continua bloqueado» em vez de «migração falhou». Escreva «iniciador do agente desativado antes da primeira execução» em vez de «provavelmente interrompido». Esses detalhes impedem que uma pessoa responsável posteriormente trate um teste incompleto como uma troca bem-sucedida.

Aprovações antigas não devem autorizar um processo novo

A aprovação da sessão e o acesso às credenciais são controles separados. Um novo Mac precisa passar pelos dois, na ordem correta. O controle do cofre determina se alguma ação é possível. A autorização da sessão determina se aquela execução específica do agente pode fazer chamadas. Uma exigência por chamada determina se uma credencial específica requer outra decisão humana a cada uso.

Essa separação é fácil de confundir porque o usuário vê uma única ação ser bem-sucedida ou falhar. Não aceite essa ambiguidade durante a migração. Teste cada parte deliberadamente.

Inicie um novo processo de agente somente depois que o cofre do destino estiver no estado de bloqueio ou desbloqueio pretendido. Peça ao agente uma ação inofensiva usando uma credencial que não possa modificar sistemas de produção. O resultado esperado para a sessão é uma nova solicitação de aprovação. Inspecione a identidade do processo e a autoridade de assinatura exibidas pela interface de aprovação, depois aprove apenas a execução que você realmente iniciou.

Se um processo de agente realizar uma ação no destino sem um novo evento de autorização, pare. Não comemore achando que a transferência economizou tempo. Encontre o caminho que concedeu a autoridade. Pode ser um processo sobrevivente, um banco de dados de sessão restaurado, uma integração iniciada fora do mecanismo esperado ou um modelo de aprovação que não vincula o processo com firmeza suficiente ao seu tempo de vida.

A autorização de sessão do Sallyport vem ativada por padrão e mostra a primeira chamada de um novo processo de agente como um cartão de aprovação que destaca a autoridade de assinatura do processo. Uma aprovação dura apenas durante aquela execução, até que ela termine, portanto um processo iniciado novamente no destino é o lugar certo para exigir uma nova decisão.

Teste as credenciais por chamada separadamente. Marque uma credencial de teste inofensiva para exigir aprovação a cada uso. Faça duas chamadas a partir da mesma execução aprovada do agente. Você deve ver uma decisão para cada uso dessa credencial, enquanto a decisão da sessão não deve se repetir simplesmente porque o mesmo processo continua em execução. Assim, você sabe se testou a camada de sessão ou a camada por chamada, em vez de adivinhar com base em uma única janela de confirmação.

Uma tabela de teste adequada é pequena:

Não faça esse teste com uma implantação em produção, porque você não está testando apenas uma janela de confirmação. Está testando se o novo endpoint reconhece corretamente o tempo de vida do processo e a política de credenciais.

O histórico de auditoria precisa de verificação, não de uma inspeção visual

Uma visualização do diário que contém as entradas de ontem é útil, mas não prova que o registro transferido continua completo. Uma migração pode omitir um arquivo, copiar um snapshot antigo, interromper uma atualização ou deixar você olhando para um índice em cache. As evidências de auditoria precisam de um teste de integridade.

Preserve o Mac de origem antes de executar a primeira ação no destino. Registre o horário final da origem e quantas sessões e chamadas você espera encontrar perto da troca. Depois, compare a visualização histórica do destino. Você está procurando continuidade, não uma posição idêntica na tela nem a mesma ordem de exibição.

O Sallyport projeta seus diários de Sessões e Atividade a partir de um único log de auditoria criptografado, encadeado por hash e sem possibilidade de escrita. Seu verificador pode conferir a cadeia offline sobre o texto cifrado, sem uma chave do cofre. Esse projeto dá aos testes de migração um ponto concreto de aprovação ou falha, em vez de pedir que alguém examine uma lista de ações antigas.

Execute o verificador na origem antes da mudança, se possível, e execute-o novamente no destino antes de permitir qualquer ação de agente. Capture a saída padrão e o código de saída sem presumir um formato específico de mensagem:

sp audit verify \u003e audit-verify.txt 2\u003e\u00261
status=$?
printf 'sp audit verify exit=%s\\n' \"$status\"

Armazene audit-verify.txt com o registro da migração, não em uma conversa que desaparecerá. Um código de saída zero só é útil se você também identificar qual endpoint o produziu e quando. Se o verificador informar um erro ou retornar um status diferente de zero, interrompa o caminho da migração. Mantenha a origem intacta, copie a saída de diagnóstico e investigue a transferência, em vez de iniciar um novo diário que esconda a descontinuidade.

Há outra distinção importante: o histórico de auditoria transferido prova o que o endpoint antigo registrou; a atividade do destino prova o que o novo endpoint faz depois da troca. Não misture essas duas coisas mentalmente. A primeira chamada no destino deve ser fácil de localizar, estar ligada à nova autorização de sessão e ser claramente posterior à última chamada da origem.

Cadastre as credenciais novamente em vez de extraí-las

O atalho mais comum é exportar um token de API ou uma chave privada SSH do Mac antigo, colá-lo no novo e prometer removê-lo depois. Ele é popular porque funciona rapidamente. Está errado quando o projeto antigo manteve deliberadamente a credencial longe do agente e vinculou o uso local a um cofre protegido.

O novo cadastro muda a pergunta de «Como copio este segredo?» para «Quem deve conceder uma nova autoridade a este endpoint?». Essa é uma pergunta mais saudável. Pode ser necessário criar um novo token de API, registrar uma nova chave pública SSH ou obter uma nova credencial do responsável pelo sistema. Isso também cria um ponto de revogação limpo para o Mac antigo.

Para acesso HTTP, crie uma credencial de teste descartável e somente leitura quando o serviço remoto permitir. Dê a ela acesso a um único recurso inofensivo. Faça o agente recém-aprovado solicitar esse recurso. Revise o resultado retornado e a entrada correspondente no registro local de auditoria. Depois, revogue a credencial de teste ou deixe-a expirar de acordo com o processo normal do serviço.

Para SSH, use uma conta de teste dedicada ou um host de teste restrito. O primeiro comando deve ser apenas de observação, como exibir a identidade da conta remota e o diretório de trabalho atual. Não faça da primeira prova de sucesso um push para um repositório, a publicação de um pacote, um comando de banco de dados ou um acionador de implantação. Essas ações dificultam muito a depuração porque alteram justamente o sistema que você está tentando proteger.

Uma credencial que exige aprovação por chamada é especialmente útil nesta etapa. Ela força uma pessoa a observar exatamente quando o uso externo começa. Depois que o destino passar pelos testes de autorização, auditoria e ação inofensiva, cadastre as credenciais de produção novamente pelo fluxo normal de propriedade. Revogue a credencial antiga ou remova a autorização do endpoint antigo assim que o sistema remoto permitir distinguir essas ações.

Não confunda um arquivo de chave SSH com uma identidade SSH que deve pertencer ao novo Mac. Uma chave privada copiada pode autenticar, mas isso apenas prova que um servidor aceitou o mesmo material criptográfico. Não diz nada sobre a preservação do seu modelo de segurança local. Novo endpoint, novo cadastro de identidade, novo registro de auditoria.

A primeira ação real deve ser intencionalmente monótona

Sua primeira ação próxima da produção deve mostrar se toda a cadeia funciona sem criar trabalho de limpeza. Escolha uma operação somente leitura, limitada a um objeto de teste inerte e fácil de localizar tanto nos logs remotos quanto no diário de atividade local.

Boas opções incluem ler os metadados de um objeto de teste de uma API, listar um diretório SSH vazio e dedicado ou consultar a identidade autenticada atual de um serviço. Más opções incluem criar recursos na nuvem, alternar credenciais compartilhadas, publicar artefatos, alterar configurações de repositórios e executar comandos que usem expansão do shell em caminhos reais.

Execute a ação uma vez. Confirme os pontos a seguir na ordem em que aconteceram:

1. O cofre do destino estava no estado pretendido antes da solicitação.
2. O novo processo de agente recebeu uma nova autorização de sessão.
3. Uma credencial por chamada solicitou aprovação, se essa for sua configuração.
4. O sistema remoto registrou a ação inofensiva esperada.
5. O registro de atividade do destino corresponde à ação autorizada.

Se alguma observação estiver ausente, não repita a ação até entender o motivo. Repetir um teste opaco costuma criar uma pilha de registros quase idênticos, sem explicação. Um único sucesso bem documentado informa mais do que cinco tentativas apressadas.

Depois que essa ação for aprovada, ative o acesso externo uma credencial por vez. Evite ativar todos os endpoints salvos em uma tarde apenas porque a máquina de destino finalmente ficou utilizável. Um token de produção, uma identidade SSH de infraestrutura e um token de serviço pessoal não carregam o mesmo risco nem precisam da mesma pessoa para aprová-los. Ative-os na ordem que conceda a menor autoridade primeiro.

Mantenha o Mac antigo até fechar as evidências

Não apague nem troque o Mac de origem assim que o destino iniciar corretamente. Mantenha-o disponível, com os agentes desativados, até concluir o registro da transferência e conseguir explicar as evidências dos dois lados.

O registro de encerramento deve incluir o último estado de auditoria verificado da origem, o primeiro estado de auditoria verificado do destino, o resultado dos testes de novas aprovações, as credenciais cadastradas novamente, as credenciais revogadas e a pessoa que autorizou o acesso à produção. Isso não é burocracia gratuita. É como você responderá mais tarde se uma ação veio da máquina antiga, da nova ou de uma sobreposição não planejada.

Depois, revogue as sessões ativas da origem. Remova a origem das listas de permissões de acesso remoto onde elas existirem. Revogue os tokens específicos da origem e os cadastros SSH assim que a substituição funcionar. Por fim, verifique se o endpoint antigo não consegue recuperar o acesso simplesmente ao voltar a ficar online.

O teste que mais importa não é saber se o Migration Assistant transferiu o suficiente. É saber se o destino precisou conquistar novamente a autoridade externa. Se a resposta for sim, o novo Mac começa com um limite defensável. Se a resposta for não, mantenha os agentes desconectados até conseguir explicar exatamente o que atravessou a transferência e por quê.