Сборник схем для выполнения типовых требований к безопасности Базы данных SQL Azure и Управляемого экземпляра SQL Azure

Применимо к: База данных SQL Azure Управляемый экземпляр SQL Azure

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

Примечание.

Microsoft Entra ID ранее назывался Azure Active Directory (Azure AD).

Решение распространенных требований к безопасности

В этом документе приведены рекомендации по выполнению типовых требований к безопасности для новых или существующих приложений, использующих Базу данных SQL Azure и Управляемый SQL экземпляр Azure. Он структурирован по высокоуровневым областям безопасности. Сведения об устранении конкретных угроз см. в разделе Общие угрозы безопасности и возможные способы их устранения. Хотя некоторые из представленных рекомендаций применимы при переносе приложений из локальной среды в Azure, сценарии миграции не являются фокусом этого документа.

Предложения по развертыванию Базы данных SQL Azure, описанные в этом руководстве

Предложения по развертыванию, не описанные в этом руководстве

  • Azure Synapse Analytics
  • Виртуальные машины SQL Azure (IaaS)
  • SQL Server

Аудитория

Целевой аудиторией для этого руководства являются клиенты, задающие вопросы о том, как защитить Базу данных SQL Azure. К числу ролей, которых может заинтересовать эта статья о рекомендациях, относятся, помимо прочего:

  • Архитекторы безопасности
  • Диспетчеры безопасности
  • Должностные лица по обеспечению соответствия
  • Должностные лица по обеспечению конфиденциальности
  • Инженеры по безопасности

Использование этого руководства

Этот документ предназначен в качестве компаньона к нашим существующим общим сведениям о возможностях безопасности Базы данных SQL Azure и Управляемого экземпляра SQL.

Если не указано иное, для достижения соответствующей цели или выполнения требований рекомендуется следовать всем рекомендациям, приведенным в каждом разделе. Чтобы соответствовать конкретным стандартам соответствия требованиям безопасности или рекомендациям, в разделе "Требования" или "Цели" в соответствующих случаях перечислены важные средства управления соответствием нормативным требованиям. Ниже приведены стандарты безопасности и нормативные документы, упоминаемые в этом документе.

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

Аутентификация

Аутентификацией называют процесс подтверждения личности пользователя. В Базе данных SQL Microsoft Azure и Управляемом экземпляре SQL поддерживаются два типа проверки подлинности.

  • Проверка подлинности SQL
  • Аутентификация Microsoft Entra

Примечание.

Проверка подлинности Microsoft Entra может не поддерживаться для всех инструментов и сторонних приложений.

Централизованное управление идентификационными данными

Централизованное управление идентификационными данными обеспечивает следующие преимущества:

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

Способы реализации

  • Используйте проверку подлинности Microsoft Entra для централизованного управления удостоверениями.

Рекомендации

  • Создайте тенант Microsoft Entra и создайте пользователей для представления реальных пользователей, а также создайте субъекты-службы для представления приложений, служб и средств автоматизации. Субъекты-службы эквивалентны учетным записям служб в Windows и Linux.

  • Назначьте права доступа к ресурсам субъектам Microsoft Entra с помощью назначения группы: создание групп Microsoft Entra, предоставление доступа к группам и добавление отдельных участников в группы. В базе данных создайте пользователей автономной базы данных, которые сопоставляются с группами Microsoft Entra. Чтобы назначить разрешения внутри базы данных, добавьте содержащихся пользователей базы данных, представляющих ваши группы, к ролям базы данных либо предоставьте им разрешения напрямую.

    Примечание.

    В База данных SQL Azure и Управляемый экземпляр SQL также можно создавать имена входа, сопоставленные с субъектами безопасности Microsoft Entra в базе данных master. См. CREATE LOGIN (Transact-SQL).

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

  • Создайте отдельную группу для администраторов Microsoft Entra для каждого сервера или управляемого экземпляра.

  • Отслеживайте изменения членства в группах Microsoft Entra с помощью отчетов о действиях аудита Microsoft Entra ID.

  • Для управляемого экземпляра требуется отдельный шаг для создания администратора Microsoft Entra.

Примечание.

  • Проверка подлинности Microsoft Entra записывается в журналы аудита SQL Azure, но не в журналах входа Microsoft Entra.
  • Разрешения RBAC Azure, предоставленные в Azure, не применяются ни к Базе данных SQL Azure, ни к разрешениям Управляемого экземпляра SQL. Такие разрешения должны создаваться и сопоставляться вручную с использованием существующих разрешений SQL.
  • На стороне клиента проверка подлинности Microsoft Entra требует доступа к Интернету или через определяемый пользователем маршрут (UDR) к виртуальной сети.
  • Маркер доступа Microsoft Entra кэшируется на стороне клиента, а время существования зависит от конфигурации маркера. См. статью Настраиваемые времена существования токенов в Microsoft Entra ID
  • Инструкции по устранению неполадок проверки подлинности Microsoft Entra см. в следующем блоге: устранение неполадок с идентификатором Microsoft Entra.

