Vous consultez une page technique concernant le logiciel de gestion Mercator. Celle-ci contient des informations spécifiques destinées aux professionnels de Mercator. Souhaitez-vous être redirigés vers des informations plus générales ?


   Ne plus poser cette question

Considérations sur la sécurisation de SQL Server et des données qu'il héberge

0000002685     -      15/12/2016

Mercator est de plus en plus utilisé en mode "SQL Cloud". Cette ouverture sur Internet pose immanquablement la question de la sécurité et de la restriction de l'accès aux seuls utilisateurs autorisés. L'équipe Mercator ne formule pas un conseil général et universel à ce propos, mais propose des outils de sécurisation. En général, la sécurité est inversement proportionnelle au confort des utilisateurs et à la facilité d'utilisation. Il incombe donc à chaque responsable de son infrastructure de déterminer l'endroit où il place le curseur. 

En ce qui concerne SQL Server, la sécurisation nous paraît comprendre au moins 2 volets essentiels :

1. Rendre le serveur SQL accessible uniquement à des utilisateurs bien déterminés

Si le serveur SQL n'est "visible" que dans un réseau local, ce point peut être ignoré. Par contre, si SQL Server est "exposé" sur Internet, il est impératif de le protéger et d'en restreindre l'accès uniquement à des internautes bien déterminés. Cet aspect peut être géré dans le pare-feu (firewall) si les utilisateurs se trouvent derrière une adresse IP fixe.

Pour les utilisateurs qui disposent d'une adresse IP dynamique, un VPN peut être mis en place :

  • le VPN de Windows (RRAS) peut être utilisé. Il est aisé de l'intégrer dans Mercator. Son inconvénient est qu'en cas de coupure de connexion réseau, il n'est pas capable de se reconnecter automatiquement (alors que Mercator peut le faire).
  • OpenVPN présente une solution attrayante car elle est à la fois réputée et gratuite. Elle repose sur un système de certificats générés sur le serveur et installés sur chacun des postes pouvant se connecter. Une liste de révocation permet de supprimer depuis le serveur un accès pour un client déterminé. OpenVPN peut fonctionner en tant que service, tant sur le serveur que le client. Il devient dès lors totalement transparent. Il dispose d'excellentes capacités de reconnexion.
  • D'autres VPN peuvent être mis en place : Cisco, SolarWinds, Fortinet, ...

Une fois un VPN mis en place, il faut s'assurer que le serveur SQL ne soit accessible que par le réseau local ou le VPN.

2. Crypter les échanges entre Mercator (le client) et le serveur SQL

Si le serveur SQL n'est accessible que depuis un réseau local ou au travers d'un VPN (qui effectue le cryptage des communications), alors ce point peut être ignoré. Si par contre, des communications transitent par l'Internet public, même entre adresses IP bien déterminées dans les firewalls, il est obligatoire de crypter les données échangées. En effet, dans le cas contraire, les mots de passe, requêtes et données sont envoyés "en clair" et peuvent être interceptés ou modifiés durant leur transit dans l'Internet public. On parle ici d'attaque du type "Man in the Middle".

Pour cela, il convient de mettre en place un cryptage des données, selon une des deux méthodes décrites ici :


Il est bien entendu possible d'adopter des mesures complémentaires pour assurer la sécurité d'un serveur SQL et l'intégrité des données qu'il héberge. Voici une liste non exhaustive d'actions qui peuvent être prises, sans que chacune d'elles ne soit à elle seule suffisante, sans que chacune d'elles ne soit non plus obligatoire.

  • changer le port par défaut de SQL Server (via les outils de  configuration)
  • masquer l'instance de SQL Server (via les outils de  configuration)
  • mettre un mot de passe (très) fort sur l'utilisateur SA
  • renommer l'utilisateur SA
  • désactiver le mode d’authentification mixte de SQL Server et, en conséquence, utiliser des chaines de connexion personnalisées. Gérer les accès à la base de données de Mercator par utilisateur défini dans Active Directory. (Cela implique de paramétrer manuellement les connexions via les outils clients de SQL Server.)
  • éviter que les applications externes (site web, ...) qui se connectent au serveur SQL avec des droits d'accès trop larges
  • restreindre les droits de la connexion portant le même nom que la base de données de Mercator
  • ...

 Afin de sensibiliser nos utilisateurs et prestataires de service sur cette matière, Mercator affichera désormais ce message au démarrage :

"Mercator communique avec le serveur SQL via l'Internet public en mode non crypté.
Les données échangées ne sont donc pas protégées contre une interception malveillante.
Il est vivement conseillé de sécuriser votre infrastructure."

si ces deux conditions sont remplies :

  • la communication avec le serveur SQL se fait au travers de l'Internet public
  • la communication avec le serveur SQL est non cryptée

Si ce message est affiché, une action correctrice doit être prise. Si ce message n'est pas affiché, cela ne signifie pas que votre infrastructure est sécurisée. En effet, Mercator n'a aucun moyen de vérifier la présence et la configuration d'éventuels firewalls.