В прошлой статье мы завершили сборку конвейера безопасной разработки: настроили GitLab CI/CD, подключили Vault для безопасной работы с секретами, добавили статический и динамический анализ, генерацию SBOM, а также интеграцию с DefectDojo, Dependency-Track и Nexus. Теперь у нас есть пайплайн, который автоматически собирает приложение, проверяет его на уязвимости и сохраняет результаты анализа. 

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

Сегодня займемся тем, о чем обычно вспоминают слишком поздно: резервным копированием. Подготовим отдельный диск для хранения бэкапов, автоматизируем создание резервных копий виртуальных машин с помощью PowerShell и настроим их регулярный запуск через планировщик Windows. В общем, избавим себя от необходимости собирать всю инфраструктуру заново в случае сбоя.

Дисклеймер

Важно сразу условиться, Путник!

Данный цикл статей не заменяет требования ГОСТ, OWASP SAMM, BSIMM и других серьезных методологий безопасной разработки. Это, скорее, практический пример того, как можно организовать конвейер безопасной разработки ПО с минимальным вложением средств. 

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

Воспринимать статью как руководство к бездумному копированию тоже не стоит. Проверяй всё на тестовых стендах, делай бэкапы и подходи к экспериментам с холодной головой.

Ошибки возможны, и не нужно бояться их совершать. Главное — делать выводы и постепенно строить процессы, которые будут надежнее вчерашних.


«Без бэкапа ты не царь, а разрухи государь», — поговаривал старый сисадмин.
Всё, что мы в прошлой статье настроили, может в одночасье рухнуть! Жесткий диск на ПК накроется, VirtualBox решит обновиться не вовремя или сам случайно не ту команду выполнишь. А если вдруг захочется перенести конвейер на более мощный сервер? Без резервных копий вся накопленная информация потеряется.

Поэтому первым делом подготовим место для хранения резервных копий. Для этого понадобится отдельный физический диск — не тот, на котором расположены виртуальные машины. Подойдет как внутренний HDD или SSD, так и внешний накопитель. Но внутренний диск обычно быстрее. Отформатируем его в NTFS и подключим так, чтобы путь к нему не менялся.

Перед настройкой резервного копирования полезно оценить необходимый объем хранилища. Для этого я посмотрел, сколько места занимают каталоги виртуальных машин и их виртуальные диски (.vdi): 

  • GitLab — 30 GB (реально занято 8);

  • Nexus — 15 GB (занято 4);

  • Vault — 20 GB (занято 2);

  • DefectDojo — 35 GB (занято 12);

  • Tools — 25 GB (занято 6).

Я взял диск на 500 GB — с запасом.

Дальше я написал для разработчиков бояр PowerShell-скрипт backup_vms.ps1, который по очереди останавливал все виртуальные машины, копировал их папки в директорию с указанием даты и чистил старые бэкапы, оставляя последние 5 экземпляров.

Этот скрипт — моя охранная грамота на случай, если виртуальный мир рухнет. 

Скрипт резервного копирования

$BackupDir = "D:\Backups\vbox_backups"
$VMsDir = "$env:USERPROFILE\VirtualBox VMs"
$VMList = @("gitlab-vm", "nexus-vm", "vault-vm", "dd-vm", "sec-vm")
$Date = Get-Date -Format "yyyy-MM-dd"
$BackupPath = Join-Path $BackupDir $Date

New-Item -ItemType Directory -Path $BackupPath -Force

function Stop-VM($vmName) {
    $running = & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" list runningvms
    if ($running -like "*`"$vmName`"*") {
        Write-Host "Останавливаю ВМ $vmName..."
        & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm $vmName acpipowerbutton
        do {
            Start-Sleep -Seconds 5
            $running = & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" list runningvms
        } while ($running -like "*`"$vmName`"*")
    } else {
        Write-Host "ВМ $vmName уже выключена."
    }
}

