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

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

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

  • Проверка подлинности Microsoft Entra (вместо проверки подлинности SQL Server)
  • брандмауэр Azure SQL
  • Transparent Data Encryption (TDE)

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

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

  • Проверка подлинности SQL использует имя пользователя и пароль. При создании сервера для базы данных вы указали имя входа администратора сервера с именем пользователя и паролем. С помощью этих учетных данных можно пройти проверку подлинности в любой базе данных на этом сервере в качестве владельца базы данных.

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

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

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

  • Позволяет смену паролей в одном месте.
  • Управляет разрешениями базы данных с помощью внешних групп Microsoft Entra.
  • Устраняет хранение паролей через интегрированную аутентификацию Windows и другие формы проверки подлинности, поддерживаемые Microsoft Entra ID.
  • Использует пользователей изолированной базы данных для проверки подлинности удостоверений на уровне базы данных.
  • Поддерживает проверку подлинности на основе маркеров для приложений, подключающихся к базе данных SQL.
  • Поддерживает федерацию домена с Active Directory Federation Services (ADFS) или собственной проверкой подлинности пользователя и пароля для локального Microsoft Entra ID без синхронизации домена.
  • Поддерживает подключения из SQL Server Management Studio, использующих универсальную проверку подлинности Active Directory, которая включает Multi-Factor Authentication (MFA). Многофакторная проверка подлинности включает надежную проверку подлинности с помощью нескольких простых параметров проверки подлинности. Параметры проверки : телефонный звонок, текстовое сообщение, смарт-карты с закреплением или уведомление мобильного приложения. Дополнительные сведения см. в статье Universal Authentication with SQL Database and Azure Synapse Analytics.

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

Замечание

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Last updated on