Многофакторная проверка подлинности Microsoft Entra

Упоминается в: упражнении OSA № 2, контроль доступа ISO (AC)

Многофакторная проверка подлинности Microsoft Entra помогает обеспечить дополнительную безопасность, требуя нескольких форм проверки подлинности.

Способы реализации

  • Включите многофакторную проверку подлинности в идентификаторе Microsoft Entra с помощью условного доступа и используйте интерактивную проверку подлинности.

  • Альтернативой является включение многофакторной проверки подлинности для всего клиента Microsoft Entra или домена Active Directory.

Рекомендации

Сведение к минимуму использования для пользователей проверки подлинности на основе пароля

Упоминается в: практическое задание OSA № 4, контроль доступа ISO (AC)

Методы проверки подлинности на основе пароля являются более слабой формой проверки подлинности. Удостоверения могут быть скомпрометированы или переданы ошибочно.

Способы реализации

  • Используйте встроенную проверку подлинности Microsoft Entra, которая устраняет использование паролей.

Рекомендации

  • Используйте проверку подлинности единого входа на основе учетных данных Windows. Настройте федерацию локального домена Active Directory с Microsoft Entra ID и используйте интегрированную проверку подлинности Windows (для компьютеров, присоединённых к домену, с Microsoft Entra ID).

Сведение к минимуму использования для приложений проверки подлинности на основе пароля

Упоминается в: практическое задание OSA № 4, контроль доступа по ISO (AC)

Способы реализации

  • Включите управляемое удостоверение Azure. Можно также использовать встроенную проверку подлинности или проверку подлинности на основе сертификата.

Рекомендации

Защита паролей и секретов

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

Способы реализации

  • Используйте Azure Key Vault для хранения паролей и секретов. При необходимости используйте многофакторную проверку подлинности для База данных SQL Azure с пользователями Microsoft Entra.

Рекомендации

  • Если не удается избежать паролей или секретов, сохраните пароли пользователей и секреты приложений в Azure Key Vault и управляйте доступом с помощью политик доступа Key Vault.

  • Различные платформы разработки приложений также могут предложить механизмы для защиты секретов в приложении. Например: приложение ASP.NET Core.

Использование проверки SQL подлинности для устаревших приложений

Проверкой подлинности SQL называется проверка подлинности пользователя при подключении к Базе данных SQL Azure или Управляемому экземпляру SQL Azure, использующая имя пользователя и пароль. Необходимо создать имя для входа на каждом сервере или управляемом экземпляре, а также создать пользователя в каждой базе данных.

Способы реализации

  • Используйте проверку подлинности SQL.

Рекомендации

Управление доступом

Управление доступом (также называемое авторизацией) — это процесс управления доступом к Базе данных SQL Azure или Управляемому экземпляру SQL и соответствующими привилегиями для авторизованных пользователей.

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

Упоминается в: FedRamp controls AC-06, NIST: AC-6, упражнение OSA № 3

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

Способы реализации

Назначьте только необходимые разрешения для выполнения требуемых задач

Рекомендации

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

  • По возможности начните с минимально возможного набора разрешений и начинайте добавлять разрешения по одному при наличии реальной потребности (и основания), в отличие от противоположного подхода — отменять разрешения по одному.

  • Старайтесь не назначать разрешения отдельным пользователям. Вместо этого последовательно используйте роли (роли базы данных или сервера). Роли в значительной мере помогают создавать отчеты и устранять неполадки, связанные с разрешениями. (В Azure RBAC назначение разрешений поддерживается только через роли.)

  • Создайте и используйте настраиваемые роли с точными необходимыми разрешениями. Типичные роли, используемые на практике

    • Развертывание системы безопасности
    • Администратор
    • Разработчик
    • Персонал службы поддержки
    • Аудитор
    • Автоматизированные процессы
    • Конечный пользователь

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

  • Помните, что разрешения в ядре СУБД можно применить в следующих областях (чем меньше область применения, тем меньше влияние предоставленных разрешений).

    • Сервер (специальные роли в базе данных master) в Azure
    • База данных
    • Схема
      • Для предоставления разрешений внутри базы данных рекомендуется использовать схемы.
    • Объект (таблица, представление, процедура и т. д.)

    Примечание.

    Не рекомендуется применять разрешения на уровне объектов, так как этот уровень добавляет ненужную сложность в общую реализацию. Если решено использовать разрешения уровня объектов, эти разрешения должны быть четко документированы. То же относится и к разрешениям на уровне столбцов, которые по тем же причинам рекомендуются в ещё меньшей степени. Также имейте в виду, что по умолчанию DENY на уровне таблицы не переопределяет разрешение GRANT на уровне столбца. Для этого потребуется активировать конфигурацию сервера, удовлетворяющую стандарту Common Criteria.

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

Реализация разделения обязанностей

