Privilegios y objetos protegibles en metastore de Hive (heredado)

En este artículo se describe el modelo de privilegios para el metastore de Hive de Azure Databricks heredado, que está integrado en cada área de trabajo de Azure Databricks. También se describe cómo conceder, denegar y revocar privilegios para objetos en el metastore de Hive integrado. Unity Catalog usa un modelo diferente para conceder privilegios. Consulte Privilegios de Unity Catalog y objetos protegibles.

Nota:

El control de acceso de tabla para los datos administrados por el metastore de Hive es un modelo de gobernanza de datos heredado. Databricks le recomienda actualizar las tablas administradas por el metastore de Hive al metastore de Unity Catalog. Unity Catalog simplifica la seguridad y la gobernanza de los datos al proporcionar un lugar central para administrar y auditar el acceso a los datos en varias áreas de trabajo de la cuenta. Para más información sobre cómo difiere el modelo de privilegios heredado del modelo de privilegios de Unity Catalog, consulte Trabajar con Unity Catalog y el metastore de Hive heredado.

Requisitos

Nota:

  • El control de acceso a datos siempre está habilitado en Databricks SQL, incluso si el control de acceso a tablas no está habilitado en el área de trabajo.
  • Si el control de acceso a tablas está habilitado en el área de trabajo y ya ha especificado ACLS (privilegios concedidos y denegados) en él, esas ACL se respetan en Databricks SQL.

Administración de privilegios en objetos en el metastore de Hive

Los privilegios de los objetos de datos administrados por el metastore de Hive se pueden conceder mediante un administrador del área de trabajo o el propietario de un objeto. Puede administrar privilegios para objetos de metastore de Hive mediante comandos SQL.

Para administrar privilegios en SQL, use las instrucciones GRANT, REVOKE, DENY, MSCK y SHOW GRANTS en un cuaderno o en el editor de consultas SQL de Databricks mediante la sintaxis siguiente:

GRANT privilege_type ON securable_object TO principal

Donde:

Para conceder un privilegio a todos los usuarios del área de trabajo, conceda el privilegio al grupo users. Por ejemplo:

GRANT SELECT ON TABLE <schema-name>.<table-name> TO users

Para obtener más información sobre cómo administrar privilegios para objetos en el metastore de Hive con comandos de SQL, consulte Privilegios y objetos protegibles en el metastore de Hive.

También puede administrar el control de acceso a las tablas en una configuración totalmente automatizada, mediante el proveedor de Terraform de Databricks y databricks_sql_permissions.

Propiedad del objeto

Cuando el control de acceso a las tablas está habilitado en un clúster o un almacén de SQL, el usuario que cree un esquema, una tabla, una vista o una función se convierte en su propietario. Al propietario se le conceden todos los privilegios y puede conceder privilegios a otros usuarios.

Los grupos pueden poseer objetos; en este caso, todos los miembros del grupo se consideran propietarios.

El propietario de un objeto o un administrador de área de trabajo pueden transferir la propiedad de un objeto mediante el siguiente comando:

ALTER <object> OWNER TO `<user-name>@<user-domain>.com`

Nota:

Cuando el control de acceso a las tablas está deshabilitado en un clúster o almacén de SQL, los propietarios no se registran cuando se crea un esquema, una tabla o una vista. Un administrador de área de trabajo debe asignar un propietario al objeto mediante el comando ALTER <object> OWNER TO.

Objetos protegibles en el metastore de Hive

Los objetos protegibles son:

  • CATALOG: controla el acceso a todo el catálogo de datos.

    • SCHEMA: controla el acceso a un esquema.
      • TABLE: controla el acceso a una tabla administrada o externa.
      • VIEW: controla el acceso a las vistas de SQL.
      • FUNCTION: controla el acceso a una función con nombre.
  • ANONYMOUS FUNCTION: controla el acceso a las funciones anónimas o temporales.

    Nota:

    Los objetos ANONYMOUS FUNCTION no se admiten en Databricks SQL.

  • ANY FILE: controla el acceso al sistema de archivos subyacente.

    Advertencia

    Los usuarios a los que se concede acceso a ANY FILE pueden omitir las restricciones que se aplican al catálogo, los esquemas, las tablas y las vistas mediante la lectura directa desde el sistema de archivos.

Nota:

No se admiten privilegios en las vistas temporales globales y locales. Las vistas temporales locales solo son visibles dentro de la misma sesión y las vistas creadas en el esquema global_temp son visibles para todos los usuarios que comparten un clúster o un almacén de SQL. Sin embargo, se aplican privilegios en las tablas y vistas subyacentes a las que hace referencia cualquier vista temporal.

