Introducción a la

Seguridad en BD

Base de Datos II
Ing. Marco Coral
Introducción a la Seguridad en BD

 Una base de datos (aspecto global de la seguridad

de los datos) es un conjunto de datos integrados,
adecuado a varios usuarios y a diferentes usos.
 Es el propio uso concurrente de los datos el que
plantea problemas de seguridad que el ABD debe
paliar en la medida de lo posible con las
funcionalidades que le proporciona el SGBD.
 La protección de los datos deberá llevarse a cabo
contra fallos físicos, fallos lógicos y fallos humanos
(intencionados o no). Estos fallos alteran
indebidamente los datos o los corrompen, con lo
que la BD ya no puede servir a los fines para los
que fue creada.
 El SGBD facilita normalmente mecanismos
para prevenir los fallos (subsistema de
control), para detectarlos una vez que se han
producido (subsistema de detección) y para
corregirlos después de haber sido detectados
(subsistema de recuperación).
Aspectos de seguridad

 Confidencialidad. No desvelar datos a

usuarios no autorizados. Comprende también
la privacidad (protección de datos
personales).
 Accesibilidad. La información debe estar
disponible.
 Integridad. Permite asegurar que los datos
no han sido falseados.
La seguridad de las BDs y el DBA
 Entre las obligaciones del DBA está otorgar privilegios a los
usuarios y clasificar los usuarios y los datos de acuerdo con la
política de la organización.
 El DBA tiene una cuenta privilegiada que confiere capacidades
extraordinarias no disponibles para las cuentas y usuarios
ordinarios de la BD.
 Las órdenes privilegiadas del DBA incluyen los siguientes tipos
de acciones:
 1. Creación de cuentas

 2. Concesión de privilegios.

 3. Revocación de privilegios.

 4. Asignación de niveles de seguridad.

 La acción 1 de la lista sirve para controlar el acceso al SGBD en

general, la 2 y la 3 para controlar las autorizaciones
discrecionales y la 4 controla la autorización obligatoria.
Controles informáticos

 Estos controles informáticos para la

seguridad incluyen:
 Autorizaciones
 Vistas
 Backup y recuperación
 Integridad
 Encriptado
 Procedimientos asociados
Confidencialidad
 En un SGBD existen diversos elementos que ayudan a controlar el acceso a los
datos. En primer lugar el sistema debe identificar y autenticar a los usuarios
utilizando alguno de las siguientes formas:
 código y contraseña
 identificación por hardware
 características bioantropométricas (huellas dactilares, voz, retina del ojo...)
 conocimientos, aptitudes y hábitos del usuario
 información predefinida
 Además, el DBA deberá especificar los privilegios que un usuario tiene sobre
los objetos de la BD:
 utilizar una BD
 consultar ciertos datos
 actualizar datos
 los SGBD suelen incorporar el concepto de perfil, rol o grupo de usuarios que
agrupa una serie de privilegios por lo que el usuario que se asigna a un grupo
hereda todos los privilegios del grupo.
Confidencialidad en SQL
 Los privilegios en el nivel de cuenta pueden incluir los siguientes privilegios:
 CREATE SCHEMA, CREATE TABLE, CREATE VIEW, ALTER, DROP, MODIFY,
SELECT.
 Los privilegios del segundo tipo se aplican a las relaciones individuales:
 SELECT, MODIFY, REFERENCES.
 Para conceder privilegios se emplea:
<sentencia de concesi ón>::=
GRANT <privilegios> ON <nombre de objeto>
TO <concedido> [<coma><concedido>...]
[WITH GRANT OPTION]
<lista de acci ón>::=
SELECT
| DELETE
| INSERT [<parent. izq.><lista de columnas><parent. dcho.>]
| UPDATE [<parent. izq.><lista de columnas><parent. dcho.>]
| REFERENCES [<parent. izq.><lista de columnas><parent. dcho.>]
| USAGE
 Por otra parte, para revocar privilegios se emplea:

<sentencia de revocación>::=
REVOKE [GRANT OPTION FOR]
<privilegios>
ON <nombre de objeto>
FROM <concedido> [{<coma><concedido>...}]<comportamiento de
borrado>
<comportamiento de borrado>::=
CASCADE
| RESTRICT

 RESTRICT no dejará revocar privilegios que hayan sido

