Le monitoring d’application consiste à obtenir en temps réel divers métriques d’une application, c’est-à-dire un programme utilisé pour la réalisation de tâches.

Cela comprend les applications « côté client » comme les navigateurs web (Google Chrome), les traitements de texte (Microsoft Word), ou même les sites web, mais également les applications « côté serveur », comme les serveurs web (Apache, Nginx), le middleware (Apache Tomcat), etc.

Cette pratique est très générale et peut consister de plusieurs métriques :

1) Les ressources utilisées par l’application

Les ressources comprennent l’usage processeur, écriture disque, ou RAM (mémoire vive), mais aussi l’usage de bande passante réseau, le nombre de processus et de threads, la taille de l’application sur le disque… En d’autres termes, l’impact qu’a l’application sur le système d’exploitation et le hardware.

Ces métriques sont basiques, et plusieurs logiciels de monitoring (supervision) permettent de les obtenir, tels que Zabbix ou Nagios.

2) Le SIEM

Le SIEM (Security Information and Event Management, en français « Gestion de l’information et des événements de sécurité ») consiste à récupérer les journaux et évènements générés par une application afin de les analyser.

Cela permet notamment d’être alerté en temps réel sur un évènement à risque, et d’être très réactif en cas de brèche dans le Système d’Information.

Ces données sont ensuite agrégées puis corrélées avec d’autres données, par exemple pour savoir quel évènement a déclenché un autre évènement. La plupart des solutions supportent aussi un archivage des données, pour une éventuelle utilisation juridique, ou pour être conforme à des règlementations.

Les solutions de SIEM incluent Graylog, mais aussi Splunk ou la suite ELK (Elasticsearch, Logstash, Kibana).

3) L’APM (Application Performance Monitoring)

L’APM consiste à surveiller la rapidité d’une application. Cette métrique se concentre sur l’utilisateur final et permet de détecter la latence et éventuellement les pannes. Cela aide notamment à respecter les SLA (entente de niveau de service) qui définissent un temps de réponse cible.

Respecter cette métrique est important pour les applications utilisées par les clients (en général, les sites et applications web) afin d’assurer une satisfaction des utilisateurs. L’analyse est également possible : on peut savoir si l’application pourrait par exemple supporter une hausse dans le nombre d’utilisateurs.

Parmi les solutions d’APM, on trouve Splunk, Uptrends et Dynatrace.

4) Les métriques internes à l’application

Enfin, certaines applications possèdent leur propre gestion de métriques : par exemple, Apache Tomcat contient plus de 50 métriques, telles que l’accès au cache, le nombre de sessions rejetées ou acceptées, le nombre d’erreurs, le temps moyen de traitement de requête, etc.

L’Application Management consiste donc également à récupérer ces métriques dans un tableau de bord commun, ce qui peut se faire avec des logiciels comme Zabbix.

Pourquoi maîtriser le monitoring d’application ?

Maîtriser le monitoring d’application est une pratique capitale, en particulier pour les éditeurs de logiciels. Néanmoins, elle reste applicable à l’ensemble des entreprises, toute entreprise ayant une DSI et des applications à usage interne.

Le monitoring d’application permet de répondre à des questions clés concernant la production informatique :

• Les utilisateurs peuvent-ils utiliser mes applications, sans crash ni latence ?
• Y a-t-il des anomalies dans le comportement de mes applications ?
• Un hacker est-il en train d’essayer de pénétrer dans mon réseau par le biais de mes applications ?
• Les ressources consommées par mes applications sont-elles d’un niveau correct ?
• Comment améliorer la performance et la stabilité de mes applications ?

De ce fait, le monitoring d’application est une pratique nécessaire pour assurer la disponibilité, la performance, l’intégrité, la sécurité, la capacité et l’amélioration continue des applications.

Comment compléter l’analyse des outils de monitoring d’application

Le contrôle périodique de Corrium permet de renforcer le monitoring d’application avec son analyse de l’infrastructure IT.

Couverture de l’intégralité de la surface de supervision

Corrium permet d’obtenir la liste des applications utilisées sur le parc informatique ; cela permet de ne pas oublier d’application à surveiller lors du raccordement des applications aux outils de monitoring.

De plus, Corrium contrôle la pertinence de chaque application, afin de réduire le nombre d’applications inutiles : cela optimise l’infrastructure IT, et diminue la surface d’attaque qu’un hacker pourrait exploiter.

Analyse des applications grâce à la cartographie applicative

Avec sa base de connaissances Stratopédia, Corrium classifie les applications pour maintenir le parc applicatif : retirer les applications non utilisées, homogénéiser les versions, connaître l’obsolescence applicative (applications non à jour), et même identifier les applications non recommandées pour un usage professionnel (Spotify, jeux…)

Un impact monétaire peut également être évité, car Corrium donne également la liste des applications qui nécessitent une licence, ce qui réduit le risque de non-paiement et aide à être en règle vis-à-vis des licences.

Par ailleurs, Stratopédia permet à Corrium de signaler s’il y a des applications disposant de vulnérabilités (CVE), qui peuvent être une faille pour la cybersécurité du SI.

L’analyse intégrée détecte aussi les applications ayant un fort impact sur le démarrage, ce qui permet d’augmenter la performance des collaborateurs car le PC sera moins ralenti.

Amélioration de la visibilité

Les contrôles faits par Corrium permettent d’augmenter la maturité de l’infrastructure : en le combinant avec les outils de monitoring application, vous disposez alors d’une visibilité complète sur votre infrastructure IT.

L’analyse de Corrium permet ainsi d’avoir un schéma réseau de l’infrastructure, la liste des serveurs et PC, leur configuration, etc. Prendre des décisions vis-à-vis du parc informatique devient alors beaucoup plus facile.

Corrium est de ce fait un complément idéal à la supervision applicative, mais également à la supervision PC et serveur.

De meilleurs diagnostics

Enfin, étant un outil d’analyse, Corrium donne en sortie des avis et des préconisations concernant l’infrastructure IT et les applications : il est alors possible de corréler et comparer ces analyses avec ceux des outils de monitoring application, pour des prises de décisions plus sûres.

Cet article vise à guider les personnes en charge de la conformité du Règlement Général sur la Protection des Données. Il explique comment trouver les données personnelles de façon exhaustive.

Tout d’abord, les données personnelles constituent toutes les caractéristiques qui permettent d’identifier un individu : adresse, nom, prénom, … Le RGPD vise à mettre en place des mécanismes de suivi, d’organisation et de sécurisation des données collectées par l’entreprise – sur l’ensemble de la chaine de traitement où transite la donnée : de la personne externe donnant l’information aux sous-traitants. L’idée est de responsabiliser les entreprises face à l’utilisation de données personnelles.

Des nombreuses problématiques soulevées

Les entreprises ont de nombreuses difficultés à détecter tous les emplacements où la donnée personnelle est présente au sein du Système d’Information : la difficulté d’identifier l’ensemble des lieux de stockage ou des processus non-parfaits et donc non-maîtrisés dans leur intégralité.