function Start-VM($vmName) {
    $running = & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" list runningvms
    if ($running -notlike "*`"$vmName`"*") {
        Write-Host "Запускаю ВМ $vmName..."
        & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" startvm $vmName --type headless
    }
}

foreach ($vm in $VMList) {
    Stop-VM $vm
}

foreach ($vm in $VMList) {
    $src = Join-Path $VMsDir $vm
    if (Test-Path $src) {
        Write-Host "Копирую $vm..."
        Copy-Item -Path $src -Destination $BackupPath -Recurse -Force
    } else {
        Write-Host "Папка $src не найдена, пропускаю."
    }
}

foreach ($vm in $VMList) {
    Start-VM $vm
}

$oldBackups = Get-ChildItem $BackupDir -Directory | Sort-Object Name | Select-Object -SkipLast 5
foreach ($old in $oldBackups) {
    Remove-Item -Path $old.FullName -Recurse -Force
}

Логика скрипта

Сначала задаем каталог для хранения резервных копий (в моем случае D:\Backups\vbox_backups) и путь к директории, где VirtualBox хранит виртуальные машины. Затем перечисляем виртуальные машины, которые нужно резервировать. После этого создаем новую папку бэкапа с текущей датой в имени. Так, каждая резервная копия будет храниться отдельно и не перезапишет предыдущую. 

Stop-VM — функция усыпления виртуалок. Проверяет, запущена ли ВМ (команда list runningvms). Если ВМ работает, ей отправляется сигнал завершения работы acpipowerbutton. После этого скрипт каждые пять секунд проверяет состояние ВМ и ждет полного выключения.

Функция Start-VM проверяет состояние ВМ и запускает ее в фоновом режиме (headless). Если ВМ уже работает, никаких действий не выполняется.

Усыпляем каждую из пяти виртуалок по очереди. Только когда все виртуалки будут остановлены, можно переходить к резервному копированию. Это важно, потому что копирование работающей ВМ может привести к несогласованности данных внутри виртуального диска. 

Для каждой виртуалки находим ее папку (например, C:\Users\an\VirtualBox VMs\gitlab) и копируем ее рекурсивно в папку бэкапа. -Force позволяет перезаписать файлы, если они уже существуют. В нашем случае это маловероятно, поскольку каждая резервная копия сохраняется в отдельную папку с текущей датой. Если каталог виртуальной машины не найден, скрипт выведет предупреждение и перейдет к следующей.

После завершения копирования запускаем виртуальные машины обратно, чтобы все сервисы продолжили работу.

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

Несколько нюансов, которые стоит учесть: 

  • Путь к VBoxManage.exe должен соответствовать месту установки VirtualBox.

  • Пользователь, от имени которого запускается скрипт, должен иметь права на чтение каталогов ВМ и запись в директорию резервного копирования. Если ставишь скрипт в планировщик задач — укажи, от чьего имени выполнять.

  • Чем больше виртуальные машины и медленнее диск, тем дольше будет выполняться резервное копирование.

  • Резервные копии необходимо периодически проверять. Самый простой вариант — восстановить одну из виртуальных машин из резервной копии в отдельный каталог и убедиться, что она успешно запускается в VirtualBox. 

Запуск скрипта вручную через PowerShell 

По умолчанию PowerShell ограничивает запуск пользовательских .ps1-скриптов, чтобы юзер случайно не запустил вредоносный код. Поэтому сначала разрешим выполнение локальных скриптов:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Политика RemoteSigned позволяет запускать скрипты, созданные на текущем компьютере, но сохраняет защиту для файлов, загруженных из интернета. Это золотая середина для тех, кто с осторожностью относится к запуску чужих скриптов. Свои скрипты работают, чужие — нет.  

Параметр -Scope CurrentUser применяет настройку только для текущего пользователя. Не нужно прав администратора, и не влияет на других людей, если компьютер общий. Безопасно и вежливо.

Запускаем скрипт, указывая путь к файлу:

& "C:\scripts\backup_vms.ps1"

После выполнения в каталоге резервного копирования появятся папки с бэкапами. 

Рисунок 1. Папки с файлами резервных копий
Рисунок 1. Папки с файлами резервных копий

Если позже потребуется вернуть стандартные ограничения PowerShell, можно выполнить:

Set-ExecutionPolicy Restricted -Scope CurrentUser

Или вообще сбросить:

Set-ExecutionPolicy Undefined -Scope CurrentUser

Настройка автоматического запуска через планировщик задач

Открываем планировщик задач командой taskschd.msc

Рисунок 2. Окно выполнения команд
Рисунок 2. Окно выполнения команд

В разделе «Действия» выбираем «Создать задачу».

Вкладка «Общие»: задаем имя, например, Backup VMs. Включаем опцию «Выполнить с наивысшими правами».

Рисунок 3. Создание задачи
Рисунок 3. Создание задачи

Во вкладке «Триггеры» создаем ежедневный запуск в удобное время.

Рисунок 4. Создание триггера
Рисунок 4. Создание триггера

Во вкладке «Действия» указываем: 

  • Программа: powershell.exe. 

  • Аргументы: -ExecutionPolicy Bypass -File "C:\scripts\backup_vms.ps1".

Рисунок 5. Вкладка «Действия»
Рисунок 5. Вкладка «Действия»

Сохраняем задачу. После этого резервное копирование будет выполняться автоматически по расписанию.

Рисунок 6. Активные задачи
Рисунок 6. Активные задачи

Альтернативный способ

Если не хочется настраивать политику выполнения PowerShell или нужно упростить ручной запуск скрипта, можно создать в Блокноте файл run_backup.cmd со строкой:

powershell.exe -ExecutionPolicy Bypass -File "C:\scripts\backup_vms.ps1"

Теперь этот .cmd-файл можно запускать двойным щелчком или добавить в планировщик как программу (вместо powershell.exe). Так проще, потому что не нужно возиться с политиками выполнения.

Заключение

Мы подготовили инфраструктуру для резервного копирования нашей лаборатории: выделили отдельный диск для хранения бэкапов, оценили необходимый объем хранилища и автоматизировали процесс с помощью PowerShell. Скрипт последовательно останавливает виртуальные машины, создает их копии, запускает обратно и удаляет устаревшие архивы, оставляя только несколько последних версий. 

Теперь даже отказ диска, неудачный эксперимент с настройками или случайная ошибка не должны превратить наше царство безопасной разработки в руины. Если что-то пойдет не так, у нас останется возможность быстро восстановить лабораторию из резервной копии.

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

Шесть выпусков мы возводили этот конвейер по кирпичику. Теперь пришло время узнать, готов ли он к первой настоящей битве.


PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона