Provisioning en flux tendu ou privilège en flux tendu

Le provisioning en flux tendu peut être configuré en mettant en place la SSO entre le service cible et le fournisseur d’identités. Vous pouvez utiliser n’importe quel protocole pour la SSO, mais pour que l’intégration fonctionne, il est important que le service cible prenne en charge le provisioning en flux tendu. Beaucoup de grands prestataires de services tels que Oracle, AWS et Adobe offrent le provisioning en flux tendu pour leurs applications.

Lorsqu’un nouvel utilisateur se connecte à un service, le service envoie une demande d’assertion SAML au fournisseur d’identités. Cette demande inclut toutes les informations nécessaires pour créer un nouveau compte d’utilisateur, notamment les informations d’identification (par exemple nom d’utilisateur et mot de passe). Le fournisseur d’identités vérifie l’identité de l’utilisateur puis crée son compte.

Le provisioning en flux tendu permet aux administrateurs d’appliquer des stratégies d’autorisation aux utilisateurs à partir d’un lieu centralisé, en fonction de leurs groupes et de leurs rôles. Par exemple, lorsqu’un nouveau développeur se connecte à un service avec provisioning en flux tendu activé, le fournisseur d’identités lui accorde automatiquement toutes les autorisations du rôle Développeur.

La SSO est une technique d’authentification qui permet aux utilisateurs de se connecter une fois pour accéder aux nombreux services et systèmes. Le provisioning en flux tendu est utilisé en plus de la SSO pour automatiser le processus d’intégration de nouveaux utilisateurs à un système.

La SSO et le provisioning en flux tendu offrent des avantages similaires. Ces deux techniques améliorent l’expérience de connexion. La SSO le fait en supprimant la nécessité de se souvenir de multiples mots de passe. Le provisioning en flux tendu y parvient en permettant aux nouveaux utilisateurs de se connecter sans recours au provisioning manuel.

La SSO et le provisioning en flux tendu diffèrent en ce qui concerne le moment où ils interviennent dans le processus d’authentification. La SSO est appliquée durant la phase de connexion du processus d’authentification, tandis que le provisioning en flux tendu est invoqué pendant la phase de création de l’utilisateur.

Le provisioning en flux tendu présente de nombreux atouts :

• Il implique un gain de temps, ce qui permet aux administrateurs de se concentrer sur des tâches plus importantes.
• Il supprime les risques de mauvaise configuration en automatisant toutes les étapes du provisioning.
• Il permet aux nouveaux utilisateurs de se connecter instantanément au réseau et d’accéder aux systèmes autorisés.
• Il augmente la productivité globale en permettant aux utilisateurs de se connecter à tout service autorisé, à tout moment.

L’accès en flux tendu est une stratégie de sécurité qui accorde des accès à privilèges aux utilisateurs approuvés pour une durée limitée en fonction des besoins. Les administrateurs peuvent utiliser l’accès JIT pour réaliser le suivi des accès aux ressources sensibles et les régir à un niveau plus granulaire.

À l’inverse, le provisioning en flux tendu permet d’enregistrer un utilisateur de manière dynamique lors de sa première connexion. En termes de conception et de philosophie, il s’agit d’une approche fondamentalement différente de l’accès JIT. L’objectif principal du provisioning en flux tendu est de réduire la charge de travail administrative en supprimant la nécessité du provisioning manuel.

L’accès JIT et le provisioning en flux tendu peuvent fonctionner soit ensemble soit indépendamment. Ces deux approches ont certains avantages en commun. Par exemple, tant l’accès JIT que le provisioning en flux tendu permettent aux administrateurs de restreindre les accès à privilèges, mais de manière différente. Toutefois, pour l’essentiel, l’accès JIT et le provisioning en flux tendu concernent des cas d’utilisation différents.

Le privilège en flux tendu est un autre exemple du paradigme Just-in-Time (en flux tendu) qui automatise l’attribution et la suppression dynamiques de privilèges pour les comptes d’utilisateurs. Dans un environnement régi par des stratégies de privilèges JIT, les privilèges élevés ne sont attribués que temporairement aux utilisateurs approuvés.

