Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?
© It-world

Компании давно осознали, что потеря данных может стать фатальной. Однако понимание необходимости защиты и готовность за нее платить далеко не одно и то же. Дискуссия, организованная изданием IT-World, началась с попытки разобраться, так ли критична ситуация с бюджетами на самом деле и действительно ли бизнес экономит на системах резервного копирования (СРК), которые еще недавно считались базовой необходимостью.

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?. Рис. 1
Пока не грянул гром, или Профилактика системы резервного копирования Как регулярные проверки, тестовые восстановления, аудит и защита резервных копий помогают избежать ситуации, когда резервные данные есть, а восстановиться из них невозможно

Большинство участников сошлось во мнении, что тренд на экономию очевиден и носит системный характер. Многие компании, годами использовавшие западные решения, долгое время просто откладывали переход на отечественные продукты, предпочитая не тратить ресурсы на столь сложный процесс. Теперь же, когда бюджеты ужаты, а острая фаза импортозамещения, казалось бы, пройдена, эти два фактора наложились друг на друга.

Рынок СКР в режиме экономии

Основной этап импортозамещения в этом сегменте завершен, и сегодня рынок живет либо пересмотром решений в пользу других отечественных продуктов, либо точечным расширением уже существующих внедрений. Причем объем новых закупок заметно сократился. «Денег стало значительно меньше», — прозвучал практически единодушный вердикт. Впрочем, не все участники были столь категоричны.

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?. Рис. 2
Владислав ЛЕОНТЬЕВ, лидер направления развития специализированных СХД для резервного копирования, компания YADRO: Заказчики, которые очень активно «бежали» в сторону импортозамещения, уже закрыли в большинстве своем определенные базовые вещи и дальше остаются в режиме отложенного спроса.

Сейчас заказчики стараются максимально использовать оставшееся у них legacy-оборудование, откладывая новые инвестиции. Наиболее четкую границу провел Андрей ЗЕЛЕНСКИЙ, технический директор компании «Береста РК», он обратил внимание на ключевое различие между нерегулируемым бизнесом и компаниями, находящимися под надзором регулирующих органов. Если первые действительно пытаются двигаться по инерции и откладывать замену устаревших решений, то для вторых процесс импортозамещения идет планово и без видимого затишья. Они подходят к выбору СРК со «здоровой осторожностью», но не отказываются от него.

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?. Рис. 3
Андрей КУЗНЕЦОВ, генеральный директор «ООО «РуБэкап» (входит в «Группу Астра»), констатировал, что за последние годы ландшафт изменился кардинально. Если три-четыре года назад основным запросом была поддержка западных решений и клиенты разочаровывались, узнав, что какой-то функционал отечественные продукты не покрывают, то сегодня ситуация зеркально изменилась. Запросы на обслуживание импортного ПО практически сошли на нет, а внимание крупных заказчиков и госструктур сосредоточено исключительно на защите российских систем.

Этот сдвиг открывает дорогу к естественной консолидации рынка. Сейчас на нем представлено множество решений, зачастую базирующихся на схожих технологических стеках — например, на одном и том же PostgreSQL, но с разными «фишками». Однако уже заметно, что кто-то начинает терять долю, а кто-то и вовсе уходит с рынка, и эта тенденция, скорее всего, усилится.

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?. Рис. 4
Дмитрий АНТОНОВ, директор направления СРК, компания «Киберпротект», согласился, что ландшафт действительно изменился, но привел важное соображение: зарубежное ПО остается, и в достаточно значительных объемах. Наибольшая головная боль — базы данных, особенно Oracle, вокруг которых десятилетиями строились целые экосистемы.

Похожая ситуация и с почтовыми системами: повторить успех Microsoft Exchange пока никому не удалось, а потому спрос на поддержку этих критичных звеньев сохраняется. Однако изменилось само качество запросов. Если на начальном этапе импортозамещения заказчики просили «хоть как-нибудь, хоть медленно, хоть неудобно, но сделать резервную копию», то теперь требования иные. От вендоров ждут работы на высоком уровне, сопоставимом с привычным западным опытом. И речь идет не только о скорости или надежности самой СРК, но и о сложной интеграции с другими системами — виртуализацией, хранением данных, серверной частью.

