Какова цель базы данных «владелец»?

Сегодня, устраняя проблему с сервисным брокером, я обнаружил, что владельцем базы данных был логин Windows сотрудника, покинувшего компанию. Его логин был удален, и поэтому уведомления о запросах не выполнялись.

Предположительно, лучшая практика для решения этой проблемы - сделать 'sa' владельцем базы данных. Мы изменили это, и это очистило очередь.

Мой (очень элементарный) вопрос: кто является владельцем базы данных и какова ее цель?

Существует некоторая путаница между понятиями базы данных «dbo» (пользователь) и «db_owner» (фиксированная роль) с одной стороны и концепцией экземпляра «владелец базы данных» с другой стороны. 'Dbo' и 'db_owner' часто называют 'владельцем базы данных'. В том, что вы спрашиваете, вы говорите о владельце базы данных как о главном сервере, который владеет базой данных.

Теория выглядит следующим образом: все, на что могут быть предоставлены разрешения, является «защищенным» . У всех подделок есть владелец. Владелец защищаемого объекта имеет абсолютный контроль над защищаемым объектом и не может быть лишен каких-либо привилегий. Защищаемые элементы уровня экземпляра принадлежат принципалам сервера (логинам). Защищаемые элементы уровня базы данных принадлежат принципалам базы данных (пользователям). Основные приходят в двух вариантах: основной (личность) и дополнительный (членство). Защищаемые элементы уровня сервера по умолчанию принадлежат зарегистрированному в настоящее время основному основному серверу. Защищаемые элементы уровня базы данных по умолчанию принадлежат текущему участнику базы данных, за исключением объектов, связанных со схемой, которые по умолчанию принадлежат владельцу схемы. Все защищаемые элементы поддерживают предложение AUTHORIZATION во время создания, чтобы обеспечить другого владельца.ALTER AUTHORIZATION Позже может быть использован для смены владельца любого защищаемого.

Поскольку база данных является защищаемой на уровне сервера, из этого следует, что по умолчанию она будет принадлежать первичному принципалу, который выполнил инструкцию CREATE DATABASE. То есть. логин NT ушедшего сотрудника.

Таким образом, ваш вопрос на самом деле « Зачем предметам безопасности владелец? ». Потому что владелец является корнем доверия. Это владелец, который предоставляет, отрицает и отзывает разрешение на объект. Можно ли спроектировать систему безопасности без владельцев защищаемых предметов? Вероятно, да, но должен был бы быть какой-то механизм, чтобы заменить роль владельцев в текущей модели. Например, учтите, что у папируемых охраняемых предметов нет владельца (например, вместо того, чтобы владеть защищаемым, первоначальному создателю предоставляется только КОНТРОЛЬ над ним), можно было бы создать защищаемое и отозвать доступ к нему для всех , включая его самого. Требование владельца обходит эту проблему, поскольку владелец не может заблокировать себя.

Малоизвестный побочный эффект CREATE DATABASE создания защищаемой (базы данных), принадлежащей исходному логину NT, сгорел много раньше. Правила одинаковы для всех защищаемых, но некоторые факторы усугубляют проблемы владельца базы данных:

• другие защищаемые элементы уровня сервера (конечная точка, роль сервера, вход в систему) используются крайне редко, перемещаются и т. д.
• Защищаемые элементы уровня базы данных обычно в конечном итоге принадлежат dbo(субъекту базы данных) или некоторому другому субъекту базы данных, и, следовательно, владелец содержится в базе данных.
• Если в качестве владельца базы данных по умолчанию используется основной субъект NT, возникает проблема локализации (владельцем является SID NT, управляемый AD, и он не перемещается с файлами базы данных, учетная запись NT может быть просмотрена и т. Д. И т. Д. И т. Д.)
• самое главное: владелец базы данных имеет важные побочные эффекты, в частности EXECUTE AS context. Эта более поздняя проблема - то, что сжигает большинство пользователей. Поскольку компонент Service Broker широко использует EXECUTE AS (доставка сообщения имеет неявный контекст EXECUTE AS, а также активацию очереди, которая имеет явный контекст), обычно пользователи Service Broker сначала обнаруживают эту проблему.

Кстати, слава за расследование и исправление вашей первоначальной проблемы :)

База данных owner- это немного назад, до того, как (SQL) схемы были введены в SQL Sever 2005.

По сути, владельцем базы данных является владелец базы данных по умолчанию dbo(владелец базы данных), а сама база данных является объектом базы данных .

Из документов SQL Server 2000 ...

Это dboпользователь, у которого есть разрешения на выполнение всех действий в базе данных.

В более ранних версиях SQL Server, когда схема не могла «владеть» объектом ( точнее, следует указать, что все объекты, таблицы, представления и т. Д. Принадлежали, dboа других схем не было), это было необходимо для «пользователь» должен владеть им… само собой разумеется, почему кому- то нужно владеть базой данных (иначе разрешения вообще будут довольно трудными).

Таким образом, технически в более старых версиях SQL Server (или обновленных базах данных) это была не таблица «Foo», а таблица «dbo.Foo» ... с dboвладельцем.

С появлением SQL Server 2005 у вас могут быть объекты базы данных, принадлежащие схеме, например, у вас есть схема с именем "bar" и таблица с именем "Foo" ... это становится bar.Fooкак в ...

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

Сложность заключается в том, что пользователь, создающий базу данных, автоматически назначается владельцем, что приводит к проблемам с текучестью кадров и т. Д.

Поэтому рекомендуется либо изменить это значение на saучетную запись, либо, по моему опыту, на учетную запись домена, которой может управлять команда ops / IT организации.

В этой статье дается различие между старым способом «хозяина» и более новой системой владения «схемой».

Чтобы понять разницу между владельцами и схемой, давайте потратим некоторое время на рассмотрение владения объектом. Когда объект создается в SQL Server 2000 или более ранней версии, он должен иметь владельца. В большинстве случаев владельцем является «dbo», также известный как владелец базы данных.