А что изменилось то с 19 века? Или со времен крестовых походов?
Методы те же, только завуалированы под моральное превосходство запада над всеми остальными. Если можно отжать ресурсы страны силой — отжимают силой — пример Ливия, Сирия. Не могут — прикрываются санкциями под выдуманными причинами. Спонсируют внутренние противоречия.
Китай защищается как может. Получить на своей территории гражданскую войну в которую будет втянуто почти 2 млрд. человек — так себе перспектива.
«Капитал… при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы...» (с) То́мас Джо́зеф Да́ннинг
Да-да, продолжайте, только не забудьте:
1. Ост-Индийскую компанию
2. Опиумные войны в Китае.
3. Раздел Индии и Пакистана
4. Куда делось коренное население северной Америки (на территории Канады ;-))
и т.д.
А так да, джентльмены геноцидом не занимаются, джентльмены бабло зашибают.
Видимо да. Вы почему то уперлись в утверждение, что join на шардинге это плохо. И приводите в качестве аргумента вырванные из контекста слайды (отсюда и предположение что не используете транзакции, все таки презентация про конктретный случай, а не про общее состояние дел).
Просто Вы не хотите посмотреть шире, и рассматриваете шардинг как размазывание одного объекта по кучи хостов из которого «магическим» образом вытаскиваются данные, и накладывание не который JOIN чревато проблемами.
Но если посмотреть на шардинг как на комплекс независмых хостов, в каждом из которых есть все необходимые данные для работы хоста — то проблема джойнов исчезает. Вы просто заранее решаете какой хост предпочтителен в данном конкретном случае, для доступа к конкретным данным.
Ох, мы опять про ежей и ужей. Вот эти вот «фантазии» почему то очень часто приходится разгребать, когда система «внезапно» перестает отвечать за вменяемое время.
http://www.myshared.ru/slide/9793/ (слайд 38)
Поглядел. И не понял почему они вообще решили при этом использовать реляционную БД. Выключить все что дает движок, и использовать СУБД как Key-Value хранилище к которому можно писать запросы на SQL, что выглядит мягко говоря странным, так как SQL это еще один дополнительный слой, который можно в такой системе выкинуть.
Давайте сразу определимся, есть хайлод в котором данные не важны, ну в некоторой степени не важны — потеряем мы комментарий пользователя, или данные сессии похерим, ничего страшного — пользователь перенаберет/перезайдет.
А есть хайлод в котором транзакции, ACID, нормализация и вот это вот все называемое реляционной моделью данных. А данные там критически важные — как самый яркий пример — финансовые транзакции. А теперь попробуйте объяснить заказчику системы, почему у вас данные не консистентны из-за того, что Вы не используете механизм транзакций. Или данные пропали, потому что не успели зафиксироваться на дисках. Или топовое серверное железо загибается, из-за того, что программер решил всю базу к клиенту гонять и обратно, вместо работы с данными в самой базе. И таких примеров много.
Я так понимаю Вы имеете ввиду, что у вас есть большая зашарденная табличка, а справочники лежат все на одном инстансе в одном месте, и вот потом Вы пытаетесь на клиенте сопоставить данные вытащенные с шардов с данными из справочников. И тут надо смотреть насколько эффективно Вы это делаете, может оказаться так, что дублирование справочников по шардам — может оказаться эффективнее централизованного хранения, а может и хуже.
Тут ведь проблема с JOIN на клиенте в объемах, которые вы пытаетесь обрабатывать. Грубо говоря, вы сделали запрос с фильтрацией (WHERE) в БД из основной таблицы, а потом начинаете в полном объеме (без WHERE) подтягивать справочники чтобы сделать ручной JOIN. И, ВДРУГ, в какой-то момент оказывается, что у справочники то большие, а в результате фильтрованного запроса часть данных справочника вообще не используется. И в итоге вы нагибаете базу заставляя её уходить в чтение с дисков на больших справочниках, нагибаете сеть — заставляя гонять кучу данных, нагибаете клиента — отъедая ОЗУ и проц на ручной JOIN.
А можно было сделать JOIN в БД и сразу отфильтровать только нужные данные.
В общем, складывается впечатление, что автор не смог разобраться с БД и почему там хреновый план выполнения запроса, и решил в лоб на клиенте сделать JOIN, потому что лень переписывать неэффективный SQL.
SQL инъекции как класс лечатся связыванием переменных.
Плюсом идет ускорение работы с БД.
https://www.google.ru/search?q=sql+bind+variable
Если уж про PHP, то:
http://php.net/manual/ru/mysqli.prepare.php
http://php.net/manual/ru/function.pg-prepare.php
http://php.net/manual/ru/function.oci-parse.php
и т.д. для остальных баз.
Словарик вполне официальный, в условиях была ссылка откуда он сформирован
https://github.com/hola/challenge_word_classifier/blob/master/blog/01-rules.md
For the purposes of this problem, we define an English word as a word from the list included here as words.txt. (If you're interested, it's the SCOWL “insane” dictionary with flattened diacritics.) Membership in the dictionary is case-insensitive. You have to write a program that can answer whether a given word is English.
http://wordlist.aspell.net/
В общем, там помимо академического английского еще и диалекты — американский, канадский, британский и т.д.
Варианта доступа к БД ровно два, в зависимости от того, что было скомпрометировано.
1. Если Ваш код, то есть есть уязвимость на заливку и изменение файлов — то, как тут уже в комментариях отмечали, модификация существующего скрипта (там где есть обращение к БД) позволяет тупо слить всю базу. И скрытие паролей уже не поможет.
2. Если хостинг, то есть грубо говоря рут — то два варианта событий:
2.1 База на этом же сервере — тут вообще пароли доступа к БД не нужны, ко всем БД можно получить рутовый доступ без пароля.
2.2 База на другом сервере — то по первому варианту, модификация существующего скрипта.
По вопросу защиты:
1. От шаред хостинга помогает переход на Dedicated или VPS хостинг. Там все в ваших руках.
2. По минимизации рисков взлома ПО вариантов много, по вашим вопросам:
2.1 например белые списки URL можно организовать через ModSecurity
2.2 по контролю целостности кода — периодическое сканирование каталога внешним скриптом с подсчетом контрольных сумм, или например можно для этого использовать GIT, он делает тоже самое, плюс можно после каждого скана сформировать отчет с изменениями.
2.3 По хешам паролей — использовать криптостойкие алгоритмы, для php это функция password_hash.
2.4 Максимально внимательно отнестись к коду отвечающему за заливку файлов на сервер, например самому генерировать названия файлов при их сохранении, а пользовательские названия, если нужны, хранить в БД.
Я говорю о логике корпораций, где деньги всего лишь инструмент достижения других целей (в конечном итоге конечно заработать еще больше денег, вот только не все так просто)
Бюджет и штат юристов — это постоянные затраты, повторюсь ПОСТОЯННЫЕ. То есть неважно сколько они реально наработали — деньги на них уже выделены и потрачены. И одним иском больше-одним меньше, на общих затратах это не существенно.
Это как на производстве — чем больше партия товара, тем меньше себестоимость.
Это если Вы как маленькая фирма или физлицо захотите посудиться — то да, для Вас лично разница между судебным и досудебным разбирательством будет в «десятки и сотни раз». Хотя Все не так катастрофично как кажется на первый взгляд, так как в случае удачного решения дела — все ваши затраты компенсируются ответчиком.
2) Для компании это всегда в десятки и сотни раз дешевле, чем начинать судебное разбирательство
Второй пункт критичен для компаний, которые считают свои деньги. Если на каждое нарушение направл
это для физического лица дешевле, потому что не надо тратититься на юристов.
А тут как вы правильно упомянули:
есть юристы
которые сидят на зарплате и должны что-то делать.
Так что расходы по большей части только на госпошлину и услуги натариуса, юристы все равно зарплату получат независимо от того работают они или нет. При этом, если работают — то может и премия случится =)
Можно проще.
Я создал шифрованный контейнер TrueCrypt, который монтирую как отдельный диск (такая виртуальная флешка). И все что нужно лежит в этом контейнере.
Сразу решается несколько проблем:
— Защита проекта стойким шифрованием (для параноиков)
— Меньше возни с путями для файлов, в некоторых случаях можно использовать Portable-версии софта
— Меньше глюков синхронизации.
В нормальных операторах финальный тендер только так и делается.
Выбор железа осуществляется ДО массовых закупок, по итогам предварительного тестирования под требования проекта. Тут очень много нюансов при выборе железки, чтобы играть в кота в мешке массово закупая самое дешевое предложение.
Мельком проглядел тендер, не увидел там никакого уникального ПО специально разрабатываемого для этого проекта.
Судя по спецификации (Приложение 2 к Документации Спецификация.pdf 2.0) — тендер на закупку конкретного железа, конкретных производителей (по большей части Huawei, есть немного IBM). Причем выбор конкретного оборудования указывает уже на наличии утвержденного проекта развития сети, то есть, опять же, никакой разработки не подразумевается.
По лицензиям ПО есть пункт 12 в «Приложение 1 к документации Договор.pdf 2.0» — там все довольно прозрачно, и стоимость лицензий включена в стоимость тендера. ПО кстати указано и в спецификации отдельными пунктами.
По 5му пункту, все в упаковке потому что от поставки оборудования до собсвенно его установки и ввода в эксплуатацию пройдет немало времени. Учитывая объем проекта, оборудование на складах может пролежать до полугода, после поставки.
PS. Сам работаю в сфере телекома (не Ростелеком =)) — это обычный тендер на закупку железа. А количество денег выделенных на него обусловлено размерами сети оператора.
Как показывает практика (а история у этой службы давняя), надежнее пока ничего не придумали.
PS. И да, MITM возможна, но в данном случае, опасна для атакующего. Хотя бы по той причине, что факт перехвата информации становится сразу известен, со всеми вытекающими.
Многие вещи устно сложно сказать. А документ «для двух-трех человек» реален, автор и адресат документа. Сотрудники СБ доступ к документу не получат.
На примере, часто вся информация и видение ситуации которую надо описать в документе есть у одного, максимум двух человек. Пусть это будет условно «аналитик» собирающий информацию от многих «оперативников» и делающий на основе него выводы. Далее «аналитик» пишет секретное письмо, запечатывает его в конверт и передает курьером (фельдегерской службой) адресату. Все, никто этот документ больше видеть не должен и не увидет. А «оперативники» обладающие частью знания, не соберут общего, того что увидел «аналитик».
Методы те же, только завуалированы под моральное превосходство запада над всеми остальными. Если можно отжать ресурсы страны силой — отжимают силой — пример Ливия, Сирия. Не могут — прикрываются санкциями под выдуманными причинами. Спонсируют внутренние противоречия.
Китай защищается как может. Получить на своей территории гражданскую войну в которую будет втянуто почти 2 млрд. человек — так себе перспектива.
«Капитал… при 300 процентах нет такого преступления, на которое он не рискнул бы, хотя бы под страхом виселицы...» (с) То́мас Джо́зеф Да́ннинг
Так что это вы «передергиваете» на запад.
1. Ост-Индийскую компанию
2. Опиумные войны в Китае.
3. Раздел Индии и Пакистана
4. Куда делось коренное население северной Америки (на территории Канады ;-))
и т.д.
А так да, джентльмены геноцидом не занимаются, джентльмены бабло зашибают.
Просто Вы не хотите посмотреть шире, и рассматриваете шардинг как размазывание одного объекта по кучи хостов из которого «магическим» образом вытаскиваются данные, и накладывание не который JOIN чревато проблемами.
Но если посмотреть на шардинг как на комплекс независмых хостов, в каждом из которых есть все необходимые данные для работы хоста — то проблема джойнов исчезает. Вы просто заранее решаете какой хост предпочтителен в данном конкретном случае, для доступа к конкретным данным.
Поглядел. И не понял почему они вообще решили при этом использовать реляционную БД. Выключить все что дает движок, и использовать СУБД как Key-Value хранилище к которому можно писать запросы на SQL, что выглядит мягко говоря странным, так как SQL это еще один дополнительный слой, который можно в такой системе выкинуть.
Давайте сразу определимся, есть хайлод в котором данные не важны, ну в некоторой степени не важны — потеряем мы комментарий пользователя, или данные сессии похерим, ничего страшного — пользователь перенаберет/перезайдет.
А есть хайлод в котором транзакции, ACID, нормализация и вот это вот все называемое реляционной моделью данных. А данные там критически важные — как самый яркий пример — финансовые транзакции. А теперь попробуйте объяснить заказчику системы, почему у вас данные не консистентны из-за того, что Вы не используете механизм транзакций. Или данные пропали, потому что не успели зафиксироваться на дисках. Или топовое серверное железо загибается, из-за того, что программер решил всю базу к клиенту гонять и обратно, вместо работы с данными в самой базе. И таких примеров много.
Я так понимаю Вы имеете ввиду, что у вас есть большая зашарденная табличка, а справочники лежат все на одном инстансе в одном месте, и вот потом Вы пытаетесь на клиенте сопоставить данные вытащенные с шардов с данными из справочников. И тут надо смотреть насколько эффективно Вы это делаете, может оказаться так, что дублирование справочников по шардам — может оказаться эффективнее централизованного хранения, а может и хуже.
Тут ведь проблема с JOIN на клиенте в объемах, которые вы пытаетесь обрабатывать. Грубо говоря, вы сделали запрос с фильтрацией (WHERE) в БД из основной таблицы, а потом начинаете в полном объеме (без WHERE) подтягивать справочники чтобы сделать ручной JOIN. И, ВДРУГ, в какой-то момент оказывается, что у справочники то большие, а в результате фильтрованного запроса часть данных справочника вообще не используется. И в итоге вы нагибаете базу заставляя её уходить в чтение с дисков на больших справочниках, нагибаете сеть — заставляя гонять кучу данных, нагибаете клиента — отъедая ОЗУ и проц на ручной JOIN.
А можно было сделать JOIN в БД и сразу отфильтровать только нужные данные.
В общем, складывается впечатление, что автор не смог разобраться с БД и почему там хреновый план выполнения запроса, и решил в лоб на клиенте сделать JOIN, потому что лень переписывать неэффективный SQL.
Судя по "… редологов..", имеется ввиду Оракл, это его термин для бинарных логов.
А так да, join вне базы, это антипаттерн сравнимый с характеру с вашим примером «Проблема «n+1»»
Такая бомба замедленного действия.
Плюсом идет ускорение работы с БД.
https://www.google.ru/search?q=sql+bind+variable
Если уж про PHP, то:
http://php.net/manual/ru/mysqli.prepare.php
http://php.net/manual/ru/function.pg-prepare.php
http://php.net/manual/ru/function.oci-parse.php
и т.д. для остальных баз.
abuse — https://github.com/hola/challenge_word_classifier/tree/master/submissions/5720eba193f2f29d3c9acbad
optimist — https://github.com/hola/challenge_word_classifier/tree/master/submissions/5720ebb893f2f29d3c9acbae
pessimist — https://github.com/hola/challenge_word_classifier/tree/master/submissions/5720ebd293f2f29d3c9acbaf
pofigist — https://github.com/hola/challenge_word_classifier/tree/master/submissions/5720ed5393f2f29d3c9acbb0
https://github.com/hola/challenge_word_classifier/blob/master/blog/01-rules.md
http://wordlist.aspell.net/
В общем, там помимо академического английского еще и диалекты — американский, канадский, британский и т.д.
Варианта доступа к БД ровно два, в зависимости от того, что было скомпрометировано.
1. Если Ваш код, то есть есть уязвимость на заливку и изменение файлов — то, как тут уже в комментариях отмечали, модификация существующего скрипта (там где есть обращение к БД) позволяет тупо слить всю базу. И скрытие паролей уже не поможет.
2. Если хостинг, то есть грубо говоря рут — то два варианта событий:
2.1 База на этом же сервере — тут вообще пароли доступа к БД не нужны, ко всем БД можно получить рутовый доступ без пароля.
2.2 База на другом сервере — то по первому варианту, модификация существующего скрипта.
По вопросу защиты:
1. От шаред хостинга помогает переход на Dedicated или VPS хостинг. Там все в ваших руках.
2. По минимизации рисков взлома ПО вариантов много, по вашим вопросам:
2.1 например белые списки URL можно организовать через ModSecurity
2.2 по контролю целостности кода — периодическое сканирование каталога внешним скриптом с подсчетом контрольных сумм, или например можно для этого использовать GIT, он делает тоже самое, плюс можно после каждого скана сформировать отчет с изменениями.
2.3 По хешам паролей — использовать криптостойкие алгоритмы, для php это функция password_hash.
2.4 Максимально внимательно отнестись к коду отвечающему за заливку файлов на сервер, например самому генерировать названия файлов при их сохранении, а пользовательские названия, если нужны, хранить в БД.
3. Внимательно изучить рекомендации OWASP www.owasp.org, для начала список Top-10. А потом можно пройтись по OWASP Cheat Sheet Series
Бюджет и штат юристов — это постоянные затраты, повторюсь ПОСТОЯННЫЕ. То есть неважно сколько они реально наработали — деньги на них уже выделены и потрачены. И одним иском больше-одним меньше, на общих затратах это не существенно.
Это как на производстве — чем больше партия товара, тем меньше себестоимость.
Это если Вы как маленькая фирма или физлицо захотите посудиться — то да, для Вас лично разница между судебным и досудебным разбирательством будет в «десятки и сотни раз». Хотя Все не так катастрофично как кажется на первый взгляд, так как в случае удачного решения дела — все ваши затраты компенсируются ответчиком.
это для физического лица дешевле, потому что не надо тратититься на юристов.
А тут как вы правильно упомянули:
которые сидят на зарплате и должны что-то делать.
Так что расходы по большей части только на госпошлину и услуги натариуса, юристы все равно зарплату получат независимо от того работают они или нет. При этом, если работают — то может и премия случится =)
Для любителей Вавилона-5 может быть интересен Crusade («Крестовый поход») — закрыли в середине первого сезона.
А еще была «Андромеда» с Кевином Сорбо, этакий Геракл в космосе =)
Ну и не увидел тут «Сверхестественное», хотя это и не НФ.
Я создал шифрованный контейнер TrueCrypt, который монтирую как отдельный диск (такая виртуальная флешка). И все что нужно лежит в этом контейнере.
Сразу решается несколько проблем:
— Защита проекта стойким шифрованием (для параноиков)
— Меньше возни с путями для файлов, в некоторых случаях можно использовать Portable-версии софта
— Меньше глюков синхронизации.
Выбор железа осуществляется ДО массовых закупок, по итогам предварительного тестирования под требования проекта. Тут очень много нюансов при выборе железки, чтобы играть в кота в мешке массово закупая самое дешевое предложение.
Судя по спецификации (Приложение 2 к Документации Спецификация.pdf 2.0) — тендер на закупку конкретного железа, конкретных производителей (по большей части Huawei, есть немного IBM). Причем выбор конкретного оборудования указывает уже на наличии утвержденного проекта развития сети, то есть, опять же, никакой разработки не подразумевается.
По лицензиям ПО есть пункт 12 в «Приложение 1 к документации Договор.pdf 2.0» — там все довольно прозрачно, и стоимость лицензий включена в стоимость тендера. ПО кстати указано и в спецификации отдельными пунктами.
По 5му пункту, все в упаковке потому что от поставки оборудования до собсвенно его установки и ввода в эксплуатацию пройдет немало времени. Учитывая объем проекта, оборудование на складах может пролежать до полугода, после поставки.
PS. Сам работаю в сфере телекома (не Ростелеком =)) — это обычный тендер на закупку железа. А количество денег выделенных на него обусловлено размерами сети оператора.
Ниже уже давали ссылку на интервью с руководителем этой службы, но продублирую http://www.mk.ru/politics/russia/interview/2011/07/21/607719-pochtalonyi-prezidenta-otkazyivayutsya-ot-migalok.html
Википедия
Как показывает практика (а история у этой службы давняя), надежнее пока ничего не придумали.
PS. И да, MITM возможна, но в данном случае, опасна для атакующего. Хотя бы по той причине, что факт перехвата информации становится сразу известен, со всеми вытекающими.
никак
и от вас, и для вас. Политика очень сложное дело, информация в ней решает все. Мир не идеален, секреты были, есть и будут.
Это нас уводит в сторону от предмета разговора. Но, лично я, не ставлю эти события в один ряд.
Каждый волен иметь свое мнение ;)
На примере, часто вся информация и видение ситуации которую надо описать в документе есть у одного, максимум двух человек. Пусть это будет условно «аналитик» собирающий информацию от многих «оперативников» и делающий на основе него выводы. Далее «аналитик» пишет секретное письмо, запечатывает его в конверт и передает курьером (фельдегерской службой) адресату. Все, никто этот документ больше видеть не должен и не увидет. А «оперативники» обладающие частью знания, не соберут общего, того что увидел «аналитик».