Строим цифровой бункер: Удаленный доступ по физическому ключу и Zero-Knowledge бэкапы

В мире, где программы-вымогатели шифруют данные за секунды, а пароли утекают тысячами, стандартных методов защиты недостаточно. Сегодня мы построим систему резервного копирования "параноидального уровня".

Наша задача:

• Создать удаленный сервер (Сейф), к которому невозможно подключиться без физической флешки и кодовой фразы.
• Настроить резервное копирование виртуальных машин (AD, NGFW) и файлов пользователей.
• Реализовать архитектуру Zero Knowledge: если сервер украдут, данные на нем останутся бесполезным цифровым шумом.

Часть 1: Подготовка «Ключа от города» (USB-токен)

Мы откажемся от паролей для входа. Единственным способом попасть на сервер будет асимметричная криптография.

Инструменты:

• Любая USB-флешка (желательно качественная, например, Samsung Bar или SanDisk Extreme).
• Утилита ssh-keygen.

Шаг 1.1: Генерация ключа Ed25519

Мы будем использовать алгоритм Ed25519. Он компактнее, быстрее и безопаснее старого RSA.

Вставьте флешку в свой ПК. Откройте терминал (PowerShell или Bash) и введите:

# -t: тип ключа, -f: путь сохранения, -C: комментарий
ssh-keygen -t ed25519 -f /path/to/usb/admin_key -C "root_access_token"

Критически важно: Когда система попросит Enter passphrase, введите сложный пароль. Это защитит ключ, если флешка будет утеряна. Без пароля ключ работать не должен.

Теперь на флешке два файла:

• admin_key — Секретный ключ (Беречь как зеницу ока!).
• admin_key.pub — Открытый ключ (Его мы положим на сервер).

Часть 2: Харденинг Сервера (The Vault)

В качестве ОС используем либо готовый образ Proxmox Backup Server (Bare-metal ISO), либо чистый Debian 12, поверх которого накатываем пакеты PBS. Использовать Ubuntu или CentOS нельзя из-за несовместимости ядра и файловой системы ZFS.

Шаг 2.1: Настройка SSH

Наша цель — запретить любой вход, кроме как по ключу.

• Скопируйте содержимое admin_key.pub с флешки.

• На сервере добавьте его в авторизованные ключи:

  mkdir -p ~/.ssh
  nano ~/.ssh/authorized_keys
  # Вставьте скопированную строку. Сохраните.
  chmod 600 ~/.ssh/authorized_keys

• Редактируем конфиг SSH демона:

  sudo nano /etc/ssh/sshd_config

• Приводим параметры к такому виду:

  Port 2222                  # Сменим порт (защита от сканеров-скриптов)
  PubkeyAuthentication yes   # Разрешаем ключи
  PasswordAuthentication no  # ЗАПРЕЩАЕМ пароли
  PermitRootLogin no         # Запрещаем рута (входим юзером, потом sudo)
  PermitEmptyPasswords no    # Запрещаем пустые пароли
  AuthenticationMethods publickey # Строго требуем ключ

• Перезагружаем службу: sudo systemctl restart ssh.

Теперь, чтобы войти на сервер, вы должны вставить флешку в свой ПК и ввести команду:

ssh -i /path/to/usb/admin_key -p 2222 user@backup-server-ip

Без флешки сервер просто сбросит соединение.

Часть 3: Бэкап Инфраструктуры (Proxmox, AD, NGFW)

Для бэкапа виртуалок (Windows Server 2022 с AD и Ideco NGFW) используем Proxmox Backup Server (PBS).

Почему PBS?
Он поддерживает дедупликацию (экономит место) и, что важнее, Client-Side Encryption. Сервер получает данные уже зашифрованными.

Шаг 3.1: Настройка шифрования

• Установите PBS на сервер: apt install proxmox-backup-server.
• В веб-интерфейсе PBS (порт 8007) создайте Datastore.
• Перейдите в ваш основной Proxmox VE -> Datacenter -> Storage -> Add -> Proxmox Backup Server.
• Самый важный момент: Перейдите на вкладку Encryption созданного хранилища в PVE и нажмите Add Key.

• Скачайте созданный ключ (.key файл).

   

• Действие: Скопируйте этот файл на вашу секретную флешку. Удалите его с рабочего стола.

