Compartir a través de


Recomendaciones para Azure Databricks con Microsoft Cloud for Sovereignty

Azure Databricks creó una herramienta de análisis de seguridad que supervisa el estado de su panel de control de acuerdo con las mejores prácticas de Databricks.

Las recomendaciones de este artículo ayudan a crear un entorno bien diseñado que se alinee con estas mejores prácticas. Microsoft Cloud for Sovereignty

Precaución

La mayoría de las recomendaciones solo funcionarán cuando implementes un espacio de trabajo de Azure Databricks en tu propia red virtual (VNet) . Es importante que incorpore esto en su arquitectura; de lo contrario, será necesario migrar los espacios de trabajo si luego decide integrarlos a su propia red virtual.

Redes

Azure Databricks ofrece varias opciones para mantener los datos dentro de redes privadas en lugar de atravesar direcciones IP o puntos finales públicos.

Si le preocupa que ubicaciones no autorizadas intenten acceder a Azure Databricks, puede controlar este acceso implementando el acceso condicional de ID con el uso de listas de acceso de IP. Microsoft Entra

Si tiene un entorno altamente seguro y desea tener la opción de restringir el acceso a la red saliente desde Azure Databricks, debe restringir los puntos de conexión privados de confianza, las redes y las identidades administradas del almacenamiento de Azure Data Lake. También puede usar Azure Private Link cuando las regulaciones o políticas requieren que todo el acceso a los datos atraviese únicamente direcciones IP privadas.

Conectividad de red segura

Azure Databricks le permite configurar características de conectividad de red entre las diferentes conexiones de red que se muestran en el siguiente diagrama:

Diagrama general de conectividad de red.

  1. Usuarios y aplicaciones en Azure Databricks: puede configurar funciones para controlar el acceso y proporcionar conectividad privada entre los usuarios y sus espacios de trabajo de Azure Databricks. Ver Usuarios en redes de Azure Databricks

  2. Plano de control y plano de cómputo clásico: los recursos de cómputo clásicos, como los clústeres, se implementan en su suscripción de Azure y se conectan al plano de control. Puede utilizar las funciones de conectividad de red clásica para implementar recursos del plano de cómputo clásico en sus propias redes virtuales y para habilitar la conectividad privada desde los clústeres al plano de control. Consulte Redes clásicas del plano de cómputo.

  3. Plano de cómputo y almacenamiento sin servidor: puede configurar conexiones privadas y dedicadas desde el cómputo sin servidor hasta el almacenamiento. Consulte Redes de plano de cómputo sin servicio.

Puede configurar funciones de red de almacenamiento de Azure, como puntos de conexión privados, para proteger la conexión entre Azure Databricks y el almacenamiento de Azure.

Para obtener más información, consulte Redes.

Conectividad de clúster segura de computación clásica

Azure Databricks tiene una característica en el plano computacional clásico llamada conectividad de clúster segura, también conocida como Sin IP pública (NPIP). Esta función garantiza que sus redes virtuales no tengan puertos abiertos y que los recursos computacionales no tengan direcciones IP públicas, lo que mejora la seguridad y simplifica la administración de la red.

Para obtener más información, consulte Conectividad segura del clúster.

Implementar Azure Databricks en su red virtual de Azure (inyección de VNet)

La implementación de Azure Databricks en su red virtual de Azure (inyección de VNet) le permite implementar un espacio de trabajo de Azure Databricks dentro de su propia red virtual de Azure (VNet). Esta configuración ofrece varios beneficios, incluida una mayor seguridad y personalización de la red.

Al usar la inyección de VNet, puede conectar Azure Databricks a otros servicios de Azure (como Azure Storage) de una manera más segura mediante puntos de conexión de servicio o puntos de conexión privados de Azure. También le permite conectarse a fuentes de datos locales mediante rutas definidas por el usuario e inspeccionar todo el tráfico saliente a través de un dispositivo virtual de red, aplicando las reglas de permitir y denegar según sea necesario.

La implementación predeterminada de Azure Databricks es un servicio completamente administrado en Azure, donde una red virtual de Azure se implementa en un grupo de recursos bloqueado. Sin embargo, con la inyección de VNet, puede implementar recursos del plano de cómputo clásico de Azure Databricks en su propia red virtual, lo que permite configuraciones de red más seguras y personalizadas.

Nota

Los rangos de IP para redes virtuales y subredes en Azure Databricks determinan la cantidad máxima de nodos de clúster que puede ejecutar simultáneamente. Seleccione estos valores para adaptarlos a las necesidades de su red y al máximo de nodos previsto. Para obtener más información, consulte Espacio de direcciones y número máximo de nodos del clúster.

Conectividad privada para computación sin servidor

Los recursos informáticos sin servidor se ejecutan en el plano informático sin servidor administrado por Azure Databricks. Los administradores de cuentas pueden configurar la conectividad segura entre el plano informático sin servidor y sus recursos, como se muestra en el siguiente diagrama.

La imagen muestra un enlace privado de computación sin servidor.

La conectividad entre el plano de control y el plano de computación sin servidor siempre se realiza a través de la red troncal en la nube y no de Internet pública. Todo el tráfico entre el usuario, el plano de control, el plano de cómputo y los servicios en la nube está cifrado con al menos TLS 1.2.

La conectividad privada de red sin servidor se administra con configuraciones de conectividad de red (NCC). Los NCC son construcciones regionales a nivel de cuenta que se utilizan para administrar la creación de puntos finales privados y la habilitación de firewall a escala.

Para obtener más información, consulte Redes de plano computacional sin servidor.

Segmentación de red sin servidor

Para la computación sin servidor, cada carga de trabajo opera dentro de una red privada sin direcciones IP públicas asignadas. La red está aislada lógicamente de otras cargas de trabajo y se bloquea el movimiento lateral o la comunicación entre cargas de trabajo.

Para obtener más información, consulte Implemente sus cargas de trabajo de forma segura en computación sin servidor.

Compatibilidad de firewall con cuentas de almacenamiento

Azure Databricks crea una cuenta de almacenamiento en un grupo de recursos administrados, que se denomina cuenta de espacio de trabajo. La cuenta de almacenamiento del espacio de trabajo contiene datos del sistema del espacio de trabajo (salida del trabajo, configuraciones del sistema y registros), raíz DBFS y, a veces, un catálogo de espacio de trabajo del Catálogo de Unity.

De forma predeterminada, cualquier red puede realizar conexiones autenticadas a la cuenta de almacenamiento de Azure para su cuenta de almacenamiento del área de trabajo. Puede restringir este acceso habilitando la compatibilidad del firewall para su cuenta de almacenamiento del espacio de trabajo. Esto bloquea el acceso a la red pública y evita que la cuenta de almacenamiento del espacio de trabajo tenga acceso a la red no autorizado.

Hay algunos requisitos previos que son necesarios para habilitar esta función y es necesario tener una subred separada para los puntos finales privados de la cuenta de almacenamiento. Estos requisitos previos se suman a las dos subredes principales para la funcionalidad básica de Azure Databricks cuando se usa la inyección de red virtual.

Para obtener más información, consulte Habilitar la compatibilidad con firewall para su cuenta de almacenamiento del espacio de trabajo.

Recomendaciones para la creación de redes en el entorno Microsoft Cloud for Sovereignty

Las siguientes son recomendaciones para la creación de redes en la arquitectura de referencia: Microsoft Cloud for Sovereignty

Almacenamiento y gestión de datos

La gobernanza de datos y la ubicación de los datos son factores importantes al diseñar una solución bien gobernada. Azure Databricks tiene una solución llamada Unity Catalog, que proporciona control de acceso centralizado, auditoría, linaje y capacidades de descubrimiento de datos en todos los espacios de trabajo de Azure Databricks.

Microsoft Purview se integra con Unity Catalog para ayudarlo a descubrir datos de Lakehouse y llevar sus metadatos a Data Map. Para obtener más información, consulte Conectarse y administrar el catálogo de Unity de Azure Databricks.

Para quienes trabajan en el sector público y gubernamental, recomendamos seguir las prácticas recomendadas estándar de Azure Databricks para Unity Catalog. Para obtener más información, consulte Prácticas recomendadas del Catálogo de Unity.

Acceso del operador

Azure Databricks es un servicio que se ejecuta en Azure con Microsoft y Databricks. Sus espacios de trabajo y entornos de producción no son accesibles para el personal de Databricks de forma predeterminada. El personal de Databricks puede solicitar acceso temporal a su espacio de trabajo para solucionar una interrupción o un problema de seguridad o para ayudar con la implementación.

La tecnología de Azure Databricks aplica los siguientes controles:

  • Solo personal limitado puede solicitar acceso a producción para resolver un ticket de soporte de ingeniería o un problema informado por el cliente.

  • Los límites de tiempo se establecen de antemano para la duración prevista de la sesión de soporte.

  • Puede configurar los registros de diagnóstico del espacio de trabajo para revisar el acceso del personal de Azure Databricks a los recursos de su espacio de trabajo. Los registros se entregan normalmente en menos de 15 minutos.

  • El personal de Azure Databricks no puede acceder a sus espacios de trabajo ni a los entornos de producción multiinquilino sin su consentimiento. Cuando genera una solicitud de soporte, puede otorgar al personal de Azure Databricks acceso temporal a sus espacios de trabajo para investigar una interrupción o un evento de seguridad, o para respaldar su implementación.

Para obtener más información, consulte la documentación del Centro de confianza de Databricks sobre acceso interno y el Portal de confianza de servicios de Microsoft. ...... Para obtener el informe más reciente, puede buscar "Databricks SOC" y anotar los controles de acceso lógicos y físicos implementados que se enumeran en la sección III.

Debes dar una aprobación explícita al abrir un ticket de soporte y puedes usar el acceso condicional de ID para controlar el acceso a tus espacios de trabajo de Azure Databricks. Microsoft Entra

Recomendaciones para el acceso del operador en el entorno Microsoft Cloud for Sovereignty

Las siguientes son recomendaciones para el acceso del operador en la arquitectura de referencia: Microsoft Cloud for Sovereignty

  • Debe aceptar la postura de seguridad que desea adoptar con respecto a permitir que el personal de Azure Databricks acceda a su espacio de trabajo para una sesión de soporte temporal.

    • La habilitación o deshabilitación del acceso se controla mediante el acceso al espacio de trabajo para el personal de Azure Databricks. Para obtener más información, consulte Acceso al espacio de trabajo para el personal de Azure Databricks.

    • Al conceder acceso, colabore con su responsable de seguridad para determinar la duración del acceso temporal a la sesión en el espacio de trabajo.

  • Debe configurar los registros de diagnóstico del espacio de trabajo según lo recomendado en la sección Auditoría de este documento.

Audit

Es posible que desee obtener información sobre las actividades realizadas por los usuarios de Azure Databricks para detectar anomalías y revisar el acceso del personal a Azure Databricks. Los registros de diagnóstico están disponibles como una característica del Plan Premium de Azure Databricks.

Si procesa datos regulados, Azure Databricks puede proporcionar seguridad mejorada y controles para las necesidades de cumplimiento de datos.

La supervisión de seguridad mejorada de Azure Databricks proporciona una imagen de disco reforzada mejorada y agentes de supervisión de seguridad adicionales que generan filas de registro que puede revisar mediante registros de diagnóstico. Las mejoras de seguridad se aplican únicamente a los recursos computacionales en el plano computacional clásico, como clústeres y almacenes de SQL clásicos.

Si usa Unity Catalog, también puede obtener un registro de auditoría de las acciones de metastore. Estos registros permiten a los administradores rastrear a los usuarios y las acciones de un conjunto de datos. Para obtener más información, consulte Auditar eventos del Catálogo de Unity

Recomendaciones para la auditoría en el entorno Microsoft Cloud for Sovereignty

Las siguientes son recomendaciones para la auditoría en la arquitectura de referencia: Microsoft Cloud for Sovereignty

Seguridad

La identidad, la autenticación y la gestión de secretos son una ruta fundamental en la configuración de Azure Databricks. Puede integrar Azure Databricks con usuarios y grupos de ID. Microsoft Entra Le recomendamos que configure la autenticación multifactor de ID para verificar al usuario. Microsoft Entra

También puede definir cómo utilizar la configuración de exfiltración de datos dentro de la consola de administración y proteger sus datos.

Identidad

Hay tres tipos de identidad de Azure Databricks:

  • Usuarios: Identidades de usuario reconocidas por Azure Databricks y representadas por direcciones de correo electrónico.

  • Entidades de servicio: Identidades para usar con trabajos, herramientas automatizadas y sistemas como scripts, aplicaciones y plataformas CI/CD.

  • Grupos: una colección de identidades utilizadas por los administradores para gestionar el acceso de grupos a espacios de trabajo, datos y otros objetos protegibles. Todas las identidades de Databricks se pueden asignar como miembros de grupos. Hay dos tipos de grupos en Azure Databricks: grupos de cuentas y grupos locales del espacio de trabajo. Para obtener más información, consulte Diferencia entre grupos de cuentas y grupos locales del espacio de trabajo.

Puede configurar el aprovisionamiento en Azure Databricks mediante ID en el nivel de cuenta de Azure Databricks o en el nivel de área de trabajo de Azure Databricks configurando un conector SCIM entre ID y Azure Databricks. Microsoft Entra Microsoft Entra SCIM (Sistema para la gestión de identidad entre dominios) es un estándar abierto que permite automatizar el aprovisionamiento de usuarios. Para obtener más información, consulte Sincronizar usuarios y grupos desde Microsoft Entra ID

Databricks recomienda aprovisionar usuarios, entidades de servicio y grupos en el nivel de cuenta y administrar la asignación de usuarios y grupos a espacios de trabajo dentro de Azure Databricks. Los espacios de trabajo deben estar habilitados para la federación de identidades, a fin de administrar la asignación de usuarios a los espacios de trabajo.

Si su cuenta se creó después del 9 de noviembre de 2023, la federación de identidades está habilitada en todos los espacios de trabajo nuevos de forma predeterminada y no se puede deshabilitar. Para las cuentas anteriores a esta fecha, un administrador de cuenta debe habilitar el espacio de trabajo para Unity Catalog asignando un metastore de Unity Catalog. Para obtener más información, consulte Habilitar un espacio de trabajo para Unity Catalog , Administrar usuarios, entidades de servicio y grupos y Prácticas recomendadas de identidad.

Es posible que tenga requisitos comerciales para rotar el token SCIM a nivel de cuenta. Para obtener más información, consulte Rotar el token SCIM de nivel de cuenta.

Acceso condicional

Azure Databricks admite el acceso condicional de ID, que permite a los administradores controlar dónde y cuándo los usuarios pueden iniciar sesión en Azure Databricks. Microsoft Entra Las políticas de acceso condicional pueden restringir el inicio de sesión en su red corporativa o pueden requerir autenticación multifactor (MFA).

Es importante tener en cuenta que el acceso condicional de ID se aplica en el punto de autenticación con ID. Microsoft Entra Microsoft Entra No se aplica a los usuarios que ya están autenticados con ID y luego cambian de red, o que utilizan métodos alternativos de autenticación, como tokens de acceso personal. Microsoft Entra Por lo tanto, para lograr controles de acceso a la red integrales, Databricks recomienda combinar el acceso condicional de ID con el uso de listas de acceso de IP o Azure Private Link. Microsoft Entra

Gestión de tokens

Los tokens de acceso personal se utilizan para autenticarse en la API y las herramientas de Azure Databricks. Puede establecer un tiempo de vida útil máximo para los nuevos tokens de acceso personal en su espacio de trabajo. También puede restringir el uso de tokens de acceso personal y, en su lugar, utilizar tokens de identificación y de corta duración para la autenticación. OAuth Microsoft Entra

Identidades administradas

Azure Databricks fomenta el uso de Unity Catalog para conectarse al almacenamiento a través de identidades administradas.

Los beneficios de utilizar identidades administradas son:

  • Las identidades administradas administran automáticamente las identidades, eliminando la necesidad de credenciales en el código y mejorando la seguridad. Microsoft Entra

  • No necesita administrar credenciales, ya que ni siquiera usted puede acceder a ellas.

  • Puede utilizar identidades administradas para autenticar cualquier recurso que admita la autenticación de ID. Microsoft Entra

  • Puede utilizar identidades administradas sin coste adicional.

Para obtener más información, consulte Conectarse al almacenamiento de objetos en la nube mediante Unity Catalog.

Configuración de exfiltración de datos dentro de la consola de administración del espacio de trabajo

Si sus cargas de trabajo contienen datos confidenciales, es fundamental configurar los ajustes de exfiltración de datos dentro del área de trabajo de Azure Databricks. Durante la instalación, considere deshabilitar las siguientes funciones para mejorar la seguridad:

  • Exportar cuadernos o celdas que contienen código y resultados parciales de consultas interactivas

  • Descargar los resultados del cuaderno

  • Funciones del portapapeles del bloc de notas en bloque

  • Descargar artefactos de ejecución de MLflow

  • Bloquear ataques a aplicaciones mediante iFrames y secuencias de comandos entre sitios

Aislar cargas de trabajo sensibles

