Технический долг или угроза безопасности?

Хаос в конфигурациях сетевого оборудования перестаёт быть просто техническим долгом в тот момент, когда из-за него теряется контроль над доступом, сегментацией, маршрутизацией и управлением самими устройствами.

Если ошибка, забытое правило или непонятное «наследие» в конфигурации сети может дать злоумышленнику лишний доступ в инфраструктуру компании, помочь обойти сегментацию, открыть управление или скрыть атаку, возникает угроза безопасности.

Текучка кадров, оборудование, доставшееся в наследство от предшественников, отсутствие единых стандартов и подходов к именованию, а главное, отсутствие журналов или систем регистрации, где отображены все изменения, порождают появление беспорядочных конфигураций. Это могут быть хаотичные имена списков контроля доступа (ACL), виртуальных локальных сетей (VLAN), сетевых объектов, групп и интерфейсов; нередко встречаются дублирующие друг друга правила, можно найти старые комментарии администраторов и даже разные стили настройки на одинаковых устройствах, выполненные разными сотрудниками в разное время.

Такой беспорядок представляет критическую угрозу безопасности инфраструктуры компании, если способен повлиять на один из контуров:

• управляющий доступ к устройствам;

• сегментацию сети;

• правила фильтрации;

• маршрутизацию;

• механизмы защиты и управления самим устройством;

• мониторинг и логирование. 

Почему не работают правила?

Казалось бы, справиться с беспорядком поможет внедрение управления сетевыми конфигурациями. Однако случается, что на практике такие политики (наборы правил, механизмов и документов) никто не соблюдает. Подобная ситуация может возникнуть по нескольким причинам:

• система управления конфигурациями не отражает реальную сеть, а содержит некий набор общих рекомендаций;

• система построена без учёта пожеланий или вопреки запросам основных участников процесса изменений, плохо подобрана, сложна в настройке и администрировании;

• управление конфигурациями не встроено в процесс изменений, и у администраторов остаётся возможность вносить и изменять конфигурации вручную;

• управление конфигурациями не предусматривает механизмы автоматических изменений и автоматизации проверок;

• система существенно замедляет работу или создаёт бóльшую нагрузку на администратора, чем это было до внедрения;

• отсутствует ответственное лицо, которое следит за производительностью и бесперебойностью работы системы;

• использование конфигураций в обход системы управления не предусматривает каких-либо последствий.

Внедрение качественной системы контроля и управления конфигурациями может решить перечисленные проблемы.

Ответственность ИТ и ИБ

Что может быть проще настройки оборудования для его стабильной работы? В теории кажется, что всё просто. Однако надо помнить, что в процессе управления конфигурациями участвуют две стороны: ИТ-департамент отвечает за реализацию и доступность, подразделение или отдел ИБ — за обязательные требования, контроль и аудит.

Важно разделить зоны ответственности ИТ- и ИБ-департаментов, чтобы избежать конфликта интересов, за время решения которого степень информационной защиты организации может быть снижена.

ИТ отвечает за:

• работоспособность сервиса;

• внедрение изменений;

• корректность технической реализации;

• эксплуатацию, отказоустойчивость, восстановление;

• соблюдение утверждённых стандартов в конфигурации.

ИБ отвечает за:

• формирование требований безопасности;

• описание типовой конфигурации и политик безопасности;

• формирование критериев допустимости риска;

• согласование исключений, создание процесса согласования внедрения компенсирующих мер;

• контроль выполнения требований и аудит.

На практике эти границы могут размываться, поэтому следует обозначать внутренними документами зоны ответственности за департаментами или конкретными сотрудниками.

Если нужен видимый результат

С чего стоит начать, чтобы получить видимый результат в обозримом будущем? Рекомендуется начинать не со всей инфраструктуры, а с того, что одновременно влияет на риск, стабильность, часто меняется и относительно легко стандартизуется. Для управления сетевыми конфигурациями лучше всего начать с критичных устройств, их конфигураций, внедрения резервных копий и отслеживания изменений.

В первую очередь управление конфигурациями стоит внедрять:

• на межсетевых экранах на периметре;

• на VPN-шлюзах;

•  на коммутаторах или маршрутизаторах на корневом уровне или уровне дистрибуции.

Как правило, такого оборудования в компаниях немного, и потому эффект от контроля за конфигурациями будет виден достаточно быстро, всего через 2–3 месяца. 

Разнородность инфраструктуры

После первых шагов по внедрению системы управления конфигурациями можно приступать к другим задачам, например переходить к подключению более массовых типов оборудования, таких как коммутаторы распределения и доступа. Здесь уже не стоит рассчитывать на быстрый и видимый результат. Как правило, сетевая инфраструктура отечественных компаний разнородна, насчитывает десятки типов оборудования как российского, так и иностранного производства. Для работы с таким разнообразием решений необходимо провести инвентаризацию и уточнить версии оборудования. Только сформировав перечни, можно переходить к обеспечению резервирования конфигураций, контролю изменений и проведению базовых проверок требований безопасности.

При переходе к массовому управлению изменениями в автоматическом режиме, управлению промышленными устройствами или устаревшими моделями оборудования возникают многочисленные проблемы и трудности. Крупные заказчики, имеющие необходимые финансовые и материальные ресурсы, внедряют собственные системы управления конфигурациями, полностью закрывающие их потребности. Остальные потребители вынуждены ждать доработки текущих решений или появления нового универсального инструмента, который будет поддерживать их парк оборудования. 

Единый механизм управления

Управление конфигурациями можно интегрировать с процессами управления уязвимостями и мониторингом инцидентов для усиления друг друга. В таком случае необходимо построить единый механизм управления конфигурациями и определения уязвимостей в них, создания инцидентов в ответ на определённую уязвимость и внесения изменений в базовые настройки для предотвращения возникновения таких инцидентов в будущем.

Схематично это можно показать следующим образом:

конфигурация → уязвимость → событие/инцидент → изменение конфигурации → контроль эффекта.

В итоге правильно связанные системы должны обеспечивать следующие процессы:

• управление конфигурациями даёт фактическое состояние;

• управление уязвимостями сообщает, что в этом состоянии опасно;

• мониторинг инцидентов показывает, где опасность стала реальной. 

Новые среды — новая логика

При управлении конфигурацией в облачной инфраструктуре, контейнерных средах или при использовании методологии автоматизации процессов развёртывания и управления инфраструктурой с помощью кода и конфигурационных файлов (Infrastructure as a Code) подход смещается от управления конфигурацией отдельных серверов и устройств к управлению желаемым состоянием сервисов, платформ и политик. На смену привычному подключению к системе и изменению конфигурации приходит новая логика:

• необходимо описать состояние в коде или системе управления;
• применить новое состояние через пайплайн;
• пайплайн перед применением автоматически запускает различные проверки и тесты, может применяться стейдж-инфраструктура;
• при возникновении проблем в пайплайне система возвращается в исходное состояние.

Подводя итог, можно сделать вывод, что хорошая система управления конфигурациями требует в первую очередь наведения порядка в конфигурациях сетевого оборудования и закрытия различного рода технических долгов, тщательного подбора самой системы, согласованной работы департаментов ИТ и ИБ. Такой подход позволит сохранить контроль над ИТ-инфраструктурой компании и минимизировать поверхность атаки для злоумышленника.

Дмитрий Кушнерёв, эксперт отдела сетевых технологий Angara Security