Comment Keeper vous aide à appliquer l’absence de privilèges permanents

Les comptes privilégiés représentent une invitation permanente pour les attaquants, qui peuvent dérober des identifiants et détourner des autorisations. Lorsque les droits d’administration restent actifs en continu, qu’ils soient utilisés ou non, les comptes privilégiés étendent considérablement la surface d’attaque. L’absence de privilèges permanents (Zero Standing Privilege, ou ZSP) réduit ce risque en veillant à ce qu’aucun utilisateur ne dispose d’un accès élevé permanent. Au lieu de cela, les privilèges sont demandés pour une tâche spécifique, accordés pour une durée limitée, approuvés par le biais d’un flux de travail défini et automatiquement révoqués à l’expiration de la durée approuvée. Le ZSP reflète une évolution plus globale de la sécurité moderne et remplace les accès permanents par des accès éphémères afin de réduire les possibilités d’exploitation par un attaquant. Keeper contribue à appliquer les principes du ZSP en accordant un accès juste-à-temps (JIT) et en le révoquant automatiquement à l’expiration de la durée approuvée. Ainsi, les utilisateurs disposant de « zero privilege » se voient accorder les accès spécifiques dont ils ont besoin, qui sont ensuite automatiquement révoqués.

Lisez la suite de l’article pour comprendre l’importance du ZSP et en savoir plus sur son fonctionnement avec Keeper et son application dans différents environnements.

Pourquoi les privilèges permanents constituent un risque pour la sécurité

Les comptes privilégiés qui restent actifs indéfiniment offrent aux attaquants une cible durable : les identifiants n’expirent pas, les accès sont constamment disponibles et aucune échéance n’est fixée pour la révocation de ces droits. Si des attaquants dérobent ou compromettent l’un de ces comptes, ils héritent de tous leurs privilèges permanents.

Le problème majeur est le rayon d’impact, car un compte compromis disposant d’un accès permanent se limite rarement au système auquel il était destiné. Les attaquants utilisent les privilèges permanents pour se déplacer latéralement au sein des environnements, atteignant ainsi des serveurs, des bases de données et des ressources cloud supplémentaires sur leur passage. Ce qui peut commencer par un simple identifiant compromis peut rapidement se transformer en point d’ancrage sur l’ensemble de votre infrastructure si l’utilisateur dispose d’un accès permanent. Lorsque les privilèges sont permanents, l’attribution des accès n’est liée à aucune demande, tâche ou échéance spécifique. Cela ne laisse en outre aucune trace claire de la raison pour laquelle un utilisateur a pu accéder à un système à un moment donné. Cette ambiguïté complique considérablement les enquêtes sur les incidents de sécurité impliquant des privilèges permanents ainsi que la preuve de conformité.

Comment fonctionne l’absence de privilèges permanents dans Keeper

Keeper permet d’appliquer le ZSP par l’intermédiaire de Keeper Privileged Cloud, qui étend le cadre de l’accès JIT de KeeperPAM à vos fournisseurs d’identité et applications fédérées. Au lieu d’attribuer des droits d’administrateur permanents, Keeper Privileged Cloud n’accorde un accès élevé qu’en cas de demande, uniquement pour une période approuvée et selon les contrôles de flux de travail que vous définissez. Les utilisateurs ne disposent par défaut d’aucun privilège et peuvent les élever par le biais d’un processus contrôlé et auditable avant de se voir révoquer ces droits lorsque la tâche est terminée. Voici comment fonctionne le ZSP en pratique avec Keeper.

Configuration des politiques d’accès

Sur une entrée PAM Cloud, les administrateurs définissent les règles d’accès à l’aide de réglages JIT et de flux de travail. Cela inclut si une demande requiert une approbation, qui peut l’approuver, pour combien de temps l’accès est accordé et le rôle auquel l’utilisateur accède avec des privilèges élevés. Ces réglages permettent de déterminer avec précision comment l’accès privilégié est demandé, approuvé et limité dans le temps, garantissant qu’aucune élévation ne dépasse les limites que vous avez fixées.

Partage d’entrées avec des utilisateurs autorisés

Une fois la politique en place, l’entrée PAM Cloud est partagée avec les utilisateurs qui doivent pouvoir demander l’accès. Comme l’élévation des privilèges s’effectue par l’intermédiaire de votre fournisseur d’identité, chaque utilisateur doit avoir un compte chez votre fournisseur d’identité et dans votre tenant Keeper. Une fois l’entrée partagée, ces utilisateurs pourront demander un accès élevé lorsqu’une tâche le requiert, sans détenir des privilèges permanents entre-temps.

Examen et approbation des demandes

