Meilleures pratiques de sécurité avec des bases de données autonomes

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 USER WITH PASSWORD processus d’authentification, qui déplace la limite d’authentification du niveau moteur de base de données vers le niveau de la base de données.

Menaces liées aux utilisateurs

Les utilisateurs d’une base de données contenue disposant de l’autorisation ALTER ANY USER, tels que les membres des rôles fixes de base de données db_owner et db_securityadmin, peuvent accorder l’accès à la base de données sans que l'administrateur SQL Server le sache ou l'autorise. 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 de contrôle d’accès et être très prudents dans l’octroi de l’autorisation ALTER ANY USER aux utilisateurs dans la base de données contenue. 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 exiger qu’un utilisateur ait accès à plusieurs bases de données. Pour ce faire, créez des utilisateurs de base de données autonomes identiques dans chaque base de données. Utilisez l’option SID lors de la création du deuxième utilisateur avec 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 inter-bases de donné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 est 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 définir le TRUSTWORHTY paramètre activé.

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 contenue avec mot de passe principal dans la base de données contenue, 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.

• Comme meilleure pratique, les membres du rôle serveur fixe sysadmin doivent envisager de toujours se connecter sans utiliser l’option de catalogue initiale. Cela connecte la connexion à la base de données master et évite toute tentative du propriétaire de la base de données d’utiliser une tentative de connexion incorrecte. L’administrateur peut ensuite passer à la base de données conteneur à l’aide de l’instruction USE<base de données>. Vous pouvez également définir la base de données par défaut de la connexion à la base de données contenue, ce qui complète la connexion à master, puis transfère la connexion à la base de données contenue.

• Comme meilleure pratique, ne créez pas d’utilisateurs de base de données avec un accès fermé et des mots de passe ayant le même nom que les identifiants SQL Server.

• Si l'identifiant en double existe, connectez-vous à la base de données master sans spécifier de catalogue initial, puis exécutez la USE commande pour passer à la base de données contenue.

• Lorsque des bases de données confinées sont présentes, les utilisateurs de bases de données qui ne sont pas confinées 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 non confinée comme catalogue initial. Cela évite de se connecter à la base de données contenue, 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 l’isolement d’une base de données

Les connexions disposant 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 disposant de l’autorisation CONTROL DATABASE , telles que les membres du rôle de base de données fixe db_owner , peuvent modifier le paramètre d’isolement d’une base de données. Si le paramètre de confinement d'une base de données est modifié de NONE vers PARTIAL ou FULL, l'accès utilisateur peut être accordé en créant des utilisateurs de base de données contenus avec des mots de passe. Cela peut fournir un accès sans connaissance ni consentement des administrateurs SQL Server. Pour éviter que des bases de données ne soient contenues, définissez l'option Moteur de Base de Donnéescontained database authentication sur 0. Pour empêcher les connexions par des utilisateurs de base de données autonome avec des mots de passe sur des bases de données autonomes sélectionnées, utilisez des déclencheurs de connexion pour annuler les tentatives de connexion par les utilisateurs de base de données autonome avec des mots de passe.

Attachement d’une base de données contenue

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 préoccupé par ce risque peut mettre la base de données en ligne en RESTRICTED_USER mode, ce qui empêche l’authentification pour les utilisateurs de base de données autonome avec des 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 à l’aide des exigences de mot de passe en vigueur au moment où ils sont créés et que les mots de passe ne sont pas vé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 jointe.

Stratégies de mot de passe

Les mots de passe d’une base de données peuvent être requis pour être des mots de passe forts, mais ne peuvent pas être protégés par des stratégies de mot de passe robustes. Utilisez l’authentification Windows chaque fois que possible pour tirer parti des stratégies de mot de passe plus complètes disponibles à partir de Windows.

Authentification Kerberos

Les utilisateurs de base de données conteneurs avec des mots de passe ne peuvent pas utiliser l’authentification Kerberos. Si possible, utilisez l’authentification Windows pour tirer parti des fonctionnalités Windows telles que Kerberos.

Attaque de dictionnaire hors connexion

Les hachages de mot de passe pour les utilisateurs de la base de données contenue qui ont des mots de passe sont stockés dans la base de données contenue. Toute personne ayant accès aux fichiers de base de données peut effectuer une attaque par dictionnaire contre les utilisateurs de base de données autonome avec des mots de passe sur un système non vérifié. Pour atténuer cette menace, limitez l’accès aux fichiers de base de données ou autorisez uniquement les connexions aux bases de données autonomes à l’aide de l’authentification Windows.

Évasion d'une base de données confinée

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 les bases de données contenues pour qu'elles se ferment automatiquement. Si elle est fermée, l’ouverture de la base de données pour authentifier un utilisateur consomme des ressources supplémentaires et peut contribuer à une attaque par déni de service.

Voir aussi

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