Такая странная тема для очередной заметки про SQL Server 2014 CTP1 выбрана не случайно. С завидным постоянством на форумах по MS SQL Server появляются вопросы из разряда:
"Как мне защитить мои данные от администратора БД?".
До недавнего времени эта задача была нерешаемой, но, благодаря появлению в SQL Server 2014 трёх новых разрешений уровня сервера (CONNECT ANY DATABASE, IMPERSONATE ANY LOGIN, и SELECT ALL USER SECURABLES), у нас появилась возможность более гибко управлять серверными ролями. В том числе мы можем создать администраторскую серверную роль с полным запретом на доступ к пользовательским данным.
Напомню, что возможность создавать серверные роли появилась впервые в SQL Server 2012 (CREATE SERVER ROLE), а в версии SQL Server 2014 разработчики пошли чуть дальше.
Но всё по порядку. Сперва создадим новую серверную роль NewServerRole, принадлежащую предопределенной роли сервера sysadmin (Члены предопределенной роли сервера sysadmin могут выполнять любые действия на сервере).
create server role NewServerRole authorization sysadmin;
go
Теперь создадим для демонстрации новый логин, который мы включим в нашу серверную роль NewServerRole. При этом не забываем прежде выставить смешаный режим авторизации (правой кнопкой мыши по нашему серверу БД => Properties => Security => Server authentication) и перезапустить службу SQL Server.
create login NewLogin with password = 'Qwerty1';
go
alter server role NewServerRole add member NewLogin;
go
А теперь делегируем нашей роли права CONTROL SERVER
grant control server to NewServerRole;
go
Теперь можем подключиться к нашему серверу БД под новым логином NewLogin и выполним ряд инструкций, чтобы убедиться в том, что у нас полные права.
--Создадим новый логин
create login NewLogin2 with password = 'Qwerty1';
go
--Изменим серверные настройки
exec sp_configure 'show advanced options', 1;
reconfigure;
go
exec sp_configure 'xp_cmdshell', 1;
reconfigure;
go
--Выполним xp_cmdshell
exec xp_cmdshell 'dir c:';
go
--Обратимся к данным в БД master
select * from master..spt_values;
go
Ну а теперь запретим нашей серверной роли доступ ко всем пользовательским данным:
deny select all user securables to NewServerRole;
go
Дальше переключимся в сессию под нашим тестовым логином NewLogin и попробуем выполнить следующий скрипт:
--Создадим новый логин
create login NewLogin3 with password = 'Qwerty1';
go
--Изменим серверные настройки
exec sp_configure 'show advanced options', 1;
reconfigure;
go
exec sp_configure 'xp_cmdshell', 1;
reconfigure;
go
--Выполним xp_cmdshell
exec xp_cmdshell 'dir c:';
go
--Обратимся к данным в БД master
select * from master..spt_values;
go
В результате мы сможем выполнить все инструкции, кроме последней:
The SELECT permission was denied on the object 'spt_values', database 'master', schema 'dbo'.
Ниже несколько сценариев, которые могут быть заданы с помощью новых разрешений:
- Администратор БД без доступа к пользовательским данным (как в данном примере)
- Администратор БД без возможности изменять логины
- Администратор БД без возможности выдавать разрешение impersonate (переключать контекст) для других логинов
- Роль с возможность читать ВСЕ пользовательские данные без администраторских прав
- Роль с возможностью читать различные метаданные, без доступа к пользовательским данным
- Роль с возможность impersonate себя с любым другим логином, кроме логинов с административными привилегиями (sa, sysadmin)
Подписаться