Lorsqu’un utilisateur a besoin d’un accès, il peut en faire la demande directement depuis son coffre-fort Keeper ou la CLI de Keeper Commander. Les approbateurs désignés reçoivent des notifications en temps réel à partir d’outils tels que Slack, Teams, Jira et ServiceNow. Ils peuvent ensuite approuver ou refuser une demande depuis n’importe quel client Keeper, de sorte que les demandes ne restent pas bloquées en attendant le retour des approbateurs à leur poste de travail. En fonction de la politique définie, les approbateurs peuvent également exiger une justification et un numéro de ticket avant d’accorder un accès pour associer chaque élévation de privilèges à un motif documenté.

Octroi et révocation automatique des accès

Une fois la demande approuvée, la passerelle Keeper procède à l’élévation des privilèges sur le fournisseur d’identité ou la ressource cible, accordant à l’utilisateur l’appartenance au groupe, le rôle ou le droit configuré afin qu’il obtienne l’accès autorisé par la politique. À l’expiration de la durée approuvée, la passerelle Keeper révoque automatiquement cet accès, supprimant l’appartenance ou l’attribution temporaire et rétablit le statut ZSP de l’utilisateur. Elle enregistre également chaque élévation ayant demandé un accès, qui l’a approuvée ainsi que le moment où elle a commencé et pris fin, afin que les équipes de sécurité et de conformité disposent d’un compte rendu clair, par demande, de la manière dont l’accès privilégié a été accordé et utilisé.

Où est-ce que Keeper applique l’absence de privilèges permanents

Keeper ne limite pas le ZSP à un seul système ou type de compte. Le même cadre JIT s’applique partout où un accès privilégié existe dans votre environnement, des fournisseurs d’identité auprès desquels vos utilisateurs s’authentifient aux ressources cloud, bases de données et machines qui y sont associées.

Dans l’ensemble de vos fournisseurs d’identité

Keeper Privileged Cloud étend l’accès JIT aux fournisseurs d’identité existants, notamment AWS IAM, Microsoft Entra ID, Google Cloud via Google Identity, Okta et Active Directory. Keeper accorde et révoque les privilèges directement au sein de votre infrastructure existante, de sorte que l’élévation s’effectue là où vos comptes se trouvent déjà, sans perturber la façon dont les utilisateurs s’authentifient. Le fournisseur d’identité reste votre source de vérité, tandis que Keeper contrôle simplement le moment où un utilisateur se voit accorder des privilèges au sein d’un groupe et lorsqu’ils lui sont retirés.

Cette portée ne concerne pas uniquement les plateformes elles-mêmes, mais inclut également les applications qui fédèrent l’accès et l’autorisation par le biais de ces fournisseurs d’identité. Les applications fédérées peuvent également utiliser Keeper pour le contrôle d’accès, ce qui permet aux utilisateurs de mettre en œuvre le même modèle JIT dans les applications en aval auxquelles les équipes se connectent chaque jour.

À travers le cloud, les bases de données et les machines

Le ZSP ne se limitant pas aux consoles cloud, KeeperPAM applique le même cadre d’élévation des privilèges au-delà de vos fournisseurs d’identité. Grâce aux entrées de cloud PAM, de base de données PAM et de machine PAM, vous pouvez étendre l’accès limité dans le temps aux ressources cloud, aux bases de données et aux machines individuelles, en appliquant le même cycle de vie à l’infrastructure qui sous-tend votre couche d’identité.

Au-delà de l’élévation des privilèges, la passerelle Keeper assure également la rotation des identifiants privilégiés afin qu’ils ne restent pas des cibles statiques. Quant aux bases de données et aux machines, elle peut provisionner des comptes éphémères, en injectant les identifiants côté serveur afin que l’utilisateur ne les manipule jamais. Tout ceci repose sur l’architecture zero knowledge de Keeper, ce qui signifie que les identifiants et les secrets restent chiffrés de bout en bout et ne sont jamais exposés à Keeper ni à quiconque. Ensemble, la rotation automatisée et le zero knowledge garantissent que même les identifiants permettant un accès privilégié ne subsistent pas en tant qu’éléments qu’un attaquant pourrait dérober et exploiter.

Minimisez votre surface d’attaque avec Keeper

L’absence de privilèges permanents ne fonctionne que si elle est appliquée de manière cohérente, et c’est là que Keeper Privileged Cloud excelle. Avec Keeper Security, les équipes de sécurité disposent d’un moyen auditable d’accorder un accès privilégié à la demande et de le révoquer automatiquement, en s’appuyant sur les fournisseurs d’identité et l’infrastructure que vous utilisez déjà. Les administrateurs peuvent contrôler les accès et prouver qui peut accéder à quelles ressources et à quel moment ; les utilisateurs obtiennent les accès nécessaires sans attendre leur attribution manuelle et sans conserver les droits dont ils n’ont plus besoin.

Demandez une démonstration de KeeperPAM pour voir le fonctionnement de l’accès JIT et la révocation automatique au sein de votre environnement.