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

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

Twitter




LinkedIn




Facebook




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

• 
  Статья
• 
  09/26/2022
• Чтение занимает 9 мин
• 
  

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

• Создается имя для входа 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 AD. Одну учетную запись Azure Active Directory можно настроить в качестве администратора развертывания Azure SQL с полными правами администратора. Эта учетная запись может быть отдельной учетной записью или учетной записью группы безопасности. Если нужно использовать учетные записи Azure AD для подключения к Базе данных SQL Azure, Управляемому экземпляру SQL или Azure Synapse, обязательно настройте администратора Azure AD. Подробные сведения о включении проверки подлинности 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.
  • Создайте учетную запись пользователя в базе данных master, связанную с этим новым именем входа.
  • Добавьте эту учетную запись пользователя в роль dbmanager, loginmanager или в обе эти роли в базе данных master с помощью инструкции ALTER ROLE (для Azure Synapse используйте инструкцию 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 Server, логины и пользователи базы данных

Понимание безопасности SQL Server является важным навыком. В этой статье Грег Ларсен объясняет методы аутентификации SQL Server, логины и пользователей базы данных.

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

Поддерживаемые методы аутентификации

Существует два разных метода аутентификации для подключения к SQL Server: Windows и SQL Server.

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

Но бывают случаи, когда люди не могут подключиться к Windows; здесь вступает в действие проверка подлинности SQL. Проверка подлинности SQL менее безопасна, чем проверка подлинности Windows. Чтобы подключиться к SQL Server с использованием SQL-аутентификации, человеку необходимо указать логин и пароль при подключении. Пароль для входа с проверкой подлинности SQL хранится в базе данных master. Поскольку пароль хранится в базе данных SQL, его легче взломать. Его также можно создать и восстановить с помощью резервной копии базы данных, поэтому он менее безопасен, чем использование проверки подлинности Windows.

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

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

Настройка SQL Server для поддержки различных режимов проверки подлинности

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

красная стрелка на рис. 1. Если вам необходимо поддерживать аутентификацию как Windows, так и SQL Server, выберите переключатель «Смешанный режим». После нажатия этой кнопки поля пароля учетной записи SA станут активными, и вам потребуется указать пароль для учетной записи SA. Если выбрана только проверка подлинности Windows, учетная запись SA отключена. Чтобы защитить учетную запись SA при использовании смешанного режима, вы можете отключить учетную запись SA после ее включения.

Как определить, какие методы аутентификации поддерживаются

Проверить, какой метод аутентификации настроен, можно несколькими способами. Одним из таких способов является использование SQL Server Management Studio (SSMS). Чтобы использовать SSMS, сначала щелкните правой кнопкой мыши имя экземпляра и выберите параметр «Свойства». Когда я делаю это на своем экземпляре, отображается страница свойств на рис. 2.

Рисунок 2: Определение режима аутентификации

На рисунке 2 показано, что мой экземпляр поддерживает аутентификацию в смешанном режиме, поскольку переключатель рядом с красной стрелкой включен.

Другой способ проверить, какие режимы аутентификации настроены, — использовать код TSQL. Код в листинге 1 отображает настройку режима аутентификации.

Листинг 1: Отображение режима проверки подлинности

Изменение методов проверки подлинности после установки SQL Server

Бывают случаи, когда вам может потребоваться изменить параметры проверки подлинности для экземпляра SQL Server. Это может произойти, если во время установки вы использовали параметры по умолчанию для поддержки только проверки подлинности Windows, а позже приобрели некоторое программное обеспечение, которое может подключаться только с использованием проверки подлинности SQL Server. Или, возможно, вы хотите сделать свой экземпляр более безопасным, удалив поддержку проверки подлинности SQL Server. Параметры аутентификации можно легко изменить с помощью страницы свойств в SSMS, показанной на рис. 2.9.0003

Если бы я хотел изменить свои экземпляры для поддержки только проверки подлинности Windows, все, что мне нужно было бы сделать, это нажать кнопку «Режим проверки подлинности Windows» на рисунке 2, а затем нажать кнопку «ОК», чтобы применить это изменение. После внесения этого изменения свойства мне нужно будет перезапустить свой экземпляр, чтобы это изменение вступило в силу.

Входы в SQL Server

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

В базе данных master хранятся три типа учетных записей: пользователь Windows, группа Windows и SQL. Давайте рассмотрим каждый из этих различных типов входа в систему.

Логин пользователя Windows обеспечивает доступ для одного пользователя Windows. При создании этого типа входа пароль не требуется при определении входа в SQL Server. Этот тип входа требует, чтобы пользователь сначала подтвердил свой логин, войдя в домен Windows. Домен Windows хранит пароль.

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

На рис. 3 показано, что вход в SQL Server может быть включен для принудительного применения политик паролей Windows и истечения срока их действия, а также может требовать от пользователя смены пароля при первом входе в систему. Microsoft добавила эти новые функции пароля, когда был выпущен SQL Server 2005. Чтобы приложения поддерживали эти новые функции пароля, они могут использовать NetValidatePasswordPolicy API.

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

Если вы посмотрите на нижнюю часть снимка экрана на рис. 3, вы увидите параметр «База данных по умолчанию» для входа в систему. Настройкой базы данных по умолчанию при создании логина является «главная» база данных. При настройке логина базу данных по умолчанию можно изменить на любую базу данных на сервере. Лучшей практикой является установить в качестве базы данных по умолчанию базу данных, которую пользователь будет использовать при подключении к SQL Server.

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

Создание входа в SQL Server позволяет пользователям подключаться к SQL Server. Но сам по себе логин не дает пользователям доступа к каким-либо данным в различных базах данных на сервере. Чтобы логин мог читать и/или записывать данные в базу данных, ему потребуется доступ к одной или нескольким базам данных. Логин может быть настроен для доступа ко многим базам данных на экземпляре, если это необходимо.

Пользователи базы данных

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

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

Чтобы показать, как обеспечить сопоставление пользователей при создании новой учетной записи, я создам новую учетную запись SQL Server с именем «Red-Gate». На снимке экрана, показанном на рисунке 4, показано окно «Логин — новый», в котором я укажу этот новый логин. Чтобы открыть это окно, я раскрываю вкладку «Безопасность» под своим экземпляром, затем щелкаю правой кнопкой мыши параметр «Логины» и затем выбираю элемент «Новый вход…» в раскрывающемся списке.

Рисунок 4: Создание входа в Red-Gate

На рисунке 4 я ввожу «Red-Gate» в качестве имени для входа и ввожу пароль для этого входа в SQL в предоставленных диалоговых окнах. Чтобы предоставить доступ к базе данных для этого нового входа в систему, я нажимаю на опцию «Сопоставление пользователей» на левой панели. Когда я это делаю, отображается окно, показанное на рис. 5.

Рисунок 5: Окно сопоставления пользователей

Красное поле показывает список баз данных на рисунке 5, где можно сопоставить мой новый логин. Чтобы сопоставить мой логин «Red-Gate» с «AdventureWorks2019», мне просто нужно было бы установить флажок «Карта» рядом с базой данных AdventureWorks2019. Когда я это сделаю, отобразится снимок экрана на рис. 6.

Рисунок 6: Сопоставление входа в базу данных

После установки флажка «Сопоставление» имя «Red-Gate» автоматически заполняется в столбце «Пользователь» для базы данных AdventureWorks2019. Этот интерфейс автоматически генерирует имя пользователя базы данных, такое же, как имя входа, с которым оно сопоставлено. Имена пользователей базы данных не обязательно должны совпадать с логином. Если бы я хотел, чтобы мое имя пользователя базы данных было другим, я мог бы просто ввести имя «Red-Gate» и указать любое имя пользователя базы данных, которое я хотел. Сопоставление логина с пользователями базы данных обеспечивает только этот логин-доступ к базе данных, но не дает логину доступ для чтения или обновления данных в базе данных. В будущих статьях я буду обсуждать, как обеспечить доступ для чтения/записи к объектам базы данных.

Предположим, мне нужно сопоставить мой новый логин «Red-Gate» с дополнительными пользовательскими базами данных. В этом случае я мог бы сделать это, просто установив флажок «Карта» рядом с дополнительными базами данных. В этом примере я хочу только сопоставить мой новый логин «Red-Gate» с базой данных «AdventureWorks2019». Чтобы завершить сопоставление моего входа «Red-Gate» с пользователем базы данных «Red-Gate», мне просто нужно нажать кнопку «ОК».

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

Бывают случаи, когда логин уже создан, и ему просто нужен доступ к еще одной базе данных. Например, предположим, что теперь я хочу, чтобы моя установленная учетная запись Red-Gate SQL Server имела доступ к базе данных с именем «MyDatabase». Чтобы предоставить логину Red-Gate дополнительный доступ к базе данных, у меня есть несколько вариантов. Одним из вариантов было бы просто изменить сопоставления пользователей, изменив свойства при входе в систему. Это было бы похоже на то, как я только что добавил сопоставление пользователей при создании входа в Red-Gate.

Другой вариант — добавить нового пользователя базы данных в «MyDatabase», а затем сопоставить этого нового пользователя базы данных с логином Red-Gate. Чтобы создать нового пользователя в базе данных «MyDatabases», я бы сначала развернул базу данных, щелкнул правой кнопкой мыши элемент «Безопасность», навел курсор на элемент «Новый», а затем щелкнул элемент «Пользователь…», как показано на рисунке. Рисунок 7.

Рисунок 7: Открытие диалогового окна нового пользователя базы данных

Когда я нажимаю на новый элемент меню «Пользователь…», отображается окно, показанное на рисунке 8.

Рисунок 8: Добавление нового пользователя базы данных

Чтобы предоставить пользователю Red-Gate доступ к MyDatabase, мне нужно заполнить форму на рисунке 8. Первый элемент на рисунке 8, который нужно рассмотреть, это «Пользователь». Тип». В этом поле по умолчанию установлено значение «Пользователь SQL с логином». Существует еще четыре типа: пользователь SQL без входа в систему, пользователь, сопоставленный с сертификатом, пользователь, сопоставленный с асимметричным ключом, и пользователи Windows. Поскольку я создаю пользователя базы данных, который будет сопоставлен с логином SQL, я использую значение по умолчанию. Затем я ввожу имя пользователя базы данных для пользователя, которого я создаю. Это может быть любое имя, но я предпочитаю, чтобы имя пользователя базы данных совпадало с именем пользователя, с которым оно связано. Поэтому я ввожу «Red-Gate» в поле «Имя пользователя». Затем я сопоставляю своих новых пользователей с логином. Чтобы выполнить сопоставление, я могу либо ввести «Red-Gate» для входа в систему, либо использовать кнопку с многоточием (…), чтобы просмотреть список уже созданных входов и выбрать один.

Последнее, что необходимо сделать, это определить схему по умолчанию для этого входа в систему. Имя схемы связано с коллекцией объектов базы данных, принадлежащей пользователю базы данных. По умолчанию каждая база данных имеет схему с именем «dbo», принадлежащую учетной записи пользователя «dbo». Вам не нужно указывать схему при определении нового пользователя базы данных. Если он не указан при определении пользователя базы данных, схема «dbo» будет схемой по умолчанию. Поскольку эта статья является лишь введением, я буду обсуждать различные аспекты схем. Оставлю это для другой статьи. Когда я создаю нового пользователя базы данных Red-Gate, я оставлю элемент схемы по умолчанию пустым и позволю процессу создания новых пользователей автоматически установить схему по умолчанию на «dbo».

Создав нового пользователя, я могу убедиться, что он существует в базе данных, развернув элемент «Пользователь» в папке «Безопасность» в обозревателе объектов. Вы также можете создать нового пользователя базы данных и сопоставить его с логином с помощью скрипта. В листинге 2 приведен пример использования TSQL для создания того же имени входа, которое я только что создал с помощью метода «укажи и щелкни».

Листинг 2. Создание пользователя базы данных Red-Gate с помощью сценария TSQL

Методы аутентификации SQL Server, логины и пользователи базы данных

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

Если вам понравилась эта статья, вам также может понравиться Понимание моделей восстановления SQL Server.

Выберите режим проверки подлинности — SQL Server

Обратная связь

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

Твиттер

LinkedIn

Фейсбук

Эл. адрес

• Статья
• 05.08.2022
• 4 минуты на чтение

Применимо к:
SQL Server (все поддерживаемые версии)

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

Настройка режима проверки подлинности

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

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

Подключение через проверку подлинности Windows

Когда пользователь подключается через учетную запись пользователя Windows, SQL Server проверяет имя и пароль учетной записи, используя основной токен Windows в операционной системе. Это означает, что личность пользователя подтверждена Windows. SQL Server не запрашивает пароль и не выполняет проверку подлинности. Аутентификация Windows — это режим аутентификации по умолчанию, который гораздо более безопасен, чем аутентификация SQL Server. Аутентификация Windows использует протокол безопасности Kerberos, обеспечивает принудительное применение политики паролей в отношении проверки сложности надежных паролей, обеспечивает поддержку блокировки учетной записи и поддерживает истечение срока действия пароля. Соединение, выполненное с использованием проверки подлинности Windows, иногда называют доверенным соединением, поскольку SQL Server доверяет учетным данным, предоставленным Windows.

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

Важно

По возможности используйте проверку подлинности Windows.

Подключение с помощью проверки подлинности SQL Server

При использовании проверки подлинности SQL Server в SQL Server создаются имена входа, не основанные на учетных записях пользователей Windows. И имя пользователя, и пароль создаются с помощью SQL Server и сохраняются в SQL Server. Пользователи, подключающиеся с использованием проверки подлинности SQL Server, должны предоставлять свои учетные данные (логин и пароль) при каждом подключении. При использовании проверки подлинности SQL Server необходимо установить надежные пароли для всех учетных записей SQL Server. Рекомендации по использованию надежных паролей см. в разделе Надежные пароли.

Для входа в SQL Server доступны три необязательные политики паролей.

• Пользователь должен сменить пароль при следующем входе в систему

  Требует от пользователя смены пароля при следующем подключении пользователя. Возможность смены пароля предоставляется SQL Server Management Studio. Сторонние разработчики программного обеспечения должны предоставить эту функцию, если она используется.

• Принудительное истечение срока действия пароля

  Политика максимального срока действия пароля компьютера применяется для входа в SQL Server.

• Применить политику паролей

  Политики паролей Windows на компьютере применяются для входа в SQL Server. Это включает в себя длину и сложность пароля. Эта функциональность зависит от API NetValidatePasswordPolicy , который доступен только в Windows Server 2003 и более поздних версиях.

Для определения политик паролей локального компьютера

1. В меню Пуск выберите Выполнить .

2. В диалоговом окне Выполнить введите secpol.msc и выберите OK .

3. В приложении Локальные параметры безопасности разверните Параметры безопасности , разверните Политики учетных записей , а затем выберите Политика паролей .

   Политики паролей описаны в области результатов.

Недостатки проверки подлинности SQL Server

• Если пользователь является пользователем домена Windows, у которого есть логин и пароль для Windows, он все равно должен предоставить другой (SQL Server) логин и пароль для подключения. Многим пользователям сложно отслеживать несколько имен и паролей. Необходимость предоставлять учетные данные SQL Server каждый раз при подключении к базе данных может раздражать.

• Проверка подлинности SQL Server не может использовать протокол безопасности Kerberos.

• Windows предлагает дополнительные политики паролей, недоступные для входа в SQL Server.

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

Преимущества проверки подлинности SQL Server

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

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

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