Esta sección está diseñada para proveer un resumen de alto nivel que busca aclarar las opciones disponibles y sus motivaciones antes de entrar en los detalles de cómo ejecutarlas.
Si bien hay algunos casos muy particulares donde se puede utilizar la solución ZofToken sin escribir una sola línea de código (como se puede ver en ejemplos disponibles en el sitio de ZaaS), cualquier integración significativa requerirá algún grado de interacción con la API.
La sección específica de la API dentro de la documentación incluye múltiples formatos y recomendaciones para entenderla y utilizarla en forma sencilla, pero esta sección está diseñada para proveer un resumen de alto nivel que busca aclarar las opciones disponibles y sus motivaciones antes de entrar en los detalles de su implementación.
Nota: antes de iniciar el proceso de enrolamiento de los usuarios, se debe decidir cuáles son los servicios que se van a utilizar y cómo van a operar. Como estos detalles se discuten en la guía de instalación de ZofToken Server y/o en las opciones de configuración de ZaaS, no se repetirán aquí.
Dado que la solución ZofToken está diseñada para operar con un número masivo de usuarios, el proceso de enrolamiento busca ser muy simple. Del lado del cliente, una llamada única a la API creará el token en la instancia y retornará la información necesaria para que el usuario pueda completar el enrolamiento por cualquiera de las tres vías disponibles.
En primer lugar, se contará con un deeplink que puede ser enviado por correo y, si la aplicación lo soporta (como es el caso con ZofToken Universal App), al ser accedido por el usuario iniciará automáticamente la aplicación en el smartphone con toda la información necesaria o redireccionará al usuario a la tienda apropiada (Apple o Android) para instalarla.
En segundo lugar, la API retornará un código QR (que es una representación gráfica del deeplink) que podrá ser leído ya sea por la aplicación o directamente por la cámara estándar en la mayoría de los smartphones modernos.
Finalmente, la API retornará un código que puede ser usado una única vez para realizar un enrolamiento manual en aplicaciones que hayan integrado el ZofToken SDK.
En cualquiera de los casos, en este momento se le solicitará al usuario que cree su PIN, se autentique con biometría o cualquier mecanismo que se haya seleccionado para proteger el secreto de autenticación y el proceso de enrolamiento quedará completo.
Dada la descripción de arriba, un proceso genérico de enrolamiento generalmente tendrá una de las formas que se detalla a continuación.
Para cada usuario existente dentro del activo que se esté protegiendo (por ejemplo, una aplicación web), obtener el correo electrónico del usuario y un identificador de usuario apropiado (por ejemplo, el nombre del usuario, un número de documento o inclusive el propio correo electrónico).
Ejecutar la llamada de enrolamiento en la API de la instancia de ZofToken utilizando un authkey con privilegios apropiados.
Enviar un correo electrónico al usuario con el deeplink retornado por la API y cualquier información adicional que se requiera (una explicación de por qué ahora el cliente está ofreciendo o requiriendo la utilización de 2FA, términos y condiciones relevantes, etc.)
Asumiendo que el usuario se encuentra autenticado contra el activo que se está asegurando (por ejemplo, una aplicación web), puede hacer click sobre algún elemento de la interfaz que ofrece la configuración de 2FA.
Se le presenta al usuario cualquier información relevante y, de ser necesario, se le indica que instale la aplicación correspondiente.
Luego de que el usuario acepta la información y confirma que tiene la aplicación disponible, el cliente ejecuta la llamada de enrolamiento en la API de la instancia de ZofToken utilizando un authkey con privilegios apropiados.
Se le muestra al usuario en su navegador el código QR retornado (que pueden leer con su smartphone para completar el enrolamiento de inmediato) y alternativamente se le envía el deeplink por correo electrónico como respaldo.
Es importante notar que los dos casos anteriores no son las únicas opciones y se pueden considerar casos particulares según el caso de negocio
A modo de ejemplo, si se utilizara ZofToken como segundo factor para transacciones con tarjetas de crédito, el usuario podría recibir un código de enrolamiento de uso único junto con la documentación de la propia tarjeta o el plástico correspondiente, y simplemente ingresarlo manualmente en la aplicación que se haya definido para tales fines.
Una vez se completa el proceso de enrolamiento, revisar el estado de un token en particular es obviamente el aspecto más relevante de la integración dado que esto será lo que le permita al cliente tomar decisiones basadas en el nivel de autenticación del usuario.
ZofToken provee tres modos de operación, permitiéndole al cliente decidir si quiere usar cualquiera de ellos por separado o todos al mismo tiempo, dependiendo del tipo de integración que se está implementando.
En este modo, un activo del cliente que necesita tomar una decisión de autenticación ejecuta el llamado correspondiente a la API de la instancia ZofToken con un authkey válido (que no requiere de privilegios administrativos) y recibe una respuesta indicando el estado actual del token.
Este modo es preferible cuando está unido a una configuración del servicio que le permite al token quedar abierto por un período de al menos algunos minutos y para aplicaciones que tienen sesiones que potencialmente incluyen transacciones con distintos niveles de importancia. Por ejemplo, un aplicación usual de Home Banking puede configurar una ventana del token de 10 a 15 minutos (suficiente para la mayoría de las sesiones de usuario) y consultar el estado del token durante el acceso inicial (cuando el usuario hace el proceso de login) y luego en cualquier tipo de transacción que implique movimiento de fondos. De este modo, el usuario solamente tiene que abrir su token antes de acceder al sistema pero luego puede operar en forma simple y segura hasta que cierra manualmente su token o la duración configurada expira. Esto es muy similar al tipo de interacción que un usuario tiene con un cajero automático (cambiando la tarjeta física por el smartphone), lo cual representa un modelo familiar para la gran mayoría de las personas e introduce un mínimo de trabajo adicional, alineado con las prácticas de diseño modernas consideradas "frictionless".
En este modo, todos los eventos relevantes de los tokens son reportados a través de llamados configurables via una conexión estándar HTTPS realizada por la instancia ZofToken. Cada uno de estos webhooks incluirá la identificación del usuario y el servicio involucrado, el evento del token y un secreto configurando para que el servicio que esté esperando estos llamados pueda confirmar que el llamado efectivamente se originó en el servidor ZofToken.
Este modo es ideal para tomar decisiones "instantáneas" (por ejemplo, esperar a realizar una transacción hasta que el usuario abra su token) o como un complemento al modo de consulta descrito previamente para identificar y reaccionar ante eventos específicos (por ejemplo, el bloqueo de un token por errores de autenticación o la indicación del usuario de que la transacción está siendo realizada bajo coacción si esto es permitido por el servicio). Notar que si bien es técnicamente posible esperar a que un token se abra realizando consultas en forma repetida y, en la mayor parte de los casos, esto operará de forma idéntica a esperar un webhook, esto debe considerarse una mala práctica de desarrollo dado que genera una carga innecesaria tanto para la aplicación del cliente como para la instancia de ZofToken.
Si bien en general este es el mecanismo de utilización que menos casos de uso permite y que le genera mayores dificultades al usuario, la solución ZofToken soporta de todos modos un modo en el cual el token va generando códigos (que cambian cada 30 segundos) y pueden ser validados contra la API.
En este modo, un activo que quiera autenticar al usuario o un operador que se esté comunicando con el usuario por un canal inseguro (por ejemplo, una línea telefónica) puede solicitarle que ingrese o lea el código que le está mostrando su token en ese momento. Dicho código puede tener entre 4 y 32 caracteres y existen mecanismos para garantizar la sincronía entre el token y la instancia ZofToken.
Una potencial ventaja de este modo, para ciertos escenarios, es que no requiere conectividad entre la aplicación en el smartphone y la instancia ZofToken, operando como un token físico tradicional.
Si bien las dos secciones previas describen la mayoría de las operaciones, a continuación se describen el resto de los llamados a la API que son provistos por una instancia ZofToken.
Este es una operación usual, pero se recomienda que durante el borrado de cualquier token, se envíe un correo electrónico al usuario que explique la situación, dado que el token configurado en su aplicación dejará de funcionar y también deberá ser eliminado.
Utilizando un authkey con privilegios administrativos la API permite que un token sea forzado a un estado abierto, cerrado o bloqueado.
Existen tres ejemplos básicos en los cuales puede ser necesario usar esta operación:
Todas las interacciones normales entre la aplicación en el smartphone del usuario y la instancia ZofToken del cliente son procesadas a través de una red compartida (Internet en la mayoría de los casos, pero potencialmente una red interna para escenarios particularmente seguros).
Si el usuario no puede conectarse a la red (tipicamente porque están en algún lugar sin acceso a un servicio de datos) pero igualmente quiere autenticarse utilizando su token, el cliente puede proveer un mecanismo para que esto sea posible.
En este modo, el usuario se pone en contacto con el cliente (tipicamente por teléfono) y solicita una autenticación fuera de línea. El operador del cliente (tipicamente a través de una aplicación interna) utiliza uno de los llamados de la API de la instancia ZofToken para solicitar un código de validación y se lo dice al usuario. El usuario ingresa este código en su aplicación ZofToken, recibe un código de respuesta y se lo comunica al operador, quien lo ingresa en su sistema para hacer otro llamado a la API que intentará abrir el token con dicho código.
Existen una serie de comentarios relevantes sobre este modo de operación:
La solución ZofToken fue diseñada para proveer la mayor flexibilidad posible, de modo de permitirle a los clientes su utilización para propósitos y escenarios muy diversos. Esta sección busca ofrecer una serie de ejemplos de dichos escenarios posibles en tres categorías que van desde lo estándar hasta lo inusual, simplemente como una forma de mostrar que no hay un único uso correcto de 2FA.
A medida que se analicen estos ejemplos, es muy importante recordar que una única instancia de ZofToken puede implementar múltiples casos de uso al mismo tiempo. Utilizando diferentes configuraciones de servicios y asignando a los usuarios apropiadamente dentro de los mismos, el cliente podrá lograr los diferentes objetivos de seguridad y autenticación requeridos.
Estos tipicamente son los primeros que los clientes imaginan al considerar la utilización de 2FA y es de esperar que la mayoría de las implementaciones de ZofToken realicen alguna de estas funciones.
En cualquier situación donde un aplicativo o servicio necesita autenticar un usuario (particularmente a través de redes inseguras), además de solicitar credenciales de acceso normales (como un nombre de usuario y una contraseña), la aplicación puede consultar a la instanacia de ZofToken, esperar un webhook apropiado o pedir un código de uso único para determinar el estado de un token antes de efectivamente permitir el acceso.
Una variante específica de este escenario es la autenticación de un usuario al acceder a un sistema operativo, ya sea en un equipo personal o corporativo. El sitio de ZaaS provee un ejemplo en esta situación para equipos personales con Windows 10 PRO, pero en general la mayoría de los sistemas operativos manejan el concepto de ejecutar determinados comandos cuando un usuario se identifica, siendo trivial agregar a estos comandos una consulta del estado del token correspondiente que desconecta al usuario si no está abierto.
La mayoría de las aplicaciones y servicios, luego de que un usuario se autentica ante las mismas, establecen una sesión durante la cual el usuario puede ejecutar diferentes operaciones. Cuando la operación o transacción a ejecutar es sensitiva en cualquier sentido, la aplicación puede agregar una capa adicional de seguridad revisando el estado del token.
Si bien estos ejemplos no siempre representan las situaciones "primarias" por las cuales un cliente está considerando la implementación de una solución de 2FA, sin embargo pueden agregar un valor significativo a la organización mitigando algunos riesgos muy comunes.
Cuando un usuario se comunica con un call center, es común que los operadores hagan una serie de preguntas, las cuales usualmente son bastante inseguras, para autenticar al usuario antes de ejecutar la solicitud que provenga del usuario. Si el operador puede en lugar de estas preguntas (o como un agregado a las mismas) verificar el estado de un token en su pantalla (por ejemplo, integrado a su CRM o con una interface específica a la instancia de ZofToken), este proceso no solamente es significativamente más seguro sino que además es mucho más cómodo y rápido para el usuario.
Garantizar que cualquier cambio a las aplicaciones o plataforma que soportan un ambiente productivo de IT se realiza en forma autorizada es un control básico para cualquier organización. Para aquellas organizaciones que han llegado a un nivel de madurez donde estos cambios no son enteramente manual sino que utilizan alguna forma de automatización, integrar 2FA puede ayudar en forma significativa tanto a mejorar la seguridad como a generar evidencia para futuras revisiones o auditorías. En particular, cualquier organización que utilice herramientas de integración continua puede integrar facilmente los webhooks o llamados de consulta a la API de ZofToken para realizar o validar operaciones críticas (por ejemplo, impactar código en repositorios relevantes o pasar nuevas versiones a producción).
Notar que esto es un ejemplo claro de como la misma instancia de ZofToken puede servir múltiples propósitos, dado que un cliente que tiene como objetivo principal agregar 2FA para sus usuarios, de todos modos puede utilizar estas funcionalidades con el personal interno o externo de TI.
Estos representan algunas ideas potenciales donde la solución ZofToken podría encargarse de aspectos que normalmente no se ven como integrados con 2FA. Es nuestra esperanza que los clientes puedan identificar todo tipo de integraciones originales para diversos temas y esa es parte de la razón por la que ofrecemos un servicio gratuito en ZaaS para promover todo tipo de pruebas y experimentos.
La mayoría de los sistemas IoT se conectan a algun tipo de concentrador que permite tanto operaciones locales como remotas y las operaciones remotas normalmente requieren que ese concentrador esté conectado a alguna forma de servicio cloud. Dado que estos servicios cloud no suelen ser particularmente seguros o tener un alto grado de disponibilidad, una opción sería tener un componente de software en la red local como la única parte que se conecta con el concentrador de IoT y mantener las operaciones remotas utilizando un elemento seguro como un ZofToken. Esto resultaría particularmente útil para operaciones con dispositivos IoT que son parte de una infraestructura de seguridad (por ejemplo, una alarma o un cerrojo inteligente) donde teniendo a un token que dispara un webhook como un evento local para abrir una puerta representa una mejora importante sobre una aplicación de un tercero que envía un llamado a un servicio cloud de otro tercero y que finalmente llega al concentrador de IoT que debe estar conectado continuamente a Internet para interactuar con ese servicio cloud.
Una instancia de ZofToken solamente accesible a través de una red Wi-Fi que cubre un edificio o una oficina podría ser utilizada para registrar el horario en el que el personal llega o se retira y quién está actualmente presente (por ejemplo, para un caso de evacuación). Una vez que el usuario llega a la ubicación correspondiente, su smartphone se conecta a la red y cuando abre su token, el webhook puede ser capturado por un sistema que registra el tiempo, con el procedimiento opuesto ocurriendo cuando el usuario cierra el token al retirarse.