Упоминалось в: FedRamp: AC-04, NIST: AC-5, ISO: A.6.1.2, PCI 6.4.2, SOC: CM-3, SDL-3

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

Способы реализации

  • Определите требуемый уровень разделения обязанностей. Примеры:

    • Между средами разработки/тестирования и промышленной средой
    • Разделение обязанностей между чувствительными к безопасности задачами, задачами управления на уровне администратора баз данных (DBA) и задачами разработчика.
      • Примеры: аудитор, создание политики безопасности для безопасности на уровне ролей (RLS), реализация объектов Базы данных SQL с помощью DDL-разрешений.

  • Определение комплексной иерархии пользователей (и автоматизированных процессов), получающих доступ к системе.

  • Создайте роли в соответствии с необходимыми группами пользователей и назначьте разрешения ролям.

    • Для задач уровня управления на портале Azure или с помощью автоматизации PowerShell используйте роли Azure. Либо найдите встроенную роль, соответствующую требованиям, либо создайте настраиваемую роль Azure, используя доступные разрешения.
    • Создайте роли сервера для задач на уровне сервера (создание новых имен для входа, баз данных) в управляемом экземпляре.
    • Создайте роли базы данных для задач уровня базы данных.

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

  • Чтобы обеспечить разделение обязанностей между владельцем данных и владельцем безопасности, реализуйте в Azure Key Vault прозрачное шифрование данных (TDE) с ключами, управляемыми заказчиком.

  • Чтобы администратор базы данных не мог видеть данные, считающиеся строго конфиденциальными, но по-прежнему мог выполнять задачи администратора, можно использовать Always Encrypted с разделением ролей.

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

Рекомендации

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

  • Старайтесь не назначать разрешения отдельным пользователям. Вместо этого последовательно используйте роли (роли базы данных или сервера). Использование ролей заметно помогает создавать отчеты и устранять неполадки, связанные с разрешениями.

  • Используйте встроенные роли, если разрешения точно совпадают с необходимыми разрешениями. Если объединение всех разрешений из нескольких встроенных ролей приводит к совпадению разрешений на 100 %, можно одновременно назначить несколько ролей.

  • Создавайте и используйте определяемые пользователем роли, если встроенные роли предоставляют слишком много разрешений или недостаточно разрешений.

  • Роли также можно назначать временно, используя так называемое динамическое разделение обязанностей (DSD) либо в шагах задания агента SQL в T-SQL, либо с помощью Azure PIM для ролей Azure.

  • Убедитесь, что у администраторов баз данных отсутствует доступ к ключам шифрования или хранилищам ключей и что у администраторов безопасности, имеющих доступ к ключам, в свою очередь, отсутствует доступ к базе данных. Использование расширенного управления ключами (EKM) может упростить достижение этого разделения. Для реализации расширенного управления ключами можно использовать Azure Key Vault.

  • Всегда обеспечивайте наличие журнала аудита для действий, связанных с безопасностью.

  • Можно получить определение встроенных ролей Azure, чтобы просмотреть используемые разрешения и создать настраиваемую роль на основе выдержек из них и их объединений с помощью PowerShell.

  • Поскольку любой участник роли базы данных db_owner может изменять параметры безопасности, такие как прозрачное шифрование данных (TDE), а также менять SLO, такое членство следует предоставлять с осторожностью. Но существует множество задач, требующих привилегий db_owner. Такие задачи, как изменение настроек базы данных, например изменение параметров базы данных. Аудит играет ключевую роль в любом решении.

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

Примечание.

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

Для читателей, которые хотят глубже изучить SoD, мы рекомендуем следующие ресурсы:

Регулярное выполнение анализа кода

Упоминалось в: PCI: 6.3.2, SOC: SDL-3

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

Способы реализации

  • Используйте средство работы с базой данных, такое как SQL Server Management Studio, поддерживающее систему контроля версий.

  • Реализуйте раздельный процесс развертывания кода.

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

Рекомендации

  • Стандартизация: позволяет реализовать стандартную процедуру, выполняемую при любых изменениях кода.

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

  • Дальнейшие проверки можно выполнить в среде контроля качества или тестирования с помощью Расширенной защиты от угроз, которая сканирует код, уязвимый для внедрения кода SQL.

  • Примеры того, на что следует обратить внимание:

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

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

  • Обязательно определите все источники изменений кода. Код может быть представлен скриптами T-SQL. Это могут быть специальные команды, выполняемые напрямую, либо объекты, развертываемые в виде представлений, функций, триггеров и хранимых процедур. Это может быть часть определений заданий (действий) агента SQL. Он также может выполняться в пакетах служб SSIS, фабрики данных Azure и других служб.

Защита данных

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

Примечание.

