Здравствуйте, LWhisper, Вы писали:
LW> Поверхностные знания по всем. NoSQL я отмёл по той же причине, что и самописные сервисы — с одной стороны SQL, с другой неведомая хрень. Между ними нужно будет наладить взаимодействие. А хочется единый интерфейс малой кровью.
Если хочется непременно SQL везде, то пусть это будет точно такой же SQL, то есть SQL Server, например Express. Тогда это будет единым интерфейсом. А иначе поддержка нескольких диалектов SQL и особенностей поведения разных СУБД ничем не проще любого другого интерфейса, и все преимущество улетучивается.
LW> Да, можно парсить SQL-запросы и превращать их в команды собственного API. Зачем?
Это я тоже не понял, зачем парсить SQL?
LW> Простейший REST API не поддерживает персистентную коннекцию и транзакционность.
Отсутствие "персистентной коннекции" это скорее бенефит в твоем кейсе, со стейтфул протоколом поимеешь проблемс (скорее всего, я задачи твоей не знаю).
А транзакционность (в рамках запроса) будет, если реализуешь; что мешает?
С>Какого именно лиха?
SQL база (как и любая другая), не должна быть доступна за пределами твоей LAN. Будет доступна — будет сломана. Есть специальные компоненты, которые созданы для того, чтобы торчать в интернет — называются веб-серверами. Данные в базе должны быть доступны через веб-интерфейс, физически это может быть какой-нибудь апач или nginx, но никакая база данных, никогда не должна даже пинговаться через WAN. Как-то так.
W>В основном лихо кроется в том, что SQL это stateful протокол. К примеру, нужно отслеживать обрыв коннекта и уметь на него реагировать.
Эм... нет. Лихо кроется в том, что далеко не все базы данных умеют в SSL. Но даже когда умеют бывает вот такое — http://www.securityweek.com/thousands-mongodb-databases-found-exposed-internet
Но даже когда все хорошо настроено, база данных не должна торчать в интернет, иначе ее всегда можно как минимум заDDOSить. Так не делают по причине херовой безопасности, а не потому что протокол stateful. Это обходится, как-раз таки (UPSERT в постгресе, например). Все остальное — глубоко вторично.
W>>Делаешь простейший REST API LW>Простейший REST API не поддерживает персистентную коннекцию и транзакционность.
Все это делают поверх HTTP, разными способами. И BTW, в 21-м веке все используют HTTP для ВООБЩЕ ВСЕГО не просто так — https://en.wikipedia.org/wiki/HTTP_persistent_connection Его полезно знать, это отличный протокол.
LW>Ищется решение из коробки. А так проще написать собственный TCP сервер, который будет принимать входящие запросы и форвардить их локальной SQLLite-базе.
Ну и например огрести проблем, когда у тебя база не откроется, из-за того, что твой самописный TCP сервер портит память а база данных живет в одном адресном пространстве с твоим сервером, портится write buffer и после рестарта данные не читаются. SQLite — он хороший, но он для конфигов и всего того, что не жалко потерять нафиг (прямо как монга).
Здравствуйте, ELazin, Вы писали: С>>Какого именно лиха? EL>SQL база (как и любая другая), не должна быть доступна за пределами твоей LAN. Будет доступна — будет сломана.
Расскажите мне, пожалуйста, каким именно образом будет сломана база. Ну вот у нее есть логин и пароль, врагу они неизвестны, что он дальше будет делать?
.
Сейчас мне расскажут про перебор паролей. Подберут, к 2050 году.
Сейчас мне расскажут про уязвимости. Как будто их не бывает в веб-серверах.
Если я скажу про авторизацию через клиентский сертификат, мне ответят про heartbleed, хотя — эта уязвимость затронула вообще всех, а не только СУБД.
А еще есть такое, как ограничение списка IP, с которых возможно подключение.
Я знаю ровно одну фундаментальную проблему с прямым доступом к базе. Это то, что любой, имеющий возможность посылать запросы, может написать такой заведомо неэффективный запрос, который загрузит базу и заставит всех остальных клиентов простаивать. И вот это не решается никак вообще, или лепи веб-методы с кучей параметров для всех возможных сочетаний действий на клиенте, либо давай возможность посылать сырые запросы и опасайся подобного DoS.
Я все понимаю, существует общепринятая практика — прятать базу за каким-то сервисом. Но ПОЧЕМУ это делается, все причины, и актуальны ли они сейчас — уже мало кто может объяснить.
С>Расскажите мне, пожалуйста, каким именно образом будет сломана база. Ну вот у нее есть логин и пароль, врагу они неизвестны, что он дальше будет делать? С>Сейчас мне расскажут про перебор паролей. Подберут, к 2050 году.
Большинство СУБД по дефолту работают без шифрования, т.е. твой пароль будет гулять по сети в plain text. В сетевых компонентах БД бывают уязвимости, google — %your-db-name% CVE. Зная IP твоей БД кто угодно может получить к ней полный доступ, используя какую-нибудь серьезную уязвимость.
С>Сейчас мне расскажут про уязвимости. Как будто их не бывает в веб-серверах. С>Если я скажу про авторизацию через клиентский сертификат, мне ответят про heartbleed, хотя — эта уязвимость затронула вообще всех, а не только СУБД.
Они бывают и в веб серверах, но в нормальной системе, получив доступ к веб серверу (который живет в DMZ), ты мало что можешь сделать, ведь база данных находится на другой машине, за файрволлом через который доступен только порт, необходимый для подключения к БД и у приложения на веб сервере есть credentials минимально возможного уровня, чтобы приложение могло работать и все. В нормально спроектированной системе, приложение, которое крутится на веб сервере может только добавлять данные, но не может их удалить или испортить.
С>А еще есть такое, как ограничение списка IP, с которых возможно подключение.
Ты видимо шутишь.
С>Я знаю ровно одну фундаментальную проблему с прямым доступом к базе. Это то, что любой, имеющий возможность посылать запросы, может написать такой заведомо неэффективный запрос, который загрузит базу и заставит всех остальных клиентов простаивать. И вот это не решается никак вообще, или лепи веб-методы с кучей параметров для всех возможных сочетаний действий на клиенте, либо давай возможность посылать сырые запросы и опасайся подобного DoS.
Есть разные решения этой проблемы. Во первых правильный API, который позволяет не лепить по методу на любое сочетание, а хорошо композируется и при этом позволяет на стороне сервера приложений построить нормальный запрос. Во вторых, так как запросы к БД делает сервер приложений, он может делать их более умным способом, например отрубая долгие запросы по таймауту, чтобы освободить пулл соединений к БД (это скорее в помощь к "во первых" чем как самостоятельное решение). В третьих, в некоторых СУБД есть фича для совсем ленивых, не помню как называется, позволяющая перед выполнением запроса построить план и оценить время выполнения и после этого отдуплить слишком тяжелые запросы.
С>Я все понимаю, существует общепринятая практика — прятать базу за каким-то сервисом. Но ПОЧЕМУ это делается, все причины, и актуальны ли они сейчас — уже мало кто может объяснить.
Да уж, стереотип какой-то. И не говори (и кстати не просто за сервисом, а за сервисом НА ДРУГОЙ МАШИНЕ! это важно)
Так стоит делать как минимум для того, чтобы админ конторы, в которой ты работаешь, не написал на тебя докладную начальству, после которой тебя выгонят на мороз.
Здравствуйте, ELazin, Вы писали:
EL>Большинство СУБД по дефолту работают без шифрования, т.е. твой пароль будет гулять по сети в plain text. В сетевых компонентах БД бывают уязвимости, google — %your-db-name% CVE. Зная IP твоей БД кто угодно может получить к ней полный доступ, используя какую-нибудь серьезную уязвимость.
Нет, не кто угодно. Я уже описал возможность ограничения доступа по IP. И из дальнейшего описания будет ясно, почему это чуть ли не самая действенная мера защиты любых сервисов.
EL>Они бывают и в веб серверах, но в нормальной системе, получив доступ к веб серверу (который живет в DMZ), ты мало что можешь сделать,
Можно использовать цепочку уязвимостей. Сначала проломить веб-сервер или приложение, затем базу.
EL>у приложения на веб сервере есть credentials минимально возможного уровня, чтобы приложение могло работать и все. В нормально спроектированной системе, приложение, которое крутится на веб сервере может только добавлять данные, но не может их удалить или испортить.
Уже упомянутый mysql как правило используется в таких очень широко распространенных проектах, как wordpress, opencart и прочее такое, уебное. Где хватает собственных уязвимостей. Где никто особо не заморачивается настройкой прав для учетной записи БД, под которой будет работать веб-приложение. Где просто люди, сроки и деньги малость не те, чтобы все это грамотно настроить.
С>>А еще есть такое, как ограничение списка IP, с которых возможно подключение. EL>Ты видимо шутишь.
Где же тут шутка? 54.93.97.248 — ломай сколько угодно, доступ открыт только для определенных IP. Тебе даже не удастся понять, что за сервисы там работают. Никому стороннему не удастся понять.
EL> запросы к БД делает сервер приложений, он может делать их более умным способом, например отрубая долгие запросы по таймауту, чтобы освободить пулл соединений к БД (это скорее в помощь к "во первых" чем как самостоятельное решение). В третьих, в некоторых СУБД есть фича для совсем ленивых, не помню как называется, позволяющая перед выполнением запроса построить план и оценить время выполнения и после этого отдуплить слишком тяжелые запросы.
Решения впечатляющие. Строился отчет полчаса, а потом ррр-раз — и отвалился по таймауту, говоря "чегой-то у вас отчет слишком большой".
Эта проблема именно фундаментальная, и в какой-то мере решиться она могла бы с помощью некоего нового языка запросов, с гарантированным завершением. Total functional programming и все такое.
Беда в том, что писать на других языках в отрасли как-то не спешат. А фуле — и так все работает, главное, сделать потолще бутерброд из костылей — кривенькую СУБД, где еще недавно не рекомендовалось делать джойны, где сплошное страшненькое Си образца 1975 года с арифметикой указателей и неизбежными уязвимостями (в сетевой части уязвимости, Карл! в обработчике протокола! Шел 2015 год, до сих пор в индустрии нет ни одного генератора для сетевых протоколов! есть WSDL, и даже 2.0 есть, только каждый вася реализовал его по-своему). Сверху этого кривенький же вебсервер на той же самой сишечке с уязвимостями. А на нем сверху уеб-приложение на пхп — с чем же? Опять, с уязвимостями, Карл! И между всем этим фильтры, в надежде, что потенциальный злоумышленник задолбается и не полезет вглубь.
EL>и кстати не просто за сервисом, а за сервисом НА ДРУГОЙ МАШИНЕ! это важно
Да, это меня тоже в нашей индустрии восхищает. Попытки впихнуть невпихуемое. Окончательно продолбанная идея того, что разные сервисы могут изолированно работать внутри одной системы, не мешая друг другу. В результате, ставится на ОДНУ И ТУ ЖЕ ФИЗИЧЕСКУЮ МАШИНУ несколько виртуалок, а в них уже — разные сервисы. Кстати, как там у нас с уязвимостями в гипервизорах?
EL>Так стоит делать как минимум для того, чтобы админ конторы, в которой ты работаешь, не написал на тебя докладную начальству, после которой тебя выгонят на мороз.
Какое хорошее сочетание терминов наемных рабов (контора, докладная) и лексики наблатыканных дельцов (выгнать на мороз). Вообще-то админ сам ставит и настраивает сервисы. А если админ чего-то там надзирает и пишет поганые бумажки, то и зовется он не админом, а как-то иначе.
Что я хочу сказать — безопасность, конечно, дело хорошее. Только очень уж обширное. Чтобы его знать хорошо, нужно им постоянно заниматься. Мое простое и незамысловатое предложение просто использовать нормальные продукты, тот же постгрес, в котором уязвимостей просто меньше, потому что он написан нормально, было встречено с негативом. Есть такое понятие — синдром утенка, это когда человек с чего начал, то и любит. Один вот на мыскле пишет, другой на прости господи файрбёрде. При этом, поиск по cvedetails.com дает 82 уязвимости для постгреса и 243/270 для мыскля. Одни продукты МОГУТ быть объективно лучше других, по техническим параметрам, а не по количеству разработчиков, которые когда-то на нем phpnuke развернули и с тех пор его нежно любят (да, я знаю про MariaDB, сколько кривизну не форкай, прямее она не станет, там нужны многие человекогоды для переписывания этого).
Безопасность пытаются обеспечить, соблюдая ритуалы, сути которые уже не понимают. Вот, в этой теме чего только ни насоветовали: "Напиши сверху базы целый REST, а что — все так делают". Почему-то никто не предложил поднять openvpn от точки до точки, и поверх него уже связываться. Это, кстати, будет надежнее какого-то самодельного REST, где разработчик запросто может навтыкать sql-инъекций.
С>Нет, не кто угодно. Я уже описал возможность ограничения доступа по IP. И из дальнейшего описания будет ясно, почему это чуть ли не самая действенная мера защиты любых сервисов.
Эту меру защиты тоже можно обойти. Это не то, чтобы экзотика. Ты там дальше правильно написал: С>Почему-то никто не предложил поднять openvpn от точки до точки, и поверх него уже связываться.
Во первых, потому что предложили, правда не явно, но это имеется ввиду, когда говорят что БД должна быть доступна только из локальной сети. Это, КМК, куда надежнее и проще, чем всякие ограничения IP.
EL>>Они бывают и в веб серверах, но в нормальной системе, получив доступ к веб серверу (который живет в DMZ), ты мало что можешь сделать, С>Можно использовать цепочку уязвимостей. Сначала проломить веб-сервер или приложение, затем базу.
Да, но это сложнее. На практике, всякие интернет порталы, которые реально могут стать целью атаки, реализуют трехзвенку и веб приложение не работает с базой напрямую (даже с ограниченными правами), оно работает с другим приложением, которое уже работает с базой. Трафик, который идет на сервера в DMZ — мониторится и атака может быть обнаружена довольно быстро. КМК, такие серваки могут пытаться ломать даже не ради твоего сервиса и данных, а тупо чтобы через них спам рассылать либо DDoS атаки организовывать (потому что сервер доступен онлайн 24x7x365 и канал там хороший).
С>Уже упомянутый mysql как правило используется в таких очень широко распространенных проектах, как wordpress, opencart и прочее такое, уебное. Где хватает собственных уязвимостей. Где никто особо не заморачивается настройкой прав для учетной записи БД, под которой будет работать веб-приложение. Где просто люди, сроки и деньги малость не те, чтобы все это грамотно настроить.
А еще, совершенно любой человек, может пойти в магазин и купить молоток, а потом ударить им себя по руке. Нужно ведь рассказывать на форуме о том как делать хорошо, а не о том, как сделать плохо.
С>Где же тут шутка? 54.93.97.248 — ломай сколько угодно, доступ открыт только для определенных IP. Тебе даже не удастся понять, что за сервисы там работают. Никому стороннему не удастся понять.
Я не сварщик, в смысле не специалист по безопасности, но даже мне ясно, что можно, например, взломать рутер, через который твой сервис общается с внешним миром, после чего можно спуфить TCP соединение спокойно. И мне кажется, что такие вещи, для квалифицированных людей, мало того что не сложны ни разу, они наверняка еще и полностью автоматизированы и даже не дороги совсем.
EL>> запросы к БД делает сервер приложений, он может делать их более умным способом, например отрубая долгие запросы по таймауту, чтобы освободить пулл соединений к БД (это скорее в помощь к "во первых" чем как самостоятельное решение). В третьих, в некоторых СУБД есть фича для совсем ленивых, не помню как называется, позволяющая перед выполнением запроса построить план и оценить время выполнения и после этого отдуплить слишком тяжелые запросы.
С>Решения впечатляющие. Строился отчет полчаса, а потом ррр-раз — и отвалился по таймауту, говоря "чегой-то у вас отчет слишком большой".
Речь не про построение отчетов шла, если что, а скорее про веб, где тяжелых запросов к базе клиенты создавать не должны.
С>Беда в том, что писать на других языках в отрасли как-то не спешат. А фуле — и так все работает, главное, сделать потолще бутерброд из костылей — кривенькую СУБД, где еще недавно не рекомендовалось делать джойны, где сплошное страшненькое Си образца 1975 года с арифметикой указателей и неизбежными уязвимостями (в сетевой части уязвимости, Карл! в обработчике протокола! Шел 2015 год, до сих пор в индустрии нет ни одного генератора для сетевых протоколов! есть WSDL, и даже 2.0 есть, только каждый вася реализовал его по-своему). Сверху этого кривенький же вебсервер на той же самой сишечке с уязвимостями. А на нем сверху уеб-приложение на пхп — с чем же? Опять, с уязвимостями, Карл! И между всем этим фильтры, в надежде, что потенциальный злоумышленник задолбается и не полезет вглубь.
Здравствуйте, Слава, Вы писали:
С>Уже упомянутый mysql как правило используется в таких очень широко распространенных проектах, как wordpress, opencart и прочее такое, уебное. Где хватает собственных уязвимостей. Где никто особо не заморачивается настройкой прав для учетной записи БД, под которой будет работать веб-приложение. Где просто люди, сроки и деньги малость не те, чтобы все это грамотно настроить.
Скажу внезапную вешь, но в типовом случае — заморачиваются. На любом хостинге такой вордресс будет в среде, ограничивающей от других клиентов (jail и т.п.), права на доступ будут только к одной базе, с которой эта установка вордпресса и работает, mysql сервер — отдельная машина, пароли пользователей хешированы с уникальным для инталляции хешем, чтобы утащив только базу данных нельзя было получить пароли пользователей.
Здравствуйте, hrensgory, Вы писали:
H>On 23.12.2015 17:14, LWhisper wrote: >> *Задача:* >> Выгрузить часть данных из MS SQL в отдельный файлик и положить его на >> удалённый Linux\Windows хост с возможностью последующего обновления >> посредством SQL-запросов (Insert, Update, Delete). >> >> *Что подходит:* >> Заливка, установка и запуск на хосте службы/демона/процесса, который >> будет принимать входящие соединения и устанавливать персистентное >> соединение, принимая команды и отдавая данные из этой базы-файла. >> Достаточно одного соединения, параллелинг не обязателен (хотя и >> желателен). Наличие транзакций. Хорошая производительность. Клиент на >> Windows.
H>http://www.h2database.com/html/main.html
(и кстати не просто за сервисом, а за сервисом НА ДРУГОЙ МАШИНЕ! это важно)
