04.07.2026 · Самуил Арсов · NIS2, Киберсигурност

Киберзащита за малкия бизнес (част 10): архивиране (backup) с отдалечен NAS, rsync и SSH

📚 Поредица „Киберзащита за малкия бизнес“ — части: 0 1 2 3 4 5 6 7 8 9 10 11

Десета част от поредицата ни за киберзащита на малкия и среден бизнес. Изградихме защитен рутер, сървър, комутатор, VPN, мониторинг, SIEM и — в предишната част — обучен персонал. Но има един въпрос, който рано или късно спасява (или погубва) целия бизнес: какво става, когато въпреки всичко нещо се обърка? Изтрит по грешка файл, отказал диск, откраднат лаптоп или крипто вирус, който заключи всичко.

Архивът (backup) — застраховката на бизнеса. Тази, за която не се сещаш, докато не ти потрябва.

Защо повечето „архиви“ не вършат работа

Архивът е едновременно най-често пренебрегваната и най-често грешно изпълнената част от системата. Две са класическите провали.

Първо — архив няма изобщо, или седи на същото физическо място, където са и данните. Пожар, наводнение, кражба или ransomware, който криптира и мрежовата папка — и „архивът“ изчезва заедно с оригинала.

Второ — архив уж има, но е фиктивен. Фирмата „прави архив всяка вечер в 22:00 ч.“ Една година по-късно служител се опитва да върне файл — и се оказва, че:

доставчикът е сменил IP адреса и архивиращото устройство отдавна не се свързва;
на архивиращото устройство му е изгорял дискът, но никой не е видял;
самото устройство изобщо не работи, защото чистачката го е изключила, за да включи прахосмукачката в единствения свободен контакт;
задачата тихо се е чупила от месеци и никой не е проверявал.

Архив, който никой не проверява дали работи и дали изобщо се възстановява, не е архив.

Единственият праведен път

След всичко изброено има само една правилна посока. Добрият архив е:

На отдалечено физическо място, през Интернет. Скоростите отдавна го позволяват. Данните и копието им НЕ трябва да са в една и съща стая — в идеалния случай дори не в един и същи град.
Автоматичен. Човек забравя; машината — не. Никакво „ще го пусна аз довечера“.
С правилна честота — нито прекалено чест, нито веднъж на две седмици. Един път на 24 часа е балансът за повечето фирми: губиш най-много един работен ден, без да товариш мрежата постоянно.
С постоянен достъп до архива. Въпреки че NAS-ът е отдалечен, до него трябва да можеш да стигнеш по всяко време — иначе възстановяването се превръща в приключение точно когато нямаш време за приключения.

Това е и духът на класическото правило 3-2-1: 3 копия на данните, на 2 различни носителя, 1 от които извън обекта. Нашият отдалечен NAS е точно това „1 извън обекта“.

Устройството: ASUSTOR AS5402T

За ролята на отдалечен архивен сторидж избрахме ASUSTOR AS5402T. Причините:

Компактен и малък — побира се навсякъде в отдалечения офис, без да заема половин шкаф.
2 × 10TB HDD — конфигурирани като обем от ~18TB полезно пространство за архива.
x86 архитектура (не ARM) с Linux-базирана операционна система (ADM) — истински Linux под капака, а не ограничен фърмуер.
Удобен Control Panel (ASUSTOR ADM), но с възможност за включен SSH и наличен rsync — точно това, което ни трябва.

Честно за RAID 0: двата диска са в обем без резервираност — ако единият откаже, копието на него се губи. Тук това е съзнателен компромис за максимален капацитет, защото това е вторичното копие — оригиналът стои на продукционния сървър (правилото 3-2-1 остава спазено). За архив, който е единственото копие на критични данни, бихме сложили RAID 1 (огледало) и бихме пожертвали половината капацитет за спокойствие.

Сърцето на решението: rsync през SSH

Ключът към целия механизъм е една малка, но гениална програма — rsync.

Обикновеното копиране прехвърля всичко всеки път. Ако архивът ти е няколко терабайта, това е немислимо да минава всяка нощ по Интернет. rsync копира само разликите. Той сравнява източника и целта и прехвърля единствено променените части на файловете. Дори сървърът да съдържа терабайти, ако за деня са се променили 200 MB — по мрежата минават само тези 200 MB.

Резултатът: по-малко трафик, по-малко време, по-малко натоварване на системата. Първата синхронизация е дълга (минава всичко веднъж), но всяка следваща е бърза.

Вторият стълб е SSH — сигурният канал, по който rsync прехвърля данните. Тук има два важни момента:

Криптиране. През SSH архивът минава шифрован — по пътя между двата града няма кой да го прочете или подмени.
Автентикация със SSH ключ, не с парола. Генерираме двойка ключове на сървъра; публичния слагаме в authorized_keys на NAS-а. Оттам нататък връзката се случва автоматично, без записана парола, и никой не може да я познае или брутфорсне.

Посоката: защо сървърът изпраща, а NAS-ът не изтегля

