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

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

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

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

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

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

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

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

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

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

не хорошая идея, если RDBMS содержит:

• любая информация, покрытая HIPAA или Sarbanes-Oxley или законом о Государственной тайне (Великобритания)

• данные кредитной карты или другая клиентская информация о кредите (НА МЕСТЕ ПРОДАЖИ, строки кредита и т.д.)

• , персональные данные (ssn, д.р., и т.д.)

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

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

, о, и что сказанный @annakata.

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

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

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

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

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

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

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

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

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

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

Это, в некотором смысле, подобно: SQL-сервер / AD польза для чего-либо

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

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

*not хорошая идея, если RDBMS содержит: * любая информация, покрытая HIPAA или Sarbanes-Oxley или законом о Государственной тайне (Великобритания) * данные кредитной карты или другая клиентская информация о кредите (НА МЕСТЕ ПРОДАЖИ, строки кредита и т.д.) * персональные данные (ssn, д.р., и т.д.) * конкурентоспособный, собственный, или информация о IP*

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

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

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

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

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

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

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

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

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

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