Big Data небезопасен по конструкции, а не из-за отдельных уязвимостей

Big Data небезопасен по конструкции, а не из-за отдельных уязвимостей

Исследователь Sheila A. Berta на Black Hat USA 2021 показала: главная проблема Big Data стека не в дырявом коде, а в том, как компоненты взаимодействуют друг с другом. Пять лет спустя ничего принципиально не изменилось — и это стоит понимать каждому, кто строит или эксплуатирует такую инфраструктуру.

Стек собран из компонентов, не знающих друг о друге

Никакого монолитного «Big Data решения» не существует. Есть набор технологий, которые собирают вместе под конкретную задачу: HDFS хранит данные, Apache Spark их обрабатывает, ZooKeeper координирует кластер, поверх добавляют ClickHouse, Presto или Cassandra — в зависимости от вкуса команды и требований к запросам.

Проблема в том, что каждый из этих компонентов разрабатывался отдельно, со своими допущениями о среде. У каждого своя модель аутентификации, свои правила доступа, своё представление о том, кому можно доверять. Когда их соединяют в одну инфраструктуру, между слоями появляются зоны, где никто до конца не понимает, что именно происходит и кто за это отвечает.

Berta предлагает смотреть на стек не как на набор сервисов, а как на несколько слоёв: ingestion, вычислительный слой, хранение, доступ и управление кластером. Ключевой вывод: основные риски находятся не внутри слоёв, а на стыках между ними.

Атака выглядит как навигация, а не взлом

Классический взлом — это найти уязвимую точку и ударить по ней. Атака на Big Data инфраструктуру устроена иначе: это последовательное перемещение по системе с использованием механизмов, которые в ней и так предусмотрены.

Сначала — служебные компоненты. ZooKeeper содержит конфигурацию кластера и даёт подробную карту всей инфраструктуры. Дальше — вычислительный слой. В Spark или YARN можно запускать задачи, а задача — это код. Если удалось закрепиться здесь, формальные права доступа к данным уже почти не важны. В конце цепочки — сами данные, до которых можно добраться, понимая структуру и имея возможность выполнять код внутри системы.

« Неважно, насколько прочные кирпичи образуют стены вашей крепости, если можно проскользнуть между ними и попасть внутрь. »

Это метафора из доклада — про плесень между камнями. Она точно описывает механику: attack surface формируется не отдельными компонентами, а связями между ними. И растёт вместе с архитектурой — причём быстрее, чем появляется возможность это осмыслить.

Исторические допущения, которые давно перестали работать

Большинство компонентов Big Data стека разрабатывались с расчётом на доверенную среду: внутренний кластер, предсказуемые пользователи, своя сеть. В таких условиях меньше проверок и больше доверия между сервисами — разумный компромисс.

Но современные инфраструктуры давно вышли за эти рамки. Системы интегрируются друг с другом, подключаются к облакам, открывают внешние доступы. Границы размываются, а старые допущения остаются. Индустрия сместилась от модели периметра к модели экосистемы — но базовые предположения о доверии в коде никуда не делись.

• Каждый новый сервис добавляет не только функциональность, но и новые точки взаимодействия

• Единой модели безопасности для всего стека не существует — есть набор разрозненных решений

• Аудит таких систем превращается в приближение: слишком много компонентов, слишком много связей

• Данные живут дольше, чем существует понимание их роли — копируются, реплицируются, остаются в промежуточных хранилищах

Что это означает для тех, кто эксплуатирует такие системы

Для меня как CIO главный вывод из этой работы — не технический, а управленческий. Безопасность Big Data инфраструктуры нельзя делегировать «команде, которая её строила». Потому что у каждого компонента есть ответственный, а за пространство между компонентами — нет.

Именно здесь возникает то, что я называю цифровой экологией: пайплайны накапливаются, старые редко удаляются, доступы сохраняются «на всякий случай». Цифровой мусор растёт, а вместе с ним — неконтролируемая поверхность атаки. Это не проблема одного инструмента. Это проблема того, как организация управляет своей инфраструктурой в целом.

Доклад Berta вышел в 2021 году. Пять лет прошло — и большинство описанных проблем никуда не делись, потому что они встроены в саму архитектуру стека. Патч здесь не поможет. Нужно менять подход к проектированию безопасности с самого начала — или честно признавать, что её нет.

[ВКонтакте](https://vk.com/ciologia)

[Telegram](https://t.me/CIOlogia)

[Habr](https://habr.com/ru/users/CIOlogia/posts/)

[TenChat](https://tenchat.ru/ciologia)

[LinkedIn](https://www.linkedin.com/in/vladislav-prokopovich-bb808376/)

Начать дискуссию