Журнал "Information Security/ Информационная безопасность" #1, 2026

Иван Барановский, "АйТи Бастион" Это абсолютно типичная ситуация для крупных инфраструктур: процессы учета отрегулированы не до конца, архитектура постоянно меняется, активы появляются и исчезают, а ответственность за все это лежит на разных подразделениях. При этом часть систем просто уходит в легаси, про которое со временем забы- вают. Риски здесь вполне прозрачные: каждый неучтенный актив – это либо потенциальная точка входа, либо удобное место для закрепления злоумышленника. Такие забытые узлы часто всплывают через анализ привилегированных досту- пов, а значит, необходимо не только стремиться к полной инвентаризации, но и централизовать контроль доступа и ответственности. Владислав Шелепов, "Газинформсервис" Проблема в том, что крупные инфра- структуры зачастую меняются быстрее, чем их успевают описывать. В контурах постоянно появляются временные маши- ны, реплики, технические узлы. Риск здесь прикладной – если актив не попал в учет, он быстро выпадает и из других процессов. Его позже патчат, по нему не всегда пересматривают доступы, его логи могут не доходить до SOC. При инцидентах это превращается в слепую зону, потому что часть маршрута атаки проходит через хосты, которых фор- мально нет в картине инфраструктуры. Алексей Карабась Причина банальная – экономическая эффективность. Бизнес просто не может себе позволить держать такое количе- ство узконаправленных специалистов, которые будут постоянно актуализиро- вать активы, схемы и планы, а внедре- ние систем автоматического учета в уже сложившиеся бизнес-процессы – очень болезненно и не дешево. Мы ждем как избавления системы автома- тизированного учета на базе нейросе- тей, которые будут сразу выдавать решение, адаптированное под конкрет- ную архитектуру. Владислав Шелепов, "Газинформсервис" Разрыв ответственности обычно воз- никает на стыке зон. Сервер может быть вашим, сеть частично вашей, часть сервисов ведет оператор, а доступы проходят еще и через подрядчиков. Пока все спокойно, это не так заметно. После инцидента сразу выясняется, что у некоторых компонентов может не быть единого владельца, который отвечает за контроль целиком. Из-за этого при работе с инцидентами может теряться время на споры о том, кто должен был заметить изменение, кто должен был закрыть доступ и кто обязан был хранить нужную телеметрию. Алексей Карабась Чаще всего это вопрос меры ответ- ственности. Бизнес обращается в ЦОДы как раз для того, чтобы оптимизировать затраты на персонал, однако ответствен- ность за сервис в итоге все равно несут представители заказчика. Как раз спо- собность подобрать подходящую схему распределения меры ответственности является одним из показателей уровня профессионализма специалистов. Иван Барановский, "АйТи Бастион" В первую очередь, это проблема фор- мализации и приземления ответственно- сти на реальные процессы. На бумаге все будет выглядеть логично: у оператора – физика, базовая сеть, иногда гиперви- зор; у заказчика – сервисы, доступы, эксплуатация, ИБ и подрядчики. Но в реальности ответственность размыва- ется и остается на уровне формулировок в договорах. Корень проблемы – в про- цессах: необходимо либо детально про- писывать зоны ответственности и сцена- рии взаимодействия (для чего необходи- ма постоянная актуализация), либо деле- гировать максимум функций по сервис- ной модели, оставляя за собой лишь контроль над ними. Это будет дороже, но значительно снизит операционную нагрузку и количество серых зон. Иван Барановский, "АйТи Бастион" Такая ситуация недопустима, ведь она ломает саму идеологию SOC как центра полной видимости. В таком случае кри- тично не просто собирать логи, но пол- ноценно контролировать доступ к инфра- структурным системам – с интеграцией Во время расследования инцидента выясняется, что часть серверов и сер- висов в инфраструктуре ЦОДа вообще отсутствует в системе учета активов. Компания размещает сер- висы в коммерческом ЦОДе. После инцидента выясняется, что разные команды по-разному пони- мают, кто отвечает за без- опасность сетевых сег- ментов и инфраструктур- ных доступов. После внедрения новой системы мониторинга выясняется, что часть событий инфраструктуры ЦОДа вообще не попадает в SOC. Например, измене- ния конфигурации сете- вых устройств и гиперви- зоров. 44 • СПЕЦПРОЕКТ Шесть тревожных сигналов из жизни ЦОДа Круглый стол экспертов инфраструктуре ЦОДов многие проблемы безопасности проявляются через обычные на первый взгляд ситуации. Но за такими эпизодами часто стоят системные архитектурные проблемы. Мы предложили экспертам разобрать несколько подобных сценариев и объ- яснить, какие риски и ошибки инфраструктуры они могут скрывать. В Эксперты: Иван Барановский, руководитель группы поддержки продаж, “АйТи Бастион” Алексей Карабась, эксперт, инженер в ЦОД Владислав Шелепов, аналитик угроз GSOC компании “Газинформсервис”