Azure Databricks ofrece muchas características para separar diferentes cargas de trabajo, pero para algunas cargas de trabajo extremadamente sensibles, la forma óptima de aislarlas podría ser transferirlas a un espacio de trabajo separado. Este aislamiento puede ser necesario cuando hay equipos distintos (por ejemplo, un equipo de seguridad y un equipo de marketing) que necesitan analizar datos diferentes en Databricks.

Sin embargo, la necesidad de aislar los datos puede generar entornos aislados que pueden dificultar tanto la gobernanza de los datos como la colaboración. Azure Databricks resuelve este problema mediante Unity Catalog, que proporciona muchas opciones de aislamiento de datos y al mismo tiempo mantiene una plataforma de gobernanza de datos unificada.

Para obtener más información, consulte las mejores prácticas del Catálogo de Unity. ...

Separación de funciones

Uno de los principios de seguridad comunes es que un administrador debe evitar utilizar sus cuentas privilegiadas para realizar tareas habituales. Este principio también se aplica a Azure Databricks. Si tiene administradores de Databricks que también son usuarios normales de la plataforma Databricks (por ejemplo, un ingeniero de datos que administra la plataforma y realiza trabajos de ingeniería de datos), debe crear una cuenta de usuario diferente para las tareas administrativas.

Una cosa a tener en cuenta es que los usuarios que tienen el rol de colaborador de Azure RBAC o permisos superiores en el grupo de recursos donde está implementado un espacio de trabajo de Azure Databricks se convierten automáticamente en administradores del espacio de trabajo cuando inician sesión en ese espacio de trabajo. Por lo tanto, los mismos factores analizados anteriormente también deberían aplicarse a los usuarios del portal de Azure.

Recomendaciones para la seguridad en el entorno Microsoft Cloud for Sovereignty

Las siguientes son recomendaciones para la seguridad en la arquitectura de referencia: Microsoft Cloud for Sovereignty

  • Integre Azure Databricks, a nivel de cuenta en lugar de a nivel de espacio de trabajo, con la integración de ID. Microsoft Entra Luego asignarías esas identidades a espacios de trabajo específicos. Con esta integración, si un empleado abandona la organización, puedes deshabilitar su ID, lo que a su vez deshabilitaría su acceso a los espacios de trabajo de Azure Databricks. Microsoft Entra

  • Para ayudar a proteger aún más el acceso, considere implementar la autenticación multifactor y el acceso condicional con listas de acceso IP. Estos pasos pueden proporcionar niveles adicionales de seguridad para validar primero a los usuarios y luego aplicar las reglas de acceso condicional para verificar que estén accediendo al espacio de trabajo desde una ubicación de red autorizada.

  • Siempre que sea posible, debe autenticarse mediante tokens de identificación en lugar de usar PAT de Azure Databricks. Microsoft Entra Microsoft Entra Se recomiendan los tokens de identificación para la automatización del espacio de trabajo y la infraestructura, en particular cuando el token de identificación se genera en nombre de una entidad de servicio. Microsoft Entra Para obtener más información, consulte Autenticación para la automatización de Azure Databricks: descripción general.

  • Implemente Unity Catalog y conéctese a Azure Storage a través de identidades administradas.

  • Para los usuarios que también necesitan administrar el espacio de trabajo y usarlo para ingeniería de datos, crea cuentas separadas para tareas administrativas.

  • Utilice entidades de servicio para cargas de trabajo de producción en lugar de vincularlas a cuentas individuales. Hacerlo puede evitar el impacto que se produce cuando un usuario abandona una organización.

Residencia de datos

Azure Databricks consta de servicios alojados en suscripciones de Azure Databricks y su suscripción. Puede obtener información sobre la ubicación de cada servicio y verificar que los servicios estén ubicados dentro de sus centros de datos de Azure designados, en lugar de estar ubicados afuera.

Datos de identidad

Para ofrecer funciones de administración de cuentas y acceso, Azure Databricks conserva los siguientes datos de identidad: nombre de usuario, nombre, apellido y dirección de correo electrónico. Estos datos se almacenan en Estados Unidos para respaldar la plataforma global Azure Databricks y están cifrados en reposo.

Para obtener más información, consulte Servicios que transfieren un subconjunto de Datos del cliente o datos personales seudonimizados fuera del límite de datos de la UE de forma continua.

