Différence entre un utilisateur et une connexion dans SQL Server

185

J'ai récemment rencontré de nombreux domaines différents de SQL Server avec lesquels je ne me dérange pas normalement. L'un d'eux qui m'a confondu est le domaine des connexions et des utilisateurs. On dirait que ça devrait être un sujet assez simple ...

Il semble que chaque connexion ne peut avoir qu'un seul utilisateur et que chaque utilisateur ne peut avoir qu'une seule connexion.

Un login peut être associé à plusieurs tables associant ainsi cet utilisateur à de nombreuses tables.

Ma question est donc pourquoi même avoir un identifiant et un utilisateur? ils semblent être à peu près identiques. Quelles sont les différences, ou qu'est-ce qui semble me manquer?

sql  sql-server  sql-server-2005 
— corymathews
source

Réponses:

210

Un "Login" accorde l'entrée principale dans le SERVEUR.

Un «utilisateur» accorde une entrée de connexion dans une seule BASE DE DONNÉES.

Un "Login" peut être associé à plusieurs utilisateurs (un par base de données).

Chacun des objets ci-dessus peut avoir des autorisations qui lui sont accordées à son propre niveau. Consultez les articles suivants pour une explication de chaque

— Scott Ivey
source
8
Ah pas étonnant que je n'ai pas pu trouver de différence. Je travaillais simplement avec 1 base de données. Merci.
— corymathews
3
Cette réponse est fondamentalement correcte, mais si je comprends bien, un utilisateur particulier peut en fait se voir accorder l'accès à plus d'une base de données disponible sur ce serveur particulier. Ainsi, la connexion à l'utilisateur est un mappage 1 à 1, mais l'utilisateur à la base de données est un mappage 1 à plusieurs.
— andrew pate
1
@coreymathews: Moins de temps dans "Boy Meets World" et plus de temps sur les livres! ;).
— MSIS
Mais maintenant, MSDN recommande un type d'utilisateur «Utilisateurs qui s'authentifient dans la base de données» (recommandé pour rendre votre base de données plus portable). Lien: docs.microsoft.com/en-us/sql/t-sql/statements/… Est-ce mieux que le type d'utilisateur traditionnel?
— Sheen le
32

L'une des raisons d'avoir les deux est que l'authentification peut être effectuée par le serveur de base de données, mais l'autorisation peut être étendue à la base de données. De cette façon, si vous déplacez votre base de données vers un autre serveur, vous pouvez toujours remapper la relation utilisateur-connexion sur le serveur de base de données, mais votre base de données n'a pas à changer.

— Tom Resing
source
Pouvez-vous s'il vous plaît élaborer? Quel est l'avantage du changement effectué sur le serveur de base de données plutôt que sur la base de données?
— OfirD
Supposons que vous souhaitiez sauvegarder et restaurer une base de données. La restauration est souvent effectuée sur un nouveau serveur. Il se peut que vous ne souhaitiez pas avoir à apporter des modifications à une base de données lors d'une restauration.
— Tom Resing
Pourquoi ne pas simplement faire le changement une fois la base de données restaurée?
— OfirD
1
Il y a une bonne vidéo de 60 secondes sur le sujet à SQLAuthority pour plus d'informations blog.sqlauthority.com/2014/07/16
— Tom Resing
1
@HeyJude Signifiant que le serveur est concerné par l'authentification, ce que la base de données devrait faire si ce n'est pour la connexion et la séparation des utilisateurs.
— Zaid Khan
25

Je pense qu'il y a un très bon article de blog MSDN sur ce sujet par Laurentiu Cristofor:

La première chose importante à comprendre à propos de la sécurité de SQL Server est que deux domaines de sécurité sont impliqués: le serveur et la base de données. Le domaine du serveur englobe plusieurs domaines de base de données. Tout le travail est effectué dans le contexte d'une base de données, mais pour arriver à faire le travail, il faut d'abord avoir accès au serveur, puis avoir accès à la base de données.

