Этот текст — попытка снять поверхностный слой конфликта, чтобы увидеть системный сбой. Взаимное непонимание между «защищающими» и «работающими» — не случайность, а закономерность. Она зашита в сами подходы, метрики и архитектуру информационной безопасности. https://seberd.ru/5898
Чаще всего службу безопасности воспринимают как внутреннего врага, а не союзника. И дело не в плохих инженерах или вредных пользователях, а в фундаментальном разрыве между тем, как видят мир инженеры ИБ и те, кто ежедневно работает с инфраструктурой. Этот разрыв — результат системных перекосов, накопленных годами.
Разрыв в целях: безопасность против бизнес-результатов
Цель разработчика, аналитика или менеджера — выпустить продукт, обработать данные, закрыть квартал. Их успех измеряется в конкретных результатах: количестве релизов, закрытых задачах, достигнутых показателях. Каждое действие оценивается по вкладу в итоговую цель.
Цель службы безопасности — предотвратить инцидент. Её успех, это отсутствие событий. Это «негативная» метрика: сложно измерить, чего не произошло из-за твоей работы. Поэтому в ход идут косвенные показатели: количество заблокированных угроз, закрытых уязвимостей, проведённых проверок.
Именно здесь рождается первый конфликт. Для бизнес-подразделения каждая дополнительная проверка, согласование или ограничение, это задержка. Задержка в момент, когда скорость — критический фактор конкуренции. Когда служба ИБ требует остановить релиз из-за «средне-критичной» уязвимости, продукт-менеджер видит не защиту от гипотетической атаки, а реальные упущенные продажи и недовольных клиентов. Безопасность начинает восприниматься как бюрократический тормоз, который ставит абстрактные риски выше конкретных бизнес-задач.
Язык запретов вместо языка возможностей
Подход, выстроенный вокруг запретов, формирует психологию «надзирателя». Вместо того чтобы говорить «вот как это можно сделать безопасно», служба ИБ чаще сообщает «этого делать нельзя». Список запрещённых действий — политики использования, требования к паролям, ограничения на ПО — растёт, а объяснение «почему» часто сводится к ссылке на внутренний регламент или внешний стандарт.
Для сотрудника это выглядит как навязывание бессмысленных правил. Зачем менять пароль каждые 60 дней, если это приводит к записи на стикере под клавиатурой? Почему нельзя установить удобную программу для быстрой работы с данными? Ответ «потому что так положено» убивает любое понимание и сотрудничество. Безопасность превращается в набор ритуальных действий, которые выполняют, чтобы отделаться, а не чтобы реально защититься.
Такой подход игнорирует ключевой принцип: безопасность, это свойство системы, а не надстройка. Когда защита воспринимается как внешнее ограничение, люди ищут и находят обходные пути. Используют личные почты для рабочих файлов, устанавливают неофициальное ПО, создают тенитовые сервисы — всё ради того, чтобы просто сделать свою работу. Служба ИБ, обнаруживая эти «серые» зоны, ужесточает контроль, загоняя проблему ещё глубже. Возникает порочный круг недоверия.
Токсичная метрика: найденные нарушения как KPI
В некоторых организациях работа сотрудников ИБ или внутреннего аудита оценивается по количеству выявленных нарушений и выписанных предписаний. Это одна из самых разрушительных практик. Она напрямую стимулирует поиск вины, а не решение проблем.
Сотрудник, чья эффективность зависит от того, сколько ошибок он найдёт у коллег, мотивирован не помогать им стать лучше, а фиксировать максимум отступлений от регламента. Даже мелкие, несущественные недочёты раздуваются до размеров инцидента. Это создаёт атмосферу тотального подозрения. Разработчики и администраторы начинают скрывать информацию, опасаясь, что любая техническая деталь будет использована против них в отчёте. Вместо партнёрства для укрепления защиты возникает ситуация «охоты на ведьм».
Такая система отчитывается о своей «активности», но полностью проигрывает в главном — в создании реально защищённой среды. Страх перед наказанием подавляет открытость, которая критически важна для быстрого обнаружения и устранения настоящих, а не бумажных уязвимостей.
Техническая слепота и догматизм
Часто требования ИБ оторваны от технической реальности. Классический пример — политика сложных паролей с обязательной ежемесячной сменой, которая давно признана контрпродуктивной ведущими специалистами. Или требования к шифрованию данных в покое для систем, которые физически изолированы в защищённом периметре. Слепое следование устаревшим или неподходящим чек-листам, без понимания контекста и реальных угроз, дискредитирует всю службу в глазах технических специалистов.
Разработчики и сисадмины видят мир иначе. Они понимают, как работают их системы, где настоящие слабые места, а где — лишь формальность. Когда приходит специалист по ИБ с требованием, технически несостоятельным или даже вредным для стабильности сервиса, его авторитет падает до нуля. Возникает устойчивое мнение: «эти ребята ничего не понимают в реальной работе, только мешают». Это особенно опасно, потому что перечёркивает ценность действительно важных и правильных требований, которые тут же записываются в ту же категорию «бессмысленного догматизма».
Культурный барьер: два разных племени
Внутри IT-компаний часто существуют две разные культуры. Культура продукта и разработки, это скорость, эксперименты, принятие рисков, итеративность. Культура классической безопасности, это порядок, контроль, минимизация рисков, проверка перед действием.
Эти культуры говорят на разных языках. Для одного «быстро пофиксить и выкатить» — норма, для другого — кошмар. Когда представители этих культур не пытаются понять мотивы друг друга, а просто пытаются продавить свои процессы, конфликт неизбежен. Служба ИБ выглядит в этой схватке консервативной силой, сопротивляющейся любым изменениям.
Что можно изменить? От полицейского к архитектору
Разворот начинается со смены роли. Служба безопасности должна перестать быть «полицией» и «надзором». Её новая роль — архитектор и консультант по безопасности. Это значит:
- Встраивать безопасность в процессы разработки и эксплуатации с самого начала (shift left security), а не проверять результат в конце.
- Предлагать безопасные альтернативы и удобные инструменты вместо голых запретов. Не «нельзя Slack», а «вот наш корпоративный мессенджер с аналогичным функционалом, настроенный и безопасный».
- Измерять успех не количеством нарушений, а снижением реальных рисков и уровнем вовлечённости команд. Метрикой может быть доля проектов, прошедших security-ревью на ранних этапах, или скорость устранения критических уязвимостей.
- Говорить на языке бизнес-рисков. Вместо «нарушение пункта 5.3 регламента» объяснять: «если мы это сделаем, есть вероятность в 20% потерять данные клиентов, что приведёт к штрафам и репутационным потерям на сумму N».
- Технически подкованные сотрудники ИБ, которые могут на равных обсуждать архитектуру с разработчиками и предлагать решения, а не просто вычитывать их по чек-листу.
Ненависть к службе безопасности, это симптом системной болезни. Это сигнал, что модель работы устарела и работает против целей организации, порождая контрпродуктивные конфликты. Переход от культуры контроля к культуре сотрудничества и общей ответственности — сложный, но единственный путь превратить ИБ из объекта всеобщего раздражения в реального стратегического партнёра. Без этого любая защита останется хрупкой ширмой, за которой кипит жизнь с её «серыми» зонами и обходными путями.