À quoi sert le propriétaire de la base de données?
Aujourd'hui, lors du dépannage d'un problème de courtier de services, j'ai découvert que le propriétaire de la base de données était la connexion Windows d'un employé qui avait quitté l'entreprise. Son identifiant avait été supprimé et les notifications de requête échouaient donc.
Soi-disant la meilleure pratique pour résoudre ce problème est de faire de "sa" le propriétaire de la base de données. Nous l'avons changé et cela a vidé la file d'attente.
Ma question (très élémentaire): quel est le propriétaire de la base de données et quel est son objectif?
Il existe une certaine confusion entre les concepts de base de données de 'dbo' (un utilisateur) et 'db_owner' (un rôle fixe) d'un côté et le concept d'instance de 'propriétaire de base de données' de l'autre côté. Les 'dbo' et 'db_owner' sont souvent appelés 'propriétaire de la base de données'. Dans ce que vous demandez, vous parlez du propriétaire de la base de données en tant que principal du serveur propriétaire de la base de données.
La théorie est la suivante: tout ce qui peut recevoir des autorisations est un 'sécurisable' . Tous les objets sécurisables ont un propriétaire. Le propriétaire d'un élément sécurisable a un contrôle absolu sur l'élément sécurisable et ne peut se voir refuser aucun privilège. Les éléments sécurisables au niveau de l'instance appartiennent au serveur principaux (connexions). Les éléments sécurisables au niveau de la base de données appartiennent aux principaux de la base de données (utilisateurs). Le principal se présente sous deux formes: primaire (identité) et secondaire (appartenance). Les éléments sécurisables au niveau du serveur appartiennent par défaut au principal du serveur principal actuellement connecté. Les éléments sécurisables au niveau de la base de données appartiennent par défaut au principal de la base de données actuelle, à l'exception des objets liés au schéma qui, par défaut, appartiennent au propriétaire du schéma. Tous les éléments sécurisables prennent en charge la clause AUTHORIZATION au moment de la création pour appliquer un propriétaire différent. ALTER AUTHORIZATION peut être utilisé ultérieurement pour changer le propriétaire de tout élément sécurisable.
Étant donné que la base de données est un serveur sécurisable, il s'ensuit qu'elle appartiendra, par défaut, au principal qui a émis l'instruction CREATE DATABASE. C'est à dire. la connexion NT de l'employé décédé.
Votre question est donc vraiment " Pourquoi les sécurisables ont-ils besoin d'un propriétaire? ". Parce que le propriétaire est la racine de la confiance. C'est le propriétaire qui accorde, refuse et révoque l'autorisation sur l'objet. Un système de sécurité peut-il être conçu sans les propriétaires d'objets sécurisables? Probablement oui, mais il faudrait qu'un mécanisme soit en place pour remplacer le rôle que jouent les propriétaires dans le modèle actuel. Par exemple, considérez que les éléments sécurisables de papa n'ont pas de propriétaire (par exemple, au lieu de posséder un élément sécurisable, le créateur d'origine se voit simplement accorder le contrôle), il serait possible de créer un élément sécurisable et de révoquer l'accès à celui-ci tout le monde , y compris lui-même. L'exigence d'un propriétaire contourne ce problème car un propriétaire ne peut pas se verrouiller.
L'effet secondaire peu connu de CREATE DATABASE de créer un élément sécurisable (la base de données) appartenant à la connexion NT d'origine en a brûlé beaucoup auparavant. Les règles sont les mêmes pour tous les éléments sécurisables, mais certains facteurs aggravent les problèmes du propriétaire de la base de données:
- les autres éléments sécurisables au niveau du serveur (point final, rôle serveur, connexion) sont rarement utilisés, déplacés, etc.
- les éléments sécurisables au niveau de la base de données finissent généralement par appartenir à
dbo(le principal de la base de données) ou à un autre principal de la base de données, et donc le propriétaire est contenu dans la base de données - La propriété par défaut de la propriété de la base de données sur le principal NT crée un problème de confinement (le propriétaire est un SID NT géré par AD et ne voyage pas avec les fichiers de la base de données, le compte NT peut être étonné, etc., etc., etc.)
- la chose la plus importante: le propriétaire de la base de données a des effets secondaires importants, en particulier le
EXECUTE AS context. Ce problème ultérieur est ce qui brûle la plupart des utilisateurs. Étant donné que Service Broker utilise largement EXECUTE AS (la remise du message a un contexte EXECUTE AS implicite, ainsi qu'une activation de file d'attente qui en a un explicite), ce sont généralement les utilisateurs de Service Broker qui découvrent ce problème en premier.
BTW, bravo pour enquêter et résoudre votre problème d'origine :)
La base de données owner est un peu un retour en arrière à une époque antérieure à l'introduction des schémas (appropriés) dans SQL Sever 2005.
Fondamentalement, un propriétaire de base de données est le dbo (propriétaire de la base de données) par défaut de la base de données, la base de données elle-même étant un objet de base de données .
À partir des documents SQL Server 20 ...
dboest un utilisateur qui a des autorisations implicites pour effectuer toutes les activités dans la base de données.
Dans les versions antérieures de SQL Server, lorsqu'un schéma ne pouvait pas "posséder" un objet ( ou plutôt il devrait être indiqué que tous les objets, tables, vues, etc. appartenaient à dbo et il n'y avait pas d'autres schémas) il était nécessaire pour un "utilisateur" de le posséder ... cela devrait aller sans dire pourquoi quelque chose doit posséder la base de données (ou bien les autorisations dans général serait plutôt difficile.)
Donc, techniquement, dans les anciennes versions de SQL Server (ou des bases de données mises à niveau), ce n'était pas la table "Foo", c'était la table "dbo.Foo" ... avec le dbo comme propriétaire.
Avec l'avènement de SQL Server 2005, vous pourriez avoir des objets de base de données appartenant à un schéma, comme dire que vous avez un schéma nommé "bar" et une table nommée "Foo" ... cela devient bar.Foo un péché ...
SELECT * FROM bar.Foo WHERE etc = 'blah`;
La partie délicate vient du fait que l'utilisateur création la base de données est automatiquement définie comme le propriétaire ce qui conduit à problèmes avec le roulement des employés, etc.
Par conséquent, il est recommandé de modifier ce paramètre sur le compte sa, ou peut-être (selon mon expérience) sur un compte de domaine qui peut être administré par l'équipe ops/IT d'une organisation.
Cette article donne une ventilation de la différence entre l'ancienne façon de faire des "propriétaires" et le nouveau système de propriété basé sur un "schéma".
Pour comprendre la différence entre les propriétaires et le schéma, examinons la propriété des objets. Lorsqu'un objet est créé dans SQL Server 2000 ou version antérieure, l'objet doit avoir un propriétaire. La plupart du temps, le propriétaire est "dbo", également appelé propriétaire de la base de données.