Корпорация Майкрософт подтверждает, что База данных SQL Azure и Управляемый экземпляр SQL Azure соответствуют требованиям FIPS 140-2 уровня 1. Этому подтверждению предшествовала проверка строгого использования допустимых алгоритмов FIPS 140-2 уровня 1 и проверенных экземпляров этих алгоритмов FIPS 140-2 уровня 1, включая согласованность с требуемыми длинами ключей, управлением ключами, созданием ключей и хранением ключей. Цель этого подтверждения — позволить нашим клиентам реагировать на потребность или требование использовать проверенные экземпляры FIPS 140-2 уровня 1 при обработке данных или доставке систем либо приложений. Мы определяем термины "соответствие FIPS 140-2 уровня 1" и "соответствие FIPS 140-2 уровня 1", использованные в приведенной выше формулировке, чтобы показать целесообразность их применения вместо другого термина, принятого государственными учреждениями США и Канады — "соответствие FIPS 140-2 уровня 1 подтверждено".

Шифрование передаваемых данных

Упоминается в: Практика OSA № 6, семейство мер контроля ISO: криптография

Защищает данные, перемещаемые между клиентом и сервером. См. статью Безопасность сети.

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

Упоминается в: Практика OSA № 6, семейство мер контроля ISO: криптография

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

Способы реализации

  • Прозрачное шифрование данных (TDE) с ключами, управляемыми службой, по умолчанию включено для всех баз данных, созданных после 2017 г. в Базе данных SQL Azure и Управляемом экземпляре SQL Azure.
  • В управляемом экземпляре, если база данных создается операцией восстановления, используя локальный сервер, будет учитываться параметр TDE исходной базы данных. Если в исходной базе данных функция TDE не включена, рекомендуется вручную включить TDE для управляемого экземпляра.

Рекомендации

  • Не сохраняйте данные, необходимые для шифрования в master базе данных. База master данных не может быть зашифрована с помощью TDE.

  • Если требуется увеличить прозрачность и детальное управление защитой TDE, используйте управляемые клиентом ключи в Azure Key Vault. Использование Azure Key Vault позволяет отменять разрешения в любое время, делая просмотр базы данных недоступным. Можно централизованно управлять средствами защиты TDE вместе с другими ключами или переключать средство защиты TDE по собственному расписанию с помощью Azure Key Vault.

  • Если вы используете ключи, управляемые клиентом, в Azure Key Vault, ознакомьтесь со статьями Рекомендации по настройке TDE с помощью Azure Key Vault и Как настроить Geo-DR с помощью Azure Key Vault.

Примечание.

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

Защита используемых конфиденциальных данных от неавторизованных пользователей с высоким уровнем привилегий

Используемые данные — это данные, находящиеся в памяти системы базы данных во время выполнения SQL-запросов. Если база данных хранит конфиденциальные данные, вашей организации может потребоваться, чтобы пользователи с высоким уровнем привилегий не могли просматривать конфиденциальные данные в базе данных. У пользователей с высоким уровнем привилегий, таких как операторы Майкрософт или администраторы баз данных в вашей организации, должна быть возможность управления базой данных, но им должно быть запрещено просматривать и потенциально извлекать конфиденциальные данные из памяти процесса SQL или путем запроса к базе данных.

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

Способы реализации

  • Используйте Always Encrypted, чтобы обеспечить недоступность конфиденциальных данных в виде открытого текста в Базе данных SQL Azure или в Управляемом экземпляре SQL Azure, даже в памяти/при использовании. Функция Always Encrypted защищает данные от администраторов баз данных и администраторов облака (или злоумышленников, которые могут выдавать себя за пользователей, обладающих высоким уровнем привилегий, но неавторизованных) и предоставляет возможность дополнительного управления предоставлением доступа к вашим данным.

