# data[].attributes.body
AUDITANDO EN LAS BASES DE DATOS

# data[].attributes.body
AUDITORÍA DE BASES DE DATOS

Consiste en un proceso de monitoreo continuo y riguroso en los controles de la administración.

# data[].attributes.headline
AUDITANDO EN LAS BASES DE                                             DATOS            

# data[].attributes.subject
AUDITANDO EN LAS BASES DE                                             DATOS            

# data[].attributes.headline
4. LA ADMINISTRACIÓN DEL REGISTRO DE AUDITORÍA

# data[].attributes.subject
4. LA ADMINISTRACIÓN DEL REGISTRO DE AUDITORÍA

# data[].attributes.body
Es necesario analizar qué tipo de información deseamos auditar, qué es relevante y qué no, qué nos sirve en una investigación y qué información no tiene sentido.

4.1 Actividades sospechosas: Se requiere auditar actividades sospechosas es, primero auditar en forma general y posteriormente auditar lo específico.

# data[].attributes.body
AUDITORÍA DE BASES DE DATOS

Proceso de monitoreo continuo y riguroso de los controles que la administración ha establecido dentro de los sistemas de bases de datos y todos sus componentes para obtener una seguridad razonable de la utilización adecuada de los datos.

# data[].attributes.body
Consiste en un proceso de monitoreo continuo y riguroso de los controles establecidos dentro de los sistemas de la base de datos y todos sus componentes

# data[].attributes.body
Es un proceso de monitoreo para obtener una seguridad

# data[].attributes.body
DÓNDE UBICAR LOS CONTROLES

Los controles en las aplicaciones: Esto implica modificaciones de código, compilaciones de programas y otros procesos necesarios para asegurar que todas las aplicaciones contengan el control.

Los controles en la red: Consiste en poner

el control entre el usuario y la base de datos, significa

realmente tenerlo en la red.

Control en la fuente: Fácil de implementar y de administrar.

# data[].attributes.body
2.1 Los controles en las aplicaciones. A cada

sistema se le debe adicionar el control, lo que genera modificaciones.

2.2 Los controles en la red. Consiste en poner

el control entre el usuario y la base de datos.

2.3 Control en la fuente. Consiste en poner el control directamente en la base de datos.

# data[].attributes.body
Hace referencia a un proceso de monitoreo continuo y riguroso de los controles que la administración ha establecido dentro de los sistemas de bases de datos y todos sus componentes .

# data[].attributes.body
Es un proceso de monitoreo continuo y riguroso de los controles que la administración ha establecido dentro de los sistemas de bases de datos y todos sus componentes para obtener una seguridad razonable de la utilización adecuada de los datos.

# data[].attributes.body
3.1 Auditoría de actividades: Consiste en controlar las actividades que realizan los usuarios en los objetos de la base de datos.

3.2 Auditoría de transacciones: consiste en implementar una serie de controles que permiten llevar un registro detallado de todas las transacciones que los usuarios realizan.

# data[].attributes.body
TIPOS DE AUDITORÍAS DE BASES DE DATOS

1. Auditoría de actividades

Realizan los usuarios en los objetos de la base de datos y entenderemos como objetos todas las tablas, vistas, restricciones de integridad que los usuarios crean en la base de datos.

2. Auditoría de transacciones

Consiste en implementar una serie de controles que permiten llevar una bitácora de todas las transacciones que los usuarios realizan.

# data[].attributes.body
Existen tres posibilidades:

✔️Poner los controles en el nivel de las aplicaciones.

✔️Ponerlos en medio de las aplicaciones y la base de datos, lo que lamamos controles en la red.

✔️Ubicar el control en la base de datos, lo que se llama control en la fuente.

# data[].attributes.body
Consiste en un proceso de monitoreo continuo y riguroso de los controles dentro de los sistemas de bases de datos y todos sus componentes mediante la utilización adecuada de los datos almacenados por usuarios en sistemas de informacion.

# data[].attributes.body
Existen tres posibilidades:

1) poner los controles en el nivel de las aplicaciones.

2) Ponerlos en medio de las apliaciones y base de datos.

3) Ubicar el control en la base de datos, lo que se llama control en la fuente.

# data[].attributes.body
DÓNDE UBICAR LOS CONTROLES

Los controles en las aplicaciones: Alternativa implica que a cada sistema, módulo o programa, se le debe adicionar

