Авторизация с использованием данных sql: Авторизация доступа к серверу и базе данных с помощью имен для входа и учетных записей пользователей — Azure SQL Database & SQL Managed Instance & Azure Synapse Analytics

Авторизация доступа к серверу и базе данных с помощью имен для входа и учетных записей пользователей — Azure SQL Database & SQL Managed Instance & Azure Synapse Analytics

Twitter




LinkedIn




Facebook




Адрес электронной почты

• 
  Статья
• 
  02/23/2023
• Чтение занимает 10 мин
• 
  

Область применения: База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics

В этой статье раскрываются следующие темы:

• Возможности настройки Базы данных SQL Azure, Управляемого экземпляра SQL и Azure Synapse Analytics, чтобы пользователи могли выполнять административные задачи и получать доступ к данным, хранящимся в этих базах данных.
• Настройка доступа и авторизации после первоначального создания нового сервера.
• Как добавить имена входа и учетные записи пользователей в master базу данных и учетные записи пользователей, а затем предоставить этим учетным записям административные разрешения.
• Добавление в пользовательские базы данных учетных записей пользователей, либо связанных с именами входа, либо автономных.
• Настройка учетных записей пользователей, имеющих разрешения в пользовательских базах данных, полученные с помощью ролей базы данных или явно.

Важно!

Базы данных в Azure SQL Database, Управляемый экземпляр SQL Azure и Azure Synapse в оставшейся части этой статьи называются базами данных, а сервер ссылается на логический сервер, который управляет базами данных для базы данных Azure SQL и Azure Synapse.

Аутентификация и авторизация

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

• Аутентификация SQL.

  При использовании этого метода пользователь отправляет имя учетной записи пользователя и связанный пароль, чтобы установить соединение. Этот пароль хранится в master базе данных для учетных записей пользователей, связанных с именем входа, или в базе данных, содержащей учетные записи пользователей , не связанные с именем входа.

  Примечание

  Azure SQL База данных обеспечивает сложность пароля только для политики паролей. Сведения о политике паролей в Управляемый экземпляр SQL Azure см. в Управляемый экземпляр SQL Azure часто задаваемых вопросов.

• Аутентификация Azure Active Directory

  При использовании этого метода проверки подлинности пользователь отправляет имя учетной записи пользователя и запрашивает, чтобы служба использовала учетные данные, хранящиеся в Azure Active Directory (Azure AD).

Имена входа и пользователи. Учетная запись пользователя в базе данных может быть связана с именем входа, которое хранится в master базе данных, или может быть именем пользователя, хранящимся в отдельной базе данных.

• Имя входа — это отдельная учетная запись в master базе данных, с которой может быть связана учетная запись пользователя в одной или нескольких базах данных. Если используется имя для входа, вместе с ним хранятся учетные данные для учетной записи пользователя.
• Учетная запись пользователя — это отдельная учетная запись в любой базе данных, которая может быть не связана с именем входа. Если учетная запись пользователя не связана с именем для входа, то учетные данные хранятся вместе с учетной записью пользователя.

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

Существующие имена для входа и учетные записи пользователей после создания базы данных

При первом развертывании Azure SQL можно указать имя входа и пароль для специального типа административного входа — администратора сервера. Во время развертывания происходит следующая конфигурация имен входа и пользователей в основной и пользовательской базах данных:

• Создается имя для входа SQL с правами администратора с использованием указанного имени для входа. Имя входа — это отдельная учетная запись для входа в База данных SQL, Управляемый экземпляр SQL и Azure Synapse.
• Этому имени для входа предоставляются полные права администратора во всех базах данных в качестве субъекта серверного уровня. Имя входа имеет все доступные разрешения и не может быть ограничено. В Управляемом экземпляре SQL это имя входа добавляется в предопределенную роль сервера sysadmin (эта роль не существует в Базе данных SQL Azure).
• Когда эта учетная запись входит в базу данных, она сопоставляется со специальной учетной записью dbo пользователя (учетной записью пользователя, которая существует в каждой пользовательской базе данных). Пользователь dbo имеет все разрешения базы данных в базе данных и является членом предопределенных db_owner ролей базы данных. Дополнительные предопределенные роли базы данных рассматриваются далее в этой статье.

Чтобы определить учетную запись администратора сервера для логического сервера, откройте портал Azure и перейдите на вкладку Свойства сервера или управляемого экземпляра.

Важно!

