Idol_111Просветите ДБА, пожалуйста, неужели ASP.NET Core теперь не поддерживает имперсонацию?
И все программы, которые подключаются через pool должны теперь использовать один общий логин (service pool login) для подключения к БД?
Ссылка

У веб-приложения должна быть единственная учётка для походов в БД, т.е. логин/пароль. Имперсонация нужна для приложений, выполняющихся на стороне пользователей, которые подключаются к БД напрямую. Для сервера приложений это полность лишено смысла, и протаскивать туда методы работы с БД из десктопа это натуральные грабли. Вроде как ДБА должен это понимать.

Idol_111Calabonga,

Спасибо за ответ.
Вы правы если речь идет об одном приложении, но если это API и он используется несколькими приложениями, убирать возможность управления правами доступа на уровне базы данных не просто глупо, но и опасно.

Правами доступа управляет приложение, так как оно находится на сервере, а не на компьтере пользователя, это абсолютно нормальная практика, это безопасно. Сказать, что это глупо, это критиковать 99% информационных систем.

Idol_111вот тут я Вас вообще не понял. см мой первый ответ. Вы считаете, что забить на безопасность на уровне ДБ - это наступать на грабли?

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

Idol_111Я слишком хорошо знаю реальность и 99% это не аргумент.

Представим, что одно приложение должно читать данные из таблицы, а другое не в коем случае (т.е. deny), и вот это уже не сделать.

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

Если приложения клиентов не имеют доступа к БД, но имеют доступ к API, при чём тут доступ на уровне ДБ?

https://docs.microsoft.com/ru-ru/aspnet/core/security/authorization/roles?view=aspnetcore-2.1

Вот уж невидаль, сервер приложения реализует доступ к данным )))

Idol_111похоже мы идем по кругу.

И в Вашем примере я не вижу как это через роли приложений реализовали раздельный доступ (колонки/строки).

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

Idol_1111)так делают все, потому что МелкоСофт "сказал". Т.е. это реально майнстрим на сегодня.

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

Управление правами пользователей через консоль БД, это огромная дыра в безопасности, это очень сложно сопровождать, управлять и контролировать. Тем более это не гибко.

Единственный случай, когда это может быть действительно уместным, при наличии клиентских приложений, которые ходят в БД напрямую. Там других вариантов и нет, кроме как закостылить безопасность на грантах и через слой ХП.

Но даже в случае клиентских приложений, делают API, и адекватную безопасность на уровне приложения на основе различных механизмов (role-based, claim-based, и т.д.)

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

Idol_1112)управление доступом к данным переносится подальше от источника данных, с БД уровня на уровень API. (что логически снижает безопасность, "чем дальше тем хуже контролировать"). Наверное в каких-то случаях это оправданно. Может, что-то облегчает (хотя мне сложно представить что).

Как раз наоборот, источником данных и средство выполнения операций для клиентов является API, соответственно безопасность должна решаться именно там. Какие проблемы с безопасностью вы видите? Я не вижу, и не только я.

Управление доступом пользователей тоже должно быть скрыто за слоем той же безопасности. Например, вышеподчинённые роли раздают права нижеподчинённым в рамках своих полномочий. Как вы это собираетесь решать на уровне БД?

Управление доступом пользователей осуществляется также через приложение (админка), как вы это будете решать на уровне БД?

Делегирование полномочий, как решать на уровне БД?

И т.д. и т.п. продолжать можно очень долго.

Idol_1113) рулят доступом теперь те кто рулит API (сисадмины или девелоперы, зависит от конторы)

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

Квалификацией, чтобы я могу пойти по ставить галочку, можно ли Васе редактировать документы? Издеваетесь?

Idol_111hVostt,

ну записывать меня в чистые админы я бы не стал :), я умудрился еще на фортране пописать.

1)2)3) Вы очевидно путаете админстрирование для конечного пользователя и для программы. Все, что Вы описали - это для конечного пользователя, и вне сомнения это должно быть сделано на уровне программы, тут спору нет.

Еще раз опишу, что меня беспокоит как ДБА:
Несколько программ обращаются к API и затем обезличиваясь под ОДНИМ логином лезут в БД. Это в принципе не есть хорошо (простые примеры привел выше).
А уж о решение проблем с производительностью вообще можно свет тушить. Какая программа уронила сервер надо долго и нудно ковыряться в логах теперь не только БД, но еще API. Супер!

Я ничего не путаю. Никто не отменял права для учётки, под которой ходит приложение в БД. Но оно одно на всё приложение, а не для каждого пользователя персонально. Потому что это маразм для сервера приложений.

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

Переубеждать вас в чём-то не буду, потому что это не вопрос веры, а вопрос знаний и опыта, у вас с этим наблюдаются некоторые проблемы, это не страшно. Как говорится, придёт с опытом. Или не придёт, но это зависит только от вас, уж точно не от меня или от другого участника дискуссии.

Shocker.ProДа вроде ТС и говорит, что у него одна учетка на приложение, просто приложений 20 штук.

Ну можно разных учёток выдать каждому приложению. Можно даже сопоставить для каждого пользователя отдельную строку соединения, мало того, что ходить будет с разными привилегиями в БД, так ещё и в разные БД по желанию


Уже, иногда очень рано просыпаюсь, потом сижу читаю что-нибудь, или пишу здесь %)

Shocker.ProhVosttНу можно разных учёток выдать каждому приложению. Можно даже сопоставить для каждого пользователя отдельную строку соединения, мало того, что ходить будет с разными привилегиями в БД, так ещё и в разные БД по желанию Вот я и говорю. Но ТС очень хочет привязаться в этом месте к AD и пока непонятно, почему такое жесткое требование.

Насколько я понял, требования нет, как такового.

Shocker.ProА, вот теперь догнал.
Под приложением подразумевается толстый клиент, а не серверное приложение. А под АПИ подразумевается как раз серверное приложение.

Т.е. это типа сквозной интерфейс к БД, через API. Что лишено какого-либо смысла.