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

  • Статья

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

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

Примечание.

Идентификатор Microsoft Entra ранее был известен как 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 Microsoft Azure и Управляемом экземпляре SQL поддерживаются два типа проверки подлинности.

  • Проверка подлинности SQL
  • Проверка подлинности Microsoft Entra

Примечание.

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

Централизованное управление удостоверениями

Централизованное управление удостоверениями предлагает следующие преимущества.

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

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

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

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

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

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

    Примечание.

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упоминалось в: упражнение № 4 OSA, контроль доступа 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

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

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

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

  • В Базах данных SQL:

    • Используйте детализированные разрешения и определяемые пользователем роли базы данных (или роли сервера в Управляемый экземпляр SQL):
      1. Создание обязательных ролей
      2. Создание необходимых пользователей
      3. Добавление пользователей в роли
      4. Затем назначьте разрешения ролям.
    • Нельзя назначать пользователям ненужные роли.

  • В Azure Resource Manager:

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

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

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

  • Старайтесь не назначать разрешения отдельным пользователям. Вместо этого последовательно используйте роли (роли базы данных или сервера). Роли в значительной мере помогают создавать отчеты и устранять неполадки, связанные с разрешениями. (В 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) является сложной задачей для задач, связанных с безопасностью или устранением неполадок. Другие области, такие как роли разработки и роли конечных пользователей, разделять проще. Большинство элементов управления, связанных с соответствием нормативным требованиям, позволяют использовать альтернативные функции управления, такие как аудит, когда применение других решений нецелесообразно.

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

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

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

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

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

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

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

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

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

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

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

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

  • Примеры того, что следует искать

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

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

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

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

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

Примечание.

Корпорация Майкрософт подтверждает, что База данных SQL Azure и Управляемый экземпляр SQL соответствуют требованиям 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 подтверждено".

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

Упоминалось в: упражнение № 6, семейство элементов управления ISO: криптография

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

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

Упоминалось в: упражнение № 6, семейство элементов управления ISO: криптография

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

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

  • Прозрачное шифрование данных (TDE) с управляемыми ключами службы по умолчанию включается для всех баз данных, созданных после 2017 года в База данных SQL Azure и Управляемый экземпляр SQL.
  • В управляемом экземпляре, если база данных создается операцией восстановления, используя локальный сервер, будет учитываться параметр 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 и Настройка географического аварийного восстановления с помощью 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упоминалось в: упражнение № 5

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

В Базе данных SQL:

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

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

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

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

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

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

    Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упоминалось в: упражнение № 9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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