> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/product-docs/product-guide/configuracoes/rmm/security.md).

# 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