Comment durcir SQL Server ?
A qui ce destine ce guide ?
Ce référentiel est destiné aux administrateurs de systèmes et d'applications, aux spécialistes de la sécurité, aux auditeurs, au service d'assistance et au personnel chargé du déploiement des platesformes qui prévoient de développer, de déployer, d'évaluer ou de sécuriser des solutions intégrant Microsoft SQL Server 2022 sur une plateforme Microsoft Windows.
Recommandations générales
Maintenir une bonne hygiène
Il est essentiel de garder à l'esprit que le risque zéro n'existe pas dans le domaine de la sécurité informatique. Toutefois, la mise en place de mesures adéquates et une bonne configuration de SQL Server permettront de ralentir les attaquants et de renforcer la résilience de votre système. En suivant les recommandations de ce guide, vous serez en mesure de prendre des mesures préventives efficaces et de protéger votre Active Directory contre les menaces potentielles.
Déployer un environnement de test
La mise en œuvre temporaire d'un environnement de test et l'acquisition temporaire de compétences spécialisées peuvent faciliter l'adoption de ce guide.
Avant toute opération de changement de configuration, de restriction de permissions, ou d'implémentation de nouvelle fonctionnalité, il est vital de s'assurer de disposer d'une sauvegarde saine et dont la restauration est maitrisée.
1 - Installation, mises à jour et correctifs
Cette section contient des recommandations relatives à l’installation et à la correction de SQL Server.
1.1 Assurer les dernières mises à jour cumulatives et de sécurité de SQL Server
Description
Les correctifs SQL Server contiennent des mises à jour de programme qui corrigent la sécurité et les fonctionnalités du produit problèmes trouvés dans le logiciel. Ces correctifs peuvent être installés avec une mise à jour de sécurité, qui est un patch unique, ou une mise à jour cumulative qui est un groupe de patches. La version du serveur et les niveaux de patch doivent être les plus récents compatibles avec le besoins opérationnels des organisations.
Motif
L'utilisation du logiciel SQL Server le plus récent, accompagné de tous les correctifs applicables, peut contribuer à limiter les possibilités de vulnérabilité du logiciel. La version d'installation et/ou les correctifs appliqués lors de l'installation doivent être établis en fonction des besoins de l'organisation.
Vérification
Pour déterminer votre niveau de correctif SQL Server, exécutez l’extrait de code suivant :
SELECT SERVERPROPERTY('ProductLevel') as SP_installed,
SERVERPROPERTY('ProductVersion') as Version,
SERVERPROPERTY('ProductUpdateLevel') as 'ProductUpdate_Level',
SERVERPROPERTY('ProductUpdateReference') as 'KB_Number';
Remédiation
Identifiez la version actuelle et le niveau de patch de vos instances SQL Server et assurez-vous qu'ils contiennent les derniers correctifs de sécurité.
Assurez-vous de tester ces correctifs dans votre test les environnements avant la mise à jour des instances de production.
Les correctifs SQL Server les plus récents se trouvent ici :
- Source : https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates
- Source : https://support.microsoft.com/en-us/topic/kb4041553-sql-server-service-packs-are-discontinued-starting-from-sql-server-2017-fd405dee-cae7-b40f-db14-01e3e4951169
1.2 S’assurer que les serveurs de membres à fonction unique sont utilisés
Description
Il est recommandé d'installer le logiciel SQL Server sur un serveur dédié. Cette considération architecturale offre une certaine souplesse en matière de sécurité, dans la mesure où le serveur de base de données peut être placé sur un sous-réseau distinct n'autorisant l'accès qu'à partir de certains hôtes et par le biais de certains protocoles. Les degrés de disponibilité sont également plus faciles à atteindre - au fil du temps, une entreprise peut passer d'un serveur de base de données unique à un basculement vers un cluster utilisant l'équilibrage de charge ou à une combinaison des deux.
Motif
Il est plus facile de gérer (c'est-à-dire de réduire) la surface d'attaque du serveur hébergeant le logiciel SQL Server si les seules surfaces à prendre en compte sont le système d'exploitation sous-jacent, le serveur SQL Server lui-même, et tout outil de sécurité/opérationnel qui pourrait être installé en plus. Comme indiqué dans la description, la disponibilité peut être un facteur de risque et la peut-être plus facilement prise en compte si la base de données se trouve sur un serveur dédié
Impact
Il est difficile de voir un impact raisonnablement négatif à ce changement d'architecture, une fois que les coûts de ce changement ont été payés. Il se peut que des applications personnalisées doivent être modifiées pour permettre des connexions de base de données au travers du réseau plutôt que sur l'hôte (c'est-à-dire en utilisant TCP/IP au lieu de Named Pipes). Des licences supplémentaires pour le matériel et le système d'exploitation peuvent être nécessaires pour effectuer ces changements architecturaux.
Vérification
S’assurer qu’aucun autre rôle n’est activé pour le système d’exploitation sous-jacent et que l’outillage excédentaire est installé, conformément à la politique de l’entreprise.
Remédiation
Désinstaller les outils excédentaires et/ou supprimer les rôles inutiles de l’exploitation sous-jacente système.
2 - Réduction de la superficie
SQL Server offre diverses options de configuration, dont certaines peuvent être contrôlées par la procédure stockée sp_configure. Cette section contient la liste des recommandations correspondantes.
2.1 Vérifier la configuration du serveur des requêtes 'distribuées ad hoc' et que L’option est définie sur '0'
Description
L’activation des requêtes distribuées ad hoc permet aux utilisateurs d’interroger les données et d'exécuter des énoncés sur les sources de données externes. Cette fonctionnalité devrait être désactivée.
Motif
Cette fonctionnalité peut être utilisée pour accéder à distance et exploiter des vulnérabilités sur des instances SQL Server distantes et pour exécuter des fonctions Visual Basic for Application non sécurisées.
Vérification
Exécuter la commande T-SQL suivante :
SELECT name, CAST(value as int) as value_configured, CAST(value_in_use as
int) as value_in_use
FROM sys.configurations
WHERE name = 'Ad Hoc Distributed Queries';
Les deux colonnes de valeur doivent afficher 0.
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'Ad Hoc Distributed Queries', 0;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
La valeur par défaut est de 0 (désactivé).
2.2 - S’assurer que l’option de configuration du serveur 'CLR Enabled' est définie sur '0'
Description
L’option clr enabled spécifie si les assemblys utilisateur peuvent être exécutés par SQL Server.
Motif
L'activation de l'utilisation des assemblages CLR élargit la surface d'attaque de SQL Server et l'expose au risque d'assemblages involontaires ou malveillants.
Impact
Si des assemblages CLR sont utilisés, il peut être nécessaire de réarchitecturer les applications pour éliminer leur utilisation avant de désactiver ce paramètre. Par ailleurs, certaines organisations peuvent autoriser l'activation de ce paramètre pour les assemblages créés avec le jeu de permissions SAFE, mais interdire les assemblages créés avec les jeux de permissions UNSAFE et EXTERNAL_ACCESS, plus risqués. Pour trouver les assemblages créés par les utilisateurs, exécutez la requête suivante dans toutes les bases de données, en remplaçant nom_de_la_base_de_données par le nom de chaque base de données
USE [nom_de_la_base_de_données]
GO
SELECT name AS Assembly_Name, permission_set_desc
FROM sys.assemblies
WHERE is_user_defined = 1;
GO
Vérification
Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'clr strict security';
Si les deux valeurs sont 1, cette recommandation est sans objet. Sinon, exécutez cette Commande T-SQL :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'clr enabled';
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'clr enabled', 0;
RECONFIGURE;
La valeur par défaut est de 0 (désactivé).
Source : https://learn.microsoft.com/en-us/sql/t-sql/statements/create-assembly-transact-sql
Renseignements supplémentaires
Si clr strict security est mis à 1 cette recommandation n’est pas applicable. Par défaut, clr une sécurité stricte est activée et traite les assemblages SAFE et EXTERNAL_ACCESS comme s’ils ont été marqués DANGEREUX.
Bien que non recommandé, l’option de sécurité stricte clr peut être désactivé pour de la compatibilité descendante. Cette recommandation a été conservée pour l'environnements configurés pour la rétrocompatibilité.
2.3 - S’assurer de la configuration du serveur 'Cross DB Ownership Chaining' que l’option est définie sur '0'
Description
L'option cross db ownership chaining contrôle le chaînage de la propriété de toutes les bases de données au niveau de l'instance (ou du serveur).
Motif
Lorsqu'elle est activée, cette option permet à un membre du rôle db_owner dans une base de données d'accéder à des objets appartenant à un login dans n'importe quelle autre base de données, ce qui entraîne une divulgation inutile d'informations. Lorsque cela est nécessaire, le chaînage de la propriété entre bases de données ne doit être activé que pour les bases de données spécifiques qui le nécessitent plutôt qu'au niveau de l'instance pour toutes les bases de données en utilisant la commande ALTER DATABASE nom_de_la_base SET DB_CHAINING ON. Cette option de base de données ne peut pas être modifiée sur les bases de données système master, model ou tempdb.
Vérification
Exécutez la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'cross db ownership chaining';
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'cross db ownership chaining', 0;
RECONFIGURE;
GO
La valeur par défaut est de 0 (désactivé).
2.4 - Assurez-vous que l’option de configuration du serveur 'Database Mail XPs’applique réglé sur '0'
Description
L’option Database Mail XPs contrôle la possibilité de générer et de transmettre des e-mails messages de SQL Server.
Motif
La désactivation de l'option Database Mail XPs réduit la surface du serveur SQL, élimine un vecteur d'attaque DOS et un canal permettant d'exfiltrer des données du serveur de base de données vers un hôte distant.
Vérification
Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'Database Mail XPs';
Les deux colonnes de valeur doivent afficher 0 pour être conformes.
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'Database Mail XPs', 0;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
La valeur par défaut est de 0 (désactivé). Source : https://learn.microsoft.com/en-us/sql/relational-databases/database-mail/database-mail?view=sql-server-ver1
2.5 Vérifier la configuration du serveur des 'Ole automation procedures' que l’option doit etre définie sur '0'
Description
L’option Ole Automation Procedures contrôle si les objets OLE Automation peuvent être instancié dans les lots Transact-SQL. Il s’agit de procédures stockées étendues qui permettent aux utilisateurs de SQL Server d’exécuter des fonctions externes à SQL Server.
Motif
L'activation de cette option augmentera la surface d'attaque du serveur SQL et permettra aux utilisateurs d'exécuter des fonctions dans le contexte de sécurité du serveur SQL.
Vérification Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'Ole Automation Procedures';
Les deux colonnes de valeur doivent afficher 0 pour être conformes.
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'Ole Automation Procedures', 0;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
La valeur par défaut est de 0 (désactivé).
2.6 S’assurer que l’option de configuration du serveur 'Remote Access' est définie sur « 0 »
Description
L’option d’accès à distance contrôle l’exécution des procédures stockées localement sur serveurs ou procédures stockées à distance sur le serveur local.
Motif
Cette fonctionnalité peut être utilisée de manière abusive pour lancer une attaque par déni de service (DoS) sur des serveurs distants en déchargeant le traitement des requêtes sur une cible.
Impact
Cette fonctionnalité pourrait être supprimée dans une prochaine version de Microsoft SQL Server. N'utilisez pas cette fonctionnalité dans les nouveaux développements et modifiez dès que possible les applications qui l'utilisent actuellement. Utilisez plutôt sp_addlinkedserver.
Vérification
Exécutez la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'remote access';
Les deux colonnes de valeur doivent afficher 0
Remédiation
exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'remote access', 0;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
Redémarrez le moteur de base de données.
La valeur par défaut est de 1 (activé).
2.7 - Vérifier la configuration du serveur 'Remote Admin Connections' que L’option est définie sur '0'
Description
L’option de connexions d’administrateur à distance contrôle si une application cliente sur un ordinateur distant peut utiliser la connexion administrateur dédiée (DAC).
Motif
La connexion administrateur dédiée (DAC) permet à un administrateur d'accéder à un serveur en cours d'exécution pour exécuter des fonctions de diagnostic ou des instructions Transact-SQL, ou pour résoudre des problèmes sur le serveur, même lorsque le serveur est verrouillé ou fonctionne dans un état anormal et ne répond pas à une connexion au moteur de base de données du serveur SQL. Dans un scénario de cluster, l'administrateur peut ne pas être connecté au même nœud que celui qui héberge actuellement l'instance de SQL Server et est donc considéré comme « distant ». Par conséquent, ce paramètre doit généralement être activé (1) pour les clusters de basculement du serveur SQL ; sinon, il doit être désactivé (0), ce qui est la valeur par défaut.
Vérification
Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'remote admin connections'
AND SERVERPROPERTY('IsClustered') = 0;
Si aucune donnée n ’est retournée, l’instance est un cluster et cette recommandation n’est pas applicable. Si les données sont retournées, les deux colonnes de valeur doivent afficher 0 pour être conforme.
Remédiation
Exécuter la commande T-SQL suivante sur les installations non groupées :
EXECUTE sp_configure 'remote admin connections', 0;
RECONFIGURE;
GO
Valeur par défaut
Par défaut, cette option est désactivée (0), seules les connexions locales peuvent utiliser le DAC.
Renseignements supplémentaires
S'il s'agit d'une installation en cluster, cette option doit être activée car un serveur SQL en cluster ne peut pas se lier à localhost et le DAC sera indisponible dans le cas contraire. Activez-la pour les installations en cluster. Désactivez-la pour les installations autonomes lorsque cela n'est pas nécessaire.
2.8 Vérifier l’option de configuration du serveur 'Scan For Startup Procs’ est réglé sur '0'
Description
L’option Scan for startup procs, si elle est activée, provoque l’analyse de SQL Server pour exécuter automatiquement toutes les procédures stockées définies pour s’exécuter au démarrage du service.
Motif
L'application de ce contrôle réduit le risque qu'une entité utilise ces installations à des fins malveillantes.
Impact
Définir Scan for Startup Procedures sur 0 empêchera certaines traces d’audit et d’autres procédures de surveillance généralement utilisées sont stockées à partir du redémarrage au démarrage. En outre, la réplication nécessite que ce paramètre soit activé (1) et le changera automatiquement de réglage si nécessaire.
Vérification
Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'scan for startup procs';
Les deux colonnes de valeur doivent afficher 0.
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'scan for startup procs', 0;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
Redémarrez le moteur de base de données. Par défaut, cette option est désactivée (0).
2.9 S’assurer que la propriété de base de données 'Digne de confiance' est définie sur 'Éteint’
Description
L’option de base de données 'TRUSTWORTHY' (DIGNE DE CONFIANCE) permet aux objets de base de données d’accéder à des objets dans d’autres bases de données dans certaines circonstances.
Motif
Protection contre les assemblages CLR malveillants ou les procédures étendues.
Vérification
Exécutez la requête T-SQL suivante pour répertorier toutes les bases de données dont la valeur de propriété de base de données digne de confiance est ON :
SELECT name
FROM sys.databases
WHERE is_trustworthy_on = 1
AND name != 'msdb';
Aucune ligne ne doit être retournée.
Remédiation
Exécuter l’instruction T-SQL suivante sur les bases de données (remplacer database_name ci-dessous) renvoyées par la procédure d’audit :
ALTER DATABASE [database_name] SET TRUSTWORTHY OFF;
Par défaut, cette propriété de base de données est OFF (is_trustworthy_on = 0), sauf pour la base de données msdb base de données dans laquelle il doit être activé.
2.10 S’assurer que les protocoles SQL Server inutiles sont définis sur 'Disabled'
Description
SQL Server prend en charge la mémoire partagée, les canaux nommés et les protocoles TCP/IP. Cependant, SQL Server doit être configuré pour utiliser le strict minimum requis en fonction du besoins de l’organisation.
Motif
L'utilisation d'un nombre réduit de protocoles minimise la surface d'attaque du serveur SQL et, dans certains cas, peut le protéger contre les attaques à distance.
Impact
Les services du moteur de base de données (MSSQL et SQLAgent) doivent être arrêtés et redémarrés pour que la modification prenne effet.
Vérification
Ouvrez SQL Server 2022 Configuration Manager ; accédez au réseau SQL Server Configuration. Assurez-vous que seuls les protocoles requis sont activés.
Remédiation
Ouvrez SQL Server 2022 Configuration Manager ; accédez au réseau SQL Server Configuration. Assurez-vous que seuls les protocoles requis sont activés. Désactiver les protocoles nécessaire.
Valeur par défaut
Par défaut, les protocoles TCP/IP et mémoire partagée sont activés sur toutes les applications commerciales éditions
2.11 Assurez-vous que SQL Server est configuré pour utiliser des ports non standard
Description
S’il est installé, une instance SQL Server par défaut se verra attribuer un port par défaut de TCP:1433 pour la communication TCP/IP. Les administrateurs peuvent également configurer manuellement les instances nommées pour utiliser TCP:1433 pour la communication. TCP:1433 est un port SQL Server largement connu et cette affectation de port doit être modifiée. Dans un scénario multi-instance, chaque instance doit se voir attribuer son propre port TCP/IP dédié.
Motif
L'utilisation d'un port autre que le port par défaut permet de protéger la base de données contre les attaques dirigées vers le port par défaut.
Impact
La modification du port par défaut forcera le DAC (Dedicated Administrator Connection) à écouter sur un port aléatoire. En outre, il pourrait faire des applications bénignes, telles que l’application pare-feu, nécessite une configuration spéciale. En général, vous devez définir un port statique pour l'utilisation cohérente par les applications, y compris les pare-feu, au lieu d’utiliser des ports dynamiques qui sera choisi au hasard à chaque démarrage de SQL Server.
Vérification
Exécuter le T-SQL suivant :
IF (select value_data from sys.dm_server_registry where value_name =
'ListenOnAllIPs') = 1
SELECT count(*) FROM sys.dm_server_registry WHERE registry_key = '%IPAll%'
and value_name like '%Tcp%' and value_data='1433'
ELSE
SELECT count(*) FROM sys.dm_server_registry WHERE value_name like '%Tcp%' and
value_data='1433';
Remédiation
- Dans SQL Server Configuration Manager, dans le volet de la console, développez SQL Configuration du réseau du serveur, développer les protocoles pour InstanceName, puis double-cliquez sur le protocole TCP/IP.
-
Dans la boîte de dialogue Propriétés TCP/IP, sous l’onglet Adresses IP, plusieurs adresses IP les adresses apparaissent au format IP1, IP2, jusqu’à IPAll. L’une d’elles est pour l’IP Page 40 adresse de l’adaptateur de bouclage, 127.0.0.1. Des adresses IP supplémentaires apparaissent pour chaque adresse IP sur l’ordinateur.
-
Sous IPAll, changez le champ TCP Port de 1433 à un port non standard ou laisser le champ TCP Port vide et définir la valeur TCP Dynamic Ports sur 0 à activer l’affectation dynamique de port, puis cliquer sur OK.
-
Dans le volet de la console, cliquez sur SQL Server Services.
-
Dans le volet des détails, cliquez avec le bouton droit sur SQL Server (InstanceName), puis cliquez sur Redémarrez, pour arrêter et redémarrer SQL Server.
Valeur par d éfaut
Par défaut, les instances SQL Server par défaut écoutent le trafic TCP/IP sur le port TCP 1433et les instances nommées utilisent des ports dynamiques.
2.12 Assurez-vous que l’option Masquer l’instance est définie sur Oui pour la production d'Instances SQL Server
Description
Les instances SQL Server non mutualisées dans les environnements de production doivent être désigné comme caché pour empêcher la publicité par le service SQL Server Browser.
Motif
Le fait de désigner les instances de production de SQL Server comme étant cachées permet de sécuriser l'installation car elles ne peuvent pas être énumérées. Cependant, les instances en cluster peuvent se briser si cette option est sélectionnée.
Impact
Cette méthode empêche uniquement l’instance d’être répertoriée sur le réseau. Si l’instance est masquée (non exposée par le navigateur SQL), les connexions devront spécifier le serveur et le port pour se connecter.
Il n’empêche pas les utilisateurs de se connecter au serveur s’ils connaissent le nom de l’instance et le port. Si vous masquez une instance nommée en cluster, le service de cluster peut ne pas être en mesure de se connecter à SQL Server. Veuillez consulter la référence de la documentation Microsoft.
Verification
- Dans SQL Server 2022 Configuration Manager, développez SQL Server Network Configuration, cliquez avec le bouton droit sur Protocoles pour InstanceName, puis sélectionnez Propriétés.
- Sous l’onglet Drapeaux, dans la zone Masquer l’instance, si Oui est sélectionné, il est conforme.
Remédiation
- Dans SQL Server 2022 Configuration Manager, développez SQL Server Network Configuration, cliquez avec le bouton droit sur Protocoles pour InstanceName, puis sélectionnez Propriétés.
- Sous l’onglet Flags, dans la zone Hide Instance, sélectionnez Yes, puis cliquez sur OK pour fermer la boîte de dialogue. La modification prend effet immédiatement pour les nouvelles connexions
2.13 Assurez-vous que le compte de connexion 'sa' est défini sur 'Disabled'
Description
Le compte SA est un compte SQL Server largement connu et souvent utilisé avec des privilèges sysadmin. Il s’agit de la connexion d’origine créée lors de l’installation et a toujours les identifiants principal_id=1 et sid=0x01
Motif
L'application de ce contrôle réduit la probabilité qu'un attaquant exécute des attaques par force brute contre un donneur d'ordre bien connu.
Impact
Ce n'est pas une bonne pratique de sécurité que de coder des applications ou des scripts pour qu'ils utilisent le compte sa. Cependant, si cela a été fait, la désactivation du compte sa empêchera les scripts et les applications de s'authentifier auprès du serveur de base de données et d'exécuter les tâches ou les fonctions requises.
Vérification
Utilisez la syntaxe suivante pour déterminer si le compte SA est désactivé. La vérification de sid=0x01 garantit que le compte SA d’origine est vérifié au cas où il aurait été renommé selon les meilleures pratiques.
SELECT name, is_disabled
FROM sys.server_principals
WHERE sid = 0x01
AND is_disabled = 0;
Aucune ligne ne doit être retournée pour être conforme. Une valeur is_disabled de 0 indique que la connexion est actuellement activée et qu’il faut donc remédiation
Remédiation
Exécuter la requête T-SQL suivante :
USE [master]
GO
DECLARE @tsql nvarchar(max)
SET @tsql = 'ALTER LOGIN ' + SUSER_NAME(0x01) + ' DISABLE'
EXEC (@tsql)
GO
Par défaut, le compte de connexion SA est désactivé au moment de l’installation lorsque le mode "authentification Windows" est sélectionné. Si le mode mixte (SQL Server et authentification Windows) est sélectionné lors de l’installation, la valeur par défaut pour la connexion sa est activée.
Sources :
- https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-server-principals-transact-sql?view=sql-server-ver16&tabs=sql
- https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-login-transact-sql?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-ver16
2.14 Assurez-vous que le compte de connexion a été renommé
Description
Le compte SA est une connexion SQL Server largement connue et souvent utilisée avec sysadmin privileges.La connexion sa est la connexion d’origine créée lors de l’installation et a toujours principal_id=1 et sid=0x01
Motif
Il est plus difficile de lancer des attaques par devinette de mot de passe et par force brute contre le login sa si le nom n'est pas connu.
Impact
Il n’est pas recommandé de coder des applications ou des scripts pour utiliser la connexion SA. Cependant, si cela a été fait, renommer la connexion SA empêchera les scripts et des applications allant de l’authentification au serveur de base de données et de l’exécution des tâches requises ou fonctions.
Vérification
Utilisez la syntaxe suivante pour déterminer si le login de sa (principal) est renommé:
SELECT name
FROM sys.server_principals
WHERE sid = 0x01;
Remédiation
Remplacer la valeur different_user dans la syntaxe ci-dessous et exécuter pour renommer la connexion SA.
ALTER LOGIN sa WITH NAME = different_user;
Par défaut, le nom de connexion est 'sa'
2.15 S’assurer que « AUTO_CLOSE » est réglé à « OFF » sur « contenu » bases de données
Description
AUTO_CLOSE détermine si une base de données donnée est fermée ou non après une connexion se termine. Si cette option est activée, les connexions ultérieures à la base de données sont à rouvrir et les caches de procédures pertinentes à reconstruire.
Motif
Étant donné que l'authentification des utilisateurs pour les bases de données de contenu s'effectue dans la base de données et non au niveau du serveur, la base de données doit être ouverte à chaque fois pour authentifier un utilisateur. L'ouverture/fermeture fréquente de la base de données consomme des ressources serveur supplémentaires et peut contribuer à un déni de service.
Vérification
Procéder comme suit pour trouver les bases de données de contenu qui ne sont pas configurées comme prescrit :
SELECT name, containment, containment_desc, is_auto_close_on
FROM sys.databases
WHERE containment <> 0 and is_auto_close_on = 1;
Aucune ligne ne doit être retournée.
Remédiation
Exécuter le T-SQL suivant, en remplaçant database_name par chaque nom de base de données trouvé dans la procédure de Vérification
ALTER DATABASE database_name SET AUTO_CLOSE OFF;
Par défaut, la propriété de base de données AUTO_CLOSE est désactivée, ce qui équivaut à is_auto_close_on = 0.
2.16 Ensure no login exists with the name 'sa' (Automated)
Description
Le login sa (par ex. principal) est un compte SQL Server largement connu et souvent utilisé. Par conséquent, il ne devrait pas y avoir de connexion appelée "sa" même lorsque la connexion d’origine (principal_id = 1) a été renommé.
Motif
L'application de ce contrôle réduit la probabilité qu'un attaquant exécute des attaques par force brute contre un nom de principal bien connu.
Impact
Il n’est pas recommandé de coder des applications ou des scripts pour utiliser le compte SA. Étant donné qu’il est recommandé de renommer et de désactiver le compte SA, certaines applications tierces vérifient l’existence d’un login nommé SA et, s’il n’existe pas, en créent un. La suppression de la connexion SA empêchera ces scripts et applications de s’authentifier sur le serveur de base de données et d’exécuter les tâches ou fonctions requises.
Vérification
Utilisez la syntaxe suivante pour déterminer s’il existe un compte nommé sa.
SELECT principal_id, name
FROM sys.server_principals
WHERE name = 'sa';
Aucune ligne ne doit être retournée.
Remédiation
Exécutez l’instruction ALTER appropriée ci-dessous en fonction du principal_id renvoyé pour remplacer la valeur different_name dans la syntaxe ci-dessous et exécuter pour renommer la connexion SA.
USE [master]
GO
-- If principal_id = 1 or the login owns database objects, rename the sa
login
ALTER LOGIN [sa] WITH NAME = different_name;
GO
Valeur par défaut
La connexion avec principal_id = 1 est nommée sa par défaut
2.17 Assurez-vous que l’option de configuration du serveur 'clr strict security' est définie à 1
Description
L’option de sécurité stricte clr spécifie si le moteur applique le PERMISSION_SET sur les assemblages.
Motif
L'activation de l'utilisation des assemblages CLR élargit la surface d'attaque de SQL Server et l'expose au risque d'assemblages involontaires ou malveillants.
Impact
Si les assemblages CLR sont utilisés, les applications peuvent avoir besoin d’être réécrite pour éliminer leur utilisation avant d’activer ce paramètre. Pour trouver les assemblys créés par l’utilisateur, exécutez la requête dans toutes les bases de données, remplacer database_name par chaque nom de base de données :
USE [database_name]
GO
SELECT name AS Assembly_Name, permission_set_desc
FROM sys.assemblies
WHERE is_user_defined = 1;
GO
Vérification
Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'clr strict security';
Les deux colonnes de valeur doivent afficher 1 pour être conformes.
Remédiation
Exécuter la commande T-SQL suivante :
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'clr strict security', 1;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
Valeur par défaut
Par défaut, cette option est activée (1) Source : https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/clr-strict-security?view=sql-server-ver16
3 - Authentification et autorisation
Cette section contient des recommandations relatives à l’authentification de SQL Server et des mécanismes d’autorisation
3.1 Assurez-vous que la propriété 'Server Authentication' est définie sur 'Windows Mode d’authentification
Description
Utilise l’authentification Windows pour valider les tentatives de connexion.
Motif
Windows fournit un mécanisme d'authentification plus robuste que l'authentification du serveur SQL.
Impact
La modification de la configuration du mode de connexion nécessite un redémarrage du service
Vérification
Exécuter la syntaxe suivante :
SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') as [login_mode];
Un login_mode de 1 indique que la propriété Server Authentication est définie sur Windows Mode d’authentification. Un login_mode de 0 indique une authentification en mode mixte.
Remédiation
- Ouvrez SQL Server Management Studio.
- Ouvrez l’onglet Explorateur d’objets et connectez-vous à l’instance SQL Server cible.
- Cliquez avec le bouton droit sur le nom de l’instance et sélectionnez Propriétés.
- Sélectionnez la page Sécurité dans le menu de gauche.
- Définissez le paramètre d’authentification du serveur sur Mode d’authentification Windows.
Redémarrez le service SQL Server pour que la modification prenne effet.
3.2 S’assurer que les autorisations CONNECT sur l’utilisateur 'invité' sont Révoqué dans toutes les bases de données SQL Server
Description
Supprimer le droit de l’utilisateur invité de se connecter aux bases de données SQL Server, sauf pour master, msdb, tempdb et, sur les instances AWS RDS, rdsadmin.
Motif
Un login assume l'identité de l'utilisateur invité lorsqu'un login a accès à SQL Server mais n'a pas accès à une base de données via son propre compte et que la base de données dispose d'un compte d'utilisateur invité. La révocation de l'autorisation CONNECT pour l'utilisateur invité garantit qu'un login n'est pas en mesure d'accéder aux informations de la base de données sans en avoir l'autorisation explicite.
Impact
Lorsque l’autorisation CONNECT à l’utilisateur invité est révoquée, une instance SQL Server se connecte doit être mappé explicitement à un utilisateur de base de données afin d’avoir accès à la base de données.
USE database_name;
GO
SELECT DB_NAME() AS DatabaseName, 'guest' AS Database_User,
[permission_name], [state_desc]
FROM sys.database_permissions
WHERE [grantee_principal_id] = DATABASE_PRINCIPAL_ID('guest')
AND [state_desc] LIKE 'GRANT%'
AND [permission_name] = 'CONNECT'
AND DB_NAME() NOT IN ('master','tempdb','msdb');
Aucune ligne ne doit être retournée.
Remédiation
L’extrait de code suivant révoque les autorisations CONNECT de l’utilisateur invité dans une base de données. Remplacer database_name selon le cas :
USE database_name;
GO
REVOKE CONNECT FROM guest;
Valeur par défaut
L’utilisateur invité ne peut pas voir l’autorisation CONNECT révoquée dans master, msdb, tempdb et, sur les instances AWS RDS, rdsadmin ; cependant, cette autorisation doit être révoquée dans toutes les autres bases de données de l’instance SQL Server.
3.3 S’assurer que les utilisateurs orphelins sont supprimés de SQL Server Bases de données
Description
Un utilisateur de base de données pour lequel la connexion SQL Server correspondante est indéfinie ou est mal défini sur une instance de serveur ne peut pas se connecter à l’instance et est renvoyé à comme orphelin et devrait être supprimé.
Motif
Les utilisateurs orphelins doivent être supprimés afin d'éviter tout risque d'utilisation abusive de ces utilisateurs supprimés de quelque manière que ce soit.
Vérification
Ex écutez la requête T-SQL suivante dans chaque base de données pour identifier les utilisateurs orphelins. Aucune ligne devrait être retourné.
USE database_name;
GO
SELECT dp.type_desc, dp.sid, dp.name as orphan_user_name,
dp.authentication_type_desc FROM sys.database_principals AS dp LEFT JOIN
sys.server_principals as sp ON dp.sid=sp.sid WHERE sp.sid IS NULL AND
dp.authentication_type_desc = 'INSTANCE'
Remédiation
Si l’utilisateur orphelin ne peut pas ou ne doit pas être associé à une connexion existante ou à une nouvelle connexion à l’aide du processus documenté Microsoft mentionné ci-dessous, exécutez la requête T-SQL suivante dans la base de données appropriée pour supprimer un utilisateur orphelin :
USE database_name;
GO
DROP USER username;
3.4 S’assurer que l’authentification SQL n’est pas utilisée dans bases de données
Description
Les bases de données de contenu n’appliquent pas les règles de complexité des mots de passe pour les utilisateurs SQL authentifiés
Motif
L'absence d'une politique de mot de passe appliquée peut augmenter la probabilité qu'un identifiant faible soit établi dans une base de données contenue.
Impact
Bien que les bases de données de contenu offrent une flexibilité pour déplacer les bases de données vers différentes instances et différents environnements, cela doit être équilibré en tenant compte du fait qu’aucun mécanisme de stratégie de mot de passe n’existe pour les utilisateurs SQL Authenticated dans les bases de données de contenu.
Vérification
Exécuter le T-SQL suivant dans chaque base de données contenue pour trouver les utilisateurs de base de données qui utilisent l’authentification SQL :
SELECT name AS DBUser
FROM sys.database_principals
WHERE name NOT IN ('dbo','Information_Schema','sys','guest')
AND type IN ('U','S','G')
AND authentication_type = 2;
GO
Remédiation
Tirez parti des utilisateurs Windows authentifiés dans les bases de données de contenu. Les utilisateurs SQL authentifiés (USER WITH PASSWORD authentication) sont autorisés dans les bases de données de contenu.
3.5 Assurez-vous que le compte de service MSSQL de SQL Server n’est pas un administrateur
Description
Le compte de service et/ou le SID de service utilisé par le service MSSQLSERVER pour une instance par défaut ou le service InstanceName pour une instance nommée ne doit pas être membre du groupe Administrateur Windows directement ou indirectement (via un groupe). Cela signifie également que le compte connu sous le nom de LocalSystem (alias NT AUTHORITY SYSTEM) ne doit pas être utilisé pour le service MSSQL car ce compte a des privilèges plus élevés que le SQL Server service nécessite.
Motif
Conformément au principe du moindre privilège, le compte de service ne doit pas avoir plus de privilèges qu'il n'en faut pour effectuer son travail. Pour les services SQL Server, l'installation de SQL Server attribue les autorisations nécessaires directement au SID du service. Aucune autorisation ou privilège supplémentaire ne devrait être nécessaire.
Impact
L’outil SQL Server Configuration Manager doit toujours être utilisé pour modifier le compte de service de SQL Server. Cela garantira que le compte dispose des privilèges nécessaires. Si le service a besoin d’accéder à des ressources autres que les répertoires et registres standard définis par Microsoft, des autorisations supplémentaires peuvent être accordées séparément à ces ressources
Vérification
Vérifiez que le compte de service (dans le cas d’un compte local ou AD) et le SID de service ne sont pas membres du groupe Administrateurs Windows.
Remédiation
Dans le cas où LocalSystem est utilisé, utilisez SQL Server Configuration Manager pour passer à un compte moins privilégié. Sinon, supprimez le compte ou le service SID du groupe Administrateurs. Vous devrez peut-être exécuter SQL Server Configuration Manager si les autorisations sous-jacentes ont été modifiées ou si SQL Server Configuration Manager n’a pas été utilisé à l’origine pour définir le compte de service
Par défaut, le compte de service (ou le SID de service) ne fait pas partie du groupe Administrateurs.
3.6 Assurez-vous que le compte de service SQLAgent de SQL Server n’est pas un administrateur
Description
Le compte de service et/ou le SID de service utilisé par le service SQLSERVERAGENT pour une instance par défaut ou le service SQLAGENT$ InstanceName pour une instance nommée ne doit pas être membre du groupe Administrateur Windows directement ou indirectement (via un groupe). Cela signifie également que le compte connu sous le nom de LocalSystem (AKA NT AUTHORITY SYSTEM) ne doit pas être utilisé pour le service SQLAGENT car ce compte dispose de privilèges plus élevés que ceux requis par le service SQL Server.
Motif
Conformément au principe du moindre privilège, le compte de service ne doit pas avoir plus de privilèges que nécessaire pour effectuer son travail. Pour les services SQL Server, le fichier SQL Server Setup
Impact
L’outil SQL Server Configuration Manager doit toujours être utilisé pour modifier le compte de service de SQL Server. Cela garantira que le compte dispose des privilèges nécessaires. Si le service a besoin d’accéder à des ressources autres que les répertoires et registres standard définis par Microsoft, des autorisations supplémentaires peuvent être accordées séparément de ces ressources.
Vérification
Vérifiez que le compte de service (dans le cas d’un compte local ou AD) et le SID de service ne sont pas membres du groupe Administrateurs Windows.
Remédiation
Dans le cas où LocalSystem est utilisé, utilisez SQL Server Configuration Manager pour passer à un compte moins privilégié. Sinon, supprimez le compte ou le service SID du groupe Administrateurs. Vous devrez peut-être exécuter SQL Server Configuration Manager si les autorisations sous-jacentes ont été modifiées ou si SQL Server Configuration Manager n’a pas été utilisé à l’origine pour définir le compte de service.
Par défaut, le compte de service (ou le SID de service) n’est pas membre du groupe des administrateurs. Source : https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver16
3.7 Assurez-vous que le compte de service de texte intégral de SQL Server n’est pas un administrateur
Description
Le compte de service et/ou le SID de service utilisé par le service MSSQLFDLauncher pour une instance par défaut ou le service MSSQLFDLauncher$InstanceName pour une instance nommée ne doit pas être membre du groupe Administrateur Windows directement ou indirectement (via un groupe). Cela signifie également que le compte connu sous le nom de LocalSystem (alias NT AUTHORITY SYSTEM) ne doit pas être utilisé pour le service de texte intégral car ce compte a des privilèges plus élevés que le service SQL Server nécessite.
Motif
Conformément au principe du moindre privilège, le compte de service ne doit pas avoir plus de privilèges qu'il n'en faut pour effectuer son travail. Pour les services SQL Server, l'installation de SQL Server attribue les autorisations nécessaires directement au SID du service. Aucune autorisation ou privilège supplémentaire ne devrait être nécessaire.
Impact
L’outil SQL Server Configuration Manager doit toujours être utilisé pour modifier le compte de service de SQL Server. Cela permettra de s’assurer que le compte a le nécessaire privilèges. Si le service a besoin d’accéder à des ressources autres que les répertoires des registres standard définis par Microsoft, des autorisations supplémentaires peuvent être accordées séparément de ces ressources.
Vérification
Vérifiez que le compte de service (dans le cas d’un compte local ou AD) et le SID de service ne sont pas membres du groupe Administrateurs Windows.
Remédiation
Dans le cas où LocalSystem est utilisé, utilisez SQL Server Configuration Manager pour passer à un compte moins privilégié. Sinon, supprimer le compte ou le service SID de le groupe Administrateurs. Vous devrez peut-être exécuter SQL Server Configuration Manager si les autorisations sous-jacentes ont été modifiées ou si SQL Server Configuration Manager n’a pas été utilisé à l’origine pour définir le compte de service.
Par défaut, le compte de service (ou le SID de service) n’est pas membre du groupe administrateurs. Source : https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver16
3.8 S’assurer que seules les autorisations par défaut spécifiées par Microsoft sont accordées au rôle de serveur public
Description
Public est un rôle de serveur fixe spécial contenant toutes les connexions. Contrairement aux autres rôles de serveur fixe, les autorisations peuvent être modifiées pour le rôle public. Conformément au principe des privilèges minimaux, le rôle de serveur public ne doit pas être utilisé pour accorder des autorisations à l’étendue du serveur, car elles seraient héritées par tous les utilisateurs.
Motif
Chaque connexion au serveur SQL appartient au rôle public et ne peut pas être supprimée de ce rôle. Par conséquent, toutes les autorisations accordées à ce rôle seront disponibles pour toutes les connexions, à moins qu'elles n'aient été explicitement refusées à des connexions spécifiques ou à des rôles de serveur définis par l'utilisateur.
Impact
L'outil SQL Server Configuration Manager doit toujours être utilisé pour modifier le compte de service du serveur SQL. Cela permet de s'assurer que le compte dispose des privilèges nécessaires. Si le service doit accéder à des ressources autres que les répertoires et le registre standard définis par Microsoft, des autorisations supplémentaires devront peut-être être accordées séparément pour ces ressources.
Vérification
Utilisez la syntaxe suivante pour déterminer si des autorisations supplémentaires ont été accordées au rôle de serveur public.
SELECT *
FROM master.sys.server_permissions
WHERE (grantee_principal_id = SUSER_SID(N'public') and state_desc LIKE
'GRANT%')
AND NOT (state_desc = 'GRANT' and [permission_name] = 'VIEW ANY DATABASE' and
class_desc = 'SERVER')
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and
class_desc = 'ENDPOINT' and major_id = 2)
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and
class_desc = 'ENDPOINT' and major_id = 3)
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and
class_desc = 'ENDPOINT' and major_id = 4)
AND NOT (state_desc = 'GRANT' and [permission_name] = 'CONNECT' and
class_desc = 'ENDPOINT' and major_id = 5);
Cette requête ne doit renvoyer aucune ligne
Remédiation
- Ajoutez les autorisations superflues trouvées dans les résultats de la requête de vérification aux connexions spécifiques aux rôles de serveur définis par l’utilisateur qui nécessitent l’accès.
- Révoquer le permission_name du rôle public comme indiqué ci-dessous.
USE [master]
GO
REVOKE permission_name FROM public;
GO
Par défaut, le rôle de serveur public se voit accorder l’autorisation VIEW ANY DATABASE et l’autorisation CONNECT sur les points de terminaison par défaut (machine locale TSQL, canaux nommés TSQL, TSQL Default TCP, TSQL Default VIA). L’autorisation VIEW ANY DATABASE permet à tous se connecter pour voir les métadonnées de la base de données, sauf refus explicite
Sources :
- Source : https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/server-level-roles?view=sql-server-ver16
- Source : https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/server-level-roles?view=sql-server-ver16#permissions-of-fixed-server-roles
3.9 S’assurer que les groupes INTERNES Windows ne sont pas des connexions SQL
Description
Avant SQL Server 2008, le groupe BUILTIN Administrators a été ajouté en tant que connexion SQL Server avec des privilèges sysadmin lors de l’installation par défaut. Les meilleures pratiques encouragent la création d’un groupe de niveau Active Directory contenant des comptes de personnel DBA approuvés et l’utilisation de ce groupe AD contrôlé comme connexion avec des privilèges sysadmin. Le groupe AD doit être spécifié lors de l’installation de SQL Server et le groupe BUILTIN Administrators n’a donc pas besoin d’être un login.
Motif
Les groupes BUILTIN (Administrateurs, Tout le monde, Utilisateurs authentifiés, Invités, etc.) contiennent généralement des membres très larges qui ne répondraient pas à la meilleure pratique consistant à s'assurer que seuls les utilisateurs nécessaires ont été autorisés à accéder à une instance de serveur SQL. Ces groupes ne doivent pas être utilisés pour un quelconque niveau d'accès à une instance du moteur de base de données SQL Server.
Impact
Avant de supprimer les connexions de groupe BUILTIN, assurez-vous que les autres groupes AD ou les connexions Windows ont été ajoutées avec des autorisations équivalentes. Sinon, le SQL son instance du serveur peut devenir totalement inaccessible.
Vérification
Utilisez la syntaxe suivante pour déterminer si des groupes ou comptes 'BUILTIN' ont été ajoutés en tant que connexions SQL Server.
SELECT pr.[name], pe.[permission_name], pe.[state_desc]
FROM sys.server_principals pr
JOIN sys.server_permissions pe
ON pr.principal_id = pe.grantee_principal_id
WHERE pr.name like 'BUILTIN%';
Cette requête ne doit renvoyer aucune ligne
Remédiation
- Pour chaque ouverture de session 'BUILTIN', au besoin, créez un groupe AD plus restrictif contenant uniquement les comptes d’utilisateur requis.
- Ajoutez le groupe AD ou des comptes Windows individuels en tant que connexion SQL Server et accordez-lui les autorisations requises.
- Supprimer la connexion BUILTIN en utilisant la syntaxe ci-dessous après avoir remplacé nom dans [BUILTIN\nom].
USE [master]
GO
DROP LOGIN [BUILTIN\nom]
GO
Par défaut, aucun groupe BUILTIN n’est ajouté en tant que connexions SQL.
3.10 Vérifier que les groupes locaux Windows ne sont pas des connexions SQL
Description
Les groupes Windows locaux ne doivent pas être utilisés comme connexions pour les instances SQL Server
Motif
Le fait d'autoriser les groupes locaux de Windows en tant que connexions SQL constitue une faille permettant à toute personne disposant de droits d'administrateur au niveau du système d'exploitation (mais pas au niveau du serveur SQL) d'ajouter des utilisateurs aux groupes locaux de Windows et de se donner ainsi, ou de donner à d'autres personnes, un accès à l'instance du serveur SQL.
Impact
Avant de supprimer les connexions de groupe local, assurez-vous que d’autres groupes AD ou connexions Windows ont été ajoutés avec des autorisations équivalentes. Sinon, l’instance SQL Server peut devenir totalement inaccessible.
Vérification
Utilisez la syntaxe suivante pour déterminer si des groupes locaux ont été ajoutés en tant que connexions SQL Server.
SELECT pr.[name] AS LocalGroupName, pe.[permission_name], pe.[state_desc]
FROM sys.server_principals pr
JOIN sys.server_permissions pe
ON pr.[principal_id] = pe.[grantee_principal_id]
WHERE pr.[type_desc] = 'WINDOWS_GROUP '
AND pr.[name] like CAST(SERVERPROPERTY('MachineName') AS nvarchar) + '%';
Cette requête ne doit renvoyer aucune ligne. Correction :
- Pour chaque ouverture de session LocalGroupName, créer au besoin un groupe AD équivalent contenant uniquement les comptes d’utilisateur requis.
- Ajoutez le groupe AD ou des comptes Windows individuels en tant que connexion SQL Server et accordez-lui les autorisations requises.
- Supprimer l’ouverture de session LocalGroupName en utilisant la syntaxe ci-dessous après le remplacement de nom.
USE [master]
GO
DROP LOGIN [<name>]
GO
Par défaut, aucun groupe local n’est ajouté en tant que connexions SQL.
3.11 S’assurer que le rôle public dans la base de données msdb n’est pas autorisé à accéder aux proxies SQL Agent (automatisés)
Description
Le rôle de la base de données publique contient tous les utilisateurs de la base de données msdb. Les proxy de l'agent SQL définissent un contexte de sécurité dans lequel une étape du travail peut être exécutée.
Motif
Accorder l'accès aux proxys de l'agent SQL pour le rôle public permettrait à tous les utilisateurs d'utiliser le proxy qui peut avoir des privilèges élevés. Cela enfreindrait probablement le principe du moindre privilège.
Impact
Avant de révoquer le rôle public du proxy, assurez-vous que d’autres connexions ou des rôles de base de données définis par l’utilisateur appropriés ont été ajoutés avec des autorisations équivalentes. Sinon, les étapes de travail SQL Agent dépendant de cet accès échoueront.
Vérification
Utilisez la syntaxe suivante pour déterminer si l’accès à des proxy a été accordé au rôle public de la base de données msdb.
USE [msdb]
GO
SELECT sp.name AS proxyname
FROM dbo.sysproxylogin spl
JOIN sys.database_principals dp
ON dp.sid = spl.sid
JOIN sysproxies sp
ON sp.proxy_id = spl.proxy_id
WHERE principal_id = USER_ID('public');
GO
Cette requête ne doit renvoyer aucune ligne.
Remédiation
- S’assurer que les principaux de sécurité requis ont explicitement accès au proxy (utilisez sp_grant_login_to_proxy).
- Révoquer l’accès au proxyname du rôle public
USE [msdb]
GO
EXEC dbo.sp_revoke_login_from_proxy @name = N'public', @proxy_name =
N'proxyname';
GO
Par défaut, le rôle de base de données publique msdb n’a accès à aucun proxy.
3.12 S’assurer que le rôle SYSADMIN est limité aux comptes administratifs ou intégrés
Description
Le rôle SYSADMIN est le rôle de niveau serveur privilégié le plus élevé dans le moteur de base de données SQL Server. De plus, par défaut, les comptes intégrés sont autorisés à ce rôle au niveau du serveur par Microsoft Design afin que le moteur de base de données fonctionne comme prévu. Les comptes virtuels / SID de service suivants sont des membres par défaut de SYSADMIN : NT SERVICE SQLWriter NT SERVICE Winmgmt NT SERVICE MSSQLSERVER (Utilisé par le service du moteur de base de données SQL) NT SERVICE SQLSERVERAGENT (Utilisé par le service SQL Agent) Cela signifie que les comptes de service pour le moteur de base de données SQL et l’agent SQL n’ont pas besoin et ne devraient pas avoir , leurs comptes de service spécifiques ajoutés au groupe SYSADMIN séparément, car ils ne sont pas nécessaires.dans la base de données sa compte et les comptes de service sont automatiquement créés lors de l’installation de SQL Server sont nécessaires pour obtenir le rôle SYSADMIN. Les DBA peuvent créer des comptes avec le rôle SYSADMIN pour le support et l’administration. Ces comptes doivent être limités et protégés par des restrictions strictes d’accès et d’autorisation.
Motif
Cela réduira considérablement la surface d'attaque, car seuls des comptes limités et spécifiques se verront attribuer le rôle de SYSADMIN. Les attaquants ne peuvent donc pas s'introduire dans le système de base de données à l'aide de comptes hautement privilégiés.
Vérification
Exécutez cette requête SQL pour trouver les comptes de service actuels exécutant votre moteur SQL Server avec l’autorisation de rôle SYSADMIN :
SELECT distinct(name),type_desc
FROM master.sys.server_principals a , sys.dm_server_services b
WHERE IS_SRVROLEMEMBER ('sysadmin',name) = 1 and a.name=b.service_account;
Exécutez cette requête SQL pour lister tous les principes d’instance SQL Server avec le rôle SYSADMIN qui leur est attribué
SELECT distinct(name),type_desc
FROM master.sys.server_principals
WHERE IS_SRVROLEMEMBER ('sysadmin',name) = 1
AND name not in (
'NT SERVICE\SQLWriter',
'NT SERVICE\Winmgmt',
'NT SERVICE\MSSQLSERVER',
'NT SERVICE\SQLSERVERAGENT'
);
Si des comptes non autorisés ont un rôle SYSADMIN, il s’agit d’un échec
Remédiation
Supprimez tous les comptes SQL Server non autorisés auxquels le rôle SYSADMIN est attribué en utilisant cette requête :
ALTER ROLE SYSADMIN DROP MEMBER account;
3.13 S’assurer que l’appartenance aux rôles d’administrateur dans la base de données MSDB est limité
Description:
Selon la conception de Microsoft, un compte avec DB_OWNER peut élever les autorisations à SYSADMIN.
Motif
MSDB doit être configuré avec l'indicateur TRUSTWORTHY sur ON pour fonctionner correctement. Si le paramètre TRUSTWORTHY est défini sur ON et si le propriétaire de la base de données est membre d'un groupe disposant d'informations d'identification administratives, tel que le groupe sysadmin (par exemple, le login sa par défaut), le propriétaire de la base de données peut alors être en mesure de créer et d'exécuter des assemblages non sécurisés susceptibles de compromettre l'instance du serveur SQL, ainsi que d'exécuter du code afin d'élever ses privilèges au niveau de SYSADMIN.
Verification
USE [msdb]
GO
SELECT count(*)
FROM sys.database_role_members AS drm
INNER JOIN sys.database_principals AS r
ON drm.role_principal_id = r.principal_id
INNER JOIN sys.database_principals AS m
ON drm.member_principal_id = m.principal_id
WHERE r.name in ('db_owner, db_securityadmin, db_ddladmin, db_datawriter')
and m.name <>'dbo'
GO;
Une valeur supérieure à 0 indique un échec.
Remédiation
USE [msdb]
GO
ALTER ROLE [db_owner] DROP MEMBER username;
La valeur par défaut est que seul l’utilisateur dbo est membre du rôle db_owner dans la base de données MSDB
4 - Politiques relatives aux mots de passe
Cette section contient des recommandations relatives aux politiques de mot de passe de SQLServer.
4.1 S’assurer que l’option « MUST_CHANGE » est activée pour tous les SQL Connexions authentifiées
Description
Chaque fois que cette option est définie sur ON, SQL Server demandera un mot de passe mis à jour la première fois que la connexion nouvelle ou modifiée est utilisée.
Motif
Le fait d'imposer un changement de mot de passe après une réinitialisation ou la création d'un nouveau login empêchera les administrateurs du compte ou toute personne ayant accès au mot de passe initial d'utiliser à mauvais escient le login SQL créé sans que cela ne soit remarqué.
Impact
Les options CHECK_EXPIRATION et CHECK_POLICY doivent toutes deux être activées. Les utilisateurs finaux doivent avoir les moyens (application) de changer le mot de passe lorsqu’ils sont forcés
Vérification
Utilisation de SQL Server Management Studio
- Ouvrez SQL Server Management Studio.
- Ouvrez l’explorateur d’objets et connectez-vous à l’instance cible.
- Accédez à l’onglet Connexions dans l’Explorateur d’objets et développez-le. Cliquez avec le bouton droit de la souris sur la connexion souhaitée et sélectionnez Propriétés.
- Vérifier que la case à cocher User must change password at next login est cochée.
Remédiation
Définissez l’option MUST_CHANGE pour les connexions SQL authentifiées lors de la création d’une connexion initiale :
CREATE LOGIN login_name WITH PASSWORD = '<password_value>' MUST_CHANGE,
CHECK_EXPIRATION = ON, CHECK_POLICY = ON;
Définir l’option MUST_CHANGE pour les connexions SQL authentifiées lors de la réinitialisation d’un mot de passe :
ALTER LOGIN login_name WITH PASSWORD = '<new_password_value>' MUST_CHANGE;
ACTIVÉ lors de la création d’une nouvelle connexion via l’interface graphique SSMS. OFF lors de la création d’une nouvelle connexion à l’aide de T-SQL CREATE LOGIN, sauf si l’option MUST_CHANGE est explicitement incluse avec CHECK_EXPIRATION = ON
Sources :
- https://learn.microsoft.com/en-us/sql/t-sql/statements/create-login-transact-sql?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/t-sql/statements/create-login-transact-sql?view=sql-server-ver16
4.2 S’assurer que l’option « CHECK_EXPIRATION » est activée pour toutes les connexions SQL authentifiées dans le rôle Sysadmin
Description
Applique la même stratégie d’expiration de mot de passe utilisée dans Windows aux mots de passe utilisés dans SQL Server.
Motif
S'assurer que les connexions SQL sont conformes à la politique de mot de passe sécurisée appliquée par le test de référence du serveur Windows garantira que les mots de passe pour les connexions SQL avec les privilèges sysadmin sont changés fréquemment pour aider à prévenir la compromission par une attaque par force brute. CONTROL SERVER est une autorisation équivalente à sysadmin et les connexions avec cette autorisation devraient également avoir des mots de passe qui expirent.
Impact
Il s’agit d’une recommandation d’atténuation pour les systèmes qui ne peuvent pas suivre la recommandation d’utiliser uniquement les connexions Windows authentifiées.Concernant la limitation de cette règle aux seules connexions avec les privilèges sysadmin et CONTROL SERVER, il y a trop de cas d’applications qui s’exécutent avec moins de privilèges de niveau sysadmin qui ont des mots de passe codés en dur ou des mots de passe codés en dur (ce qui est défini la première fois est presque impossible à changer). Il y a plusieurs applications d’affaires qui sont considérées comme les meilleures de la race qui ont cet échec. De plus, gardez à l’esprit que la stratégie de mot de passe est extraite de la stratégie locale de l’ordinateur, qui est extraite du paramètre Stratégie de domaine par défaut. De nombreuses organisations ont une politique de mot de passe différente concernant les comptes de service. Ceux-ci sont gérés dans AD en définissant le mot de passe du compte pour ne pas expirer et en ayant un autre processus de suivi lorsque le mot de passe doit être modifié. Avec ce deuxième contrôle en place, c’est parfaitement acceptable du point de vue de la vérification. Si vous traitez une connexion SQL Server comme un compte de service, vous devez faire de même. Cela garantit que le changement de mot de passe se produit pendant une fenêtre de temps d’arrêt communiquée et non arbitrairement
Vérification
Exécutez l’instruction T-SQL suivante pour trouver sysadmin ou les connexions équivalentes avec CHECK_EXPIRATION = OFF
SELECT l.[name], 'sysadmin membership' AS 'Access_Method'
FROM sys.sql_logins AS l
WHERE IS_SRVROLEMEMBER('sysadmin',name) = 1
AND l.is_expiration_checked <> 1
UNION ALL
SELECT l.[name], 'CONTROL SERVER' AS 'Access_Method'
FROM sys.sql_logins AS l
JOIN sys.server_permissions AS p
ON l.principal_id = p.grantee_principal_id
WHERE p.type = 'CL' AND p.state IN ('G', 'W')
AND l.is_expiration_checked <> 1;
Aucune ligne ne doit être retournée.
Remédiation
Pour chaque login_name trouvé dans la procédure d’audit, exécuter le T-SQL suivant énoncé :
ALTER LOGIN [login_name] WITH CHECK_EXPIRATION = ON;
CHECK_EXPIRATION est activé par défaut lorsque vous utilisez SSMS pour créer une connexion authentifiée SQL. CHECK_EXPIRATION est désactivé par défaut lors de l’utilisation de la syntaxe T-SQL CREATE LOGIN sans spécifier l’option CHECK_EXPIRATION.
Le compte rdsa créé par AWS RDS ne peut pas être modifié. Il a le rôle Sysadmin mais son mot de passe ne peut pas être modifié pour lui permettre d’expirer. Source : https://learn.microsoft.com/en-us/sql/relational-databases/security/password-policy?view=sql-server-ver16
4.3 S’assurer que l’option « CHECK_POLICY » est activée pour toutes les connexions authentifiées SQL
Description
Applique la même stratégie de complexité de mot de passe utilisée dans Windows aux mots de passe utilisés dans SQL Server.
Motif
S'assurer que les mots de passe de connexion authentifiés SQL sont conformes à la politique de mot de passe sécurisée appliquée par le test de référence du serveur Windows afin qu'ils ne puissent pas être facilement compromis par une attaque par force brute.
Impact
Il s’agit d’une recommandation d’atténuation pour les systèmes qui ne peuvent pas suivre la recommandation d’utiliser uniquement les connexions Windows authentifiées.Les mots de passe faibles peuvent entraîner des systèmes compromis. Les connexions authentifiées SQL Server utiliseront la stratégie de mot de passe définie dans la stratégie locale de l’ordinateur, qui est généralement définie par le paramètre Stratégie de domaine par défaut. Le paramètre est appliqué uniquement lorsque le mot de passe est modifié. Ce paramètre ne force pas la modification des mots de passe faibles existants.
Vérification
Utilisez l’extrait de code suivant pour déterminer l’état des connexions SQL et si leur complexité de mot de passe est appliquée
SELECT name, is_disabled
FROM sys.sql_logins
WHERE is_policy_checked = 0;
La valeur is_policy_checked de 0 indique que l’option CHECK_POLICY est OFF ; la valeur de 1 est ON. Si la valeur is_disabled est 1, la connexion est désactivée et inutilisable. Si aucune ligne n’est retournée, il n’existe pas de connexion SQL Authenticated ou elles ont toutes CHECK_POLICY ON.
Remédiation
Pour chaque login_name trouvé par la procédure d’audit, exécuter l’instruction T-SQL suivante :
ALTER LOGIN [login_name] WITH CHECK_POLICY = ON;
La valeur par défaut est CHECK_POLICY est ON
5 Vérification et journalisation
Cette section contient des recommandations relatives aux mécanismes d’audit et de journalisation de SQL Server.
5.1 S’assurer que le nombre maximal de fichiers journaux d’erreurs est supérieur ou égal à 12
Description
Les fichiers journaux d’erreurs SQL Server doivent être protégés contre la perte. Les fichiers journaux doivent être sauvegardés avant d’être écrasés. Conserver plus de journaux d’erreurs permet d’éviter la perte de recyclage fréquent avant que les sauvegardes ne puissent se produire.
Motif
Le journal des erreurs du serveur SQL contient des informations importantes sur les principaux événements du serveur ainsi que des informations sur les tentatives de connexion.
Impact
Une fois le nombre maximal de journaux d’erreurs atteint, le fichier journal d’erreurs le plus ancien est supprimé chaque fois que SQL Server redémarre ou que sp_cycle_errorlog est exécuté.
Verification
- Ouvrez SQL Server Management Studio.
- Ouvrez l’explorateur d’objets et connectez-vous à l’instance cible.
- Accédez à l’onglet Gestion dans l’Explorateur d’objets et développez-le. Cliquez avec le bouton droit de la souris sur le fichier SQL Server Logs et sélectionnez Configurer.
- Vérifiez que la case Limit the number of error log files before they are recycled est cochée.
- Vérifier que le nombre maximal de fichiers journaux d’erreurs est supérieur ou égal à 12.
Remédiation
- Ouvrez SQL Server Management Studio ;
- Ouvrez l’explorateur d’objets et connectez-vous à l’instance cible;
- Accédez à l’onglet Gestion dans l’Explorateur d’objets et développez-le. Cliquez avec le bouton droit de la souris sur le fichier SQL Server Logs et sélectionnez Configurer ;
- Cochez la case Limiter le nombre de fichiers journaux d’erreurs avant leur recyclage ;
- Définissez le nombre maximal de fichiers journaux d’erreurs sur 12 ou plus.
5.2 Assurez-vous que l’option de configuration du serveur 'Default Trace Enabled' est réglé sur '1'
Description
Le suivi par défaut fournit un journal d’audit de l’activité de la base de données, y compris les créations de compte, l’élévation des privilèges et l’exécution des commandes DBCC.
Motif
La trace par défaut fournit des informations d'audit précieuses concernant les activités liées à la sécurité sur le serveur.
Vérification
Exécuter la commande T-SQL suivante :
SELECT name,
CAST(value as int) as value_configured,
CAST(value_in_use as int) as value_in_use
FROM sys.configurations
WHERE name = 'default trace enabled';
Les deux colonnes de valeur doivent afficher 1.
Remédiation
Exécutez la commande T-SQL suivante
EXECUTE sp_configure 'show advanced options', 1;
RECONFIGURE;
EXECUTE sp_configure 'default trace enabled', 1;
RECONFIGURE;
GO
EXECUTE sp_configure 'show advanced options', 0;
RECONFIGURE;
5.3 Assurez-vous que 'Vérification de connexion' est défini sur 'Échecs de connexion'
Description
Ce paramètre enregistre les tentatives d’authentification échouées pour les connexions SQL Server au journal d’erreurs SQL Server. Il s’agit du paramètre par défaut pour SQL Server. Historiquement, ce paramètre a été disponible dans toutes les versions et éditions de SQL Server. Avant la disponibilité de SQL Server Audit, c’était le seul mécanisme fourni pour capturer les connexions (réussies ou échouées).
Motif
La capture des échecs de connexion fournit des informations clés qui peuvent être utilisées pour détecter et confirmer les attaques par devinette de mot de passe. La capture des tentatives de connexion réussies peut être utilisée pour confirmer l'accès au serveur lors d'enquêtes judiciaires, mais l'utilisation de ce paramètre de niveau d'audit pour capturer également les connexions réussies crée un bruit excessif dans le journal d'erreurs du serveur SQL, ce qui peut gêner un administrateur de bases de données essayant de résoudre les problèmes. Dans d'autres parties de ce benchmark, nous recommandons d'utiliser la nouvelle fonctionnalité légère d'audit du serveur SQL pour capturer à la fois les connexions réussies et les échecs.
Impact
Au minimum, nous voulons nous assurer que les connexions échouées sont capturées afin de détecter si un adversaire tente de forcer les mots de passe ou d’accéder de manière incorrecte à un serveur SQL. La modification du paramètre nécessite un redémarrage du service SQL Server.
Vérification:
EXEC xp_loginconfig 'audit level';
Une valeur config_failure indique un paramètre de vérification de la connexion au serveur pour les connexions ayant échoué uniquement. Si une config_value de all apparaît, les connexions échouées et réussies sont enregistrées. Les deux paramètres doivent également être considérés comme valides, mais comme mentionné, la capture de connexions réussies à l’aide de cette méthode crée beaucoup de bruit dans SQL Server Errorlog.
Remédiation
- Ouvrez SQL Server Management Studio ;
- Cliquez avec le bouton droit de la souris sur l’instance cible, sélectionnez Propriétés et accédez à l’onglet Sécurité ;
- Sélectionnez l’option Échecs de connexion uniquement dans la section Vérification de connexion, puis cliquez sur OK ;
- Redémarrez l’instance SQL Server ;
5.4 S’assurer que 'SQL Server Audit' est configuré pour capturer à la fois les 'échecs' et les 'connexions réussies'
Description
SQL Server Audit est capable de capturer les connexions échouées et réussies et de les écrire à l’un des trois endroits suivants : le journal des événements d’application, le journal des événements de sécurité ou le système de fichiers. Nous l’utiliserons pour capturer toute tentative de connexion à SQL Server, ainsi que toute tentative de modification de la stratégie d’audit, des modifications des adhésions de rôles privilégiés et des modifications des paramètres du serveur. Cela servira également de deuxième source pour enregistrer les échecs de connexion tentatives.
Motif
En utilisant l'audit au lieu du paramètre traditionnel sous l'onglet Sécurité pour capturer les connexions réussies, nous réduisons le bruit dans l'ERRORLOG. Il est ainsi plus petit et plus facile à lire pour les administrateurs de bases de données qui tentent de résoudre des problèmes avec le serveur SQL. L'objet Audit peut également écrire dans le journal des événements de sécurité, bien que cela nécessite une configuration du système d'exploitation. Cela offre une option supplémentaire pour le stockage des événements de connexion, en particulier en conjonction avec un SIEM.
Impact
Avec la recommandation précédente, seules les connexions échouées sont capturées. Si l’objet Audit n’est pas implémenté avec le paramètre approprié, SQL Server ne capture pas les connexions réussies, ce qui pourrait s’avérer utile pour la criminalistique.
Verification
Exécutez la commande T-SQL suivante :
SELECT
S.name AS 'Audit Name'
, CASE S.is_state_enabled
WHEN 1 THEN 'Y'
WHEN 0 THEN 'N' END AS 'Audit Enabled'
, S.type_desc AS 'Write Location'
, SA.name AS 'Audit Specification Name'
, CASE SA.is_state_enabled
WHEN 1 THEN 'Y'
WHEN 0 THEN 'N' END AS 'Audit Specification Enabled'
, SAD.audit_action_name
, SAD.audited_result
FROM sys.server_audit_specification_details AS SAD
JOIN sys.server_audit_specifications AS SA
ON SAD.server_specification_id = SA.server_specification_id
JOIN sys.server_audits AS S
ON SA.audit_guid = S.audit_guid
WHERE SAD.audit_action_id IN ('CNAU', 'LGFL', 'LGSD', 'ADDP', 'ADSP', 'OPSV')
or (SAD.audit_action_id IN ('DAGS', 'DAGF') and (select count(*) from
sys.databases where containment=1) > 0);
Le jeu de résultats doit contenir les lignes suivantes, une pour chacune des lignes suivantes :
AUDIT_CHANGE_GROUP
FAILED_LOGIN_GROUP
SUCCESSFUL_LOGIN_GROUP
DATABASE_ROLE_MEMBER_CHANGE_GROUP
SERVER_ROLE_MEMBER_CHANGE_GROUP
SERVER_OPERATION_GROUP
L’ensemble de résultats doit également contenir ces 2 lignes s’il y a des bases de données de contenu :
SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP
FAILED_DATABASE_AUTHENTICATION_GROUP
Les spécifications Audit et Audit doivent être activées et le résultat audité devrait inclure à la fois le succès et l’échec.
Remédiation
- Développez SQL Server dans l’explorateur d’objets ;
- Développez le dossier de sécurité ;
- Cliquez avec le bouton droit de la souris sur le dossier Audits et choisissez New Audit... ;
- Spécifiez un nom pour l’audit du serveur ;
- Spécifiez les détails de la destination de l’audit, puis cliquez sur OK pour enregistrer l’audit du serveur ;
- Cliquez avec le bouton droit de la souris sur Server Audit Specifications et choisissez New Server Audit Spécification... ;
- Nommer la spécification de vérification du serveur ;
- Sélectionnez l’audit de serveur qui vient d’être créé dans le menu déroulant Audit ;
- Cliquez sur le menu déroulant sous Type d’action de vérification et sélectionnez AUDIT_CHANGE_GROUP ;
- Cliquez sur le nouveau menu déroulant Type d’action d’audit et sélectionnez FAILED_LOGIN_GROUP ;
- Cliquez sur le nouveau menu déroulant sous Type d’action de vérification et sélectionnez SUCCESSFUL_LOGIN_GROUP ;
- Cliquez sur le nouveau menu déroulant sous Type d’action de vérification et sélectionnez DATABASE_ROLE_MEMBER_CHANGE_GROUP ;
- Cliquez sur le nouveau menu déroulant sous Type d’action de vérification et sélectionnez SERVER_ROLE_MEMBER_CHANGE_GROUP ;
- Cliquez sur le nouveau menu déroulant sous Type d’action de vérification et sélectionnez SERVER_OPERATION_GROUP ;
- Cliquez sur le nouveau menu déroulant sous Type d’action de vérification et sélectionnez SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP ;
- Cliquez sur le nouveau menu déroulant sous Type d’action de vérification et sélectionnez FAILED_DATABASE_AUTHENTICATION_GROUP ;
- Cliquez sur OK pour enregistrer la spécification d’audit du serveur ;
- Cliquez avec le bouton droit de la souris sur la nouvelle spécification de vérification du serveur et sélectionnez et activer la spécification de vérification du serveur ;
- Cliquez avec le bouton droit de la souris sur le nouvel audit du serveur et sélectionnez Activer l’audit du serveur.
Renseignements supplémentaires
Si vous souhaitez filtrer les événements « VIEW SERVER STATE » de l’audit (parce qu’il peut créer des lignes supplémentaires dans le journal et que vous pouvez ou non être intéressé par cet événement spécifique), créez votre audit serveur avec un filtre pour exclure cet événement spécifique :
CREATE SERVER AUDIT TrackLogins TO APPLICATION_LOG WHERE
([audit_id]<>(1414746966)) ;
6 - Développement d’applications
Cette section contient des recommandations relatives au développement d’applications qui interagissent avec SQL Server.
6.1 S’assurer que les entrées de la base de données et de l’application sont nettoyées
Description
Validez toujours les entrées de l’utilisateur reçues d’un client ou d’une application de base de données en testant le type, la longueur, le format et la plage avant de les transmettre au serveur de base de données.
Motif
L'assainissement de l'entrée utilisateur minimise considérablement le risque d'injection SQL.
Impact
Le nettoyage des entrées utilisateur peut nécessiter des modifications du code d’application ou de la syntaxe des objets de base de données. Ces changements peuvent exiger que les applications ou les bases de données soient temporairement mises hors ligne.
Toute modification apportée à TSQL ou au code d’application doit être minutieusement testée dans l’environnement de test avant la mise en production.
Vérification
Vérifier avec les équipes d'application que toute interaction avec la base de données se fait au moyen de procédures stockées et non de SQL dynamique. Révoquer tous les privilèges INSERT, UPDATE ou DELETE des utilisateurs afin que les modifications des données soient effectuées au moyen de procédures stockées. Vérifier qu'il n'y a pas de requête SQL dans le code de l'application produite par la concaténation de chaînes.
Remédiation
Les mesures suivantes peuvent être prises pour corriger les vulnérabilités d’injection SQL :
- Examiner TSQL et le code d’application pour l’injection SQL ;
- Autoriser uniquement les comptes à privilèges minimaux à envoyer des données utilisateur au serveur ;
- Minimiser le risque d’attaque par injection SQL en utilisant des commandes paramétrées et des procédures stockées ;
- Rejeter les entrées utilisateur contenant des données binaires, des séquences d’échappement et des caractères de commentaire ;
- Toujours valider les entrées utilisateur et ne pas les utiliser directement pour créer des instructions SQL.
Source : https://owasp.org/www-community/attacks/SQL_Injection
6.2 S’assurer que « CLR Assembly Permission Set » est réglé sur « SAFE_ACCESS » pour tous les ensembles CLR (automatisés)
Description
Définir les ensembles d’autorisations d’assemblage CLR sur SAFE_ACCESS empêchera les assemblages d’accéder aux ressources externes du système telles que les fichiers, le réseau, les variables d’environnement ou le registre.
Motif
Les ensembles de permissions EXTERNAL_ACCESS ou UNSAFE peuvent être utilisés pour accéder à des zones sensibles du système d'exploitation, voler et/ou transmettre des données et modifier l'état et d'autres mesures de protection du système d'exploitation Windows sous-jacent.
Impact
La mesure de correction doit d’abord être testée dans un environnement d’essai avant la production pour s’assurer que l’assemblage fonctionne toujours comme prévu avec le paramètre d’autorisation SAFE.
Vérification
Exécuter l’instruction SQL suivante :
USE database_name;
GO
SELECT name,
permission_set_desc
FROM sys.assemblies
WHERE is_user_defined = 1 AND name <> 'Microsoft.SqlServer.Types';
Tous les assemblages retournés doivent afficher SAFE_ACCESS dans le permission_set_desc colonne
Remédiation
USE database_name;
GO
ALTER ASSEMBLY <assembly_name> WITH PERMISSION_SET = SAFE;
Selon la documentation de Microsoft, "SQL Server contient des assemblys CLR que le moteur de base de données utilise pour fournir certaines fonctionnalités. L’assemblage Microsoft.SQLServer.Types qui est inclus avec l’installation de SQL Server apparaît dans les métadonnées comme un assemblage NON SÉCURISÉ. C’est par conception. Ces assemblys sont considérés comme sécurisés par défaut.".
Sources :
- https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration/security/clr-integration-code-access-security?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-assemblies-transact-sql?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-assembly-transact-sql?view=sql-server-ver16
7 – Chiffrement
Ces recommandations concernent les aspects liés au chiffrement de SQL Server
7.1 S’assurer que l’algorithme de chiffrement à clé symétrique est défini sur 'AES_128' ou supérieur dans les bases de données non système
Description
Conformément aux meilleures pratiques de Microsoft, seules les options d’algorithme AES SQL Server, AES_128, AES_192 et AES_256, doivent être utilisées pour un algorithme de chiffrement à clé symétrique.
Motif
Les algorithmes suivants (tels qu'ils sont désignés par le serveur SQL) sont considérés comme faibles ou obsolètes et ne doivent plus être utilisés dans le serveur SQL : DES, DESX, RC2, RC4, RC4_128. De nombreuses organisations peuvent accepter les algorithmes Triple DES (TDEA) qui utilisent les options de clés 1 (3 clés ou 3TDEA) ou 2 (2 clés ou 2TDEA). Dans SQL Server, ces algorithmes sont appelés respectivement TRIPLE_DES_3KEY et TRIPLE_DES. En outre, l'algorithme de SQL Server appelé DESX est en fait la même implémentation que l'algorithme TRIPLE_DES_3KEY. Cependant, l'utilisation de l'identifiant DESX en tant que type d'algorithme a été dépréciée et son usage est désormais déconseillé
Impact
Élimine l’utilisation d’algorithmes faibles et obsolètes qui peuvent mettre un système à un risque plus élevé d’un attaquant de casser la clé. Les données cryptées ne peuvent pas être compressées, mais les données compressées peuvent être cryptées. Si vous utilisez la compression, vous devez compresser les données avant de les chiffrer.
Vérification
Exécuter le code suivant pour chaque base de données utilisateur individuelle :
USE database_name
GO
SELECT db_name() AS Database_Name, name AS Key_Name
FROM sys.symmetric_keys
WHERE algorithm_desc NOT IN ('AES_128','AES_192','AES_256')
AND db_id() > 4;
GO
Pour la conformité, aucune ligne ne doit être retournée.
Remédiation
Sources :
- https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-symmetric-key-transact-sql?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/choose-an-encryption-algorithm?view=sql-server-ver16
7.2 S’assurer que la taille de la clé asymétrique est définie sur 'supérieure ou égale à 2048' dans les bases de données non système
Description
Microsoft Best Practices recommande d’utiliser au moins un algorithme de chiffrement 2048 bits pour les clés asymétriques
Motif
L'algorithme de chiffrement RSA_2048 pour les clés asymétriques dans le serveur SQL est le niveau binaire le plus élevé fourni et donc le choix disponible le plus sûr (les autres choix sont RSA_512 et RSA_1024).
Impact
Le niveau de bit supérieur peut entraîner des performances plus lentes, mais réduit la probabilité qu’un attaquant casse la clé. Les données cryptées ne peuvent pas être compressées, mais les données compressées peuvent être cryptées. Si vous utilisez la compression, vous devez compresser les données avant de les chiffrer.
Vérification
Exécuter le code suivant pour chaque base de données utilisateur individuelle :
USE database_name
GO
SELECT db_name() AS Database_Name, name AS Key_Name
FROM sys.asymmetric_keys
WHERE key_length < 2048
AND db_id() > 4;
GO
Pour la conformité, aucune ligne ne doit être retournée.
Sources :
- https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-symmetric-key-transact-sql?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/choose-an-encryption-algorithm?view=sql-server-ver16
7.3 S’assurer que les sauvegardes de base de données sont chiffrées
Description
S’assurer que les sauvegardes de base de données sont chiffrées
Motif
Les bases de données peuvent contenir des données sensibles. Les sauvegardes de ces données permettent à celles-ci de quitter facilement l'entreprise et les environnements sécurisés. Le chiffrement de la sauvegarde rend l'accès aux données beaucoup plus difficile.
Impact
Une sauvegarde de base de données accidentellement exposée à Internet ou transmise en dehors d'un environnement sécurisé peut être facilement restaurée sur un serveur SQL n'importe où et son contenu découvert.
Verification
SELECT
b.key_algorithm, b.encryptor_type, d.is_encrypted,
b.database_name,
b.server_name
FROM msdb.dbo.backupset b
inner join sys.databases d on b.database_name = d.name
where b.key_algorithm IS NULL AND b.encryptor_type IS NULL AND d.is_encrypted
= 0;
Aucune ligne ne doit être retournée par la requête.
Remédiation
Les sauvegardes SQL Server doivent 'Sauvegarder sur un nouveau support', pas 'Sauvegarder sur le support existant' afin de permettre le chiffrement. L’option de sauvegarde pour chiffrer la sauvegarde peut être implémentée après qu’un certificat ou une clé asymétrique a été appliquée à SQL Server à cette fin. Vous pouvez également chiffrer la base de données avec TDE. Cela chiffre également automatiquement les sauvegardes. Voir le chapitre 7.5.
7.4 S’assurer que le chiffrement du réseau est configuré et activé
Description
La configuration et l'activation du chiffrement du réseau garantissent que le trafic entre l'application et le système de base de données est crypté. Cela garantit la conformité aux normes de sécurité telles que PCI DSS, ce qui est nécessaire si les connexions passent par un réseau public. Le chiffrement réseau peut être configuré dans SQL Server avec des certificats auto-signés ou des certificats TLS.
Motif
Le chiffrement du réseau garantit que les données transmises sur le réseau sont protégées, de sorte que les attaquants ne peuvent pas exfiltrer les mots de passe et les données confidentielles. Il protège contre les attaques de l'homme du milieu et les attaques de reniflage du réseau visant à exfiltrer les données transmises entre le système de base de données et les applications.
Vérification
Exécuter le code T-SQL suivant sur la base de données principale :
use [master]
select distinct(encrypt_option) from sys.dm_exec_connections;
GO
Remédiation
Sources :
- https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-sql-server-encryption?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver16
- https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/certificate-requirements?view=sql-server-ver16
7.5 S’assurer que les bases de données sont chiffrées avec TDE
Description
Assurez-vous que les bases de données des utilisateurs sont cryptées à l’aide de Transparent Data Encryption (TDE). Sauvegardes de bases de données cryptées avec TDE ou également cryptées automatiquement.
Motif
Une personne malveillante qui vole des supports physiques tels que des lecteurs ou des bandes de sauvegarde peut restaurer ou attacher la base de données et parcourir ses données. Une solution consiste à crypter les données sensibles dans une base de données et à utiliser un certificat pour protéger les clés qui cryptent les données. Cette solution empêche toute personne ne disposant pas des clés d'utiliser les données.
Impact
Un fichier de données de base de données, un fichier journal ou une sauvegarde accidentellement exposé à Internet ou transmis en dehors d’un environnement sécurisé peut être facilement copié / restauré sur un serveur SQL n’importe où et son contenu découvert.
Vérification :
select database_id, name, is_encrypted from sys.databases
where database_id > 4 and is_encrypted != 1
La requête ne doit renvoyer aucune ligne
Remédiation
Implémentez le chiffrement TDE sur chaque base de données utilisateur avec des données sensibles.
Sources :
- https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver16
- https://learn.microsoft.com/en-us/archive/blogs/sqlsecurity/feature-spotlight-transparent-data-encryption-tde
Sources
Ce guide a été traduit de l'anglais par Visiativ depuis http://benchmarks.cisecurity.org.
