Сразу оговорюсь: я не безопасник. В ИБ я разбираюсь ровно настолько, насколько должен разбираться любой взрослый человек не называть три цифры с оборота карты, не хранить пароли в файле "пароли.txt", немного понимаю про доступы и разграничение прав. ИБ это не моя специализация, и я не претендую на экспертную оценку конкретных практик.
Но у меня как у человека, который много лет занимается внедрениями ITSM/ITAM и постоянно взаимодействует со службами безопасности заказчиков, накопилось наблюдение, которым хочется поделиться и услышать мнение тех, кто в теме глубже.
Наблюдение
Возьмем типовую ситуацию. Есть сервис-деск. Он хочет постучаться во внешнюю систему которая живет в руже интернета, чтобы, например, автоматически забирать оттуда критичные уязвимости ПО и заводить по ним заявки. Задача понятная, полезная, снижает ручной труд и человеческий фактор.
Приходит ИБ и говорит НЕТ. Защищенный контур, никаких внешних обращений, точка.
И вот тут у меня как у стороннего наблюдателя возникает вопрос, а разве задача ИБ это запретить инициативу? Или все-таки оценить риск и предложить, как его закрыть?
То есть в идеальном мире ответ звучал бы не НЕТ, а что-то вроде: "окей, делаем, но трафик шифруем так-то, доступ даём только сервисному аккаунту с такими-то правами, логируем каждое обращение, ставим WAF/прокси на периметре, ревью раз в квартал". Риск не в том, что система смотрит наружу риск в том, как она это делает. И управлять этим КАК это и есть, как мне кажется, содержание работы ИБ, а не сам факт запрета любых инициатив.
Почему тогда так происходит?
У меня есть несколько версий, и я не уверен, какая ближе к истине возможно, все сразу, в разных пропорциях.
Версия про бюджет и ресурсы. Сказать НЕТ это бесплатно. Спроектировать безопасную схему интеграции, согласовать ее, потом сопровождать это время, компетенции и деньги. Если в ИБ два человека на весь холдинг, у них физически нет ресурса разбираться с каждым "а давайте достучимся туда-то" проще закрыть тему одним словом НЕТ.
Версия про ответственность. Запрет не создает для безопасника личного риска. Разрешение создает. Если что-то случится после ДА, спросят с того, кто разрешил.
Версия про традицию. ИБ во многих компаниях исторически выросла из "режимного отдела" оттуда, где по умолчанию всё закрыто, а открывается только по специальному разрешению сверху. Культура за 20-30 лет не поменялась, хотя ландшафт угроз и кардинально другой.
Версия про КИИ и регуляторику. Отдельная история объекты критической информационной инфраструктуры, там свои требования, свои категории значимости, и там запрет часто действительно обоснован нормативкой, а не ленью или отсутствием бюджета. Но проблема в том, что логика "раз где-то есть жесткие требования давайте применим их ко всему" переносится и на банальный сервис-деск, которому нужно всего лишь синхронизировать справочник уязвимостей.
Мне интересно, насколько мое наблюдение справедливо, или я просто вижу нерепрезентативную выборку компании, где ИБ действительно недоинвестировано и работает по остаточному принципу.
Если вы работаете в ИБ или тесно с взаимодействуете с ними правда ли, что зрелая практика по умолчанию ищет способ разрешить с компенсирующими мерами, а не запретить? Или запрет по умолчанию это и есть правильный подход при текущем уровне угроз, а мое "а давайте разрешим, но защитим" звучит инфантильно?
Буду рад комментариям, особенно от тех, кто может аргументированно высказать свое мнение.
Комментарии (20)
pqbd
09.07.2026 06:53Не запретительный, а разрешительный :)
Две стратегии:
(Либеральный) Всё разрешено, пока явно не запрещено
Всё запрещено, пока явно не разрешено
Оставим гибридную за рамками…
Первая требует постоянного мониторинга изобретательности людей и выдачи точечных запретов (запретительный орган). В итоге нужно управлять и поддерживать большой список непонятных запретов.
Вторая требует мониторинга, но не совсем такого широкого. В итоге нужно управлять и поддерживать небольшой список понятных разрешений. (разрешительный орган)
А как там устроено на местах - это отдельный вопрос. Где-то ИБ может работать только как супервизор: не предлагает решений, а анализирует предложенные на предмет их допустимости. "Нет" значит “в этом виде не годится, приходите с другим решением”.
Evgenii_ESM Автор
09.07.2026 06:53Спасибо, в таком случае получается, что у каждой команды разработки должен быть личный ибешник, что в целом правильно. Код должен быть безопасным. Иначе я не понимаю как можно приди с другим решением, не имея должной компетенции в составлении таких решениях
nmouse
09.07.2026 06:53ИБ специалистов можно можно как сервис организовать, если своих нет или свободных нет, то можно привлечь на почасовой основе. Даже бигтехи так делают, например, тот же ИБ или специалистов по СУБД внешних привлекают. Не надо стесняться того, что экспертиза внутри недоступна и запросить помощь из вне. Я и сам консультировал ребят несколько раз, например, есть идея устроить ран и нужно по-быстрому прикинуть во что это станется и через сколько инвестиции отобьются. Или на стриме всегда продуктовый подход, но тут нарисовался контракт, который сейчас и в перспективе позволит поднять прилично бабла, но для этого нужно перейти на водопад и точно исполнить контракт, а потом вернуться обратно к продуктовым гибким способам достижения целей.
C0BHAPK0M
09.07.2026 06:53Существуют две политики, массовая - палочная, и маргинальная - превентивная.
Первая стала массовой именно потому что вы заметили, это же хоть и информационная но БЕЗОПАСНОСТЬ. А потому как правило на руководящие позиции туда прут пенсы из силовиков, в основном "мусора". Какие вы от них навыки и скилы хотите? Только наказать и палки зарабатывать. Они и в прошлом своём занятии тем же занимались. А вот стратегия (которой стараюсь придерживаться и я в своей работе) превентивная - руководством не поддерживается.
Стратегия, имхо, должна предусматривать всего то несколько принципов:
защита компании от нарушителей
соответствие регуляторики в отрасли
защита сотрудников компании от ошибок
Стиль простой, ИБ должна работать так, чтобы никто и не знал о её работе, а все действия пользователей, отрегулированные политикой в рамках трудовой деятельности, никак не могли создать проблем как системам так и самим пользователям, им не нужно думать о правилах соблюдения ИБ, у них своя работа есть, подчас гораздо сложнее.
Это непростая задача, но решаемая. Главное чётко представлять цели, а способ найдётся.
nmouse
09.07.2026 06:53Долгое время был частенько с ИБ на ножах (персоналка, PCI DSS, банковская тайна, тайна связи. ГИС - это всё с чем работаю, обычно). Но как-то попал в одного телеком провайдера и как-то с ребятами притерлись и нормально сотрудничали, да местами искрило, но был диалог, а не посылания и эскалации.
С тех пор сразу диалог с ИБ:
1) Что хотим сделать, зачем хотим сделать, как хотим сделать, можно насыпать какие бенифиты могут быть для ИБ, если они есть;
2) Если отказ, то прошу примеры векторов атаки => идем прорабатываем концепт, с учётом защиты от указанных векторов. Часто так получалось, что ИБ само давало подсказки в виде каких-нибудь статей
3) Приходим повторно с доработанными предложениями.
4) ИБшники (во множественном числе не просто так, у них бывает много направлений) предлагают докрутки объясняют зачем и почему, плюс у себя какие-то докрутки.
5) Идём считаем во сколько это всё встрянет и сравниваем с планируемым профитом. Если перевешивает профит - идём и делаем.
Пункты 2, 3, 4, обычно, выполняются в цикле, пока, не придете к одному или нескольким вариантам.
Наверное, стоит рассмотреть отдельно, если в организации теоретически есть СС или гостайна, там бесполезно. Сам не сталкивался, но опосредственно наблюдал: "заваривают" так, что проще и дешевле еще раз читануть регламент или местный стандарт ИБ, а потом забить болт
Evgenii_ESM Автор
09.07.2026 06:53Классный опыт, но он работает на уровне внутри компании, моя рабочая практика быть подрядчиком. И не всегда заказчики готовы идти проделывать шаги 2, 3, 4 даже при условии моего согласия проходить эти шаги совместно и всячески содействовать. Все как всегда на личной инициативе. Спасибо за классный чек-лист.
Wiseguy777
К сожалению это действительно так. Сейчас очень распространена атака на цепочку поставок, а так как сервис дески в основном опенсорсное решение и редко когда разработчики занимаются харденингом кода, а если к этому еще добавить огромное количество форков, в которых может быть овердофига закладок и т.п., то пускать в ружу такую систему может быть себе дороже. Обычно сервис дески работают с AD по LDAP, и если с ружи получится скомпрометировать УЗ и повысить привилегии, то game over. Понятно что в зрелых организациях есть FW на границе, возможно даже EDR на конечных точках (хотя бы серверах) и сисадмины даже могут замутить DMZ спецом для такого кейса, но все это упирается во время и нехватку персонала, поэтому либо проект остаётся на бумаге либо чаще просто НЕТ.
Evgenii_ESM Автор
Спасибо. Тут дело не в сервис десках (кстати опен сорс решений у энтерпрайз сегмента не видел), думаю с такой проблемой сталкиваются любые классы систем, которые хотят на ружу). Да сервис деск зачастую работает с AD по LDAP, но SSO SAML никто не отменял + всегда есть двухфакторная аутентификация, если подытожить то упираемся в бюджеты и время.
mist56
Я такой себе ИБ пофигист, поэтому пускаю клода в свою небольшую рабочую сетку небольшой организации на 30 чел. Настраивает AD вдоль и поперёк. Вычистил кучу техдолга в интранете. В общем имхо вопрос бюджеты-время упирается лишь в уровень доверия ИИ инструментарию.
Evgenii_ESM Автор
ИИ инструментарий это относительно новая технология. А вот всякие CRM или ITSM системы используются уже десятки лет, а до сих пор запрещают в некоторых организациях интеграцию с внешними системами. Что касается ИИ тут в первую очередь с людьми нужно работать, что бы не сливали в ИИ конфиденциальную информацию.
Я для тестов свою AD тоже настраивал чрез ИИ, заводя тута десятки тестовых пользователей, групп и т.д.
mist56
Недавно клодом 1) поднял новую виртуалку на ESXi c Win2025 2) На нём новый DC 3) старый задемоутил Всё это с ворохом всякого обвеса в sysvol и кастом скриптах, вылечиванием старых проблем в DNS и DHCP из-за собственной криворукости и прочее. За 2 дня. Ни разу не заходив ни на один из серверов. Не призываю так делать, но будущее рядом.