Usar Microsoft SQL Server de forma segura con Power Apps
Hay diferentes formas de conectar y autenticarse en SQL Server con Power Apps. Este artículo describe conceptos que pueden ser útiles para elegir cómo conectarse a SQL Server con un enfoque de seguridad que se ajuste a los requisitos de su aplicación.
Importante
La característica conexiones implícitas seguras se lanzó en enero de 2024. Microsoft recomienda encarecidamente que todas las aplicaciones que actualmente utilizan conexiones implícitas se conviertan en conexiones implícitas seguras y revoquen las conexiones compartidas con los usuarios finales.
Diferencia entre conexiones explícitas, implícitas e implícitas seguras
Se crea una conexión a SQL Server cada vez que crea una aplicación mediante Power Apps conectándose a SQL Server. Cuando dichas aplicaciones se publican y comparten con otros, tanto la aplicación como la conexión se implementan para esos usuarios. En otras palabras, la aplicación y la conexión, ambas son visibles para los usuarios con los que se comparte la aplicación.
El método de autenticación usado para tales 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 explícitamente compartida significa que el usuario final de la aplicación debe autenticarse en SQL Server con sus propias credenciales explícitas. Por lo general, esta autenticación tiene lugar en segundo plano como parte de Microsoft Entra o el protocolo de enlace de autenticación de Windows. El usuario ni siquiera se da cuenta de cuándo se realiza 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 origen de datos durante la creación de la aplicación. Las credenciales del usuario final no se usan para autenticar. Cada vez que el usuario final ejecuta la aplicación, utiliza las credenciales con las que el autor creó la aplicación.
- Una conexión segura compartida implícitamente se refiere 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 aplicaciones usó para conectarse y autenticarse en origen de datos en la creación de la aplicación. Esto significa que las credenciales del usuario final no se utilizan para la autenticación. En su lugar, cuando el usuario final ejecuta la aplicación, utiliza las credenciales con las que el autor creó la aplicación. Es importante tener en cuenta que el usuario final no tiene acceso directo a la conexión y la aplicación solo permite el acceso a un conjunto limitado de acciones y tablas.
Los siguientes cuatro tipos de autenticación de conexión se pueden utilizar con SQL Server para Power Apps:
| Tipo de autenticación | Método de conexión de Power Apps |
|---|---|
| Microsoft Entra integrada | Explícito |
| Autenticación de SQL Server | Implícita / Implícita segura |
| Autenticación de Windows | Implícita / Implícita segura |
| Autenticación de Windows (no compartida) | Explícito |
Riesgos implícitos de compartir conexiones
Todas las aplicaciones nuevas utilizan automáticamente las nuevas conexiones implícitas seguras. Sin embargo, con las aplicaciones que usan las "conexión implícitas" antiguas, 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 utiliza 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 usuario final reutilice una conexión para crear una nueva aplicación. En cambio, la aplicación funciona con una conexión proxy que conoce la aplicación y solo se comunica con esa aplicación específica. La conexión proxy permite acciones limitadas (crear, leer, actualizar, eliminar) y acceder a tablas específicas en la aplicación que se definen cuando se publica la aplicación. Por lo tanto, solo se otorgan al usuario final acciones y acceso autorizados.
La conexión implícita simple de estilo antiguo en realidad distribuye un objeto de conexión al usuario final. Por ejemplo, si ha creado una aplicación que filtraba los datos que no quiere que vean los usuarios. Pero los datos filtrados están presentes en la base de datos. Pero está contando con el filtro que ha configurado para asegurarse que los usuarios finales no vean algunos datos.
Una vez más, con conexiones implícitas de estilo antiguo, después de implementar la aplicación, los usuarios finales pueden usar la conexión implementada con su aplicación en cualquier aplicación nueva que creen. En las nuevas aplicaciones, los usuarios pueden ver los datos filtrados fuera de su aplicación. Es importante utilizar las nuevas conexiones implícitas seguras.
Importante
Una vez que se implementa una conexión compartida implícitamente antigua para los usuarios finales, las restricciones que puede haber implantado en la aplicación compartida (como filtros o acceso de solo lectura) dejan de ser válidas para las nuevas aplicaciones que crean los usuarios finales. Los usuarios finales tendrán todos los derechos que permita la autenticación como parte de una conexión compartida implícitamente. Por lo tanto, cuando convierte una aplicación para usar conexiones implícitas seguras, debe también revocar las conexiones que compartió con su aplicación. Los administradores pueden obtener un informe de aplicaciones con conexiones compartidas implícitamente con el kit de herramientas COE.
Seguridad de servidor y cliente
No puede confiar en la seguridad de los datos a través del filtrado u otras operaciones del lado del cliente para estar seguro. Las aplicaciones que requieren un filtrado seguro de datos deben garantizar que tanto la identificación del usuario como el filtrado se realicen en el servidor.
Utilice servicios como id. de Microsoft Entra en lugar de depender de los filtros diseñados dentro de las aplicaciones en lo que respecta a la seguridad e identidad del usuario. Esta configuración garantiza que los filtros del lado del servidor funcionen según lo previsto.
Las siguientes ilustraciones explican cómo los patrones de seguridad dentro de las aplicaciones difieren entre los modelos de seguridad del lado del cliente y del lado del servidor.
En un patrón de aplicación de seguridad de cliente, [1] el usuario solo se autentica para la aplicación en el lado del cliente. Luego [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 del servidor, [1] el usuario primero se autentica en el servicio para que el servicio lo conozca. Luego, [2] cuando se realiza una llamada desde la aplicación, el servicio [3] utiliza la identidad conocida del usuario actual para filtrar los datos de forma adecuada y [4] devuelve los datos.
Los escenarios implícitos de intercambio departamental descritos anteriormente son una combinación de estos dos patrones. El usuario debe iniciar sesión en el servicio Power Apps mediante las credenciales de Microsoft Entra. Este comportamiento es el patrón de la aplicación de seguridad del servidor. Al usuario se le conoce mediante la identidad de Microsoft Entra en el servicio. Por lo tanto, la aplicación está restringida al conjunto de usuarios con 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 la aplicación de seguridad del cliente. SQL Server solo sabe que se utiliza un nombre de usuario y una contraseña específicos. Cualquier filtrado del lado del cliente, por ejemplo, se puede omitir con una nueva aplicación usando el mismo nombre de usuario y contraseña.
Para filtrar de forma segura los datos en el lado del servidor, utilice las características de seguridad integradas en SQL Server, como la seguridad a nivel de fila para filas, y los permisos de denegar para objetos específicos (como columnas) para usuarios específicos. Este enfoque utilizará la identidad de usuario de Microsoft Entra para filtrar los datos en el servidor.
Algunos servicios corporativos existentes han utilizado un enfoque en el que la identidad del usuario se captura en una capa de datos profesionales de la misma manera que lo hace Microsoft Dataverse. En este caso, la capa empresarial puede utilizar o no la seguridad del nivel de fila de SQL Server y denegar características directamente. Si no es así, a menudo se da el caso de que la seguridad se habilita mediante vistas o procedimientos almacenados.
La capa empresarial (en el lado del servidor) utiliza un identidad de Microsoft Entra de usuario conocida para invocar un procedimiento almacenado como entidad de seguridad de SQL Server y filtrar los datos. Sin embargo, Power Apps actualmente no se conecta a los procedimientos almacenados. Una capa empresarial también puede invocar una vista que utiliza la identidad de Microsoft Entra como entidad de seguridad de SQL Server. En este caso, utilice Power Apps para conectarse a las vistas para que los datos se filtren en el lado del servidor. La exposición únicamente de las vistas a los usuarios puede requerir flujos de Power Automate para actualizaciones.