ProjectProfy.ru
Имя: Пароль:
Забыли пароль?

Статьи

Методика управления проектами [86]

Методические пособия и книги [25]

Готовые отраслевые решения [60]

Обзоры программ для управления проектами [62]

События в мире Управлениия Проектами [126]

Сравнение разных программ для управления проектами [26]

Обучение и сертификация [50]

Управление рисками [4]

Опыт внедрения [36]

Разрешение проблем MS Project и др. системах [4]

Скачать Microsoft Project [3]

Администрирование MS Project Server [36]

Разработка для Microsoft Project [5]



28.02.2013

Хакеры взломали облако Мегаплан? Уничтожены данные 125 компаний и местонахождение резервных копий данных остальных клиентов неизвестно

  

Почему то вспомнилось как на конференции Clouds 2012 Михаил Смолянинов рассказывал нам взахлеб со сцены что ИТ директора не нужны ибо Мегаплан гораздо надежнее чем внутренние ИТ системы. В качестве аргумента проводилась исключительно высокая квалификация сотрудников Мегаплан.

Андрей Бешков (Security Program Manager в корпорации Microsoft) о взломе Мегаплан

Владимир Иванов

В декабре 2012 года вокруг известного облака по управлению поручениями в микропроектах Мегаплан (один из клонов Basecamp) разразился грандиозный скандал. Были утрачены данные 125 компаний, дальнейшее бурное обсуждение инцидента на Facebook показало, что сотрудники Мегаплана также не знают местонахождение  резервных копий данных остальных клиентов на текущий момент. Эксперты  комментирующие тему указали, что указанный инцидент мог произойти только либо в результате конфликта с руководства Мегаплана со своим персоналом, т.е. это просто месть администраторов покинувших компанию. Либо сервис был взломан, данные всех клиентов похищены под заказ, а повреждение баз было сделано как доказательство взлома перед заказчиками. Обе версии плохие для вендора, но вторая хуже и она подтверждается тем, что сотрудники одного из крупнейших Интернет холдингов в России продемонстрировали как методом "фишинга" они смогли пробить все межсетевые экраны Мегаплана и активировать свой код (эксплоит) на всех серверах вендора. Такая слабая защищенность сервиса и очевидно низкая квалификация персонала Мегаплана не обеспечивающая надежность данных клиентов и совершенно не инструктированные об атаках класса "фишинга" просто взорвало Facebook. Я отложил обсуждение этого инцидента до общей рассылке по облачной теме, чтобы показать, что инцидент Мегаплана не случайность, а как раз одно из проявлений системной ненадежности облаков первого поколения. Мне также удалось получить комментарии от руководства Мегаплана и результаты опроса его пользователей, которые многое проясняют. Давайте разберем инцидент и сделаем выводы.

Все началось с того, что шокированные пользователи Мегаплана стали публиковать на Facebook письмо Мегаплана в котором вендор извинялся за потерю их данных и обвинял поставщика баз данных PostgreSQL в дефектах его программного обеспечения, что якобы и привело к инциденту. Сам Мегаплан в этот момент двое суток не работал, но как язвительно замечали некоторые комментаторы это "обычное дело" для этого облака, поэтому сначала мало кто верил в подлинность таких сообщений и offline от Мегаплана  воспринимали как обычное явление для недорогих сервисов, пока не явился сотрудник Мегаплана Eugene Zinin и лично не подтвердил факт инцидента. В дальнейшем ситуация накалилась из-за того, что эксперты PostgreeSQL посчитали, что некомпетентный персонал Мегаплана на них переводит репутационные издержки и обрушились с критикой на их действия. Через некоторое время к обсуждению подключились эксперты в безопасности от Microsoft и скандал стал совсем ярким. И так, что было, вот начальное сообщение пользователей Мегаплана о том, что они теперь лишились своих данных.

Добрый день!

Меня зовут Полетаев Алексей, я руководитель технической поддержки компании Мегаплан.

Вечером 23 ноября на одном из серверов нашей компании случилось чрезвычайное происшествие. Из-за серьезной ошибки в серверном программном обеспечении (СУБД PostgreSQL) были испорчены базы данных. Доступ к 125 аккаунтам был ограничен.

Масштабы проблемы оказались достаточно большими. Пострадали не только текущие, но и резервные базы. Нам пришлось восстанавливать данные низкоуровневым способом, что потребовало много времени. Удалось восстановить большую часть пострадавших аккаунтов.

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

Наша компания приносит вам свои глубокие извинения. Мы знаем, что вопрос доступа к данным – один из самых важных, когда дело касается информационных систем. Риск серьезных ошибок существует, независимо от того, где хранятся данные. Риск очень малый. Но иногда он оборачивается реальной проблемой.

Мы все опечалены этой ситуацией и уже сделали все возможное, чтобы избежать подобных проблем в будущем. Надеемся на ваше понимание и благодарим за терпение.

Если у вас есть вопросы, пожалуйста, пишите мне.

27 ноября 2012 года необратимо изменило репутацию Мегаплана, разрушенные базы данных и взлом сервиса шокировал пользователей