Заказчикам все чаще нужна не просто СРК, а правильно выстроенное технологическое партнерство между вендорами, чтобы все элементы инфраструктуры работали в связке.

Участники сошлись во мнении, что работа с технологическими партнерами и интеграторами стала сегодня одним из самых трудозатратных треков. Андрей ЗЕЛЕНСКИЙ («Береста РК») отметил, что здесь кипит постоянная работа: интеграция с устройствами хранения резервных копий, непрерывная доработка совместимости с платформами виртуализации и, конечно же, с любыми СУБД. По его словам, поддержка новых источников данных и расширение матрицы совместимости — это непрерывный процесс, требующий огромных ресурсов.

S3-хранилища

Однако особенно жаркая дискуссия развернулась вокруг, казалось бы, безобидной темы — S3-хранилищ. Андрей ВИНОГРАДОВ, главный редактор журнала IT Expert (IT-World), модератор круглого стола, спросил, наблюдается ли в России тот же мировой тренд на рост интереса к этому протоколу. Оказалось, что сегодня S3 действительно «на хайпе», как выразился один из спикеров, — о нем говорят буквально из каждого чайника.

Андрей КУЗНЕЦОВ, «РуБэкап»: S3 разных реализаций — это очень востребованные технологии. Природа S3 как условно бесконечного хранилища с понятным и удобным протоколом делает его лучшим из того, что сейчас есть на рынке, несмотря на отдельные недостатки.

Дмитрий АНТОНОВ («Киберпротект») согласился, что протокол модный и удобный, но с точки зрения резервного копирования S3 — не самое лучшее решение, и его популярность в России подпитывается отнюдь не техническим совершенством, а дефицитом альтернатив. Ленточных устройств в российском реестре сейчас нет, и купить их невозможно. Поэтому заказчики, особенно те, кто связан регуляторными ограничениями, вынуждены искать замену. И S3 становится самым подходящим вариантом: недорогой, производительный, легко расширяемый.

И тут Дмитрий АНТОНОВ («Киберпротект») неожиданно заявил, что S3 не нужно и не следует резервировать с помощью систем резервного копирования. Надежность, отказоустойчивость и безопасность данных в S3 должны обеспечиваться самим хранилищем, а не внешним бэкапом. С технической точки зрения S3 — один из самых неудобных источников для резервного копирования. Его сложно и долго бэкапить, скорости крайне низкие, а окно резервирования может растягиваться на дни и даже недели. Поэтому, когда заказчики приходят с просьбой зарезервировать большое S3-хранилище, в компании первым делом задают вопрос: «А вы отдаете себе отчет, что процесс займет несколько суток?». Таким образом, участники пришли к общему мнению, что S3 — это хорошее решение для хранения резервных копий, но не для их создания.

Дискуссия о S3 неожиданно привела к конструктивному диалогу, когда слово взял Игорь МАКАРОВ, руководитель департамента разработки проектов компания «Умный архив». Его продукт как раз и работает по протоколу S3, но не является системой резервного копирования в классическом понимании. Это защищенный контур для хранения продуктов бэкапа — своеобразное связующее звено, которое принимает результаты работы бэкапного софта и размещает их в объектном хранилище. По сути, это не замена, а логическое продолжение инфраструктуры, агрегирующее все существующие в компании носители: от ленточных библиотек до дисковых массивов.

Такие СХД решают целый спектр задач, которые раньше закрывались фрагментарно. Они поддерживают отчуждаемость носителей — физическое извлечение дисков и их хранение в сейфе, что автоматически решает проблему вирусов-шифровальщиков: третья копия просто недоступна по сети. Кроме того, система позволяет управлять миграцией данных по правилам, распределяя копии по разным носителям и даже городам.

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?. Рис. 5
Игорь МАКАРОВ, «Умный архив»: Мы не говорим, «откажитесь от библиотеки, если она у вас есть». Отлично, мы можем ее использовать. А сценарий заказчик определяет сам.

