Привет, Хабр!
На связи Игорь Шконда, руководитель направления систем резервного копирования в «Инфосистемы Джет».
Когда все идет не по плану, у вас остается только резервная копия. Ни отказоустойчивые кластеры, ни репликация, ни привычное дублирование уже не спасают. В этот момент возникает простой и довольно неприятный вопрос: получится ли вообще восстановиться?
За последние годы атаки заметно изменились. Если раньше шифровальщики ограничивались отдельными серверами или рабочими станциями, то теперь они целенаправленно идут к системе резервного копирования. Изучают, где она находится, как управляется, какие учетные записи используются и можно ли теми же правами удалить бэкапы.
Если это удается — атака уже выиграна, даже если остальная инфраструктура формально еще работает. В этот момент становится очевидно: сам факт наличия резервных копий ничего не гарантирует.
Поэтому сегодня приходится защищать не только данные, но и саму систему резервного копирования. Этот подход называется харденингом СРК. По сути, мы исходим из того, что часть инфраструктуры рано или поздно будет скомпрометирована, и задача СРК — пережить этот момент и сохранить возможность восстановления.
Ниже разберем, как к этому подходят на практике — на примере «Кибер Бэкапа» и реальных сценариев из инфраструктур заказчиков.
Почему обычные бэкапы больше не спасают. И что приходит им на смену
Типичная атака на инфраструктуру сегодня развивается достаточно предсказуемо:
компрометируется какая-нибудь рабочая станция;
злоумышленник получает доступ к домену и административным учетным записям;
начинается поиск СРК;
проверяется, можно ли удалить резервные копии или изменить политики хранения;
если это удается, РК удаляются;
запускается шифровальщик;
компания остается без данных и без возможности восстановиться.
Обычная схема, когда система резервного копирования живет в той же инфраструктуре и управляется теми же учетными записями, безнадежно устарела. Поэтому архитектуру резервного копирования строят так, чтобы система не зависела полностью от основной инфраструктуры. Это база, матчасть, истина в последней инстанции, которую не стыдно повторить еще раз.
Даже если домен или административные учетные записи скомпрометированы, резервные копии все равно нельзя просто удалить.
На практике это: минимальные привилегии для сервисов и администраторов, изоляция системы резервного копирования от основной инфраструктуры и использование неизменяемых хранилищ.
Поэтому есть основной контур резервного копирования, который живет вместе с основной инфраструктурой. А есть второй, максимально изолированный сегмент. Его мы для себя называем «Бункером». Это самостоятельный сегмент, который максимально отделен от основной среды: со своими учетными записями, ключами доступа и хранилищами. Его задача простая — сохранить резервные копии и обеспечить возможность восстановления даже в ситуации, когда основная инфраструктура уже скомпрометирована.
Как это выглядит в реальной СРК
Переходим к практике. Например, в «Кибер Бэкапе» используется фиксированная ролевая модель. Есть несколько предустановленных ролей, включая отдельную роль для спецов по информационной безопасности. С точки зрения аудита это удобно. Понятно, кто именно может управлять заданиями резервного копирования, а кто имеет доступ только к просмотру. Но гибкость при этом ограничена. Роли нельзя произвольно конструировать, поэтому в сложных организациях иногда приходится подстраивать процессы под существующую модель доступа. С точки зрения безопасности это ближе к принципу минимальных привилегий: каждая роль имеет фиксированный набор действий.
Система умеет работать как с локальными учетными записями, так и с внешними каталогами вроде Active Directory, FreeIPA или SambaDC. Это упрощает администрирование, но одновременно делает безопасность СРК сильно зависимой от состояния домена. Если домен скомпрометирован, атакующий рано или поздно попытается добраться и до системы резервного копирования.
Отдельная история — это Linux-инсталляции. При установке сервера управления учетная запись root автоматически добавляется как администратор организации и используется для первого входа. После настройки ее можно убрать из списка администраторов и отключить в интерфейсе, но полностью отказаться от нее нельзя. Агент РК работает именно из-под root. Это означает довольно простую вещь — компрометация ОС автоматически становится компрометацией всей СРК. Поэтому харденинг самой операционной системы здесь критичен.
При этом в архитектуре СРК есть не только управляющий сервер и агенты. Например, используются агенты резервного копирования уровня гипервизора для систем виртуализации, которые представляют собой «апплаенсы» — готовые виртуальные машины с собственными веб-интерфейсами и сервисами управления. У таких компонентов тоже есть собственные веб-интерфейсы и сервисы управления, поэтому их лучше сразу закрывать за аутентификацией и ограничивать доступ на уровне сети.
Шифрование резервных копий реализовано довольно прямолинейно. Используется AES с ключами различной длины, а включить шифрование можно либо в параметрах задания резервного копирования, либо на уровне защищаемого хоста через CLI. Второй вариант обычно удобнее, если заданий много. При этом ключи не хранятся ни в системе, ни в самих резервных копиях. С точки зрения безопасности — это плюс, но в части эксплуатации создает жесткое требование. Потеря ключа означает невозможность восстановления данных.
Сетевое взаимодействие между компонентами системы тоже требует внимания. Управляющий сервер, узлы хранения и агенты используют довольно большой набор сервисов, которым нужны сетевые порты. Документация обычно содержит полный список портов, но это не означает, что их нужно открывать все подряд. На практике открывают только те соединения, которые действительно используются, а саму систему резервного копирования стараются держать в отдельном сегменте сети. Обычно это реализуется через отдельный VLAN или сегмент с ограниченными правилами межсетевого экрана.
Доступ к консоли управления по небезопасному HTTP
В идеале список необходимых портов определяют еще на этапе внедрения. Тогда администратор или интегратор могут открыть только реально используемые сервисы, а всё остальное оставить закрытым.
Создание РК само по себе еще ничего не гарантирует. Бэкап может быть успешно создан, но при попытке восстановления внезапно выяснится, что данные повреждены или цепочка резервный копий сломана. Поэтому важная часть любой СРК — проверка резервных копий.
В «Кибер Бэкапе» для этого используется механизм валидации через контрольные суммы. Проверяются не только блоки данных, физически лежащие в резервной копии, но и те, которые будут восстановлены при выборе конкретной точки. Процедура довольно тяжелая и быстро начинает упираться в ресурсы, поэтому обычно ее выносят в отдельные планы проверки. В некоторых системах такие задачи даже называют отдельным типом задания — CRC-check.
Для виртуальных машин есть более наглядный сценарий. ВМ можно запустить прямо из резервной копии и проверить, загрузилась ли система. Проверка выполняется через VMware Tools или Hyper-V Heartbeat. По сути, если система стартует и отвечает агенту, значит, резервная копия, скорее всего, пригодна для восстановления.
В некоторых системах резервного копирования есть дополнительные механизмы защиты от шифровальщиков. Например, в «Кибер Бэкапе» используется модуль Active Protection. Он работает на уровне агента и в фоновом режиме отслеживает аномальную активность в файловой системе, например, массовое шифрование файлов или нетипичную нагрузку на диск.
После активации агент может автоматически остановить подозрительный процесс, заблокировать подключение или попытаться восстановить поврежденные файлы. На практике такие механизмы не заменяют нормальную архитектуру защиты, но могут выиграть время, если атака уже началась.
Почему неизменяемые хранилища стали стандартом
Еще одна важная вещь, которая активно появляется в современных СРК, — неизменяемые резервные копии. Для этого используют WORM-хранилища или Object Lock, чтобы защитить бэкапы от удаления. В связке «Кибер Бэкапа» и «Кибер Инфраструктуры» это реализуется через объектное хранилище S3.
При создании бакета можно задать режим хранения и срок, в течение которого данные нельзя изменять. В одном режиме параметры еще можно скорректировать учетной записью с особыми правами. В другом режиме изменить их невозможно в принципе. Резервные копии остаются неизменными до истечения срока хранения.
Это усложняет жизнь атакующему. Даже при административном доступе к СРК удалить такие данные уже невозможно на уровне хранилища. Правда, у схемы есть и обратная сторона. Ошибка в настройке срока хранения иногда обнаруживается только спустя месяцы. Поэтому такие параметры обычно согласовывают заранее, изменить их задним числом бывает уже нельзя.
Подключение хранилищ: iSCSI и NFS
Если устройства хранения подключаются к узлу хранения по протоколу iSCSI, вопрос аутентификации становится принципиальным. Минимальный базовый уровень — использование CHAP-аутентификации. Односторонний CHAP, при котором инициатор аутентифицируется на стороне таргета, уже снижает риск несанкционированных подключений. Двусторонний CHAP дополнительно защищает от подмены сторон, так как сервер и клиент взаимно проверяют друг друга. Дополнительным уровнем защиты может служить шифрование канала с использованием IPsec.
# На сервере и клиенте
ikev2-setup --server --target=192.168.1.100 --initiator=192.168.1.101 --psk=SharedSecretKey
Если устройства хранения подключаются к узлу хранения с использованием протокола NFS, то рекомендуем использовать последние версии протокола — NFSv4+. NFSv3 не поддерживает Kerberos и уязвим к спуфингу.
# В /etc/nfs.conf
[nfsd]
vers2=no
vers3=no
# В /etc/exports
/data 192.168.1.0/24 (rw,all_squash,anonuid=65534,anongid=65534)
all_squash — все пользователи становятся nobody
anonuid/anongid — можно задать конкретного несуществующего пользователя
# Логирование NFS-запросов
auditctl -a always,exit -F arch=b64 -S open -S read -S write -F path=/data
Аудит действий
Еще один полезный механизм — аудит операций внутри СРК. В «Кибер Бэкапе» есть журнал аудита, в который попадают ключевые события: запуск заданий, удаление резервных копий, изменения конфигурации и другие административные действия. Эти события можно отправлять во внешние системы мониторинга или SIEM через syslog или CEF. Сам журнал проблему, конечно, не решает. Но без него расследование инцидентов обычно превращается в догадки.
Что становится понятно на этапе эксплуатации
Харденинг СРК — это не столько про настройки, сколько про архитектуру и процессы. Тут важны простые на первый взгляд вещи. Например, изолированный контур для административного доступа или многофакторная аутентификация, которая не зависит от основной инфраструктуры. В некоторых случаях используют даже своеобразные «приманки» — тестовые экземпляры управляющих систем, которые выглядят как настоящие и позволяют раньше заметить попытку вторжения. Но довольно быстро приходит понимание, что никакой одной волшебной настройки здесь не существует.
Сегментация сети, минимальные привилегии, шифрование и неизменяемые хранилища действительно повышают устойчивость системы. Но в конечном итоге все упирается в процессы. Регулярные проверки резервных копий, тестовые восстановления и архитектурные решения, которые позволяют пережить момент, когда всё остальное уже перестало работать. Потому что именно в этот момент резервная копия действительно становится последним «выжившим».
Средства харденинга СРК — необходимый базовый минимум защиты от угроз шифровальщиков. Но максимально гарантировать восстановление данных в случае полного уничтожения продуктивной среды может только полностью изолированный контур СРК — «Бункер».