Active directory authentication library for sql server что это за программа

1. По сравнению с аутентификацией SQL — она более безопасна, тк не передается логин и пароль, а используется встроенные механизмы безопасности Windows, токены или сертификаты
2. Централизованное управление (созданиеизменениеблокирование) учетными записями на уровне windows машины или инфраструктуры AD
3. Удобство пользователя: локально подключение осуществляется через сессию Windows

Преимущества аутентификации SQL сервер

1. Обеспечение поддержки устаревших систем
2. Возможность минимизировать взаимодействие с внешними системами. Например, при предоставлении доступа только УЗ SQL, можно ограничить перечень УЗ, которым позвонено получать доступ к данным, причем централизованное упраление УЗ не позволит к ним подключиться просто сменив пароль на уровне AD
3. Возможность в рамках одной сессии настроит разные процессы с разными правами доступа.

Как изменить тип аутентификации в Microsoft SQL Server 2019

Самый простой способ изменения типа аутентификации SQL, это использование графического интерфейса SQL Server Management Studio (SSMS).

SSMS -включен в полную версию дистрибутива SQL Server, а также его можно бесплатно скачать с сайта Microsoft по ссылке: SSMS .

1. Запустить SSMS, и указать имя целевого SQL сервера
2. Подключиться и выбрать свойства сервера (Properties)

3. Перейти на закладку Security и выбрать необходимый режим проверки подлинности.
4. Нажать ОК
5. в случае, если режим аутентификации менялся, то для применения настроек, необходимо выполнить перезапуск службы SQL Server или перезагрузить сервер целиком.

Источник: userman.ru

Deploying and configuring Active Directory authentication with SQL Server 2017 on Amazon Linux 2

SQL Server on Windows allows you to configure SQL Server instances to use Windows authentication with Active Directory accounts. This post addresses how to do that with SQL Server 2017 on Amazon Linux 2. This solution allows you to log in with your Active Directory accounts using Windows authentication to manage SQL Server Linux instances on Amazon EC2.

In this post, you learn how to do the following:

1. Deploy and join SQL Server Linux instance to your domain.
2. Create a new Active Directory user and set the Service Principal Name for SQL Server Linux.
3. Add a SQL Server service keytab; you use the keytab file to authenticate to Active Directory.
4. Create an Active Directory based SQL login using SQL Server Management Studio (SSMS).
5. Test the Windows Authentication with SSMS from a Windows machine using a domain account.

Walkthrough

Follow these steps to deploy and configure Active Directory authentication with SQL Server 2017 on Amazon Linux.

Prerequisites

Before starting, you need:

• An Active Directory domain: It can be on-premises Windows domain or a Windows domain running on EC2. You can also use AWS Managed Microsoft AD or Simple AD (Samba) in AWS Directory Services.
• SQL Server 2017 Linux (Express, Web, Standard, or Enterprise Edition) on Amazon Linux 2.
• A Windows Server (2012 R2 or 2016) machine joined to the same domain. Install SQL Server Management Studio (SSMS) to connect to the SQL instance, and Active Directory management tools to manage the domain.

Step 1: Deploy and join SQL Server Linux instance to your domain

First, you must deploy and join a SQL Server Linux instance to your domain.

Deploy SQL Server 2017 Express, Web, Standard, or Enterprise edition on Amazon Linux 2. This post uses an Amazon Linux 2 instance with SQL Server 2017 Enterprise edition.

Use SSH to connect to your Linux instance and refer to these steps to join your Linux instance to the domain:

Make sure to change example.local to your domain name and verify that the joiner Active Directory account has permissions to create computer objects.

If the Linux machine joins successfully, you should get the following message at the end:* Successfully enrolled machine in realm.

Step 2: Create a new Active Directory user and set the service principal name for SQL Server Linux:

Use Remote Desktop Protocol (RDP) to connect to your Windows machine with Active Directory management tools. Create a SQL Server account to run the service in Linux. The user account name can be anything you want it to be. You can also use an existing Active Directory account instead of creating a new account.

To associate the SQL Server Linux instance with the service account, create the service principal name (SPN).

From a Windows domain joined machine, open PowerShell as administrator, and run the following command:

setspn -A MSSQLSvc/SQL-LINUX.corp.local:1433 nour

