Как спасти свои данные и бизнес от хакеров: советы от IT-предпринимателя

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

История: шифровальщик

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

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

История: забытый сайт

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

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

История: вы что-то меняли?

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

История: ошибка разработчика

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

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

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

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

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

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

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

Чек-лист: как себя обезопасить

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

• Резервные копии хранятся на отдельной машине. В идеале — в другом датацентре. Это позволит все восстановить, даже если в дата-центре случится пожар.
• Сервер резервных копий занимается исключительно резервным копированием. Этим мы минимизируем вероятность взлома.
• Доступ к серверу есть у строго ограниченного круга лиц (у единиц) и только по ключам.
• Другие машины не имеют доступа к серверу с резервными копиями (в т.ч. те, с которых мы забираем данные). Иначе при взломе одного сервера, взломают и все остальные.
• Сохраняется не только последняя копия, но и предыдущие периоды. Ведь иногда бывает, что единственная копия уже содержит проблемные данные. В идеале сохранять 7 последних дней, 4 понедельника, 12 первых чисел последних месяцев.
• Регулярно проводится проверка полноты и корректности сохраненных данных.
• Настроен автоматический мониторинг ключевых параметров сервера резервных копий: доступность, место на диске и т.д.
• Раз в месяц задаются вопросы: не появилось ли чего-то нового, что также нужно сохранить? Актуален ли список доступов или в нем остались уволенные сотрудники?

Что точно следует сохранять:

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