Альтернативный подход к резервному копированию с учетом безопасности хранения данных

Reduction_Gear

Сегодня мы рассмотрим несколько иной подход к резервному копированию linux, который будет использовать те методы, которые мы использовали ранее (duplicity), но с учетом пожелания, чтобы данные, которые мы резервируем хранились наиболее безопасно, то есть, чтобы при взломе сервера, на котором хранятся оригиналы, злоумышленник не смог получить доступ к резервным копиям. То есть, мы будем защищать данные от целенаправленного действия, когда злоумышленник взламывает именно Ваш сервер с целью безвозвратного удаления Ваших данных.

Рассмотрим исходный способ резервного копирования, который описан ранее в статьях:

  1. Резервное копирование с помощью duplicity;
  2. Практическая настройка duplicity.

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

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

Итак, рассмотрим аутентификацию по SSH с помощью ключей. Команда ssh-keygen генерирует два ключа: id_rsa и id_rsa.pub. Их свойства таковы, что, если Вы имеете доступ к ключу id_rsa, то сможете авторизоваться на хосте, хранящем id_rsa.pub в authorized_keys. В применении к нашей задаче получаем, что на хосте где лежат основные данные имеется ключ id_rsa для хранилища. С другой стороны, если есть доступ только к публичной части id_rsa.pub, то это ничего не дает, Вы не можете авторизоваться на хосте, который хранит id_rsa. Это свойство мы и будем использовать.

Для защиты наших данных мы введем дополнительный хост-агент, который получит доступ к нашей системе с данными посредством протокола SSH с использованием SSHFS. Таким образом, на хосте с данными будет храниться публичный ключ хоста-агента, а на хосте-агенте будет храниться приватный ключ. Все резервное копирование будет выполнять хост-агент. Все то же самое в таблице:

Хост Ключ для хоста с данными Ключ хоста с хранилищем архивов Потенциальная уязвимость
Агент ID_RSA_HOST ID_RSA_ARCH низкая
Данные ID_RSA_HOST.PUB высокая
Хранилище ID_RSA_ARCH.PUB низкая

Несколько замечаний:

  1. уязвимости Агента и Хранилища низкие, потому что они не экспортируют лишних сервисов и никак себя в публичной сети не проявляют;
  2. уязвимость Хоста с Данными высокая, потому что он проявляет себя в сети и его будут взламывать, в случае атаки.
  3. Только Агент имеет доступ к обоим серверам и поэтому он является тем узлом, который необходимо защищать от взлома и обнаружения.
  4. Хост с Данными не может обратиться ни к Хранилищу ни к Агенту, а значит, что его взлом не приведет к потере данных.
  5. На Агенте и Хосте с Данными необходимо иметь различные пароли, а для Агента желательно запретить соединение с ним по SSH с Хоста с Данными.

Следующий шаг — настройка агента.

Настройка агента

Для настройки агента необходимо выполнить следующие команды:

# обновим информацию репозиториев
# apt-get update
# установим SSHFS и duplicity
# apt-get install sshfs duplicity
# сгенерируем ключи для доступа к хосту с данными (пароль не указываем)
# ssh-keygen -t rsa
# внесем публичный ключ на сервер с данными
# cat /root/.ssh/id_rsa.pub | ssh root@datahost cat >> /root.ssh/authorized_keys
# загрузим модуль для работы с SSHFS (fuse)
# modprobe fuse
# добавим модуль в автозагрузку
# echo "fuse" >> /etc/modules
# создадим точку монтирования
# mkdir /mnt/data-source
# добавим информацию в fstab о монтировании корня с сервера с данными
# echo "root@datahost:/ /mnt/data-source  fuse.sshfs     noauto,_netdev,IdentityFile=/root/.ssh/id_rsa,reconnect     0     0" >> /etc/fstab
# монтируем
# mount /mnt/data-source

После выполнения данных команд в каталоге /mnt/data-source мы увидим корневой каталог с сервера, который мы планируем копировать. Вот практически и все… Теперь надо организовать резервное копирование данных из каталога /mnt/data-source средствами duplicity. Поскольку в качестве файловой системы используется FUSE-реализация SSHFS, то это снижает производительность резервного копирования и нагружает процессор, что может затруднить копирование больших объемов данных.

В случае, если Агент и Сервер с Данными располагаются в безопасном, управляемом сегменте сети, Вы можете использовать на Сервере с Данными NFS-сервер, а на агенте NFS-клиент, что положительно повлияет на производительность резервного копирования.

Удачи в защите своих данных.