Как построить систему резервного копирования в сетях с несколькими контурами безопасности
Наличие нескольких контуров информационной безопасности требует особого подхода к резервному копированию. Опыт показывает, что усидеть на нескольких стульях — выдержать стандарты ИБ, получить работающую систему резервного копирования (СРК) и не заплатить космическую стоимость — вполне реально. Дмитрий Кострюков, руководитель отдела проектирования СХД/СРК «Инфосистемы Джет», в своей статье для CNews рассказал, как построить единую систему резервного копирования на нескольких контурах сети.
Рост числа киберугроз из года в год стал обыденным. По данным Positive Technologies, в I квартале 2020 г. было выявлено на 22% больше атак, чем в предыдущем квартале. Учитывая такую динамику, новым стандартом становится выделение особо защищаемых зон корпоративной сети. Дополнительной защиты конфиденциальных данных и информационных систем также требуют регуляторы для различных отраслей. При этом бизнесу по-прежнему важна доступность данных. Компании заинтересованы в максимально быстром восстановлении данных после сбоя, чтобы защитить себя от возможных потерь и простоев. Постоянное резервное копирование требуется как продуктивным данным, так и информации, находящейся в контурах повышенной безопасности.
С технической точки зрения сложность состоит в том, что СРК, как и другие элементы сетевого контура, должна соответствовать тем же требованиям ИБ, что и хранящиеся в ней данные. Поэтому менеджерам приходится оценивать риски компрометации и потери критически важной информации, чтобы определить, какие элементы защиты реализовать в первую очередь — создавать изолированные зоны сети или обеспечить эффективное резервное копирование. Но сегодня решить эти задачи можно параллельно, не создавая две отдельные системы резервного копирования, а значит — не увеличивая затраты и сложности в управлении разрозненными системами. Вместо этого предпочтительно внедрять централизованные и отказоустойчивые решения, но со специально адаптированной к работе в нескольких контурах архитектурой.
СРК с несколькими сегментами безопасности
Единая СРК, которая управляется из одной консоли и гарантирует единый уровень SLA для всех категорий данных, намного выгоднее для бизнеса. Во-первых, решение не требует дополнительных лицензий на отдельную инсталляцию. Во-вторых, для развертывания централизованной СРК нужно меньше оборудования, а емкость хранилища может гибко распределяться между разными сегментами без перемешивания копий и с полным соблюдением требований ИБ.
Строится такая система на отдельных медиа-серверах для каждого сегмента сети. Для центрального сервера открывают специальные порты в межсетевых экранах, которые пропускают только управляющий трафик. Каждый медиа-сервер располагается в своем сегменте сети, и трафик резервного копирования не покидает контура безопасности. Еще больших результатов можно достичь, используя для передачи данных сети хранения данных SAN. Трафик резервного копирования в этом случае вообще не передается по локальной сети, что говорит о гарантированной изоляции данных резервных копий. Кроме того, снимается нагрузка с продуктивной сети, а значит, процессы резервного копирования не влияют на производительность бизнес-сервисов.
Резервные копии из каждого контура должны храниться отдельно и не смешиваться с резервными копиями других сегментов. Для этого можно использовать разные дисковые массивы или изолировать данные внутри одной ленточной библиотеки, разделенной на логические сегменты с выделенными картриджами.
Чтобы обеспечить соответствие требованиям ИБ, защита серверов СРК должна быть реализована аналогично другим серверам в каждом сегменте сети. Например, если речь идет о резервном копировании для платежных систем, серверу необходимо обеспечить не только контроль доступа с ролевой моделью, протоколирование событий и сбор логов для восстановления хронологии событий, антивирусную защиту, контроль целостности и установку исправлений для известных уязвимостей, но также и внедрение двухфакторной аутентификации для входа.
Проект: два контура безопасности и полная отказоустойчивость
По стандарту PCI DSS процессинг должен быть изолирован. Нередко, чтобы достичь этого, банки создают отдельную ИТ-инфраструктуру для поддержки платежных операций. Такое дублирование дорого обходится: покупка оборудования, лицензий и последующая поддержка ложатся серьезным грузом на ИТ-бюджет. Создание единой СРК на нескольких контурах безопасности — оптимальный выход. Как строится СРК на нескольких контурах, подробно рассмотрим на примере одного из реальных кейсов в финансовой отрасли. Этот проект наша команда выполнила в этом году в крупном банке.
На тот момент системы резервного копирования заказчика «обслуживали» 320 ТБ данных 700 клиентов в двух ЦОД, а на дисковых массивах хранилось порядка 2 ПБ резервных копий. Для этого использовались 4 отдельные системы для разных категорий серверов. Развитие действовавших на тот момент систем резервного копирования оказалось неэффективно. Стоимость поддержки для них была высокой, оборудование уже работало на пределе своих возможностей, а использование ЛВС для резервного копирования снижало производительность сервисов.
Поэтому банк согласился с нашим предложением создать новую СРК. Она должна была обеспечить резервное копирование и возможность восстановления сразу в двух контурах, включая защищенный сегмент платежных систем, поддержку отказоустойчивых конфигураций с подключением двух ЦОД, а также резервирование физических серверов.
Основой для этого стала система Commvault. Одним из аргументов в ее пользу оказалась экономика решения. Мы подобрали способ лицензирования, при котором новая СРК обходилась намного дешевле прежней. Кроме того, Commvault имеет развитый функционал в области защиты физических серверов и возможность построения отказоустойчивой гиперконвергентной системы.
Архитектура СРК спроектирована так, чтобы трафик не покидал изолированных сегментов SAN — для большей производительности и безопасности. Эта конфигурация полностью отвечала требованиям безопасности. Но в процессе выполнения проекта поступила новая задача — обеспечить отказоустойчивость решения.
Чтобы остаться в рамках бюджета, мы наладили резервирование медиа-серверов между собой. Для них выделили отдельный сегмент сети с жесткими ограничениями на уровне межсетевого экрана и установили две базы дедупликации — по одной для каждого контура. То есть при отключении одного медиа-сервера второй берет на себя всю нагрузку. А поскольку трафик СРК остается в рамках SAN, резервные копии на уровне хранилища по-прежнему не перемешиваются.
Хранилище данных было переведено на кластерную файловую систему Microsoft CSV, чтобы разделить доступ и хранение данных.
Поскольку элементы в каждом контуре не дублированы, получилось исключить лишние затраты на оборудование — а это как минимум $350 тыс. Централизованное управление делает возможным балансировку нагрузки. Так, работа с сетью SAN позволяет задать гибкие ограничения по объему трафика в зависимости от дня и времени суток. А распределение расписания создания полных и синтетических копий снижает нагрузку на серверы и освобождает ресурсы для бизнес-сервисов. Например, для каждого клиента полная резервная копия может делаться только один день в неделю, а в остальное время создаются синтетические копии.
Управляющий сервер работает в виртуальной машине, а VMware HA «зеркалит» процесс и запуск дублирующих виртуальных машин в каждом из ЦОД для организации полностью катастрофоустойчивой конфигурации. После дедупликации резервные копии также можно зеркалировать между двумя ЦОД, обеспечивая резервное копирование и аварийное восстановление на уровне Metro кластера. И все это в рамках одной СРК.
Разумный подход
Единая СРК для двух и более контуров безопасности — это реальная практика, которая снижает стоимость эксплуатации, упрощает мониторинг и контроль за системой, помогает в будущем более гибко масштабировать решение, добавлять новые сегменты и строже придерживаться регламентов. Проводя аудит раздельных СРК для изолированных сегментов, мы чаще сталкиваемся с проблемными точками в них: нехваткой ресурсов, несоответствием лучшим практикам, устаревшими версиями ПО и прошивок оборудования.
Правильный подход к построению системы позволяет выполнить требование ИБ по раздельному хранению копий. Вместе с этим исключаются затраты на дублирующие компоненты системы, и, как показал наш кейс, экономия может быть существенной. А факт успешного прохождения ИБ-аудита подобными комплексами говорит о том, что построение отдельных СРК для разных контуров безопасности не имеет никакого смысла.