Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLección 3 de 5
Databricks-to-Open y OIDC
Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
17 min aprox.
03OperaciónDatabricks-to-Open y OIDC
Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
+
Databricks-to-Open y OIDC
Gobierna sharing con auditoría, residencia, egress, rotación y compatibilidad de políticas antes de incorporar un consumidor.
El proveedor conserva el control y puede revocar el recipient o retirar activos. Registra owner, propósito, región, base legal, clasificación, protocolo y método de autenticación. Audita acciones de shares/recipients y accesos según las system tables disponibles. Si usas bearer credentials, almacénalas como secretos, rota con solapamiento y destruye copias antiguas.
Row filters/masks y ABAC tienen limitaciones específicas al compartir; no presupongas que una política aplicada a la fuente se reproduce igual en el receptor. Prueba el share con una identidad real del recipient. Modela egress cloud y foreign compute en el coste, especialmente para vistas, materialized views, streaming tables o datos federados.
SHOW SHARES;
SHOW RECIPIENTS;
SHOW ALL IN SHARE retail_partner;
-- Conserva la salida con owner, propósito y fecha de revisión
-- en una tabla de control gobernada, no en una hoja personal.Complementa el inventario con audit logs y el contrato del recipient; `SHOW` por sí solo no describe la base legal ni el coste.
¿Qué prueba demuestra mejor que una revocación funciona?
Profundiza
Sharing cruza una frontera organizativa aunque los datos permanezcan en almacenamiento del proveedor. Cada consulta puede generar transferencia, credenciales temporales y eventos de acceso; por eso la evaluación abarca residencia, egress, identidad, retención y compatibilidad, no sólo un GRANT. Provider y recipient tienen responsabilidades distintas: el primero decide qué expone y monitorea solicitudes; el segundo gobierna quién puede leer el catálogo recibido y qué copias deriva. Una política ABAC del proveedor puede tener limitaciones o no gobernar el lado receptor como se imagina; el consumidor necesita sus propios controles. Bearer tokens se rotan y distribuyen con cuidado, OIDC se prefiere cuando está disponible, y todo onboarding incluye una prueba real de revocación.
Transferencia de datos desde la región o proveedor de almacenamiento hacia otra red, región, nube o consumidor externo.
Puede introducir coste, latencia y restricciones de residencia aunque OpenSharing evite una copia administrada previa.Credencial de alcance y duración reducidos generada para que un cliente lea únicamente datos autorizados de un share.
Limita exposición frente a claves permanentes, pero su generación y uso todavía requieren auditoría y controles.División de obligaciones donde provider gobierna publicación y recipient gobierna acceso y derivados dentro de su organización.
Evita asumir que una policy del origen protege automáticamente copias, usuarios o retención en el consumidor.Resumen
Puntos clave
- Prueba la experiencia y restricciones desde el lado receptor.
- Incluye egress, compute y fuente remota en FinOps del share.
- Ensaya rotación y revocación antes del incidente.
Evita
- Suponer que una mask de la tabla base siempre se conserva igual en OpenSharing.
- Crear recipients sin owner o fecha de revisión y acumular acceso huérfano.