• L’ancienneté des systèmes empêchent de localiser l’ensemble des flux de données
• Le manque de documentation nécessite de longs travaux de recherches
• La multitude d’interlocuteurs complexifie le travail
• Le faire de manière déclarative provoque parfois un décalage et un manque d’actualisation chez certaines entreprises.

Maîtriser l’infrastructure pour maîtriser les données

Les prérequis / objectifs de la localisation des données :

1. Tenir un registre de traitement: expliquant toutes les activités d’une entreprise qui manipulent les données utilisateurs, identifier les flux de données (de la collecte aux emplacements de stockage)
2. Sécuriser la donnée(utilisateurs et d’identification) : une donnée non localisée = non-maitrisée = non-sécurisée

Vous pouvez retrouver les prérequis nécessaires ici.

Les méthodes pour identifier tous les lieux de stockage de données pour une mise en conformité RGPD

Concernant les méthodes que vous pouvez utiliser, voici deux possibilités :

• TOP – Down: Partir des services fournis au client et suivre le parcours de la donnée dans les composants de l’IT et des sous-traitants. Par ailleurs, il existe quelques désavantages : comme un risque de non-couverture si la donnée a été copiée ou déplacée en dehors de la chaine de traitement par exemple.
• Bottom – UP: Partir de l’ensemble de mes composants informatiques et identifier où se trouvent des données utilisateurs et potentiellement des données personnelles. C’est un travail plus fastidieux, mais il permet de s’assurer qu’il n’y a pas d’erreurs.

Notre expert vous propose un focus sur la méthode pour le Bottom – Up ici.

Industrialiser la démarche Bottom-UP

Le constat que nous pouvons faire : La démarche Bottom-UP est fiable mais chronophage, laborieux, et risque d’être ratée s’il est fait par un humain.

2 actions permettent de garantir un résultat plus efficace et moins coûteux.

1. Optimiser : prendre appui sur le guide BP RGPD sur la sécurité

Pour accompagner les entreprises dans cette obligation, la CNIL a publié un guide de la sécurité des données personnelles.

Ce guide couvre à la fois les aspects organisationnels et techniques. Le respect de ce guide ne constitue pas une garantie de conformité RGPD, mais apporte un ensemble de bonnes pratiques à respecter pour s’assurer d’une bonne sécurisation des données, entre autres : sécuriser les postes de travail, serveurs, réseaux, sites web, …

Tout ceci aide à la maitrise de son IT et fait donc gagner du temps quand il s’agit d’identifier l’emplacement de la donnée.

2. Automatiser : avec l’audit automatisé Corrium pour la mise en conformité RGPD

La démarche à réaliser pour localiser la donnée personnelle perdue dans le SI peut s’avérer fastidieuse et les risques d’oublis sont élevés. Surtout si la collecte est réalisée manuellement. En effet, elle peut se trouver dans divers lieux de stockage :

• Sur les équipements stockant de la donnée
• Dans les applications
• Dans les bases de données
• Sur les partages réseaux
• Sur les applications Cloud
• Dans l’annuaire des utilisateurs et groupes
• Auprès des sous-traitants avec la même démarche : applications, partages, bases de données, …

L’outil Corrium répond à cette problématique en collectant de manière automatique la donnée sur l’ensemble des équipements et fournit des rapports permettant à l’IT d’agir tout de suite pour traiter ces données personnelles. Enfin, l’offre de contrôle en continu permet de répéter cette opération tous les trimestres pour s’assurer de ne manquer aucune donnée à caractère personnel.

Tout d’abord, dans un but de rationalisation de son infrastructure informatique, d’optimisation des coûts et même de gain de place il peut être intéressant de remplacer ses serveurs physiques par des serveurs virtuels : la virtualisation.

Néanmoins, ce travail nécessite un minimum de préparation. Il faut notamment faire une évaluation de la performance gagnée ou perdue par le serveur suite à la virtualisation. Il est également important d’évaluer les risques encourus lors de la migration en elle-même mais également des risques de ne pas virtualiser le serveur physique.

Ces évaluations permettent de définir l’éligibilité de virtualisation des serveurs. En fonction des résultats, la décision peut être prise pour certains serveurs physiques de ne pas les virtualiser en l’état.

Les avantages et inconvénients de la virtualisation des serveurs

Avant de détailler comment réaliser les évaluations, les tableaux suivants rappellent de façon générale les avantages et inconvénients de la virtualisation des serveurs.

Que faut-il analyser pour évaluer l’éligibilité à la virtualisation des serveurs

Chaque serveur a une configuration matérielle et système différente. De plus, chaque serveur héberge des services métiers différents, plus ou moins impactant pour l’activité de l’entreprise. Il est donc nécessaire d’évaluer au cas par cas l’éligibilité à la virtualisation des serveurs.

Evaluation 1 : Quel impact de la virtualisation sur les performances sur mon serveur ?

Tout d’abord, comme expliqué dans les inconvénients à la virtualisation, les serveurs hébergeant des bases de données sont généralement plus performants en étant installés directement sur un serveur physique.

Il faut ici identifier le profil du serveur à migrer en contrôlant les services hébergés. En effet, certains serveurs hébergent souvent plus de services que ce pourquoi ils existent. De plus, la documentation étant souvent incomplète ou pas à jour, il n’est donc pas suffisamment fiable de se baser sur cette documentation ou sur le nom DNS/NetBIOS du serveur.

Les éléments à contrôler pour identifier l’ensemble des services hébergés d’un serveur sont :

• Les rôles et fonctionnalités installés (pour les serveurs Windows)
• Les services actifs
• Les applications installées
• Les ports ouverts

En croisant l’ensemble de ces données on peut en déduire le profil du serveur (serveur Web, de messagerie, serveur de fichiers, …). On identifiera ainsi si des bases de données tournent sur le serveur et donc potentiellement, que les performances du serveur soit altérée suite à la virtualisation.

Evaluation 2 : Quels sont les risques de ne pas virtualiser le serveur ?

En fonction de certains critères, il peut devenir impératif de faire évoluer le serveur physique et son système pour éviter un incident (une interruption de service). Ne pas faire évoluer son système (via de la virtualisation par exemple) peut donc être un risque.

• L’obsolescence physique : Des composants vieillissants ont plus de chance de tomber en panne. De plus, ils sont plus sujets à des failles de sécurité. Virtualiser une telle machine permet de bénéficier d’un matériel plus récent.

 Ensuite, ce qu’il faut contrôler pour évaluer l’obsolescence physique :

• La date de sortie du processeur
• La date de sortie du BIOS
• Le type de disque dur (HDD, SSD)
• Le type de barrette mémoire et la quantité

• L’obsolescence système: De la même façon, un OS non supporté ne dispose plus des correctifs de l’éditeur. Le virtualiser permettra de l’installer sur du matériel récent sans problèmes de compatibilités. De plus, il sera plus simple de l’isoler via des switches virtuels par exemple et donc de compenser le manque d’update par l’isolement

Ensuite, ce qu’il faut contrôler pour évaluer l’obsolescence système :