el control; esto implica modificaciones de código,

compilaciones de programas y otros procesos.

Los controles en la red: Esta alternativa tiene la

ventaja de un único control, ubicado en una posición

estratégica fácil de modificar y de administrar.

Control en la fuente: Con esta alternativa y en este caso sí es posible conocer los valores de los datos antes y después de la actualización.

# data[].attributes.body
TIPOS DE AUDITORÍAS DE BASES DE DATOS

Auditoría de actividades

Que consiste en controlar las actividades que realizan los usuarios en los objetos de la base de datos y entenderemos como objetos todas las tablas, vistas, restricciones de integridad que los usuarios crean en la base de datos.

Auditoría de transacciones

Permiten llevar una bitácora de todas las transacciones que los usuarios realizan, pero a un nivel tal que podamos establecer una historia de cómo se produjeron los cambios.

# data[].attributes.body
LA ADMINISTRACIÓN DEL REGISTRO DE AUDITORÍA

Es posible que tengan razón, y eviten con estas justificaciones establecer los controles, dejando la base de datos completamente vulnerable.

• Audite sólo lo necesario o sólo las excepciones.

• Haga respaldo y limpieza del RA y el RAT.

Actividades sospechosas

Esto se refiere que para empezar con el proceso de la auditoría, comenzamos a auditar todo tipo de acciones que realicen los usuarios.

# data[].attributes.body
HABILITANDO LA AUDITORÍA

El sistema gestor de la base de datos relacionales Oracle provee un conjunto de instrucciones SQL, a lo que llamamos script, que permite habilitar la auditoría de actividades.

Habilitar: CATAUDIT.SQL

Deshabilitar: CATNOAUDIT.SQL

Composición del RA de Oracle:

• Usuario.

• Sesión.

• Terminal.

• Nombre del objeto accesado.

• Operación realizada o intentada.

• Fecha y hora.

El RA permitirá saber:

• ¿Quién se conectó?

• ¿Cuándo se conectó?

• ¿Qué hizo en la base de datos?

• ¿Tuvo éxito o no?

• ¿Qué privilegios tenía?

• ¿Quién se los otorgó?

* Los tres niveles de auditoría de actividades

Para esto entonces desde una interfaz de usuario como el

SQL PLUS, el auditor escribe:

AUDIT SESSION BY ANA

Si se desea saber todas las consultas que hace Ana en las tablas a las que tiene derecho, escribimos:

AUDIT SELECT ANY TABLE

Si deseamos saber las transacciones que

realiza Ana, en cada tabla, y en que momento,

escribimos:

AUDIT INSERT TABLE, DELETE TABLE,

EXECUTE PROCEDURE BY ACCESS

WHENEVER NOT SUCCESSFUL

Consultando el registro de auditoría

Para realizar la consulta, se implementa una instrucción SQL como la siguiente:

SELECT * FROM

SYS.DBA_PRIV_AUDIT_OPTS

# data[].attributes.body
AUDITANDO LAS TRANSACCIONES

Supongamos que deseamos registrar todos

los cambios que se realizan en la tabla cuentas,

quién los realiza y cuándo los realiza. Para hacer

estos primeros cambios necesitamos crear nuestro

propio registro de auditoría.

La sentencia SQL para crear la tabla sería

la siguiente:

Create table RAT

( usuario varchar (10),

Fecha date,

Cliente varchar (6),

Saldo_anterior number (10,2)

Saldo_actual number (10,2) )

El TRIGGER, que se creará, sólo reaccionará

en el caso de que se haga una actualización, pero

es posible que reaccione a inserciones y borrados,

el código necesario es el siguiente:

Create trigger auditor

after update on cuentas

for each row

begin

insert into RAT

values ( user, date, :new.cliente,

:old.saldo, :new.saldo ) end

# data[].attributes.body
UN GRAN VIDEO DE AUDITORIA

# data[].attributes.headline
3. TIPOS DE AUDITORÍAS DE BASES DE DATOS

# data[].attributes.subject
3. TIPOS DE AUDITORÍAS DE BASES DE DATOS

# data[].attributes.body
3.1 Auditoría de actividades. Consiste en controlar las

actividades que realizan los usuarios en los objetos

