Meilleures pratiques de sécurité recommandées avec les bases de données autonomes

  • Article

S’applique à :SQL ServerAzure SQL Managed Instance

Les bases de données autonomes présentent quelques menaces originales que les administrateurs du Moteur de base de données SQL Server doivent connaître et limiter. La plupart des menaces sont liées au processus d’authentification USER WITH PASSWORD , qui déplace la limite d’authentification du niveau moteur de base de données au niveau de la base de données.

Les utilisateurs d’une base de données autonome disposant de l’autorisation ALTER ANY USER, telles que les membres de l’db_owner et db_accessadmin rôles de base de données fixes, peuvent accorder l’accès à la base de données sans connaissance ni autorisation ni administrateur SQL Server. L’octroi aux utilisateurs d’un accès à une base de données autonome augmente la surface d’exposition d’attaque potentielle sur l’ensemble de l’instance SQL Server. Les administrateurs doivent comprendre cette délégation du contrôle d'accès et être très prudents lorsqu'ils accordent à des utilisateurs l'autorisation ALTER ANY USER dans la base de données autonome. Tous les propriétaires de base de données disposent de l'autorisation ALTER ANY USER . Les administrateurs SQL Server doivent régulièrement auditer les utilisateurs d’une base de données autonome.

Accès à d'autres bases de données à l'aide du compte Invité

Les propriétaires de base de données et les utilisateurs de base de données disposant de l'autorisation ALTER ANY USER peuvent créer des utilisateurs de base de données autonome. Après la connexion à une base de données autonome sur une instance de SQL Server, un utilisateur de base de données autonome peut accéder à d’autres bases de données sur le moteur de base de données, si les autres bases de données ont activé le compte invité .

Création d'un utilisateur en double dans une autre base de données

Certaines applications peuvent nécessiter qu'un utilisateur puisse accéder à plusieurs bases de données. Pour cela, il convient de créer des utilisateurs de base de données autonome dans chaque base de données. Utilisez l'option SID pour créer le second utilisateur avec le mot de passe. L'exemple suivant crée deux utilisateurs identiques dans deux bases de données.

USE DB1;  
GO  
CREATE USER Carlo WITH PASSWORD = '<strong password>';   
-- Return the SID of the user  
SELECT SID FROM sys.database_principals WHERE name = 'Carlo';  
  
-- Change to the second database  
USE DB2;  
GO  
CREATE USER Carlo WITH PASSWORD = '<same password>', SID = <SID from DB1>;  
GO

Pour exécuter une requête de bases de données croisées, vous devez définir l’option TRUSTWORTHY sur la base de données appelante. Par exemple, si l’utilisateur (Carlo) défini ci-dessus figure dans DB1, pour exécuter SELECT * FROM db2.dbo.Table1; , le paramètre TRUSTWORTHY doit être activé pour la base de données DB1. Exécutez le code suivant pour activer le paramètre TRUSTWORTHY .

ALTER DATABASE DB1 SET TRUSTWORTHY ON;

Création d'un utilisateur qui duplique une connexion

Si un utilisateur de base de données autonome avec mot de passe est créé, en utilisant le même nom qu’une connexion SQL Server et si la connexion SQL Server se connecte en spécifiant la base de données autonome comme catalogue initial, la connexion SQL Server ne pourra pas se connecter. La connexion sera évaluée en tant qu’utilisateur de base de données autonome avec principal de mot de passe sur la base de données autonome au lieu d’un utilisateur basé sur la connexion SQL Server. Cela peut entraîner un déni de service intentionnel ou accidentel pour la connexion SQL Server.

  • Il est recommandé que les membres du rôle serveur fixe sysadmin se connectent toujours sans utiliser l'option de catalogue initial. Cela connecte la connexion à la base de données master et évite toute utilisation malveillante de la tentative de connexion de la part d'un propriétaire de base de données. L’administrateur peut ensuite passer à la base de données autonome à l’aide de l’instruction USE<Database.> Vous pouvez également définir la base de données par défaut de la connexion sur la base de données autonome, qui complète la connexion à master, puis transférer la connexion vers la base de données autonome.

  • Comme meilleure pratique, ne créez pas d’utilisateurs de base de données autonome avec des mots de passe portant le même nom que les connexions SQL Server.

  • En cas de connexion en double, connectez-vous à la base de données master sans spécifier de catalogue initial, puis exécutez la commande USE pour choisir comme catalogue initial la base de données autonome.

  • Lorsque des bases de données autonomes sont présentes, les utilisateurs de bases de données qui ne sont pas des bases de données autonomes doivent se connecter au moteur de base de données sans utiliser de catalogue initial ou en spécifiant le nom de la base de données d’une base de données non autonome comme catalogue initial. Cela évite de se connecter à la base de données autonome qui est sous un contrôle moins direct par les administrateurs du moteur de base de données.