This Linux instance hostname is “SQL-LINUX” and the Active Directory account name is “nour”. Make sure to change it to your applicable Hostname and Active Directory account logon name. If SQL Server is configured to listen on a different TCP port, make sure to change it to that port. Also note that SPNs may take some time to propagate through your domain.

In the attribute editor, you should also see the following:

Step 3: Add a SQL Server service keytab

You use a keytab file to authenticate to Active Directory.

Acquire a Kerberos ticket for your service account by running the following command from the Linux host.

It prompts you to enter your Active Directory account password. Make sure to replace “nour” with your account logon name, and capitalize all the letters of your applicable domain name.

After you enter the Active Directory password, run the following command to use the kvno tool to configure the SPN.

Take a note of the key version number “kvno” for the Active Directory account service account. It should be number “2,” but it can be different if the password has changed before.

Make sure to change SQL-LINUX to your applicable Linux Hostname. Also change corp.local to your applicable domain name. You might get something similar to the following error: kvno:server not found in kerberos database while …. If so, allow some time before running the command again. It may be because the SPN info hasn’t replicated to other domain controllers in your environment.

If everything goes well, you should see the following:

Now, create the keytab file for the SQL Server service account using the ktutil utility. A keytab file is used to authenticate into your Windows domain using Kerberos and without entering a password. If you ever plan to change the Active Directory password in the future, you must create a new keytab file again.

Run the following commands from your Linux SQL host. Make sure to change SQL-Linux to your applicable Linux hostname and corp.local to your domain name. The ktutil utility doesn’t validate the correct Active Directory password, so make sure that you type the correct Active Directory password for the SQL Server service account. I added -k 2 for the key version kvno . If you get a different number in step 3, make sure to use that number.

After you run ktutil, run the following commands:

Anyone who has access to this keytab file can impersonate the service account on the Active Directory domain. Make sure to restrict access to the keytab file to only allow the mssql account to have read access.

sudo chown mssql:mssql /var/opt/mssql/secrets/mssql.keytab sudo chmod 400 /var/opt/mssql/secrets/mssql.keytab

Configure SQL Server on Linux to use Kerberos authentication and restart SQL Server service. Run the following commands from the Linux host.

sudo /opt/mssql/bin/mssql-conf set network.kerberoskeytabfile /var/opt/mssql/secrets/mssql.keytab sudo systemctl restart mssql-server

Step 4: Create an Active Directory–based SQL login using SQL Server Management Studio

Follow these steps to create an Active Directory–based SQL login with SQL Server Management Studio (SSMS).

If you deployed a SQL Server 2017 instance from an Amazon Linux 2 AMI, run the following command to reset the sa password.

sudo systemctl stop mssql-server sudo /opt/mssql/bin/mssql-conf set-sa-password sudo systemctl start mssql-server

1. Make sure to create a record in DNS to point to the SQL Linux instance IP address in the VPC. If you want to connect using the IP address, make sure to create a PTR record. If you don’t have a DNS server, you can modify the host file in Windows.
2. Load SQL Server Management Studio from a Windows machine that is part of the same domain and connect to the SQL Linux instance using the sa
3. After you log in with the sa account, you must create an SQL login for your domain account so it can use Windows Authentication.
4. Assign a Server Role to the domain account.

Step 5: Test the Windows authentication with SSMS from a Windows machine using a domain account

This is an example:

You are now ready to login and administer your SQL Server on Linux using your Windows Active Directory accounts.

About the Author

Noureddine Ennacir is a Cloud Support Engineer with Amazon Web Services.

Источник: aws.amazon.com

Основные средства обеспечения безопасности в SQL Server

07.02.2020

insci

SQL Server

Комментариев пока нет

В этой статье мы рассмотрим средства SQL Server для обеспечения безопасности и лучшие практики, связанные с настройкой и обеспечением безопасности в этой СУБД.

Для начала вспомним базовые концепции безопасности SQL Server. MSSQL управляет доступом к объектам через аутентификацию и авторизацию.

Аутентификация — это процесс входа в SQL Server, когда пользователь отправляет свои данные на сервер. Аутентификация устанавливает личность пользователя, который проходит аутентификацию;

Многие объекты SQL Server имеют свои разрешения, которые могут наследоваться от вышестоящего объекта. Разрешения могут быть предоставлены отдельному пользователю, группе или роли.

