# Sustituir un Mac de desarrollo implica rotar las credenciales de los agentes Sustituir un Mac de desarrollo es un cambio de acceso, no una transferencia de archivos. Los ajustes del editor, los repositorios, el historial de la shell y la caché de compilación local pueden trasladarse con herramientas de migración normales. Las credenciales que permiten a un agente de IA llamar a API de producción o abrir sesiones SSH necesitan un plan aparte. El error que veo con más frecuencia es tratar el Mac antiguo como una maleta. El desarrollador pone en marcha el equipo nuevo, ejecuta Migration Assistant, ve el escritorio de siempre y da por terminado el cambio. En realidad, años de permisos, tokens en caché, identidades SSH olvidadas y herramientas de agentes pueden haber cruzado un límite de confianza sin que nadie compruebe qué se ha conservado. ## Traslada los datos por separado de la autoridad Los archivos son copias. La autoridad es la capacidad continua de hacer algo fuera del Mac. Un token de API puede crear un despliegue después de que el portátil antiguo haya salido de tu casa. Una clave pública SSH puede seguir aceptándose en un servidor mucho después de que su parte privada se haya copiado, respaldado o borrado. Una sesión en la nube puede renovarse hasta que su emisor la revoque. Esta distinción cambia el plan de sustitución. Puedes copiar pronto el código fuente, las notas y la configuración que no contenga secretos porque después podrás compararlos. Conviene aplazar la autoridad hasta decidir si el Mac nuevo necesita la misma credencial, una credencial de reemplazo o ninguna. Las herramientas de agentes hacen que la diferencia sea aún más importante. Un desarrollador normal puede escribir un comando cuando un token caducado exige su atención. Un agente de programación autónomo puede hacer llamadas rápidamente, repetirlas y trabajar mientras miras hacia otro lado. El agente no necesita un secreto en texto plano para crear un riesgo. Solo necesita una ruta hacia una acción que todavía acepte la autoridad del equipo antiguo. Una migración sensata tiene dos registros: - Un registro de datos enumera repositorios, documentos, archivos de configuración, bases de datos locales, ubicaciones de copias de seguridad y material de licencias. - Un registro de autoridad enumera todos los sistemas remotos que aceptarán una acción debido a algo almacenado en el Mac antiguo, emitido para él o aprobado desde él. No mezcles estas listas. Un repositorio puede restaurarse dos veces sin causar problemas. Un token de acceso copiado dos veces crea dos lugares que proteger. Por eso el consejo habitual de migrar primero y limpiar después no funciona con las credenciales. Apple describe Migration Assistant como una herramienta para transferir documentos, aplicaciones, cuentas de usuario y ajustes. No elimina la información del Mac antiguo. Apple describe correctamente una migración normal, pero precisamente por eso no es un procedimiento para retirar credenciales. El equipo antiguo sigue siendo una copia activa hasta que le quites la autoridad de forma deliberada. ## El registro nuevo debe ser la opción predeterminada Registrar las credenciales de nuevo suele ser más seguro porque te obliga a decidir qué puede hacer el Mac de reemplazo. Vuelves a iniciar sesión, creas un token o una identidad SSH nuevos cuando el servicio lo permite, asignas al equipo nuevo el rol mínimo que necesita y eliminas el acceso del equipo anterior cuando el cambio funciona. Este enfoque parece más lento porque deja al descubierto deudas que la migración de cuentas oculta. Puedes encontrar un token de despliegue antiguo cuyo propietario ya no está en el equipo, un token de acceso personal con un alcance mucho mayor del necesario o una clave SSH copiada en varias máquinas porque nadie quería interrumpir una entrega. Esos hallazgos son útiles. La sustitución es uno de los pocos momentos en que puedes corregirlos sin interrumpir una configuración que funciona. Elige el registro nuevo cuando se cumpla cualquiera de estas condiciones: - El Mac antiguo se ha usado para más de una función, como trabajo personal, administración y soporte de producción. - No puedes nombrar todas las credenciales o cuentas remotas que puede utilizar el equipo antiguo. - El equipo antiguo fue reparado, compartido, se perdió durante un tiempo o estuvo fuera de tu control por cualquier otro motivo. - El emisor de credenciales puede crear un token, certificado, contraseña de aplicación o clave SSH específico para el dispositivo. - Estás cambiando de empresa, equipo, perfil de dispositivo gestionado o cuenta de Apple. El registro nuevo también facilita la vuelta atrás. Si el Mac nuevo falla durante el primer día de trabajo, el antiguo puede seguir conectado temporalmente mientras corriges el acceso. Esa superposición tiene un coste, así que establece un plazo corto y anótalo. Debe existir para demostrar que el equipo nuevo funciona, no para evitar decidir qué revocar. El argumento equivocado es que cambiar todas las credenciales crea más credenciales que gestionar. Un periodo corto con dos credenciales identificadas e inventariadas es manejable. Un periodo indefinido en el que nadie sabe si un elemento del gestor de contraseñas, un registro del llavero local, una copia de seguridad o una bóveda de agentes aún contiene la autoridad antigua no lo es. ## La migración cifrada tiene una función limitada Una migración cifrada puede estar justificada cuando volver a registrar las credenciales crearía un riesgo operativo inaceptable, cuando el emisor no permite sustituirlas correctamente o cuando un producto de bóveda cuenta con un proceso documentado de exportación e importación diseñado para este cambio exacto. No está justificada solo porque volver a escribir las credenciales resulte molesto. No confundas un disco cifrado por el sistema operativo con un paquete de credenciales cifrado y portátil. El cifrado completo del disco protege un dispositivo mientras el almacenamiento permanece dentro de su modelo de protección normal. Una exportación de migración se convierte en un objeto nuevo. Debes saber si tiene su propio cifrado, si el material para descifrarla se guarda por separado, cuánto tiempo existe el archivo y si puede restaurarse en un segundo equipo sin que nadie lo detecte. Usa esta prueba antes de permitir una exportación cifrada de la bóveda: 1. Nombra el formato de exportación y la versión de la aplicación que puede leerlo. 2. Identifica el límite de cifrado de la propia exportación, no solo el del disco que la contiene. 3. Decide dónde estará la exportación durante el cambio y establece un plazo para borrarla. 4. Confirma cómo demuestra la nueva bóveda que la importación se realizó correctamente sin exponer los valores secretos. 5. Decide qué registros de credenciales se retirarán o cambiarán después de la importación. Si alguna respuesta es imprecisa, usa el registro nuevo. Las migraciones de seguridad fallan en las partes imprecisas, no en el asistente que sigue el camino esperado. Hay otro punto incómodo: una exportación cifrada puede ser una copia de seguridad disfrazada. Un equipo puede importarla en el Mac nuevo, dar el trabajo por terminado y dejar el archivo en Time Machine, un servicio de archivos compartidos o una unidad externa. Esa exportación sigue siendo un contenedor de credenciales. Necesita la misma decisión de conservación que el Mac antiguo. La migración cifrada y el registro nuevo no son opciones opuestas. El enfoque práctico puede combinarse. Si es necesario, traslada las credenciales de servicios de bajo impacto mediante una ruta cifrada y documentada. Vuelve a emitir los tokens de producción, las claves SSH privilegiadas, el material de firma y todo lo que pueda llegar a los datos de clientes. Clasifica según las consecuencias, no según lo fácil que sea copiar un secreto. ## Crea el registro de autoridad antes de tocar el Mac nuevo Haz el inventario en el Mac antiguo mientras todavía funciona. No dependas de la memoria después de la transferencia, porque los ajustes migrados pueden hacer que el equipo nuevo parezca completo aunque falte un acceso importante. El registro debe contener referencias a los secretos, no sus valores. Un archivo sencillo es suficiente. Guárdalo en una ubicación de trabajo privada que no pase a formar parte de un repositorio público. ```text Service: production deployment API Purpose: release automation Credential form: bearer token Old-device location: agent vault record deploy-prod Issuer: deployment service administrator Replacement method: create new device token Cutover test: read release status only Old-access action: revoke old token Owner: platform team Status: pending Service: build host Purpose: remote build troubleshooting Credential form: SSH identity Old-device location: agent vault record build-ssh Issuer: build host authorized_keys Replacement method: create a new SSH key pair Cutover test: ssh hostname Old-access action: remove old public key Owner: build infrastructure Status: pending ``` El campo que la gente suele omitir es la acción para el acceso antiguo. Sin él, el inventario se convierte en una lista de compras para el Mac nuevo. También debe ser un plan para eliminar el acceso del equipo antiguo. Haz inventario de las credenciales en los lugares que los desarrolladores suelen olvidar: - Bóvedas de agentes y archivos de configuración de agentes. - Configuración de SSH, estado del agente SSH, identidades protegidas por hardware y listas remotas de claves autorizadas. - Sesiones del navegador para consolas en la nube y proveedores de identidad. - Registros de paquetes, herramientas de alojamiento de código, sistemas de despliegue y cuentas de administración de CI. - Archivos de entorno locales, archivos de inicio de la shell, gestores de contraseñas, archivos de copia de seguridad y unidades extraíbles cifradas. No pongas tokens de acceso reales, claves privadas, códigos de recuperación ni contraseñas en el registro. El registro resulta útil porque ofrece la información suficiente para sustituir y revocar el acceso sin convertirse en otro almacén de secretos de gran valor. Para cada elemento, anota la prueba menos destructiva. Una credencial de despliegue debe empezar leyendo el estado, no creando una entrega. Una identidad SSH debe comenzar con un comando restringido o con un host que no tenga autoridad sobre producción. Si la única prueba disponible puede modificar producción, el servicio tiene un problema de diseño de acceso que conviene corregir antes del siguiente cambio de hardware. ## Una bóveda nueva debe demostrar más que un inicio de sesión correcto Una bóveda nueva está lista cuando puedes justificar los registros esperados, desbloquearla con los controles del nuevo dispositivo, realizar mediante ella una acción acotada y consultar un registro independiente de esa acción. Ver una etiqueta conocida en una aplicación no basta. Una etiqueta copiada puede apuntar a un registro caducado, a una cuenta equivocada o a una credencial que nunca estuvo presente. Para una bóveda que guarda credenciales de agentes, usa una secuencia de prueba en un orden explícito: 1. Bloquea la bóveda e intenta realizar la acción inofensiva. La solicitud debe rechazarse mientras la bóveda esté bloqueada. 2. Desbloquéala mediante el control local normal y repite la misma acción inofensiva. 3. Inicia un proceso de agente nuevo y confirma que el comportamiento de autorización coincide con la configuración de sesión prevista. 4. Consulta el registro de actividad individual de la llamada y el registro de sesión de la ejecución del agente. 5. Verifica el registro de auditoría antes de retirar cualquier material de origen del Mac antiguo. Sallyport guarda sus secretos en una bóveda local cifrada y realiza acciones HTTP y SSH sin entregar credenciales en texto plano al agente. La puerta de la bóveda deniega las acciones mientras está bloqueada, lo que hace que la primera prueba sea significativa y no solo una formalidad. Usa el comando de auditoría como parte del registro de aceptación: ```text sp audit verify ``` Ejecútalo en el Mac nuevo después de la llamada de prueba y anota la fecha, el operador, el objetivo de la prueba y el resultado en el ticket de migración o en el registro de cambios. No se trata de generar papeleo. Se trata de conservar pruebas de que el equipo nuevo produjo un registro válido antes de destruir el dispositivo de origen. Un registro de auditoría encadenado por hashes puede detectar alteraciones del registro, pero no puede decirte que olvidaste registrar una credencial. El registro de autoridad cubre ese problema aparte. Haz que la prueba sea pequeña. Si una credencial no puede realizar de forma segura una solicitud de solo lectura, crea un punto de conexión de prueba específico o una cuenta restringida para la migración. La gente suele usar un cambio real en producción como prueba porque es concluyente. Lo es de la peor manera: convierte una prueba de migración en un incidente cuando apunta a la cuenta equivocada. ## Migration Assistant es útil, pero no es un protocolo de bóveda Migration Assistant puede ahorrar horas cuando necesitas las aplicaciones, cuentas de usuario, archivos y ajustes del Mac antiguo. También puede transferir todo un entorno de usuario desde una copia de Time Machine. Apple documenta ambos usos. Ese alcance es útil para restaurar una estación de trabajo, pero no ofrece una prueba precisa de qué archivos con credenciales, sesiones, cachés y registros de aplicaciones se han trasladado. Úsalo para el registro de datos. Considera que todos los elementos de autoridad están ausentes hasta que los verifiques bajo los controles previstos para el equipo nuevo. Esta forma de pensar evita dos resultados negativos: confiar en una transferencia accidental de estado sensible y perder tiempo buscando una credencial que, por diseño, no debía transferirse. Un fallo habitual tiene este aspecto. Un desarrollador migra su cuenta, abre un proyecto de agente y ve que el agente realiza una llamada HTTP correcta. Da por hecho que la nueva bóveda funciona. En realidad, la llamada usó una sesión en la nube derivada del navegador o un token que seguía presente en un archivo de configuración copiado. Una semana después, la sesión caduca. El desarrollador añade deprisa una credencial de reemplazo, deja la credencial copiada en su sitio y ahora el Mac antiguo, una copia de seguridad y la bóveda nueva tienen rutas hacia el mismo servicio. La solución no es prohibir Migration Assistant. La solución es aislar la prueba. Antes de probar el agente, cierra las sesiones de navegador no relacionadas, evita usar archivos de entorno copiados y utiliza un registro de la bóveda que hayas registrado o importado deliberadamente. Después, inspecciona el registro de actividad resultante. Debes saber qué ruta realizó la acción. Apple también indica que Migration Assistant no elimina la información del Mac antiguo. Organiza el cambio partiendo de ese hecho. Una pantalla que confirma la finalización de la migración significa que la copia terminó. No significa que el dispositivo anterior sea seguro para entregárselo a otra persona. ## Revoca el Mac antiguo antes de borrarlo La revocación tiene varias capas, y tratarlas como una sola acción crea una falsa sensación de seguridad. Finalizar una ejecución del agente detiene un proceso. Eliminar un dispositivo de un proveedor de identidad puede terminar algunas sesiones. Revocar un token de acceso impide usos futuros de la API. Eliminar una clave pública SSH detiene el inicio de sesión remoto mediante esa identidad. Cambiar una contraseña puede invalidar algunas sesiones y dejar otras activas, según el servicio. Escribe la acción de revocación para cada entrada del registro antes de empezar. No te conformes con una nota que diga «desactivar el dispositivo antiguo». Los sistemas remotos no comparten una definición universal del acceso de un dispositivo. Un orden práctico es: 1. Revoca las sesiones activas de los agentes y detén los procesos locales de los agentes en el Mac antiguo. 2. Cambia o revoca los tokens de API externos, las contraseñas de aplicaciones, las sesiones en la nube y las credenciales de cuentas de servicio que sigan siendo válidas desde el dispositivo antiguo. 3. Elimina las claves públicas SSH antiguas de todos los servidores, bastiones y cuentas de alojamiento de código que las acepten. 4. Elimina la confianza del dispositivo o las sesiones del navegador de los sistemas de identidad cuando el servicio ofrezca ese control. 5. Vuelve a revisar el registro y marca cada elemento con las pruebas de revocación. El registro de sesiones de Sallyport puede revocar de inmediato una ejecución de agente, mientras que su registro de actividad permite inspeccionar llamadas individuales. Úsalo para la capa del proceso activo y termina después el trabajo con las credenciales externas. Revocar una sesión local no revoca un token que un servicio externo todavía aceptaría. No borres primero el equipo, porque el Mac antiguo puede contener el único registro de una cuenta de servicio poco conocida, la asociación de un token de hardware o un alias de host que necesites eliminar. Déjalo apagado y bajo control físico mientras verificas el Mac nuevo. Si debes mantenerlo conectado durante las pruebas, no ejecutes agentes en él, no le añadas credenciales y establece un plazo de cambio explícito. En el momento en que confirmas la revocación, el Mac antiguo cambia de función. Ya no es una estación de trabajo de respaldo. Es una prueba que se conserva brevemente por si un servicio informa de un acceso inesperado y después pasa a estar listo para el borrado. ## El desecho es un control de seguridad independiente Borrar el Mac no sustituye la revocación, y revocar no sustituye borrar el Mac. Necesitas ambas cosas. La revocación remota limita lo que puede hacer una credencial copiada. El borrado elimina los datos locales, el estado de las aplicaciones, el código fuente descargado, el historial del navegador y el material de la bóveda que pueda seguir en el dispositivo. En un Mac con Apple silicon, o en un Mac Intel con el chip de seguridad T2 que ejecute una versión compatible de macOS, usa Ajustes del Sistema, General, Transferir o restablecer, y después «Borrar contenidos y ajustes». Apple indica que el Asistente de Borrado elimina las cuentas de usuario, los datos del usuario, las aplicaciones instaladas, los inicios de sesión en servicios de Apple, Buscar y el bloqueo de activación. También borra los volúmenes, no solo la cuenta del usuario actual. Si la opción no está disponible, no improvises borrando archivos ni haciendo un formateo rápido del disco. Apple dirige los equipos antiguos no compatibles al procedimiento de borrado correspondiente mediante Recuperación y Utilidad de Discos. El método cambia porque también cambian el hardware compatible y el modelo de seguridad. Cuando termine el borrado, detente en la pantalla de configuración inicial si vas a vender, entregar como parte de pago, regalar o reciclar el Mac. Apple recomienda específicamente no continuar con la configuración en esas situaciones. Completarla solo crea otra cuenta local en un ordenador que está a punto de salir de tu control. Si el Mac antiguo ha desaparecido o sospechas que ha sido manipulado, no restaures su cuenta de usuario en el equipo nuevo. Apple advierte que no se debe restaurar una copia de seguridad al restablecer el equipo por sospechas de manipulación, ya que la copia podría restaurar también el software no deseado. En ese caso, prioriza la revocación remota de credenciales y una configuración limpia del Mac de reemplazo. ## Haz que el procedimiento de sustitución sea lo bastante rutinario para repetirlo El mejor proceso para sustituir hardware no depende de recordar de memoria dónde están los secretos. Produce los mismos registros cada vez: un registro de datos, un registro de autoridad, pruebas acotadas en el Mac nuevo, pruebas de revocación para el antiguo y una confirmación del borrado. No pidas a cada desarrollador que se convierta en especialista en análisis forense de credenciales. Exige que los servicios emitan credenciales específicas para cada dispositivo cuando sea posible. Exige nombres y responsables para los accesos privilegiados. Ofrece a los ingenieros una ruta de prueba de solo lectura. Haz que la revocación sea evidente en cada servicio. Estos hábitos reducen el trabajo de sustituir un Mac y facilitan la contención de cualquier otro incidente. El Mac de reemplazo debería recibir solo la autoridad que pueda justificar durante su primer día. Si resulta incómodo, deja el dispositivo antiguo apagado durante una verificación más. Ese retraso cuesta menos que descubrir meses después que un portátil desechado todavía tenía una ruta hacia producción.