DORA et Keeper : protéger les credentials, secrets et connexions privilégiées

Un compte administrateur ou un compte technique peut rester nécessaire même lorsqu'on souhaite réduire les privilèges permanents. La difficulté consiste alors à contrôler l'utilisation de son credential sans le diffuser aux différents utilisateurs qui en ont ponctuellement besoin.

KeeperPAM permet de lancer des connexions privilégiées depuis le coffre et documente notamment la possibilité de partager une connexion sans exposer les credentials sous-jacents. La plateforme propose également des tunnels à durée limitée et des connexions Zero Trust vers les ressources protégées.

Cette séparation entre l'utilisateur et le secret utilisé pour établir la connexion est particulièrement utile avec des comptes d'administration ou des comptes techniques historiques. Elle ne dispense pas de respecter l'article 21(c), qui demande de limiter autant que possible les comptes génériques et partagés : le PAM ne doit pas devenir un prétexte pour les multiplier. Lorsqu'un compte de ce type reste nécessaire, l'objectif est au contraire de contrôler précisément qui est autorisé à l'utiliser et de conserver la traçabilité de son utilisation.

Les privilèges ne concernent pas uniquement les administrateurs humains. Applications, scripts, pipelines CI/CD et services utilisent eux aussi des secrets pour accéder à des bases de données, API ou infrastructures.

Keeper Secrets Manager est conçu pour fournir ces secrets aux applications et environnements techniques sans les intégrer en dur dans le code. Keeper fournit des SDK pour plusieurs langages ainsi qu'une CLI permettant à un processus de récupérer ou d'injecter des secrets depuis le coffre.

Le modèle de Keeper Secrets Manager utilise des applications et des devices clients dédiés. Leur initialisation s'appuie notamment sur un jeton d'accès à usage unique servant à établir les clés et identifiants nécessaires aux accès ultérieurs ; après initialisation, les requêtes sont signées avec les clés du device.

Cette capacité n'est pas une réponse directe à tout l'article 21(e)(ii), qui vise principalement les accès privilégiés, d'urgence et administrateur. Elle permet néanmoins d'étendre la maîtrise des secrets aux identités non humaines, qui constituent elles aussi une source d'accès sensible au système d'information.

KeeperPAM et Netwrix Privilege Secure couvrent tous les deux une partie du terrain du PAM, notamment les accès et sessions privilégiés. Il serait donc incorrect de dessiner une architecture DORA dans laquelle les deux produits seraient nécessairement déployés l'un derrière l'autre.

Le choix dépend du problème à résoudre et de l'existant. Netwrix Privilege Secure se prête particulièrement bien à un scénario dans lequel une activité administrative déclenche l'octroi temporaire d'un privilège, éventuellement après approbation, puis son retrait à la fin de la session. Keeper apporte de son côté une couverture forte autour du credential, de sa rotation, du secret applicatif, de la connexion sans exposition du credential et de la gestion de sessions privilégiées.

Les périmètres peuvent donc se recouvrir. Une architecture doit partir des usages, des ressources, des types de comptes et du modèle d'exploitation avant de décider s'il faut privilégier l'une de ces approches ou éventuellement les combiner sur des périmètres distincts.