ИТ-безопасность простыми словами: архивирование данных (бэкапы)

В этой части цикла разберёмся с темой, без которой все остальные меры безопасности теряют смысл: резервное копирование данных. Что, куда и как копировать, чтобы одна атака или сбой не остановили ваш бизнес.

«Люди делятся на тех, кто уже делает бэкапы…»

Среди системных администраторов есть шутка: «Люди делятся на две категории: те, кто не делает бэкапы, и те, кто уже делает».

Во многих небольших компаниях резервному копированию уделяется мало внимания. Бэкапы делаются время от времени — руками, когда «вспомнили» — или вообще не делаются.

Частая картина:

  • копии лежат там же, где и рабочие данные;
  • никто не проверяет, можно ли из них восстановиться;
  • никто не знает, когда последний раз делалась копия.

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

Почему бэкапы — must have для любой компании

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

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

Если у компании нет надёжной системы резервного копирования, то у неё по сути, нет и системы информационной безопасности.

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

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

Итак, основные принципы:

  • Бэкапы дожны храниться исключительно на отдельном сервере или хранилище.
  • Очень желательно, чтобы хранилища с бэкапами находились физически далеко от серверов с данными. Например, если в здании, где находится серверная, случится пожар, то архивы, находящиеся в другом здании, не пострадают. Очень желательно, чтобы архивы копировались в два и более хранилища архивов, особенно, если это очень чувствительные данные для жизни компании. Вспомним пример с автосервисной компанией, приведенный в части 1.
  • Сервисы архивации (например, программы архивации, которые запускаются на серверах) не должны связываться в хранилищами архивов и отсылать им свежие архивы. Хранилища архивов должны САМИ подключаться к этим сервисам и «забирать» у них архивы. Например, на сервере баз данных в 3 часа ночи запускается архивация базы данных, а в 4 часа хранилище архивов подключается к серверу и «забирает» себе последний архив. Для чего это нужно? Если на сервер баз данных проникнет злоумышленник, и уничтожит базы данных, он не найдет на этом сервере учетных данных хранилища архивов. Он, возможно, даже не сможет узнать его о существовании.
  • Хранилище архивов необходимо обслуживать (например, следить за наличием свободного места, настраивать его и т.п.). Для этого у администратора должен быть доступ к хранилищу архивов. Идеально, если это будет отдельный компьютер, с которого будет осуществляться доступ к хранилищу, а пароль на такой доступ будет храниться в виде бумажной копии. Или выполнять все работы непосредственно на самом хранилище архивов. В любом случае, учетные данные для доступа к хранилищам архивов должны храниться отдельно от других учетных записей и должны быть надежно защищены.

Сейчас очень популярно хранение архивов на облачных сервисах, таких как Amazon S3, MS Azure и т.п. Но здесь важны, с нашей точки зрения несколько моментов:

  • Архивы, находящиеся в облачном хранилище, должны быть обязательно зашифрованы (либо средствами этих сервисов, либо уже отправляться в зашифрованном виде, что лучше). Это позволит избежать доступа к данным третьих лиц.
  • Отправка архивов в облачное хранилище должно осуществляться из локального хранилища, которое уже «забрало» себе архивы, которые создаются на серверах.

Итак, схема архивации примерно такая:

  • на серверах, где находятся данные, запускается архивация и создаются «свежие» архивы.
  • хранилище архивов по расписанию заходит на эти серверы и «забирает» себе «свежие» архивы.
  • хранилище шифрует архивы и отправляет шифрованные копии в облачное хранилище.

Таким образом, мы имеет три копии архивов: на серверах данных, на хранилище архивов и на облачном хранилище.

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

Коротко:

1) Бэкапы должны жить отдельно от данных

Резервные копии нужно хранить на отдельном сервере или хранилище, а не на том же диске, где находятся рабочие базы. В этом случае:

  • Сбой основного сервера ≠ потеря бэкапов.
  • Шифровальщик на основном сервере не должен добраться до хранилища резервных копий.
Критическая ошибка: хранить архивы на том же диске или в той же папке, что и «живые» данные.

2) Физическое разделение: разные здания и площадки

Очень желательно, чтобы сервер/хранилище с бэкапами находилось физически отдельно от основного оборудования. Например:

  • Головной офис — рабочие серверы.
  • Филиал — хранилище бэкапов.

При пожаре, затоплении или краже оборудования в одном месте резервные копии останутся целыми в другом.

Для особо критичных данных: держать копии в двух и более независимых хранилищах.

3) Хранилище само забирает бэкапы

Важно, чтобы сервер с рабочими данными не хранил учётные данные хранилища бэкапов.

Правильная схема:

  • на сервере в 03:00 создаётся свежий архив базы;
  • в 04:00 хранилище само подключается к серверу и «забирает» архив;
  • сервер не знает логина и пароля от хранилища.
Зачем: если злоумышленник попал на сервер с данными, он не сможет добраться до хранилища бэкапов и удалить/зашифровать архивы.

4) Доступ к хранилищу — под особым контролем

Хранилище бэкапов требует обслуживания: мониторинг свободного места, настройка, проверка восстановления.

  • Доступ к нему имеет ограниченное число администраторов.
  • Учётные данные для хранилища архивов хранятся отдельно от других паролей.
  • В идеале — на отдельном защищённом компьютере и в бумажном виде.
Идея: даже если украдут пароль от обычной «парольной базы», добраться до бэкапов будет невозможно.

Облака: Amazon S3, Azure и другие

Сейчас очень популярно хранить резервные копии в облаках: Amazon S3, Microsoft Azure и т.п. Это удобно и надёжно — если соблюдать несколько правил.

Два ключевых момента

  • Шифрование. Архивы в облаке должны быть зашифрованы — либо силами сервиса, либо передаваться уже в зашифрованном виде.
  • Отправка из локального хранилища. Серверы с данными сначала складывают архивы в локальное хранилище бэкапов, и уже оно отправляет копии в облако.
Схема: серверы → локальное хранилище бэкапов → шифрование → облако.

Как выглядит правильная схема архивирования

Упростим всё до трёх шагов.

  1. На серверах создаются свежие архивы.
    По расписанию (например, ночью) на сервере с базами запускается задача резервного копирования.
  2. Хранилище забирает архивы.
    Отдельный сервер-хранилище подключается к рабочим серверам и забирает свежие копии.
  3. Хранилище шифрует и отправляет копии в облако.
    В итоге у вас есть три уровня защиты: данные на серверах, локальное хранилище бэкапов, облачное хранилище.
Результат: даже если один из уровней будет уничтожен или зашифрован, у вас останутся остальные копии.

Мини-чеклист по резервному копированию

  • Бэкапы не лежат на тех же дисках, что и рабочие данные.
  • Есть как минимум одно отдельное хранилище бэкапов.
  • Хранилище само забирает архивы с серверов, а не наоборот.
  • Учётные данные для доступа к хранилищам архивов защищены и хранятся отдельно.
  • Если используются облачные хранилища — есть ли шифрование архивов.
  • Регулярно проверяется возможность восстановления из бэкапов.

Не уверены, что ваши бэкапы реально спасут в критический момент?

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

Прокрутить вверх