concedidos a otros usuarios, mientras que si empleamos la
opción en cascada, se borrarán todos los privilegios.
Disponibilidad

 Los SBDs deben asegurar la disponibilidad de los

datos a aquellos usuarios que tienen derecho a ello
por lo que proporcionan mecanismos que permiten
recuperar la BD contra fallos lógicos o físicos que
destruyan los datos en todo o en parte.
 En lo que se refiere al SGBD existen dos tipos
importante de fallos:
 Los que provocan la perdida de memoria volátil, debidos a
interrupción del suministro eléctrico o por funcionamiento
anormal del hw.
 Los que provocan la pérdida del contenido de memoria
secundaria.
Transacción
 Una transacción puede terminar de dos formas diferentes:
 Con éxito, en cuyo caso las actualizaciones de que consta la transacción se
graban (commit)
 Con fracaso, en cuyo caso debe ser restaurado el estado inicial en el que se
encontrada la BD antes de que empezara a ejecutarse la transacción. Las
actualizaciones de que consta la transacción deberán, por tanto, deshacerse
(rollback)
 Los principales componentes del SGBD que se
encargan de la gestión y recuperación de las
transacciones son:
 Gestor de transacciones, que coordina las transacciones para los programas de
aplicación.
 Planificador (scheduler), responsable de llevar a cabo el control de concurrencia.
 Gestor de recuperación, que asegura que la BD queda consistente después de
algún fallo.
 Gestor de memoria intermedia (caché/buffer), que se ocupa de la transferencia
de los datos de memoria volátil (tanto de la BD como de los relativos a la
recuperación) a disco y viceversa.
Ficheros diarios
 Para conseguir anular y recuperar transacciones, el método más
extendido suele ser la utilización de un fichero denominado diario
(log o journal) en el que se va guardando toda la información
necesaria para deshacer -en caso de fracasar- o rehacer -si hay
que recuperar- las transacciones.
 Un registro del fichero diario suele constar de:
 identificador de la transacción

 hora de la modificación

 identificador del registro afectado

 tipo de acción

 valor anterior del registro

 nuevo valor del registro

 información adicional (por ejemplo, un puntero al registro previo

del diario que concierne a la misma transacción)
 El fichero diario puede ser un fichero circular,
es decir, que una vez lleno va eliminando
registros según van entrando otros nuevos,
aunque lo normal es que conste de dos
partes; la primera en-línea (en disco), que
almacena las actualizaciones que se llevan a
cabo hasta que se llena, momento en el que
se pasa el contenido a la segunda parte (por
ejemplo, en cinta u otra lugar en el HD).
 SQL soporta las transacciones clásicas
mediante las sentencias COMMIT y
ROLLBACK.
 Las transacciones se inician al empezar los
programas o al ejecutar sentencias de
definición o manipulación.
Integridad Integridad

 El objetivo en cuanto a la integridad es proteger la

BD contra operaciones que introduzcan
inconsistencias en los datos, por eso se habla de
integridad en el sentido de corrección, validez o
precisión de los datos de la BD.
 El subsistema de integridad de un SGBD debe, por
tanto, detectar y corregir en la medida de lo posible
las operaciones incorrectas.
 Existen dos tipos de operaciones que pueden
atentar contra la integridad de los datos que son las
operaciones semánticamente inconsistentes y las
interferencias debidas a accesos concurrentes.
Niveles de seguridad:

 Seguridad de cuentas para la validación de

usuarios.
 Seguridad en el acceso a los objetos de la
base de datos.
 Seguridad a nivel de sistema para la gestión
de privilegios globales.
Seguridad de Cuentas

 Para acceder a los datos en una BD Oracle, se debe

