Короткий ответ
Учётки backup — отдельные субъекты: contoso\svc-veeam для службы VBR01, contoso\svc-veeam-guest для guest processing, contoso\svc-restore для аварийного SMB, Linux veeam на hardened, PBS backup@pbs. Ни одна из них не член Domain Admins. Пароли/ключи — в vault (не в заявке, не в C:\pass.txt). Ротация без сюрприза: обновили vault и Log On службы и Credentials в Veeam.
Это фундамент изоляции от ransomware и защиты от удаления.
Симптомы и как отличить
Типичная картина:
Get-WmiObject Win32_Service→ StartNameCONTOSO\Administrator;- в Veeam Credentials — персональный логин админа;
- PBS API token в письме;
- WSB задача от имени пользователя, который уволился.
Отличия: репозиторий недоступен часто следствие смены пароля DA, под которым бежала служба. Лечите модель учёток, не только шару.
Возможные причины
- «Временный» DA на год.
- Guest processing требовал админа гостя — дали DA на весь лес.
- Нет vault, пароль в документации на файловике, который бэкапится той же учёткой.
- Один токен PBS на всех админов.
- Hardened repo с root SSH password=доменный.
- Restore ночью только под DA, отдельную роль не создали.
- Облачный ключ с Full Access «чтобы Object Lock не мешал».
- Редкий: оркестратор с DA для «всех API».
Диагностика
1. Кто бежит на VBR01
Get-WmiObject Win32_Service | Where-Object { $_.Name -like 'Veeam*' } |
Select-Object Name, StartName, StateЛюбой Domain Admins / персональный админ — к замене.
2. Credentials в Veeam
GUI: Credentials. Список: для гипервизора, для guest, для SMB Repo01, для Linux repo. Персональные ФИО — провал.
3. ACL Repo01
Get-SmbShareAccess -Name 'Repo01'Не должно быть Everyone, Authenticated Users Full, Domain Admins как единственный рабочий write (DA всё равно могут забрать хост, если он в домене — поэтому изоляция хоста).
4. PBS / Linux
Пользователи PBS, API tokens, sudoers, authorized_keys. Общий root password = общий ключ от копий.
5. Где секрет лежит
Найдите файлы *pass*, документы на шаре ИТ, тикеты с паролем. Перевыпустите всё найденное.
После смены пароля svc-veeam проверьте три места: AD/vault, Log On службы на VBR01, Credentials репозитория и guest в консоли. Забыли одно — ночью Daily-VMs красный с Access denied, и смена включает DA «на час». Заложите чеклист ротации в календарь, не в память.
Не кладите SSH-ключ hardened repo в профиль того же человека, что держит DA: компрометация ноутбука открывает оба мира. Ключ на jump backup-зоны, passphrase в другом сейфе.
Решение
Модель ролей (минимум)
| Роль | Кто | Для чего | Не для чего |
|---|---|---|---|
| svc-veeam | служба VBR | SQL конфиг, API | интерактив, DA |
| svc-veeam-repo | SMB/Linux repo | запись цепочки | вход на DC |
| svc-veeam-guest | локальный админ гостей job | VSS | весь домен |
| svc-restore | break-glass restore SMB | авария | ежедневный RDP |
| оператор | человек + роль Veeam Restore | консоль | пароль службы |
| PBS backup@pbs | токен DatastoreBackup | backup | Datastore.Allocate как root |
Человек-админ входит своей учёткой с MFA в консоль, не знает пароль службы.
Сценарий A. Убрать DA со службы
- Создать
svc-veeam(или gMSA). - Права: локальный админ только
VBR01(часто нужно для Veeam), права на SQL Veeam, не DA. - Сменить Log On, перезапустить службы в окно.
- Проверить
Daily-VMsSuccess и FLR.
Откат: вернуть прежнюю учётку из vault, не «снова DA».
Сценарий B. Guest
Группа g-veeam-guest-admins → локальные админы VM в job (GPO restricted groups точечно или LAPS+группа). Учётка svc-veeam-guest только там. Не DA.
Сценарий C. Repo SMB
NTFS+share: Modify для svc-veeam-repo. Credentials репозитория в Veeam = эта учётка. Пароль в vault, ротация с runbook (порядок: новый пароль → Veeam → служба если та же).
Сценарий D. PBS
Отдельный пользователь, токен с ограниченным privilege, срок, хранение в vault. Запрет использовать root@pam с рабочих ПК для cron backup.
Сценарий E. Break-glass
svc-restore в конверте/vault с dual control. Проверка раз в квартал, что вход на share из WinRE возможен. После проверки — ротация.
Сценарий F. WSB
Учётка задачи Scheduled Task — не уволенный сотрудник. Права на Repo01. Документ.
Не храните пароли в описании job Daily-VMs.
Как проверить, что проблема устранена
- Ни одна Veeam-служба не StartName DA / персональный админ.
Daily-VMsSuccess после смены.- Guest processing Success на пробной VM.
- Vault содержит все секреты, поиск по шаре ИТ пуст.
- Оператор restore без знания пароля службы сделал FLR.
Get-WmiObject Win32_Service | Where-Object { $_.Name -like 'Veeam*' } | Select-Object Name, StartNameЕсли не помогло
- Job fail Access denied после ухода с DA — не хватило прав на гипервизор: выдайте роль на vCenter/Hyper-V по матрице Veeam 12, не DA домена.
- gMSA не стартует — SPN/хост в домене; временно user-svc, не DA.
- PBS 403 — privilege, не «дать root».
Не отключайте MFA на человеческих входах, потому что службе MFA не нужна: службе MFA и не ставят.
Ротация: не меняйте пароль svc-veeam-repo в пятницу без окна — понедельник начнётся с Unavailable Repo01. Чеклист трёх мест (AD, Log On, Veeam Credentials) положите в тикет ротации. Guest-учётку не используйте для RDP на VBR01 и наоборот: смешение ролей возвращает blast radius DA, только под другим именем.
PBS-токены с бесконечным TTL — как пароль на стикере. Срок и перевыпуск по календарю.
Профилактика
- Рецензия Credentials раз в квартал.
- Алерт на членство DA для
svc-*. - Offboarding: персональные учётки из Veeam в день увольнения.
- Запрет в регламенте: DA на backup-службах.
FAQ
Нужен ли отдельный лес для учёток?
Идеал для крупного. Для SME достаточно не-DA + hardened вне досягаемости DA. Не блокируйте простые шаги ожиданием леса.
Можно ли одну svc на всё?
Хуже blast radius. Минимум отделить guest от repo.
Пароль в менеджере компании, куда входят все ИТ
Слишком широко. Отдельный vault/folder backup с ACL.
Локальная учётка на VBR01 вместо доменной?
Да, если VBR не в домене. Тогда изоляция ещё лучше, но гипервизор-учётки всё равно нужны.
Токен PBS в переменной systemd
Файл с правами 600, не world-readable. Ротация.
Документировать пароль в runbook восстановления?
Ссылку на vault и процедуру break-glass, не сам пароль в wiki.