Thales adopte une architecture sans confiance pour l’administration de son SI

Drastique. C’est le qualificatif qu’a employé Nicolas Alamome, responsable des annuaires techniques chez Thales, lors d’un atelier organisé aux Assises de la Sécurité, pour décrire le « corpus d’exigences » qui entoure le contrôle de l’administration des hôtes du système d’information. Et à écouter la description de l’architecture retenue, le terme retenu n’apparaît pas trop fort.

L’objectif affiché a de quoi paraître simple : « centraliser la gestion des machines, Windows et Unix », tout en homogénéisant les règles applicables aux différentes entités du groupe, en suivant les pratiques de référence préconisées par l’Agence nationale pour la sécurité des systèmes d’information (Anssi) et Microsoft, et bien sûr en traçant toutes les activités d’administration pour réussir à savoir « qui a fait quoi sur quoi ». La traduction pratique apparaît en revanche bien moins triviale que l’énoncé. Et cela d’autant plus qu’il n’est pas question d’affecter l’expérience des administrateurs, ne serait-ce que pour ménager leur productivité.

Tout d’abord, l’administration de l’ensemble du parc doit se faire « à partir d’un cœur de confiance, une solution d’administration conçue spécifiquement ». Mais tous les administrateurs doivent pouvoir travailler de la même manière, et cela malgré le recours à des comptes dédiés – pas question, chez Thales, de laisser trainer des comptes administratifs génériques. Les habilitations sont également gérées étroitement, sans chèque en blanc, en somme – « qui aura le droit de faire quoi sur quoi, et pour combien de temps ».

Qui plus est, il faut compter avec une ségrégation forte des populations d’administrateurs : « nous n’avons pas envie qu’un administrateur d’annuaire puisse aller administrer un serveur ou un poste de travail ». Découlent de cette segmentation rigoureuse « plusieurs dizaines de profils et de sous-profils d’administration afin de gérer les droits de manière très fine ».

« Les administrateurs n’ont pas de droits d’administration sur leurs systèmes… afin d’empêcher la primo-infection des postes d’administration. »

Pour ne rien gâcher, les administrateurs n’ont pas de droits d’administration sur leurs systèmes… « afin d’empêcher la primo-infection des postes d’administration ». La connexion à la production avec des comptes dédiés à l’administration est interdite, tant via la gestion des habilitations que par le biais de règles réseau.

Un réseau physique dédié à l’administration est déployé sur chacun des sites du groupe, avec des services d’infrastructure qui lui sont spécifiques et indépendants de ceux du SI de production « qui ne servent qu’à administrer nos forêts d’administration », explique Nicolas Alamome. Et d’ajouter que « deux types de postes d’administration dédiés et durcis sont rattachés à des forêts d’administration – une pour les annuaires et les privilèges, et une autre pour les ressources ».

C’est dans cet environnement que Thales a déployé la solution de Centrify, pour notamment gérer les délégations de privilèges et assurer une expérience homogène de l’administration sur l’ensemble des ressources administrées, quelles qu’elles soient et quel que soit le système d’exploitation concerné. « Avec Windows et Centrify, nous avons réussi à positionner des droits fins ». Mais cela vaut aussi pour le monde Unix où « des zones Centrify assurent le lien entre identifiant Windows et Unix. Le serveur génère des attributs Unix pour gérer la correspondance entre identité et objet Active Directory ».

Nicolas Alamome reconnaît de bon cœur que « tout cela ne s’est pas fait en un mois. Le modèle est tel, que l’intégration a demandé beaucoup de travail conjoint entre équipes d’annuaire et Centrify ». Mais les administrateurs ont été impliqués dès le départ pour accélérer l’adoption et l’éditeur « nous a accompagnés dans la conception et la mise en œuvre, notamment pour l’expérience des administrateurs ». Des difficultés ont été rencontrées et ont nécessité l’intervention de l’ingénierie de Centrify, par exemple « pour le SSO avec Kerberos », les développements nécessaires ont été réalisés : « au final, l’intégration est parfaite, et nous n’avons pas eu à transformer notre modèle d’intégration ».