Comment améliorer la sécurité de votre serveur SQL.

Découvrez comment améliorer la sécurité de votre SQL Server 2022 déployé sur Microsoft Windows Server en suivant les meilleures pratiques pour protéger vos données et garantir une architecture résiliente et aussi sécurisée que possible.

REMARQUE : Il est important de préciser que tout ce qui est décrit ici est destiné aux environnements de SQL Server sur Windows Server, bien que certaines recommandations soient également opérationnelles pour les systèmes GNU/Linux.

En plus de ce qui est exposé ici, il est recommandé de consulter l’article sur les exigences et la planification de l’installation de SQL Server 2022 sur notre blog, bien que certaines parties, telles que celles concernant la sécurité, puissent être quelque peu redondantes.

Conseils et meilleures pratiques pour sécuriser notre SQL Server :

La première chose à considérer est qu’en matière de sécurité, il n’y a jamais trop de précautions. Nous devons toujours mettre en œuvre un modèle en couches d’oignon dans lequel nous appliquons différents niveaux de protection.

Ces niveaux de protection doivent être appliqués de manière holistique, c’est-à-dire qu’ils doivent s’appliquer à tous les niveaux et aspects de l’installation du serveur de base de données : depuis l’installation physique du serveur jusqu’aux correctifs de sécurité des applications et du système d’exploitation, en passant par la conception des requêtes.

Ensuite, nous allons passer en revue certains des points à prendre en compte pour améliorer la sécurité de notre base de données Microsoft SQL Server sur des systèmes Microsoft Windows Server.

Sécurité physique :

Le premier point de la sécurité d’un système, avant de se concentrer sur la partie logique, consiste à sécuriser la machine physique qui contient le serveur. Peu importe à quel point nous protégeons un serveur au niveau logique, en utilisant des pare-feux, des antivirus, en le patchant, en configurant ses accès, etc., s’il n’y a pas de sécurité physique, c’est-à-dire une porte qui empêche l’accès au serveur, un contrôle d’accès, un contrôle de la température, etc., tout ce qui a été fait précédemment ne servira à rien car quelqu’un pourra accéder au serveur et l’éteindre, le voler, etc.

La sécurité physique du serveur peut inclure de nombreux éléments, tels que la mise en place des serveurs dans une salle séparée avec un accès contrôlé (par une porte verrouillée, une serrure électronique, des systèmes biométriques, etc.), ainsi que la présence de systèmes d’extinction d’incendie, de systèmes de climatisation pour maintenir une température stable et éviter les problèmes de surchauffe des serveurs, etc.

Bien que cela ne fasse pas partie de la sécurité physique, il convient également de prendre en compte d’autres aspects tels que les sources d’alimentation redondantes, les systèmes d’alimentation électrique sans interruption (ASI), les connexions depuis différents fournisseurs, la connexion Internet (de préférence redondante), etc.

Sécurité du système d’exploitation :

C’est un point sur lequel je ne me lasse pas de parler. Si nous n’avons pas un système d’exploitation solide, il est impossible d’avoir une application en cours d’exécution dessus et d’être sûr.

Tout d’abord, il est essentiel de déployer uniquement les services minimums sur le serveur et l’idéal est de ne pas en déployer plus d’un par serveur en utilisant des machines virtuelles, des conteneurs, etc. De cette manière, nous éviterons la possibilité de créer des points critiques de défaillance dans notre infrastructure. Bien sûr, dans le cas des bases de données, elles doivent être déployées sur un serveur isolé ne fournissant aucun autre service.

Nous devons appliquer tous les packs de correctifs et mises à jour possibles, sans en laisser aucun, mais en ayant pleinement conscience que nous n’installons que ceux qui s’appliquent à notre plateforme.

Cela signifie que si nous n’avons pas un matériel spécifique, il peut être contre-productif d’appliquer un correctif conçu pour ce matériel, et que s’il y a un correctif pour Office et que nous n’avons pas Office installé, il vaut mieux ne pas l’installer car il pourrait contenir des bugs, des problèmes, etc.

Rappelons que l’idéal serait de déployer un environnement de test sur lequel nous pouvons déployer nos mises à jour et les tester avant de les mettre en production.

Bien sûr, en plus des mises à jour, nous devons installer un logiciel antivirus et antimalware qui nous protège des mille et une menaces qui existent aujourd’hui et qui ne cessent de s’améliorer et d’apparaître en permanence.

