Autorización y permisos en SQL Server (ADO.NET)

Artículo
10/07/2008

Actualización: November 2007

Al crear objetos de base de datos, se deben conceder permisos de forma explícita para que los usuarios tengan acceso a ellos. Cada objeto susceptible de protegerse tiene permisos que se pueden otorgar a una entidad de seguridad mediante instrucciones de permiso.

Principio de los privilegios mínimos

Desarrollar una aplicación utilizando un enfoque basado en cuenta de usuario de privilegios mínimos (LUA) constituye una parte importante de una estrategia de defensa exhaustiva contra las amenazas a la seguridad. El enfoque LUA garantiza que los usuarios siguen el principio de los privilegios mínimos y siempre inician sesión con cuentas de usuario limitadas. Las tareas administrativas se realizan utilizando funciones fijas del servidor y el uso de la función fija del servidor sysadmin es muy restringido.

Cuando conceda permisos a usuarios de base de datos, siga siempre el principio de los privilegios mínimos. Otorgue a usuarios y funciones los mínimos permisos necesarios para que puedan realizar una tarea concreta.

Nota de seguridad:
Cuado se desarrolla o prueba una aplicación utilizando el enfoque LUA, se aumenta el grado de dificultad del proceso de desarrollo. Resulta más fácil crear objetos y escribir código cuando se inicia sesión como administrador del sistema o propietario de la base de datos que cuando se utiliza una cuenta LUA. Sin embargo, el desarrollo de aplicaciones con cuentas de privilegios elevados puede entorpecer el impacto de funcionalidades reducidas cuando usuarios con privilegios de nivel bajo intentan ejecutar una aplicación que requiere permisos elevados para funcionar correctamente. Otorgar a los usuarios permisos excesivos para recuperar funcionalidades perdidas puede exponer a la aplicación a posibles ataques. El diseño, desarrollo y prueba de una aplicación en la que se ha iniciado sesión con una cuenta LUA impone un enfoque disciplinado del planeamiento de la seguridad que evita sorpresas desagradables, así como la tentación de recurrir a la solución rápida de otorgar privilegios elevados. Puede utilizar un inicio de sesión de SQL Server para realizar pruebas, incluso aunque la aplicación esté pensada para implementarse con autenticación de Windows.

Cuado se desarrolla o prueba una aplicación utilizando el enfoque LUA, se aumenta el grado de dificultad del proceso de desarrollo. Resulta más fácil crear objetos y escribir código cuando se inicia sesión como administrador del sistema o propietario de la base de datos que cuando se utiliza una cuenta LUA. Sin embargo, el desarrollo de aplicaciones con cuentas de privilegios elevados puede entorpecer el impacto de funcionalidades reducidas cuando usuarios con privilegios de nivel bajo intentan ejecutar una aplicación que requiere permisos elevados para funcionar correctamente. Otorgar a los usuarios permisos excesivos para recuperar funcionalidades perdidas puede exponer a la aplicación a posibles ataques. El diseño, desarrollo y prueba de una aplicación en la que se ha iniciado sesión con una cuenta LUA impone un enfoque disciplinado del planeamiento de la seguridad que evita sorpresas desagradables, así como la tentación de recurrir a la solución rápida de otorgar privilegios elevados. Puede utilizar un inicio de sesión de SQL Server para realizar pruebas, incluso aunque la aplicación esté pensada para implementarse con autenticación de Windows.

Permisos basados en funciones

Otorgar permisos a funciones en lugar de a usuarios simplifica la administración de la seguridad. Los conjuntos de permisos asignados a funciones los heredan todos los miembros de la función. Es más fácil agregar o quitar usuarios de una función que volver a crear conjuntos de permisos distintos para cada usuario. Las funciones se pueden anidar. Sin embargo, la existencia de demasiados niveles de anidamiento puede reducir el rendimiento. También puede agregar usuarios a funciones fijas de bases de datos para simplificar los permisos de asignación.

A partir de SQL Server 2005, se pueden conceder permisos a nivel de esquema. Los usuarios heredan automáticamente los permisos en todos los objetos nuevos creados en el esquema; no es necesario otorgar permisos cuando se crean objetos nuevos.

Permisos a mediante código basado en procedimiento

El encapsulamiento del acceso a los datos a través de módulos tales como procedimientos almacenados y funciones definidas por el usuario brinda un nivel de protección adicional a la aplicación. Se puede evitar que los usuarios interactúen directamente con objetos de la base de datos otorgando permisos sólo a procedimientos almacenados o funciones, y denegando permisos a objetos subyacentes tales como tablas. SQL Server lo consigue mediante encadenamiento de propiedad.

