I

dola

icelosta.

'la,de

CT,;ser

isetas

1

Seguridad SQL

Cuando alguien confía sus datos a un sistema de gestión de base de datos, laseguridad de los datos almacenados es una preocupación primordial. La seguri-dad es especialmente importante en un DBMS basado en SQL, puesto que SQLinteractivo hace el acceso a la base de datos muy sencillo. Los requerimientosde seguridad de una base de datos de producción típica son muchos y muyvariados:

• Los datos de cualquier tabla dada deberían ser accesibles a algunos usuarios,pero el acceso a otros debería ser impedido.

• Algunos usuarios deberían tener permitido actualizar datos en una tablaparticular; a otros sólo se les debería permitir recuperar datos.

• Para algunas tablas, el acceso debería estar restringido en base a las columnas.

• Algunos usuarios deberían tener denegado el acceso mediante SQL interac-tivo a una tabla, pero se les debería permitir utilizar programas de aplicaciónque actualicen la tabla.

El esquema de seguridad SQL, descrito en este capítulo, proporciona estos tiposde protección para datos en una base de datos relacional.

Conceptos de seguridad SQL

La implementación de un esquema de seguridad y el reforzamiento de lasrestricciones de seguridad son responsabilidad del software DBMS. El lenguajeSQL define un panorama general para la seguridad de la base de datos, y las

351

352 Aniirtiia KOI

sentencias SQL se utilizan para especificar restricciones de seguridad. El esque-ma de seguridad SQL se basa en tres conceptos principales:

• Los usuarios son los actores de la base de datos. Cada vez que el DBMSrecupera, inserta, suprime o actualiza datos, lo hace a cuenta de algún usuario.El DBMS permitirá o prohibirá la acción dependiendo de qué usuario estéefectuando la petición.

• Los objetos de la base de datos son los elementos a los cuales se puede aplicarla protección de seguridad SQL. La seguridad se aplica generalmente a tablasy vistas, pero otros objetos tales como formularios, programas de aplicación ybases de datos enteras también pueden ser protegidos. La mayoría de losusuarios tendrán permiso para utilizar ciertos objetos de la base de datos,pero tendrán prohibido el uso de otros.

• Los privilegios son las acciones que un usuario tiene permitido efectuar paraun determinado objeto de la base de datos. Un usuario puede tener permisopara SELECT e INSERÍ sobre filas en una tabla determinada, por ejemplo, peropuede carecer de permiso para DELETE o ÚRDATE filas de la tabla. Un usuariodiferente puede tener un conjunto diferente de privilegios.

La Figura 15.1 muestra cómo podrían ser utilizados estos conceptos de seguri-dad en un esauema de seguridad nara la base de datos eiemnlo.

— A J i

Para establecer un esquema de seguridad en una base de datos, se utiliza lasentencia de SQL GRANT para especificar qué usuarios tienen qué privilegiossobre qué objetos de la base de datos. Por ejemplo, he aquí una sentencia GRANTque permite a Sam Clark recuperar e insertar datos en la tabla OFICINAS de labase de datos ejemplo:

Permite a Sam Clark recuperar e insertar datos en la tabla OFICINAS.

GRANT SELECT, INSERTON OFICINASTO SAM

La sentencia GRANT especifica una combinación de un identificador de usuario(SAM), un objeto (la tabla O F I C I N A S ) y privilegios (SELECT e INSERT). Una vezconcedidos, los privilegios pueden ser rescindidos más tarde con esta sentenciaDFWWF-

Revoca los privilegios concedidos anteriormente a Sam Clark.

REVOKE SELECT, INSERTON OFICINAS

YWfí SAH

Las sentencias GRANT y REVOKE se describen con detalle posteriormente en estecapítulo.

Tabl

Taca t

los

Figu

Ide

Cadun iUSUc

ejeciid-uDBI

admhabíque

so.té

irisy

ra30

roio;

laosNTla

10ez

Seguridad SQL 353

Departamentoprocesadode pedidos

Departamentocobro decuentas

Totalacceso

Tabla PEDIDOS

/Al /A\SELECT,'UPDATE

algunas^columnas

Tabla CLIENTES

INSERT,SELECT

Á K\mmSELECT

algunascolumnas

Tabla REPVENTAS

Larry Fitch,director dela oficinade Chicago

Tabla OFICINAS

Disponiblepara todoslos usuarios

ste

ITotalaccesoa todos - N

los datos NM̂/.

SELECT Iftalgunasfilas X

*

SELECT\ oalgunas A\columnas /Ai

Bob Smith,director dela oficinade Chicago

Total acceso a y \todos los datos >s,M/.

Sam ClarkV.P. de ventas

George WalkinsV.P. de marketing

Figura 15.1. Un esquema de seguridad para la base de datos ejemplo.

Identificadores de usuario (Id-Usuario)

Cada usuario de una base de datos basada en SQL tiene asignado un id-usuario,un nombre breve que identifica al usuario dentro del software DBMS. El id-usuario se encuentra en el núcleo de la seguridad SQL. Toda sentencia SQLejecutada por el DBMS se lleva a cabo a cuenta de un id-usuario específico. Elid-usuario determina si la sentencia va a ser permitida o prohibida por elDBMS. En una base de datos de producción los id-usuario son asignados por eladministrador. En una base de datos sobre un computador personal, puedehaber únicamente un solo id-usuario, que identifica al usuario que ha creado yque tiene la propiedad de la base de datos.

I

354 Apliaue SQL

El estándar SQL ANSÍ/ISO permite que los id-usuario tengan hasta 18caracteres y requiere que sean nombres SQL válidos, pero muchos productosDBMS comerciales tienen diferentes restricciones. En DB2 y SQL/DS, porejemplo, los id-usuario no pueden tener más de ocho caracteres. En Sybase ySQL Server, los id-usuario pueden tener hasta 30 caracteres. Si la portabilidades una preocupación, es mejor limitar los id-usuario a ocho o menos caracteres.La Figura 15.2 muestra a varios usuarios que necesitan acceso a la base de datosejemplo e id-usuario típicos asignados a ellos. Observe que todos los usuarios enel departamento de procesado de pedidos pueden tener asignados el mismo id-usuario, puesto que tienen todos idénticos privilegios en la base de datos.

