Есть сервер БД на котором есть порядка 20 баз. MSSQL
Отдельно есть веб сервера систем, тоже порядка 20 систем, которые рабаотают с этими базами.

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

Какие идеи как реализовать или ктото делал такого вида авторизации?
Желательно, чтобы не очень надолго пришлось делать.

Здравствуйте, merge, Вы писали:

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

В чем проблема? Создаешь в приложении несколько db connection и подключаешься к каждой базе с разными именами пользователей.

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, merge, Вы писали:

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

Б>В чем проблема? Создаешь в приложении несколько db connection и подключаешься к каждой базе с разными именами пользователей.

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

Как вариант — пишется служба, подключенная ко всем базам и предоставляющая "внешний" API для веб-серверов (с настройкой прав).

Здравствуйте, merge, Вы писали:

M>Есть сервер БД на котором есть порядка 20 баз. MSSQL
M>Отдельно есть веб сервера систем, тоже порядка 20 систем, которые рабаотают с этими базами.

M>Сейчас возникла идея сделать авторизацию на уровне баз, а не так чтобы один юзер сисадмин имел доступ ко всему на всех базах.
Приложение не должно быть сисадмином в принципе никогда. Есть более слабые роли, которые можно дать, но в целом сисадмин — это роль для DBA, а не для приложений.

M>Как правило приложение работает с одной базой. поэтому хотим сделать, чтобы у каждого приложения был свой юзер в СУБД.
M>Но почти в любом приложении есть иногда несколько запросов в другие базы.
Это типичная ситуация. В SQL Server есть аутентификация на уровне сервера (server principal получает вход на сервер БД) и на уровне каждой БД (database principal имеет доступ и права на уровне конкретной БД). Так вот у каждого приложения должен быть разный доступ на уровне БД (желательно через роли), где в рамках данной БД ему назначены только те права, которые нужны. Например, если он пишет в базу А, то дать права на запись в эту базу, и дополнительно право входа в базу B и чтение оттуда.

Здравствуйте, merge, Вы писали:

M>Здравствуйте, Буравчик, Вы писали:

Б>>Здравствуйте, merge, Вы писали:

M>Задача: уменьшить количество подключений или четко контролировать самую большую базу, которая служит мастер базой для других.

Зачем уменьшать количество подключений? Подозреваю, у вас там блокировки или даже дедлоки. Так вот, уменьшение количества подключений этому не поможет, потому что там дело совсем в другом.
M>То есть если другой базе/системе нужна мастер база, то будут либо джобы либо еще что-то что будет данные подгонять, но доступа в мастер базу не будет
Зачем все так усложнять?

Здравствуйте, merge, Вы писали:

M>Задача: уменьшить количество подключений или четко контролировать самую большую базу, которая служит мастер базой для других.
M>То есть если другой базе/системе нужна мастер база, то будут либо джобы либо еще что-то что будет данные подгонять, но доступа в мастер базу не будет

Все еще не понятна цель. Попробуй так: чем не устраивает текущее положение дел?

Здравствуйте, Milena, Вы писали:

M>Здравствуйте, merge, Вы писали:

M>>Здравствуйте, Буравчик, Вы писали:

Б>>>Здравствуйте, merge, Вы писали:

M>>Задача: уменьшить количество подключений или четко контролировать самую большую базу, которая служит мастер базой для других.

M>Зачем уменьшать количество подключений? Подозреваю, у вас там блокировки или даже дедлоки. Так вот, уменьшение количества подключений этому не поможет, потому что там дело совсем в другом.

локи бывают.
но не всегда проблема только в этом.
чаще всего диск не справляется

M>>То есть если другой базе/системе нужна мастер база, то будут либо джобы либо еще что-то что будет данные подгонять, но доступа в мастер базу не будет
M>Зачем все так усложнять?

какие предложения?

Здравствуйте, Milena, Вы писали:

M>Здравствуйте, merge, Вы писали:

M>>Есть сервер БД на котором есть порядка 20 баз. MSSQL
M>>Отдельно есть веб сервера систем, тоже порядка 20 систем, которые рабаотают с этими базами.

M>>Сейчас возникла идея сделать авторизацию на уровне баз, а не так чтобы один юзер сисадмин имел доступ ко всему на всех базах.
M>Приложение не должно быть сисадмином в принципе никогда. Есть более слабые роли, которые можно дать, но в целом сисадмин — это роль для DBA, а не для приложений.

M>>Как правило приложение работает с одной базой. поэтому хотим сделать, чтобы у каждого приложения был свой юзер в СУБД.
M>>Но почти в любом приложении есть иногда несколько запросов в другие базы.
M>Это типичная ситуация. В SQL Server есть аутентификация на уровне сервера (server principal получает вход на сервер БД) и на уровне каждой БД (database principal имеет доступ и права на уровне конкретной БД). Так вот у каждого приложения должен быть разный доступ на уровне БД (желательно через роли), где в рамках данной БД ему назначены только те права, которые нужны. Например, если он пишет в базу А, то дать права на запись в эту базу, и дополнительно право входа в базу B и чтение оттуда.

есть таблица на террабайт и программист может неудачным запросом подвесить базу или удалить лишнее. как с этим бороться?

Здравствуйте, merge, Вы писали:

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

M>Какие идеи как реализовать или ктото делал такого вида авторизации?
M>Желательно, чтобы не очень надолго пришлось делать.

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

Можно в "других базах" выделить нужные вьюшки или хранимки в ОТДЕЛЬНУЮ СХЕМУ и дать на неё доступ кому надо. Делается в принципе мышкой. Ну или создать "публичное api" в этой новой схеме.

Здравствуйте, merge, Вы писали:
M>есть таблица на террабайт и программист может неудачным запросом подвесить базу или удалить лишнее. как с этим бороться?
Не давать программисту доступа в продакшн.
Только на тестовые реплики. Код перед заливкой в продакшн тестируется.