Qual é o objetivo do 'proprietário' do banco de dados?

Hoje, enquanto solucionava um problema do corretor de serviços, descobri que o proprietário do banco de dados era o logon no Windows de um funcionário que havia deixado a empresa. Seu login foi removido e, portanto, as notificações de consulta estavam falhando.

Supostamente, a melhor prática para lidar com isso é tornar 'sa' o proprietário do banco de dados. Nós mudamos e isso limpou a fila.

Minha pergunta (muito elementar): qual é o proprietário do banco de dados e qual é o seu objetivo?

Existe alguma confusão entre os conceitos de banco de dados do 'dbo' (um usuário) e 'db_owner' (uma função fixa) de um lado e o conceito de instância de 'proprietário do banco de dados' do outro lado. O 'dbo' e 'db_owner' são freqüentemente chamados de 'proprietário do banco de dados'. No que você está perguntando, está falando sobre o proprietário do banco de dados como o principal do servidor que possui o banco de dados.

A teoria é a seguinte: tudo o que pode receber permissões é um 'protegível' . Todos os protegíveis têm um proprietário. O proprietário de um título passível de controle tem absoluto controle sobre o passível de proteção e não pode ser negado qualquer privilégio. Os itens protegíveis no nível da instância são de propriedade dos principais do servidor (logins). Os itens protegíveis no nível do banco de dados pertencem aos principais (usuários) do banco de dados. O diretor tem duas características: primário (identidade) e secundário (associação). Por padrão, os protegíveis no nível do servidor são de propriedade da entidade principal do servidor atualmente registrada. Os itens protegíveis no nível do banco de dados pertencem por padrão à entidade de banco de dados atual, exceto os objetos vinculados ao esquema que, por padrão, pertencem ao proprietário do esquema. Todos os protegíveis suportam a cláusula AUTHORIZATION no momento da criação para impor um proprietário diferente.ALTER AUTHORIZATION pode ser usado posteriormente para alterar o proprietário de qualquer produto protegível.

Como o banco de dados é protegível no nível do servidor, segue-se que, por padrão, ele será de propriedade do principal principal que emitiu a instrução CREATE DATABASE. Ou seja. o logon NT do funcionário que partiu.

Portanto, sua pergunta é realmente " Por que os produtos de segurança precisam de um proprietário? ". Porque o proprietário é a raiz da confiança. É o proprietário que concede, nega e revoga a permissão no objeto. Um sistema de segurança pode ser projetado sem proprietários de produtos protegíveis? Provavelmente sim, mas teria que haver algum mecanismo para substituir o papel que os proprietários desempenham no modelo atual. Por exemplo, considere que o pai que pode ser protegido por segurança não tem proprietário (por exemplo, em vez de possuir um seguro, o criador original recebe apenas CONTROLE sobre ele) seria possível criar um acesso seguro e revogá-lo para todos , inclusive para ele próprio. A exigência de um proprietário contorna esse problema, pois um proprietário não pode se bloquear.

O pouco conhecido efeito colateral de CREATE DATABASE de criar um protegível (o banco de dados) pertencente ao logon original do NT já havia queimado muitos antes. As regras são as mesmas para todos os protegíveis, mas alguns fatores agravam os problemas do proprietário do DATABASE:

• os outros dispositivos protegíveis no nível do servidor (terminal, função do servidor, logon) são muito raramente usados, movidos etc.
• os itens protegíveis no nível do banco de dados geralmente acabam pertencendo a dbo(principal do banco de dados) ou a algum outro principal do banco de dados e, portanto, o proprietário está contido no banco de dados
• Como a propriedade do banco de dados padrão como principal principal do NT cria um problema de contenção (o proprietário é um SID do NT gerenciado pelo AD e não viaja com os arquivos do banco de dados, a conta do NT pode ser pressionada, etc etc etc)
• a coisa mais importante: o proprietário do banco de dados tem efeitos colaterais importantes, especificamente o EXECUTE AS context. Esse problema posterior é o que queima a maioria dos usuários. Como o Service Broker faz uso extensivo do EXECUTE AS (a entrega da mensagem tem um contexto EXECUTE AS implícito, bem como a ativação da fila com um explícito), geralmente os usuários do Service Broker descobrem esse problema primeiro.

BTW, parabéns por investigar e corrigir seu problema original :)

O banco de dados owneré um pouco distante do tempo anterior à introdução dos esquemas (apropriados) no SQL Sever 2005.

Basicamente, um proprietário de banco de dados é o padrão dbo(proprietário do banco de dados) do banco de dados, com o próprio banco de dados sendo um objeto de banco de dados .

Dos documentos do SQL Server 2000 ...

O dboé um usuário que possui permissões implícitas para executar todas as atividades no banco de dados.

Nas versões anteriores do SQL Server, quando um esquema não podia "possuir" um objeto ( ou melhor, deveria ser declarado que todos os objetos, tabelas, exibições etc. eram de propriedade dboe não havia outros esquemas ), era necessário "usuário" para possuí-lo ... não é necessário dizer por que algo precisa possuir o banco de dados (ou então as permissões em geral seriam bastante difíceis).

Portanto, tecnicamente em versões mais antigas do SQL Server (ou bancos de dados atualizados), não era a tabela "Foo", era a tabela "dbo.Foo" ... dbosendo o proprietário.

Com o advento do SQL Server 2005, você poderia ter objetos de banco de dados pertencentes ao esquema, como digamos que você tenha um esquema chamado "bar" e uma tabela denominada "Foo" bar.Foo...

SELECT * FROM bar.Foo WHERE etc = 'blah`;

A parte complicada vem com o fato de que o usuário que cria o banco de dados é definido automaticamente como o proprietário, o que leva a problemas com a transferência de funcionários etc.

Portanto, é uma boa prática alterar isso para a saconta, ou talvez (na minha experiência) para uma conta de domínio que possa ser administrada pela equipe de operações / TI da organização.

Este artigo detalha a diferença entre a maneira mais antiga de "proprietário" de fazer as coisas e o novo sistema de propriedade baseado em "esquema".

Para entender a diferença entre proprietários e esquema, vamos passar algum tempo revisando a propriedade do objeto. Quando um objeto é criado no SQL Server 2000 ou anterior, o objeto deve ter um proprietário. Na maioria das vezes, o proprietário é "dbo", também conhecido como proprietário do banco de dados.