El estándar SQL ANSÍ/ISO utiliza el término id-autorización en vez de id-usuario, y usted encontrará ocasionalmente este término utilizado en otra docu-mentación SQL. Técnicamente, «id-autorización» es un término más preciso,puesto que el papel de la identificación (id) es determinar la autorización oprivilegios en la base de datos. Existen situaciones, como en la Figura 15.2,donde tiene sentido asignar el mismo id-usuario a diferentes usuarios. En otrassituaciones, una sola persona puede utilizar dos o tres id-usuario diferentes. Enuna base de datos de producción, los id-autorización pueden ir asociados conprogramas y grupos de programas, en vez de con usuarios humanos. En cadauna de estas situaciones, el «id-autorización» es un término más preciso y menosconfuso que «id-usuario». Sin embargo, la práctica más común es asignar un id-usuario diferente a cada persona, y la mayoría de los DBMS basados en SQLutilizan el término «id-usuario» en su documentación.

Validación de usuario. El estándar SQL ANSÍ/ISO especifica que los id-usuario proporcionan seguridad en la base de datos, pero no dice nada conrespecto al mecanismo de asociar un id-usuario con una sentencia SQL. Porejemplo, cuando se escriben sentencias SQL en una utilidad SQL interactiva¿cómo determina el DBMS qué id-usuario está asociado con las sentencias? Lamayoría de las implementaciones SQL comerciales establecen un id-usuariopara cada sesión de base de datos. En SQL interactivo, la sesión comienzacuando arranca el programa SQL interactivo, y dura hasta que se abandona elprograma. En un programa de aplicación que utiliza SQL programado, la sesióncomienza cuando el programa de aplicación se conecta al DBMS, y finalizacuando el programa de aplicación termina. Todas las sentencias SQL utilizadasdurante la sesión están asociadas con el id-usuario especificado para la sesión.

Generalmente debe suministrarse tanto un id-usuario como una contraseñaasociada al comienzo de una sesión. El DBMS comprueba la contraseña paraverificar que el usuario está, en efecto, autorizado a utilizar el id-usuario quesuministra. Aunque loa id usuario y las contraseñas son habituales en la mayo-ría de los productos SQL, las técnicas específicas utilizadas para especificar el id-usuario y la contraseña varían de un producto a otro.

Algunos productos DBMS implementan su propia seguridad id-usuario/con-

Dep,

traseíllamaasoci;

El'prnomh

ISQ

8IS

>ryid5S.

OS

en¡d-

id-cu-ISO,

1 O

52,trasEiicon;adasncslid-SQL

i con. Porictiva,s?Laiuariolienzaona elsesióninalizaizadassesión.;raseña¡a parario quemayo-

ir el id-

rio/con-

Seguridad SQL 355

Departamento de procesado de pedidos Departamento de cobro de cuentas

id-usuario: USUARIOPP

Directores de oficina

id-usuario: USUARIOCC

Vicepresidentes

Larry Fitch Bob SmithSam Clark

V.P. de ventasGeorge Watkins

V.P. de marketing

id-usuario: LARRY id-usuario: BOB id-usuario: SAM id-usuario: GEORGE

Figura 15.2. Asignaciones de id-usuario para la base de datos ejemplo.

traseña. Por ejemplo, cuando se utiliza el programa SQL interactivo Oracle,llamado SQLPLUS, hay que especificar un nombre de usuario y la contraseñaasociada en la orden que arranca el programa, de este modo:

SQLPLUS SCOTT/TIGRE

El'programa SQL interactivo de Sybase, llamado ISQL, también acepta unnombre de usuario y contraseña, utilizando este formato de orden:

ISQL /USER=SCOTT /PASSWORO=TIGRE

En cada caso, el DBMS valida el id-usuario (SCOTT) y la contraseña (TIGRE) antesde comenzar la sesión SQL interactiva.

Muchos otros productos DBMS, incluyendo Ingres e Informix, utilizan losnombres de usuario del sistema operativo del computador como id-usuario de labase de datos. Por ejemplo, cuando usted se conecta a un sistema informáticoVAX/VMS, debe suministrar un nombre de usuario VMS válido y una contrase-ña para obtener acceso. Para iniciar la utilidad SQL interactiva de Ingres,simplemente tiene que dar la orden:

ISQL BOVENTAS

Anlimie .90 /

donde BDVENTAS es el nombre de la base de datos Ingres que usted desea utilizar.Ingres obtiene automáticamente el nombre de usuario VMS y lo convierte en elid-usuario de Ingres para la sesión. Por tanto usted no tiene que especificar unid-usuario de base de datos y una contraseña aparte. El SQL interactivo deDB2, que corre bajo MVS/TSO, utiliza una técnica análoga. El nombre depresentación ante TSO se convierte automáticamente en el id-usuario de DB2para la sesión SQL interactiva.

La seguridad también se aplica al acceso programado a una base de datos,de modo que el DBMS debe determinar y validar el id-usuario para cadaprograma de aplicación que pretenda acceder a la base de datos. De nuevo, lastécnicas y reglas para establecer el id-usuario varían de un producto de DBMS aotro. Se describirán en el Capítulo 17, que trata del SQL programado.

Grupos de usuario. En una base de datos de producción grande existen confrecuencia grupos de usuario con necesidades similares. En la base de datosejemplo, por ejemplo, las tres personas del departamento de procesado depedidos forman un grupo natural de usuarios, y las dos personas del departa-mento de cobro de cuentas forman otro grupo natural. Dentro de cada grupo,todos los usuarios tienen necesidades idénticas para acceder a los datos ydeberían tener privilegios idénticos.

Bajo el esquema de seguridad de SQL ANSÍ/ISO, se pueden manejar gruposde usuario con similares necesidades en uno de dos modos:

