Chaque entreprise fonctionne différemment. Vous avez vos propres utilisateurs, groupes, administrateurs, prestataires, applications, réseaux, VPN, bureaux, travailleurs à distance, méthodes d'authentification et exigences de sécurité.

Alors, pourquoi devriez-vous réorganiser le fonctionnement de votre entreprise en fonction des limites de votre solution de cybersécurité ?

Vous ne devriez pas. Votre sécurité devrait s'adapter à votre organisation et vos règles.

C'est l'une des idées derrière WebADM Stratégies et accès conditionnel avec OpenOTP. Au lieu d'appliquer une seule configuration d'authentification à tout le monde, WebADM vous permet d'être très précis sur qui peut accéder à quoi, quand, à partir de quels réseaux et dans quelles conditions.

Et une fois que vous combinez cela avec OpenOTP, les contextes de confiance, les stratégies de renforcement et d'allègement de l'authentification (Step-Up et Step-Down), le badgeage, les conditions réseau, les flux de travail d'approbation et les décisions basées sur les risques, vous pouvez faire quelque chose d'utile :

Renforcer la sécurité là où cela compte sans ajouter de friction partout ailleurs.

Le problème du “ MFA partout ”

Voici Sarah. Sarah travaille en comptabilité. C'est lundi matin. Elle est assise à son bureau habituel, utilise son ordinateur portable professionnel et est connectée au réseau de l'entreprise. Elle se connecte.

MFA (authentification multi-facteurs)

Elle ouvre une autre application protégée.

Encore l'authentification multifacteur.

Plus tard, elle se connecte à un autre service.

Une autre demande de MFA.

À l'heure du déjeuner, Sarah est devenue très douée pour appuyer Approuver.

Maintenant, imaginez que mardi soir, quelqu'un possède le mot de passe de Sarah et tente de s'authentifier via une adresse IP associée à une infrastructure suspecte.

Cette tentative d'authentification devrait-elle recevoir exactement la même notification Push que Sarah assise à son bureau ? Probablement pas. Le problème ne vient pas de l'authentification multifacteur (MFA).

Le problème est de traiter des situations très différentes comme si elles étaient identiques.

Un utilisateur n'a pas besoin d'une seule politique

WebADM commence par un modèle de politique multicouche.

Il existe une configuration d'application par défaut, mais cette configuration peut être remplacée pour des groupes particuliers, des utilisateurs individuels, des applications clientes, des groupes au sein de ces stratégies clientes et des réseaux.

WebADM attribue des priorités, ou des pondérations, à ces couches de stratégies. La stratégie la plus spécifique et dotée du poids le plus élevé peut primer sur la configuration la plus générale.

Sur le plan conceptuel, cela ressemble à ceci :

C'est important parce que les véritables politiques de sécurité ne sont pas uniformes.

Un employé qui accède à l'intranet n'a pas nécessairement besoin de la même politique qu'un administrateur accédant à la production. Un VPN n'a pas nécessairement besoin de la même configuration qu'une connexion Windows. Un réseau interne n'a pas nécessairement besoin du même traitement qu'un réseau externe. Et un prestataire n'a pas nécessairement besoin des mêmes règles d'accès qu'un employé permanent.

WebADM vous permet de modéliser ces différences au lieu de faire semblant qu'elles n'existent pas.

Qui êtes-vous ?

Commençons par quelque chose de simple.

Votre configuration OpenOTP standard peut nécessiter : LDAP + MFA

C'est votre référence de base. Mais maintenant nous avons Bob. Bob est un administrateur de domaine. Bob a considérablement plus de pouvoir que l'employé moyen, donc vous ne voulez probablement pas que sa politique d'accès soit identique.

WebADM vous permet de contourner les paramètres d'OpenOTP pour un groupe particulier.

En effet, la documentation de RCDevs illustre cela à l'aide du groupe ’ Domain Admin ». L'exemple modifie le mode de connexion OpenOTP pour passer à une authentification LDAP + FIDO, désactive le repli sur OTP, active la protection contre les faux défis et la vérification du mot de passe, et impose une opération d'enregistrement par badge.

