Безопасность серверов баз данных MS SQL в облаке Azure

Как мы и обещали в статье « Миграция on-prem базы данных SQL Server в Azure SQL », в этой статье речь пойдет о настройках безопасности для службы баз данных в Azure. У этой службы есть множество функций, связанных с безопасностью, которые можно использовать в различных сценариях развертывания MS SQL.

1. Пароль администратора сервера SQL

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

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

• Пароль не должен являться словом из словаря, сленга, диалекта, жаргона;
• Пароль не должен содержать персональную информацию (дату рождения, имя, телефон и т.д).
• Пароль не должен совпадать с именем веб-приложения, если сервер базы данных используется для приложения.
• Пароль не должен совпадать с URL сайта или именем домена
• Рекомендуется проверить не входит ли ваш пароль в список популярных паролей. Список таких паролей легко найти в Интернете.

2. Настройка Networking для Azure SQL

Параметр Allow Azure services and resources to access this server должен быть отключен. Если включить его параметр, то брандмауэр будет разрешать абсолютно все подключения из Azure, включая подключения из подписок других клиентов.

Можно включить Azure Defender for SQL. Это платная опция, которая включает оценку уязвимостей и защиту от угроз.

Настройки брандмауэра в разделе Firewall and virtual networks можно изменить после создания виртуального SQL сервера.

Как мы видим, здесь есть правило, разрешающее трафик с клиентского IP-адреса. Это публичный IP-адрес, назначенный клиенту. При смене этого адреса вы уже не сможете подключиться к SQL серверу. При повторном подключении при помощи Microsoft SQL Server Management Studio появится запрос на создание нового подключения:

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

Публичная конечная точка (public endpoint) позволяет подключиться к облачному SQL серверу из Интернет. Существует несколько сценариев подключения SQL-сервера к общедоступной конечной точке:

• Управляемый экземпляр должен интегрироваться с предложениями «платформа как услуга» (PaaS) только для нескольких клиентов.
• Вам нужна более высокая пропускная способность обмена данными, чем это возможно при использовании VPN.
• Политика компании запрещает PaaS внутри корпоративных сетей.

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

Подробнее о защите сетевого подключения рассказывается в документации Microsoft: https://docs.microsoft.com/ru-ru/azure/azure-sql/managed-instance/public-endpoint-overview

Если необходимо обеспечить более высокий уровень безопасности для инфраструктуры веб-приложения, то соединения с SQL сервером может происходить при помощи частной конечной точки (private endpoint). Частная конечная точка — это сетевой интерфейс, который использует частный IP-адрес виртуальной сети. Такое соединение обеспечивает быстрое, безопасное и надежное подключение к службе с помощью частной сети Azure.

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

Для шифрации данных между клиентским приложением и Microsoft Azure используется протокол TLS. Сейчас MS Azure использует три версии протокола TLS: 1.0, 1.1 и 1.2. Для публичных конечных точек используется версия TLS 1.2, но более старые версии пока поддерживаются для обеспечения обратной совместимости со старыми веб-приложениями. Более подробно о настройке протокола TLS можно прочитать в документации Microsoft: https://docs.microsoft.com/ru-ru/azure/storage/common/transport-layer-security-configure-minimum-version?tabs=portal

3. Аутентификация Azure AD в SQL

При создании Azure SQL мы получили одну учетную запись, включающую логин и пароль. Для управления доступом к базе данных рекомендуется использовать Azure AD.

Для этого необходимо перейти в базу данных, которую мы будем настраивать и выбрать Active Directory admin .

После этого назначим администратора SQL Server ( Set admin ), выбрав учетную запись из списка пользователей.

После того, как мы назначили администратора, с этой учетной записью можно войти при помощи Microsoft SQL Server Management Studio:

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

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

Добавим роль db_datareader группе test_gp в базе данных appdb . Эта роль позволяет только читать данные из базы данных appdb. Для этого необходимо выполнить следующий запрос в базе данных appdb:

CREATE USER " [email protected] " FROM EXTERNAL PROVIDER;
exec sp_addrolemember 'db_datareader', 'test_gp@@test234.onmicrosoft.com' WITH DEFAULT_SCHEMA = [dbo];

FROM EXTERNAL PROVIDER указывает на то, что Azure AD является нашей службой каталогов.

4. Azure RBAC

Azure RBAC (Role Based Access Control) позволяет управлять доступом на основе ролей. Эта служба представляет собой систему авторизации, основанную на AzureResource Manager, обеспечивающей гранулированное управление доступом к ресурсам Azure.

Способ управления доступом к ресурсам при помощи Azure RBAC заключается, как следует из названия, заключается в назначении ролей. Роль состоит из трех элементов: участника безопасности (security principal), определения роли (role definition), и области действия (scope).

• Субъект безопасности — это объект, предоставляющий пользователя, группу, Service principal или Managed identity, запрашивающие доступ к ресурсам Azure. Вы можете назначить роль любому из этих субъектов.

• Определение роли — это набор разрешений. Обычно определение роли просто называется ролью. В определении роли перечислены действия, которые можно выполнять, например, чтение, запись или удаление.

  
  

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

Рассмотрим, как можно использовать субъект безопасности Managed identity для подключения веб-приложения при помощи Managed identity и зачем использовать именно эту идентификацию.

