Рекомендации по защите баз данных PaaS в Azure

2025-04-21

В этой статье рассматривается коллекция рекомендаций по обеспечению безопасности Базы данных SQL Azure и Azure Synapse Analytics для защиты веб-приложений как службы (PaaS). Эти рекомендации основаны на нашем опыте, полученном в процессе использования Azure AD, и на отзывах других пользователей.

База данных SQL Azure и Azure Synapse Analytics предоставляют реляционную службу баз данных для веб-приложений. Давайте рассмотрим службы, которые помогают защитить приложения и данные при использовании базы данных SQL Azure и Azure Synapse Analytics в развертывании PaaS:

Проверка подлинности Microsoft Entra (вместо проверки подлинности SQL Server)
Брандмауэр SQL Azure
Прозрачное шифрование данных (TDE)

Использование централизованного репозитория удостоверений

Базу данных SQL Azure можно настроить для использования одного из двух типов проверки подлинности:

Проверка подлинности SQL использует имя пользователя и пароль. При создании сервера для базы данных вы указали имя входа администратора сервера с именем пользователя и паролем. С помощью этих учетных данных можно пройти проверку подлинности в любой базе данных на этом сервере в качестве владельца базы данных.
Проверка подлинности Microsoft Entra использует удостоверения, управляемые идентификатором Microsoft Entra, и поддерживается для управляемых и интегрированных доменов. Чтобы использовать проверку подлинности Microsoft Entra, необходимо создать другого администратора сервера с именем "администратор Microsoft Entra", который разрешен для администрирования пользователей и групп Microsoft Entra. Этот администратор также может выполнять все операции, доступные обычному администратору.

Проверка подлинности Microsoft Entra — это механизм подключения к базе данных SQL Azure и Azure Synapse Analytics с помощью удостоверений в идентификаторе Microsoft Entra. Идентификатор Microsoft Entra предоставляет альтернативу проверке подлинности SQL Server, чтобы остановить распространение удостоверений пользователей на серверах баз данных. Проверка подлинности Microsoft Entra позволяет централизованно управлять удостоверениями пользователей базы данных и другими службами Майкрософт в одном центральном расположении. Централизованное управление удостоверениями позволяет использовать единое расположение для управления пользователями и упрощает управление разрешениями.

Преимущества использования идентификатора Microsoft Entra вместо проверки подлинности SQL

Позволяет смену паролей в одном месте.
Управляет разрешениями базы данных с помощью внешних групп Microsoft Entra.
Устраняет хранение паролей путем включения встроенной проверки подлинности Windows и других форм проверки подлинности, поддерживаемых идентификатором Microsoft Entra.
Использует пользователей изолированной базы данных для проверки подлинности удостоверений на уровне базы данных.
Поддерживает проверку подлинности на основе маркеров для приложений, подключающихся к базе данных SQL.
Поддерживает федерацию домена со службами федерации Active Directory (ADFS) или собственной проверкой подлинности пользователя или пароля для локального идентификатора Microsoft Entra без синхронизации домена.
Поддерживает подключения из СРЕДЫ SQL Server Management Studio, использующую универсальную проверку подлинности Active Directory, которая включает многофакторную проверку подлинности (MFA). Многофакторная проверка подлинности включает надежную проверку подлинности с помощью нескольких простых параметров проверки подлинности. Параметры проверки : телефонный звонок, текстовое сообщение, смарт-карты с закреплением или уведомление мобильного приложения. Дополнительные сведения см. в статье "Универсальная проверка подлинности с помощью базы данных SQL" и Azure Synapse Analytics.

Дополнительные сведения о проверке подлинности Microsoft Entra см. в следующих статье:

Замечание

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

Ограничение доступа на основе IP-адреса

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

Ограничения исходного IP-адреса базы данных SQL по умолчанию разрешают доступ с любого адреса Azure, включая другие подписки и арендаторы. Это можно ограничить, чтобы разрешить доступ к экземпляру только IP-адресам. Даже при ограничениях брандмауэра SQL и IP-адреса надежная аутентификация по-прежнему необходима. Ознакомьтесь с рекомендациями, приведенными ранее в этой статье.

Дополнительные сведения об ограничениях брандмауэра SQL Azure и IP-адресов см. в следующем разделе:

Шифрование неактивных данных

Прозрачное шифрование данных (TDE) включено по умолчанию. TDE прозрачно шифрует SQL Server, Базу данных SQL Azure и файлы данных Azure Synapse Analytics. TDE защищает от компрометации прямого доступа к файлам или их резервной копии. Это позволяет вам шифровать данные, находящиеся в состоянии покоя, не изменяя существующие приложения. TDE всегда должен оставаться включённым, однако это не остановит злоумышленника, пробующего проникнуть через обычный путь доступа. TDE предоставляет возможность соблюдать множество законов, нормативных требований и руководящих принципов, установленных в различных отраслях.

Azure SQL управляет вопросами, связанными с шифрованием ключей для TDE. Как и в случае с TDE, в локальной среде необходимо уделять особое внимание обеспечению возможности восстановления и при перемещении баз данных. В более сложных сценариях ключи можно явно управлять в Azure Key Vault с помощью расширяемого управления ключами. См. раздел "Включить TDE" в SQL Server с помощью EKM. Это также позволяет реализовать функцию использования собственного ключа (BYOK) в возможности Azure Key Vault BYOK.

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

Шифрование на уровне приложения также должно использоваться для выборочных данных. Проблемы с суверенитетом данных иногда могут быть устранены путем шифрования данных с помощью ключа, который хранится в правильной стране или регионе. Это предотвращает даже случайную передачу данных, так как невозможно расшифровать данные без ключа, если используется надежный алгоритм (например, AES 256).

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

Дальнейшие шаги

В этой статье описана коллекция рекомендаций по обеспечению безопасности Базы данных SQL и Azure Synapse Analytics для защиты веб-приложений PaaS и мобильных приложений. Дополнительные сведения о безопасности развернутых служб PaaS см. в следующих статьях: