Полное руководство по сбору данных в DevSecOps
6 января 2023 г.Для успеха предприятия уже недостаточно запустить продукт, который «достаточно хорош». Сегодня компании должны предоставлять цифровые возможности высокого качества, которые не только эффективны и доступны, но также конфиденциальны и безопасны.
Но как всего этого добиться? Один из способов заключается в том, чтобы команды DevSecOps внедрили практику наблюдения, которая использует журналы (и другие средства) для сбора большого количества данных о вашем пользовательском опыте и средах угроз. Регистрируя и анализируя как данные о безопасности, так и данные об наблюдаемости, вы можете лучше обнаруживать и устранять множество проблем, таких как проблемы с производительностью, уязвимости и нарушения безопасности, что повышает качество работы.
В этой статье мы сосредоточимся на тонкостях широкомасштабного сбора данных, а также на том, чем, в частности, могут помочь журналы. Мы рассмотрим разницу между данными наблюдаемости и данными безопасности и как лучше собрать все эти данные. Затем мы рассмотрим, как использовать эти данные для улучшения вашего приложения, и, наконец, посмотрим, как реализовать централизованный универсальный магазин для сбора данных.
Что такое наблюдаемые данные? Что такое данные безопасности?
Наблюдаемость — это свойство систем, определяющее, что оператор может сообщить о состоянии системы как в настоящее время, так и в прошлом. Исходя из этого, данные наблюдаемости — это представление состояния системы — например, процент ошибок, использование памяти и поток трафика. Данные наблюдаемости могут быть необработанными данными, записанными из различных источников, или данными с уменьшенной выборкой, агрегированными и обработанными данными.
Чем это отличается от данных безопасности?
Данные безопасности – это подмножество ваших данных для наблюдения, которые используются для обнаружения угроз безопасности. Если это кажется нечетким, это потому, что это так!
Например, если приложение демонстрирует медленное время отклика, это данные безопасности? По-разному. Возможно, приложение просто неправильно настроено для текущей нагрузки, или злоумышленник взломал систему и запускает рабочую нагрузку, которая замедляет работу.
Даже то, что обычно не считается данными безопасности, может быть таковым. Например, если раскрывается новый CVE для конкретной библиотеки, вам необходимо знать, какие службы зависят от этой версии библиотеки. А иногда явные данные о безопасности — например, личность вызывающего абонента к какой-либо конечной точке API — также оказываются полезными для отслеживания ошибок, не связанных с безопасностью.
В конце концов, мы можем сказать, что часть наблюдаемых данных может быть данными безопасности… а может и нет. Это зависит от специфики варианта использования, о которой часто ничего не известно до тех пор, пока это не произойдет.
Три столпа наблюдаемых данных
Когда мы рассматриваем данные об наблюдаемости, мы часто разбиваем их на три компонента: журналы, метрики и трассировки. Давайте посмотрим на них и на то, как они могут применяться как к наблюдаемым данным, так и к данным безопасности.
Журналы
Журналы регистрируют события с отметками времени и предоставляют временную шкалу того, что произошло с системой. Например, ваше приложение может создать сообщение журнала, если ему не удается подключиться к базе данных, и может записать, кто выполнил определенное действие, в журнал аудита. В любой нетривиальной системе будет много разных логов. Запись и организация этих журналов в централизованной системе ведения журналов, где они могут быть разделены на части, являются основным аспектом сбора данных для наблюдения.
Данные аналитики журналов имеют решающее значение для мониторинга, устранения неполадок и расследования проблем с надежностью и безопасностью, чтобы выяснить основную причину, «почему» возникла эта проблема. Данные журналов часто представляют собой наиболее подробную информацию о системах компании, поэтому имеет смысл использовать эти данные для работы, извлекая файлы журналов по всей организации для сквозной видимости и более быстрого устранения неполадок.
Показатели
Хотя журналы обычно содержат текстовую информацию, метрики представляют собой числовые временные ряды , например, количество ожидающих обработки модулей в кластере Kubernetes с течением времени. Метрики обычно записываются периодически и могут помочь выявить тенденции и аномалии. Метрики намного экономичнее логов. Они не требуют синтаксического анализа и преобразования, а их передача и хранение обходятся дешевле. Метрики — это жизненно важные признаки вашей системы. Оповещения в основном строятся на основе показателей.
Следы
Распределенная трассировка связывает идентификатор с каждым запросом. Трассировка запроса представляет собой набор спанов и ссылок. Вы можете думать о трассировке как о направленном ациклическом графе, который представляет прохождение запроса через компоненты распределенной системы. Каждый диапазон записывает время, которое запрос провел в данном компоненте, а ссылки — это ребра графа, которые соединяют один диапазон со следующими. Трассировки — очень важный инструмент для современных систем, построенных на микросервисах, бессерверных функциях и очередях. Он обеспечивает «цепочку поставок» для системных операторов, что имеет решающее значение для анализа проблем как с производительностью, так и с безопасностью.
Так как же эти принципы пересекаются с данными безопасности?
Почти вся информация о безопасности поступает из журналов. Хотя метрики и трассировки могут помочь вам понять, когда что-то не так (например, высокая загрузка ЦП), вы, скорее всего, не будете знать, что происходит на самом деле (в данном случае высокая загрузка ЦП из-за криптомайнера), пока вы просматриваете журналы.
Как собирать данные
Теперь, когда мы понимаем данные об наблюдаемости и безопасности, почему они важны и откуда они берутся, давайте рассмотрим некоторые более практические аспекты: как собирать данные и как их эффективно использовать.
Давайте рассмотрим каждый столп, некоторые передовые практики и несколько инструментов, которые могут помочь. Эти шаги относятся ко всем вашим данным — наблюдаемости и безопасности.
Журналы
Возможно, у вас есть много журналов, созданных вашей ОС, Kubernetes и вашим облачным провайдером. Ваши приложения и стороннее программное обеспечение также создают файлы журналов. Однако стандартные журналы сопряжены с рядом проблем:
- Доступ к большому количеству файлов журналов на многих хостах неэффективен и неудобен для пользователя.
- Файлы журналов со временем заполнят диск (если только вы не используете постоянное облачное хранилище).
- Если вы чередуете файлы журналов для решения проблемы с дисковым пространством, вы теряете исторические данные.
- Ваши серверы могут время от времени выходить из строя.
- Диски могут быть повреждены.
Для решения этих проблем рекомендуется использовать агент сборщика журналов на каждом хосте, который отправляет журналы на централизованную платформу наблюдения. Централизованная система управления журналами будет хранить журналы в долговременном хранилище, предоставлять интерфейс запросов, обеспечивать агрегирование и другие преобразования, а также сохранять резервные копии журналов по мере необходимости для соответствия требованиям и выявления исторических тенденций.
Чтобы облегчить некоторые проблемы, рекомендуется использовать отраслевые стандарты и инструменты, такие как OpenTelemetry (https://opentelemetry.io). Для сбора данных, специфичных для журналов, инструменты с открытым исходным кодом, такие как LogStash и Fluentd также популярны.
Показатели
С метриками работать несколько проще, чем с журналами, поскольку все метрики из любого источника могут быть представлены единообразно в виде одного временного ряда с набором связанных с ним тегов. Подобно сборщику журналов, сборщик метрик может работать на каждом хосте и периодически считывать соответствующие данные, такие как использование ЦП и памяти каждым процессом или количество запросов в процессе выполнения, и отправлять их на платформу наблюдения.
Метрики на уровне приложения можно собирать двумя способами: приложение может предоставлять стандартный интерфейс, который агент метрик может очищать, или, в качестве альтернативы, приложение может быть оснащено инструментами (обычно с использованием библиотеки) для отправки своих метрик непосредственно на платформу наблюдения. Точки данных фиксируются с фиксированными интервалами и отправляются на платформу наблюдения для анализа.
Что касается метрик, Prometheus является бесспорным королем, разработанным для очистки конечных точек приложений, которые раскрывают метрики приложений. Grafana отлично подходит для визуализации ваших показателей.
Отслеживание
Трассы собираются приложениями и службами для перехвата запросов и прикрепления идентификатора, который следует за запросом при вызове других служб. Трассировки отправляются на платформу наблюдения для анализа.
В распределенной трассировке лидирует Jaeger (изначально разработанный Uber). Другие проекты включают Zipkin и Signoz.
Как данные используются для повышения безопасности приложений?
Как вы используете все эти данные для повышения безопасности вашего приложения? Давайте рассмотрим роль, которую эти части наблюдаемых данных могут играть в различных аспектах обнаружения инцидентов и реагирования на них.
Начнем с обнаружения инцидентов, которое основано на сборе метрик для обнаружения аномальной активности. Эти показатели, отслеживаемые платформой наблюдения, вызывают оповещение для команды DevSecOps.
В этот момент команда знает только, что происходит что-то ненормальное, но не знает, связано ли это с безопасностью или нет. Для идентификации инцидента критически важным становится просмотр журналов. Если инцидент связан с безопасностью, команда может использовать журналы, чтобы определить, как злоумышленники получают доступ к системе, и заблокировать дальнейший доступ, отменив доступ для скомпрометированных пользователей или служб.
Затем команда может использовать комбинацию журналов, метрик и трассировок для оценки воздействия взлома, определения того, какие части системы были затронуты и были ли данные удалены. Зная масштабы воздействия, команда может уменьшить радиус взрыва, сделав эти компоненты недоступными до тех пор, пока они не будут исправлены.
Наконец, команда может использовать журналы и метрики, особенно при выполнении пост-мортема, чтобы помочь в анализе основных причин всех инцидентов, связанных с безопасностью или иным образом. Результирующие действия могут включать ужесточение контроля доступа, исправление уязвимых систем или дальнейшую точную настройку стратегии наблюдения.
Как это выглядит на практике?
Элитный уровень наблюдаемости достигается, когда вы интегрируете все различные источники данных и технологии в единую платформу, которая позволяет вам получить представление о вашей системе.
Вы можете создать это самостоятельно, используя многие из уже упомянутых проектов с открытым исходным кодом. Хотя это предлагает широкие возможности настройки, для создания, обслуживания и эксплуатации требуется много усилий, особенно если вам нужна надежная, масштабируемая и всегда доступная система. Кроме того, вам также необходимо следить за своей платформой наблюдения.
Другой вариант — выбрать управляемую платформу для решения проблем наблюдаемости. Это позволяет вам сосредоточиться на своих основных компетенциях.
Пример из Черной пятницы
Давайте рассмотрим пример с Черной пятницей. Учитывая, что на многих сайтах , особенно в розничной торговле , наблюдается всплеск активности пользователей, как использование данных для наблюдения и платформы может помочь смягчить инциденты безопасности? Я нашел этот своевременный пост об Ulta Beauty с использованием таких показателей, как неверный пароль. попыток и попыток входа в систему по IP-адресу и по стране, все возможные признаки мошеннической деятельности.
Ulta передает эти метрики на платформу наблюдения от Sumo Logic, которая предоставляет панель управления Brute Force Attack для помощи в обнаружении инцидентов. Оттуда группа реагирования на инциденты может начать анализировать журналы, чтобы определить и устранить основную причину инцидента безопасности, как мы описали выше.
Платформа от Sumo Logic принимает, объединяет, обогащает и сохраняет все данные об наблюдаемости. Sumo Logic позволяет вам решить, хотите ли вы установить сборщики данных локально или использовать сборщики данных, работающие на AWS. Он также интегрируется с основными продуктами для наблюдения, такими как Prometheus и OpenTelemetry, что может упростить миграцию и снять опасения по поводу привязки к поставщику.
Заключение
Сбор больших массивов данных для наблюдения и безопасности — это ключ к качественному цифровому опыту для ваших пользователей. Чтобы добиться успеха, вам нужно полагаться на все три столпа наблюдаемости: журналы, метрики и распределенную трассировку. Эти данные понадобятся вам для обнаружения, изоляции и смягчения последствий атак.
В следующем посте серии мы более подробно рассмотрим мониторинг, который является следующим логическим шагом. Как только вы соберете все эти данные, что вы будете с ними делать?
Хорошего дня!
Оригинал