Основные понятия для управления доступом на основе атрибутов (ABAC)

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

См. управление доступом на основе атрибутов в Unity Catalog для получения обзора всех тем ABAC, включая руководства, управление политиками, рекомендации и ограничения.

Что такое ABAC?

Управление доступом на основе атрибутов (ABAC) — это динамическая модель управления доступом, в которой решения о доступе основаны на политиках, вычисляемых по атрибутам, связанным с защищаемыми компонентами. В каталоге Unity эти атрибуты представлены с помощью управляемых тегов. Эти управляемые теги используются в условиях политики для сопоставления объектов данных в заданной области, таких как каталог или схема. Это позволяет одной политике автоматически применяться к нескольким объектам данных, которые соответствуют его условиям.

Например, политика ABAC может маскировать все столбцы, помеченные PII, для таблиц в схемах, помеченных HR. При создании и теге новых объектов данных политика применяется автоматически, не требуя отдельных определений политик для каждого объекта.

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

Для сравнения с фильтрами строк и масками столбцов на уровне таблицы, см. раздел «Когда использовать ABAC по сравнению с фильтрами строк и масками столбцов на уровне таблицы».

Управляемые теги

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

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

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

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

Дополнительные сведения см. в разделе "Управляемые теги " и "Применение тегов к защищаемым объектам каталога Unity".

Policies

Политики присоединяются к защищаемым объектам в каталоге Unity для определения правил управления доступом на основе условий тегов. Ниже приведен пример:

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
    RETURN '***';

CREATE POLICY mask_pii_for_hr
ON CATALOG catalog_a
COLUMN MASK mask_pii
TO `account users` EXCEPT `HR admins`
FOR TABLES
WHEN has_tag('HR')
MATCH COLUMNS has_tag('PII') AS pii_col
ON COLUMN pii_col;

Каждая политика указывает:

• Область: защищаемый объект, в котором присоединена политика, указанная предложением ON . Присоединение политики к защищаемому объекту означает, что условия политики оцениваются для всех объектов того типа, который указан в предложении FOR, в рамках этого защищаемого объекта и всех его подчиненных.
  • Поддерживаемые области политики сегодня : CATALOGSCHEMAили TABLE.
  • Таблицы, включая потоковые таблицы и материализованные представления, в настоящее время являются единственным поддерживаемым защищаемым типом, указанным в предложении FOR TABLES .
  • Политика, присоединенная к каталогу, оценивает все таблицы в этом каталоге. Политика, присоединенная к схеме, проверяется на соответствие во всех таблицах в этой схеме. Политика, подключенная к таблице, оценивается только в этой таблице.

• Основные стороны: на кого распространяется политика и кто подлежит исключению. Условие TO указывает пользователей, группы или служебные субъекты, подлежащие политике. Необязательное условие EXCEPT исключает конкретные субъекты из этой политики.
• Действия. Применяет ли политика фильтр строк или маску столбца. Действие реализуется определяемой пользователем функцией (UDF), которая определяет логику фильтрации или маскирования. См. типы политик.
• Условия: выражения на основе тегов, определяющие, на какие таблицы или столбцы направлена политика. См. условия и встроенные функции.

Политики создаются и управляются с помощью пользовательского интерфейса или программно с помощью SQL-запросов, таких как CREATE POLICY, DROP POLICY, SHOW POLICIES, или DESCRIBE POLICY, REST API, SDK Databricks или Terraform. См. статью "Создание политик ABAC и управление ими " для полного синтаксиса и примеров.

Типы политик

ABAC поддерживает два типа политик: политики фильтрации строк и политики маски столбцов. Для реализации логики фильтрации или маскирования требуются UDF.

Политики фильтрации строк

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

Пример использования: Для каталога продаж убедитесь, что команда EMEA видит только записи продаж EMEA во всех таблицах с тегами столбцов region.

CREATE FUNCTION filter_by_region(region STRING, allowed STRING) RETURNS BOOLEAN
    RETURN region = allowed;