tener acceso a una cuenta en esa BD. Cada cuenta
debe tener una palabra clave o password asociada. Una
cuenta en una BD puede estár ligada con una cuenta de
sistema operativo. Los passwords son fijados cuando se
crea un usuario y pueden ser alterados por el DBA o por
el usuario mismo. La BD almacena una versión
encriptada del password en una tabla del diccionario
llamada dba_users. Si la cuenta en la BD está asociada
a una cuenta del sistema operativo puede evitarse la
comprobación del password, dándose por válida la
comprobación de la identidad del usuario realizada por
el SO.
Creación de Usuarios
Parámetro Significado
Username Nombre del Usuario (Esquema)
Palabra clave de la cuenta. Puede ser
Password asociada directamente a una cuenta
del sistema operativo.
Espacio de tablas por defecto en el que
los objetos de este usuario serán
Default Tablespace
creados. Esto no da al usuario
derechos de crear objetos.
El espacio de tablas en el que se
Temporary Tablespace almacenarán los segmentos
temporales de las ordenaciones.
Espacio máximo que puede ocupar en
Quota
un espacio de tablas.
Asigna un perfil al usuario. Los perfiles
Profile se utilizan para restringir el uso de
recursos como el tiempo de CPU.
1> create user perez
2> identified by zerep
3> default tablespace users
4> temporary tablespace temp;

Eliminación
1> drop user perez cascade;
 Si a continuación se crea otro usuario con el mismo
nombre no hereda los objetos del anterior usuario con
ese nombre.
 La razón estriba en que Oracle asigna a cada cuenta un
número además del nombre, y utiliza ese número para
determinar el propietario de todos los objetos que crea
esa cuenta, y no utiliza el nombre sino para la
comunicación con los usuarios. De este modo al crear
un nuevo usuario, aunque sea con el mismo nombre, no
puede heredar los objetos que antes eran de otro
usuario con el mismo nombre.
Seguridad de Objetos

 El acceso a los objetos de la BD se realiza via

privilegios. Estos permiten que determinados comandos
sean utilizados contra determinados objetos de la BD.
Esto se especifica con el comando GRANT, conceder.
Los privilegios se pueden agrupar formando lo que se
conoce por roles. La utilización de los roles simplifica la
administración de los privilegios cuando tenemos
muchos usuarios. Los roles pueden ser protegidos con
passwords, y pueden activarse y desactivarse
dinámicamente, con lo que constituyen una capa más de
seguridad en el sistema.
Roles del Sistema

 Los roles se pueden utilizar para gestionar los

comandos de sistema disponibles para los usuarios.
Estos incluyen comandos como CREATE TABLE o
SELECT ANY TABLE. Todos los usuarios que quieran
acceder a la BD deben tener el rol CONNECT; aquellos
que necesiten crear segmentos necesitaran el rol
RESOURCE. Un usuario con el rol DBA tiene derecho
para ver y manejar todos los datos de la BD. En Oracle
CONNECT, RESOURCE y DBA son roles de sistema.
Las acciones contra cada tipo de objeto son autorizadas
por privilegios separados. Así, un usuario puede tener
concedido el privilegio CREATE TABLE, pero no el
ALTER TABLE.
Privilegio Capacidades
Manejo de Objetos ...
CREATE ANY INDEX Crear cualquier índice.
CREATE [PUBLIC] SYNONYM Crear sinónimos [públicos].
Crear tablas. El usuario debe tener cuota
en el espacio de tablas, o ha de tener
CREATE [ANY] TABLE
asignado el privilegio UNLIMITED
TABLESPACE.
CREATE [ANY] VIEW Crear vistas.
ALTER ANY INDEX Alterar cualquier índice.
ALTER ANY TABLE Alterar cualquier tabla
DROP ANY INDEX Borrar cualquier índice.
DROP ANY SYNONYM Borrar cualquier sinónimo.
DROP PUBLIC SYNONYM Borrar sinónimos públicos.
DROP ANY VIEW Borrar cualquier vista.
DROP ANY TABLE Borrar cualquier tabla.
Efectuar selecciones de cualquier tabla o
SELECT ANY TABLE
vista.
INSERT ANY TABLE Insertar en cualquier tabla o vista.
Borrar filas de cualquier tabla o vista, y
DELETE ANY TABLE
también truncar.
ALTER SESSION Alterar los parámetros de la sesión.
CREATE SESSION Conectarse a la BD.
Gestión de la BD ...
CREATE PROFILE Crear perfiles de usuario.
CREATE ROLE Crear roles.
CREATE ROLLBACK SEGMENT Creación de segmentos de rollback.
CREATE TABLESPACE Crear espacios de tablas.
CREATE USER Crear usuarios.
ALTER PROFILE Alterar perfiles existentes.
ALTER ANY ROLE Alterar cualquier rol.
ALTER ROLLBACK SEGMENT Alterar segmentos de rollback.
ALTER TABLESPACE Alterar espacios de tablas.
ALTER USER Alterar usuarios.
DROP PROFILE Borrar un perfil existente.
DROP ANY ROLE Borrar cualquier rol.
DROP ROLLBACK SEGMENT Borrar un segmento de rollback existente.
DROP TABLESPACE Borrar un espacio de tablas.
Borrar un usuario. Añadir CASCADE si el
DROP USER
usuario posee objetos.
ALTER DATABASE Permite una sentencia ALTER DATABASE.
GRANT ANY PRIVILEGE Otorgar cualquiera de estos privilegios.
GRANT ANY ROLE Otorgar cualquier rol a un usario.
Puede usar una cantidad de almacenamiento
UNLIMITED TABLESPACE
ilimitada.
DROP PROFILE Borrar un perfil existente.
 Los privilegios se pueden agrupar en roles, para así
