active directory authentication library for sql server что это
Руководство по Использование проверки подлинности Active Directory с SQL Server на Linux
В этом руководстве описывается, как настроить в SQL Server на Linux поддержку проверки подлинности Active Directory, также известную как встроенная проверка подлинности. Общие сведения см. в статье Проверка подлинности Active Directory для SQL Server на Linux.
В этом руководстве рассматриваются следующие задачи:
Предварительные требования
Прежде чем настраивать проверку подлинности Active Directory, необходимо сделать следующее:
Присоединение узла SQL Server к домену Active Directory
Присоедините узел SQL Server на Linux к контроллеру домена Active Directory. Сведения о присоединении к домену Active Directory см. в статье Присоединение узла SQL Server на Linux к домену Active Directory.
Создание пользователя Active Directory (или управляемой учетной записи службы) для SQL Server и задание имени субъекта-службы
В целях безопасности рекомендуется использовать для SQL Server выделенную учетную запись Active Directory, чтобы учетные данные SQL Server не использовались другими службами. Однако при необходимости можно выбрать существующую учетную запись Active Directory, если вы знаете ее пароль (он потребуется для создания файла KEYTAB в следующем шаге). Кроме того, учетная запись должна быть включена для поддержки 128-разрядного и 256-разрядного шифрования Kerberos (атрибут msDS-SupportedEncryptionTypes) в учетной записи пользователя. Чтобы убедиться в том, что для учетной записи включено шифрование AES, найдите ее в служебной программе Пользователи и компьютеры Active Directory и выберите пункт Свойства. В окне Свойства перейдите на вкладку Учетные записи и убедитесь в том, что установлены два указанных ниже флажка.
Данная учетная запись поддерживает 128-битовое шифрование Kerberos AES
Данная учетная запись поддерживает 256-битовое шифрование Kerberos AES
Если в будущем вы измените TCP-порт, необходимо будет еще раз выполнить команду setspn с новым номером порта. Кроме того, необходимо будет добавить новое имя субъекта-службы в файл KEYTAB службы SQL Server, выполнив инструкции в следующем разделе.
Настройка KEYTAB-файла службы SQL Server
Для настройки проверки подлинности AD для SQL Server на Linux требуется учетная запись AD (учетная запись пользователя MSA или AD) и имя субъекта-службы, созданное в предыдущем разделе.
При изменении пароля для учетной записи AD или учетной записи, которой назначены имена субъектов-служб, необходимо обновить файл KEYTAB, указав новый пароль и номер версии ключа (KVNO). В некоторых службах смена паролей может происходить автоматически. Проверьте политики смены паролей для нужных учетных записей и приведите их в соответствие с запланированными действиями по обслуживанию, чтобы избежать непредвиденных простоев.
Записи имени субъекта-службы в файле KEYTAB
Определите номер версии ключа (KVNO) для учетной записи Active Directory, созданной в предыдущем шаге. Обычно он имеет значение 2, но может быть другим целым числом, если пароль учетной записи менялся несколько раз. На хост-компьютере SQL Server выполните следующие команды:
С помощью ktpassдобавьте записи KEYTAB для каждого имени субъекта-службы с помощью следующих команд в командной строке компьютера Windows:
Приведенные выше команды позволяют использовать методы шифрования AES и RC4 для проверки подлинности AD. RC4 — это старый метод шифрования, и если требуется более высокая степень безопасности, то можно создать записи KEYTAB только с методом шифрования AES. Последние две записи UserName должны быть в нижнем регистре, иначе проверка подлинности для предоставления разрешений может завершиться сбоем.
Любой пользователь, имеющий доступ к KEYTAB-файлу, может олицетворять SQL Server в домене, поэтому необходимо ограничить доступ к файлу так, чтобы только учетная запись mssql имела доступ для чтения:
Для указания учетной записи для доступа к KEYTAB-файлу необходимо задать соответствующий параметр конфигурации с помощью средства mssql-conf.
Включайте только имя пользователя, а не имя_домена\имя_пользователя или username@domain. SQL Server сам добавляет имя домена вместе с этим именем пользователя при использовании.
Чтобы настроить использование KEYTAB-файла для проверки подлинности Kerberos при запуске SQL Server, выполните указанные ниже действия.
Чтобы повысить производительность, можно отключить подключения UDP к контроллеру домена. При подключении к контроллеру домена UDP-подключения часто завершаются сбоем, поэтому в файле /etc/krb5.conf можно задать параметры конфигурации для пропуска вызовов UDP. Измените файл /etc/krb5.conf, задав следующие параметры:
Теперь все готово для использования имен входа на основе Active Directory в SQL Server.
Создание имен входа на основе Active Directory в Transact-SQL
Подключитесь к SQL Server и создайте имя входа на основе Active Directory:
Убедитесь в том, что имя входа теперь приводится в представлении системного каталога sys.server_principals:
Подключение к SQL Server с помощью проверки подлинности Active Directory
Выполните вход на клиентский компьютер, используя учетные данные домена. Теперь можно подключаться к SQL Server с помощью проверки подлинности Active Directory, не вводя пароль повторно. Если создать имя входа для группы Active Directory, все пользователи Active Directory, входящие в эту группу, смогут подключаться одинаковым образом.
Параметр строки подключения, предписывающий использование проверки подлинности Active Directory для клиентов, зависит от драйвера. Рассмотрим примеры в следующих разделах.
sqlcmd в клиенте Linux, присоединенном к домену
Выполните вход в присоединенный к домену клиент Linux с помощью ssh и учетных данных домена:
Убедитесь в том, что установлен пакет mssql-tools, а затем подключитесь с помощью sqlcmd, не указывая учетные данные:
В отличие от SQL Windows проверка подлинности Kerberos работает для локального подключения в SQL Linux. Однако вам по-прежнему необходимо предоставить полное доменное имя узла SQL Linux, а проверка подлинности AD не будет работать при попытке подключения к «.», «localhost», «127.0.0.1» и т. д.
SSMS в клиенте Windows, присоединенном к домену
Выполните вход в присоединенный к домену клиент Windows с помощью учетных данных домена. Убедитесь в том, что установлена среда SQL Server Management Studio, а затем подключитесь к экземпляру SQL Server (например, mssql-host.contoso.com ), выбрав проверку подлинности Windows в диалоговом окне Подключение к серверу.
Проверка подлинности Active Directory с использованием других клиентских драйверов
В приведенной ниже таблице представлены рекомендации для других клиентских драйверов.
| Клиентский драйвер | Рекомендация |
|---|---|
| JDBC | Используйте встроенную проверку подлинности Kerberos для подключения к SQL Server. |
| ODBC | Используйте встроенную проверку подлинности. |
| ADO.NET | Синтаксис строки подключения. |
Дополнительные параметры конфигурации
Если вы используете сторонние служебные программы, такие как PBIS, VAS или Centrify, для присоединения узла Linux к домену Active Directory и хотите настроить принудительное использование библиотеки openldap сервером SQL Server, можно настроить параметр disablesssd с помощью mssql-conf следующим образом:
В результате LDAPS через SSSD будет использоваться, если присоединение узла к домену Active Directory было выполнено с помощью пакета SSSD и параметр disablesssd не установлен в значение true. Если параметр disablesssd установлен в значение true и параметр forcesecureldap также имеет значение true, протокол LDAPS будет использоваться для вызовов библиотеки openldap, совершаемых сервером SQL Server.
Версии начиная с SQL Server 2017 с накопительным пакетом обновления 14
Начиная с SQL Server 2017 с накопительным пакетом обновления 14, если сервер SQL Server был присоединен к контроллеру домена Active Directory с помощью сторонних поставщиков и для него настроено использование вызовов openldap для общих операций просмотра в Active Directory путем задания значения true для параметра disablesssd, можно также с помощью параметра enablekdcfromkrb5 настроить принудительное использование сервером SQL Server библиотеки krb5 для просмотра KDC вместо обратного просмотра DNS для сервера KDC.
Это может быть полезно в ситуациях, когда нужно вручную настроить контроллеры домена, с которыми пытается связаться SQL Server. Механизм библиотеки openldap используется посредством списка KDC в krb5.conf.
Сначала установите параметры disablesssd и enablekdcfromkrb5conf в значение true, а затем перезапустите SQL Server:
Затем настройте список KDC в файле /etc/krb5.conf следующим образом:
Хотя делать это не рекомендуется, вы можете использовать служебные программы, такие как realmd, для настройки SSSD при присоединении узла Linux к домену и присвоить параметру disablesssd значение true, чтобы SQL Server использовал вызовы openldap вместо SSSD для вызовов, связанных с Active Directory.
Имя входа SQL Server с использованием полного доменного имени (например, CONTOSO.COM\имя_пользователя) не поддерживается. Используйте формат CONTOSO\имя_пользователя.
Имена входа SQL Server из групп локального домена не поддерживаются. Используйте группы глобальных доменов безопасности.
Дальнейшие действия
В этом руководстве были представлены пошаговые инструкции по настройке проверки подлинности Active Directory для SQL Server на Linux. Вы ознакомились с выполнением следующих задач:
Далее вы можете ознакомиться с другими сценариями обеспечения безопасности для SQL Server на Linux.
Основные средства обеспечения безопасности в SQL Server
В этой статье мы рассмотрим средства SQL Server для обеспечения безопасности и лучшие практики, связанные с настройкой и обеспечением безопасности в этой СУБД.
Для начала вспомним базовые концепции безопасности SQL Server. MSSQL управляет доступом к объектам через аутентификацию и авторизацию.
Многие объекты SQL Server имеют свои разрешения, которые могут наследоваться от вышестоящего объекта. Разрешения могут быть предоставлены отдельному пользователю, группе или роли.
Аутентификация в SQL Server
Аккаунт SQL Server можно разделить на 2 части: Имя входа и Пользователь.
Например, ваше имя входа на сервер может быть domain\username, а пользователь в базе данных, привязанный к этому имени входа может называться domain_databaseUser. Практически всегда имя входа и пользователь в базе данных совпадают по названию, но нужно иметь в виду что они могут и различаться, иметь разные имена.
SQL Server поддерживает 2 режима аутентификации:
Microsoft рекомендует использовать аутентификацию Windows, если есть такая возможность. Для аутентификации посредством логина и пароля, данные (логин и пароль) передаются по сети, хоть и в зашифрованном виде. При Windows аутентификации по сети передаётся серия зашифрованных сообщений, в которых не участвует пароль пользователя.
Но некоторые приложения, особенно старые, не поддерживают аутентификацию Windows, поэтому при установке режима аутентификации стоит учитывать какие приложения будут подключаться к серверу.
SQL Server поддерживает три типа Login Name (имен входа):
SQL Server автоматически интегрируется с Active Directory. Если вы хотите раздать права доменной учетной записи, вам нужно использовать NetBios имя домена и логин учетной записи. Например для пользователя username в домене domain.local будет верным “domain\username”.
Авторизация в SQL Server
Для авторизации SQL Server использует безопасность на основе ролей, которая позволяет назначать разрешения для роли или группы Windows/домена, а не отдельным пользователям. В SQL Server есть встроенные роли сервера и баз данных, у которых есть предопределенный набор разрешений.
В SQL Server есть 3 уровня безопасности, их можно представить, как иерархию от высшего к низшему:
Встроенные роли сервера
| Роль | Описание |
| sysadmin | Участник роли имеет полные права ко всем ресурсам SQL Server. |
| serveradmin | Участники роли могут изменять параметры конфигурации на уровне сервера и выключать сервер. |
| securityadmin | Участники роли управляют логинами и их свойствами. Они могут предоставлять права доступа GRANT, DENY и REVOKE на уровне сервера и на уровне базы данных, если имеют к ней доступ. |
securityadmin мало чем отличается от роли sysadmin, потому что участники этой роли потенциально могут получить доступ ко всем ресурсам SQL Server.
Схема ролей SQL Server:
На практике использования серверных ролей не особо распространено, потому что часто пользователю нужен уникальный набор разрешений. Исключением могут быть роль sysadmin для системных администраторов и роль public.
Встроенные роли базы данных
| Роль | Описание |
| db_owner | Участники роли могут выполнять все действия по настройке и обслуживанию базы данных, включая удаление. |
| db_securityadmin | Участники роли могут менять членство других ролей. Участники этой группы потенциально могут увеличить свои права до db_owner, поэтому стоит считать эту роль эквивалентной db_owner. |
| db_accessadmin | Участники роли могут управлять доступом к базе данных для существующих на сервере логинов. |
| db_backupoperator | Участники роли могут выполнять резервное копирование базы данных. |
| db_ddladmin | Участники роли могут выполнять любую DDL команду в базе данных. |
| db_datawriter | Участники роли могут создавать/изменять/удалять данные во всех пользовательских таблицах в базе данных. |
| db_datareader | Участники роли могут считывать данные со всех пользовательских таблиц. |
| db_denydatawriter | |
| db_denydatareader | Участникам роли запрещен доступ к пользовательским таблицам базы данных. |
Так же стоит отдельно выделить специальные роли в базе данных msdb.
| db_ssisadmin db_ssisoperator db_ssisltduser | Участники этих ролей могут администрировать и использовать SSIS (SQL Server Integration Services). |
| dc_admin dc_operator dc_proxy | Участники этих ролей могут администрировать и использовать сборщик данных. |
| PolicyAdministratorRole | Участники этой роли имеют полный доступ к политикам SQL Server |
| ServerGroupAdministratorRole ServerGroupReaderRole | Участники этих ролей имеют полный доступ к зарегистрированным группам серверов. |
| SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole | Участники этих ролей имеют полный доступ заданиям агента SQL Server |
Схема по встроенным ролям баз данных в SQL Server:
Роли приложений
Роль приложения – это объект базы данных (такой же, как и обычная роль базы данных), который позволяет с помощью аутентификации через пароль менять контекст безопасности в базе данных. В отличие от ролей баз данных, роли приложений по умолчанию находятся в неактивном состоянии и активируются, когда приложение выполняет процедуру sp_setapprole и вводит соответствующий пароль.
В отличие от обычных ролей, роли приложений практически никогда не используются. Как исключение, их применение можно найти в multi-layer приложениях.
Фильтрация данных в SQL Server
Фильтрация данных в SQL Server через хранимые процедур/представления/функции можно отнести к реализации принципу наименьших привилегий, так как вы предоставляете доступ не ко всем данным в таблице, а лишь к некоторой их части.
Например, можно предоставить пользователю права только на SELECT из представления и запретить прямой доступ к таблицам, которые используются в представлении. Таким образом вы предоставите доступ только к части данных из таблицы, задав фильтр where в представлении.
Фильтрация данных через Row-Level Security
Безопасность на уровне строк или Row-Level Security (RLS) позволяет фильтровать данные таблицы для разных пользователей по настраиваемому фильтру. Это осуществляется через SECURITY POLICY в T-SQL
На данном скриншоте политика настраивается таким образом, что пользователь Sales1 будет видеть строки таблицы, в которых значение столбца Sales равняется имени пользователя (Sales1), а пользователь Manager будет видеть все строки.
Схемы в SQL Server
У некоторых объектов SQL Server (таблицы, процедуры, представления, функции) есть схема. Схемы можно представить, как контейнеры для различных объектов (или пространство имён/namespace, если вы знакомы с программированием).
Например, если у пользователя есть права на select из схемы, то пользователь так же может делать select со всех объектов этой схемы. То есть объекты, принадлежащие схеме, наследуют её разрешения. Когда пользователи создают объекты в схеме, объекты принадлежат владельцу схемы, а не пользователю. Разрешения не наследуются от схемы пользователями. Т.е. у пользователей со схемой dbo по умолчанию, нет разрешений которые предоставлены этой схеме – они должны быть явно указаны.
Главное отличие схем от ролей в том, что разрешения на схемы могут быть предоставлены ролям. Например, у роли testrole могут быть разрешения select со схемы schema1 и разрешения на select/update на схеме schema2. Объект может принадлежать всего одной схеме, но права на него могут быть у нескольких ролей.
Встроенные схемы
В SQL Server есть встроенные системные схемы:
Схема dbo является схемой по умолчанию для новых баз данных, а пользователь dbo является владельцем схемы dbo. По умолчанию, новые пользователи в базе данных имеют схему dbo в качестве схемы по умолчанию. Другие встроенные схемы нужны для системных объектов SQL Server.
Шифрование данных средствами SQL Server
SQL Server может шифровать данные, процедуры и соединения с сервером. Шифрование возможно с использованием сертификата, асимметричного или симметричного ключа. В SQL Server используется иерархичная модель шифрования, то есть каждый слой иерархии шифрует слой под ним. Поддерживаются все известные и популярные алгоритмы шифрования. Для реализации алгоритмов шифрования используется Windows Crypto API.
Самыми распространенными типами шифрования являются TDE (Прозрачное шифрование данных) и Always Encrypted.
Прозрачное шифрование данных
Диаграмма, для того чтобы представить весь процесс
Базовое шифрование базы данных через T-SQL:
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘password’;
go
CREATE CERTIFICATE ServerCert WITH SUBJECT = ‘DEK Certificate’;
go
USE AdventureWorks2012;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE ServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO
Always Encrypted
Эта технология позволяет хранить шифрованные данные в SQL Server без передачи ключей шифрования самому SQL Server. Always Encrypted так же как и TDE шифрует данные в базе данных, но не на уровне базы, а на уровне столбца.
Для шифрования Always Encrypted использует 2 ключа:
Все процессы шифрования и дешифрования данных происходят на клиенте, в базе данных хранятся только зашифрованное значение ключа шифрования (CEK).
Always Encrypted так же позволяет ограничить доступ к данным даже для DBA, таким образом давая возможность не беспокоиться о том, что администратор получит доступ к данным, к которым не должен.
Когда стоит использовать шифрование SQL Server?
Шифрование данных это одна из важных мер обеспечения безопасности, но шифрование может быть требовательно к ресурсам сервера и иногда может быть лишним.
Если пользователи обращаются к данным через общедоступную сеть, то для обеспечения безопасности может потребоваться шифрование, но если данные передаются по защищенной интрасети или ВПН, то необходимости в шифровании данных нет. Так же стоит рассмотреть возможность шифрования данных, если есть угроза кражи физического носителя с базами данных.
Внедрение шифрования должно быть хорошо спланировано: нужно учесть дополнительную нагрузку на сервер, могут ли приложения, которые работают с вашим сервером внедрить поддержку шифрования данного типа на своей стороне и многие другие нюансы.
Использование Group Managed Service Accounts для SQL Server
Групповые управляемые учетные записи службы или gMSA – это специальная учетная запись, которая автоматически управляется Active Directory. gMSA это развитие технологии MSA, так как MSA было невозможно использовать в кластерных сценариях.
gMSA исключает необходимость вручную менять пароли для учетной записи. При настройке gMSA вы указываете на каких серверах будет работать gMSA аккаунт, как часто Active Directory будет менять пароль, и кто имеет право на просмотр пароля. На серверах, на которых будет установлен gMSA не нужно указывать пароль при указании соответствующей учетной записи gMSA.
Имейте в виду, что версия Windows Server для работы с gMSA должна быть не ниже 2012.
Оценка уязвимостей SQL Server через SSMS
В SQL Server Management Studio есть функция оценки уязвимостей для базы данных.
Сканнер оценит базу данных на предмет популярных ошибок в конфигурации безопасности и даст соответствующие рекомендации.
Обязательно стоит пройтись этим сканнером по вашим базам данных. Он может выявить скрытые проблемы, которых не видно на первый взгляд.
Аудит активности в SQL Server
SQL Server предоставляет возможность вести аудит любой пользовательской активности в экземпляре сервера.
Это очень мощный инструмент, который позволяет полностью контролировать действия ваших пользователей/разработчиков.
Рассмотрим базовую настройку аудита:
Затем, для аудита нужно создать Спецификацию (Audit Specification), для указания событий, которые будут отслеживаться.
После того как вы создадите и активируете аудит, в журнале аудита можно будет посмотреть события, которые зафиксированы процедурой аудита.
Общие рекомендации по безопасности SQL Server
Всегда следуйте принципу наименьших привилегий. В том числе настройте аккаунт службы SQL Server с помощью gMSA. Ни в коем случае не используйте доменный аккаунт с привилегиями администратора домена.
Принцип наименьших привилегий
Когда вы заводите новых пользователей, рекомендуется использовать принцип LUA (Least-privileged User Account или Аккаунт с Наименьшими Правами). Этот принцип является важной частью безопасности сервера и данных.
Для пользователей с административными правами рекомендуется выдавать разрешения только на те операции, которые им будет необходимы. Встроенные серверные роли стоит использовать только тогда, когда набор их разрешений полностью совпадает с задачами пользователя.
Предоставление прав ролям, а не пользователям
Когда пользователей становится много, управлять их разрешениями становится сложнее, и также становится сложнее не допустить ошибки в предоставлении прав.
Рекомендуется предоставлять разрешения ролям, а пользователей добавлять в роли. Таким образом вы добьетесь большей прозрачности, так как все пользователи той или иной роли будут иметь одинаковые права. Добавить или удалить пользователей из роли проще, чем воссоздать отдельные наборы разрешений для отдельных пользователей. Роли могут быть вложенными, но так делать не рекомендуется, из-за меньшей прозрачности и потенциального ухудшения производительности (если вложенных ролей станет слишком много).
Можно предоставить права пользователю на схему. В этом случае пользователи сразу смогут работать с вновь созданными объектами в этой схеме, в отличии от ролей, когда при создании нового объекта, роли нужно будет раздать на него права.