Qué hacer al perder un Mac de desarrollo: revoca el acceso de forma segura

Un Mac de desarrollo perdido es primero un incidente de credenciales y después un incidente de hardware. El portátil puede volver intacto. También puede estar desbloqueado, sin conexión o en manos de otra persona, mientras sus sesiones del navegador, claves SSH, caché de la CLI de la nube, repositorios locales y procesos de agentes siguen teniendo autoridad.

La peor respuesta es esperar a tener certeza. Rara vez la tendrás. Empieza por una contención reversible, conserva las pruebas antes de que los cambios ruidosos borren el contexto y rota las credenciales que podrían permitir a un intruso ampliar el acceso. Una secuencia tranquila es mejor que cambiar contraseñas sin orden en todos los servicios.

Trata la desaparición como un acceso activo hasta completar la contención

Supón que el Mac perdido puede hacer solicitudes autenticadas hasta que hayas detenido las rutas importantes. Esta suposición no acusa a nadie ni predice una intrusión. Evita el error habitual de tratar una solicitud de recuperación del dispositivo como si fuera solo un asunto logístico y no un evento de control de acceso.

Anota de inmediato cuatro momentos: cuándo se vio físicamente el Mac por última vez, cuándo se supo por última vez que estaba bloqueado, cuándo realizó su usuario una tarea sensible por última vez y cuándo se notificó la pérdida. Esos momentos definen el periodo de revisión. No dejes que los recuerdos se difuminen durante horas mientras la gente busca en las salas de reuniones.

Registra qué estaba abierto en el último momento seguro conocido. Los detalles útiles son concretos: un terminal conectado a un host de producción, una ejecución de agente que editaba código de despliegue, una pestaña del navegador en una consola de la nube, un redireccionamiento de puerto local, un repositorio con credenciales en su historial o un gestor de contraseñas desbloqueado para una migración. «Trabajaba en el backend» no dice casi nada a quien responde al incidente.

Clasifica la situación antes de repartir tareas:

• El equipo estaba bloqueado y se perdió en una oficina controlada.
• El equipo estaba desbloqueado o se desconoce su estado de bloqueo.
• El equipo desapareció en transporte público, un hotel u otro lugar sin control.
• El equipo tenía acceso activo a producción o un proceso de agente autónomo.
• El equipo pertenecía a un administrador, ingeniero de lanzamientos o propietario de una cuenta de organización.

Un equipo bloqueado, con cifrado de disco y un almacén de secretos protegido por hardware, es una situación mejor que un equipo desbloqueado. No es motivo para omitir la revocación. La protección del dispositivo limita la extracción desde el almacenamiento. No puede deshacer acciones realizadas mientras el equipo estaba desbloqueado, invalidar sesiones remotas ni decirte si alguien lo usó antes de que se bloqueara.

Asigna a una persona la responsabilidad de tomar decisiones y a otra la de mantener la línea temporal. En un equipo pequeño puede ser la misma persona. El registro debe incluir la cuenta, la clase de credencial, la acción realizada, la hora, el operador y la ubicación de las pruebas. Una hoja de cálculo sirve durante la primera hora. Un hilo de chat con emojis de reacción no es un registro de incidente.

No uses la última dirección de red del Mac perdido como prueba de que está a salvo. La ubicación de red puede estar obsoleta, pasar por un proxy o ser compartida. No llames, escribas ni envíes alertas a una persona que pudiera haberlo encontrado usando cuentas que quizá estén abiertas en el equipo. Utiliza un canal independiente.

Contén el dispositivo sin destruir la investigación

El bloqueo y el borrado remotos son medidas razonables, pero solo constituyen una parte de la contención. Envíalos mediante el servicio de gestión de dispositivos o el servicio de localización del sistema operativo en cuanto los hechos conocidos lo justifiquen. Registra la hora de la solicitud y cualquier confirmación de entrega.

Una orden remota espera a que el dispositivo se conecte al servicio. Si el Mac está sin conexión, la orden puede quedar pendiente. Si alguien consigue mantenerlo desconectado, quizá no se ejecute durante mucho tiempo. Por eso la revocación de credenciales no puede esperar a la confirmación del borrado.

Pide al administrador de dispositivos que recopile los registros de gestión disponibles antes de que cambie la retención o desaparezcan tras un borrado posterior. Los campos útiles incluyen el número de serie o identificador de inventario, el usuario asignado, la hora del último contacto, la versión del sistema operativo, la última IP registrada, el estado de custodia de FileVault si la organización lo registra y el estado de la solicitud de bloqueo o borrado remoto. Recopila lo que ofrezcan tus herramientas. No inventes una historia limpia a partir de campos ausentes.

