Où élaborer ses politiques d’accès lorque l’on combine IDaaS et UEM ?
Les redondances fonctionnelles sont bien présentes, entre IDaaS et UEM, notamment en ce qui concerne l’authentification, l’intégration avec des contrôles de sécurité tiers, et les moteurs de stratégies contextuelles.
Le contrôle d’accès conditionnel et, avec lui, les approches sans confiance, ou zero trust, comptent parmi les sujets les plus importants du moment dans l’informatique des utilisateurs finaux.
Les entreprises ayant adopté gestion unifiée des terminaux (UEM) et identité en mode service (IDaaS) associent naturellement les deux afin construire des règles de contrôle d’accès qui prennent en compte un large éventail de données contextuelles et de facteurs de risque. Toute la question consiste à savoir où élaborer et administrer ces règles – UEM ou IDaaS.
Évidemment, chaque a son rôle nominal. Mais les redondances fonctionnelles ne manquent pas, sur des domaines comme l’authentification (y compris à facteurs multiples), l’intégration avec des systèmes de sécurité tiers, comme protection du terminal (EPP), ou défense contre les menaces mobiles (MTD), et encore moteurs de stratégies qui lient ensemble tous ces composants pour prendre des décisions de contrôle d’accès en fonction des facteurs de risques identifiés dans le contexte des demandes d’accès.
L’enrôlement UEM pour l’accès aux applications SaaS
Prenons l’exemple d’une politique d’accès : pour accéder à une application SaaS à partir d’un terminal mobile, ce dernier doit être enrôlé dans le système d’UEM.
Ceci peut être appréhendé de manière centrée sur l’UEM : le terminal est enrôlé, le système authentifie également l’utilisateur. De là, l’UEM peut utiliser un fournisseur d’identité intégré – lui-même probablement fédéré ou synchronisé avec l’annuaire Active Directory interne – pour assurer la fédération vers une application SaaS. Mais lorsqu’une solution d’IDaaS est présente, l’UEM peut lui déléguer cela, à charge pour elle d’assurer la fin de la chaîne d’ouverture de session vers l’application SaaS.
Mais il est également envisageable de centrer la mise en œuvre d’une telle politique sur l’IDaaS. Là, l’utilisateur s’authentifie auprès de l’IDaaS, qui assure la fédération vers l’application SaaS. Mais, avant d’accorder l’accès, l’IDaaS appelle l’UEM via une API pour vérifier que le terminal utilisé est enrôlé dans l’UEM et conforme aux politiques établies.
Les deux techniques aboutissent au même résultat, mais la logique décisionnelle est mise en œuvre à des endroits différents.
Faire appel à un agent de sécurité tiers
L’illustration peut être poussée plus loin, en impliquant un agent de défense contre les menaces mobiles (MTD), capable de rapporter sur l’état du terminal.
Dans une approche centrée sur l’UEM, celui-ci authentifie l’utilisateur et sait quel appareil il emploie. Il interroge alors la solution de MTD, via une API spécifique, pour s’assurer de l’état du terminal.
Dans l’approche centrée sur l’IDaaS, après authentification de l’utilisateur, l’IDaaS peut interroger à la fois l’UEM et la solution de MTD, pour prendre sa décision relative à l’autorisation d’accès à l’application SaaS en fonction de leurs réponses.
Encore une fois, la politique est la même, produit les mêmes effets ; c’est le point d’intégration qui diffère.
Autres considérations
Il ne s’agit là que de politiques très élémentaires, décrites dans les termes les plus simples possible. En réalité, il existe bien d’autres façons de concevoir la relation IDaaS et UEM. Les standards d’identités permettent d’enchaîner les choses et de déléguer des fonctions d’une plateforme à l’autre de manière granulaire. De plus, presque tous ces produits offrent une API propriétaire pour lire et/ou rapporter des informations sur l’état des appareils, ainsi que d’autres données.
Viennent ensuite toutes les intégrations tierces auxquelles il est possible de procéder dans un moteur de politique d’accès conditionnel : l’EPP, la MTD, bien sûr, mais également les passerelles d’accès cloud sécurisé (CASB), les solutions d’authentification à facteurs multiples tiers, des bases de connaissance de vulnérabilités, des flux de renseignements sur les menaces, etc.
Cela a conduit à la prolifération des programmes d’intégration et de partenariats, comme le Workspace ONE Intelligence Trust Network, la Microsoft Graph API, la Google Cloud Identity BeyondCorp Alliance, la Lookout Post Perimeter Security Alliance, et d’autres encore.
Et c’est sans compter avec des moteurs de gestion des politiques d’accès disposant de leur propre marque indépendante, comme Workspace ONE Intelligence, Citrix Analytics, Microsoft Intelligent Security Graph, et MobileIron Access.
Conclusions
Il y a une décision à prendre, mais elle n’est pas forcément anodine. Tout dépend de la manière dont sont appréhendées les différentes briques considérées : certaines peuvent être vues comme stratégiques, tandis que d’autres ne relèvent que du choix tactique.
Mais une chose est sûre : l’intégration de l’IDaaS et de l’UEM, l’élaboration de toutes les politiques d’accès conditionnel et contextuel souhaitées, et l’intégration de produits de sécurité tiers constituent une étape importante de la modernisation de l’informatique de l’utilisateur final.
Aujourd’hui, il apparaît donc important de voir, avec ses fournisseurs d’IDaaS et d’UEM comment ils construisent leurs intégrations de référence, quelles données ils peuvent transmettre et quels partenaires font partie de leur écosystème.