Рекомендации

  • Always Encrypted не является заменой шифрования данных ни при хранении (TDE), ни при передаче (SSL/TLS). Always Encrypted не следует использовать для неконфиденциальных данных, чтобы свести к минимуму влияние на производительность и функциональность. Для полной защиты данных при хранении, передаче и использовании рекомендуется использовать Always Encrypted вместе с TDE и протоколом TLS.

  • Перед развертыванием Always Encrypted в рабочей базе данных оцените влияние шифрования столбцов выявленных конфиденциальных данных. В общем случае Always Encrypted уменьшает функциональные возможности запросов к шифрованным столбцам и имеет другие ограничения, перечисленные в статье Подробные сведения о возможностях Always Encrypted. Поэтому может потребоваться перестроить ваше приложение для повторной реализации функциональности, которую запрос не поддерживает, на стороне клиента или/и рефакторинг схемы базы данных, включая определения хранимых процедур, функций, представлений и триггеров. Существующие приложения могут не работать с зашифрованными столбцами, если они не соответствуют ограничениям и ограничениям Always Encrypted. Хотя экосистема инструментов, продуктов и служб корпорации Майкрософт, поддерживающих Always Encrypted, растет, некоторые из них не работают с шифрованными столбцами. Шифрование столбца также может повлиять на производительность запросов в зависимости от характеристик рабочей нагрузки.

  • При использовании Always Encrypted для защиты данных от администраторов-злоумышленников управляйте ключами Always Encrypted с помощью разделения ролей. При использовании разделения ролей администратор безопасности создает физические ключи. Администратор базы данных создает главный ключ столбцов и объекты метаданных ключа шифрования столбцов, описывающие физические ключи в базе данных. Во время этого процесса администратору безопасности не требуется доступ к базе данных, а администратору базы данных не требуется доступ к физическим ключам в виде открытого текста.

  • Для упрощения управления храните главные ключи столбцов в Azure Key Vault. Избегайте использования хранилища сертификатов Windows (и в общем случае распределенных решений хранения ключей, в отличие от централизованных решений для управления ключами), которое затрудняет управление ключами.

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

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

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

  • В случае опасений о получении сторонними лицами легального доступа к данным без вашего согласия убедитесь, что все приложения и средства, обладающие доступом к ключам и данным в виде открытого текста, выполняются вне облака Microsoft Azure. Без доступа к ключам сторонним лицам не удастся расшифровать данные, если только они не будут пытаться обойти шифрование.

  • Always Encrypted не поддерживает предоставление временного доступа к ключам (и защищенным данным). Например, если нужно предоставить администратору базы данных доступ к ключам, чтобы разрешить ему выполнить некоторые операции очистки над конфиденциальными и зашифрованными данными. Единственный способ надежно отменить доступ к данным для администратора базы данных — сменить ключи шифрования столбцов и главные ключи столбцов, защищающие данные, что является дорогостоящей операцией.

  • Чтобы получить доступ к значениям зашифрованных столбцов как к открытому тексту, пользователю нужен доступ к главному ключу столбцов (CMK), который защищает столбцы и настраивается в хранилище ключей, в котором хранится CMK. Пользователю также необходимы разрешения базы данных VIEW ANY COLUMN MASTER KEY DEFINITION и VIEW ANY COLUMN ENCRYPTION KEY DEFINITION.

Управление доступом пользователей приложений к конфиденциальным данным с помощью шифрования

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

Способы реализации

  • Используйте шифрование на уровне ячеек (CLE). Дополнительные сведения см. в статье Шифрование столбца данных.
  • Используйте Always Encrypted, но помните об ограничениях этой функции. Ограничения перечислены ниже.

Рекомендации

При использовании CLE:

  • Управляйте доступом к ключам с помощью разрешений и ролей SQL.

  • Для шифрования данных используйте алгоритм AES (рекомендуется использовать AES 256). Алгоритмы, такие как RC4, DES и TripleDES, являются устаревшими и не должны использоваться из-за известных уязвимостей.

  • Чтобы избежать использования 3DES, защитите симметричные ключи с помощью асимметричных ключей и сертификатов (не паролей).

  • Будьте осторожны при миграции базы данных, использующей шифрование на уровне ячеек, через экспорт/импорт (файлы BACPAC).

Имейте в виду, что Always Encrypted в первую очередь предназначен для защиты конфиденциальных данных, находящихся в использовании, от пользователей База данных SQL Azure с высоким уровнем привилегий (операторы облака, администраторы баз данных). Дополнительные сведения см. в разделе "Защита используемых конфиденциальных данных от пользователей с высоким уровнем привилегий и несанкционированных пользователей". При использовании Always Encrypted для защиты данных от пользователей приложений учитывайте следующие проблемы.

  • По умолчанию все драйверы клиента Майкрософт, поддерживающие Always Encrypted, поддерживают глобальный (по одному на приложение) кэш ключей шифрования столбцов. Когда драйвер клиента получает ключ шифрования столбцов в виде открытого текста, обратившись к хранилищу ключей, в котором хранится главный ключ столбцов, ключ шифрования столбцов в виде открытого текста кэшируется. Это затрудняет изоляцию данных от пользователей многопользовательских приложений. Если при взаимодействии с хранилищем ключей (например, Azure Key Vault) приложение олицетворяет конечных пользователей, после того как пользовательский запрос заполнит кэш ключом шифрования столбцов, последующий запрос, требующий использования того же ключа, но запущенный другим пользователем, будет использовать кэшированный ключ. Драйвер не будет вызывать хранилище ключей и не будет проверять, есть ли у второго пользователя разрешение на доступ к ключу шифрования столбцов. В результате пользователь может видеть зашифрованные данные, даже если у него нет доступа к ключам. Чтобы обеспечить изоляцию пользователей в многопользовательском приложении, можно отключить кэширование ключей шифрования столбцов. Отключение кэширования приведет к дополнительному ухудшению производительности, так как драйверу потребуется связываться с хранилищем ключей для каждой операции шифрования или расшифровки данных.

Защита данных от несанкционированного просмотра пользователями приложений с одновременным сохранением формата данных

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

Способы реализации

Примечание.

Функция Always Encrypted не работает с динамическим маскированием данных. Невозможно шифровать и маскировать один и тот же столбец, что означает необходимость определить, что приоритетнее — защита используемых данных или их маскирование для пользователей приложения с помощью динамического маскирования данных.

Рекомендации