Donc :

Même infrastructure OpenOTP mais politique différente. Parce que qui vous êtes a de l'importance.

Qu'essayez-vous d'accéder ?

Maintenant, rendons les choses plus intéressantes.

Bob n'est pas simplement un administrateur de domaine. C'est un administrateur de domaine qui essaie d'accéder à un système particulier.

De WebADM Politiques des clients vous permet de configurer des politiques pour une application spécifique ou un groupe d'applications et de serveurs. RCDevs recommande de définir des politiques client distinctes lorsque différentes applications nécessitent des paramètres différents.

Selon l'intégration, WebADM peut identifier le client par le biais de mécanismes incluant un identifiant client (Client ID), un identifiant RADIUS NAS-Identifier, une adresse IP NAS ou l'adresse IP du système client.

Cela signifie :

• Bob accède à une application normale → Une politique.
• Bob accède à un système administratif → Politique renforcée.
• Bob se connecte via le VPN d'entreprise → Politique VPN.

La question n'est plus simplement : Bob a-t-il le droit de s'authentifier ?

Cela devient : Comment Bob doit-il s'authentifier auprès de cette ressource particulière ?

C'est une question beaucoup plus utile.

Où êtes-vous ?

Maintenant, ajoutez un autre élément de contexte : le réseau.

Une stratégie client peut contenir Paramètres d'application par réseau.

WebADM peut donc modifier la configuration d'OpenOTP en fonction du réseau d'origine de l'authentification.

La documentation RCDevs donne un exemple dans lequel des requêtes provenant d'un 192.168.3.0/24 modifier le LoginMode d'OpenOTP en LDAP. Pour ce mécanisme, l'intégration client doit transmettre l'adresse IP de l'utilisateur à OpenOTP.

Maintenant nous savons :

• Qui êtes-vous ?
• À quels groupes appartiens-tu ?
• À quoi accédez-vous ?
• D'où vous connectez-vous ?

Et WebADM peut utiliser ces informations pour décider quels paramètres d'application doivent s'appliquer.

Nous sommes déjà loin de : MFA : ACTIVÉ/DÉSACTIVÉ.

Mais cela devient plus intéressant.

Et si quelque chose ne va pas ?

C'est là où Paramètres d'application dynamiques Entrez.

WebADM peut modifier de manière dynamique les paramètres d'une application Web ou d'un service Web lorsqu'une adresse IP source est identifiée comme appartenant à une infrastructure de botnet, au réseau TOR ou à des points d'extrémité VPN publics. RCDevs fournit un microservice cloud qui effectue ces vérifications à l'aide de bases de données d'adresses IP publiques.

Maintenant nous pouvons présenter Step-Up.

Imaginez que Sarah s'authentifie normalement en utilisant la politique OpenOTP standard de l'entreprise. Ensuite, une authentification concernant le compte de Sarah arrive par un point de terminaison VPN public. WebADM peut réagir en entrant Mode survolteur.

Mais voici la partie intéressante.

Step-Up ne signifie pas simplement “ demander l'authentification multifacteur ”.”

C'est VOUS qui décidez ce que signifie Step-Up.

Dans l'exemple de configuration ’ RCDevs », Step-Up modifie OpenOTP pour exiger l'utilisation de LDAP + OTP, active la connexion par push et modifie les paramètres de blocage des comptes.

Vous pourriez donc avoir :

Vous n'êtes pas limité à l'ajout d'un autre facteur. Vous changez le configuration de sécurité de l'application pour cette situation.

Parfois, la bonne réponse n'est pas davantage de MFA. C'est “ Non ”.”

Le mode basé sur les risques de WebADM peut aller plus loin. Avec la politique basée sur les risques Niveau 1, une source suspecte correspondante déclenche les paramètres de vérification renforcée configurés.

Avec Niveau 2, un point de terminaison VPN public déclenche une authentification renforcée (Step-Up) tandis qu'une adresse IP identifiée comme appartenant à l'infrastructure d'un botnet entraîne le refus de l'accès. C'est une distinction importante.

