Должны ли пользователи приложения быть пользователями базы данных?

Question

Моя предыдущая работа была связана с обслуживанием и программированием очень большой базы данных с огромными объемами данных. Пользователи просматривали эти данные в основном через веб-интерфейс интрасети. Вместо того, чтобы иметь таблицу учетных записей пользователей, каждая учетная запись пользователя была настоящей первоклассной учетной записью в СУБД, которая позволяла им соединяться с собственными инструментами запросов и т. Д., А также позволяла нам контролировать доступ через саму СУБД. использования нашей собственной логики приложения.

Это хорошая установка, если вы не находитесь в публичной интрасети и имеете дело с потенциально миллионами (потенциально злонамеренных) пользователей или чем-то еще? Или всегда лучше определить свои собственные средства обработки учетных записей пользователей, свои собственные разрешения, собственную логику безопасности приложений и раздавать только учетные записи СУБД опытным пользователям с особыми потребностями?

Answer 1

Редактировать: Я должен уточнить, что, несмотря на все, что в OP, вы логически определяете приложение, даже если код не существует. В противном случае это просто общедоступная база данных со всеми опасностями, которые влечет за собой.

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

Пользовательский объект должен быть определен системой, в которой он работает. Если вы фактически определяете их в другом приложении (базе данных), у вас потеря контроля.

Это не имеет смысла с точки зрения дизайна, потому что если вы хотите расширить эти учетные записи любыми данными (адрес электронной почты, номер сотрудника, MyTheme ...), вы не сможете расширить пользователь БД, и вам все равно нужно будет создать эту таблицу пользователей.

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

О масштабировании не может быть и речи. Представьте себе абстракцию, где у вас будут десятки или сотни тысяч пользователей. Это просто не подходит для управления учетными записями в БД, но как записи в таблице это просто данные. Давний аргумент «ну, а когда-нибудь они будут пользователями X», не держит меня на плаву, потому что я видел очень ограниченные внутренние приложения, которые становятся публично доступными, когда бизнес считает, что это может повысить ценность для клиента или компании. только что купленный гигантским партнером, которому теперь нужен доступ. Вы должны планировать разумную расширяемость.

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

У меня, похоже, много серьезных проблем, и я думаю, что другие более опытные SO могут перечислить больше.

Answer 2

Я не согласен с тем, что использование базы данных для контроля доступа пользователей столь же опасно, как и другие. Я из области Oracle Forms Development, где этот тип контроля доступа пользователей является нормой. Как и любое дизайнерское решение, оно имеет свои преимущества и недостатки.

Одним из преимуществ является то, что я могу управлять привилегиями выбора / вставки / обновления / удаления для КАЖДОЙ таблицы из одного параметра в базе данных. В одной системе у нас было 4 разных приложения (управляемых разными командами и на разных языках), которые использовали одну и ту же таблицу базы данных. Мы смогли заявить, что только пользователи с ролью диспетчера могли вставлять / обновлять / удалять данные в определенной таблице. Если бы мы не справились с этим через базу данных, то каждая команда приложения должна была бы правильно реализовать (продублировать) эту логику в своем приложении. Если одно приложение ошибочно, другие приложения пострадают. Кроме того, у вас будет дублирующий код для управления, если вы когда-нибудь захотите изменить разрешения для одного ресурса.

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

Я не согласен с тем, что «учетные записи пользователей базы данных по своей природе более опасны, чем что-либо в учетной записи, определенной вашим приложением». Привилегии, требуемые для изменения специфичных для базы данных привилегий, обычно НАМНОГО сложнее, чем привилегии, необходимые для обновления / удаления одной строки в таблице «ЛИЦА».

И «масштабирование» не было проблемой, потому что мы назначали привилегии ролям Oracle, а затем назначали роли пользователям. С помощью одного оператора Oracle мы можем изменить привилегию для миллионов пользователей (не то чтобы у нас было так много пользователей).

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

Answer 3

"каждая учетная запись пользователя была настоящей первоклассной учетной записью в СУБД, которая позволяла им соединяться с собственными инструментами запросов и т. Д."

не очень хорошая идея, если СУБД содержит:

• любая информация, охватываемая HIPAA или Sarbanes-Oxley или Официальным законом о секретах (Великобритания)

• информация о кредитной карте или другая информация о клиенте (PO, кредитных линий и т. Д.)

• личная информация (ssn, dob и т. Д.)

• информация о конкурентах, правах собственности или IP-адресах

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

о, и что сказал @annakata.

Answer 4

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

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

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

Не запирай вещи, потому что можешь. Объясните ответственным за последствия для безопасности, но не пытайтесь помешать людям делать что-то, потому что вы можете. Особенно когда они используются для прямого доступа к данным.

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

Answer 5

Я знаю, я отвечаю на очень старый пост, но недавно столкнулся с такой же ситуацией в моем текущем проекте. Я также думал о том же: «Пользователи приложения будут пользователями базы данных?». Вот что я проанализировал:

1. Определенно, не имеет смысла создавать такое большое количество пользователей приложения в базе данных (если ваше приложение будет использоваться многими пользователями).
2. Допустим, вы создали X (огромное количество) пользователей в базе данных. Вы открываете свободный доступ к вашей базе данных.

Давайте рассмотрим сценарий решения:

Существует два типа пользователей приложений (менеджеры и помощники). Для обоих транзакций требуется доступ к базе данных.

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

Что я предлагаю:

1. Создайте одну учетную запись базы данных для каждой роли. (Скажем Manager_Role_Account)
2. Позвольте вашему приложению иметь бизнес-логику для сопоставления пользователя приложения с соответствующей ролью (пользователь Том с ролью менеджера Manager_Role_Account)
3. Используйте пользователя базы данных (Manager_Role_Account), соответствующего указанной роли в # 2, чтобы подключиться к базе данных и выполнить ваш запрос.

Надеюсь, это имеет смысл!

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

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

1. Для Postgresql ниже Выбор метода аутентификации для финансовое приложение на PostgreSQL

   2. Для Oracle Проверка подлинности прокси

Надеюсь, это поможет!

Answer 6

* не очень хорошая идея, если СУБД содержит: * любая информация, охватываемая HIPAA или Sarbanes-Oxley или The Official Secrets Act (Великобритания) * информация о кредитной карте или другая информация о клиенте (PO, кредитных линий и т. д.) * личная информация (ssn, dob и т. д.) * информация о конкурентах, правах собственности или IP-адресах *

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

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

Answer 7

Это, в некотором смысле, похоже на: является ли сервер sql / AD хорошим для чего-либо

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

Я говорю не о всех приложениях, но я видел большое количество случаев, когда захват пароля так же прост, как открытие кода в блокноте, использование встроенной библиотеки DLL для расшифровки файла конфигурации или поиск файла резервной копии. (например, web.config.bak в asp.net), доступ к которому можно получить из браузера.

Answer 8

В наши дни многие инструменты запросов к базе данных очень развиты, и может быть стыдно переопределить мир, просто добавив ограничения. И до тех пор, пока права доступа пользователей базы данных правильно заблокированы, все может быть в порядке. Однако во многих случаях вы не можете сделать это, вы должны предоставлять высокоуровневый API для базы данных, чтобы правильно вставлять объекты во многие таблицы, не требуя специального обучения пользователя, чтобы он «просто добавил адрес в эту таблицу», почему не работает? ".

Если они хотят использовать данные только для генерации отчетов в Excel и т. Д., То, возможно, вы могли бы вместо этого использовать внешний интерфейс отчетности, такой как BIRT.

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

Answer 9

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

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

Answer 10

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