Principales caractéristiques des solutions 2FA inWebo

Pourquoi protéger les comptes utilisateurs avec l’authentification forte.

Que les utilisateurs soient des employés utilisant des applications bureautiques ou métier, des administrateurs système dans votre département IT, ou des clients accédant à votre plateforme de services, les comptes utilisateur représentent l’endroit par lequel la réputation et le business de votre organisation sont ou seront touchés.

L’authentification multi-facteurs désigne au sens large toute solution de sécurité plus efficace que les mots de passe choisis par les utilisateurs (très peu sécurisés) et les politiques de mots de passe (inapplicables ou inefficaces car elles sont trop complexes pour les utilisateurs).

Une solution multi-facteurs est toujours un compromis entre le niveau de sécurité apporté, le niveau de friction introduit pour les utilisateurs et les coûts et efforts pour votre organisation. Contrairement aux solutions traditionnelles (hardware) ou low-cost (SMS), la solution inWebo apporte un très bon compromis sur ces 3 dimensions, pas uniquement la sécurité.

Rendre les mots de passe dépendants de terminaux de confiance

inWebo ajoute un niveau de sécurité aux mots de passe statiques en générant des mots de passe uniques dépendant de terminaux de confiance. Ainsi, notre technologie transforme les terminaux des utilisateurs – tels que tablettes, téléphones mobiles et ordinateurs – en méthodes d’authentification forte. Lors de la connexion, un des terminaux de confiance de l’utilisateur est utilisé pour génerer un mot de passe unique dépendant de ce terminal. Il peut s’agir directement du terminal utilisé pour se connecter si c’est l’un des terminaux de confiance de l’utilisateur, ou du téléphone mobile de l’utilisateur sinon. Notez que ce mot de passe unique n’est pas envoyé à l’utilisateur.

Pourquoi cela vous aide-t-il à sécuriser les comptes utilisateur ? Si quelqu’un souhaite accéder à un compte utilisateur, il doit non seulement connaître le mot de passe (c’est déjà le cas sans 2FA) mais doit AUSSI avoir accès à l’un des terminaux de confiance de cet utilisateur car il n’y a pas d’autre moyen d’obtenir un mot de passe unique valide. Ni le mot de passe, ni le terminal de confiance ne sont suffisants, il faut obligatoirement les deux pour accéder au compte souhaité.

Tous les terminaux. Pas de prérequis. Pas de dépendance.

Ce que nous entendons par terminal de confiance ne correspond pas à l’appareil lui-même, mais à un navigateur ou à une App (ou client). Ainsi, inWebo supporte:

  • L’authentification par App mobile : L’App inWebo Authenticator est utilisée pour générer des mots de passe uniques: soit sur demande, soit déclenchée par notification depuis la plate-forme inWebo. inWebo Authenticator est disponible pour iOS, Android, Windows Mobile et Blackberry.
  • L’authenfitication in-App: inWebo mAccess est un SDK transformant vos propres Apps et clients en générateurs de mots de passe uniques: inWebo mAccess est disponible en Objective C, Java et C#.
  • L’authentification via navigateur : le navigateur est directement le “token” d’authentification, c’est-à-dire le générateur de mots de passe unique. Virtual Authenticator et inWebo Helium sont disponibles pour tous les navigateurs.

Les méthodes d’authentification inWebo sont simplement ajoutées pour votre service en configurant des politiques pour des groupes d’utilisateurs. Vous n’avez pas besoin de savoir quel utilisateur possède quel(s) terminal(aux). Egalement, l’intégration de notre technologie à de nouvelles versions est totalement transparente, c’est-à-dire que vous n’avez rien à faire lors des montées de versions d’OS ou l’apparition de nouveaux terminaux.

Multiples terminaux de confiance. Un seul PIN

Dans un scénario 2FA où les mots de passe uniques dépendent d’un terminal de confiance et d’un PIN, un utilisateur peut posséder de multiples terminaux de confiance, mais il n’a besoin que d’un PIN. Ainsi, l’expérience est la même quelque soit la façon dont les utilisateurs accèdent à votre service. Cela peut sembler évident dans le contexte d’une authentification par mot de passe, mais c’est rarement le cas pour de l’authentification forte. Evidemment, ce PIN n’est jamais stocké dans les terminaux de confiance.

L’authentification flexible.

Ces méthodes d’authentification couvrent la plupart des situations, cas d’usage, et circonstances, de facon très flexible. Par exemple, vous pouvez déployer l’authentification multi-facteurs pour tous les utilisateurs sans vous soucier de savoir qui a un smartphone ou non. Un utilisateur peut se connecter via un navigateur d’un de ses terminaux habituels par notre méthode “mains-libres”, et utiliser l’authentification mobile dans les rares cas où il se connecte depuis un terminal nouveau ou inhabituel – quand bien même il ne dispose ni de couverture mobile ni de WiFi sur son téléphone.

Améliorez l’expérience tout en diminuant les risques.

Contrairement aux solutions multi-facteurs classiques, les méthodes inWebo n’ajoutent pas de friction au process d’authentification par mot de passe existant, et diminuent même cette friction dans la plupart des cas. Puisqu’il n’y a pas de friction additionnelle, la question n’est donc plus de savoir s’il faut ou non demander l’authentification multi-facteurs pour une transaction donnée (en essayant d’estimer le risque à ne pas demander l’authentification multi-facteurs). Il n’y a en fait aucun bénéfice à prendre ce risque.