Имя учетной записи администратора сервера нельзя изменить после ее создания. Чтобы сбросить пароль администратора сервера, на портале Azure щелкните Серверы SQL, выберите в списке сервер и щелкните Сбросить пароль. Чтобы сбросить пароль для Управляемого экземпляра SQL, перейдите на портал Azure, выберите экземпляр и нажмите Сбросить пароль. Вы также можете использовать PowerShell или Azure CLI.

Создание дополнительных имен для входа и пользователей с правами администратора

На этом этапе ваш сервер или управляемый экземпляр настроен для доступа только с помощью одного имени входа SQL и учетной записи пользователя. Для создания дополнительных учетных записей с полными или частичными правами администратора доступны следующие варианты (в зависимости от режима развертывания).

• Создание учетной записи администратора Azure Active Directory с полными правами администратора

  Включите проверку подлинности Azure Active Directory и добавьте администратора Azure Active Directory . Одну учетную запись Azure Active Directory можно настроить в качестве администратора развертывания Azure SQL с полными правами администратора. Эта учетная запись может быть отдельной учетной записью или учетной записью группы безопасности. Если вы хотите использовать учетные записи Azure AD для подключения к База данных SQL, Управляемый экземпляр SQL или Azure Synapse, необходимо настроить администратора Azure Active Directory. Подробные сведения о включении проверки подлинности Azure AD для всех типов развертывания Azure SQL см. в следующих статьях:

  • Использование проверки подлинности Azure Active Directory для проверки подлинности с помощью SQL
  • Настройка и администрирование аутентификации Azure Active Directory с помощью SQL

• В Управляемом экземпляре SQL создайте имена входа SQL с полными разрешениями администратора.

  • Создайте дополнительное имя входа SQL в master базе данных.
  • Добавьте имя для входа к предопределенной роли сервера sysadmin с помощью оператора ALTER SERVER ROLE. У этого имени для входа будут полные права администратора.
  • Кроме того, можно создать имя для входа Azure AD с помощью синтаксиса CREATE LOGIN.

• В Базе данных SQL создайте имена входа SQL с ограниченными административными разрешениями.

  • Создайте дополнительное имя входа SQL в master базе данных.
  • Добавьте имя входа в ##MS_DatabaseManager####MS_LoginManager##роли уровня сервера и ##MS_DatabaseConnector## с помощью инструкции ALTER SERVER ROLE.

• В Azure Synapse создайте имена входа SQL с ограниченными административными разрешениями.

  • Создайте дополнительное имя входа SQL в master базе данных.
  • Создайте учетную запись пользователя в базе данных, связанной master с этим новым именем входа.
  • Добавьте учетную запись пользователя в dbmanager, loginmanager роль или обе роли в master базе данных с помощью инструкции sp_addrolemember .

  Примечание

  Роли dbmanager и loginmanagerне относятся к развертываниям Управляемого экземпляра SQL.

  Члены этих специальных ролей базы данных master для Базы данных SQL Azure имеют полномочия на создание баз данных и имен входа и управление ими. В базах данных, созданных пользователем, который является членом роли dbmanager, этот пользователь сопоставляется с фиксированной ролью базы данных db_owner и может входить в нее и управлять ею с помощью учетной записи пользователя dbo. Эти роли не имеют явных разрешений за пределами master базы данных.

  Важно!

  Нельзя создать дополнительное имя входа SQL с полными правами администратора в Базе данных SQL.

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

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

• Создает вход

  Создайте имя входа SQL в master базе данных. Затем создайте учетную запись пользователя в каждой базе данных, к которой пользователю требуется доступ, и свяжите учетную запись пользователя с этим именем для входа. Этот подход предпочтителен, если пользователь должен получить доступ к нескольким базам данных и вы хотите синхронизировать пароли. Однако с этим подходом возникают сложности при использовании георепликации, так как имя для входа нужно создать как на сервере-источнике, так и на серверах-получателях. Дополнительные сведения см. в статье Настройка безопасности Базы данных SQL Azure и управление ею для геовосстановления или отработки отказа.

• Создание учетной записи пользователя

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

  • В Базе данных SQL вы всегда можете создать учетную запись этого типа.
  • Если используется Управляемый экземпляр SQL, поддерживающий субъекты сервера Azure AD, можно создавать учетные записи пользователей для проверки подлинности в Управляемый экземпляре SQL без необходимости создания пользователей базы данных в качестве автономных пользователей.

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

