Скрытие учетных данных MySQL в приложении

Question

Скрытие учетных данных MySQL в приложении

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

Моя первоначальная идея состояла в том, чтобы создать базу данных MySQL, жестко закодировать учетные данные в приложении и подключить приложение к базе данных MySQL. База данных MySQL будет тогда иметь таблицу под названием «пользователи», в которой будут храниться имена пользователей, пароли и разрешения. Затем приложение запросит сервер и выполнит аутентификацию.

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

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

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

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

4

c++desktop-application mysql security

Решение

Другие решения

Там, где я работаю, я видел две практики:

Каждый объект (человек, вещь или бизнес (в зависимости от необходимого уровня детализации), обращающийся к базе данных) имеет свои собственные учетные данные. Это использовалось в MSSQL и в базе данных Rocket Universe. В основном это программное обеспечение для розничной торговли и устаревшее программное обеспечение.
Мы сами размещаем приложение и используем отдельную систему аутентификации для пользователей. Учетные данные базы данных хранятся на нашем сервере, где размещено приложение. Клиент ничего не знает о резервной базе данных. Обычно это веб-приложения и веб-сервисы.

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

Упаковка базы данных в веб-сервис дает вам несколько возможных преимуществ:

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

Недостатки, которые я вижу:

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

RESTful архитектура: http://en.wikipedia.org/wiki/Representational_state_transfer

HMAC: http://en.wikipedia.org/wiki/Hash-based_message_authentication_code

Наша система HMAC работает следующим образом:

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

Вышеуказанное уязвимо для атак «человек посередине», если HTTPS не используется, поэтому часто люди создают сообщение на основе одноразового номера и запрашиваемого URL-адреса вместе с отметкой времени и вычисляют HMAC на этом основании. Затем сервер заново создает сообщение на основе URL-адреса, проверяет, находится ли временная метка в каких-то пределах (+/- 4 минуты или около того), и затем авторизует пользователя на основе этой информации.

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

Резюме: Учетные данные создаются пользователем за пользователем, конечный пользователь не знает базы данных, веб-служба оборачивает базу данных в API RESTful, а система на основе ролей используется для детализирования разрешений.

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

2

Давайте рассмотрим два способа работы с базой данных:

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

Учитывая ваш вариант использования:

действительный действительный серийный номер или для хранения / чтения информации о конкретном пользователе

он может быть разработан следующим образом для обеспечения безопасности. (Я не эксперт в этом)

Клиент напрямую подключается к базе данных и манипулирует базой данных
- Вам не нужно использовать администратора для посещения базы данных, вместо этого вы создаете пользователя только для клиента, и ограничить права доступа пользователя только просмотр (определенные данные). И вы можете применить политику безопасности в базе данных, изменив привилегии для этого пользователя.
- вы можете проконсультироваться MySQL :: MySQL 5.1 Справочное руководство :: 6 Безопасность для получения дополнительной информации.
  - 6.2 Система привилегий доступа MySQL
  - 6.3 Управление учетными записями пользователей MySQL
Сервер подключается к базе данных и предоставляет интерфейс для использования клиентом
- Вы можете использовать HTTP и предоставить клиенту интерфейс для использования. И только база данных подключается к базе данных.
- Что-то вроде RESTful API, есть много простых в использовании фреймворков, которые обеспечивают аутентификацию и авторизацию.

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

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

0

Источник

Accepted Answer

Как отметил @Perception. Лучше всего здесь реализовать веб-сервис перед MySQL. Вы не хотите, чтобы неизвестные номера клиентов с неизвестных IP-адресов имели доступ к вашей базе данных.

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

Веб-служба может также предложить вам возможность контролировать аутентификацию и авторизацию пользователей любым количеством способов (комбинация «пользователь / пароль», доступ на основе токенов, доступ OAuth и т. Д.).

3