Аутентификация в SQL Server

Аккаунт SQL Server можно разделить на 2 части: Имя входа и Пользователь.

• Имя входа – это глобальный логин для всего экземпляра SQL Server. С помощью него вы проходите процесс аутентификации;
• Пользователь – это участник базы данных, привязанный к определенному Имени Входа.

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

SQL Server поддерживает 2 режима аутентификации:

• Аутентификация Windows (Windows Authentication) – аутентификация осуществляется с помощью системы безопасности Windows. Пользователям, которые уже аутентифицированы в Windows и имеют права на SQL Server не нужно предоставлять дополнительные учетные данные.
• Смешанный режим аутентификации (Mixed Mode Authentication) – в этом режиме помимо аутентификации Windows поддерживается аутентификация самого SQL Server через логин и пароль.

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

Но некоторые приложения, особенно старые, не поддерживают аутентификацию Windows, поэтому при установке режима аутентификации стоит учитывать какие приложения будут подключаться к серверу.

SQL Server поддерживает три типа Login Name (имен входа):

• Локальная учетная запись пользователя Windows или учетная запись домена/доверенного домена.
• Группа Windows. Предоставление доступа локальной группе Windows или группе из AD домена. Позволяет предоставить доступ ко всем пользователям, которые являются членами группы.
• Логин SQL Server (SQL Server authentication). SQL Server хранит имя пользователя и хэш пароля в базе данных master, используя методы внутренней аутентификации для проверки входа в систему.

SQL Server автоматически интегрируется с Active Directory. Если вы хотите раздать права доменной учетной записи, вам нужно использовать NetBios имя домена и логин учетной записи. Например для пользователя username в домене domain.local будет верным “domainusername”.

Авторизация в SQL Server

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

В SQL Server есть 3 уровня безопасности, их можно представить, как иерархию от высшего к низшему:

Встроенные роли сервера

Роль	Описание
sysadmin	Участник роли имеет полные права ко всем ресурсам SQL Server.
serveradmin	Участники роли могут изменять параметры конфигурации на уровне сервера и выключать сервер.
securityadmin	Участники роли управляют логинами и их свойствами. Они могут предоставлять права доступа GRANT, DENY и REVOKE на уровне сервера и на уровне базы данных, если имеют к ней доступ.

Схема ролей 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_ssisoperator

dc_operator

Заметка: имейте в виду, что участники ролей dc_ssisadmin и dc_admin могут повысить свои права до уровня sysadmin.

Схема по встроенным ролям баз данных в 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.

Прозрачное шифрование данных

Прозрачное шифрование данных или Transparent Data Encryption шифрует всю базу целиком. При краже физического носителя или .mdf/.ldf файла, злоумышленник не сможет получить доступ к информации в базе данных.

Диаграмма, для того чтобы представить весь процесс

Базовое шифрование базы данных через 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 ключа:

• Column Encryption Key (CEK)
• Column Master Key (CMK)

Все процессы шифрования и дешифрования данных происходят на клиенте, в базе данных хранятся только зашифрованное значение ключа шифрования (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 есть функция оценки уязвимостей для базы данных.

Выберите базу данных -> Tasks -> Vulnerability Assessment -> Scan For Vulnerabilities.

Сканнер оценит базу данных на предмет популярных ошибок в конфигурации безопасности и даст соответствующие рекомендации.

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

Аудит активности в SQL Server

SQL Server предоставляет возможность вести аудит любой пользовательской активности в экземпляре сервера.

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

Рассмотрим базовую настройку аудита:

В SSMS, во вкладке Security -> Audits создайте новый аудит.

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

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

Общие рекомендации по безопасности SQL Server

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

Принцип наименьших привилегий

Когда вы заводите новых пользователей, рекомендуется использовать принцип LUA (Least-privileged User Account или Аккаунт с Наименьшими Правами). Этот принцип является важной частью безопасности сервера и данных.

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

Предоставление прав ролям, а не пользователям

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

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

Можно предоставить права пользователю на схему. В этом случае пользователи сразу смогут работать с вновь созданными объектами в этой схеме, в отличии от ролей, когда при создании нового объекта, роли нужно будет раздать на него права.

Предыдущая статья Следующая статья

Источник: winitpro.ru