Важно!

Чтобы создать автономных пользователей, сопоставленных с удостоверениями Azure AD, необходимо войти в систему с помощью учетной записи Azure AD в базе данных Базы данных SQL Azure. В Управляемом экземпляре SQL при использовании имени входа SQL с разрешениями sysadmin также можно создавать имя входа или пользователя Azure AD.

Примеры, демонстрирующие создание имен для входа и пользователей, см. в следующих статьях:

• Создание имени входа для Базы данных SQL Azure
• Создание имени входа для Управляемого экземпляра SQL Azure
• Создание имени входа для Azure Synapse
• Создание пользователя
• Создание автономных пользователей Azure AD

Совет

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

Использование фиксированных и настраиваемых ролей базы данных

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

• Фиксированные роли базы данных

  Добавьте учетную запись пользователя к фиксированной роли базы данных. Существует 9 фиксированных ролей базы данных, у каждой из которых свой определенный набор разрешений. Самые распространенные роли базы данных: db_owner, db_ddladmin, db_datawriter, db_datareader, db_denydatawriter и db_denydatareader. Роль db_owner обычно используется для предоставления полных прав ограниченному числу пользователей. Другие фиксированные роли можно использовать для быстрого получения простых баз данных при разработке, но их не рекомендуется использовать для большинства рабочих баз данных. Например, фиксированная роль базы данных db_datareader предоставляет доступ на чтение ко всем таблицам в базе данных —это больше, чем необходимо для работы.

• Настраиваемая роль базы данных

  Создайте настраиваемую роль базы данных с помощью оператора CREATE ROLE. Настраиваемая роль позволяет создавать определяемые пользователем роли базы данных, а затем предоставлять каждой роли наименьший набор разрешений, необходимый для работы. Затем можно добавить пользователей в настраиваемую роль. Если пользователь является участником нескольких ролей, то ему предоставлены разрешения всех этих ролей.

• Предоставление разрешений напрямую

  Предоставьте учетной записи пользователя разрешения напрямую. Существует более 100 разрешений, которые можно по отдельности предоставлять или отменять в базе данных SQL. Многие эти разрешения являются частью других разрешений. Например, разрешение UPDATE на схеме включает в себя разрешение UPDATE для каждой таблицы в этой схеме. Как и в большинстве систем разрешений, отмена разрешения переопределяет предоставление. Так как некоторые разрешения включены в другие разрешения и их достаточно много, необходимо внимательно изучить их, чтобы спроектировать соответствующую систему разрешений, которая будет надежно защищать базу данных. Изучите список разрешений на этой странице и ознакомьтесь с графическим представлением разрешений.

Использование групп

Эффективное управление доступом основано на разрешениях, назначенных группам безопасности Active Directory, и фиксированным или настраиваемым ролям, а не отдельным пользователям.

• Если используется аутентификация Azure Active Directory, поместите пользователей Azure Active Directory в соответствующую группу безопасности. Создайте пользователя автономной базы данных для группы. Добавьте одного или нескольких пользователей базы данных в качестве члена пользовательских или встроенных ролей базы данных с определенными разрешениями, соответствующими этой группе пользователей.

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

  Примечание

  Можно также использовать группы для пользователей неавтономной базы данных.

Ознакомьтесь со следующими возможностями, которые можно использовать, чтобы ограничить или расширить права:

• Чтобы безопасно временно повысить уровень разрешений, можно использовать олицетворение и подписание модулей.
• Безопасности на уровне строк может использоваться, чтобы ограничить доступ пользователя к строкам.
• Маскирование данных позволяет снизить уязвимость конфиденциальных данных.
• хранимые процедуры .

Дальнейшие действия

Обзор всех функций обеспечения безопасности Базы данных SQL Azure и Управляемого экземпляра SQL см. в разделе Общие сведения о безопасности.

Transact-SQL | Авторизация пользователей

160

Работа с базами данных в .NET Framework — SQL Server 2012 — Авторизация пользователей

Исходники баз данных

Выполнять инструкции или осуществлять операции с объектами баз данных могут только авторизованные пользователи. Попытка выполнения любой из этих задач неавторизованным пользователем будет неудачной. Для выполнения задач, связанных с авторизацией, используются следующие три инструкции языка Transact-SQL: GRANT, DENY и REVOKE.

