Как спасти свои данные и бизнес от хакеров (и собственных коллег)
За 20 лет в IT я много раз видел, как компании и рядовые пользователи теряют данные и несут серьезные убытки. Можно ли этого избежать? В большинстве случаев да. Сегодня расскажу, как компании расстаются с важной информацией и деньгами из-за хакеров, а также дам подробный чек-лист по организации резервного копирования.
История: шифровальщик
Самая частая и самая банальная история: вирус-шифровальщик проникает во внутреннюю сеть компании и парализует работу.
В одном случае повезло - шифровальщик лишь переименовал файлы, не трогая их содержимое. Обошлось. В другом - пришлось несколько дней на восстановление инфраструктуры. Платить злоумышленникам, к счастью, не стали.
История: забытый сайт
Однажды наш клиент попросил посмотреть давно заброшенный сайт, за которым никто не следил. Сайт подвергся дефейсу (была заменена главная страница) и пытался заражать посетителей вирусами.
На вопрос “Есть ли бекапы?” был получен радостный ответ “Да!”. “Отлично, сейчас мы быстро всё восстановим!”- подумал я. Вот только оказалось, что бекап делается раз в сутки. И сохраняется лишь последняя версия. А поскольку факт взлома был обнаружен лишь спустя неделю, в имеющейся резервной копии хранилась уже взломанная версия. Восстанавливать нечего.
История: вы что-то меняли?
Вторая по частоте история, на которой и мы обжигались на самом старте. Есть проект, данные с которого успешно резервируются в отдельном месте. Но когда бекап реально понадобился, выяснилось, что в нем… ничего нет! Пусто. Потому что недавно проект переехал на другой сервер: перенести перенесли, а вот обновить реквизиты для резервного копирования забыли. Итог: пришлось по кусочку восстанавливать из устаревших копий.
История: ошибка разработчика
Не всегда виноваты взломщики. Бывают и досадные ошибки разработчиков. В самом начале карьеры я работал в известном на всю страну проекте. И так уж там повелось: разработка велась с использованием боевой (рабочей) базы данных, а не на отдельном тестовом стенде.
Однажды я позвал начальника, чтобы сдать очередную задачу. Он сразу заметил ошибку - забытое условие в коде, которое поменяет данные обо всех проведённых оплатах. Ставит сумму в одну копейку, а меня - получателем абсолютно для всех платежей.
— Ох, — сказал начальник. — Хорошо, что это ещё не выполнялось.
Это был тот самый случай, когда хотелось провалиться сквозь несколько этажей бизнес-центра, а потом и сквозь землю. Сложнее всего было открыть рот и выдавить из себя:
— Андрей… выполнялось…
— Ну… Разбирайся…
И ушел. Можете себе представить масштаб бедствия? Провалиться мне не удалось, поэтому пришлось разбираться. Спасибо коллегам-инфраструктурщикам: с резервными копиями в компании было всё хорошо и данные удалось спасти. А вот нервные клетки изрядно пострадали.
Чек-лист: как себя обезопасить
В Code Pilots мы не только извлекли уроки из ситуаций выше, но также составили чек-лист, помогающий минимизировать риск потери данных.
- Резервные копии хранятся на отдельной машине. В идеале - в другом датацентре. Это позволит всё восстановить, даже если в дата-центре случится пожар.
- Сервер резервных копий занимается исключительно резервным копированием. Этим мы минимизируем вероятность взлома.
- Доступ к серверу есть у строго ограниченного круга лиц (у единиц) и только по ключам.
- Другие машины не имеют доступа к серверу с резервными копиями (в т.ч. те, с которых мы забираем данные). Иначе при взломе одного сервера, взломают и все остальные.
- Сохраняется не только последняя копия, но и предыдущие периоды. Ведь иногда бывает, что единственная копия уже содержит проблемные данные. В идеале сохранять 7 последних дней, 4 понедельника, 12 первых чисел последних месяцев.
- Регулярно проводится проверка полноты и корректности сохраненных данных.
- Настроен автоматический мониторинг ключевых параметров сервера резервных копий: доступность, место на диске и т.д.
- Раз в месяц задаются вопросы: не появилось ли чего-то нового, что также нужно сохранить? Актуален ли список доступов или в нем остались уволенные сотрудники?
Что точно следует сохранять?
- Базы данных;
- Исходный код;
- Файлы, которые невозможно автоматически создать заново (например, загрузки пользователей);
- Настройки, параметры конфигурации (как сервера, так и приложения);
- Периодические задания (cron).
Вам есть чем дополнить список? Буду рад вашим предложениям в комментариях!
Есть ощущение, что прежде чем настраивать бэкапы, нужно навести порядок в корпоративных знаниях — хотя бы элементарно выделить файловую помойку и обязать все рабочие файлики хранить там — иначе придётся бэкапить ещё и документы на машинках пользователей, а это сильно всё усложняет. Нет?
Ну а как иначе? Бекапить все компы это же бред
Ну вот и я о том же. Что начинать надо на уровень выше, с организации, а не с железок )))
Централизованное хранения информации да это начало, а вот дальше уже вопрос облако или свой сервак вплоть до физического в офисе
Всё так, но одно другому не мешает. Файловую помойку без бекапа сможет угробить любая взломанная машина из общей сети (или недовольный сотрудник)
Я про процесс ))) Если важные данные раскиданы по куче машин — их же сложнее собрать для бэкапа, чем если они хранятся в одном месте?
Верно, главное, чтобы это самое место было достаточно надежным)
Как-то у нас упал клиентский сайт, сразу все изучили про бэкапы
Классика! 😁
Ну как… КАК можно забыть обновить реквизиты для резервного копирования? И сколько вы потом восстанавливали все?
Как это чаще всего бывает - человеческий фактор, недоглядели 🤷♂️
К счастью, то был не самый активный проект, и обошлось без серьезных последствий
Самое сложное — не забывать делать бэкапы на личных компах. За клиентов всегда чувствуем ответственность, а про себя любимых забываем
Забыли про самый главный лайфхак: жестко публично пороть каждого сотрудника, который на свою рабочую машину качает подозрительные файлы из почты, странные программы и прочее-прочее-прочее
Спасибо за наводку! Пару лет назад сотрудники как раз подарили мне хлыст на день рождения, всё без дела лежал… 😅
Как быть с удаленщиками?
А в чем разница?
Контроля никакого, в основном работают на личных компах
Ставьте систему для контроля, данные храните на корпоративном сервере. Защищайте сервер. Идеально подойдет Битрикс 24 там есть все..
https://dodcio.defense.gov/Portals/0/Documents/Library/(U)ZT_RA_v2.0(U)_Sep22.pdf
Каждого, кто качает мемы!
Есть у вас рекомендации по бэкапам облачных хранилищ? Тот же гугл диск, допустим?
В целом рекомендации те же - независимое хранилище, несколько копий, …
А вот сами технические инструменты могут отличаться. Из известных мне есть rclone, который в правильных руках может сделать всё что нужно.
Так а есть истории, когда после перевода денег злоумышленники реально давали ключ? Звучит, как скам.
Есть и не один. Правда спустя какое-то время они могут вернуться снова 👀
А сколько просят за ключи? Просто интересно понять порядок цен хотя бы примерный))
Тут, надо отдать должное, чаще всего действует гибкое ценообразование) если взломали частную машину - ценник небольшой. Если масштабное предприятие - всё становится на порядки дороже.
Факапы жесткие, сочувствую автору. А за чек-лист огромное спасибо!
на жестких факапах учатся. Спасибо!
Вот про сотрудников да, актуально. Давно уже задумывался, что нужен какой-то инструмент, чтобы при появлении нового сотрудника по нажатию кнопки он делал сотруднику аккаунт в корпоративном GitLab, YouTrack, Slack. SSH-ключ рабочего компа прописывал на тех стендах, на которых человек работает. При увольнении сотрудника - чтобы корректно забирал доступы и деактивировал учетные записи. Иначе получается человек уволился, а доступ у него ко всему остался - кто ж все эти ключи на стендах проверяет! Мб что-то подобное вы уже реализовали?
Пока дошли до использования SSO авторизаций с привязкой к корпоративной почте. А выдачу/отзыв ключей пока ручной. Смотрим в сторону реализации этого функционала в рамках внутренней ERP системы
Проинструктировать сотрудников, чтобы не ставили пароль 123. Такое тоже иногда спасает, особенно, когда главный менеджер не крепит листочек с таким паролем у себя на самом видном месте на рабочем столе