Instrucciones de permiso

En la siguiente tabla se describen las tres instrucciones de permiso de Transact-SQL.

Instrucción de permiso	Descripción
GRANT	Concede un permiso.
REVOKE	Revoca un permiso. Este es el estado predeterminado de un objeto nuevo. Un permiso revocado a un usuario o función se puede heredar de otros grupos o funciones a los que está asignada la entidad de seguridad.
DENY	DENY revoca un permiso de manera que no pueda ser heredado. DENY tiene prioridad sobre todos los permisos, pero no se aplica a propietarios de objeto o miembros de sysadmin. Si deniega permisos a un objeto en la función public, se los deniega igualmente a todos los usuarios y funciones excepto a los propietarios del objeto y a los miembros de sysadmin.

La instrucción GRANT puede asignar permisos a un grupo o función que puede ser heredada por los usuarios de la base de datos. No obstante, la instrucción DENY tiene prioridad sobre el resto de las instrucciones de permiso. Por ello, un usuario al que se le ha denegado un permiso no puede heredarlo de otra función.

Nota:
A los miembros de la función fija del servidor sysadmin y a los propietarios de objetos no se les pueden denegar permisos.

Cadenas de propiedad

SQL Server garantiza que solamente puedan tener acceso a los objetos las entidades de seguridad a las que se les han concedido permisos. Cuando varios objetos de base de datos tienen acceso el uno al otro, la secuencia se conoce como "cadena". Cuando SQL Server atraviesa los vínculos de la cadena, evalúa los permisos de manera diferente a como lo haría si estuviera obteniendo acceso a cada elemento separadamente. Cuando se obtiene acceso a un objeto a través de una cadena, SQL Server primero compara al propietario del objeto con el propietario del objeto de llamada (el vínculo anterior de la cadena). Si ambos objetos tienen el mismo propietario, los permisos del objeto al que se hace referencia no se comprueban. Siempre que un objeto obtiene acceso a otro objeto que tiene un propietario distinto, la cadena de propiedad se rompe y SQL Server debe comprobar el contexto de seguridad del llamador.

Código basado en procedimiento y encadenamiento de propiedad

Suponga que a un usuario se le otorgan permisos para ejecutar en un procedimiento almacenado que selecciona datos desde una tabla. Si el procedimiento almacenado y la tabla tienen el mismo propietario, el usuario no necesita ningún permiso en la tabla y se le pueden incluso denegar permisos. Sin embargo, si el procedimiento almacenado y la tabla tienen distintos propietarios, SQL Server debe comprobar los permisos del usuario en la tabla antes de permitirle el acceso a los datos.

Nota:
El encadenamiento de propiedad no se aplica en el caso de las instrucciones de SQL dinámico. Para llamar a un procedimiento que ejecuta una instrucción SQL, el llamador debe tener permiso de acceso a las tablas subyacentes, lo que deja a su aplicación expuesta a posibles ataques de inyección SQL. SQL Server 2005 incorpora nuevos mecanismos, como representación y módulos de firma con certificados, que no requieren otorgar permisos en las tablas subyacentes. Estos mecanismos se pueden utilizar también con procedimientos almacenados CLR.

El encadenamiento de propiedad no se aplica en el caso de las instrucciones de SQL dinámico. Para llamar a un procedimiento que ejecuta una instrucción SQL, el llamador debe tener permiso de acceso a las tablas subyacentes, lo que deja a su aplicación expuesta a posibles ataques de inyección SQL. SQL Server 2005 incorpora nuevos mecanismos, como representación y módulos de firma con certificados, que no requieren otorgar permisos en las tablas subyacentes. Estos mecanismos se pueden utilizar también con procedimientos almacenados CLR.

Recursos externos

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

Recurso	Descripción
Permissions en los Libros en pantalla de SQL Server 2008	Contiene temas que describen la jerarquía de permisos, las vistas de catálogo y permisos de servidores fijos y funciones de bases de datos.
Permissions y Ownership Chains y en los Libros en pantalla de SQL Server 2005	Temas que describen la jerarquía de permisos, las vistas de catálogo y los permisos de servidores fijos y funciones de bases de datos.
Managing Permissions y Using Ownership Chains en los Libros en pantalla de SQL Server 2000	Temas que describen la concesión y administración de permisos.