Meilleures pratiques de sécurité pour SQL Server

S’applique à : SQL Server Base de données Azure SQL Azure SQL Managed Instance

Cet article fournit des informations sur les meilleures pratiques, ainsi que des instructions vous aidant à mettre en place la sécurité pour SQL Server. Pour un examen complet des fonctionnalités de sécurité de SQL Server, consultez Sécurisation de SQL Server.

Pour connaître les meilleures pratiques de sécurité d’un produit spécifique, consultez Azure SQL Database et SQL Managed Instance et SQL Server sur machines virtuelles Azure.

Vue d’ensemble

Une méthodologie de sécurité en couches fournit une solution de défense en profondeur utilisant plusieurs fonctionnalités de sécurité visant des étendues de sécurité différentes. Les fonctionnalités de sécurité mises à disposition dans SQL Server 2016 et améliorées dans les versions ultérieures contribuent à faire face aux menaces de sécurité et à fournir des applications de base de données bien sécurisées.

Azure est conforme à plusieurs règlements et normes de l’industrie et vous permet de créer une solution conforme avec SQL Server exécuté sur une machine virtuelle. Pour plus d’informations sur les exigences réglementaires relatives à Azure, voir Centre de confidentialité Azure.

Protection au niveau des colonnes

Les organisations doivent souvent protéger les données au niveau des colonnes car les données relatives aux clients, aux employés, aux secrets commerciaux, aux données de produits, aux informations de santé, aux données financières et à d’autres données sensibles sont souvent stockées dans des bases de données SQL Server. Les colonnes sensibles incluent souvent les numéros d'identification/de sécurité sociale, les numéros de téléphone mobile, le prénom, le nom, l'identification de compte financier et toutes les autres données susceptibles d'être considérées comme des données personnelles.

Les méthodes et les fonctionnalités mentionnées dans cette section augmentent le niveau de protection au niveau des colonnes avec une surcharge minimale et sans nécessiter de modifications importantes dans le code de l’application.

Utilisez Always Encrypted pour chiffrer les données au repos et sur le réseau. Les données chiffrées sont déchiffrées uniquement par les bibliothèques clientes au niveau du client d’application. Utilisez le chiffrement aléatoire déterministe quand cela est possible. Always Encrypted avec enclaves sécurisées peut améliorer les performances des opérations de comparaison comme BETWEEN, IN, LIKE, DISTINCT, Joins, et plus encore pour les scénarios de chiffrement aléatoires.

Utilisez le masquage Dynamic Data Masking (DDM) pour obfusquer les données au niveau des colonnes quand Always Encrypted n'est pas une option disponible. La fonctionnalité Dynamic Data Masking (DDM) n'est pas compatible avec Always Encrypted. Préférez Always Encrypted au masquage dynamique des données (Dynamic Data Masking) quand cela est possible.

Vous pouvez également accorder des autorisations (GRANT) au niveau des colonnes à une table, une vue ou une fonction table. Tenez compte des points suivants : - Seules les autorisations SELECT, REFERENCES et UPDATE peuvent être octroyées à une colonne. - Une instruction DENY au niveau de la table n'a pas la priorité sur une instruction GRANT au niveau de la colonne.

Protection au niveau des lignes

La Sécurité au niveau des lignes (SNL) permet à la fonctionnalité d'utiliser le contexte d'exécution de l'utilisateur afin de contrôler l'accès aux lignes d'une table de base de données. La Sécurité au niveau des lignes (SNL) garantit que les utilisateurs peuvent voir uniquement l’enregistrement qui les concerne. Cela permet à votre application de bénéficier d’une sécurité au niveau des enregistrements sans devoir effectuer de modifications significatives de l’application.

