Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

Seguridad del sistema de base de datos ORACLE (página 2)




Enviado por Gabriel Pineda



Partes: 1, 2

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.

  1. 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.

  1. 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.

  2. 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.

  3. Temporay Tablespace
  4. 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:

  • El número de sesiones concurrentes que el
    usuario puede establecer
  • El tiempo de
    CPU:

– 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:

  1. 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.

  2. El Redo Log en línea
    (online)
  3. El Redo Log almacenado (offline)

Se almacenan mediante archivos.

  1. 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.

  2. Archivos de control
  3. 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.

  1. 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.

  1. Bibliografía

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

Partes: 1, 2
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter