Удаленный доступ к MySQL - UNSAFE?

Question

Небезопасно открывать порт сервера mysql для разрешения удаленных подключений? Если это небезопасно, какое лучшее решение?

EDIT:

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

Какие проблемы безопасности возникают в этой среде? Есть ли лучшее решение?

Answer 1

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

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

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

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

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

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