S3 не отменяет традиционные подходы, а дополняет их, выстраивая распределенную иерархическую систему.

Модератор уточнил, правильно ли он понял, что S3-хранилищам, по сути, и не нужен отдельный бэкап, ведь сами копии данных создаются в необходимом количестве внутри системы. Спикер подтвердил, что это так, но с оговоркой: в долгосрочном хранении традиционные RAID-массивы неэффективны, они потребляют много энергии и изнашивают диски, а использование SSD для архивов и вовсе названо «отдельным клиническим случаем». Оптимальный подход — хранить файлы целиком, не размазывая их по дискам, что предоставляет возможность извлечь накопитель и создать автономный архив.

Игорь МАКАРОВ («Умный архив») рассказал о встроенной поддержке WORM (Write Once, Read Many) — концепции, при которой запись данных возможна только один раз, а чтение — многократно. Это означает, что даже если злоумышленник получит все ключи доступа и попытается стереть бэкап, система может отрапортовать об успешном удалении, но реально объекты останутся нетронутыми. Версионность позволяет сохранять все версии объектов, а система всегда следит за тем, чтобы существовало как минимум две копии на разных физических носителях.

Самым актуальным тезисом стало обсуждение катастрофоустойчивости в современных реалиях. В системе спикера используется удаленная репликация, позволяющая развозить копии по удаленным городам и поселкам, даже туда, где связь нестабильна. И аргумент был прагматичным: если в вашу самую навороченную RAID-СХД прилетит дрон, восстановить что-либо будет практически невозможно. А георепликация делает такие сценарии гораздо менее страшными.

Сформировался консенсус участников: S3 — это не панацея и не тупик, а новый, эффективный слой в иерархии хранения, который не отменяет ленты и RAID-массивы, а дополняет их, обеспечивая баланс между скоростью доступа, надежностью и экономической целесообразностью.

Ленточные хранилища

Андрей ЗЕЛЕНСКИЙ («Береста РК») внес важную корректировку, подчеркнув, что его компания рассматривает S3 именно как альтернативу, но без фанатизма: «Мы не топим за то, чтобы выбросить ленточный слой, мы его всецело поддерживаем, пока эти устройства живут и принимают резервные копии».

Рынок сейчас находится на этапе приживления S3 для нужд резервного копирования, прежде всего, как хранилища для бэкапов. Причем воздушный зазор (air gap), по словам Андрея ЗЕЛЕНСКОГО, можно организовать не только через физическое извлечение шпинделей, но и, например, через активацию сервиса на шлюзе в определенное время. Это позволяет заказчикам рассчитывать на надежную альтернативу емкому ленточному хранению, не теряя в функциональности.

Битва за данные. Выстоит ли «последний рубеж» ИТ-инфраструктуры в режиме жесткой экономии?. Рис. 6
Андрей ЗЕЛЕНСКИЙ, «Береста РК»: Работу с S3 необходимо тюнить. Нельзя просто взять протокол и отправлять туда резервные копии. Компания серьезно подошла к этой задаче, особенно в части многопоточной загрузки и скачивания, чтобы обеспечить нужную пропускную способность для Enterprise-заказчиков. Внедрение S3 — это не покупка волшебной таблетки, а сложная инженерная работа по настройке и оптимизации.

В отличие от своих коллег, которые настаивали на том, что S3 должен быть исключительно хранилищем, а не источником для бэкапа, Андрей ЗЕЛЕНСКИЙ занял более гибкую позицию. Он отметил, что существуют сценарии, когда S3 необходим и как источник данных. Защита данных с избыточностью за счет RAID, Erasure Coding или реплик не спасает от всех видов угроз. Более того, угроза может исходить не от злоумышленника, а от собственного сотрудника, случайно или намеренно испортившего все версии объекта. Поэтому компания «Береста РК» сделала поддержку S3 как источника данных, позволяя выполнять резервное копирование нативно, без «колхозных» решений с монтированием через Fuse.

