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

ABAC y políticas centralizadas

Contenido abierto

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

Lección 4 de 5

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.

Duración
17 min aprox.
Objetivo
Demuestra quién hizo qué mediante `system.access.audit` y lineage, manteniendo separación de funciones y acceso restringido a telemetría sensible.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Unity Catalog avanzado y privacidad

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

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
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.

Mostrar prerrequisitos
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
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