Si el Mac perdido usaba una cuenta personal de Apple, su propietario debe gestionar la localización del dispositivo con la presencia de la persona que dirige el incidente. El equipo no debe pedirle sus credenciales personales. La organización necesita confirmar que se envió una solicitud de bloqueo o borrado, no acceder a datos personales ajenos.

Conserva el contexto de trabajo local desde otros sistemas. Desactiva la VPN del dispositivo o su postura de dispositivo de confianza cero si tu proveedor permite bloquear equipos concretos. Revoca su certificado si tiene uno. Retíralo de los grupos de gestión de endpoints que conceden acceso a la red. Desactiva los privilegios de escritorio remoto y sincronización asociados a ese endpoint.

Este es también el momento de suspender el trabajo desatendido vinculado al equipo. Una tarea local programada no puede ejecutarse si el portátil está apagado, pero un agente remoto, un entorno de desarrollo en la nube, un ejecutor de CI o una automatización del navegador iniciada desde él puede continuar de forma independiente. Identifica dónde se ejecuta cada proceso antes de asumir que el Mac perdido lo controla.

Evita la recomendación popular, pero débil, de «cambiar simplemente la contraseña principal del usuario». Parece atractiva porque es rápida y visible. Puede ayudar, sobre todo si alguien pudo observar la contraseña, pero a menudo deja activos los tokens de acceso personal, permisos OAuth, claves SSH, sesiones del navegador, tokens de renovación de la CLI y credenciales específicas de cada servicio. Restablecer la contraseña es una tarea dentro de un plan de contención más amplio.

Revoca la autoridad activa del agente antes de que haga otra llamada

Un agente de programación con acceso a acciones externas merece la misma urgencia que un terminal interactivo. Todavía puede llamar a una API o abrir una conexión SSH si su proceso sigue activo, su sesión continúa autorizada y el equipo puede acceder a la red. Detén la autoridad del agente en la puerta de enlace y en cada servicio remoto que haya aceptado sus credenciales.

Primero identifica cada ejecución que pudiera haberse originado en el Mac perdido. Captura su identidad de proceso, hora de inicio y finalización, credenciales asignadas, sistemas objetivo y última acción completada. Si el host del agente tiene una lista de sesiones, revoca las afectadas en lugar de esperar a que caduquen. Si no puedes distinguir las ejecuciones del equipo perdido, revoca todas las sesiones de ese usuario y crea otras nuevas después.

El diario de sesiones de Sallyport puede revocar de inmediato una ejecución del agente, mientras que su diario de actividad registra las llamadas individuales realizadas a través de la aplicación. Usa ambos registros durante la respuesta a la pérdida del dispositivo: uno indica qué ejecución debes cortar y el otro muestra qué intentó hacer antes de que la detuvieras.

No confundas el nombre de un agente con una identidad fiable. «Claude Code» en una etiqueta de proceso o en el título de un terminal no demuestra qué ejecutable se inició, quién lo firmó ni si un atacante lanzó un proceso copiado. Un registro de aprobación adecuado debe identificar la autoridad de firma de código del proceso que realiza la llamada. Registra esa identidad junto con la sesión y compárala con la configuración de desarrollo conocida como legítima.

Una puerta de enlace puede bloquear futuras llamadas, pero no retirar una solicitud que ya llegó a una API. Si un agente creó un token de despliegue, añadió un usuario, cambió la configuración de un repositorio o subió datos, investiga directamente ese servicio. El diario del agente te da una pista. El servicio de destino sigue siendo la autoridad para confirmar si la acción tuvo éxito.

En los agentes que se conectan mediante un servidor MCP, revoca o desactiva la ruta de conexión en la identidad de la estación de trabajo afectada. Después inspecciona la configuración del agente almacenada en repositorios de código, perfiles del shell, directorios de proyectos y configuración gestionada. No restaures esa configuración en un Mac de sustitución hasta eliminar los tokens antiguos, revisar los hooks de comandos y comprobar si apunta a cuentas personales o de producción.

La aprobación por llamada ofrece aquí una ventaja concreta. Obliga a una persona a decidir en el momento en que se usa la credencial, lo que puede reducir el daño después de que alguien se aleje del equipo. No sustituye a la revocación cuando desaparece un portátil. Una aprobación ya concedida a una sesión activa puede seguir siendo válida para ese proceso, y cualquier token externo usado antes puede haberse copiado o tener su propio periodo de validez.

Rota las credenciales en el orden en que las aprovecharía un atacante