• La version de l’OS (pour évaluer s’il est encore sous support éditeur)
• L’absence de sauvegardes: Un serveur non sauvegardé peut être sujet à des pertes de données définitives en cas de crash. La virtualisation permet à minima de sauvegarder son système via l’hyperviseur.

Enfin, ce qu’il faut contrôler pour évaluer l’obsolescence système :

• La présence d’agents de sauvegardes

Evaluation 3 : Quels sont les risques d’incidents lors de la migration du serveur ?

Enfin, le dernier aspect à contrôler est le risque qu’un incident ait lieu au moment de la migration (passage du serveur physique à virtuel en l’occurrence). Lors d’un incident les services hébergés par le serveur peuvent devenir inactif ce qui peut avoir des répercussions sur le Business de l’entreprise.

L’idée est donc indispensable de connaitre « le poids Business » du serveur physique pour en déduire l’impact en cas d’incident lors de la migration.

Pour cela un profilage du serveur doit être fait et les éléments à contrôler sont les mêmes que l’analyse d’impact sur les performances.

Il pourrait être défini qu’un serveur physique concentrant une multitude de services à fort impact Business ne soit pas virtualisé en l’état. L’une des solutions sera de découper ce serveur en plusieurs machines virtuelles hébergeant séparément chacun des services à fort impact Business. L’avantage de la virtualisation c’est que ça ne consommera pas plus de matériel.

Enfin, les serveurs physiques dont le stockage est externalisé (sur des NAS, SAN, baies de stockages) représentent un risque d’incident plus faible que les serveurs tout en un.

Optimiser l’évaluation via l’automatisation

Une fois les 3 types d’évaluations réalisées, il faudra mettre les résultats en parallèle sur chaque serveur physique et ainsi déduire son éligibilité à la virtualisation.

Réaliser ces opérations unitairement sur un serveur est possible. Cependant cela nécessite la présence d’un administrateur système et qui a le temps de faire ce travail de collecte et d’analyse. Si l’infrastructure serveur n’est pas maitrisée ou si la quantité de serveur à évaluer est importante, il devient rapidement utile et moins couteux d’automatiser ce travail chronophage.

Cet article vise à vous donner des pistes d’actions pour garder une infrastructure fiable, même en période de réduction du budget informatique.

Plusieurs formes de restrictions :

• Tout d’abord, cela peut constituer une réduction de l’équipe: vos ressources humaines diminuent contrairement à votre périmètre à traiter qui reste identique.
• Ensuite, cela peut concerner une augmentation du périmètre: avec des ressources en personnel inchangées (un projet de migration, l’augmentation des personnes à distance, un projet d’augmentation des serveurs, …)
• Faire plus avec moins: enfin, parfois les restrictions peuvent représenter par un périmètre augmentant et le personnel diminuant

Face à ces différents contextes, votre périmètre augmentant ou pas, la quantité de travail s’alourdit sur le personnel informatique. Face à cela, il est important de travailler sur les problématiques budgétaires, sur la composition du budget.

La composition du budget informatique

Le budget de l’infrastructure est composé de deux parties : le BUILD et le RUN.

• Le BUILD repose sur vos projets futurs (dans un mois comme dans un an). C’est la partie fonctionnelle et développement qui est souvent plus importante que l’infrastructure : prévoir une nouvelle architecture de virtualisation, un nouveau système de liens entre sites distants, des migrations. C’est ce que l’on fabrique pour les utilisateurs (run).
• Le RUN est le fonctionnement du quotidien. L’infrastructure est donc plus grande que le développement (peut consister à être le support pour une nouvelle application par exemple).

 Ce schéma ci-dessous synthétise ces différents éléments :

Ici, on cherche à savoir comment maîtriser la partie infrastructure. Celle-ci est composée de :

• les composantes humaines (ressources humaines avec salaires, prestations externes, …),
• la partie matérielle (achat de machines, maintenance des serveurs, localisation de liens réseaux, …)
• et la partie logicielle (licences, maintenance support, …)

Vous devez donc prendre le temps d’identifier toutes ces parties.

La méthode itérative d’amélioration, pour assurer fiabilité et répondre aux exigences utilisateurs

La méthode itérative d’amélioration, similaire à la méthode PDCA (Plan, Do, Check, Act) en sécurité, consiste à créer des périodes pendant lesquelles vous planifiez, effectuez, contrôlez et corrigez. L’idée est d’avoir une méthode circulaire indéfinie.

Concernant la période, nous vous recommandons de fonctionner par trimestre.

Au début du trimestre :

1. Constats de départ
2. Définition des objectifs
3. Définition d’un plan d’action
4. Vous avez 3 mois pour les mettre en œuvre

A la fin du trimestre :

5. Faire un contrôle pour savoir si les objectifs sont atteints

Et ainsi de suite

6. Basé sur Corrium, nous vous recommandons, comme dans notre produit, de faire un quick check (suivi du plan d’action) chaque mois. Il permet de connaître l’ajustement et donc de corriger si besoin.

D’autres solutions pour conserver faire face aux restrictions de budget informatique

Piloter ses équipes avec des objectifs et des indicateurs

Afin à une réduction de budget informatique et une quantité de travail plus importante, il est important de guider ses équipes. Ainsi, elles sauront ce que vous attendez d’eux. Leur donner des objectifs avec des indicateurs concrets permettra de leur faciliter le travail, et à vous, de suivre les actions.

Par exemple, si la direction décide de réduire de 10% le nombre de serveurs, l’indicateur à suivre sera tout simplement le nombre de serveurs aujourd’hui et celui dans un an. Pour atteindre cet objectif, vous pouvez décider de diminuer cet indicateur de 5% sur le premier trimestre, puis 5% supplémentaire pour le deuxième.

Il est important de valoriser le travail de vos équipes techniques : comme elles ont beaucoup de travail, il est important de les encourager pour garder la motivation. Vous devez aussi valoriser leur travail auprès de la direction avec des éléments factuels/des indicateurs pour avoir conscience du travail. On pourrait appeler cela : valoriser le travail de l’ombre et sa qualité.

Les bons éléments pour argumenter son budget informatique

Si vous souhaitez soutenir un budget, il est très important de l’argumenter. Pour cela, vous devez aborder des éléments factuels qui vont permettre à votre dirigeant de décider. Soyez synthétique, précis et proposer des solutions. Analysez les services vitaux pour les métiers et faites une analyse de risques.

De plus, vous pouvez utiliser un outil de benchmarketing pour diagnostiquer votre DSI en la comparant à une entreprise égale en termes de périmètre (nombre de serveurs, collaborateurs, …) ou en termes de CA pour appuyer votre besoin.

Améliorer la partie matérielle

Plutôt que de changer vos matériels, vous pouvez certainement upgrader vos machines. Pour les PCs, vous pouvez jouer sur la RAM, le SSD ou encore la Carte graphique. Ainsi, vous pourriez gagner 12 voire 18 mois. Cela permet d’étaler vos dépenses. D’un point de vue écologique, vous retardez la production d’une nouvelle machine. De plus, vous n’avez pas de coût de migration ni besoin de réinstaller la machine.

