Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 30 · Professional

Seguridad

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Professional

Unity Catalog avanzado y privacidad

Aplica controles centralizados a datos sensibles y demuestra cumplimiento mediante auditoría.

Lectura pública
Al terminar podrás
  • Diseñar herencia y ownership
  • Aplicar row filters, masks y ABAC
  • Implementar retención, anonimización y purga
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
delivery
Dominios blueprint
Data Security and Compliance · Data Governance
Estado
Revisión editorial interna
Fuentes principales
Access control in Unity Catalog · Attribute-based access control in Unity Catalog
Reportar un error
01
Modelo mental

Modelo de privilegios e inheritance

Construye acceso base con ownership, grupos y herencia de privilegios, evitando grants directos a personas y propietarios operativos ambiguos.

Objetivo
Construye acceso base con ownership, grupos y herencia de privilegios, evitando grants directos a personas y propietarios operativos ambiguos.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m29
Reportar un error en esta lección

Unity Catalog evalúa privilegios en una jerarquía. Para consultar una tabla suelen intervenir `USE CATALOG`, `USE SCHEMA` y `SELECT`; los grants sobre catálogo o esquema pueden heredarse por descendientes según el modelo de privilegios. Ownership concede capacidades amplias, mientras `MANAGE` permite administrar permisos sin transferir propiedad en los objetos compatibles.

Asigna privilegios a grupos de cuenta y service principals, no a usuarios individuales. Separa productores, consumidores y administradores de políticas. El propietario de un catálogo no debería ser una persona que puede marcharse, sino un grupo gobernado. Usa `SHOW GRANTS` e information schema para revisar acceso efectivo antes de añadir otro grant aparentemente necesario.

Modelo mental

Unity Catalog combina una jerarquía de securables con dos ideas distintas: ownership y privilegios. El owner puede administrar el objeto y delegar; un privilegio autoriza una acción concreta. Los usuarios necesitan además atravesar la jerarquía mediante USE CATALOG y USE SCHEMA antes de SELECT u otro permiso sobre el objeto. La herencia permite conceder en catálogo o schema para objetos presentes y futuros, lo que simplifica pero amplía alcance. El modelo sostenible asigna permisos a grupos por función y ownership a grupos operativos o principals, nunca a individuos como mecanismo normal. El mínimo privilegio no es el menor número de grants, sino el conjunto mínimo comprensible que permite trabajo y puede revocarse sin romper ownership.

Securable

Objeto gobernado de Unity Catalog sobre el que pueden asignarse ownership, privilegios, políticas o restricciones de workspace.

Define la unidad exacta de autorización y evita hablar de acceso genérico sin identificar catálogo, schema o activo.
Privilege inheritance

Propagación de determinados privilegios concedidos en un contenedor hacia sus objetos descendientes actuales y futuros.

Simplifica administración, pero un grant demasiado alto puede ampliar acceso automáticamente cuando aparecen objetos nuevos.
Ownership operativo

Asignación de propietario a un grupo o principal estable responsable del ciclo de vida, en vez de una persona.

Evita objetos huérfanos y mantiene administración cuando cambian miembros, equipos o cuentas individuales.
SQLAcceso de sólo lectura por grupo
GRANT USE CATALOG ON CATALOG prod TO finance_analysts;
GRANT USE SCHEMA ON SCHEMA prod.gold TO finance_analysts;
GRANT SELECT ON TABLE prod.gold.daily_margin TO finance_analysts;

SHOW GRANTS ON TABLE prod.gold.daily_margin;

Si todo el esquema comparte el mismo contrato, evalúa un grant en esquema; no amplíes más de lo que el grupo necesita.

Puntos clave

  • Concede a grupos y hereda desde el nivel más estable y limitado.
  • Ownership no es el mecanismo cotidiano para consumir datos.
  • Verifica privilegios efectivos y prerequisitos `USE` antes de ampliar acceso.

Evita

  • Conceder `ALL PRIVILEGES` a usuarios para resolver un `USE SCHEMA` ausente.
  • Dejar catálogos productivos propiedad de una cuenta personal.

Recuerdo activo

Un grupo tiene `SELECT` sobre una tabla pero no puede consultarla. ¿Qué privilegios de navegación revisarías?

Borrador privado · solo en este navegador
02
Implementación

Workspace ACLs y securables

Escala protección con governed tags y ABAC para que nuevos objetos clasificados reciban políticas sin grants o masks manuales por tabla.

Objetivo
Escala protección con governed tags y ABAC para que nuevos objetos clasificados reciban políticas sin grants o masks manuales por tabla.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m29
Reportar un error en esta lección

