Cadrer les opérations des admins sur les systèmes

Curieusement, quand on parle de cadrer les opérations des adminsys, la première question qui se pose est de savoir qui est adminsys. Tout le monde imagine l’informaticien barbu avec des lunettes en cul de bouteille et qui parle klingon dans le texte, mais en fait la définition est un peu plus large : selon votre dévoué serviteur elle inclut tous les agents qui disposent de droits sur un système allant au-delà des habilitations strictement nécessaires aux manipulations courantes. Selon cette définition, un ingénieur applicatif qui connaît le mot de passe du SGBD (souvent indispensable pour taper directement dans les tables afin d’analyser les bugs), un référent métier qui dispose d’un compte lui permettant de créer ou de supprimer des utilisateurs métier, voire même (soyons fous) le technicien de maintenance climatique dont la carte d’accès lui permet d’entrer dans le datacenter, tous ces personnels sont de facto à ranger dans la catégorie des adminsys.

Un adminsys a besoin d’un compte utilisateur sur les systèmes qu’il manage ; un compte, cela se crée, cela se surveille, cela se supprime. À partir de ce premier niveau de constat, un certain nombre de processus doivent être mis en place pour encadrer ces trois phases, et notamment :

– une procédure formalisée de création des comptes : document écrit, avec un propriétaire et une date de révision, décrivant qui fait quoi et implémentant le principe de séparation des rôles (celui qui demande la création n’est pas celui qui la valide) ;

– une procédure formalisée d’audit : idéalement tous les trimestres (au moins) une petite extraction de l’ensemble des comptes admin, histoire de vérifier qu’un petit malin n’est pas allé s’en créer un dans le dos du RSSI ;

– une procédure formalisée de destruction, déclenchée soit par un départ (démission, licenciement, etc.), soit par une mutation au sein des équipes (redoutable nid à problèmes).

Récemment, un auditeur m’a demandé comment je pouvais déterminer depuis quand tel agent était adminsys. Si l’on s’en tient aux éléments ci-dessus, c’est compliqué (il faut aller fouiller dans le logiciel de ticketing, autant dire qu’on ne s’en sortira pas). Il est plus simple de mettre en place une main courante, gérée par le responsable infrastructure ou le RSSI et alimentée à chaque changement.

Une fois que l’on a instruit la question du cycle de vie des comptes, l’autre sujet est de savoir comment les adminsys vont se connecter aux plateformes (là, le cas du technicien climatique est hors scope) : en direct ou en passant par un bastion ? Pour les systèmes internes (serveurs) sur le LAN, du fait qu’ils sont aussi connectés à l’AD local, la connexion en direct ne pose pas vraiment de problème, du moment bien entendu que l’on collecte les traces de connexion, qu’on les range dans un système spécifique à l’abri des adminsys eux-mêmes (un compte local de connexion sur ce système suffit). Le bastion possède l’avantage d’éviter cela, mais engendre une autre difficulté : il faut totalement isoler le réseau de production des PC des adminsys de telle sorte qu’ils ne puissent pas passer par un autre biais que le bastion en question. Là, on change de gamme en matière de difficulté d’architecture.

Quand il s’agit de systèmes hébergés pour le compte d’un client (HDS), c’est un peu différent. La certification HDS est assez stricte sur ce sujet, mais la différence réside dans le fait que ces systèmes sont déjà sur des réseaux distincts. On peut donc soit passer par un bastion, soit attaquer les systèmes en direct. Dans ce second cas, attention cependant. Étant donné que ces systèmes sont rarement liés à un AD (surtout si vous hébergez trois machines pour un même client), il va falloir créer autant de comptes admin locaux que d’adminsys et de serveurs : la facture peut vite être salée.

Bon, dans la réalité, le sujet est plus complexe et protéiforme : si les cycles de vie des ID/MDP adminsys et Power Users Applications sont très semblables, les contraintes de traçabilité ne sont pas les mêmes, la notion de bastion n’existe pas dans le second cas, etc. Et avec les accès à des locaux sensibles, par exemple, c’est encore différent. Ce qui est certain, c’est que jusqu’à récemment nous étions tous un peu « légers » sur ce sujet. Les différentes normes, réglementations et autres contraintes métiers sont en train de sérieusement réviser les besoins à la hausse.