Нужно ли создавать несколько пользователей для доступа к БД?

Question

[Александр Рублев]

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

Я говорю про этих пользователей.

Answer 1

[Roman]

Ммм, зачем? Обычно права доступа разруливаются приложением, некоторым ACL. Вы же не пишете сразу в БД из формы? Обычно это все делается через некую модель/сервисный слой, в котором этот самый ACL и реализован.

ЗЫ Допустим у вашего приложения 1К пользователей. Для каждого отдельный акк в мускуле?

Comments

[Roman]

Хотя если ваше приложение (десктопное, я так понимаю), работает с некоторой БД (в локальной сети, например) и пишет туда, то ваши опасения не лишены смысла. Расскажите подробнее о приложении и архитектуре.

[Александр Рублев]

Ну как бы коротко рассказать) Грубо говоря программа учета предприятия. Работники заходят и работают.
Одни вбивают заказы, другие вбивают приход материала, третьи вбивают выполненную работу.
Все это на нескольких компах в локальной сети + отдельный комп с БД
Для входа есть логин и пароль который конечно ограничевает работников от ненужных действий!
SQL запросы я пишу сам. ORM не использую.

[Roman]

Александр Рублев: то есть соединение с этой БД идет в приложения напрямую? Если так, то вот вам атака: злоумышленник в локальной сети снимает траффик Wireshark, вычленяет оттуда логин/пароль к БД, соединяется с ней клиентом и получает доступ к БД.

[Александр Рублев]

Да теоретически такое можно сделать!!! Но ведь я могу создать одного общего пользователя для всех работников с ограничеными возможностями!

[Roman]

Александр Рублев: да, пользователь MySQL с ограниченными правами это лучше, чем ничего.

Но стоит задуматься о другом пути: отельный сервер приложения, который управляет правами пользователей, в нем будет вся бизнес-логика, и он будет писать в БД и предоставлять API для приложений-клиентов. Это лучше по нескольким причинам: это безопаснее, более безболезненное расширение функциональности в будущем. Вдруг понадобится сделать не только десктопное приложение, но и мобильный клиент для сотрудников вне офиса? Тогда вы сделаете сервер приложения видимым из в интернета, и АПИ уже будет. Ну это так, на вскидку.

[Александр Рублев]

Это хорошая идея! Но для меня одного это сложновато! Я так то нуб в программировании))

Answer 2

[Станислав Макаров]

Ответ на вопрос зависит от архитектуры вашего приложения и его компонентов. Если у вас только тонкие клиенты, а бизнес-логика вся обернута в сервис и в ней реализован весь необходимый контроль доступа - то тогда отдельные пользователи не нужны (за исключением разве что отдельного пользователя для самого сервиса и отдельных - для административных целей, чтобы сервис максимально был ограничен в правах).

Если толстые клиенты тоже есть, т.е. такие, которые сами содержат бизнес-логику и напрямую пишут в базу, то тогда есть смысл разделять пользователей. Как правило, разделение идёт по ролям в приложении. Т.е. для всех бухгалтеров отдельный пользователь, для всех складовщиков - также. Это поможет ограничить множество допустимых действий с БД и уменьшить риски (которые по определению будут в случае толстых клиентов).

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

Comments

[Александр Рублев]

У меня скорее всего получается толстые клиенты! Я тоже думал о вашей схеме! Спасибо!

Answer 3

[entermix]

Не нужно, пользователи работают с программой, а она с вашим сервером.