Le privilège JIT peut jouer le rôle d’une couche de sécurité supplémentaire dans un environnement Active Directory (AD). Active Directory est un élément de base des infrastructures informatiques. Il contrôle et régit l’accès à toutes les ressources sensibles d’un réseau d’entreprise. Pour cette raison, il s’agit souvent d’une cible de choix pour les cyberattaques telles qu’une élévation des privilèges.

L’un des moyens les plus courants de procéder à une élévation de privilèges AD consiste à utiliser un hachage résiduel. Un hachage résiduel est un hachage de mot de passe connecté lorsqu’un utilisateur (standard ou à privilèges) se connecte de façon interactive à un système dans AD. Si une personne malveillante a accès au hachage résiduel d’un utilisateur à privilèges, il peut réaliser des opérations élevées dans l’ensemble de l’infrastructure.

Le privilège JIT offre une façon de réduire ces menaces en s’assurant que les privilèges sont uniquement accordés lorsqu’ils sont demandés, et qu’ils sont révoqués immédiatement après leur utilisation.

Dans un environnement AD classique, les privilèges sont stockés au sein d’Active Directory. En cas d’utilisation d’un privilège JIT, les privilèges sont attribués de façon dynamique aux utilisateurs au moment de la vérification des informations d’identification. Par exemple, si un compte AD autorisé exige des privilèges élevés pour réaliser une action, il est temporairement ajouté à un groupe à privilèges. Dès que l’opération est réalisée et que l’accès privilégié n’est plus nécessaire, l’appartenance du groupe au compte est révoquée et son mot de passe est modifié.

Par exemple, supposons qu’un utilisateur autorisé souhaite réaliser une opération privilégiée telle que la modification d’une stratégie de sécurité à l’échelle du réseau. Voici comment cela se passera dans un environnement AD avec privilège JIT :

1. Une demande d’accès à privilèges sera générée pour vérifier les informations d’identification d’un compte AD à privilèges.
2. La solution de privilège JIT exécutera le workflow d’approbation. Si la demande est approuvée, le compte d’utilisateur sera temporairement ajouté au groupe à privilèges correspondant.
3. L’utilisateur pourra alors utiliser le compte à privilèges pour modifier la stratégie de sécurité à l’échelle du réseau.
4. Ensuite, l’utilisateur restituera le compte au système ou la fenêtre de temps de la demande expirera.
5. Le processus sera ensuite automatiquement inversé, c’est-à-dire que l’appartenance au groupe à privilèges sera révoquée, le compte sera désactivé et le mot de passe sera modifié.

Le provisioning temporaire de privilèges AD réduit considérablement les risques de compromission par hachage résiduel. Même si une personne malveillante parvient à extraire un hachage résiduel d’un utilisateur AD à privilèges, il ne peut l’exploiter dans la mesure où l’appartenance au compte a été annulée et que son mot de passe a été modifié.

Non, le provisioning en flux tendu n’est pas identique au Zero Trust. Cependant, le paradigme du Just-in-Time est un concept fondamental du Zero Trust. Les approches telles que l’accès en flux tendu, le privilège en flux tendu et le provisioning en flux tendu s’alignent sur les principes de base du Zero Trust.

Le Zero Trust implique de ne faire confiance à aucune entité d’un réseau, sachant que chacune de ces entités reçoit des privilèges d’accès de façon temporaire. L’accès et le privilège en flux tendu y parviennent en attribuant de façon dynamique un accès temporaire à des ressources et en s’assurant qu’aucun accès n’est illimité.

En permettant aux administrateurs d’appliquer des stratégies d’autorisation, le provisioning en flux tendu garantit la conformité au principe du moindre privilège, qui est un principe de base du Zero Trust. Il serait donc juste de dire que le provisioning en flux tendu et le Zero Trust sont complémentaires, mais il serait faux de les considérer comme équivalents.