Qual è lo scopo del "proprietario" del database?

Oggi, durante la risoluzione dei problemi di un broker di servizi, ho scoperto che il proprietario del database era il login di Windows di un dipendente che aveva lasciato l'azienda. Il suo login era stato rimosso e quindi le notifiche delle query non andavano a buon fine.

Presumibilmente la migliore pratica per affrontare questo è rendere "sa" il proprietario del database. L'abbiamo cambiato e questo ha cancellato la coda.

La mia (molto elementare) domanda: qual è il proprietario del database e qual è il suo scopo?

Esiste una certa confusione tra i concetti del database di "dbo" (un utente) e "db_owner" (un ruolo fisso) da un lato e il concetto di istanza di "proprietario del database" dall'altro. "Dbo" e "db_owner" sono spesso chiamati "proprietario del database". In quello che stai chiedendo, stai parlando del proprietario del database come principale del server proprietario del database.

La teoria va così: tutto ciò a cui possono essere concesse autorizzazioni è un "sicuro" . Tutti i valori mobiliari hanno un proprietario. Il proprietario di un sistema di sicurezza ha il controllo assoluto sul valore di sicurezza e non può essere negato alcun privilegio. I titoli a livello di istanza sono di proprietà dei principali server (accessi). I titoli a livello di database sono di proprietà dei principali database (utenti). Il principale si presenta in due modi: primario (identità) e secondario (appartenenza). I titoli a livello di server sono per impostazione predefinita di proprietà dell'entità server principale attualmente registrata. I titoli a livello di database sono di proprietà per impostazione predefinita dall'entità database corrente, ad eccezione degli oggetti associati allo schema che per impostazione predefinita sono di proprietà del proprietario dello schema. Tutti i valori mobiliari supportano la clausola AUTORIZZAZIONE al momento della creazione per imporre un proprietario diverso.ALTER AUTHORIZATION può essere successivamente utilizzato per modificare il proprietario di qualsiasi elemento sicuro.

Poiché il database è un server a livello di sicurezza, ne consegue che sarà, per impostazione predefinita, di proprietà dell'entità principale che ha emesso l'istruzione CREATE DATABASE. Vale a dire. il login NT dell'impiegato defunto.

Quindi la tua domanda è davvero " Perché i titoli di sicurezza hanno bisogno di un proprietario? ". Perché il proprietario è la radice della fiducia. È il proprietario che concede, nega e revoca l'autorizzazione sull'oggetto. È possibile progettare un sistema di sicurezza senza i proprietari di valori mobiliari? Probabilmente sì, ma dovrebbe esserci un meccanismo in atto per sostituire il ruolo dei proprietari nel modello attuale. Ad esempio, considera che i paparabili non hanno alcun proprietario (es. Invece di possedere un sicurabile, al creatore originale è stato concesso il CONTROLLO su di esso) sarebbe possibile creare un sicuro e revocare l'accesso ad esso a tutti , incluso se stesso. Il requisito di un proprietario elude questo problema poiché un proprietario non può bloccarsi.

L'effetto collaterale poco noto di CREATE DATABASE della creazione di un sicuro (il database) di proprietà dell'accesso NT originale è già stato bruciato in passato. Le regole sono le stesse per tutti i titoli, ma alcuni fattori aggravano i problemi del proprietario di DATABASE:

• gli altri dispositivi di sicurezza a livello di server (endpoint, ruolo del server, accesso) sono raramente utilizzati, spostati, ecc.
• i titoli a livello di database di solito finiscono per essere di proprietà del dbo(principale del database), o di qualche altro principale del database, e quindi il proprietario è contenuto nel database
• Avere la proprietà del database predefinita sull'entità primaria NT crea un problema di contenimento (il proprietario è un SID NT gestito da AD e non viaggia con i file del database, l'account NT può essere puntato sul pollice ecc. Ecc. Ecc.)
• la cosa più importante: il proprietario del database ha effetti collaterali importanti, in particolare il EXECUTE AS context. Questo problema successivo è ciò che brucia la maggior parte degli utenti. Poiché Service Broker fa ampio uso di EXECUTE AS (il recapito dei messaggi ha un contesto EXECUTE AS implicito, così come l'attivazione della coda che ne ha uno esplicito) sono in genere gli utenti di Service Broker che scoprono prima questo problema.

A proposito, complimenti per indagare e risolvere il problema originale :)

Il database ownerè un po 'indietro nel tempo prima che gli schemi (corretti) fossero introdotti in SQL Sever 2005.

Fondamentalmente un proprietario del database è il predefinito dbo(proprietario del database) del database, con il database stesso come oggetto del database .

Dai documenti di SQL Server 2000 ...

L' dboè un utente che ha implicato autorizzazioni per svolgere tutte le attività nel database.

Nelle versioni precedenti di SQL Server, quando uno schema non poteva "possedere" un oggetto ( o piuttosto si dovrebbe affermare che tutti gli oggetti, le tabelle, le viste, ecc. Erano di proprietà dboe non c'erano altri schemi ) era necessario per un "utente" per possederlo ... dovrebbe essere ovvio il motivo per cui qualcosa deve possedere il database (altrimenti le autorizzazioni in generale sarebbero piuttosto difficili).

Quindi, tecnicamente nelle versioni precedenti di SQL Server (o database aggiornati) non era la tabella "Foo", era la tabella "dbo.Foo" ... con l' dboessere il proprietario.

Con l'avvento di SQL Server 2005 potresti avere oggetti di database di proprietà dello schema come dire che hai uno schema chiamato "bar" e una tabella denominata "Foo" ... questo diventa bar.Foocome in ...

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

La parte difficile deriva dal fatto che l'utente che crea il database viene automaticamente impostato come proprietario, il che porta a problemi con la rotazione dei dipendenti, ecc.

Pertanto, è consigliabile modificare questo sanell'account o (in base alla mia esperienza) in un account di dominio che può essere gestito dal team operativo / IT di un'organizzazione.

Questo articolo fornisce una suddivisione della differenza tra il vecchio modo di "proprietario" di fare le cose e il più recente sistema di proprietà basato su "schema".

Per capire la differenza tra proprietari e schema, passiamo un po 'di tempo a rivedere la proprietà degli oggetti. Quando un oggetto viene creato in SQL Server 2000 o precedente, l'oggetto deve avere un proprietario. Il più delle volte, il proprietario è "dbo", noto anche come proprietario del database.