OpenTelemetry всё чаще используют в легаси-системах, потому что компании открывают для себя современные инструменты для организации наблюдаемости (observability) за системой. Но применение этих инструментов в промышленых системах создаёт дополнительные проблемы с безопасностью. Ограничения легаси-инфраструктуры принципиально меняют то, где и как следует применять защитные меры.
В легаси-средах часто встречаются:
Системы, которые нельзя модифицировать или инструментировать.
Оборудование с длительным жизненным циклом и редкими окнами для установки обновлений.
Плоские сети, или сети со слабой сегментацией.
Конфиденциальные оперативные данные, которые не относятся к привычным персональным данным (ПДн).
В этой статье рассказывается о том, чем отличается обеспечение безопасности OpenTelemetry в таких средах и как соответствующим образом адаптировать свой подход.
Чем отличаются легаси-среды
Рекомендации по безопасности для нативных облачных систем (cloud native systems) обычно исходят из того, что:
В сервисы можно встроить инструменты для отслеживания их состояния.
Шифрование и аутентификацию можно сделать обязательными во всей системе.
Компоненты можно регулярно обновлять.
В промышленных и легаси-средах эти условия часто невыполнимы.
Задача состоит не в том, чтобы повсеместно внедрить идеальный набор защитных мер. Важно выбрать правильные точки контроля в конвейере телеметрии и найти баланс между наблюдаемостью и риском.
Проблемы безопасности легаси-систем
Системы нельзя модифицировать
Во многих промышленных системах невозможно запустить агент, подключить современные библиотеки или вообще внести какие-либо изменения. Из этого следуют несколько ограничений:
Источник телеметрии может не поддерживать современные версии TLS и механизмы аутентификации либо поддерживать их лишь частично.
Прямое добавление инструментов для отслеживания состояния системы с помощью SDK невозможно.
Приходится использовать промежуточные компоненты: OpenTelemetry Collector, мосты и конвейеры обработки логов.
Если в исходную систему нельзя внедрить современные средства защиты, основная нагрузка переносится на Collector, промежуточные компоненты и сетевые границы.
Слабая сегментация сети или её отсутствие
Архитектура легаси-сетей проектировалась без учёта современного подхода к наблюдаемости. Одни системы работают в плоской или общей сети почти без сегментации. Другие, наоборот, находятся в глубоко вложенных сетевых сегментах, где одновременно используются устаревшие и современные протоколы. В обоих случаях внедрение сбора телеметрии может:
Открыть эндпоинты приёма данных для тех сегментов сети, которым доступ не предназначался.
Сделать Collector или мосты доступными для других узлов сети, которым доступ не предполагался.
Сформировать новые пути передачи данных между ранее изолированными зонами.
В таких средах место размещения Collector не менее важно, чем его конфигурация. Необходимо тщательно оценить его положение относительно сетевых границ, межсетевых экранов и шлюзов между протоколами.
Редкие обновления и длительный жизненный цикл
Промышленные системы могут работать годами без обновлений. Стратегия их установки зависит от того, как именно развёрнут Collector. Чаще всего используют одну из двух моделей.
Collector как внешний мост (рекомендуемый вариант)
Collector работает за пределами контура легаси-системы на отдельном сервере, виртуальной машине или в контейнере и связывает промышленную среду с серверной частью платформы наблюдаемости. При такой схеме:
Collector можно исправлять и обновлять независимо от легаси-системы.
На проблемы безопасности цепочки поставок ПО можно реагировать сразу.
Легаси-система остаётся неизменной и стабильной.
Collector внутри легаси-среды
Collector запускается рядом с легаси-системой или внутри неё и подчиняется тем же процедурам управления изменениями и тем же окнам обслуживания. В этом случае:
Оперативная установка исправлений может оказаться невозможной.
Критически важными становятся компенсирующие меры защиты.
Нужно заранее предусмотреть работу на старых версиях Collector и отслеживать уязвимости, чтобы оценивать риски в период между выявлением уязвимости и установкой исправления.
Если возможно, то лучше выбрать модель внешнего моста. Она чётко разделяет зоны ответственности и позволяет обслуживать конвейер телеметрии по современному жизненному циклу, даже когда обновлять исходные системы нельзя.
Если внешний мост использовать невозможно, то акцент нужно перенести с установки обновлений на изоляцию и снижение риска:
Изолировать уязвимые компоненты от остальной сети.
Ограничить Collector входящий и исходящий сетевой доступ.
Отключить ненужные маршруты передачи телеметрии и лишние компоненты.
Постоянно отслеживать сообщения об уязвимостях и оценивать текущий уровень риска.
В таких средах конфиденциальными считаются другие данные
На производстве к конфиденциальной информации нередко относятся:
Параметры производственных процессов и настройки оборудования.
Идентификаторы активов и сведения об их текущем состоянии.
Показатели работы предприятия или отдельной производственной площадки.
Конвейер телеметрии нужно проектировать так, чтобы эти сведения не покидали контролируемый контур.
Как спроектировать безопасный конвейер телеметрии с учётом ограничений
Если защитить исходные системы напрямую нельзя, основной точкой контроля становится сам конвейер телеметрии.
При его проектировании стоит придерживаться следующих принципов.
Ограничивайте точки приёма данных. Не открывайте конечные точки Collector для всей сети. Привязывайте их только к нужным сетевым интерфейсам и ограничивайте доступ к ним.
Классифицируйте данные по уровню доверия к источнику. Учитывайте, каким способом поступила телеметрия. Например, данным, полученным по каналу без аутентификации, такому как многоадресная рассылка UDP, нельзя доверять так же, как данным, переданным по каналу с mTLS. Помечайте телеметрию с помощью ресурсных атрибутов или метаданных, указывающих контекст её получения. Тогда последующие компоненты смогут применять соответствующие политики доверия и доступа.
Изолируйте компоненты-мосты. MQTT-мосты, сборщики логов и адаптеры протоколов должны работать в контролируемых сегментах и не быть доступны напрямую.
Сведите число открытых компонентов к минимуму. По мере развития легаси-инфраструктуры в ней могут накапливаться уже ненужные компоненты. Регулярно проверяйте конфигурацию Collector и оставляйте включёнными только те компоненты приёма данных и компоненты отправки данных, которые действительно нужны для текущих задач наблюдаемости. Это уменьшает поверхность атаки, что особенно важно там, где обновления устанавливают редко.
По возможности обрабатывайте данные внутри доверенного контура. Собирайте и преобразуйте телеметрию до её отправки во внешние системы. На уровне Collector используйте компоненты обработки, чтобы фильтровать, маскировать или преобразовывать данные. Так за сетевую границу уйдёт меньше информации, а её чувствительность снизится.
OpenTelemetry Collector следует рассматривать не просто как маршрутизатор данных, а как контролируемую границу. Такой подход согласуется с принципами Zero Trust: доступ и потоки данных явно ограничиваются, а расположение внутри сети само по себе не считается гарантией безопасности.
Практическая модель выбора средств защиты телеметрии
Выбрать способ получения телеметрии и подходящие защитные меры можно по следующему алгоритму:
Как работать с конфиденциальными оперативными данными
Инструменты OpenTelemetry не способны самостоятельно определить, какие данные важны для бизнеса и требуют защиты. Это должен решить специалист, внедряющий систему. Здесь важны два принципа.
Минимизация данных
Собирайте только ту телеметрию, которая решает конкретную задачу. В средах с жёсткими ограничениями:
Не сохраняйте содержимое пакетов или сообщений целиком, если в этом нет необходимости.
Предпочитайте агрегированные показатели исходным данным.
Регулярно пересматривайте набор собираемых атрибутов.
Очистка и преобразование данных
В зависимости от дистрибутива и версии Collector можно использовать такие processors, как transform и redaction. Они позволяют хешировать идентификаторы, удалять конфиденциальные поля и задавать списки разрешённых атрибутов.
Например, идентификатор пользователя можно заменить его хешем:
processors: transform/hash_user: trace_statements: - context: span statements: - set(attributes["user.hash"], SHA256(attributes["user.id"])) - delete_key(attributes, "user.id")
Другой вариант — разрешить только строго определённые атрибуты:
processors: redaction/strict: allow_all_keys: false allowed_keys: - id - name - status
В легаси-средах Collector часто оказывается единственной точкой, в которой данные вообще можно контролировать.
Как уменьшить поверхность атаки
Каждый компонент конвейера телеметрии создаёт дополнительный риск. Особенно важно учитывать это в средах, где сами системы почти не способны противостоять угрозам. Поэтому следует:
Сократить число активных receivers и exporters.
Исключить ненужный доступ извне.
Запускать Collector с минимально необходимыми правами.
Принимать входящий трафик только от известных и доверенных источников.
Чем меньше инфраструктура телеметрии и число доступных извне конечных точек, тем меньше поверхность атаки.
Безопасность всегда требует компромиссов
В современных системах часто стремятся добиться максимально полной наблюдаемости. В легаси-средах эту цель приходится сопоставлять с другими требованиями:
Стабильностью системы.
Ограничениями, связанными с функциональной безопасностью.
Ограниченным контролем над источниками данных.
Поэтому меняется и сам подход: задача состоит не в том, чтобы добиться идеальной наблюдаемости, а в том, чтобы получить действительно полезную информацию наиболее безопасным способом.
Заключение
В средах операционных технологий и на промышленных объектах любые изменения, связанные с телеметрией, нужно оценивать не только с точки зрения кибербезопасности. Необходимо также учитывать требования к функциональной безопасности, надёжности и управлению изменениями.
OpenTelemetry даёт возможность внедрить современную наблюдаемость в промышленных и легаси-системах, но при этом меняется расположение и характер точек контроля. Вместо того чтобы полагаться на защиту источников данных, командам необходимо:
Защищать сам конвейер телеметрии.
Тщательно контролировать раскрытие и передачу данных.
Проектировать решение с учётом ограничений и несовершенства существующих систем.
Так организация сможет получить полезную информацию о работе систем, не игнорируя реальные ограничения традиционной инфраструктуры.