Прежде чем приступить к рассмотрению этих инструкций, будет полезным освежить наиболее важные факты о модели безопасности компонента Database Engine. Итак, эта модель разделяет мир сервера базы данных на принципалов безопасности и защищаемые объекты. Каждый защищаемый объект имеет связанные с ним разрешения, которые могут быть предоставлены принципалу. Принципалы, такие как отдельные лица, группы или приложения, могут обращаться к защищаемым объектам. Защищаемые объекты — это ресурсы, доступ к которым регулируется подсистемой авторизации. Существует три основных класса защищаемых объектов: сервер, база данных и схема, которые содержат другие защищаемые объекты, такие как регистрационные имена, пользователи базы данных, таблицы и хранимые процедуры.

Инструкция GRANT

Инструкция GRANT предоставляет разрешения принципалам на защищаемые объекты. Эта инструкция имеет следующий синтаксис:

GRANT {ALL [PRIVILEGES]} | permission_list
    [ON [class::] securable] TO principal_list [WITH GRANT OPTION]
    [AS principal ]


Соглашения по синтаксису

Предложение ALL означает, что указанному принципалу предоставляются все применимые к указанному защищаемому объекту разрешения. В параметре permission_list указываются разрешаемые инструкции или объекты (разделенные запятыми), а в параметре class — класс или имя защищаемого объекта, для которого предоставляются разрешения. Предложение on securable указывает защищаемый объект, на который предоставляется разрешение. В параметре prinicpal_list перечисляются все учетные записи (разделенные запятыми), которым предоставляются разрешения. Параметр principal и составляющие списка principal_list могут быть учетной записью пользователя Windows, регистрационным именем или учетной записью пользователя, сопоставленной с сертификатом, регистрационным именем, сопоставленным с асимметричным ключом, пользователем базы данных, ролью базы данных или ролью приложения.

В таблице ниже приводятся разрешения и защищаемые объекты, к которым они применяются, а также краткое описание предоставляемых каждым разрешением возможностей:

В таблице перечислены только наиболее важные разрешения. Так как модель безопасности компонента Database Engine является иерархической, то она содержит многие гранулярные разрешения, которые не отображены в списке. Описание этих разрешений смотрите в электронной документации.

Применение инструкции GRANT показано в примерах ниже. Для начала, в следующем примере показано использование разрешения CREATE:

USE SampleDb;

GRANT CREATE TABLE, CREATE PROCEDURE
    TO Vasya, [ProfessorWeb\Alexandr];

В этом примере пользователям Vasya и [ProfessorWeb\Alexandr] дается право на выполнение инструкций языка Transact-SQL CREATE TABLE и CREATE PROCEDURE. (Как можно видеть в этом примере, инструкция GRANT для разрешения CREATE не включает параметр ON.)

В примере ниже пользователю Vasya предоставляется возможность для создания определяемых пользователем функций в базе данных SampleDb:

USE SampleDb;

GRANT CREATE FUNCTION TO Vasya;

Далее показано использование разрешения SELECT в инструкции GRANT:

USE SampleDb;

GRANT SELECT ON Employee
    TO Vasya;

Здесь пользователь Vasya получает разрешение на чтение строк из таблицы Employee. Когда разрешение дается учетной записи пользователя Windows или регистрационному имени, это разрешение распространяется только на данную учетную запись (регистрационное имя). С другой стороны, разрешение, предоставленное группе или роли, распространяется на всех пользователей данной группы или роли.

В примере ниже показано использование разрешения UPDATE в инструкции GRANT:

USE SampleDb;

GRANT UPDATE ON Works_on (EmpId, EnterDate)
    TO Vasya;

После выполнения инструкции GRANT в этом примере ниже, пользователь Vasya может модифицировать значения столбцов Id и EnterDate таблицы Works_on.

В следующем примере показано использование разрешения VIEW DEFINITION, которое предоставляет пользователям доступ для чтения метаданных:

USE SampleDb;

GRANT VIEW DEFINITION ON OBJECT::Employee TO Vasya;
GRANT VIEW DEFINITION ON SCHEMA::dbo TO Vasya;

Здесь показаны две инструкции для разрешений VIEW DEFINITION. Первая из них предоставляет пользователю Vasya разрешение на просмотр метаданных таблицы Employee базы данных SampleDb. (В предложении ON OBJECT указывается защищаемый объект базы данных. Посредством этого предложения можно предоставлять разрешения для работы с конкретными объектами, такими как таблицы, представления и хранимые процедуры.) Благодаря иерархической структуре защищаемых объектов, защищаемый объект более высокого уровня можно использовать, чтобы расширить область действия разрешения VIEW DEFINITION (или любого другого базового разрешения). Вторая инструкция GRANT в примере предоставляет пользователю Vasya доступ к метаданным всех объектов схемы dbo базы данных SampleDb.

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

