База данных нашего конкурента EasyFinance скомпрометирована

Не буду повторяться, т.к. тут всё написано (кликните сюда, если исходная ссылка не открывается). Без тени злорадства сочувствую конкурентам. А вот тут я писал про кражу информации у работодателя.

А вот если вы собираетесь сами делать серьёзный сервис, работающий с пользовательскими данными, не забудьте, что:

  • Наёмным работникам надо платить зарплату независимо от того, зарабатываете ли вы достаточно денег или нет.
  • Инвесторские деньги кончаются в 2 раза быстрее, чем вы планируете.
  • Доступ к личным данным должен быть сложнее доступа к данным самой системы. Решается это рядом мер:
    • Доступ к production базе есть только у приложения и администратора
    • Test база, используемая для разработки и тестирования, содержит либо полностью фиктивные данные, либо малую выборку старых данных из production.
    • Программисты (кроме тех, кто работает с базой) к базе доступа иметь не должны. Тем более, что всякие ORM неплохо скрывают физическую базу.
    • Права доступа надо подвергать аудиту ежемесячно

Как я понял из хабровских комментариев, уже понятно, кто это сделал (бывший сотрудник), когда он это сделал (примерно 27 января 2011 года) и наказание может быть не за горами. Понятно, что пользователям от этого не легче. Лично мне жаль, что этот инцидент ударит не только по EasyFinance (где 34к учётных записей), но и по аналогичным сервисам типа Дребеденег с 50к учётных записей или нашим “4 Конвертам с 65к учётных записей.

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

А вот если вы собираетесь сами делать серьёзный сервис, работающий с пользовательскими данными, не забудьте, что:

  • Наёмным работникам надо платить зарплату независимо от того, зарабатываете ли вы достаточно денег или нет.
  • Инвесторские деньги кончаются в 2 раза быстрее, чем вы планируете.
  • Доступ к личным данным должен быть сложнее доступа к данным самой системы. Решается это рядом мер:
    • Доступ к production базе есть только у приложения и администратора
    • Test база, используемая для разработки и тестирования, содержит либо полностью фиктивные данные, либо малую выборку старых данных из production.
    • Программисты (кроме тех, кто работает с базой) к базе доступа иметь не должны. Тем более, что всякие ORM неплохо скрывают физическую базу.
    • Права доступа надо подвергать аудиту ежемесячно

Как я понял из хабровских комментариев, уже понятно, кто это сделал, и наказание может быть не за горами. Понятно, что пользователям от этого не легче. Лично мне жаль, что этот инцидент ударит не только по EasyFinance (где 34к учётных записей), но и по аналогичным сервисам, включая наши “4 Конверта“, где зарегистрированных пользователей в 2 раза больше, или по Дребеденьгам, где 50к учётных записей.

Подписаться по Email

