Как спасти свои данные и бизнес от хакеров (и собственных коллег)
За 20 лет в IT я много раз видел, как компании и рядовые пользователи теряют данные и несут серьезные убытки. Можно ли этого избежать? В большинстве случаев да. Сегодня расскажу, как компании расстаются с важной информацией и деньгами из-за хакеров, а также дам подробный чек-лист по организации резервного копирования.
История: шифровальщик
Самая частая и самая банальная история: вирус-шифровальщик проникает во внутреннюю сеть компании и парализует работу.
В одном случае повезло — шифровальщик лишь переименовал файлы, не трогая их содержимое. Обошлось. В другом — пришлось несколько дней на восстановление инфраструктуры. Платить злоумышленникам, к счастью, не стали.
История: забытый сайт
Однажды наш клиент попросил посмотреть давно заброшенный сайт, за которым никто не следил. Сайт подвергся дефейсу (была заменена главная страница) и пытался заражать посетителей вирусами.
На вопрос «Есть ли бекапы?» был получен радостный ответ «Да!». «Отлично, сейчас мы быстро всё восстановим!»- подумал я. Вот только оказалось, что бекап делается раз в сутки. И сохраняется лишь последняя версия. А поскольку факт взлома был обнаружен лишь спустя неделю, в имеющейся резервной копии хранилась уже взломанная версия. Восстанавливать нечего.
История: вы что-то меняли?
Вторая по частоте история, на которой и мы обжигались на самом старте. Есть проект, данные с которого успешно резервируются в отдельном месте. Но когда бекап реально понадобился, выяснилось, что в нем… ничего нет! Пусто. Потому что недавно проект переехал на другой сервер: перенести перенесли, а вот обновить реквизиты для резервного копирования забыли. Итог: пришлось по кусочку восстанавливать из устаревших копий.
История: ошибка разработчика
Не всегда виноваты взломщики. Бывают и досадные ошибки разработчиков. В самом начале карьеры я работал в известном на всю страну проекте. И так уж там повелось: разработка велась с использованием боевой (рабочей) базы данных, а не на отдельном тестовом стенде.
Однажды я позвал начальника, чтобы сдать очередную задачу. Он сразу заметил ошибку — забытое условие в коде, которое поменяет данные обо всех проведённых оплатах. Ставит сумму в одну копейку, а меня — получателем абсолютно для всех платежей.
— Ох, — сказал начальник. — Хорошо, что это ещё не выполнялось.
Это был тот самый случай, когда хотелось провалиться сквозь несколько этажей бизнес-центра, а потом и сквозь землю. Сложнее всего было открыть рот и выдавить из себя:
— Андрей… выполнялось…
— Ну… Разбирайся…
И ушел. Можете себе представить масштаб бедствия? Провалиться мне не удалось, поэтому пришлось разбираться. Спасибо коллегам-инфраструктурщикам: с резервными копиями в компании было всё хорошо и данные удалось спасти. А вот нервные клетки изрядно пострадали.
Чек-лист: как себя обезопасить
В Code Pilots мы не только извлекли уроки из ситуаций выше, но также составили чек-лист, помогающий минимизировать риск потери данных.
Резервные копии хранятся на отдельной машине. В идеале — в другом датацентре. Это позволит всё восстановить, даже если в дата-центре случится пожар.
Сервер резервных копий занимается исключительно резервным копированием. Этим мы минимизируем вероятность взлома.
Доступ к серверу есть у строго ограниченного круга лиц (у единиц) и только по ключам.
Другие машины не имеют доступа к серверу с резервными копиями (в т.ч. те, с которых мы забираем данные). Иначе при взломе одного сервера, взломают и все остальные.
Сохраняется не только последняя копия, но и предыдущие периоды. Ведь иногда бывает, что единственная копия уже содержит проблемные данные. В идеале сохранять 7 последних дней, 4 понедельника, 12 первых чисел последних месяцев.
Регулярно проводится проверка полноты и корректности сохраненных данных.
Настроен автоматический мониторинг ключевых параметров сервера резервных копий: доступность, место на диске и т.д.
Раз в месяц задаются вопросы: не появилось ли чего-то нового, что также нужно сохранить? Актуален ли список доступов или в нем остались уволенные сотрудники?
Что точно следует сохранять?
Базы данных;
Исходный код;
Файлы, которые невозможно автоматически создать заново (например, загрузки пользователей);
Настройки, параметры конфигурации (как сервера, так и приложения);
Периодические задания (cron).
Вам есть чем дополнить список? Буду рад вашим предложениям в комментариях!
Я 10 лет развиваю свое агентство по разработке, запустил сотни проектов, в том числе свой стартап. Делюсь опытом по управлению командой, развитию бизнеса и просто личными историями побед и поражений в своем телеграм-канале. Подписывайтесь!