Enfin, n’oublions pas le pare-feu du système d’exploitation, qui ne doit avoir ouverts que les ports minimums nécessaires pour fonctionner. Pour vérifier ce point, nous vous recommandons de consulter le tutoriel où vous pouvez voir comment configurer les ports requis par le SGBD. Nous vous recommandons également de consulter le contenu suivant sur le site web de Microsoft pour apprendre à configurer le service SSIS avec le pare-feu de Windows.

Ensuite, nous allons passer en revue certaines des recommandations pour améliorer la sécurité de notre SQL Server.

Sécurité des fichiers de SQL Server :

SQL Server utilise le système de fichiers du système d’exploitation pour stocker certains fichiers. Pour éviter les problèmes, les accès à ces fichiers doivent être limités. Pour cela, nous devrons déterminer les chemins à protéger, et la première chose à faire est de lancer la requête suivante depuis SSMS :

SELECT CONVERT(char(20), SERVERPROPERTY(‘productlevel’));

REMARQUE : Dans notre cas, nous travaillons avec SQL Server 2022, donc c’est une version 16.x, mais nous expliquons cela pour ceux qui ont d’autres versions.

Pouvant obtenir comme résultat :

Lorsque nous connaîtrons la version de notre SQL Server, nous pourrons remplacer la version dans la chaîne « <unité>:\Archivos de programa\Microsoft SQL Server\nnn ».

Où :

• <unité> : sera la lettre d’unité où SQL Server est installé, par exemple « E: ».
• nnn : Identifier la version de SQL Server.

Il est important de noter qu’en fonction de l’installation, il y aura différents éléments et nomenclatures.

• MSSQL : Moteur de SQL Server. Suivi d’un numéro de version, d’un tiret bas et de la version secondaire, d’un point et du nom de l’instance. Par exemple : MSSQL{nn}.MSSQLSERVER. MSAS : Analysis Services. Suivi d’un numéro de version, d’un tiret bas et de la version secondaire, d’un point et du nom de l’instance. Par exemple : MSAS{nn}.MSSQLSERVER.
• MSRS : Reporting Services. Suivi du numéro de version, d’un tiret bas et de la version secondaire, d’un point et du nom de l’instance. Par exemple : MSSQL{nn}.<instance>.

Ainsi, pour une instance appelée « TestNacho », les chemins seraient les suivants :

• C:\Program files\Microsoft SQL Server\MSSQL16
  C:\Program files\Microsoft SQL Server\MSAS16.TestNacho
  C:\Program files\Microsoft SQL Server\MSRS16.TestNacho\

Sécurité de SQL Server dans le registre du système :

De la même manière que les chemins des fichiers du système d’exploitation sont protégés en ce qui concerne SQL Server, les entrées du SGBD dans le registre de Windows (accessible avec RegEdit) doivent également être protégées.

Une fois la version clairement identifiée, les entrées suivantes du sous-arbre du registre qui sont créées dans « HKLM\Software\Microsoft\Microsoft SQL Server<instance> » doivent être protégées.

Par exemple, pour notre instance « TestsNacho » :

HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL16.TestNacho HKLM\Software\Microsoft\Microsoft SQL Server\MSAS16.TestNacho HKLM\Software\Microsoft\Microsoft SQL Server\MSRS16.TestNacho.

Configuration du moteur de base de données SQL Server pour le chiffrement des connexions :

Pour assurer la sécurité de la plateforme, il est nécessaire de chiffrer toutes les connexions entrantes vers Microsoft SQL Server. Il est également possible d’activer le chiffrement uniquement pour un ensemble spécifique de clients, mais nous considérons que cela est moins sûr que d’exiger le chiffrement pour tous.

Pour configurer ce chiffrement, la première étape consiste à configurer SQL Server pour utiliser un certificat conforme aux exigences du certificat pour SQL Server, ce qui permettra de continuer avec les autres étapes nécessaires pour renforcer la sécurité de l’infrastructure du SGBD.

Dans cet article, nous ne souhaitons pas nous étendre trop, nous préférons donc renvoyer le lecteur à l’examen du lien suivant de Microsoft, où il pourra voir comment configurer SQL Server pour utiliser des certificats et comment modifier les paramètres de chiffrement de l’instance de SQL Server, permettant ainsi le chiffrement de toutes les connexions entrantes vers SQL Server lorsqu’un certificat d’une entité commerciale publique est utilisé.

