Exporter (0) Imprimer
Développer tout

Sécurisation de votre serveur de base de données

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Menaces et contre-mesures Menaces et contre-mesures
Méthodologie pour sécuriser votre serveur Méthodologie pour sécuriser votre serveur
Considérations d'installation de SQL Server Considérations d'installation de SQL Server
Recommandations d'installation de SQL Server Recommandations d'installation de SQL Server
Étapes de sécurisation de votre serveur de base de données Étapes de sécurisation de votre serveur de base de données
Étape 1 : Correctifs et mises à jour Étape 1 : Correctifs et mises à jour
Étape 2 : Services Étape 2 : Services
Étape 3 : Protocoles Étape 3 : Protocoles
Étape 4 : Comptes Étape 4 : Comptes
Étape 5 : Fichiers et répertoires Étape 5 : Fichiers et répertoires
Étape 6 : Partages Étape 6 : Partages
Étape 7 : Ports Étape 7 : Ports
Étape 8 : Registre Étape 8 : Registre
Étape 9 : Audit et journalisation Étape 9 : Audit et journalisation
Étape 10 : Sécurité de SQL Serveur Étape 10 : Sécurité de SQL Serveur
Étape 11 : Noms de connexion, utilisateurs et rôles Étape 11 : Noms de connexion, utilisateurs et rôles
Étape 12 : Objets de la base de données SQL Server Étape 12 : Objets de la base de données SQL Server
Instantané d'un serveur de base de données sécurisé Instantané d'un serveur de base de données sécurisé
Remarques supplémentaires Remarques supplémentaires
Rester protégé Rester protégé
Administration distante Administration distante
Résumé Résumé

Dans ce module

Une base de données contient généralement vos données les plus sensibles et les plus confidentielles (telles que les dossiers du personnel, les coordonnées des clients, les bons de commande ou les informations sur les cartes de crédit). Ces données doivent être stockées en toute sécurité et protégées des divulgations non autorisées, des falsifications ou de toute utilisation malveillante. Le serveur de base de données, même s'il n'est pas directement connecté à Internet, doit être protégé des attaques visant à exploiter les faiblesses de configuration, les dépassements de capacité de la mémoire tampon ou toute autre mauvaise habitude de développement.

Ces attaques peuvent être exécutées par :

  • Une application Web non sécurisée, utilisée pour exploiter la base de données.

  • Un administrateur malveillant disposant d'un accès au réseau.

  • Un utilisateur de base de données qui exécute un code nuisible.

Ce module passe tout d'abord en revue les menaces les plus courantes dont les serveurs de base de données font l'objet. Cette perspective sert alors de point de départ pour créer une méthodologie pour protéger les serveurs. Le module propose ensuite de mettre en pratique la méthodologie, en utilisant une approche étape par étape pour vous montrer comment améliorer la sécurité de vos serveurs de base de données.

Objectifs

Ce module vous permettra :

  • D'apprendre les méthodologies éprouvées de sécurisation des serveurs de base de données.

  • De savoir quels éléments sont installés par SQL Server.

  • D'installer SQL Server en mode sécurisé.

  • De verrouiller votre serveur de base de données en configurant le système d'exploitation en mode sécurisé. Ceci implique la configuration de services, de correctifs et de mises à jour, de protocoles, de comptes, de fichiers et de répertoires, de partages, de ports, ainsi que d'informations de registre et d'audit. Le module comporte des exemples pour un scénario SQL Server.

  • De verrouiller une application SQL Server en consignant dans un journal les demandes d'authentification et en gérant les paramètres de sécurité interne de SQL Server, parmi lesquels les noms de connexion, les utilisateurs de la base de données, les rôles et les autorisations sur des objets de la base de données.

  • D'exécuter SQL Server en utilisant le compte le moins privilégié et de réserver l'utilisation de procédures de stockage sensibles à l'administrateur.

  • De maintenir la sécurité après le déploiement.

  • De connaître les contre-mesures à appliquer pour faire face à une menace courante du serveur de base de données, parmi lesquelles l'injection SQL, l'écoute clandestine de réseau, l'accès non autorisé au serveur et le détournement de mots de passe.

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Microsoft Windows Server 2000

  • Microsoft .NET Framework 1.1 et ASP.NET 1.1

  • Microsoft SQL Server 2000 ;

Menaces et contre-mesures

Un attaquant dispose de différents moyens pour cibler et compromettre un serveur de base de données en exploitant les diverses vulnérabilités au niveau des applications et de la configuration.

Les principales menaces du serveur de base de données sont les suivantes :

  • Injection SQL

  • Écoute clandestine du réseau

  • Accès non autorisé au serveur

  • Piratage de mot de passe

La figure 18.1 illustre les principales menaces et vulnérabilités pouvant conduire à l'infection d'un serveur de base de données et à la possibilité de détruire ou de dérober les données sensibles.

 Principales menaces et vulnérabilités d'un serveur de base de données.

Figure 18.1
Principales menaces et vulnérabilités d'un serveur de base de données

Les sections qui suivent décrivent chacune de ces menaces et de ces vulnérabilités.

Injection SQL

Dans le cas d'une attaque par injection SQL, l'attaquant exploite les vulnérabilités de validation des entrées dans votre application et du code d'accès aux données. Il peut ainsi exécuter arbitrairement des commandes dans la base de données dans le contexte de sécurité de l'application Web.

Vulnérabilités

Les vulnérabilités exploitées par l'injection SQL comprennent :

  • La faiblesse de la validation des entrées dans vos applications Web.

  • Des commandes SQL non sécurisées, construites de manière dynamique.

  • L'utilisation de connexions sur-privilégiées à la base de données.

  • Des autorisations faibles qui ne parviennent pas à limiter la connexion de l'application à la base de données.

Contre-mesures

Pour contrer les attaques par injection SQL :

  • Votre application doit limiter et assainir les données saisies avant de les utiliser dans des requêtes SQL.

  • Utilisez les paramètres sécurisés SQL pour accéder aux données. Ces paramètres peuvent être utilisés dans des procédures stockées ou dans des chaînes de commande SQL construites de manière dynamique. L'utilisation de tels paramètres garantit que les données saisies sont soumises à des contrôles de type et de longueur et que le code injecté est traité comme des données littérales et non comme des instructions exécutables dans la base de données.

  • Utilisez un nom de connexion à SQL Server qui restreint les autorisations dans la base de données. Idéalement, vous ne devriez accorder d'autorisation d'exécution qu'à certaines procédures stockées sélectionnées dans la base de données et ne pas fournir d'accès direct à la table.

Pour plus d'informations sur les mesures au niveau des applications contre les attaques par injection SQL, consultez le module 14,« Création d'un accès sécurisé aux données ».

Écoute clandestine du réseau

L'architecture de déploiement de la plupart des applications comprend une séparation physique entre le code d'accès aux données et le serveur de base de données. Les données sensibles, telles que les données spécifiques d'une application ou les autorisations de connexion à la base de données, doivent par conséquent être protégées contre les écoutes clandestines de réseau.

Vulnérabilités

Parmi les vulnérabilités qui augmentent la probabilité d'écoute clandestine du réseau figurent :

  • Des canaux de communication non sécurisés.

  • Des transmissions d'autorisation en texte clair à la base de données, par exemple :

    • en utilisant l'authentification SQL à la place de l'authentification Windows ;

    • en utilisant l'authentification SQL sans certificat du serveur.

Contre-mesures

Pour contrer l'écoute clandestine du réseau :

  • Utilisez l'authentification Windows pour vous connecter au serveur de base de données et éviter ainsi d'envoyer des informations d'identification sur le réseau.

  • Installez un certificat de serveur sur le serveur de base de données. Ce certificat permet d'obtenir un cryptage automatique des informations d'identification SQL sur le réseau.

  • Utilisez une connexion SSL entre le serveur Web et le serveur de base de données pour protéger les données sensibles des applications. Ce type de connexion nécessite un certificat de serveur de base de données.

  • Utilisez un canal crypté IPSec entre le serveur Web et le serveur de base de données.

Accès non autorisé au serveur

L'accès direct à votre serveur de base de données doit être limité à certains ordinateurs clients spécifiques pour empêcher les accès non autorisés au serveur.

Vulnérabilités

Les vulnérabilités qui favorisent l'accès non autorisé au serveur de base de données sont les suivantes :

  • Impossibilité de bloquer le port SQL Server au niveau du pare-feu de périmètre.

  • Absence de stratégie de filtrage TCP/IP ou IPSec.

Attaques

Les attaques par connexion directe existent à la fois pour les utilisateurs authentifiés et pour les utilisateurs sans nom d'utilisateur ni mot de passe, par exemple :

  • Il existe des outils tels que l'Analyseur de requêtes (Isqlw.exe) ou son équivalent en ligne de commande (Osql.exe) qui permettent d'établir une connexion directe avec SQL Server et d'envoyer des commandes.

  • Les informations du serveur, telles que la version des logiciels, sont révélées à l'attaquant qui envoie des paquets construits avec soin pour écouter les ports.

Contre-mesures

Pour contrer ces attaques :

  • Veillez à ce que les ports SQL Server ne soient pas visibles en dehors du périmètre du réseau.

  • Au sein de ce périmètre, limitez l'accès direct des hôtes non autorisés, en utilisant par exemple des filtres IPSec ou TCP/IP.

Piratage de mot de passe

L'une des attaques type consiste à essayer de découvrir les mots de passe des noms de compte bien connus, tels que sa, le compte administrateur SQL Server.

Vulnérabilités

Les vulnérabilités courantes menant au piratage du mot de passe sont les suivantes :

  • Mots de passe vierges ou faibles.

  • Mots de passe contenant des mots usuels.

Attaques

Les attaques courantes par piratage de mot de passe comprennent :

  • Les attaques par dictionnaire

  • La recherche manuelle de mot de passe

Contre-mesures

Pour contrer ces attaques :

  • Pour les comptes de connexion à SQL Server, créez des mots de passe répondant à des critères de complexité.

  • Évitez les mots de passe contenant des mots courants, figurant dans le dictionnaire.

    Remarque : si vous utilisez l'authentification Windows, la complexité du mot de passe peut être renforcée par la stratégie de sécurité Windows.

Méthodologie pour sécuriser votre serveur

Sécuriser SQL Server et Windows 2000 implique de nombreux changements de configuration. La meilleure approche en la matière consiste à classer les changements suivant des catégories de configuration spécifique. L'utilisation de telles catégories vous permet de passer en revue systématiquement et de A à Z le processus de sécurisation ou de prendre en compte une catégorie en particulier et de mettre en œuvre la procédure spécifique.

Catégories de configuration

La méthodologie de sécurisation a été organisée en catégories, illustrée en figure 18.2.

Catégories de sécurité du serveur de base de données

Figure 18.2
Catégories de sécurité du serveur de base de données

