Mejores prácticas de seguridad para Delta Sharing

 

El lakehouse de datos nos ha permitido consolidar nuestras arquitecturas de gestión de datos, eliminando silos y aprovechando una plataforma común para todos los casos de uso. La unificación de los casos de uso de data warehousing e IA en una única plataforma es un gran avance para las organizaciones, pero una vez que han dado ese paso, la siguiente pregunta a considerar es "¿cómo compartimos esos datos de forma sencilla y segura sin importar el cliente, herramienta o plataforma que el destinatario esté utilizando para acceder a ellos?". Afortunadamente, el lakehouse también tiene una respuesta a esta pregunta: el intercambio de datos con Delta Sharing.

Delta Sharing

Delta Sharing es el primer protocolo abierto del mundo para compartir datos de forma segura en tiempo real, interna y externamente entre organizaciones, independientemente de la plataforma en la que residan los datos. Es un componente clave de la apertura de la arquitectura lakehouse, y un habilitador clave para organizar nuestros equipos de datos y patrones de acceso de maneras que no han sido posibles antes, como el data mesh.

Seguro por Diseño

Es importante tener en cuenta que Delta Sharing se ha construido desde cero pensando en la seguridad, lo que le permite aprovechar las siguientes características listas para usar, tanto si utiliza la versión de código abierto como su equivalente administrado:

• Cifrado TLS de extremo a extremo desde el cliente hasta el servidor y la cuenta de almacenamiento
• Credenciales de corta duración, como las URL pre-firmadas, se utilizan para acceder a los datos
• Administre, rastree y audite fácilmente el acceso a sus conjuntos de datos compartidos a través de Unity Catalog

Las mejores prácticas que compartiremos como parte de este blog son aditivas, lo que permite a los clientes alinear los controles de seguridad apropiados con su perfil de riesgo y la sensibilidad de sus datos.

Mejores Prácticas de Seguridad

Nuestras recomendaciones de mejores prácticas para usar Delta Sharing para compartir datos sensibles son las siguientes:

1. Evalúe la versión de código abierto frente a la versión administrada según sus requisitos
2. Establezca la duración adecuada del token del destinatario para cada metastore
3. Establezca un proceso para rotar las credenciales
4. Considere el nivel adecuado de granularidad para Shares, Destinatarios y Particiones
5. Configure Listas de Acceso IP
6. Configure el registro de auditoría de Databricks
7. Configure restricciones de red en las cuentas de almacenamiento
8. Configure el registro en las cuentas de almacenamiento

1. Evalúe la versión de código abierto frente a la versión administrada según sus requisitos

Como hemos establecido anteriormente, Delta Sharing se ha construido desde cero con la seguridad como máxima prioridad. Sin embargo, existen ventajas al usar la versión administrada:

• Delta Sharing en Databricks es proporcionado por Unity Catalog, que le permite proporcionar acceso detallado a cualquier conjunto de datos entre diferentes conjuntos de usuarios de forma centralizada desde un solo lugar. Con la versión de código abierto, necesitaría separar los conjuntos de datos que tienen varios derechos de acceso a datos entre varios servidores de intercambio, y también necesitaría imponer restricciones de acceso en esos servidores y las cuentas de almacenamiento subyacentes. Para facilitar la implementación, se proporciona una imagen de docker con la versión de código abierto, pero es importante tener en cuenta que escalar las implementaciones en grandes empresas supondrá una sobrecarga no trivial para los equipos responsables de administrarlas.
• Al igual que el resto de la Plataforma Lakehouse de Databricks, Unity Catalog se proporciona como un servicio administrado. No tiene que preocuparse por cosas como la disponibilidad, el tiempo de actividad y el mantenimiento del servicio porque nosotros nos encargamos de eso por usted.
• Unity Catalog le permite configurar capacidades completas de registro de auditoría listas para usar.
• Los propietarios de datos podrán administrar los intercambios utilizando la sintaxis SQL. Además, hay disponibles API REST para administrar los intercambios. El uso de la sintaxis SQL familiar simplifica la forma en que compartimos datos, reduciendo la carga administrativa.
• Al usar la versión de código abierto, usted es responsable de la configuración, la infraestructura y la administración del intercambio de datos, pero con la versión administrada, toda esta funcionalidad está disponible lista para usar.

Por estas razones, recomendamos evaluar ambas versiones y tomar una decisión basada en sus requisitos. Si la facilidad de configuración y uso, la gobernanza y auditoría listas para usar, y la gestión de servicios externalizada son importantes para usted, la versión administrada probablemente será la opción correcta.

2. Establezca la duración adecuada del token del destinatario para cada metastore

Cuando habilita Delta Sharing, configura la duración del token para las credenciales del destinatario. Si establece la duración del token en 0, los tokens del destinatario nunca caducan.

Establecer la duración adecuada del token es de vital importancia desde el punto de vista regulatorio, de cumplimiento y reputacional. Tener un token que nunca caduca es un gran riesgo; por lo tanto, se recomienda usar tokens de corta duración como mejor práctica. Es mucho más fácil otorgar un nuevo token a un destinatario cuyo token ha caducado que investigar el uso de un token cuya duración se ha configurado incorrectamente.

Consulte la documentación (AWS, Azure) para configurar tokens para que caduquen después del número apropiado de segundos, minutos, horas o días.

3. Establezca un proceso para rotar las credenciales

Hay varias razones por las que podría querer rotar las credenciales, desde la caducidad de un token existente, preocupaciones de que una credencial pueda haber sido comprometida, o incluso simplemente porque ha modificado la duración del token y desea emitir nuevas credenciales que respeten ese tiempo de expiración.

Para garantizar que dichas solicitudes se cumplan de manera predecible y oportuna, es importante establecer un proceso, preferiblemente con un SLA establecido. Esto podría integrarse bien en su proceso de gestión de servicios de TI, con la acción apropiada completada por el propietario de datos, el administrador de datos o el DBA designado para ese metastore.

Consulte la documentación (AWS, Azure) sobre cómo rotar credenciales. En particular:

• Si necesita rotar una credencial inmediatamente, establezca --existing-token-expire-in-seconds en 0, y el token existente caducará inmediatamente.
• Databricks recomienda las siguientes acciones cuando existen preocupaciones de que las credenciales puedan haber sido comprometidas:
  1. Revoque el acceso del destinatario al intercambio.
  2. Rote al destinatario y establezca --existing-token-expire-in-seconds en 0 para que el token existente caduque inmediatamente.
  3. Comparte el nuevo enlace de activación con el destinatario previsto a través de un canal seguro.
  4. Una vez que se haya accedido a la URL de activación, vuelve a conceder al destinatario el acceso a la compartición.

4. Considera el nivel de granularidad adecuado para las comparticiones, destinatarios y particiones

En la versión administrada, cada compartición puede contener una o más tablas y asociarse a uno o más destinatarios, utilizando controles detallados para gestionar quién o cómo se accede a los múltiples conjuntos de datos. Esto nos permite proporcionar un acceso detallado a múltiples conjuntos de datos de una manera que sería mucho más difícil de lograr solo con código abierto. E incluso podemos ir un paso más allá, añadiendo solo una parte de una tabla para compartir proporcionando una especificación de partición (consulta la documentación sobre AWS, Azure).

Vale la pena aprovechar estas funcionalidades implementando tus comparticiones y destinatarios para seguir el principio de mínimo privilegio, de modo que si una credencial de destinatario se ve comprometida, esté asociada al menor número de conjuntos de datos o a la menor subsección de los datos posible.

5. Configura Listas de Acceso por IP

Por defecto, todo lo que se requiere para acceder a tus comparticiones es un archivo de credenciales de Delta Sharing válido, por lo tanto, es fundamental minimizar la posibilidad de que las credenciales se vean comprometidas implementando límites a nivel de red sobre dónde se pueden utilizar.

Configura listas de acceso IP de Delta Sharing (consulta la documentación para AWS, Azure) para restringir el acceso de los destinatarios a direcciones IP de confianza, por ejemplo, la IP pública de tu VPN corporativa.

Combinar las listas de acceso IP con el token de acceso reduce considerablemente los riesgos de acceso no autorizado. Para que alguien acceda a los datos de forma no autorizada, necesita haber adquirido una copia de tu token y estar en la misma red autorizada, lo cual es mucho más difícil que solo adquirir el token.

6. Configura el Registro de Auditoría de Databricks

Los registros de auditoría son tu registro autoritativo de lo que ocurre en tu Databricks Lakehouse Platform, incluyendo todas las actividades relacionadas con Delta Sharing. Como tal, recomendamos encarecidamente que configures los registros de auditoría de Databricks para cada nube (consulta la documentación para AWS, Azure) y configures pipelines automatizados para procesar esos registros y monitorizar/alertar sobre eventos importantes.

Consulta nuestro blog complementario, Monitoring Your Databricks Lakehouse Platform with Audit Logs para una inmersión más profunda en este tema, incluyendo todo el código que necesitas para configurar pipelines de Delta Live Tables, configurar alertas de Databricks SQL y ejecutar consultas SQL para responder preguntas importantes como:

• ¿Cuáles de mis comparticiones de Delta son las más populares?
• ¿Desde qué países se accede a mis comparticiones de Delta?
• ¿Se están creando destinatarios de Delta Sharing sin aplicar restricciones de listas de acceso IP?
• ¿Se están creando destinatarios de Delta Sharing con restricciones de listas de acceso IP que están fuera de mi rango de IP de confianza?
• ¿Están fallando los intentos de acceder a mis comparticiones de Delta debido a las restricciones de listas de acceso IP?
• ¿Están fallando repetidamente los intentos de acceder a mis comparticiones de Delta debido a la autenticación?

7. Configura restricciones de red en la(s) cuenta(s) de almacenamiento

