Москва, ул. Пришвина, д.8, корп.2
Компания переносит серверы из офиса в дата-центр. Теперь оборудование находится за контролируемым физическим периметром, питание и охлаждение зарезервированы, связь идет по нескольким каналам. Кажется, что одна из главных проблем решена.
Но вместе с сервером в ЦОД переезжают старые учетные записи, накопившиеся права доступа, общие пароли, сетевые правила, которые давно никто не пересматривал, резервные копии и зависимость от отдельных специалистов. Железо стало защищено лучше. А инфраструктура?
Продолжаем тему резервирования и непрерывности сервисов, но теперь посмотрим на нее шире. Вместе с нашим партнером по IT-безопасности GRAF group разберемся, что действительно меняется после переезда в дата-центр, какие риски остаются на стороне компании и как связать площадку, доступы, данные и резервирование в единый контур.
Что действительно меняется после переезда в ЦОД
Профессиональный дата-центр закрывает вполне конкретный класс рисков. Сервер больше не зависит от офисного кондиционера, единственного интернет-канала или электропитания здания. Физический доступ к оборудованию ограничен, а питание, охлаждение и связь строятся с резервированием.
Именно эту задачу решает инфраструктура дата-центра ESTT: создает инженерную среду для стабильной работы оборудования.
Но внутренняя архитектура компании от смены адреса автоматически не меняется. Сохраняются учетные записи, права пользователей, способы администрирования, сетевые связи и порядок хранения данных. Если ключевые знания и доступы были сосредоточены у одного специалиста, переезд оборудования эту зависимость тоже не устранит.
Поэтому размещение серверов в ЦОД лучше воспринимать не как финальную точку проекта по безопасности, а как надежное физическое основание, поверх которого строится все остальное.
Кто на самом деле имеет доступ
Права в корпоративной инфраструктуре имеют свойство накапливаться. Сотрудника перевели в другой отдел, но старые разрешения остались. Подрядчику открыли административный доступ на время проекта и забыли его закрыть. Несколько специалистов используют одни реквизиты, поэтому позднее невозможно точно определить, кто изменил конфигурацию.
Есть и более серьезная зависимость: знания об инфраструктуре могут годами оставаться в голове одного человека.
В одном из кейсов одной российской компании собственник обнаружил масштаб проблемы только тогда, когда возник вопрос о замене IT-специалиста. Карта сети, пароли и логика взаимодействия сервисов были сосредоточены у одного сотрудника. Пока все работало, модель казалась вполне жизнеспособной. После его ухода новому специалисту понадобились недели только на то, чтобы разобраться в инфраструктуре.
В таком сценарии точкой отказа становится уже не сервер, а человек.
Поэтому инвентаризация доступов должна отвечать не только на вопрос «у кого есть пароль». Нужно понимать, какие учетные записи существуют, для чего они используются, кому действительно необходимы административные права, где фиксируются изменения и что происходит с доступами после увольнения сотрудника или завершения работы подрядчика.
Старую учетную запись тоже не всегда стоит удалять вслепую. Через нее могут работать автоматические задания или интеграции, о которых давно забыли. Сначала нужно понять зависимости, затем менять права.
Сеть тоже переезжает со всей своей историей
Корпоративная сеть редко проектируется один раз и навсегда. Компания растет, появляются новые серверы, 1С, CRM, базы данных, файловые хранилища, системы мониторинга, удаленные сотрудники и интеграции с внешними сервисами. Для каждой новой задачи добавляются маршруты, правила и точки доступа.
Через несколько лет схема продолжает работать, хотя никто уже точно не помнит, почему конкретный сервис доступен извне или зачем двум внутренним сегментам разрешено свободно взаимодействовать друг с другом.
Переезд серверов в ЦОД дает хороший повод провести ревизию: определить, какие сервисы действительно должны быть доступны извне, откуда разрешено администрирование, какие сегменты необходимо разделить и где нужны защищенные сетевые туннели между офисом, дата-центром и другими площадками.
Задача здесь не в количестве средств защиты. Чем понятнее связи между системами и чем меньше в них лишних маршрутов, тем проще инфраструктуру контролировать и сопровождать.
Бэкап есть. А восстановиться из него получится?
С резервными копиями проблема часто остается незаметной до первого реального восстановления.
Задание выполняется каждую ночь, мониторинг показывает успешный результат, архив занимает положенное место на диске. Все выглядит нормально, пока копия действительно не понадобится.
В опубликованном на Хабре кейсе транспортной компании примерно на 150 сотрудников база клиентов и данные о маршрутах находились на физическом сервере. Резервное копирование было настроено, но архив сохранялся на тот же сервер. Когда дисковый массив начал деградировать, скрипт еще около трех недель исправно создавал копии уже поврежденных данных. После окончательного отказа компания получила три дня простоя и частичную потерю информации.
Никакой сложной атаки для этого не потребовалось. Бэкап технически существовал, но зависел от той же инфраструктуры, которую должен был страховать.
Поэтому критичная копия должна быть достаточно независимой от рабочей системы по месту хранения, инфраструктуре и доступам. Одним из вариантов отдельного слоя хранения может быть S3-хранилище ESTT, в котором можно размещать резервные копии и архивные данные отдельно от основного сервера.
Но отдельное хранилище не отменяет главного вопроса: когда в последний раз систему действительно восстанавливали из этой копии? Реальный тест восстановления говорит о состоянии резервирования гораздо больше, чем зеленый статус очередного задания.
Отказ сервера и потеря площадки: разные сценарии
Допустим, данные сохранились, но вышел из строя физический сервер. Резервная копия сама по себе приложение в работу не вернет. Нужны новые вычислительные ресурсы, запуск системы и восстановление необходимых данных.
Для внутреннего сервиса несколько часов простоя могут быть приемлемы. Для клиентского портала, интернет-магазина или производственной системы тот же срок уже может означать прямые потери.
Если сервис должен переживать отказ отдельного физического узла, используется кластерная архитектура. В защищенном кластере ESTT вычислительная нагрузка не должна зависеть от работоспособности одного сервера.
Но у такого решения есть своя граница. Кластер защищает от части отказов внутри инфраструктуры, но не решает сценарий, при котором недоступной становится сама площадка.
Для этого уже нужны резервная площадка и Disaster Recovery: ресурсы в другом месте, актуальные данные и заранее подготовленный порядок восстановления сервисов.
Практика последних лет хорошо показывает, почему внутреннее резервирование ЦОДа и независимый резервный контур нельзя считать одним и тем же. Питание, охлаждение, связь и отдельные элементы оборудования можно дублировать, но остаются сценарии, масштаб которых выходит за пределы отказа одного устройства или инженерной системы.
Поэтому вопрос «что произойдет, если основная площадка временно станет недоступна целиком?» полезно задавать заранее.
Эту задачу мы отдельно разбирали в статье «Что будет, если основная площадка станет недоступна: как построить резервный контур». Там уже подробно рассмотрены RPO и RTO, hot, warm и cold reserve, переключение сервисов и проверка DR-сценария.
При этом резервная площадка не исправляет проблемы, которые уже существуют внутри основной инфраструктуры. Если на второй контур перенести избыточные права доступа, плохо документированную сеть и зависимость от одного администратора, географическое разнесение этих слабых мест не устранит.
Не каждому сервису нужен резерв один к одному
Когда инфраструктуру начинают рассматривать не как набор серверов, а как набор бизнес-сервисов, довольно быстро выясняется, что полное дублирование требуется далеко не всегда.
Представим компанию с несколькими десятками виртуальных машин. Клиентский портал и база данных должны вернуться в работу в течение часа. Внутренний архив может быть недоступен до следующего рабочего дня, а тестовая среда вообще не требует отдельного резерва.
Строить вторую площадку как точную копию основной в таком случае дорого и не всегда оправданно. Для критичного контура можно заранее подготовить вычислительные ресурсы и актуальные данные, а менее важные системы восстановить позднее.
Поэтому вопрос «сколько серверов нужно для резерва?» появляется ближе к концу проектирования. Сначала стоит определить, какие сервисы критичны, сколько данных допустимо потерять и какое время восстановления приемлемо для бизнеса.
После этого уже выбирается инфраструктура: собственное оборудование в дата-центре ESTT, выделенные серверы, VPS/VDS, виртуальная инфраструктура, S3-хранилище, защищенный кластер или отдельная резервная площадка.
Как собрать это в единый контур
Если соединить все части, получается достаточно последовательная схема.
Сначала компания понимает, кто имеет доступ к критичным системам и какие права ему действительно нужны. Затем приводятся в порядок сетевые связи и административные подключения. Для важных данных создаются независимые резервные копии с проверяемым восстановлением. Сервисы, которые не должны зависеть от одного физического узла, переводятся на отказоустойчивую инфраструктуру. Для сценария потери основной площадки готовится независимый резервный контур.
Эту логику мы используем в «Контуре безопасности», который ESTT прорабатывает вместе с партнером по IT-безопасности GRAF group.
У партнеров разные зоны компетенций. Со стороны GRAF group это аудит существующей IT-инфраструктуры, доступов, сетевого контура и организационных зависимостей. ESTT предоставляет инфраструктурную часть: площадку ЦОД, размещение оборудования, выделенные серверы, VPS/VDS, виртуальные ресурсы, S3-хранилище, защищенный кластер и резервную площадку.
В результате разговор начинается не с выбора очередного сервера, а со сценария: что именно нужно защитить, от какого события и за какое время система должна вернуться в работу.
Проверка до аварии обычно дешевле восстановления после нее
Для первого анализа не обязательно сразу покупать дополнительное оборудование. Иногда достаточно пройти несколько ситуаций и честно ответить, что произойдет в каждой из них.
Что будет, если завтра из компании уйдет специалист, у которого находятся ключевые знания и доступы? Из какой копии будет восстановлена критичная база и сколько это займет? Продолжит ли сервис работать после отказа одного физического узла? Где он будет запущен, если недоступной станет основная площадка?
Хороший ответ описывает не название технологии, а конкретный сценарий: кто принимает решение, где находятся необходимые ресурсы и данные, каким способом возвращается сервис и сколько времени на это отводится.
Если на каком-то этапе схема заканчивается словами «тогда будем разбираться», скорее всего, именно там находится зависимость, которую стоит устранить заранее.
Надежный дата-центр дает инфраструктуре инженерную основу. Непрерывность сервисов появляется тогда, когда поверх нее выстроены управляемые доступы, понятная сеть, проверяемые резервные копии, отказоустойчивые вычислительные ресурсы и независимый резервный контур.
Если нужно разобрать существующую инфраструктуру, подобрать ресурсы или подготовить резервную площадку в Москве, можно начать с консультации с инженерами ESTT.