ИТ и ИБ. Как договориться о правилах, приоритетах и ответственности

22 апреля 2026 г.

Природа конфликта в кризисные моменты

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

В моменты кризиса ситуация меняется. Кибератаки 2022–2024 годов показали, что отсутствие четких правил ведет к параличу бизнеса. Организации сталкиваются с необходимостью мгновенного принятия решений: отключить ли незащищенный, но критичный для продаж сервис? Кто несет ответственность за простой инфраструктуры? Без заранее оговоренных регламентов эти вопросы решаются хаотично, что увеличивает ущерб. Успешная атака может стоить компании десятки миллионов рублей, но и необоснованная остановка бизнеса обходится не дешевле.

Организационные модели и где возникает конфликт

Эффективность ИБ зависит не от формального подчинения, а от полномочий принимать решения по рискам. Выделяют четыре основные модели.

• ИБ внутри ИТ-департамента. CISO подчиняется CIO. Модель характерна для среднего бизнеса. Плюс — технологическое единство. Минус — системный конфликт интересов. CIO может сознательно жертвовать безопасностью ради выполнения KPI по срокам запуска проектов. Риск замалчивается внутри департамента.
• ИБ как отдельная структура. CISO подчиняется CEO. Соответствует принципам ISO/IEC 27001. Плюс — независимый контроль. Точка конфликта — ИТ-отдел воспринимает требования ИБ как внешнюю нагрузку, не обеспеченную ресурсами эксплуатации.
• ИБ в составе службы безопасности (СБ). Акцент смещается на физическую защиту и расследование инцидентов. Конфликт рождается из-за технологического разрыва: сотрудники СБ часто не понимают специфики DevOps и облачных сред, внедряя неэффективные методы контроля.
• Матричная модель (Governance). ИБ задает правила и проводит аудит, ИТ эксплуатирует контроли, бизнес владеет риском. Это наиболее зрелая модель по NIST CSF 2.0. Конфликт минимизируется через прозрачный «аппетит к риску», утвержденный руководством.

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

Наиболее зрелой обычно является матричная модель. В ней ИБ задаёт правила, оценивает риск и контролирует достаточность мер. ИТ внедряет и сопровождает технические решения. Бизнес владеет сервисом и принимает остаточный риск там, где решение влияет на деньги, простой и обязательства перед клиентами. Такая логика согласуется с NIST CSF 2.0, где выделена отдельная функция управления, охватывающая стратегию, ожидания, политику, роли, ответственность и полномочия, а также с риск-ориентированным подходом ISO/IEC 27001.

Роли и ответственность

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

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

Минимальный состав ролей обычно такой:

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

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

Единая карта критичных сервисов и процессов

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

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

Практично использовать три уровня критичности:

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

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

Совместные зоны: доступы и изменения

На практике больше всего споров возникает вокруг доступа и изменений.

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

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

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

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

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

Инциденты: кто руководит и как фиксируется ответственность

Во время инцидента нельзя управлять по принципу «кто первым увидел, тот и главный». Нужен единый координатор. Эту роль можно назвать руководителем реагирования на инцидент.

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

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

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

Центр мониторинга ИБ и ИТ-эксплуатация

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

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

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

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

Минимальный набор документов, который можно внедрить за 2-4 недели

За короткий срок можно внедрить не идеальную модель, а рабочий минимум:

1. Матрица ролей и ответственности по ключевым сценариям: доступы, резервное копирование, установка исправлений, аварийные изменения, изоляция узла, закрытие инцидента.
2. Реестр критичности сервисов. В нём фиксируются владелец, уровень критичности, допустимое время простоя, допустимая потеря данных, ключевые зависимости и обязательные меры защиты.
3. Регламент управления исключениями. В нём должны быть основание исключения, срок, компенсирующие меры, дата пересмотра и подпись владельца риска.
4. Регламент управления изменениями. С видами изменений, обязательным участием ИБ и правилами согласования.
5. План реагирования на инциденты. С ролями, каналами связи, уровнями серьёзности, журналом решений и порядком эскалации.
6. Соглашение о взаимодействии между центром мониторинга ИБ и эксплуатацией. С измеримыми сроками и критериями закрытия задачи.

Итог

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

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

Следующий шаг на завтра

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

Артефакты-шаблоны

• Матрица ролей и ответственности по ключевым ИТ/ИБ-сценариям.
• Реестр критичных сервисов и бизнес-процессов.
• Карточка сервиса: владелец, зависимости, допустимое время простоя, допустимая потеря данных, окна изменений, стоп-факторы.
• Регламент управления исключениями по требованиям ИБ.
• Регламент управления доступами: роли, многофакторная аутентификация, привилегии, аварийный доступ, периодический пересмотр.
• Регламент участия ИБ в изменениях.
• План реагирования на инциденты с уровнями серьёзности и журналом решений.
• Соглашение о взаимодействии между центром мониторинга ИБ, ИТ-эксплуатацией и владельцами сервисов.
• Шаблон постинцидентного разбора с задачами на доработку процессов и архитектуры.
• Шаблон сообщения бизнесу и руководству при инциденте.

Источник: Егор Андюков, ведущий специалист по ИБ компании Б-152