Governed tags son etiquetas de cuenta con valores permitidos y permisos de asignación. Heredan desde catálogo y esquema a objetos descendientes, salvo reglas específicas como columnas. ABAC evalúa esos atributos y aplica políticas de row filter o column mask en el ámbito definido. Así el equipo de gobierno escribe una política y los data stewards clasifican objetos sin poder desactivar la protección.

ABAC requiere compute compatible y governed tags, no etiquetas libres. Cambios de tag pueden tardar unos minutos en aplicarse. Diseña taxonomías pequeñas —clasificación, región, dominio— y evita PII en valores de tag porque pueden replicarse globalmente. Prueba conflictos: si varias políticas distintas aplican al mismo usuario/objeto, el acceso puede bloquearse de forma segura.

Modelo mental

ABAC protege datos por atributos, no por una lista manual en cada tabla. Los governed tags forman una taxonomía controlada a nivel de cuenta; una policy adjunta a catálogo, schema o tabla selecciona objetos cuyas etiquetas cumplen una condición y aplica row filter o column mask. Cuando aparece una columna nueva etiquetada como PII, la política puede actuar automáticamente sin esperar otro ALTER TABLE. Eso escala sólo si la clasificación es fiable, los tags tienen ownership y la función de política es simple. ABAC complementa privilegios: primero el usuario necesita acceso al objeto; después la política limita filas o valores visibles. No sustituye minimización, workspace binding ni una revisión de limitaciones de compute y sharing.

Governed tag

Atributo de catálogo definido con valores y permisos controlados que clasifica securables para políticas y gobierno consistentes.

Impide etiquetas libres contradictorias y proporciona una señal confiable para aplicar ABAC automáticamente a escala.
ABAC policy

Política central que selecciona objetos por atributos y aplica filtros de filas o máscaras de columnas en tiempo de consulta.

Protege objetos presentes y futuros de forma uniforme sin mantener reglas manuales separadas para cada tabla.
Policy scope

Nivel jerárquico donde se adjunta una política y desde el que puede evaluar objetos descendientes que coincidan.

Determina alcance y blast radius; una policy de catálogo exige pruebas más amplias que una de tabla.
SQLClasificar una tabla con tags gobernados
ALTER TABLE prod.hr.employees
SET TAGS (
  'data_classification' = 'restricted',
  'data_region' = 'eu'
);

SHOW TAGS ON TABLE prod.hr.employees;

Los tags deben existir y el ejecutor necesita permiso ASSIGN; la política ABAC se gestiona por separado en el ámbito del catálogo o esquema.

Puntos clave

  • Los tags gobernados controlan valores y quién puede asignarlos.
  • ABAC separa autores de política de propietarios de tablas.
  • Prueba compatibilidad de compute, herencia y conflictos de políticas.

Evita

  • Crear etiquetas libres con variantes `PII`, `pii` y `personal` y esperar una política coherente.
  • Guardar nombres de clientes o emails en tags para decidir acceso.

Recuerdo activo

¿Por qué ABAC escala mejor que una mask configurada manualmente en cada tabla?

Borrador privado · solo en este navegador
03
Operación

Row filters y column masks

Aplica row filters y column masks con funciones simples, deterministas y auditables, entendiendo su impacto en optimización e interoperabilidad.

Objetivo
Aplica row filters y column masks con funciones simples, deterministas y auditables, entendiendo su impacto en optimización e interoperabilidad.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m29
Reportar un error en esta lección

Un row filter devuelve boolean y elimina filas que el usuario no debe ver; una column mask devuelve el valor original o transformado con un tipo compatible. Pueden asignarse directamente a una tabla mediante UDFs SQL o centralizarse con ABAC. La política se evalúa en query time y la seguridad prima sobre optimizaciones que pudieran filtrar información.

Mantén UDFs simples: evita agregaciones, ventanas y lógica no determinista que limite `MERGE` o pushdown. Prueba cada grupo con usuarios representativos, incluyendo administradores exentos y service principals. Acceso por path y ciertos clientes externos no soportan tablas con políticas; inventaría interoperabilidad y crea una vista o share seguro cuando proceda.

Modelo mental

Row filters y column masks son transformaciones de seguridad insertadas en la consulta. Un row filter decide si cada fila puede atravesar; una mask sustituye el valor visible de una columna y debe devolver un tipo compatible. Pueden asignarse manualmente a una tabla o centralizarse mediante ABAC, opción recomendada para reglas repetidas. Como el motor debe impedir inferencias sobre valores protegidos, prioriza seguridad sobre ciertas optimizaciones, y funciones complejas reducen pushdown o rendimiento. Una máscara no cifra el almacenamiento ni borra el dato; controla la vista del usuario en consultas compatibles. Las claves de join, particiones y columnas usadas en la policy merecen pruebas especiales por semántica, rendimiento y limitaciones de DML.

Row filter

Función de seguridad evaluada en consulta que devuelve verdadero únicamente para las filas visibles por la identidad actual.