La logique métier est encapsulée dans des fonctions table contrôlées par une stratégie de sécurité qui active ou désactive la fonctionnalité de Sécurité au niveau des lignes (SNL). La stratégie de sécurité contrôle également les prédicats FILTER et BLOCK qui sont liés aux tables sur lesquelles la fonctionnalité SNL s'exécute. Utilisez la Sécurité au niveau des lignes (SNL) pour limiter les enregistrements renvoyés à l’utilisateur qui effectue l’appel. Utilisez SESSION_CONTEXT (T-SQL) pour les utilisateurs qui se connectent à la base de données par le biais d'une application de niveau intermédiaire dans laquelle les utilisateurs partagent le même compte d'utilisateur SQL Server. Pour optimiser les performances et la facilité de gestion, suivez les meilleures pratiques de sécurité au niveau des lignes.

Chiffrement de fichier

Le chiffrement Transparent Data Encryption (TDE) protège les données au niveau du fichier en fournissant le chiffrement au repos aux fichiers de base de données. Le chiffrement Transparent Data Encryption (TDE) permet de s'assurer que les fichiers de base de données, les fichiers de sauvegarde et les fichiers tempdb ne peuvent pas être joints ni lus sans les certificats corrects pour déchiffrer les fichiers de base de données. Sans le chiffrement Transparent Data Encryption (TDE), un attaquant peut prendre le support physique (lecteurs ou bandes de sauvegarde) et restaurer ou joindre la base de données afin de lire le contenu. Le chiffrement Transparent Data Encryption (TDE) est pris en charge pour le fonctionnement avec toutes les autres fonctionnalités de sécurité de SQL Server. Le chiffrement Transparent Data Encryption (TDE) fournit le chiffrement et le déchiffrement des E/S en temps réel des fichiers de données et des fichiers journaux. Le chiffrement TDE utilise une clé de chiffrement de base de données (DEK) stockée dans la base de données utilisateur. La clé de chiffrement de base de données peut aussi être protégée à l'aide d'un certificat qui est lui-même protégé par la clé principale de base de données de la base de données master.

Utilisez le chiffrement TDE pour protéger les données au repos, les sauvegardes et tempdb.

Audit et création de rapports

Pour auditer SQL Server, créez une stratégie d’audit au niveau du serveur ou de la base de données. Les stratégies de serveur s’appliquent aux bases de données existantes et à celles qui viennent d’être créées sur le serveur. Par souci de simplicité, activez l’audit au niveau du serveur et autorisez l’audit au niveau de la base de données à hériter de la propriété au niveau du serveur pour toutes les bases de données.

Auditez les tables et les colonnes contenant des données sensibles auxquelles des mesures de sécurité sont appliquées. Si une table ou une colonne est suffisamment importante pour nécessiter une protection via une fonctionnalité de sécurité, on doit considérer qu’elle est assez importante pour être auditée. Il est particulièrement important d'auditer et de passer régulièrement en revue les tables qui contiennent des informations sensibles, mais pour lesquelles il n'est pas possible d'appliquer les mesures de sécurité souhaitées en raison d'un type d'application ou d'une limitation de l'architecture.

Identités et authentification

SQL Server prend en charge deux modes d’authentification : le mode Authentification Windows et le « mode d’authentification SQL Server et Windows » (mode mixte).

Les connexions sont différentes des utilisateurs de base de données. Mappez tout d’abord des connexions ou des groupes Windows à des utilisateurs ou des rôles de base de données séparément. Accordez ensuite des autorisations à des utilisateurs, des rôles serveur et/ou des rôles de base de données pour accéder aux objets de base de données.

SQL Server prend en charge les types de connexions suivants :

• Un compte d’utilisateur Windows local ou un compte de domaine Active Directory – SQL Server s’appuie sur Windows pour authentifier les comptes d’utilisateur Windows.
• Groupe Windows : l’octroi de l’accès à un groupe Windows accorde l’accès à l’ensemble des connexions utilisateur Windows qui sont membres du groupe. La suppression d’un utilisateur d’un groupe entraîne la suppression des droits qui sont issus du groupe. L’appartenance de groupe constitue la stratégie privilégiée.
• Compte de connexion SQL Server : SQL Server stocke le nom d'utilisateur et un hachage du mot de passe dans la base de données master.
• Les utilisateurs de base de données autonome authentifient les connexions SQL Server au niveau de la base de données. Une base de données autonome est une base de données qui est isolée des autres bases de données et de l'instance SQL Server (et de la base de données master) qui héberge la base de données. SQL Server prend en charge les utilisateurs de base de données autonome pour Windows et l’authentification SQL Server.

