Jamf Concepts
指南

指南

Form to Wipe

Form to Wipe

Form to Wipe (FTW)是一个安全的、批准门控的设备擦除工作流,连接Slack或GitHub到Jamf Platform API。请求者提交擦除请求;独立的批准者审查并批准该请求;工作流向目标设备发送MDM擦除命令。每个步骤都被记录。

FTW提供两种部署路径。跨两种部署路径的架构和安全模型相同——只有接口和基础设施要求不同。

工作原理

请求者提交 → 批准者审查 → 请求者确认 → 发送擦除命令 → 记录结果
  1. 请求者通过Slack斜杠命令或GitHub Issue提交擦除请求,指定目标租户、设备类型、设备ID和理由。
  2. 工作流将请求路由到批准者。批准者不能是请求者——这在两种部署路径的平台级别都会被强制执行。
  3. 批准者审查该请求并批准或拒绝它。
  4. 如果获得批准,请求者会收到最终确认提示,然后擦除命令才会执行。
  5. 工作流调用Jamf Platform API向每个目标设备发送MDM擦除命令。
  6. 结果会发布回请求者并写入审计日志。

支持的目标

FTW支持三种方式指定要擦除的设备:

  • 单个设备 — 一个Jamf Pro记录ID
  • 多个设备 — 以逗号分隔的Jamf Pro记录ID列表
  • 设备组 — 智能组或静态组名称,通过Platform API在运行时解析为成员设备ID

支持的设备类型

类型 平台 擦除选项
Computer macOS 可选的"查找我的"PIN
Mobile Device iOS / iPadOS 保留数据计划、清除激活锁、返回服务状态、禁用邻近设置

多租户支持

两种部署路径都支持多个Jamf租户。租户配置为成对的显示名称和UUID列表。请求者在提交时从下拉菜单中选择租户——所选租户会自动贯穿每个下游步骤。

JAMF_TENANT_NAMES = Production, Staging, Lab
JAMF_TENANT_IDS   = aaaaaaaa-..., bbbbbbbb-..., cccccccc-...

安全模型

FTW基于三个安全原则构建:

职责分离。 请求者无法批准自己的请求。这在平台级别被强制执行——GitHub分支保护规则和Slack模态路由逻辑都防止自我批准。

审计跟踪。 每项操作——提交、批准、拒绝、确认、擦除结果、超时——都以参与者身份、时间戳和租户进行记录。GitHub Workflow路径使用合并的Pull Request作为不可变的审计记录;n8n路径写入Slack审计频道。

凭证隔离。 Jamf Platform API凭证存储为环境秘密,不在工作流代码或请求正文中。n8n路径使用共享的秘密令牌来验证传入的Slack请求是否真实,然后再处理它们。

Jamf Platform API 先决条件

两种部署路径都需要具有以下权限的Jamf Platform API OAuth2客户端:

权限 需要的原因
Read Computers 按记录ID查找计算机名称和管理ID
Read Mobile Devices 按记录ID查找移动设备名称和管理ID
Read Computer Groups 解析智能组和静态组成员以进行群组范围目标定位
Read Mobile Device Groups 解析移动设备组成员以进行群组范围目标定位
Send Computer Remote Erase Command 向macOS设备发出擦除命令
Send Mobile Device Remote Erase Command 向iOS/iPadOS设备发出擦除命令

在Jamf Pro中的 Settings → API roles and clients → API Clients → New 下创建API客户端。

选择部署路径

n8n GitHub Workflow
接口 Slack模态 GitHub Issue + PR
批准UX Slack DM PR审查
批准者来源 Entra、Okta或Slack用户组 分支保护 + CODEOWNERS
审计日志 Slack频道 Git历史记录(永久)
基础设施 需要n8n实例 无(GitHub托管运行程序)
实时超时 ✅ 可配置 ❌ 手动关闭
成本 n8n许可证 免费(公开)/ Actions分钟数

选择n8n如果 您的团队已经运行n8n、想要Slack原生模态体验,或需要基于Okta或Slack用户组的批准路由。

选择GitHub Workflow如果 您想要零基础设施、优先考虑审计跟踪(每个wipe都是一个合并的PR——永久git历史记录),并且您的IT团队熟悉在GitHub中工作。


准备好部署了吗?跳到您选择的路径指南: