Выбор между собственным ЦОД и публичным облаком давно перестал быть выбором «или-или». Бизнес и госструктуры держат критичные системы внутри периметра, а под пиковые и непредсказуемые нагрузки берут мощности у провайдера. Это и есть гибридное облако – единый контур, где часть ресурсов своя, часть арендована. Вопрос не в том, переходить ли к такой модели, а в том, как провести границу между двумя средами и не порвать ни безопасность, ни управляемость.

Что оставить в ЦОД, а что вынести наружу

Базовый принцип – данные определяют размещение. Персональные данные граждан, сведения, попадающие под 152-ФЗ, государственные информационные системы и всё, что требует аттестации по приказам ФСТЭК, остаётся в собственном или аттестованном ЦОД на территории России. Закон о локализации персданных действует с 2015 года, и Роскомнадзор проверяет его исполнение всё жёстче.

В публичное облако логично выносить то, что нагружает инфраструктуру неравномерно: тестовые и dev-среды, обработку отчётности по итогам периода, веб-фронты под маркетинговые кампании, ресурсоёмкие вычисления вроде распознавания изображений на производстве. Эти задачи выгодно оплачивать по факту потребления, а не держать под них железо круглый год.

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

Как связать две среды

Гибрид работает только при едином сетевом контуре. Между ЦОД и облаком провайдера поднимают защищённый канал – IPsec VPN или выделенную линию, для госсегмента с обязательной криптографией по ГОСТ. Адресные пространства планируют заранее, чтобы подсети не пересекались и маршрутизация оставалась прозрачной.

Управление тоже должно быть единым. Разрозненные консоли двух платформ съедают весь выигрыш от гибкости. Практичный подход – оркестрация через инструменты вроде Terraform и Ansible, когда инфраструктура описывается кодом и разворачивается одинаково и на своём железе, и в облаке. Так вы избегаете привязки к одному провайдеру и переносите нагрузку между средами без ручной пересборки.

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

Где ломаются проекты

Чаще всего гибрид буксует на двух вещах. Первая – недооценка трафика между средами. Постоянная синхронизация больших объёмов данных через VPN упирается в канал и в счёт за исходящий трафик у провайдера. Решение – держать «горячие» данные рядом с вычислениями, а не гонять их туда-обратно.

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

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

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