2. Mecanismos de seguridad
El sistema de
base de
datos ORACLE
provee control de acceso discrecional, el cual es un
medio de restricción de acceso basado en privilegios.
Para que un usuario pueda acceder a un objeto, se le deben
otorgar los privilegios apropiados. Los usuarios
con los privilegios adecuados pueden otorgar privilegios a
otros usuarios a su criterio. Por esta
razón, este tipo de seguridad es
llamada "discrecional".
Oracle administra la seguridad de la base de datos
utilizando diferentes servicios o
facilidades:
- Usuarios y esquemas
- Privilegios
- Roles
- Configuración del almacenamiento y quotas
- Límites a los recursos
- Monitoreo
2.1 – Usuarios y esquemas
Cada base de datos tiene una lista de nombres de
usuarios. Para acceder a la base de datos, un usuario debe usar
una aplicación e intentar entablar una conexión
con un nombre de usuario válido de la base de datos.
Cada usuario tiene una clave de acceso asociada para prevenir
el uso no autorizado.
- Dominio de Seguridad
Cada usuario tiene un dominio de
seguridad, un conjunto de propiedades que determinan factores
como:
- Acciones (privilegios y roles) disponibles para el
usuario. - Límites de espacio en el Tablespace para los
usuarios. - Límites de utilización de los
recursos
del sistema para los usuarios.
2.2 – Privilegios
Un privilegio es un permiso para ejecutar un tipo
particular se sentencias SQL.
Los privilegios de una base de datos ORACLE pueden ser
divididos en dos categorías distintas: Privilegios de
sistema y Privilegios de objetos.
2.2.1 Privilegios de sistema
Los Privilegios de sistema permiten a los usuarios
desempeñar una acción particular dentro del sistema o
una acción particular sobre un tipo determinado de
objeto. Por ejemplo, el privilegio para crear un tablespace o
para borrar filas de una tabla en la base de datos son
privilegios de sistema. Muchos privilegios de sistema
están disponibles solamente para administradores y
desarrolladores de aplicaciones porque estos privilegios son
muy poderosos.
2.2.2 Privilegios de objetos
Los privilegios de objetos permiten a los usuarios
desempeñar acciones
sobre un esquema específico. Por ejemplo, el privilegio
para borrar filas de una tabla específica es un
privilegio de objetos. Los privilegios de objetos son asignados
a usuarios finales, entonces ellos pueden usar una
aplicación de la base de datos para llevar a cabo tareas
específicas.
2.2.3 Asignar privilegios
Un usuario puede recibir un privilegio de dos formas
distintas:
- Los privilegios pueden ser asignados a los usuarios
explícitamente. - Los privilegios pueden ser asignados a roles
(grupo de
privilegios), y después el rol puede ser signado a uno
o más usuarios.
Debido a que los roles permiten una mejor y más
fácil administración de los privilegios,
éstos normalmente son asignados a roles y no a usuarios
específicos.
2.3 – Roles
ORACLE provee los roles para una administración más fácil y
controlada de los privilegios. Los roles son un grupo con
nombre de privilegios, que son asignados a usuarios o a otros
roles. Las siguientes propiedades de los roles permiten
administrar los privilegios de una manera más
fácil:
- Reducida asignación de
privilegios: En lugar de otorgar
explícitamente el mismo conjunto de privilegios a
muchos usuarios el administrador
de la base de datos puede asignar los privilegios a un rol y
éste a un grupo de usuarios. - Administración dinámica de los privilegios:
Cuando los privilegios de un grupo deben cambiar, sólo
los privilegios del rol necesitan ser modificados. Los
dominios de seguridad de todos los usuarios a los que
asignó dicho rol, reflejarán
automáticamente los cambios hechos en el
rol. - Selectiva disponibilidad de los
privilegios: Los roles asignados a los usuarios
pueden ser selectivamente activados o desactivados. Esto
permite control
específico de los privilegios de los usuarios en
cualquier situación. - Consciencia de aplicación: Una
aplicación de la base de datos puede ser
diseñada para habilitar o inhabilitar roles
automáticamente cuando un usuario intenta usar la
aplicación.
2.4 – Configuración del almacenamiento y
quotas
ORACLE provee medios para
limitar el uso del espacio de disco asignado a la base de
datos, de acuerdo a cada usuario; incluyendo los default
tablespaces, temporary tablespaces y los tablespaces
quotas.
Cada usuario es asociado a un default tablespace.
Cuando un usuario crea una tabla, índice, o cluster
y no se especifica ningún tablespace que contenga
físicamente al objeto, el default tablespace es
utilizado si el usuario tiene privilegio para crear el
objeto.- Default Tablespace
Cada usuario tiene un temporary tablespace. Cuando
un usuario ejecuta una sentencia SQL que requiere la
creación de objetos temporarios (por ejemplo un
índice), se usa el temporary tablespace del
usuario. - Temporay Tablespace
- Tablespace Quotas
ORACLE puede limitar el espacio disponible de disco
colectivo. Las quotas (límites
de espacio) pueden ser configuradas para cada tablespace
disponible para un usuario. Las tablespace quotas permiten un
control selectivo sobre el espacio en disco que es consumido
por cada objeto de cada esquema.
2.5 – Límites a los recursos
A cada usuario le es asignado un perfil que especifica
las limitaciones sobre varios recursos del sistema disponibles
para el usuario, incluyendo:
– disponible para la sesión del
usuario
- disponible para una simple llamada a ORACLE
realizada por una sentencia SQL.
- Cantidad de I/O:
– disponible para la sesión del
usuario
– disponible para una simple llamada a ORACLE
realizada
por una sentencia SQL.
- La cantidad de tiempo ocioso permitido para la
sesión del usuario. - La cantidad de tiempo de conexión permitido
para la sesión del usuario. - Restricciones en las passwords:
- Bloqueo de la cuenta después de una
determinada cantidad de intentos de conexión
fallidos - Expiración de las passwords y período
de gracia. - Reutilización de passwords y
restricciones.
Se pueden crear diferentes perfiles y asignarse
individualmente a cada usuario de la base de datos. A los
usuarios que no se le ha asignado explícitamente un
perfil, se le asigna el perfil por default. El límite
en la utilización de recursos previene el consumo
excesivo de los recursos globales del sistema de base de
datos.
2.6 – Monitoreo
ORACLE permite realizar un monitoreo selectivo de
las acciones de los usuarios para ayudar en la investigación de usos maliciosos de la
base de datos. El monitoreo puede realizarse a tres niveles
distintos:
- Monitoreo de sentencias: Es el
monitoreo de sentencias SQL específicas sin atender
concretamente a los objetos. Este tipo de monitoreo puede
hacerse para todos los usuarios del sistema o se puede
enfocar sólo a algunos usuarios
seleccionados. - Monitoreo de privilegios: Es el
monitoreo de los privilegios del sistema sin atender
concretamente a los objetos. Este tipo de monitoreo puede
hacerse para todos los usuarios del sistema o se puede
enfocar sólo a algunos usuarios
seleccionados. - Monitoreo de objetos: Es el monitoreo
de los accesos a esquemas específicos sin considerar
el usuario. Monitorea las sentencias permitidas por los
privilegios.
Para todos los tipos de monitoreo, ORACLE permite el
monitoreo selectivo de sentencias ejecutadas con éxito, sentencias ejecutadas sin
éxito o ambas.
Los resultados del monitoreo son registrados en una
tabla llamada "the audit trail" (la pista de auditoría).
3. Políticas de Seguridad
Este capítulo provee una guía para el
desarrollo
de políticas de seguridad para operaciones de
bases de datos,
e incluye los siguientes temas:
- Política de Seguridad del
Sistema - Política de Seguridad de la
Información - Política de Seguridad del
Usuario - Política Administrativa de
Passwords - Política de Auditoría
3.1 – Política de
Seguridad del sistema
Esta sección describe aspectos de la
política de seguridad de sistemas e
incluye los siguientes temas:
- Administración de usuarios de base de
datos - Autentificación de usuarios
- Seguridad de Sistemas Operativos
Cada base de datos tiene uno o más
administradores de seguridad quienes son responsables del
mantenimiento de todos los aspectos de la
política de seguridad. Si el sistema de bases de datos
es pequeño, el administrador de bases de datos
podría tener las responsabilidades del administrador de
seguridad. Sin embargo, si el sistema de bases de datos es
grande, una persona o
grupos de
personas especiales podrían tener responsabilidades
limitadas de aquellas que corresponden a un administrador de
seguridad.
Luego de decidir quien administrará la
seguridad del sistema, se debe desarrollar una política
de seguridad para cada base de datos. Una política de
seguridad de base de datos debería incluir muchas
sub-políticas, como se explica en las siguientes
secciones.
3.1.1 Mantenimiento de usuarios de bases de
datos
La seguridad debería ser mantenida por el
mantenimiento de los usuarios de bases de datos. Dependiendo
del tamaño de un sistema de bases de datos y de la
cantidad del trabajo
requerido para administrar los usuarios de bases de datos, el
administrador de seguridad debería ser el único
usuario con los privilegios requeridos para crear, alterar o
borrar un usuario de base de datos. Por otro lado,
debería haber un número de administradores con
privilegios para administrar los usuarios de bases de datos.
Solo personas que gozan de confianza deberían tener
privilegios totales para administrar los usuarios de bases de
datos.
3.1.2 Autentificación de
usuarios
Los usuarios de bases de datos pueden ser
autentificados (verificados como una persona correcta) por
Oracle usando el sistema
operativo de host, los servicios de red, o la base de datos.
Generalmente la autentificación de usuarios vía
un sistema operativo host es preferida por las siguientes
razones:
- Los usuarios pueden conectarse a Oracle más
rápido y más convenientemente sin especificar
nombre de usuario y contraseña. - Control centralizado sobre la autorización
de usuarios en el sistema operativo: Oracle no necesita
almacenar o administrar los nombres de usuario y
contraseñas si el sistema operativo y la base de datos
se corresponden - Las entradas de los usuarios en los audit
trails de la base de datos y el sistema operativo se
corresponden
La autentificación de usuarios por la base de
datos es normalmente utilizada cuando el sistema operativo no
puede soportar la autentificación de
usuarios.
3.1.3 Seguridad de Sistemas
Operativos
Si es apropiado, los siguientes temas de seguridad
deben ser considerados no sólo para un entorno de
sistema operativo ejecutando Oracle sino también
cualquier aplicación de bases de datos:
- Los administradores de bases de datos deben tener
los privilegios del sistema operativo para crear o eliminar
archivos. - Los usuarios típicos de bases de datos no
deberían tener los privilegios del sistema operativo
para crear o eliminar archivos relacionados a la base de
datos. - Si el sistema operativo identifica el rol de bases
de datos para los usuarios, los administradores de seguridad
deben tener los privilegios del sistema operativo para
modificar el dominio de seguridad de las cuentas
del sistema operativo.
3.2 – Política de Seguridad de la
Información
La seguridad de datos incluye los mecanismos que
controlan el acceso y el uso de la base de datos en el nivel de
objeto. Su política de seguridad de datos determina que
usuarios tienen acceso a objetos de esquema específicos,
y los tipos específicos de acciones permitidos para cada
usuario sobre el objeto. También debería definir
las acciones, para cualquiera, que sea auditado para cada
objeto de esquema.
De cualquier forma, la seguridad de los datos
debería estar basada sobre la sensibilidad de los datos.
Si la información no es sensible, entonces la
política de seguridad de datos puede ser mas flexible.
Sin embargo, si los datos son sensibles, una política de
seguridad debe ser desarrollada para mantener un fuerte control
sobre el acceso a los objetos.
3.3 – Política de Seguridad de
Usuarios
Esta sección describe los aspectos de una
política de seguridad de usuarios e incluye los
siguientes temas:
- Seguridad del Usuario General
- Seguridad de Usuario-Final
- Seguridad de Administrador
- Seguridad de Desarrollador de
Aplicaciones - Seguridad de Administrador de
Aplicaciones
3.3.1 Seguridad del Usuario
General
Para todos los tipos de usuarios de base de datos,
considere los siguientes temas de seguridad de usuario
general:
- Seguridad por contraseña
- Administración de privilegios
3.3.1.1 Seguridad por
contraseña
Si la autentificación de usuarios es
administrada por la base de datos, los administradores de
seguridad deberían desarrollar una política de
seguridad por contraseña para mantener la seguridad de
acceso a la base de datos. Por ejemplo, los usuarios de base
de datos deberían ser advertidos de cambiar su
contraseña cada cierto período regular, y por
supuesto, cuando sus contraseñas son reveladas a
otros. Forzando a un usuario a modificar su contraseña
en tales situaciones, los accesos a bases de datos sin
autorización pueden ser reducidos.
Para proteger mejor la confidencialidad de su
contraseña, Oracle puede ser configurado para utilizar
contraseñas encriptadas para conexiones cliente/servidor y
servidor/servidor.
3.3.1.2 Administración de
privilegios
Los administradores de seguridad deben considerar
los temas relacionados a la
administración de privilegios para todos los tipos
de usuarios. Por ejemplo, en una base de datos con muchos
usuarios, podría ser beneficioso utilizar roles para
administrar los privilegios disponibles a usuarios. Por otro
lado, en una base de datos con un número de usuarios
reducido, podría ser mas fácil otorgar
privilegios explícitamente a los usuarios y anular el
uso de roles.
Los administradores de seguridad que administran una
base de datos con muchos usuarios, aplicaciones u objetos
deberían tomar ventaja de los beneficios ofrecidos por
los roles. Los roles simplifican en gran medida la tarea de
la administración de privilegios en entornos
complejos.
3.3.2 Seguridad de
Usuario-Final
Los administradores de la seguridad deben definir
también una política para la seguridad de
usuario-final. Si una base de datos es grande y con muchos
usuarios, el administrador de seguridad puede decidir que
grupos de usuarios pueden ser categorizados, crear roles de
usuarios para esos grupos de usuarios, otorgar los
privilegios necesarios o roles de aplicación para cada
rol de usuario, y asignar los roles de usuarios a los
usuarios. En excepciones, el administrador de seguridad debe
también decidir que privilegios deben ser
explícitamente otorgados a usuarios
individuales.
Cuando es posible, utilizar roles en todas las
situaciones posibles para crear privilegios usuario-final
hacen su administración eficiente y simple.
3.3.3 Seguridad de
Administrador
Los administradores de seguridad deben tener una
política de seguridad de administrador. Por ejemplo,
cuando es una gran base de datos y existen diversos tipos de
administradores de base de datos, el administrador de
seguridad debe decidir como agrupar los privilegios
administrativos relacionados a los diversos roles
administrativos.
Los roles administrativos pueden entonces ser
otorgados a los usuarios administradores apropiados. Por otro
lado, cuando la base de datos es pequeña y tiene pocos
administradores puede ser más conveniente crear un rol
administrativo y otorgarlo a todos los
administradores.
3.3.3.1 Protección para conexiones SYS y
SYSTEM
Luego de la creación de la base de datos,
inmediatamente cambie la contraseña para los
nombres de usuario administrativos SYS y SYSTEM para prevenir
accesos no autorizados a la base de datos. Conectarse como
SYS y SYSTEM da al usuario todos los privilegios para
modificar la base de datos de distintas formas. Por lo tanto,
los privilegios para estos nombres de usuario son
extremadamente sensibles,y deben estar disponibles
sólo para los administradores de bases de datos
seleccionados.
3.3.3.2 Protección para conexiones
Administrador
Sólo los administradores de bases de datos
deben tener la capacidad para conectarse a la base de datos
con los privilegios de administrador. Conectarse como SYSDBA
da al usuario privilegios sin restricción para hacer
cualquier cosa sobre la base de datos (tales como encender,
apagar y recuperar) o los objetos dentro de la base de datos
(tales como crear, eliminar, y borrar).
3.3.4 Seguridad de Desarrollador de
Aplicaciones
Los administradores de seguridad deben definir una
política especial de seguridad para los
desarrolladores de aplicaciones que usen base de datos. Un
administrador de seguridad solo puede otorgar privilegios,
los necesarios para crear los objetos que necesiten los
desarrolladores, a los administradores de bases de datos y
ellos se encargaran de recibir los pedidos de creación
de objetos de parte de los desarrolladores.
3.3.4.1 Desarrolladores de Aplicaciones y sus
privilegios
Los desarrolladores de bases de datos son
exclusivamente usuarios de ésta y requieren un grupo
de privilegios para poder
cumplir con sus trabajos. A diferencia de los usuarios
finales, los desarrolladores necesitan privilegios de
sistema, como por ejemplo para crear una tabla, crear un
procedimiento, etc. Sin embargo, solo
específicos privilegios van a otorgarse a los
desarrolladores, asi se podrá restringir sus accesos
en la base de datos.
3.3.4.2 Desarrollo de Aplicaciones Libres vs.
Desarrollo de Aplicaciones Controladas
El administrador de base de datos puede definir las
siguientes opciones cuando determine que privilegios deben
ser otorgados a los desarrolladores:
Libre Desarrollo Un desarrollador de
aplicaciones esta autorizado a crear nuevos esquemas de
objetos, incluyendo tablas, índices, procedimientos, paquetes, etc. Esta
opción permite desarrollar una aplicación
independiente de los otros objetos.
Desarrollo Controlado Un desarrollador no
está autorizado a crear nuevos esquemas de objetos.
Todas las tablas, índices, procedimientos, etc.,
requeridos son creados por el administrador de base de
datos, por un pedido del desarrollador. Esta opción
permite al administrador de base de datos tener
completamente controlado el espacio usado de la misma y el
camino de acceso a la información en
ella.
No obstante, algunos sistemas de base de datos usan
solo una de esas opciones, otros sistemas pueden combinar
esas opciones. Por ejemplo, los desarrolladores pueden ser
autorizados para crear nuevos procedimientos y paquetes
almacenados, pero no están autorizados para crear
tablas o índices.
Para que un administrador de seguridad tome alguna
decisión con respecto a este tema debe basarse en lo
siguiente:
- El control deseado sobre el espacio a utilizar de
la base de datos - El control deseado sobre las rutas de acceso a los
esquemas de los objetos - La base de datos usada para desarrollar
aplicaciones, si una base de datos de prueba es usada para el
desarrollo de aplicaciones, una política más
liberal de desarrollo será implementada.
3.3.4.3 Roles y privilegios para los
desarrolladores
Los administradores de seguridad pueden crear roles
para manejar los privilegios requeridos por los
desarrolladores. Por ejemplo, el típico rol llamado
APPLICATION_DEVELOPER puede incluir los privilegios de sistemas
para utilizar CREATE TABLE, CREATE VIEW y CREATE
PROCEDURE.
Los administradores de seguridad considerarán
lo siguiente cuando definan roles para los
desarrolladores:
- Los privilegios de sistema para utilizar CREATE son
usualmente otorgados a los desarrolladores, entonces ellos
pueden crear sus propios objetos. Sin embargo, CREATE ANY, el
cual permite al usuario crear un objeto en cualquier campo de
acción del usuario, no es usualmente otorgado a los
desarrolladores. Esto restringe la creación de nuevos
objetos sólo para las cuentas de usuario de los
desarrolladores. - Es poco frecuente asignar privilegios sobre objetos
a los roles usados por los desarrolladores de aplicaciones.
Es impráctico, esto restringe sus posibilidades de uso
en la creación de otros objetos. Es más
práctico permitir a los desarrolladores crear sus
propios objetos para propósitos de
desarrollo.
3.3.4.4 Restricciones de Espacio impuestas sobre
los desarrolladores
Como el privilegio de crear objetos, que se le otorga
a los desarrolladores, forma parte del proceso de
desarrollo de aplicaciones, los administradores de seguridad
deben controlar cual y cuanto espacio va a ser usado por cada
desarrollador en la base de datos. Por ejemplo, como un
administrador de seguridad, debería fijar o restringir
los siguientes límites para cada
desarrollador:
- El Tablespace en los cuales los desarrolladores
pueden crear tablas o índices. - La quota por cada Tablespace accesible por los
desarrolladores.
3.3.5 Seguridad de Administrador de
Aplicaciones
En grandes sistemas de bases de datos con muchas
aplicaciones (por ejemplo, precompiladores y aplicaciones de
formularios)
podría tener un administrador de aplicaciones. Este es
responsable de los siguientes tipos de tareas:
- Creación de roles para aplicaciones y manejo
de privilegios para cada rol de las aplicaciones. - Creación y manejo de objetos usados por una
aplicación en la base de datos. - Mantenimiento y actualización del código de las aplicaciones y de los
procedimientos de Oracle.
Frecuentemente, un administrador de aplicaciones es
también el desarrollador que diseñó dicha
aplicación. Sin embargo, esos trabajos pueden no ser las
responsabilidades del desarrollador y se le asignará a
otro individuo
familiarizado con la aplicación de la base de
datos.
3.4 – Política administrativa de
Passwords
La seguridad de los sistemas de base de datos depende
de no divulgar las passwords en ningún momento. No
obstante, son vulnerables al robo, falsificación y
abuso. Para permitir un mayor control en la seguridad sobre las
bases de datos, la política administrativa de passwords
de Oracle es controlada por DBAs.
Esta sección describe los siguientes aspectos
de la administración de passwords en Oracle:
- Cierre de cuenta
- Expiración de las
passwords - Verificación en la complejidad de
passwords
3.4.1 Cierre de Cuenta
Cuando un usuario excede un determinado número
de intentos de accesos fallidos, el server
automáticamente cierra la cuenta del usuario. DBA
especifica el número permitido de accesos fallidos
usando la sentencia CREATE PROFILE. También especifica
el período de tiempo que la cuenta quedará
cerrada.
Si el DBA no especifica el tiempo que tardará
en habilitarse la cuenta nuevamente, el sistema toma un tiempo
por default; y si el tiempo estipulado es ilimitado, el
encargado del sistema de seguridad deberá directamente
habilitar la cuenta. De esta manera, el período de
tiempo que una cuenta permanece cerrada depende de cómo
la DBA configura los recursos asignados al usuario.
El encargado de seguridad también puede
directamente cerrar cuentas de usuarios. Cuando esto ocurre
sólo el encargado de seguridad puede habilitarla
nuevamente.
3.4.2 Expiración de las
passwords
El DBA usa la sentencia CREATE PROFILE para
especificar un máximo de tiempo de vida de las
passwords. Pasado este tiempo la password expira y el usuario
deberá cambiarla. También puede especificar un
período de gracia usando la misma sentencia.
Los usuarios ingresarán el período de
gracia sobre el primer intento de login, a una cuenta de la
base de datos, después de que su password haya expirado.
Durante el período de gracia, aparecerá un
mensaje de advertencia cada vez que el usuario intente entrar
en su cuenta, y continuará apareciendo hasta que expire
el período de gracia. Si la password no es modificada
dentro de dicho período, la cuenta expirará y
ningún intento de acceso será permitido hasta que
no se modifique la password.
El encargado de la seguridad puede también
expirar directamente la cuenta. Esto es particularmente
útil para generar nuevas cuentas.
3.4.3 Verificación en la complejidad de
passwords
La rutina de verificación de complejidad de
passwords en Oracle puede ser especificada usando PL/SQL
script, el cual fija los parámetros de
default.
La rutina de verificación de la complejidad de
las passwords representa los siguientes puntos:
- La password tiene una longitud mínima de 4
posiciones - Debe ser distinta que el userid
- Tiene al menos un número, una letra y un
punto - No usar palabras simples tales como welcome,
account, database o user - La password actual difiere de la password anterior
al menos en 3 letras
Oracle recomienda no cambiar las passwords usando la
sentencia ALTER USER porque no soporta enteramente la
función de verificación de
passwords. En cambio, si
podría usar las herramientas que provee Oracle como SQL*Plus o
Enterprise Manager para cambiar las passwords.
DBA puede mejorar las rutinas de verificación
de complejidad de las passwords o crear sus propias rutinas
de verificación de passwords usando PL/SQL.
3.5 – La Política de
Auditoria
Los administradores de Seguridad deben establecer
una política para el procedimiento de auditoria de
cada base de datos. Cuando es necesaria una auditoria el
administrador de seguridad debe decidir a que nivel de
detalle se realizará la auditoría de la base de
datos.
Una vez detectado alguna actividad de origen
sospechosa a través del sistema general de auditoria,
se realizará una auditoría más
especifica.
4. Trusted ORACLE
Trusted Oracle es un sistema de
administración de la seguridad de bases de datos. Fue
diseñado para proveer el más alto nivel de
capacidades para la administración de la seguridad
requerido por organizaciones que procesan información
sensitiva. Trusted Oracle es compatible con todos los
productos
Oracle.
Además, Trusted Oracle implementa
Mandatory Access
Control (MAC) (control de acceso obligatorio).
Mandatory Access
Control es un medio para restringir el acceso a la
información basado en etiquetas o rótulos. La
etiqueta de un usuario indica a qué información
le está permitido acceder a un usuario y con
qué tipo de acceso (lectura o
escritura). La etiqueta de un objeto indica la
sensibilidad de la información que el objeto
contiene.
5. Copia de
seguridad y recuperación de la base de
datos
En cada sistema de base de datos siempre existe la
posibilidad de una falla del sistema o de hardware. Si
una falla ocurre y afecta la base de datos esta debe ser
recuperada.
Los objetivos
después de la falla son asegurar que los efectos de
todas las transacciones realizadas se reflejen en la base de
datos recuperada y retornar a la operación normal tan
rápido como sea posible mientras se aísla a los
usuarios.
5.1 – Tipos de falla
Varias circunstancias pueden detener la
operación de una base de datos Oracle.
Los tipos de falla más comunes
son:
5.1.1 Errores de usuario
Los errores de usuario pueden requerir, para ser
recuperados, de una base de datos en un punto anterior en el
tiempo al que ocurrió el error.
Para permitir la recuperación a partir de los
errores de usuario y acomodar otros requisitos únicos
de recuperación, Oracle provee una recuperación
exacta en el tiempo.
5.1.2 Fallas de sentencias y
procesos
Las fallas de sentencias ocurren cuando hay una
falla lógica en el manejo de una sentencia en
un programa
Oracle.
Cuando ocurre una falla de sentencia los efectos de
las sentencias se deshacen automáticamente por Oracle
y se devuelve el control al usuario.
Una falla de proceso es una falla en un proceso de
usuario accediendo a Oracle, tales como una
desconexión o finalización de un proceso en
forma anormal.
El proceso de usuario fallido no puede continuar
trabajando, aunque Oracle y otro proceso de usuario puedan.
El proceso subordinado de Oracle PMON detecta
automáticamente los procesos
de usuario fallidos o es informado de este hecho por SQL *
Net. PMON resuelve el problema realizando una
regresión de las transacciones realizadas y liberando
los recursos que estaban tomados por el proceso
fallido.
5.1.3 Falla de una copia de programa en
memoria
Una falla de una copia de programa en memoria puede
resultar por un problema de hardware como la salida de
energía o un problema de software como
la caída del sistema operativo.
Cuando ocurre una falla de este tipo la
información de los buffers del área global del
sistema no se escribe en los archivos. Esta falla requiere
recuperar la copia del programa en la memoria
La recuperación de la instancia se lleva a
cabo automáticamente por Oracle cuando la instancia se
reinicializa.
El Redo log se usa para recuperar los datos en los
buffers del SGA.
5.4.1 Falla en disco
La falla en disco es un problema físico
cuando se lee o escribe un archivo en
disco.
La recuperación del medio restablece los
archivos de la base de datos con la información
correspondiente al instante más reciente antes de la
falla, incluyendo la información que se perdió
a causa de la falla. Se requiere lo siguiente: copia de
seguridad de los archivos de la base de datos
Si algunos archivos de datos se dañan, en una
falla de disco, pero la mayor parte de la base de datos esta
intacta, la base de datos puede permanecer abierta mientras
la "tablespaces" requeridas se recuperan
individualmente.
Por consiguiente las porciones no dañadas de
una base de datos están disponibles para su uso normal
mientras se recuperan las porciones dañadas
5.2 – Estructuras
utilizadas para la recuperación
Oracle utiliza diversas estructuras para proveer una
recuperación completa a causa de una falla de una
copia del programa en memoria del disco: el redo log,
segmentos de rollbak, un archivo de control y copia de
seguridad de la base de datos necesarias.
5.2.1 El Redo Log
El Redo Log es un conjunto de archivos que protegen
la información de la base de datos alterada que
aún no ha sido escrita en los archivos.
El Redo Log puede consistir en 2
partes:
Registra todos los cambios hechos a la base de
datos. Cuando se envía una transacción a la
base de datos, se guarda en forma temporal la entrada
correspondiente del Redo log en los buffers del SGA, que
luego el proceso subordinado LGWR escribe en un archivo
Redo log en línea.- El Redo Log en línea
(online) - El Redo Log almacenado (offline)
Se almacenan mediante archivos.
Los archivos de control de una base de datos
mantienen, entre otras cosas información sobre la
estructura de los archivos de una base de
datos y el número de secuencia del log actual que
esta siendo escrito por LGWR.Durante los procedimientos normales de
recuperación.- Archivos de control
- Segmentos de regresión (rollback
segments)
Los segmentos de regresión graban
información usada por distintas funciones de
Oracle.
Durante la recuperación de la base de datos,
después que todos los cambios grabados en el Redo log
han sido aplicados. Oracle utiliza información de los
segmentos rollback para deshacer cualquier transacción
realizada. Debido a que los segmentos rollback se almacenan en
los buffers de la base de datos, esta importante
información de recuperación es
automáticamente protegida por el redo log.
5.2.4 Copias de Seguridad de la Base de
Datos
Debido a que uno o más archivos pueden ser
físicamente dañados como consecuencia de una
falla del disco, la recuperación del medio requiere
restauración de los archivos dañados desde el
backup mas reciente.
Hay varias formas de hacer copias de seguridad de los
archivos de una base de datos:
5.2.4.1 Copia de seguridad completa de una base de
datos
Es una copia de seguridad de todos los archivos de
datos, archivos redo log en línea, y el archivo de
control.
Las copias de seguridad completas se realizan cuando
se cierra la base de datos y queda inhabilitada para su
uso.
- Copias de seguridad parciales
Es una copia de una parte de la base datos. La copia
de seguridad de un tablespace individual o la copia de
seguridad de un archivo de control son ejemplos de backups
parciales.
5.3 – Pasos básicos de
recuperación
Debido a la forma en que la información de los
buffers se graba en los archivos puede ocurrir que en un
momento dado:
- un archivo contenga datos modificados por
transacciones no ejecutadas - un archivo no contenga algunos datos modificados
por transacciones ejecutadas.
Para solucionar esta situación, Oracle siempre
utiliza dos pasos separados durante la recuperación de
una falla de un medio o una falla de una copia de un programa
en memoria:
5.3.1 Avance (Rolling
Forward)
Consiste en aplicar a los archivos de datos todos los
cambios grabados en el Redo Log, llevando (adelantando) los
archivos de datos al punto de tiempo requerido.
Si todo la información del Redo Log está
en línea, Oracle ejecuta este paso de
recuperación de manera automáticamente se inicia
la base de datos. Después de realizado este paso los
archivos de datos contienen todos los cambios realizados por
transacciones ejecutados y por transacciones no ejecutadas,
grabados en el Redo Log.
5.3.2 Retroceso (Rolling
Back)
Se utilizan los segmentos de retroceso (Rollback
Segments) para identificar las transacciones que nunca se
ejecutaron, pero que están grabadas en el Redo Log.
Oracle realiza este paso automáticamente.
5.4 – El administrador de la
Recuperación
Es una herramienta de Oracle que lleva a cabo las
operaciones referidas a las copias de seguridad y a la
recuperación de la base de datos.
Este mantiene un catálogo de
recuperación, el cual contiene información sobre
las copias de seguridad de archivos y de los Redo Logs
offline.
Manual de Oracle 8 Server
De Brito, Cynthia
Diz Marín, María Paula
Pineda, Gabriel
Tripi, Hernán
Yagi, Marisa
U.T.N-Facultad Regional Buenos
Aires-
Ingeniería en sistemas de
información
Seguridad Informática
Página anterior | Volver al principio del trabajo | Página siguiente |