Обеспечиваем безопасность в среде Dev/Sandbox

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

Сначала синтаксис:

GRANT EXECUTE ON SCHEMA:: 
<некоторая_схема>
TO < некоторый_пользователь>;

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

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

Недостатки
Представьте на секунду, что это означает в среде с широкомасштабными схемами, где каждый может загрузить и установить Microsoft SQL Server Management Studio за 10 минут через Интернет со скромной пропускной способностью: любые предохранительные меры можно обойти с помощью Microsoft SQL Server Management Studio, напрямую применяя хранимые процедуры к базе данных. Каждый, кто знает имя пользователя и пароль для базы данных или может получить доступ к строке подключения, имеет доступ к выполнению всех хранимых процедур, правами на которые обладает соответствующий пользователь. При этом все барьеры на прикладном уровне обходятся благодаря прямому обращению к объектам в Microsoft SQL Server Management Studio. Никогда не слушайте сторонних поставщиков и разработчиков внутри компании, утверждающих, что безопасность обеспечивается разделением приложений. Такая защита ненадежна: представьте, как просто установить Microsoft SQL Server Management Studio, определить связи серверов и баз данных и соответствующие пары «имя пользователя-пароль».

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


Недавно один из разработчиков, с которым я сотрудничаю, запросил разрешение dbowner в «песочнице» разработки, чтобы подобрать права для новых проектируемых хранимых процедур. Сказать, что я ответил уклончиво, значит, выразиться мягко. Помимо того что разработчикам разрешено предоставлять доступ, наличие у них прав db owner повышает вероятность разнообразных негативных сценариев, от изменения типов данных в таблицах до удаления таблиц и удаления базы данных. Еще одна тема, которую я охотно поднимаю при обсуждении, — вопрос о дополнительном влиянии разрешений db_owner, предоставленных для одной базы данных, на другую базу данных в консолидированной среде. Владелец роли db_owner имеет полный контроль над размерами файлов базы данных. Это означает, что владелец роли db_owner может изменить размер файла журнала транзакций, заполнив все свободное пространство на томе, выделенное для ваших журналов транзакций. Когда такое происходит, результаты получаются плачевные. Поэтому своему коллеге в правах db_owner я категорически отказал.

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

Синтаксис простой:

GRANT CONTROL ON SCHEMA::
< определенная. схема>
ТО <определенному_пользователю>; 

Преимущества
Мы возвращаемся к тому положению, когда администраторы баз данных уже не препятствуют обеспечению безопасности, и теперь у конечных пользователей есть права только на выполнение необходимых операций с объектами базы данных (при условии, что удастся удержать разработчиков в тех же рамках, в которых действуют администраторы баз данных). Разработчики не имеют прав, предоставляемых через db.owner, но все же их права шире, чем когда-либо раньше.

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



Я предпочитаю использовать гибридный вариант, когда модель GRANT CONTROL ON SCHEMA применяется к разработчикам в нашей «песочнице» или среде разработки в сочетании с предоставлением им прав в роли db ddladmin. При переносе объектов в среду, приближенную к производственной, мы используем инструменты сравнения, такие как Redgate SQLCompare, для подготовки сценариев развертывания, охватывающих базовые права, необходимые для любых новых хранимых процедур. Таким образом достигается возможность быстрого размещения в тестовой среде или «песочнице», но строгого контроля при движении к производственному этапу. В итоге мы соблюдаем принцип предоставления минимальных прав в каждой среде, кроме среды начальной разработки, одновременно не препятствуя быстрому проектированию.

---

Впервые слышите названия Dev и Sandbox, а единственное ваше желание - как можно быстрее утолить свою жажду азарта? В этом случае рекомендую вам прервать прочтение данной статьи и немедленно перейти на http://www.club-vulkan-onlayn.com/otzyvy/ (http://www.club-vulkan-onlayn.com/otzyvy/). Здесь вы найдете отзывы реальных игроков об азартных заведениях, работающих в онлайн режиме. Благодаря им вы сможете выбрать самое честное и неподкупное казино, в котором вы точно сможете сорвать куш!