Configurar la autenticación

Completado

La autenticación es el proceso de validación de las credenciales que se lleva a cabo cuando se accede a los recursos de una infraestructura digital. Esto garantiza que se pueda validar la identidad de un individuo o un servicio que quiera acceder a un servicio del entorno. Azure Synapse Analytics proporciona varios métodos de autenticación.

¿Qué se debe autenticar?

Hay diversos escenarios en los que se debe realizar la autenticación para proteger los datos que se almacenan en su instancia de Azure Synapse Analytics.

La forma habitual de autenticación es la de los usuarios que quieren acceder a los datos del servicio. Normalmente, individuos que proporcionan un nombre de usuario y una contraseña para autenticarse en un servicio. Sin embargo, este método se está volviendo más sofisticado, con solicitudes de autenticación que funcionan en combinación con directivas de acceso condicional, con el fin de proteger aún más el proceso de autenticación con pasos de seguridad adicionales.

Lo que resulta menos obvio es el hecho de que los servicios deben autenticarse con otros para que puedan funcionar sin problemas. Un ejemplo de ello es el uso de un grupo de SQL sin servidor o uno de Spark en Azure Synapse para acceder a los datos de un almacén de Azure Data Lake Store. Un mecanismo de autenticación debe llevarse a cabo en segundo plano para garantizar que Azure Synapse Analytics pueda acceder a los datos del lago de datos de una manera autenticada.

Por último, hay situaciones en las que usuarios y servicios operan juntos al mismo tiempo. Aquí tiene una combinación de autenticación de usuarios y servicios que se realiza en segundo plano para garantizar que el usuario obtenga acceso a los datos sin problemas. Un ejemplo de esto es el uso de Power BI para ver informes en un panel que se administra mediante un grupo de SQL dedicado. Aquí tiene varios niveles de autenticación que deben administrarse.

Tipos de seguridad

A continuación se indican los tipos de autenticación que se deben tener en cuenta al trabajar con Azure Synapse Analytics.

Microsoft Entra ID

Microsoft Entra ID es un servicio de directorio que permite mantener de forma centralizada los objetos que se pueden proteger. Entre estos objetos se encuentran las cuentas de usuario y de equipos. Normalmente, los empleados de una organización tendrán una cuenta de usuario que les representa en el inquilino de Microsoft Entra de la organización y, a continuación, usarán esa cuenta de usuario con una contraseña para autenticarse en otros recursos almacenados en el directorio mediante un proceso conocido como "inicio de sesión único".

La ventaja que aporta Microsoft Entra ID es que solo tienen que iniciar sesión una vez; Microsoft Entra ID administra el acceso a otros recursos en función de la información contenida en él mediante la autenticación de paso a través. Si un usuario y una instancia de Azure Synapse Analytics forman parte del mismo directorio de Microsoft Entra ID, es posible que el usuario pueda acceder a Azure Synapse Analytics sin necesidad de iniciar sesión. Si se administra correctamente, este proceso es perfecto, ya que, a modo de ejemplo, el administrador habría dado al usuario autorización para acceder al grupo de SQL dedicado de Azure Synapse Analytics.

En esta situación, lo normal es que un administrador de Azure cree las cuentas de usuario y las asigne a los roles y grupos pertinentes en Microsoft Entra ID. A continuación, el ingeniero de datos agregará el usuario, o un grupo al que pertenezca el usuario, para que acceda a un grupo de SQL dedicado.

Identidades administradas

La identidad administrada para los recursos de Azure es una característica de Microsoft Entra ID. La característica proporciona a los servicios de Azure una identidad administrada automáticamente en Microsoft Entra ID. Puede usar la funcionalidad de identidad administrada para autenticarse en cualquier servicio que admita la autenticación de Azure AD.

Identidad administrada para recursos de Azure es el nuevo nombre del servicio conocido anteriormente como Managed Service Identity (MSI). Al crear el área de trabajo, se crea una identidad administrada asignada por el sistema para el área de trabajo de Azure Synapse.

Azure Synapse también usa la identidad administrada para integrar las canalizaciones. El ciclo de vida de la identidad administrada está directamente vinculado al área de trabajo de Azure Synapse. Si elimina el área de trabajo de Azure Synapse, la identidad administrada también se borra.

La identidad administrada del área de trabajo necesita permisos para realizar operaciones en las canalizaciones. Al conceder permisos, puede usar el identificador de objeto o el nombre del área de trabajo de Azure Synapse para buscar la identidad administrada.

Puede recuperar la identidad administrada en Azure Portal. Abra el área de trabajo de Azure Synapse en Azure Portal y seleccione Información general en el panel de navegación izquierdo. El identificador de objeto de la identidad administrada se muestra en la pantalla principal.

Visualización de la información de la identidad administrada en Azure Portal.

También se mostrará la información de identidad administrada cuando cree un servicio vinculado que admita la autenticación de la identidad administrada desde Azure Synapse Studio.