Les recommandations et les meilleures pratiques suivantes vous aident à sécuriser vos identités et méthodes d’authentification :

• Utilisez des stratégies de sécurité basée sur les rôles à privilèges minimum pour améliorer la gestion de la sécurité.

  • La procédure standard consiste à placer les utilisateurs Active Directory dans les groupes AD. Les groupes AD doivent exister dans des rôles SQL Server et les rôles SQL Server doivent disposer des autorisations minimales requises par l’application.

• Dans Azure, utilisez la sécurité du moindre privilège en utilisant des contrôles d'accès basés sur les rôles (RBAC).

• Choisissez Active Directory plutôt que l’authentification SQL Server chaque fois que cela est possible. En particulier, préférez Active Directory au stockage de la sécurité au niveau de l’application ou de la base de données.

  • Si un utilisateur quitte l'entreprise, il est facile de désactiver le compte.
  • Il est également facile de supprimer des utilisateurs des groupes quand ils changent de rôles ou quittent l'organisation. La sécurité de groupe est considérée comme une meilleure pratique.

• Utilisez l'authentification multifacteur pour les comptes disposant d'un accès au niveau de l'ordinateur, notamment les comptes qui utilisent le protocole RDP pour se connecter à l'ordinateur. Cela permet de se prémunir contre les fuites ou les vols d’informations d’identification. En effet, l’authentification par mot de passe à facteur unique est une forme d’authentification plus faible, car les informations d’identification risquent d’être compromises ou fournies par erreur.

• Exigez des mots de passe forts et complexes qui ne peuvent pas être facilement devinés et qui ne sont utilisés ni pour d'autres comptes ni à d'autres fins. Mettez les mots de passe régulièrement à jour et appliquer les stratégies Active Directory.

• Les comptes de service géré de groupe (gMSA) offrent une gestion automatique des mots de passe, une gestion simplifiée du nom de principal du service (SPN) et délèguent la gestion à d’autres administrateurs.

  • Avec les comptes gMSA, le système d’exploitation Windows gère les mots de passe pour le compte au lieu de compter sur l’administrateur pour cette tâche.
  • Les comptes gMSA mettent à jour les mots de passe de compte automatiquement sans redémarrer les services.
  • Les comptes gMSA réduisent le niveau de la surface administrative et améliorent la séparation des tâches.

• Réduisez les droits accordés au compte AD de l’administrateur de bases de données. Envisagez une séparation des tâches qui limite l’accès à la machine virtuelle, la possibilité de se connecter au système d’exploitation, la possibilité de modifier les journaux d’erreurs et d’audit, ainsi que la possibilité d’installer des applications et/ou des fonctionnalités.

• Envisagez de supprimer les comptes d’administrateur de bases de données du rôle d’administrateur système et d’octroyer SERVEUR DE CONTRÔLE aux comptes d’administrateur de bases de données au lieu d’en faire des membres du rôle d’administrateur système. Le rôle d'administrateur système ne respecte pas DENY, contrairement à CONTROL SERVER.

Traçabilité et intégrité des données

Il peut être judicieux de conserver des enregistrements historiques des modifications de données dans le temps pour résoudre les modifications accidentelles des données. Cela peut également s'avérer utile pour l'audit des modifications d'application et permettre de récupérer des éléments de données quand un intervenant malveillant introduit des modifications de données qui n'étaient pas autorisées.

• Utilisez les tables temporelles pour conserver les versions d'enregistrement dans le temps, et pour voir les données sur la durée de vie de l'enregistrement afin de fournir un affichage historique des données de votre application.
• Les tables temporelles peuvent être utilisées pour fournir à tout moment une version de la table actuelle.

Outils et méthodes d’évaluation de la sécurité

