Compartir a través de

Roles de la aplicación

  • Artículo

Se aplica a: SQL Server Azure SQL Database Azure SQL Managed Instance

Un rol de aplicación es una entidad de seguridad de base de datos que permite que una aplicación se ejecute con sus propios permisos de usuario. Puede utilizar los roles de aplicación para permitir el acceso a datos específicos únicamente a aquellos usuarios que se conecten a través de una aplicación concreta. A diferencia de los roles de base de datos, los roles de aplicación no contienen miembros y están inactivos de manera predeterminada. Los roles de aplicación se habilitan empleando sp_setapprole, que requiere una contraseña. Debido a que los roles de aplicación son una entidad de seguridad de la base de datos, solo pueden obtener acceso a otras bases de datos por medio de los permisos que se conceden para dichas bases de datos a guest. Por lo tanto, cualquier base de datos en la que el invitado se haya deshabilitado no es accesible para los roles de aplicación de otras bases de datos.

En SQL Server, los roles de aplicación no pueden acceder a los metadatos de nivel de servidor porque no están asociados a una entidad de seguridad de nivel de servidor. Para deshabilitar esta restricción y, por tanto, permitir que los roles de aplicación accedan a los metadatos de nivel de servidor, establezca la marca de seguimiento global 4616 mediante -T4616 o DBCC TRACEON (4616, -1). Si prefiere no habilitar esta marca de seguimiento, puede usar un procedimiento almacenado firmado por certificado para permitir que los roles de aplicación vean el estado del servidor. Para obtener códigos de ejemplo, consulte este script de ejemplo en GitHub.

Conexión con un rol de aplicación

Los siguientes pasos muestran el proceso mediante el cual un rol de aplicación cambia de contexto de seguridad:

  1. Un usuario ejecuta una aplicación cliente.

  2. La aplicación cliente se conecta con una instancia de SQL Server como usuario.

  3. A continuación, la aplicación ejecuta el procedimiento almacenado sp_setapprole con una contraseña conocida solo por la aplicación.

  4. Si el nombre y la contraseña del rol de aplicación son válidos, el rol de aplicación se habilita.

  5. En este momento, la conexión pierde los permisos del usuario y asume los permisos del rol de aplicación.

Los permisos adquiridos durante el rol de aplicación se mantienen mientras dura la conexión.

En versiones anteriores de SQL Server, la única forma de que un usuario vuelva a adquirir su contexto de seguridad original después de iniciar un rol de aplicación consiste en desconectarse y volver a conectarse a SQL Server. A partir de SQL Server 2005 (9.x), sp_setapprole tiene una opción que crea una cookie. La cookie contiene información sobre el contexto anterior al momento en que se habilita el rol de aplicación. A continuación, el procedimiento almacenado sp_unsetapprole usa la cookie para revertir la sesión a su contexto original. Para obtener información sobre esta nueva opción y un ejemplo, consultesp_setapprole (Transact-SQL) y sp_unsetapprole (Transaction-SQL).

Importante

SqlClient no admite la opción encryptde ODBC. Cuando transmita información confidencial a través de una red, utilice Seguridad de la capa de transporte (TLS), conocida anteriormente como Capa de sockets seguros (SSL), o IPSec para cifrar el canal. Si necesita conservar las credenciales de la aplicación cliente, cífrelas mediante las funciones de la API de criptografía. En SQL Server 2005 (9.x) y versiones posteriores, el parámetro password se almacena como un hash unidireccional.

Tarea Tipo
Crear un rol de aplicación. Creación de un rol de aplicación y CREATE APPLICATION ROLE (Transact-SQL)
Modificar un rol de aplicación. ALTER APPLICATION ROLE (Transact-SQL)
Eliminar un rol de aplicación. DROP APPLICATION ROLE (Transact-SQL)
Usar un rol de aplicación. sp_setapprole (Transact-SQL)

Consulte también

Proteger SQL Server