Changement des comptes utilisés par les services :

Un autre point assez simple et facile à mettre en œuvre est le changement des comptes utilisés pour l’authentification de SQL Server par les services. Cela est plus que nécessaire, non seulement pour changer les mots de passe, ce qui ne devrait pas poser de problème car ils devraient être uniques, mais aussi pour changer les noms d’utilisateur pour qu’ils ne soient pas génériques, ce qui augmentera considérablement la sécurité.

Pour les changer, vous devez accéder au gestionnaire de configuration de SQL Server, que vous pouvez ouvrir depuis l’invite de commande Windows ou en exécutant directement la console avec « C:\Windows\SysWOW64\SQLServerManager<nn>.msc », en remplaçant <nn> par la version de SQL Server installée.

Il est important de rappeler que, dans cet article même, dans la section « Sécurité des fichiers de SQL Server », il est expliqué comment obtenir la version de SQL Server que vous implémentez, par exemple la version 16 pour SQL Server 2022, et la route serait alors « C:\Windows\SysWOW64\SQLServerManager16.msc ».

REMARQUE : Lorsque vous changez le mot de passe depuis le gestionnaire de configuration de SQL Server, les modifications prennent effet sans nécessiter de redémarrage du service.

Masquage dynamique des données :

L’utilisation du masquage dynamique des données, également connu sous le nom de DDM selon son acronyme anglais (Dynamic Data Masking), fournit une couche supplémentaire de protection en limitant l’accès aux informations par des utilisateurs non privilégiés.

REMARQUE : Le DDM est disponible depuis la version SQL Server 2016.

Ce modèle ajoute une bonne sécurité avec un besoin minimal de conception.

Le masquage dynamique des données permet aux clients de spécifier la quantité d’informations qui doit être disponible pour leur consultation et à qui l’accès est autorisé.

Un avantage du DDM est qu’il peut être appliqué sur les champs dont vous ne souhaitez pas qu’ils soient extraits, tout en affichant d’autres données de cette même table, mais en empêchant l’accès aux colonnes spécifiques.

Pour la mise en œuvre du DDM, il est nécessaire de désigner une politique de masquage de données centrale, qui doit agir sur les champs confidentiels de la base de données. Ensuite, il faut désigner les utilisateurs (qui peuvent être des rôles) ayant accès aux informations, étant les seuls autorisés à y accéder, tandis que l’accès est refusé aux autres rôles et utilisateurs.

Pour configurer le masquage dynamique des données, nous utiliserons des commandes T-SQL, mais nous devons prendre en compte à la fois une syntaxe spécifique et certaines limitations d’utilisation.

Pour commencer, sachez que le DDM ne peut pas être utilisé sur les types de colonnes suivants :

• Colonnes chiffrées.
• Filestream.
• Column_Set.
• Colonne de table externe de PolyBase.
• Colonnes d’index FULLTEXT.

Il faut également garder à l’esprit qu’il n’est pas possible de créer des masques sur des colonnes calculées, mais si le calcul d’une colonne utilise une colonne masquée, le résultat sera masqué.

Les autorisations nécessaires pour créer un DDM sont celles de CREATE TABLE et ALTER, tandis que pour la modification, l’ajout, le remplacement ou la suppression, les autorisations ALTER ANY MASK et ALTER TABLE sont requises. Enfin, l’affichage se fera avec SELECT comme pour toute autre requête, mais dépendra de la possibilité d’accéder à ces données.

Pour en savoir plus sur cette option, nous recommandons de visiter le site web de Microsoft.

Protection étendue pour le moteur de base de données :

SQL Server possède une fonctionnalité de sécurité qui, curieusement, n’est pas activée par défaut, mais doit être activée par l’administrateur. Il s’agit de la protection étendue pour l’authentification.

Il s’agit d’une fonctionnalité des composants réseau mise en œuvre par le système d’exploitation, qui permet de réaliser des connexions plus sécurisées lorsque les connexions sont effectuées avec Extended Protection.

Cette fonction utilise le lien de service et le lien de canal pour prévenir les attaques de retransmission d’authentification, dans lesquelles un client capable d’effectuer l’authentification NTLM se connecte à un attaquant lorsque ce dernier utilise les informations d’identification du client pour se faire passer pour lui et s’authentifier auprès d’un service.

