Security & Conditional Access

Três camadas de proteção do login do RMM e da postura da frota. Podem ser combinadas.

Painel principal em /tenant-security.

Camada 1: IP allowlist do tenant

Restringe novos logins a faixas de IP confiáveis (VPN corporativa, escritório, faixas de home-office aprovadas).

• Enabled + lista de CIDR — sign-in de IPs fora é rejeitado com código LOGIN_IP_BLOCKED

• Sessões já ativas continuam funcionando — a barreira só cerca novo login, não paginação de quem já entrou (padrão do mercado enterprise)

• Guardrail: o RMM se recusa a habilitar o allowlist se seu próprio IP atual não estiver dentro dele. Zero chance de você se trancar fora do próprio tenant.

CIDR ou IP puro: 10.0.0.0/8, 200.20.5.10, 192.168.1.0/24.

Camada 2: Conditional Access por grupo

Cada permission group pode ter um bloco de Conditional Access com verificações mais finas. Ligado apenas quando marcado como enabled no grupo.

Regra	O que checa
IP allowlist	Fonte precisa estar em uma das faixas
IP blocklist	Fonte não pode estar em uma das faixas (aplicada antes do allowlist)
Country allowlist	Só países listados (ISO alpha-2 — BR, US, PT)
Country blocklist	Blacklist explícita
Min Trust Band	Trust Score do device precisa ser ≥ HEALTHY (ou TRUSTED)
Require MFA	Rejeita quem não tem MFA ativo — impossível entrar sem TOTP

O país vem do header CF-IPCountry (Cloudflare) ou X-Country-Code — se o reverse proxy da organização adiciona, o RMM usa. Se não vem header, as regras de país passam silenciosamente (não bloqueiam por falta de sinal).

Camada 3: Auto-quarentena de devices comprometidos

Devices que o Play Integrity marca como POTENTIALLY_COMPROMISED — ou que caem para banda RISK do Trust Score — são movidos automaticamente para uma policy AMAPI restritiva. Ao recuperar, a policy anterior é restaurada.

Configuração:

Campo	Descrição
Enabled	Master switch
Quarantine policy name	Nome da policy AMAPI que substitui a atual (o admin cria essa policy uma vez)
Trigger	RISK (banda) ou COMPROMISED_ONLY (só Play Integrity)
Auto-release	Se ligado, quando o device volta pra banda HEALTHY/TRUSTED a policy anterior é restaurada
Notify recipients	Emails para receber notificação de cada evento

Como funciona operacionalmente

1. A cada 10 min o Trust Score é recalculado

2. Se o device transiciona pra RISK / COMPROMISED e não estava quarantinado, a policy anterior é snapshotada no device doc e um comando de troca de policy é enfileirado no AMAPI queue

3. O log de auditoria registra DEVICE_QUARANTINED com motivo específico

4. Se o device recupera e auto-release está ligado, a policy anterior volta e o log grava DEVICE_QUARANTINE_RELEASED

Requer preparação

O admin precisa criar a policy de quarentena antes. Nome padrão sugerido: quarantine. Ela deve ser mais restritiva que a policy normal — por exemplo:

• Apenas apps essenciais (calendário, mensageria da empresa)

• Sem câmera, sem microfone, sem transferência de arquivos

• VPN sempre ligada

• Wipe do work profile permitido apenas para admin

Eventos de segurança

Todos os eventos gerados pelas 3 camadas caem em uma coleção -securityEvents e aparecem em /tenant-security na aba de histórico. Tipos:

• LOGIN_IP_BLOCKED

• CA_IP_NOT_ALLOWED, CA_COUNTRY_BLOCKED, CA_TRUST_TOO_LOW, CA_MFA_REQUIRED

• DEVICE_QUARANTINED, DEVICE_QUARANTINE_RELEASED

• DATA_CAP_WARN, DATA_CAP_EXCEEDED

• SIM_SWAP

Combinando com o resto do produto

• RBAC por grupo já tem accessSchedule (janelas de horário) — Conditional Access é a camada seguinte

• Alerts podem virar auto-remediation

• Compliance report consolida todos os eventos de segurança em um relatório LGPD / SOC 2 exportável