Kill Switch (device roubado)

Quando um dispositivo é declarado roubado, o RMM aciona uma cascata de camadas defensivas que juntas tornam o hardware antieconômico para reutilizar — sem prometer o que a plataforma Android não entrega.

Aberta em /stolen-devices (ledger) + botão Mark stolen no painel de detalhe de qualquer dispositivo em /sysadmin.

O que o Kill Switch faz

Ao marcar um device como roubado, em uma única ação:

1. Lock imediato — o device trava a tela via comando AMAPI LOCK

2. Lost Mode com mensagem de retorno + telefone de contato exibidos em tela cheia (via START_LOST_MODE)

3. Swap de policy — o device passa a rodar sob a policy stolen do tenant (kiosk restritivo, sem apps, sem câmera, sem USB debug, sem unknown sources)

4. Snapshot da policy anterior — se o device for recuperado, a policy original volta com um clique em "Recovered"

5. Log de auditoria — cada passo fica no -logs do tenant

6. SIM swap e location — continuam alertando (features já existentes)

O que o Kill Switch não faz — sendo honesto

• ❌ Não impede o device de ligar — nenhum MDM (Intune, Workspace ONE, Knox, DataDike) consegue "brickar" hardware Android

• ❌ Não impede factory reset local por recovery se o bootloader estiver destravado (raro em enterprise, mas possível)

• ❌ Não impede troca de placa-mãe — nesse ponto vira outro device

O objetivo é empilhar barreiras para que o custo de recuperar (tempo do ladrão + risco de FRP + peças) supere o valor de revenda.

Camadas empilhadas

O Kill Switch é a camada 5 da nossa estratégia anti-roubo. As outras 4 dependem de configuração prévia da organização — o RMM não pode ativá-las sozinho.

Camada	O que faz	Configuração
1. FRP (Factory Reset Protection)	Após reset, device exige o email admin da organização. Sem ele, para na tela de boot.	Setar frpAdminEmails: ["[e-mail]"] na policy stolen. O RMM aplica junto com o wipe usando a flag PRESERVE_RESET_PROTECTION_DATA.
2. Zero-Touch Enrollment (KME)	Devices comprados via KME re-baixam a policy da mesma conta pós-reset. Mesmo restaurado, o device volta para a policy stolen.	Comprar hardware via Google KME (canal Zero-Touch autorizado). Configurar em zero-touch.google.com.
3. Bootloader locked + Verified Boot	Impede reflash com firmware customizado.	Configuração de fábrica. Enterprise Android devices (Samsung, Zebra, Honeywell) vêm com bootloader travado.
4. Samsung Knox Guard / OEM APIs	Marca o IMEI como banido no servidor Samsung. Device conecta na rede pós-reset → lock permanente que nem wipe nem recovery removem.	Contrato Samsung Knox Guard + envio do IMEI para a API Samsung. Só devices Samsung enterprise.
5. Kill Switch DataDike (esta feature)	Cascade comportamental via AMAPI padrão — funciona em qualquer device Android gerenciado.	Um clique em "Mark stolen". A policy stolen deve existir uma vez.

Preparação — policy "stolen"

O admin cria uma vez uma policy AMAPI chamada stolen (ou o nome que preferir) em /policies com:

• Kiosk mode — app único (pode ser um app corporativo que só mostre "STOLEN — RETURN TO ACME")

• Câmera / microfone / USB debug / unknown sources = disabled

• maximumFailedPasswordsForWipe = 3 — 3 senhas erradas → wipe automático

• frpAdminEmails = email da equipe de TI da organização

• passwordRequirements.passwordQuality = COMPLEX — dificulta força bruta

Recuperação

Se o device for recuperado (funcionário achou, foi entregue):

1. Vá em Compliance & Governance → Stolen devices

2. Clique Recovered na linha do device

3. O RMM enfileira:

   • STOP_LOST_MODE — remove a tela vermelha

   • Restaura a policy que estava antes do roubo

4. Log de auditoria registra a recuperação com o nome do admin

Fluxo de operação recomendado

Quando o funcionário reporta roubo/perda:

1. T+0: Admin marca stolen no RMM (login → Sysadmin → device → Mark stolen)

2. T+segundos: Device recebe lock + lost mode + policy stolen

3. T+horas: Se o ladrão trocar SIM, alerta imediato (SIM swap detection)

4. T+dias: Localização continua sendo capturada em qualquer network

5. Recuperado: Admin marca "Recovered" → policy anterior restaurada

6. Não recuperado: Se após N dias o device sumiu de vez, admin pode fazer WIPE com PRESERVE_RESET_PROTECTION_DATA — pós-reset, o device só passa da tela de boot com o email admin FRP

Auditoria

Cada ação de mark/unmark fica registrada em:

• Audit log do tenant (-logs) — busca por DEVICE_MARKED_STOLEN ou DEVICE_UNMARKED_STOLEN

• History collection dedicada (-killSwitchHistory) — GET /api/v1/kill-switch/history/:deviceId retorna a série completa

• Toda mudança de policy vai no policy version history existente

Permissão

A ação de marcar/desmarcar exige a permissão devices.wipe (mesma classe de ação destrutiva). Grupos HELP_DESK e AUDITOR não conseguem por padrão — só ADMIN e OPERATOR.