La cuenta de Azure Databricks es un servicio a nivel de inquilino, pero permite la creación de un catálogo de unidad por región. Para obtener más información, consulte ¿Qué es Unity Catalog? ...

Redundancia del sistema de archivos Databricks (DBFS)

Cuando se crea un espacio de trabajo, la redundancia predeterminada para la cuenta de almacenamiento administrada (raíz DBFS) se establece como almacenamiento con redundancia geográfica (GRS). Puede cambiar la configuración de redundancia de la cuenta de almacenamiento del área de trabajo (DBFS) de Azure Databricks.

Si tiene requisitos de política que no le permiten replicar estos datos en el par regional de Azure relacionado, puede cambiar esta configuración para ayudar a cumplir con las políticas locales. Para obtener más información, consulte Cambiar las opciones de redundancia de almacenamiento del espacio de trabajo.

Recomendaciones para la residencia de datos en el entorno Microsoft Cloud for Sovereignty

Las siguientes son recomendaciones para la seguridad en la arquitectura de referencia: Microsoft Cloud for Sovereignty

  • Evalúe si la redundancia de DBFS se alinea con sus políticas locales y cambie la redundancia para ayudar a cumplir con sus políticas de residencia de datos.

Cifrado

Azure Databricks utiliza varias capas de cifrado para garantizar la seguridad de los datos. De forma predeterminada, Azure Storage cifra automáticamente todos los datos de una cuenta de almacenamiento, incluido el almacenamiento raíz del sistema de archivos Databricks (DBFS). Este cifrado se aplica a nivel de servicio.

Es posible que desee agregar sus propias claves para mejorar la seguridad de sus datos para los datos almacenados en el plano de control, los datos almacenados en la cuenta de almacenamiento raíz utilizada para DBFS y los datos almacenados en los discos administrados para los clústeres en el plano de cómputo clásico. Los administradores desean almacenar esta clave en Azure Key Vault Premium o Azure Key Vault mHSM.

Dentro del Centro de seguridad y confianza de Databricks, se enumeran varios beneficios de usar claves administradas por el cliente para proteger los datos, como se indica a continuación:

  • Más control sobre tus datos

  • Mayor tranquilidad si hay un compromiso

  • Implemente sus propias políticas de rotación

  • Monitorizar el acceso

Para obtener más información, consulte Protección de datos con claves administradas por el cliente y Cómo mejorar la protección de datos en Azure Databricks.

Cifrado del plano de control

Los datos de servicios administrados en el plano de control de Azure Databricks están cifrados en reposo. Puede agregar una clave administrada por el cliente para servicios administrados para ayudar a proteger y controlar el acceso a los siguientes tipos de datos cifrados:

  • Archivos fuente del cuaderno que se almacenan en el plano de control.

  • Resultados de cuadernos para cuadernos que están almacenados en el plano de control.

  • Secretos almacenados por las API del administrador de secretos.

  • Consultas SQL de Databricks e historial de consultas.

  • Tokens de acceso personal u otras credenciales utilizadas para configurar la integración de Git con las carpetas Git de Databricks.

Para obtener más información, consulte Claves administradas por el cliente para servicios administrados.

Cifrado del plano de cómputo clásico

En Classic Compute Plane, las consultas y transformaciones del usuario normalmente se envían a los clústeres de Databricks a través de un canal cifrado. Sin embargo, de forma predeterminada, los datos intercambiados entre los nodos de trabajo de un clúster no están cifrados.

Las cargas de trabajo de procesamiento de Azure Databricks en el plano de procesamiento almacenan datos temporales en discos administrados de Azure. De forma predeterminada, los datos almacenados en discos administrados se cifran en reposo mediante cifrado del lado del servidor con claves administradas por Microsoft. Puede configurar su propia clave para su espacio de trabajo de Azure Databricks para usarla en el cifrado de disco administrado. Esta función se aplica a los discos de datos y no a los discos del sistema operativo.

Para un espacio de trabajo que ya tiene una clave administrada por el cliente para discos administrados, puede rotar la clave sin finalizar los recursos informáticos.

Para obtener más información, consulte Claves administradas por el cliente para discos administrados de Azure.

Cifrar consultas

Si configura el cifrado para los servicios administrados, de manera predeterminada, se cifran los datos en reposo para las consultas y el historial de consultas. Para obtener más información, consulte Cifrar consultas, historial de consultas y resultados de consultas.

Cifrar el tráfico entre los nodos de trabajo del clúster

