Partager via

Utilisateurs de base de données autonome - Rendre votre base de données portable

Utilisez des utilisateurs de base de données autonome pour authentifier les connexions SQL Server et SQL Database au niveau de la base de données. Une base de données autonome est une base de données isolée d’autres bases de données et de l’instance de SQL Server/SQL Database (et de la base de données master) qui héberge la base de données. SQL Server prend en charge les utilisateurs de bases de données contenues, à la fois pour l’authentification Windows et SQL Server. Lorsque vous utilisez SQL Database, combinez des utilisateurs de base de données autonome avec des règles de pare-feu au niveau de la base de données. Cette rubrique examine les différences et les avantages de l’utilisation du modèle de base de données autonome par rapport aux règles de pare-feu traditionnelles de connexion/utilisateur et Windows ou au niveau du serveur. Des scénarios spécifiques, une facilité de gestion ou une logique métier d’application peuvent encore nécessiter l’utilisation de règles de pare-feu traditionnelles de connexion/utilisateur et de pare-feu au niveau du serveur.

Remarque

À mesure que Microsoft évolue le service SQL Database et passe à des contrats SLA garantis plus élevés, vous devrez peut-être basculer vers le modèle utilisateur de base de données autonome et les règles de pare-feu dans l’étendue de la base de données afin d’atteindre le contrat SLA de disponibilité plus élevé et les taux de connexion maximal plus élevés pour une base de données donnée. Microsoft vous encourage à envisager de telles modifications aujourd’hui.

Connexion traditionnelle et modèle utilisateur

Dans le modèle de connexion traditionnel, les utilisateurs Windows ou les membres des groupes Windows se connectent au moteur de base de données en fournissant des informations d’identification d’utilisateur ou de groupe authentifiées par Windows. Ou la connexion fournit à la fois un nom et un mot de passe et se connecte à l’aide de l’authentification SQL Server (qui est la seule option lors de la connexion à SQL Database). Dans les deux cas, la base de données principale doit avoir un identifiant qui correspond aux informations d’identification de connexion. Une fois que le moteur de base de données confirme les informations d’identification d’authentification Windows ou authentifie les informations d’identification d’authentification SQL Server, la connexion tente généralement de se connecter à une base de données utilisateur. Pour vous connecter à une base de données utilisateur, la connexion doit être mappée à (c’est-à-dire associée) à un utilisateur de base de données dans la base de données utilisateur. La chaîne de connexion peut également spécifier la connexion à une base de données spécifique facultative dans SQL Server, mais requise dans SQL Database.

Le principal important est que la connexion (dans la base de données master) et l’utilisateur (dans la base de données utilisateur) doivent exister et être liées les unes aux autres. Cela signifie que la connexion à la base de données utilisateur dépend de l'identifiant dans la base de données master, ce qui limite la capacité de la base de données à être déplacée vers un autre serveur SQL Server ou un serveur Azure SQL Database. Et si, pour une raison quelconque, une connexion à la base de données master n’est pas disponible (par exemple, un basculement est en cours), l’heure de connexion globale est augmentée ou la connexion peut expirer. Par conséquent, cela peut réduire la scalabilité des connexions.

Modèle utilisateur de base de données autonome

Dans le modèle utilisateur de base de données autonome, la connexion dans la base de données master n’est pas présente. Au lieu de cela, le processus d'authentification se produit sur la base de données utilisateur, et l'utilisateur de base de données de la base de données utilisateur n'a pas de connexion associée dans la base de données MASTER. Le modèle utilisateur de base de données autonome prend en charge l’authentification Windows (dans SQL Server) et l’authentification SQL Server (dans SQL Server et SQL Database). Pour se connecter en tant qu’utilisateur de base de données autonome, la chaîne de connexion doit toujours contenir un paramètre pour la base de données utilisateur afin que le moteur de base de données sache quelle base de données est responsable de la gestion du processus d’authentification. L’activité de l’utilisateur de base de données autonome est limitée à la base de données d’authentification. Par conséquent, lors de la connexion en tant qu’utilisateur de base de données autonome, le compte d’utilisateur de base de données doit être créé indépendamment dans chaque base de données dont l’utilisateur aura besoin. Pour modifier les bases de données, les utilisateurs sql Database doivent créer une connexion. Les utilisateurs de base de données autonome dans SQL Server peuvent modifier les bases de données si un utilisateur identique est présent dans une autre base de données.

Pour SQL Database, aucune modification n’est requise pour la chaîne de connexion lors du passage du modèle traditionnel au modèle utilisateur de base de données autonome. Pour les connexions SQL Server, le nom de la base de données doit être ajouté à la chaîne de connexion, s’il n’est pas déjà présent.

