Использование Postgresql в качестве среднего слоя. Нужно мнение

Question

Мне нужны некоторые мнения.

Я собираюсь разработать программное обеспечение для POS и инвентаря для друга. Это проект небольшого масштаба для одного человека, поэтому я хочу сделать архитектуру максимально простой.

Я использую Winform для разработки графического интерфейса (веб-интерфейс не имеет смысла для программного обеспечения POS). Для базы данных я использую Postgresql.

Программа будет контролировать доступ на основе ролей пользователей, поэтому мне нужно разработать средний уровень, используя веб-сервер, для управления доступом пользователей, или я могу просто установить пользовательские привилегии непосредственно в Postgresql.

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

Теперь выясняется, что использование базы данных для контроля доступа пользователей затруднительно. Я должен установить priveleges для каждой роли. Не говоря уже о том, что для некоторых таблиц привилегии находятся на уровне столбца. Это очень затрудняет рассуждение о безопасности.

Итак, теперь я должен установить все таблицы как недоступные, кроме суперпользователей. Программа будет подключаться к базе данных с использованием публичной роли. Поскольку таблицы недоступны публике, я собираюсь сделать общедоступные хранимые функции функцией SECURITY DEFINER (с ролью суперпользователя). Использование этих функций - единственный способ доступа к таблицам.

Я буду размещать роли пользователя и пароли в таблице. Поскольку сама таблица пользователя недоступна не суперпользователем, я сделаю функцию входа в систему, назовем ее fn_login(username, password). fn_login вернет ключ сеанса, если вход успешно завершен.

Для вызова других функций нам необходимо предоставить ключ сеанса для пользователя, например: fn_purchase_list(session_key), fn_purchase_new(session_key, purchase_id, ...).

Таким образом, я рассматриваю хранимые функции как API. Добавление нового пользователя будет проще, так как мне нужно только добавить новые строки в таблице пользователя, а не добавлять новые роли Postgresql. Мне не нужно будет устанавливать priveleges на уровне столбца. Все элементы управления будут выполняться программно.

Как вы думаете? Является ли этот подход выполнимым и масштабируемым? Есть ли лучший способ сделать это?

Спасибо!

Answer 1

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

Поскольку вы разрабатываете код приложения в .NET, этот код нужно доверять (в отличие от веб-приложения). Поэтому почему бы вам просто не реализовать свои роли и разрешения в коде приложения, а не в базе данных?

Моя забота о вашем заявленном подходе - это накладные расходы на хранение хранимых процедур. Скорее увидели бы, что вы пишете указанные функции в C#, а не в PostgreSQL. Тогда могут применяться стандартные методы контроля версий и разработки программного обеспечения.

Answer 2

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

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

Answer 3

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

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

Answer 4

Мой честный совет: не изобретайте ПОС и инвентарь. Возьмите один из existing projects и сделайте его лучше.