• Si quelque chose semble inhabituel : Faites un pas en avant.
• Si quelque chose dépasse le seuil de risque de l'organisation : Refuser.

Il y a peu d'intérêt à envoyer une notification Push amicale à un utilisateur chaque fois que quelqu'un essaie ses identifiants depuis une infrastructure à laquelle vous avez déjà décidé de ne pas faire confiance.

Voici la partie amusante : la sécurité peut aussi se désengager

Les discussions sur la sécurité ont tendance à se concentrer sur l'ajout de choses.

• Plus d'authentification.
• Plus de contrôles.
• Plus de vérification.
• Plus de messages.

Mais il y a une autre question : Et si nous avions déjà assez de confiance ?

Pourquoi déranger l'utilisateur à nouveau ?

Les paramètres d'application dynamiques de WebADM prennent également en charge Paramètres de réduction.

L'administrateur définit ce que l'application doit faire lorsque la stratégie fonctionne en mode progressif.

Par exemple :

Tu ne désactives pas l'authentification multifacteur pour toute l'entreprise.

Vous dites : Dans ces circonstances spécifiques, nous disposons d'un contexte supplémentaire suffisant pour utiliser temporairement une politique d'authentification moins restrictive.

C'est très différent.

Sarah vient juste de badger au bureau. Ça ne devrait pas compter un minimum ?

C'est là que la sécurité physique et la sécurité numérique peuvent se rencontrer.

Imaginez que Sarah arrive au siège à 8h55.

Elle badge en utilisant son OpenOTP Token App. .(Pour en savoir plus sur Mobile Badging avec OpenOTP, veuillez lire ce blog).

C'est une information. L'organisation vient de recevoir un autre signal indiquant que Sarah est physiquement présente.

WebADM permet de modifier temporairement le mode de fonctionnement d'une politique client pour Réduction, augmentation ou refus pour une période définie. Le mode modifié peut également être appliqué conjointement avec des politiques par groupe et/ou par réseau. La rétrogradation n'est pas déclenchée automatiquement par le mécanisme des risques ; elle peut être activée explicitement via la fonction de modification de mode de la politique.

Par exemple :

C'est beaucoup plus précis que de dire : “ L'authentification multifacteur n'est pas requise au bureau. ”

Vous pourriez à la place formuler une politique autour d'une combinaison de : l'utilisateur + leur groupe + le réseau + l'application + le mode de fonctionnement actuel.

Alors peut-être : Employé + badgé sur + réseau d'entreprise → S'arrêter pendant une heure.

But : Administrateur privilégié + réseau d'entreprise → Exige toujours une authentification résistante au hameçonnage.

Et : Salarié + réseau externe → MFA normale.

Votre organisation décide de ce qui a du sens.

Ne viens-je pas juste de prouver qui je suis ?“

OpenOTP dispose d'un autre mécanisme utile pour réduire les frictions d'authentification : Connexion contextuelle.

Une fois les Contextes de Confiance activés, OpenOTP peut reconnaître un contexte utilisateur-appareil/IP de confiance suite à une authentification à deux facteurs réussie.

Les requêtes ultérieures correspondant à ce contexte de confiance peuvent basculer le LoginMode sur LDAP uniquement.

La confiance n'a pas non plus besoin de durer éternellement. Expiration du contexte détermine quand le contexte IP/appareil de confiance expire, tandis que Renouvellement de contexte peut étendre le contexte après des connexions réussies jusqu'à une durée de vie maximale configurée.

Donc :

Cela vous donne un principe utile : La confiance se mérite, elle est cadrée et temporaire.

L'utilisateur n'est pas simplement dispensé de MFA. OpenOTP utilise le contexte préalablement établi pour déterminer si un autre défi est nécessaire.

Maintenant, mettez le tout ensemble

C'est là où Politiques de WebADM devenir bien plus intéressant qu'une case à cocher intitulée “ Exiger l'authentification multifacteur ”.”

Lorsqu'une personne demande un accès, votre politique peut potentiellement prendre en compte plusieurs dimensions :

