Безопасность начинается с бэкапов: новые подходы к защите и восстановлению данных

В эпоху непрерывных атак именно резервные копии становятся «страховым полисом» устойчивости. Но чтобы бэкапы действительно спасали бизнес, их нужно проектировать как защищённую систему: от архитектуры и изоляции до регулярных проверок восстановления.

Редакция CISOCLUB пообщалась с Владимиром Маракшиным, директором департамента стратегического развития «Киберпротект», о том, какие атаки чаще всего нацелены на системы резервного копирования и хранилища, как защитить бэкапы от шифровальщиков и инсайдеров, какие ошибки организации допускают при проектировании СРК и как выстроить работающую стратегию для разнородной и распределённой инфраструктуры. Мы поговорили про практики неизменяемого хранения и правило «3-2-1», Air-Gap и закрытых протоколов, он-прем и облачные сценарии, методы и периодичность тестов восстановления, контроль доступа и корреляция событий в SOC, подходы к сокращению времени восстановления критичных сервисов, а также тренды и требования регуляторов, влияющие на выбор решений и дорожные карты импортозамещения.

Какие атаки на системы резервного копирования сегодня встречаются чаще всего?

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

• Теневые копии
• Снапшоты
• Резервные копии

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

Как защитить бэкапы от шифровальщиков и саботажа инсайдеров?

С точки зрения повреждения бэкапов и их защиты, самое надёжное – это техническое отсутствие возможности выполнить сами по себе эти деструктивные действия. Примером могут быть здесь отчуждаемые носители (например, ленты, Blu-ray-диски). Безусловно, эти способы проигрывают по сравнению с дисковыми системами хранения резервных копий, по:

• Времени записи бэкапов
• Времени восстановления из них
• Времени доступности бэкапов (отчуждаемый носитель нужно ещё найти, достать, установить)

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

Как ни странно, следует исключить или минимизировать использование упрощённых сценариев доступности резервных копий по известным протоколам: CIFS/NFS, потому что это достаточно частый сценарий, при котором нет необходимости получать доступ в систему резервного копирования и достаточно получить привилегии на доступ к этим файловым ресурсам общего доступа с бэкапами.

Здесь приоритетнее использовать закрытые протоколы передачи резервных копий, или использовать эшелонированные прокси-серверы (Backup Gateway) для передачи бэкапов на CIFS/NFS, чтобы избежать прямого доступа агентов к хранилищам резервных копий.

Какие ошибки компании чаще всего допускают при организации резервного копирования?

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

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

Второй случай – это отсутствие выделенной команды, занимающейся резервным копированием, и связанные с этим нарушения в ролевой модели доступа. Казалось бы, на первый взгляд, администратор СУБД может отвечать и за резервные копии, но к чему это приводит: компрометация учётной записи этого администратора приводит к одновременной компрометации как самой инфраструктуры, так и резервных копий. Когда эти операции разделены между администраторами, риск получения доступа к обоим слоям инфраструктуры значительно снижается. При этом после разделения ролей важно правильно разделить и привилегии непосредственно в самих системах, чтобы не допустить избыточных прав доступа.

Ну и обычные, казалось бы, уже достаточно известные истины: не хранить бэкапы рядом с продуктивными данными; отсутствие запланированных регулярных проверок резервных копий; отсутствие учёта требований к резервному копированию и прочее. Нет-нет да появляются случаи, когда в инфраструктуре забывают об этих простых правилах, поэтому не лишним будет сказать о них ещё раз.

Как правильно хранить резервные копии: он-премис, в облаке?

Лучше и там, и там, и ещё где-нибудь. Бэкапов много не бывает 😊

Но если без шуток, то здесь определяющим будет политика компании в области ИБ и обращений с резервными копиями. Если в компании строго запрещено передавать резервные копии или какие-либо данные бизнес-систем внешним компаниям, то о каком публичном облаке в его классическом виде может идти речь?

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

Если же ограничений нет, и мы рассматриваем сценарий, когда есть локальная инфраструктура и нет ограничений по облачному хранению, то вполне разумен будет гибрид: оперативные бэкапы хранятся локально, архивные – передаются облачному IaaS / BaaS провайдеру услуг, к которым можно прибегнуть в случае достаточно серьезных проблем в своей инфраструктуре. Также это позволит реализовать географически распределённое хранение резервных копий в том сценарии, когда у вас один центр обработки данных и построение второго не является на текущий момент экономически обоснованным. В таком виде у вас появляется некая запасная площадка с минимальными затратами и за достаточно быстрое время.

Насколько важна изоляция копий и как её реализовать на практике?