Теперь, когда Proxmox делает бэкап AD или Ideco, он шифрует их этим ключом до отправки по сети. Даже если злоумышленник физически украдет диск из бэкап-сервера, он не сможет восстановить контроллер домена без ключа с вашей флешки.

Часть 4: Бэкап данных пользователей (Windows + Restic)

Для файлов (документы, базы 1С и т.д.) используем Restic. Это open-source утилита, которая шифрует всё по умолчанию.

Шаг 4.1: Подготовка на сервере

Создадим изолированного пользователя, который может только пользоваться SFTP (без доступа к консоли).

sudo adduser backup-win
sudo mkdir -p /backups/windows
sudo chown backup-win:backup-win /backups/windows

В sshd_config добавим ограничение (Jail):

Match User backup-win
    ChrootDirectory /backups
    ForceCommand internal-sftp
    AllowTcpForwarding no

Шаг 4.2: Скрипт для Windows клиентов

На клиентской машине скачиваем restic.exe. Создаем скрипт backup_daily.ps1:

# Файл с паролем шифрования (защитить правами доступа NTFS!)
$Env:RESTIC_PASSWORD_FILE = "C:\ProgramData\Scripts\secret.pwd"

# Репозиторий на нашем сервере
$Repo = "sftp:backup-win@192.168.1.X:/windows/pc_buchgalter"

# Инициализация (запустить один раз вручную)
# restic -r $Repo init

# Бэкап
restic.exe -r $Repo backup "C:\Users\Accountant\Documents" --host "BUCHGALTER-PC"

# Очистка старых копий (оставляем последние 60 дней)
restic.exe -r $Repo forget --keep-daily 60 --prune

Пароль, который лежит в secret.pwd (и копию которого вы храните на флешке), используется для шифрования данных AES-256. Сервер видит только зашифрованные блоки.

Анализ уязвимостей и модель угроз

Как профессионалы, мы должны знать слабые места нашей системы.

Уязвимость 1: Физическая кража флешки

• Сценарий: Вы потеряли флешку, её нашел хакер.
• Защита: Мы установили passphrase на SSH-ключ (Шаг 1.1). Без пароля ключ бесполезен.
• Усиление: Создайте на флешке зашифрованный раздел (VeraCrypt или BitLocker) и храните файлы ключей (admin_key, proxmox.key, restic.pwd) внутри него. Тогда для доступа нужно будет сначала смонтировать том, а потом ввести пароль ключа.

Уязвимость 2: Компрометация ПК администратора

• Сценарий: На вашем рабочем компьютере троян, он перехватывает ввод пароля, когда вы вставляете флешку.
• Защита: Флешка не защищает от зараженного эндпоинта.
• Решение: Используйте выделенный "чистый" ноутбук или LiveUSB Linux для администрирования. Либо переходите на аппаратные ключи YubiKey (FIDO2), которые невозможно скопировать.

Уязвимость 3: Уничтожение данных на сервере

• Сценарий: Хакер получил доступ к серверу (например, через уязвимость 0-day в SSH) и просто удалил все файлы командой rm -rf.
• Защита:
  • Immutable attributes: Настроить файловую систему ZFS на сервере с периодическими снапшотами, доступными только root.
  • Off-site копия: Данная схема защищает от доступа, но не от пожара. Нужна репликация зашифрованных данных в облако (тот же Restic умеет лить в S3).

Уязвимость 4: Бэкап зараженных файлов

• Сценарий: Вирус-шифровальщик зашифровал файлы пользователя, Restic сбэкапил уже зашифрованные файлы.
• Защита: Версионность Restic и Proxmox. Мы храним историю за 60 дней. Если сегодня файлы зашифровали, мы просто восстановим состояние "вчера".

Заключение

Мы реализовали систему резервного копирования уровня Enterprise:

• Доступ: Строго двухфакторный (Физический токен + Знание пароля).
• Конфиденциальность: Полное шифрование на стороне клиента. Владелец сервера не может прочитать данные.
• Надежность: Proxmox для VM и Restic для файлов обеспечивают целостность и дедупликацию.

Это решение идеально подходит для малого бизнеса и приватных данных, где паранойя — это не болезнь, а профессиональная необходимость.