Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 4 de 5
ABAC y políticas centralizadas
Demuestra quién hizo qué con audit, extiende lineage a sistemas externos y comunica confianza o deprecación sin convertir una etiqueta en garantía oficial.
17 min aprox.
04DiagnósticoABAC y políticas centralizadas
Demuestra quién hizo qué con audit, extiende lineage a sistemas externos y comunica confianza o deprecación sin convertir una etiqueta en garantía oficial.
+
ABAC y políticas centralizadas
Demuestra quién hizo qué con audit, extiende lineage a sistemas externos y comunica confianza o deprecación sin convertir una etiqueta en garantía oficial.
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 automático cubre interfaces compatibles ejecutadas en Databricks. Para first-mile o last-mile externos, crea external metadata objects y relaciones external lineage hacia tablas, modelos, paths u otros objetos externos; eso documenta flujo, no actor ni acceso. `system.certification_status` permite marcar activos como `certified` o `deprecated` según estándares internos: mejora descubrimiento, pero no convierte el activo en requisito oficial ni sustituye pruebas, owner o contrato.
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.
¿Qué modela un external metadata object y qué no demuestra?
Profundiza
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.
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.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 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.Resumen
Puntos clave
- Audit responde actor/acción; lineage, procedencia/consumo.
- External metadata objects enlazan first-mile y last-mile fuera de Databricks.
- Certified/deprecated expresa una decisión interna gobernada, no una garantía automática.
Evita
- Interpretar ausencia de lineage de una API no soportada como prueba de que no hubo acceso.
- Marcar un activo como certified sin criterio, evidencia, owner o revisión periódica.