Как отметки времени о событиях в архитектуре данных Lakehouse позволяют обеспечить безопасность Delta Lake: примеры извлечения и преобразования, а также лучшие практики.
Почему отметки времени в логах системных событий так важны для архитектуры больших данных
Архитектура Lakehouse построена на открытых стандартах и API, которые позволяют сочетать ACID-транзакции и управление данными классических корпоративных хранилищ с гибкостью и экономичностью озер данных. Подробнее о том, как она устроена, мы писали здесь и здесь. Сегодня на рынке популярны несколько реализаций архитектуры Lakehouse от крупных PaaS-провайдеров, например, платформа Databricks организует данные, хранящиеся в Delta Lake, в облачном объектном хранилище с помощью схем базы данных, таблиц и представлений. Можно представить Lakehouse как слой поверх классического DWH и/или Data Lake, с чьими данными активно работают ETL-конвейеры, чтобы сделать данные пригодными для аналитики и машинного обучения.
Поскольку Lakehouse аккумулирует все информационные активы предприятия, обеспечение безопасности этой архитектуры критически важно для бизнеса, особенно, когда данные из корпоративного озера и хранилищ используются для машинного обучения, что мы разбираем здесь. Специалисты по cybersecurity выделяют разные подходы и инструменты обеспечения информационной безопасности на корпоративном уровне. Одним из них является мониторинг и анализ логов о событиях, произошедших с данными, чтобы вовремя среагировать на инцидент или предотвратить угрозу. Для этого необходимо знать, когда именно произошло конкретное событие. Ответ на этот вопрос дают временные метки или отметки времени (timestamp) событий, которые фиксируются в локальном журнале каждого приложения. А если приложения выстроены в единый ETL-конвейер для Lakehouse, в этом хранилище временные метки событий также сохраняются.
Однако, широкий набор приложений в ETL-конвейере не предполагает унифицированных форматов логирования событий. Хотя существуют унифицированные форматы времени, например, ISO 8601, на практике они не всегда точно соблюдаются. Чаще всего каждое приложение по-своему записывает дату и время события, используя собственные привязки к геолокации или особенностям языка программирования. Но, несмотря на различные форматы записи временных меток о событиях в корпоративном хранилище или озере данных, все они должны быть стандартизованы, чтобы обеспечить совместимость со всеми логами, получаемыми и анализируемыми с точки зрения кибербезопасности.
Совместимость отметок времени событий в разных приложениях позволит быстро ответить на вопросы расследования инцидентов информационной безопасности, например:
- какой компьютер злоумышленник первым взломал?
- в каком порядке были взломаны системы?
- какие действия после нарушения контура защиты происходили в каждом приложении и в каком порядке?
Однако, из-за того, что отметки времени логируются по-разному, сопоставить их между собой не так-то просто. Прежде всего, надо понять, что представляет собой timestamp как элемент данных в архитектуре Lakehouse: один столбец таблицы или несколько разных. Некоторые приложения логируют timestamp в виде единого поля, например, потоковая передача событий с Spark Streaming или Flink, а также продюсеры и потребители для Kafka, написанные без использования этих фреймворков. Но если лог приложения представляет собой, например, CSV-файл, данные об отметке времени будут разделены по нескольким столбцам. И дата-инженеру придется выполнять контенкацию символьных данных из них.
Кроме того, потребуется делать преобразование из-за разных форматов записи даты и времени. Например, 10 ноября 2023 года может быть представлено как 10.11.23 или 11.10.23. Хотя оба варианта валидны, определить день, месяц и год сложно, не зная формата локального системного журнала. Также возникают сложности с идентификацией часового пояса. Подобно форматам данных и времени, некоторые системы записывают часовой пояс во временной метке, а другие предполагают местное время. Это становится проблемой, если источники данных и приложения ETL-конвейера распределены по нескольким часовым поясам.
Таким образом, идентификация, извлечение и анализ временных меток событий требуют последовательного и эффективного представления времени в системах хранения. Как это сделать, рассмотрим далее.
Пример реализации
В качестве примера рассмотрим стандартный формат журнала веб-сервера Apache. Данные создаются как текстовая запись и читаются как один столбец в архитектуре данных Lakehouse на примере платформы Databricks. Поэтому, чтобы извлечь метку времени события, нужно использовать регулярное выражение.
Напишем Python-пример регулярного выражения для извлечения метки времени события из одного столбца данных:
from pyspark.sql.functions import regexp_extract
TIMESTAMP_REGEX = '^([^ ]*) [^ ]* ([^ ]*) \[([^\]]*)\]'
df1 = df.select(regexp_extract("value", TIMESTAMP_REGEX, 3).alias('_raw_time'), "*")
display(df1)
В этом участке PySpark-кода используется функция regexp_extract() для извлечения части строки с меткой времени события и создания столбца _raw_time с соответствующими символами. Результирующий датафрейм будет выглядеть так:
Теперь, когда временная метка события извлечена в виде нового столбца, ее можно нормализовать в стандартную временную метку ISO 8601. Для этого надо определить формат с помощью модификаторов формата даты/времени и преобразовать его в временную метку в стиле unix, прежде чем представлять в формате ISO.
Есть несколько типовых сценариев использования даты и времени в Spark:
- источники данных CSV/JSON используют строку шаблона для анализа и форматирования содержимого даты и времени;
- функции Datetime, связанные с преобразованием StringTypeв/из DateTypeили TimestampType. Например, unix_timestamp(), date_format(), to_unix_timestamp(), from_unixtime(), to_date(), to_timestamp(), from_utc_timestam(), to_utc_timestamp(), и т.д.
Например, представим отметку времени в формате dd/MMM/yyyy:HH:mm:ss Z:
TIMESTAMP_FORMAT = "dd/MMM/yyyy:HH:mm:ss Z"
Пример преобразования в метку времени события в формате ISO 8601 выглядит так:
from pyspark.sql.functions import to_timestamp, unix_timestamp, col
TIMESTAMP_FORMAT="dd/MMM/yyyy:HH:mm:ss Z"
df2 = df1.select(
to_timestamp(unix_timestamp(col("_raw_time"), TIMESTAMP_FORMAT).cast("timestamp"), "dd-MM-yyyy HH:mm:ss.SSSZ").alias("_event_time")
)
display(df2)
В этом участке PySpark-кода используются функции unix_timestamp() и to_timestamp() для создания нового столбца метаданных _event_time.
В результате столбец _event_time преобразуется в тип отметки времени, который выглядит понятно и единообразно, чтобы обеспечить согласованность и целостность данных.
В заключение перечислим несколько рекомендаций по работе с временными метками событий в корпоративных хранилищах и озерах данных:
- задавать явный формат времени события;
- явно именовать столбец с отметкой времени, например, с помощью префикса и подчеркивания (_event_type, _raw_time и пр.). Это позволит различать машинно-генерируемые данные и метаданные, а также дополнительно отображать их в датафреймах и таблицах.
- Сохранять не только отметку времени события, когда оно произошло в реальном мире, но и когда оно было принято в хранилище данных. Эти значения будут отличаться из-за задержки при передаче данных. Отслеживание этой разницы позволит определить источники данных или ETL-процессы, которые отстают, и принять соответствующие меры по исправлению ситуации.
Таким образом, правильно сформированные и точные временные метки событий очень важны для операций по обеспечению информационной безопасности, позволяя реагировать на инциденты для расследования киберугроз. Без совместимости всех источников данных поддерживать эффективный уровень безопасности невозможно. Но, чтобы эффективно работать с отметками времени, записанными в Lakehouse из различных приложений, их необходимо привести к единообразному представлению, используя регулярные выражения и анализ несоответствий в источниках данных.
Код курса
SPAD
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Освойте работу с современными архитектурными паттернами и инструментами для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