Аналогичный подход, по его словам, применяется и к контейнеризации. Компания не упорствует в отказе от новых технологий, а слышит заказчиков, особенно из крупного интерпрайза, которые активно приживляют Kubernetes для stateful-приложений, где данные динамически изменяются и требуют бэкапа.

Мгновенное восстановление

У западных систем существует практика «мгновенного» восстановления, и участников интересовало, есть ли такой функционал у отечественных решений.

Андрей КУЗНЕЦОВ («РуБэкап») дал лаконичный ответ: «Есть, но не везде». Он пояснил, что ключевой фактор — интеграция и возможности самой защищаемой системы. Мгновенное восстановление невозможно без тесной связки с виртуализацией и другими компонентами инфраструктуры.

Дмитрий АНТОНОВ («Киберпротект») развил эту мысль, отметив, что вопрос на самом деле не простой. С одной стороны, для виртуальных машин, например, на платформе VMware, действительно существует механизм мгновенного запуска виртуальной машины непосредственно из резервной копии — система поднимается прямо из архива, а затем в фоновом режиме подтягивает данные. Это позволяет быстро восстановить достаточно простые сервисы, такие как сайт. Однако, с другой стороны, скорость восстановления — это всегда вопрос компромисса.

Дело в том, что дедупликация экономит место, но восстановление из дедуплицированной копии всегда будет медленнее, чем из обычной. Поэтому в компании сохраняют архитектуру, позволяющую восстанавливаться из недедуплицированных данных с высокой скоростью.

Впрочем, разговор должен идти не о скорости как таковой, а о времени восстановления.

Время восстановления — это комплексный показатель, включающий не только саму операцию чтения данных из бэкапа, но и все последующие процедуры по поднятию сервиса до рабочего состояния. Если системе нужно сначала восстановить копию на диск, а затем уже с этого диска запускать приложение, время увеличивается кратно. Поэтому ключевой фактор — не столько скорость самого процесса восстановления, сколько качество взаимодействия с теми продуктами, которые бэкапятся. И здесь все упирается в технологические партнерства с производителями систем виртуализации, баз данных и других компонентов. Без их поддержки даже самый оперативный бэкап не гарантирует быстрого восстановления.

Отечественные вендоры уже предлагают решения, способные конкурировать с западными аналогами по отдельным параметрам, но полноценный успех требует зрелости всего рынка — от СХД до платформ виртуализации.

И тут Андрей ВИНОГРАДОВ (IT-World) обратился к представителю YADRO с вопросом, который заставил всех притихнуть: ситуация с ленточными хранилищами в России парадоксальна. Критическая инфраструктура и многие государственные объекты до сих пор сидят на лентах, но ни одного отечественного ленточного привода в реестре нет.

Владислав ЛЕОНТЬЕВ, YADRO: Есть законодательное требование, что какие-то копии должны находиться на отчуждаемых носителях, особенно копии критической инфраструктуры, к тому же все должно храниться на отечественном «железе», причем единственный хорошо показывающий себя отчуждаемый носитель — это ленточные библиотеки, которые не производятся в России.

Получается замкнутый круг. Заказчики вынуждены жить на старых ленточных библиотеках, экономить место, складывать туда только месячные копии. И здесь прозвучал ключевой тезис: уйти от лент возможно и технологии для этого уже есть. Владислав ЛЕОНТЬЕВ (YADRO) сослался на выступление коллеги из «Умного архива» о WORM и неизменяемых форматах, а также упомянул специализированные хранилища для резервных копий, которые активно интегрируют этот функционал. Поскольку обходные пути есть — те же самые неудаляемые снимки, те же возможности организаций воздушного зазора без физического извлечения носителей. Однако он сделал оговорку: вопрос в том, можно ли это в полной мере назвать отчуждаемым хранилищем, и к архитектуре таких решений нужно подходить тщательно.

