Какие разрешения на «настоящие» базы данных предоставляют пользователям?

Question

Читая ответ @ PerformanceDBA на Историческая / проверяемая база данных , он сделал следующее заявление:

В реальной (стандартной ISO / IEC / ANSI SQL) базе данных мы не делаемGRANT INSERT / UPDATE / DELETE разрешение для пользователей.Мы ПРЕДОСТАВЛЯЕМ ВЫБОР и ССЫЛКИ только (для выбранных пользователей). Все ВСТАВКИ / ОБНОВЛЕНИЯ / УДАЛЕНИЯ кодируются в Транзакциях, что означает хранимые процедуры.Затем мы ПРЕДОСТАВЛЯЕМ EXEC для каждого сохраненного процесса выбранным пользователям (используйте ROLES для сокращения администрирования).

Это правда?Как это сочетается с инструментами ORM, которые динамически генерируют INSERT / UPDATE?

UPDATE

ОК, так что вот пример.У меня есть веб-приложение с двумя интерфейсами: Admin и Пользователь .Администратор использует тяжелый ORM, способный динамически генерировать сотни, если не тысячи отдельных команд SQL.

Взаимодействие с пользователем намного проще, и я получилдюжина или около того SP, которые обрабатывают любые UPDATE / INSERT для пары кнопок голосования.Очевидно, что пользователи, под которыми работают приложения, имеют очень разные наборы разрешений.На стороне администратора пользователь БД для ORM имеет полный CRUD-доступ к соответствующим таблицам, для этого приложения вообще не используются SP, и я бы не стал касаться данных, не пройдя бизнес-логику в модели предметной области.,Даже массовый импорт данных обрабатывается через ORM.ИП на стороне пользователя. Я считаю небольшую уступку этому принципу только потому, что это такой особый случай.

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

Answer 1

Джайв, как твоя грампа на рейве. ORM могут использовать SP, но они не получают от них наилучшего.

С.П. Конечно, жизнь была такой, какой была раньше, это было похоже на одиннадцатую заповедь, но, как вы заметили, ORM действительно не работают так. Раньше я думал, что весь слой SP сам по себе является своего рода препубертатным ORM, вы взяли свою реляционную БД, сделали несколько соединений и вернули набор данных со столбцами / свойствами, необходимыми для заполнения ваших объектов.

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

Хорошие администраторы баз данных знают, что защищенная БД с доступом к таблицам столь же безопасна, как и БД с доступом только к SP. Убедить менее уверенных администраторов в этом гораздо сложнее.

Answer 2

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

Таким образом, если вышеизложенное является целью проектирования, то пользователю приложения требуется только SELECT и EXECUTE в базе данных.Вот почему:

create procedure MyTestProcedure
with execute as 'UserWithDMLRights'
as

    -- your CRUD code

go

Если типичный пользователь приложения имеет только SELECT и EXECUTE, тогда разрешений для выполнения вышеуказанной хранимой процедуры будет достаточно.INSERT/UPDATE/DELETE в хранимой процедуре будет выполняться в контексте безопасности UserWithDMLRights, и у этого пользователя базы данных должны быть разрешения INSERT/DELETE/UPDATE.

Что касается ORM, я склонен согласитьсяс тобой.Я полагаю, что L2S просто делает многочисленные вызовы специальных запросов с sp_executesql, поэтому я полагаю, что вы столкнетесь с проблемой с этой теорией и использованием вышеупомянутой практики безопасности.