Les données sont un atout essentiel de toute organisation, et les bases de données mal sécurisées sont trop souvent responsables des failles de sécurité. Cet article détaille les meilleures pratiques de sécurité du serveur SQL, ainsi que les considérations de sécurité essentielles pour protéger vos bases de données contre les attaques malveillantes.
La sécurité des données comprend trois piliers essentiels - confidentialité, intégrité et disponibilité (CIA) et traite de processus spécifiques pour protéger les données contre les accès intentionnels et accidentels. Décomposons les différents domaines et étapes à suivre pour aborder la sécurité de SQL Server, l'une des bases de données relationnelles les plus utilisées aujourd'hui.
Bonnes pratiques de sécurité SQL Server
1. Assurez la sécurité physique de votre SQL Server
En matière de sécurité SQL Server, la sécurité physique ne peut être négligée. La sécurité physique fait référence à la limitation de l'accès non autorisé aux centres de données ou à d'autres composants physiques du serveur. Par exemple, vous pouvez implémenter une pièce verrouillée avec un accès restreint à l'aide d'une carte à puce, d'une empreinte digitale ou d'une reconnaissance faciale. Vous pouvez également configurer un segment de réseau restreint pour SQL Server.
Les centres de données abritent l'infrastructure d'une organisation, telle que les routeurs, les commutateurs, les serveurs, les pare-feu et les périphériques de stockage. La sécurité physique traite de la protection du matériel, des logiciels et du réseau contre tout accès non autorisé ou catastrophe naturelle. Cela peut concerner les domaines suivants :
- Sécuriser l'accès aux locaux et aux équipements pour le personnel autorisé uniquement
- Maintenir les systèmes de contrôle d'accès
- Vigilance 24h/24, 7j/7 et 365j/an grâce à des agents de sécurité sur site ou à une surveillance CCTV
- Alimentation sans coupure (UPS)
- Disposer d'un système d'alarme incendie et d'un système de détection de fumée par aspiration
- Disposer d'un panneau de détection de fuites d'eau actif
- Systèmes anti-rongeurs
- Systèmes d'extinction d'incendie
- Contrôle et surveillance de la température et de l'humidité
- Maintenance périodique du matériel
2. Protégez votre système d'exploitation
SQL Server est installé sur un système d'exploitation existant tel que Windows ou Linux. Par conséquent, la sécurité du système d'exploitation joue un rôle essentiel dans la sécurité de SQL Server. Voici quelques recommandations pour protéger votre système d'exploitation :
- Appliquez régulièrement les correctifs de sécurité et les service packs du système d'exploitation
- Définir une politique de correctifs du système d'exploitation qui applique des correctifs sur des environnements inférieurs suivis d'un correctif de production
- Utilisez toujours des versions stables et prises en charge du système d'exploitation du produit. Par exemple, Microsoft a interrompu la prise en charge de Windows Server 2003, vous ne devez donc pas l'utiliser pour l'hébergement de bases de données
- Ne pas autoriser l'accès à Internet sur vos serveurs de base de données
- Vous devez désinstaller, arrêter ou désactiver les applications et les lecteurs inutilisés pour limiter les possibilités d'attaques potentielles
- Mettre en place un pare-feu avec un accès restreint aux serveurs de base de données afin que seuls les serveurs d'applications nécessitant un accès au serveur de base de données soient autorisés à transmettre le trafic provenant des pare-feu
- Ouvrez des ports spécifiques dans le pare-feu. Par exemple, par défaut, SQL Server s'exécute sur le port 1433. Par conséquent, vous pouvez autoriser les ports TCP 1433 et 3389 pour l'accès au serveur distant si aucune autre application ne s'exécute sur le serveur. De même, le service d'analyse utilise le port par défaut 2383 comme port standard. Pour obtenir la liste complète des ports dans SQL Server, consultez cette documentation sur les ports utilisés par SQL Server. Vous pouvez également utiliser des certificats SSL ou TLS pour sécuriser l'accès à SQL Server. Ces certificats peuvent chiffrer le transfert de données entre SQL Server et les applications clientes. La configuration de SQL Server est requise pour un certificat auto-signé ou le certificat émis par l'autorité de certification (CA). Vous pouvez vous référer à l'article : Comment définir et utiliser des connexions SQL Server chiffrées pour plus de détails.
- Exploitez l'option Extended Protection for Authentication pour empêcher une attaque de relais d'authentification à l'aide de la liaison de service et de la liaison de canal. Pour activer la protection étendue, accédez au gestionnaire de configuration SQL Server, développez l'écran, cliquez avec le bouton droit sur Protocoles, puis accédez à Protection avancée, étendue. Notez que cette option est désactivée par défaut.
De même, vous pouvez forcer la connexion chiffrée à SQL Server en utilisant l'option suivante.
Vous pouvez également consulter la protection étendue pour plus de détails.
3. Réduisez votre surface
La surface de SQL Server comprend des fonctionnalités de moteur de base de données qui fournissent des fonctionnalités supplémentaires telles que l'envoi d'e-mails. Ces composants peuvent être une cible potentielle pour accéder à SQL Server pour des activités malveillantes. Par conséquent, vous devez désactiver le composant et les fonctionnalités de SQL Server qui ne sont pas utilisés, car cela limitera les risques d'attaque potentielle. Les principaux composants que vous pouvez examiner et désactiver sont répertoriés ci-dessous.
- Rechercher les procédures de démarrage
- Procédures d'automatisation OLE
- CLR activé
- Chaînage de propriété entre bases de données
- xp_cmdshell
- XP de messagerie de base de données
Vous pouvez consulter cet article pour obtenir des informations détaillées sur les options de configuration du serveur.
4. Configurer un serveur pour écouter sur un port différent
Microsoft SQL Server utilise le port par défaut 1433 pour toutes les connexions à la base de données. Il s'agit d'un risque de sécurité courant dans de nombreux environnements de bases de données, car les professionnels des bases de données ne modifient généralement pas le port par défaut. C'est un port bien connu et les intrus peuvent profiter de cette opportunité pour accéder à SQL Server. Par conséquent, vous devez utiliser un port autre que celui par défaut pour renforcer votre sécurité SQL Server. Vous pouvez modifier cela à l'aide du gestionnaire de configuration SQL Server.
5. Ajuster l'authentification SQL Server
La protection de vos données dépend de la capacité à authentifier l'accès à des données spécifiques. SQL Server propose deux options pour l'authentification de la base de données.
- Authentification Windows
- Authentification Windows et SQL (mode mixte)
Pour vérifier le modèle d'authentification du serveur, cliquez avec le bouton droit sur l'instance SQL Server et accédez à Sécurité.
L'authentification Windows utilise des comptes Active Directory pour les authentifications. Vous pouvez disposer d'un contrôle de politique centralisé pour la complexité du mot de passe, l'expiration du mot de passe, le verrouillage du compte et les groupes Active Directory dans l'Active Directory. Par conséquent, vous devez utiliser l'authentification Windows au lieu de l'authentification SQL Server. Ici, l'utilisateur se connecte à l'aide d'un compte Windows et SQL Server valide les informations d'identification à l'aide du jeton principal Windows. Il utilise le protocole de sécurité Kerberos pour les authentifications. Reportez-vous au mode d'authentification pour plus de détails.
Toutefois, si vous devez utiliser les connexions SQL Server, vous pouvez toujours appliquer la politique de mot de passe comme indiqué ci-dessous.
6. Mémoriser les autorisations du compte de service
SQL Services utilise un compte Windows pour exécuter ses services. Vous ne devez pas utiliser les comptes intégrés à privilèges élevés tels que Service réseau ou Système local. De même, pour un compte de service de domaine, vous devez attribuer des privilèges appropriés au rôle.
Par conséquent, je vous recommande de vous référer à la configuration des comptes de service et des autorisations Windows pour plus de détails sur les autorisations des comptes de service SQL Server.
7. Appliquer les correctifs SQL Server en production
Microsoft publie des service packs réguliers (SQL Server 2016 ou version antérieure) et des packs cumulatifs (SQL Server 2017 et versions ultérieures) pour résoudre les problèmes connus et les problèmes de sécurité. Par conséquent, vous devez toujours prévoir d'implémenter les correctifs SQL Server sur les instances de production. Cependant, n'appliquez pas directement les correctifs sur les instances de production. Appliquez-les toujours en premier dans l'environnement de test, validez et planifiez le déploiement en production.
Vous pouvez vous référer aux dernières mises à jour de Microsoft SQL Server pour trouver des détails sur les derniers service packs et packs cumulatifs.
8. Sécurisez vos sauvegardes
En ce qui concerne la sécurité de SQL Server, la sécurisation de vos sauvegardes est essentielle. Généralement, les professionnels des bases de données ne tiennent pas compte de toutes les exigences de sécurisation des sauvegardes de bases de données. La sauvegarde de base de données est le processus de création d'une copie de l'état opérationnel, de l'architecture et des données stockées d'une base de données. Il est donc tout aussi important de le protéger. Cela signifie restreindre l'accès aux fichiers de sauvegarde et les chiffrer correctement. En ce qui concerne la sécurisation des sauvegardes, voici quelques rappels.
- Ne donnez pas à tout le monde des droits sur le dossier de sauvegarde pour créer, afficher, modifier et supprimer des fichiers de sauvegarde
- Utilisez des sauvegardes de base de données avec chiffrement ; reportez-vous à cet article sur le chiffrement des sauvegardes pour plus de détails
9. N'oubliez pas les techniques de chiffrement et de masquage des données SQL Server
Un domaine clé de la sécurité de SQL Server est le chiffrement. Vous pouvez utiliser divers mécanismes de chiffrement pour protéger les données sensibles de votre base de données SQL Server. Les différentes options de chiffrement sont les suivantes.
- Always Encrypted :la technique Always Encrypted permet de chiffrer les données sensibles dans les applications clientes. Le pilote toujours crypté crypte et décrypte automatiquement les données sensibles dans les applications clientes. Les clés de chiffrement ne sont jamais révélées au moteur de base de données SQL Server. Il protège les données confidentielles.
- Chiffrement transparent des données (TDE) :le TDE chiffre les données au repos. Il permet de sécuriser les fichiers de données, les fichiers journaux et les fichiers de sauvegarde.
- Cryptage au niveau des colonnes :le chiffrement au niveau des colonnes permet de chiffrer des données de colonne spécifiques, par exemple, les numéros de carte de crédit et les numéros de sécurité sociale.
- Masquage des données statiques :le masquage des données statiques remplace les données sensibles à l'aide des règles de transformation des données définies.
- Masquage dynamique des données :le masquage dynamique des données permet de limiter l'exposition des données sensibles aux utilisateurs non privilégiés.
- Sécurité au niveau des lignes :la sécurité au niveau des lignes limite l'accès aux lignes de données.
10. Rendre le mot de passe de l'administrateur système compliqué
Si vous utilisez l'authentification SQL, il crée une SA de connexion avec les autorisations sysadmin. Pour protéger votre serveur SQL, procédez comme suit.
- Renommer la connexion nommée SA en un autre nom
- Désactivez le compte si vous ne prévoyez pas de l'utiliser
- Utilisez un mot de passe complexe
- Ne pas autoriser les applications à utiliser le compte SA dans les chaînes de connexion
11. Auditer les connexions à la base de données
L'audit est souvent négligé lorsqu'il s'agit de la sécurité de SQL Server. Vous devez effectuer un audit régulier de SQL Server pour les échecs de connexion. Vous pouvez utiliser le mécanisme d'audit de connexion par défaut pour examiner les comptes. Par exemple, supposons qu'un utilisateur tente de se connecter à SQL Server avec un compte à privilèges élevés. Dans ce cas, vous pouvez voir l'échec de la connexion et l'adresse IP de la demande entrante (client). Cela peut vous aider à détecter et à éliminer les activités suspectes.
Vous pouvez utiliser les événements étendus, la trace SQL, la capture de données modifiées, les déclencheurs (DDL, DML ou Logon), les spécifications d'audit au niveau de la base de données ou du serveur pour l'audit SQL Server.
12. Tenez compte des autorisations au niveau du serveur et de la base de données
Les professionnels des bases de données doivent être prudents lors de l'attribution d'autorisations au niveau du serveur ou au niveau de la base de données. Parfois, nous voyons que les développeurs obtiennent l'administrateur système au niveau du serveur ou les autorisations du propriétaire de la base de données au niveau de la base de données. Ce sont les autorisations les plus élevées qu'un utilisateur peut avoir au niveau de l'instance ou de la base de données, respectivement.
- Reportez-vous aux rôles fixes au niveau du serveur pour comprendre les rôles fixes au niveau du serveur et leurs fonctionnalités.
- Reportez-vous aux rôles au niveau de la base de données pour mieux comprendre les rôles fixes au niveau de la base de données.
13. Désactivez le service de navigateur SQL Server
SQL Server utilise le service de navigateur pour l'instance nommée. Il écoute toutes les demandes entrantes de connexions SQL Server. Il utilise le port UDP 1434 et répond aux requêtes avec le numéro de port TCP/IP requis pour se connecter à SQL Server. Par conséquent, vous pouvez désactiver le service du navigateur et définir explicitement le numéro de port dans les chaînes d'application. Cela évite l'exposition du numéro de port aux demandes de connexion entrantes et contribue à la sécurité de SQL Server.
Vous pouvez vous référer à l'article Fonctionnement du navigateur SQL Server pour mieux comprendre le service du navigateur SQL Server.
Considérations supplémentaires sur la sécurité de SQL Server
Comme indiqué, la sécurité de SQL Server est un processus continu avec divers facteurs et étapes. Vous devez régulièrement revoir les instances SQL Server, les politiques de sécurité et les mettre à jour régulièrement à la fois au niveau de votre système d'exploitation et au niveau de SQL Server. En appliquant régulièrement ces bonnes pratiques, vous contribuerez à créer un service de base de données plus sécurisé et non perturbateur pour votre entreprise.