satisfacer a distintos tipos de usuarios. En la instalación
se crea un rol llamado OSOPER que sirve para los
operarios de la máquina donde está la BD y permite
realizar copias de seguridad en frio y en caliente. Los
privilegios de OSOPER son STARTUP, SHUTDOWN,
ALTER DATABASE OPEN/MOUNT, ALTER DATABASE
BACKUP, ARCHIVE LOG, RECOVER y RESTRICTED
SESSION.
 Se pueden crear nuevos roles. Por ejemplo, podemos
crear un rol llamado creadorCuentas que sólo pueda
crear usuarios y no pueda realizar ninguna otra
operación de DBA. Las sentencias que permiten hacer
esto son las siguientes:
> create role creadorCuentas;

> grant create session, create user to creadorCuentas;

Rol Privilegios
alter session, create session, create cluster,
CONNECT create table, create view, create synonym,
create sequence, create database link
create cluster, create table, create procedure,
RESOURCE
create sequence, create trigger
todos los privilegios de sistema con la opcion
DBA
with admin option
Perfiles de Usuario

 Los perfiles se utilizan para limitar la cantidad de

recursos del sistema y de la BD disponibles para un
usuario. Si no se definen perfiles para un usuario se
utiliza el perfil por defecto, que especifica recursos
ilimitados.
 Los perfiles se pueden crear via el comando CREATE
PROFILE, y se pueden modificar con la sentencia
ALTER PROFILE.
 En general, el perfil por defecto debe ser adecuado para
los usuarios normales; los usuarios con requerimientos
especiales deberían tener perfiles especiales
Recurso Descripción
El número de sesiones concurrentes que un usuario
SESSIONES_PER_USER
puede tener en una instancia.
El tiempo de CPU, en centenas de segundos, que
CPU_PER_SESSION
una sesión puede utilizar.
El número de minutos que una sesión puede
CONNECT_TIME
permanecer activa.
El número de minutos que una sesión puede
IDLE_TIME
permanecer sin que sea utilizada de manera activa.
El número de bloques de datos que se pueden leer
LOGICAL_READS_PER_SESSION
en una sesión.
El número de bloques de datos que se pueden leer
LOGICAL_READS_PER_CALL
en una operación.
La cantidad de espacio privado que una sesión
PRIVATE_SGA puede reservar en la zona de SQL compartido de la
SGA.
El número de total de recursos por sesión, en
unidades de servicio. Esto resulta de un calculo
ponderado de CPU_PER_SESSION,
COMPOSITE_LIMIT CONNECT_TIME,
LOGICAL_READS_PER_SESSION y
PRIVATE_SGA, cuyos pesos se pueden variar con el
comando ALTER RESOURCE COST.
Gestionando Privilegios

 Los privilegios dan acceso a los usuarios a los datos que