Implementa segmentación regional, departamental o por tenant sin crear copias físicas separadas de cada conjunto.
Column mask

Función que sustituye dinámicamente el valor mostrado de una columna mientras conserva un tipo compatible con su contrato.

Permite compartir estructura y datos no sensibles sin exponer el valor original a lectores no autorizados.
Secure optimization

Principio por el que el motor limita transformaciones del plan si podrían revelar información protegida por filtros o máscaras.

Explica por qué una policy correcta puede cambiar pushdown o rendimiento y exige medición específica.
SQLFiltro regional y mask de email por tabla
CREATE OR REPLACE FUNCTION prod.governance.region_filter(region STRING)
RETURN IF(is_account_group_member('finance_global'), TRUE, region = 'EU');

CREATE OR REPLACE FUNCTION prod.governance.mask_email(email STRING)
RETURN IF(
  is_account_group_member('pii_readers'),
  email,
  CONCAT('***@', element_at(split(email, '@'), -1))
);

ALTER TABLE prod.sales.customers
SET ROW FILTER prod.governance.region_filter ON (region);

ALTER TABLE prod.sales.customers
ALTER COLUMN email SET MASK prod.governance.mask_email;

El filtro fijo a EU es un ejemplo de laboratorio; en producción mapea identidad a región mediante una tabla de autorización gobernada.

Puntos clave

  • Row filter controla filas; column mask transforma valores visibles.
  • El tipo de la mask debe ser compatible con la columna.
  • Políticas complejas pueden afectar DML, pushdown y clientes externos.

Evita

  • Implementar una mask que cambia STRING por un tipo incompatible.
  • Usar una UDF no determinista o con subconsultas complejas y bloquear DML necesario.

Recuerdo activo

¿Qué ocurre con una fila si el row filter devuelve FALSE?

Borrador privado · solo en este navegador
04
Diagnóstico

ABAC y políticas centralizadas

Demuestra quién hizo qué mediante `system.access.audit` y lineage, manteniendo separación de funciones y acceso restringido a telemetría sensible.

Objetivo
Demuestra quién hizo qué mediante `system.access.audit` y lineage, manteniendo separación de funciones y acceso restringido a telemetría sensible.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m29
Reportar un error en esta lección

El audit log system table registra eventos de cuenta y workspace con identidad, servicio, acción, parámetros y respuesta. Consulta cambios de permisos, tags, policies y accesos dentro de la región y retención documentada. Los eventos de creación, modificación y eliminación de políticas ABAC son auditables; una alerta debe filtrar acciones relevantes y enlazar el objeto afectado.

Lineage de Unity Catalog captura lecturas y escrituras a nivel de tabla y columna para interfaces compatibles, y ayuda a analizar impacto de un cambio o flujo de PII. No reemplaza auditoría: lineage explica flujo, audit explica acción/actor. Expón vistas redactadas a seguridad y operaciones; no distribuyas request parameters completos sin evaluar secretos o datos personales.

Modelo mental

Auditoría responde quién intentó qué, cuándo, desde dónde y con qué resultado; lineage responde qué activos leyó o escribió una operación cuando esa relación pudo inferirse. Son fuentes complementarias, no equivalentes. system.access.audit registra eventos de control y acceso con parámetros y respuestas; las system tables de lineage registran relaciones a nivel de tabla o columna para entidades capturadas. Lineage tiene cobertura parcial por diseño y la ausencia de un edge no demuestra ausencia de acceso. Ambas fuentes contienen identidades, nombres y consultas potencialmente sensibles, por lo que su acceso debe ser más estrecho que el dashboard que derivan. La evidencia útil conserva IDs, timestamps y granularidad sin exportar indiscriminadamente todo el plano de control.

Audit event

Registro de una acción de cuenta o workspace con actor, operación, tiempo, parámetros relevantes y resultado observado.

Proporciona evidencia para cambios de permisos, accesos, despliegues e investigaciones de responsabilidad y cumplimiento.
Data lineage

Relación inferida entre activos de origen, destino y entidad ejecutora durante una lectura o escritura capturable.

Ayuda a evaluar impacto y trazabilidad, pero su cobertura parcial exige no interpretar ausencia como prueba negativa.
Vista redactada

Vista gobernada que expone sólo columnas y filas necesarias de telemetría sensible para una audiencia concreta.

Permite observabilidad operativa sin entregar consultas, identidades o parámetros completos a todos los consumidores.
SQLAuditar cambios de permisos y políticas
SELECT
  event_time,
  user_identity.email AS actor,
  service_name,
  action_name,
  request_params,
  response.status_code AS status_code