Андрей ВИНОГРАДОВ (IT-World) спросил, готово ли ПО для работы с разными носителями, например, для перехода с лент на жесткие диски. Андрей КУЗНЕЦОВ («РуБэкап») ответил коротко: физически это реализовать возможно и программные продукты это поддерживают. Вся проблема, по его словам, лежит не в технологической плоскости, а в организационной — как сотрудники, работающие с СРК, будут управлять этим процессом. Но сама готовность у вендоров есть.

Когда дискуссия зашла о ленточных хранилищах, Игорь МАКАРОВ («Умный архив») сказал, что ленты медленны, они несовместимы между поколениями, а если вы теряете доступ к софту бэкапа, данные на кассетах становятся практически бесполезными — ленточная библиотека не знает, что именно и где записано. Он привел неожиданный аргумент: до недавнего времени, пока не случился кризис производства накопителей и хайп вокруг ИИ, стоимость хранения на жестких дисках была зачастую ниже, чем на лентах. При этом заказчик получал не только резервное хранение, но и быстрый доступ к файлам в любой момент — диск можно быстро раскрутить и получить любой файл практически мгновенно, чего не скажешь о лентах. Это был вызов устоявшемуся мнению, что ленты — самый дешевый способ долгосрочного хранения.

Но достаточно неожиданным стало отношение Игоря МАКАРОВА («Умный архив») к RAID-массивам. Он назвал RAID «попыткой сэкономить» и «технологией от бедности», которая хороша только в «боевых» высоконагруженных системах, где данные постоянно меняются и важна быстрая замена дисков. В архивных же системах, по его мнению, RAID использовать не стоит. Он объяснил это просто: в архиве стоят сотни шпинделей, которые крутятся, потребляют электроэнергию, требуют охлаждения. А восстановить RAID в случае катастрофы практически невозможно. Если же данные хранятся на файловом уровне, на отдельных дисках, восстановить их гораздо проще — можно переставить пластины и головки, можно извлечь данные даже после обрушения здания.

Игорь МАКАРОВ, продолжив свою мысль, предложил прагматичный подход к лентам: «Если есть ленты, продолжайте их использовать». Его компания не призывает выбрасывать работающее оборудование — их софт умеет складывать данные на ленточные библиотеки, причем с полным знанием того, где что лежит, что делает восстановление с лент возможным и управляемым. Однако в компании пошли дальше и отказались от проприетарных форматов. Если вдруг исчезнут все дата-центры, софт и документация, но останутся жесткие диски, их можно достать из сейфа, подключить к любому компьютеру и прочитать данные. Пусть с хитрыми названиями, но с полным набором метаданных и манифестом, что позволит с помощью простого скрипта восстановить все без специального ПО. Этот подход — полная независимость от вендора — стал одним из самых сильных аргументов в пользу отказа от проприетарных форматов.

Заказчики, имеющие крупные ленточные библиотеки, не спешат их выбрасывать. Они чинят приводы, покупают кассеты, эксплуатируют оборудование активно. Причина — привычка и уверенность: лента обеспечивает тот самый пресловутый ERG (воздушный зазор) в наилучшем виде. Достал кассету, положил в несгораемый шкаф — и ты абсолютно уверен, что данные сохранятся.

Он также привел технический аргумент в пользу лент: даже если полностью потерять систему, метаданные хранятся внутри архива на самой ленте. Достаточно поставить новую установку и пересканировать ленту — и все восстанавливается.

Модератор усомнился в том, что через 20 лет можно будет прочитать не только жесткие диски, но и сами ленты, ведь во всем мире остался лишь один производителей драйвов для кассет. Этот скепсис мгновенно парировал Андрей ЗЕЛЕНСКИЙ («Береста РК») с отсылкой к истории: он напомнил, что первый маркетинговый слоган о смерти лент появился еще в апреле 2004 года у компании EMC.