Pour activer cette fonctionnalité, vous devez accéder à « l’Administrateur de configuration de SQL Server », étendre la configuration réseau de SQL Server et accéder aux propriétés des « Protocoles de _<instance> », où <instance> sera le nom de l’instance à configurer.

Ensuite, vous devez rechercher la valeur « Protection étendue » parmi les options avancées, vous pouvez alors cocher l’option pour forcer le chiffrement.

Pour que les changements prennent effet, vous devrez redémarrer la base de données.

Examen du compte SA :

Le compte SA est bien connu des administrateurs de SQL Server et a suscité plus d’une discussion entre eux et les administrateurs des systèmes d’exploitation. Ce compte est utilisé pour la connexion au moteur de base de données de SQL Server lui-même et possède des privilèges d’administrateur système.

Il s’agit d’un compte créé par défaut sur le serveur lors du déploiement de l’instance par défaut du maître. Il est important de savoir que les privilèges ne peuvent pas être limités, mais le compte peut être désactivé.

La meilleure approche serait d’utiliser l’authentification Windows, ce qui désactivera l’authentification SQL Server. Cela signifie que le compte SA sera présent mais désactivé, avec un mot de passe généré de manière aléatoire et complexe.

Limitation de l’utilisateur invité (guest) de SQL Server :

Toutes les bases de données SQL Server, tout comme d’autres applications, incluent un utilisateur invité, également connu sous le nom de guest. Les autorisations de cet utilisateur s’appliquent à tous les utilisateurs ayant accès à la base de données sans disposer de leur propre compte.

Cet utilisateur ne peut pas être supprimé, mais il peut être désactivé en révoquant son autorisation de connexion.

REMARQUE : On peut utiliser la commande T-SQL « REVOKE CONNECT FROM GUEST; » sur les bases de données autres que master et tempdb.

Exploitation du canal latéral :

Les systèmes informatiques nécessitent des supports physiques pour rester opérationnels, ce qui entraîne la génération de toutes sortes de traces, telles que le temps, l’image, le son, etc.

La vulnérabilité du canal latéral exploite l’une de ces traces pour obtenir des informations sensibles grâce à un algorithme, en utilisant les modèles de sortie d’informations que les ordinateurs émettent en permanence.

Pour minimiser le risque d’une attaque par canal latéral sur un système SQL Server, les points suivants peuvent être pris en compte :

• Maintenir le système aussi à jour que possible (oui, je suis très insistant avec cela, je le sais).
• Ne pas oublier les mises à jour firmware les plus récentes pour tout matériel local.
• Si vous travaillez avec un cloud public, ajoutez une protection supplémentaire contre les attaques par canal latéral avec des machines virtuelles isolées, des hôtes dédiés ou en tirant parti des machines virtuelles avec protection de processus confidentiel.
• Dans le cas d’un cloud privé, des options telles que les machines virtuelles blindées de Microsoft Hyper-V sont disponibles.

Protection contre l’injection SQL :

L’injection SQL, « SQL injection » ou « SQLi », est une vulnérabilité de sécurité des services web qui permet à un attaquant de modifier les requêtes envoyées à la base de données depuis une application.

Les attaquants utilisent généralement cette vulnérabilité pour extraire des données auxquelles ils n’auraient normalement pas accès, y compris des données appartenant à d’autres utilisateurs ou à toute autre donnée accessible par l’application elle-même.

Dans les cas les plus critiques, l’attaquant pourra modifier voire supprimer les données contenues dans la base de données, provoquant ainsi des changements persistants dans le contenu et le comportement de l’application.

Pour minimiser le risque d’une injection SQL, les points suivants doivent être pris en compte :

• Construire les instructions SQL générées de manière paramétrée.
• Les administrateurs de sécurité et les développeurs doivent passer en revue tout le code qui appelle EXECUTE, EXEC ou « sp_executesql ».
• Réviser les processus qui construisent des instructions SQL.
• Toujours valider les entrées utilisateur.
• Nettoyer les sorties d’erreur pour éviter les débordements.

En plus de ce qui a été exposé précédemment, les caractères d’entrée suivants ne doivent pas être autorisés :

