Sobre la versin de la BD

Actualmente se tiene la base de datos con versin: Oracle8 Release

8.0.4.0.0 Production

Propuesta:
Se recomienda realizar un parche o actualizacin para habilitar ciertas
herramientas internas y evitar inconvenientes de la versin actual.
Oracle8 Database: 8.0.38.0.6
Oracle8i Database Release 1: 8.1.5.08.1.5.1
Oracle8i Database Release 2: 8.1.6.08.1.6.3
Oracle8i Database Release 3: 8.1.7.08.1.7.4
Para actualizar a una versin reciente, no se puede hacer en una sola
migracin. Debe hacerse hacia una versin poco superior (intermediaria) y
luego de esa versin, se actualiza a la versin reciente. A continuacin se
explica brevemente los caminos que se pueden tomar para actualizar:

Versin actual

Camino de actualizacin
No se permite la actualizacin directa. Se debe actualizar a
una versin de base de datos intermediaria. Por ejemplo:

7.3.3 o inferior
7.3.4
8.0.3
8.0.4
8.0.5
8.0.6
8.1.5
8.1.6
8.1.7.4
9.0.1.4

9.2.0.8
10.1.0.5
10.2.0.2
11.1.0.6

7.3.3 (o inferior) 7.3.4 9.2.0.8 11.2

8.0.5 (o inferior) 8.0.6 9.2.0.8 11.2
AQU ESTAMOS ACTUALMENTE
8.1.7 (o inferior) 8.1.7.4 10.2.0.4 11.2
9.0.1.3 (o inferior) 9.0.1.4 10.2.0.4 11.2

Cuando actualizamos a una versin de base de datos

intermediaria, se debern seguir las recomendaciones que
se encuentran en la documentacin de la versin
intermediaria. Luego, la base de datos intermediaria se
cambia hacia la nueva base de datos (en este caso, la
versin 11.2). Podemos optar por el camino marcado en
rojo despus de haber actualizado (a versin 8.1.7) la
base de datos a travs de script/parches.
A partir de la versin 9.2.0.8 o superior, est permitido
migrar hacia una versin reciente.

Sobre la seguridad en las

operaciones de la base de datos:
Como buena prctica, por motivos de seguridad se espera que se tengan bien
definidos roles que cumplan cada funcin u objetivo de la aplicacin para
realizar las operaciones. Con esto se puede determinar qu usuarios pueden
realizar ciertas tareas y qu usuarios estn restringidos. Esto es importante
para evitar que usuarios no autorizados puedan manipular informacin crtica
de los sistemas.
Realizando un anlisis, actualmente se tienen pocos roles, los cuales no
estn siendo utilizados de forma correcta dado a que no se detalla cada rol por
cada funcin: eliminacin, actualizacin, ingreso, alteracin, de informacin.
En la siguiente imagen se muestra el rol: USUARIOS, el cual est definido para
brindar permisos de alteracin de estructura, eliminacin, ingreso, consulta y
modificacin de informacin. Todos esos permisos estn asociados a un solo
rol, el cual al asignrselo a un usuario, le permite a que pueda realizar todas
esas operaciones.

Adicionalmente, se cuenta con usuarios que tienen permisos de DBA

(Administrador de Bases de Datos). Estos permisos no deberan estar
permitidos a menos que sea la persona encargada de velar por la
administracin de la base de datos.
GRANTEE
BANCO_5B

GRANTED_R
OLE
DBA

ADMIN_OPTI
ON
NO

DEFAULT_RO
LE
YES

BANCO_REAL
CUADRES
DBA_PRUEBA
ERICK
MANTENIMIEN
TO
MIGRA
PROMEDIO
PRUEBA
SYS
SYSTEM
XSISTEMA

DBA
DBA
DBA
DBA
DBA

NO
NO
NO
NO
NO

YES
YES
YES
YES
YES

DBA
DBA
DBA
DBA
DBA
DBA

