Управление данными в Lakehouse — это не только про хранение и обработку, но и, в первую очередь, про безопасность. Если архитектура не обеспечивает надежный контроль доступа, ее ценность для бизнеса сводится к нулю. Однако, для этой относительно новой технологии стандартных и понятных решений в области безопасности зачастую не хватает. В данной статье мы сосредоточимся на ключевом аспекте — авторизации доступа к таблицам и схемам данных.
На текущем этапе в России сложилась парадоксальная ситуация: несмотря на известные проблемы, основным инструментом для организации такого доступа остается Apache Ranger. Его ключевые недостатки — громоздкость, высокие операционные издержки и уязвимость к изменениям — давно осознаны и успешно решены в западных решениях. Что мешает нам двигаться дальше? Давайте рассмотрим современную альтернативу, которая не просто заменяет, а кардинально упрощает управление безопасностью данных.
Чтобы понять корень проблемы, стоит взглянуть на эволюцию подходов. В классических MPP-системах, таких как Greenplum, архитектура была монолитной, но централизованной. Все процессы: хранение, вычисления и управление доступом, — происходили в рамках единого контура. Это создавало понятную и прозрачную модель безопасности: сама система решала, к каким данным может обратиться каждый пользователь. Сегодня пользователи уходят от таких решений из-за их дороговизны и проблем с масштабированием, но их ключевое преимущество (целостный контроль доступа) было очевидным.
Следующий этап: Data Lakes на базе Hadoop (HDFS, Hive, Impala). Здесь архитектура уже разделена на независимые уровни хранения и вычислений, но контур управления доступом по-прежнему оставался относительно компактным и централизованным благодаря таким специализированным инструментам, как Apache Ranger, которые, будучи подключены к экосистеме, централизованно применяли политики безопасности для всех ее компонентов.
Однако при переходе к архитектуре Lakehouse сами паттерны доступа к данным меняются кардинально. Ключевая идеология Lakehouse — это демократизация данных, то есть устранение барьеров для вовлечения в аналитику максимального числа пользователей и команд. Это касается и производительности запросов, и скорости разработки новых моделей и отчетов.
В результате в Lakehouse центральным и единственным постоянным компонентом остается только объектное хранилище (например, S3, ADLS, HDFS или Ozone). К этому единому источнику правды начинают подключаться десятки разнородных вычислительных движков (Spark, Trino, Presto, Flink и др.). Каждый из этих движков может работать в множестве независимых инстансов — например, у одной компании в продакшене могут одновременно работать сотни кластеров Trino, обслуживающих разные отделы и задачи.
Именно здесь классическая модель управления доступом, подобная Ranger, сталкивается с фундаментальным вызовом. Единый центр управления политиками должен теперь координировать сотни распределенных и разнородных точек принятия решений о доступе, что создает огромную операционную сложность и риски несогласованности.
В дополнение к разнообразию движков, с данными в Lakehouse начинают работать кастомные приложения (например, Python-скрипты, микросервисы на Go или Java), созданные разными командами. Это и есть та самая демократизация и горизонтальное масштабирование аналитики. Однако она немедленно ставит ключевой вопрос: где теперь находится точка контроля доступа? Кто и как должен авторизовать каждую операцию?
Этот вопрос долгое время не имел очевидного ответа даже для создателей подобных систем. Первое решение, которое напрашивалось, — адаптировать проверенный инструмент. А именно: взять Apache Ranger, с которым многие уже работали в Hadoop-стеках, и подключить его ко всем возможным потребителям данных в Lakehouse. В теории это позволяло централизованно управлять политиками.
На первый взгляд кажется, что таким образом проблема контроля доступа решена. Однако это решение хорошо работает лишь на старте, пока речь идет о единичных движках и малом масштабе. При попытке развернуть такую модель в масштабах всей компании, где в дело вступают десятки разнородных систем и команд, выявляются фундаментальные недостатки подхода.
- Ограниченная совместимость
Оказывается, что Apache Ranger не является универсальным решением. Многие современные движки и кастомные приложения не имеют готовых плагинов или нативной поддержки для интеграции с ним. На практике это означает, что для работы с такими системами администраторам приходится либо отказываться от их использования, либо создавать нестандартные и потенциально уязвимые обходные пути. Таким образом, вместо декларируемой демократизации доступа, архитектура навязывает новые технологические барьеры, вынуждая команды отказываться от оптимальных инструментов и откатываясь к практике ограниченного выбора. - Множество точек доступа и рост поверхности для атак
В данной модели критическая функция авторизации делегируется каждому отдельному потребителю данных (движку или приложению). Вместо одного централизованного рубежа безопасности возникает множество распределенных точек принятия решений. С точки зрения злоумышленника это превращает каждый такой компонент в потенциальную цель для атаки, поскольку компрометация лишь одного из них может открыть доступ ко всему хранилищу. В результате поверхность атаки (attack surface) системы увеличивается на порядки, а её общая безопасность начинает определяться самым уязвимым звеном в цепочке. - Операционная сложность и человеческий фактор
Управление безопасностью трансформируется из задачи централизованной настройки в масштабную операционную проблему. Теперь политики необходимо внедрять, контролировать и актуализировать в десятках или сотнях независимых систем. Это экспоненциально увеличивает круг лиц, имеющих доступ к критическим настройкам безопасности, и сложность обеспечения их согласованности. В сочетании с человеческим фактором, рисками ошибок, недобросовестных действий или социальной инженерии, такой подход создает высокую вероятность возникновения «слепых зон» и уязвимостей из-за неверной или устаревшей конфигурации в одном из множества компонентов.
Почему это происходит?
Фундаментальная причина кроется в архитектуре самого Ranger. По своей сути Ranger — это не система контроля доступа, а централизованное хранилище (база данных) политик. Критическое решение о применении этих политик делегируется на сторону потребителей данных через специальные плагины.
Это порождает ключевой вопрос безопасности: можем ли мы быть уверены, что каждый из десятков разнородных движков и приложений корректно и неизменно применяет эти политики, и что ни один из них не скомпрометирован? Уверенности нет, и вот почему.
- Архитектурный изъян: делегирование ответственности.
Модель, где политика хранится централизованно, а исполняется распределенно, создает непреодолимый разрыв. Вы теряете гарантию того, что решение «запретить доступ» трактуется и исполняется абсолютно идентично во всех компонентах вашей инфраструктуры. Безопасность системы начинает зависеть от самого слабого или некорректно настроенного звена. - Проблема реализации: отсутствие стандартов и документации.
Попытка расширить поддержку, написав плагин для нового движка, наталкивается на практическое отсутствие официальной документации и четких спецификаций. Нет эталонного описания того, как правильно интегрироваться с Ranger. Следовательно, не существует объективного способа верифицировать, корректно ли реализована логика контроля доступа в каждом конкретном плагине. Вы вынуждены полагаться на добросовестность и компетенцию разработчика, что неприемлемо для системы безопасности. - Проблема безопасности самого стека: уязвимое основание.
Наш собственный опыт разработки плагинов для Ranger выявил еще более серьезную проблему: крайне низкое качество кода и зависимость от устаревших библиотек с известными уязвимостями. Интегрируя его плагины, вы невольно вносите эти уязвимости в контур своих вычислительных движков. Получается парадокс: инструмент, призванный обеспечивать безопасность, сам становится ее новым слабым звеном, расширяя общую поверхность для атак.
Существует альтернативный подход, позволяющий реализовать единый централизованный механизм контроля доступа для всех потребителей данных. Этот подход уже получил признание в сообществе Apache Iceberg и рассматривается как ключевая архитектурная компонента для современных Lakehouse. Речь идет об использовании метаданных и каталогов данных (Catalog).
Важно уточнить: здесь имеется в виду не бизнес-ориентированный Data Catalog (например, для поиска и описания данных), а технический, инфраструктурный каталог, идеологически наследующий принципам Hive Metastore. Его фундаментальная роль в архитектуре Lakehouse — хранить метаинформацию о данных (где они физически расположены, какова их схема) и предоставлять ее вычислительным движкам.
Процесс доступа всегда следует единому сценарию: прежде чем выполнить запрос, движок обращается к каталогу, чтобы получить актуальные указатели на физическое расположение данных. Ключевая идея заключается в том, чтобы встроить логику авторизации непосредственно в эту критическую точку взаимодействия. Если каталог будет проверять права доступа в момент запроса метаданных, то он автоматически станет единой, универсальной точкой авторизации для всей экосистемы.
Этот подход кардинально меняет парадигму безопасности. Мы больше не полагаемся на добросовестность и корректность настройки каждого отдельного потребителя. Вместо этого решение о предоставлении доступа принимается централизованно и принудительно, на основе единого набора политик, до того как движок получит информацию для выполнения запроса.
Именно эту архитектурную модель реализует CedrusData Catalog. Он интегрирует в себя полноценную систему управления доступом, где заданные политики становятся обязательными для исполнения всеми без исключения движками. Для этого не требуются отдельные плагины, агенты или модификации самих потребителей данных, что исключает риски их обхода или некорректной реализации. В результате архитектура контроля доступа приобретает ясную и безопасную форму.
У нас по-прежнему остается большое количество разноплановых потребителей данных — от Spark и Trino до кастомных приложений. Однако ключевое отличие в том, что все они теперь обязаны проходить через единый контрольный контур каталога. Здесь централизованно принимается решение о предоставлении доступа к данным, что позволяет совместить надежность и контроль классических систем с масштабируемостью и гибкостью архитектуры Lakehouse.
Этот подход уже получил поддержку потребителей открытого табличного формата Apache Iceberg и стал ключевым стандартом для реализации Lakehouse. Подавляющее большинство современных аналитических систем, фреймворков и библиотек имеют нативную поддержку Iceberg. Единственным заметным исключением является Apache Impala, чья поддержка этого формата пока остается ограниченной. Таким образом, за исключением Impala, архитектура доступна для всех распространенных инструментов работы с данными.
Данная модель значительно сокращает операционные риски, упрощает настройку и делает управление безопасностью предсказуемым. Важно отметить, что этот подход подтвержден отраслевой практикой. Наряду с нашим решением CedrusData Catalog, аналогичные продукты предлагают и другие вендоры (например, Snowflake Polaris Catalog). Сообщество Iceberg пришло к консенсусу, что централизованный каталог с интегрированной авторизацией является целевой архитектурой для безопасных Lakehouse.
Безопасность — это не опция, а фундамент любой data-инфраструктуры. Выбор устаревшего подхода может дать быстрый тактический выигрыш за счет использования знакомого инструмента. Однако истинный успех измеряется не скоростью первого релиза, а способностью платформы через 3-7 лет поддерживать экспоненциальный рост в десятки и сотни раз — как операций с данными, так и числа сотрудников, извлекающих из них ценность.
Правильная модель безопасности, основанная на централизованном контроле, делает этот рост органичным и не создает операционных барьеров. В то время как делегирование решений множеству распределенных компонентов будет постоянно тормозить развитие, создавая растущую долгосрочную нагрузку.
Данная архитектура реализована в нашем продукте CedrusData Catalog. Его можно начать использовать бесплатно, включая развертывание в production-среде.
Мы предлагаем несколько вариантов внедрения для разных сценариев:
- Быстрый старт и тестирование. Каталог интегрирован в высокопроизводительный движок CedrusData Engine (основан на Trino). Это позволяет развернуть полноценную среду с централизованным управлением доступом силами одной командой. Такой подход идеален для ознакомления, тестирования и оценки работы решения в собственном контуре.
- Для комплексного развертывания — CedrusData Platform. Это готовый продукт для работы в Kubernetes. Платформа включает все необходимые компоненты: движки Trino и Spark, CedrusData Catalog для управления доступом и метаданными, а также инфраструктуру для мониторинга и управления. Это законченное решение для построения безопасного и управляемого Lakehouse.
Инвестиции в правильную архитектуру безопасности на старте — это стратегическое решение, которое предотвращает будущие операционные сложности и закладывает основу для устойчивого роста вашей data-платформы.