Архитектура КИИ: как сделать контур управляемым

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

• сервисами,
• доступами,
• интеграциями,
• подрядчиками,
• площадками,
• бэкапами,
• исторически сложившимися зависимостями.

Задача после категорирования — привести этот контур к управляемому состоянию, чтобы он работал, контролировался, восстанавливался и масштабировался без хаоса.

Разбираем, что и в каком порядке делать.

Шаг 1. Определяем границы и зависимости

Значимый объект КИИ не живёт изолированно. У него есть прикладная часть, инфраструктура, каналы связи, доступы, интеграции, данные, средства мониторинга, резервного копирования и восстановления. 

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

Рассмотрим всё на примере системы диспетчеризации в транспортной компании, которая управляет грузовыми перевозками между регионами. 

Если судить по названию, всё выглядит достаточно просто: есть система, через которую диспетчер планирует рейсы, видит транспорт на маршруте и контролирует статусы грузов.

Но в реальной инфраструктуре за ней стоят: база данных, серверы или виртуальные машины, СХД, сеть, каналы связи между площадками, рабочие места диспетчеров, система авторизации, интеграции со складской системой, GPS/ГЛОНАСС-мониторингом, мобильным приложением водителей, клиентским кабинетом, мониторинг, резервное копирование и люди, которые всё это сопровождают.

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

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

Поэтому границы контура определяются через реальные зависимости объекта: 

• что нужно для его работы,
• какие данные он обрабатывает,
• с какими системами связан,
• кто имеет доступ,
• какие компоненты участвуют в мониторинге, резервном копировании и восстановлении.

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

Шаг 2. Сегментация и изоляция

Когда контур понятен по составу и зависимостям, переходим к сетевой части.

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

И все эти связи нужно разложить по полочкам:

• Кто подключается к объекту? Откуда и зачем?
• По каким портам и протоколам? Через какие узлы проходит трафик?
• Какие связи нужны каждый день, а какие остались исторически и уже давно никому не нужны?
• Что произойдёт с бизнес-процессом, если конкретный маршрут будет недоступен?

Это и есть сегментация: понять, какие зоны есть в инфраструктуре, какие связи между ними разрешены и как контролируется движение данных внутри контура.

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

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

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

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

Шаг 3. Упорядочиваем доступы и администрирование

После сетевой части смотрим на доступы. В нашем примере в системе диспетчеризации могут работать разные категории пользователей:

• диспетчер работает с рейсами, маршрутами, статусами грузов и заявками;
• администратор приложения может менять настройки системы, перезапускать сервисы, подключать модули и управлять пользователями;
• администратор базы данных с доступом к данным по рейсам, маршрутам, водителям, складам, клиентам и событиям;
• сетевой инженер может изменить правила между диспетчеризацией, WMS, GPS/ГЛОНАСС-мониторингом, мобильным приложением водителей и площадками компании;
• подрядчик сопровождает приложение, интеграцию со складской системой или модуль обмена статусами;
• сервисные учётные записи: для обмена данными, мониторинга, резервного копирования, интеграций с WMS, мобильным приложением водителей, клиентским кабинетом или внешними системами.

Каждый такой доступ может повлиять на работу объекта.

• Диспетчер с лишними правами может изменить то, что должен только смотреть.
• Администратор приложения может случайно отключить модуль обмена статусами и т.д.

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

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

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

Отдельно смотрим на административный доступ. Для КИИ лучше, когда администрирование идёт через понятные точки входа: бастион, jump-сервер, PAM, отдельный административный сегмент, MFA и журналирование действий. 

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

Шаг 4. Настроить наблюдаемость: мониторинг и журналирование

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

В диспетчеризации сама система может быть доступна, но GPS-данные от транспорта приходят с задержкой.

База данных может работать, но запросы выполняются слишком долго.

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

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

Команда должна видеть, где именно начинается проблема: в приложении, базе, сети, интеграции, хранилище, канале связи или внешнем сервисе. 

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

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

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

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

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

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

На выходе должна появиться схема наблюдаемости.

Она показывает:

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

Шаг 5. Спроектировать восстановление всего контура: резервирование и DR в КИИ

О стратегии резервного копирования и аварийного восстановления мы подробно рассказывали в отдельных материалах:

1. Иллюзия безопасности: почему бэкапы не спасают бизнес
2. Сколько стоит час простоя: строим стратегию восстановления данных

Разберём, что меняется, когда речь идёт о значимом объекте КИИ.

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

В системе диспетчеризации при восстановлении приложение может запуститься, база может открыться, но если WMS не передаёт статусы грузов или GPS/ГЛОНАСС-мониторинг не обновляет положение транспорта — перевозочный процесс ещё не восстановлен.

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

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

Если контур изменился, сценарий восстановления тоже должен измениться. 
Добавили новую площадку, поменяли СХД, перенесли систему на другую платформу, подключили подрядчика или что-то еще … — всё это влияет на восстановление значимого объекта.

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

Поэтому для КИИ нужно отдельно смотреть, где хранятся копии, кто имеет к ним доступ, как они защищены и проверялось ли восстановление на практике.

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

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

Результат восстановления должен подтверждать рабочий бизнес-процесс.
Для ИТ система может считаться поднятой, когда запустилось приложение и открылась база. 
Для бизнеса восстановление наступает тогда, когда весь процесс снова работает в нормальном режиме.

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

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

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

Архитектуру дополняют DR-сценарии и runbook’и — пошаговые инструкции, по которым команда может действовать без импровизации в момент аварии.

Шаг 6. Проверять каждое изменение на влияние на контур

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

После обновления WMS проверяем, как она передаёт статусы грузов в диспетчеризацию. 

После переноса БД на другую платформу смотрим производительность, задержки, резервное копирование и восстановление.

И так по всем зонам, где произошли изменения.

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

Перед внедрением команда должна ответить как минимум на несколько вопросов:

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

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

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

Что должно остаться после архитектурного разбора

После архитектурного разбора у компании должна остаться рабочая картина контура:

• карта значимого объекта;
• карта зависимостей;
• матрица сетевых потоков;
• матрица доступа;
• схема администрирования;
• схема мониторинга и журналирования;
• архитектура восстановления;
• DR-сценарии и runbook’и;
• порядок проверки изменений;
• план доработки инфраструктуры;
• актуальные схемы, регламенты и документация.

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

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

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