Form to Wipe
Form to Wipe (FTW) es un flujo de trabajo de borrado de dispositivos seguro y con aprobación que conecta Slack o GitHub con la Jamf Platform API. Un solicitante envía una solicitud de borrado; un aprobador separado la revisa y aprueba; el flujo de trabajo envía un comando de borrado MDM al dispositivo de destino. Cada paso se registra.
FTW está disponible en dos rutas de implementación. La arquitectura y el modelo de seguridad son idénticos en ambas — solo la interfaz y los requisitos de infraestructura difieren.
Cómo funciona
Solicitante envía → Aprobador revisa → Solicitante confirma → Comando de borrado enviado → Resultados registrados
- Un solicitante envía una solicitud de borrado a través de un comando de barra diagonal en Slack o un GitHub Issue, especificando el inquilino de destino, tipo de dispositivo, ID(s) de dispositivo y un motivo.
- El flujo de trabajo enruta la solicitud a un aprobador. El aprobador no puede ser la misma persona que el solicitante — esto se aplica a nivel de plataforma en ambas rutas.
- El aprobador revisa la solicitud y la aprueba o la rechaza.
- Si se aprueba, el solicitante recibe un mensaje de confirmación final antes de que se ejecute el comando de borrado.
- El flujo de trabajo llama a la Jamf Platform API para enviar un comando de borrado MDM a cada dispositivo de destino.
- Los resultados se publican nuevamente al solicitante y se escriben en un registro de auditoría.
Targeting compatible
FTW admite tres formas de especificar qué dispositivos borrar:
- Dispositivo único — un ID de registro de Jamf Pro
- Múltiples dispositivos — lista separada por comas de IDs de registro de Jamf Pro
- Grupo de dispositivos — nombre del grupo inteligente o estático, resuelto a IDs de dispositivos miembros a través de la Platform API en tiempo de ejecución
Tipos de dispositivos compatibles
| Tipo | Plataforma | Opciones de borrado |
|---|---|---|
| Computadora | macOS | PIN de Buscar mi PIN opcional |
| Dispositivo móvil | iOS / iPadOS | Preservar plan de datos, borrar Bloqueo de activación, devolver al servicio, desactivar configuración de proximidad |
Soporte para múltiples inquilinos
Ambas rutas de implementación admiten múltiples inquilinos de Jamf. Los inquilinos se configuran como listas emparejadas de nombres mostrados y UUIDs. El solicitante selecciona un inquilino de una lista desplegable al momento de envío — el inquilino seleccionado se lleva automáticamente a través de cada paso descendente.
JAMF_TENANT_NAMES = Production, Staging, Lab
JAMF_TENANT_IDS = aaaaaaaa-..., bbbbbbbb-..., cccccccc-...
Modelo de seguridad
FTW se construye sobre tres principios de seguridad:
Separación de funciones. El solicitante no puede aprobar su propia solicitud. Esto se aplica a nivel de plataforma — tanto las reglas de protección de rama de GitHub como la lógica de enrutamiento de modal de Slack previenen la autoaprobación antes de que la solicitud llegue a un aprobador.
Registro de auditoría. Cada acción — envío, aprobación, rechazo, confirmación, resultado de borrado, tiempo de espera — se registra con identidad del actor, marca de tiempo e inquilino. La ruta del flujo de trabajo de GitHub utiliza Pull Requests fusionadas como registros de auditoría inmutables; la ruta n8n escribe en un canal de auditoría de Slack.
Aislamiento de credenciales. Las credenciales de la Jamf Platform API se almacenan como secretos de entorno, nunca en código de flujo de trabajo o cuerpos de solicitud. La ruta n8n utiliza un token secreto compartido para verificar que las solicitudes entrantes de Slack sean genuinas antes de procesarlas.
Requisitos previos de la Jamf Platform API
Ambas rutas requieren un cliente OAuth2 de la Jamf Platform API con los siguientes privilegios:
| Privilegio | Por qué es necesario |
|---|---|
Read Computers |
Buscar nombre de computadora e ID de gestión por ID de registro |
Read Mobile Devices |
Buscar nombre de dispositivo móvil e ID de gestión por ID de registro |
Read Computer Groups |
Resolver pertenencia a grupo inteligente y estático para targeting con alcance de grupo |
Read Mobile Device Groups |
Resolver pertenencia a grupo de dispositivos móviles para targeting con alcance de grupo |
Send Computer Remote Erase Command |
Emitir comando de borrado a dispositivos macOS |
Send Mobile Device Remote Erase Command |
Emitir comando de borrado a dispositivos iOS/iPadOS |
Cree el cliente API en Jamf Pro en Settings → API roles and clients → API Clients → New.
Selección de ruta de implementación
| n8n | GitHub Workflow | |
|---|---|---|
| Interfaz | Modal de Slack | GitHub Issue + PR |
| UX de aprobación | DM de Slack | Revisión de PR |
| Origen del aprobador | Entra, Okta, o grupo de usuarios de Slack | Protección de rama + CODEOWNERS |
| Registro de auditoría | Canal de Slack | Historial de Git (permanente) |
| Infraestructura | Instancia n8n requerida | Ninguno (corredores alojados por GitHub) |
| Tiempo de espera en tiempo real | ✅ Configurable | ❌ Cierre manual |
| Costo | Licencia n8n | Gratis (público) / Minutos de Actions |
Elija n8n si su equipo ya ejecuta n8n, desea una experiencia de modal nativa de Slack, o necesita enrutamiento de aprobación basado en Okta o grupo de usuarios de Slack.
Elija GitHub Workflow si desea cero infraestructura, el registro de auditoría es una prioridad (cada borrado es un PR fusionado — historial de git permanente), y su equipo de TI es cómodo trabajando en GitHub.
¿Listo para implementar? Salte a la guía para su ruta elegida: