Aplicando el Principio Least Privilege

El principio básico de seguridad en Oracle y uno de los fundamentos en seguridad a nivel de infraestructura de IT es aplicar «Lo Más Restrictivo», es decir aplicar lo que se conoce como «Menor Privilegio».

El «Menor Privilegio» es un mecanismo de seguridad que se aplica sobre los permisos, accesos y privilegios que debe tener un usuario sobre un cierto servicio/recurso. Este principio es aplicado a todo tipo de infraestructura (red, bases de datos, aplicación, etc.), pero en este artículo nos vamos a enforcar exclusivamente a su aplicación en bases de datos Oracle
 
Mejores Prácticas Generales

• Instalar únicamente el software necesario en el servidor, evitando instalar aplicaciones de usuario final
• Activar únicamente los servicios que sean necesarios
• Abrir únicamente los puertos necesarios para acceso, sesiones y mantenimiento; se debe deshabilitar los puertos que no se utilicen
• Dar acceso al Sistema Operativo y a la Base de Datos únicamente a los usuarios que requieran dicho acceso.  Se debe restringir el acceso del DBA al SO y el acceso del administrador de red a la BDD
• Limitar acceso a la cuenta Administrador
• Limitar acceso a las cuentas SYSDBA y SYSOPER
• Limitar el acceso de los usuarios ÚNICAMENTE a los objetos de la base de datos requeridos para que cumplan con su trabajo.

Aplicación Práctica

• Protejer el Diccionario de Datos
  O7_DICTIONARY_ACCESSIBILITY=FALSE
• Revocar privilegios innecesarios del usuario PUBLIC
  REVOKE EXECUTE ON UTL_SMTP, UTL_TCP, UTL_HTTP,UTL_FILE FROM PUBLIC;
• Restringir autenticación remota a la base de datos
  REMOTE_OS_AUTHENT=FALSE
• Restringir directorios que sean accesibles por usuarios
  UTL_FILE_DIR=NULL;
• LImitar usuarios con privilegios administrativos

Eliminando Contención de I/O

La contención de disco ocurre cuando múltiples procesos intentan acceder al mismo disco físico simultáneamente, lo que causa una baja en el rendimiento de la base de datos. En este artículo vamos a conocer un poco más en detalle como los escenarios en los que se da este problema y ciertos mecanismos para evitarlo.La solución más obvia para reducir la contención de disco es reducir las entradas I/O. esto se logra distribuyendo las I/O sobre las diferentes unidades de disco lógicas que tiene el servidor. Para distribuir las entradas de I/O será necesario mover los Datafiles que estén saturados en lectura y escritura. Lo que se debe hacer primero es identificar dichos Datafiles mediante las vistas dinámicas V$FILESTAT y V$DATAFILE.
Nota: V$FILESTAT y V$DATAFILE no funcionan para Tablespaces temporales. Para monitorear tablespaces temporales se debe usar V$TEMPFILE y V$TEMPSTATS.  
SQL> col name format a25
SQL> SELECT name, phyrds, phywrts, readtim, writetim
   2     FROM v$filestat a, v$datafile b
   3     WHERE a.file#=b.file#;

Mediante esta consulta es posible identificar los Datafiles que tienen la mayor cantidad de lecturas y escrituras. Una vez identificados los Datafiles procedemos a mover los tablespaces a otra unidad/partición para equilibrar I/O: Para esto tenemos que seguir los siguientes pasos:

Tomamos el tablespace correspondiente al datafile que tiene la mayor cantidad de I/O y lo ponemos en estado Offline
SQL> ALTER TABLESPACE USERS OFFLINE;

Copiamos el Datafile a la nueva ubicación (En otra partición/disco)
Renombramos el Datafile apuntándolo a la nueva ubicación
SQL> ALTER DATABASE USERS RENAME DATAFILE
   2    ‘D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\USERS01.dbf’ to
   3    ‘H:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP10G\USERS01.dbf’;

Volvemos a poner el tablespace en estado Online
SQL> ALTER TABLESPACE USERS OFFLINE;

Verificamos si el Control File actualizó la base de datos mediante la vista dinámica V$DATAFILE
SQL> col name format a50
SQL> select file#, name from v$datafile;

Gestionando UNDO