Обычно строка подключения (connection string) для подключения приложения к базе данных SQL Azure содержит имя пользователя и пароль. Если эти данные хранятся в KeyVault, пароль требует регулярной смены и всегда есть риск компрометации, например, если небрежные разработчики хранят пароли на своих компьютерах. Чтобы избежать компрометации пароля, приложение может подключаться к базе данных без учетных данных, используя проверку подлинности AAD и управляемую идентификацию (Managed Identity). Для использования этой функции сначала необходимо установить Azure Active Directory Admin на сервер базы данных.

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

Следующим шагом создадим managed identity. Для этого для Identity включим System assigned.

Для подключения к базе данных нам нужна учетная запись пользователя в базе данных. Создадим автономного пользователя, это может сделать только администратор в группе grp-sqladmin. Автономный пользователь должен имеет то же имя, что и приложение. Создадим автономного пользователя для приложения my-app:

CREATE USER [my-app] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-app];
ALTER ROLE db_datawriter ADD MEMBER [my-app];

Следующим шагом необходимо установить драйвер Microsoft.Data.SqlClient v. 3.0.0.

Этот драйвер получает токен от AAD, присоединяет его к соединению SQL и обрабатывает кэширование и обновление токенов.

Когда приложение подключается к базе данных Azure SQL с использованием аутентификации AAD, в строке подключения к базе данных должно быть указано ключевое слово Authentication и задан тип аутентификации (Active Directory Managed Identity или Active Directory Default). Будем использовать аутентификацию AD по умолчанию, тогда строка подключения для подключения базы данных будет иметь вид:

Server=my-sql-server.database.windows.net,1433;Database=my-database;Authentication=Active Directory Default

Подробнее о подключении приложения при помощи управляемой идентификации можно прочитать в документации Microsoft:

https://docs.microsoft.com/en-us/azure/app-service/tutorial-connect-msi-sql-database?tabs=windowsclient%2Cdotnet

5. Always Encrypted в Azure SQL

При помощи функции Always Encrypted можно шифровать несколько столбцов, расположенных в одной или в разных таблицах, а также зашифровать определенный столбец. Опция Always Encrypted позволяет шифровать не только хранимые данные, но и передаваемые данные. Клиентское приложение также должно поддерживать шифрование.

Существует два вида шифрования:

• Deterministic encryption — для любого заданного текстового значения генерируется одно и то же зашифрованное значение. Это менее безопасно. Но это позволяет выполнять поиск, объединения по равенству, группировку и индексирование по зашифрованным столбцам.
• Randomized encryption – более безопасное шифрование. Но оно не позволяет выполнить поиск, группировку и индексирование по зашифрованным столбцам.

Можно включить функцию Always Encrypted при помощи SQL Server Management Studio. При включении этой функции в базе данных создается два ключа.

• Column master key – этот ключ необходимо сохранить во внешнем хранилище (или в хранилище сертификатов Windows или в службе Azure key vault).
• Column Encryption key – этот ключ генерируется из ключа Column master key и используется для шифрования любых столбцов.

Теперь пользователю, который хочет воспользоваться функцией Always Encrypted, необходимо задать необходимые разрешения на ключи (create, get, list, sign, verify, wrapKey, unwrapKey).

Зашифруем столбец EmailAddress в базе данных appdb, таблицы SalesLT.Customer. Эта данные необходимо шифровать при помощи ключа шифрования. Эти ключи должны храниться в Azure key vault. Пользователь, который выполняет это шифрование (demousrC), должен иметь разрешения на выполнение этой операции.

Теперь перейдем в таблицу SalesLT.Customer и выберем столбец, который мы будем шифровать.

В открывшемся мастере выберем столбец, тип шифрования и ключ.

Теперь столбец, содержащий email клиентов, будет зашифрован:

В таблице Always Encrypted Keys содержатся ключи шифрования: Column Master Keys и Column Encryption Keys.

В Azure ключи хранятся в Azure key vault.

6. Маскирование данных в Azure SQL

Для защиты данных и соблюдения правил безопасности, таких как GDPR и HIPAA, базы данных, используемые разработчиками и тестировщиками не должны содержать конфиденциальные данных из баз данных, используемых в производственных базах данных. Маскировка данных – это замена конфиденциальной информации случайными значениями. Эти значения можно получить, изменив полностью или частично содержимое исходного столбца.

Существуют несколько типов маскировки данных:

• Credit Card masking rule – используется для маскировки столбцов, содержащих данные кредитных карт. Показывается только последние 4 цифры.
• Email – Показываются только первые 4 символа адреса электронной почты. Все доменные имена заменяются на xxx.com
• Custom text – маскировка любого текста. Вы можете сами решить, какие символы поля нужно замаскировать.
• Random number – можно сгенерировать случайный набор цифр для поля.

Перейдем в раздел Security сервера баз данных и выберем там Dynamic Data Masking :

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

Функция маскировки применяется только для непривилегированных пользователей системы. Администраторы видят немаскированные данные.

Безопасность SQL Server – очень важная тема, отличающаяся глубиной и разнообразием. В этой статье мы рассмотрели не все аспекты безопасности облачного SQL Server, но осветили основные и достаточно важные моменты.