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 (сисадмины или девелоперы, зависит от конторы)

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

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