Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog
Diggi Blog

Sécurité - La faute aux utilisateurs ? Pas toujours...

20 Février 2021 , Rédigé par Diggi Publié dans #Sécurité, #Windows Server

J'ai récemment fait la migration de deux applicatifs d'un "ancien" serveur vers un tout nouveau (tout beau, tout propre). Outre le fait de bénéficier des nouvelles versions de ces applicatifs, cette migration avait pour moi un intérêt dans mes objectifs d'amélioration de la sécurité de mon parc informatique.

Malheureusement, ce fût l'occasion de constater qu'en 2021, certains intervenants dans l'informatique ne maitrisent toujours pas des règles de bases de l'informatique !

Voici donc un petit témoignage afin de soulager mon exaspération face à ces combats du quotidien d'un informaticien qui passe pour le "lourd" de service avec ces règles pénibles...

 

Premier applicatif:

L'installation se passe bien, tout fonctionne et l'intervenant m'indique que tout est OK pour lui.

Comme à mon habitude, je met à jour le "dossier d'exploitation" que j'ai rédigé sur cet applicatif, afin de prendre en compte les dernières modifications et surtout de conserver les informations importantes pour de prochaines interventions qui pourraient avoir lieu dans plusieurs mois voir années.

Et en vérifiant l'installation sur le nouveau serveur, je constate avec effroi que le dossier de l'applicatif est accessible à "tous les utilisateurs" avec "tous les droits" !

Clairement, n'importe quel utilisateur pourra donc lire, modifier, voir même supprimer les fichiers présents dans ce dossier, même s'ils ne sont pas censés avoir accès à cet applicatif "social". Le dossier contient non seulement des programmes, mais aussi les données, dont certaines sont des données personnelles (big up au RGPD).

Je réapplique donc les droits comme sur l'ancien serveur (limiter aux utilisateurs autorisés seulement) mais du coup, l'applicatif ne fonctionne plus !

Après un échange avec l'intervenant, il s'avère qu'il avait créé un utilisateur sur le serveur (sans m'en informer bien entendu) et qu'il est nécessaire que cet utilisateur soit autorisé pour que l'appli fonctionne.

"La sécurisation de l'application et de votre serveur n'est pas de notre responsabilité". Merci de votre conscience professionnelle !

 

Mais ce n'est pas le pire hélas !

 

Deuxième applicatif:

L'installation se passe bien, jusqu'au moment où l'intervenant me demande de lui communiquer le mot de passe de l'administrateur du domaine AD:

"Euh oui, c'est pour faire quoi ?

 - C'est pour le fonctionnement du "Microsoft SQL server".

 - Et pourquoi ce serveur a besoin d'être administrateur du domaine ?

 - C'est la procédure officielle de l'éditeur du logiciel.

 - A la limite, administrateur local du serveur pour l'installation, mais certainement pas pour le fonctionnement permanent, et encore moins administrateur du domaine !

 - Si si, je vous transmet la procédure officielle."

Effectivement, la procédure officielle de ce "grand" éditeur français, dont les logiciels sont largement diffusés dans les PME et TPE françaises (et en Europe), indique "noir sur blanc" que la partie MS SQL doit être lancée en tant qu'administrateur du domaine.

Il est vrai que cela simplifie la gestion des droits: plus de blocage quelconque ou de question à se poser sur la configuration !

Mais que penser d'un serveur dont la partie MS SQL sera "administrateur" en permanence ? Ce n'est pas comme si SQL server n'était jamais exploité pour ses failles...

Évidemment, j'ai refusé, au grand dam de l'intervenant pour qui c'était la première fois que cela posait problème à un client. J'imagine que la plupart des PME où il installe cet applicatif ne savent pas ce que cela peut impliquer et fait entièrement confiance à cette société de service qui met en avant son expertise en conseil informatique.

" - Je vous propose qu'on essaye avec un simple compte utilisateur local, cet applicatif et la partie SQL n’'ayant pas besoin de se connecter à d'’autres machines du domaine. On avisera si cela génère des soucis dans le fonctionnement du serveur SQL et de l'applicatif."

Et cela a bien fonctionné, aucun souci avec l'applicatif et sa base SQL.

😋

 

Conclusion:

Je ne suis pas un expert sécurité, je ne suis pas un expert "applicatif". Mais pour moi, les deux notions de sécurités abordées dans ces deux exemples devraient être la base de tout intervenant informatique:

  •  Limiter l'accès aux dossiers (programmes et données) uniquement aux utilisateurs clairement identifiés comme devant y accéder. (Ne pas considérer qu'un utilisateur n'a de toute façon pas de raison d'essayer d'y accéder).
  • Limiter les droits des "comptes" utilisés pour faire fonctionner des applicatifs ou serveurs au strict minimum pour lequel ils sont utilisés.

 

Deux articles intéressants sur les comptes à utiliser avec MS SQL server:

https://docs.microsoft.com/fr-fr/sql/ssms/agent/select-an-account-for-the-sql-server-agent-service?view=sql-server-ver15

http://blogs.developpeur.org/christian/archive/2008/04/28/sql-server-quels-comptes-de-service-choisir.aspx

 

Partager cet article
Repost0
Pour être informé des derniers articles, inscrivez vous :
Commenter cet article