В примере ниже показано использование разрешения CONTROL:

USE SampleDb;

GRANT CONTROL ON DATABASE::SampleDb TO Vasya;

Здесь пользователю Vasya предоставляются, по сути, все определенные права доступа к защищаемому объекту (в данном случае к базе данных SampleDb). Принципалу, которому предоставлено разрешение CONTROL для защищаемого объекта, также неявно предоставляется возможность самому предоставлять разрешения для данного объекта. Иными словами, разрешение CONTROL включает в себя предложение WITH GRANT OPTION. Разрешение CONTROL является самым высшим разрешением, применительно ко многим защищаемым объектам базы данных. Вследствие этого, разрешение CONTROL на уровне определенной области неявно включает разрешение CONTROL для всех защищаемых объектов в этой области. Поэтому разрешение CONTROL пользователя Vasya для базы данных SampleDb неявно включает в себя все разрешения к этой базе данных, а также все разрешения ко всем сборкам этой базы данных, все разрешения ко всем схемам и объектам базы данных.

По умолчанию, если пользователь A предоставляет разрешение пользователю B, то пользователь B может использовать разрешения при выполнении инструкций языка Transact-SQL в инструкции GRANT. Предложение WITH GRANT OPTION дает пользователю B дополнительную возможность предоставлять данное разрешение другим пользователям:

USE SampleDb;

GRANT SELECT ON Works_on TO Vasya
    WITH GRANT OPTION;

В этом примере пользователю Vasya предоставляется разрешение выполнять инструкцию SELECT для выборки строк из таблицы Works_on, а также право самому предоставлять это разрешение другим пользователям базы данных SampleDb.

Инструкция DENY

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

DENY {ALL [PRIVILEGES] } | permission_list
    [ON [class::] securable] TO principal_list
    [CASCADE] [ AS principal ]


Соглашения по синтаксису

Все параметры инструкции DENY имеют точно такое же логическое значение, как и одноименные параметры инструкции GRANT. Инструкция DENY имеет дополнительный параметр CASCADE, в котором указывается, что разрешения, запрещенные пользователю A, будут также запрещены пользователям, которым он их предоставил. Если в инструкции DENY параметр CASCADE опущен, и при этом ранее были предоставлены разрешения для соответствующего объекта с использованием предложения WITH GRANT OPTION, исполнение инструкции DENY завершается ошибкой.

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

Инструкцию GRANT можно рассматривать как положительную авторизацию пользователя, а инструкцию DENY — как отрицательную. Обычно инструкция DENY используется для запрещения разрешений, уже предоставленных для группы (или роли), отдельным членам этой группы.

Использование инструкции DENY показано в примерах ниже. В следующем примере мы запрещаем пользователю Vasya два предоставленных ранее разрешения:

USE SampleDb;

DENY CREATE TABLE, CREATE PROCEDURE
    TO Vasya;

Инструкция DENY в примере отменяет для пользователя Vasya ранее предоставленные ему разрешения на создание таблиц и процедур. В примере ниже показана негативная авторизация для некоторых пользователей базы данных SampleDb:

USE SampleDb;

GRANT SELECT ON Project TO PUBLIC;
DENY SELECT ON Project TO Vasya;

Вначале предоставляется разрешение на выборку всех строк из таблицы Project всем пользователям базы данных SampleDb. После этого это разрешение отменяется для пользователя Vasya.

Запрещение разрешений на более высоком уровне модели безопасности компонента Database Engine аннулирует разрешения, предоставленные на более низком уровне. Например, если разрешение SELECT запрещено на уровне базы данных SampleDb, и это разрешение предполагается для таблицы Employee, в результате чего разрешение SELECT будет запрещено для таблицы Employee так же, как и для всех других таблиц этой базы данных.

Инструкция REVOKE

Инструкция REVOKE удаляет предоставленное или запрещенное ранее разрешение. Эта инструкция имеет следующий синтаксис:

REVOKE [GRANT OPTION FOR]
    { [ALL [PRIVILEGES] ] | permission_list ]}
    [ON [class:: ] securable ]
    FROM principal_list [CASCADE] [ AS principal ]