N’hésitez pas non plus à faire tourner vos machines de bureau : les PCs des développeurs peuvent faire de très bonnes machines pour des utilisateurs qui font du Word/Excel.

Décommisionnez les serveurs inutiles, va vous permettre de gagner de l’espace disque, la réutilisation pour des bases de données. Entreprendre ce projet est un coût au départ : identifier les machines, planifier, mettre en œuvre mais économique face à l’achat de nouvelles machines.

Pour conclure, afin d’optimiser votre budget informatique, voici les principaux axes à prendre en compte :

Cet article vise à vous sensibiliser de l’importance de l’obsolescence informatique physique et comment évaluer les impacts liés.

Pour rappel, une machine obsolète est une machine dont les composants physiques sont trop anciens, la performance est dégradée et où la conformité par rapport à la politique de la DSI n’est plus en accord. Elle est donc contextualisée par rapport à l’entreprise. L’obsolescence physique est la somme de l’ancienneté des composants et la conformité par rapport à la politique de la DSI.

On mesure l’obsolescence physique pour :

• Identifier les équipements ne respectant pas la politique de la DSI
• Diminuer les risques
• Mettre en en conformité son matériel / Renouveler son parc
• Prévoir les futurs dépenses

Il existe 4 critères permettant d’évaluer l’obsolescence d’une infrastructure IT : la performance, la sécurité, l’empreinte écologique et le coût / valeur du parc.

En fonction des objectifs de l’entreprise, tous les critères ne seront pas forcément concernés. Une organisation soucieuse de son empreinte environnementale jugera ce critère comme important. Une société non-concernée sera davantage intéressée par le coût de ses machines et jugera par rapport à cela l’obsolescence.

La performance liée au confort d’utilisation et à la productivité

A défaut d’avoir une supervision complète de son parc PCs, l’aspect humain est très important. La DSI doit donc identifier les besoins des collaborateurs, par métier : créer des profils, faire des personae, faire des enquêtes sur l’utilisation du PC. Ainsi, elle saura quelle machine est utile pour tel profil. Cet aspect est primordial pour le côté performance.

Ensuite, grâce à cette évaluation, on pourra déterminer la durée moyenne d’utilisation. Un graphiste aura un PC qui sera potentiellement plus renouvelé puisqu’il aura besoin de performances graphiques plus élevées.

Il est important de mettre en place un système de feedback. Les collaborateurs gagneront en confiance de la DSI le jour où un dialogue entre les deux se crée. De plus, la DSI pourra mesurer la qualité de ses services auprès des collaborateurs : le nombre de tickets générés auprès de cette catégorie d’utilisateurs par exemple permettra d’effectuer des actions en conséquence.

La DSI a besoin de savoir ce qui est présent sur le parc : les configurations complètes, précises et factuelles de l’ensemble. Connaître son infrastructure permet donc aussi de déterminer quand changer les machines. On arrive donc à créer un cercle vertueux :

• Avoir des remontées utilisateurs
• Identifier les catégories d’utilisateurs et savoir comment leur répondre avec le type de matériel adéquat
• Déterminer si le parc est obsolète par rapport à leur usage

Le service marketing peut utiliser des applications pour le traitement de texte. Par ailleurs, si les collaborateurs affectés à ce service créent aussi des vidéos, il faudrait donc réfléchir à ajouter de la mémoire en plus ou un processeur plus performant pour une meilleure utilisation, par exemple : PC plus performants = gain de temps = meilleur confort.

La sécurité pour pallier l’obsolescence informatique physique

Une machine n’est ni plus ni moins du matériel avec des micrologiciels. Ces micrologiciels peuvent être faillibles (voir les CVE, bibliothèque répertoriant les vulnérabilités logicielles et matérielles). Ces failles peuvent être dues à leur ancienneté, le manque de mises à jour (firmwares, BIOS, …). Il est donc important de bien choisir son matériel. Par ailleurs, le matériel ne fait pas tout. Les systèmes d’exploitation sont aussi importants. Il faut mettre à jour les logiciels, proposant des améliorations pour corriger les failles, via les drives, le système d’exploitation ou encore les microfirmwares comme le BIOS. Le changement de matériel n’est pas toujours synonyme de sécurité, c’est un ensemble.

L’empreinte écologique, du point de vue de l’usage

Certains se demandent s’il est mieux de changer tous les ans son matériel pour éviter l’obsolescence d’un point de vue écologique ou pas ? En effet, depuis quelques années, les consommations du processeur ont été divisées par deux, pour une puissance égale. Le coût à l’usage est donc plus important d’un point de vue écologique (consommation électrique) et un coût à l’achat (on demande à récréer une machine d’un point de vue production). Il faut donc corréler la performance par rapport à l’utilisation. Le PC du développeur devant être changé à cause des performances, peut être donné à un marketeur qui n’aura pas besoin d’autant de performances. On assiste là à un système de recyclage : le matériel n’étant plus suffisant pour un profil, peut l’être pour un autre.

Le ratio Coût / Valeur du parc pour calculer l’obsolescence informatique

Pour réfléchir à l’obsolescence relative à son parc, nous voulons que le coût soit moindre et qu’il apporte le plus de valeur possible aux utilisateurs. En fonction de vos critères d’importance, vous devriez adapter votre travail. Si vous ne souhaitez pas changer de machines régulièrement, des coûts de maintenance sont à prévoir et parfois tierces, donc plus onéreuses. Une machine n’ayant pas des performances optimales dégradera la productivité et le temps sera donc plus conséquent d’un point de vue financier. Vos choix seront déterminés à partir de votre stratégie.

Développer sa stratégie de renouvellement

Après avoir mis en place les profils types, pris en considération les différents éléments, vous pourrez mettre en place une stratégie de renouvellement :

• Les développeurs changeront de machines tous les X temps
• Leurs PCs pourront être recyclés auprès de tel profil
• En fonction de la maintenance, est ce que je choisis d’avoir du matériel d’avance, ou pas

Par exemple, pour le modèle du processeur, Corrium identifie la date de sortie et peut donc calculer l’âge du processeur.

A partir des différents critères, des ratios d’obsolescence sont appliqués par critère, à la machine, puis à toutes les machines pour connaître l’obsolescence physique du parc entier.

Voici un exemple de livrables Corrium relatif à l’obsolescence physique :

Une fin de support Windows ou Linux peut avoir beaucoup d’impact. Découvrez quels sont ces impacts ? Les risques encourus ? Comment fonctionne ces supports ?

Qu’est-ce que le support d’un OS

Le temps de support est la période durant laquelle un système d’exploitation est maintenu par son éditeur. Nous verrons que chaque éditeur a sa stratégie mais nous pouvons dire qu’en général, la politique de support se fait par phase.

Le système d’exploitation est une partie essentielle au bon fonctionnement de son infrastructure. C’est une couche technique qui est le terreau des applications et donc de la valeur ajoutée à son business. C’est donc une brique technique mais qui est incontournable.

