O acesso é organizado em dois níveis. No nível da organização, cada usuário tem um papel que define o alcance das suas ações, do proprietário da conta até o acesso somente leitura. Além desses papéis, existe um controle mais granular por recurso e ação, para casos em que os papéis padrão são amplos demais.
— Proprietário — controle total da organização, incluindo cobrança e equipe.
— Administrador — gestão operacional completa.
— Operador — execução das operações do dia a dia.
— Somente leitura — consulta, sem capacidade de alterar nada.
A verificação de e-mail é obrigatória no cadastro, e o acesso a funcionalidades também é limitado pelo plano contratado — um recurso indisponível no plano é bloqueado no servidor, e não apenas escondido na interface.
Isolamento de dados e auditoria
Cada organização é um tenant isolado, e o identificador da organização é aplicado nas consultas ao banco, de modo que dados de organizações diferentes não se misturam na mesma infraestrutura.
Toda ação relevante é registrada em um log de auditoria imutável, com a ação executada, o recurso afetado, os detalhes, o endereço IP e o agente de usuário. Quando o suporte da Zonix EM precisa acessar uma conta para diagnosticar um problema, esse acesso usa um token com prazo de expiração e também fica registrado na trilha de auditoria.
Segredos sensíveis, como as credenciais de integração com o Azure, são armazenados criptografados.
Informação necessária do responsável
Certificações auditadas por terceiros, como SOC 2 Tipo II e ISO 27001, ainda não foram concluídas e estão no roadmap. Prazos e escopo dessas certificações dependem de definição do responsável — não publique estimativas antes disso.
Roteiro de diagnóstico
A maioria dos problemas relatados cai em um número pequeno de causas. Este roteiro segue a ordem que costuma resolver mais rápido.
— Operações de dispositivo ou política falhando em uma conta nova: verifique se a enterprise do Android Enterprise está vinculada à organização. Sem esse vínculo, essas operações são recusadas.
— QR Code de enrollment que parou de funcionar: confira a validade do token, que é de 24 horas por padrão, e gere um novo se necessário.
— Enrollment em BYOD ou COPE recusado: o recurso de perfil de trabalho precisa estar disponível no plano contratado.
— Comando parado como pendente: o aparelho precisa estar acessível para receber a ação. Comandos têm prazo e podem expirar antes de o aparelho voltar a se comunicar.
— Estado do aparelho desatualizado no console: o estado chega por notificação, não por consulta ao vivo. Um aparelho sem rede mantém o último estado conhecido.
— Aparelho marcado como fora de conformidade: a aba de conformidade mostra a origem e o motivo de cada apontamento, incluindo os detectados pelo monitoramento comportamental além dos reportados pela AMAPI.
Quando abrir um chamado
Se o roteiro acima não resolveu, o suporte consegue diagnosticar mais rápido com três informações: o identificador do dispositivo, o horário aproximado em que o problema aconteceu e o que era esperado em vez do comportamento observado. Se o problema envolve um comando específico, informar qual comando e quando ele foi enviado ajuda a localizar o registro correspondente.