Как я уже отмечал, попытка персонала Мегаплана "перевести стрелки" на вендора PostreSQL закончились тем, что к обсуждению подключился один из ведущих экспертов в этом SQL-сервере Олег Бартунов, который ведет раздел по этому серверу на SQL.RU. Его мнение было таково: "Я работаю с постгресом больше десяти лет и никогда не сталкивался с порчей данных и невозможностью восстановления. Разве что у ваших админов кривые ручки, но это требует расследования!". Таким образом, эксперты в PostgreeSQL указали, что сообщение о причине инцидента со стороны Мегапалана не соответствует действительности и реальная причина скрывается. Ведущий эксперт по безопасности Microsoft Russia Андрей Бешков оставил комментарий, который приведен как эпиграф в статье, который также выражал общее мнение Сообщества, что Мегаплан потратил свой бюджет на рекламу в ущерб расходам на опытный персонал. Мне удалось получить комментарии Мегаплана по этому вопросу, новая версия вендора что имелся сбой сервисов Amazon, которыми он пользуется в некоторых случаях. Однако Amazon не объявлял в этот момент наличие сбоев, что обязательно, т.к. Amazon в случае отключения своих облачных сервисов сразу же выплачивает финансовые компенсации по своему SLA-соглашению.

Далее масло в огонь подлило еще то, что сотрудники Мегаплана не могли ответить на простой вопрос экспертов, почему просто не восстановиться из резервных копий в такой аварии? Сам Мегаплан заявляет, что использует раздельные базы данных для своих клиентов, поэтому никаких технологических проблем для практически мгновенного восстановления работоспособности из резервных копий нет, если эти копии не пропали. Отсутствие внятных объяснений привело к экспертов выводу, что причина в том, что Мегаплан утратил все резервные копии своих данных как на "боевом" сервере, так и на тестовом, так и на сервер разработчиков. Отрицать, что это так сотрудники Мегаплана не стали и даже какой-то своей версии о местонахождении резервных копий не привели. В комментариях Мегаплана, что я получил также не проясняется вопрос куда пропали резервные копии, т.к. только их пропажа могла быть препятствием для быстрого восстановления из них.  Такие действия не могут быть ни при каких обстоятельствах последствиями аварии. Бекапы так мог уничтожить только человек получивший административные права. Поэтому вопрос сузился между "месть админов руководству" до "взлом", правда есть еще третий вариант на который я укажу в конце статьи.

Сначала большинство экспертов склонялось к тому, что руководство Мегаплана просто утратило контроль над своим персоналом и инцидент следствие конфликтов с ним, т.к. администраторы Мегаплана сами разрушили сервис сводя счеты с работодателем. Однако через некоторое время к дискуссии подключились сотрудники одного из ведущих Интернет холдингов в России. Они решили поставить эксперимент можно ли взломать Мегаплан популярным методом "Фишинг трояном", которым был взломаны недавно LinkedIn, Twitter и даже Facebook. В течении суток сотрудники Мегаплана клюнули на удочку "рыбака-хакера" и сами запустили с административными правами эксплоит на своих серверах, повторив психологическую ошибку сотрудников LinkedIn и Twitter.

Эксплоит был не зловредный по утверждению создателей и просто возвращал названия внутренних серверов. Опубликованы были следующие имена внутренних серверов Мегаплана: prod.megatest.local, svavilov.megaplan, megaplan.promo, promo.hotfix. Сотрудники Мегаплана не стали отрицать, что это подлинные имена их внутренних серверов. Но получить такую информацию можно только пробив все защитные межсетевые экраны Мегаплана .Отмечу, что на текущий момент это обсуждение на Facebook удалено, т.к. по словам авторов теста им якобы стали писать угрозы менеджеры Мегаплана  через личные сообщения Facebook. В принципе действительно такое "тестирование" с проникновением в чужую инфраструктуру нельзя признать юридически абсолютно чистым, даже если не наносится вендору ущерб. По полученным комментариям из Мегаплана я смог убедится, что внешнее проникновении во внутренюю сеть вендора действительно имело место быть. Однако вендор не считает это опасным, т.к. просто преодоление firewall и прямая видимость внутреннего сервера еще не означает его взлом. Однако я думаю, эксперты в security согласятся, что "голый" сервер у которого не закрыты межсетевым экраном порты очень уязвим к атакам.

Отметим, что в отзывах на эту статью пользователи Мегаплана также указали, что это далеко не первый случай утечки данных у вендора из-за халатности его персонала. Как пишут пользователи, вендор ранее по ошибке рассылал всем подряд e-mail с приватными финансовыми данными своих клиентов из их CRM систем. Также пользователи отмечают, что сотрудники Мегаплана при расторжении договора с сервисом сообщает заведомо недостоверную информацию об удалении данных бывших клиентов, в реальности вендор сохраняет и использует эти данные как минимум в своих спам рассылках, чем безусловно вызывает резкую критику своих экс-пользователей в крупных публичных группах на Facebook. По указанным обвинениям в адрес вендора я решил провести специальное расследование и вынужден констатировать, что десятки пользователей подтвердили, что нарушены правила работы с их конфиденциальными данными указанным образом. В ближайшее время я планирую опубликовать исследования такого толка по целому ряду вендоров, чтобы проверить не является ли это системной проблемой в какой-то нише облачного рынка.