Rotar credenciales consiste en eliminar, en el orden adecuado, las rutas hacia la ampliación de privilegios. Rota primero las credenciales que pueden crear más acceso y después las que solo permiten leer un servicio de desarrollo de bajo riesgo. Si inviertes el orden, puedes pasar una hora restableciendo tokens menores mientras un token de administrador de la nube sigue siendo utilizable.

Empieza por el acceso a la identidad y al plano de control: sesiones del proveedor de identidad, cuentas propietarias de la organización, roles de administrador de la nube, acceso al gestor de secretos, administración de la organización de control de código fuente, cuentas de control de despliegue y administración de dispositivos. Si una sola persona controla todo esto, es un problema arquitectónico que deberás corregir después de la contención, pero primero resuelve el incidente inmediato.

Después rota el acceso que puede mover código o ejecutar cargas de trabajo: credenciales de CI, tokens de publicación del registro de paquetes, credenciales de firma, claves de despliegue, tokens de cargas de trabajo en la nube, tokens del registro de contenedores y claves SSH usadas por bastiones o hosts de producción. Por último, gestiona los rastreadores de incidencias, herramientas de documentación, tokens API de menor privilegio y contraseñas individuales de servicios.

Usa esta tabla para cada credencial. Evita el fallo habitual de rotar un secreto y olvidar los sistemas que todavía confían en él.

No rotes sobrescribiendo un secreto y esperando. Revoca el elemento antiguo cuando el proveedor permita una revocación independiente. Crea el reemplazo con el alcance mínimo que mantenga activo el flujo previsto. Actualiza los consumidores autorizados. Después valida que la credencial antigua falla. Registra el identificador de la credencial y la hora, nunca el valor secreto, en el informe del incidente.

Para un token bearer, la validación puede consistir en un endpoint autenticado e inocuo que rechace el token antiguo y acepte el reemplazo. Para SSH, elimina la clave pública antigua de todas las rutas autorizadas y prueba una conexión con esa clave esperando que sea denegada. Para una autorización OAuth, revoca la autorización en el proveedor de identidad y comprueba las sesiones activas o la lista de tokens de la aplicación.

Una prueba desde la línea de comandos puede dejar esto claro. Sustituye el endpoint por uno seguro que devuelva la identidad autenticada y ejecútala solo desde un equipo limpio:

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

Después de la revocación, debe producirse un fallo de autenticación, como HTTP/1.1 401 Unauthorized o la respuesta de token no válido documentada por el proveedor. Una respuesta 200 significa que el token antiguo todavía funciona. No aceptes «lo cambiamos en el gestor de secretos» como prueba, porque el servicio remoto podría seguir aceptando la credencial antigua.

SSH merece una sospecha especial. Los desarrolladores suelen recordar ~/.ssh/id_ed25519 y olvidar las claves de despliegue, las claves protegidas por hardware, los certificados SSH, los agentes reenviados, las claves registradas en proveedores de control de código fuente, las claves almacenadas en CI y las claves públicas copiadas en bastiones. Busca en el lado del control de acceso, no solo en el disco perdido. Cada lugar que acepte la clave pública debe dejar de aceptarla.

Comprueba la actividad antes y después del periodo de pérdida

La revisión de auditoría debe responder si hubo acceso, qué autoridad se utilizó, qué cambió y si ese cambio creó una nueva ruta de entrada. Leer los registros buscando únicamente comandos destructivos evidentes deja fuera el trabajo de preparación que suelen hacer primero los atacantes.

Define el periodo de revisión desde el último momento seguro conocido hasta que se revocó cada credencial de alta autoridad. Amplíalo hacia atrás si el dispositivo mostró actividad inexplicable antes de la pérdida. Amplíalo hacia delante mientras sigan activos sesiones o credenciales antiguas. Usa una sola zona horaria en el registro del incidente.

Revisa primero los eventos del proveedor de identidad. Busca inicios de sesión correctos y fallidos, nuevos métodos MFA, cambios de recuperación, consentimientos OAuth, nuevas autorizaciones de aplicaciones, creación de sesiones, registros de dispositivos inusuales y cambios de roles administrativos. Un inicio fallido no es necesariamente inofensivo si aparece junto a renovaciones correctas o una sesión nueva del mismo contexto.

Después inspecciona los registros de auditoría de la nube y de la infraestructura para encontrar acciones que creen persistencia: nuevas claves de acceso, entidades de servicio, tokens API, asignaciones de roles, cambios de políticas, cambios de firewall, creación de instancias, lecturas de secretos, exportaciones de instantáneas y cambios en la configuración de los registros de auditoría. Un token con permiso de solo lectura todavía puede exponer suficiente configuración para localizar una credencial más potente.