NO
NO
NO
YES
YES
NO

YES
YES
YES
YES
YES
YES

En la tabla anterior se puede observar que existen 10 usuarios con permisos de

DBA. Se exceptan de este listado a los usuarios: SYS y SYSTEM, los cuales son
propios de las bases de datos.

Propuestas:

Definir roles especficos para las distintas acciones: ALTER, DELETE, etc.
Esto con el fin de que se le otorgue el rol a cada usuario dependiendo la
necesidad de su funcin. As se evita inconvenientes que puedan
resultar en una auditora (interna/externa).
Como mnimo, dependiendo la aplicacin, se deberan definir los roles
siguientes:
o Consulta
o Ingreso/Modificacin
o Eliminacin *
o Administracin **

* No es buena prctica eliminar informacin. Si es necesario eliminar del sistema, se debera

guardar una bitcora de la eliminacin a realizar, de tal forma que se pueda captar el estado de
la informacin antes de ser eliminada. A nivel de base de datos se recomienda seguir esta
prctica, o mejor an, definir una bandera a cada registro, en la cual indique si es vlida/invlida
la informacin.
** Es un rol que se le permite nada ms a ciertos administradores de la informacin. El rol
permite agrandar un espacio de un campo, agregar una nueva columna, modificar un proceso,
etc. Se recomienda que se permita este rol solamente a aquellas tablas que no son crticas; sin
embargo, No se le debera permitir alterar toda tabla crtica (entindase: salarios de empleados,
crditos de clientes, saldos, etc.); de preferencia esta funcin debera ser realizada por el DBA (a
travs de una autorizacin).

Bloquear a los Esquemas (dueos) de la aplicacin y crear un usuario

adicional para conexiones de la aplicacin; as se evita que si se conocen
las contraseas que estn configuradas en la conexin del servidor de
aplicacin, los usuarios no puedan conectarse en otra herramienta
(haciendo uso de dicha credencial). Utilizar: Trigger after_logon.

Proponer que a travs de la aplicacin, se tenga definido qu

operaciones pueda realizar el usuario segn el rol asignado a dicho
usuario.
Para ello se recomienda tener una aplicacin de administracin en la
seguridad de los usuarios, a travs de la cual, cada nuevo usuario que se
va a crear en cada sistema (administrativo), se le otorguen roles
dependiendo la aplicacin. Tomar nota que esto va a depender de la
lgica de seguridad que tenga cada aplicacin ya que esta puede tener
su propia administracin de seguridad interna.
Quitar los permisos de DBA a todo aquel usuario que por su funcin no
debera tener ese tipo de rol dentro de la base de datos.

Sobre el almacenamiento en la
BD
1) Por qu existen varios Datafile? Es por poco espacio, o por poltica de
tener varios?
2) Por qu se crean menores a 1Gb de tamao?
3) Por qu no estn autoincrementales? Se recomienda para evitar
inconvenientes de espacio.

Propuestas:

Segn espacio a disponer para almacenamiento, crear un Datafile de mayor

tamao (lo ms justo al total de almacenamiento necesitado), considerando el
mximo tamao que puede tener un archivo dentro del sistema Operativo (por
ejemplo: 16Gb, 32Gb, etc.). En versiones recientes de Base de Datos Oracle
suele utilizarse el trmino BIGFILE TABLESPACE, el cual contiene Datafile que
pueden ir de un tamao en Kilobyte (Kb) hasta Terabytes (T). Esto es para
evitar estar creando mltiples Datafile y mejoramiento en el rendimiento de la
base de datos debido a que reduce el SGA a utilizar; disponible para
almacenamiento en ASM u otros gestores de volmenes lgicos.
El autoincremento es importante habilitarlo para evitar que se den errores de
escritura en los Datafile al momento de llenarse. Dependiendo la frecuencia
con la que crecen los Datafile, se puede automatizar incrementndolos a una
escala considerable (dependiendo el espacio del que se tenga).
Revisiones constantes:
Chequear los espacios en Tablespaces:
o Crear una tarea (Job) que realice las revisiones necesarias y
alertar.
Chequear los objetos invlidos (recompilarlos en caso sea necesario).
o Crear una tarea (Job) que realice las revisiones necesarias y
alertar.
Revisiones peridicas:
Ver los procesos y rendimiento, a fin de realizar procesos de
optimizacin, compactacin, y todo lo relacionado a mejoramiento del
rendimiento de la base de datos.
Se puede hacer uso de vistas materializadas? Revisar algn proceso que
lo requiera.