Los datos UNDO no son más que una copia de los datos originales antes de aplicar una sentencia DML (Insert, Update, Delete o Merge) y que son utilizados para Operaciones de Rollback, Lecturas Consistentes, Flashback Queries y Recuperación de transacciones fallidas.
 

Undo Tablespaces y Undo Segments

La información UNDO es almacenada en UNDO SEGMENTS y estos a su vez en UNDO TABLESPACES. Los Undo Segments pueden existir en solamente en el Undo Tablespace. (Pueden existir algunos Undo Tablespaces pero solamente uno será el activo en cualquier momento). Los Undo Segments no son de tamaño fijo por lo que si un Undo Segment se llena, Oracle añadirá automáticamente otro Extent. Además Oracle generará automáticamente nuevos Undo Segmens “On demand”. Los Undo Tablespaces deben ser permanentes (Permanent), manejados localmente (Locally Managed) y con Asignación de Extensión Automática (Automatic Extent Allocation). Además un Undo Tablespace (Si es que está activo) no puede puesto fuera de línea (Offline), ni Solo-Lectura (Read-Only) ni ser eliminado, pero pueden añadirse, mover o cambiar el tamaño de los Datafiles.

Segmentos Undo y Transacciones

Cuando una transacción empieza Oracle automáticamente asigna SOLO UN Undo Segment. La información necesaria para hacer un Rollback de la sentencia DML es escrita en los bloques asignados al Segmento Undo. Los datos almacenados aquí son retenidos hasta que se aplique COMMIT; en este estado los datos UNDO están en estado ACTIVE (Que indica que la información almacenada hace referencia a una transacción no finalizada y por ende no puede ser eliminada). Esta etapa garantiza la característica de ATOMICIDAD del modelo ACID de las transacciones.
Si otra sesión hace una lectura de los datos que están siendo actualizados por otra sesión (la transacción aún está activa) Oracle redirecciona la búsqueda a los Undo Segments garantizando la consistencia de datos. Cuando esto sucede se dice que los datos de Undo están en estado UNEXPIRED (Utilizado para lecturas consistentes y Flashback). Esto garantiza a propiedad de CONSISTENCIA del modelo ACID.

Cuando una transacción ha finalizado, automáticamente los datos de Undo pasan a un estado EXPIRED que implica que Oracle puede sobreescribir sobre dichos bloques ya que es información que ya no se necesita para lecturas consistentes y además ha pasado el tiempo suficiente para ejecutar Flashback.
Hay que tener en cuenta que Oracle trabaja en “Circular Fashion”, es decir que cuando los Undo Segments están en un estado EXPIRE y una nueva transacción empieza o alguna transacción que está en ejecución necesita más Undo Segments, los datos más antiguos serán sobrescritos. Oracle asumirá que los Undo Segments catalogados como EXPIRE no son parte de una transacción larga a la que aún no se aplica COMMIT. Si se ve ese caso será necesario extender el tamaño de los Undo Segments.

Errores con UNDO

Si una transacción se queda sin espacio de Undo (porque ya no habrá espacio libre Undo tablespace para extender el Undo Segment) entonces a la sentencia que causó el problema se aplicará automáticamente un Rollback pero el resto de la transacción se mantendría intacta en estado UNCOMMIT. Esto se da si el Undo Tablespace se llena de datos tipo UNEXPIRED UNDO. (ORA-30036)
Otro problema se da cuando una consulta hace una consulta a un block que fue cambiado por otra sesión. Cuando la consulta es redireccionada al Undo Segment respectivo para obtener la versión pre-actualizada y encuentra que el Block ha sido sobreescrito (porque estaba en estado EXPIRED) se obtiene el error “Snapshot Too Old” (ORA-1555)

Para solucionar estos problemas se deben aplicar dos sencillos criterios: Se debe tener suficiente espacio de Undo para permitir que todas las transacciones continúen; y debe haber suficiente Undo Data para que todas las consultas se ejecuten con éxito.

Para prevenir errores relacionados con UNDO es necesario tener en cuenta:

• Aplicar el tamaño del UNDO Tablespace apropiadamente
• Asegurarse que a las transacciones largas se apliquen COMMITs periódicamente
• Configurar apropiadamente el intervalo de retención de UNDO
• Considerar garantizar UNDO Retention (mediante el parámetro UNDO_RETENTION)