Примечание.

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

  • Не разрешайте пользователям приложений выполнять нерегламентированные запросы, поскольку они могут обойти Dynamic Data Masking. Дополнительные сведения см. в статье об обходе маскирования с помощью инференциальных методов или методов перебора.

  • Используйте правильную политику контроля доступа (с помощью разрешений SQL, ролей и RLS), чтобы ограничить разрешения пользователей на изменение маскированных столбцов. Создание маски для столбца не запрещает его изменение. Пользователи, получающие маскированные данные с помощью запроса маскированного столбца, могут изменять данные, если у них есть разрешения на запись.

  • Динамическое маскирование данных не сохраняет статистические свойства маскированных значений. Это может повлиять на результаты запроса (например, запросы, содержащие предикаты фильтрации или соединения в маскированных данных).

Безопасность сети

Сетевая безопасность относится к элементам управления доступом и рекомендациям по защите данных, передаваемых в Базу данных SQL Azure.

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

Рекомендации по предотвращению подключения клиентских компьютеров и приложений с известными уязвимостями (например, использующих устаревшие протоколы TLS и наборы шифров) к Базе данных SQL Azure и Управляемому экземпляру SQL.

Способы реализации

  • Убедитесь, что клиентские компьютеры, подключающиеся к Базе данных SQL Azure и Управляемому экземпляру SQL, используют последнюю версию протокола TLS (Transport Layer Security).

Рекомендации

  • Примените минимальную версию TLS на логическом сервере в Базе данных SQL Azure или Управляемом экземпляре SQL Azure с помощью минимального параметра версии TLS. Мы рекомендуем использовать минимальную версию TLS 1.2, предварительно с помощью тестирования убедившись, что все приложения ее поддерживают. TLS 1.2 включает исправления всех уязвимостей, найденных в предыдущих версиях.

  • Настройка всех приложений и средств для подключения к Базе данных SQL с включенным шифрованием

    • Encrypt = On, TrustServerCertificate = Off (или эквивалентные значения для драйверов сторонних производителей).

  • Если приложение использует драйвер, не поддерживающий TLS или поддерживающий устаревшую версию TLS, по возможности замените драйвер. Если это невозможно, тщательно оцените риски безопасности.

Уменьшение уязвимой зоны

Сведите к минимуму число компонентов, которые может атаковать злоумышленник. Реализуйте управление доступом к сети для Базы данных SQL Azure.

Упоминается в: Практика OSA № 5

Способы реализации

В базе данных SQL Azure:

  • установите на уровне сервера значение OFF для параметра "Разрешить доступ к службам Azure".
  • Используйте конечные точки службы виртуальной сети и правила брандмауэра виртуальной сети.
  • Используйте Приватный канал.

В Управляемом экземпляре SQL:

Рекомендации

  • Ограничьте доступ к Базе данных SQL Azure и Управляемому экземпляру SQL, подключившись к частной конечной точке (например, используя частный путь к данным).

    • Управляемый экземпляр можно изолировать внутри виртуальной сети, чтобы предотвратить внешний доступ. Приложения и средства, находящиеся в той же или в одноранговой виртуальной сети в том же регионе, могут обращаться к нему напрямую. Для установления соединения приложения и средства, находящиеся в разных регионах, могут использовать соединение между виртуальными сетями или пиринг канала ExpressRoute. Клиент должен использовать группы безопасности сети (NSG), чтобы предоставить доступ через порт 1433 только тем ресурсам, которым требуется доступ к управляемому экземпляру.
    • Для базы данных SQL Azure используйте приватный канал, который предоставляет выделенный частный IP-адрес для сервера в виртуальной сети. Можно также использовать конечные точки службы виртуальной сети для ограничения доступа к логическим серверам.
    • Мобильные пользователи должны использовать VPN-подключения типа "точка-сеть" для подключения через путь передачи данных.
    • Пользователи, подключенные к локальной сети (on-premises), должны использовать VPN-подключение типа site-to-site или ExpressRoute для подключения по каналу передачи данных.

  • Доступ к Базе данных SQL Azure и Управляемому экземпляру SQL можно получить, подключившись к общедоступной конечной точке (например, используя общедоступный путь к данным). Рекомендуется рассмотреть применение следующей стратегии.

    Примечание.

    Общедоступная конечная точка Управляемого экземпляра SQL по умолчанию не включена и должна быть включена явно. Если политика компании запрещает использование общедоступных конечных точек, используйте Политику Azure, чтобы в первую очередь запретить включение общедоступных конечных точек.

  • Настройте компоненты Сети Azure.

Настройка Power BI для безопасных соединений с Базой данных SQL и Управляемым экземпляром SQL

Рекомендации

Настройка App Service для безопасного подключения к Базе данных SQL и Управляемому экземпляру SQL

Рекомендации

Настройка виртуальной машины Azure для безопасных подключений к Базе данных SQL/Управляемому экземпляру SQL