Los registros del control de código fuente requieren el mismo cuidado. Comprueba adiciones de claves de despliegue, eventos de tokens de acceso personal, cambios de claves SSH, modificaciones de la protección de ramas, webhooks, transferencias de repositorios, instalaciones de aplicaciones, publicación de versiones, publicación de paquetes y cambios en archivos de workflows. Un workflow de CI modificado puede conceder a una ejecución futura más acceso del que tenía el Mac robado.

Para los destinos SSH, revisa los registros de autenticación, los registros de comandos si los recopilas, los historiales del shell solo como pruebas de apoyo, los registros de comandos privilegiados y las nuevas entradas en authorized_keys. Un inicio de sesión correcto con una clave después de la hora declarada de la pérdida requiere una explicación, aunque la dirección de origen parezca conocida. La salida de la VPN corporativa puede hacer que muchas personas aparezcan desde la misma dirección.

Sallyport conserva un registro de auditoría cifrado, encadenado mediante hashes y protegido contra escritura, detrás de sus diarios. En un Mac limpio, conserva el material de auditoría disponible y ejecuta la comprobación de integridad sin conexión antes de tratar sus entradas como pruebas:

sp audit verify

Una verificación correcta debe indicar que la cadena es válida. Si falla, conserva los archivos afectados, registra el error e investiga el motivo. El comando verifica la cadena sobre el texto cifrado y no necesita la clave del almacén. Comprueba que la secuencia registrada no se ha alterado, no que todas las acciones remotas hayan tenido éxito.

Crea una tabla breve de eventos en lugar de pegar registros sin procesar en un canal de chat. Incluye la hora, el actor o identificador de la credencial, el origen, la acción, el objetivo, el resultado, la referencia de la prueba y la decisión tomada. Marca los eventos como esperados, sospechosos, dañinos confirmados o no resueltos. La columna de no resueltos importa. Los equipos suelen cerrar incidentes porque encontraron una explicación inocua mientras varios cambios de cuentas siguen sin examinarse.

Busca persistencia, no solo robo

Un intruso que puede usar un equipo de desarrollo quizá prefiera una vía discreta para volver en lugar de hacer un cambio inmediato en producción. Busca credenciales nuevas, automatizaciones modificadas y cambios de control que sobrevivan a un restablecimiento de contraseña.

Inspecciona cada plano de control en busca de accesos creados recientemente: usuarios nuevos, tokens API, aplicaciones OAuth, claves públicas SSH, claves de despliegue, cuentas de servicio, tokens de acceso personal, métodos de recuperación, inscripciones de dispositivos y roles administrativos delegados. Compáralos con una referencia si la tienes. Si no la tienes, pide al propietario del servicio que valide manualmente cada entrada reciente en lugar de declarar normal toda la lista.

Busca en los cambios de código definiciones de CI modificadas, scripts de compilación, ajustes de publicación de paquetes, URL de dependencias, endpoints de webhooks y referencias a secretos. Un workflow malicioso suele ocultarse en una solicitud de cambios pequeña o en una modificación de configuración que parece mantenimiento rutinario. Revisa los cambios fusionados y las ramas abiertas creadas durante el periodo de revisión.

Inspecciona también el movimiento de datos. Comprueba descargas de artefactos, clonaciones de repositorios cuando el proveedor las registre, exportaciones de sistemas de clientes, eventos de listado y recuperación de almacenamiento de objetos y documentos compartidos recientemente. Quizá no tengas una visibilidad perfecta, especialmente en el caso de un clon local creado antes del incidente. Declara esa limitación en el registro en lugar de suponer que no hubo exportación.

No reacciones de forma desproporcionada ante cada anomalía. Un despliegue a una hora extraña puede tener una incidencia aprobada. Verifícalo con la persona o cuenta de automatización que lo realizó, usando un canal de comunicación ajeno al portátil perdido. No envíes una solicitud de confirmación a una cuenta cuya sesión pueda estar expuesta y aceptes su respuesta como prueba.

Si encuentras persistencia, amplía el alcance. Una nueva clave SSH en un bastión exige inspeccionar todos los hosts accesibles a través de él. Una nueva aplicación de control de código fuente exige revisar los repositorios concedidos y los workflows que usan su token. Un rol nuevo en la nube exige revisar sus asignaciones y actividad. Elimina primero la persistencia, conserva las pruebas y después rota todas las credenciales que pudiera haber leído.