Андрей ЗЕЛЕНСКИЙ, «Береста РК»: Поддержка лент — это абсолютный must-have, обязательный атрибут для любого ПО СРК. И это не просто формальная поддержка «записать файлик в один поток на один привод». Нет, нужно уметь быстро перекачивать на ленту большие объемы для долгосрочного хранения, а также быстро забирать данные обратно, оставляя метаданные в заголовках, чтобы можно было сделать инвентаризацию в любой момент.

Он аргументировал это просто: у заказчиков уже есть огромная накопившаяся кассетная емкость. Стоят IBM, Quantum, StorageTek, Oracle-библиотеки — и это оборудование уже оплачено. Задача вендора — дать заказчику возможность сэкономить на слое хранения за счет поддержки со стороны ПО, позволить этому оборудованию дожить свои 3–5 лет, пока оно не выйдет из строя естественным путем, а за это время подготовить переход к «светлому будущему» на объектных хранилищах и дисковых дедуплицирующих системах.

Причем подключаться к хранилищам нужно не через монтирование файловой системы (как к обычному серверу), а через SDK, как к S3 по API. Это не только повышает производительность, но и серьезно затрудняет жизнь злоумышленникам, закрывая целый класс атак, связанных с сетевыми протоколами файлового доступа.

Последний аргумент в защиту лент добавил Андрей КУЗНЕЦОВ («РуБэкап»), напомнив о технологии LTFS. Это стандарт SNIA, который позволяет работать с лентами LTO так же просто, как с обычными жесткими дисками или флешками, — через файловую систему. Понятно, что это медленнее, чем прямой доступ к приводу, но это значит, что ленту, записанную в одной системе, можно вставить в другой привод и прочитать данные без проприетарного софта.

Защита от шифровальщиков

Разговор о защите от шифровальщиков, который Андрей ВИНОГРАДОВ (IT-World) инициировал, коснувшись темы зловредного ПО, стал одним из важных с точки зрения понимания роли СРК в современном ИТ-ландшафте.

Андрей ЗЕЛЕНСКИЙ («Береста РК») подтвердил, что защита от шифровальщиков — это основной стимул, который постоянно довлеет над СРК, несмотря на то, что система позиционируется как «последний оплот», когда отваливаются все реплики или случается логическая потеря данных. Он описал трехуровневую архитектуру защиты, которую выстраивает его компания.

Первый уровень — это периметр управления. Компания внедрила поддержку двухфакторной аутентификации, чтобы защитить вход в систему и авторизацию. Второй уровень — защита на уровне хоста, где установлена СРК. Если злоумышленник проникает в системный периметр, задача ПО — затруднить ему доступ к устройствам хранения.

Андрей ЗЕЛЕНСКИЙ, «Береста РК»: Ленты, S3-хранилища и специализированные дисковые системы не «светятся» в стандартных блочных устройствах, поэтому злоумышленник не может просто записать нули или стереть данные с точки монтирования — он может зашифровать только системный раздел, но не сами бэкапы.

Третий, самый надежный уровень — защита на уровне самих устройств хранения: для дисковых систем это снимки (snapshots), для S3 — механизмы WORM, Object Lock и Retention Lock, которые не позволяют изменить или удалить данные даже при наличии всех ключей доступа.

Однако Владислав ЛЕОНТЬЕВ (YADRO) внес уточнение: не стоит полагаться на ПО СРК как на инструмент информационной безопасности. Это инструмент для других операций, и хотя он должен реализовывать определенные функции на своем уровне, комплексная защита от шифровальщиков — это архитектурная задача, решаемая на многих уровнях. Он перечислил уже обсуждавшиеся кирпичики: ленты, репликация между площадками, режимы WORM, снапшоты на СХД. Все они работают в связке. Особый акцент он сделал на защите на уровне снапшотов.