30 Responses to “База данных нашего конкурента EasyFinance скомпрометирована”

  1. Поэтому стараюсь предоставлять интимные данные только “выдержанным” сервисам.
    Хотя, как показала практика, кого только уже не вскрывали.

  2. Это не “вскрытие”, это атака изнутри. От неё даже техническими мерами уберечься сложно.

  3. Макс, линк в первом предложении не работает.

  4. только что поправил

  5. Он его считает относительным, потому не работает. Но даже если сделать его правильно – работать не будет, т.к.:
    “Вы пытаетесь открыть публикацию, написанную пользователем mubinov.

    Автор переместил топик в черновики.”

  6. отлично работает и показывается.

  7. в ЖЖ текст сообщения два раза отображается.

  8. Если честно, то это ппц.

    Я не знаю, что со мной надо сделать, чтобы я таким образом навредил работодателю.

    Это в крайней мере непрофессионально.

  9. Макс – Вы действительно считаете что “Решается это рядом мер” выполнимо?

    Пример:
    Запрос на фикс от заказчика. Issue, естественно, воспроизводится только на базе заказчика => разработчику (а порой и у тестировщику фикса) есть доступ к продакшн базе.

  10. Слишком абстрактный вопрос. Не всегда требуется доступ к полной базе заказчика. Также можно выполнять работу под наблюдением или с логированием всего, что только возможно. Увести базу и исходники – это не пару чисел запомнить.

  11. Я пошел самым простым для меня путем… написал свой софт для управления финансами.

  12. Я сделал почти то же самое 🙂

  13. Да, такие истории вновь заставляют задуматься о безопасности хранения чувствительных данных “у дяди”.

    Это конечно привлекательно – переложить заботу о технической стороне дела вовне. Но имеет свои риски.

    К сожалению, хороший сервис 4konverta работает всё так же медленно как и пол года назад, что опять же побуждает перенести всю кухню к себе.

  14. Кстати, Максим, а вы не планируете сделать какое-то standalone приложение 4 конверта? Купил бы.

  15. Нет, мне неинтересны standalone приложения. Наигрался уже.

  16. Это своеобразная реклама или просто злорадство? 🙂
    Довольно рискованно размещать у себя ссылки на конкурентов (а опосредованно – даже на тематические списки конкурентов), будто подталкивая пользователей проверить – “а как там дела у других?” 🙂
    Особенно учитывая нынешние темпы развития сервиса, пыльный внутренний блог и полузаброшенный форум.

  17. Нет, меня такой риск не пугает. Скорость развития сервиса – не главный показатель его эффективности и надёжности.

  18. Срок регистрации домена http://www.habrahabr.ru истёк

    Так и не узнаем что там было =)

    Но я кстати считаю что в таких сервисах надо регистрироваться на аналог qweqwe@mailinator.com, тогда никакие утечки не страшны. Об этом вроде и на сайте 4 конвертов прямым текстом написано. В любом случае, при работе с SaaS (особенно бесплатным) надо учитывать что оно может в любой момент внезапно сдохнуть.

  19. Узнаем. Они исправятся.

  20. Ссылка не открывется. В кратце понятно о чёи речь, но нельзя ли выложить подробности?

  21. Вот кэш

  22. Я сомневаюсь в возможности скрыть продакшн базу от внутренних разработчиков. Если, человек намеренно хочет получить доступ, то есть тысяча способов сделать это из нутри компании, имея доступ к одному из серверов того же дата центра.
    Особенно это тяжело тем компаниям, которые страдают от нехватки финансов, нанимать сикьюрити группу им не по карману.

  23. Кстати, нашел в базе “maxim.kraynov+easyfinance@” 🙂 Это была разведка конкурентов? Какие дальнейшие действия?

  24. Это был я и действительно ради разведки. Дальнейших действий нет, т.к. я не дурак к ним свои данные вводить. Тем более, что метод детального учёта занимателен, но бесполезен.

  25. Согасен, скорость развития сервиса не главный показатель, но вот скорость фидбека и устранения проблем – важна.
    Иначе (особенно при отсутствии нововведений) возникает ощущение, что сервисом никто не занимается, и закономерен вопрос – к чему бы это?

  26. Пока ни к чему. Сейчас работаем над возможностью привлечения дополнительных ресурсов на поддержание (скорость) и развитие (новые функции)

  27. Я как всегда встану в опозицию. Я конечно не одобряю поступка того человека, но владельцы имхо доигрались и виноваты в первую очередь они. Даже если поверить в то, что команда разработчиков сменилась 3 раза за год, то это говорит только о том, что руководители там самые что ни наесть матерые прохиндеи и у проекта нет будущего, все как по Демингу. Т.е. чтобы доверить чувствительные данные какому либо сервису, нужно в первую очередь понять кто у него хозяин. У хорошего хозяина такого не случится.

  28. Если к краже дошло, то это как минимум значит, что процесс девелопмента и процесс управления людми не отлажен.
    Для того чтобы отладить процесс требуется время и люди разбирающиеся в вопросе, которым надо платить.
    Иногда не мало.
    Если все делать “правильно”, то возникают значительные накладные расходы. И кому это интересно?
    И откуда тогда взять маслецо на хлебушек.

    Все проблемы от жадности.

  29. На мой взгляд тут наложились несколько проблем, связанные с:
    1. Финансами (не платили зарплату)
    2. Менеджментом (отсутствие адекватной мотивации, невнимательное отношение к сотрудникам, не подкрепленные обещания)
    3. Технической реализацией ЗИ (доступ к личным данным жестко не контролировался)
    Для максимальной безопасности все должно быть на уровне. Судя по прочитанному – у данного сервиса проблемы были по всем пунктам. Сотрудников явно очень и очень разозлили, а иначе бы в письме не были указаны определенные фамилии.

    Абсолютно согласен, что раз был осуществлен найм работников, перед ними должны соблюдаться финансовые обязательства. Эту ответственность основатели должны понимать на 100%

  30. То бишь классическая проблема менежмента. 🙂
    Это не оправдывает неадекватного поведения работника(ов), но менежмент своими действием или бездействием довел ситуацию до критической.