Si su caso de uso requiere cifrado de datos en tránsito y en reposo, puede usar un script init para habilitar el cifrado AES de 256 bits a través de una conexión TLS 1.3 entre los nodos de trabajo del clúster. Para obtener más información, consulte Cifrar el tráfico entre nodos de trabajo del clúster.

Importante

Este cifrado solo se aplica al plano computacional clásico y puede degradar el rendimiento, lo que afecta las grandes transacciones.

Plano de cómputo sin servidor

Las claves administradas por el cliente para el almacenamiento en disco administrado no se aplican a los recursos informáticos sin servidor. Los discos para recursos informáticos sin servidor tienen una vida útil corta y están vinculados al ciclo de vida de la carga de trabajo sin servidor. Cuando se detienen o se reducen los recursos computacionales, las máquinas virtuales y su almacenamiento se destruyen.

Todo el almacenamiento conectado está protegido mediante el cifrado AES-256 estándar de la industria. Para obtener más información, consulte Implemente sus cargas de trabajo de forma segura en computación sin servidor.

Raíz del sistema de archivos Databricks (DBFS)

Azure Databricks admite tener una clave administrada por el cliente para la cuenta de almacenamiento raíz utilizada para DBFS. Al mismo tiempo, puedes habilitar el doble cifrado. Actualmente no se admite el cifrado del almacenamiento de tablas y colas, ya que no se recomienda almacenar datos en el DBFS.

En entornos regulados, es importante educar a los usuarios para que eviten usar esta ubicación para almacenar datos confidenciales y, en cambio, se concentren en usar Unity Catalog, que tiene una arquitectura diferente para administrar tablas administradas. Para obtener más información, consulte Recomendaciones para trabajar con la raíz DBFS.

Recomendaciones para el cifrado en Microsoft Cloud for Sovereignty ambiente

Las siguientes son recomendaciones para el cifrado en Microsoft Cloud for Sovereignty arquitectura de referencia:

  • Almacene claves administradas por el cliente en Azure Key Vault. En nuestra arquitectura de referencia, nos concentramos en utilizar un Azure Key Vault o un HSM de Azure Key Vault ubicado dentro de la suscripción de Data Landing Zone. En nuestra experiencia, Azure Key Vault HSM requiere un modelo operativo diferente y puede desviarse de la recomendación de tener un Azure Key Vault por aplicación. Para obtener más información, consulte Modelos de operaciones para la administración de claves y consulte Cómo elegir entre Azure Key Vault, Azure Managed HSM, Azure Dedicated HSM y Azure Payment HSM.

  • Después de la evaluación de riesgos, si su entorno requiere que los datos estén siempre cifrados, ya sea en reposo o en tránsito, configure sus clústeres para cifrar el tráfico entre los nodos de trabajo. Este paso afecta el rendimiento.

  • Habilite las siguientes funciones de cifrado:

    • Agregar una clave administrada por el cliente para servicios administrados (plano de control)

    • Agregar una clave administrada por el cliente para la raíz de DBFS

    • Agregar una clave administrada por el cliente para discos administrados (computación clásica)

  • Eduque a los usuarios para que eviten usar DBFS para almacenar datos confidenciales y utilicen Unity Catalog para administrar tablas administradas.

Consideraciones adicionales sobre el plano de cómputo clásico

La sección de arquitectura de alto nivel de Databricks cubrió cómo se ejecuta la solución en Azure. Para el plano de cómputo clásico, hay otras consideraciones en nuestra arquitectura de referencia, para implementaciones de la industria del gobierno y del sector público.

Políticas de clúster

Las políticas de clúster le ayudan a administrar varios elementos de los clústeres que activa, como la selección de tipos de instancias, versiones de Databricks y las dimensiones de las instancias. Estas políticas le permiten mantener la coherencia en todo su entorno informático en Azure Databricks.

Puede configurar varias políticas de clúster, lo que permitirá que ciertos grupos de usuarios creen clústeres pequeños, que algunos grupos de usuarios creen clústeres grandes y que otros grupos solo utilicen clústeres existentes.

Para obtener más información, consulte Crear y administrar políticas de cómputo.

Aislamiento del usuario

Anteriormente, Databricks ofrecía clústeres "Sin aislamiento compartido" (conocidos como "modo estándar" o "clústeres estándar") de forma predeterminada, principalmente para equipos de ingeniería pequeños que compartían los mismos conjuntos de datos. Sin embargo, como Azure Databricks ahora tiene más funciones de aislamiento de usuarios que se adaptan a sus requisitos de seguridad, sugerimos utilizar clústeres que habiliten el aislamiento de usuarios cuando sea posible.