Inicie Azure Synapse Studio y seleccione la pestaña Manage (Administrar) en el panel de navegación izquierdo. Luego, seleccione Linked services (Servicios vinculados) y elija la opción + New (+ Nuevo) para crear un servicio vinculado.

En la ventana New linked service (Nuevo servicio vinculado), escriba Azure Data Lake Storage Gen2. Seleccione el tipo de recurso Azure Data Lake Storage Gen2 en la lista siguiente y elija Continue (Continuar).

En la siguiente ventana, elija Managed Identity (Identidad administrada) en Authentication method (Método de autenticación). Verá los valores de Name (Nombre) y Object ID (Id. de objeto).

Configuración de la información de la identidad administrada en un servicio vinculado.

Autenticación de SQL

En el caso de las cuentas de usuario que no forman parte de Microsoft Entra ID, una alternativa es usar la autenticación de SQL. En esta instancia, se crea un usuario en la instancia de un grupo de SQL dedicado. Si el usuario en cuestión requiere acceso de administrador, los detalles del usuario se mantienen en la base de datos maestra. Si el acceso de administrador no es necesario, puede crear un usuario en una base de datos específica. Después, un usuario se conecta directamente al grupo de SQL dedicado de Azure Synapse Analytics, donde se le pide que use un nombre de usuario y una contraseña para acceder al servicio.

Este enfoque suele ser útil para los usuarios externos que necesitan acceder a los datos, o bien si usa aplicaciones de terceros o heredadas en el grupo de SQL dedicado de Azure Synapse Analytics.

Autenticación multifactor

Synapse SQL admite conexiones procedentes de SQL Server Management Studio (SSMS) mediante la Autenticación universal de Active Directory.

Inicio de sesión con la autenticación multifactor.

De este modo, podrá trabajar en entornos que usen directivas de acceso condicional y que apliquen la autenticación multifactor como parte de la directiva.

Claves

Si no puede usar una identidad administrada para acceder a recursos como Azure Data Lake, puede usar las claves de cuentas de almacenamiento y las firmas de acceso compartido.

Con una clave de cuenta de almacenamiento. Azure crea dos de estas claves (principal y secundaria) para cada cuenta de almacenamiento que se crea. Las claves dan acceso a todo lo que hay en la cuenta. Las claves de cuenta de almacenamiento se encuentran en la vista de la cuenta de almacenamiento de Azure Portal. Simplemente, seleccione Configuración y, a continuación, haga clic en Claves de acceso.

No se recomienda compartir las claves de cuentas de almacenamiento, y puede usar Azure Key Vault para administrar y proteger las claves.

Azure Key Vault es un almacén de secretos: un servicio en la nube centralizado para almacenar secretos de aplicación; valores de configuración como contraseñas y cadenas de conexión que deben estar protegidos en todo momento. Para ayudar a controlar los secretos de aplicación, Key Vault los mantiene en una sola ubicación central y proporciona acceso seguro, control de permisos y registro de acceso.

Las principales ventajas del uso de Key Vault son:

  • Separación de la información confidencial de la aplicación de otra configuración y código, lo que reduce el riesgo de fugas accidentales
  • Acceso restringido a los secretos con directivas de acceso adaptadas a las aplicaciones y los individuos que las necesitan
  • Almacenamiento de secretos centralizado, lo que permite que los cambios necesarios se produzcan en un solo lugar
  • Registro y supervisión del acceso para saber cómo y cuándo se accede a los secretos

Los secretos se almacenan en almacenes individuales, que son recursos de Azure que se usan para agrupar los secretos. La administración de los almacenes y del acceso a los secretos se logra a través de una API REST, que también es compatible con todas las herramientas de administración de Azure y las bibliotecas cliente disponibles para muchos lenguajes populares. Cada almacén tiene una dirección URL única donde se hospeda su API.

Firmas de acceso compartido

Si estas aplicaciones necesitan acceso a los datos, debe proteger sus conexiones sin usar claves de cuentas de almacenamiento. En el caso de los clientes que no son de confianza, use una firma de acceso compartido (SAS). Una firma de acceso compartido es una cadena que contiene un token de seguridad que se puede asociar a un URI. Use una firma de acceso compartido para delegar el acceso a objetos de almacenamiento y especificar restricciones, como los permisos y el intervalo de tiempo de acceso. Puede proporcionar a un cliente el token de la firma de acceso compartido.

Tipos de firmas de acceso compartido

Puede usar una firma de acceso compartido de nivel de servicio para permitir el acceso a recursos específicos de una cuenta de almacenamiento. Este tipo de firma de acceso compartido se usaría, por ejemplo, para permitir que una aplicación recuperara una lista de archivos de un sistema de archivos o para descargar un archivo.

Use una firma de acceso compartido de nivel de cuenta para permitir el acceso a todo lo que puede permitir una firma de acceso compartido de nivel de servicio, además de a otros recursos y capacidades. Por ejemplo, puede usar una firma de acceso compartido de nivel de cuenta para permitir la creación de sistemas de archivos.