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

Как это исправить? Попытка исправить это, скопировав распределенные данные в новое единое хранилище только для того, чтобы применить политики безопасности, приводит к огромным задержкам в конвейере и дублированию правил. Объединение всех этих источников в одном месте обычно не является вариантом, и это означает, что исправление требует другого подхода. Рост производственных AI-агентов делает эти задержки неприемлемыми. AI-агент не может ждать завершения многолетнего проекта миграции, прежде чем дать ответ, и не может работать безопасно, если правила безопасности обходятся через заднюю дверь подключения к необработанным схемам.

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

Оборачивая распределенные наборы данных в управляемые продуктовые данные и управляя ими через федеративный движок запросов, организации могут применять единообразные политики безопасности как для человеческих аналитиков, так и для AI-агентов, не перемещая ни одного байта данных.

Ключевые выводы

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

Управление сломалось, когда платформа перестала быть единой системой хранения данных

Единая система хранения данных делала обеспечение политики простым по умолчанию. Эта эпоха закончилась. Реальность современных предприятий включает постоянные силиконы данных, несколько облачных платформ и автономных потребителей AI, которые все требуют ответов в режиме реального времени на один и тот же вопрос о том, кто может получить доступ к конкретному полю в конкретном запросе.

Ответ на этот вопрос путем копирования данных в центральный источник данных дублирует правила безопасности и останавливает инженерные конвейеры. AI-нагрузки делают эти задержки немедленно видимыми, поскольку автономные агенты не могут ждать многолетних проектов миграции данных.

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

Поместите управление на путь доступа

Чтобы понять, почему современное управление не работает, нужно посмотреть, где применяются механизмы безопасности. Инфраструктурные команды регулярно шифруют облачные хранилища и базовые диски в состоянии покоя. Шифрование необходимо для безопасности инфраструктуры, но оно фундаментально недостаточно для управления данными. Уровни хранения работают на уровне файлов и папок. Политика Amazon S3 bucket или разрешение на файл могут предоставить или отказать в доступе к префиксу всего набора данных, но не могут проверить SQL-запрос, оценить, кто его запрашивает, или замаскировать один чувствительный столбец, отображая остальную часть файла.

Истинное управление данными должно находиться непосредственно на пути выполнения, по которому проходит каждый оператор SELECT. Разрешение, которое определяет соответствие, — это не разрешение на уровне файла, проверяемое на уровне хранения, а тонкое правило, оцениваемое движком запросов непосредственно перед возвращением строки.

Федерация и доступ к данным

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

Эта модель также важна для открытых форматов таблиц, таких как Apache Iceberg, в рамках дата-лейкхауса. Хотя открытые форматы приносят возможности хранилища данных в виде схем в облачное объектное хранилище, файловые форматы сами по себе не могут обеспечить соблюдение правил доступа. Управление должно находиться выше абстрактного слоя таблиц, чтобы маскирование столбцов и фильтрация строк выполнялись идентично, независимо от того, запрашивает ли пользователь управляемую таблицу лейкхауса или удаленную операционную базу данных.

Запуск управления в производстве требует перехода от грубых, высокоуровневых разрешений к обеспечению тонких механизмов контроля непосредственно на пути выполнения запроса. Эта структура основана на четырех фундаментальных столпах.

Аутентификация личности

Во-первых, начните с разрешения идентичности. Каждый потребитель, будь то человеческий аналитик, автоматизированный конвейер или автономный AI-агент, должен аутентифицироваться через поставщика идентичности, который движок запросов сопоставляет непосредственно с авторизованными ролями и атрибутами.

Механизмы управления доступом

Во-вторых, команды платформы должны сочетать механизмы управления доступом на основе ролей и атрибутов. Управление доступом на основе ролей (RBAC) отвечает на вопрос, что пользователь или служба может делать, предоставляя широкий доступ к каталогам, схемам или конкретным заданиям запросов. RBAC сам по себе слишком груб для чувствительных данных, таких как персональная идентифицирующая информация. Управление доступом на основе атрибутов (ABAC) отвечает на вопрос, что содержит конкретное поле и кто может его просмотреть. Прикрепляя метаданные, такие как PII или конфиденциальные данные, к столбцам данных, инженеры платформы могут применять динамические правила маскирования по всей платформе, не переписывая вручную разрешения на доступ для тысяч отдельных таблиц.

Фильтрация

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

Журнал аудита

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

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

Данные продукты как единица управления

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

Данные продукты, которые несут с собой политику доступа упаковывают RBAC, ABAC, правила маскировки PII и историю происхождения в единый контролируемый актив. Федеральный движок запросов автоматически применяет этот встроенный контракт во время выполнения запроса, обеспечивая, чтобы аналитики, ноутбуки и модели ИИ не могли обойти логику безопасности платформы.

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

Команды платформы должны публиковать минимально жизнеспособный продукт данных, необходимый для обслуживания конкретного домена, проверяя, что контракт безопасности выполняется, прежде чем расширять доступ к более широким группам потребителей.

Федерация и дата-лейкхаус

Современные корпоративные архитектуры данных основаны на гибридной реальности. Организации используют дата-лейкхаус для хранения основных аналитических наборов данных в открытых форматах, таких как Apache Iceberg, наряду с живыми операционными базами данных и складами, которые невозможно легко мигрировать. Политики безопасности должны в равной степени охватывать обе среды. Федерация запросов обеспечивает единый слой доступа ко всем этим распределенным системам, в то время как лейкхаус служит слоем хранения для таблиц, которые вы решите разместить.

В этой парадигме Starburst предоставляет единый контекстный слой для аналитики и ИИ, соединяя различные платформы хранения с общими бизнес-определениями и путями доступа. Операционное правило простое:

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

Практическая последовательность внедрения

Ниже представлен практический подход к реализации предложенного выше плана.

Выберите один домен. Начните с одного конкретного бизнес-домена, у которого есть четкий владелец и активная проблема доступа к данным.
Классифицируйте и маркируйте. Отобразите базовые наборы данных, идентифицируйте чувствительные поля и примените метаданные-теги к столбцам, содержащим PII или конфиденциальную информацию.
Прикрепите политики. Настройте права доступа к ролям и правила маскировки на основе атрибутов для этих помеченных полей на уровне движка запросов.
Опубликуйте продукт данных. Упакуйте набор данных, определения и правила безопасности в единый сертифицированный продукт данных.
Подключите рабочие нагрузки. Укажите одну человеческую аналитическую рабочую нагрузку и один агент ИИ или ноутбук непосредственно к опубликованному продукту.
Проверьте журналы аудита. Проверьте журнал аудита в течение первой недели, чтобы убедиться, что агент ИИ запросил сертифицированный продукт и что маски столбцов сработали правильно. Если ноутбуки или скрипты все еще имеют доступ к сырым схемам, закройте эти несанкционированные пути.
Масштабируйте операционную модель. Повторите эту последовательность классификации, маркировки и контракта продукта для смежных доменов, используя точно тот же движок запросов, чтобы предотвратить фрагментацию политик.

Избегайте запуска массовой, общекомпанийской инициативы по каталогизации, прежде чем управлять одним доменом. Широкие программы каталогизации часто застревают под собственным административным бременем. Завершенный, полностью контролируемый домен устанавливает проверенную операционную модель, в то время как незавершенный корпоративный каталог не приносит никакой ценности в области безопасности.

Следующие шаги

Хотите узнать больше о контролируемом доступе к данным в разных регионах? Посмотрите этот вебинар: Разблокируйте безопасный и соответствующий доступ к данным и их обмен между регионами.

Часто задаваемые вопросы

Где должно быть обеспечено управление, если данные находятся в нескольких системах?

Управление должно быть обеспечено на центральном слое запросов и доступа, который использует каждый потребитель. Шифрование на уровне хранения по-прежнему необходимо для защиты инфраструктуры, но оно не может заменить динамические фильтры строк, маски столбцов и журналы аудита, выполняемые на пути SELECT.

Как RBAC и ABAC работают вместе на платформе данных?

Контроль доступа на основе ролей (RBAC) предоставляет ролям пользователей разрешения на доступ к более широким каталогам, схемам и продуктам данных. Контроль доступа на основе атрибутов (ABAC) применяет метаданные-теги к чувствительным полям, чтобы PII маскировался динамически на основе атрибутов пользователя, устраняя необходимость писать пользовательские разрешения для отдельных таблиц.

Как управление файлами отличается от управления таблицами во время запроса?

Разрешения на файлы могут только скрывать или раскрывать целые объекты хранения или префиксы папок. Управление таблицами во время запроса оценивает SQL-запросы, чтобы маскировать конкретные столбцы или фильтровать конкретные строки для одной роли, в то время как другая роль может просматривать весь набор данных.

Как данные продукты делают управление полезным для агентов ИИ?

Данные продукты привязывают бизнес-определения, владение доменом и правила безопасности непосредственно к сертифицированному набору данных. Агенты ИИ запрашивают продукт в соответствии с точно такими же правилами доступа, как и человеческие аналитики, а не сканируют сырые схемы через неконтролируемые соединения.

Какой разумный первый домен стоит контролировать от начала до конца?

Выберите один бизнес-домен с четким владельцем, пометьте его чувствительные поля, опубликуйте один контролируемый продукт данных, подключите одного человеческого аналитика вместе с одним ноутбуком ИИ и проверьте сгенерированный журнал аудита, чтобы убедиться в выполнении политики, прежде чем расширять систему по всему предприятию.