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

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

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

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

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

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

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

Аккаунт Microsoft SQL Server можно разделить на 2 части: 

Имя входа   и  Пользователь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Уровень сервера  – на этом уровне можно раздать права на базы данных, учетные записи, роли сервера и группы доступности;
• Уровень базы данных   включают в себя схемы, пользователи базы данных, роли базы данных и полнотекстовые каталоги;
• Уровень схемы   включают такие объекты, как таблицы, представления, функции и хранимые процедуры.

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

Роль

Описание

sysadmin

Участник роли имеет полные права ко всем ресурсам SQL Server.

serveradmin

Участники роли могут изменять параметры конфигурации на уровне сервера и выключать сервер. Securityadmin мало чем отличается от роли sysadmin, потому что участники этой роли потенциально могут получить доступ ко всем ресурсам SQL Server.

securityadmin

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

processadmin

Участники роли могут завершать процессы, запущенные в SQL Server.

setupadmin

Участники роли могут добавлять и удалять связанные серверы с помощью TSQL.

bulkadmin

Участники роли могут запускать BULK INSERT операции.

diskadmin

Участники роли могут управлять устройствами резервного копирования. На практике эта роль практически не применяется.

dbcreator

Участники роли могут создавать, изменять, удалять и восстанавливать базы данных.

public

Каждый логин SQL Server находится в этой роли. Изменить членство public нельзя. Когда у пользователя нет разрешения для объекта, к которому он получает доступ, пользователь наследует разрешения public роли для этого объекта.

На практике использования серверных ролей не особо распространено, потому что часто пользователю нужен уникальный набор разрешений. Исключением могут быть роль 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

Участники этих ролей могут администрировать и использовать SSIS (SQL Server Integration Services).

dc_admin

PolicyAdministratorRole

db_ssisltduser

dc_operator

Участники этих ролей могут администрировать и использовать сборщик данных.

dc_proxy

Участники этой роли имеют полный доступ к политикам SQL Server

ServerGroupAdministratorRole

ServerGroupReaderRole

Участники этих ролей имеют полный доступ к зарегистрированным группам серверов.

SQLAgentUserRole SQLAgentReaderRole SQLAgentOperatorRole

Участники этих ролей имеют полный доступ заданиям агента SQL Server

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

Роли приложений

Роль приложения – это объект базы данных (такой же, как и обычная роль базы данных), который позволяет с помощью аутентификации через пароль менять контекст безопасности в базе данных. В отличие от ролей баз данных, роли приложений по умолчанию находятся в неактивном состоянии и активируются, когда приложение выполняет процедуру sp_setapprole и вводит соответствующий пароль.

В отличие от обычных ролей, роли приложений практически никогда не используются. Как исключение, их применение можно найти в multi-layer приложениях.

Фильтрация данных в Microsoft SQL Server

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

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

Фильтрация данных через Row-Level Security

Безопасность на уровне строк  или  Row-Level Security (RLS) позволяет фильтровать данные таблицы для разных пользователей по настраиваемому фильтру. Это осуществляется через SECURITY.

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

Схемы в Microsoft SQL Server

У некоторых объектов Microsoft SQL Server (таблицы, процедуры, представления, функции) есть схема. Схемы можно представить, как контейнеры для различных объектов (или пространство имён.

Например, если у пользователя есть права на select из схемы, то пользователь так же может делать select со всех объектов этой схемы. То есть объекты, принадлежащие схеме, наследуют её разрешения. Когда пользователи создают объекты в схеме, объекты принадлежат владельцу схемы, а не пользователю. Разрешения не наследуются от схемы пользователями. Т.е. у пользователей со схемой dbo по умолчанию, нет разрешений которые предоставлены этой схеме – они должны быть явно указаны.

Главное отличие схем от ролей в том, что разрешения на схемы могут быть предоставлены ролям. Например, у роли testrole могут быть разрешения select со схемы schema1 и разрешения на select/update на схеме schema2. Объект может принадлежать всего одной схеме, но права на него могут быть у нескольких ролей.

Встроенные схемы

В SQL Server есть встроенные системные схемы:

• dbo
• guest
• sys
• INFORMATION_SCHEMA

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

Шифрование данных средствами Microsoft SQL Server

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

Самыми распространенными типами шифрования являются TDE (Прозрачное шифрование данных) и Always Encrypted.

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

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

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

Базовое шифрование базы данных через T-SQL:

(Выделяются две разновидности языка SQL: PL-SQL и T-SQL. PL-SQL используется в таких СУБД как Oracle и MySQL. T-SQL (Transact-SQL) применяется в Microsoft SQL Server. )

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

Эта технология позволяет хранить шифрованные данные в Microsoft SQL Server без передачи ключей шифрования самому Microsoft SQL Server. Always Encrypted так же как и TDE шифрует данные в базе данных, но не на уровне базы, а на уровне столбца.

Для шифрования Always Encrypted использует 2 ключа:

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

Все процессы шифрования и дешифрования данных происходят на клиенте, в базе данных хранятся только зашифрованное значение ключа шифрования (CEK).

Always Encrypted так же позволяет ограничить доступ к данным даже для DBA, таким образом давая возможность не беспокоиться о том, что администратор получит доступ к данным, к которым не должен.

Когда стоит использовать шифрование в Microsoft SQL Server?

Шифрование данных - это одна из важных мер обеспечения безопасности, но шифрование может быть требовательно к ресурсам сервера.

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

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

Использование Group Managed Service Accounts для SQL Server

Групповые управляемые учетные записи службы  или  gMSA   – это специальная учетная запись, которая автоматически управляется Active Directory.

gMSA - это развитие технологии MSA, так как MSA было невозможно использовать в кластерных сценариях.

gMSA исключает необходимость вручную менять пароли для учетной записи. При настройке gMSA указывают на каких серверах будет работать gMSA аккаунт, как часто Active Directory будет менять пароль, и кто имеет право на просмотр пароля. На серверах, на которых будет установлен gMSA, не нужно указывать пароль при указании соответствующей учетной записи gMSA.

Оценка уязвимостей SQL Server через SSMS

В SQL Server Management Studio есть функция оценки уязвимостей для базы данных.

  Tasks  -  Vulnerability Assessment  -  Scan For Vulnerabilities . Сканнер оценит базу данных на предмет популярных ошибок в конфигурации безопасности и даст соответствующие рекомендации. " width="640"

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

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

Audits создайте новый аудит. " width="640"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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