Тук направихме съзнателен завой спрямо „учебникарския“ вариант — и си струва да обясним честно защо.

На теория е малко по-сигурно NAS-ът да изтегля (pull): инициативата е у архива, той се логва в сървъра и си изтегля данните, така че дори сървърът да бъде компрометиран, атакуващият не вижда архива. Красиво на хартия. На практика обаче вграденият backup помощник на NAS-а предлагаше само rsync daemon на порт 873 — а това е протокол в чист текст. За бизнес документи, които пътуват между два града по Интернет, това е неприемливо: и файловете, и паролата минават нешифровано.

Затова обърнахме посоката: сървърът стартира rsync през SSH и изпраща архива към NAS-а на порт 22. Целият трансфер е шифрован (SSH), а от NAS-а не се иска нищо повече от включен SSH достъп.

Как се разменя ключът (еднократно). Първо генерираме двойка ключове на сървъра — без парола (passphrase), за да може задачата да върви автоматично нощем, без някой да въвежда нищо:

ssh-keygen -t ed25519 -f /root/.ssh/nas_backup -N ""

Това създава два файла: таен ключ nas_backup и публичен nas_backup.pub. Публичния копираме в NAS-а с една команда — тя пита паролата на NAS-а само този единствен път:

ssh-copy-id -i /root/.ssh/nas_backup.pub -p 22 backup@nas.example.net

(Ако устройството няма ssh-copy-id, същото се постига ръчно — добавяш реда от nas_backup.pub във файла ~/.ssh/authorized_keys на NAS-а.) Накрая проверяваме, че вече влизаме без парола:

ssh -i /root/.ssh/nas_backup -p 22 backup@nas.example.net

Оттук нататък rsync ползва същия ключ и работи напълно автоматично.

Примерна команда, с която сървърът изпраща промените към NAS-а:

rsync -az --delete \
  -e "ssh -i /root/.ssh/nas_backup -p 22" \
  /var/nextcloud-data/  backup@nas.example.net:/volume1/backup/nextcloud/

Не забравяй базата данни

Тук е грешката, която проваля много „backup“ настройки на приложения като Nextcloud: rsync копира файлове, но живата база данни не се копира консистентно просто като файл — рискуваш повреден дъмп. Затова, преди синхронизацията, правим консистентен дъмп на базата (без да спираме услугата) и го архивираме заедно с данните:

mysqldump --single-transaction --quick nextcloud | gzip > /backup-staging/db/nextcloud-$(date +%F).sql.gz

Тоест пълният архив на Nextcloud е три неща: данните (папката с файловете на потребителите), базата (дъмпът) и config файлът. Само файловете не стигат — без базата възстановяването е невъзможно.

Кога и как — автоматично, в 5:00 сутринта

Целият процес е един скрипт на сървъра: първо дъмпва базата, после изпраща данните + дъмпа + config-а към NAS-а. Пуска се всеки ден в 5:00 ч. сутринта — когато мрежата е празна и работният ден още не е започнал — чрез един ред в /etc/crontab, който логва резултата във файл:

0 5 * * * root /usr/local/sbin/nextcloud-backup.sh >> /var/log/nextcloud-backup.log 2>&1

Никой не го стартира ръчно и никой не може да го „забрави“. А понеже дъмпът е --single-transaction, всичко се случва без прекъсване на услугата — потребителите дори не разбират.

Достъп до данните — по всяко време, отвсякъде

Отдалеченият NAS стои в друг офис или дори в друг град, но до него трябва да има постоянен достъп, за да можеш да върнеш файл в реално време — направо на десктопа си — през интуитивния ASUSTOR File Manager (връзката с интерфейса на ASUSTOR е защитена със SSL).

Как да стигнем до него сигурно?

Най-сигурно — през WireGuard тунела (част 7). Ако двата обекта са свързани със site-to-site VPN, достъпваме NAS-а по локалния му адрес през тунела — File Manager и ADM панелът са ти под ръка, а устройството няма нито един отворен порт към Интернет.

Ако пренасочвате порт директно (както при нашата backup връзка на порт 22), задължително ограничете достъпа само до IP адреса на сървъра с firewall правило. NAS с широко отворен порт към Интернет е точно това, което ransomware кампании като Deadbolt използваха, за да ударят хиляди устройства. Правилото „допускай само познатия IP“ премахва този риск — а WireGuard подходът го премахва напълно.

Заключение

С това затваряме кръга. Изградихме многослойна защита — рутер, комутатор, сегментирана мрежа, VPN, филтриращ DNS, мониторинг, SIEM и обучен персонал — а сега и надежден, автоматичен, отдалечен архив, който изпраща само промените през шифрован канал и до който имаме достъп по всяко време.

Това е и последната линия на отбрана: когато всичко друго откаже, добрият архив е разликата между „фирмата е на крака до час“ и „изгубихме данните от последната година“. Не защото сме параноични — а защото, както видяхме, единственият архив, на който можеш да разчиташ, е този, който работи автоматично, стои надалеч и си го тествал, че наистина се възстановява.