S

Surmonter le risque de sécurité de l'authentification unique Active Directory

Travailler dans l'informatique est une bataille constante pour trouver l'équilibre parfait entre sécurité et productivité. Ce n'est pas mieux personnifié que dans le besoin pour les utilisateurs Active Directory (AD) d'accéder à plusieurs systèmes grâce à l'utilisation de plates-formes d’authentification unique (SSO).

Les solutions SSO éliminent le besoin pour les utilisateurs de se souvenir d'un mot de passe unique et complexe pour chaque application et plate-forme auxquelles ils accèdent, en le remplaçant par une seule connexion facilitant l'accès à plusieurs systèmes et applications.

Pour les organisations, l’authentification unique est en grande partie un jeu de productivité.

Offrant des temps d'accès plus rapides aux applications, avec des exigences de mot de passe réduites (généralement une), cette technologie simplifie les frais généraux et de support, tout en étant une technologie non perturbatrice avec un taux d'adoption élevé.

Elle présente également certains avantages en termes de sécurité: comme l'authentification unique n'utilise qu'un seul identifiant, cela revient souvent à exiger un mot de passe unique très complexe. De plus, le fait de désactiver l'accès à l'échelle de l'entreprise devient aussi simple que de désactiver le compte initial.

Mais, comme avec toute technologie conçue pour améliorer la productivité, il y a souvent des pertes sur le plan de la sécurité. Et dans le cas du SSO, il existe des risques de sécurité implicites.

Quels sont les risques de sécurité de l’authentification unique?

En général, SSO est plus soucieux de fournir un accès que de le restreindre. Et, à une époque où les attaques basées sur des logiciels malveillants sont répandues, ce n'est pas le moment idéal pour tout donner. Malgré les avantages mentionnés précédemment, il existe un certain nombre de risques liés à l'utilisation de l’authentification unique:

  1. Accès instantané à bien plus que simplement le point de terminaison – les identifiants de connexions constituent un objectif majeur pour les attaquants externes (81% des violations de données impliquent un abus d'informations d'identification ). Lorsque l'authentification unique est en place, une fois qu'un utilisateur malveillant a un accès initial à un compte SSO authentifié, il a automatiquement accès à toutes les applications, systèmes, ensembles de données et environnements liés à ce compte. La plupart des environnements SSO exploitent un portail quelconque qui facilite l'accès sans nécessiter de mots de passe supplémentaires. Bien que ce soit génial pour les utilisateurs, c'est terrible pour la sécurité!

    Les attaques externes utilisant un logiciel malveillant pour prendre le contrôle d'un point de terminaison auraient un accès post-connexion à tout ce qui est connecté via SSO immédiatement après l'infection, augmentant ainsi l'empreinte d'un attaquant au sein de l'organisation.

  2. Contrôle moins parfait sur l'accès une fois accordé – Supposons qu'un utilisateur se soit connecté avec succès via SSO et ait accès à des applications externes supplémentaires dans le cloud. Ensuite, l'utilisateur tombe en proie à une attaque de phishing, donnant à un attaquant un accès au point de terminaison.

    S'il est détecté, le compte peut certainement être désactivé, mais étant donné le fonctionnement de Windows, l'utilisateur reste connecté et, selon la solution SSO et le modèle de sécurité de l'application liée, l'attaquant peut rester connecté avec un accès à une application donnée.

  3. Confiance excessive dans la double authentificationLa double authentification (2FA) exploite un mécanisme d'authentification externe (en plus d'un mot de passe) pour prouver que l'utilisateur est bien qui il prétend être. Cependant, les solutions 2FA ne sont pas largement adoptées (page en anglais) et très probablement parce qu'elles entravent les utilisateurs finaux avec des étapes de sécurité supplémentaires qui s'avèrent coûteuses, complexes et longues à mettre en place et à gérer pour le service informatique.

    Les environnements SSO les plus forts reposent sur la biométrie - coûteuse - qui est la plus difficile à simuler, mais beaucoup reposent sur un facteur externe pratique: SMS et leur téléphone portable - ou simplement le mot de passe AD en tant que protection unique.

    Le problème est que le SMS a été au centre de beaucoup de piratages à deux facteurs. Cela a conduit l'Institut national des normes et de la technologie à retirer son soutien aux deux facteurs basés sur le SMS.

    Et pour les organisations qui dépendent uniquement du mot de passe d'ouverture de session AD, il suffit qu'une seule instance de comportement inapproprié pour mener à une violation grave, par exemple, un employé partageant un mot de passe, laissant un poste de travail déverrouillé ou un utilisateur malveillant volant les identifiants d’un collègue.

  4. Peu ou pas d'adhésion au principe du privilège minimumLe principe du privilège minimum impose aux utilisateurs d'avoir accès aux données, applications et systèmes minimums nécessaires pour faire leur travail, et nécessite généralement des informations d'identification distinctes pour un accès élevé.

    Parce que SSO consiste à vous donner accès avec une authentification unique, cela va à l'encontre de l'idée d'exiger que l'utilisateur s'authentifie chaque fois qu'il doit accéder à quelque chose de nouveau.