Restaura el acceso desde un endpoint limpio, no desde una imagen de respaldo

Un Mac de sustitución debe recibir autoridad nueva de forma deliberada. Restaurar una copia completa puede recuperar tokens antiguos, claves SSH, cookies del navegador, configuración del agente, hooks del shell y archivos desconocidos junto con el código fuente. Durante una investigación activa, esa comodidad sale cara.

Inscribe el nuevo Mac en la gestión habitual de dispositivos, aplica las actualizaciones del sistema operativo, activa el cifrado de disco y el bloqueo de pantalla e instala herramientas de desarrollo aprobadas desde fuentes de confianza. Restaura el código fuente desde repositorios remotos después de revisar el acceso a las cuentas. Recrea los ajustes locales desde configuración versionada y revisada cuando sea posible.

Usa una cuenta o un perfil del navegador separado para las tareas administrativas durante la respuesta. Mantén más limitado el acceso de desarrollo diario. Esta separación reduce el daño cuando un entorno de desarrollo acaba ejecutando una extensión, un script de paquete o una instrucción de agente no fiable.

Vuelve a emitir las credenciales SSH para el dispositivo nuevo. Cuando la infraestructura lo permita, prefiere un certificado SSH gestionado por la organización o una clave distinta por máquina. Una clave privada compartida entre portátiles convierte cada pérdida de dispositivo en una migración amplia. Las convenciones de nombres de claves públicas que identifican la máquina y a su propietario facilitan futuras retiradas.

Crea tokens API nuevos solo cuando una herramienta los necesite de verdad. Entrega al sistema de compilación su propia credencial en lugar de copiar un token de desarrollador en CI. Establece una caducidad cuando el servicio lo permita. Documenta quién es responsable del token y dónde se utiliza. Un secreto que nadie puede atribuir se convertirá más adelante en un problema de incidentes.

Restaura el acceso del agente en último lugar. Confirma qué ejecutable se conectará, qué autoridad de firma de código presenta, qué canales puede utilizar y qué credenciales puede solicitar. Empieza con credenciales de solo lectura o de desarrollo cuando sea posible. Observa las primeras acciones en lugar de conceder una aprobación amplia porque el equipo va con retraso.

No pongas credenciales en prompts del agente, textos de configuración, comentarios de incidencias ni comandos del shell que vayan a quedar en el historial. Una puerta de enlace de acciones debe guardar el secreto e inyectarlo solo al realizar la solicitud. Ese límite evita que el agente reciba credenciales en texto plano, pero no justifica autorizar sin cuidado las acciones.

Cierra el incidente solo después de demostrar que las rutas antiguas fallan

Puedes cerrar un incidente por un Mac perdido cuando el endpoint ya no tiene una ruta utilizable hacia un acceso relevante, se ha investigado el periodo de revisión y la configuración de sustitución no reproduce la exposición anterior. Encontrar físicamente el Mac no basta. Un dispositivo recuperado puede necesitar volver a inscribirse o borrarse si su custodia fue incierta.

Comprueba cada línea de la tabla de credenciales. Toda credencial de alta autoridad debe tener un resultado registrado de revocación o rotación. Toda sesión activa del agente vinculada al dispositivo debe tener un resultado de terminación. Cada evento sospechoso debe contar con una explicación, una corrección o una decisión documentada de aceptar el riesgo residual.

Ejecuta pruebas negativas desde un entorno controlado para las rutas de acceso que eliminaste. Confirma que el acceso VPN desactivado rechaza la identidad del dispositivo antiguo. Confirma que las claves SSH revocadas fallan. Confirma que los tokens API antiguos fallan. Confirma que las sesiones antiguas de la organización no pueden acceder a páginas administrativas si el proveedor permite inspeccionar sesiones. Estas pruebas detectan los casos incómodos en los que una credencial antigua seguía siendo válida en una región secundaria, un bastión olvidado o un tenant de identidad separado.

Escribe una nota breve posterior al incidente mientras los detalles estén frescos. Incluye la línea temporal, el impacto, las credenciales afectadas, las pruebas revisadas, las acciones realizadas, las incertidumbres abiertas y los cambios que aplicarás. No busques culpables. Si la respuesta dependió de que una persona recordara dónde estaba un token, el proceso necesita inventario y responsables, no un sermón.

La prueba práctica es sencilla: si alguien encendiera mañana el Mac perdido, ¿qué acciones podría realizar todavía? Sigue trabajando hasta que la respuesta verdadera sea «ninguna que importe». Ese estándar es más estricto que un recibo de borrado remoto y es el que protege tus sistemas.