Владислав ЛЕОНТЬЕВ, YADRO: Даже если злоумышленник получит доступ к хранилищу и зашифрует файлы, он не сможет изменить блоки данных, из которых эти файлы состоят, потому что система хранит неизменяемые снимки. В любой момент можно откатиться на снапшот, не теряя актуальных данных.

Модератор задал вопрос: как система понимает, что это именно шифровальщик, а не легитимный пользователь? Ответ был прагматичным: на уровне СХД и ПО СРК можно оперировать только косвенными признаками. Например, в дедуплицирующем хранилище если неделями полные резервные копии изменялись на 10%, а вдруг появляется копия с изменениями на 50 или 60% — это триггер, alarm, о котором стоит сообщить администратору. Однако аналитику на уровне СХД, произошло ли шифрование файлов или нет, провести невозможно, потому что система не смотрит внутрь файлов. Это зона ответственности других инструментов — антивирусов, DLP-систем и решений класса EDR.

Игорь МАКАРОВ («Умный архив») решил объяснить аудитории, что такое S3 на самом деле. Он подчеркнул, что S3 — это не просто протокол, а объектно-ориентированное хранилище, которое по принципу работы очень похоже на базу данных. Ключевое отличие от блочных систем: вы можете положить и забрать объект, но не можете его изменить. Если вы что-то положили, потом забрали, изменили и положили обратно — это уже второй объект. Именно на этом принципе легко строить версионирование и WORM.

Игорь МАКАРОВ, «Умный архив»: Поскольку мы сами пишем стек S3, то у нас есть такие фичи, когда можем не стирать объект при его удалении, это своеобразное «тихое стирание». Мы отрапортуем клиенту о том, что объект удален, но на самом деле он будет, например, храниться 30 дней.

Он также развеял страхи о взломе S3-хранилищ: у системы всего один открытый порт — 443-й, и взломать ее практически невозможно. Поскольку это не блочное хранилище, классические атаки, связанные с монтированием томов и записью нулей, здесь неприменимы. Борьба с угрозами ведется через версионность и WORM, что защищает от случайного удаления, ошибок администратора или утечки ключей доступа.

Однако Дмитрий АНТОНОВ обратил внимание, что атака на систему резервного копирования особенно выгодна злоумышленникам, потому что СРК имеет доступ практически ко всем системам в архитектуре заказчика: к базам данных, виртуализации, Kubernetes, хранилищам.

Дмитрий АНТОНОВ, «Киберпротект»: Целенаправленная атака на систему резервного копирования может привести к полному и практически незаметному взлому всего, что есть в компании. Именно поэтому его компания сохранила и переписала систему защиты от вирусов-шифровальщиков, доставшуюся от предыдущей западной материнской компании. Исходный код был практически полностью переписан: он был под Windows, а теперь работает и под Linux, и под Windows.

И здесь прозвучал тезис, который стал итогом всей дискуссии о безопасности. Дмитрий АНТОНОВ («Киберпротект») провел прямую параллель между подходом к резервному копированию и подходом к информационной безопасности. Он напомнил, что наличие самой простой СРК внутри системы не гарантирует восстановления в случае аварии — нужен план, учения, постоянная проверка целостности копий, понимание порядка восстановления. Точно так же, с точки зрения ИБ и защиты системы резервного копирования от взлома, у компании должна быть целостная ИБ-политика, чтобы говорить о готовности противостоять вторжению. Это не разовая настройка, а непрерывный процесс — проверки, аудиты, учения и обновление политик.

СКР и искусственный интеллект

С помощью искусственного интеллекта хакерам стало гораздо проще взламывать системы. Специально обученные нейросети позволяют достаточно быстро и просто найти уязвимость и использовать ее для атаки на всю архитектуру компании. Поэтому комплексный подход к безопасности не менее важен, чем комплексный подход к резервному копированию.