Sobre estandarizacin de
definicin en las estructuras de
datos
Es importante considerar ciertas recomendaciones en la forma de definir o
crear las estructuras de datos, por ejemplo: colocar nombres lgicos a las
tablas, columnas; definir tamaos especficos a las columnas segn la
necesidad. Se puede definir nombres a las tablas haciendo uso de prefijos, los
cuales indiquen las iniciales o siglas del esquema donde se crean las tablas.
Con esto evitamos que en un futuro existan tablas similares en distintos

esquemas y puedan dar conflictos. Esto tambin aplica para las funciones,
procedimientos, vistas, etc.
A continuacin se encuentran ciertas sugerencias que se pueden ir tomando en
cuenta, a fin de empezar a estandarizar la creacin de los objetos en la base de
datos:

Se tiene que definir la tabla para el control de los empleados en el

sistema de recursos humanos. El nombre apropiado para esta tabla
sera: empleado. A su vez tambin existe una aplicacin de
correspondencia para los empleados; esta tambin tiene a su vez una
tabla para los empleados. Como podemos darnos cuenta, existe la
posibilidad de tener dos tablas llamadas empleado, pero en diferentes
esquemas. Por tanto, se aconsejara colocar los siguientes nombres:
o
o
o

Para el sistema de recurso humano, la tabla se llamara:

RH_EMPLEADO
Para el sistema de correspondencia, la tabla se llamara:
CR_EMPLEADO
Objetivo de nombramiento:
Evitar que en una futura ocasin, ya sea por migracin en
dado caso exista poco recurso, se tenga que trasladar
esquemas de un servidor a otro, y colocarlos en la misma
instancia. Estaremos evitando que equivocadamente se
est accediendo a tablas diferentes.
Cuando existen muchos esquemas/aplicaciones (con sus
respectivas
tablas) en la misma instancia, se puede
diferenciar fcilmente los dueos de las tablas.
Se evita tener inconvenientes con alguna mala accin (error
humano) a causa de no especificar el dueo (esquema) de
la tabla.
Se evita problemas de seguridad al momento de querer
otorgar permisos sobre ciertas tablas a los usuarios.

Se tienen que definir nombres y tamaos apropiados a las columnas,

dependiendo la funcin/objetivo que va a tener dicha columna. Por
ejemplo, no es conveniente asignar un tamao de 2000 caracteres
mximo a una columna que va almacenar nada ms el nombre de una
persona. En las columnas numricas, tambin asignar el tamao
apropiado a la columna segn el alcance que se tenga.

Evitar el uso permanente de tablas temporales. Si es una tabla temporal,

definir el nombre como tal y establecer una poltica para borrado de
dichas tablas al momento de dejar de funcionar.

Se sugiere tener una tabla base, la cual es un catlogo, con el objetivo

de que dentro de esta tabla, se agreguen todos los nombres de las
tablas existentes para cierto sistema, diferencindolas si son catlogos o

transaccionales, as como tambin agregando una descripcin de la

misma tabla. Esto con el fin de que cuando se tenga duda, se pueda
hacer la consulta a dicha tabla y tener la idea mnima de la funcin
principal de la tabla. As tambin, se puede diferenciar los catlogos y
transaccionales, para cuando se necesite depurar una base de datos.

Jeovany Tal - Riesgos