Que ce soit le système d’exploitation serveur, utilisateur ou même embarqué, son choix est vite imposé par les contraintes applicatives, budgétaires ou politiques. Néanmoins, on oublie souvent de prendre en compte le temps que ce Système d’Exploitation sera supporté. Nous verrons que ce détail a des incidences sur la sécurité et l’évolutivité de son infrastructure.

Stratégie de support Windows

Globalement le cycle de vie des systèmes d’exploitation Windows s’articule autour de 3 périodes :

• Période 1 : entre le lancement du produit et la première date de fin de support Windows. C’est la période où la maintenance est pleine. Nous avons les améliorations fonctionnelles, les bugs, les patchs de sécurité.
• Période 2 : entre la fin de cette période 1 et la date de fin de vie du produit (end of life). C’est la maintenance est partielle qui est focalisée sur les bugs bloquants et les patchs de sécurité. Donc sans plus aucunes améliorations fonctionnelles.
• Période 3 : entre la fin de la période 2 et la fin de votre budget pour cette maintenance. En effet, Microsoft propose une extension de support moyennant une contribution financière.

L’ordre de grandeur entre les périodes 1 et 2 est d’environ 5 années jusqu’à l’avènement de Windows 10 où avec ce dernier ses sous-versions ont accéléré les fins de support de l’ordre de 2 ans. Le cycle de vie de Windows 10 est donc plus bref. Sauf pour les versions spécifiques de Windows 10 estampillées LTSB (Long-Term Servicing Branch) et LTSC (Long-Term Servicing Channel). Ces dernières versions respectent le cycle de vie habituel d’environ 10 ans découpé en 2 période d’environ 5 années.

Cette dernière notion de LTS (Long Term Support) est donc primordiale à avoir en tête lors d’un choix d’un OS (et aussi d’une application).

Stratégie de support des grandes distributions Linux

Le cas Redhat

Les familles de système d’exploitation RedHat Enterprise Linux ont un cycle de vie long (environ 10 ans) quelque soit les versions utilisées :

• Période 1 : entre le lancement et la première date de fin de support. C’est la période où la maintenance est complète. Toutes améliorations fonctionnelles, bugs, patchs de sécurité ou encore drivers sont publiés.
• Période 2 : pour les versions 5, 6, 7 de Redhat uniquement. C’est une petite période, d’environ 1 an, où les bugs bloquants, les patchs de sécurité sont publiés, ainsi que quelques drivers pour certains matériels.
• Période 3 : support plus léger qui ne concerne que les bugs bloquants et les patchs de sécurité.
• Période 4 : support restreint qui est étendu par le biais d’un abonnement commercial après la date de fin officielle pour continuer les patchs de sécurité ainsi que les bug bloquants uniquement.

Le cas Ubuntu

Les familles de système Ubuntu ont un cycle de vie un peu plus frénétique d’une durée de 6 mois entrecoupées par des versions estampillées LTS. Ainsi une version non-LTS ne sera supportée qu’un peu moins d’un an. Par contre une version LTS sera quant à elle supportée pendant 5 ans. Cette période se veut unique et complète en termes de bugs corrigés, d’améliorations fonctionnelles ou de patchs de sécurité. Cette distribution est tout de même tributaire du support de Debian en se basant notamment sur ces repos ‘testing’ pour une version donnée.

Les incidences de la fin de support OS sur mon infrastructure

Comme nous venions de le dire, la fin de support Windows ou Linux expose à ces risques :

• risque sur la sécurité de mon infrastructure
• risque sur ma capacité à faire évoluer mon infrastructure

Risques liés à la sécurité 

Le risque majeur lorsque que mon système d’exploitation n’est plus supporté par l’éditeur est le fait que toute nouvelle attaque trouvée sur ce système ne sera pas colmatée. Certes, nous avons pu voir que certains éditeurs ont patché des failles importantes après la fin officielle du support mais cela reste exceptionnel.

Il est donc important pour la santé de son infrastructure de mettre à jour les différents patchs de l’éditeur, mais surtout que ces mises à jour soient encore disponibles.

La chance que nous ayons, est que les éditeurs ont globalement une stratégie identique quand il s’agit de la sécurité. C’est la période la plus longue qui est proposée par l’éditeur. Prenons l’exemple de Windows 7, ses phases de support se présentent ainsi :

• Phase 1 : maintenance complète : correction de bug, ajout de fonctionnalité et patch de sécurité, date de fin : 13 Janvier 2015
• Phase 2 : maintenance partielle : correction de bug uniquement bloquant et patch de sécurité, date de fin : 14 Janvier 2020

Windows 7 a été disponible au grand public le 22 Octobre 2009. Nous avons eu un support d’un peu plus de 10 ans pour l’aspect sécurité. Néanmoins, dès lors que le support a pris fin, déjà que les risques liés à la sécurité sont grands même en période de support, sans maintenance nous nous exposons à un risque démultiplié.

Evolution de mon infrastructure

Ce n’est pas un scoop, l’évolution des technologies et autres fonctionnalités ne font qu’évoluer dans le domaine IT. Chaque jour avec son lot de nouveautés. C’est d’autant plus vrai d’un point de vue des applications qui se basant sur des capacités à la fois matérielles et OS.

Il est donc important de pouvoir utiliser ces nouveautés lorsqu’elles ont un réel impact sur son business. La veille est donc primordiale. Mais afin d’aller le plus rapidement sur ce chemin, il faut que les briques les plus basse de son infrastructure soient solides et suffisamment récentes ou pouvant être facilement mises à jour.

Ainsi si nous reprenons nos phases décrites plus haut, pour maximiser les chances d’avoir cette nouveauté le plus rapidement possible dans notre infrastructure, c’est d’être dans la phase 1. Tout dépend si l’éditeur aura joué le jeu mais globalement nous en maximisons les chances. C’est bien durant cette phase que de nouvelles fonctionnalités peuvent être poussées par l’éditeur.

Tout d’abord, l’obsolescence IT donne souvent une vision d’ancienneté. Par ailleurs, il faut savoir que cela peut être plus complexe et dépasser cette seule notion d’ancienneté. Un produit obsolète est un produit dépassé qui perd une partie de sa valeur d’usage (la valeur perçue par l’utilisateur). Cela est souvent lié aux évolutions techniques.

On peut distinguer deux notions :

• L’obsolescence indirecte, induite par l’impossibilité de réparer ou ne peut plus être mis à jour.
• L’obsolescence psychologique, souvent liée aux effets de mode ou à la mise en avant de nouveaux produits sur le marché paraissant plus efficaces et plus séduisants, notamment à cause de la publicité.

Pourquoi évaluer l’obsolescence IT dans une organisation

Des raisons budgétaires

Tous les ans, vous avez besoin de prévoir le budget de l’an prochain. Parfois, vous avez même besoin de voir plus loin, avec une vision à 3 ans, en lien avec les matériels, les systèmes mais aussi les migrations à prévoir.

Répondre aux besoins de vos utilisateurs

