El acceso se organiza en dos niveles. Dentro de la organización, cada usuario tiene un rol que define el alcance de sus acciones, desde el propietario de la cuenta hasta el acceso de solo lectura. Junto a esos roles existe un control más granular por recurso y acción, para casos en que los roles por defecto resultan demasiado amplios.
— Propietario — control total de la organización, incluidas facturación y equipo.
— Administrador — gestión operativa completa.
— Operador — operaciones del día a día.
— Solo lectura — consulta, sin capacidad de modificar nada.
La verificación de correo es obligatoria en el registro, y el acceso a las funcionalidades también está acotado por el plan contratado — una funcionalidad no incluida en el plan se bloquea en el servidor, no solo se oculta en la interfaz.
Aislamiento de datos y auditoría
Cada organización es un tenant aislado, y el identificador de la organización se aplica en las consultas a la base de datos, de modo que los datos de organizaciones distintas no se mezclan en la misma infraestructura.
Toda acción relevante se registra en un log de auditoría inmutable, con la acción ejecutada, el recurso afectado, los detalles, la dirección IP y el agente de usuario. Cuando el soporte de Zonix EM necesita acceder a una cuenta para diagnosticar un problema, ese acceso usa un token con caducidad y también queda registrado en la auditoría.
Los secretos sensibles, como las credenciales de integración con Azure, se almacenan cifrados.
Información necesaria del responsable
Las certificaciones auditadas por terceros, como SOC 2 Tipo II e ISO 27001, aún no se han completado y están en el roadmap. Los plazos y el alcance de esas certificaciones dependen de una definición del responsable — no publique estimaciones antes de eso.
Ruta de diagnóstico
La mayoría de los problemas reportados cae en un número pequeño de causas. Esta ruta sigue el orden que suele resolver más rápido.
— Operaciones de dispositivo o política que fallan en una cuenta nueva: verifique que la enterprise de Android Enterprise esté vinculada a la organización. Sin ese vínculo, esas operaciones se rechazan.
— Código QR de enrollment que dejó de funcionar: revise la validez del token, que es de 24 horas por defecto, y genere uno nuevo si hace falta.
— Enrollment en BYOD o COPE rechazado: la funcionalidad de perfil de trabajo debe estar disponible en el plan contratado.
— Comando detenido como pendiente: el equipo debe ser alcanzable para recibir la acción. Los comandos tienen plazo y pueden expirar antes de que el equipo vuelva a comunicarse.
— Estado del equipo desactualizado en la consola: el estado llega por notificación, no por consulta en vivo. Un equipo sin red mantiene su último estado conocido.
— Equipo marcado como no conforme: la pestaña de cumplimiento muestra el origen y el motivo de cada hallazgo, incluidos los detectados por el monitoreo de comportamiento además de los reportados por AMAPI.
Cuándo abrir un ticket
Si la ruta anterior no lo resolvió, el soporte diagnostica más rápido con tres datos: el identificador del dispositivo, la hora aproximada en que ocurrió el problema y qué esperaba en lugar del comportamiento observado. Si el problema involucra un comando concreto, indicar cuál fue y cuándo se envió ayuda a localizar el registro correspondiente.