Как спасти свои данные и бизнес от хакеров (и собственных коллег)

За 20 лет в IT я много раз видел, как компании и рядовые пользователи теряют данные и несут серьезные убытки. Можно ли этого избежать? В большинстве случаев да. Сегодня расскажу, как компании расстаются с важной информацией и деньгами из-за хакеров, а также дам подробный чек-лист по организации резервного копирования.

Самая частая и самая банальная история: вирус-шифровальщик проникает во внутреннюю сеть компании и парализует работу.

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

Однажды наш клиент попросил посмотреть давно заброшенный сайт, за которым никто не следил. Сайт подвергся дефейсу (была заменена главная страница) и пытался заражать посетителей вирусами.

На вопрос “Есть ли бекапы?” был получен радостный ответ “Да!”. “Отлично, сейчас мы быстро всё восстановим!”- подумал я. Вот только оказалось, что бекап делается раз в сутки. И сохраняется лишь последняя версия. А поскольку факт взлома был обнаружен лишь спустя неделю, в имеющейся резервной копии хранилась уже взломанная версия. Восстанавливать нечего.

Вторая по частоте история, на которой и мы обжигались на самом старте. Есть проект, данные с которого успешно резервируются в отдельном месте. Но когда бекап реально понадобился, выяснилось, что в нем… ничего нет! Пусто. Потому что недавно проект переехал на другой сервер: перенести перенесли, а вот обновить реквизиты для резервного копирования забыли. Итог: пришлось по кусочку восстанавливать из устаревших копий.

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

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

— Ох, — сказал начальник. — Хорошо, что это ещё не выполнялось.

Это был тот самый случай, когда хотелось провалиться сквозь несколько этажей бизнес-центра, а потом и сквозь землю. Сложнее всего было открыть рот и выдавить из себя:

— Андрей… выполнялось…

— Ну… Разбирайся…

И ушел. Можете себе представить масштаб бедствия? Провалиться мне не удалось, поэтому пришлось разбираться. Спасибо коллегам-инфраструктурщикам: с резервными копиями в компании было всё хорошо и данные удалось спасти. А вот нервные клетки изрядно пострадали.

В Code Pilots мы не только извлекли уроки из ситуаций выше, но также составили чек-лист, помогающий минимизировать риск потери данных.

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

- Сервер резервных копий занимается исключительно резервным копированием. Этим мы минимизируем вероятность взлома.

- Доступ к серверу есть у строго ограниченного круга лиц (у единиц) и только по ключам.

- Другие машины не имеют доступа к серверу с резервными копиями (в т.ч. те, с которых мы забираем данные). Иначе при взломе одного сервера, взломают и все остальные.

- Сохраняется не только последняя копия, но и предыдущие периоды. Ведь иногда бывает, что единственная копия уже содержит проблемные данные. В идеале сохранять 7 последних дней, 4 понедельника, 12 первых чисел последних месяцев.

- Регулярно проводится проверка полноты и корректности сохраненных данных.

- Настроен автоматический мониторинг ключевых параметров сервера резервных копий: доступность, место на диске и т.д.

- Раз в месяц задаются вопросы: не появилось ли чего-то нового, что также нужно сохранить? Актуален ли список доступов или в нем остались уволенные сотрудники?

Что точно следует сохранять?
- Базы данных;
- Исходный код;
- Файлы, которые невозможно автоматически создать заново (например, загрузки пользователей);
- Настройки, параметры конфигурации (как сервера, так и приложения);
- Периодические задания (cron).

Вам есть чем дополнить список? Буду рад вашим предложениям в комментариях!