Les catégories de configuration présentées en figure 18.2 reposent sur les pratiques en usage, résultant de l'expérience, de la validation des clients et de l'étude des déploiements sécurisés. La logique qui sous-tend ces catégories est la suivante :

  • Correctifs et mises à jour
    De nombreuses menaces de sécurité existent en raison des vulnérabilités présentes dans les systèmes d'exploitation, les services et les applications. Ces vulnérabilités sont bien connues et largement diffusées. Lorsque de nouvelles vulnérabilités sont découvertes, le code d'attaque est fréquemment publié sur des forums Internet dans les heures qui suivent la première attaque réussie. Appliquer les correctifs aux logiciels de votre serveur et les mettre à jour est la première étape du processus de sécurisation de votre serveur de base de données. Il existe toutefois des situations dans lesquelles aucun correctif n'existe pour la vulnérabilité trouvée. Le cas échéant, prenez connaissance des détails de la vulnérabilité pour évaluer le risque d'attaque et prendre les mesures en conséquence.

  • Services
    Les services sont au premier rang des points vulnérables pour les attaquants qui peuvent exploiter les privilèges et capacités du service pour accéder au serveur et potentiellement aux autres ordinateurs. Certains services sont conçus pour être exécutés avec des comptes privilégiés. Si ces services sont infectés, l'attaquant peut exécuter des opérations privilégiées. Par défaut, il n'est pas nécessaire que tous les services d'un serveur de base de données soient activés. En désactivant les services non utilisés et inutiles, vous pouvez réduire rapidement et aisément la zone exposée aux attaques.

  • Protocoles
    Réduisez la gamme de protocoles que peuvent utiliser les ordinateurs clients pour se connecter au serveur de base de données et veillez à pouvoir sécuriser ces protocoles.

  • Comptes
    Réduisez au minimum nécessaire pour le service et les utilisateurs le nombre de comptes Windows accessibles à partir du serveur de base de données. Utilisez les comptes les moins privilégiés avec des mots de passe fiables dans tous les cas. L'utilisation d'un compte moins privilégié pour exécuter SQL Server limite les capacités de l'attaquant à fragiliser SQL Server et à exécuter les commandes du système d'exploitation.

  • Fichiers et répertoires
    Utilisez les autorisations du système de fichiers NTFS pour protéger les fichiers programme, les fichiers de base de données et les journaux contre les accès non autorisés. En utilisant des listes de contrôle d'accès (ACL) associées à l'audit Windows, vous pouvez détecter les activités suspectes ou non autorisées.

  • Partages
    Supprimez tous les partages de fichiers inutiles, y compris les partages administratifs par défaut s'ils ne sont pas nécessaires. Sécurisez tous les partages restants à l'aide d'autorisations NTFS réduites. Bien que les partages ne soient pas exposés directement sur Internet, une stratégie complète de défense utilisant un nombre limité de partages sécurisés permet de réduire les risques en cas de fragilisation du serveur.

  • Ports
    Les ports non utilisés sont fermés au niveau du pare-feu, mais il est nécessaire que les serveurs situés derrière le pare-feu bloquent également les ports ou en restreignent l'accès en fonction de leur utilisation. Dans le cas d'un SQL Server dédié, bloquez tous les ports à l'exception du port SQL Server requis et des ports nécessaires à l'authentification.

  • Registre
    SQL Server conserve un certain nombre de paramètres liés à la sécurité dans le registre, parmi lesquels le mode d'authentification configuré. Limitez et contrôlez l'accès au registre pour éviter la mise à jour non autorisée des paramètres de configuration, visant par exemple, à relâcher le niveau de sécurité du serveur de base de données.

  • Audit et journalisation
    L'audit est un support vital pour identifier les intrus, les attaques en cours et diagnostiquer les empreintes d'attaque. Configurez un niveau minimal d'audit pour le serveur de base de données en combinant les fonctions d'audit de Windows avec celles de SQL Server.

  • Sécurité de SQL Server
    Il est possible de contrôler un certain nombre de paramètres de sécurité de SQL Server via Enterprise Manager. Parmi ces paramètres figurent le mode d'authentification, le niveau d'audit et les comptes utilisés pour exécuter le service SQL Server. Pour renforcer la sécurité, nous vous recommandons d'utiliser l'authentification Windows. Vous devez en outre activer l'audit d'ouverture de session SQL Server et vous assurer que le service SQL Server s'exécute sur le compte le moins privilégié.

  • Noms de connexion, utilisateurs et rôles
    SQL Server 2000 gère le contrôle d'accès à l'aide de noms de connexion, de bases de données, d'utilisateurs et de rôles. Les utilisateurs (et les applications) obtiennent l'accès à SQL Server au moyen d'un nom de connexion SQL Server. Ce nom de connexion est associé à un utilisateur de la base de données, lui même placé dans un ou plusieurs rôles. Les autorisations accordées aux rôles déterminent les tables auxquelles le nom de connexion peut accéder et les types d'opérations qu'il peut exécuter. Cette approche est utilisée pour créer des comptes de base de données les moins privilégiés, qui disposent d'un jeu d'autorisations strictement nécessaires pour réaliser leur fonction légitime.

  • Objets de la base de données SQL Server
    Vous devez revoir la capacité à accéder à certains objets de la base de données tels que les procédures stockées intégrées, les procédures stockées étendues et les travaux cmdExec. En outre, toute base de données exemple doit être supprimée.

Considérations d'installation de SQL Server

Avant de procéder à la sécurisation de votre serveur de base de données, il convient de connaître les composants supplémentaires présents sur un ordinateur Windows 2000 Server une fois SQL Server installé.

Quels éléments SQL Server installe-t-il ?

Lorsque vous installez SQL Server, un certain nombre de services Windows sont installés en plus des fichiers programme et de données. Par défaut, les fichiers de données et programme sont stockés dans le répertoire \Program Files\Microsoft SQL Server\. Le tableau 18.1 présente les services et dossiers créés.

Tableau 18.1 Installation SQL Server par défaut

Élément

Détails

Services

MSSQLSERVER
MSSQLServerADHelper
Microsoft Search
SQLSERVERAGENT

Dossiers

