Единая архитектура ИТ и ИБ: как перестать строить параллельные миры

Дарья Петрова, директор департамента продуктов и стратегии R-Vision.

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

Этот разрыв напрямую отражается на бизнесе: задержки согласований, дублирующие процессы и несогласованные SLA замедляют работу и повышают риски. Инциденты ИБ влияют на SLA ИТ, а сбои инфраструктуры – на безопасность данных. Разные регламенты, устаревший контекст аналитиков SOC (Центр мониторинга и реагирования на инциденты информационной безопасности) и самостоятельные системы ИБ усугубляют проблему и ведут к лишним затратам.

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

Из чего состоит платформенный подход

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

Уровень сервисов

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

В этот слой входят следующие сервисы:

• CMS (Content Management Service) отвечает за пользовательские интерфейсы системы и позволяет быстро адаптировать экраны и формы под задачи разных ролей – аналитиков, администраторов и инженеров – без отдельной разработки под каждый продукт.
• Playbooks – основа автоматизации процессов: от обработки обращений и согласований до реагирования на инциденты ИБ. Все сценарии описываются и исполняются в одном сервисе, масштабируются под нагрузку и обеспечивают единые правила работы и предсказуемое время реакции во всех системах – SOC, ITSM и других.
• Streams – единый высокопроизводительный сервис потоковой обработки событий для ИТ и ИБ. Она закрывает задачи SIEM, мониторинга, телеметрии и интеграций в одном масштабируемом и отказоустойчивом контуре, снижая сложность, стоимость владения и операционные риски за счёт единой архитектуры и общих SLA.
• BI – единое окно аналитики, визуализации и отчётности. Общий BI-слой даёт ИТ и ИБ единый контекст данных, метрики и KPI, обеспечивая согласованные дашборды и отчёты без расхождений между системами.
• Scanner – сервис сбора данных с инфраструктуры для ИТ и ИБ: инвентаризация, технические характеристики, выявление уязвимостей. Единый сервис формирует один источник достоверных данных, снижает издержки и упрощает контроль за счёт централизованных обновлений.
• Agent – универсальное агентское решение для ИТ и ИБ. Используется для реагирования и форензики, мониторинга состояния систем и контроля конфигураций. Унификация агентской модели снижает сложность эксплуатации и упрощает централизованное управление инфраструктурой и безопасностью.

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

Продуктовый уровень

На базе общих сервисов формируется продуктовая линейка, закрывающие конкретные задачи бизнеса. Это могут быть SIEM, SOAR, VM или ITSM.

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

Уровень плагинов

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

Показательный пример – матрица MITRE ATT&CK. Она применяется в SIEM для сопоставления событий с техниками атак, в SOAR – для построения сценариев реагирования, в VM – для приоритизации уязвимостей, а также при расследовании инцидентов и обучении команд.

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

В платформенном подходе MITRE ATT&CK реализуется один раз в виде плагина и используется всеми продуктами. Обновление применяется централизованно и сразу становится доступным везде. Новые сценарии реагирования автоматически работают во всех системах без дополнительной разработки.

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

Уровень экспертизы

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

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

Ключевой эффект – тиражируемость и более частое обновление экспертизы.

Почему важна синергия всех уровней

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

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

Как это работает на практике

Ценность единой архитектуры хорошо видна в повседневных сценариях.

Сценарий 1. Плановые изменения

В классической модели ИТ инициирует и планирует изменения через ITSM, а ИБ подключается к согласованию преимущественно для высокорисковых ЗНИ (заявок на изменения). При большом объёме изменений и ограниченных ресурсах ИБ значительная часть локальных или типовых изменений проходит без их участия. В результате контекст таких изменений становится доступен ИБ уже постфактум, нередко в момент разбора инцидента безопасности.

В единой архитектуре всё выглядит иначе. Как только ИТ планирует обновление, информация об этом автоматически появляется в общей системе, отвечающей за управление изменениями: какие системы затрагиваются, когда пройдут работы и на какие бизнес-сервисы это повлияет. ИБ видит эти данные заранее, а система автоматически учитывает запланированные работы, переводя затронутые компоненты в режим обслуживания (maintenance mode) и предотвращая генерацию ложных инцидентов. После завершения работ конфигурация обновляется во всех связанных системах автоматически. В итоге изменения проходят быстрее, без лишнего шума и риска для бизнеса.

Сценарий 2. Реагирование на инцидент

Расследование инцидентов – ещё одна зона, где отсутствие общего контекста стоит слишком дорого. Когда данные об активах и их владельцах разбросаны по разным системам, аналитик SOC сначала ищет информацию, а уже потом реагирует.

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

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

Важно и то, что инцидент не «заканчивается» его закрытием. Выводы расследования (уязвимости, ошибки конфигурации, рекомендации) возвращаются в процессы ИТ и ИБ, чтобы не допустить повторения ситуации.

Вам также может быть интересен материал Клуба ИТ-лидеров Global CIO:

Реагирование на инциденты информационной безопасности. Взаимодействие ИТ и ИБ на стыке компетенций

Когда ИТ отвечает за скорость и доступность, а ИБ — за контроль рисков, противоречия быстро превращаются в задержки и рост операционных рисков. В материале рассматриваются подходы к согласованию KPI, распределению ответственности (RACI), приоритизации уязвимостей и выстраиванию совместной работы ИТ и ИБ.

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

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

Вместо заключения: единая архитектура как точка роста

Практика показывает, что переход к единому архитектурному подходу даёт измеримый эффект уже на ранних этапах. Сокращается время реагирования на инциденты за счёт доступа к актуальному и полному контексту, растёт пропускная способность аналитиков SOC, повышается общая производительность ИТ- и ИБ-команд. Это происходит не за счёт «ускорения людей», а за счёт устранения дублирующих процессов, оптимизации коммуникаций и более эффективной синхронизации действий между командами.

Однако ключевой результат – изменение характера взаимодействия между ИТ и ИБ. Вместо противостояния и постоянных компромиссов формируется партнёрство: команды работают в одном технологическом и понятийном пространстве и говорят на языке бизнес-результатов.

Дорожная карта перехода: от разрозненности к платформе

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

Дорожная карта перехода: от разрозненности к платформе

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

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

Шаг 2. Формирование единого источника данных об активах
Единая архитектура невозможна без консистентной картины инфраструктуры. Необходимо определить источник истины по активам, согласовать модель данных между ИТ и ИБ и свести в неё информацию из существующих систем. Это снимает значительную часть конфликтов и ошибок на последующих этапах.

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

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

Финальный вывод

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

За последние годы информационная безопасность перестала быть «стражником у ворот». Сегодня ИБ – это источник устойчивости и конкурентного преимущества. При этом разрозненность данных, процессов и инструментов ИТ и ИБ превращается из операционного неудобства в прямой бизнес-риск.

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

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

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

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