Ну если за политикой паролей следит админ, то чего бояться то?

Нэт.

iptables и белые списки на айпишники этих клиентов, если айпишники не постоянные тогда :D только вдоль

Что вы имеете в виду под словами «только вдоль»?)

нет, перестук и списки

Безопасно ли сделать так, что бы база смотрела в нэт и принимала, грубо говоря, ИНСЕРТЫ непосредственно от клиентов?

Фи как грубо, инсерт в базу через инет, это как секс с первым встречным и презерватива нэт.

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

Уже одно это сгарантирует что

1 вас просто так не хакнут стырив пароль\вломав базу 2 у вас не будут висеть блокирвоки на таблице из-за отвалившихся соединений

vpn + белые списки ip + бэкапы

веб сервер(или какой нибудь свой сервер) принимает данные от клиентов, _ПРОВЕРЯЕТ ЭТИ ДАННЫЕ_ и делает в базе все, что нужно.

Безопасно ли сделать так, что бы база смотрела в нэт и принимала, грубо говоря, ИНСЕРТЫ непосредственно от клиентов?

Тут вопрос ещё и в организации.
Ты на каждое изменение в бд будешь обновлять все клиенты? А если нужно будет срочно закрыть какую нибудь уязвимость? В бд нет средств проверки входных данных. А если начальник захочет веб-интерфейс к бд? Будешь дублировать логику работы с бд из клиентов в веб приложение?
Получится эталонный быдлокод.

заюзай впн.

ИМХО прямого доступа к БД быть не должно. Я поднимал VPN и линк только через него. Всех клиентов, у которых есть белые IP можно пропустить через iptables, серых через VPN.

Ещё, как вариант, ограничить число соединений в секунду с БД через iptables, по аналогии с методами защиты SSH. Я сейчас не готов привести конкретный пример, но если загуглить есть описание, как сделать ограничение коннектов к SSH в рамках 5 коннектов в секунду и в случае превышения - банн на 10 минут. Опять таки, надо продумать вариант, что за серым IP может быть более 1-2-3 клиентов, либо такой серый IP добавлять в «белый» список iptables. Но это уже вопросы политики безопасности. Вероятность взлома это решение уменьшит на порядок. Ещё как вариант для развития «паранойи» предусмотреть алгоритм смены паролей на основе ключа, раз в сутки на пример, с блокировкой доступа к БД в тот период времени, когда работа не производится - типа ночью.

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

В бд нет средств проверки входных данных.

Да ты чо! А мужики то и не знают.

Да ты чо! А мужики то и не знают.

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

Ещё как вариант для развития «паранойи» предусмотреть алгоритм смены паролей на основе ключа, раз в сутки на пример, с блокировкой доступа к БД в тот период времени, когда работа не производится - типа ночью.

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

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

ну если организовать соединения к базе поверх SSL/TLS с аутентификацией по сертификатам, то это будет немного безопаснее

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

Ну так просвети.

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

Этот твой пост только подтверждает мои догадки.

Нет, только в локалхост.

Ну, если БД на отдельном сервере, то ещё в локалку можно.

Если есть белые списки адресов, то допустимо.

Нет, не безопасно

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

Безопасно ли, что бы база смотрела в нэт?

сча тебе насоветуют прятать жопу в земном ядре что бы она наружу не воняла.

как в SQL реализована проверка входных данных

http://2.bp.blogspot.com/_isk1o8_XWYA/R0ML6q6-HYI/AAAAAAAAAtY/_bm0dffd6Gc/s16...

Есть сервер c БД, который должен получать информацию из 100500 различных клиентов, не организованных в общую сеть. Безопасно ли сделать так, что бы база смотрела в нэт и принимала, грубо говоря, ИНСЕРТЫ непосредственно от клиентов?

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

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

Если я ошибаюсь, поправьте.

и таки дыры будут находить дальше. ТС должен разрешить доступ только с локалхоста, на котором параллельно крутиться веб прослойка или даже простенький RESTfull сервис. Прямой доступ к БД лютый ССЗБ.