Рекомендации

  • Используйте сочетание правил «Разрешить» и «Запретить» в группах безопасности сети (NSG) виртуальных машин Azure, чтобы управлять тем, к каким регионам можно получать доступ с виртуальной машины.

  • Убедитесь, что ваша виртуальная машина настроена в соответствии со статьей Рекомендации по безопасности для рабочих нагрузок IaaS в Azure.

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

  • Оцените, нужен ли маршрут по умолчанию 0.0.0.0/Internet в соответствии с руководством в статье Сведения о принудительном туннелировании.

    • Если да — например, в подсети внешнего интерфейса — сохраните маршрут по умолчанию.
    • Если нет — например, для подсети среднего уровня или серверной подсети, — включите принудительное туннелирование, чтобы никакой трафик для доступа к локальной инфраструктуре не проходил через Интернет (т. е. между локальной и облачной средами).

  • Если применяется пиринг или подключение к локальной среде, используйте дополнительные маршруты по умолчанию.

  • Используйте определяемые пользователем маршруты, если для проверки пакетов нужно отправить весь трафик виртуальной сети в сетевой виртуальный модуль.

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

Защита от распределенных атак типа "отказ в обслуживании" (DDoS)

Распределенные атаки типа "отказ в обслуживании" (DDoS) — это попытки злоумышленника добиться переполнения сетевого трафика, направляемого в Базу данных SQL Azure, для перегрузки инфраструктуры Azure и отклонения правильных входов в систему и допустимой рабочей нагрузки.

Упоминается в: OSA Практика № 9

Способы реализации

На платформе Azure защита от DDoS включена автоматически. В нее входит постоянно включенный мониторинг трафика и устранение в реальном времени атак на уровне сети в общедоступных конечных точках.

Рекомендации

  • Следуйте рекомендациям, описанным в разделе Уменьшение уязвимой зоны, чтобы свести к минимуму угрозы от атак DDoS.

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

  • Для приложений, размещённых на виртуальных машинах Azure и подключающихся к базе данных SQL:

    • Выполните рекомендации по ограничению доступа через подключенные к Интернету конечные точки в Microsoft Defender для облака.
    • Используйте масштабируемые наборы виртуальных машин для запуска нескольких экземпляров приложения на виртуальных машинах Azure.
    • Отключите доступ к RDP и SSH из Интернета, чтобы предотвратить атаку методом перебора.

Мониторинг, ведение журналов и аудит

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

Защита баз данных от атак

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

Способы реализации

  • Используйте расширенную защиту от угроз для SQL для обнаружения необычных и потенциально опасных попыток доступа к базам данных или эксплойтов, в том числе:
    • Атака путем внедрения кода SQL.
    • Кража или утечка учетных данных.
    • Нарушение привилегий.
    • Кража данных

Рекомендации

  • Настройте Microsoft Defender для SQL для конкретного сервера или управляемого экземпляра. Вы также можете настроить Microsoft Defender для SQL для всех серверов и управляемых экземпляров в подписке, включив Microsoft Defender для облака.

  • Для полноценного расследования рекомендуется включить Аудит для База данных SQL Azure. С помощью аудита можно отслеживать события базы данных и записывать их в журнал аудита учетной записи службы хранилища Azure или рабочей области Azure Log Analytics.

Аудит критических событий безопасности

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

Способы реализации

  • Включите аудит базы данных SQL Azure или аудит управляемого экземпляра SQL для отслеживания событий базы данных и записи их в журнал аудита в учетной записи хранения Azure, рабочей области Log Analytics (предварительная версия) или Центрах событий (предварительная версия).

  • Журналы аудита можно записывать в учетную запись хранения Azure, в рабочую область Log Analytics для обработки журналами Azure Monitor или в Центры событий Azure для последующей обработки с их помощью. Вы также можете настроить любое сочетание этих вариантов, и журналы аудита будут записываться в каждый из них.

Рекомендации

  • Настроив аудит для Базы данных SQL Azure или Управляемого экземпляра SQL Azure для аудита событий, все существующие и вновь созданные базы данных на этом сервере будут проверены.
  • По умолчанию политика аудита включает все действия (запросы, хранимые процедуры и успешные и неудачные входы в систему) по отношению к базам данных, что может привести к значительному увеличению объема журналов аудита. Клиентам рекомендуется настраивать аудит для различных типов действий и групп действий с помощью PowerShell. Такая настройка позволяет управлять количеством аудируемых действий и снизить риск потери событий. Настраиваемые конфигурации аудита позволяют клиентам записывать только необходимые данные аудита.
  • Журналы аудита можно просматривать непосредственно в портале Azure или в настроенном расположении хранилища.

Примечание.

Включение аудита в Log Analytics повлечёт расходы в зависимости от объёма принимаемых данных. Изучите затраты, связанные использованием этой возможности, или подумайте о хранении журналов аудита в учетной записи хранения Azure.

Дополнительные ресурсы

Защита журналов аудита

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