FROM system.access.audit
WHERE event_time >= current_timestamp() - INTERVAL 24 HOURS
  AND (
    lower(action_name) LIKE '%grant%'
    OR lower(action_name) LIKE '%policy%'
    OR lower(action_name) LIKE '%tag%'
  )
ORDER BY event_time DESC;

Valida los action names reales de tu cuenta y limita la vista; `request_params` puede contener información que no necesita todo el equipo.

Puntos clave

  • Audit responde actor y acción; lineage, procedencia y consumo.
  • Restringe columnas y filas de telemetría según función.
  • Alerta sobre cambios de grants, policies, tags y accesos anómalos.

Evita

  • Conceder acceso al audit log completo a quienes sólo investigan un catálogo.
  • Interpretar ausencia de lineage de una API no soportada como prueba de que no hubo acceso.

Recuerdo activo

¿Qué fuente usarías para saber quién revocó un grant y cuál para descubrir dashboards afectados?

Borrador privado · solo en este navegador
05
Decisión de diseño

PII, tokenización, retención y auditoría

Integra privacidad con clasificación, minimización, workspace bindings, retención y pruebas de acceso negativas.

Objetivo
Integra privacidad con clasificación, minimización, workspace bindings, retención y pruebas de acceso negativas.
Duración estimada
17 min aprox.
Dificultad
Professional
Prerrequisitos
m29
Reportar un error en esta lección

Privacidad no se limita a una mask. Clasifica datos, minimiza columnas, limita retención y separa ambientes. Workspace bindings restringen desde qué workspaces pueden usarse catálogos, external locations o storage credentials; combinados con grants y ABAC reducen el radio de exposición. Las tablas administradas permiten a Unity Catalog controlar también el ciclo de vida de almacenamiento.

Prueba políticas desde tres perspectivas: usuario autorizado ve original, usuario restringido ve mask/filtro y principal no autorizado recibe denegación. Añade pruebas de path bypass, clones, time travel y shares según las limitaciones actuales. Cuando se comparte fuera, publica una vista/tabla derivada con minimización y contrato, no la tabla sensible por comodidad.

Modelo mental

Privacidad es una propiedad end-to-end, no una máscara colocada al final. Empieza preguntando si el dato debe recopilarse, con qué finalidad, durante cuánto tiempo y en qué regiones; continúa con clasificación, acceso, minimización, retención, sharing y borrado verificable. Unity Catalog aporta ownership, tags, policies, lineage y workspace bindings, pero cada control cubre una frontera distinta. Un catálogo vinculado a un workspace limita desde dónde se accede; ABAC limita lo visible; retención limita cuánto persiste; ninguna reemplaza las demás. Las pruebas negativas demuestran que identidades, workspaces y consumidores no autorizados fallan. El diseño también conserva capacidad de investigación sin replicar PII en logs o etiquetas de coste.

Minimización

Principio de recopilar, procesar y compartir únicamente los atributos y periodos necesarios para una finalidad explícita.

Reduce impacto de incidentes, coste de gobierno y complejidad de cumplir borrado, residencia y acceso.
Workspace binding

Restricción que limita determinados objetos de Unity Catalog a un conjunto aprobado de workspaces dentro de la cuenta.

Añade una frontera de entorno incluso cuando una identidad posee privilegios sobre el objeto gobernado.
Prueba negativa de acceso

Verificación automatizada de que una identidad, workspace u operación fuera del contrato recibe una denegación efectiva.

Demuestra controles reales y detecta herencia, excepciones o bindings que una inspección de configuración podría pasar por alto.
SQLVista minimizada para consumo analítico
CREATE OR REPLACE VIEW prod.analytics.customer_activity_safe AS
SELECT
  sha2(CAST(customer_id AS STRING), 256) AS customer_key,
  region,
  DATE_TRUNC('month', last_order_at) AS activity_month,
  order_count_12m
FROM prod.sales.customers
WHERE consent_analytics = TRUE;

GRANT SELECT ON VIEW prod.analytics.customer_activity_safe
TO marketing_analysts;

Hashing no es anonimización automática; evalúa reidentificación, salt/gestión de claves y necesidad real de cada atributo.

Puntos clave

  • Combina clasificación, mínimo privilegio, bindings y ciclo de vida.
  • Incluye pruebas negativas y de bypass en cada release de política.
  • Comparte productos minimizados en lugar de exponer fuentes sensibles.

Evita

  • Creer que una mask sustituye consentimiento, retención y minimización.
  • Probar sólo con un administrador y no verificar la experiencia del usuario restringido.

Recuerdo activo

¿Qué añade un workspace binding a un grant de Unity Catalog?

Borrador privado · solo en este navegador
5 lecciones pendientes

Vista de lectura · sin ejecución

Startup ERP Data Lakehouse

Startup ERP Data Lakehouse · commit ba6c71b

notebooks/01_bronze_generate_startup_erp_data.py