Вы когда-нибудь сталкивались с неожиданными объектами базы данных или принципалами в экземплярах SQL Server? Это может быть довольно загадочным, особенно если вы следуете bewt практикам и используете группы Active Directory (AD) для управления доступом. В этом блоге мы рассмотрим, почему происходят эти неожиданные события и как SQL Server с ними обращается.

Давайте начнем с сценария. Представьте, что вы импортируете данные о продажах в свою базу данных. В рамках процесса вам необходимо получить SalesPersonId для каждой продажи. Однако вы сталкиваетесь с новым продавцом, который не указан в вашей таблице SalesPeople. Чтобы справиться с этим, вы создаете дополнительный путь в своем процессе, который загружает отсутствующих продавцов перед продолжением импорта данных. Это похоже на то, что происходит, когда в SQL Server появляются неожиданные объекты базы данных или принципалы.

Недавно один из моих коллег столкнулся с ситуацией, когда его сетевой идентификатор появился в качестве логина на одном из наших экземпляров SQL Server. Это было удивительно, потому что мы обычно используем группы AD для контроля доступа. При расследовании выяснилось, что ряд команд, включая создание серверной роли, привели к этому неожиданному результату.

Когда вы создаете серверную роль (или другие объекты базы данных, такие как таблицы или аудиты) без указания существующего принципала для его владения, SQL Server должен создать новый. В случае серверной роли создается серверный принципал (логин). Это похоже на то, как вы создаете новую запись о продавце при импорте данных о продажах.

Теперь вы можете задаться вопросом, почему SQL Server не использует автоматически группу AD вместо создания нового серверного принципала. Ответ кроется в сложности управления несколькими группами AD. Допустим, вы являетесь членом нескольких групп AD, и каждая группа имеет разные разрешения на экземпляр SQL Server. Если SQL Server автоматически выберет группу AD, он может выбрать неправильную, предоставляя доступ нежелательным пользователям. Поэтому SQL Server требует явных инструкций, чтобы гарантировать назначение правильного принципала.

Например, если вы указываете группу AD при создании серверной роли, вот так:

CREATE SERVER ROLE [ThisIsAServerRole] AUTHORIZATION [MyADGroup];

Новый серверный принципал не будет создан, потому что SQL Server знает, какому принципалу его назначить. Однако, если вы опустите авторизацию, SQL Server создаст новый серверный принципал.

Важно отметить, что SQL Server обрабатывает метаданные (такие как объекты базы данных и принципалы) так же, как если бы они были данными. Он обращается с ними бережно, чтобы обеспечить безопасность и целостность вашего экземпляра SQL Server.

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

Спасибо за чтение! Следите за новыми советами и идеями по SQL Server.