Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад «The Unbelievable Insecurity of the Big Data Stack» с конференции Black Hat USA 2021 — в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.
Доклад делала Sheila A. Berta — специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.
И вначале я бы хотел оставить ссылки на оригинальные публикации в дань уважения автору и её труду. Я очень рекомендую ознакомиться с этой работой, если хотите больше технических деталей, а тут я, скорее, хочу дать более высокоуровневый пересказ и свои мысли.
-
Запись доклада на английском: https://www.youtube.com/watch?v=vl9hk4fQdos
-
Запись доклада на испанском (ну вдруг): https://www.youtube.com/watch?v=vl9hk4fQdos
Так вот. Что вообще такое Big Data? Можем ли мы очертить её границы и точно определить, что вот тут у нас Big Data, а тут не очень Big, или вообще не Data?
На практике — не особо. Это не строгий термин, а скорее ярлык для систем, где объём, скорость и разнообразие данных выходят за рамки классических подходов. Там, где уже не получается обойтись одной базой и одним сервером, и приходится строить распределённую инфраструктуру. И вот отсюда начинается самое интересное.
Когда говорят про Big Data, разговор почти всегда уходит в масштабируемость, скорость обработки и красивые дашборды. Как всё это работает под капотом и насколько оно вообще безопасно — тема куда менее популярная, но ничуть не менее важная.
Вообще говоря, никакого «Big Data решения» как однозначного и конвенционально принятого в реальности не существует. Есть набор технологий, которые собираются вместе в одну инфраструктуру. Данные лежат, например, в HDFS, обрабатываются через Apache Spark, координируются через Apache ZooKeeper, сверху к этому добавляется доступ через SQL или BI-инструменты вроде ClickHouse, Presto или Cassandra (в зависимости от задач и вкуса команды).
Если развернуть это чуть подробнее, типичная архитектура выглядит примерно так:
И возникает ощущение, что это просто стек. Набор сервисов, ничего необычного. Но на практике это система, собранная из компонентов, которые изначально не проектировались жить вместе в единой модели безопасности. Каждый решает свою задачу и делает это неплохо. Но как только их соединяют, между ними появляются зоны ответственности, где никто до конца не понимает, что именно происходит и кто за это отвечает.
В докладе автор предлагает смотреть на эту историю чуть иначе: не просто как стек технологий, а как на несколько слоёв, через которые проходят данные и управление — от поступления данных в систему (ingestion) до доступа к ним, плюс отдельный слой управления кластером. Такой взгляд сразу сдвигает фокус — становится важным не то, насколько безопасен отдельный сервис, а то, как они взаимодействуют между собой.
И здесь появляется ключевая идея всей работы. Основные проблемы находятся не внутри этих слоёв, а на стыках между ними. Как мы знаем, абстракции имеют свойство протекать от одного уровня к другому. Там, где один сервис доверяет другому, потому что «так принято», а проверок почти нет. В результате attack surface формируется не отдельными компонентами, а их связями — и растёт вместе с архитектурой.
Если посмотреть на это со стороны атаки, картина получается довольно показательная. Здесь нет одной уязвимой точки, по которой нужно бить. Скорее это последовательное перемещение по системе.
Сначала можно получить доступ к служебным компонентам. Системы координации вроде ZooKeeper часто содержат конфигурацию кластера и дают довольно подробное представление о том, как всё устроено. По сути, это карта всей инфраструктуры.
Дальше используется вычислительный слой. В системах вроде Spark или YARN можно запускать задачи, а задача — это код. Если получилось закрепиться на этом уровне, дальше уже не так важно, где именно лежат данные и как к ним формально организован доступ.
И в конце цепочки остаются сами данные, до которых уже можно добраться, понимая структуру системы и имея возможность выполнять код внутри неё.
Атака на такие системы выглядит не как классический взлом, а скорее как навигация по инфраструктуре. Переход от одного слоя к другому с использованием тех механизмов, которые и так предусмотрены системой. Это чем-то напоминает плесень или мох между камнями в здании, которая распостраняется по всему доступному пространству. Неважно насколько прочные кирпичи образуют стены вашей крепости, если можно проскользнуть между ними и попасть внутрь.
Такая логика возможна не из-за одной конкретной ошибки. Она возникает из базовых предположений, на которых строится весь стек. Большая часть компонентов исторически разрабатывалась с ожиданием доверенной среды: внутренний кластер, своя сеть, предсказуемые пользователи. В этих условиях можно позволить себе меньше проверок и больше доверия между сервисами. Но как говорил Петир «Мезинец» Бейлиш: «Недоверие ко мне — ваш самый мудрый шаг с тех пор, как вы приехали сюда.»
В современных инфраструктурах это предположение почти никогда не выполняется. Системы интегрируются друг с другом, выходят за пределы одного кластера, подключаются к облакам, открывают внешние доступы. Границы становятся размытыми, а старые допущения остаются. В целом индустрия давно сместилась от модели «периметра» к модели экосистемы.
К этому добавляется ещё один фактор — отсутствие единой модели безопасности. У каждого компонента свои механизмы аутентификации, свои правила доступа, свои представления о том, кому можно доверять. В итоге безопасность оказывается не системой, а набором разрозненных решений, которые не всегда согласуются друг с другом. В этом смысле Big Data стек во многом наследует проблемы микросервисной архитектуры: система собирается из множества независимых частей, но целостная модель безопасности при этом часто остаётся размытой.
Чем больше растёт инфраструктура, тем сильнее проявляется этот эффект. Каждый новый сервис добавляет не только функциональность, но и новые точки взаимодействия. Новые API, новые соединения, новые зависимости. Attack surface увеличивается вместе с архитектурой, причём быстрее, чем появляется возможность это всё осмыслить и проверить.
Отсюда возникает практическая проблема, о которой редко говорят напрямую: такие системы крайне сложно полноценно аудировать. Слишком много компонентов, слишком много связей, слишком слабая наблюдаемость. В какой-то момент проверка превращается в приближение, а не в точное понимание.
И здесь эта история естественным образом пересекается с тем, что я обычно называю цифровой экологией.
По мере роста инфраструктуры данные начинают жить дольше, чем существует понимание их роли. Они копируются между слоями, реплицируются, остаются в промежуточных хранилищах. Пайплайны накапливаются, старые редко удаляются, доступы сохраняются «на всякий случай». Плодится цифровой мусор.
В какой-то момент данных становится больше, чем контроля над ними. Появляются массивы, которые никто явно не использует, но которые продолжают существовать и участвовать в системе. Это уже не только вопрос эффективности или стоимости хранения. Это прямое увеличение поверхности атаки и рисков утечек данных. Чем больше «наполнена система», тем выше вероятность, что что-то где-то окажется открытым или забытым.
Генеративные модели только ускоряют этот процесс. Объём данных растёт кратно, появляются новые сценарии их использования, новые пайплайны, новые точки доступа. Система усложняется ещё быстрее, чем раньше. И параллельно растёт отчуждение: мы всё чаще пользуемся инструментами, не до конца понимая, как они устроены внутри.
В итоге складывается довольно характерная картина. Мы строим всё более мощные и гибкие системы для работы с данными, но при этом всё хуже понимаем, как они устроены целиком и где проходят их реальные границы.
И если систему невозможно полностью понять и проверить, она неизбежно остаётся частично неконтролируемой. А там, где появляется неконтролируемость, довольно быстро появляется хаос. И как говорил уже упомянуты лорд Бейлиш: «Хаос — это лестница». Вопрос только в том, кто по ней поднимается.
P.S.: Эту статью я написал, потому что меня лично интересуют темы современных инфраструктурных решений, обработки и хранения больших данных и проблемы цифровой экологии. Я сам пытаюсь глубже в этом разобраться, изучаю эти вопросы и делюсь находками с теми, кому это тоже интересно. В том числе в своём скромном канале Econet, где я пишу и размышляю на эти темы, а также про всякое интересное из мира AI и IT. В первую очередь — то, что интересно мне, но надеюсь, зацепит и вас.
ссылка на оригинал статьи https://habr.com/ru/articles/1030842/