• “;” Délimiteur de requêtes.
• “’” Délimiteur de chaîne de caractères de données.
• “—“ Délimiteur de commentaire sur une seule ligne. “/ * … * /”
• Délimiteurs de commentaire. “xp_”
• Procédures stockées étendues du catalogue, par exemple “xp_cmdshell”.

Il convient de remplacer “xp_cmdshell” par “SQLCLR”, car son utilisation est déconseillée dans les environnements SQL Server.

Authentication Windows pour Reporting Services :

Le système d’exploitation est responsable de la gestion de l’authentification des utilisateurs pour l’utilisation de Reporting Services via la sécurité intégrée, en validant les informations d’identification des utilisateurs.

Cependant, cela n’est pas toujours le cas, et nous pouvons développer une authentification personnalisée au sein de Reporting Services pour prendre en charge des schémas d’authentification supplémentaires via l’interface d’extension de sécurité connue sous le nom de « IAuthenticationExtension2 ».

Pour apprendre à tirer parti de cette fonctionnalité, nous vous recommandons de consulter la ressource suivante de Microsoft.

Audit du système et des bases de données :

Maintenir des rapports réguliers sur les applications et le système d’exploitation lui-même, ainsi que des audits, nous aide à avoir un système sécurisé. Pour cette raison, des stratégies d’audit doivent être créées au niveau du serveur ainsi qu’au niveau de la base de données.

Lors de la création des audits, il ne faut pas oublier les tableaux ni les colonnes contenant des données sensibles soumises à toute mesure de sécurité.

En plus de créer des règles et des rapports, ceux-ci doivent être régulièrement examinés pour s’assurer que tout fonctionne correctement, et déclencher les opérations nécessaires en cas de problème.

Vous pouvez trouver plus d’informations sur l’audit de SQL Server sur le site web de Microsoft.

Les mots de passe sécurisés :

Tout au long de cet article, et de nombreux autres écrits précédemment et à venir, nous avons parlé de la nécessité d’utiliser des mots de passe sécurisés, et je ne veux pas conclure cet article sans répondre, ou du moins approcher la réponse, à la question suivante : Qu’est-ce qu’un mot de passe sécurisé pour Microsoft ?

Eh bien, la première chose à dire est que cela dépend un peu des exigences fixées par le domaine ou l’application utilisée pour la validation, et qu’en outre, étant donné la puissance des ordinateurs et des outils visant à casser les mots de passe, le nombre de caractères utilisés doit être augmenté chaque jour. Cependant, de manière générale, on peut dire qu’un bon mot de passe devrait :

• Avoir une longueur d’au moins huit caractères.
• Ne pas être composé du nom de l’organisation, du nom d’utilisateur ni du nom de la personne.
• Ne pas être composé de mots existants dans un dictionnaire.
• Ne pas être similaire à des mots de passe précédents.
• Contenir des majuscules.
• Contenir des minuscules.
• Contenir des chiffres.
• Contenir des caractères spéciaux.

Conclusion

Tout au long de cet article, nous avons passé en revue certaines des meilleures pratiques pour maintenir notre Microsoft SQL Server 2022 (ou d’autres versions) en toute sécurité. Les conseils donnés ici sont vraiment utiles pour toutes les versions actuellement prises en charge, y compris les déploiements locaux et sur le cloud.

Nous avons abordé certains points concernant la sécurité physique, la codification, les requêtes et même la programmation, ainsi que d’autres aspects liés à l’administration, en particulier dans la gestion des processus et des utilisateurs.

Tous ces points visent à améliorer la sécurité, mais nous devons dire que le plus important, comme nous l’avons déjà mentionné à d’autres occasions, est d’avoir une planification correcte, ce qui nous aidera à éliminer la plupart des vulnérabilités ou des erreurs de déploiement.

Cet article, bien sûr, n’est (et ne devrait pas être) infini, car il deviendrait ennuyeux et écrasant, ce qui pourrait décourager le lecteur. C’est pourquoi nous avons omis certains points, comme l’utilisation des fonctions cryptographiques de Transact-SQL, que nous pourrions aborder ultérieurement.

Nous pensons qu’avec ces conseils, vous pourrez améliorer la sécurité de vos bases de données, mais n’oubliez pas qu’il s’agit seulement de quelques points, et nous vous encourageons à explorer et à ajouter de nouveaux points.

Merci de nous avoir accompagnés !