Même avec des risques, les organisations aiment le bénéfice de l'amélioration de la productivité et la réduction des coûts de support. Alors, comment pouvez-vous faciliter l'accès simplifié de SSO tout en maintenant une posture de sécurité solide?

Réduire le risque de l’authentification unique active directory

Étonnamment, la réponse ne réside pas dans la suppression de SSO. Au contraire, il s'agit de combler les lacunes en matière de sécurité en prenant quelques mesures supplémentaires d'une manière aussi peu perturbatrice que possible.

Étape 1: Sécuriser la connexion à Active Directory avec la gestion des connexions

La plupart des solutions SSO utilisent Active Directory comme connexion initiale. Donc, c'est le point le plus pertinent pour mettre des contrôles de sécurité - après tout, si vous ne pouvez pas vous connecter à AD, vous n'avez accès à rien via SSO. Une solution de gestion des connexions place quelques contrôles de sécurité autour de la connexion Windows initiale:

  • Il limite quand et à partir de quel(s) point(s) de terminaison ou adresses IP un compte d'utilisateur particulier peut se connecter
  • Il limite la fréquence d'ouverture de session et les connexions simultanées
  • Il restreint en fonction du type de session (local, RDP, etc.)
  • Il surveille les connexions à la recherche d'activités inhabituelles, telles que la tentative d'ouverture de session après les heures de travail ou à partir d'un point de terminaison inhabituel
  • Il peut nécessiter des approbations d'un autre utilisateur - normalement un gestionnaire ou un informaticien
  • Il peut forcer une fermeture de session complète à partir d'une session Windows en fonction des heures autorisées ou en réponse à la directive informatique

C'est cette dernière partie (soutenue par toutes les autres capacités de la gestion des connexions) qui remplit l'un des trous de la SSO - arrêter l'accès via SSO n'est efficace que si vous arrêtez également l'accès à toutes les applications externes. Avec une capacité à fermer toute la session Windows, vous savez que chaque ensemble de données, système et application accessible est également sécurisé.

Habituellement exécuté en tant que partie intégrante du processus de connexion, la gestion des connexions est une technologie non perturbatrice qui s'harmonise avec l'état d'esprit axé sur la productivité de ceux qui implémentent l'authentification unique.

Étape 2: Améliorer une posture de privilège minimum avec la Gestion des Sessions Privilégiées

SSO souhaite donner aux utilisateurs l'accès à des applications supplémentaires sans nécessiter de connexion. Mais une bonne pratique du privilège minimum dicte qu'un accès élevé nécessite une authentification supplémentaire. Un bon moyen pourrait être l'utilisation de Gestion des Sessions privilégiées (GSP).

