Автор: Pieter Vanhove, MICROSOFT, 17 июня 2025г. Secure by default: What’s new in SQL Server 2025 security
В SQL Server 2025 была улучшена безопасность, теперь клиентские секреты будут защищены с помощью управляемой аутентификации, а также внедрены более строгие стандарты шифрования и протоколы подключения. Всё это призвано помочь упреждать появление новых угроз благодаря усилению безопасности данных — прямо из коробки.
Обновления криптографии
PBKDF2 для
хэшей паролей по умолчанию
Начиная с SQL Server 2012, использовался хэш SHA-512 в
сочетании с 32-битной случайной и уникальной «солью» (дополнительные случайные
данные, усложняющие подбор пароля). Этот метод сделал статистически невозможным
взлом паролей пользователей.
В SQL Server 2025 реализован итеративный алгоритм
хэширования RFC2898, также известный как функция деривации ключа на основе
пароля (PBKDF). Этот алгоритм по-прежнему использует SHA-512, но хэширует
пароль несколько раз (100 000 итераций), что значительно замедляет атаки
методом подбора. Это изменение усиливает защиту паролей в ответ на
развивающиеся угрозы безопасности и помогает клиентам соблюдать рекомендации
NIST SP 800-63b.
Это касается:
•
CREATE LOGIN WITH PASSWORD
•
CREATE USER WITH PASSWORD
•
CREATE APPLICATION ROLE
Поддержка OAEP для сертификатов и асимметричных ключей
Иерархия
шифрования
SQL Server шифрует данные с помощью иерархического шифрования и инфраструктуры управления ключами. Каждый уровень шифрует уровень ниже себя, используя комбинацию сертификатов, асимметричных ключей и симметричных ключей. Асимметричные ключи и симметричные ключи могут храниться вне SQL Server в модуле Extensible Key Management (EKM). На следующем рисунке ниже показаны наиболее актуальные конфигурации шифрования.
Новый
алгоритм шифрования для сертификатов и асимметричных ключей
SQL Server использует алгоритм RSA для асимметричного
шифрования. Однако «чистая» (базовая) версия RSA неприменима, поскольку не
обладает семантической стойкостью и уязвима к атакам с выбранным открытым
текстом и атакам на зашифрованный текст из-за своей детерминированной природы.
Шифрование одного и того же сообщения дважды даёт идентичный шифрованный текст.
Для обеспечения безопасности сообщений требуются т.н.
дополнения (padding). В
настоящее время данные шифруются с помощью RSA по схеме PKCS #1 v1.5. Последние
версии стандарта PKCS#1 v1.5 включают улучшенный метод дополнения — Optimal Asymmetric Encryption Padding (OAEP), который
использует хеш-функцию для добавления внутренней избыточности. Это делает
маловероятным случайное совпадение произвольной строки с форматом дополнения.
OAEP также вводит дополнительное хеширование между этапом шифрования RSA и
проверкой дополнения, что существенно затрудняет атаки.
Начиная с SQL Server 2025, появилась поддержка OAEP-256 для
RSA-шифрования с использованием сертификатов или асимметричных ключей. Переход
на режим OAEP зависит от уровня совместимости базы данных, он доступен для
уровня 170 или выше.
Защита
данных при передаче с поддержкой TDS 8.0 и TLS 1.3
В SQL
Server 2025 внедрена поддержка Tabular Data Stream (TDS) 8.0 и Transport Layer Security (TLS) 1.3. TDS
8.0 обеспечивает строгие протоколы шифрования для защиты данных при передаче,
что соответствует современным стандартам шифрования и ожиданиям клиентов
относительно безопасных конфигураций по умолчанию.
Улучшение
TDS 8.0 и TLS 1.3
В предыдущих версиях SQL Server шифрование было необязательным
и обычно добавлялось после первоначальной настройки соединения. TDS 8.0 меняет
этот подход, обеспечивая шифрование с начала соединения. Благодаря TLS 1.3 SQL
Server 2025 обеспечивает сквозное шифрование всех коммуникаций, что сокращает
поверхность атаки и соответствует лучшим отраслевым практикам.
Новая последовательность подключения теперь выглядит так:
TCP handshake → TLS handshake → TDS prelogin (encrypted) → Authentication (encrypted) → Data exchange (encrypted)
Это существенное улучшение по сравнению с предыдущей
моделью, где фаза предварительного входа TDS была зашифрована опционально в
зависимости от настроек клиента и сервера. С TDS 8.0 шифрование применяется с
самого начала соединения, включая фазу предварительного входа, обеспечивая сквозную
защиту по умолчанию.
Поддержка
компонентами SQL Server протокола TDS 8.0
Поддержка TDS 8.0 и TLS 1.3 добавлена во все функции и
утилиты SQL Server 2025. На момент выхода статьи такую поддержку имел следующий
функционал:
·
Database
Mail
·
SQL
Writer/VSS
·
sqlcmd.exe
·
bcp.exe
После релиза SQL Server 2025 поддержка TDS 8.0 будет у
следующих компонент:
·
Availability
Groups & Failover Clusters
·
Linked
Server
·
Log
Shipping
·
PolyBase
·
SQL
Agent
Другие улучшения безопасности
Улучшения кэша безопасности
Кэш безопасности SQL Server хранит разрешения пользователей
или логинов для защищаемых объектов базы данных или сервера. Одним из
преимуществ такого кэширования является то, что ускоряется выполнение запросов.
Перед тем, как SQL Server выполнит запрос, он проверяет разрешения пользователя
на объекты базы данных, например, разрешения на уровне схемы, разрешения на
уровне таблицы или разрешения на уровне столбцов.
Возможны случаи, когда кэш безопасности на уровне базы данных или сервера будет
аннулирован, что приводит к потере всех текущих записей кэша. Все последующие
запросы и проверки разрешений будут следовать полному рабочему алгоритму «без
кэша» до тех пор, пока кэш не будет снова заполнен, что может существенно
повлиять на производительность сервера. Это особенно неприятно при высокой
нагрузке, поскольку всем активным соединениям необходимо загрузить в кэш соответствующие
записи. Повторные аннулирования кэша могут усугубить ситуацию. Аннулирования
кэша в базе данных master рассматриваются как аннулирования на уровне сервера, и затрагивает
кэши всех баз данных экземпляра. В таблице ниже перечислены все DDL, которые
аннулируют кэш безопасности.
Поддержка пользовательской
политики паролей в Linux
В течение многих лет SQL Server на Windows для обеспечения
соблюдения политик паролей использовал Active Directory (AD), обеспечивая
согласованность со стандартами безопасности на уровне предприятия. Однако этот
уровень контроля отсутствовал в SQL Server на Linux. Это меняется с выходом SQL
Server 2025, где мы представляем Custom Password Policies для
SQL Server на Linux. Эта новая функция позволяет администраторам применять строгие
правила создания паролей даже без интеграции с AD. Независимо от того,
работаете ли вы в гибридной среде или полностью в облаках, теперь вы можете
применять требования к сложности пароля, сроку действия и истории
непосредственно в SQL Server на Linux.
Там, где управление политиками централизовано на сервере AD,
администраторы домена могут управлять политикой паролей непосредственно в AD.
Чтобы это работало, хосты Linux, на которых запущен SQL Server, должен быть
присоединен к домену Windows. Затем нужно использовать утилиту ADutil для
извлечения политики паролей, определенной в AD, и записи её в файл «mssql.conf».
Это обеспечит централизованное, согласованное применение политики в SQL Server.
В качестве альтернативы, если хост на Linux не присоединен к
домену или у него нет доступа к контроллеру домена, вы можете настроить
политики паролей вручную. Просто измените соответствующие параметры в файле
mssql.conf с помощью mssql-conf. Этот метод обеспечивает простоту и хорошую
управляемость, что делает его идеальным для автономных или не доменных установок.
Эта новая возможность закрывает давнюю брешь в безопасности и приводит установки на Linux в соответствие с требованиями управления паролями корпоративного уровня.
Комментариев нет:
Отправить комментарий