Crear funciones de aplicación en SQL Server (ADO.NET)

Artículo
10/07/2008

Actualización: November 2007

Las funciones de aplicación proporcionan un método para asignar permisos a una aplicación sin necesidad de utilizar una función o un usuario de base de datos. Los usuarios se pueden conectar a la base de datos, activar la función de aplicación y asumir los permisos concedidos a la aplicación. Los permisos concedidos a la función de aplicación se mantienen mientras dura la conexión.

Nota de seguridad:
Las funciones de aplicación se activan cuando una aplicación cliente proporciona un nombre de función de aplicación y una contraseña en la cadena de conexión. Presentan una vulnerabilidad de seguridad en las aplicaciones de dos niveles, ya que la contraseña se debe almacenar en el equipo cliente. En una aplicación de tres niveles, puede almacenar la contraseña de forma que los usuarios de la aplicación no tengan acceso a ella.

Las funciones de aplicación se activan cuando una aplicación cliente proporciona un nombre de función de aplicación y una contraseña en la cadena de conexión. Presentan una vulnerabilidad de seguridad en las aplicaciones de dos niveles, ya que la contraseña se debe almacenar en el equipo cliente. En una aplicación de tres niveles, puede almacenar la contraseña de forma que los usuarios de la aplicación no tengan acceso a ella.

Características de las funciones de aplicación

Las funciones de aplicación tienen las siguientes características:

A diferencia de las funciones de base de datos, las funciones de aplicación no contienen miembros.
Las funciones de aplicación se activan cuando una aplicación proporciona el nombre de función de aplicación y una contraseña en el procedimiento almacenado del sistema sp_setapprole.
La contraseña se debe almacenar en el equipo cliente e indicar en tiempo de ejecución; las funciones de aplicación no se pueden activar desde SQL Server.
La contraseña no se cifra. A partir de SQL Server 2005, el parámetro password se almacena como un valor hash unidireccional.
Una vez activados, los permisos adquiridos durante la función de aplicación se mantienen mientras dura la conexión.
En SQL Server 2000, no puede devolver el contexto de ejecución al autor original de la llamada. Por tanto, para usar las funciones de aplicación debe desactivar la agrupación de conexiones. Para obtener más información, vea Agrupación de conexiones en SQL Server (ADO.NET).
Las funciones de aplicación heredan los permisos concedidos a la función public.
Si un miembro de la función fija de servidor sysadmin activa una función de aplicación, el contexto de seguridad cambia al correspondiente a la función de aplicación mientras dura la conexión.
Si crea una cuenta guest en una base de datos que incluye una función de aplicación, no necesita crear una cuenta de usuario de base de datos para la función de aplicación ni para los inicios de sesión que la invoquen. Las funciones de aplicación sólo pueden obtener acceso directamente a otra base de datos si existe una cuenta guest en la segunda base de datos.
Las funciones integradas que devuelven nombres de inicio de sesión, como SYSTEM_USER, devuelven el nombre del inicio de sesión que invocó la función de aplicación. Las funciones integradas que devuelven nombres de usuario de base de datos devuelven el nombre de la función de aplicación.

Principio de los privilegios mínimos

Las funciones de aplicación sólo deben recibir los permisos necesarios si la contraseña se ve comprometida. Se deben revocar los permisos a la función public en las bases de datos que usen funciones de aplicación. Deshabilite la cuenta guest en cualquier base de datos a la que no desea que tengan acceso los autores de llamadas a la función de aplicación.

Mejoras de las funciones de aplicación

A partir del lanzamiento de SQL Server 2005, el contexto de ejecución se puede devolver al autor original de la llamada tras activar una función de aplicación, lo que evita la necesidad de deshabilitar la agrupación de conexiones. El procedimiento sp_setapprole incluye una nueva opción que crea una cookie, que contiene información de contexto acerca del autor de la llamada. Puede revertir la sesión mediante una llamada al procedimiento sp_unsetapprole, al que le pasa la cookie.

Alternativas a las funciones de aplicación

Las funciones de aplicación dependen de la seguridad de una contraseña, lo que supone una posible vulnerabilidad de seguridad. Las contraseñas se pueden exponer mediante su incrustación en código de aplicación o su almacenamiento en disco.

En SQL Server 2005 y versiones posteriores, puede tener en cuenta las siguientes alternativas.

Usar el cambio de contexto con la instrucción EXECUTE AS y sus cláusulas NO REVERT y WITH COOKIE. Puede crear una cuenta de usuario en una base de datos que no esté asignada a un inicio de sesión. Posteriormente asignará permisos a esta cuenta. El uso de EXECUTE AS con un usuario sin inicio de sesión resulta más seguro, ya que se basa en los permisos y no en una contraseña. Para obtener más información, vea Personalizar permisos con suplantación en SQL Server (ADO.NET).
Firmar procedimientos almacenados con certificados y conceder únicamente permiso para ejecutar los procedimientos. Para obtener más información, vea Firmar procedimientos almacenados en SQL Server (ADO.NET).

Recursos externos

Para obtener más información, vea los siguientes recursos.

Recurso	Descripción
Funciones de aplicación en los Libros en pantalla de SQL Server 2008	Describe cómo crear y usar funciones de aplicación en SQL Server 2008.
Funciones de aplicación, en los Libros en pantalla de SQL Server 2005	Describe cómo crear y usar funciones de aplicación en SQL Server 2005.
Establishing Application Security and Application Roles, en los Libros en pantalla de SQL Server 2000	Describe cómo crear y usar funciones de aplicación en SQL Server 2000.