CREATE POLICY regional_access_emea
ON CATALOG sales
ROW FILTER filter_by_region
TO `emea team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS rgn
USING COLUMNS (rgn, 'EMEA');

Политики маскирования столбцов

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

Пример использования: Маскировать столбцы SSN, помеченные так pii : ssn , чтобы пользователи видели ***-**-XXXX (только последние четыре цифры), если они не находятся в группе соответствия требованиям, исключенной из политики.

CREATE FUNCTION mask_ssn(ssn STRING, show_last INT) RETURNS STRING
    RETURN CONCAT('***-**-', RIGHT(ssn, show_last));

CREATE POLICY mask_ssn_columns
ON CATALOG hr_catalog
COLUMN MASK mask_ssn
TO `account users` EXCEPT `compliance team`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col
USING COLUMNS (4);

Инструкция USING COLUMNS передает аргументы в UDF. Он принимает псевдонимы для столбцов, соответствующих выражению на основе тегов, или константных значений (строк, заключённых в кавычки, числовых литералов, логических значений (TRUE/FALSE) или NULL), предоставленных в порядке их ожидания функцией. Для политик маски столбцов это дополнительные аргументы за пределами маскированного столбца (который автоматически привязан к ON COLUMN). Это позволяет повторно использовать один UDF в разных политиках с разными параметрами.

Функции SQL, определяемые пользователем, рекомендуются для повышения производительности. Функции Python UDF, зарегистрированные в каталоге Unity, также поддерживаются, хотя оптимизатор запросов не может встраивать или оптимизировать их так же эффективно, как UDF SQL. Рекомендации по выбору языка UDF см. в рекомендациях по повышению производительности .

Условия и встроенные функции

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

• Условия таблицы (WHEN предложение): логические выражения, соответствующие таблицам на основе их тегов. Если опущено, значение по умолчанию TRUEозначает, что политика применяется ко всем таблицам в области.
• Условия столбца (MATCH COLUMNS предложение): одно или несколько логических выражений, разделенных запятыми, которые определяют, какие столбцы затрагиваются политикой. Каждое выражение может быть одной встроенной функцией, например has_tag('pii'), или сочетанием с помощью логических операторов, таких как has_tag_value('pii', 'ssn') AND has_tag('sensitive'). Каждому выражению может быть назначен псевдоним (указанный после AS), на который можно ссылаться в предложениях ON COLUMN и USING COLUMNS. Политика может включать до 3 выражений столбцов, и все они должны соответствовать политике для применения.

Оба типа предложения используют следующие встроенные функции, вычисляемые каталогом Unity с защищаемыми метаданными:

Теги не распространяются из таблиц на столбцы. Использование has_tag() в MATCH COLUMNS предложении соответствует только тегам уровня столбца, а не тегам родительской таблицы или ее предкам.

Пример: использование двух условий для столбцов. Схема customers содержит таблицы со столбцом электронной почты, помеченным тегом pii : email, и столбцом согласия, помеченным тегом consent_to_contact. Политика маскирует адреса электронной почты, если клиент не согласился связаться. В нем используются два условия столбца:

1. has_tag_value('pii', 'email') определяет столбец, содержащий адреса электронной почты (столбец для маскирования).
2. has_tag('consent_to_contact') определяет столбец, содержащий сведения о согласии (используется UDF для определения того, следует ли маскировать).

CREATE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = true THEN email
  ELSE '****@****.***'
END;

CREATE POLICY mask_email_with_consent
ON SCHEMA customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('consent_to_contact') AS c
ON COLUMN m
USING COLUMNS (c);

Эта политика применяется только к таблицам, которые имеют как столбец с тегом pii : email, так и столбец с тегом consent_to_contact. Если в таблице нет столбцов, соответствующих обоим условиям, политику невозможно применить, и данные остаются открытыми.

Определяемые пользователем функции

Политики фильтрации строк и маскировки столбцов используют определяемые пользователем функции для реализации логики фильтрации или маскирования. См. определяемые пользователем функции (ОПФ) в каталоге Unity для создания и управления ОПФ, и общие шаблоны для фильтрации строк и маскирования столбцов для примеров.

Разделение обязанностей и разрешений

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

1. Создайте таксономию тега. Определите ключи тегов и их допустимые значения, прежде чем их начнут применять или задействовать в правилах. Например, создайте sensitivity тег с управляемыми значениями (public, , internalconfidential, restricted) или pii тегом со значениями, такими как ssn, emailи phone_number. Обратитесь к стандартизации атрибутов и именования, чтобы получить рекомендации по соглашениям об именовании и проектированию таксономии.

   • Необходимые разрешения: администратор учетной записи или пользователь с CREATE разрешением для тегов на уровне учетной записи.

2. Тег ресурсов данных. Управление данными, создатель данных или система классификации ИИ применяет теги, управляемые к каталогам, схемам, таблицам или столбцам. Например, столбцы тегов, содержащие личную информацию.pii : ssn Правильный тег — это основной шаг применения политик ABAC.

   • Необходимые разрешения: ASSIGN для тега и APPLY TAG объекта.

3. Создание политики. Администратор системы управления создает политику в области, например каталог или схему. Политика указывает, к кому он применяется, какие условия он оценивает, и UDF, реализующий логику фильтрации или маскирования.

   • Необходимые разрешения: MANAGE разрешение или владение объектом безопасности, к которому политика подключена (каталог, схема или таблица), и EXECUTE привилегия на UDF.

4. Создание объектов данных. Создатели данных создают таблицы в областях, к которым они получили доступ. Новые таблицы наследуют теги от родительских объектов, таких как каталоги и схемы. Создатели данных также автоматически используют APPLY TAG объекты, которые они создают, поэтому они могут применять дополнительные теги. Кроме того, они могут полагаться на автоматическую классификацию данных для обработки тегов. Если организация полагается на создателей данных, чтобы пометить собственные объекты, следует установить четкие методики тегов. Создатели данных не обязаны настраивать элементы управления доступом, если политики установлены на более высоких уровнях, как рекомендует Azure Databricks.

   • Необходимые разрешения: CREATE TABLE или другие соответствующие привилегии создания родительского объекта.

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

   • Необходимые разрешения: пользователям необходимо предоставить разрешения на таблицу, например SELECT, посредством прямого предоставления объекта. Фильтры строк ABAC и политики маскирования столбцов не предоставляют разрешения самостоятельно. Они фильтруют только записи или маскируют столбцы для таблиц, к которым пользователь уже может получить доступ.

Преимущества ABAC

• Повторно используемые политики на основе атрибутов: Одна политика может применяться к нескольким объектам данных, которые соответствуют одинаковым условиям на основе атрибутов, а не привязаны к одному конкретному объекту.

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

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

• Снижение текущего обслуживания: Изменения можно внести, обновив логику политики или управляемые теги, а не пересмотреть каждый отдельный объект, как это необходимо с фильтрами строк на уровне таблицы и масками столбцов.

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

Дополнительные сведения

• Управляемые теги
• CREATE POLICY
• Управление привилегиями в каталоге Unity
• Фильтры строк и маски столбцов
• Справочник по системной таблице журнала аудита
• Требования, квоты и ограничения ABAC