Старое доброе правило «3-2-1» в своём аскетичном, но всё же минимально достаточном виде, остаётся актуальным и по сей день. Нужно следовать как минимум ему, разнося разные резервные копии на разные носители и площадки – это уже будет хорошим шагом для повышения возможности восстановиться. Вторым шагом будет организация защиты резервных копий от намеренного или ненамеренного удаления за счёт механизмов WORM/Immutability. И третьим шагом будет организация Air-Gap резервных копий, недоступных основной системе резервного копирования на постоянной основе. Здесь инициатором должен выступать некий отличный от централизованной системы резервного копирования узел, который имеет доступ к резервным копиям в режиме «только чтение» и при этом неизвестен самой системе резервного копирования. В таком случае злоумышленнику будет сложнее обнаружить такой узел и удалить бэкапы там.

Как часто стоит тестировать восстановление данных и какие методы проверки самые надёжные?

На практике – самым эффективным и надёжным методом проверки резервных копий является развёртывание полного состава защищаемой информационной системы в виде ландшафта-клона, т.е. проведение полных мер по восстановлению работы компонентов, обеспечивающих бизнес-процессы. Разумеется, этот способ одновременно и самый «дорогой» по трудозатратам, времени и ресурсам, а значит и по стоимости. Но только он может в полной мере подтвердить корректность, а главное – полноту резервного копирования. Ведь зачастую случается так: в приложении появляется новый компонент (служба, база данных), и на стадии её имплементации нужно определиться в необходимости резервного копирования. Если это повсеместная практика в компании – то тяжелых последствий можно избежать. Если же нет – велика вероятность, что при каких-то изменениях что-то упустили и не перенастроили планы резервного копирования. Выявить это можно только на таком клоне.

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

Далее, от наиболее эффективного к наименее эффективному, расположу иные вполне себе применяемые способы проверки резервных копий, а также укажу примерные сроки, когда это лучше делать:

• Частичное выборочное восстановление объектов информационных систем (ИС) – раз в несколько месяцев для критичных ИС и близких к ним по классификации критичности
• Частичное выборочное восстановление типов объектов – раз в месяц, чтобы убедиться в корректной работе СРК
• Гранулярное восстановление отдельно взятых объектов – в зависимости от специфики приложений и сценариев восстановления, но можно ориентироваться также на раз в месяц
• Проверка на уровне контрольных сумм и механизмов обеспечения консистентности непосредственно бэкапов (проверка бэкапов на возможность чтения) – дорогостоящий процесс, но с малыми гарантиями. Рекомендовал бы его проводить по запросу или при случаях, когда нужно убедиться в работоспособности носителя бэкапа.
• Проверка контрольных сумм записываемых данных в ходе выполнения операций резервного копирования – при каждом выполнении резервного копирования. Лучше эту опцию не отключать на всех заданиях бэкапа.

Как контролировать доступ к репозиториям резервных копий, чтобы исключить злоупотребления?

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

Если в компании есть SOC (Security Operations Center), то следует события системы резервного копирования сформировать в сценарии инцидентов и выводить их наряду с остальными событиями на панелях мониторинга оператора. Здесь можно выделить как нетипичные сценарии: например, настройка параметров системы резервного копирования в нерабочее время, так и вполне стандартные: несанкционированный доступ, изменение прав доступа на каталогах резервных копий, массовость действий с резервными копиями и пр.

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

Как выбрать стратегию бэкапа при работе с разнородными системами и распределённой инфраструктурой?

Для начала следует ввести категоризацию систем, например, исходя из критичности или влияния на бизнес-процессы. Это позволит уменьшить разнородность в классификации самих по себе информационных систем и сгруппировать их исходя из очерёдности восстановления и допустимых значений основных метрик.

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

Касательно распределённой инфраструктуры, нужно не забывать учитывать каналы связи и их ограниченную пропускную способность. Если речь идёт о защите данных на удалённых объектах с нестабильными каналами связи, следует предусмотреть каскадное хранение:

1. Резервная копия выгружается на узел оперативного резервного копирования непосредственно на площадке в соответствии с основным расписанием резервного копирования. Здесь можно оставлять одну или две последние резервные копии для оперативного восстановления.
2. В фоновом режиме резервные копии передаются в основной ЦОД, где хранятся в соответствии с политикой и сроками хранения резервных копий (РК). Здесь уже следует держать всю цепочку резервных копий.

Возможны вариации, когда на локальной площадке хранятся не только самые последние копии, а организуется подсистема более длительного оперативного хранения резервных копий, а в ЦОД отправляются резервные копии, подлежащие долговременному хранению. Такой вариант тоже допустим, если есть возможность обеспечить достаточную защиту резервных копий на этой площадке и утеря оперативных резервных копий удалённой площадки не будет являться критической для бизнес-процессов.

Что реально помогает сократить время восстановления критичных сервисов после атаки?

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

Также современные системы резервного копирования имеют в своём арсенале специализированные средства ускорения процесса: гранулярное восстановление объектов, Instant Recovery (возможность запуска БД или ВМ напрямую из резервной копии).

Как меняются требования к резервному копированию со стороны регуляторов и как к этому готовиться?

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

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