Рекомендации по безопасности для SQL Server

  • Статья

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

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

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

Обзор

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

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

Защита на уровне столбцов

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

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

Используйте Always encrypted для шифрования неактивных данных и сетевого трафика. Зашифрованные данные расшифровываются только клиентскими библиотеками на уровне клиента приложения. По возможности используйте случайное шифрование, а не детерминированное. Always Encrypted с безопасными анклавами может повысить производительность для операций сравнения, таких как BETWEEN, IN, LIKE, DISTINCT, Joins и многое другое для случайных сценариев шифрования.

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

Вы можете также предоставить разрешения на уровне столбцов для таблицы, представления или функции с табличным значением. Рассмотрим следующее: — SELECTтолько , REFERENCESи UPDATE разрешения можно предоставить в столбце. — уровень DENY таблицы не имеет приоритета над уровнем GRANTстолбца.

Защита на уровне строк

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

Бизнес-логика инкапсулирована в функции с табличным значением, управляемые политикой безопасности, которая активирует и деактивирует функциональность RLS. Политика безопасности также управляет FILTER и BLOCK предикатами, привязанными к таблицам RLS, работает против. Используйте безопасность на уровне строк (RLS), чтобы ограничить количество записей, возвращаемых пользователю, осуществляющему вызов. Используйте SESSION_CONTEXT (T-SQL) для пользователей, которые подключаются к базе данных через приложение среднего уровня, где пользователи приложений используют ту же учетную запись пользователя SQL Server. Чтобы оптимизировать производительность и управляемость, следуйте лучшим практикам по обеспечению безопасности на уровне строк.

Совет

Используйте безопасность на уровне строк (RLS) вместе с Always Encrypted или динамическим маскированием данных (DDM), чтобы максимально улучшить уровень безопасности своей организации.

Шифрование файлов

Прозрачное шифрование данных (TDE) позволяет защитить данные на уровне файлов, предоставляя шифрование неактивных данных файлов базы данных. прозрачное шифрование данных (TDE) гарантирует, что файлы базы данных, файлы резервного копирования и файлы не могут быть присоединены и tempdb считываются без надлежащего расшифровки файлов базы данных сертификатов. Без прозрачное шифрование данных (TDE) злоумышленник может взять физический носитель (диски или ленты резервного копирования) и восстановить или подключить базу данных для чтения содержимого. Эта технология поддерживается в сочетании со всеми другими возможностями безопасности в SQL Server. Прозрачное шифрование данных (TDE) выполняет в реальном времени шифрование и дешифрование файлов данных и журналов в операциях ввода-вывода. Шифрование TDE использует ключ шифрования базы данных (DEK) хранится в пользовательской базе данных. Ключ шифрования базы данных также можно защитить с помощью сертификата, который защищен главным ключом master базы данных базы данных.

Используйте TDE для защиты неактивных данных, резервных копий и tempdb.

Аудит и создание отчетов

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

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

Удостоверения и проверка подлинности

SQL Server поддерживает два режима проверки подлинности: проверка подлинности Windows и режим проверки подлинности SQL Server и Windows (смешанный режим).

Имена для входа отличаются от пользователей базы данных. Сначала сопоставьте имена для входа или группы Windows пользователям базы данных или ролям в отдельной операции. Затем предоставьте разрешения на доступ к объектам базы данных пользователям, ролям сервера, а также (или) ролям базы данных.

В SQL Server существуют следующие типы имен входа.

  • Локальная учетная запись пользователя Windows или учетная запись доменных служб Active Directory — SQL Server полагается на Windows для проверки подлинности учетных записей пользователей Windows.
  • Группа Windows — предоставление доступа группе Windows обеспечивает доступ ко всем именам для входа пользователей Windows, которые являются членами группы. При удалении пользователя из группы для него будут удалены права, которые он получил во время членства в группе. Членство в группе является предпочтительной стратегией.
  • Имя входа SQL Server — SQL Server сохраняет имя пользователя и хэш пароля в master базе данных.
  • Пользователи автономной базы данных проверяют подлинность подключений SQL Server на уровне базы данных. Содержащаяся база данных — это база данных, изолированная от других баз данных и от экземпляра SQL Server (и master базы данных), на котором размещена база данных. SQL Server поддерживает использование пользователей автономной базы данных для проверки подлинности Windows и SQL Server.

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

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

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

  • В Azure используйте безопасность с минимальными привилегиями с помощью элементов управления доступом на основе ролей (RBAC)

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

    • Если пользователь покидает компанию, это легко отключить учетную запись.
    • Кроме того, можно легко удалить пользователей из групп, когда пользователи изменяют роли или покидают организацию. Гарантирование безопасности групп является рекомендуемым поведением.

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

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

  • Групповые управляемые учетные записи служб (gMSA) обеспечивают автоматическое управление паролями, упрощенное управление именами субъектов-служб и возможность делегировать управление другим администраторам.

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

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

  • Рассмотрите возможность удаления для учетных записей DBA прав роли sysadmin и предоставления прав CONTROL SERVER, вместо того, чтобы делать эти учетные записи участниками роли sysadmin. Роль системного администратора не учитывается DENY , пока CONTROL SERVER делает.

