Значительная часть серьезных инцидентов происходит не из-за новых уязвимостей, а из-за ошибок и несовершенства процесса изменения конфигураций, которые накапливались месяцами или даже годами.
Автор: Сергей Овчинников, директор продуктового департамента компании “Газинформсервис”
В ИБ много говорят о целевых атаках, уязвимостях 0-day и APT-группировках. Однако если внимательно посмотреть на причины серьезных инцидентов последних лет, картина оказывается более прозаичной. Во многих случаях атакующие лишь воспользовались тем, что система уже была небезопасна. И причиной этого стала не злонамеренная активность каких-либо сотрудников организации, а накопленные изменения в конфигурациях – так называемый Configuration Drift, или дрейф конфигураций.
По данным Fidelis Security от ноября 2025 г., неправильная настройка облачных сервисов является причиной до 99% сбоев в системе безопасности. BI.ZONE TDR сообщает, что в среднем на одну конечную точку приходится 2-3 мисконфигурации – то есть, статистически, они присутствуют почти везде и постоянно. По оценке Yandex Cloud, в первом полугодии 2025 г. конечной целью 76% разобранных атак были облачные базы данных и S3-хранилища, при этом среди хронических недостатков, на которые опираются атакующие, прямо названы ошибки конфигурации. По мнению специалистов управления по организации борьбы с противоправным использованием информационно-коммуникационных технологий МВД России, ошибки конфигурации относятся к основным угрозам облачной безопасности. Примеры можно приводить бесконечно.
Рассматривая конкретные инциденты, становится очевидно, что в подавляющем большинстве случаев никто изначально не планировал делать инфраструктуру небезопасной. Изменения в конфигурации вносились по делу – при обновлении и модернизации, внедрении новых мощностей, для срочной интеграции, для устранения другого инцидента, при автоматических внесениях изменений, предоставлении временных доступов и прочее. Но, как часто бывает, планы разошлись с реальностью, и произошло это не сразу, а постепенно. Такая постепенность и является ключевой первопричиной проблем. Дрейф конфигураций – медленное поэтапное и неконтролируемое расхождение фактической конфигурации системы с эталонной архитектурой или политикой безопасности. Это явление происходит, когда мы делаем временные исключения из правил, а потом точечные изменения накапливаются, и их уже никто не контролирует. Или когда мы автоматизируем какой-то процесс, но не проводим последующую валидацию результата. Примеры, которые хорошо знакомы любому специалисту по ИБ: временно добавили правило на межсетевом экране, настроили NAT для пилотного проекта, изменили параметр операционной системы ради совместимости, собрали контейнер с dev-настройками и забыли пересобрать.
Дрейф конфигураций – это не единичная ошибка, а процесс, который неизбежно возникает практически в любой инфраструктуре. Чем активнее развивается ИТ-ландшафт, тем быстрее накапливается расхождение между тем, как должно быть, и тем, как есть на самом деле.
Что со всем этим делать и как решить проблему?
Первая реакция – усилить проверки на наличие уязвимостей. Однако решения класса Vulnerability Management показывают CVE, не отвечая на вопросы, которые относятся к архитектуре безопасности: нарушена ли сегментация, появились ли неожиданные маршруты трафика, соответствует ли фактическое состояние политике безопасности. Уязвимости характеризуют состояние отдельных компонентов системы, в то время как дрейф конфигураций – это состояние всей системы в целом.
SIEM также не решает проблему. Системы этого класса фиксируют уже совершившиеся события и подозрительную активность, связанные с последствиями, которые произошли в том числе из-за некорректной конфигурации. Но сам дрейф конфигураций – это не событие, а фоновое состояние среды (системы). Когда SIEM фиксирует подозрение на инцидент, расхождение в конфигурациях уже накопилось.
Для отслеживания изменений в конфигурациях можно разработать определенные регламенты, а также проводить с некоторой периодичностью аудиты для фиксации состояния системы в конкретный момент времени. Однако аудит – как правило, ежегодное мероприятие. Инфраструктура же меняется каждый день. Дрейф конфигураций возникает именно между аудитами, в повседневной операционной деятельности.
Во многих организациях службы ИБ научились обнаруживать атаки и выявлять нарушения политик безопасности, но остается проблема системного контроля среды, в которой эти нарушения происходят. Для реального решения проблемы дрейфа конфигураций необходимо сместить фокус: нужно контролировать не только то, что произошло, но и то, какой система должна быть, что в ней изменилось и к каким последствиям это может привести.
На уровне сети это означает:
- ведение защищенной базы конфигураций сетевого оборудования;
- построение актуальной карты топологии с учетом NAT и VPN;
- моделирование маршрутов прохождения трафика;
- проверку соответствия стандартам и лучшим практикам;
- оценку влияния планируемых изменений до их внедрения.
Все это позволяет ответить на управленческий вопрос: действительно ли сегментация работает так, как задокументировано? Может ли трафик пройти по маршруту, о котором никто не подозревает?
На уровне узлов и приложений контроль включает в себя:
- контроль целостности файлов;
- мониторинг изменений конфигураций ОС и прикладного ПО;
- проверку соответствия требованиям регуляторов и корпоративных стандартов;
- контроль защищенности контейнеров и средств оркестрации;
- формирование рекомендаций по приведению системы к эталону.
В результате организация переходит от управления политиками безопасности к контролируемому состоянию безопасности, которое подтверждается реальными фактами.
Может показаться, что такой подход, основанный на непрерывном контроле конфигураций, является слишком сложным, и на его внедрение можно потратить годы. Но на практике сложность возникает как раз из-за отсутствия контроля. Когда изменения накапливаются стихийно, а расследование инцидента превращается в ручной анализ истории всех правок в конфигурационных фай- лах, что действительно сложно и долго. Контроль конфигураций фиксирует текущее состояние системы и делает изменения управляемыми. Сложность не исчезает, но становится локализованной и предсказуемой.
Многие изменения в конфигурациях происходят с помощью средств автоматизации, которая, конечно же, ускоряет изменения, но не гарантирует их корректность. Если в используемых инструментах нет встроенного механизма для проверки соответствия конечного состояния системы заданной архитектуре и политикам, то дрейф возникает быстрее, чем при ручных настройках. Контроль конфигураций помогает замкнуть цикл: изменение – проверка – подтверждение соответствия.
Какие выгоды дает контроль конфигураций?
На операционном уровне контроль конфигураций снижает количество инцидентов, вызванных накопленными негативными изменениями. Инженеры быстрее понимают текущее состояние среды, сокращается время расследования, снижается зависимость от человеческого фактора, который связан с наличием в штате сотрудников, владеющими "тайными знаниями" о ключевых настройках оборудования, общесистемного ПО и прикладных систем. Таким образом, безопасность становится частью повседневной эксплуатации.
На управленческом уровне CISO получает регулируемость и предсказуемость изменений. Появляется возможность на основе фактов подтверждать соответствие политики безопасности реальному состоянию инфраструктуры, оценивать риски до внедрения изменений и аргументированно обосновывать решения перед руководством.
На стратегическом уровне контроль конфигураций повышает зрелость архитектуры безопасности. Он создает основу для Zero Trust, автоматизированного реагирования и зрелого риск-менеджмента. Организация перестает бороться с последствиями и начинает управлять состоянием среды, масштабируя инфраструктуру без пропорционального роста рисков.
Configuration Drift – не техническая мелочь и не вопрос аккуратности администраторов. Это системное явление, которое неизбежно происходит в развивающейся ИТ-инфраструктуре. Игнорировать его – значит соглашаться с тем, что архитектура безопасности постепенно разрушается под давлением изменений.
В практической плоскости описанный подход реализуется через сочетание контроля сетевой архитектуры и контроля состояния узлов. В составе платформы Efros DefOps1 эти задачи решаются модулями Network Assurance и Integrity Check Compliance, которые охватывают сетевой и хостовый уровни и позволяют выстроить непрерывный контроль конфигураций как процесс, а не как разовую проверку.
Network Assurance (NA) фокусируется на сетевой инфраструктуре – той части ИТ-ландшафта, где дрейф особенно опасен, потому что напрямую влияет на маршруты трафика и границы сегментации. Решение формирует защищенную и актуальную базу конфигураций активного сетевого оборудования, анализирует их на соответствие стандартам и лучшим практикам, выявляет известные уязвимости (в соответствии с БДУ ФСТЭК, CVE, OVAL и др.). NA отображает топологию сети на интерактивной карте, моделирует маршруты прохождения заданного типа трафика и позволяет оценить, как изменится картина безопасности при внесении тех или иных изменений. Это принципиально важно, так как организация получает возможность увидеть потенциальный дрейф конфигураций до того, как он станет реальностью.
Отдельную ценность представляет контроль целостности конфигураций сетевого оборудования и возможность оперативного восстановления. В условиях, когда изменения вносятся часто, например в рамках проектов, инцидентов или модернизации, наличие эталонного состояния и механизма отслеживания отклонений позволяет удерживать конфигурации в управляемых границах. Таким образом, с помощью NA закрывается именно та часть проблемы, которая остается слепой зоной для классических VM и SIEM: соответствие реальной топологии сети той модели, которая изначально была задумана.
Если NA отвечает на вопрос "как устроена и работает сеть на самом деле", то Integrity Check Compliance (ICC) дает ответ на вопрос "в каком состоянии находятся системы и приложения". ICC обеспечивает контроль целостности файлов в различных операционных системах и средах виртуализации, отслеживает изменения конфигураций ОС и прикладного ПО, включая СУБД, системы виртуализации и другие критически важные компоненты. Это позволяет фиксировать и анализировать отклонения не только на уровне параметров, но и на уровне конкретных объектов защиты.
Важной частью ICC является осуществление проверок соответствия (Compliance) объектов защиты требованиям регуляторов, корпоративным стандартам безопасности. Таким образом, контроль конфигураций перестает быть исключительно технической задачей и становится инструментом управляемости и доказуемости соответствия. При выявлении отклонений система формирует рекомендации по внесению изменений для соответствия стандартам безопасности, что переводит процесс из режима обнаружения проблемы в практическую плоскость ее устранения.
В связке Efros DefOps NA и Efros DefOps ICC реализуется именно та концепция, о которой шла речь в статье, то есть переход от декларативного управления политиками к подтвержденному состоянию безопасности. NA обеспечивает прозрачность и управляемость сетевой архитектуры, а ICC – контроль состояния операционных систем и приложений. Вместе они позволяют не просто фиксировать последствия изменений, а системно удерживать инфраструктуру в заданных границах, предотвращая накопление дрейфа конфигураций и снижая вероятность возникновения инцидентов.
Реклама: ООО «Газинформсервис». ИНН 7838017968. Erid: 2SDnjdYXqd4