Одной из наиболее опасных угроз для корпоративных данных являются вирусы-шифровальщики (ransomware). Они проникают в систему, зашифровывают все доступные файлы (включая базы данных 1С, архивы и документы) и требуют выкуп за ключ дешифрации. Традиционное резервное копирование в облако с использованием стандартных программ синхронизации (таких как Яндекс.Диск, Google Drive или Dropbox в режиме реального времени) не защищает данные. Как только локальный файл на сервере зашифровывается, клиент синхронизации автоматически отправляет «испорченную» копию в облако, перезаписывая здоровый бэкап.
В этой статье мы подробно разберем, как организовать надежный процесс отправки резервных копий в облачные хранилища, исключив постоянный доступ операционной системы к облаку. Мы рассмотрим как проверенные временем классические сценарии, так и современные профессиональные стандарты защиты данных.
Когда на сервере постоянно запущено официальное приложение облачного диска, оно создает в системе виртуальную папку или постоянно мониторит локальный каталог. Любые изменения в этой папке мгновенно дублируются на удаленный сервер. Если вирус-шифровальщик получает доступ к системе, он шифрует локальные файлы, а клиент синхронизации послушно отправляет зашифрованные версии в облако. В результате администратор теряет и локальный бэкап, и облачный.
Наша цель — сделать так, чтобы процесс бэкапа имел доступ к облаку только в момент отправки файла, а в остальное время хранилище было полностью изолировано от операционной системы.
---
Рассмотрим классический и полностью бесплатный способ изоляции облака с помощью пакетного сценария (батника). Суть метода заключается в том, что диск подключается по протоколу WebDAV только на время копирования архива и сразу же отключается после завершения операции.
Разберем по шагам создание такого скрипта:
.bat или .cmd.Посмотрим на пример практической реализации такого сценария:
@echo off
chcp 65001 > nul
:: Настройка путей и учетных данных
set CLOUD_URL=\\webdav.yandex.ru@SSL\backup
set CLOUD_USER=your_login
set CLOUD_PASS=your_password
set LOCAL_FILE=C:\Backup\1c_base.7z
set DRIVE_LETTER=Y:
echo Подключение облачного хранилища...
net use %DRIVE_LETTER% %CLOUD_URL% /USER:%CLOUD_USER% %CLOUD_PASS%
if %errorlevel% neq 0 (
echo Ошибка подключения к WebDAV! Бэкап не выполнен.
exit /b 1
)
echo Копирование файла резервной копии...
copy "%LOCAL_FILE%" "%DRIVE_LETTER%\" /Y
set copy_res=%errorlevel%
echo Отключение сетевого диска...
net use %DRIVE_LETTER% /delete /yes
if %copy_res% equ 0 (
echo Резервное копирование успешно завершено!
) else (
echo Произошла ошибка при копировании файла!
)
Преимущества метода: Простота реализации, отсутствие необходимости устанавливать сторонний тяжелый софт синхронизации. В остальное время диск Y: не существует в системе, и вирус-шифровальщик не может до него добраться.
---
Для тех, кто хочет иметь полноценный мониторинг, логирование и отправку уведомлений на почту в случае сбоев, отличным решением станет использование бесплатной программы Cobian Backup (или аналогичного современного софта) в связке с нашими скриптами.
Выясним, как настроить эту схему работы:
Y:\).net use Y: /delete /yes).---
Проанализируем ситуацию, когда нам все-таки необходимо использовать стандартный клиент синхронизации (например, Яндекс.Диск), но мы хотим обезопасить его папку от вредоносного ПО, запущенного под текущим пользователем или администратором.
Для этого можно использовать механизм разграничения прав доступа ОС Windows:
BackupUser) и задаем ему сложный пароль.BackupUser.C:\YandexDisk) полностью удаляем права на запись и чтение для всех обычных пользователей и администраторов, оставив полные права только для BackupUser и системы.BackupUser.При такой схеме вирус-шифровальщик, запустившись под правами обычного пользователя или даже локального администратора, получит ошибку "Доступ ограничен" при попытке зашифровать файлы в папке облака, так как у него не будет прав на доступ к этой директории.
---
Многие популярные облачные провайдеры предлагают встроенную защиту от потери данных в виде истории версий файлов. Например, в Dropbox (базовая бесплатная опция до 30 дней) или в Яндекс.Диске (при наличии платной подписки) сохраняются предыдущие версии измененных файлов.
Если шифровальщик зашифровал файлы, и они успели синхронизироваться в облако, вам не нужно паниковать. Достаточно выполнить следующие действия:
Это самый простой "пассивный" способ защиты, не требующий написания сложных скриптов, однако он требует контроля за дисковым пространством и своевременного обнаружения атаки (до истечения срока хранения версий в облаке).
---
Если у вас есть возможность арендовать недорогой виртуальный сервер (VDS) или использовать удаленный ПК со статическим IP-адресом, можно развернуть собственный FTP/SFTP-сервер (например, на базе FileZilla Server или IIS).
Главная фишка этого подхода — тонкая настройка прав пользователя на стороне сервера:
STOR / Write).DELE / Delete), переименования (RNFR/RNTO / Rename) и перезаписи существующих файлов.В этом случае скрипт на сервере 1С отправляет новый архив с уникальным именем (например, содержащим дату и время: backup_2023_10_27.7z). Если сервер будет атакован шифровальщиком, вирус не сможет стереть ранее отправленные бэкапы или перезаписать их зашифрованными копиями — сервер FTP просто отвергнет эти команды из-за отсутствия прав.
---
В современной практике системного администрирования стандартом де-факто для работы с облаками без установки лишнего ПО стала консольная утилита Rclone. Это бесплатный инструмент с открытым исходным кодом, который работает с десятками облачных провайдеров (включая Яндекс.Диск, Google Drive, Mail.ru, а также профессиональные S3-хранилища) напрямую через API.
Рассмотрим, почему Rclone идеально решает задачу автора темы:
Разберем пример простой команды для отправки бэкапа через Rclone:
:: Отправка файла на предварительно настроенное облако "yandex" в папку "backups"
rclone copy "C:\Backup\1c_base.7z" yandex:backups --log-file="C:\Backup\rclone.log" --log-level INFO
Настройка подключения в Rclone выполняется один раз через интерактивное меню rclone config, где вы авторизуетесь в облаке по протоколу OAuth. Пароли и токены хранятся в зашифрованном конфигурационном файле, доступ к которому также можно ограничить правами ОС.
---
Для построения отказоустойчивой системы резервного копирования в облако рекомендуем придерживаться комплексного подхода:
Rclone.backup_%date%.7z). Никогда не перезаписывайте один и тот же файл backup.7z.