"C’est les comptes de service, stupide": Pourquoi les déploiements PAM prennent (presque) une éternité


Les solutions de gestion des accès à privilèges (PAM) sont considérées comme la pratique courante pour prévenir les menaces d’identité sur les comptes administratifs. En théorie, le concept PAM est tout à fait logique : placez les informations d’identification de l’administrateur dans un coffre-fort, faites pivoter leurs mots de passe et surveillez de près leurs sessions. Cependant, la dure réalité est que la grande majorité des projets PAM deviennent soit un projet de plusieurs années, soit même s’arrêtent complètement, les empêchant de fournir la valeur de sécurité promise.

Dans cet article, nous explorons ce qui fait les comptes de service sont un obstacle majeur à l’intégration de PAM. Nous apprendrons pourquoi le stockage et la rotation des mots de passe des comptes de service sont une tâche presque impossible, ce qui les expose à des compromis. Nous conclurons ensuite en expliquant comment Silverfort permet aux équipes d’identité, pour la première fois, de surmonter ces défis grâce à la découverte, la surveillance et la protection automatisées des comptes de service, et de rationaliser le processus d’intégration PAM en quelques semaines seulement.

La promesse PAM : protection pour tous les utilisateurs administratifs

Le concept de PAM est extrêmement simple. Étant donné que les adversaires cherchent à compromettre les informations d’identification de l’administrateur pour les utiliser pour un accès malveillant, la chose naturelle à faire est de placer des obstacles dans leurs tentatives pour réussir à effectuer ce compromis. PAM fournit une couche de sécurité supplémentaire qui inclut à la fois une surveillance étroite des connexions d’administrateur via l’enregistrement de session et, plus important encore, une couche de prévention proactive sous la forme d’informations d’identification d’administrateur de coffre-fort et les soumet à une rotation périodique des mots de passe. Cela réduit considérablement le risque d’une attaque réussie, car même si un adversaire parvient à compromettre les informations d’identification de l’administrateur, la rotation des mots de passe les rendra invalides au moment où il tentera de les utiliser pour accéder aux ressources ciblées.

Donc en théorie, tout va bien.

La création de politiques MFA faciles à mettre en œuvre pour tous vos comptes privilégiés est le seul moyen de s’assurer qu’ils ne sont pas compromis. Sans avoir besoin de personnalisations ou de dépendances de segmentation du réseau, vous pouvez être opérationnel en quelques minutes avec Silverfort. Découvrez comment protéger vos comptes privilégiés de compromis rapidement et en toute transparence grâce à des politiques d’accès adaptatives qui appliquent aujourd’hui la protection MFA sur toutes les ressources sur site et dans le cloud.

La réalité PAM : un processus d’intégration long et complexe qui peut prendre des années

Cependant, ce que les équipes d’identité et de sécurité rencontrent dans la pratique, c’est que le déploiement de solutions PAM est l’un des processus les plus gourmands en ressources. Le fait est que très peu de projets PAM vont jusqu’au bout de l’objectif de protection de tous les comptes administratifs au sein de l’environnement. Ce qui se passe généralement à la place, c’est que les défis surviennent tôt ou tard, sans solution facile. Au mieux, ces défis ne font que ralentir le processus d’intégration, l’étirant sur des mois, voire des années. Au pire, ils arrêtent tout le projet. De cette façon ou de l’autre, les implications sont graves. En plus des lourds investissements en temps et en efforts, l’objectif principal de PAM n’est pas atteint et les comptes d’administrateur ne bénéficient pas de la protection dont ils ont besoin.

Bien qu’il existe diverses raisons aux difficultés introduites par le déploiement de PAM, la plus importante concerne la protection des comptes de service.

Récapitulatif des comptes de service : comptes privilégiés pour la connexion de machine à machine

Les comptes de service sont des comptes d’utilisateur créés pour la communication de machine à machine. Ils sont créés de deux manières principales. Le premier est le personnel informatique qui les crée pour automatiser les tâches répétitives de surveillance, d’hygiène et de maintenance au lieu de les exécuter manuellement. La deuxième méthode s’inscrit dans le cadre du déploiement d’un produit logiciel dans l’environnement de l’entreprise. Par exemple, le déploiement d’un serveur Outlook Exchange implique la création de divers comptes qui effectuent des analyses, des mises à jour logicielles et d’autres tâches qui impliquent une connexion entre le serveur Exchange et d’autres machines de l’environnement.

De cette façon ou de l’autre, un compte de service typique doit être hautement privilégié pour pouvoir établir la connexion de machine à machine pour laquelle il a été créé. Cela signifie qu’il n’est pas différent de n’importe quel compte d’administrateur humain dans la protection dont il a besoin. Malheureusement, l’intégration d’un compte de service à une solution PAM est une tâche presque impossiblece qui en fait le plus grand obstacle au déploiement réussi de PAM.

L’écart de visibilité : il n’existe aucun moyen simple de découvrir les comptes de service ou de cartographier leurs activités

Il se trouve qu’il n’existe aucun moyen simple d’obtenir une visibilité sur l’inventaire des comptes de service. En fait, dans la plupart des environnements, vous ne pouvez pas connaître le nombre total de comptes de service à moins qu’une surveillance et une documentation strictes de la création, de l’attribution et de la suppression des comptes de service aient été pratiquées au fil des ans – ce qui n’est guère la pratique courante. Cela signifie que la découverte complète de tous les comptes de service dans un environnement n’est réalisable qu’avec un effort de découverte manuelle important, ce qui est hors de portée pour la plupart des équipes d’identité.