Important

Lorsque vous utilisez le modèle traditionnel, les rôles au niveau du serveur et les autorisations au niveau du serveur peuvent limiter l’accès à toutes les bases de données. Lorsque vous utilisez le modèle de base de données autonome, les propriétaires de base de données et les utilisateurs de base de données disposant de l’autorisation ALTER ANY USER peuvent accorder l’accès à la base de données. Cela réduit le contrôle d’accès des connexions de serveur à privilèges élevés et étend le contrôle d’accès pour inclure des utilisateurs de base de données à privilèges élevés.

Pare-feux

SQL Server

Les règles de pare-feu Windows s’appliquent à toutes les connexions et ont les mêmes effets sur les connexions par identification (modèle traditionnel) et les utilisateurs de bases de données contenues. Pour plus d’informations sur le pare-feu Windows, consultez Configurer un pare-feu Windows pour l’accès au moteur de base de données.

Pare-feux de bases de données SQL

SQL Database autorise des règles de pare-feu distinctes pour les connexions au niveau du serveur (connexions) et pour les connexions au niveau de la base de données (utilisateurs de base de données autonome). Lors de la connexion à une base de données utilisateur, les premières règles de pare-feu de base de données sont vérifiées. S’il n’existe aucune règle qui autorise l’accès à la base de données, les règles de pare-feu au niveau du serveur sont vérifiées, ce qui nécessite l’accès à la base de données maître du serveur logique. Les règles de pare-feu au niveau de la base de données combinées avec des utilisateurs de base de données autonome peuvent éliminer la nécessité d’accéder à la base de données maître du serveur pendant la connexion, ce qui améliore l’extensibilité des connexions.

Pour plus d’informations sur les règles de pare-feu SQL Database, consultez les rubriques suivantes :

Différences de syntaxe

Modèle traditionnel Modèle utilisateur de base de données autonome
Quand vous êtes connecté à la base de données master :

CREATE LOGIN login_name WITH PASSWORD = 'strong_password';

Ensuite, quand vous êtes connecté à une base de données utilisateur :

CREATE USER 'user_name' FOR LOGIN 'login_name';		 Quand vous êtes connecté à une base de données utilisateur :

CREATE USER user_name WITH PASSWORD = 'strong_password';
Modèle traditionnel Modèle utilisateur de base de données autonome
Pour modifier le mot de passe, dans le contexte de la base de données master :

ALTER LOGIN login_name WITH PASSWORD = 'strong_password';		 Pour modifier le mot de passe, dans le contexte de la base de données utilisateur :

ALTER USER user_name WITH PASSWORD = 'strong_password';

Remarques

  • Dans SQL Server, les utilisateurs de base de données contenue doivent être activés pour l'instance de SQL Server. Pour plus d’informations, consultez l’option de configuration de l’authentification de base de données contenue.

  • Les utilisateurs de base de données autonomes et les connexions avec des noms qui ne se chevauchent pas peuvent coexister dans vos applications.

  • S'il existe un identifiant dans la base de données master avec le nom name1 et que vous créez un utilisateur de base de données contenu nommé name1, lorsqu'un nom de base de données est fourni dans la chaîne de connexion, le contexte de l'utilisateur de la base de données sera privilégié par rapport au contexte de l'identifiant lors de la connexion à la base de données. Autrement dit, l'utilisateur de base de données contenu prendra le pas sur les connexions portant le même nom.

  • Dans SQL Database, le nom de l’utilisateur de base de données autonome ne peut pas être identique au nom du compte d’administrateur de serveur.

  • Le compte d’administrateur du serveur SQL Database ne peut jamais être un utilisateur de base de données autonome. L’administrateur du serveur dispose des autorisations suffisantes pour créer et gérer des utilisateurs de base de données autonome. L’administrateur du serveur peut accorder des autorisations aux utilisateurs de base de données contenue sur les bases de données utilisateur.

  • Étant donné que les utilisateurs de base de données contenus sont des principaux de la base de données, vous devez créer des utilisateurs de base de données contenus dans chaque base de données que vous utilisez. L’identité est limitée à la base de données et est indépendante de tous les aspects d’un utilisateur portant le même nom et le même mot de passe dans une autre base de données sur le même serveur.

  • Utilisez les mêmes mots de passe de force que ceux que vous utiliseriez normalement pour les connexions.

Voir aussi

Bases de données autonomes
Meilleures pratiques de sécurité recommandées avec les bases de données autonomes
CRÉER UN UTILISATEUR (Transact-SQL)

  • Last updated on