• Se puede asignar el mismo id-usuario a todas las personas del grupo, como semuestra en la Figura 15.2. Este esquema simplifica la administración de laseguridad, ya que permite especificar los privilegios de acceso a datos una vezpara el único id-usuario. Sin embargo, bajo este esquema las personas quecomparten el id-usuario no pueden distinguirse unas de otras en las visuahza-ciones del operador del sistema ni en los informes del DBMS.

• Se puede asignar un id-usuario diferente a cada persona del grupo. Esteesquema permite diferenciar a los usuarios en los informes producidos por elDBMS y permite establecer privilegios diferentes para los usuarios individua-les con'posterioridad. Sin embargo, deben especificarse privilegios para cadausuario individualmente, haciendo la administración de la segundad tediosa ypropensa a errores.

El esquema que se elija dependerá de los compromisos en cada base de datosy aplicación particular.

Sybase y SQL Server ofrecen una tercera alternativa para manejar grupos deusuarios similares. Soportan id-gmpo, que identifica grupos de id-usuario rela-cionados. Los privilegios pueden ser concedidos tanto a id-usuanos individualescomo a id-grupo, y un usuario puede efectuar una acción de base de datos si sele permite por su privilegio bien como id-usuario o bien como id-grupo. Los id-

grujgrupServ

Idiferde irusuamenisecwprivisecuilos úgruptadoipero

Obj\

Las fen unsegur:mentíid-usí

LÍdad amientsegurialmacespaciobjetoalgun(denegíotros

Privi

El conde Hat,

especií

Seguridad SQL 357

r.elinleie>2

ia.as> a

ontosdeta-¡po»5 ypos

5 se5 lavezqueiza-

i

Este>r eliua-;adaisa y

grupos simplifican por tanto la administración de privilegios proporcionados agrupos de usuarios. Sin embargo, no son estándar y son específicos de SQLServer y Sybase.

DB2 también soporta grupos de usuarios, pero adopta un planteamientodiferente. El administrador de la base de datos en DB2 puede configurar al DB2

usuario (conocido como id-autorización primario), DB2 examina automática-mente un conjunto de id-usuarios adicionales (conocido como id-autorizaciónsecundario) que puede utilizarse. Cuando DB2 comrpueba posteriormente losprivilegios, examina los privilegios de todos los id-autorización, primario ysecundario. El administrador de la base de datos en DB2 establece normalmentelos id-autorización secundarios para que sean los mismos que los nombres degrupo de usuario utilizados por RACF, la facilidad de seguridad en maxicompu-tador IBM. Así que el mecanismo de DB2 proporciona efectivamente id-grupos,pero lo hace sin añadir al mecanismo id-usuario.

Objetos de seguridad

I .as nrnteeciones de seguridad SOL se aplican a objetos específicos contenidosen una base de datos. El estándar ANSÍ/ISO especifica dos tipos de objetos deseguridad —tablas y vistas—. Así cada tabla y cada vista pueden ser individual-mente protegidas. El acceso a una tabla o vista puede ser permitido por ciertosid-usuario y prohibido para otros id-usuario.

La mayoría de los productos SQL comerciales soportan objetos de seguri-dad adicionales. En una base de datos SQL Server, por ejemplo, un procedi-miento almacenado es un objeto importante de la base de datos. El esquema deseguridad SQL determina qué usuarios pueden crear y suprimir procedimientosalmacenados y qué usuarios tienen permitido ejecutarlos. En el DB2 de IBM, losespacios de tablas físicos en donde se almacenan las tablas son tratados comoobjetos de seguridad. El administrador de la base de datos puede dar permiso aalgunos id-usuario para crear nuevas tablas en un espacio de tablas particular ydenegar ese permiso a otros id-usuario. Otras implementaciones SQL soportanotros objetos de seguridad.

latos

)s derela-ualesj>i se)s id-

Privilagios

El conjunto de acciones que un usuario puede efectuar sobre un objeto de basede datos se denomina los privilegios para el objeto. El estándar SQL ANSÍ/ISOespecifica cuatro privilegios para tablas y vistas:

@ El privilegio SELECT permite recuperar datos de una tabla o vista. Con este