Соглашения по синтаксису

Единственным новым параметром инструкции REVOKE является параметр GRANT OPTION FOR. Все другие параметры этой инструкции имеют точно такое же логическое значение, как и одноименные параметры инструкций GRANT или DENY. Параметр GRANT OPTION FOR используется для отмены эффекта предложения WITH GRANT OPTION в соответствующей инструкции GRANT. Это означает, что пользователь все еще будет иметь предоставленные ранее разрешения, но больше не сможет предоставлять их другим пользователям.

Инструкция REVOKE отменяет как «позитивные» разрешения, предоставленные инструкцией GRANT, так и «негативные» разрешения, предоставленные инструкцией DENY. Таким образом, его функцией является нейтрализация указанных ранее разрешений (позитивных и негативных).

Использование инструкции REVOKE показано в примере ниже:

USE SampleDb;

REVOKE SELECT ON Project FROM public;

Инструкция REVOKE в этом примере отменяет предоставленное разрешение выборки данных для роли public. При этом существующее запрещение разрешения этой инструкции для пользователя Vasya не удаляется, поскольку разрешения, предоставленные или запрещенные явно членам группы (или роли), не затрагиваются удалением этих разрешений (положительных или отрицательных) для данной группы.

Управление разрешениями с помощью среды Management Studio

Пользователи базы данных могут выполнять действия, на которые им были предоставлены разрешения. Разрешения на определенные действия установлены в значение g (от GRANT) в столбце state в представлении просмотра каталога sys.database_permissions. Негативная запись в таблице не дает возможность пользователям выполнять деятельность. Значение d (от DENY) в этом столбце state аннулирует разрешение, предоставленное пользователю явно или неявно посредством предоставления его роли, к которой он принадлежит. Таким образом, пользователь не может выполнять данное действие в любом случае. И последнее возможное значение r (от REVOKE) в столбце state означает, что пользователь не имеет никаких явных разрешений, но может выполнять действие, если роли, к которой он принадлежит, предоставлено соответствующее разрешение.

Для управления разрешениями с помощью среды Management Studio разверните сервер, а затем папку «Databases». Щелкните правой кнопкой мыши требуемую базу данных и в контекстном меню выберите пункт Properties. В открывшемся диалоговом окне свойств базы данных Database Properties — SampleDb выберите страницу Permissions, после чего нажмите кнопку Search, чтобы выбрать пользователей, которым предоставить или запретить разрешения. В открывшемся диалоговом окне нажмите кнопку Browse, в диалоговом окне Browse for Objects выберите требуемых пользователей или роли (например, guest и public) и нажмите кнопки ОК соответствующих окон, чтобы добавить выбранных пользователей (роли).

Выбранные таким образом пользователи будут отображены в окне свойств базы данных в поле Users or roles (Пользователи и роли).

Теперь для выбранных пользователей можно разрешить или запретить выполнение определенных действий. В частности, для предоставления разрешения, для требуемого действия установите флажок в столбце Grant, а для запрещения действия установите для него флажок в столбце Deny. Установленный флажок в столбце With Grant означает, что получатель разрешения также имеет право предоставлять его другим пользователям. Отсутствие установленных флажков в столбце разрешений или запрещений означает, что для данного пользователя нет никаких явных разрешений или запрещений на выполнение соответствующих действий.

Предоставление и запрещение разрешений пользователям или ролям для выполнения действий с индивидуальными таблицами базы данных посредством среды Management Studio осуществляется точно так же, как и для всей базы данных: в обозревателе объектов Object Explorer разворачивается вся иерархия папок сервера вплоть до требуемой таблицы, открывается окно свойств этой таблицы, выбираются и добавляются в поле Users or roles требуемые пользователи, после чего им предоставляются или запрещаются требуемые разрешения на исполнение определенных действий установкой соответствующих флажков:

Использование ограничений через представления

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

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

USE SampleDb;

GO
CREATE VIEW view_without_budget
    AS SELECT Number, ProjectName
    FROM Project;

Как показано в примере ниже, представление view_without позволяет разделить пользователей на две группы: тех, кто может просматривать бюджеты всех проектов, и тех, для которых доступ к столбцу Budget таблицы Projects не предоставляется.

USE SampleDb;

GO
    ALTER TABLE Employee
    ADD user_name CHAR(60) DEFAULT SYSTEM_USER;