C'est toute l'histoire.

• L'identité compte.
• L'appartenance à un groupe compte.
• L'application a de l'importance.
• Le réseau a de l'importance.
• Le risque compte.
• La confiance préalablement établie a de l'importance.
• Le port de badges physiques peut avoir de l'importance.

Et votre entreprise décide de l'importance de chacune de ces choses.

Fin de non-recevoir ne signifie pas douloureux

Il y a un point important ici.

Nous venons de discuter de nombreux contrôles. L'utilisateur ne devrait avoir à en comprendre aucun.

Sarah n'a pas besoin de savoir que WebADM a évalué son groupe, la politique client, le réseau, le contexte de confiance, l'état des risques et le mode de fonctionnement actuel de la politique.

Elle devrait simplement acquérir l'expérience appropriée.

• Dans des conditions normales : Approuver la connexion.
• Dans un contexte de confiance établi : Peut-être qu'elle ne voit même pas d'invite MFA.
• Lorsque le risque augmente : Authentification supplémentaire requise.
• Lorsque la politique stipule que le risque n'est pas acceptable : Accès refusé.

La complexité réside dans le moteur de règles, absente de l'expérience quotidienne de l'utilisateur.

C'est ainsi que les contrôles d'accès granulaires peuvent réellement réduire les frictions au lieu d'en créer d'autres.

Parfois, la politique devrait dire : “ Demandez à quelqu'un ”

Toutes les décisions d'accès ne peuvent pas, ni ne devraient, être entièrement automatisées.

Imaginez qu'un prestataire demande l'accès à un système sensible. Tout est peut-être techniquement valide, mais l'organisation souhaite tout de même qu'un responsable ou un propriétaire de système approuve la demande.

WebADM prend en charge Conditions d'approbation d'accès pour cela.

L'accès peut nécessiter l'approbation d'un ou de plusieurs approbateurs désignés. WebADM et OpenOTP génèrent la demande d'approbation, et les approbateurs autorisés peuvent la recevoir via la fonctionnalité Push de l'application OpenOTP Token. L'e-mail d'approbation peut également contenir des détails sur la transaction tels que l'utilisateur, le domaine, l'adresse IP source et l'ID client.

Parfois, la bonne décision en matière de sécurité est réellement : Demande à Jane.

“ Signez ceci avant d'avoir accès ”

Il y a une autre fonction intéressante de politique client : Consentement d'accès de l'utilisateur / Signature du contrat.

WebADM peut exiger que les utilisateurs signent un document avant d'être autorisés à accéder à un système.

Ce document peut être un accord de confidentialité (NDA), des conditions générales, une charte d'utilisation ou tout autre accord. Le document signé peut avoir une durée de validité, et si le document original est modifié, WebADM peut exiger de l'utilisateur qu'il signe la version mise à jour avant de pouvoir s'authentifier à nouveau. (RCDevs | Centre de documentation)

Cela permet de créer des flux de travail tels que :

C'est un bon exemple de la raison pour laquelle l'accès conditionnel ne doit pas s'arrêter à l'authentification.

Parfois, la règle d'accès de votre entreprise est vraiment : Vous pouvez accéder à ce système après avoir signé ce document et l'avoir fait approuver par votre manager.

Pourquoi le système de sécurité ne devrait-il pas appliquer cette règle ?

Comment cela se compare-t-il à l'accès conditionnel de Microsoft ?

Il y a une comparaison évidente avec l'accès conditionnel de Microsoft Entra.

Les deux approches partagent une idée importante : Ne prenez pas de décisions d'accès sur la base des seuls identifiants. Évaluez le contexte et appliquez les contrôles appropriés.

Mais je ne présenterais pas WebADM comme “ notre version de l'accès conditionnel Microsoft ”. Ce n'est pas la partie intéressante.

La question intéressante est la suivante : À quoi ressemble votre infrastructure réelle ?

De nombreuses entreprises ne vivent pas entièrement au sein d'un seul écosystème d'identité.

Ils peuvent avoir :

