Authentification unique (SSO) pour Amazon Web Services (AWS)

Si votre organisation utilise Amazon Web Services (AWS), vous vous demandez peut-être comment sécuriser au mieux l'accès. Voici un bref aperçu des options disponibles, ainsi qu’un éclairage sur les cas où UserLock SSO pour AWS est particulièrement adapté.

Lorsque le SSO a fait son apparition dans les années 1990, il était surtout perçu comme un moyen de simplifier la vie des employés des grandes entreprises en leur permettant d’accéder à plusieurs applications avec un seul identifiant. Cet aspect reste central aujourd’hui.

Mais deux autres avantages du SSO, moins évidents à l'époque, deviennent de plus en plus cruciaux : la sécurité de l’authentification et le suivi des utilisateurs.

Le moteur de ces trois aspects est l’explosion du nombre d’applications, bien au-delà de ce que les inventeurs du SSO avaient imaginé. Plus il y a d’applications, plus elles sont difficiles à gérer — et donc moins sécurisées.

Gérer plusieurs identifiants complique la surveillance par l’IT et pousse les employés vers des pratiques risquées.

Le SSO résout cela en centralisant les identifiants, mais cela n’a de valeur que si cet identifiant unique est solide et sécurisé — il devient en effet un point unique de vulnérabilité.

Bien sûr, la sécurisation de l’identifiant unique est essentielle. Mais avant d’y venir, revenons à la base : comprenons-nous bien le problème fondamental que le SSO tente de résoudre ? Fondamentalement, le SSO répond aujourd’hui à la nécessité de gérer en toute sécurité la complexité déroutante de la distribution moderne d’applications.

Nous avons trop d’applications, dans trop d’environnements, avec trop d’identifiants séparés.

Le premier niveau concerne les applications traditionnelles, locales ou héritées, utilisées depuis des années et authentifiées via un annuaire comme Microsoft Active Directory (AD). Naturellement, les utilisateurs doivent d’abord saisir leurs identifiants AD pour se connecter à leur poste avant d’accéder aux applications AD ou à d’autres applications SaaS Cloud via un navigateur.

Viennent ensuite les services cloud SaaS autonomes sur lesquels les organisations s’appuient, tels que Salesforce ou Slack. Les intégrer est déjà une tâche conséquente, sans même parler de la croissance massive des plateformes cloud ces dix dernières années. Chacune peut nécessiter plusieurs identifiants pour accéder aux applications exploitées par le client ainsi qu’aux nombreux services intégrés à la plateforme.

L’exemple le plus connu de ce dernier cas est Amazon Web Services (AWS). Cette vaste plateforme regroupe de nombreux services Amazon, des applications clients et des serveurs virtuels. Anticipant les défis que cela pose, Amazon propose une solution SSO via AWS IAM Identity Center (anciennement AWS SSO jusqu’en 2022). Cela facilite l’attribution des accès SSO aux applications Amazon tout en permettant :

• L’intégration avec une gamme de plateformes cloud tierces via SAML 2.0 (Microsoft 365, Salesforce, Google).

• L’intégration avec plusieurs fournisseurs d’identité (IdP) tiers tels que Okta, OneLogin et Ping Identity.

En théorie, le SSO d’Amazon simplifie les choses. Si votre organisation est orientée cloud et fortement investie chez Amazon, utiliser AWS IAM Identity Center peut parfaitement convenir. Bien sûr, il faut s’assurer que votre IdP est compatible avec AWS. Et selon vos besoins en matière de gestion des identités et des accès (IAM), même les organisations orientées cloud peuvent gagner en flexibilité avec un fournisseur SSO tiers.

Mais qu’en est-il des nombreuses organisations non orientées cloud ? Beaucoup utilisent encore principalement des applications locales authentifiées via AD. Et dans les environnements Active Directory, des solutions comme AWS IAM Identity Center ne sont tout simplement pas adaptées.

Vos utilisateurs ont toujours besoin de deux jeux d’identifiants : leurs identifiants Amazon AWS et leurs identifiants AD. Nous appelons cela du "pseudo-SSO", car il nécessite toujours deux ensembles d’identifiants. Il n’y a rien de “single” (unique) dans ce “sign-on” !

La façon la plus simple d’accommoder une infrastructure AD locale avec AWS est d’utiliser une solution SSO locale dédiée telle que UserLock. Avec UserLock, vos utilisateurs n’ont besoin que d’un seul jeu d’identifiants — leurs identifiants Active Directory — pour accéder à AWS et aux applications prises en charge par AWS.

Vous remarquerez que la majorité des discussions autour du SSO se concentrent sur la commodité : éviter la gestion de multiples identifiants pour différentes plateformes.

Cela minimise l’enjeu de la sécurité. Comme mentionné précédemment, la sécurité est un enjeu de plus en plus critique dans la mise en œuvre du SSO.

D’une certaine manière, configurer un SSO est la partie facile. Le vrai défi est toujours de le mettre en œuvre de manière sécurisée.

Utiliser AWS IAM Identity Center ou un SSO tiers basé sur un IdP suppose que vous :

• Faites confiance aux contrôles de sécurité de ces plateformes, et

• Ayez les compétences — ou embauchiez quelqu’un qui les possède — pour les configurer correctement.

Comme toutes les plateformes cloud, Amazon AWS fonctionne selon un modèle de sécurité partagé. Le fournisseur est responsable de la sécurité de l’infrastructure, mais vous, en tant que client, êtes responsable de la sécurisation de vos ressources et données.