Les outils de configuration et d'évaluation suivants traitent de la sécurité de surface, identifient les opportunités de sécurité des données et fournissent une évaluation des bonnes pratiques de la sécurité de votre environnement SQL Server au niveau de l'instance.

• Configuration de la surface d'exposition : il est recommandé de n'activer que les fonctionnalités requises par votre environnement afin de réduire le nombre de fonctionnalités susceptibles d'être attaquées par un utilisateur malveillant.
• Évaluation des vulnérabilités pour SQL Server (SSMS) : l’évaluation des vulnérabilités SQL est un outil de SSMS v17.4+ qui permet de découvrir, suivre et corriger les vulnérabilités potentielles des bases de données. L’évaluation des vulnérabilités est un outil précieux pour améliorer la sécurité des bases de données. Elle est exécutée au niveau de la base de données, par base de données.
• Découverte et classification des données SQL (SSMS) : il est courant que les administrateurs de base de données gèrent les serveurs et les bases de données sans être conscient de la sensibilité des données contenues. La recherche et classification des données ajoute la possibilité de découvrir, classifier, étiqueter et générer des rapports sur le niveau de confidentialité de vos données. La découverte et classification des données est prise en charge à partir de SSMS 17.5.

Menaces courantes liées à SQL

Il est utile de connaître certaines menaces courantes liées à SQL Server :

• Attaque par injection de code SQL : une attaque par injection de code SQL est un type d’attaque dans lequel un code malveillant est inséré dans les chaînes transmises à une instance SQL Server afin d’être exécuté.
  • Le processus d’injection consiste à terminer une chaîne de texte et à ajouter une nouvelle commande. Étant donné que la commande insérée peut avoir d'autres chaînes ajoutées préalablement à son exécution, l'attaquant termine la chaîne injectée par une marque de commentaire --.
  • SQL Server exécute toutes les requêtes reçues dont la syntaxe est valide.
• Tenez compte des attaques par canal auxiliaire, des programmes malveillants et autres menaces.

Risques d’injection de code SQL

Pour réduire le risque d'une attaque par injection de code SQL, tenez compte des éléments suivants :

• Passez en revue tous les processus SQL qui construisent des instructions SQL pour les vulnérabilités liées à une injection.
• Construisez des instructions SQL générées dynamiquement de manière paramétrée.
• Les développeurs et les administrateurs de la sécurité doivent examiner tout le code qui appelle EXECUTE, EXEC ou sp_executesql.
• Interdire les caractères d'entrée suivants :
  • ; : délimiteur de requête
  • ' : délimiteur de chaîne de données caractères
  • -- : délimiteur de commentaire sur une seule ligne
  • /* ... */ : délimiteurs de commentaire
  • xp_ : procédures stockées étendues de catalogue, comme xp_cmdshell
    • Il n'est pas recommandé d'utiliser xp_cmdshell sur un environnement SQL Server. Utilisez SQLCLR à la place ou recherchez d'autres alternatives en raison des risques liés à xp_cmdshell.
• Validez toujours les entrées utilisateur et nettoyez les sorties d’erreur afin qu’elles ne soient pas déversées ni exposées à l’attaquant.

Risques d’attaque par canal auxiliaire

Pour réduire le risque d’une attaque par canal auxiliaire, tenez compte les éléments suivants :

• Vérifiez que les correctifs d’application et de système d’exploitation (patchs) les plus récents sont appliqués.
• Pour les charges de travail hybrides, assurez-vous que les correctifs de microprogramme les plus récents sont appliqués pour tout matériel local.
• Pour les applications et les charges de travail très sensibles dans Azure, vous pouvez ajouter une protection supplémentaire contre les attaques par canal auxiliaire avec des ordinateurs virtuels isolés, des hôtes dédiés ou en utilisant des ordinateurs virtuels de calcul confidentiel, comme les ordinateurs virtuels Série DC et les ordinateurs virtuels qui tirent profit des processeurs AMD EPYC de 3e génération.

Menaces de l’infrastructure

Tenez compte des menaces d’infrastructure courantes suivantes :