Происхождение и целостность данных

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

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

Средства оценки безопасности и вычисление

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

  • Конфигурация области поверхности . Вы должны включить только компоненты, необходимые вашей среде, чтобы свести к минимуму количество функций, которые могут быть атакованы злоумышленником.
  • Оценка уязвимости для SQL Server (SSMS) — оценка уязвимости SQL — это средство в SSMS v17.4+, помогающее находить, отслеживать и устранять потенциальные уязвимости базы данных. Оценка уязвимостей является ценным инструментом для повышения безопасности вашей базы данных и выполняется для каждой базы данных на уровне базы данных.
  • Обнаружение и классификация данных SQL (SSMS) — это обычно для субД для управления серверами и базами данных и не учитывать конфиденциальность данных, содержащихся в базе данных. Обнаружение и классификация данных добавляет возможность обнаружения, классификации, метки и отчета о уровне конфиденциальности данных. Эта возможность поддерживается начиная с SSMS версии 17.5.

Распространенные угрозы SQL

Полезно знать, какие распространенные угрозы представляют опасность для SQL Server:

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

Риск внедрения кода SQL

Чтобы свести к минимуму риск внедрения SQL, рассмотрите следующие элементы:

  • Проверяйте любой процесс, создающий SQL-запросы, на наличие угроз внедрения кода.
  • Конструируйте динамически создаваемые операторы SQL параметризованным образом.
  • Разработчики и администраторы безопасности должны просматривать весь код, вызывающий EXECUTE, EXECили sp_executesql.
  • Запретить следующие входные символы:
    • ;: разделитель запросов
    • ': разделитель строк данных символов
    • --: один строковый комментарий разделитель.
    • /* ... */: разделители комментариев.
    • xp_: расширенные хранимые процедуры, такие как xp_cmdshellкаталог.
      • Не рекомендуется использовать xp_cmdshell в любой среде SQL Server. Вместо этого используйте SQLCLR или ищите другие варианты xp_cmdshell из-за рисков, которые могут возникнуть.
  • Всегда проверяйте данные, введенные пользователем, и не допускайте утечки информации об ошибках, чтобы они не попали в руки злоумышленника.

Риски атак по сторонним каналам

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

  • Убедитесь, что применяются последние исправления приложений и операционной системы.
  • При использовании гибридных рабочих нагрузок убедитесь, что для всего локального аппаратного обеспечения применяются последние исправления встроенного ПО.
  • В Azure для высокочувствительных приложений и рабочих нагрузок можно добавить дополнительную защиту от атак на стороне канала с изолированными виртуальными машинами, выделенными узлами или с помощью виртуальных машин конфиденциальных вычислений, таких как серия DC и Виртуальные машины, которые используют процессоры AMD EPYC 3-го поколения.

Угрозы для инфраструктуры

Рассмотрите следующие распространенные угрозы для инфраструктуры:

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

Риски для паролей

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

  • Создайте уникальную учетную запись локального администратора, которая не называется Администратор istrator.
  • Используйте сложные надежные пароли для всех учетных записей. Дополнительные сведения о том, как создать надежный пароль, см. в статье Создание надежного пароля.
  • По умолчанию во время настройки виртуальной машины SQL Server в Azure выбирается проверка подлинности Windows. Следовательно, имя для входа SA отключается, а пароль назначается в ходе настройки. Рекомендуется использовать или включить имя входа SA. Если у вас должна быть учетная запись SQL, используйте одну из следующих стратегий:

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

      Совет

      Если во время подготовки проверка подлинности SQL не включена, необходимо вручную изменить режим проверки подлинности на SQL Server и режим проверки подлинности Windows. Дополнительные сведения см. в разделе "Изменение режима проверки подлинности сервера".

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

Риски, связанные с программой-шантажистом

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

  • Лучшая стратегия защиты от атаки программой-шантажистом — уделить особое внимание уязвимостям RDP и SSH. Кроме того, рассмотрим следующие рекомендации.
    • Использование брандмауэров и блокировка портов
    • Убедитесь, что применяются последние обновления операционной системы и системы безопасности приложений.
    • используйте групповые управляемые учетные записи служб (gMSA);
    • ограничьте доступ к виртуальным машинам;
    • требуйте использования JIT-доступа и Бастиона Azure;
    • усовершенствуйте безопасность контактной зоны, отказавшись от установки инструментов, включая sysinternals и SSMS, на локальном компьютере;
    • Избегайте установки компонентов Windows, ролей и включения служб, которые не требуются
    • кроме того, необходимо регулярно планировать полное резервное копирование, защищенное от общей учетной записи администратора, чтобы исключить возможность удаления копий баз данных.

Связанный контент