Сегодня — про бэкапы в целом и Veeam в частности Кто не любит рутину — приходите через неделю… или даже через месяц Резервное копирование в компаниях часто строится по остаточному принципу. Вывели сервер из боевой среды, добили дисков — вот тебе и система хранения. Безопасность? Когда-то о ней не задумывались вовсе: получил доступ к одному серверу → посмотрел настройки NTBackup → зашёл в шару с бэкапами → извлёк реквизиты доступа к остальным системам. Сейчас про NTBackup помнят только деды. А вот отношение к бэкапам почти не изменилось: им по-прежнему отводят вспомогательную роль — в надежде, что использовать не придётся. О том, что их тоже нужно защищать, вспоминают только, когда всё уже потеряно. А ведь бэкап — это полноценная Tier-0 система 1. Хранит логины и пароли привилегированного доступа к большинству активных систем. 2. Хранит логины и пароли к системам хранения резервных копий — откуда можно извлечь и данные, и аутентификационный материал. Компрометация бэкапов — это 100% game over Именно поэтому защита системы резервного копирования — это следующий шаг после защиты антивируса. Как защитить систему резервного копирования в целом (база, которую нельзя игнорировать) 1. Системы хранения и сервер резервного копирования — в изолированном VLAN. Настолько изолированном, что запрещены входящие SYN-пакеты. Только исходящие соединения изнутри. 2. Интерфейсы управления СХД — тоже в отдельном VLAN. 3. Обязательный SMB-signing на сервере резервного копирования и хранилищах. 4. Никаких SMBv1 в бэкапной инфраструктуре — даже если «никто не дотянется» и «денег ну совсем нет». Наивно требовать от вас актуального железа в системе резервного копирования — но хотя бы уязвимости в том, что есть, не выставляйте напоказ — А что если злоумышленник дотянется до самого сервера резервного копирования? — спросит внимательный читатель. Помните предыдущий пост про сервер 1С и пароль в нём? Выдыхайте. В современных системах резервного копирования пароли в чистом виде уже никто не хранит (обычно это так). Например, в Veeam Backup & Replication они находятся в базе данных и шифруются машинным ключом системы. Однако если у злоумышленника есть права администратора — он может расшифровать их штатными средствами. Картинок «как именно» — не будет. Моя задача — вас хорошему учить 🙂 А вот про дополнительные меры защиты — это пожалуйста. Как защитить сервер резервного копирования в частности 1. Доступ по сети с учётной записью администратора — запрещён. По той самой причине, что описана выше. 2. Принудительный OTP для всех пользователей системы — встроенная функция. Чтобы даже при компрометации пароля злодей не добрался до бэкапов. 3. Автоматическое завершение неактивного сеанса в консоли — тоже встроенная функция, как и OTP (см. скриншот). 4. Система резервного копирования — не в домене. Никаких лишних служб. Парольная политика — на уровне. Всё как в Kaspersky. И помните: инфраструктура защищена ровно настолько, насколько защищены её резервные копии. Поэтому отчуждаемые резервные копии — наше всё. P.S. Если в вашей инфраструктуре используется другая система резервного копирования и в ней есть TOTP — поделитесь, плз, в комментариях.