Autenticación para el análisis a escala de la nube en Azure
La autenticación es el proceso que consiste en comprobar la identidad del usuario o de la aplicación. Es preferible un único proveedor de identidades de origen que controle la administración y la autenticación de las identidades. Este proveedor se conoce como servicio de directorio. Proporciona los métodos necesarios para almacenar datos de directorio y ponerlos a disposición de los usuarios y los administradores de la red.
Toda solución de lago de datos debe utilizar el servicio de directorio que ya esté en uso e integrarse en este. En la mayoría de las organizaciones, Active Directory es el servicio de directorio para todos los servicios relacionados con la identidad. Es la base de datos principal y centralizada para todas las cuentas de servicio y de usuario.
En la nube, Microsoft Entra ID es un proveedor de identidades centralizado y el origen preferido para la administración de identidades. Al delegar la autenticación y la autorización en Microsoft Entra ID, se abren otros escenarios, como el uso de directivas de acceso condicional que requieren que un usuario esté en una ubicación específica. Admite la autenticación multifactor para aumentar el nivel de seguridad de acceso. Configure servicios de Data Lake Store con la integración de Microsoft Entra ID siempre que sea posible.
Para los servicios de datos que no admiten Microsoft Entra ID, use el token o la clave de acceso para la autenticación. El cliente debe almacenar la clave de acceso en un almacén de administración de claves, como Azure Key Vault.
Los escenarios de autenticación para el análisis a escala de la nube son:
- Autenticación de usuarios
- Autenticación de la aplicación y entre servicios
Autenticación de usuarios
Los usuarios que se conectan a un recurso o servicio de datos deben presentar una credencial. Esta credencial demuestra que los usuarios son quienes dicen ser. A continuación, pueden acceder al servicio o recurso. La autenticación también permite que el servicio conozca la identidad de los usuarios. Una vez comprobada la identidad de un usuario, el servicio decide lo que este puede ver y hacer.
Azure Data Lake Storage Gen2, Azure SQL Database y Azure Synapse admiten la integración de Microsoft Entra. El modo de autenticación interactiva de los usuarios requiere que estos proporcionen credenciales en un cuadro de diálogo.
Importante
No codifique las credenciales de usuario en una aplicación para realizar la autenticación.
Autenticación de la aplicación y entre servicios
Estas solicitudes no están asociadas a ningún usuario concreto o no hay ningún usuario disponible para especificar las credenciales.
Autenticación entre servicios
Aunque un servicio acceda a otro sin interacción humana, el servicio debe presentar una identidad válida. Esta identidad demuestra que el servicio es real. El servicio al que se accede puede usar la identidad para decidir qué puede hacer el otro servicio.
El método preferido de autenticación entre servicios de Azure son las identidades administradas. Las identidades administradas para los recursos de Azure permiten la autenticación en cualquier servicio que admita la autenticación de Microsoft Entra sin credenciales explícitas. Para obtener más información, consulte ¿Qué son las identidades administradas de recursos de Azure?
Las identidades administradas son entidades de servicio que solo pueden usarse con recursos de Azure. Por ejemplo, se puede crear una identidad administrada directamente para una instancia de Azure Data Factory. Esta identidad administrada es un objeto registrado en Microsoft Entra ID. Representa esta instancia de Data Factory. Esta identidad se puede usar para autenticarse en cualquier servicio, como Data Lake Storage, sin ninguna credencial en el código. Azure se encarga de las credenciales que usa la instancia del servicio. La identidad puede conceder autorización a los recursos del servicio de Azure, por ejemplo, una carpeta en la instancia de Azure Data Lake Storage. Al eliminar esta instancia de Data Factory, Azure limpia la identidad en Microsoft Entra ID.
Ventajas del uso de las identidades administradas
Las identidades administradas deben utilizarse para autenticar un servicio de Azure en otro servicio o recurso de Azure. Ofrecen las siguientes ventajas:
- Una identidad administrada representa al servicio para el que se crea. No representa a un usuario interactivo.
- Las credenciales de identidad administrada se mantienen, administran y almacenan en Microsoft Entra ID. El usuario no debe conservar ninguna contraseña.
- Con las identidades administradas, los servicios cliente no usan contraseñas.
- La identidad administrada asignada por el sistema se elimina cuando se borra la instancia del servicio.
Estas ventajas implican que la credencial esté mejor protegida y que los problemas de seguridad sean menos probables.
Autenticación de aplicación a servicio
Otro escenario de acceso es una aplicación (por ejemplo, una aplicación web móvil) que accede a un servicio de Azure. Para todo acceso a un servicio de Azure deberá proporcionarse la identidad correspondiente y esa identidad debe comprobarse.
Una entidad de servicio de Azure es la alternativa para que las aplicaciones y los servicios que no admiten las identidades administradas se autentiquen en los recursos de Azure. Una entidad de servicio de Azure es una identidad creada para su uso con aplicaciones, servicios hospedados y herramientas automatizadas que acceden a los recursos de Azure. El acceso está restringido por los roles asignados a la entidad de servicio. Por motivos de seguridad, se recomienda usar entidades de servicio con aplicaciones o herramientas automatizadas, en lugar de permitirles iniciar sesión con una identidad de usuario. Para más información, consulte Objetos de aplicación y de entidad de servicio en Microsoft Entra ID.
Nota:
Tanto las identidades administradas como las entidades de servicio se crean y se mantienen únicamente en Microsoft Entra ID.
Diferencia entre la identidad administrada y la entidad de servicio
| Entidad de servicio | Identidad administrada |
|---|---|
| Identidad de seguridad creada manualmente en Microsoft Entra ID para que las aplicaciones, los servicios y las herramientas la usen para acceder a recursos específicos de Azure. | Tipo especial de entidad de servicio. Es una identidad automática que se genera al crear un servicio de Azure. |
| La puede usar cualquier aplicación o servicio. No está vinculada a ningún servicio de Azure específico. | Representa una instancia de un servicio de Azure. No se puede usar para representar otros servicios de Azure. |
| Tiene un ciclo de vida independiente. Debe eliminarla de forma explícita. | Se elimina automáticamente al eliminar la instancia de servicio de Azure. |
| Autenticación basada en contraseña o en certificados. | No debe proporcionarse ninguna contraseña explícita para la autenticación. |
Autenticación y permisos de la base de datos
Es probable que el almacenamiento a escala de la nube contenga almacenamiento políglota. Entre los ejemplos se incluyen PostgreSQL, MySQL, Azure SQL Database, SQL Managed Instance y Azure Synapse Analytics.
- Uso de Microsoft Entra ID para la autenticación con PostgreSQL
- Uso de la autenticación de Microsoft Entra con Azure SQL Database, SQL Managed Instance y Azure Synapse Analytics
- Uso de Microsoft Entra ID para la autenticación con MySQL
Se recomienda usar grupos de Microsoft Entra para proteger los objetos de base de datos, en lugar de cuentas de usuarios de Microsoft Entra individuales. Use estos grupos de Microsoft Entra para autenticar a los usuarios y proteger los objetos de base de datos. Puede usar la incorporación de aplicaciones de datos para crear estos grupos, de manera similar al patrón de lago de datos.
Nota:
Las aplicaciones de datos pueden almacenar productos de datos confidenciales en grupos de Azure SQL Database, SQL Managed Instance o Azure Synapse Analytics. Para obtener más información, consulte la sección sobre datos confidenciales.
Seguridad de Azure Data Lake en los análisis a escala en la nube
Para controlar el acceso a los datos en Data Lake, se recomienda usar una lista de control de acceso (ACL) en el nivel de archivos y carpetas. Azure Data Lake también adopta un modelo de lista de control de acceso de tipo POSIX. POSIX (interfaz de sistema operativo portátil) es una familia de estándares para sistemas operativos. Un estándar define una estructura de permisos sencilla pero eficaz para acceder a archivos y carpetas. POSIX se ha adoptado ampliamente en los recursos compartidos de archivos de red y en los equipos Unix.
De forma similar a los procedimientos generales de Azure RBAC, las reglas siguientes deben aplicarse a la ACL:
Administración del acceso mediante grupos Asigne acceso a los grupos de Microsoft Entra y administre la pertenencia de los grupos para la administración del acceso continuo. Consulte Control de acceso y configuraciones de lago de datos en Azure Data Lake Storage.
Privilegios mínimos. En la mayoría de los casos, los usuarios solo deben tener permiso de lectura en las carpetas y los archivos que necesiten del lago de datos. Una identidad administrada o una entidad de servicio, como la que usa Azure Data Factory, tiene permisos de lectura, de escritura y de ejecución. Los usuarios de los datos no deben tener acceso al contenedor de la cuenta de almacenamiento.
Alinear con el esquema de partición de datos. El diseño de listas de control de acceso y de particiones de datos deben alinearse para garantizar un control de acceso a los datos eficaz. Para obtener más información, consulte [Creación de particiones de un lago de datos].
Pasos siguientes
Administración de datos y control de acceso basado en roles para el análisis a escala de la nube en Azure (Data management and role-based access control for cloud-scale analytics in Azure)