oco !«/;„,.„ on/*

privilegio, se puede especificar la tabla o vista en la cláusula FROM de unasentencia SELECT o subconsulta.

• El privilegio INSERÍ permite insertar nuevas filas en una tabla o vista. Con esteprivilegio, se puede especificar la tabla o vista en la cláusula INTO de unasentencia INSERÍ.

• El privilegio DELETE permite eliminar filas de datos de una tabla o vista. Coneste privilegio, se puede especificar la tabla o vista en la cláusula FROM de unasentencia DELETE.

• El privilegio ÚRDATE permite modificar filas de datos en una tabla o vista. Coneste privilegio, se puede especificar la tabla o vista como tabla destino en unasentencia ÚRDATE. El privilegio ÚRDATE puede restringirse a columnas específicasde la tabla o vista, permitiendo actualizaciones de estas columnas, pero desau-torizando actualizaciones de cualesquiera otras columnas.

Estos cuatro privilegios son soportados por virtualmente todos los productosSQL comerciales.

Privilegios de propiedad. Cuando se crea una tabla con la sentencia CRÉATETABLE, quien lo hace se convierte en su propietario y recibe totales privilegios

la ía'úla (GLLECT, INSERT, DELETE, ÚRDATE y cualesquiera otro?soportados por el DBMS). Otros usuarios no tiene inicialmente privilegios sobrela tabla recién creada. Si se les va a proporcionar acceso a la tabla, hay queconcederles específicamente privilegios, utilizando la sentencia GRANT.

Si usted crea una vista con la sentencia CRÉATE VIEW, se convierte en elpropietario de la vista, pero no recibe necesariamente privilegios totales sobreella. Para crear la vista con éxito debe ya tener el privilegio SELECT sobre cadauna de las tablas fuente para la vista; por tanto el DBMS le proporciona elprivilegio SELECT para la vista automáticamente. Para cada uno de los otrosprivilegios (INSERT, DELETE y ÚRDATE), el DBMS proporciona el privilegio sobre lavista solamente si se dispone de ese mismo privilegio sobre todas las tablasfuente para la vista.

Otros privilegios. Muchos productos DBMS comerciales ofrecen privilegiosadicionales sobre tablas y vistas además de los privilegios SELECT, INSERT, DELETE yÚRDATE especificados en el estándar SQL ANSÍ/ISO. Por ejemplo, las bases dedatos sobre maxicomputadores de IBM (DB2 y SQL/DS) y Oracle soportan unprivilegio ALTER y un privilegio INDEX para las tablas. Un usuario con el privilegioALTER sobre una tabla particular puede utilizar la sentencia ALTER TABLE paramodificar la definición de la tabla; un usuario con el privilegio INDEX puede wcaíun índice para la tabla con la sentencia CRÉATE INDEX. En productos DBMS queno soportan los privilegios ALTER e INDEX, únicamente el propietario puede utili-zar las sentencias ALTER TABLE y CRÉATE I N D E X .

i

Vist

Se pueSígüien

CREA!

y dandmuestrael acces

ina!

5Steana

Zoo.una

Conunaficas;sau-

uctos

;REATElegioslegiossobre

en el; sobree cadaiona els otrosobre la, tablas

ivilegiosDELETE yjases de3rtan undvilegioBLE! para;de creariMS queede utili-

Seguridad SQL 359

Otro ejemplo de privilegios adicionales sobre tablas y vistas es el privilegioSELECT extendido ofertado por Sybase y SQL Server. Al igual que el privilegioUPOATE de ANSÍ/ISO, este privilegio SELECT puede ser especificado para columnasindividuales de una tabla o vista. Por tanto un usuario puede tener permitidorecuperar ciertas columnas de una tabla mientras que otro usuario está restrin-gido a otras columnas.

Frecuentemente se soportan privilegios adicionales para objetos de seguri-dad DBMS diferentes a tablas y vistas. Por ejemplo, Sybase y SQL Serversoportan un privilegio EXECUTE para procedimientos almacenados, que determinasi un usuario tiene permitido ejecutar un procedimiento almacenado. DB2soporta un privilegio USE para espacios de tablas, que determina si un usuariopuede crear tablas en un espacio de tablas específico. Estos privilegios sontípicamente administrados utilizando las sentencias GRANT y REVOKE, del mismomodo que los privilegios estándar ANSÍ/ISO.

Vistas y segur/dad SQL

Además de las restricciones sobre acceso a tabla proporcionadas por los privile-gios SQL, las vistas también juegan un papel clave en la seguridad SQL.Definiendo cuidadosamente una vista y proporcionando un permiso de usuariopara acceder a ella pero no a sus tablas fuente, se puede restringir efectivamenteel acceso de un usuario a únicamente columnas y filas seleccionadas. Las vistasofrecen por tanto un modo de ejercitar un control muy preciso sobre qué datosse hacen visibles a qué usuarios.

Por ejemplo, supongamos que se desea forzar esta regla de seguridad en labase de datos ejemplo:

El personal del departamento de cobro de cuentas debe poder recuperar losnúmeros y nombres de los empleados y los números de oficina de la tablaREPVENTAS, pero los datos referentes a ventas y cuotas no deben tenerlosdisponibles.

Se puede implementar esta regla de seguridad definiendo una vista del modosiguiente:

CRÉATE VIEW INFOREP ASSELECT NUM_EMPL, NOMBRE, OFICINOEP

FROH REPVENTAS

y dando el privilegio SELECT para la vista al id-usuario U S U A R I O C C , como semuestra en la Figura 15.3. Este ejemplo utiliza una vista vertical para restringirel acceso a columnas específicas.

360 Anüaue SO¿

Las vistas horizontales son también efectivas para forzar reglas de seguridadcomo ésta:

Los directores de venta de cada región deben tener acceso completo a losdatos de REPVENTAS referentes a los vendedores asignados a esa región.

Como se muestra en la Figura 15.4, se pueden definir dos vistas, VISTASESTE yVISTASOESTE, que contengan los datos de REPVENTAS referentes a cada una de lasdos regiones, y luego conceder a cada director de oficina acceso a la vistaadecuada.

Naturalmente las vistas pueden ser mucho más complejas que los sencillossubconjuntos de filas y columnas de una tabla única mostrados en estos ejem-plos. Definiendo una vista con una consulta agrupada, se puede dar a unusuario acceso a datos sumarios, pero no a las filas detalladas de la tablasubyacente. Una vista también puede combinar datos de dos o más tablas,proporcionando precisamente los datos necesitados por un usuario particular ydenegando acceso a todo otro dato. La utilidad de las vistas para implementarseguridad SQL está limitada por las dos restricciones fundamentales descritasanteriormente en el Capítulo 14:

• Restricciones de actualización. El privilegio SELECT puede ser utilizado convistas de sólo lectura para limitar la recuperación de datos, pero los privilegiosINSERÍ, DELETE y ÚRDATE no tienen significado para estas vistas. Si un usuariodebe actualizar los datos visibles en una lista de sólo lectura, el usuario debeobtener permiso para actualizar las tablas subyacentes, y debe utilizar lassentencias INSERT, DELETE y ÚRDATE que referencian a esas tablas.

• Rendimiento. Puesto que el DBMS traduce cada acceso a una vista en unacceso correspondiente a sus tablas fuente, las vistas pueden añadir recargossignificativos a las operaciones de base de datos. Las vistas no pueden serutilizadas indiscriminadamente para restringir el acceso a la base de datos sincausar que el rendimiento global de la base de datos descienda.

Concesión de privilegios (GRANT)

La sentencia G R A N T , mostrada en la Figura 15.5, se utiliza para conceder privile-gios de seguridad sobre objetos de la base de datos a usuarios específicos.Normalmente la sentencia GRANT es utilizada por el propietario de una tabla ovista para proporcionar a otros usuarios acceso a los datos. Como se inuestia cula figura, la sentencia GRANT incluye una lista específica de los privilegios aconceder, el nombre de la tabla a la cual se aplican los privilegios y el id-usuarioal cual los privilegios son concedidos.

NUMJH

105109102106104iOi110108103107

Tabla

Figuf

Seguridad SQL 361

lad;

los

t E y; lasvista

USUARIOCC

iO conilegiosisuario0 debezar las

1 en unecargosden seratos sin

r privüe-pecificos.a tabla o•uestra en«legios a

-usuario

4Í/U

V

Vista INFOREP 'NUM_EHPL

105109102106104101110108103107

4í/U

JSELECT

!

NOMBRE

BUL AdamsMary JonesSue SmithSara ClarkBob SmithDan RobertsTora SnyderLarry FitchPaul CruzttónC/ nñycci.1

OFICIN/LREP

1311211112121221

NULLÍ.L.

Accesodenegado

NUN_EMP

105109102106104101110108103107

NOMBRE

Bill ÁcimasMary JonesSue SmithSan ClarkBob SmithDam RobertsTom SnyderLarry Fitchrain CruzNancy Ange.li

EDAD

37314852334541622949

OFICINOEP

1311211112121221

NULL22

TITULO

Rep VentasRep VentasRep VentasVP VentasDir VentasRep V*ntasRep VentasDir VentasRep Ventas•n'ép vcrítáS

CONTRATO

02/12/198810/12/198912/10/198606/14/198805/19/198710/20/198601/13/199010/12/198903/01/198711/14/1988

DIRECTOR

104106108

NULL106104101106104108

CUOTA

$350,000.00$300,000.00$350,000.00$275,000.00$200,000.00$300,000.00

NULL$350,000.00$275,000.00$300,000.00

VENTAS

$367,911.00$392,725.00$474,050.00$299,912.00$142,594.00$305,673.00$75,985.00$361,865.00$286,775.00$186,042.00

Tabla REPVENTAS

Figura 15.3. Utilización de una vista para restringir acceso a columna.

SELECT

INSERT

DELETE

ÚRDATE»-

Vista REPESTE

NUfLEHPU

105109106104101103

NOMBRE

Bill AdamsMary JonesSara ClarkBob SmithDan RobertsPaul Cruz

EDAD

373152334529

OFICINOEP

131111121212

<

/X

\ >

• "§C/JoF

Tabla REPVENTAS

SELECT

INSERT

DELETE

ÚRDATE

Vista REPSOESTE

NUOMPL

102108107

NOMBRE

Sue SmithLarry FitchNancy Angelí i

EDAD

486249

OFICINA _REP

212122

1

\

\\

//

X

XNX.

/

////*\' N\\ \\

„•"^>

NUOMPL

105109102106104101110108103107

NOMBRE

Bill AdamsMary JonesSue SmithSam ClarkBob SmtihDan RobertsTon SnyderLarr^ FitchPaul CruzNancy Angelí i

EDAD37314852334541622949

OFICINOEP

131121111212 <

NUIL211222

Figura 15.4. Utilización de vistas para restringir acceso ajila.

i

•a -a si o 0.Si ft «r;

Seguridad SQL 363

La sentencia GRANT mostrada en el diagrama sintáctico se conforma al están-dar SQL ANSÍ/ISO. Muchos productos DBMS siguen la sintaxis de la senten-cia GRANT de DB2, que es más flexible. La sintaxis DB2 permite especificar unalista de id-usuarios y una lista de tablas, haciendo más simple conceder muchosprivilegios de una vez. He aquí algunos ejemplos de sencillas sentencias GRANTpara la base de datos ejemplo:

Proporciona a los usuarios de procesado de pedidos acceso completo a la tabla PEDIDOS.

GRANT SELECT, INSERT, DELETE, UPDATEON PEDIDOSTO USUARIOPP

Permite a los usuarios de cobro de cuentas a recuperar datos del cliente y añadir nuevosclientes a la tabla CLIENTES, pero proporciona a los usuarios de procesado de pedidos accesode sólo lectura.

GRANT SELECT, INSERTON CLIENTESTO USUARIOCC

GRANT SELECTON CLIENTESTO USUARIOPP

|— GRANT SELECT

— INSERT

— DELETE

1— UPDATE

nombre-de-columa

i

-).

ALL PRIVILEGES-

ON nombre-de-tabla 10-r-nombre-de-usuario-

PUBLIC I WITH GRANT OPTION J-*••

figura 10.0. uiúgruma Smíavli

364 Anliaue SQL

Permite a Sam Clark insertar o suprimir una oficina.

GRANT INSERÍ, DELETEON OFICINASTO SAM

Por conveniencia, la sentencia GRANT dispone de dos atajos que se puedenutilizar cuando se conceden muchos privilegios o cuando se conceden a muchosusuarios. En vez de listar específicamente todos los privilegios disponibles paraun objeto particular, se puede utilizar las palabras claves ALL PRIVILEGES. Estasentencia GRANT da a Sam Clark, el vicepresidente de ventas, acceso total a latabla REPVENTAS:

Da privilegios totales sobre la tabla REPVENTAS a Sam Clark.

GRANT ALL PRIVILEGESON REPVENTASTO SAM

En vez de conceder privilegios a todos los usuarios de la base de datos uno auno, se puede utilizar la palabra clave PUBLIC para conceder un privilegio a todousuario autorizado de la base de datos. Esta sentencia GRANT permite a cualquie-ra recuperar datos de ia labia OFICINAS:

Da a todos los usuarios acceso SELECT a la tabla OFICINAS.

GRANT SELECTON OFICINASTO PUBLIC

Observe que esta sentencia GRANT concede acceso a todos los usuarios autoriza-dos presentes y futuros, no solamente a los id-usuarios actualmente conocidos alDBMS. Esto elimina ia necesidad de conceder explícitamente privilegios a losnuevos usuarios conforme son autorizados.

El estándar SQL ANSÍ/ISO permite conceder el privilegio UPDATE para columnasindividuales de una tabla o vista. Las columnas actualizables se listan tras lapalabra clave UPDATE y se encierran enire paréntesis. He aqui una sentenciaUPDATE que permite al departamento de procesado de pedidos actualizar sola-mente las columnas del nombre de la empresa y del vendedor en la tablaCLIENTES:

FuPP

CUSot

Seguridad SQL 365

leniosaraIstai l a

no atodoquie-

onza-idos al¡ a los

lumnastras lantenciaar sola-

Permite a los usuarios de procesado de pedidos modificar los nombres de empresa y lasasignaciones de vendedores.

GRANT ÚRDATE (EMPRESA, REPELIENTE)ON CLIENTESTO USUARIOPP

Si la lista de columnas se omite, el privilegio ÚRDATE se aplica a todas lascolumnas de la tabla o vista, como en este ejemplo:

Permite a los usuarios de cobro de cuentas modificar cualquier información de cliente.

GRANT UPDATEON CLIENTESTO USUARIOCC

El estándar ANSÍ/ISO no permite una lista de columnas para el privilegioSELECT; requiere que el privilegio SELECT se aplique a todas las columnas de unatabla o vista. En la práctica, ésta no es una restricción importante. Para conce-der acceso a columnas específicas se define primero una vista sobre la tabla queincluya sólo a esas columnas, y luego se concede el privilegio SELECT para la vistaúnicamente, como describimos anteriormente en este capítulo. Sin embargo, lasvistas definidas únicamente con propósitos de seguridad pueden embarullar laestructura de una base de datos que de otra manera resultaría sencilla. Por estarazón algunos productos DBMS permiten una lista de columnas para el privile-gio SELECT. Por ejemplo, la siguiente sentencia GRANT es legal para los productosDBMS Sybase, SQL Server e Informix:

Proporciona a los usuarios de cobro de cuentas acceso de sólo lectura a las columnas dey riürtibi'K dé einplcüuO y Gjicixz MC vCriiss **c *« ta^ta •.... .- ..... -.

GRANT SELECT (NlfLEMPL, NOMBRE, OFICINOEP)ON REPVENTASTO USUARIOCC

Esta sentencia GRANT elimina la necesidad de la vista INFOREP definida en laFigura 15.3, y en la práctica puede eliminar la necesidad de muchas vistas enuna base de datos de producción. Sin embargo, el uso de una lista de columnaspara el privilegio SELECT es única en ciertos dialectos SQL, y no está permitidapor el estándar ANSÍ/ISO ni por los productos SQL de IBM.

Paso de privilegios (GRANT OPTION)

Cuando usted crea un objeto de base de datos y se convierte en su propietario,usted es la única persona que puede conceder privilegios para autorizar elobjeto. Cuando concede privilegios a otros usuarios, éstos tienen permitido el

366 Aplique SQL

uso del objeto, pero no pueden transmitir esos privilegios a otros usuarios. Deeste modo el propietario de un objeto mantiene un control muy estricto sobrequién tiene permisos para utilizar el objeto y sobre qué formas de acceso sepermiten.

Ocasionalmente puede desearse permitir a otros usuarios que concedanprivilegios sobre un objeto que no es de su propiedad. Por ejemplo, considere-mos una vez más las vistas REPESTE y REPOESTE de la base de datos ejemplo. SamClark el vicepresidente de ventas, creó estas vistas y tiene propiedad sobre ellas.El puede proporcionar al director de la oficina de Los Angeles, Larry Fitch,permiso para utilizar la vista REPOESTE con esta sentencia GRANT:

GRANT SELECTON REPOESTETO LARRY

;Qué ocurre si Larry desea conceder permiso a Sue Smith (id-usuario SUE) paraacceder a los datos de REPOESTE debido a que ella está realizando algunasprevisiones de ventas para la oficina de Los Angeles? Con la sentencia GRANTprecedente, él no puede proporcionar el privilegio requerido. Únicamente SamClark puede conceder el privilegio, puesto que es el propietario de la vista.

Si Sam desea dar a Larry discreción sobre quién puede utilizar la vistaREPOESTE. puede utilizar esta variante de la sentencia GRANT anterior:

GRANT SELECTON REPOESTETO LARRY

WITH GRANT OPTION

Debido a la cláusula WITH GRANT OPTION, esta sentencia GRANT comporta, junto conlos privilegios especificados, el derecho a conceder esos privilegios a otrosusuarios.

Larry puede ahora emitir esta sentencia GRANT:

GRANT SELECTON REPOESTETO SUE

„ „ -., _____ !_ *_„ J» 1.. .,„<.„ T o Pimii-d 1 ^ f\la cual permue a sue amun recupera! uaiwa u^ i<* YMM» ..^. «.-«.*ilustra gráficamente el flujo de privilegios, primero de Sam Clark a Larry, yluego de Larry a Sue. Debido a que la sentencia GRANT emitida por Larry noincluía la cláusula WITH GRANT OPTION, la cadena de permisos finaliza con Sue; ellapuede recuperar los datos de REPOESTE, pero no puede conceder acceso a otrousuario. Sin embargo, si la concesión de privilegios de Larry a Sue hubieraincluido la opción de concesión, la cadena podría continuar a otro nivel, permi-tiendo a Sue que concediera acceso a otros usuarios.

Figur

Aiúnica;nara ¡

CRE

GRAÍ(

Larry <REPOES1efectivjsobre Rese prñ

Un<

Dearese

ianoc-iaralias,itch,

Seguridad SQL 367

GRANTyiTH GRANT OPTION

SAM

para;unasGRANTSam

a.vista

ito coni otros

; \V '•-' •

ura 15.6Larry, y,arry no

E

Sue; ella [o a otrohubiera

;1, permi-

i

Figura 15.6. Utilización de la GRANT OPTION.

Alternativamente, Larry podría construir una vista para Sue que incluyeraúnicamente los vendedores de la oficina de Los Angeles y después le proporcio-nara acceso a esa vista:

CRÉATE VIEW REPSLA ASSELECT *

FROM REPOESTEWHERE OFICINA = 21

GRANT ALL PRIVILEGESON REPSLATO SUE

Larry será el propietario de la vista REPSLA, pero no es el propietario de la vistaREPOESTE de la cual ésta nueva se ha derivado. Para mantener la seguridadefectiva, el DBMS requiere que Larry no solamente tenga el privilegio SELECTsobre REPOESTE, sino que también exige que tenga la opción de concesión paraese privilegio antes de permitirle conceder el privilegio SELECT sobre REPSLA a Sue.

Una vez que a un usuario se le han concedido cienos privilegios con ía

368 Anliaue SOL

opción de concesión, ese usuario puede conceder estos privilegios y la opción deconcesión a otros usuarios. Aquellos otros usuarios pueden, a su vez, continuarconcediendo tanto los privilegios como la opción de concesión. Por esta razónse debería utilizar gran cuidado cuando se proporcionen a otros usuarios laopción de concesión. Observe que la opción de concesión se aplica únicamente alos privilegios específicos designados en la sentencia GRANT. Si se desean concederciertos privilegios con la opción de concesión y conceder otros privilegios sinella, deben utilizarse dos sentencias GRANT separadas, como en este ejemplo:

Permite a Larry Fitch recuperar, insertar, actualizar y suprimir datos de la tabla REPOESTE, ytambién se le permite conceder permiso de recuperación a otros usuarios.

GRANT SELECTON REPOESTETO LARRY

WITH GRANT OPTION

GRANT INSERT, DELETE, UPDATEON REPOESTETO LARRY

Revocación de orivileaios (REVOKE)

En la mayoría de las bases de datos basadas en SQL, los privilegios que se hanconcedido con la sentencia GRANT pueden ser retirados con la sentencia REVOKE,mostrada en la Figura 15.7. La sentencia REVOKE tiene una estructura que seasemeja estrechamente a la sentencia GRANT, especificando un conjunto específicode privilegios a ser revocados, para un objeto de base de datos específico, parauno o más id-usuarios.

Una sentencia REVOKE puede retirar todos o parte de los privilegios quepreviamente se han concedido a un id-usuario. Por ejemplo, consideremos estasecuencia de sentencias:

Concede y luego revoca algunos privilegios sobre la tabla REPVENTAS.

GRANT SELECT, INSERT, UPDATEUN REPVENTASTO USUARIOCC, USUARIOPP

REVOKE INSERT, UPDATEON REPVENTAS

FROH USUARIOPP

Los privilegios INSERT y UPDATE sobre la tabla REPVENTAS son primero concedidos alos dos usuarios y luego revocados a uno de ellos. Sin embargo, el privilegio

Figura

SELECT i

sentena

Retir

REVOKIOf

FR(»

Retín

REVOKEON

FRON

líevocttodos i

REVOKEON

FROH

Cuancprivilegio;puede tea

Seguridad SQL 369

" - • • ' • '! deuarzónslaite aeder; sin

i

STE,>>

1 i. . . 1 ;

. . I ' 1

' ..1

• . •

L ,|..

se hanREVOKE,que se

pecífico;o, para

jos quenos esta

'

prvnií'r - tn reí1 '¡ INSERÍ

DELETE — •

1 UPOATE '.

-- ) '

ALL PRIVILEGES

. 'n ' i ^ '

, 9 puní ir •• —

fFigura 15.7. Diagrama sintáctico de la sentencia REVOKE.

SELECT permanece para ambos id-usuarios. He aquí algunos otros ejemplos de lasentencia REVOKE:

Retira todos los privilegios concedidos anteriormente sobre la tabla O F I C I N A S .

REVOKE ALL PRIVILEGESON O F I C I N A S

FROH USUARIOCC

Retira los privilegios UPDATE y DELETE a dos id-usuarios.

i.cedidos aprivilegio

REVOKE UPDATE, DELETEON OFICINAS

FROH USUARIOCC, USUARIOPP

Revoca todos los privilegios sobre la tabla O F I C I N A S que fueron anteriormente concedidos atodos los usuarios.

REVOKE ALL PRIVILEGESON OFICINAS

FROH PUBLIC

Cuando usted emite una sentencia REVOKE, solamente puede retirar aquellosprivilegios que usted haya concedido previamente a otro usuario. Ese usuariopuede tener además privilegios que le fueron concedidos por otros usuarios; esos

A _ / / O/"l I-

privilegios no quedan afectados por la sentencia REVOKE que usted haya emitido.Observe específicamente que si dos usuarios diferentes conceden el mismo privi-legio sobre el mismo objeto a un usuario y uno de ellos posteriormente revoca elprivilegio, la concesión del segundo usuario seguirá permitiendo al usuarioacceder al objeto. Este manejo de «concesiones solapadas» de privilegios seilustra en la secuencia ejemplo siguiente:

Supongamos que Sam Clark, el vicepresidente de ventas, proporciona aLarry Fitch privilegios SELECT para la tabla REPVENTAS, y privilegios SELECT yÚRDATE para la tabla PEDIDOS, utilizando las sentencias siguientes:

GRANT SELECTON REPYENTASTO LARRY

GRANT SELECT, ÚRDATEON PEDIDOSTO LARRY

Unos pocos días más tarde George Watkins, el vicepresidente de marketing,proporciona a Larry los privilegios SELECT y DELETE para la tabla PEDIDOS, y elprivilegio SELECT para la tabla CLIENTES, utilizando estas sentencias:

GRANT SELECT, DELETEON PEDIDOSTO LARRY

GRANT SELECTON CLIENTESTO LARRY

Observe que Larry ha recibido privilegios sobre la tabla PEDIDOS desde dosfuentes diferentes. De hecho, el privilegio SELECT sobre la tabla PEDIDOS se le haconcedido por parte de ambas fuentes. Unos pocos días después, Sam revoca losprivilegios que previamente concedió a Larry para la tabla PEDIDOS:

KtVUFvt 3ELCU , UfUM 11

ON PEDIDOSFROM LARRY

Después que el DBMS procesa la sentencia REVOKE, Larry sigue reteniendo elprivilegio SELECT sobre la tabla REPVENTAS, los privilegios SELECT y DELETE sobre latabla PEDIDOS y el privilegio SELECT sobre la tabla CLIENTES, pero ha perdido elprivilegio UPDATE sobre la tabla PEDIDOS.

Seguridad SQL 371

do.ivi-aelirio> se

.a a:T y

eting,i, y el

íde dosse le ha/oca los

dendo elsobre la

REVOKE y la opción de concesión

Cuando se conceden privilegios con la opción de concesión y posteriormente serevocan esos privilegios, la mayoría de los productos DBMS revocarán automá-ticamente todos los privilegios derivados de la concesión original. Consideremosuna vez más ¡a cadena de privilegios de ia Figura Í5.6, que va de Sam Clark, elvicepresidente de ventas, a Larry Fitch, el director de la oficina de Los Angeles,y luego a Sue Smith. Si Sam revoca ahora los privilegios de Larry para la vistaREPOESTE, el privilegio de Sue es revocado automáticamente también.

Esta situación se complica más si dos o más usuarios tienen privilegiosconcedidos y uno de ellos posteriormente revoca los privilegios. Consideremosla Figura 15.8, una ligera variación del último. Aquí Larry recibe el privilegioSELECT con la opción de concesión de Sam (el vicepresidente de ventas) y George(el vicepresidente de marketing), y luego concede privilegios a Sue. Esta vezcuando Sam revoca los privilegios de Larry, la concesión de privilegios por partede George permanece. Además, los privilegios de Sue también permanecen, yaque pueden ser derivados de la concesión de George.

Sin embargo, consideremos otra variante sobre la cadena de privilegios conlos eventos ligeramente reordenados, como se muestra en la Figura 15.9. AquíLarry recibe el privilegio ctm la opción úc concesión por pane de Sam, concedeel privilegio a Sue y luego recibe la concesión, con la opción de concesión, porparte de George. Esta vez cuando Sam revoca los privilegios de Larry, losresultados son ligeramente diferentes, y pueden variar de un DBMS a otro.Como en la Figura 15.8, Larry tiene el privilegio SELECT sobre la vista REPOESTE,ya qe la concesión de George sigue intacta. Pero en una base de datos DB2 oSQL/DS, Sue perderá automáticamente su privilegio SELECT sobre la tabla. ¿Porqué? Porque la concesión de Larry a Sue se derivaba claramente de la concesiónde Sam a Larry, la cual acaba de ser revocada. No podría haberse derivado de laconcesión de George a Larry, ya que esa concesión no había tenido lugar auncuando se efectuó la concesión de Larry a Sue.

En un producto diferente de DBMS, los privilegios de Sue podrían permane-cer intactos, debido a que la concesión de George a Larry sigue intacta. Portanto la secuencia temporal de sentencias GRANT y REVOKE, y no tan solo losprivilegios, puede determinar lo lejos que los efectos de una sentencia REVOKE secontinúan en cascada. La concesión y revocación de privilegios con la opción deconcesión deben ser manejadas muy cuidadosamente, para asegurar que losresultados sean los que se pretenden.

REVOKE y el estándar ANSÍ/ISO

El estándar SQL ANSÍ/ISO especifica la sentencia G R A N T como parte del Len-guaje de Definición de Datos (DDL) de SQL. Recuerde del Capítulo 13 que el

372 Aoliaue SQL

GRANTWITH GR-ANTOPTION

GRANTWITHGRANTOPTION

SAM

GEORGE

JRR4NT

LARRY

SUE

Figura 15.8. Revocación de privilegios concedidos por dos usuarios.

estándar ANSÍ/ISO trata al DDL como una definición estática de una base dedatos, y no requiere que el DBMS permita modificaciones dinámicas a laestructura de la base de datos. Este planteamiento se aplica a la seguridad de labase de datos también. Bajo el estándar ANSÍ/ISO, la accesibilidad a tablas yvistas en ía base de datos se determina mediante una serie de sentencias GRANTincluidas en el esquema de la base de datos. No existe mecanismo para cambiarel esquema de seguridad una vez deñnida ía estructura de la base de datos. Lasentencia REVOKE está per tanto ausente de! estándar SQL ANSÍ/ISO, lo mismoque la sentencia DROP TABLE falta del estándar.

A pesar de su ausencia del estándar ANSÍ/ISO, la sentencia REVOKE es pro-porcionada por prácticamente todos los productos DBMS comerciales basadosen SQL. Al igual que con las sentencias DROP y ALTER, el dialecto DB2 de SQL seha establecido eíéctivameníe como el estándar para la sentencia REVOKE.

Ret

Ellebase

• El(aclao j

• Laqmde

• Lacoidos

• Lacor

•¿i

ase dei a laI de lablas y¡ GRANTimbiar:os. Lamismo

I

;s pro-asadosiQLse

Seguridad SQL 373

(I)GRANTUITH GRANTOPTION

(D GRANTWITHGRANTOPTION

Figura 15.9. Revocación de privilegios en una secuencia diferente.

Resumen

El lenguaje SQL sé utiliza para especificar las restricciones de seguridad en unabase de datos basada en SQL:

• El es'quema de seguridad de SQL está construido alrededor de privilegios(acciones permitidas) que pueden ser concedidos sobre objetos específicos dela base de datos (tales como tablas y vistas), a id-usuario específicos (usuarioso grupos de usuarios).

• Las vistas también juegan un papel esencial en la seguridad de SQL, puestoque pueden ser utilizadas para restringir acceso a filas o columnas específicasde una tabla.

• La sentencia GRANT se utiliza para conceder privilegios, los privilegios que ustedconcede a un usuario con la opción de concesión pueden a su vez ser concedi-dos por ese usuario a otros.

• La sentencia REVOKE se utiliza para revocar privilegios previamente concedidoscon la sentencia GRANT.