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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

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

• любая информация, охватываемая HIPAA или Sarbanes-Oxley или Закон о государственной тайне (UK)

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

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

• конкурентная, конфиденциальная или IP-информация

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

Это зависит (как и большинство вещей).

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

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

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

Ответ 9

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

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

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

Ответ 10

Я думаю, стоит подчеркнуть, что затронули другие ответы:

База данных может определять ограничения только на основе данных. Т.е. ограничение select/insert/update/delete на определенные таблицы или столбцы. Я уверен, что некоторые базы данных могут делать несколько более умные вещи, но они никогда не смогут реализовать ограничения, основанные на бизнес-правилах, такие как приложение. Что делать, если определенному пользователю разрешено обновлять столбец только до определенных значений (например, 1000) или только повышать цены или изменять один из двух столбцов, но не оба?

Я бы сказал, если вы абсолютно уверены, что вам никогда не понадобится ничего, кроме гранулярности таблицы/столбца, это сама по себе причина.

Ответ 11

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

Ответ 12

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

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

Возьмем сценарий для решения:

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

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

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

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

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

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

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

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

  2. Для Oracle Прокси-аутентификация

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