Les bonnes pratiques pour bien protéger SQL Server
Authentifications, mots de passe forts et permissions limitées sont trois des points clés à retenir de cette checklist de bonnes pratiques en matière de sécurité pour SQL Server.
SQL Server est un emplacement de stockage d’informations très critiques pour les entreprises. C’est pourquoi il est important de s’assurer que seuls les utilisateurs autorisés y ont bien accès. Toutefois sécuriser SQL Server sans générer d'erreurs n’est pas tâche facile. Une série de manipulations par l'administrateur SQL est nécessaire pour renforcer les paramètres de sécurité de la base de données. Cet article vous propose une checklist des bonnes pratiques pour bien protéger SQL Server.
Authentification
SQL Server supporte deux modes d’authentification : l’authentification Windows et l’authentification en mode mixte. Selon les bonnes pratiques, vous devez toujours choisir l’authentification Windows pour vos installations de SQL Server à moins que vos applications Legacy existantes ne nécessitent le mode mixte pour des raisons d’accès et de compatibilité descendante.
L’authentification Windows est plus sécurisée que le mode mixte. Lorsqu'elle est activée, les crédences Windows (Kerberos ou Windows NT LAN Manager) sont considérées comme fiables pour se loguer dans SQL Server. Les identifiants Windows utilisent une série de messages chiffrés pour permettre de s'authentifier dans SQL Server et les mots de passe ne transitent pas par le réseau lors de l’authentification. De plus, Active Directory offre un niveau supplémentaire de sécurité grâce au protocole Kerberos. Ainsi l’authentification est plus fiable et sa gestion minimale via les groupes Active Directory pour les accès par rôle à SQL Server. En comparaison, le mode mixte supporte à la fois les comptes Windows et des comptes spécifiques à SQL Server. Les mots de passe pour SQL sont transmis à travers le réseau, les identifiants sont ainsi moins bien protégés.
Protection du compte sysadmin
Le compte sysadmin (sa) est vulnérable lorsqu’il reste inchangé. Et les potentiels attaquants en ont bien conscience. Cela facilite un peu plus le piratage de la solution, s’ils parviennent à prendre le contrôle de ce compte clé. Pour empêcher que le compte sa soit ciblé, renommez le avec un nom de compte différent. Pour cela, rendez-vous dans Object Explorer puis déroulez Logins, puis efectuez un clic droit sur le compte sa. Sélectionnez alors Renommer (Rename). Une autre méthode consiste à exécuter le script T-SQL suivant pour renommer le compte sa :
USE [master]
GO
ALTER LOGIN sa WITH NAME = [<New-name>]
GO
Vous pouvez également désactiver le compte sa sur vos instances SQL Server.
Utiliser des mots de passe forts pour sa et pour les identifiants spécifiques à SQL Server
Lorsque l’authentification est activée, assurez-vous que des mots de passe forts sont bien utilisés pour sa et tous les identifiants spécifiques à SQL Server. Vérifiez en premier les options « Enforce password expiration » et « Enforce password policy » pour sa et les identifiants SQL. Ces deux options garantissent que tous les autres identifiants SQL Server sont conformes aux politiques de login de l’OS sous-jacent. De plus, activez l’option MUST_CHANGE pour chaque nouvel identifiant SQL. Chaque utilisateur devra modifier son mot de passe à la première connexion.
Rôle serveur fixe et permission CONTROL SERVER
Sélectionnez les rôles serveur fixes pour sysadmin car les membres de ces rôles peuvent interagir comme ils le souhaitent avec SQL Server. De plus, n’attribuez pas explicitement la permission CONTROL SERVER aux identifiants Windows, groupe Windows ou SQL car les identifiants avec cette permission disposent de tous les privilèges administrateurs lors d’une installation de SQL Server. Par défaut, le rôle serveur fixe de sysadmin dispose de cette permission.
Administration SQL Server
Evitez d’administrer les instances SQL Server en utilisant le compte sa ou tout autre compte SQL auxquels ont été attribués la permission CONTROL SERVER ou étant membre du rôle fixe server.
Révoquer les accès des utilisateurs invités
Par défaut, un utilisateur invité est présent dans tous les systèmes de base de données, ce qui représente un risque potentiel pour tout environnement fermé, car il ouvre un accès aux identifiants qui ne sont pas associés à un utilisateur dans la base de données. A cause de ce risque, il convient de désactiver l’accès à l’utilisateur invité pour tous les utilisateurs et les bases (sauf msdb). Cela permet de garantir que les membres du rôle serveur public n’ont pas accès aux comptes utilisateurs sur les instances SQL Server, sauf si des accès leur ont explicitement été attribués.
Limiter les permissions attribuées au rôle public
A cause des risques potentiels de sécurité, révoquez les accès des rôles publics sur les procédures suivantes :
N’attribuez pas explicitement de permissions au rôle public sur les procédures stockées utilisateurs et systèmes. Pour lister les procédures stockées disponibles à un rôle public, exécutez la requête suivante :
SELECT o.[name] AS [SPName]
,u.[name] AS [Role]
FROM [master]..[sysobjects] o
INNER JOIN [master]..[sysprotects] p
ON o.[id] = p.[id]
INNER JOIN [master]..[sysusers] u
ON P.Uid = U.UID
AND p.[uid] = 0
AND o.[xtype] IN ('X','P')
Réduire la surface d'attaque de SQL Server
Configurez l’installation de SQL Server avec uniquement les fonctions nécessaires et désactivez les fonctions non souhaitées après l’installation via la configuration de la surface du système. Vous pouvez également utiliser la fonction Policy-Based Management pour créer des politiques systèmes et implémenter des paramètres de configuration granulaires pour un ou plusieurs systèmes SQL Server.
Renforcer les ports SQL Server
Une autre bonne pratique en matière de sécurité consiste à changer les ports par défaut associés à l’installation de SQL Server en utilisant SQL Server Configuration Manager. Utilisez des ports TCP spécifiques au lieu des ports dynamiques. De plus, assurez-vous que les ports TCP classiques, comme 1433 et 1434, ne soient pas utilisés pour les requêtes du client car ces ports sont bien connus – les transformant en une cible évidente pour les attaquants.
Désactiver le service SQL Server Browser
Assurez-vous que le service Browser fonctionne seulement lorsque plusieurs instances de SQL Server tournent sur un unique serveur. Ce service liste des informations sur le réseau, représentant ainsi une menace pour tout environnement fermé.
Les comptes de service SQL Server
Créez des comptes dédiés avec des privilèges peu élevés pour faire fonctionner les services SQL Server. Passez régulièrement en revue les membres des comptes de services et assurez-vous qu’ils ne soient pas membres de groupes qui leur octroient des permissions non requises.
Protégez les logs d’erreurs et les clés de registre
Sécurisez les logs d’erreurs de SQL Server et les clés de registre en utilisant les permissions NTFS car elles peuvent révéler de nombreuses informations sur les instances et les installations de SQL Server.
Traduit par la rédaction
