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

Статья
2025-01-02

Область применения: 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, которые являются членами этой группы. При удалении пользователя из группы для него будут удалены права, которые он получил во время членства в группе. Членство в группе является предпочтительной стратегией.
Имя входа в 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) — Нередко администраторы баз данных (DBA) управляют серверами и базами данных, не осознавая чувствительность данных, содержащихся в базе данных. Функция "Обнаружение и классификация данных" добавляет возможность выявлять, классифицировать, маркировать и отчитываться об уровне конфиденциальности ваших данных. Функция "Обнаружение и классификация данных" поддерживается начиная с 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-го поколения.

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

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

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

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

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

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

Риски вымогательского ПО

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

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