Иван Бодягин
Описать более-менее подробно все возможности новой версии Microsoft SQL Server задача не тривиальная, поэтому в данной статье предложен лишь небольшой обзор некоторых нововведений. А именно представления метаданных, схем, немного о безопасности, новые возможности при работе с индексами и новые встроенные типы данных. Я не ставил перед собой цели раскопать все в подробностях, поскольку на данный момент доступна лишь первая предварительная версия сервера и многое может измениться, но основная функциональность, очевидно, останется, поэтому ее и имеет смысл рассмотреть.
Одно из достаточно серьезных изменений в сервере касается метаданных. Ранее эта информация хранилась в нескольких системных табличках, и была довольно незатейливо структурирована, теперь же все стало несколько сложнее, но в то же время строже и логичнее. Вообще сейчас об этой части сервера сложно говорить что-либо наверняка, так как, судя по всему, часть заявленной функциональности еще не реализована, а часть ожидают довольно серьезные изменения. Главы в Books On-Line, относящиеся к безопасности, на данный момент попросту отсутствуют, но уже можно разглядеть направление дальнейшего развития и даже кое-что потрогать руками.
В предыдущих версиях сервера для обслуживания и тонкой настройки, как правило, использовались специальные системные хранимые процедуры. Теперь же вся эта функциональность вносятся в T-SQL, посредством создания новых DDL операторов или небольшого изменения старых. От системных же процедур в будущих версиях, судя по всему, откажутся. Функции диагностики, сбора статистики и просмотра прочей административной информации, также переходят от системных процедур и DBCC команд к специальным системным функциям.
Как уже говорилось, на данный момент что-то конкретное в этой части сервера раскопать сложновато, поскольку документация практически отсутствует. Но, тем не менее, уже ясно, что ожидаются серьезные изменения.
Row level security
В свое время Microsoft была заявлена поддержка безопасности на уровне отдельных строк в таблице, но как это будет выглядеть, пока непонятно. В BOL по этому поводу – только намеки, и нет ни строчки примера или хотя бы приблизительного описания, а все попытки сделать что-то наугад к успеху не привели.
Хранимые процедуры для создания пользователя и логина объявлены устаревшими и оставлены исключительно для обратной совместимости, на смену им пришли новые DDL операторы – CREATE USER, CREATE LOGIN, ALTER USER и ALTER LOGIN, которые предоставляют больше возможностей.
В Yukon можно применить политику логинов операционной системы к логинам SQL-сервера. При этом для контроля согласованности политик безопасности ОС и SQL-сервера используется специальное API, появившееся в Windows 2003 Server. При создании или изменении логина может быть выставлено два флага, CHECK_EXPIRATION и CHECK_POLICY, которые и определяют вмешательство ОС в политику логинов сервера.
Значение флага CHECK_EXPIRATION (по умолчанию ON) определяет, будет ли происходить проверка устаревания пароля. Установка этого флага в “OFF” означает, что проверка не производится, и пароль не устаревает.
Значение флага CHECK_POLICY (по умолчанию ON) определяет, будет ли производиться проверка стойкости пароля с использованием локальной политики ОС. Установка этого флага в “OFF” означает, что локальная политика ОС не используется, и действует внутренняя политика СУБД.
Есть также параметр HASHED, означающий, что пароль, указанный при создании или изменении логина, уже зашифрован, и параметр MUST_CHANGE, означающий, что при первом обращении пользователя с этим логином будет затребован новый пароль.
Если флаг CHECK_POLICY установлен в «OFF», то и CHECK_EXPIRATION так же должен быть установлен в «OFF». Если указан параметр MUST_CHANGE, то флаг CHECK_EXPIRATION должен быть установлен в «ON», а, следовательно, и CHECK_POLICY также должен быть «ON».
Естественно, все эти настройки применимы только к локальным пользователям SQL-сервера.
Например, если попытаться создать логин Vasya с простым и незатейливым паролем:
CREATE LOGIN Vasya WITH PASSWORD = 'password'