De plus, même si le défi de la découverte est résolu, il reste encore un défi plus grave qui reste sans réponse, qui consiste à cartographier l’objectif de chaque compte et les dépendances qui en résultent, c’est-à-dire les processus ou applications que ce compte prend en charge et gère. Cela s’avère être un bloqueur PAM majeur. Comprenons pourquoi.

L’implication de PAM : la rotation du mot de passe du compte de service sans visibilité sur son activité peut interrompre les processus qu’il gère

La façon typique dont les comptes de service se connectent à différentes machines pour effectuer leur tâche est avec un script qui contient les noms des machines auxquelles se connecter, les commandes réelles à exécuter sur ces machines, et le plus important – le nom d’utilisateur et le mot de passe du compte de service qui sont utilisés pour s’authentifier auprès de ces machines. Le conflit avec l’intégration PAM se produit parce que pendant que le PAM fait pivoter le mot de passe du compte de service à l’intérieur du coffre, il n’y a aucun moyen de mettre à jour automatiquement le mot de passe codé en dur dans le script pour qu’il corresponde au nouveau que le PAM a généré. Ainsi, la première fois que le script s’exécutera après la rotation, le compte de service tentera de s’authentifier avec l’ancien mot de passe – qui n’est plus valide. L’authentification échouera et la tâche que le compte de service était censé effectuer ne se produira jamais, brisant également tous les autres processus ou applications qui reposent sur cette tâche. L’effet domino et les dommages potentiels sont évidents.

Le piège des comptes de service PAM : pris entre deux problèmes opérationnels et de sécurité

En fait, la plupart des équipes d’identité, compte tenu de ce risque, éviteront complètement de mettre en chambre forte les comptes de service. Et c’est exactement l’impasse – la mise en chambre forte des comptes de service crée un risque opérationnel, tandis que ne pas les mettre en chambre forte crée un risque de sécurité non moindre. Malheureusement, jusqu’à présent, il n’y a pas eu de réponse facile à ce dilemme. C’est pourquoi les comptes de service sont un tel inhibiteur pour l’intégration PAM. La seule façon de satisfaire à la fois les exigences de sécurité et les exigences opérationnelles consiste à lancer un effort manuel minutieux de découverte de tous les comptes de service, des scripts qui les utilisent, ainsi que des tâches et des applications qu’ils exécutent. Il s’agit d’une mission gargantuesque et de la principale raison des mois, voire des années, du processus d’intégration de PAM.

Relever le défi avec la découverte et la cartographie des activités des comptes de service automatisés

La racine du problème est le manque traditionnel d’un utilitaire qui peut facilement filtrer tous les comptes de service et produire un résultat de leurs activités. C’est le défi que Silverfort vise à simplifier et à résoudre.

Silverfort est le pionnier de la première plate-forme de protection d’identité unifiée qui s’intègre nativement à Active Directory pour surveiller, analyser et appliquer une politique d’accès active sur tous les comptes d’utilisateurs et ressources de l’environnement AD. Avec cette intégration en place, AD transmet chaque tentative d’accès entrante à Silverfort pour analyse des risques et attend son verdict d’accorder ou de refuser l’accès.

En tirant parti de cette visibilité et de l’analyse de toutes les authentifications, Silverfort peut facilement détecter tous les comptes qui présentent le comportement répétitif et déterministe qui caractérise les comptes de service. Silverfort produit une liste détaillée de tous les comptes de service dans l’environnement, y compris leur niveau de privilège, leurs sources, leurs destinations et leur volume d’activité.

Avec ces informations disponibles, les équipes d’identité peuvent facilement identifier les dépendances et les applications de chaque compte de service, localiser les scripts qui l’exécutent et prendre une décision éclairée concernant les comptes de service et choisir l’une des options suivantes :

  • Placer dans le coffre-fort et faire pivoter les mots de passe: dans ce cas, la visibilité nouvellement acquise permet d’effectuer facilement les ajustements requis dans les scripts respectifs pour s’assurer que les mots de passe qu’ils contiennent sont mis à jour conformément à la rotation des mots de passe du coffre-fort.
  • Placer dans le coffre-fort sans rotation et protéger avec une politique Silverfort: parfois, le volume d’utilisation d’un compte de service rendait la mise à jour continue trop difficile à maintenir. Dans ce cas, la rotation des mots de passe serait évitée. L’équipe d’identité utilisera à la place une politique générée automatiquement par Silverfort pour protéger le compte de service, en alertant ou en bloquant son accès lorsqu’un écart par rapport à son comportement normal est détecté.

De cette manière, Silverfort raccourcit le processus d’intégration PAM à quelques semaines seulement, ce qui en fait une tâche réalisable même pour un environnement avec des centaines de comptes de service.

Avez-vous du mal à mettre vos projets PAM sur la bonne voie ? En savoir plus sur la façon dont Silverfort peut aider à accélérer les projets PAM ici.

Vous avez trouvé cet article intéressant ? Suivez-nous sur Twitter et LinkedIn pour lire plus de contenu exclusif que nous publions.





ttn-fr-57