Если при установке SQL Server использовали смешанный режим проверки подлинности, программа установки позволяет назвать имя входа SQL Server «sa». Важно создать сложный пароль для этого имени входа, поскольку он имеет права администратора на уровне сервера баз данных. Если при установке SQL Server использовали режим проверки подлинности Windows, то изменение его на смешанный режим аутентификации не позволит имя «sa» использовать как логин SQL Server.

Участники уровня базы данных.

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

Чтобы логин имел доступ к базам данных, надо сопоставить имя входа (login) и пользователя базы данных (database user) в базе данных. Можно добавить пользователей базы данных к роли уровня базы данных (database-level roles) для упрощения управления разрешениями.

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

Наилучшим способом считается сопоставление имен входа именам пользователей базы данных.

Существует одно исключение из этого правила: если база данных была настроена в качестве автономной базы данных. Автономные БД изолированы от других баз данных и от экземпляра SQL Server, на котором они размещены. Полностью автономная база данных содержит все параметры и метаданные, необходимые для определения базы данных, а ее конфигурация не зависит от Database Engine. Поэтому пользователи автономной базы данных не сопоставляются с именами входа. Можно пользователей автономной БД сопоставить с учетной записью Windows, или настроить на проверку подлинности SQL Server на уровне базы данных.

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

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

Разрешения в sql Server.

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

Архитектуры безопасности часто являются иерархическими, в первую очередь для того, чтобы упростить управление разрешениями. В архитектуре иерархической безопасности защищаемые объекты могут содержать другие защищаемые объекты, и участники могут содержать другие сущности (Principal), например, пользователи могут быть добавлены в группу. Обычно разрешения наследуются как в иерархии защищаемых объектов, так и иерархиями участников. Для тонкой настройки доступа можно явно переопределить унаследованные разрешения на разных уровнях иерархии.

Такая иерархическая организация упрощает управление разрешениями: