Как энергетика собирает корпоративное ядро под требования КИИ

В энергетике ИТ-ландшафт проектируется от ограничений, а не от продуктов. Сначала – сегментация, изоляция, модель угроз. Потом – все остальное. Архитектура рождается из этих рамок. Отсюда ключевой вопрос: каким должно быть корпоративное ядро в компаниях с КИИ, где требования безопасности задают рамки всей архитектуры? Формальные инструкции здесь не работают – зато работает набор практик, который стабильно выдерживает пилоты и ОПЭ.

Корпоративное ядро: как оно устроено

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

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

В корпоративном сегменте энергетики ядро состоит из набора базовых сервисов: каталог, почта, коммуникации, документооборот, файловый слой, рабочие места и защита. Его фундамент – доменная структура, часто на Alt Domain или RedADM (службы на базе Samba DC): эти решения без сюрпризов проходят проверки совместимости и корректно работают с Kerberos и LDAP.

В реальных проектах переход к новому домену почти всегда начинается с гибридного режима. Старый Active Directory продолжает хранить SID и привязки приложений – без trust-связей массовую миграцию просто не запустить. Так домен становится точкой опоры для всех остальных компонентов. Почта – один из первых сервисов в корпоративном сегменте, который начинает жить по доменной модели: учетные записи, группы, права. И чаще всего именно она на прикладном уровне первой замечает любые отклонения в каталоге.

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

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

На уровне ниже находится невидимый пласт сервисов, на которых держится все ядро: DNS/DHCP домена, репликация, политики и настройки безопасности. Ошибки в любом из них могут спровоцировать каскад проблем – от задержек авторизации до потери доступа у части пользователей. На такие сценарии и заточены внутренние ППИ/ПМИ каждого компонента. Сценарии отрабатывают вручную, фиксируют протоколы, закрывают замечания – и только после этого переходят к пилоту.

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

В корпоративном сегменте на практике применяются переходные схемы – гибридный режим домена и поэтапная миграция пользовательских сервисов. В КИИ-контуре такие компромиссы возможны далеко не всегда

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

В рамках такой стандартизации на пользовательском уровне и появляется частичный dual-OS: критичные приложения остаются в Windows, а пользовательская среда переезжает в Linux. Это самый безопасный способ пройти миграцию без остановки процессов.

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

Как выглядит внедрение на практике

На проектах внедрение почти всегда проходит в три этапа.

1. Прототипирование – создание в миниатюре будущей инфраструктуры и выявление несовместимостей.
2. Настройка паттернов – сборка образов, настройка групп, OU, профилей, fallback-логики.
3. Переходный период – введение dual-OS, выравнивание политик и подготовка к ОПЭ.

Прототипирование занимает от трех до шести месяцев. На этом этапе всплывает все, что невозможно увидеть на этапе проектирования. Где-то рабочие станции не загружаются на новых образах без обновления BIOS. Где-то плоттеры, сканеры и терминалы требуют ручной настройки. Профили Windows при переносе в Linux теряют ярлыки, MIME-ассоциации и политики. Если корпоративный домен в гибридном режиме, любое расхождение по времени, сбой Kerberos или конфликт GPO могут вывести из строя авторизацию на половине контура.

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

Но часть задач паттернами не решить – слишком много рабочих мест держится на Windows-приложениях. Поэтому dual-OS закрепляется как рабочая норма в корпоративном контуре: пользовательский профиль — в Linux, технологические приложения — в Windows, а архитектура постепенно приводится к единому набору политик, профилей и прав.

Откат в этом контуре обязателен. Пользователь должен иметь возможность вернуться в привычную среду в любой момент. На практике команда стремится уложиться в 10–15 минут – иначе миграционный участок становится неуправляемым

Даже после перехода в ОПЭ двухслойная конфигурация сохраняется. Часть сервисов – на новой платформе, часть – на старой. Пока среды существуют параллельно, они должны быть синхронны. Расхождение в правах, политиках или репликации моментально ломает согласованность контуров – и превращается в локальный инцидент.

Информационная безопасность как каркас архитектуры

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

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

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

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

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

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

Стандартизация через эксплуатацию

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

Конечно же, у компаний в разных регионах – своя история, парк оборудования или глубина легаси. Но архитектурные требования одинаковые везде. Они и формируют единый «слепок» корпоративного ядра при сохранении изоляции КИИ-контуров: правила для каталога, почты, коммуникаций и подготовки рабочих мест.

Если система стабильно прошла ОПЭ на одной площадке, она, как правило, так же ведет себя и на других

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

Импортонезависимое ядро – основа цифровой устойчивости

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

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

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