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 los grupos permite realizar una administración más flexible que la de los usuarios. El método más simple para gestionar las conexiones es pasar por la creación de un grupo local. Este grupo local está autorizado a conectarse al servidor SQL y es utilizado por los usuarios o los grupos globales.

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 los usuarios, que sabe hacerla bien. Además, con este esquema de funcionamiento, es posible...

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.

Los usuarios de base de datos se asocian a una conexión a nivel del servidor. Sin embargo, algunos usuarios, como guest, sys e INFORMATION_SCHEMA, no se mapean a ninguna conexión.

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 corresponden a una conexión. Son los usuarios de base de datos quienes reciben los diferentes derechos que permiten utilizar 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 de datos (db_owner) o al administrador de acceso (db_accessadmin).

Administración de los esquemas

El objetivo de los esquemas es separar los usuarios de base de datos de los objetos que pueden crear. Sin embargo, los objetos no se dejan tal cual, sino que se agrupan de manera lógica en el esquema. De esta manera, es posible definir un esquema como un conjunto lógico de objetos de una base de datos.

Permitiendo esta agrupación lógica de tablas, vistas, funciones y procedimientos en la base de datos, los esquemas ofrecen una mejor legibilidad sin complicar la estructura.

Los esquemas facilitan la compartición de información entre varios usuarios sin perder el nivel de seguridad. Por ejemplo, si varios desarrolladores trabajan en conjunto sobre un mismo proyecto, todos ellos se pueden conectar utilizando su propia conexión y usuario de base de datos, lo que no impide trabajar sobre el mismo esquema y, de esta manera, compartir las tablas, vistas, procedimientos, funciones... que se definen sobre la base dentro del proyecto.

Los esquemas facilitan la administración de los permisos de uso de los objetos que los componen, ya que es posible asignar los permisos de uso de los objetos directamente a nivel de estos.

Es responsabilidad del propietario del esquema gestionar los permisos de uso del esquema y de los objetos presentes en él. El propietario del esquema puede transferir la gestión de las tablas/vistas a otros usuarios.

Para acceder a los objetos situados fuera de su esquema predeterminado, un usuario de base de datos debe utilizar...

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.

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.

1. Permisos de uso de las instrucciones

Los permisos de uso de las instrucciones SQL para crear nuevos objetos de la base de datos son los permisos para ejecutar algunas sentencias SQL. Un usuario que dispone de estos permisos puede, por ejemplo, crear sus propias tablas, procedimientos... La asignación de estos permisos no debería poder llegar a ser peligrosa y, como para todos los permisos, se deben asignar solo cuando sea necesario.

Los permisos principales de instrucciones disponibles son:

• CREATE DATABASE

• CREATE PROCEDURE

• CREATE FUNCTION

• CREATE TABLE

• BACKUP DATABASE

• CREATE VIEW

• BACKUP LOG

Es posible obtener una vista gráfica de todos los permisos disponibles en SQL Server 2014 descargando el documento pdf del sitio Web de Microsoft en la siguiente dirección: http://go.microsoft.com/fwlink/?linkid=229142

a. Autrizar

SQL Server Management Studio

Estos derechos se administran a nivel de la base de datos mediante la ventana de propiedades.

Ejemplo

El privilegio CREATE TABLE se asigna al usuario de base de datos Pedro por medio de la ventana de propiedades de la base GESCOM.

Transact SQL

La asignación de privilegios se efectúa utilizando la instrucción GRANT, cuya sintaxis se detalla a continuación.

GRANT permiso [,...] 
    TO usuario[,...] 
    [ WITH GRANT OPTION ]
 

permiso

Nombre del/de los permiso(s) relativo(s) a esta autorización. También es posible utilizar la palabra clave...

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.

En primer lugar, cuando un usuario accede a los objetos de los que es propietario, esto no representa ningún problema porque no hay ruptura de encadenamiento de propiedades. Este caso es relativamente raro, ya que los usuarios de las bases de datos que crean objetos raramente los utilizan a diario.

Otro caso sencillo se produce cuando el usuario ha recibido de su propietario permisos para usar un objeto. 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...

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.