Privilegios que puede conceder en los objetos de metastore de Hive

  • SELECT: otorga acceso de lectura a un objeto.
  • CREATE: da la capacidad de crear un objeto (por ejemplo, una tabla en un esquema).
  • MODIFY: permite agregar, eliminar y modificar datos en un objeto o a partir de un objeto.
  • USAGE: no proporciona ninguna capacidad, pero es un requisito adicional para realizar cualquier acción en un objeto de esquema.
  • READ_METADATA: brinda la capacidad de ver un objeto y sus metadatos.
  • CREATE_NAMED_FUNCTION: da la capacidad de crear una UDF con nombre en un catálogo o esquema existentes.
  • MODIFY_CLASSPATH: permite agregar archivos a la ruta de acceso de clase de Spark.
  • ALL PRIVILEGES: concede todos los privilegios (se traduce en todos los privilegios anteriores).

Nota:

El privilegio MODIFY_CLASSPATH no se admite en Databricks SQL.

Privilegio USAGE

Para realizar una acción en un objeto de esquema en el metastore de Hive, el usuario debe tener el privilegio USAGE en ese esquema además del privilegio para realizar esa acción. Cualquiera de los siguientes cumple el requisito USAGE:

  • Ser un administrador del área de trabajo
  • Tener el privilegio USAGE en el esquema o estar en un grupo que tenga el privilegio USAGE en el esquema.
  • Tener el privilegio USAGE en CATALOG o estar en un grupo que tenga el privilegio USAGE.
  • Ser el propietario del esquema o estar en un grupo que posea el esquema.

Incluso el propietario de un objeto dentro de un esquema debe tener el privilegio USAGE para poder usarlo.

Jerarquía de los privilegios

Cuando el control de acceso a las tablas está habilitado en el área de trabajo y en todos los clústeres, los objetos de SQL de Azure Databricks son jerárquicos y los privilegios se heredan hacia abajo. Esto significa que conceder o denegar un privilegio en CATALOG concede o deniega automáticamente el privilegio a todos los esquemas del catálogo. De igual modo, todos los objetos de del esquema heredan los privilegios concedidos a un objeto de ese esquema. Este patrón se cumple para todos los objetos protegibles.

Si se deniegan privilegios de usuario en una tabla, el usuario no podrá ver la tabla cuando intente enumerar todas las tablas del esquema. Si se deniegan privilegios de usuario en un esquema, el usuario no podrá ver el esquema cuando intente enumerar todos los esquemas del catálogo.

Funciones de vista dinámica

Azure Databricks incluye dos funciones de usuario que permiten expresar permisos de columna y fila dinámicamente en el cuerpo de una definición de vista que se administra en el metastore de Hive.

  • current_user(): devuelve el nombre del usuario actual.
  • is_member(): determina si el usuario actual es miembro de un grupo de Azure Databricks específico a nivel de área de trabajo.

El ejemplo siguiente combina ambas funciones para determinar si un usuario tiene la pertenencia a grupos adecuada:

-- Return: true if the user is a member and false if they are not
SELECT
  current_user as user,
-- Check to see if the current user is a member of the "Managers" group.
  is_member("Managers") as admin

Permisos de nivel de columna

Puede usar vistas dinámicas para limitar las columnas que verá un grupo o un usuario específicos. Considere el ejemplo siguiente en el que solo los usuarios que pertenecen al grupo auditors pueden ver las direcciones de correo electrónico de la tabla sales_raw. En el momento del análisis, Spark reemplaza la instrucción CASE por el literal 'REDACTED' o la columna email. Este comportamiento permite todas las optimizaciones de rendimiento habituales que proporciona Spark.

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW sales_redacted AS
SELECT
  user_id,
  CASE WHEN
    is_group_member('auditors') THEN email
    ELSE 'REDACTED'
  END AS email,
  country,
  product,
  total
FROM sales_raw

Permisos de nivel de fila

Con las vistas dinámicas puede especificar permisos hasta el nivel de fila o campo. Considere el ejemplo siguiente, donde solo los usuarios que pertenecen al grupo managers pueden ver los importes de transacción (columna total) mayores que 1 000 000,00 USD:

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  country,
  product,
  total
FROM sales_raw
WHERE
  CASE
    WHEN is_group_member('managers') THEN TRUE
    ELSE total <= 1000000
  END;

Enmascaramiento de datos

Como se muestra en los ejemplos anteriores, puede implementar el enmascaramiento de nivel de columna para evitar que los usuarios vean datos de columna específicos a menos que estén en el grupo correcto. Dado que estas vistas son SQL Spark estándar, puede realizar tipos más avanzados de enmascaramiento con expresiones SQL más complejas. En el ejemplo siguiente se permite a todos los usuarios realizar análisis en dominios de correo electrónico, pero permite a los miembros del grupo auditors ver las direcciones de correo electrónico de los usuarios completas.

-- The regexp_extract function takes an email address such as
-- user.x.lastname@example.com and extracts 'example', allowing
-- analysts to query the domain name

CREATE VIEW sales_redacted AS
SELECT
  user_id,
  region,
  CASE
    WHEN is_group_member('auditors') THEN email
    ELSE regexp_extract(email, '^.*@(.*)$', 1)
  END
  FROM sales_raw