Конечно достаточно вольготные манипуляции вендора с конфиденциальными данными своих пользователей, а также очевидные проблемы организации безопасности их обработки не дадут возможности получить любой сертификат на безопасное хранение и обработку данных пользователей как Safe Harbor, SAS 70 или ISO 27001. Впрочем вендор на текущий момент не имеет никакой признаваемой сертификации на безопасную обработку и хранение данных своих пользователей. Это означает, что сервис не имеет никакой внешней защиты от взлома из-за ошибки собственных программистов путем поставленных внешними аудиторами процессов обеспечения безопасности.

Часть экспертов комментировала инцидент в духе, что утечка данных даже если имела место быть, то не играет особой роли, т.к. она не первая поскольку Мегаплан  подключен к  системе on-line прослушивания СОРМ-2, т.к. используемые центры обработки данных вендора в Москве и Санкт-Петербурге согласно законодательству РФ поставлены на прослушивание ФСБ с последующей передачей данных заинтересованным чиновникам.  Поэтому в "секретность" данных которых "пылесосит" СОРМ-2 в реальном времени вопрос не более чем условный. Огромное количество чиновников в России могут в реальном времени просматривать данные Мегаплана от налоговиков, до МВД и антимонопольщиков. Количество таких "пользователей" так велико, что в общем-то желающему получить данные не требуется заказывать взлом, а достаточно просто "договорится" с одним из госслужащих. 

Однако несмотря на сбор такого количества "компромата" на Мегаплан я думаю, что скорее всего взлома вендора не было, хотя многие специалисты думают иначе. Как я уже отметил, в этой статье я  не публикую данные опроса пользователей Мегаплана, т.к. хочу их обработать и сравнить с другими вендорами. Однако уже могу сообщить с доказательствами в руках, что сотни пользователей заявили о наличии критических дефектов в программном обеспечении вендора и не только неспособности технической поддержки их своевременно устранить, а даже фактическом прекращении реагирования на заявки о проблемах. Хотя вендор имеет во много раз меньшую долю чем Microsoft, но как не сложно убедиться по нашим Форумам даже к совершенно не блистающему надежностью MS Project Server, имеющему плохие отзывы экспертов на надежность этого серверного продукта Microsoft, тем не менее нет замечаний в стиле протеста сотен человек.  В указанных обстоятельствах наиболее вероятная версия, что просто очередная программная ошибка совершенная программистами Мегаплана в совокупности с дезорганизацией технической поддержки привела к указанному инциденту.

Какие выводы стоит сделать

1) Если вы пользователь Мегаплана хорошая идея поговорить со своей Службой Безопасности и оценить риски размещения данных. Вне зависимости имел ли место взлом или просто ошибка, важно, то что вендор не смог пройти ни одну сертификацию по безопасности такую как  Safe Harbor, SAS 70 или ISO 27001, что требует от специалистов по безопасности крайне настороженно подойти к размещению данных в таких условиях.

2) Маленькие облачные игроки такие как Мегаплан не в состоянии создать высоконадежный и достаточно защищенный облачный сервис как это может сделать Microsoft или Google. Все заявления маленьких игроков нельзя воспринимать серьезно в данном плане, о чем и говорит Андрей Бешков из Microsoft. Моя точка зрения, что определенно это так, пока вендор не навел порядок в управлении своими программистами и специалистами технической поддержки согласно требованию указанных выше международных стандартов подразумевающих соблюдение деловых обычаев к разумной осмотрительности ведения бизнеса такого класса.

3) На этом инциденте хорошо проявился недостаток первого поколения облаков. Если бы Мегаплан был гибридным облаком с типичными приемами шифрования или изоляции части данных от облака, то вопрос о взломе не стоял бы вообще. Даже если бы взлом имел место быть, то хакеры бы ушли не с чем даже получив пароли администраторов. Достаточно очевидно, что технология пригодная для сайтов имеет существенные недостатки относительно современных требований к бизнес-системам по безопасности и надежности.

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

Расскажите о статье в Facebook и Twitter. Если статья понравилась, поставьте нам "плюс" Google.

Вы не вошли под своим пользователем на ProjectProfy.ru.
Рекомендуется нажать "Закрыть" и зарегистрироваться на сайте.
Зарегистрированные пользователи, выступающие как редакторы,
имеют различные бонусы по доступу к закрытым материалам.
Если Вам не важны бонусы, можете отправить правку прямо сейчас.

Фрагмент, требующий улучшения
Ваша версия фрагмента. Отредактируйте текст
Степень серьезности проблемы
Проблемы содержания
Стилистические проблемы
Синтаксические и орфографические проблемы
Ваш комментарий:

Если вы заметили любую ошибку в статье, вы можете сообщить об этой ошибке редакторам сайта, выделив мышью отрывок текста с ошибкой и нажав Ctrl+Enter. Ваша помощь в улучшении материалов для нас неоценима!

© 2003-2011, Портал ProjectProfy.ru. Все права защищены.

E-mail: обратная связь