Effectivement l’informatique étant généralement en support du business, il est essentiel de fournir des services de qualité : en termes de performance et d’usage dont ils ont besoin.

Assurer la sécurité de votre organisation

Face aux enjeux grandissants des organisations et à l’augmentation des attaques, vous devez assurer une totale maîtrise de vos machines. Parfois, une machine satisfait amplement les besoins de l’utilisateur, celui-ci en est content mais peut tout de même constituer une faille due à un manque de mises à jour par exemple et doit donc être changée.

Prévenir les changements organisationnels

Le jour où l’entreprise grossit, il faut s’assurer que vos machines (notamment les serveurs) supportent cette croissance. Vous devez donc vous assurer que votre infrastructure est capable de faire face à ces changements et notamment aux usages des utilisateurs.

Les critères d’obsolescence

Nos experts ont mis en place un référentiel synthétisant les différents critères à considérer pour parler d’obsolescence :

1. L’usure : une machine trop ancienne, des disques durs trop anciens faisant trop de bruit par exemple, sachant que l’usure peut arriver plus vite en fonction de l’usage
2. Les fonctionnalités offertes, des besoins en fonctionnalités non-couverts par votre machine actuelle
3. Le coût de fonctionnement, des machines peuvent parfois coûter trop cher à migrer ou à utiliser
4. L’incompatibilité, un manque de compatibilité avec les nouveaux entrants par exemple
5. La capacité, la montée en charge notamment pour les serveurs lorsque la taille de l’entreprise augmente, des machines consommant trop d’électricité, …
6. La sécurité, un critère indispensable

Pour analyser correctement l’obsolescence de votre infrastructure informatique, nos experts conseillent d’analyser chaque couche – à savoir, les matériels puis les systèmes puis les applications, puis l’architecture avec le réseau notamment.

Déterminez les critères adéquats

Les ratios d’obsolescence

Avec Corrium, notre robot d’analyse, nous avons mis en place des ratios d’obsolescence IT de 1 à 10. On considère que lorsque le ratio atteint 6, il faut faire des changements.

Ces ratios sont basés sur l’âge de la machine :

• le CPU,
• le BIOS, s’il est à jour (performance et sécurité)
• la capacité (RAM),
• l’espace disque disponible,
• …

Les critères de changement d’une machine

Nous avons élaboré une liste de critères qui indique que vous devriez changer de machine

• Elle est amortie
• Elle n’est pas upgradable
• Elle coûte trop cher à mettre à jour
• Elle ne comporte pas de vulnérabilité
• Elle est incompatible avec les nouveaux matériels
• Elle est incompatible avec les nouveaux logiciels

Déterminez vos seuils

Pour assurer vos propres critères d’obsolescence IT, vous devez déterminer :

• Le seuil de sécurité
• Le seuil de performance
• Le seuil budgétaire
• Le seuil de fonctionnalité

 Depuis quelques années, nous avons vu monter en puissance un critère lié à l’environnement – le critère de responsabilité environnementale. En effet, si vous changez une machine qui n’avait pas besoin de réelle modification, vous demandez à en créer une nouvelle machine et vous avez donc un coût écologique élevé.

Lutter contre l’obsolescence matérielle

Pour prévenir et lutter contre une obsolescence IT précoce, nous vous conseillons de :

1. En amont :

• Choisir des produits plus solides et réparables pour optimiser leur maintenabilité
• Acheter des machines puissantes pour augmenter leur usabilité

2. En cours de vie :

• Faire tourner les machines entre vos différents utilisateurs. Un PC obsolète pour un développeur ne sera pas forcément obsolète pour un technicien.

3. En fin de vie :

• Upgrader les machines

En fonction de vos choix budgétaires, vous déterminerez quoi faire. En effet, il est parfois plus judicieux d’acheter une machine avec un processeur plus important, qui aura une durée de vie plus grande.

Établir un scan réseau vous permet d’identifier l’ensemble des hôtes présents, les machines présentes sur votre parc et ainsi cela vous permet de maîtriser votre infrastructure IT.

Au-delà de cela, cela vous permet d’identifier si du Shadow IT est présent. Pour rappel, le Shadow IT correspond aux éléments présents sur votre infrastructure que vous n’avez pas autorisé : machines, logiciels, applications, … Avec le scan réseau, vous pourrez donc identifier l’ensemble des éléments présents sur votre parc, vérifier si c’est normal qu’ils soient présents et s’assurer que les machines soient à jour.

En effet, une machine non-autorisée sur votre parc est une faille. Une machine non-autorisée et non mise à jour est une double faille pour votre infrastructure.

L’obsolescence système

L’obsolescence système concerne essentiellement les OS. Pour identifier leur obsolescence, vous devez regarder s’ils sont toujours supportés par l’éditeur.

A savoir, il y a deux notions à distinguer lorsque l’on parle de support :  

• La date de maintenance support: les mises à jour sont publiées à tout le monde par Microsoft par exemple
• La date d’extension de support: le support est accessible uniquement aux entreprises ayant souscrits au support étendu sauf pour les mises à jour de sécurité qui sont publiées pour tout le monde par Microsoft  

Le RGPD et le rôle du DPO

Pourquoi fournir une cartographie applicative au DPO ?

Depuis plus de deux ans, les sociétés doivent définir un Data Privacy Officer, une personne responsable des traitements des données personnelles qu’elles utilisent. Ainsi, dans le cadre du Règlement Général sur la Protection des Données, cette personne doit être en mesure de gérer, lister, identifier et maîtriser tout type de traitement de ces données.

Pour cela, elle peut faire appel au responsable informatique de l’organisation pour obtenir la liste de ces applications pour ainsi identifier les traitements plus facilement.

Or, nous avons pu remarquer que le responsable informatique de l’organisation a parfois du mal ou n’est pas en mesure de fournir une liste complète et bonne des applications qui utilisent ces données personnelles.

La difficulté pour les responsables IT de donner une visibilité claire des applications déployées sur le parc et de l’emplacement des données

En effet, il arrive que les responsables IT aient des difficultés à donner une vision claire des applications. Pour répondre à cette problématique, il est possible de créer une cartographie applicative. Mais alors, comment le responsable IT peut fournir une cartographie applicative utile au DPO ?

La cartographie applicative pour aider le DPO

Une cartographie applicative liste l’ensemble des applications du parc informatique. Elle vise à établir un catalogue recensant le patrimoine applicatif de l’entreprise en soulignant les interactions entre applications ou composants d’applications, leur description ainsi que les données échangées.

La cartographie applicative permet donc de savoir quelles sont les applications de votre parc, où se trouvent-elles (serveur, PC), et ainsi permet d’identifier la localisation (l’utilisateur associée à la machine et le lieu où se trouve la machine). En fonction des pays, les droits et devoirs concernant l’utilisation des données peuvent être différents.

Il existe deux façons de constituer une cartographie applicative :