Los siguientes tipos de clústeres refuerzan el aislamiento de usuarios para que los usuarios con diferentes niveles de privilegios puedan coexistir en el mismo clúster:

  • Almacenes de SQL

  • Cualquier clúster que no tenga el modo de acceso configurado en "Sin aislamiento compartido".

Los clústeres con aislamiento de usuarios incluyen una aplicación tal que cada usuario se ejecuta como una cuenta de usuario sin privilegios diferente en el host del clúster. Solo se permiten lenguajes que se puedan implementar de manera aislada (SQL y Python), y las API de Spark deben estar en una lista de permitidos de aquellos que consideramos que son seguros para el aislamiento.

Los almacenes de SQL también refuerzan el aislamiento de usuarios y tienen características de seguridad similares, aunque implementadas en un mecanismo específico para las cargas de trabajo de SQL que se ejecutan en estos clústeres.

Si tiene requisitos de seguridad estrictos, puede aplicar políticas de clúster que no permitan la creación de clústeres estándar dentro del entorno.

Si tiene Unity Catalog en sus espacios de trabajo, puede permitir que los usuarios creen clústeres de usuario único si se requieren clústeres estándar. Sin Unity Catalog, los administradores del espacio de trabajo pueden establecer clústeres y administrar el acceso a los notebooks a través de las ACL del clúster.

Actualizaciones del sistema

Los clústeres de Azure Databricks son efímeros. Azure Databricks no actualiza los sistemas mientras están en ejecución: cuando se reinicia un clúster y hay imágenes o contenedores del sistema más nuevos, el sistema usa automáticamente las imágenes y los contenedores más recientes disponibles.

Puedes establecer un tiempo de vida para los clústeres antes de que se apaguen. Cuando un usuario se conecta, los clústeres se reinician y utilizan imágenes del sistema más nuevas, si las hay.

Informática confidencial de Azure

Azure Databricks Classic Compute puede utilizar Azure Confidential Computing para proporcionar un entorno seguro para procesar datos confidenciales. Al ejecutar cargas de trabajo de Azure Databricks en máquinas virtuales (VM) confidenciales de Azure, puede garantizar una mayor confidencialidad y privacidad al cifrar los datos en uso. Estas máquinas virtuales cuentan con procesadores AMD EPYC con tecnología AMD SEV-SNP, que ofrece cifrado de memoria para proteger los datos durante el cálculo.™ Estas funciones deben usarse con otros productos de seguridad, cumplimiento y mejora de la privacidad de Databricks, como Unity Catalog, Delta Sharing y Enhanced Security and Compliance.

Los casos de uso típicos que requieren informática de confidencialidad incluyen la prevención del lavado de dinero, la prevención del fraude y la detección de eventos adversos de medicamentos. .........

Recomendaciones para el plano de cómputo clásico en el entorno Microsoft Cloud for Sovereignty

Las siguientes son recomendaciones para el plano de cómputo clásico en la arquitectura de referencia: Microsoft Cloud for Sovereignty

  • Estandarizar las políticas de clúster para mantener versiones mínimas de Databricks en el entorno de producción.

  • Comprenda y defina su política con respecto al aislamiento de usuarios para cargas de trabajo. Utilice clústeres que permitan el aislamiento de usuarios cuando sea posible.

  • Establezca un tiempo de vida para cada clúster que cree para garantizar que los clústeres se reinicien periódicamente.

Continuidad del negocio y recuperación ante desastres

Recuperación ante desastres

Si bien Databricks no ofrece servicios de recuperación ante desastres, puede utilizar las capacidades de Databricks, incluida la API de cuenta, para crear un espacio de trabajo frío (en espera) en otra región.

Para obtener más información, consulte Recuperación ante desastres.

Recomendaciones para la Continuidad del Negocio en Microsoft Cloud for Sovereignty ambiente

Las siguientes son recomendaciones para la Continuidad del Negocio en Microsoft Cloud for Sovereignty arquitectura de referencia:

  • Documente y configure su recuperación ante desastres alineada con las políticas regionales y de residencia de datos. Por ejemplo, verifique si puede replicar datos fuera de su región o si deben permanecer dentro de un área geográfica específica.