• Accès en force brute : l’attaquant tente de s’authentifier avec plusieurs mots de passe sur des comptes différents jusqu’à ce qu’un mot de passe correct soit trouvé.
• Craquage de mot de passe/pulvérisation de mot de passe : les attaquants essaient un mot de passe unique et soigneusement élaboré pour tous les comptes d’utilisateur connus (un mot de passe pour plusieurs comptes). En cas d’échec de la pulvérisation initiale de mot de passe, ils réessayent avec un autre mot de passe soigneusement élaboré. Ils patientent généralement un certain temps entre les tentatives pour éviter la détection.
• Les attaques par ransomware (rançongiciel) sont un type d’attaque ciblée où un logiciel malveillant est utilisé pour chiffrer les données et les fichiers, ce qui empêche l’accès au contenu important. Les attaquants tentent d’extorquer de l’argent aux victimes, généralement sous la forme de cryptomonnaies, en échange de la clé de déchiffrement. La plupart des infections par ransomware (rançongiciel) commencent par l’envoi d’e-mails contenant des pièces jointes qui tentent d’installer un ransomware ou lors de la consultation de sites web hébergeant des kits d’exploitation qui essaient d’utiliser les vulnérabilités des navigateurs web et d’autres logiciels pour installer un ransomware.

Risques liés au mot de passe

Comme vous souhaitez éviter que les attaquants devinent facilement les noms de comptes et les mots de passe, procédez comme suit pour réduire le risque que les mots de passe soient découverts :

• Créez un seul compte d'administrateur local avec un nom différent de Administrator.
• Utilisez des mots de passe forts complexes pour tous vos comptes. Pour plus d’informations sur la création d’un mot de passe sécurisé, consultez l’article Créer un mot de passe sécurisé.
• Par défaut, Azure sélectionne l’authentification Windows pendant l’installation de la machine virtuelle SQL Server. Par conséquent, la connexion SA est désactivée et un mot de passe est affecté par l’installation. Nous recommandons que la connexion SA ne soit ni utilisée ni activée. Si vous devez avoir une connexion SQL, utilisez l'une des stratégies suivantes :

  • Créez un compte SQL avec un nom unique et qui est membre de sysadmin. Vous pouvez le faire dans le portail en activant l’authentification SQL lors de l’approvisionnement.

    Conseil

    Si vous n'activez pas l'authentification SQL lors de l'approvisionnement, vous devez modifier manuellement le mode d'authentification pour définir le mode Mode d'authentification Windows et SQL Server. Pour plus d'informations, consultez Modifier le mode d'authentification du serveur.

  • Si vous devez utiliser la connexion SA, activez la connexion après l’approvisionnement et assignez un nouveau mot de passe sécurisé.

Risques de ransomware (rançongiciel)

Tenez compte des éléments suivants pour réduire les risques de ransomware (rançongiciel) :

• La meilleure stratégie pour se prémunir contre les ransomwares (rançongiciels) est de prêter une attention particulière aux vulnérabilités des protocoles RDP et SSH. En outre, tenez compte des recommandations suivantes :
  • Utiliser des pare-feu et des ports de verrouillage
  • S'assurer que les dernières mises à jour de sécurité du système d'exploitation et des applications sont appliquées
  • Utiliser des comptes de service géré de groupe (gMSA)
  • Limiter l’accès aux machines virtuelles
  • Exiger l’accès juste-à-temps (JIT) et Azure Bastion
  • Améliorer la sécurité de la surface d’exposition en évitant d’installer des outils, notamment des outils Sysinternals et SSMS sur l’ordinateur local
  • Éviter d'installer des rôles, des fonctionnalités Windows et d'activer des services si cela n'est pas nécessaire
  • En outre, une sauvegarde complète régulière doit être planifiée et sécurisée séparément d’un compte Administrateur ordinaire afin qu’il ne puisse pas supprimer les copies des bases de données.

Contenu connexe

• Sécurisation de SQL Server
• Azure SQL Database et SQL Managed Instance
• SQL Server sur machines virtuelles Azure