de la base de datos, este proceso permite encontrar posibles accesos a objetos no autorizados. El registro de auditoría (RA) tiene un crecimiento muy alto, por lo que es necesario administrarlo adecuadamente.

3.2 Auditoría de transacciones. Consiste en

implementar una serie de controles que permiten

llevar una bitácora de todas las transacciones que los

usuarios realizan, es necesario crear el registro de auditoría de transacciones (RAT), su crecimiento es superior al RA

# data[].attributes.body
LA ADMINISTRACIÓN DEL REGISTRO DE AUDITORÍA

Se almacena en el RA y el RAT hace pensar en algunas organizaciones donde este control puede ser innecesario, que el costo de almacenamiento es muy alto, y el rendimiento de la base de datos se puede ver afectado.

• Audite sólo lo necesario o sólo las excepciones.

• Haga respaldo y limpieza del RA y el RAT.

Actividades sospechosas

Una guía adecuada cuando se requiere

auditar actividades sospechosas es, primero auditar en forma general y posteriormente auditar lo específico.

# data[].attributes.headline
4. LA ADMINISTRACIÓN DEL REGISTRO DE AUDITORÍA

# data[].attributes.subject
4. LA ADMINISTRACIÓN DEL REGISTRO DE AUDITORÍA

# data[].attributes.body
Se recomienda :

Audite sólo lo necesario o sólo las excepciones.

Haga respaldo y limpieza del RA y el RAT.

4.1 Actividades sospechosas.

Primero auditar en forma general y posteriormente auditar lo

específico.

# data[].attributes.body
HABILITANDO LA AUDITORÍA

Para habilitar la auditoría es necesario ejecutar algunas instrucciones que permitan crear una serie de procesos “espías” y el RA.

Habilitar: CATAUDIT.SQL

Deshabilitar: CATNOAUDIT.

SQL

Con este tipo de auditoría, no podemos

saber qué datos estaban involucrados, es decir, si

la acción del usuario genera un cambio en el saldo

de la cuenta de un cliente.

• Usuario.

• Sesión.

• Terminal.

• Nombre del objeto accesado.

• Operación realizada o intentada.

• Fecha y hora.

El RA permitirá saber:

• ¿Quién se conectó?

• ¿Cuándo se conectó?

• ¿Qué hizo en la base de datos?

• ¿Tuvo éxito o no?

• ¿Qué privilegios tenía?

• ¿Quién se los otorgó?

Los tres niveles de auditoría de actividades:

Supongamos que deseamos auditar las veces

en que Ana se conecta o se desconecta. Para esto

entonces desde una interfaz de usuario como el

SQL PLUS, el auditor escribe:

AUDIT SESSION BY ANA

Si se desea saber todas las consultas que

hace Ana en las tablas a las que tiene derecho,

escribimos:

AUDIT SELECT ANY TABLE

Si deseamos saber las transacciones que

realiza Ana, en cada tabla, y en que momento,

escribimos:

AUDIT INSERT TABLE, DELETE TABLE,

EXECUTE PROCEDURE BY ACCESS

WHENEVER NOT SUCCESSFUL

Consultando el registro de auditoría

El RA puede ser consultado por el usuario

que tenga el privilegio adecuado.

• SYS.DBA_PRIV_STMT_OPTS

• SYS.DBA_PRIV_AUDIT_OPTS

Para realizar la consulta, se implementa una

instrucción SQL como la siguiente:

SELECT * FROM

SYS.DBA_PRIV_AUDIT_OPTS

DESCRIBE de esta forma se detallan todas las columnas que

tiene la tabla.

DESCRIBE SYS.DBA_PRIV_AUDIT_

OPTS

# data[].attributes.body
AUDITANDO LAS TRANSACCIONES

La sentencia SQL para crear la tabla sería la siguiente:

Create table RAT

( usuario varchar (10),

Fecha date,

Cliente varchar (6),

Saldo_anterior number (10,2)

Saldo_actual number (10,2) )

Create trigger auditor

after update on cuentas

for each row

begin

insert into RAT

values ( user, date, :new.cliente,

:old.saldo, :new.saldo ) end

Considerando lo anterior debemos aplicar los siguientes consejos:

1. Utilice TRIGGER en tablas críticas.

2. Audite sólo transiciones relevantes.

3. Construya varios registros de auditoría, no

use solo uno.

4. Ubique los registros de auditoría en un