GO
CREATE VIEW view_my_rows
    AS SELECT Id, FirstName, LastName, DepartamentNumber
    FROM Employee
    WHERE user_name = SYSTEM_USER;

В этом примере модифицируется схема таблицы Employee, добавляя в нее новый столбец user_name. Теперь при каждой вставке строки в эту таблицу в столбец user_name вставляется регистрационное имя пользователя, осуществляющего эту вставку. Создав соответствующие представления, пользователи могут с помощью этих представлений выбирать из таблицы только те строки, которые они сами вставили.

USE SampleDb;

GO
CREATE VIEW view_analyst
    AS SELECT Employee.Id, FirstName, LastName
    FROM Employee, Works_on
    WHERE Employee.Id = Works_on.EmpId
        AND Job = 'Аналитик';

Представление view_analyst в примере представляет горизонтальное и вертикальное подмножество таблицы Employee. Иными словами, оно ограничивает доступ к определенным строкам и столбцам этой таблицы.

Использование стандартной авторизации SQL

Использование стандартной авторизации SQL

Когда включен стандартный режим авторизации SQL, владельцы объектов
можно использовать операторы GRANT и REVOKE SQL для установки привилегий пользователя для
определенные объекты базы данных или для определенных действий SQL. Они также могут использовать роли
управлять привилегиями.

Стандартный режим авторизации SQL — это контроль доступа, совместимый с SQL2003.
система. Вы включаете стандартный режим авторизации SQL, устанавливая derby.database.sqlAuthorization свойство
до ИСТИНА .

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

Оператор GRANT используется для предоставления определенных привилегий пользователям или
ролей или для предоставления ролей пользователям или ролям.
Оператор REVOKE используется для отзыва привилегий и предоставленных ролей. Грант и
отозвать привилегии:

• УДАЛИТЬ
• ВЫПОЛНИТЬ
• ВСТАВКА
• ВЫБЕРИТЕ
• ССЫЛКИ
• ТРИГГЕР
• ОБНОВЛЕНИЕ

При создании таблицы, представления, функции или процедуры лицо, которое
создает объект, упоминается как владелец объекта.
Только владелец объекта и
владелец базы данных
иметь полные права на объект.
Никакие другие пользователи не имеют привилегий на объект, пока владелец объекта не предоставит
им привилегии.

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

Дополнительные сведения см. в справочном руководстве по Java DB .
информация об операторах GRANT и REVOKE.

Публичные и индивидуальные привилегии пользователя

Объект
владелец может предоставлять и отменять привилегии для определенных пользователей, для определенных ролей,
или для всех пользователей.
Ключевое слово PUBLIC используется для указания всех пользователей. Когда указано ОБЩЕСТВЕННОЕ,
привилегии распространяются на всех текущих и будущих пользователей. Предоставляемые привилегии
и отозваны для PUBLIC и для отдельных пользователей или ролей независимы. Например,
привилегия SELECT для таблицы t предоставляется как ОБЩЕСТВЕННОМУ, так и
пользователю harry . Позже привилегия SELECT отменяется.
от пользователя harry , но пользователь harry имеет доступ
к таблице t через привилегию PUBLIC.

Исключение: при создании представления, триггера или ограничения Дерби сначала
проверяет, есть ли у вас необходимые привилегии на уровне пользователя.
Если у вас есть привилегии уровня пользователя, объект создается и зависит
на этой привилегии уровня пользователя. Если у вас нет необходимых прав на
на уровне пользователя, Дерби проверяет
чтобы определить, есть ли у вас необходимые привилегии на уровне PUBLIC. Если вы
имеют привилегии уровня PUBLIC, объект создается и зависит от
эта привилегия ОБЩЕСТВЕННОГО уровня. После создания объекта, если привилегия
от которого зависит объект, отменяется, объект автоматически удаляется. Дерби не пытается определить
если у вас есть другие привилегии, которые могут заменить привилегии, которые
отозван.

Пример 1

Пользователь zhi создает таблицу t1 и предоставляет
Привилегии SELECT для пользователя harry в таблице t1 .
Пользователь zhi предоставляет привилегии SELECT для PUBLIC в таблице t1 .
Пользователь harry создает представление v1 с оператором
ВЫБРАТЬ * из жи.т1 . Вид зависит от уровня пользователя
привилегия, которую пользователь harry имеет на t1 . Впоследствии,
пользователь zhi отменяет привилегии SELECT у пользователя harry on
таблица т1 . В результате представление harry.v1
упавший.