\program files\Microsoft SQL Server\mssql\binn (fichiers programme)
\program files\Microsoft SQL Server\mssql\data (fichiers de données comprenant .mdf, .log et .ndf)
\program files\Microsoft SQL Server\80\tools (outils partagés/documentation en ligne)
\program files\Microsoft SQL Server\mssql\logs (journaux d'erreurs)
\program files\Microsoft SQL Server\mssql\backup (fichiers de sauvegarde)
\program files\Microsoft SQL Server\mssql\jobs (fichiers temporaires de sortie)

Pour les instances nommées, le nom de l'instance est utilisé dans le chemin du fichier :
\program files\Microsoft SQL Server\MSSQL$InstanceName\binn
\program files\Microsoft SQL Server\MSSQL$InstanceName\data

Recommandations d'installation de SQL Server

Si vous créez un nouveau serveur de base de données de A à Z, vous devrez prendre en compte un certain nombre de considérations avant d'installer SQL Server. De plus, il peut s'avérer intéressant de réaliser une installation personnalisée de SQL Server de manière à pouvoir sélectionner les options d'installation les plus sécurisées.

Avant de procéder à l'installation de SQL Server

Avant d'exécuter le programme d'installation de SQL Server, vérifiez les éléments suivants :

  • Créez un compte local le moins privilégié possible avec lequel vous pourrez exécuter le service SQL Server. Utilisez ce compte lorsque vous y êtes invité pour paramétrer les services au cours de l'installation. N'utilisez pas de compte système local ni de compte administrateur.

  • Veillez à ne pas installer SQL Server sur un contrôleur de domaine.

  • Veillez à installer SQL Server sur une partition formatée à l'aide de NTFS.

  • Installez les fichiers de base de données et de programme SQL Server sur un volume non système, distinct de celui du système d'exploitation.

Installation de SQL Server

Lors de l'installation de SQL Server sur un serveur de production, choisissez l'option d'installation personnalisée. Vous pouvez ensuite choisir les éléments à installer. Vous ne devez pas installer les éléments répertoriés dans le tableau 18.2 sur un serveur de base de données de production.

Tableau 18.2 Éléments à ne pas installer pendant l'installation personnalisée

Outil

Objet

Outils de mise à niveau

Utilisés pour mettre à niveau les bases de données SQL Server 6.5

Prise en charge de la réplication

Les fichiers binaires et les scripts sont utilisés pour la réplication. (Ne l'installez pas à moins d'avoir besoin de la réplication)

Recherche de texte intégral

Moteur de recherche de texte intégral (Service de recherche Microsoft). Ne l'installez pas à moins d'avoir besoin de la fonction de recherche de texte intégral.

Documentation en ligne

Documentation de SQL Server

Outils de développement

En-têtes et fichiers de bibliothèques utilisés par les développeurs en C et Microsoft Data Access (MDAC), kits de développement logiciels XML (SDK) et interface de débogage des procédures stockées.

Exemples de codes

Exemple de code utilisé pour former les développeurs.

Vous devez également sélectionner le mode d'authentification Windows à moins que l'authentification SQL Server ne soit spécifiquement requise. L'authentification Windows offre les avantages suivants :

  • Les stratégies de sécurité locales et de domaine peuvent être utilisées pour imposer la mise en œuvre de bonnes pratiques en matière d'utilisation de mots de passe fiables et de gestion des comptes.

  • Les informations d'identification ne sont pas transmises par le réseau.

  • Les chaînes de connexion à la base de données de l'application ne nécessitent pas d'informations d'identification.

Si vous choisissez le mode mixte, créez un mot de passe fiable pour le compte sa. Le compte sa est une cible de choix pour les attaques par dictionnaire ou par recherche de mot de passe.

Étapes de sécurisation de votre serveur de base de données

Cette section vous guide tout au long du processus de sécurisation de votre serveur de base de données et utilise les catégories de configuration présentées plus haut. Les étapes concernent Windows 2000 et SQL Server 2000. Chaque étape peut contenir une ou plusieurs actions pour sécuriser une zone ou une fonction particulière.

Étape 1

Correctifs et mises à jour

Étape 7

Ports

Étape 2

Services

Étape 8

Registre

Étape 3

Protocoles

Étape 9

Audit et journalisation

Étape 4

Comptes

Étape 10

Sécurité SQL Server

Étape 5

Fichiers et répertoires

Étape 11

Noms de connexion, utilisateurs et rôles SQL Server

Étape 6

Partages

Étape 12

Objets de base de données SQL Server

Étape 1 : Correctifs et mises à jour

Si vous n'appliquez pas les correctifs ni ne procédez aux mises à jour en temps utile, vous offrez aux attaquants la possibilité d'exploiter les vulnérabilités connues. Vous devez donc vérifier que votre serveur de base de données est à jour par rapport aux derniers services packs et mises à jour de Windows 2000 et du service SQL Server.

Important : Veillez à tester les correctifs et les mises à jour sur des systèmes de test, à l'image de vos serveurs, avant de les appliquer aux serveurs de production.

Détection des service packs et mises à jour manquants

Utilisez l'outil Microsoft Baseline Security Analyzer (MBSA) pour détecter les mises à jour nécessaires de Windows et de SQL Server. Le MBSA utilise un fichier XML comme référence des mises à jour existantes. Ce fichier XML peut être téléchargé par MBSA en cours d'analyse ou téléchargé sur le serveur local à partir d'un serveur de réseau.

  • Pour détecter et installer les correctifs et mises à jour

    1. Téléchargez et installez MBSA.
      Pour ce faire, rendez-vous sur la page d'accueil de MBSA http://www.microsoft.com/technet/security/tools/mbsahome.mspx.
      Si vous n'avez pas d'accès Internet lorsque vous exécutez MBSA, vous ne pourrez pas récupérer le fichier XML contenant les derniers paramètres de sécurité de Microsoft. Dans ce cas, téléchargez le fichier XML manuellement et placez-le dans le répertoire du programme MBSA.
      Le fichier XML est disponible à l'adresse : http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab.

    2. Exécutez MBSA en cliquant deux fois sur l'icône sur le bureau ou en le sélectionnant à partir du menu Programmes.

    3. Cliquez sur Scan a computer. MBSA analyse par défaut l'ordinateur local.

    4. Désélectionnez toutes les cases à l'exception de la case Check for security updates. Cette option permet de détecter les correctifs et mises à jour manquants.

    5. Cliquez sur Start scan. Votre serveur est en cours d'analyse. Lorsque l'analyse est terminée, MBSA affiche un rapport de sécurité, également inscrit dans le répertoire %userprofile%\SecurityScans.

    6. Téléchargez et installez les mises à jour manquantes.
      Cliquez sur le lien Result details en regard de chaque vérification non réussie pour afficher la liste des mises à jour de sécurité manquantes. Une boîte de dialogue affiche alors le numéro de référence du bulletin de sécurité Microsoft. Cliquez sur la référence pour en savoir plus sur le bulletin et télécharger la mise à jour.

Pour plus d'informations sur l'utilisation de MBSA, consultez la rubrique « Procédure : utilisation de Microsoft Baseline Security Analyzer » de la section « Procédures » de ce guide.

Correctifs MSDE

L'Édition Desktop Microsoft SQL Server (MSDE) n'obéit pas aux mêmes règles de mises à jour et de correction que la version complète de SQL Server. Pour plus d'informations sur l'utilisation des correctifs dans MSDE, consultez la rubrique « Procédure : sécurisation de la station de travail du développeur » de la section « Procédures » de ce guide.

Étape 2 : Services

Pour réduire la zone d'attaque et vous assurer que vous n'êtes pas menacé en raison de vulnérabilités de service encore non découvertes, désactivez tout service inutile. Exécutez les services qui restent en utilisant les comptes les moins privilégiés.

Au cours de cette étape vous devez :

  • Désactiver les services SQL Server non utilisés.

  • Désactiver le service Microsoft DTC (s'il est inutile).

Remarque : pour désactiver un service, définissez son type de démarrage sur Désactivé à l'aide du composant logiciel enfichable MMC des services de l'outil Gestion de l'ordinateur.

Désactiver les services SQL Server non utilisés.

Pendant l'installation d'un service SQL, les quatre services Windows suivants sont installés :

  • MSSQLSERVER (ou MSSQL$InstanceName pour une instance nommée). Il s'agit du moteur de base de données SQL Server ; il constitue le seul service obligatoire.

  • SQLSERVERAGENT (ou SQLAgent$InstanceName pour une instance nommée). Grâce à ce service d'assistance, vous pouvez planifier les commandes et notifier les opérateurs des erreurs qui se produisent.

  • MSSQLServerADHelper. Cette instance fournit des services d'intégration Active Directory, parmi lesquels l'inscription de l'instance de base de données.

  • Microsoft Search. Ce service offre des capacités de recherche de texte intégral. Il doit toujours être exécuté sous un compte du système local.

Seul le moteur de base de données MSSQLSERVER est requis. Les autres services fournissent des fonctionnalités complémentaires et sont requis dans des scénarios spécifiques uniquement. Désactivez ces services s'ils ne sont pas nécessaires.

Remarque : SQL Server ne doit pas être configuré pour s'exécuter comme compte du système local ou comme tout compte membre du groupe Administrateurs locaux. Pour plus de détails sur la configuration du compte de service utilisé pour exécuter MSSQLSERVER, reportez-vous à la rubrique « Étape 4 : Comptes ».

Désactiver le service Microsoft DTC (s'il est inutile).

Si vous n'utilisez pas de transactions distribuées via Microsoft DTC, désactivez le service.

Étape 3 : Protocoles

En empêchant l'utilisation des protocoles inutiles, vous limitez la zone exposée aux attaques. Configurez SQL Server qu'il prenne en charge uniquement les clients qui se connectent via le protocole TCP/IP. Désactivez tous les autres protocoles, sauf si nécessaire.

Au cours de cette étape vous devez :

  • Limiter SQL Server à TCP/IP.

  • Renforcer la pile TCP/IP.

Limitation de SQL Server à TCP/IP

En renforçant l'utilisation de TCP/IP, vous pouvez contrôler qui se connecte au serveur sur les ports spécifiques grâce aux stratégies IPSec ou au filtrage TCP/IP. Pour prendre en charge IPSec ou le filtrage TCP/IP, il faut que SQL Server ne prenne en charge que les connexions clients sur TCP/IP.

  • Pour configurer la prise en charge du protocole réseau TCP/IP

    1. Dans le groupe de programmes Microsoft SQL Server, démarrez l'utilitaire réseau SQL Server.

    2. Vérifiez que TCP/IP est bien le seul protocole SQL Server activé, comme l'illustre la figure 18.3. Désactivez tous les autres protocoles.

Désactivation de tous les protocoles à l'exception de TCP/IP dans l'utilitaire de réseau SQL Server.

Figure 18.3
Désactivation de tous les protocoles à l'exception de TCP/IP dans l'utilitaire de réseau SQL Server

Renforcement de la pile TCP/IP.

Windows 2000 vous permet de contrôler plusieurs paramètres pour configurer son implémentation de TCP/IP. Certaines valeurs par défaut visent à accroître la disponibilité du serveur et sont utilisées pour certaines caractéristiques spécifiques.

Pour plus d'informations sur le renforcement de la pile TCP/IP, consultez la rubrique « Procédure : renforcement de la pile TCP/IP » de la section « Procédures » de ce guide.

Remarques supplémentaires

Pour améliorer davantage la sécurité de votre serveur de base de données, désactivez NetBIOS et SMB. Ces deux protocoles pouvant être utilisés pour récupérer des informations de configuration, il est conseillé de les supprimer lorsque c'est possible. Pour plus d'informations sur la suppression de NetBIOS et de SMB, reportez-vous à la rubrique « Protocole » du module 16, « Sécurisation de votre serveur Web ».

Tenez compte également du fait que l'utilisation d'IPSec limite les ports sur lesquels le serveur de base de données accepte les connexions entrantes. Pour plus d'informations sur cette procédure, consultez la rubrique « Procédure : utilisation d'IPSec pour le filtrage des ports et l'authentification » de la section « Procédures » de ce guide.

Étape 4 : Comptes

Appliquez le principe du compte le moins privilégié pour les comptes servant à exécuter et à se connecter à SQL Server afin de restreindre les capacités de l'attaquant à exécuter des commandes SQL sur le serveur de base de données. Mettez également en œuvre des stratégies de mot de passe fiable pour contrer la menace des attaques par dictionnaire.

Au cours de cette étape vous devez :

  • Sécuriser le compte du service SQL Server.

  • Supprimer ou désactiver les comptes inutilisés.

  • Désactiver le compte invité de Windows.

  • Renommer le compte administrateur.

  • Renforcer la stratégie de mot de passe fiable.

  • Restreindre les connexions à distance.

  • Désactiver les sessions NULL (ouverture de sessions anonymes).

Sécurisation du compte du service SQL Server

Exécutez le service SQL Server à partir d'un compte le moins privilégié possible pour réduire les dommages pouvant être perpétrés par un attaquant qui parviendrait à exécuter des commandes du système d'exploitation à partir de SQL Server. Le compte du service SQL Server ne doit pas accorder de privilèges élevés, tels que l'appartenance au groupe Administrateurs.

  • Pour créer un nouveau compte afin d'exécuter le service SQL Server

    1. Démarrez l'outil Gestion de l'ordinateur, puis développez Utilisateurs et groupes locaux.

    2. Cliquez avec le bouton droit de la souris sur le nouveau dossier, Utilisateurs, puis cliquez sur Nouvel utilisateur.

    3. Créez un nouvel utilisateur en veillant à utiliser un mot de passe fiable.
      Dans la boîte de dialogue Nouvel utilisateur, désélectionnez la case L'utilisateur doit changer le mot de passe à la prochaine ouverture de session, puis cochez les cases L'utilisateur ne peut pas changer de mot de passe et Le mot de passe n'expire jamais.

    4. Supprimez le nouveau compte du groupe Utilisateurs car ce groupe a un accès libre à l'ensemble de l'ordinateur.

Vous pouvez maintenant configurer SQL Server afin qu'il soit exécuté à l'aide de ce nouveau compte. Pour plus d'informations, reportez-vous à la rubrique « Étape 10 : Sécurité de SQL Server ».

Accès au réseau à partir de SQL Server

Si vous avez besoin d'accéder aux ressources du réseau à partir de SQL Server, pour effectuer une sauvegarde de réseau par exemple, pour des besoins de réplication ou d'envoi de journal, vous devez faire en sorte que le compte du service SQL Server puisse être authentifié sur le réseau. Vous avez deux possibilités. Vous pouvez créer une copie du compte local, avec les mêmes nom et mot de passe sur le serveur local ou utiliser un compte de domaine le moins privilégié possible.

Suppression ou désactivation des comptes inutilisés

Les comptes inutilisés et leurs privilèges peuvent servir de refuge à un attaquant qui aurait obtenu un accès au serveur. Passez en revue les comptes locaux sur le serveur et supprimez ceux qui ne sont pas utilisés. Nous vous recommandons de les désactiver avant de les supprimer et de vérifier que cela ne pose pas de problème car les comptes supprimés ne peuvent pas être récupérés. Notez que les comptes administrateur et invité ne peuvent pas être supprimés.

Remarque : au cours de l'installation de SQL Server 2000 SP 3, Sqldbreg2.exe crée le compte Débogueur SQL. Visual Studio .NET utilise ce compte lorsqu'il débogue les procédures stockées à partir du code géré .NET. Comme ce compte n'est utilisé que pour le débogage, vous pouvez le supprimer des serveurs de base de données de production.

Désactivation du compte invité de Windows

Le compte invité de Windows est un compte utilisé pour effectuer une connexion anonyme sur l'ordinateur. Pour empêcher les connexions anonymes à votre serveur de base de données, maintenez ce compte désactivé. Par défaut le compte invité de Windows 2000 est désactivé. Pour vérifier s'il est activé, affichez le dossier Utilisateurs de l'outil Gestion de l'ordinateur. Son état actif est représenté par une icône en forme de croix. S'il n'est pas désactivé, affichez sa boîte de dialogue de Propriétés et cochez la case Le compte est désactivé.

Changement du nom du compte Administrateur

Le compte local par défaut Administrateur est la cible d'utilisation malveillante dans la mesure où il dispose des privilèges les plus élevés sur l'ordinateur. Pour améliorer la sécurité, renommez le compte Administrateur par défaut et assignez-lui un mot de passe fiable.

Renforcement de la stratégie de mot de passe fiable

Pour contrer les attaques brutales par dictionnaire et de recherche de mot de passe, mettez en œuvre des stratégies de mot de passe fiable en configurant la stratégie de sécurité. Les points clés des stratégies de compte et de mot de passe fiables sont les suivants :

  • Définissez la longueur du mot de passe et sa complexité. L'utilisation de mots de passe fiables réduit les chances de réussite des attaques par recherche de mot de passe ou par dictionnaire.

  • Définissez un délai d'expiration du mot de passe. Les mots de passe qui expirent régulièrement réduisent les risques de voir un ancien mot de passe utilisé pour un accès non autorisé. Le délai d'expiration est généralement fixé en fonction de la stratégie de sécurité de la société.

Le tableau 18.3 illustre les paramètres par défaut et recommandés pour la stratégie de mot de passe.

Tableau 18.3 Paramètres par défaut et recommandés de la stratégie de mot de passe

Stratégie de mot de passe

Paramètre par défaut

Paramètre minimum recommandé

Conserver l'historique des mots de passe

1 mot de passe en mémoire

24 mots de passe en mémoire

Durée de vie maximale du mot de passe

42 jours

42 jours

Durée de vie minimale du mot de passe

0 jours

2 jours

Longueur minimale du mot de passe

0 caractères

8 caractères

Les mots de passe doivent respecter des exigences de complexité

Désactivé

Activé

Stocker le mot de passe en utilisant le cryptage réversible pour tous les utilisateurs du domaine

Désactivé

Désactivé

Parallèlement, enregistrez dans un journal les tentatives infructueuses de connexion pour détecter et suivre les comportements malveillants. Pour plus d'informations, reportez-vous à la rubrique « Étape 9 : Audit et journalisation ».

Pour plus d'informations sur les stratégies de mot de passe, consultez cette rubrique.

Limitation des connexions à distance.

Utilisez l'outil Stratégie de sécurité locale pour supprimer le droit utilisateur intitulé « Accéder à cet ordinateur depuis le réseau » du groupe Tout le monde pour limiter le nombre d'utilisateurs pouvant se connecter au serveur à distance.

Désactivation des sessions NULL (ouvertures de sessions anonymes)

Pour empêcher les accès anonymes, désactivez les sessions NULL. Il s'agit de toutes les sessions non authentifiées ou anonymes établies entre deux ordinateurs. Si les sessions NULL ne sont pas désactivées, un attaquant peut se connecter anonymement à votre serveur, c'est-à-dire, sans s'authentifier.

Dès qu'un attaquant établit une session NULL, il peut lancer tout un ensemble d'attaques, y compris l'énumération utilisée pour obtenir les données liées au système de l'ordinateur cible. Les informations récupérées par ce biais comprennent les détails de domaine et de sécurisation, de partages, les données utilisateur y compris les groupes et droits d'utilisateur, les clés du Registre, etc. Désactivez ces sessions qui représentent une grave menace pour la sécurité.

Limitez les sessions NULL en définissant le paramètre RestrictAnonymous=1 dans le registre, à l'emplacement suivant :

HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

Pour plus d'informations, consultez l'article 246261 de la base de connaissances Microsoft, « Utilisation de la valeur de Registre RestrictAnonymous dans Windows 2000 ».

Remarques supplémentaires

Tenez compte des étapes suivantes pour améliorer la sécurité de votre serveur de base de données :

  • Exigez que la délégation d'un compte passe par une approbation. Ne marquez pas les comptes de domaine comme des comptes sécurisés pour la délégation dans Active Directory sans approbation spéciale.

  • N'utilisez pas de comptes partagés. Ne créez pas de compte partagé par plusieurs personnes. Attribuez à chacun son propre compte. Les activités de chacun pourront ainsi être surveillées séparément et l'appartenance aux groupes et l'accord de privilèges pourront être définis de manière appropriée.

  • Limitez l'appartenance au groupe local Administrateurs. Idéalement, il ne doit pas y avoir plus de deux comptes d'administrateur. La gestion en est ainsi facilitée. En outre, ne partagez pas les mots de passe, par souci de facilité de gestion.

  • Limitez le compte Administrateur aux connexions interactives. Si vos opérations d'administration se limitent au local, vous pouvez limiter votre compte Administrateur aux connexions interactives en désélectionnant le droit d'utilisateur « Accéder à cet ordinateur à partir du réseau » pour refuser les droits de connexion réseau. Vous empêchez ainsi les utilisateurs (bien intentionnés et autres) de se connecter à distance au serveur en utilisant le compte Administrateur. Si la stratégie d'administration en local est trop rigide, mettez en place une administration distante sécurisée.

    Pour plus d'informations sur l'administration distante, reportez-vous à la rubrique « Administration distante », plus loin dans ce module.

  • Activez l'authentification NTLMv2

    Si les ordinateurs clients se connectent à votre serveur de base de données en utilisant l'authentification Windows, vous devez configurer votre serveur de base de données pour qu'il utilise la version la plus puissante de l'authentification Windows, à savoir NTLMv2.

    Remarque : pour prendre en charge NTLMv2, les clients doivent s'exécuter sur Windows 2000, Windows Server 2003 ou Windows NT® version 4.0 avec le service pack 4.

  • Pour activer l'authentification NTLMv2 à partir de l'outil Stratégie de sécurité locale

    1. Développez l'option Stratégies locales, sélectionnez Options de sécurité, puis double-cliquez sur Niveau d'authentification Lan Manager.

    2. Sélectionnez Envoyer des réponses NTLM version 2 uniquement\refuser LM et NTLM.

    Il s'agit du paramétrage le plus sûr.

    Remarque : ce paramétrage revient à définir la valeur de
    HKLM\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel DWORD sur 5.

Étape 5 : Fichiers et répertoires

Outre la sécurisation des fichiers du système d'exploitation à l'aide des ACL, renforcez les autorisations NTFS pour restreindre l'accès aux fichiers programme SQL Server, aux fichiers de données et aux fichiers journaux ainsi qu'aux outils au niveau du système. Par ailleurs, le compte du service SQL Server ne doit avoir accès qu'aux éléments nécessaires.

Au cours de cette étape vous devez :

  • Vérifier les autorisations sur les répertoires d'installation SQL Server.

  • Vérifier que le groupe Tout le monde n'a pas d'autorisation sur les fichiers SQL Server.

  • Sécuriser les fichiers journaux d'installation.

  • Sécuriser ou supprimer les outils, utilitaires et kits de développement (SDK).

Vérification des autorisations sur les répertoires d'installation SQL Server.

Vérifiez dans le tableau 18.4 les autorisations accordées au compte à partir duquel est exécuté le service SQL Server. L'emplacement spécifié entre parenthèses est l'emplacement d'installation par défaut. Il peut être différent dans votre installation.

Tableau 18.4 Autorisations pour le compte du service SQL Server

Emplacement

Autorisations pour le compte SQL Service

Emplacement d'installation
(\Program Files\Microsoft SQL Server\MSSQL\)

Lecture et exécution
Affichage du contenu du dossier
Lecture

Répertoire des fichiers de base de données (fichiers .mdf, .ndf, .ldf)
(\Program Files\Microsoft SQL Server\MSSQL\Data)

Contrôle total

Répertoire des fichiers journaux d'erreurs
(\Program Files\Microsoft SQL Server\MSSQL\LOG)

Contrôle total

Répertoire des fichiers de sauvegarde
(\Program Files\Microsoft SQL Server\MSSQL\Backup)

Contrôle total

Répertoire de sortie des fichiers temporaires de travail
(\Program Files\Microsoft SQL Server\MSSQL\Jobs)

Contrôle total

Si vous utilisez Enterprise Manager pour configurer le compte du service SQL Server, le compte se verra attribuer les autorisations de contrôle total sur le répertoire d'installation de SQL Server ainsi que sur ses sous-dossiers (\Program Files\Microsoft SQL Server\MSSQL\*).

En supprimant les autorisations d'écriture sur ce dossier et ses sous-dossiers, puis en accordant le contrôle total sur les répertoires de données, de journaux d'erreurs, de fichiers de sauvegarde et de travail, le nouveau compte ne peut pas écraser les fichiers binaires SQL Server.

Vérification des autorisations du groupe Tout le monde sur les fichiers SQL Server

Le groupe Tout le monde ne doit pas avoir accès à l'emplacement des fichiers SQL Server (par défaut \Program Files\Microsoft SQL Server\MSSQL). Vous pouvez vous en assurer en vérifiant que le groupe Tout le monde ne dispose pas d'accès via un ACL et en accordant le contrôle total qu'au compte du service SQL Server, au groupe Administrateurs et au compte système local.

Sécurisation des fichiers journaux d'installation

Une fois que SQL Server Service Pack 1 ou 2 a été installé, il est possible que le mot de passe de l'administrateur système ou celui du compte de service soit conservé dans le répertoire d'installation de SQL. Utilisez l'utilitaire Killpwd.exe pour supprimer les instances des mots de passe des fichiers journaux.

Pour plus d'informations sur la manière de se procurer cet utilitaire, consultez l'article 263968 de la base de connaissances Microsoft « CORRECTIF : L'installation du Service Pack peut enregistrer le mot de passe de protection standard dans un fichier ».

Sécurisation ou suppression des outils, utilitaires et kits de développement (SDK).

Les kits de développement (SDK) et les kits de ressources ne doivent pas être installés sur un serveur de base de données de production. Supprimez-les le cas échéant. Par ailleurs :

  • Assurez-vous que l'accès aux outils systèmes puissants et aux utilitaires, tels que ceux du répertoire \Program Files, est restreint.

  • Les outils de débogage ne doivent pas être à disposition sur le serveur de base de données. Si le débogage de production est nécessaire, vous devez créer un CD contenant les outils de débogage nécessaires.

Remarques supplémentaires

Pour améliorer la sécurité de votre serveur de base de données :

  • Supprimez les applications non utilisées installées sur le serveur. Si votre serveur contient des applications que vous n'utilisez pas, supprimez-les.

  • Cryptez vos fichiers de données à l'aide du système de codage des fichiers (EFS). Vous pouvez utiliser EFS pour protéger vos fichiers de données. En cas de vol des fichiers de données, les fichiers codés sont plus difficiles à lire. L'utilisation d'EFS pour les fichiers de données SQL Server est prise en charge.

    Avant d'utiliser EFS, tenez compte des informations suivantes :

    • Codez les fichiers de base de données (.MDF) et non les fichiers journaux (.LDF). Si vous cryptez les fichiers journaux, SQL Server ne pourra pas ouvrir votre base de données.

    • Effectuez le codage au niveau du fichier et non au niveau du répertoire. Bien qu'il soit souvent recommandé de procéder au codage au niveau du répertoire lorsque vous utilisez EFS pour que les nouveaux fichiers ajoutés soient automatiquement codés, vous devrez effectuer le codage de vos fichiers de données SQL Server au niveau des fichiers uniquement. Vous éviterez ainsi de coder vos fichiers journaux.

    • Évaluez le coût des performances. L'utilisation de l'EFS entraîne une baisse des performances. Testez l'EFS avant de l'utiliser dans votre scénario afin de déterminer l'impact réel des performances. Généralement les performances sont peu pénalisées car les fichiers de données sont décodés par SQL Server lorsque le processus démarre.

    Pour implémenter l'EFS, cliquez avec le bouton droit de la souris sur le répertoire, choisissez Avancés, puis cliquez sur Encrypt contents to be secure. Pour plus d'informations sur EFS, consultez les ressources suivantes :

Étape 6 : Partages

Supprimez tous les partages non utilisés et renforcez les autorisations NTFS sur tous les partages requis. Par défaut, tous les utilisateurs ont un contrôle total sur les partages de fichiers qui viennent d'être créés. Renforcez ces autorisations par défaut de manière à vous assurer que seuls les utilisateurs autorisés peuvent accéder aux fichiers exposés par le partage. Utilisez également les listes de contrôle d'accès NTFS sur les fichiers et dossiers exposés par le partage, en plus des autorisations de partage explicite.

Au cours de cette étape vous devez :

  • Supprimer les partages inutiles.

  • Restreindre l'accès aux partages requis.

Suppression des partages inutiles

Supprimez les partages inutiles. Pour passer en revue les partages, démarrez le composant logiciel enfichable MMC de l'outil Gestion de l'ordinateur et sélectionnez Partages sous Dossiers partagés.

Limitation de l'accès aux partages requis.

Supprimez le groupe Tout le monde et accordez à la place des autorisations spécifiques. Tout le monde est utilisé lorsque vous n'imposez pas de restriction sur l'accès au partage.

Remarques supplémentaires

Si vous n'autorisez pas l'administration distante de l'ordinateur, supprimez les partages administratifs non utilisés tels que C$ et Admin$.

Remarque : certaines applications telles que Microsoft Management Server (SMS) ou Microsoft Operations Manager (MOM), peuvent nécessiter des partages administratifs. Pour plus d'informations, consultez l'article 318751 de la base de connaissances Microsoft, « COMMENT FAIRE : Supprimer des partages administratifs dans Windows Server 2003 ».

Étape 7 : Ports

Par défaut, SQL Server examine le port TCP 1433 et utilise le port UDB 1434 pour la négociation client-serveur. Associez pare-feu et stratégies IPSec pour limiter l'accès à ces ports et réduire les occasions d'attaques offertes aux attaquants.

Au cours de cette étape vous devez :

  • Restreindre l'accès au port SQL Server.

  • Configurer les instances nommées pour écouter sur le même port.

  • Configurer le pare-feu pour prendre en charge le trafic DTC (le cas échéant).

Limitation de l'accès au port SQL Server

Utilisez un pare-feu de périmètre pour interdire l'accès direct d'Internet aux ports de SQL Server ? par défaut, les ports TCP 1433 et UDP 1434. Cette opération ne protège pas votre serveur des attaques internes. Configurez les stratégies IPSec pour restreindre l'accès, via les ports TCP 1433 et UDP 1434, des serveurs Web ou d'application se connectant à la base de données.

Pour plus d'informations, consultez la rubrique « Procédure : utilisation d'IPSec » de la section « Procédures » de ce guide.

Configuration des instances nommées pour écouter sur le même port.

Par défaut, les instances nommées de SQL Server allouent de manière dynamique un numéro de port au client et utilisent la négociation UDP pour lui permettre de situer une instance nommée. Pour éviter d'ouvrir une plage de numéros de port sur le pare-feu interne ou d'avoir à créer plusieurs stratégies IPSec, utilisez l'utilitaire de réseau SQL Server pour configurer les instances de sorte qu'elles écoutent sur un numéro de port spécifique.

Si vous reconfigurez le numéro de port sur le serveur, vous devez également reconfigurer tous les clients pour vous assurer qu'ils se connectent au numéro de port approprié. Vous pouvez ici utiliser l'utilitaire de réseau client, mais cet utilitaire ne doit pas être installé sur un serveur Web. Les applications doivent en revanche spécifier le numéro de port dans leurs chaînes de connexion en ajoutant ce numéro à l'attribut de serveur ou celui de la source de données, comme l'illustre le code qui suit.

"Server=VotreServeur|AdresseIPVotreServeur,NuméroPort"

Configuration du pare-feu pour prendre en charge le trafic DTC (le cas échéant).

Si vos applications utilisent les transactions de services d'entreprises (COM+) et nécessitent les services de DTC, vous devez configurer spécifiquement le pare-feu qui sépare votre application Web de votre serveur de base de données pour autoriser le trafic DTC entre les instances séparées DTC et entre DTC et SQL Server.

Pour plus d'informations sur l'ouverture des ports pour DTC, consultez l'article 250367 de la base de connaissances Microsoft, « INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall ».

Remarques supplémentaires

Pensez à utiliser l'option Masquer le serveur dans l'utilitaire de réseau serveur comme indiqué dans la figure 18.4. Si vous sélectionnez cette option dans la boîte de dialogue des propriétés TCP/IP de l'utilitaire réseau SQL, SQL Server sera configuré pour écouter sur le port 2433. Cette option désactive les réponses aux requêtes de diffusions issues des clients qui tentent de répertorier les instances SQL Server.

Cette mesure n'est pas sûre à 100 % pour masquer complètement le port SQL Server. Le masquage complet du port est impossible car il existe de nombreuses façons d'énumérer des ports et de découvrir son emplacement.

Remarque : cette option ne peut être utilisée que si vous n'utilisez qu'une seule instance de SQL Server. Pour plus d'informations, consultez l'article 308091 de la base de connaissances Microsoft, « BUG: Hide Server Option Cannot Be Used on Multiple Instances of SQL Server 2000 ».

Activation de l'option Masquer le serveur à partir de l'utilitaire de réseau SQL Server

Figure 18.4
Activation de l'option Masquer le serveur à partir de l'utilitaire de réseau SQL Server

Étape 8 : Registre

Lors de son installation, SQL Server crée un certain nombre d'entrées et de sous-entrées de registre qui préservent les paramètres vitaux de configuration du système. Il est important de protéger ces paramètres pour empêcher un attaquant de les modifier et de compromettre ainsi la sécurité de votre installation SQL Server.

Lors de son installation, SQL Server crée les entrées et sous-entrées de registre suivantes

  • Pour une instance par défaut :

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER
  • Pour une instance nommée :

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MICROSOFT SQL SERVER\INSTANCENAME
  • Pour le service SQL :

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSSQLSERVER

Au cours de cette étape vous devez :

  • Vérifier les autorisations des clés de registre SQL Server.

  • Sécuriser le SAM (serveurs autonomes uniquement).

Vérification des autorisations des clés de registre SQL Server.

Utilisez Regedt32.exe pour vérifier que le groupe Tout le monde ne dispose pas d'autorisation sur les clés de registre SQL Server indiquées ci-dessus. Par défaut, les contrôles suivants sont définis comme suit :

Administrateurs : Contrôle total
Compte du service SQL Server : Contrôle total

Remarque : l'outil Microsoft Baseline Security Analyzer va vérifier les autorisations du registre. Utilisez l'outil comme une alternative à la vérification manuelle des autorisations avec Regedt32.exe.

Sécurisation de SAM (serveurs autonomes uniquement).

Les serveurs autonomes stockent des hachages de nom de compte et de mots de passe unidirectionnels (Lmhash) dans la base de données SAM locale, qui fait partie du registre. Généralement, seuls les membres du groupe Administrateurs ont accès aux informations du compte.

Bien que les mots de passe ne soient pas réellement stockés dans le SAM et que les hachages de mots de passe ne soient pas réversibles, si un attaquant obtient une copie de la base de données SAM, il peut utiliser les techniques de piratage brut des mots de passe pour obtenir des informations d'identification valides.

Limitez le stockage LMHash dans la SAM en créant la clé (non la valeur) NoLMHash dans le registre, comme illustré ci-dessous.

HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

Pour plus d'informations, consultez l'article 299656 de la base de connaissances Microsoft, « How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases ».

Étape 9 : Audit et journalisation

L'audit n'empêche pas les attaques de système bien qu'il s'agisse d'un support vital pour identifier les intrus, les attaques en cours et pour diagnostiquer les empreintes d'attaque. Il est important d'activer tous les mécanismes d'audit à votre disposition, y compris l'audit au niveau du système d'exploitation Windows et celui de la journalisation SQL Server. SQL Server prend également en charge un audit étendu de niveau C2. Ce dernier peut être nécessaire dans les scénarios d'application dans lesquels les exigences en matière d'audit sont strictes.

Au cours de cette étape vous devez :

  • Consigner toutes les tentatives infructueuses de connexion à Windows.

  • Consigner toutes les actions qui ont échoué dans le système de fichiers.

  • Activer l'audit de connexion de SQL Server.

Consignation de toutes les tentatives infructueuses de connexion à Windows

Vous devez consigner toutes les tentatives infructueuses de connexion à Windows pour pouvoir détecter et suivre tout comportement malveillant.

  • Pour auditer les tentatives infructueuses de connexion

    1. Démarrez l'outil de stratégie de sécurité locale.

    2. Développez Stratégies locales, puis sélectionnez Stratégie d'audit.

    3. Double-cliquez sur Auditer les événements de connexion aux comptes.

    4. Cliquez sur Échec, puis sur OK.

Les échecs de connexion à Windows sont enregistrés comme événements dans le journal des événements de sécurité Windows. Les numéros d'événements suivants sont suspects :

  • 531. Ce code signifie qu'une tentative de connexion a eu lieu à l'aide d'un compte désactivé.

  • 529. Ce code signifie qu'une tentative de connexion a eu lieu via un compte utilisateur inconnu ou un compte utilisateur connu mais avec un mot de passe incorrect. L'augmentation inattendue du nombre d'événements de ce type peut traduire une tentative de recherche de mots de passe.

Consignation de toutes les actions qui ont échoué dans le système de fichiers.

Utilisez l'audit NTFS sur le système de fichiers pour détecter les tentatives potentiellement malveillantes. Il s'agit d'un processus en deux étapes :

  • Pour activer la consignation

    1. Démarrez l'outil de stratégie de sécurité locale.

    2. Développez Stratégies locales, puis sélectionnez Stratégie d'audit.

    3. Double-cliquez sur Auditer l'accès aux objets.

    4. Cliquez sur Échec, puis sur OK.

  • Pour consigner toutes les actions qui ont échoué dans le système de fichiers

    1. Démarrez l'Explorateur Windows et placez-vous à la racine du système de fichiers.

    2. Cliquez avec le bouton droit sur la racine du système de fichiers et choisissez Propriétés.

    3. Cliquez sur l'onglet Sécurité.

    4. Cliquez sur l'onglet Paramètres avancés, puis sur l'onglet Audit.

    5. Cliquez sur Ajouter, puis entrez Tout le monde dans le champ relatif au nom de l'objet à sélectionner.

    6. Cliquez sur OK, puis cochez la case Contrôle total dans la colonne Échec pour auditer tous les événements ayant échoué.

      Par défaut, cette opération s'applique au dossier courant ainsi qu'à tous les sous-dossiers et fichiers.

    7. Cliquez sur OK trois fois pour refermer toutes les boîtes de dialogue ouvertes.

Les événements ayant échoué sont consignés dans le journal des événements de sécurité Windows.

Activation de l'audit de connexion de SQL Server.

Par défaut, l'audit de connexion SQL Server n'est pas activé. Vous devez, au minimum, auditer les connexions qui ont échoué. L'audit des tentatives infructueuses de connexion permet de détecter un attaquant tentant de pirater les mots de passe d'un compte. Pour plus d'informations sur l'activation de l'audit SQL Server, reportez-vous à la rubrique « Étape 10 : Sécurité SQL Server ».

Remarques supplémentaires

Vous trouverez ci-dessous des mesures complémentaires à prendre en compte lors des audits et consignations :

  • Envisagez d'arrêter le système si vous ne parvenez pas à consigner les audits de sécurité. Cette option de la stratégie est définie dans les Options de sécurité des Paramètres de sécurité locaux de la console de gestion. Utilisez ce paramètre pour les serveurs hautement sécurisés.

  • Utilisez l'audit de niveau C2. SQL Server offre des fonctionnalités d'audit compatibles avec la certification C2 du gouvernement américain. L'audit de niveau C2 fournit nettement plus d'informations d'audit au prix cependant d'exigences supérieures de stockage sur le disque.

Étape 10 : Sécurité de SQL Serveur

Les paramètres présentés dans cette section sont configurés via l'onglet Sécurité de la boîte de dialogue Propriétés de SQL Server dans Enterprise Manager. Les paramètres s'appliquent à toutes les bases de données dans une seule et même instance de SQL Server. La boîte de dialogue Propriétés de SQL Server est illustrée en figure 18.5.

Propriétés de sécurité SQL Serveur

Figure 18.5
Propriétés de sécurité SQL Server

Au cours de cette étape vous devez :

  • Définir l'authentification Windows uniquement pour SQL Server.

  • Définir le niveau d'audit de SQL Server sur Échec ou Tous.

  • Exécuter SQL Server via le compte le moins privilégié.

Définition de l'authentification Windows uniquement pour SQL Server

Nous vous recommandons de configurer SQL Server de telle sorte qu'il ne prenne en charge que l'authentification Windows, compte tenu des avantages qu'elle procure. Les informations d'identification ne sont pas transmises sur le réseau ; vous évitez les noms d'utilisateur et mots de passe imbriqués dans les chaînes de connexion à la base de données ; la sécurité peut être gérée plus facilement dans la mesure où vous travaillez avec un seul modèle de sécurité et non avec un modèle de sécurité SQL Server distinct ; la sécurité de la connexion est renforcée grâce aux stratégies de délai d'expiration des mots de passe, de longueurs minimales et de verrouillage des comptes.

  • Pour configurer l'authentification Windows uniquement

    1. Démarrez SQL Server Enterprise Manager, développez le Groupe SQL Server, puis votre serveur SQL.

    2. Cliquez avec le bouton droit de la souris sur votre serveur SQL, puis cliquez sur Propriétés.

    3. Cliquez sur l'onglet Sécurité.

    4. Sélectionnez Uniquement Windows, puis cliquez sur OK.

    5. Redémarrez SQL Server pour que les modifications prennent effet.

Définition du niveau d'audit de SQL Server sur Échec ou Tous.

Par défaut, l'audit de connexion SQL Server n'est pas activé. Vous devez, au minimum, auditer les connexions infructueuses.

Remarque : les entrées du journal sont écrites dans les fichiers journaux SQL. Par défaut, ces journaux sont stockés dans C:\Program Files\Microsoft SQL Server\MSSQL\LOG. Vous pouvez utiliser tout éditeur de texte, tel que le Bloc-notes, pour les visualiser.

  • Pour activer l'audit SQL Server

    1. Démarrez SQL Server Enterprise Manager, développez le Groupe SQL Server, puis votre serveur SQL.

    2. Cliquez avec le bouton droit de la souris sur votre serveur SQL, puis cliquez sur Propriétés.

    3. Cliquez sur l'onglet Sécurité.

    4. Définissez le niveau d'audit sur Tous ou sur Échec.

    5. Redémarrez SQL Server pour que les modifications apportées à la stratégie d'audit prennent effet.

Pour plus d'informations sur les journaux d'audit SQL Server, consultez la section « Understanding the Audit Log » de l'article TechNet « SQL Server 2000 Auditing » à l'adresse http://technet2.microsoft.com/WindowsServer/en/library/753fcae1-8b02-48de-b2af-f431277cf72a1033.mspx?mfr=true.

Exécution de SQL Server avec le compte le moins privilégié

Exécutez le service SQL Server à partir d'un compte le moins privilégié possible pour réduire les dommages pouvant être perpétrés par un attaquant qui parviendrait à exécuter des commandes du système d'exploitation à partir de SQL Server. Le compte du service SQL Server ne doit pas accorder de privilèges élevés, tels que l'appartenance au groupe Administrateurs.

  • Pour configurer l'exécution de SQL Server comme compte

    Cette procédure fait appel à Enterprise Manager et non pas au composant logiciel enfichable MMC des Services car Enterprise Manager accorde automatiquement les droits d'utilisateur dont a besoin le service SQL Server.

    1. Démarrez SQL Server Enterprise Manager, développez le Groupe SQL Server, puis votre serveur SQL.

    2. Cliquez avec le bouton droit de la souris sur votre serveur SQL, puis cliquez sur Propriétés.

    3. Cliquez sur l'onglet Sécurité.

    4. Cliquez sur Ce compte dans le groupe Compte du service de démarrage. Entrez le nom d'utilisateur et le mot de passe de votre compte le moins privilégié.

    5. Redémarrez SQL Server pour que les modifications prennent effet.

      Remarque : si vous utilisez le service SQLSERVERAGENT, le compte « Exécuter en tant que » devra être également modifié. Utilisez le composant logiciel enfichable MMC des Services pour modifier ce paramètre.

Pour plus d'informations sur la création d'un compte peu privilégié pour exécuter SQL Server, reportez-vous à la rubrique « Étape 4 : Comptes ».

Étape 11 : Noms de connexion, utilisateurs et rôles

Pour pouvoir accéder aux objets dans une base de données, vous devez passer deux couches de vérification de la sécurité. Vous devez tout d'abord présenter à SQL Server un ensemble valide d'informations d'identification. Si vous utilisez l'authentification Windows, vous devrez vous connecter par le biais d'un compte disposant d'un nom d'accès SQL Server. Si vous utilisez l'authentification SQL Server, vous devrez fournir un nom d'utilisateur et un mot de passe valides.

Le nom de connexion vous accorde l'accès à SQL Server. Pour accéder à une base de données, ce nom de connexion doit être associé à un utilisateur de la base de données, au sein de la base de données à laquelle vous voulez vous connecter. Si le nom de connexion est associé à l'utilisateur de la base de données, ses fonctionnalités dans la base sont déterminées par les autorisations de cet utilisateur. Si le nom de connexion n'est pas associé à un utilisateur spécifique de la base de données, ses fonctionnalités sont alors définies par les autorisations accordées au rôle public dans la base de données. Tous les noms de connexions valides sont associés au rôle public, qui existe dans toutes les bases de données et ne peut pas être supprimé. Par défaut, le rôle public d'une base de données que vous créez n'a aucune autorisation.

Suivez les recommandations ci-dessous pour configurer les paramètres d'autorisation dans la base de données :

  • Utilisez un mot de passe sa (administrateur système) fiable.

  • Supprimez le compte utilisateur invité de SQL Server.

  • Supprimez le nom de connexion au serveur BUILTIN\Administrateurs.

  • N'accordez pas d'autorisation au rôle public.

Utilisation d'un mot de passe sa (administrateur système) fiable.

Le compte administrateur système par défaut (sa) est sujet à un nombre infini d'attaques. C'est le membre par défaut du rôle d'administration de SQL Server sysadmin. Veillez à utiliser un mot de passe fiable pour ce compte.

Important Le compte sa reste actif même si vous passez de l'authentification SQL à l'authentification Windows.

Utilisez des mots de passe fiables pour tous les comptes, et plus particulièrement pour les comptes privilégiés, tels que les membres des rôles sysadmin et db_owner. Si vous utilisez la réplication, vous devez également utiliser un mot de passe fiable pour le compte distributor_admin utilisé pour établir des connexions avec les serveurs distributeurs distants.

Suppression du compte utilisateur invité de SQL Server

Lors de l'installation de SQL Server, le système crée un compte invité si le compte invité de Windows 2000 est activé. Un nom de connexion adopte l'identité invité s'il a accès à SQL Server mais pas à la base de données via un compte utilisateur de base de données.

Il est recommandé de désactiver le compte invité. Par ailleurs, supprimez le compte invité de toutes les bases définies par l'utilisateur. Notez que vous ne pouvez pas supprimer le compte invité des bases de données principale, tempdb, de réplication et de distribution.

Suppression du nom de connexion au serveur BUILTIN\Administrateurs.

Par défaut, le groupe Windows local BUILTIN\Administrateurs est ajouté au rôle de serveur fixe sysdamin pour administrer SQL Server. Ceci signifie que les administrateurs de domaine, membres du groupe BUILTIN\Administrateurs ont accès sans restriction à la base de données SQL Server. La plupart des sociétés différencient le rôle d'administrateur de domaine de celui d'administrateur de base de données. Si tel est le cas, supprimez le nom de connexion BUILTIN\Administrateurs de SQL Server. Il peut être intéressant de créer un groupe Windows spécifique contenant l'administration spécifique des bases de données et de l'ajouter comme nom de connexion au serveur SQL, comme l'illustre la procédure qui suit.

  • Pour ajouter un nouveau nom de connexion aux administrateurs de la base de données

    1. Démarrez Enterprise Manager.

    2. Développez Microsoft SQL Server, Groupe SQL Server, puis votre serveur SQL.

    3. Développez le dossier Sécurité, sélectionnez Connexions à l'aide du bouton droit de la souris et cliquez sur Nouvelle connexion.

    4. Dans le champ Nom, entrez le nom du groupe personnalisé Windows contenant uniquement les administrateurs de base de données.

    5. Cliquez sur l'onglet Rôles des serveurs puis sur Administrateurs du système.

Vous ajoutez ainsi la nouvelle collection au rôle du serveur sysadmin.

  • Pour supprimer la connexion BUILTIN\Administrateurs

    1. Démarrez Enterprise Manager.

    2. Développez Microsoft SQL Server, Groupe SQL Server, puis votre serveur SQL.

    3. Développez le dossier Sécurité et sélectionnez Connexion. Si BUILTIN\Administrateurs apparaît dans la liste des connexions, sélectionnez-le, puis cliquez avec le bouton droit sur Supprimer pour supprimer la connexion.

Pour plus d'informations sur la reconfiguration des comptes du service SQL après installation, consultez l'article MSDN « Changing Passwords and User Accounts » à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/instsql/in_afterinstall_4p0z.asp

N'accordez pas d'autorisation au rôle public.

Toutes les bases de données comportent un rôle public de base de données. Tous les utilisateurs, groupes et rôles sont membres du rôle public. Vous ne pouvez pas supprimer de membres du rôle public. Vous pouvez, en revanche, ne pas accorder d'autorisation au rôle public pour accéder aux tables de la base de données de votre application, aux procédures stockées ou à d'autres objets. Si vous accordez ces accès, vous ne pourrez pas obtenir l'autorisation que vous souhaitez via les rôles de base de données définis par l'utilisateur car le rôle public accorde les autorisations par défaut aux utilisateurs de la base de données.

Remarques supplémentaires

Tenez compte également des recommandations suivantes lorsque vous configurez les noms de connexion SQL Server, les utilisateurs et les rôles :

  • Limitez le nombre de membres de sysadmin. Par souci de facilité de gestion individuelle, limitez le nombre de comptes membres du rôle sysadmin. Idéalement, ce rôle ne doit pas avoir plus de deux utilisateurs membres.

  • Accordez des autorisations restreintes sur la base de données. N'attribuez aux comptes que les autorisations minimales nécessaires pour effectuer une tâche. Évitez d'utiliser les rôles intégrés tels que db_datareader et db_datawriter. Ces rôles n'offrent pas de possibilité d'affinage des autorisations et ont accès à tous les objets personnalisés de votre base de données.

  • Ne modifiez pas les autorisations par défaut qui s'appliquent aux objets SQL Server. Dans les versions SQL Server antérieures au Service Pack 3, le rôle public n'a pas accès aux divers objets de la base de données SQL Server par défaut. Avec le Service Pack 3, le concept de sécurité a été revu et la sécurité a été améliorée en supprimant le rôle public là où il n'était pas nécessaire et en appliquant une vérification des rôles plus fine.

Étape 12 : Objets de la base de données SQL Server

SQL Server fournit deux bases de données exemples pour le développement et la formation ainsi qu'une série de procédures stockées intégrées et de procédures stockées étendues. Les bases de données exemples ne doivent pas être installées sur les serveurs de production et les procédures stockées puissantes et étendues doivent être sécurisées.

Au cours de cette étape vous devez :

  • Supprimer les bases de données exemples.

  • Sécuriser les procédures stockées.

  • Sécuriser les procédures stockées étendues.

  • Restreindre l'accès à cmdExec au rôle sysadmin.

Suppression des bases de données exemples

Utilisez SQL Server Enterprise Manager pour supprimer toutes les bases de données exemples. Par défaut, SQL Server inclut les bases exemples Pubs et Northwind.

Sécurisation des procédures stockées

Limitez l'accès aux procédures stockées de votre application. N'accordez pas au rôle public ni à l'utilisateur invité l'accès aux procédures stockées que vous créez. Votre principale ligne de défense pour sécuriser les procédures stockées consiste à vous assurer que vous utilisez bien une authentification fiable, puis à octroyer minutieusement les permissions pour n'autoriser que certains utilisateurs à exécuter les procédures stockées.

L'approche recommandée consiste à créer une connexion SQL Server pour votre application, à mapper cette connexion sur un utilisateur de la base de données, à ajouter cet utilisateur à un rôle de la base défini par l'utilisateur, puis à accorder les autorisations au rôle.

Sécurisation des procédures stockées étendues

La suppression des procédures stockées n'a pas été testée et n'est pas prise en charge.

Restriction de l'accès à cmdExec au rôle sysadmin.

La fonction cmdExec est utilisée par l'agent SQL Server pour exécuter les applications de ligne de commande Windows ainsi que les scripts programmés par l'agent SQL Server. Avant le Service Pack 3, l'agent SQL Server autorisait par défaut les utilisateurs qui ne faisaient pas partie du rôle sysadmin à planifier les travaux qui pouvaient nécessiter un accès privilégié au système. Vous devez modifier ce paramètre pour ne permettre qu'aux membres du rôle sysadmin de planifier les travaux.

  • Pour restreindre l'accès à cmdExec au rôle sysadmin

    1. Démarrez SQL Server Enterprise Manager, développez le Groupe SQL Server, puis votre SQL Server.

    2. Développez le nœud Gestion, cliquez avec le bouton droit sur Agent SQL Server, puis cliquez sur Propriétés.

      La boîte de dialogue Propriétés de l'Agent SQL Server s'affiche.

    3. Cliquez sur l'onglet Système de travaux.

    4. Au bas de la boîte de dialogue, cochez la case Seuls les utilisateurs ayant des privilèges SysAdmin peuvent exécuter les étapes de tâche CmdExec et ActiveScripting.

    5. Cliquez sur OK.

Remarque : cette modification peut nécessiter que vous fournissiez un nom d'utilisateur et un mot de passe. Si le compte du service SQL Server est l'utilisateur le moins privilégié (comme recommandé précédemment dans ce module), vous serez invité à fournir le nom d'utilisateur et le mot de passe d'un compte administrateur disposant des privilèges pour modifier le service.

Instantané d'un serveur de base de données sécurisé

Avec un cliché des attributs d'un serveur de base de données SQL Server sécurisé, vous êtes à même de comparer aisément et rapidement les paramètres avec ceux de votre propre serveur. Les paramètres présentés dans le tableau 18.5 reposent sur l'analyse de serveurs de base de données SQL dont la résistance aux attaques a été prouvée et ayant fait preuve de solides pratiques de sécurité.

Tableau 18.5 : Instantané d'un serveur de base de données sécurisé

Composant

Caractéristiques

Correctifs et mises à jour

Utilisation des derniers Service Packs et correctifs pour Windows 2000 et SQL Server

Services

Les services inutiles sont désactivés.
Le service MS DTC est désactivé s'il est inutilisé.
Le service MSSearch est désactivé s'il n'est pas requis.
Le service SQLServerAgent est désactivé s'il n'est pas nécessaire.
Le service MSSQLServerADHelper est désactivé s'il n'est pas nécessaire.

Protocoles

Les protocoles inutiles sont supprimés ou désactivés.
Les protocoles suivants ne sont pas activés sur le serveur : NetBIOS et SMB.
La pile TCP/IP est renforcée.

Comptes

Le compte du service SQL Server est sécurisé (compte le moins privilégié).
Les comptes Windows inutiles sont supprimés ou désactivés.
Le compte Invité Windows est désactivé.
Un nouveau compte administrateur est créé.
La stratégie de mot de passe fiable est renforcée.
Les connexions distantes sont limitées.
Les sessions NULL (connexions anonymes) sont désactivées.
La délégation d'un compte doit être approuvée.
Les comptes partagés ne sont pas utilisés.
L'appartenance au groupe Administrateurs locaux est limitée (pas plus de deux membres idéalement).
Le compte Administrateur est limité aux connexions interactives (ou une solution d'administration distante sécurisée est prévue).
L'authentification NTLMv2 est activée et renforcée (LMCompatibilityLevel défini sur 5).

Fichiers et répertoires

Les volumes sont formatés avec NTFS.
Le groupe Tout le monde n'a aucun droit sur les répertoires d'outils et système. Les répertoires d'exemple, d'aide et les répertoires d'administration non utilisés sont supprimés du serveur.
Les autorisations sont renforcées sur le dossier d'installation de SQL Server.
Les mots de passe sont supprimés des fichiers journaux d'installation des Service Pack 1 et 2.
Les outils, les utilitaires et les kits de développement (SDK) sont supprimés.
Les applications inutilisées sont supprimées.
Les fichiers de données sensibles sont codés à l'aide d'EFS. Le codage est facultatif pour les fichiers de base de données (.mdf) mais pas pour les fichiers journaux (.ldf).

Partages

Les partages inutiles sont supprimés du serveur.
L'accès est limité aux partages requis.
Les partages ne sont pas accessibles à Tout le monde sauf en cas de besoin.
Les partages administratifs (C$, Admin$) sont supprimés s'ils ne sont pas requis.

Ports

Tous les ports à l'exception du port d'écoute de SQL Server [1433 par défaut] sont bloqués.
Les instances nommées sont configurées pour écouter sur le même port.
Un port SQL Server non standard (pas le port TCP 1443) sert de couche de protection complémentaire.
L'option de masquage du serveur sert de couche complémentaire de protection (facultatif).
Le pare-feu est configuré pour prendre en charge le trafic DTC (le cas échéant).
Un pare-feu est utilisé pour séparer les utilisateurs du port TCP/IP SQL.

Registre

Le groupe Tout le monde est supprimé des clés de registre de SQL Server.
SAM (serveurs autonomes uniquement) est sécurisé.

Audit et journalisation

Les tentatives infructueuses de connexion à Windows sont consignées.
Les actions qui ont échoué sur le système de fichiers sont consignées.
L'audit de connexion SQL Server est activé.

Paramètres de SQL Server

 

Sécurité de SQL Serveur

Le paramètre d'authentification pour SQL Server est défini, si possible, sur Windows uniquement.
Le niveau d'audit de SQL Server est défini sur Échec ou Tous.
Le compte de service de démarrage de SQL Server est le compte le moins privilégié.

Noms de connexion, utilisateurs et rôles SQL

Le compte sa a un mot de passe fiable.
Les comptes Invité SQL Server sont supprimés des bases de données non système.
Le groupe BUILTIN\Administrateurs est supprimé des noms de connexion SQL Server.
Le rôle sysadmin ne comprend pas le groupe BUILTIN\Administrateurs.
Aucune autorisation n'est accordée au rôle public.
Le rôle sysadmin ne comprend pas plus de deux utilisateurs.
Les autorisations d'accès aux bases de données sont limitées (rôles intégrés non granulaires tels que db_datareader et db_datawriter évités).
Les autorisations par défaut pour les objets SQL Server ne sont pas modifiées.

Objets de la base de données SQL Server

Toutes les bases de données exemples sont supprimées du serveur.
Les procédures stockées sont sécurisées.
Les procédures stockées étendues sont sécurisées.
L'utilisation cmdExec est réservée au rôle sysadmin uniquement.

Remarques supplémentaires

Outre les étapes décrites dans ce module, tenez compte des conseils qui suivent :

  • Installez un certificat sur le serveur de base de données. Si vous utilisez l'authentification Windows (NTLM ou Kerberos), les informations d'identification de connexion ne sont pas transmises à SQL Server via le réseau. Si vous utilisez l'authentification SQL, il peut être intéressant de sécuriser les informations d'identification car elles sont transmises à SQL Server sous forme non codée. Pour ce faire, installez un certificat sur le serveur de base de données. Vous obtiendrez ainsi le codage automatique des informations d'identification SQL sur le câble. Nous vous conseillons également de vous assurer que votre application stocke de façon sûre les chaînes de connexion des bases de données. Pour plus d'informations, consultez le module 14, « Création d'un accès sécurisé aux données ».

  • Limitez l'accès aux commandes sensibles et aux procédures stockées. SQL Server fournit de puissants points de raccordement dans le système d'exploitation. Ainsi, vous pouvez utiliser la procédure stockée étendue xp_cmdshell pour exécuter toute commande du système d'exploitation. Si un attaquant parvient à exécuter arbitrairement des commandes dans la base de données, via une vulnérabilité d'injection SQL, sa capacité à exécuter les commandes du système d'exploitation est limitée uniquement par les informations d'identification de sécurité du compte utilisé pour exécuter SQL Server. C'est la principale raison pour laquelle vous devez exécuter SQL Server avec le compte local le moins privilégié.

  • Utilisez un ordinateur dédié comme serveur de base de données. De plus, mettez-le en cluster pour le basculement.

  • Protégez physiquement le serveur de base de données. Placez le serveur dans une salle informatique sécurisée.

  • Limitez les connexions à distance. Ne permettez à personne, à l'exception de l'administrateur, de se connecter localement au serveur.

Rester protégé

Vous devez surveiller régulièrement l'état de protection de votre serveur de base de données et le mettre à jour régulièrement pour empêcher que ne soient exploitées les toutes dernières vulnérabilités. Pour préserver la sécurité de votre serveur de base de données :

  • Effectuez des sauvegardes régulières.

  • Procédez à l'audit des membres des groupes.

  • Surveillez les journaux d'audit.

  • Restez à jour en matière de Service Packs et de correctifs.

  • Procédez à des évaluations de votre sécurité.

  • Utilisez des services de notification de sécurité.

Sauvegardes régulières

Vous devez être capable de restaurer les données en cas d'altération de celles-ci. Si vous disposez d'un système de récupération, testez-le avant d'en avoir réellement besoin. Votre première récupération réelle des données ne doit pas correspondre à votre premier test du processus de sauvegarde et de récupération. Pour plus d'informations sur la sauvegarde et la récupération de SQL Server, consultez les ressources suivantes :

Audit des membres des groupes

Gardez la trace de l'appartenance aux groupes d'utilisateurs, plus particulièrement pour les groupes privilégiés tels que les administrateurs. La commande suivante permet de répertorier les membres du groupe Administrateurs :
net localgroup administrateurs

Surveillance des journaux d'audit

Surveillez les journaux d'audit régulièrement et analysez les fichiers journaux en les visualisant manuellement ou utilisez la technique décrite dans l'article 296085 de la Base de connaissances, « How To: Use SQL Server to Analyze Web Logs ».

À la pointe des Service Packs et des correctifs

Définissez un calendrier pour analyser vos logiciels de serveurs et souscrivez à des alertes de sécurité. Utilisez MBSA pour rechercher régulièrement les correctifs manquants sur votre serveur. Les liens suivants donnent accès aux mises à jour les plus récentes :

Évaluation de votre sécurité

Utilisez l'outil MBSA pour rechercher régulièrement les vulnérabilités de sécurité et identifier les correctifs et mises à jour manquants. Planifiez l'exécution quotidienne de MBSA et analysez les résultats pour agir en conséquence. Pour plus d'informations sur l'automatisation de MBSA, consultez la rubrique « Procédure : utilisation de MBSA » de la section « Procédures » de ce guide.

Services de notification de sécurité

Utilisez les services Microsoft répertoriés dans le tableau 18.6 pour obtenir les bulletins de sécurité avec notification des vulnérabilités possibles du système.

Tableau 18.6 Services de notification de sécurité

Service

Emplacement

Site Web de sécurité TechNet

www.microsoft.com/france/technet/securite
Consultez sur cette page Web les bulletins de sécurité disponibles pour votre système.

Microsoft Security Notification Service

http://www.microsoft.com/france/securite/newsletters.mspx.
Utilisez ce service pour vous abonner aux bulletins électroniques qui vous préviendront de la disponibilité des nouveaux correctifs et des mises à jour.

Vous pouvez également vous abonner aux services d'alerte de sécurité de l'industrie présentés dans le tableau 18.7. Ces services vous permettent d'évaluer les menaces de vulnérabilité lorsqu'un correctif n'est pas encore disponible.

Tableau 18.7 Services de notification de sécurité de l'industrie

Service

Emplacement

Liste de diffusion de conseil du CERT

http://www.cert.org/contact_cert/certmaillist.html
Des informations et conseils sont envoyés à mesure que les vulnérabilités sont rapportées.

MISE À JOUR de sécurité Windows & .NET Magazine

http://email.winnetmag.com/winnetmag/winnetmag_prefctr.asp
Annonce les dernières failles de sécurité et identifie les correctifs.

NTBugtraq

http://www.ntbugtraq.com/default.asp?pid=31&sid=1#020
Forum de discussion ouvert sur les vulnérabilités de sécurité Windows et les attaques. Il est notamment question des vulnérabilités qui n'ont pas encore de correctif.

Administration distante

Il n'est pas rare que les administrateurs aient besoin de pouvoir administrer plusieurs serveurs. Veillez à ce que les exigences de votre solution d'administration distante ne compromettent pas la sécurité. Si vous souhaitez profiter des capacités d'administration à distance, lisez les recommandations qui suivent pour améliorer la sécurité :

  • Limitez le nombre de comptes administratifs. Ceci inclut la limitation du nombre de comptes d'administrateur, mais aussi de comptes autorisés à se connecter à distance.

  • Limitez les outils. Parmi les principales options, on retiendra SQL Enterprise Manager et Terminal Services. Ces deux outils utilisent la sécurité Windows. Les principales considérations ici consistent donc à restreindre le nombre de comptes Windows et les ports que vous utilisez.

  • Limitez le nombre d'ordinateurs autorisés à administrer le serveur. Vous pouvez utiliser IPSec pour définir les ordinateurs autorisés à se connecter à votre système SQL Server.

Sécurisation des services Terminal Server

Il est possible d'utiliser les services Microsoft Terminal Server pour administrer à distance et de façon sûre votre serveur de base de données.

Les services Terminal Server reposent sur le protocole propriétaire de Microsoft appelé RDP (Remote Desktop Protocol). RDP utilise le port TCP 3389 et supporte deux utilisateurs concurrents. Les sections qui suivent décrivent l'installation et la configuration des services Terminal Server pour une administration sûre :

  • Installez les services Terminal Server.

  • Configurez les services Terminal Server.

Installation des services Terminal Server
  • Pour installer les services Terminal Server, procédez comme suit :

    1. Installez les services Terminal Server via la commande Ajout/Suppression de programmes du panneau de configuration. Utilisez l'option Ajout/Suppression de composants Windows. Il n'est pas nécessaire d'installer le service de licence des services Terminal Server pour l'administration distante.

    2. Configurez les services Terminal Server pour le mode d'administration distante.

    3. Supprimez du système le compte utilisateur TsInternetUser, créé au cours de l'installation des services Terminal Server. Ce compte est utilisé pour prendre en charge l'accès anonyme par Internet aux services Terminal Server et ne doit pas être activé sur le serveur.

Configuration des services Terminal Server
  • Utilisez le composant logiciel enfichable de configuration MMC des services Terminal Server, disponible dans le groupe de programme Outils d'administration pour configurer les éléments qui suivent

    1. Il existe trois niveaux (bas, moyen et élevé) de codage des connexions aux services Terminal Server. Définissez le codage sur la clé 120 bits. Notez que le pack Cryptage fort Windows doit être installé à la fois sur le serveur et sur le client.

    2. Configurez la session de services Terminal Server pour qu'elle se déconnecte après une certaine durée d'inactivité. Définissez-la pour mettre fin à une session déconnectée. Une session est considérée comme déconnectée si l'utilisateur ferme l'application client de services Terminal Server sans se déconnecter dans un intervalle de 10 minutes.

    3. Enfin, limitez les autorisations d'accès aux services Terminal Server. Utilisez l'onglet d'autorisations RDP de la boîte de dialogue RDP. Par défaut, tous les membres du groupe Administrateurs sont autorisés à accéder aux services Terminal Server. Si vous ne souhaitez pas que tous les membres de ce groupe puissent y accéder, supprimez le groupe et ajouter les comptes individuels pouvant y accéder. Notez que le compte SYSTEM doit figurer dans la liste.

Utilisez une connexion VPN entre le client et le serveur ou un tunnel IPSec pour plus de sécurité. Cette approche fournit une authentification mutuelle et la charge utile RDS est cryptée.

Copie des fichiers via RDP

Les services Terminal Server n'offrent pas de transfert de fichiers intégré. Vous pouvez toutefois installer l'utilitaire de copie de fichiers à partir du kit de ressources Windows 2000 Server pour ajouter la fonction de transfert de fichiers à la fonction de redirection du Presse-papiers dans Terminal Server. Pour plus d'informations sur l'utilitaire et les instructions d'installation, consultez l'article 244732 de la base de connaissances Microsoft, « COMMENT FAIRE : Installer l'outil de copie de fichiers inclus dans le Kit de ressources Windows 2000 ».

Résumé

Les serveurs de base de données sont les principales cibles des attaquants. Ce type de serveur doit donc être protégé contre les attaques internes et externes, au niveau du réseau comme au niveau de l'application. Un serveur de base de données sûr comprend une installation renforcée de SQL Server 2000 sur une installation Windows 2000, associées aux défenses de réseau que procurent les routeurs et pare-feu.

Retrouvez la liste de contrôle aide-mémoire « Liste de contrôle : sécurisation de votre serveur de base de données » dans la section « Listes de contrôle » de ce guide.

Afficher:
© 2014 Microsoft