no poseen. Los roles con grupos de privilegios que
facilitan la administración de los privilegios. Pero los
privilegios se pueden manejar de manera explícita en
algunas circunstancias.
 Los privilegios se crean via el comando GRANT y son
registrados en el diccionario de datos.
 Los privilegios que pueden otorgarse sobre objetos son
los siguientes:
Privilegio Capacidades Otorgadas
SELECT Puede consultar a un objeto.
Puede insertar filas en una tabla o vista. Puede
INSERT especificarse las columnas donde se permite
insertar dentro de la tabla o vista.

Puede actualizar filas en una tabla o vista. Puede

UPDATE especificarse las columnas donde se permite
actualizar dentro de la tabla o vista.

DELETE Puede borrar filas dentro de la tabla o vista.

ALTER Puede alterar la tabla.

INDEX Puede crear índices de una tabla.
Puede crear claves ajenas que referencie a esta
REFERENCES
tabla.
Puede ejecutar un procedimieto, paquete o
EXECUTE
función.
 Haciendo un privilegio PUBLIC lo hace disponible a
todos los usuarios de la BD.
 Aunque los privilegios se puedan otorgar
individualmente, no resulta razonable basar la gestión
de los privilegios en su asignación individual. La gestión
de los privilegios se facilita con la utilización de los roles.
A continuación se puede ver como se crean dos roles, el
rol ALUMNOS que permite establecer una sesión, y el
rol INSERTA_PEREZ que permite insertar y seleccionar
en la tabla emp de perez:
> create role alumnos;
> grant create session to alumnos;
> create role inserta_perez;
> grant select, insert on perez.employees to inserta_perez;
> grant usuarios to inserta_perez;

Los roles pueden asignarse a los usuarios. Así, podemos asignar el rol
INSERTA_PEREZ al usuario alu20:

> grant inserta_perez to alu20;

Los roles se pueden denegar con el comando REVOKE.

Vista Contenidos
Nombres de los roles y su estado del
DBA_ROLES
password.
Usuarios a los que han sido otorgados
DBA_ROLES_PRIVS
roles.
Usuarios a los que han sido otorgados
DBA_SYS_PRIVS
privilegios del sistema.
Usuarios a los que han sido otorgados
DBA_TAB_PRIVS
privilegios sobre objetos.
Usuarios a los que han sido otorgados
DBA_COL_PRIVS
privilegios sobre columnas de tablas.
Roles que han sido otorgados a otros
ROLE_ROLE_PRIVS
roles.
Privilegios de sistema que han sido
ROLE_SYS_PRIVS
otorgados a roles.
Privilegios de tabla que han sido
ROLE_TAB_PRIVS
otorgados a roles.
Auditoría de Seguridad

 El SGBD Oracle tienen la capacidad de

auditar todas las acciones que tienen lugar
en la BD. Se pueden auditar tres tipos de
acciones:
 intentos de entrada en cuentas de la BD.
 accesos a los objetos de la BD.
 acciones sobre la BD.
 La BD registra todos los intentos de acción, tanto los
exitosos como los infructuosos, aunque es un parámetro
configurable.
 Para habilitar la capacidad de auditoría, se debe fijar el
parámetro AUDIT_TRAIL en el fichero init.ora. Los
registros de auditoría se almacenan en la tabla
SYS.AUD$ o bien su gestión se deja al SO.
 Cuando se decide utilizar la tabla SYS.AUD$ esta debe
revisarse periódicamente, por si hiciera falta truncarla
debido a que su aumento de tamaño puede causar
problemas de espacio en el tablespace SYSTEM. Los
valores del parámetro AUDIT_TRAIL son los que se
exponen en la siguiente tabla:
Valor Descripción
NONE Deshabilita la auditoría
Habilita la auditoría, escribiendo en la
BD
tabla SYS.AUD$.
Habilita la auditoría, dejando al SO su
OS
gestión.
 Auditando Conexiones
> audit session;
 Para determinar si se deben registrar sólo los éxitos, o
sólo los fracasos se pueden utilizar los siguientes
comandos:
audit session whenever successful;
> audit session whenever not successful;