Пример 2

Пользователь anita создает таблицу t1 и предоставляет
SELECT привилегии для PUBLIC. Пользователь harry создает представление v1 с
оператор SELECT * from anita.t1 . Вид зависит от
привилегия уровня PUBLIC, которую пользователь harry имеет на t1 , так как
пользователь harry не имеет привилегий уровня пользователя в таблице t1 , когда
он создает представление harry.v1 . Впоследствии пользователь anita предоставляет
Привилегии SELECT для пользователя harry в таблице anita.t1 .
Представление harry.v1 продолжает зависеть от привилегии уровня PUBLIC.
у этого пользователя harry есть t1 . Когда пользователь anita отзывает
SELECT привилегии от PUBLIC для таблицы t1 , вид harry. v1 есть
упавший.

См.
Права доступа к представлениям, триггерам и ограничениям для
Дополнительная информация.

Понятия, связанные с данным

Привилегии для представлений, триггеров и ограничений

Использование ролей SQL

Ссылки, связанные с данной

Стандартные исключения авторизации SQL

Сценарии на этой странице отслеживают трафик веб-страницы,
но никак не меняет содержание.

Проверка подлинности в SQL Server — поставщик ADO.NET для SQL Server

Редактировать

Твиттер

LinkedIn

Фейсбук

Электронная почта

• Статья
• 18. 11.2022
• 2 минуты на чтение

Загрузить ADO.NET

SQL Server поддерживает два режима проверки подлинности: режим проверки подлинности Windows и смешанный режим.

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

• Смешанный режим поддерживает аутентификацию как Windows, так и SQL Server. Пары имени пользователя и пароля хранятся в SQL Server.

Важно

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

При проверке подлинности Windows пользователи уже вошли в систему Windows, и им не нужно отдельно входить в систему SQL Server. Следующий SqlConnection.ConnectionString указывает аутентификацию Windows, не требуя от пользователей ввода имени пользователя или пароля.

 "Сервер=MSSQL1;База данных=AdventureWorks;Интегрированная безопасность=true;Шифрование=True;"
 

Примечание

Логины отличаются от пользователей базы данных. Вы должны сопоставить имена входа или группы Windows с пользователями или ролями базы данных в отдельной операции. Затем вы предоставляете пользователям или ролям разрешения на доступ к объектам базы данных.

Сценарии проверки подлинности

Проверка подлинности Windows обычно является лучшим выбором в следующих ситуациях:

• Есть контроллер домена.

• Приложение и база данных находятся на одном компьютере.

• Вы используете экземпляр SQL Server Express или LocalDB.

Логины SQL Server часто используются в следующих ситуациях:

• Если у вас есть рабочая группа.

• Пользователи подключаются из разных недоверенных доменов.

• Интернет-приложения, такие как ASP.NET.

Примечание

Указание проверки подлинности Windows не отключает вход в SQL Server. Используйте инструкцию Transact-SQL ALTER LOGIN DISABLE, чтобы отключить вход в SQL Server с высоким уровнем привилегий.

Типы входа

SQL Server поддерживает три типа входа:

• Локальная учетная запись пользователя Windows или учетная запись доверенного домена. SQL Server использует Windows для аутентификации учетных записей пользователей Windows.

• Группа Windows. Предоставление доступа к группе Windows предоставляет доступ ко всем учетным записям пользователей Windows, которые являются членами группы.

• Вход в SQL Server. SQL Server сохраняет как имя пользователя, так и хэш пароля в базе данных master, используя внутренние методы проверки подлинности для проверки попыток входа в систему.

Примечание

SQL Server предоставляет учетные записи, созданные на основе сертификатов или асимметричных ключей, которые используются только для подписи кода. Их нельзя использовать для подключения к SQL Server.

Проверка подлинности в смешанном режиме

Если необходимо использовать проверку подлинности в смешанном режиме, необходимо создать учетные записи SQL Server, которые хранятся в SQL Server. Затем вы должны указать имя пользователя и пароль SQL Server во время выполнения.

Важно

SQL Server устанавливается с именем входа SQL Server sa (аббревиатура от «системный администратор»). Назначьте надежный пароль для входа sa и не используйте имя входа sa в своем приложении. Логин sa сопоставляется с фиксированной серверной ролью sysadmin , которая имеет неотменяемые учетные данные администратора на всем сервере.