• Active Directory
• LDAP
• RAYON
• VPN
• Pare-feux
• Windows
• Linux
• Applications SAML
• Applications OpenID Connect
• Systèmes sur site
• Services cloud
• Les applications héritées qui continuent de fonctionner parfaitement bien

Les politiques du client WebADM peuvent mettre en correspondance les intégrations à l'aide de mécanismes tels que les identifiants client RCDevs, les identifiants NAS RADIUS et les adresses IP. RCDevs prend également en charge les intégrations SAML et OpenID Connect via son fournisseur d'identité.

Ainsi, plutôt que de forcer votre architecture de politique d'accès à suivre un écosystème cloud particulier, WebADM et OpenOTP peuvent s'intégrer à l'infrastructure mixte que de nombreuses organisations exploitent déjà.

C'est une distinction importante.

Votre infrastructure n'a pas besoin de devenir l'idée qu'un autre se fait d'une infrastructure pour que vous puissiez y appliquer une authentification contextuelle.

Élaborez des politiques adaptées au mode de fonctionnement réel de votre entreprise

Au lieu de commencer un déploiement OpenOTP en demandant : “Où devons-nous activer l'authentification multifacteur (MFA) ?”

Essayez de demander : “Quel niveau d'authentification nous faut-il réellement selon chaque condition ?”

Vous pourriez vous retrouver avec quelque chose comme :

Il n'y a pas de tableau universel qui fonctionne pour chaque organisation. Et c'est précisément le but.

Vos règles. Votre politique.

Chaque entreprise a déjà des règles d'accès.

Le problème, c'est qu'ils sont souvent disséminés dans des groupes Active Directory, des configurations VPN, des règles de pare-feu, des paramètres MFA, des systèmes d'accès physique, des autorisations d'applications, des feuilles de calcul, des procédures internes et des instructions qui se terminent par : “Si cela se produit, appelle Mike.“

Le modèle de politique de WebADM vous offre un moyen d'exprimer davantage de ces règles concernant l'authentification elle-même.

• Qui demande l'accès ?
• Dans quel groupe sont-ils ?
• À quoi accèdent-ils ?
• Où sont-ils ?
• La confiance est-elle déjà établie ?
• La situation est-elle devenue plus risquée ?
• Ont-ils badgé ?
• Est-ce que quelqu'un doit valider cela ?
• Doivent-ils d'abord signer un document ?

Et puis OpenOTP peut s'adapter.

• Normal ? Appliquer la politique normale.
• De confiance ? Réduisez les frictions inutiles.
• Risque accru ? Faites un pas en avant.
• Besoin d'une autorisation ? Demander l'approbation.
• Risque inacceptable ? Refuser.

L'objectif n'est pas d'ajouter davantage messages de sécurité aux yeux des utilisateurs. Cela permet de prendre de meilleures décisions en matière d'accès.

• Quand tout semble normal, Utilisez la politique normale.
• Lorsque la confiance est déjà établie, ne pas gêner l'utilisateur.
• Lorsque le contexte change, adapter.
• Lorsque le risque augmente, renforcer la sécurité.
• Lorsqu'une validation humaine s'avère justifiée, Demandez-le.
• Et lorsque le risque est inacceptable, dites simplement Non.

C'est précisément le rôle des politiques d'accès détaillées.

Votre entreprise dispose déjà de ses propres utilisateurs, groupes, applications, réseaux, flux de travail, contrôles d’accès physiques, exceptions et exigences de sécurité. Votre solution de cybersécurité ne devrait pas vous obliger à réorganiser tout cela autour d’un modèle prédéfini.

Il doit s'adapter au fonctionnement réel de votre entreprise.

Avec les politiques WebADM et OpenOTP, vous définissez les règles. OpenOTP applique les exigences d'authentification appropriées en fonction du contexte.

Le résultat n'est pas plus d'authentification. C'est la bonne authentification, au bon moment, pour le bon accès.

Et pour l'utilisateur ? Dans l'idéal, il ne se rend même pas compte de tout ce qui se passe en coulisses.

Votre entreprise. Vos règles. Une cybersécurité qui s'adapte.