Як захистити доступ до бекапів

Коротка відповідь: Дайте бекапам власні облікові дані: окремий користувач на сховищному сервері, окремий 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 →