Gestión de la seguridad del acceso

Introducción

El control de acceso representa una operación importante en la gestión de la seguridad sobre un servidor de bases de datos. La seguridad de los datos requiere una organización de los objetos de manera independiente de los usuarios, y esto es posible gracias a los esquemas. La seguridad pasa también por un mejor control de las autorizaciones y la posibilidad de asignar los privilegios necesarios a cada usuario para que puedan trabajar de manera autónoma.

Para la organización de esta política de seguridad, es necesario tener en cuenta la organización jerárquica de los elementos de seguridad, de manera que la gestión de los derechos de acceso sea simple y eficaz.

SQL Server se apoya sobre tres elementos claves, que son:

Las entidades de seguridad son las cuentas de seguridad que disponen de un acceso al servidor SQL.

Los objetos asegurables representan los objetos gestionados por el servidor. Aquí, un objeto puede ser una tabla, un esquema o una base de datos, por ejemplo.

Las autorizaciones se conceden a las entidades de seguridad para que puedan trabajar con los objetos asegurables.

La organización jerárquica permite asignar una autorización (por ejemplo, SELECT) a un objeto asegurable de nivel elevado (por ejemplo, el esquema) para permitir a la entidad de seguridad que recibe la autorización...

Gestión de los accesos al servidor

Antes de poder trabajar con los datos gestionados por las bases de datos, es necesario en primer lugar conectarse al servidor SQL. Esta etapa permite hacerse identificar por el servidor SQL y utilizar posteriormente todos los derechos que se asignan a la conexión. En SQL existen dos modos de gestión de los accesos al servidor de base de datos.

Atención: en esta sección únicamente se aborda la parte de conexión al servidor. Es importante distinguir bien la conexión al servidor de la utilización de bases de datos. La conexión al servidor permite hacerse identificar por el servidor SQL como un usuario válido para utilizar, posteriormente, una base de datos: los datos y los objetos. El conjunto de estos derechos se definirá más adelante. Estos derechos se asocian a un usuario de base de datos al que corresponde una conexión.

1. Modo de seguridad de Windows

Este tipo de gestión de seguridad permite apoyarse sobre los usuarios y los grupos de Windows para el dominio y el puesto local. SQL Server utiliza la gestión de los usuarios de Windows (gestión de las contraseñas...) y recupera únicamente los nombres para crear conexiones al servidor.

Una funcionalidad muy importante de SQL Server es poder autorizar a los grupos de Windows a conectarse. La gestión de grupos simplifica enormemente la gestión del acceso a los recursos. Por lo tanto, se pueden utilizar los mismos grupos de Windows para dar acceso a archivos o a objetos de base de datos de SQL Server.

Con este método de funcionamiento, como un usuario de Windows puede pertenecer a varios grupos, puede tener varios derechos de conexión a SQL Server.

Autenticación de Windows

En modo de seguridad de Windows, solo se almacenan los nombres de usuario. La gestión de las contraseñas y la pertenencia a diferentes grupos se deja a Windows. Este modo de funcionamiento permite separar las tareas que son responsabilidad de cada uno y especializar a SQL Server en la gestión de los datos, dejando a Windows la gestión de la autenticación de los usuarios, que sabe hacerla bien. Además, con este esquema de funcionamiento, es posible aplicar la política siguiente: un usuario = una contraseña. El acceso al servidor...

Gestión de los usuarios de la base de datos

Después de la definición de las conexiones (login) a nivel del servidor, es necesario definir los usuarios en las diferentes bases de datos.

Los permisos de uso de los objetos definidos en la base de datos se asignan a nivel de los usuarios de base de datos. Cuando se define una conexión, la base de datos predeterminada permite situar la cuenta de conexión sobre una base de datos para comenzar a trabajar. Sin embargo, la conexión solo podrá trabajar sobre la base de datos si existe una cuenta de usuario definida a nivel de la base de datos y asociada a la conexión. Este es un punto de paso obligatorio, salvo si se asignan a la conexión los privilegios de alto nivel.

En general, los usuarios de base de datos se asocian a una conexión a nivel del servidor.

Sin embargo, el usuario guest (que está deshabilitado de forma predeterminada) no está asignado a ningún inicio de sesión. Como cualquier cuenta de usuario de base de datos, se le pueden otorgar derechos de acceso a los objetos.

La cuenta de invitado (guest) se activa en las bases de datos master y tempdb. Esto es parte del funcionamiento normal de SQL Server y no es posible anular esta regla.

Si un usuario tiene una conexión a SQL Server pero no existe usuario de base de datos que le permita trabajar sobre las bases de datos, el usuario solo puede realizar operaciones muy limitadas:

Existen dos tipos de permisos: los permisos de uso de los objetos definidos en una base de datos y los de ejecución de las instrucciones de SQL, que añaden nuevos objetos a la base de datos.

Los usuarios de base de datos están unidos a una conexión. Son los usuarios de base de datos quienes reciben los diferentes derechos que permiten acceder a los objetos de las bases de datos.

Para ser capaz de gestionar los accesos a la base de datos, es necesario tener los permisos correspondientes al propietario de base...

Administración de los esquemas

