Form to Wipe
Form to Wipe (FTW) est un workflow sécurisé d'effacement d'appareil avec approbation préalable qui connecte Slack ou GitHub à la Jamf Platform API. Un demandeur soumet une demande d'effacement ; un approbateur distinct la révise et l'approuve ; le workflow envoie une commande MDM d'effacement au périphérique cible. Chaque étape est enregistrée.
FTW est disponible sur deux chemins de déploiement. L'architecture et le modèle de sécurité sont identiques sur les deux — seule l'interface et les exigences d'infrastructure diffèrent.
Comment ça marche
Demandeur soumet → Approbateur révise → Demandeur confirme → Commande d'effacement envoyée → Résultats enregistrés
- Un demandeur soumet une demande d'effacement via une commande slash Slack ou un problème GitHub, en spécifiant le tenant cible, le type d'appareil, les ID(s) d'appareil et une raison.
- Le workflow achemine la demande à un approbateur. L'approbateur ne peut pas être la même personne que le demandeur — ceci est imposé au niveau de la plateforme sur les deux chemins.
- L'approbateur révise la demande et l'approuve ou la refuse.
- Si approuvée, le demandeur reçoit un message de confirmation final avant que la commande d'effacement ne soit exécutée.
- Le workflow appelle la Jamf Platform API pour envoyer une commande MDM d'effacement à chaque appareil cible.
- Les résultats sont affichés au demandeur et écrits dans un journal d'audit.
Ciblage pris en charge
FTW prend en charge trois façons de spécifier les appareils à effacer :
- Appareil unique — un ID d'enregistrement Jamf Pro
- Appareils multiples — liste séparée par des virgules d'ID d'enregistrement Jamf Pro
- Groupe d'appareils — nom d'un groupe intelligent ou statique, résolu en ID d'appareils membres via la Platform API lors de l'exécution
Types d'appareils pris en charge
| Type | Plateforme | Options d'effacement |
|---|---|---|
| Computer | macOS | Code PIN Find My optionnel |
| Mobile Device | iOS / iPadOS | Préserver le plan de données, effacer la verrouillage d'activation, retourner au service, interdire la configuration de proximité |
Support multi-tenant
Les deux chemins de déploiement prennent en charge plusieurs tenants Jamf. Les tenants sont configurés comme des listes appairées de noms d'affichage et d'UUID. Le demandeur sélectionne un tenant dans une liste déroulante au moment de la soumission — le tenant sélectionné est conservé tout au long de chaque étape aval automatiquement.
JAMF_TENANT_NAMES = Production, Staging, Lab
JAMF_TENANT_IDS = aaaaaaaa-..., bbbbbbbb-..., cccccccc-...
Modèle de sécurité
FTW est construit autour de trois principes de sécurité :
Séparation des fonctions. Le demandeur ne peut pas approuver sa propre demande. Ceci est imposé au niveau de la plateforme — les règles de protection des branches GitHub et la logique de routage des modales Slack empêchent tous deux l'auto-approbation avant que la demande ne parvienne à un approbateur.
Piste d'audit. Chaque action — soumission, approbation, refus, confirmation, résultat d'effacement, expiration du délai — est enregistrée avec l'identité de l'acteur, l'horodatage et le tenant. Le chemin GitHub Workflow utilise les Pull Requests fusionnées comme dossiers d'audit immuables ; le chemin n8n écrit dans un canal d'audit Slack.
Isolation des accréditations. Les accréditations API Jamf Platform sont stockées en tant que secrets d'environnement, jamais dans le code de workflow ou les corps de demandes. Le chemin n8n utilise un jeton secret partagé pour vérifier que les demandes Slack entrantes sont authentiques avant de les traiter.
Prérequis de l'API Jamf Platform
Les deux chemins nécessitent un client OAuth2 de l'API Jamf Platform avec les privilèges suivants :
| Privilège | Pourquoi il est nécessaire |
|---|---|
Read Computers |
Rechercher le nom de l'ordinateur et l'ID de gestion par ID d'enregistrement |
Read Mobile Devices |
Rechercher le nom de l'appareil mobile et l'ID de gestion par ID d'enregistrement |
Read Computer Groups |
Résoudre l'appartenance au groupe intelligent et statique pour le ciblage à l'aide du groupe |
Read Mobile Device Groups |
Résoudre l'appartenance au groupe d'appareils mobiles pour le ciblage à l'aide du groupe |
Send Computer Remote Erase Command |
Émettre une commande d'effacement pour les appareils macOS |
Send Mobile Device Remote Erase Command |
Émettre une commande d'effacement pour les appareils iOS/iPadOS |
Créez le client API dans Jamf Pro sous Settings → API roles and clients → API Clients → New.
Choix d'un chemin de déploiement
| n8n | GitHub Workflow | |
|---|---|---|
| Interface | Modal Slack | GitHub Issue + PR |
| Expérience utilisateur d'approbation | Slack DM | Révision PR |
| Source d'approbateur | Entra, Okta, ou groupe d'utilisateurs Slack | Protection de branche + CODEOWNERS |
| Journal d'audit | Canal Slack | Historique Git (permanent) |
| Infrastructure | Instance n8n requise | Aucune (GitHub-hosted runners) |
| Expiration en temps réel | ✅ Configurable | ❌ Fermeture manuelle |
| Coût | Licence n8n | Gratuit (public) / Actions minutes |
Choisir n8n si votre équipe exécute déjà n8n, vous souhaitez une expérience modale native Slack, ou vous avez besoin d'un routage d'approbation basé sur Okta ou groupe d'utilisateurs Slack.
Choisir GitHub Workflow si vous souhaitez zéro infrastructure, la piste d'audit est une priorité (chaque effacement est une PR fusionnée — historique git permanent), et votre équipe IT est à l'aise de travailler dans GitHub.
Prêt à déployer ? Passez au guide pour votre chemin choisi :