[Перевод] Как собирать данные в DevSecOps
Для успеха компании уже недостаточно, чтобы выпущенный продукт был «достаточно хорошим». Сегодня бизнесы должны предоставлять высококачественные цифровые сервисы, которые обладают не только высокой производительностью и степенью доступности, но и являются конфиденциальными и безопасными.
Но как всего этого достичь? Один из способов, доступных команде DevSecOps — реализовать систему наблюдаемости, использующую логи (и другие средства) для сбора больших объёмов данных во взаимодействиях пользователя и угрожающих средах. Выполняя логирование и анализ данных безопасности и наблюдаемости, можно лучше распознавать и устранять множество проблем, например, проблемы с производительностью, уязвимости и нарушения безопасности, что повышает качество сервисов.
В этой статье мы рассмотрим вопрос широкомасштабного сбора данных и, в частности, то, как в этом могут помочь логи. Мы разберём различия между данными наблюдаемости и безопасности, поговорим о том, как лучше собирать все эти данные. Затем мы посмотрим, как использовать эти данные для совершенствования приложения, а также узнаем, как реализовать централизованный единый механизм для сбора данных.
Что такое данные наблюдаемости? Что такое данные безопасности?
Наблюдаемость (observability) — это свойство систем, определяющее, что оператор может сказать о состоянии системы как в текущий момент, так и исторически. Исходя из этого, данные наблюдаемости — это описание такого состояния системы, например, процент ошибок, использование памяти и потоки трафика. Данные наблюдаемости могут быть сырыми данными, записанными из различных источников, или дискретизированными, агрегированными и обработанными данными.
Как это отличается от данных безопасности (security)?
Данные безопасности — это подмножество данных наблюдаемости, используемое для выявления угроз безопасности. Возможно, это определение кажется нечётким, но на самом деле так и есть!
Например, если у приложения высокое время отклика, то относятся ли эти данные к безопасности? Это зависит от разных аспектов. Возможно, приложение просто неправильно сконфигурировано для текущей нагрузки, или, возможно, нападающий скомпрометировал систему и выполняет полезную нагрузку, замедляющую всё остальное.
Даже то, что обычно не считается данными безопасности, может ими быть. Например, если для определённой библиотеки опубликован новый CVE, то вам нужно знать, какие сервисы зависят от этой версии библиотеки. А иногда очевидные случаи данных безопасности, например, идентификация вызывающего какую-то конечную точку API, могут оказаться полезными для выявления багов, не связанных с безопасностью.
В конечном итоге, можно сказать, что элемент данных наблюдаемости может быть данными безопасности… или не быть ими. Это зависит от специфики конкретного случая, которая часто неизвестна до происхождения события.
Три столпа данных наблюдаемости
При изучении данных наблюдаемости мы часто разбиваем их на три категории: логи, метрики и трассировки. Давайте рассмотрим их и узнаем, почему они могут относиться к данным и наблюдаемости, и безопасности.
▍ Логи
В логах фиксируются события с метками времени и создаётся временная шкала того, что происходит в системе. Например, приложение может отправить сообщение лога, если ему не удаётся подключиться к базе данных, или записать в логе аудита, какой пользователь выполнил определённое действие. В любой достаточно сложной системе есть множество различных логов. Основной аспект сбора данных наблюдаемости — это запись и упорядочивание таких логов в централизованной системе логирования для дальнейшей обработки.
Данные аналитики логов критически важны для мониторинга, устранения проблем и выявления проблем с надёжностью и безопасностью; они позволяют добраться до первопричины возникновения проблем. Данные логов часто являются самой подробной информацией о системах компаний, поэтому логично использовать эти данные, собирая файлы логов по всей организации для сквозного наблюдения и ускоренного решения проблем.
▍ Метрики
В то время как логи обычно содержат текстовую информацию, метрики — это числовые временные последовательности; например, количество готовящихся подов в кластере Kubernetes в динамике по времени. Метрики обычно записываются периодически, позволяя выявлять тренды и аномалии. Метрики гораздо экономнее логов. Они не требуют парсинга и преобразований, а их передача и хранение менее затратны. Метрики — основные показатели жизнедеятельности вашей системы. Системы алертов в основном создаются на основе метрик.
▍ Трассировки
Распределённая трассировка связывает с каждым запросом идентификатор. Трассировка запроса — это набор спанов и ссылок. Можно воспринимать трассировку как направленный ациклический граф, описывающий прохождение запроса через компоненты распределённой системы. Каждый спан фиксирует время, которое запрос провёл в компоненте, и ссылки на рёбра графа, соединяющие один спан с последующими спанами. Трассировки — очень важный инструмент для современных систем, создаваемых на основе микросервисов, бессерверных функций и очередей. Они предоставляют операторам системы «цепь ответственности», что критически важно для анализа проблем и с производительностью, и с безопасностью.
Как эти типы данных пересекаются с данными безопасности?
Почти вся информация о безопасности берётся из логов. Метрики и трассировки могут помочь понять, когда что-то не так (например, CPU имеет большую нагрузку), но чаще всего вы не поймёте, что конкретно происходит (в данном случае, нагрузка на CPU велика из-за криптомайнера), пока не изучите логи.
Как собирать данные
Разобравшись с данными наблюдаемости и безопасности, поняв, почему они важны и откуда берутся, мы можем рассмотреть более практические аспекты: как собирать данные и эффективно их использовать.
Давайте рассмотрим каждую категорию, рекомендации по их использованию и инструменты, которые могут в этом помочь. Эти этапы применимы ко всем вашим данным как наблюдаемости, так и безопасности.
▍ Логи
Вероятно в вашей ОС, Kubernetes и у поставщика облачных услуг генерируется много логов. Ваши приложения и стороннее ПО тоже генерируют файлы логов. Однако стандартные логи создают множество трудностей:
- Доступ к широкому спектру файлов логов на множестве хостов неэффективен и неудобен для пользователя.
- Файлы логов рано или поздно заполнят диск (если только вы не используете постоянное хранилище в облаке).
- Если вы выполняете ротацию файлов логов, чтобы решить проблему с пространством на дисках, то потеряете исторические данные.
- Время от времени происходят сбои серверов.
- Диски могут повреждаться.
Чтобы устранить эти проблемы, лучше всего использовать на каждом хосте агент для сбора логов, который передаёт логи на централизованную платформу наблюдаемости. Централизованная система управления логами сохраняет логи в надёжном хранилище, предоставляет интерфейс очереди, обеспечивает агрегирование и другие преобразования, а также хранит резервные копии логов для комплаенса и поиска исторических трендов.
Чтобы устранить часть проблем, рекомендуется использовать отраслевые стандарты и инструментарий наподобие OpenTelemetry. Для сбора данных, связанных с логами, есть популярные опенсорсные инструменты наподобие LogStash и Fluentd.
▍ Метрики
Метрики обрабатывать проще, чем логи, поскольку все метрики от любого источника можно представить единообразно как временные последовательности и связанный с ними набор меток. Аналогично сборщику логов, на каждом хосте можно запустить сборщик метрик и периодически считывать релевантные данные, например, использование CPU и памяти каждым процессом или текущее количество запросов, после чего отправлять их на платформу наблюдаемости.
Метрики уровня приложений можно собирать двумя способами: приложение может раскрывать стандартный интерфейс, скрейпингом которого занимается агент метрик, или же приложение можно оснастить таким образом (обычно при помощи библиотеки), чтобы оно отправляло метрики напрямую на платформу наблюдаемости. Данные захватываются через фиксированные интервалы и передаются на платформу наблюдаемости для анализа.
В сфере метрик бесспорным королём является Prometheus, спроектированный для скрейпинга конечных точек приложений, раскрывающих метрики приложения. Для визуализации метрик хорошо подходит Grafana.
▍ Трассировка
Трассировки собираются благодаря реализации в приложениях и сервисах функций перехвата запросов и добавления идентификатора, следующего за запросом при выполнении вызовов других сервисов. Трассировки отправляются на платформу наблюдаемости для анализа.
В области распределённых трассировок ведущим инструментом является Jaeger (изначально разработанный Uber). Среди прочих проектов можно обратить внимание на Zipkin и Signoz.
Как данные используются для повышения безопасности приложений?
Как использовать все эти данные для повышения безопасности приложений? Давайте рассмотрим роль, которую все эти элементы данных наблюдаемости могут играть в различных аспектах выявления инцидентов и реагирования на них.
Мы начнём с выявления инцидентов, для которого используются захват метрик с целью распознавания аномальной активности. Эти метрики, отслеживаемые платформой наблюдаемости, генерируют алерты, передаваемые команде DevSecOps.
На этом этапе команда знает только, что происходит что-то аномальное, но не знает, связан ли этот инцидент с безопасностью. Чтобы идентифицировать инцидент, критически важно изучить логи. Если инцидент связан с безопасностью, то команда может использовать логи для определения того, как злоумышленники получают доступ к системе, и блокировать дальнейшие злоупотребления, отключив доступ скомпрометированных пользователей или сервисов.
Далее команда может использовать комбинацию из логов, метрик и трассировок для оценки степени влияния проникновения, определяя, на какие части системы оно повлияло и произошла ли утечка данных. Зная масштабы проникновения, команда может уменьшить площадь поражения, сделав эти компоненты недоступными, пока они не будут исправлены.
Наконец, команда может использовать логи и метрики (в частности, при создании постмортема), которые помогают в анализе первопричин всех инцидентов. В результате могут быть предприняты следующие действия: ужесточение контроля доступа, патчинг уязвимых систем или совершенствование стратегии наблюдаемости.
Как это выглядит на практике?
Элитного уровня наблюдаемости можно достигнуть, интегрировав все источники данных и технологии в целостную систему, позволяющую делать выводы о системе.
Можно создать такой механизм самостоятельно при помощи уже упомянутых опенсорсных проектов. Хотя это обеспечивает высокую степень гибкости настроек, при этом требуется большой труд по созданию, обслуживанию и эксплуатации, особенно если вам нужна надёжная, масштабируемая и всегда доступная система. Кроме того, вам также понадобится наблюдать за своей платформой наблюдаемости.
Второй вариант — выбрать для решения задач наблюдаемости готовую платформу. Это позволяет вам сосредоточиться на своих основных компетенциях.
▍ Пример чёрной пятницы
Давайте рассмотрим пример, связанный с чёрной пятницей. Многие сайты, особенно в сфере розничной торговли, испытывают в такие дни всплеск активности пользователей; как использование данных и платформы доступности позволяет справляться с инцидентами безопасности? Мне показался интересным этот пост о том, как Ulta Beauty использовала метрики наподобие ошибочных попыток ввода пароля и попыток логина по IP-адресу и по стране, а также всех возможных показателей мошеннической активности.
Ulta передаёт эти метрики на платформу наблюдаемости Sumo Logic, предоставляющей дэшборд брутфорс-атак для помощи в выявлении инцидентов. Далее команда реагирования на инциденты может начать анализировать логи для определения и устранения первопричины инцидента безопасности.
Платформа Sumo Logic получает, агрегирует, обогащает и сохраняет все данные наблюдаемости. Sumo Logic позволяет выбирать, хотите ли вы устанавливать сборщики данных или у вас есть сборщики, работающие на AWS. Также она обеспечивает интеграцию с такими популярными инструментами, как Prometheus и OpenTelemetry, что может облегчить процесс миграции и уменьшить проблемы, связанные с зависимостью от услуг Sumo Logic.
Заключение
Крупномасштабный сбор данных наблюдаемости и безопасности — важнейший фактор обеспечения высокого качества услуг. Чтобы преуспеть, вам нужно полагаться на все три категории данных наблюдаемости: логи, метрики и распределённые трассировки. Вам потребуются эти данные для распознавания, изолирования и устранения атак.
Играй в нашу новую игру прямо в Telegram!
