Журнал "Information Security/ Информационная безопасность" #1, 2026

40 • СПЕЦПРОЕКТ Сначала сделали то, что делают почти всегда, – аккуратно сегментировали сеть. Выделили подсети, использовали VLAN, развели трафик. Управление отдельно, потоки данных отдельно. Это выглядело как стандартная практика: меньше связности, меньше шансов слу- чайного доступа, проще контролировать, кто куда ходит. На этом этапе все выгля- дело вполне традиционно. Дальше перешли к хранению. Разгра- ничение доступа реализовали на уровне СХД. Каждый пул данных закрепили за конкретным ресурсом хранения. То есть это уже не общее хранилище бэкапов, куда все пишут и откуда все читают. У каждого сегмента – свой пул, свои права, свой набор операций: чтение, запись, администрирование. Многополь- зовательская модель сохранилась, но внутри четких границ. Можно работать совместно, но не выходя за пределы свое- го домена. И вот тут проект начал менять харак- тер. Потому что главный вопрос оказался не в VLAN и не в пулах хранения. Глав- ный вопрос – управление. Было принято решение изолировать систему резервного копирования в каж- дом контуре безопасности. Не логически изолировать в рамках одной большой системы, а физически и организационно разнести инсталляции. Каждая СРК работает автономно, со своими ресур- сами хранения, своим питанием, своими сетевыми подключениями. Причем изо- ляция – не только в настройках, но и на уровне железа. По сути, вместо одной централизо- ванной платформы резервного копиро- вания получился набор самостоятельных доменов восстановления. И здесь начинается самое интересное. ЦОД по своей логике тяготеет к центра- лизации. Один контур управления, общие роли администраторов, единая система управления. Это удобно, это снижает издержки, делает эксплуатацию пред- сказуемой. Но ровно эта же централиза- ция создает точку системного риска. Если СРК управляется теми же учет- ками и теми же ролями, что и гиперви- зоры или доменная инфраструктура, то при компрометации контура управления бэкапы падают вместе со всем осталь- ным. Именно так сегодня работают мно- гие атаки шифровальщиков: сначала злоумышленники получают контроль над управлением, потом отключают или уда- ляют резервные копии, и только затем шифруют продуктивные данные. Фор- мально бэкапы есть, но фактически доступа к ним может уже не быть. В выбранной модели мы попытались разорвать эту связку. Если один контур скомпрометирован, это не означает авто- матическую потерю всех резервных дан- ных. Но за автономию приходится платить усложнением администрирования. Требо- вания к регламентам и передаче полномо- чий становятся жестче. Нельзя опираться на мантру "общий домен все спасет". Дальше пошла инженерная классика: отказоустойчивость, масштабирование, производительность. Серверы СРК мы объединили в кластеры, чтобы распре- делять нагрузку и переживать (в хоро- шем смысле) отказ отдельных узлов. Объемы хранения рассчитывали заранее – количественный рост данных, хватит ли емкости, когда потребуется расши- рение. Производительность оценивали не только по скорости создания копий, но и по скорости восстановления. Потому что в ЦОДе важен не сам факт наличия бэкапа, а время возврата сервиса. Но в распределенной архитектуре даже эти привычные параметры начинают играть по-другому. Кластер внутри одного контура не спасет, если потерян контроль над управлением. Большой объем хра- нилища ничего не стоит, если права доступа оказались скомпрометированы. В какой-то момент становится понятно, что мы защищаем не просто данные, а саму возможность ими управлять. Отдельная сложность – люди. Чем больше имеется автономных инсталля- ций, тем выше зависимость от конкрет- ных администраторов. Увольнение, отпуск, ротация – и внезапно выясняется, что доступы и процедуры должны быть продуманы гораздо жестче, чем в цент- рализованной модели. Добавьте к этому гетерогенную инфраструктуру: разные операционные системы, разные особен- ности резервного копирования, разные требования к настройке. Универсального одного окна тут не получается. И наконец, импортозамещение. Рынок пока не всегда предлагает решения, которые полностью закрывают требова- ния без доработок. В результате СРК превращается в инженерный проект с элементами кастомизации. Каждая дора- ботка – это новая зависимость от коман- ды и ее компетенций. В распределенной архитектуре такие зависимости множат- ся по контурам. В итоге проект, который начинался как внедрение системы резервного копи- рования в ЦОД, привел к пересмотру базового принципа. Централизация удоб- на, но в какой-то момент она начинает работать против устойчивости. Разделяя СРК на автономные домены, команда фактически пошла против естественной логики унификации. И здесь возникает главный вопрос. Что для нас важнее – эксплуатационная простота или архитектурная живучесть? В зрелом ЦОД резервное копирование уже не может быть просто сервисом поддержки. Оно становится отдельным, самостоятельным элементом инфра- структуры, который должен жить по своим правилам и не зависеть от общей схемы управления. И его ценность опре- деляется не только объемом дисков и количеством узлов в кластере, а степе- нью независимости от общей плоскости управления. l Централизация ЦОД и автономность систем резервного копирования сли убрать все красивые формулировки, проект начинался довольно приземленно. Нужно было развернуть систему резервного копирования в инфраструктуре ЦОД так, чтобы она выдерживала рост данных, не падала при отказах и нор- мально администрировалась. В принципе, обычная инженер- ная задача. Но по мере проработки стало понятно, что вопрос не в том, как поставить СРК, а в том, как встроить ее в существующую инфраструктуру так, чтобы она не унаследо- вала все ее риски. Е Альберт Богданов, менеджер продукта RuBackup (входит в “Группу Астра”) Ваше мнение и вопросы присылайте по адресу is@groteck.ru Фото: "Группа Астра"