Augmentation de l'accès en modifiant l'état de la relation contenant-contenu d'une base de données

Les connexions qui disposent de l’autorisation ALTER ANY DATABASE, telles que les membres du rôle serveur fixe dbcreator, et les utilisateurs d’une base de données non autonome qui disposent de l’autorisation CONTROL DATABASE, tels que les membres du rôle de base de données fixe db_owner, peuvent modifier le paramètre d’autonomie d’une base de données. Si le paramètre d’autonomie d'une base de données est modifié de NONE en PARTIAL ou FULL, des accès utilisateur peuvent être accordés en créant des utilisateurs de base de données autonome avec mots de passe. Cela peut fournir un accès sans connaissance ni consentement des administrateurs SQL Server. Pour empêcher tout contenu de bases de données, définissez l’option d’authentification de base dedonnées sur 0. Pour empêcher que des utilisateurs de base de données autonome avec mots de passe se connectent aux bases de données autonomes sélectionnées, utilisez des déclencheurs de connexion pour annuler leurs tentatives de connexion.

Attacher une base de données autonome

En attachant une base de données autonome, un administrateur peut accorder aux utilisateurs indésirables l’accès à l’instance du moteur de base de données. Un administrateur conscient de ce risque peut mettre la base de données en ligne en mode RESTRICTED_USER, ce qui empêche l’authentification des utilisateurs de base de données autonome avec mots de passe. Seuls les principaux autorisés par le biais de connexions pourront accéder au moteur de base de données.

Les utilisateurs sont créés selon les exigences de mot de passe en vigueur au moment de leur création et les mots de passe ne sont pas revérifiés lorsqu'une base de données est attachée. En attachant une base de données autonome qui permettait des mots de passe faibles à un système avec une stratégie de mot de passe plus stricte, un administrateur pouvait autoriser les mots de passe qui ne répondent pas à la stratégie de mot de passe actuelle sur le moteur de base de données attaché. Les administrateurs peuvent éviter de conserver les mots de passe faibles en exigeant que tous les mots de passe soient réinitialisés pour la base de données attachée.

Stratégies de mot de passe

Les mots de passe d'une base de données peuvent être obligatoirement des mots de passe forts, mais ils ne peuvent pas être protégés par des stratégies de mot de passe fiables. Utilisez l'Authentification Windows chaque fois que possible pour tirer parti des stratégies de mot de passe plus étendues disponibles dans Windows.

Authentification Kerberos

Les utilisateurs de base de données autonome avec mots de passe ne peuvent pas utiliser l'Authentification Kerberos. Lorsque c'est possible, utilisez l'Authentification Windows pour tirer parti des fonctionnalités de Windows telles que Kerberos.

Attaque par dictionnaire hors connexion

Les hachages de mot de passe des utilisateurs de base de données autonome avec mots de passe sont stockés dans la base de données autonome. Quiconque disposant d'un accès aux fichiers de la base de données pourrait effectuer une attaque par dictionnaire contre des utilisateurs de base de données autonome avec mots de passe sur un système non vérifié. Pour atténuer cette menace, restreignez l'accès aux fichiers de base de données, ou n'autorisez des connexions aux bases de données autonomes qu'en utilisant l'Authentification Windows.

S'échapper d'une base de données autonome

Si une base de données est partiellement autonome, les administrateurs SQL Server doivent régulièrement auditer les fonctionnalités des utilisateurs et des modules dans des bases de données autonomes.

Déni de service via AUTO_CLOSE

Ne configurez pas de bases de données autonomes pour la fermeture automatique. Si la base de données est fermée, son ouverture pour authentifier un utilisateur consomme des ressources supplémentaires et risque de contribuer à une attaque par déni de service.

Voir aussi

Bases de données autonomes
Migrer vers une base de données partiellement autonome