Bien que les entreprises adoptent les applications cloud pour le confort et l’efficacité qu’elles offrent, elles augmentent également leur risque. Les applications et données sensibles sont, par défaut, protégées par des mots de passe faibles et statiques. La visibilité quant aux personnes accédant aux ressources, aux ressources consultées, aux heures d’accès et à la manière dont l’identité est vérifiée devient difficile à atteindre, ce qui entrave la conformité. Les administrateurs informatiques nécessitent plusieurs consoles différentes pour gérer les identités cloud. Quant à la personne la plus importante du processus, l’utilisateur, elle est chargée de conserver un grand nombre de noms d’utilisateur et de mots de passe.
Identity and access management key concepts, technologies and standards compiled for you in this Access Management ebook . You will learn: • Authentication and access management differences • How to leverage cloud single sign on (SSO) • Key concepts in Access...
La gestion des identités et des accès (IAM) est une sous-discipline de la sécurité des données qui comprend deux ensembles de fonctionnalités : la gouvernance et l’administration des identités (IGA) et la gestion des accès (AM).
Les solutions de gestion des identités et des accès fournissent un cadre méthodique pour l’octroi et les demandes d’accès aux applications (IGA), mettant en application les contrôles d’accès (AM) et garantissant une visibilité en ce qui concerne les événements d’accès (AM).
Les solutions de gouvernance et d’administration des identités aident à répondre aux questions « Qui doit obtenir un accès ou qui mérite un accès, à quelle application ? » et « Qui, en pratique, a obtenu un accès à quelle application, par qui et quand ? » Les solutions de gestion des accès aident à répondre aux questions « Qui a accès à quoi et quand, et comment l’identité a-t-elle été vérifiée ? »
Une solution de gestion des identités et des accès se compose d’une fonctionnalité de gouvernance et d’administration des identités (IGA) et d’une fonctionnalité de gestion des accès (AM). Les solutions de gestion des identités et des accès fournissent un cadre méthodique pour l’octroi et les demandes d’accès aux applications (IGA), mettant en application les contrôles d’accès (AM) et garantissant une visibilité en ce qui concerne les événements d’accès (AM). Étant donné que la plupart des organisations déploient ces deux composants séparément, ces disciplines sont de plus en plus évaluées en tant que familles de solutions distinctes et autonomes plutôt qu’en tant que fonctionnalités composites d’une seule suite de gestion des identités et des accès (IAM).
La gestion des accès est une fonctionnalité qui permet de déterminer si un utilisateur est autorisé à accéder à une certaine ressource et qui facilite la mise en application de la politique d’accès configurée pour cette ressource.
La gestion des accès est mise en place en fonction des politiques d’accès définies par les administrateurs informatiques et comprend des informations telles que les groupes d’utilisateurs (p. ex., équipe commerciale, recherche et développement, RH) autorisés à accéder aux applications cloud, les applications cloud dont l’accès est autorisé (p. ex., Salesforce, Office 365, Jira, Taleo), ainsi que l’ensemble d’attributs utilisateur requis pour l’accès à chaque application (p. ex., réseau de confiance, mot de passe, OTP).
En fonction de la sensibilité d’une application cloud, le nombre d’attributs utilisateur dont la politique d’accès exige l’évaluation peut varier. Ces attributs sont évalués à l’aide de l’authentification basée sur les risques ou contextuelle, qui est essentielle pour la mise en application de différentes politiques d’accès définies pour chaque application cloud. Pour en savoir plus, se référer à la section sur l’authentification contextuelle.
Autre élément essentiel à la gestion des accès au cloud, l’authentification unique, qui permet l’utilisation d’une paire nom d’utilisateur/mot de passe, ou identité, unique pour se connecter à toutes les applications cloud d’un utilisateur. Pour en savoir plus, se référer à la section sur l’authentification unique.
L’IDaaS, ou l’IAM en tant que service, est également connue sous le nom d’identité en tant que service. L’IDaaS décrit les solutions de gestion des identités et des accès (IAM) qui offrent un modèle de fourniture en tant que service basé sur le cloud pour la gestion des identités et des accès. Alors que l’IDaaS a été revue en tant que marché distinct ces dernières années, étant donné les dernières tendances du marché, elle sera désormais traitée comme deux disciplines différentes, celle de la gestion des accès et celle de la gouvernance et de l’administration des identités, dont les méthodes de fourniture incluent des installations sur site ou des plateformes logicielles ou cloud.
La gouvernance et l’administration des identités est un ensemble de fonctionnalités qui aide à répondre aux questions « Qui doit obtenir un accès ou qui mérite un accès, à quelle application ? » et « Qui, en pratique, a obtenu un accès à quelle application, par qui et quand ? » Par exemple, une solution de gouvernance et d’administration des identités peut aider à établir un accès autorisé pour l’équipe de recherche et développement à certaines applications de développement, comme GitHub, Jira et Confluence. Une solution de gouvernance et d’administration des identités peut fournir un accès automatique à ces applications, en fonction de l’appartenance au groupe Recherche et développement. L’utilisateur du groupe Recherche et développement peut également demander à obtenir un accès à d’autres applications, une demande qui est ensuite soumise à un processus d’approbation pris en charge par certaines solutions de gouvernance et d’administration des identités.
La fédération des identités est une architecture basée sur un seul fournisseur d’identité approuvé (IdP) qui gouverne l’authentification des utilisateurs, avec les applications qui relaient le processus d’authentification au fournisseur d’identité à chaque fois qu’un utilisateur essaie d’y accéder. Les applications qui relaient le processus d’authentification au fournisseur d’identité approuvé sont appelées fournisseurs de service (SP).
La fédération des identités résout les défis et les frustrations associés à la gestion des identifiants pour de nombreuses applications Web séparément, que ce soit à l’intérieur ou à l’extérieur d’une organisation, et permet aux administrateurs et aux utilisateurs de conserver une seule paire nom d’utilisateur/mot de passe, ou identité, pour plusieurs applications et ressources informatiques. La fédération des identités élimine la lassitude liée aux mots de passe, améliore la sécurité et résout le problème de la gestion d’une multitude de mots de passe.
Elle repose sur des protocoles de fédération comme SAML et Open ID Connect, ainsi que sur des protocoles propriétaires comme WS-Federation de Microsoft.
La connexion fédérée est une fonction des protocoles de fédération (p. ex., SAML, Open ID Connect, etc.) permettant aux utilisateurs de se connecter à plusieurs applications à l’aide de leur identité d’entreprise actuelle. Par exemple, au lieu de se connecter à différentes applications cloud avec différentes identités, ou combinaisons nom d’utilisateur/mot de passe, la connexion fédérée laisse les utilisateurs se connecter à Office 365, Salesforce, AWS etc. avec la même identité qu’ils utilisent pour se connecter au réseau de l’entreprise le matin, ou au VPN le soir.
Un fournisseur d’identité est un système qui authentifie les utilisateurs essayant d’accéder à d’autres sites Web non affiliés (fournisseurs de services). Les fournisseurs d’identité, avec les fournisseurs de services, se composent d’une architecture de fédération des identités, dans laquelle les utilisateurs qui essaient d’accéder à un site Web (ou fournisseur de services) sont relayés au fournisseur d’identité pour l’authentification. Le fournisseur d’identité vérifie les données d’authentification de l’utilisateur (p. ex., cookie de l’utilisateur, appareil, réseau, OTP) et produit une réponse de type « acceptation » ou « refus », qui est ensuite envoyée au fournisseur de services. Les fournisseurs d’identité peuvent également demander l’autorisation d’accéder à certaines données au nom d’un autre site Web non affilié. Les données d’autorisation peuvent inclure la permission d’accéder à des informations telles que les adresses e-mail d’un compte de messagerie Web ou les noms des amis d’un compte de réseau social.
Par exemple, SafeNet Authentication Service agit en tant que fournisseur d’identité lorsque l’utilisateur accède aux applications cloud comme dans le cas de figure décrit ci-dessus.
Un service d’émission de token de sécurité est un système qui authentifie les utilisateurs essayant d’accéder à d’autres sites Web non affiliés, ou « parties de confiance ». Les services d’émission de token de sécurité, avec les parties de confiance, se composent d’une architecture de service d’émission de token de sécurité, dans laquelle les utilisateurs qui essaient d’accéder à un site Web (partie de confiance) sont relayés au service d’émission de token de sécurité pour l’authentification.
Les services d’émission de token de sécurité sont également appelés modèles de fournisseur d’identité ou authentification basée sur des tokens. Un service d’émission de token de sécurité est l’équivalent d’un fournisseur d’identité, et une partie de confiance équivaut à un fournisseur de services. Et, au lieu d’échanger des assertions SAML, il s’agit de tokens de sécurité. Différentes appellations, pour le même concept.
Le langage SAML (Security Assertion Markup Language), prononcé « sammel », est un standard XML libre pour l’échange de données d’authentification entre les sites Web non affiliés, une capacité également appelée fédération des identités ou authentification fédérée.
La fédération des identités signifie la possibilité d’étendre les identités d’entreprise actuelles des utilisateurs au cloud, ce qui leur permet de se connecter à leurs applications cloud avec leur identité d’entreprise actuelle. Grâce à l’authentification fédérée aux applications cloud avec SAML, les utilisateurs peuvent se connecter à toutes leurs applications cloud avec leur identité d’entreprise actuelle, et ainsi, plutôt que de conserver 5 ou 25 combinaisons nom d’utilisateur/mot de passe, ils n’en ont qu’une à conserver.
Fonctionnement de SAML
Lorsqu’un utilisateur essaie de se connecter à une application cloud, il est redirigé vers un fournisseur d’identité pour l’authentification. Le fournisseur d’identité collecte les identifiants de l’utilisateur, par exemple, son nom d’utilisateur et son mot de passe à usage unique, puis renvoie une réponse à l’application cloud dont l’accès est demandé. Cette réponse est une assertion SAML, et l’assertion SAML contient une réponse de type « acceptation » ou « refus ».
En fonction de cette réponse, le fournisseur de services, p. ex. Salesforce, Office 365 ou DropBox, bloque ou autorise l’accès à l’application.
WS-Federation Services, ou WS-Fed, est le protocole de fédération des identités propriétaire de Microsoft. WS-Fed s’associe aux services de fédération Active Directory, ou ADFS, de Microsoft, pour étendre les identités stockées dans Active Directory aux applications cloud Microsoft comme Office 365 et Azure. Tout comme SAML, WS-Fed utilise un modèle de fournisseur d’identité. Lorsqu’il accède à une application cloud Microsoft, l’utilisateur est redirigé vers AD FS pour s’authentifier, et selon sa réponse, l’application cloud octroie ou refuse l’accès à l’utilisateur.
OAuth (qui se prononce « oh-auth »), diminutif de « Open Authorization » en anglais, est un protocole libre pour l’authentification et l’autorisation fédérées et basées sur des tokens entre des sites Web non affiliés. Tout comme avec d’autres protocoles de fédération des identités, comme SAML, Open ID Connect et WS-Fed, OAuth permet la connexion à une application avec une identité vérifiée par un fournisseur d’identité approuvé. OAuth va au-delà de l’authentification fédérée pour que les utilisateurs puissent autoriser les sites Web de confiance à accéder à certaines informations du compte, telles que les noms et les adresses e-mail des contacts. Par exemple, OAuth est le protocole utilisé par les sites de réseaux sociaux pour accéder aux contacts de votre messagerie Web et vous demander si vous souhaitez les inviter à vos réseaux sociaux.
À l’instar de SAML, OpenID Connect est un protocole de fédération des identités libre standard qui utilise un modèle de fournisseur d’identité. Cependant, contrairement à SAML qui utilise un cookie et ne fonctionne donc qu’avec des applications qui s’ouvrent dans un navigateur (« applications Web »), OpenID Connect offre une structure d’authentification unique permettant la mise en place de l’authentification unique sur toutes les applications Web, les applications mobiles natives et les clients pour les ordinateurs de bureau (comme les clients lourds et certains VPN). Alors que la plupart des configurations d’authentification unique ne sont actuellement compatibles qu’avec les applications cloud et Web, l’adoption d’OpenID Connect par un nombre grandissant de fournisseurs d’identité signifie que nous serons en mesure de procéder à une seule authentification pour accéder simultanément à toutes nos ressources : clients pour les ordinateurs de bureau, applications Web ou applications mobiles natives.
Le terme BYOI (Bring Your Own Identity) est utilisé pour décrire la capacité d’une entreprise ou d’une autre organisation à prendre en charge une identité qui a été émise ailleurs et à permettre un accès sécurisé aux ressources avec cette identité.
Dans le secteur de la gestion des identités, les fournisseurs et les organisations cherchent à donner aux employés et aux partenaires la capacité d’utiliser leur propre identité pour accéder aux ressources de l’entreprise. En théorie, il peut s’agir de n’importe quelle identité qui offre un niveau d’assurance suffisant, par exemple, les cartes d’identité émises par un gouvernement, les cartes à puce du secteur de la santé, ainsi que les identités en ligne, comme les identités sociales, les identités de réseau professionnel et les identités disponibles sur le marché, comme FIDO. Les mondes de l’entreprise et du consommateur se rapprochent, les équipes de sécurité d’entreprise étant de plus en plus incitées à mettre en place le même type de méthodes d’authentification généralement employé dans les services destinés aux consommateurs.
Un broker d’identité est un système pouvant être compatible avec les dispositifs BYOI en prenant l’identité existante d’un utilisateur (ou tout nombre d’identités existantes) et en autorisant l’authentification à des sites Web non affiliés avec cette identité. Par exemple, un broker d’identité peut prendre en charge l’identité sociale ou l’identité de messagerie Web d’un utilisateur et autoriser cet utilisateur à accéder à une multitude de sites Web non affiliés. Grâce aux brokers d’identité, les organisations peuvent prendre en charge plusieurs fournisseurs d’identité.
L’authentification unique (SSO) offre la capacité de procéder à une seule authentification afin de pouvoir accéder à différentes ressources en étant automatiquement authentifié. Cette méthode élimine le besoin de se connecter et de s’authentifier à chaque application et système individuellement, servant ainsi d’intermédiaire entre l’utilisateur et les applications auxquelles il souhaite accéder. De leur côté, les applications et systèmes cibles conservent leurs propres magasins d’identifiants et continuent de présenter des invitations d’authentification unique au système de l’utilisateur. La SSO répond à ces invitations et fait correspondre les identifiants à une seule paire ID de connexion/mot de passe. (Source : Gartner)
Que ce soit dans une solution autonome ou une solution de gestion des accès plus étendue, la SSO peut être obtenue grâce à une variété de protocoles de fédération des identités, notamment des protocoles libres comme SAML 2.0 et Open ID Connect, des protocoles propriétaires comme WS-Federation de Microsoft et d’autres technologies comme les coffres-forts de mots de passe et les proxies inverses.
Un coffre-fort de mots de passe, ou gestionnaire de mots de passe, est une méthode simple de création d’une expérience d’authentification unique lorsqu’une application cible n’est pas compatible avec les protocoles de fédération des identités (application héritée ou personnalisée, par exemple). Les coffres-forts de mots de passe sont des systèmes qui fonctionnent en stockant et en chiffrant les mots de passe de différents sites Web. Au lieu de se connecter à chaque application avec un mot de passe dédié, l’utilisateur peut simplement s’authentifier avec un mot de passe principal (qui déchiffre le coffre-fort de mots de passe) sans avoir à conserver plusieurs mots de passe.
L’autorisation est un processus garantissant que les utilisateurs correctement authentifiés ne peuvent accéder qu’aux ressources pour lesquelles l’accès est autorisé, comme défini par le propriétaire ou l’administrateur de cette ressource. Dans le monde des consommateurs, l’autorisation peut également faire référence au processus par lequel un utilisateur garantit qu’une application cloud (un réseau social, par exemple) n’accède qu’à certaines informations d’un site Web non affilié (par exemple, le compte de messagerie Web de l’utilisateur).
L’authentification est un processus dans lequel l’identité d’un utilisateur est validée selon les identifiants qu’il fournit lorsqu’il se connecte à une application, un service, un ordinateur ou un environnement numérique. La plupart des identifiants d’authentification font partie des catégories « ce que l’utilisateur possède », comme un nom d’utilisateur, et « ce que l’utilisateur connaît », comme un mot de passe. Si les identifiants fournis par l’utilisateur correspondent à ceux stockés dans l’application sous-jacente ou le fournisseur d’identité, l’authentification est réussie et l’accès de l’utilisateur est autorisé.
L’authentification contextuelle est une méthode d’authentification basée sur une gamme d’informations supplémentaires évaluées au moment de la connexion à une application. Le type d’informations contextuelles le plus courant est l’emplacement d’un utilisateur, l’heure qu’il est, l’adresse IP, le type d’appareil, l’URL et la réputation de l’application. L’authentification contextuelle, ou authentification basée sur les risques ou encore adaptative, est essentielle pour la SSO et la gestion des accès, là où l’objectif consiste à rendre l’expérience d’authentification aussi transparente et fluide que possible.
En évaluant les attributs de connexion d’un utilisateur, qu’ils soient contextuels (appareil, rôle, emplacement) ou basés sur le comportement (vitesse de saisie, séquence de consultation des pages, notamment), les solutions d’authentification unique et de gestion des accès peuvent correspondre à tout moment au niveau d’authentification requis par l’utilisateur avec la politique d’accès définie pour chaque application. Ainsi, l’authentification est appliquée avec granularité, de la manière la plus fluide possible, par la politique d’accès d’une application, plutôt que par une règle générique et uniforme pour toutes les ressources de l’entreprise.
L’authentification continue est une forme d’authentification qui se fait de manière continue, à chaque fois qu’un utilisateur accède à une nouvelle application ou ressource, contrairement à une authentification ponctuelle ou binaire, qui fournit une décision de type oui/non ponctuelle qui n’est valide que pour une connexion unique à une seule application.
Avec un token, un mot de passe ou une empreinte digitale, l’authentification est fondamentalement une décision de type oui/non : le système valide l’identité d’un utilisateur et autorise ou refuse son accès à une application.
Mais, grâce aux technologies plus récentes, telles que l’authentification contextuelle ou la biométrie comportementale (comme le schéma de navigation, le mode de saisie ou d’autres caractéristiques physiques), l’authentification peut devenir un processus plus continu. En évaluant une gamme d’attributs comme l’adresse IP, les paramètres mobiles, l’appareil connu, le système d’exploitation, etc., l’authentification contextuelle ou basée sur les risques peut vérifier en continu l’identité d’une personne à chaque fois qu’elle se connecte à une application. Elle peut en effet le faire sans même que l’utilisateur le sache.
L’authentification contextuelle offre de nombreuses méthodes fluides de vérification de l’identité d’une personne. C’est ce qui permet de trouver le bon équilibre entre confort de l’utilisateur et capacité d’appliquer des contrôles d’accès granulaires à de nombreuses applications cloud. C’est pourquoi le concept d’authentification continue, reposant sur l’authentification contextuelle, est un fondement de la gestion des accès cloud.