В «Яндексе» рассказали об утечке данных 5 тысяч почтовых ящиков по вине сисадмина с высоким уровнем доступа Статьи редакции

Владельцам ящиков направили уведомление о смене пароля.

Во время внутреннего расследования «Яндекс» обнаружил, что сотрудник компании предоставлял несанкционированный доступ в почтовые ящики пользователей.

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

В результате действий сисадмина было скомпрометировано 4887 почтовых ящиков. Неавторизованный доступ в них уже заблокирован, а сотрудника уволят из компании, рассказали vc.ru в «Яндексе».

Компания планирует пересмотреть процессы работы сотрудников, обладающих административными правами такого уровня доступа. «Яндекс» также обратилась в правоохранительные органы, детали обращения в компании не раскрывают.

0
196 комментариев
Написать комментарий...
Matvey Kukuy

Тут есть прикольная деталь: "Компания планирует пересмотреть процессы работы сотрудников, обладающих административными правами такого уровня доступа".

Люди ошибаются всегда и задача компании — создать условия, когда ошибка не приводит к последствиям. Яндекс показывает очень хороший и адекватный пример, когда не только поругали сотрудника, но и починили у себя. Можно кидать ссылку на этот пресс-релиз тем, кто во время утечек только шеймит исполнителей.

Ответить
Развернуть ветку
Михаил Качалов
Яндекс показывает очень хороший и адекватный пример, когда не только поругали сотрудника, но и починили у себя

- с логикой согласен, с оценкой нет: "поругали" - почему смягчаете? в тексте - "уволили"; "починили" - опять смягчаете, в тексте "планируют пересмотреть". Тут вопросы: почему эти процессы раньше никто не анализировал, а если анализировал, то какое наказание положено тому сотруднику ИБ или аналитику который эти процессы разработал? Почему одна из крупнейших на российском рынке IT компаний, которая хорошо знает что такое утечки данных, зашевелилась только тогда когда эта утечка произошла?

Ответить
Развернуть ветку
Гала Перидоловна
Тут вопросы: почему эти процессы раньше никто не анализировал, а если анализировал, то какое наказание положено тому сотруднику ИБ или аналитику который эти процессы разработал?

Никакое не положено. Делать выводы ретраспективно очень удобно, если ты не тот человек, который все это дело проектировал.

Почему одна из крупнейших на российском рынке IT компаний, которая хорошо знает что такое утечки данных, зашевелилась только тогда когда эта утечка произошла?

Потому, что предусмотреть все векторы атаки невозможно. Вы думаете, что чувак там сидел и пароли из базы копировал? Тем более как защититься от человека, который по должностным обязанностям администрировать базы? Писать заявление на имя начальника на выполнение каждой команды?

Ответить
Развернуть ветку
Михаил Качалов
предусмотреть все векторы атаки невозможно

- ой не смешите. Все аспекты невозможно, хотя люди давно над этим работают и кому-то по должностным обязанностям положено знать слова - "инсайдерская (внутренняя) угроза", но то что чувак имеющий доступ может им воспользоваться в дурных целях - это и глупышу понятно.

Делать выводы ретраспективно очень удобно

- да, обычно именно ретроспективно лишают премии тех, кто план не выполнил или еще как то проштрафился. Хотя мы же говорим об IT!, о Яндексе!, о крутых алгоритмах!, об искусственном интеллекте который картины рисует! - тут наверное походы другие, плохишей можно прогнозировать и заранее штрафовать.

Вы думаете, что чувак там сидел и пароли из базы копировал?

- а Вы думаете он их запоминал и как Джони-мнемоник в башке уносил? Как думаете зачем в некоторых конторах USB-порты не работают и трафик сканится? Ну и другие способы контроля существуют (специалисты знают)

Ответить
Развернуть ветку
Гала Перидоловна
да, обычно именно ретроспективно лишают премии тех, кто план не выполнил или еще как то проштрафился. Хотя мы же говорим об IT

Нет, ни в одной области нельзя наказывать людей за то, что они не сделали по причине того, что не смогли предусмотреть все варианты. Это относится и к IT и к заборостроительной компании. Наказание приводит к страху потери зарплаты/премии/работы, что в целом ведет к консервации компании и последующему затуханию вообще всех процессов. Хотите второй Сбер - пожалуйста.
Премий нельзя лишать. Премию нужно выдавать в зависимости от результатов. Опять же, человек не будет стермиться сделать что-то лучше, если премия у него и так в кармане.

Вы думаете он их запоминал и как Джони-мнемоник в башке уносил?

Пароли никто не хранит в открытом виде, тем более помимо пароля есть еще 2FA. Это самый бессмысленный способ атаки. Скорее всего человек уводил какие-то идентификаторы, которые идентифицировали текущую авторизованную сессию, либо генерировал новые сессии.

Как думаете зачем в некоторых конторах USB-порты не работают и трафик сканится?

Потому, что они не осили условный osquery? Уже даже самый ленивый после релиза от FB себе внедрил его. Ну и DPI не отменяет факта передачи, он используется как мониторинг активности.

Ну и другие способы контроля существуют (специалисты знают)

Видимо вы вообще никогда с ИБ не сталкивались и не понимаете что используется для обнаружения атак, а что для предотвращения. И что риски для разных групп по-разному оцениваются.

Ответить
Развернуть ветку
Ольга Грабко
Пароли никто не хранит в открытом виде, тем более помимо пароля есть еще 2FA.

Простите, что вмешиваюсь в беседы взрослых о высоком, но мне вот прям вчера домру при подключении припёр данные для входа в лк на листочке. А я автоматически сгенерированный пароль меняла при первом входе в лк, до подключения. Вот они мне мной установленный типа постоянный пароль на листочке и выдали. Мне показалось это дичь, а поддержка ответила, что всё норм, все безопасно, это для удобства. 
Если не затруднит, дайте профессиональный комментарий, пожалуйста. 

Ответить
Развернуть ветку
Эрик Безфамильный

Ну, если конечно идеализировать весь процесс вкратце, потому что ручаться мы не можем, как там всё на самом деле - есть определенный сервер, который хранит очередь адресов на подключение, где пароли хранятся в незашифрованном виде, откуда потом данные удаляются после подключения. А есть уже сервер с базой данных, где пароль хранится в зашифрованном виде, для проверки данных во время авторизации в ЛК. 

Ответить
Развернуть ветку
Ольга Грабко

При восстановлении пароля они шлют старый пароль, а не генерируют новый. Значит хранятся постоянные пароли в лучшем случае обратимо зашифрованными, не хэшами. 
Да и описанный "идеальный" вариант чёт не выглядит нормальным, пока хранит и тащит на листочке в руках техника установленный юзером, а не только автоматически сгенерированный временный пароль. 
В моих представлениях, система это как-то все же различать должна. Хз, может мои представления слишком идеальны? Но мне б почему-то хотелось, чтоб установленный мной пароль нельзя было восстановить из значения, хранящегося в базе, про "притащить на листочке и обвести заботливой ручкой техника" вообще молчу. 

Ответить
Развернуть ветку
Эрик Безфамильный

Чтож... Я пытался. Но мой описанный вариант, и вправду идеален, по крайней мере мне так кажется. Других я не вижу. Иногда бывают такие вынужденные меры (я про хранение и таскание на листочке и т.д). С одной стороны, это всего лишь доступ в ЛК провайдера, там особо ничего не натворишь, да и никто их не ломает, нафиг никому не надо.
А если в общем и целом, то... 

Ответить
Развернуть ветку
193 комментария
Раскрывать всегда