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.
Top Related