Comment la Société Générale renforce la gestion de ses comptes techniques
La banque s’appuie sur les outils de Sailpoint pour assurer une gouvernance d’accès hautement automatisée, par le biais de rôles, au sein de son infrastructure transverse. De quoi assurer contrôle et agilité.
Depuis 2009, la Société Générale s’est dotée d’une unité transverse, dites Global Technologies & Services (GTS), chargée de fournir un socle d’infrastructure IT pour l’ensemble de ses activités. C’est au sein de ce département que Christophe Machado, était jusqu’à tout récemment en charge de la gestion des identités et des accès (IAM) pour l’IT. A l’occasion d’un atelier organisé avec Sailpoint aux Assises de la Sécurité, au mois d’octobre à Monaco, il explique que cette infrastructure a vocation à devenir la plateforme de services de la banque. Et là, l’IAM doit jouer un rôle clé.
Sans surprise, l’IAM est utilisé à la Société Générale depuis plusieurs années, mais il concernait surtout la gestion des identités au niveau des applications métiers : « on faisait de l’IAM pour IT avant, mais de façon plus indépendante, sur certaines entités, et avec une maturité différente ». C’est donc en 2016 qu’a été relancé un programme de renforcement de la gouvernance et de la gestion des comptes à privilèges. Les outils de Sailpoint ont été retenus pour le premier volet, et ceux de Cyberark pour le second. L’ambition, comme la décrit Christophe Machado, consiste à « gérer les comptes IT, qu’ils soient nominatifs ou techniques (services, applicatifs, génériques, etc.) », mais aussi à « rationaliser, fédérer, et augmenter le niveau de maturité global de l’IAM autour de l’IT pour assurer une vraie cohérence ».
La solution de Sailpoint a été retenue à la suite d’une migration, opérée en 2015, à partir d’outils qui assuraient automatisation et provisioning, mais n’assurait pas le contrôle de la ségrégation des tâches ni la certification des accès. Aujourd’hui, ce sont 15 000 utilisateurs qui sont gérés, au travers de rôles IT, « et qui nous permettent d’adresser des accès sur différents types de cibles : serveurs Windows, Unix, bases de données, mainframe… » Soit environ 5000 systèmes. Le périmètre doit donc être étendu à l’ensemble du groupe, en se concentrant sur les actifs sensibles et réglementés.
SailPoint IIQ a notamment été choisi dans l’activité banque de détail de Société Générale, pour la gestion des comptes métiers, mais donc également pour cette migration des outils existants – « notamment pour le mainframe avec un connecteur natif TSS ». Il a été de nouveau retenu en 2016 à la suite d’une étude pour étendre le périmètre et compléter l’offre interne d’IAM IT.
Le déploiement de Sailpoint IIQ a commencé en janvier 2015, avec initialement, les comptes nominatifs d’administrateurs, et d’utilisateurs mainframe. Au mois de juin suivant, le portail de gestion des comptes est ouvert. Mais il a rapidement fallu ajuster l’approche, en consolidant les identités, avec IdM pour les systèmes Red Hat ou encore OUD pour les systèmes Oracle. En juin 2016, la migration des utilisateurs a été finalisée et la certification des accès a pu commencer. En mai 2017, la solution patrimoniale a pu être supprimée.
Christophe Machado souligne les difficultés liées aux comptes techniques. Autant les comptes nominatifs sont assortis de données RH qui simplifient la gestion de leur cycle de vie, autant les comptes techniques en sont dépourvus, alors qu’ils peuvent être dotés de privilèges élevés, et être « souvent dormants » : « ce sont des chantiers sur lesquels on se penche également cette année ». Mais déjà, le projet a été l’occasion de nombreux apprentissages.
Et cela commence par l’importance de l’automatisation, notamment pour la mise à jour des rôles lorsque de nouveaux actifs sont créés dans l’environnement. Et cela suppose d’aller vite, très vite, en particulier pour suivre le rythme des équipes DevOps. « L’aspect CMDB est également très important : il y a une connexion forte avec les outils d’IAM et les référentiels d’identité ». Et ces derniers sont également essentiels, car gérer ces identités avec des comptes locaux revient à « les démultiplier ; on porte atteinte aux performances et ce n’est pas très gérable ».
Et les comptes IT recouvrent aussi ceux des développeurs – « auxquels il faut aussi donner les moyens de gestion de leurs comptes » – et cela implique de disposer « d’une source fiable de données d’identités. C’est toujours perfectible, mais on a la chance de disposer d’un référentiel central » pour ces données.
Mais la nature même des comptes IT, « souvent multipliés » et « moins explicites que les comptes métiers », affecte un autre volet de leur gestion : leur certification. Assurer celle-ci à l’unité n’apparaît donc pas comme une option viable : « nous avons adopté une approche par les rôles qui englobent un certain nombre d’accès et de comptes ». L’action de certification est donc déplacée sur les rôles – quelques milliers tout de même – plutôt que sur les comptes. Mais « là encore, cela ne fonctionne bien que si l’on dispose d’une bonne automatisation et intégration ».
Mais l’ambition va au-delà : il s’agit d’offrir, avec l’IAM, le socle d’une « sécurité sans couture », à la fois en interne et pour les clients de la Société Générale. Et cela nécessite une vaste intégration, et une « gestion des accès au sein du groupe qui soit également transparente ». C’est donc d’un modèle fédéré qu’il est question : chaque entité peut donc disposer de son propre outil de gouvernance des accès, dans une démarche centrée sur l’utilisateur, en s’appuyant sur des connecteurs agnostiques, comme des API Rest.