Должны ли мои пользователи подключаться напрямую к базе данных? Как подключить пользователей к базе данных;

Question

Сначала я должен отметить, что я довольно плохо знаком с базами данных;

В настоящее время я настроил сервер MySQL и не уверен, как подключить моих пользователей к базе данных; Я хочу, чтобы они могли использовать мое программное обеспечение для отправки определенных предварительно определенных запросов (SELECT / ALTER).

В настоящее время, как я делаю это: я спрашиваю имя пользователя / пароль в моей первой форме. Затем я подключаюсь к базе данных, используя имя пользователя по умолчанию: "javaApp" / пароль: "javaApp", а затем я проверяю, данные, указанные в форме входа, соответствуют пользователю в пользовательской таблице;

Может ли кто-нибудь рассказать о том, как сделать это более эффективно / профессионально / более безопасно?

Может быть, какие-то веб-сервисы или что-то? У меня действительно нет никакой идеи.

Как это решают профессиональные разработчики программного обеспечения?

Заранее спасибо!

Answer 1

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

Подключение к одной учетной записи базы данных для всех пользователей

Преимущества

• Гибкость: Вы не обязаны использовать методы ограничения доступа, предоставляемые СУБД.

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

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

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

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

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

  Это может повлиять на качество ваших решений.

Недостатки

• Единая точка отказа: С точки зрения СУБД все ваши пользователи являются одним и тем же пользователем.

  То есть, если по какой-либо причине этот счет попадет в чужие руки, все будет потеряно. Конечно, вы можете (и должны!) Ограничивать такую ​​единственную учетную запись СУБД в максимально возможной степени на стороне СУБД. Но любой, кто имеет доступ к этой учетной записи, может делать все, что позволяют самые высокие привилегии вашего приложения.

  Также записывается, кто сделал, что можно обойти в таком случае. Поскольку злоумышленник обладает всеми правами, которыми обладает ваше приложение, а СУБД не имеет возможности определить, кто это может быть, они могут имитировать всех пользователей, которые им нравятся. Может быть, даже манипулировать (в базе данных) журналы. Найти следы атаки может быть сложнее.

  Пароль (или любые другие учетные данные) для одной учетной записи базы данных должен быть известен вашему приложению, чтобы предоставить его СУБД при входе в систему. Очевидно и особенно вы не можете «передать» эти знания в мозг пользователей. Если бы они знали это, они могли бы легко обойти ваше приложение, просто используя универсальный клиент (например, MySQL Workbench), выполняя действия, которые ваше приложение никогда не позволяло. И атаки изнутри не так уж редки. Например. некоторый пользователь, который манипулирует работой других, чтобы лучше выглядеть перед управлением в отношении рекламных акций. Или кто-то, кто чувствует себя преданным компанией и хочет отомстить. Вы называете это. (Или замените компанию сообществом, если это не коммерческий проект.)

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

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

• Меньше хорошо проверено: Если вы возьмете одну из хорошо известных СУБД, вы можете быть уверены, что ее используют многие другие. Многие люди проверяли это. Некоторые, возможно, даже явно его одитировали.

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

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

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

Преимущества

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

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

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

  Вы можете «передать» учетные данные для входа в мозг пользователей. Нет необходимости, чтобы он хранился физически где-то в доступном для вашего приложения месте. Это менее подвержено. (При условии, что пользователи не пишут это на постах рядом со своими клавиатурами или такими забавными вещами. Но это другая история ...) И если пароль требует изменения для одного пользователя, это не влияет на других пользователей или Установки программы вообще.

• Хорошо протестировано, хорошо поддерживается: Как я уже говорил выше, если вы возьмете одну из хорошо известных СУБД, вы можете быть уверены, что многие другие люди ее используют. Это было хорошо проверено, возможно, даже явно проверено.

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

  Возможно, это не важная вещь для вашего проекта. Я не могу судить о масштабе. Но я не хочу упоминать, что некоторые СУБД предоставляют средства для интеграции в сложные ИТ-ландшафты организации. Это также касается администрирования пользователей. Например, в SQL Server Active Directory могут использоваться пользователи. Это может помочь в целом упростить, централизовать и / или стандартизировать администрирование пользователей в организации и, следовательно, сделать его менее подверженным ошибкам. Это также может быть удобно для пользователей - может быть обеспечен единый вход.

Недостатки :

• Меньше свободы: Используя средства СУБД для управления пользователями и правами, вы должны придерживаться ее правил.

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

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

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

• Может потребоваться обучение: Особенно, когда вы новичок в мире СУБД, вам нужно научиться понимать, как средства управления доступом может обеспечить СУБД в целом, и как определенные СУБД предоставляют их или что они могут предложить дополнительно.

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

Заключение

Каждый из методов имеет свои преимущества и недостатки.

Выбор маршрута «один пользователь СУБД для всех» может быть правильным выбором, если требования безопасности не высоки. Большая гибкость может перевесить это.

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

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

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

Answer 2

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

Не определять соединение с базой данных в коде. Вместо этого используйте ресурс JNDI (особенно если вы работаете поверх сервера приложений, например Tomcat, который управляет ресурсами JNDI). Это позволит отделить ваш код от информации о соединении. Кроме того, вы можете использовать такие вещи, как пул соединений с JNDI, которые повысят производительность вашего приложения (а также будут обрабатывать такие вещи, как закрытое соединение). Параллелизм будет обрабатываться пулом соединений. См. Эту статью Oracle о ресурсах JNDI и , специфичную для Tomcat .

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

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

Вы хотите утомиться, позволяя пользователям определять свои собственные операторы SQL. Это открывает вам множество SQL-атак (ищите SQL-инъекции).

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

Наконец, взгляните на эти потрясающие лучшие практики .