Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Hay diferentes maneras de conectarse y autenticarse en SQL Server con Power Apps. En este artículo se describen los conceptos que pueden resultar útiles para elegir cómo conectarse a SQL Server con un enfoque de seguridad que coincida con los requisitos de la aplicación.
Importante
La característica de conexiones implícitas seguras se publicó en enero de 2024. Microsoft recomienda encarecidamente que todas las aplicaciones usen conexiones implícitas actualmente para convertirlas en conexiones implícitas seguras y revocar conexiones compartidas con los usuarios finales.
Diferencia entre conexiones implícitas, implícitas y seguras explícitas
Se crea una conexión a SQL Server cada vez que se crea una aplicación mediante Power Apps que se conecta a SQL Server. Cuando estas aplicaciones se publican y comparten con otras personas, tanto la aplicación como la conexión se implementan en esos usuarios. En otras palabras, la aplicación y la conexión son visibles para los usuarios con los que se comparten las aplicaciones.
El método de autenticación usado para estas conexiones puede ser explícito o implícito. También podemos decir que dicha conexión se comparte explícita o implícitamente.
- Una conexión compartida explícita significa que el usuario final de la aplicación debe autenticarse en SQL Server con sus propias credenciales explícitas. Normalmente, esta autenticación se produce en segundo plano como parte del protocolo de enlace de autenticación de Microsoft Entra o Windows. El usuario ni siquiera observa cuándo tiene lugar la autenticación.
- Una conexión compartida implícitamente significa que el usuario usa implícitamente las credenciales de la cuenta que el creador de aplicaciones usó para conectarse y autenticarse en el origen de datos durante la creación de la aplicación. Las credenciales del usuario final no se usan para autenticarse. Cada vez que el usuario final ejecuta la aplicación, usa las credenciales con las que creó la aplicación.
- Una conexión compartida implícitamente segura hace referencia a un escenario en el que el usuario final de la aplicación usa implícitamente las credenciales de la cuenta que el creador de la aplicación usó para conectarse y autenticarse en el origen de datos al crear la aplicación. Esto significa que las propias credenciales del usuario final no se usan para autenticarse. En su lugar, cuando el usuario ejecuta la aplicación, usa las credenciales con las que el autor de la aplicación lo creó. Es importante tener en cuenta que el usuario final no se proporciona acceso directo a la conexión, y la aplicación solo permite el acceso a un conjunto limitado de acciones y tablas.
Los cuatro tipos de autenticación de conexión siguientes se pueden usar con SQL Server para Power Apps:
| Tipo de autenticación | Método de conexión de Power Apps |
|---|---|
| Microsoft Entra integrada | Explicit |
| Autenticación de SQL Server | Implícito o implícito seguro |
| Autenticación de Windows | Implícito o implícito seguro |
| Autenticación de Windows (no compartida) | Explicit |
Riesgos implícitos de uso compartido de conexiones
Todas las nuevas aplicaciones usan automáticamente las nuevas conexiones implícitas seguras. Sin embargo, con las aplicaciones que usan las "conexiones implícitas" anteriores, tanto la aplicación como sus conexiones se implementan para los usuarios finales, significa que los usuarios finales pueden crear nuevas aplicaciones basadas en esas conexiones.
Cuando un autor usa conexiones implícitas seguras, significa que no se comparte ninguna conexión y ningún usuario final recibe el objeto de conexión. Esto elimina el riesgo de que un autor final vuelva a usar una conexión para crear una aplicación. En su lugar, la aplicación funciona con una conexión de proxy que es consciente de la aplicación y solo se comunica con esa aplicación específica. La conexión de proxy permite acciones limitadas (crear, leer, actualizar, eliminar) y acceder a tablas específicas de la aplicación que se definen cuando se publica la aplicación. Por lo tanto, solo se conceden acciones autorizadas y acceso al usuario final.
La conexión implícita simple de estilo anterior distribuye realmente un objeto de conexión al usuario final. Por ejemplo, si crea una aplicación que filtra los datos que no quiere que vean los usuarios. Pero los datos filtrados están presentes en la base de datos. Pero se basa en el filtro que configuró para asegurarse de que los usuarios finales no verán determinados datos.
De nuevo, con conexiones implícitas simples de estilo anterior, después de implementar la aplicación, los usuarios finales pueden usar la conexión implementada con la aplicación en las nuevas aplicaciones que creen. En las nuevas aplicaciones, los usuarios pueden ver los datos que ha filtrado en la aplicación. Es importante usar las nuevas conexiones implícitas seguras.
Importante
Una vez que se implementa una conexión compartida implícitamente anterior a los usuarios finales, las restricciones que puede haber puesto en la aplicación compartida (como filtros o acceso de solo lectura) ya no son válidas para las nuevas aplicaciones que los usuarios finales crean. Los usuarios finales tendrán los derechos que permita la autenticación como parte de la conexión compartida implícitamente. Por lo tanto, al convertir una aplicación para que use conexiones implícitas seguras, también debe revocar las conexiones que ha compartido con la aplicación. Los administradores pueden obtener un informe de aplicaciones con conexiones compartidas implícitamente con el kit de herramientas de COE.
Seguridad de cliente y servidor
No puede confiar en la seguridad de los datos mediante el filtrado u otras operaciones del lado cliente para ser seguras. Las aplicaciones que requieren un filtrado seguro de datos deben asegurarse de que tanto la identificación del usuario como el filtrado se produzcan en el servidor.
Use servicios como Microsoft Entra ID en lugar de confiar en los filtros diseñados dentro de las aplicaciones cuando se trata de la identidad y la seguridad del usuario. Esta configuración garantiza que los filtros del lado servidor funcionen según lo previsto.
En las ilustraciones siguientes se explica cómo los patrones de seguridad de las aplicaciones difieren entre los modelos de seguridad del lado cliente y del lado servidor.
En un patrón de aplicación de seguridad de cliente, [1] el usuario solo se autentica en la aplicación en el lado cliente. A continuación, [2] la aplicación solicita información del servicio y [3] el servicio devuelve la información únicamente en función de la solicitud de datos.
En un patrón de seguridad del lado servidor, [1] el usuario primero se autentica en el servicio para que el usuario sea conocido por el servicio. A continuación, [2] cuando se realiza una llamada desde la aplicación, el servicio [3] usa la identidad conocida del usuario actual para filtrar los datos correctamente y [4] devuelve los datos.
Los escenarios implícitos de uso compartido de departamento descritos anteriormente son una combinación de estos dos patrones. El usuario debe iniciar sesión en el servicio Power Apps con las credenciales de Microsoft Entra. Este comportamiento es el patrón de aplicación de seguridad del servidor. El usuario se conoce mediante la identidad de Microsoft Entra en el servicio. Por lo tanto, la aplicación está restringida al conjunto de usuarios a los que Power Apps ha compartido formalmente la aplicación.
Sin embargo, la conexión compartida implícita a SQL Server es el patrón de aplicación de seguridad de cliente. SQL Server solo sabe que se usa un nombre de usuario y una contraseña específicos. Por ejemplo, cualquier filtrado del lado cliente se puede omitir con una nueva aplicación con el mismo nombre de usuario y contraseña.
Para filtrar de forma segura los datos en el lado servidor, use características de seguridad integradas en SQL Server, como la seguridad de nivel de fila para las filas, y los permisos de denegación de objetos específicos (como columnas) para usuarios específicos. Este enfoque usa la identidad de usuario de Microsoft Entra para filtrar los datos en el servidor.
Algunos servicios corporativos existentes han usado un enfoque en el que la identidad del usuario se captura en una capa de datos empresariales de la misma manera que Microsoft Dataverse hace. En este caso, el nivel de negocio puede o no usar la seguridad de nivel de fila y denegar características de SQL Server directamente. Si no es así, suele ser el caso de que la seguridad esté habilitada mediante procedimientos almacenados o vistas.
El nivel de negocio (en el lado servidor) usa una identidad conocida de Microsoft Entra de usuario para invocar un procedimiento almacenado como entidad de seguridad de SQL Server y filtrar los datos. Sin embargo, Power Apps no se conecta actualmente a procedimientos almacenados. Una capa de negocio también puede invocar una vista que use la identidad de Microsoft Entra como entidad de seguridad de SQL Server. En este caso, use Power Apps para conectarse a las vistas para que los datos se filtren en el servidor. Exponer solo las vistas a los usuarios puede necesitar flujos de Power Automate para las actualizaciones.