Si los registros de auditoría se almacenan en la tabla

SYS.AUD$, entonces pueden verse a través de la vista
DBA_AUDIT_SESSION.
select os_username, /* nombre de usuario SO */
username, /* nombre de usuario BD */
terminal,
decode (returncode,'0','Conectado', '1005','Solo username, sin
password', '1017','Password incorrecto',
returncode), /* comprobacion de error */
to_char(timestamp,'DD-MON-YY HH24:MI:SS'), /* hora de entrada */
to_char(logoff_time,'DD-MON-YY HH24:MI:SS') /* hora de salida */
from dba_audit_session;

Para deshabilitar la auditoria de las conexiones basta con ejecutar la

siguiente sentencia:
> noaudit session;
Grupo Comandos Auditados
CLUSTER Todas las sentencias que afecten a clusters.
DATABASE LINK Todas las sentencias que afecten a enlaces de BD.
Todas las sentencias que fallen porque ya existe un
EXISTS
objeto en la BD.
INDEX Todas las sentencias que afecten a índices.
Todas las sentencias que fallen porque un
NOT EXISTS
determinado objeto no existe.
PROCEDURE Todas las sentencias que afecten a procedimientos.
PROFILE Todas las sentencias que afecten a perfiles.
Todas las sentencias que afecten a enlaces públicos
PUBLIC DATABASE LINK
de BD.
Todas las sentencias que afecten a sinónimos
PUBLIC SINONYM
públicos.
ROLE Todas las sentencias que afecten a roles.
Todas las sentencias que afecten a segmentos de
ROLLBACK SEGMENT
rollback.
SEQUENCE Todas las sentencias que afecten a secuencias.
SESSION Todas las sentencias de acceso a la BD.
SYNONYM Todas las sentencias que afecten a sinónimos.
SYSTEM AUDIT Todas las sentencias AUDIT y NOAUDIT.
SYSTEM GRANT Todas las sentencias afecten a privilegios.
SYSTEM AUDIT Todas las sentencias AUDIT y NOAUDIT.
SYSTEM GRANT Todas las sentencias afecten a privilegios.
TABLE Todas las sentencias que afecten a tablas.
Todas las sentencias que afecten a espacios de
TABLESPACE
tablas.
TRIGGER Todas las sentencias que afecten a disparadores.
Todas las sentencias que afecten a las cuentas de
USER
usuarios.
VIEW Todas las sentencias que afecten a vistas.
Auditando tablas
Por ejemplo, para auditar todas acciones que tienen que
ver con las tablas sirve el siguiente comando:
> audit table;
Y para deshabilitar la auditoría se utilizará el siguiente
comando:
> noaudit table;
También se puede afinar un poco más en la auditoría
fijando un usuario concreto al que seguir la pista:
> audit table by perez;
Cada acción auditada recibe un código numérico al que se
puede acceder a través de la vista AUDIT_ACTIONS. Una
vez que conocemos el código de la acción, podemos
utilizarlo para determinar como dicha acción ha afectado a
un objeto, consultado la vista DBA_AUDIT_OBJECT.
Auditando Objetos
 Además de la auditoría de acciones sobre los objetos,
se puede seguir el rastro a las operaciones de
manipulación de tablas: SELECT, INSERT, UPDATE y
DELETE. Estas auditorías se pueden hacer por sesión o
por acceso.
> audit insert on perez.emp;
> audit all on perez.emp by session;
> audit delete on perez.emp by access;

 Los registros de auditoría se pueden ver en la misma

vista DBA_AUDIT_OBJECT anteriormente mencionada.
Protegiendo los Registros de Auditoría

 Los registros de la tabla SYS.AUD$ pueden ser objeto de

intentos de acceso para ser eliminados ya que pueden
reflejar acciones no autorizadas en la BD. Así, resulta
interesante reflejar ese tipo de acciones. Esto se consigue
con el siguiente comando:
> audit all on sys.aud$ by access;

De este modo cualquier acción contra la tabla SYS.AUD$

quedará registrado.

¿ Que usuarios y como pueden borrar los registros de la tabla

SYS.AUD$ ?