disco aparte de los discos de datos de los

sistemas.

5. Revise el tamaño del registro de auditoría.

6. Elimine información que ya no sea necesa-

ria.

7. Respalde en forma periódica.

# data[].attributes.body
Es necesario ejecutar algunas instrucciones que permitan crear una serie de procesos “espías” y el RA.

En el caso de Oracle, la habilitación requiere la ejecución de una secuencia de comandos SQL:

Habilitar: CATAUDIT.SQL

Deshabilitar: CATNOAUDIT.SQL

5.1 Composición del RA de Oracle. (udit.Trail, de Oracle)

• Usuario.

• Sesión.

• Terminal.

• Nombre del objeto accesado.

• Operación realizada o intentada.

• Fecha y hora.

El RA permitirá saber:

• ¿Quién se conectó?

• ¿Cuándo se conectó?

• ¿Qué hizo en la base de datos?

• ¿Tuvo éxito o no?

• ¿Qué privilegios tenía?

• ¿Quién se los otorgó?

5.1.1 Los tres niveles de auditoría de actividades

Estatutos SQL. Todas aquellas instrucciones de tipo SQL que podamos realizar(ej. inicio de sesión)

Privilegios. Permisos que se le otorgan a los usuarios para que realicen transacciones o consulten información.

Manipulaciones Directas Sobre Objetos. Como borrados, creaciones, modificaciones de objetos de usuario o de sistema.

Para auditar en Oracle es necesario contar con

el privilegio AUDIT SYSTEM, para que se pueda

habilitar o deshabilitar la auditoría.

5.1.2 Consultando el registro de auditoría

Para realizar las consultas en el RA se cuenta con varios tipos de vistas, como por ejemplo:

SYS.DBA_PRIV_STMT_OPTS

SYS.DBA_PRIV_AUDIT_OPTS

Para realizar la consulta, se implementa una

instrucción SQL como la siguiente:

SELECT * FROM

SYS.DBA_PRIV_AUDIT_OPTS

Si desea conocer la composición de alguna

de las tablas o vistas puede utilizar el comando:

DESCRIBE SYS.DBA_PRIV_AUDIT_

OPTS

# data[].attributes.body
Los sistemas gestores de bases de datos relacionales tienen un objeto especial llamado TRIGGER (desencadenador).

El TRIGGER consiste en un conjunto de sentencias SQL que se le adhieren a una tabla, con el propósito de que en caso que la tabla reciba una transacción se ejecutará y aplicará

las sentencias que tiene almacenadas.

Hay que tomar en cuenta que interfiere en el rendimiento de la transacción, aun así, si es necesario implementarlo de manera adecuada y moderada.

Consejos:

Utilice TRIGGER en tablas críticas.

Audite sólo transiciones relevantes.

Construya varios registros de auditoría, no use solo uno.

Ubique los registros de auditoría en un disco aparte de los discos de datos de los sistemas.

Revise el tamaño del registro de auditoría.

Elimine información que ya no sea necesaria.

Respalde en forma periódica.

# data[].attributes.body
Es necesario ejecutar algunas instrucciones que permitan crear una serie de procesos “espías” y el RA.5.1

# data[].attributes.body
5.1 Composición del RA de Oracle: El RA llamado Audit.Trail, de Oracle, puede contener diversos tipos de información. La información básica que encontramos es:

Usuario.

Sesión.

Terminal.

Nombre del objeto accesado.

Operación realizada o intentada.

Fecha y hora.

El RA permitirá saber:

¿Quién se conectó?

¿Cuándo se conectó?

¿Qué hizo en la base de datos?

¿Tuvo éxito o no?

¿Qué privilegios tenía?

¿Quién se los otorgó?

# data[].attributes.body
5.1.1 Los tres niveles de auditoría de actividades son:

Estatutos SQL: Son todas aquellas instrucciones de tipo SQL que podamos realizar.

Privilegios: Son los permisos que se le otorgan a los usuarios para que realicen transacciones o consulten información.

Objetos: Hace referencia a borrados, creaciones, modificaciones de objetos de usuario o de sistema.

# data[].attributes.body
5.1.2 Consultando el registro de auditoría:

El RA puede ser consultado por el usuario que tenga el privilegio adecuado. Para realizar las consultas se cuenta con varios tipos de vistas en el diccionario de datos, como por ejemplo:

