Pendant des décennies, la gestion des accès à privilèges (PAM) a répondu à la problématique des serveurs en stockant les identifiants dans un coffre-fort, en assurant la rotation des mots de passe et en enregistrant les sessions sur les hôtes Linux et les serveurs Windows. Et à cette époque, le système fonctionnait.
Mais la surface d’attaque a évolué. Les données les plus sensibles de l‘entreprise ne résident plus principalement sur les serveurs. Elles se trouvent dans les bases de données : dossiers clients, données financières, informations personnelles identifiables (PII) et charges de travail réglementées. Le volume augmente. La sensibilité augmente. Et les environnements qui hébergent ces données sont devenus bien plus complexes que ce pour quoi la gestion traditionnelle des accès à privilèges a été conçue.
Les environnements modernes de bases de données sont complexes. Ils couvrent des instances on-premise, des services gérés dans le cloud et un ensemble croissant de moteurs, chacun disposant de son propre modèle d’autorisation, d’une hiérarchie de rôles et de contrôles d’accès natifs. Un développeur ou un administrateur de base de données intervenant dans ces environnements est confronté à un défi de gestion des identifiants fondamentalement différent de l’accès aux serveurs. Les autorisations sont imbriquées. L’héritage manque de transparence. Un processus qui respecte en apparence le principe du moindre privilège masque souvent des droits étendus dissimulés à des niveaux inférieurs.
La réglementation a fait monter les enjeux. Les frameworks SOX, RGPD, HIPAA et PCI DSS exigent tous un contrôle démontrable sur qui peut accéder à quelles données et à quel moment. Les auditeurs le demandent. Les équipes sécurité tentent de l’appliquer. Mais les outils n’ont pas suivi. La plupart des entreprises s’appuient encore sur des identifiants statiques, des comptes de service partagés et des processus manuels de rotation pour protéger l’accès à leurs data store les plus sensibles. C’est dans cette faille que surviennent les brèches.
Gérer les bases de données dans Okta Privileged Access
Okta Privileged Access propose désormais un accès à privilèges sécurisé pour les bases de données. Actuellement disponible en Early Access, cette fonctionnalité unifie le contrôle des accès aux bases de données avec les politiques de sécurité existantes utilisées pour les serveurs, les applications SaaS et Active Directory. En centralisant la visibilité, elle élimine les risques d’accès fragmentés au sein des niveaux de données critiques. Fini les identifiants statiques. Fini les mots de passe partagés qui circulent dans votre entreprise. Un accès gouverné et auditable aux systèmes les plus stratégiques.
Voici les améliorations et nouveautés :
Les utilisateurs partagés de bases de données, enfin gérés
Les utilisateurs partagés de bases de données sont devenus une faille : des comptes utilisés par tous, mais dont personne n’est véritablement responsable. Les administrateurs Privileged Access peuvent les onboarder en tant que ressources gérées, permettant ainsi aux utilisateurs finaux d’accéder à des bases de données spécifiques via l’expérience qu’ils connaissent déjà.
La fin des identifiants statiques
Privileged Access prend le contrôle des mots de passe des utilisateurs partagés de la base de données, les remplace par des valeurs sécurisées de manière cryptographique, puis les stocke dans un coffre-fort. Lorsqu’un utilisateur a besoin d’accéder à une ressource, il emprunte des identifiants pour une session à durée limitée, à l’issue de laquelle le mot de passe expire et est automatiquement renouvelé.
Des contrôles de politiques adaptés à la sensibilité de la ressource
Privileged Access vous permet d’imposer des exigences d‘authentification et le MFA à chaque demande d’accès, afin que chaque session soit vérifiée, gouvernée et prête pour l’audit.
La couverture des bases de données que vous exploitez aujourd’hui et demain
La version Early Access de Secure Privileged Access for Databases prend en charge PostgreSQL et MySQL. La version GA, très bientôt disponible, couvrira Microsoft SQL Server, Oracle Database et MongoDB.
À regarder : comment Okta sécurise l’accès aux bases de données ?
À venir
Cette première version élimine les identifiants statiques et place les utilisateurs partagés de bases de données sous un contrôle piloté par une politique. Ensuite, la roadmap devient plus ambitieuse : couverture élargie des bases de données, règles d’onboarding automatisé des utilisateurs et évolution vers des utilisateurs de bases de données entièrement éphémères en flux tendu (JIT) avec une granularité au niveau des tables.
L’objectif final que nous visons est simple : zéro privilège permanent (ZSP). Aucun identifiant persistant susceptible d’être dérobé, aucun compte n’accumule de droits d’accès au fil du temps. L’accès est accordé lorsque nécessaire, limité à la tâche, puis révoqué à la fin de la session.
Il faudra plus d‘une étape pour y parvenir. La plupart des entreprises continuent de s’appuyer sur la mise en coffre (vaulting) et la rotation, et ces contrôles restent essentiels. Privileged Access prendra en charge les deux approches afin de combler l’écart entre le modèle à privilèges permanents utilisé actuellement par les équipes et le modèle d’accès éphémère vers lequel elles tendent.
Envie de vous lancer ? Contactez votre responsable de compte ou votre responsable de la réussite client pour planifier une démo d‘Okta Privileged Access.
Toute mention de produits, fonctions, fonctionnalités ou certifications futurs dans cet article de blog revêt un caractère purement informatif. Ces éléments ne constituent pas des engagements et ne doivent pas être considérés comme un facteur déterminant dans les décisions d’achat. © Okta, Inc. et ses affiliés.