Понятно, что СРК — это не замена антивирусам, DLP-системам и средствам защиты периметра. Это последний рубеж, который должен выстоять, когда все остальные оборонительные линии пали.

Последним, но не по важности, стал вопрос об искусственном интеллекте, точнее, о его влиянии на развитие систем резервного копирования и защиты данных. Модератор напомнил, что ИИ используется не только во благо, но и для взлома, и спросил, насколько эти системы могут быть опасны для СХД и как от этого защититься.

Андрей КУЗНЕЦОВ («РуБэкап») начал с того, что ИИ действительно упростил жизнь злоумышленникам, но предложил использовать его же во благо. По его мнению, ИИ можно и нужно применять для формулирования и проверки организационных мер, которые должны быть внедрены в компании. Он подчеркнул, что организационные меры зачастую важнее любых функций безопасности, встроенных в ПО. Если о них забывать, никакой функционал не поможет — он может быть не настроен, выполняться из рук вон плохо или просто игнорироваться. Он советует использовать ИИ для проверки документации и формулирования того, что нужно для защиты системы. Однако он, как и модератор, отнесся к этому с долей здорового скепсиса.

Андрей ЗЕЛЕНСКИЙ («Береста РК») рассказал, что его компания пытается ИИ поставить на службу. Здесь ключевую роль сыграло молодое поколение разработчиков — те, кто родился уже после 2000 года, они провели для старших коллег семинары по передаче знаний о том, как использовать ИИ во благо разработки, техподдержки и составления технической документации.

Дмитрий АНТОНОВ («Киберпротект») признал, что искусственный интеллект — это палка о двух концах, которая может и помогать, и мешать, и оказаться в руках злоумышленников. Однако он признался, что его компания относится с некоторой опаской к большим языковым моделям. «Мы не доверяем им написание кода», — прозвучало как негласное правило, разделяемое всеми участниками.

ИИ можно и нужно использовать для вспомогательных задач — генерации документации, проверки оргмер, анализа данных, — но доверять ему написание критического кода или принятие решений в области безопасности пока рано.

Финальный аккорд дискуссии был посвящен практическому применению искусственного интеллекта в разработке систем резервного копирования. Дмитрий АНТОНОВ («Киберпротект») рассказал, что его компания развернула собственную локальную LLM, которую «натаскали» для внутренних задач: это и помощь техподдержке, и аналитика, и помощь разработчикам с кодом. Однако модель работает только внутри контура компании, и никакие данные не уходят в публичные модели вроде ChatGPT или DeepSeek. Он поспешил развеять возможные иллюзии: их модель — это не собственная разработка с нуля, а развернутое локально закрытое решение на базе существующих технологий.

Владислав ЛЕОНТЬЕВ (YADRO) подтвердил, что у них тоже внутри развернута локальная LLM, которую используют не только разработчики, но и продуктовые, и сейлз-команды. Однако он сделал оговорку: к этим моделям нужно относиться с опаской, они часто галлюцинируют. Его компания выработала практическое правило — задавать один и тот же вопрос два-три раза, и если хотя бы два из трех ответов совпадут, можно ИИ доверять чуть больше. Его компания проводит внутренние тесты релизов с помощью специализированного ПО, в том числе на основе ИИ. «Этот инструмент в наших руках тоже прекрасно работает», — резюмировал он, подтвердив, что нейросети стали еще одним элементом арсенала как для атак, так и для защиты.

Игорь МАКАРОВ («Умный архив») добавил, что его компания применяет ИИ для генерации дополнительных метаданных объектов, что особенно актуально для объектно-ориентированных СХД. Однако он отметил, что хотелось бы все это делать на российском «железе», но ситуация с отечественными нейропроцессорами оставляет желать лучшего.

Рынок отечественного резервного копирования, несмотря на все сложности — от дефицита ленточных приводов до отсутствия российских LLM, — движется вперед. Медленно, но уверенно, с прагматизмом и здоровым скепсисом. ИИ не заменит человека, но станет его помощником — там, где он действительно полезен.