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

В ИБ много говорят о целевых атаках, уязвимостях 0-day и APT-группировках. Однако если внимательно посмотреть на причины серьезных инцидентов последних лет, картина оказывается более прозаичной. Во многих случаях атакующие лишь воспользовались тем, что система уже была небезопасна. И причиной этого стала не злонамерен- ная активность каких-либо сотрудников организации, а накопленные изменения в конфигурациях – так называемый Con- figuration Drift, или дрейф конфигураций. По данным Fidelis Security от ноября 2025 г., неправильная настройка облач- ных сервисов является причиной до 99% сбоев в системе безопасности. BI.ZONE TDR сообщает, что в среднем на одну конечную точку приходится 2-3 мискон- фигурации – то есть, статистически, они присутствуют почти везде и постоянно. По оценке Yandex Cloud, в первом полу- годии 2025 г. конечной целью 76% разо- бранных атак были облачные базы дан- ных и S3-хранилища, при этом среди хронических недостатков, на которые опираются атакующие, прямо названы ошибки конфигурации. По мнению спе- циалистов управления по организации борьбы с противоправным использова- нием информационно-коммуникацион- ных технологий МВД России, ошибки конфигурации относятся к основным угрозам облачной безопасности. При- меры можно приводить бесконечно. Рассматривая конкретные инциденты, становится очевидно, что в подавляю- щем большинстве случаев никто изна- чально не планировал делать инфра- структуру небезопасной. Изменения в конфигурации вносились по делу – при обновлении и модернизации, внедрении новых мощностей, для срочной интегра- ции, для устранения другого инцидента, при автоматических внесениях измене- ний, предоставлении временных досту- пов и прочее. Но, как часто бывает, планы разошлись с реальностью, и про- изошло это не сразу, а постепенно. Такая постепенность и является ключе- вой первопричиной проблем. Дрейф кон- фигураций – медленное поэтапное и неконтролируемое расхождение факти- ческой конфигурации системы с эта- лонной архитектурой или политикой без- опасности. Это явление происходит, когда мы делаем временные исключения из правил, а потом точечные изменения накапливаются, и их уже никто не конт- ролирует. Или когда мы автоматизируем какой-то процесс, но не проводим после- дующую валидацию результата. Приме- ры, которые хорошо знакомы любому специалисту по ИБ: временно добавили правило на межсетевом экране, настрои- ли NAT для пилотного проекта, изменили параметр операционной системы ради совместимости, собрали контейнер с dev-настройками и забыли пересобрать. Дрейф конфигураций – это не еди- ничная ошибка, а процесс, который неизбежно возникает практически в любой инфраструктуре. Чем активнее развивается ИТ-ландшафт, тем быстрее накапливается расхождение между тем, как должно быть, и тем, как есть на самом деле. Что со всем этим делать и как решить проблему? Первая реакция – усилить проверки на наличие уязвимостей. Однако реше- ния класса Vulnerability Management пока- зывают CVE, не отвечая на вопросы, которые относятся к архитектуре без- опасности: нарушена ли сегментация, появились ли неожиданные маршруты трафика, соответствует ли фактическое состояние политике безопасности. Уязвимости характеризуют состояние отдельных компонентов системы, в то время как дрейф конфигураций – это состояние всей системы в целом. SIEM также не решает проблему. Системы этого класса фиксируют уже совершившиеся события и подозритель- ную активность, связанные с послед- ствиями, которые произошли в том числе из-за некорректной конфигурации. Но сам дрейф конфигураций – это не собы- тие, а фоновое состояние среды (систе- мы). Когда SIEM фиксирует подозрение на инцидент, расхождение в конфигура- циях уже накопилось. Для отслеживания изменений в кон- фигурациях можно разработать опреде- ленные регламенты, а также проводить с некоторой периодичностью аудиты для фиксации состояния системы в конкрет- ный момент времени. Однако аудит – как правило, ежегодное мероприятие. Инфраструктура же меняется каждый день. Дрейф конфигураций возникает именно между аудитами, в повседневной операционной деятельности. Во многих организациях службы ИБ научились обнаруживать атаки и выявлять нарушения политик безопас- ности, но остается проблема системного контроля среды, в которой эти наруше- ния происходят. Для реального решения проблемы дрейфа конфигураций необхо- димо сместить фокус: нужно контроли- ровать не только то, что произошло, но и то, какой система должна быть, что в ней изменилось и к каким послед- ствиям это может привести. На уровне сети это означает: l ведение защищенной базы конфигу- раций сетевого оборудования; l построение актуальной карты тополо- гии с учетом NAT и VPN; l моделирование маршрутов прохож- дения трафика; l проверку соответствия стандартам и лучшим практикам; l оценку влияния планируемых измене- ний до их внедрения. Все это позволяет ответить на управ- ленческий вопрос: действительно ли сег- ментация работает так, как задокументи- ровано? Может ли трафик пройти по марш- руту, о котором никто не подозревает? На уровне узлов и приложений конт- роль включает в себя: l контроль целостности файлов; l мониторинг изменений конфигураций ОС и прикладного ПО; l проверку соответствия требованиям регуляторов и корпоративных стандартов; l контроль защищенности контейнеров и средств оркестрации; 50 • ТЕХНОЛОГИИ Невидимая угроза: дрейф конфигураций разрушает архитектуру кибербезопасности начительная часть серьезных инцидентов происходит не из-за новых уязвимостей, а из-за ошибок и несовершенства процес- са изменения конфигураций, которые накапливались месяца- ми или даже годами. З Сергей Овчинников, директор продуктового департамента компании “Газинформсервис” Фото: Газинформсервис