SQL Server : 8 bonnes pratiques de sécurité

1 - De l'importance des sauvegardes de bases de données cryptées

Pour l'entreprise, les sauvegardes de bases de données revêtent toujours une importance vitale. Si les fichiers de sauvegarde ne sont pas cryptés, ils sont faciles à copier et à restaurer sur n'importe quelle autre installation SQL Server ; une situation qui favorise le vol des données et amoindrit la sécurité. Pour éviter ce scénario peu engageant, l'administrateur de bases de données peut créer des sauvegardes en utilisant la fonction intégrée MEDIAPASSWORD. L'exemple de script ci-dessous permet de créer des sauvegardes de bases de données cryptées dans SQL Server :

BACKUP DATABASE AdventureWorks
TO DISK='C:\AdventureWorks.BAK'
WITH MEDIAPASSWORD='C0mplexP@ssW0rd'
GO

2 - Sécuriser le dossier de sauvegarde de base de données en éliminant les utilisateurs superflus

Un administrateur de bases de données doit s'assurer que l'accès au dossier de sauvegarde est restreint, qu'il n'est accordé qu'aux utilisateurs qui en ont vraiment besoin. Un accès non autorisé peut rendre ce dossier vulnérable, les fichiers de la sauvegarde pouvant alors être copiés sur des serveurs distants. Parallèlement, ce type d'accès peut favoriser la suppression accidentelle de fichiers de sauvegarde vitaux ; suppression qui détruirait la séquence de restauration de la base de données. Aussi est-il essentiel que l'administrateur de bases de données s'assure que seules les personnes appropriées disposent d'un accès au dossier de sauvegarde de la base de données.

3 - Utiliser l'authentification Windows plutôt que le mode d'authentification SQL Server

L'usage de l'authentification Windows pour se connecter à SQL Server constitue une bonne pratique de sécurité. Dans SQL Server, le mode d'authentification Windows permet d'exploiter les politiques en vigueur à l'échelle de l'entreprise concernant Active Directory, les comptes, les groupes et les mots de passe. L'accès devient ainsi plus sécurisé. Si vous utilisez le mode d'authentification SQL Server pour vous connecter, il est déconseillé d'utiliser un compte d'administrateur système (SA). Utiliser une authentification SQL Server ne vous empêche pas de tirer parti des politiques de mot de passe de Windows lorsque vous définissez les mots de passe des comptes d'utilisateur.

4 - Complexifier le mot de passe du compte de l'administrateur système

Si vous utilisez une authentification en mode mixte dans SQL Server, définissez systématiquement un mot de passe complexe pour le compte SA. Une bonne pratique consiste à toujours éviter de connecter des applications Web à SQL Server en utilisant le compte SA. Il faut toujours éviter d'utiliser le compte de l'administrateur système pour procéder à des activités de maintenance au quotidien. Pour les tâches quotidiennes, utilisez des comptes Windows dotés des autorisations adéquates. Bonne pratique toujours, pensez à changer les mots de passe des comptes SA au bout de plusieurs jours.

5 - Auditer les connexions

Dans le cadre de vos bonnes pratiques de sécurité SQL Server, auditez systématiquement les échecs de connexion à votre SGBDR. Une fois l'audit des connexions activé dans SQL Server, les informations relatives aux connexions en échec ou réussies sont consignées dans les journaux des erreurs. Une surveillance régulière de ces journaux permet d'identifier ponctuellement des activités suspicieuses.

6 - Désactiver le service SQL Server Browser

Autre bonne pratique de sécurité SQL Server, l'administrateur de bases de données doit désactiver le service SQL Server Browser lorsqu'il exécute une instance par défaut de SQL Server. Même si vous exécutez une instance nommée, vous pouvez, pour vous y connecter, définir explicitement le port et le mentionner au sein des chaînes de connexion des applications concernées.

7 - Désactiver les fonctions inutilisées dans SQL Server

Lorsqu'elles sont inusitées, désactivez les fonctions telles que XP_CMDSHELL, OLE AUTOMATION, OPENROWSET et OPENDATASET pour réduire la surface d'exposition aux attaques. Le gestionnaire de configuration de Microsoft SQL Server 2005 permet d'activer et de désactiver ces fonctions. Si vous utilisez SQL Server 2008 ou une version ultérieure, vous ferez appel pour cela à la fonction de gestion basée sur des stratégies.

8 - Diminuer les privilèges du compte des services SQL Server

Enfin, dernière bonne pratique, un administrateur de bases de données doit toujours exécuter les services SQL Server au moyen d'un compte de domaine local doté de privilèges minimaux. Evitez d'exécuter les services SQL Server dans le cadre de comptes de système local, d'administrateur local ou d'administrateur de domaine. Toutefois, assurez-vous que le compte des services SQL Server dispose d'une autorisation « Contrôle total » en lecture et en écriture sur les répertoires des données, des journaux et des sauvegardes.