El propósito de los diagramas es facilitar la gestión de la seguridad del acceso de los usuarios a los objetos (tablas, vistas, procedimientos almacenados, funciones). Es parecido a un servidor de archivos con carpetas y subcarpetas, donde se almacenarán los archivos. Los derechos de acceso tienen prioridad sobre las carpetas, que será más fácil que archivo por archivo. En el caso de SQL Server, los derechos se pueden establecer en bases de datos, esquemas y eventualmente, en objetos para manejar una excepción.

En el caso de que no exista una división de esquema lógico para una base de datos, los objetos se colocarán en el esquema predeterminado, es decir, dbo.

Para acceder a los objetos, incluso si están almacenados en el esquema predeterminado del usuario, es preferible nombrarlos usando su esquema, es decir, schemaName.objectName. Cuando se usa un nombre corto (solo el nombre del objeto sin prefijarlo con el nombre del esquema), SQL Server verifica la existencia del objeto en el esquema predeterminado del usuario y luego en el esquema dbo, por lo que si se especifica el nombre del esquema, este paso no se tiene que realizar y optimiza el tiempo de respuesta de las solicitudes.

Administración de los permisos

Todos los usuarios de base de datos, incluido guest (el invitado), pertenecen al grupo public. Los derechos que se detallan a continuación se pueden asignar directamente a public. 

Los derechos se organizan de manera jerárquica con relación a los elementos del servidor a los que se puede dar seguridad.

Es posible gestionar la asignación de privilegios a nivel del servidor, de la base de datos, del esquema o directamente a nivel del objeto. De esta manera, los privilegios se pueden asignar tanto a un usuario de base de datos como a una conexión.

Los derechos otorgados a nivel de servidor, son específicos y caen dentro de los derechos de los administradores delegados. A nivel de la base de datos, también existen derechos relacionados con el acceso administrativo, pero también derechos relacionados con el acceso de los usuarios a los objetos. Estos mismos derechos también se pueden establecer sobre los esquemas o directamente en objetos (los derechos se heredan en estos tres niveles, de la misma manera que en un servidor de archivos entre carpetas y archivos).

SQL Server gestiona los privilegios con tres tipos de palabras claves:

Es decir, un privilegio se puede asignar (GRANT) o retirar (REVOKE) si se ha asignado previamente. La instrucción DENY permite prohibir el uso de un privilegio particular, aunque el privilegio en cuestión haya sido asignado directamente o por medio de un rol.

Contexto de ejecución

El contexto de ejecución está directamente relacionado con la conexión y el usuario de bases de datos asociado. La conexión de ejecución permite establecer la lista de posibles acciones y aquellas que no se pueden realizar. Esta lista se crea a partir de los permisos asignados a los usuarios directamente o a través de los roles.

En algunos casos puede ser necesario y deseable modificar el contexto de ejecución para aprovechar los permisos extendidos, pero solo en el ámbito de un script, procedimiento o función.

Asociada al contexto de ejecución, es necesario entender bien la noción de encadenamiento de propiedades en SQL Server.

Por ejemplo, el usuario Ángel recibe de María el permiso para usar (SELECT) una vista de María. La consulta SELECT de definición de la vista hace referencia a una tabla también de María. Ángel no tiene ningún permiso sobre esta tabla y podrá utilizar esta vista sin problemas, ya que los dos objetos (vista y tabla) tienen el mismo propietario.

Si la vista de María que utiliza Ángel accede a una tabla que no es propiedad de María, se comprueban los permisos asignados a Ángel para saber si este puede ejecutar la consulta.

EXECUTE AS

Con esta instrucción se puede solicitar la conexión a la base de datos usando una conexión diferente a la actual....

Los roles

Los roles son los conjuntos de permisos. Estos conjuntos existen a tres niveles distintos: servidor, base de datos y aplicación. Los roles permiten agrupar los derechos y gestionar más fácilmente los diferentes usuarios y las conexiones. Siempre es preferible asignar los derechos a los roles y posteriormente asignar los roles a los usuarios. Con una estructura como esta, la adición y la modificación de permisos o de usuarios son más sencillas.

Es posible definir un rol como un conjunto identificado de permisos. Para facilitar la gestión de los permisos, SQL Server ofrece los roles predefinidos, también llamados fijos, ya que no es posible añadir o eliminar privilegios en estos roles.

Estos roles fijos se definen en dos niveles:

Además de estos roles fijos, es posible gestionar otros roles. Es conveniente establecer un nombre único para definir un rol y posteriormente asignar uno o varios permisos respetando un procedimiento en todo punto similar al utilizado para asignar los permisos a los usuarios. Estos roles se pueden definir en tres niveles:

Los roles permiten una gestión simplificada de los privilegios, ya que también es posible definir los perfiles tipo de privilegios y posteriormente asignar a cada usuario de base de datos uno o varios perfiles tipo con objeto de darle todas las autorizaciones que necesita para trabajar en la base de datos.

El usuario dispone al final del conjunto de permisos que se le asignan:

Como complemento de estos diferentes roles, existe el rol public. Este rol es adicional, ya que todos los usuarios reciben el rol public y no pueden ignorarlo. Este rol también es particular, ya que se le pueden asignar, retirar o prohibir permisos. Todas las modificaciones hechas a nivel de los permisos sobre el rol public son válidas para todos los usuarios. Por lo tanto, no es recomendable trabajar con este rol, aunque, en algunos casos, añade flexibilidad a la gestión de los permisos.