L'accès au serveur est accordé via les connexions. Il existe deux catégories principales de connexions: les connexions authentifiées SQL Server et les connexions authentifiées Windows. Je ferai généralement référence à ceux-ci en utilisant les noms plus courts des connexions SQL et Windows. Les connexions authentifiées Windows peuvent être soit des connexions mappées à des utilisateurs Windows, soit des connexions mappées à des groupes Windows. Ainsi, pour pouvoir se connecter au serveur, il faut avoir accès via l'un de ces types ou connexions - les connexions donnent accès au domaine du serveur.

Mais les connexions ne suffisent pas, car le travail est généralement effectué dans une base de données et les bases de données sont des domaines distincts. L'accès aux bases de données est accordé via les utilisateurs.

Les utilisateurs sont mappés aux connexions et le mappage est exprimé par la propriété SID des connexions et des utilisateurs. Une connexion est mappée à un utilisateur dans une base de données si leurs valeurs SID sont identiques. Selon le type de connexion, nous pouvons donc avoir une catégorisation des utilisateurs qui imite la catégorisation ci-dessus pour les connexions; Ainsi, nous avons des utilisateurs SQL et des utilisateurs Windows et cette dernière catégorie se compose d'utilisateurs mappés aux connexions utilisateur Windows et d'utilisateurs mappés aux connexions de groupe Windows.

Prenons un peu de recul pour un aperçu rapide: un login permet d'accéder au serveur et pour avoir davantage accès à une base de données, un utilisateur mappé sur le login doit exister dans la base de données.

c'est le lien vers l'article complet.

— David Leitner
source
1
Ce billet de blog a été supprimé :(
— Steven Schlansker
23

En bref,

Les connexions auront accès au serveur.

et

Les utilisateurs auront accès à la base de données.

— Vikrant Kedari
source
6

Je pense que c'est une question très utile avec une bonne réponse. Juste pour ajouter mes deux cents du MSDN Créer une page de connexion :

Une connexion est un principal de sécurité ou une entité qui peut être authentifiée par un système sécurisé. Les utilisateurs ont besoin d'une connexion pour se connecter à SQL Server. Vous pouvez créer une connexion basée sur un principal Windows (tel qu'un utilisateur de domaine ou un groupe de domaines Windows) ou vous pouvez créer une connexion qui n'est pas basée sur un principal Windows (comme une connexion SQL Server).

Remarque:
pour utiliser l'authentification SQL Server, le moteur de base de données doit utiliser l'authentification en mode mixte. Pour plus d'informations, consultez Choisir un mode d'authentification.

En tant que principal de sécurité, des autorisations peuvent être accordées aux connexions. La portée d'une connexion est l'ensemble du moteur de base de données. Pour vous connecter à une base de données spécifique sur l'instance de SQL Server, une connexion doit être mappée à un utilisateur de base de données. Les autorisations à l'intérieur de la base de données sont accordées et refusées à l'utilisateur de la base de données, pas à la connexion. Les autorisations qui ont la portée de toute l'instance de SQL Server (par exemple, l'autorisation CREATE ENDPOINT) peuvent être accordées à une connexion.

— ilmatte
source
3
C'est un peu plus clair si vous mettez un >au début de chaque paragraphe dans la citation pour qu'elle soit formatée comme une citation.
— Sam
2
C'était tellement utile. Bien que j'aie configuré correctement les utilisateurs et les connexions, le système n'a pas été configuré pour autoriser l'authentification de connexion SQL Server. Pourquoi je pourrais créer des connexions SQL Server lorsque le serveur ne leur permet pas de se connecter me dépasse!
— Mark Ireland
J'étais également perplexe. si le serveur n'est actuellement pas en mode mixte, je me serais attendu à ce que le serveur lève simplement une erreur en essayant de créer une connexion SQL Auth, cela donnerait au moins à l'utilisateur un indice indiquant qu'il devrait d'abord activer l'authentification en mode mixte.
— arunsun
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.