Как правильно подключать клиентское приложение к базе данных?
Очень часто мне приходится подключать приложения (например, wpf) к базе данных. В примерах и в задачах чаще всего это подключение происходит либо через учётную запись windows, либо, господи помилуй, через sa пользователя.
как же правильно производить подключение к базе данных?
Мои предположения заключаются в том, что для каждой роли клиентского приложения необходимо создать свою учётную запись с правами на сервере.
Как, например, подключение происходит у приложения "вконтакте"? Я думаю, что у них есть определённая учётная запись базы данных, а администраторы копаются в ней уже через свою, с полными правами.
Правка 1: В данном случае я имею в виду роли БД. Т.е. на стороне сервера должна создаваться роль, определённая для приложения. По моим предположениям, в строке подключения к базе данных я могу прописать соответствующие логин и пароль. (Если я конечно в правильном направлении)
Ответы (2 шт):
Ваше предположение верно.
Часто создают, как минимум две учетных записи для ролей:
- Application - имеет право читать и писать данные.
- Deployer - может выполнять DDL. Используется на этапе разворачивания приложения и при установке новых версий, когда нужно запускать миграции.
Если приложение состоит из нескольких разных компонентов, то роль Application может быть еще поделена, например, если у приложения есть админка, то там может использоваться отдельная учетная запись, к которой есть права изменения в таблицах конфигурации самого приложения. Для модуля отчетов может быть создана отдельная учетка с правами только на чтение и т.д.
Администраторы БД используют отдельные учетные записи, у которых прав побольше. В организациях, которые серьезно относятся к безопасности, встречал подход, когда для расследований проблем на проде, ответственным разработчикам дают права только на чтение, а если нужно что-то исправить, то добавляют прав кратковременно.
Правильно - это так, чтобы вы могли контролировать кто имеет досуп к БД (аутенификация) и что он там может делать (авторизация).
Например, если у вас настольное WPF приложение, которое лезет само напрямую в БД (что само по себе не лучшее решение), то единтвенный способ для вас контролировать кто и что может делать с БД - это контроль на уровне пользователей и прав вашей БД. То есть либо каждый юзер сам вводит свой логин/пароль (БД аутенификация), либо используется доменная аутентификация + БД-авторизация.
Если же у вас вебсайт, то есть конечный юзер может даже никогда и не узнать, что вообще используется какая либо БД, то тут 2 варианта:
Имперсонализация, когда учетные данные пользователя используются для доступа к БД. Такое распрострнанено в интранете - частных корпоративных сетях, когда пул пользователей конечен и управляется централизованно. Обычно такое просят безопасники, которые хотят знать все действия юзера вплоть до транзакций.
Более рспространенный вариант - использовать данные аутенификации юзера для его авторизации уже на вашем сайте/сервисе. То есть сайт решит, какие юзеру доступны операции, но при этом сам сайт ходит в БД под какой то единой записью для всего сайта. Такая схема широко используется как на публичных веб сайтах, так и во всяких микросервисах, где каждый микросервис (которых может быть сотни, и соответсвенно, баз данных тоже может быть сотни) сам уже решает, что юзер может делать, а что не может. Это позволяет снизить нагрузку на БД, так как БД больше не парится по поводу юзеров и их прав. К примеру, в микросервисной архитектуре, где может быть множетство баз данных, будет расточительно хранить каждого юзера в каждой из БД.