Una vez que el servidor de compartición ha autenticado correctamente una solicitud de compartición de delta, se genera y devuelve al cliente una matriz de credenciales de corta duración. El cliente utiliza entonces estas URL para solicitar los archivos relevantes directamente al proveedor de la nube. Este diseño significa que la transferencia puede ocurrir en paralelo a un ancho de banda masivo, sin transmitir los resultados a través del servidor. También significa que, desde una perspectiva de seguridad, probablemente querrás implementar restricciones de red similares en la cuenta de almacenamiento al destinatario de Delta Sharing, de qué sirve proteger la compartición a nivel de destinatario si los datos en sí están alojados en una cuenta de almacenamiento a la que cualquiera puede acceder desde cualquier lugar.

Azure

En Azure, Databricks recomienda usar Managed Identities (actualmente en Vista Previa Pública) para acceder a la cuenta de almacenamiento subyacente en nombre de Unity Catalog. Los clientes pueden entonces configurar firewalls de almacenamiento para restringir todo el demás acceso a los puntos de conexión privados de confianza, redes virtuales o rangos de IP públicos que los clientes de Delta Sharing pueden usar para acceder a los datos. Ponte en contacto con tu representante de Databricks para obtener más información.

Nota importante: De nuevo, es importante considerar todos los casos de uso potenciales al determinar qué restricciones a nivel de red aplicar. Por ejemplo, además de acceder a los datos a través de Delta Sharing, es probable que uno o más espacios de trabajo de Databricks también necesiten acceso a los datos, y por lo tanto, debes permitir el acceso desde los puntos de conexión privados de confianza, redes virtuales o rangos de IP públicos relevantes utilizados por esos espacios de trabajo.

AWS

En AWS, Databricks recomienda usar políticas de bucket de S3 para restringir el acceso a tus buckets de S3. Por ejemplo, la siguiente declaración Deny podría usarse para restringir el acceso a direcciones IP y VPC de confianza.

Nota importante: Es importante considerar todos los casos de uso potenciales al determinar qué restricciones a nivel de red aplicar. Por ejemplo:

• Cuando se utiliza la versión administrada, las URL pre-firmadas son generadas por Unity Catalog, y por lo tanto, necesitarás permitir el acceso desde la IP NAT del plano de control de Databricks para tu región.
• Es probable que uno o más espacios de trabajo de Databricks también necesiten acceso a los datos, y por lo tanto, debes permitir el acceso desde los IDs de VPC relevantes si el bucket S3 subyacente está en la misma región y estás utilizando puntos de conexión de VPC para conectarte a S3 o a la dirección IP pública a la que el tráfico del plano de datos se resuelve (por ejemplo, a través de una puerta de enlace NAT).
• Para evitar perder conectividad desde tu red corporativa, Databricks recomienda permitir siempre el acceso desde al menos una dirección IP conocida y de confianza, como la IP pública de tu VPN corporativa. Esto se debe a que las condiciones Deny se aplican incluso dentro de la consola de AWS.

Además de las restricciones a nivel de red, también se recomienda restringir el acceso a los buckets de S3 subyacentes al rol de IAM utilizado por Unity Catalog. La razón es que, como hemos visto, Unity Catalog proporciona un acceso detallado a sus datos de una manera que no es posible con los permisos generales que proporciona AWS IAM/S3. Por lo tanto, si alguien pudiera acceder directamente al bucket de S3, podría eludir esos permisos detallados y acceder a más datos de los que tenía previsto.

Nota importante: Como se mencionó anteriormente, las condiciones Deny se aplican incluso dentro de la consola de AWS, por lo que se recomienda permitir también el acceso a un rol de administrador que un pequeño número de usuarios privilegiados pueda utilizar para acceder a la interfaz de usuario/API de AWS.

8. Configurar el registro en las cuentas de almacenamiento

Además de aplicar restricciones a nivel de red en las cuentas de almacenamiento subyacentes, es probable que desee supervisar si alguien intenta eludirlas. Como tal, Databricks recomienda:

• Configurar el registro de acceso de servidores S3 en AWS, así como la supervisión y las alertas adecuadas en torno a él.
• Configurar el registro de diagnóstico en Azure, así como la supervisión y las alertas adecuadas en torno a él.

Conclusión

El lakehouse ha resuelto la mayoría de los problemas de gestión de datos que llevaron a tener arquitecturas de datos y patrones de acceso fragmentados, y ha limitado severamente el tiempo de obtención de valor que una organización podía esperar de sus datos. Ahora que los equipos de datos se han liberado de estos problemas, el intercambio de datos abierto pero seguro se ha convertido en la próxima frontera.

Delta Sharing es el primer protocolo abierto del mundo para compartir datos de forma segura interna y externamente en tiempo real, independientemente de la plataforma en la que residan los datos. Y al utilizar Delta Sharing en combinación con las mejores prácticas descritas anteriormente, las organizaciones pueden intercambiar datos de forma fácil pero segura con sus usuarios, socios y clientes a escala empresarial.

Los mercados de datos existentes no han logrado maximizar el valor empresarial para los proveedores y consumidores de datos, pero con Databricks Marketplace puede aprovechar la Plataforma Databricks Lakehouse para llegar a más clientes, reducir costos y ofrecer más valor en todos sus productos de datos.

Si está interesado en convertirse en un Socio Proveedor de Datos, ¡nos encantaría saber de usted!

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original