• SYS.DBA_PRIV_STMT_OPTS

• SYS.DBA_PRIV_AUDIT_OPTS

-Para realizar la consulta, se implementa una

instrucción SQL como la siguiente:

SELECT * FROM

SYS.DBA_PRIV_AUDIT_OPTS

-Si desea conocer la composición de alguna

de las tablas o vistas:

DESCRIBE SYS.DBA_PRIV_AUDIT_OPTS

# data[].attributes.body
Los sistemas gestores de bases de datos relacionales tienen un objeto especial llamado TRIGGER (desencadenador), lo cual consiste en un conjunto de sentencias SQL que se le adhieren a una tabla, con el propósito de que en caso que la tabla reciba una transacción, el TRIGGER se ejecutará y aplicará las sentencias que tiene almacenadas.

# data[].attributes.body
3.1 Auditoría de actividades:

Consiste en controlar las actividades que realizan los

usuarios en los objetos de la base de datos.

3.2 Auditoría de transaciones:

Consiste en implementar una serie de controles que permiten llevar un registros detallado de todas las transacciones que los usuarios realizan.

# data[].attributes.headline
4. Administracion del registro de Auditoría

# data[].attributes.subject
4. Administracion del registro de Auditoría

# data[].attributes.body
4.1 Actividades sospechosas:

Una guía adecuada cuando se requiere

auditar actividades sospechosas es, primero

auditar en forma general y posteriormente auditar lo

específico.

# data[].attributes.body
Para habilitar la auditoría es necesario ejecutar

algunas instrucciones que permitan crear una

serie de procesos “espías” y el RA.

# data[].attributes.body
El RA llamado Audit.Trail, de Oracle, puede

contener diversos tipos de información.

La información básica que encontramos es:

Usuario.

• Sesión.

• Terminal.

• Nombre del objeto accesado.

• Operación realizada o intentada.

• Fecha y hora.

El RA permitirá saber:

• ¿Quién se conectó?

• ¿Cuándo se conectó?

• ¿Qué hizo en la base de datos?

• ¿Tuvo éxito o no?

• ¿Qué privilegios tenía?

• ¿Quién se los otorgó?

# data[].attributes.headline
5.1.1 Los tres niveles de auditoría de actividades son: 

# data[].attributes.subject
5.1.1 Los tres niveles de auditoría de actividades son: 

# data[].attributes.body
Estatutos SQL: Son aquellas intrucciones de tipo SQL que podemos realizar.

Privilegios: Son los permisos que se le otorgan a los usuarios para que realicen transacciones o consulten información.

Objetos: Hace referencia a borrados, creaciones, modificaciones de objetos de usuario o del sistema.

# data[].attributes.headline
5.1.2 Consultando el registro de auditoría

# data[].attributes.subject
5.1.2 Consultando el registro de auditoría

# data[].attributes.body
El RA puede ser consultado por el usuario

que tenga el privilegio adecuado. Para realizar las

consultas se cuenta con varios tipos de vistas en el

diccionario de datos, ejemplo:

• SYS.DBA_PRIV_STMT_OPTS

• SYS.DBA_PRIV_AUDIT_OPTS

Para poder realizar la consulta, se implementa una

instrucción SQL como la siguiente:

-SELECT * FROM

-SYS.DBA_PRIV_AUDIT_OPTS

Si desean conocer la composición de alguna

de las tablas o vista.

Describa:

DESCRIBE SYS.DBA_PRIV_AUDIT_OPTS

# data[].attributes.body
Los sistemas gestores de bases de datos

relacionales tienen un objeto especial llamado

TRIGGER (desencadenador), consistiendo en un conjunto de sentencias SQL que se le adhieren a una tabla, con el propósito de que en caso que la tabla reciba una transacción, el TRIGGER se ejecutará y aplicará las sentencias que tiene almacenadas.

# data[].attributes.body
Considerando lo anterior debemos aplicar los siguientes consejos:

1. Utilice TRIGGER en tablas críticas.

2. Audite sólo transiciones relevantes.

3. Construya varios registros de auditoría, no

use solo uno.

4. Ubique los registros de auditoría en un

disco aparte de los discos de datos de los

sistemas.

5. Revise el tamaño del registro de auditoría.

6. Elimine información que ya no sea necesaria.

7. Respalde en forma periódica.