• Dans les grandes organisations, vous partez de très haut niveau et vous appliquez un plan d’occupation des salles grâce à un urbaniste du système d’information. Son rôle est de comprendre l’architecture métier, les besoins métiers et ainsi comprendre l’infrastructure. Par ailleurs, en partant du haut et descendant, vous pouvez avoir un fort décalage avec ce qui est déployé en réalité. (TOP DOWN)
• En partant du bas, vous pourrez réfléchir à quelles sont mes infrastructures, ce qu’il y a dessus, quelles sont les serveurs présents, les applications présentes. Cette démarche s’applique davantage à ceux qui n’ont pas les moyens d’avoir un urbaniste et qui n’ont pas forcément le temps (BUTTOM UP). En partant de l’existant, on regarde ce que l’on a au niveau des réseaux, puis quels sont les matériels présents, quelles sont mes applications et ainsi pouvoir les relier derrière aux besoins fonctionnels.

Chez Straton IT, nous utilisons pour notre produit Corrium, une démarche se rapprochant de la méthode OBASHI (Owner Business Applications System Hardware Infrastructure). En plus des domaines fonctionnels, des traitements, des applications, des systèmes, des matériels et réseaux, nous ajoutons la notion de sites et de bâtiments qui est très importante – la zone géographique étant très importante pour l’identification des données personnelles et la conformité RGPD. Puis, nous analysons quels sont les espaces de stockages, quelles sont les bases de données et où sont les applications pour analyser les traitements relatifs au RPGD. Enfin, nous analysons aussi les flux réseaux et identifions les flux applicatifs.

Pour illustrer à quoi ressemble et vous sert une cartographie applicative, voici ce schéma :

1. Liste des machines
2. Descriptif des applications présentes sur chaque machine (quelles applications, quelle version, …)
3. Catégorisation de chaque application (multimédia, sécurité, bureautique, …)

Ainsi vous pourrez identifier chaque application, valider ou non sa présence, avoir accès à l’emplacement de l’application (sur les machines précisément). Au niveau RGPD, la catégorie d’applications que vous allez considérer davantage est celle des bases de données.

Utiliser la cartographie applicative pour favoriser le travail du DPO

Voici une méthodologie pour identifier les applications concernées par le RGPD et ainsi localiser plus facilement la donnée.

Identifier le poids RGPD de chaque application

1. Pour cela, vous pouvez établir un scoring :

• 0 = N, l’application n’est pas concernée par le RGPD
• 1 = P, l’application est partiellement concernée par le RGPD
• 2 = L, l’application est largement concernée par le RGPD
• 3 = F, l’application est complètement concernée par le RGPD

2. Ensuite, vous déterminez la présence de chaque application (le taux de couverture).
3. Puis, vous pouvez mesurer l’éparpillement des versions des applications

• Homogénéité : vous disposez des mêmes versions d’applications (la cible étant 100%)
• Dilution : vous disposez d’un éparpillement des versions d’une application (la cible est 0%)

4. Ainsi vous saurez si vous êtes concernés ou pas

Identifier le poids des applications sur votre parc informatique

D’autres indicateurs globaux vous donneront de précieuses informations sur l’état de votre parc :

• Le taux d’uniformisation: permet de savoir si vous utilisez les mêmes applications, la même version. Il doit être le plus proche de 100%
• Le poids applicatif (RGPD) des machines: correspond à la somme des applications classées RGPD*leur coefficient RGPD (leur importance)
• Le contrôle des versions: via le taux de couverture, correspond au % de PC utilisant cette version de l’application

Constituer un classement des applications

A partir de différents critères, vous pourrez les classer selon des similitudes, les voici :

Les types d’applications à identifier

Cette liste est non-exhaustive mais vous permet d’identifier un certain nombre d’applications concernées :

• Bases de données (serveurs),
• Bases de données sur des postes (Access, Excel, …),
• Partages de fichiers,
• Drives,
• Outils de requêtage,
• Outil de reporting,
• Drivers ODBC,
• Outils d’administration de BDD,
• Transfert de données,
• …

Tout d’abord, depuis mai 2018 l’ensemble des sociétés traitant des données à caractère personnelle des européens doivent respecter la loi RGPD (Règlement Général sur la Protection des Données). Il s’agit là de mettre en place les mécanismes de suivi, d’organisation et de sécurisation des données collectées permettant d’identifier un individu. Ceci sur toute la chaîne par laquelle transite la donnée, incluant également les sous-traitants. Pour cela, vous pouvez réaliser un audit RGPD pour assurer conformité.

Tout d’abord, la loi RGPD impose principalement aux entreprises de :

Localiser la donnée : un véritable enjeu pour les DSI

Une difficulté rencontrée par les entreprises désireuses de se conformer au RGPD est d’identifier tous les emplacements au sein du Système d’Information où de la donnée personnelle est présente. En effet, les architectures existantes sont parfois (très) anciennes et imparfaites. De plus, la quantité de personnels IT est souvent limitée. Ces 2 facteurs empêchaient déjà de maîtriser son existant avant l’audit RGPD, l’obligation contraint à présent les entreprises de trouver des solutions à cette problématique.

Cette étape de localisation de données est néanmoins indispensable. En premier lieu pour créer le registre de traitement, il faut pour chaque activité de l’entreprise, identifier les données à caractère personnel utilisées. Le flux de la donnée doit être maîtrisé, depuis sa collecte jusqu’à ses emplacements de stockage dans le système d’information ou chez les sous-traitants.

Localiser la donnée est également indispensable pour la sécuriser comme l’impose le RGPD et éviter toute violation.  Il va de soi qu’une donnée non localisée est par conséquent non-maitrisée et donc non-sécurisée.

Pour accompagner les entreprises dans cette obligation, la CNIL a publié un guide de la sécurité des données personnelles.

Ce guide couvre à la fois les aspects organisationnels et techniques. Le respect de ce guide ne constitue pas une garantie de conformité à l’audit RGPD, mais apporte un ensemble de bonnes pratiques à respecter pour s’assurer d’une bonne sécurisation des données.

La CNIL ne fournit cependant aucune aide pour localiser les données personnelles et éviter les absences dans le registre de traitement. Ce travail est à réaliser en pleine conscience par l’entreprise pour éviter toute fuite de donnée.

Où chercher pour trouver l’exhaustivité des données personnelles ?

Voici la suite des actions à mener pour localiser les données personnelles sans oubli.

1. Inventorier l’entièreté de son infrastructure et des équipements stockant potentiellement de la donnée

C’est la première étape, primordiale. Quels équipements composent mon infrastructure et lesquels sont des équipements amenés à stocker de la donnée utilisateur ? Il faut ici récupérer la liste de ses serveurs, postes de travail, tablettes, baies de stockage, SAN, NAS, serveurs de backup… Le tout sur l’ensemble de ses réseaux.

2. Effectuer une cartographie applicative

Récupérer la liste de toutes les applications métiers installées sur les PC et sur les serveurs pouvant manipuler de la donnée utilisateur.

3. Inventorier les bases de données

Lister toutes les bases de données installées sur l’infrastructure pour cibler où trouver de la donnée personnelle.

Cette étape répond à la question « Où sont mes données ? ».