GSP est une sorte de proxy entre l'utilisateur et le système ou l'application avec un accès élevé. Les utilisateurs de bas niveau peuvent demander un accès (au moyen d'un portail) avec un accès accordé sans fournir le mot de passe à l'utilisateur. Maintenant, on dirait que ce n'est pas différent de SSO, et à certains égards, c'est vrai.

Ce que la GSP ajouterait à la combinaison, ce sont ses contrôles axés sur les politiques qui mettent en place quelques contrôles supplémentaires:

  • Il peut définir quels utilisateurs peuvent accéder à quels systèmes, quand, d'où, etc.
  • Il peut nécessiter des approbations d'un pair ou d'un responsable avant d'autoriser l'accès
  • Il peut informer le département informatique de l'accès accordé
  • Il peut enregistrer la session pour créer une piste d'audit d'activité

L'ajout de GSP crée un résultat final similaire à SSO, avec un niveau comparable de «non-perturbation» mais avec l'ajout de plusieurs couches de contrôles de sécurité en place.

Étape 3: Utiliser l'authentification unique pilotée par la stratégie de sécurité

SSO a sa place dans n'importe quelle organisation et, dans le cas d'organisations avec de nombreuses applications basées sur le cloud, vous pouvez utiliser AD comme système d'enregistrement pour tous les accès externes. En disposant de contrôles AD solides (tels que la gestion des connexions et GSP), vous créez une base sécurisée pour SSO. Mais vous ne pouvez pas vous arrêter là.

Voici quelques suggestions de contrôles de sécurité SSO à mettre en place:

  • Garantir le privilège minimum SSO – pensez à l'accès que SSO devrait fournir en utilisant l'objectif de privilège minimum. Définissez des rôles pour chaque type d'utilisateur dans l'organisation, en identifiant les applications spécifiques dont ils ont besoin pour effectuer leur travail, en limitant l'accès aux seules tâches informatiques jugées absolument nécessaires.

  • Exiger l'authentification multifacteur – demander plus d'un facteur supplémentaire améliore considérablement la sécurité.

  • Utiliser les protocoles d'authentification modernes – Assurez-vous que votre solution SSO exploite OpenId Connect ou OAuth 2.0.

  • Limiter l'accès au périphérique – Définissez des restrictions sur les périphériques avec lesquels un utilisateur peut tirer parti de l'authentification unique.

  • Appliquer les changements fréquents de mot de passe – pour les comptes avec un accès élevé, envisagez d'exiger de nouveaux mots de passe plus souvent.

Obtenir une sécurité et une productivité élevées avec les connexions active directory et l’authentification unique

Pour un utilisateur, SSO est un cadeau de dieu; être capable d'accéder à tout sans connexion supplémentaire? Je signe! Mais, avec les gains supplémentaires de productivité vient l'augmentation égale des préoccupations de sécurité. Une fois passé le SSO, les vannes d'accès sont grandes ouvertes, faisant de la connexion un point d'inflexion critique pour la sécurité de l'organisation.

En tirant parti des solutions qui répondent aux lacunes de sécurité introduites par l'authentification unique, les entreprises réduisent le risque associé à l'authentification unique. La mise en œuvre de SSO avec la politique de sécurité à l'esprit peut améliorer la propre position de sécurité de SSO. GSP répond aux préoccupations concernant l'accès aux comptes privilégiés. Et, la gestion des connexions met une sécurité appropriée autour du fondement même de SSO - la connexion AD.

Le risque dans SSO existe uniquement si vous voyez SSO comme un moyen de gagner de l’accès. Mais en reconnaissant les lacunes de sécurité inhérentes qui existent et en compensant par la mise en œuvre de contrôles supplémentaires sous la forme de Gestion des Connexions et Gestion des Sessions Privilégiées, vous réduisez efficacement le risque SSO, ce qui en fait une source de productivité et de sécurité élevée.

1 Verizon, Data Breach Investigations Report (2017)