Une solution clé en main.

Authentifier les utilisateurs, tous comptes faits, est une chose aisée. Il existe de nombreuses technologies pour cela, ainsi que des standards, des RFCs, des alliances industrielles, des fournisseurs, et de bons développeurs. La réelle difficulté à laquelle votre organisation est confrontée avec l’authentification forte est de fournir un service s’appuyant sur ces options technologiques. Cela nécessite certes d’intégrer la technologie d’authentification choisie, mais également de disposer des moyens et outils pour provisionner les comptes utilisateur, enrôler les utilisateurs, gérer le support, l’administration, l’audit, l’analyse des logs d’usage, etc. C’est-à-dire en fait toutes les activités d’exploitation que les organisations mettent en oeuvre pour leurs infrastructures ou leurs applications, à grand renfort d’outils, de process et de ressources.

Ces process d’exploitation sont couverts par notre solution. Grâce à notre API, vous pouvez les exécuter à partir de vos outils existants. Le provisioning et l’enrôlement peuvent ainsi être gérés depuis votre plate-forme de gestion d’identité; le support utilisateur depuis votre plate-forme de gestion de service, l’analyse depuis le SIEM, etc.

Cependant, vous n’avez pas besoin d’intégrer notre API dès le début car tous ces processus peuvent également être gérés depuis notre console d’administration. En fait, il est même probable que vous puissiez commencer sans aucune intégration. Pour le provisioning des comptes utilisateur, vous avez besoin d’une solution automatisée. C’est précisément ce à quoi sert l’outil IWDS (inWebo Directory Sync) : synchroniser les comptes utilisateur, les groupes et les politiques d’authentification à appliquer à votre service. Les logs de connexion et d’administration peuvent être générés et exportés manuellement si vous ne souhaitez pas initialement intégrer l’API de collecte de logs. Des outils d’enrôlement très modulaires sont pré-définis dans la console d’administration inWebo pour vous éviter d’avoir à en construire. Et ainsi de suite.

Implémenter l’authentification forte avec inWebo est sans doute bien plus simple que vous ne l’imaginiez.

Disponible, robuste, certifié.

Puisque vous attendez d’un service d’authentification qu’il soit toujours disponible, nous avons créé des plates-formes complètement redondantes. Une plate-forme est un groupe de plusieurs (actuellement 3) infrastructures serveur indépendantes, distribuées dans des datacenters certifiés. La perte de connectivité de toutes nos infrastructures serveur sauf une n’a pas d’impact sur la disponibilité du service d’authentification. Contrairement à la plupart des solutions, nos plate-formes ne reposent jamais sur un fournisseur unique : cette architecture nous a permis d’atteindre 100% de disponibilité de service au cours des 5 dernières années. À titre de comparaison, des services tels que Gmail et AWS ont des taux de disponibilité plus faibles.

La sécurité n’est pas une caractéristique ‘automatique’ d’une solution multi-facteurs. Certes, un utilisateur doit connaître son mot de passe et posséder un terminal de confiance, il a donc l’impression que le mécanisme est nettement plus sécurisé qu’une authentication reposant uniquement sur un mot de passe. Cependant, pour un attaquant, les options permettant d’accéder à un compte utilisateur sont quasiment aussi nombreuses qu’il s’agisse d’une authentification par mot de passe ou d’une authentification multi-facteurs (vous pouvez lire notre livre blanc pour plus de détails sur ce sujet). Ce qui rend vraiment sécurisée une solution 2FA, c’est avant tout son implémentation et son design, tant côté client que côté serveur. Ainsi, l’implémentation d’algorithmes brevetés confère à nos solutions un niveau de sécurité auquel la plupart des RSSI et spécialistes de sécurité rencontrés ne s’attendaient pas; notamment pour une solution logicielle. De plus, dans nos plateformes, les algorithmes d’authentification sont exécutés au sein de serveurs de sécurité (Hardware Security Modules, HSM) protégeant ainsi des attaques et abus. Ainsi, contrairement aux solutions d’authentification Cloud classiques, nos clients contrôlent intégralement toute la chaîne de confiance.

Ouvert et connecté.

inWebo supporte les standards tels que radius et SAML v2. Rien qu’avec ces deux standards, vous pouvez utiliser nos solutions d’authentification pour la plupart – si ce n’est tous – les VPNs, proxies web, applications Saas (telles qu’Office 365, Salesforce, Google Apps et bien d’autres), et équipements installés dans vos datacenters (tels que SailPoint IdentityIQ, CyberArk, Wallix et bien d’autres).

Nous exposons également une API REST, ce qui est intéressant dans trois situations :

  • Si votre site internet est basé sur CMS tel que WordPress, Drupal ou Joomla. Nous avons développé des plugins d’authentification basés sur notre API pour ces CMS.
  • Si vous utilisez un système de fédération ou de gestion des accès tel que ADFS, Shibboleth, Forgerock OpenAM, Gluu Server, PingFederate, Memority, Ilex, etc. Des modules basés sur notre API ont également été développés, par inWebo ou par l’un de nos partenaires. D’autres sont en cours de développement. Ces modules fournissent davantage de flexibilité et d’options que radius et SAML v2.
  • Si vous développez votre propre site ou portail, web ou mobile. Dans ce cas, vous souhaiterez sans doute intégrer directement notre API. Vous trouverez toutes les informations nécessaires sur notre site développeur. Des exemples de projets sont fournis pour différents environnements.