4. Inventorier les partages réseaux

 Identifier tous les lecteurs réseaux et dossiers partagés sur les serveurs et sur les postes. Ils peuvent contenir des fichiers et des listes de données à caractère personnel.

Cette étape répond également à la question « Où sont mes données ? ».

5. Inventorier les applications Cloud

Identifier les applications Cloud utilisées par l’entreprise et particulièrement celles de stockage : Google Drive, Dropbox, OneDrive…

Cela répond à la question « Où vont mes données ? ».

Il est intéressant ici de scanner les postes des utilisateurs pour identifier si des applications Cloud non-validées par l’entreprise sont utilisées avec, de fait, une éventuelle fuite de données personnelles.

6. Inventorier les utilisateurs, les groupes et les autorisations d’accès.

Pour chaque élément des 5 premières étapes, l’idée est de récupérer les utilisateurs qui ont des accès et leur niveau d’autorisation. Cela nécessite de parcourir à la fois l’annuaire LDAP, s’il y en a un, ainsi que les comptes locaux sur les machines, les applications, les bases de données et les partages réseaux.

 7. S’assurer que les sous-traitants appliquent cette même démarche.

Enfin, si le flux de la donnée l’amène sur des systèmes non-propriétaires de la société traitant avec l’utilisateur (emplacement Cloud par exemple), il s’agira de s’assurer que chaque sous-traitant concerné ait également effectué ce travail de recherche puis de sécurisation de la donnée.

Une fois que la liste des emplacements de stockage de données est exhaustive, l’étape suivante est d’identifier pour chaque emplacement les données utilisateurs puis plus précisément les données à caractère personnel. Enfin il faudra mapper ces données avec les traitements métiers pour compléter ensuite le registre de traitement des données.

Ce travail final se fait via 2 approches :

1. Top-Down : Partir du traitement métier et descendre dans l’architecture des composants du service concerné pour en déduire les emplacements de stockage
2. Bottom-Up : Se baser sur les emplacements de stockage et remonter l’infrastructure pour trouver quels traitements métiers utilisent cet emplacement

Dans toute entreprise, les collaborateurs doivent accéder à plusieurs applications :

• le compte Windows,
• les portails web internes de l’intranet,
• le VPN (très fréquent avec le Covid-19), …

Pour assurer une sécurité, l’accès à chacune de ces applications doit se faire avec un système d’authentification et d’autorisation, avec par exemple, un nom d’utilisateur et un mot de passe. Découvrez quelle est l’importance de la centralisation des comptes utilisateurs.

Tout d’abord, ll existe deux façons de gérer cet accès. Le premier est un système décentralisé : on laisse chacune des applications gérer son propre système d’authentification.

Le deuxième est un système centralisé : les applications consultent un seul et même système d’authentification afin d’unifier les procédures de connexion.

Découvrez comment démontrer pourquoi la centralisation des comptes utilisateurs est préférable, en améliorant la sécurité. Puis, retrouvez diverses solutions pour mettre en place un tel système.

La décentralisation, plus sécurisée ?

Décentraliser les comptes utilisateurs peut paraître plus sécurisé : cela permet aux utilisateurs d’utiliser des mots de passe différents. Si le mot de passe du système centralisé est compromis, l’attaquant peut pirater le compte sur toutes les applications. Par ailleurs, sur un système décentralisé, il ne serait capable de ne pirater que l’application dont le compte a été compromis.

En pratique toutefois, cela n’apporte que très peu de bénéfices de sécurité :

• La plupart des utilisateurs utiliseront le même mot de passe sur toutes les applications, ou un mot de passe différent mais suivant une logique (MotDePasseWindows pour le compte Windows, MotDePasseIntranet pour le compte de l’intranet…) qui apporte une sécurité effective équivalente à un système centralisé.
• Si les utilisateurs sont forcés à utiliser des mots de passe trop différents (par exemple, des politiques de mot de passe qui varient selon les applications), cela amène à une forte réduction de la sécurité, car les mots de passe seront alors écrits en clair. Noter les mots de passe sur un post-it en dessous du clavier est malheureusement une mauvaise habitude qui perdure. Encourager les utilisateurs à n’utiliser qu’un seul mot de passe fort renforce la sécurité et permet aux utilisateurs de pouvoir s’en souvenir facilement.
• Il serait possible d’utiliser un gestionnaire de mot de passe afin d’avoir un mot de passe différent et sécurisé (car généré aléatoirement) pour chaque application. Toutefois, il faut protéger la base de mots de passe par un mot de passe « maître », ce qui revient à utiliser un mot de passe unique. De plus, il est difficile de former les utilisateurs à la bonne utilisation d’un gestionnaire de mots de passe.

Le seul cas où la décentralisation serait plus sécurisée serait si les utilisateurs avaient la capacité de retenir un mot de passe fort et unique à chaque application ; cependant, ce cas est assez rare, et il n’y a pas de moyen de vérifier cette capacité.

De ce fait, il n’y a que très peu de cas où la décentralisation serait plus sécurisée que la centralisation ; et même dans ces cas, les avantages apportés par une centralisation sont plus conséquents et facilitent le travail de la DSI dans l’accompagnement des utilisateurs.

La centralisation des comptes utilisateurs, l’avenir de l’authentification

Ce n’est pas pour rien que la centralisation des comptes d’utilisateurs est un point de conformité pour certains audits.

Du point de vue de la DSI, et même du point de vue des collaborateurs, un point central d’authentification facilite les processus et permet d’être plus performant et sécurisé, en ayant une visibilité et un contrôle sur l’intégralité des applications utilisées.

La réduction de la complexité inhérente à un système décentralisé n’est pas triviale, et diminue le temps et donc les coûts requis.

Une gestion des comptes simplifiée

Ajouter et décommissionner des comptes d’utilisateurs devient très facile avec un système centralisé. Dans un système décentralisé, il faut ajouter le compte séparément dans chaque application, tout en configurant par exemple les groupes auxquels appartient le compte (groupe « marketing », groupe « helpdesk »…).

Cela représente un travail non négligeable et présente même des problèmes de sécurité. Par exemple, dans les centres d’appels avec beaucoup de turn-over, les nouveaux collaborateurs doivent attendre que la DSI mette en place leur compte. Ils doivent alors utiliser le compte d’un autre collaborateur pour travailler, ce qui représente une grande brèche de sécurité !

Le temps passé pour décommissionner les comptes d’utilisateurs fait que ce décommissionnement est, à tort, passé en basse priorité puis souvent oublié : les entreprises se retrouvent alors avec des comptes d’utilisateurs pour des collaborateurs ayant quitté l’entreprise il y a plusieurs mois, voire plusieurs années, ce qui crée un risque car l’utilisateur pourrait se connecter à distance et effectuer des actions mettant l’entreprise en péril.

Il est certes possible d’utiliser un script pour automatiquement ajouter puis décommissionner les comptes d’utilisateurs. Cette solution requiert toutefois plus de maintenance et est plus complexe, en raison des différentes façons de gérer les comptes (base de données, fichier texte, fichier binaire au format propriétaire…).