Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Mongo DB, UniFi Network
 
Есть какая-то причина, по которой выбрали MongoDB, а не другую базу данных, например PostgreSQL, MySQL или Firebird (список, конечно, большой)? Я провел большую часть жизни, прописывая, проектируя и внедряя огромные защищённые базы данных. Многие современные СУБД, такие как Mongo, кажутся довольно ненадёжными и, что самое главное, я не могу ими пользоваться, потому что они изначально небезопасны. Если честно, MongoDB безопасна только когда машина, на которой она стоит, выключена.

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

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

R+C
 
Что ж, мне просто приходится разбираться с некоторыми вопросами аккредитации на небольшом локальном объекте, где используются UniFi AP. Чтобы избежать бесконечных обсуждений и доработок ради получения обязательной аккредитации, мы не используем контроллер UniFi после настройки точек доступа. Так что MongoDB защищена. Исходную установку мы уже обезопасили, но не могли гарантировать, как обновления повлияют на безопасность в будущем.
 
Это меня настолько рассмешило, что я чуть не упал в обморок. На мой взгляд, MogoDB — на самом деле довольно подходящий выбор, учитывая масштаб и специфику приложения. Недостатки в основном доставляют неудобства, но в данном случае это не катастрофа уровня полного краха системы.
 
Нет, я на этот раз не собираюсь брать вину на себя. Я рад, что кто-то другой выложил такую элементарную проблему — так мой основной посыл становится понятнее всего. R+C
 
Это твой отчёт об ошибке, Uberseehandel? 😉
 
Должен признаться, что считаю глупым то, что база данных вообще никак не защищена паролем. Это значит, что любой, кто получил доступ к оболочке на машине, может прочитать всё, что угодно в базе, даже пароль администратора (используйте ace; db.admin.find()), что фактически равно свободному доступу. Наверное, будет разумно настроить базу так, чтобы она слушала через unix-сокет с правами 0600.
 
https://speakerdeck.com/mitsuhiko/a-year-of-mongodb может быть интересно. Надеюсь, кто-нибудь из UBNT прочитает эту отличную презентацию Армина Ронахера. В ней коротко и ясно изложены реальные проблемы, присущие MongoDB. Предложение рассмотреть RethinkDB в качестве альтернативы — интересное, и я планирую с ним ознакомиться в ближайшее время. Роначер также написал очень занимательный блог — SQL is agile — в котором объясняет: «Я бы никогда снова не начал проект с MongoDB или, вообще, с любой другой нереляционной базы данных в качестве основной». Пока я изучал варианты настройки MongoDB и к середине июня планирую предложить рекомендации по оптимизации конфигурации с точки зрения безопасности и пропускной способности, так как сейчас у меня довольно много дел. Общая СУБД для всех продуктов Ubiquiti Network — это очень разумно. R+C
 
https://speakerdeck.com/mitsuhiko/a-year-of-mongodb может быть интересно.
Страницы: 1
Читают тему (гостей: 1)