Как защитить доступ к бэкапам

Краткий ответ: Дайте бэкапам собственные учётные данные: отдельный пользователь на хранилищном сервере, отдельный SSH-ключ на каждой исходной машине и максимально узкие права. Цель — одностороннее стекло: продакшн может писать новые бэкапы, но скомпрометированный продакшн-сервер не может читать чужие данные или удалять историю.

Обзор

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

Что нужно иметь

• Рабочий поток бэкапов на Storage VPS или похожую цель.
• Базовое управление SSH-ключами (гайд).
• Десять минут на каждый исходный сервер, чтобы заменить общие доступы на отдельные.

Пошаговая инструкция

1. Один пользователь на исходную машину на хранилищном сервере — никогда не общий аккаунт:

   adduser bk-web1
   mkdir -p /srv/backups/web1 && chown bk-web1:bk-web1 /srv/backups/web1
   chmod 700 /srv/backups/web1

2. Один ключ на источник, только для бэкапов, и с ограниченной командой, где возможно:

   # /home/bk-web1/.ssh/authorized_keys
   command="rrsync /srv/backups/web1",restrict ssh-ed25519 AAAA... backup@web1

   (rrsync поставляется с rsync и привязывает ключ к одному каталогу.)
3. Защитите сам хранилищный сервер: SSH только по ключу, без root-логина, файрвол с разрешением SSH только с IP ваших серверов, fail2ban.
4. Защитите историю от удаления: pull-бэкапы, снапшот-раскладки, где источники не трогают старые каталоги, или append-only репозитории:

   borg serve --append-only          # in the forced command
   restic ... # with an append-only rest-server

5. Аудит ежеквартально: просмотрите authorized_keys, уберите серверы, которых больше нет, проверьте времена последних входов на сюрпризы.

Типичные проблемы

• Root-ключ продакшна на бэкап-машине: кто владеет продакшном, тот владеет каждым бэкапом — инвертируйте это отдельными ограниченными пользователями.
• Каталоги бэкапов, читаемые всеми: один дырявый аккаунт открывает данные всех клиентов — chmod 700 на каждый каталог.
• Права на удаление везде: если ключ ночной задачи может чистить историю, ransomware тоже сможет; разделите учётные данные на запись и чистку.

Когда обращаться в поддержку

Безопасность вашей ОС и ключей на unmanaged-планах — на стороне клиента, но откройте тикет, если подозреваете аномальный доступ к самому хранилищному серверу — сетевые логи помогут установить, что произошло.

Частые вопросы

Зачем каждому серверу отдельный бэкап-пользователь?

Изоляция: с одним пользователем и каталогом на исходную машину (chmod 700) компрометация любого сервера открывает только его собственные бэкапы и никогда — данные других машин.

Что такое append-only репозиторий бэкапов?

Режим, в котором бэкап-ключ может добавлять новые данные, но не удалять или перезаписывать историю — borg serve --append-only или флаг restic rest-server; ransomware не сотрёт старые снапшоты.

Как ограничить SSH-ключ только бэкапами?

Добавьте в authorized_keys принудительную команду и ограничения, напр. command="rrsync /srv/backups/web1",restrict — тогда ключ работает только для того каталога и больше ни для чего.

Похожие статьи

• Как шифровать бэкапы
• Как настроить SSH-ключи
• Локальный бэкап против удалённого
• Что делать, если сервер скомпрометирован

Нужна помощь? Связаться с поддержкой Cloud2Y →