Способы реализации

  • При сохранении журналов аудита в службе хранилища Azure убедитесь, что доступ к учетной записи хранения ограничен принципами минимальной безопасности. Управляйте предоставлением доступа к учетной записи хранения.
  • Дополнительные сведения см. в статье Авторизация доступа к службе хранилища Azure.

Рекомендации

Управление безопасностью

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

Убедитесь, что базы данных настроены в соответствии с рекомендациями по обеспечению безопасности.

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

Способы реализации

  • Включите Оценку уязвимостей SQL (VA), чтобы проверять базу данных на наличие проблем безопасности и автоматически выполнять эту проверку периодически в базах данных.

Рекомендации

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

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

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

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

Дополнительные ресурсы

Выявление и маркировка конфиденциальных данных

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

Способы реализации

  • Используйте обнаружение и классификацию данных для обнаружения, классификации, метки и защиты конфиденциальных данных в базах данных.
    • Просмотрите рекомендации по классификации, созданные при автоматическом обнаружении, на панели мониторинга "Обнаружение и классификация данных SQL". Примите соответствующие классификации, чтобы конфиденциальные данные были постоянно помечены метками классификации.
    • Вручную добавьте классификации для любых дополнительных полей конфиденциальных данных, которые не были обнаружены автоматическим механизмом.
  • Дополнительные сведения см. в статье Обнаружения и классификация данных SQL.

Рекомендации

  • Регулярно контролируйте панель мониторинга классификации для точной оценки состояния классификации базы данных. Отчет о состоянии классификации базы данных можно экспортировать или распечатать для предоставления в целях аудита и обеспечения соответствия нормативным требованиям.

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

  • Используйте классификацию способом, настроенным в соответствии с конкретными потребностями организации. Настройте политику защиты информации (метки чувствительности, типы данных, логика обнаружения) в политике SQL Information Protection в Microsoft Defender для облака.

Мониторинг доступа к конфиденциальным данным

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

Способы реализации

Рекомендации

Визуализация состояния безопасности и соответствия нормативам

Используйте единую систему управления безопасностью инфраструктуры, позволяющую усилить состояние безопасности центров обработки данных (в том числе Баз данных SQL). Просмотрите список рекомендаций, касающихся безопасности баз данных и состояния соответствия нормативам.

Способы реализации

Распространенные угрозы безопасности и потенциальные способы их устранения

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

Угроза безопасности: кража данных

Кража данных — это несанкционированное выполнение копирования, передачи или извлечения данных с компьютера или сервера. См. определение кражи данных в Википедии.

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

Сценарий 1. Приложение, работающее на виртуальной машине Azure, подключается к базе данных в Базе данных SQL Azure. Злоумышленник получает доступ к виртуальной машине и компрометирует ее. В этом сценарии кража данных означает, что внешняя сущность, использующая фальшивую виртуальную машину, подключается к базе данных, копирует личные данные и сохраняет их в хранилище BLOB-объектов или в другой Базе данных SQL в другой подписке.

Сценарий 2: Недобросовестный администратор базы данных. Этот сценарий часто возникает у клиентов из регулируемых отраслей, для которых важны вопросы безопасности. В этом сценарии пользователь с высоким уровнем привилегий может копировать данные из Базы данных SQL Azure в другую подписку, не управляемую владельцем данных.

Потенциальные способы устранения рисков

Сегодня База данных SQL Azure и Управляемый экземпляр SQL предлагают следующие методы для устранения угроз кражи данных:

  • Используйте сочетание правил «Разрешить» и «Запретить» в группах безопасности сети (NSG) виртуальных машин Azure, чтобы управлять тем, к каким регионам можно получать доступ с виртуальной машины.
  • Если используется сервер в База данных SQL, задайте следующие параметры:
    • Параметр "Разрешить службы Azure" — значение OFF.
    • Разрешите трафик только из подсети, содержащей виртуальную машину Azure, настроив правило брандмауэра виртуальной сети.
    • Используйте Приватный канал
  • В случае Управляемого экземпляра SQL использование по умолчанию частного IP-доступа устраняет первую проблему кражи данных с помощью посторонней виртуальной машины. Включите в подсети функцию делегирования подсети, чтобы автоматически задать самую ограничивающую политику в подсети Управляемого экземпляра SQL.
  • Риск, связанный с недобросовестным администратором баз данных, более заметен в случае Управляемый экземпляр SQL, поскольку у него больше поверхность атаки, а сетевые требования видны клиентам. Лучший способ снизить этот риск — применять все методы, описанные в этом руководстве по безопасности, чтобы в принципе не допустить сценария с недобросовестным администратором базы данных (а не только для предотвращения утечки данных). Always Encrypted — это один из методов защиты конфиденциальных данных путем их шифрования и обеспечения недоступности ключа для администратора базы данных.

Аспекты обеспечения безопасности при непрерывности и доступности бизнес-процессов

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

Следующий шаг

Общие сведения о возможностях безопасности Базы данных SQL Azure и Управляемого экземпляра SQL

  • Last updated on