Основные принципы безопасности SQL Server Security - имя подключения (логины), пользователи и доверители

Основные принципы безопасности SQL Server Security - имя подключения (логины), пользователи и доверители

В этом посте я хотел бы поговорить о некоторых основных понятиях безопасности SQL Server. SQL Server имеет необычный дизайн, который может смутить пользователей, знакомых с функциями безопасности других программных продуктов, таких как ОС Microsoft Windows, в частности, разница между логинами и пользователями может запутать новых пользователей SQL Server.


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

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

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

Важное замечание: При описании поведения SQL Server, такие термины, как логин и пользователь не должно использоваться как синонимы - Логин это другая концепция, чем пользователь.

Пользователи, сопоставляются с логинами через их SID. Логин соответствует пользователю в базе данных , если их значения SID идентичны. Таким образом, у нас есть пользователи SQL и пользователи Windows; и последняя категория состоит из пользователей связанных с логинами  и связанных с группами логинов Windows . 

Давайте сделаем шаг назад и быстро повторим : логин обеспечивает доступ к серверу и может в дальнейшем получить доступ к базе данных; пользователь связанный с логином должен существовать в базе данных. Важно знать разницу между этими двумя понятиями логина и пользователя и не использовать эти термины как синонимы. 

Существование базы данных в качестве отдельной области позволяет отключить базу данных от экземпляра сервера и прикрепить к другому серверу SQL. Такая операция не проста, так как возможно, потребуется переназначить пользователей СУБД новым (логинам) именам входа в новом экземпляре. Это можно выполнить с помощью функции sp_change_users_login. Начиная с SQL Server 2005 SP2, такую операцию можно выполнить при помощи новой инструкции ALTER USERS.

Примечание: Пользователи, которые не отображаются в логинs в результате переезда базы данных известны как пользователи сироты. 

Another advantage is that databases as separate entities allow a better separation of distinct applications - applications can each be placed in their own database, making it harder to accidentally or maliciously access data under the control of another application.
This separation has an impact on the authorization model of SQL Server as well, as it may be expected. Permissions can be granted at both scopes: server and database. Permissions granted at server scope take effect regardless of what is the current database, but permissions granted at database scope are used only while working in that database. Server level permissions are the permissions that are assignable to logins, and database level permissions are the permissions assignable to users. To help with the management of permissions, some other entities than the logins and users we discussed so far can be used as the grantees of a permission. Collectively, in SQL Server, the entities that can be granted a permission are referred to as principals. Principals are separated into server principals and database principals according to their scope.

Еще одним преимуществом является то, что базы данных как отдельные объекты позволяютлучше разделение различных приложений - приложений каждый из них может быть размещен в собственной базе данных , что делает его труднее случайно или злонамеренно доступ к данным под контролем другого приложения . 

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

Important Note: While the logins discussed so far grant access to the server and thus are having a role in the authentication process, the other server principals are only used for permission management and do not help with server authentication.
Examples of server principals besides the logins discussed previously are server roles and logins mapped to certificate or asymmetric keys. Examples of database principals are database roles (fixed and flexible), application roles, users mapped to certificate or asymmetric keys, and loginless users. All of these help with the assignment of the permissions. Loginless users (created using CREATE USER ... WITHOUT LOGIN) are a special case because they can be impersonated (application roles are similar, but terminology differs - approles are set, while loginless users are impersonated).
The last concept I want to discuss here is that of execution context. The execution context is how SQL Server keeps track of who you are. As it may be expected already, the execution context is formed of a server execution context and a database execution context - these are referred to as login token and user token. The login-user token pair determines who you are in the eyes of the system. The context is initially determined upon login and changes when you switch to a different database or when an impersonation takes place. For more information on the execution context and on impersonation mechanisms, which are topics that extend well beyond the scope of this post, you can have a look at my presentation from http://cmcgc.com/Media/WMP/261115/ and its relevant demo.

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

 Примеры серверах-участниках , кроме логинов обсуждаемых ранее являются серверные роли и логины , отображенные на сертификат или асимметричными ключами . Примеры руководителей баз данных являются роли базы данных (фиксированные и гибкие ), роли приложений , пользователи , отображенные на сертификат или асимметричными ключами и пользователей loginless . Все это поможет с присвоением разрешений . Пользователи Loginless ( создана при помощи CREATE USER ... без входа ) представляют собой особый случай, потому что они могут быть олицетворением ( роли приложений похожи, но терминология отличается - approles установлены, в то время как loginless пользователи олицетворение ) .Последнее понятие, которое я хочу обсудить здесь является то, что из контекста выполнения . Контекст выполнения , как SQL Server отслеживает , кто вы есть . Как можно ожидать, уже , контекст выполнения сформирован из контекста выполнения сервера и контекста выполнения базы данных - они называют Войти маркера и пользователя маркера. Маркер пара Войти пользователь определяет , кто вы в глазах системы . Контекст изначально определяется при входе и изменений при переключении на другую базу данных или когдаолицетворение происходит . Для получения дополнительной информации о контексте выполнения и о механизмах олицетворения , которые темы , которые простираются далеко за рамки этого поста , вы можете взглянуть на моего выступления от http://cmcgc.com/Media/WMP/261115/ и его отношение демо .