Du point de vue d’un responsable IT, utiliser AWS IAM Identity Center revient donc à ajouter un système supplémentaire à gérer. Cela ouvre la porte à :

• Des mauvaises configurations (droits d’accès excessifs),

• Une gestion inefficace (nettoyage des comptes utilisateur négligé).

Les mêmes problèmes apparaissent avec les IdP externes, auxquels s’ajoutent des inconvénients comme :

• Le risque d’enfermement fournisseur,

• Des coûts de fonctionnement plus élevés,

• L’incompatibilité potentielle avec certaines applications.

Les limites de sécurité sont inhérentes au SSO. Tout système qui accorde l’accès à plusieurs services via un seul identifiant devient un point faible s’il est mal configuré ou compromis. C’est pourquoi les identifiants sont devenus une cible majeure des attaquants, qui savent que compromettre un seul compte avec les bons droits peut suffire à pénétrer tout un système.

Si votre organisation doit répondre à des exigences strictes en matière de conformité ou de réglementation (ou souhaite tout simplement être sécurisée), faire confiance à un IdP pour le SSO n’est pas une option envisageable.

Protéger vos applications critiques locales exige une certitude et une visibilité absolues. UserLock est l’une des rares solutions à offrir un SSO sécurisé sur site pour les organisations qui doivent s’assurer que l’authentification reste localisée dans Active Directory.

En mettant en œuvre le SSO de cette manière, vous pouvez mieux :

• Garantir un contrôle interne total sur les utilisateurs et les applications,

• Valoriser l’investissement existant de votre organisation dans Windows AD sans le coût et le temps associés à la migration des utilisateurs vers une nouvelle plateforme SSO,

• Mettre en place un SSO avec Amazon AWS ainsi qu’une large gamme d’applications cloud basées sur SAML,

• Configurer le SSO avec des contrôles de sécurité avancés tels que l’authentification multifacteur (MFA) et des restrictions d’accès en fonction du type de session ou de facteurs contextuels.

La première étape pour connecter UserLock SSO à Amazon AWS SSO consiste à activer UserLock en tant que fournisseur d’identité externe via la console AWS. Une fois cette étape terminée, l’accès à AWS est attribué à chaque utilisateur autorisé.

Dans la console UserLock, sélectionnez AWS comme plateforme à configurer en accédant au menu de configuration SSO. Le certificat AWS SSO et les métadonnées d’URL pointant vers AWS sont ajoutés à UserLock. N’oubliez pas de vérifier que le certificat SAML établissant la confiance avec AWS est bien à jour.

Pour un aperçu plus détaillé, consultez notre documentation sur la configuration de UserLock SSO pour AWS.

Une fois que vous avez configuré UserLock SSO pour l’accès à AWS, vous pouvez aller encore plus loin. Amazon AWS propose un vaste catalogue d’applications SaaS disponibles via AWS SSO.

UserLock SSO s’intègre en arrière-plan avec AWS SSO, ce qui permet à vos utilisateurs d’accéder à toute application SaaS configurée dans AWS.

Découvrez comment configurer UserLock avec AWS SSO.

UserLock SSO offre plusieurs avantages, à la fois pour les utilisateurs finaux et pour les administrateurs.

Les utilisateurs bénéficient de la simplicité du SSO. Lorsqu’ils sont connectés à un poste membre du domaine, ils peuvent accéder à l’application SaaS sans avoir à ressaisir leurs identifiants. Ils utilisent le même jeton d’authentification que dans Active Directory.

Cela améliore clairement l’expérience utilisateur et réduit la prolifération des mots de passe. Au lieu de devoir gérer un identifiant Amazon séparé, les utilisateurs accèdent à la plateforme AWS et aux applications compatibles AWS avec leur identifiant AD habituel.

Et comme cela se fait sans mots de passe supplémentaires à mémoriser ou écrans de connexion à gérer, cela ne nuit ni à la productivité, ni à la fluidité. La complexité reste invisible pour l’utilisateur.

Les équipes IT peuvent gérer l’identité des utilisateurs via AD, comme elles le font déjà, et provisionner les accès à Amazon AWS et à d’autres applications cloud via la console UserLock.

Surtout, les mêmes contrôles de sécurité familiers s’appliquent. Comme pour d’autres types d’accès, cela inclut la MFA (applications d’authentification, notifications push ou tokens physiques), qui peut être personnalisée selon le type de connexion ou les conditions de connexion.

Les administrateurs peuvent voir comment la MFA est appliquée, suivre facilement les tentatives d’authentification échouées (pouvant indiquer une tentative d’intrusion) et, si nécessaire, désactiver la MFA pour certains comptes.

Le grand avantage de UserLock, c’est que vous pouvez appliquer les mêmes contrôles d’accès et la même MFA à travers RDP, VPN, IIS et les sessions SaaS. Toute organisation qui souhaite gérer les restrictions d’accès depuis une seule solution y trouvera un réel bénéfice, notamment celles qui :

• Sont fortement investies dans un environnement sur site, mais souhaitent activer un accès hybride vers Amazon AWS et d’autres plateformes cloud via SSO,

• Évoluent dans des environnements fortement réglementés où l’audit détaillé est essentiel et où faire confiance à un fournisseur cloud pour la gestion des identités n’est pas envisageable,

• Souhaitent renforcer la sécurité du SSO avec des options comme la MFA granulaire, des restrictions sur les sessions concurrentes, et d’autres contrôles de surveillance non proposés par AWS IAM Identity Center.