Single Sign On : Questions à poser

Grand-père a toujours dit : « N'essaie jamais rien de nouveau. Attends de voir si cela tue quelqu'un d'abord ». Récemment, j'ai été impliqué dans la réalisation de plusieurs projets de Single Sign On, et ses mots n'ont cessé de résonner dans mon esprit. Une partie de moi dit : « C'est une mauvaise idée d'avoir juste un nom d'utilisateur et un mot de passe pour accéder à tout ». Si une attaque de pirate survient, l'intrus s'empare de leurs affaires, il a accès à tout. Mais l'autre partie regarde cela et dit : « Les utilisateurs vont adorer ça ». C'est une situation classique où l'on est stupide si l'on fait, et stupide si l'on ne fait pas. Alors, que faites-vous ?

Qu'est-ce que le Single Sign On ?

Lorsque vous examinez pour la première fois le Single Sign On (SSO) du point de vue de quelqu'un qui est au fait de la sécurité, mais qui ne comprend pas les détails, le SSO ressemble à un suicide au niveau de l'entreprise. Le nom même, Single Sign-On évoque l'image de l'utilisation d'un seul ensemble d'identifiants pour tout, mais en réalité, il est conçu pour faciliter la vie de vos utilisateurs, sans compromettre la sécurité. Ce que vous faites, c'est tirer parti de quelque chose appelé SAML (Security Assertion Markup Language, et pas moins). Il s'agit d'un format de données open source basé sur XML qui nous permet d'échanger des données d'authentification et d'autorisation entre différentes applications ou parties. En fait, cela renforce un peu les choses en ajoutant une autre couche pour ainsi dire en exploitant les informations des utilisateurs AD ou LDAP.

Nous avons donc renforcé la sécurité en liant la manière dont elles affectent les droits déjà accordés dans AD. Dans la plupart des cas, s'il y a un nom d'utilisateur/mot de passe séparé associé à une application, il est saisi une fois, et l'application SSO nous donne accès. Cela semble un peu effrayant, mais gardez à l'esprit que les verrouillages typiques d'AD fonctionnent toujours, et nous avons l'avantage supplémentaire que si le compte est compromis, la plupart des logiciels SSO sont dotés de fonctionnalités de reporting vraiment puissantes. Ainsi, nous pouvons détecter les comptes compromis et les données auxquelles il a été accédé.

Questions à poser avant de s'engager dans le Single Sign On

Je vais jouer mon propre avocat du diable ici et poser la question qui est dans tous les esprits. À quel point est-ce vraiment sécurisé ?

Eh bien, comme le Diable, je vais vous faire patienter pour la réponse et dire que nous examinerons cela dans les semaines à venir. Pour l'instant, supposons que vous souhaitiez mettre en place une authentification unique au sein de votre organisation. Si vous voulez du SSO dans votre organisation, voici quelques éléments à prendre en compte.

En premier sur la liste, parlons-nous de quelque chose de nouveau ou d'une mise à niveau ? Souvent, il s'agit d'un nouveau produit SSO qui remplace un ancien. À ce moment-là, vous devez commencer à penser à la formation et aux communications. Communications – pour que les utilisateurs soient au courant de ce qui se passe, formation (même s'il s'agit juste d'une vidéo en ligne) – sur la manière d'utiliser le nouveau produit.

Que cherchons-nous à faire avec cela ? Cherchons-nous à centraliser l'accès ? À améliorer la sécurité en améliorant l'autorisation ? Ou peut-être juste de l'audit pur et simple ? Peut-être que nous essayons d'atteindre ces trois objectifs. En fin de compte, cela aide certainement à réaliser un projet réussi lorsque l'on sait à quoi s'attendre à la fin de tout cela.

Décider quelles applications nous voulons rendre accessibles dès le début est très important. La plupart des applications fonctionneront bien avec un SSO, mais d'autres non. Les « autres » pourraient vraiment vous compliquer la vie, et nécessiter l'intervention de tiers et plus d'un peu de créativité pour fonctionner. Alors attendez-vous à cela.

Qui va s'en occuper ? Quelqu'un doit être responsable du système, et cela peut impliquer plusieurs personnes à différents niveaux de l'entreprise pour le gérer. Par exemple, dans un récent projet SSO, j'étais responsable de la mise en place sur les serveurs, de l'aide à la gestion du projet et de l'initialisation des applications et de l'enregistrement des utilisateurs. Mais il a été déterminé dès le début que, à l'avenir, les nouveaux utilisateurs seraient ajoutés par le personnel de niveau 1. Nous avons donc dû les former jusqu'à ce point. Cependant, les applications, ainsi que l'entretien et la gestion des serveurs (sans parler des futures mises à niveau et de la DR) reposeraient fermement entre mes mains.

Probablement l'élément le plus important auquel nous devons faire attention est de savoir si le SSO que nous achetons continue de se développer et d'évoluer à mesure que l'entreprise grandit et évolue.

Et comme on le disait dans les années 60, ne touchez pas au cadran.