Auditora de arquitecturas

En el captulo anterior aprendi acerca de las diversas categoras de auditora que puede que
tenga que implementar. Usted vio que la auditora del entorno de la base de datos no es un
ejercicio de todo o nada y que puede optar por auditar muchas categoras de datos y tipos de
acceso, dependiendo de los requisitos de seguridad y cumplimiento de su organizacin. En este
captulo explorar detalles arquitectnicos que le ayudarn a implementar una solucin de
auditora prctica y pragmtica y abordar los requisitos de seguridad y cumplimiento. Ver que no
basta con decidir qu eventos y elementos necesitan ser auditados, sino que tambin debe prestar
atencin a la arquitectura y atributos sistmicos de su solucin de auditora.
No crear una falsa sensacin de seguridad
La auditora es un medio, no un objetivo. El propsito de la auditora es elevar la seguridad y
acercarle ms al cumplimiento de las distintas polticas y regulaciones de seguridad. No hay
necesidad de auditora que est desprovista de tales impulsores comerciales. Por lo tanto,
independientemente de la solucin de auditora que elija implementar, asegrese de que le acerca
ms a estos objetivos.
Un error comn que la gente hace implica la creacin de pistas de auditora integral con el
propsito de crear pistas de auditora. Tener una pista de auditora no aumenta la seguridad a
menos que se use. Como ejemplo, tener un archivo de registro (o tabla de base de datos) que
contiene 20 millones de elementos de lnea cada da no aumenta la seguridad. De hecho, crea una
falsa sensacin de seguridad y al hacerlo, hace que su entorno sea menos seguro. Si sabe que su
entorno de base de datos no tiene provisiones de seguridad y auditora, entonces es ms probable
que preste atencin a anomalas y varios eventos extraos que lo hara si cree que tiene algn tipo
de marco de seguridad y auditora en su lugar.
La auditora, especialmente en un entorno de base de datos, implica una gran cantidad de
datos. Las bases de datos de produccin pueden crear grandes cantidades de datos granulares
(ms informacin ms adelante en este captulo). Si slo desea cruzar una tarea en algn plan de
proyecto, puede poner una solucin en el lugar que simplemente le ayuda a recopilar y archivar
esta informacin. Si esto es todo lo que hace, entonces est creando verdaderamente una falsa
sensacin de seguridad porque no ha creado un proceso mediante el cual utiliza la informacin de
auditora para mejorar la seguridad.
Con el fin de elevar la seguridad mediante la auditora, debe implementar una solucin pragmtica
y debe ser capaz de utilizar los datos que se recopilan a travs de los mecanismos de auditora. Los
datos no son tiles a menos que pueda extraer informacin procesable de los datos. En el caso de
la seguridad, esto significa que su solucin de auditora debe permitirle extraer la informacin
para exponer anomalas, intrusiones, errores, malas prcticas, violaciones de polticas, etc. Si no
puede explicarse a s mismo cmo estas (o al menos una de estas) metas pueden lograrse
utilizando los senderos de auditora, entonces su implementacin se convierte en parte del
problema en lugar de parte de la solucin.
Para no caer en este falso sentido de la trampa de seguridad, debe darse cuenta de que una
solucin de auditora (y por lo tanto la arquitectura puesta en marcha) tiene dos partes
importantes: la parte que recopila la informacin y la parte que utiliza la informacin. La
arquitectura de la solucin debe soportar eficazmente ambas, porque sin una u otra, su solucin
de auditora es ineficaz. Las secciones de este captulo exploran algunos de los atributos que su
arquitectura de auditora debe poseer para que la informacin se recopile correctamente y sea
utilizable, asegurndose de que su solucin de auditora le ayuda a alcanzar sus objetivos.
Opte por una pista de auditora independiente / de copia de seguridad.
Todas las bases de datos tienen funciones de auditora y puede crear pistas de auditora utilizando
cualquiera de las bases de datos. Adems, numerosas soluciones de terceros se centran en la
auditora y crean una pista de auditora basada en las actividades de la base de datos. Estos
sistemas son externos a la base de datos y auditan la actividad de la base de datos usando uno de
los tres mtodos descritos en la siguiente seccin. Sin embargo, independientemente del mtodo
que se utilice, en todos estos sistemas la pista de auditora es una pista de auditora externa e
independiente, en contraposicin a una pista de auditora creada por la base de datos.
Una pista de auditora independiente es ms valiosa que una pista de auditora creada por la base
de datos. Filosficamente, una pista de auditora independiente y externa est alineada con una
estrategia de defensa en profundidad. Tcnicamente, un camino independiente es ms difcil de
comprometer, no va a ser sensible a los errores y las vulnerabilidades que la base de datos puede
tener (que puede ser una de las razones para la auditora en primer lugar), y apoya mejor los
conceptos aprendidos en captulos anteriores como Como la separacin de funciones. Como
ejemplo, una pista de auditora basada en bases de datos que almacena la informacin de
auditora dentro de la base de datos bajo los auspicios del DBA carece de valor desde una
perspectiva de segregacin de funciones. Una pista de auditora independiente tambin es ms
probable que sea utilizable por personal no-DBA, lo que permite que el trabajo sea descargado de
la DBA y ayudar a los responsables de la seguridad de la informacin en su conjunto para hacer su
trabajo. Por ltimo, se puede utilizar una pista de auditora independiente junto con una pista de
auditora de base de datos para soportar entornos con rigurosos requisitos de seguridad y
cumplimiento. En este caso, los dos senderos de auditora pueden compararse continuamente
para asegurar su integridad y que uno de los senderos de auditora no ha sido comprometido.
Arquitecturas para sistemas de auditora externa.
Veamos tres mtodos para crear una pista de auditora externa. Los mtodos son aplicables a
todos los entornos de bases de datos porque las tres categoras son arquitectnicas y porque
todas las bases de datos utilizan comunicaciones en red, comunicacin interprocesos, registros de
transacciones (redo), etc. Las tres categoras arquitectnicas son las siguientes:

1. Inspeccin de estructuras de datos de bases de datos internas

2. Inspeccin de todas las comunicaciones con la base de datos
3. Inspeccin de elementos creados por la base de datos en el proceso de
funcionamiento normal.
Las bases de datos tienen estructuras de datos internas que se utilizan para procesar comandos,
almacenar resultados y as sucesivamente. Por ejemplo, Oracle tiene un conjunto de tablas
internas denominadas tablas X que se utilizan para almacenar SQL y procesarlo. El respaldo de
estas tablas es un conjunto de estructuras de memoria que pueden ser de ingeniera inversa (y en
realidad han sido diseadas de forma inversa por ms de un proveedor). Un mtodo para auditar
lo que la base de datos est haciendo implica inspeccionar estas estructuras de datos en
memoria. Para ello, el sistema de auditora debe compartir el mismo espacio de direcciones que la
base de datos, y la auditora se basa en sondear estas estructuras de datos. Esto se muestra en la
Figura 13.1 como Sistema de Auditora 1.

Una permutacin de este mtodo se muestra como Sistema de Auditora 2 en la Figura 13.1. En
algunas bases de datos, algunas de estas estructuras de datos internas se abstraen como tablas y
vistas visibles para el usuario. Como ejemplo, en Oracle esta informacin est disponible a travs
de las vistas V $. En lugar de realizar sondeos en la estructura interna de datos, un sistema de
auditora puede conectarse a la base de datos utilizando una cuenta de administrador y examinar
estas vistas / tablas. Tenga en cuenta que en ambos casos el sistema de auditora debe consultar
las estructuras de datos / vistas lo suficientemente rpido para no perder datos, pero no
demasiado rpido, para no sobrecargar la base de datos.
La segunda arquitectura de auditora implica inspeccionar todos los flujos de comunicacin que
son terminados por la base de datos. Una base de datos es un servidor que acepta peticiones de
conexin y, finalmente, todas las actividades se inician utilizando dichas conexiones. Por lo tanto,
mediante el seguimiento de estos flujos de comunicacin, puede auditar todo lo que la base de
datos se le pide que haga.
Las conexiones pueden ser locales o provienen de la red. Los clientes de base de datos se conectan
al proceso de base de datos utilizando protocolos de red o mediante mecanismos de
comunicacin entre procesos (IPC) si el cliente reside en el mismo servidor que la base de
datos. Un sistema de auditora que inspecciona las comunicaciones de la base de datos (ver Figura
13.2) puede utilizar la inspeccin basada en red (por ejemplo, inspeccin de paquetes) para
auditar todas las conexiones en red y utilizar una sonda ejecutndose en el sistema operativo local
para monitorear las comunicaciones IPC. Algunos sistemas de auditora le dan una flexibilidad
adicional en trminos de cmo se realiza la inspeccin de la red. Una opcin es utilizar
capacidades de red y dispositivos tales como conexiones de red, concentradores o duplicacin de
puertos de conmutacin. En el ltimo caso, el sistema de auditora utiliza instalaciones dentro de
un conmutador que crea paquetes espejo para cada paquete que se entrega a la base de datos o
utiliza el hecho de que puede leer promiscuamente los paquetes fuera del cable sin interferir con
los flujos de paquetes a la base de datos. El sistema de auditora puede incluso funcionar como un
puente de red de trabajo donde cada paquete fluye a travs del sistema de auditora. La opcin
basada en host es usar la sonda local para inspeccionar tambin el trfico de red. Este trfico llega
al sistema operativo donde est registrada la base de datos para estar escuchando ciertos
puertos. Por lo tanto, el trfico puede ser inspeccionado en este ltimo segmento por la sonda IPC
local. Todas estas opciones se muestran en la Figura 13.2.

Por ltimo, la tercera arquitectura de auditora utiliza los archivos que utiliza la base de datos en el
curso normal de su funcionamiento y extrae informacin relevante de ellos. El archivo ms obvio
es el registro de transacciones (o el registro de rehacer). En la mayora de las bases de datos, todas
las sentencias DDL y DML se escriben en el registro de transacciones, para que la base de datos
pueda recuperarse de un desastre y desplegar todas las transacciones comprometidas. Un sistema
de auditora que lee y procesa continuamente estas entradas puede crear una pista de auditora
para estos eventos de base de datos. Otros archivos tambin pueden ser utilizados por el sistema
de auditora para proporcionar una auditora ms completa que cubre todas las actividades de la
base de datos (o cerca de ella), pero esto depende de los mecanismos de base de datos que son
compatibles y si estn activos y generando tales Archivos externos. Este esquema se muestra en la
Figura 13.3.
Archivar informacin de auditora.
Dependiendo de las categoras de informacin de auditora que elija recopilar, es probable que
recoja grandes cantidades de datos. Esto es cierto para los tres mecanismos de auditora descritos
en la seccin anterior, ya que todo subyace en el hecho de que sus bases de datos suelen soportar
un gran nmero de llamadas SQL, todas las cuales pueden necesitar ser auditadas.
Su solucin de auditora es probablemente buena para almacenar esta informacin y hacerla
fcilmente disponible para su uso en informes, alertas y auditoras. Sin embargo, para que la
auditora sea sostenible, tambin tiene que verificar que su solucin de auditora se ocupa de las
capacidades de archivado y restauracin.
No subestime este problema. Debe comprender plenamente dnde se almacenan los datos de
auditora y cules son los volmenes en casos extremos. La consecuencia de los errores aqu
puede ser tan amplia como la parada de su base de datos. Por ejemplo, si utiliza la funcin de
auditora C2 de SQL Server, los archivos de auditora se guardan en el disco. Si no mueve estos
archivos del servidor, se llenar el disco con bastante rapidez. Cuando esto sucede, SQL Server
simplemente dejar de proporcionar cualquier servicio de base de datos.
En general, es mucho mejor no almacenar archivos de auditora en el servidor de base de datos. El
servidor de base de datos y el disco tienen mucho que hacer sin pedirles que tambin escriban
toda esta informacin de auditora. Independientemente de dnde se almacene la informacin de
auditora, debe tener una clara comprensin de la auditora de volmenes de datos y de lo que
deberan ser los programas de archivo.
Muchas regulaciones requieren que usted mantenga la informacin de auditora durante muchos
aos. Algunas regulaciones financieras requieren que usted mantenga los datos durante tres aos,
y HIPAA requiere que usted mantenga la informacin durante seis aos. Las polticas internas en
algunas organizaciones de servicios financieros incluso requieren la preservacin de estos datos
durante siete aos. En todos los casos, los nmeros son enormes. Un simple ejercicio le mostrar
lo mal que puede llegar a ser: digamos que usted hace 50 millones de peticiones SQL por da en
sus entornos de base de datos (y muchos entornos que incluyen muchas bases de datos hacen
mucho ms que eso). Suponga que tiene que auditar el 20% de estos (incluidos DML, DDL y SELECT
en objetos sensibles). Suponiendo (por simplicidad) que todos los das tienen la misma carga, esto
llega a ms de 3,5 millones de registros de auditora en un ao.
Para una solucin de auditora sostenible, necesitar archivar la informacin. Esto tambin
asegurar que los tiempos de respuesta para los informes y las consultas sean
razonables.Suponiendo que almacene la informacin archivada en un lugar y un formato que sea
fcilmente accesible para una posible investigacin, realmente no hay inconveniente en archivar
estos datos, y siempre debe buscar esta caracterstica para existir en una solucin adquirida o
buscar implementar esto Caracterstica en una solucin homegrown.
Los atributos importantes que debe asegurarse con respecto al archivado son los siguientes:

Permitir reglas flexibles que definen qu archivar, cundo y dnde.

Programe el archivado de una manera que garantice que sus datos en lnea sean lo
suficientemente buenos para todas sus actividades de informes. Por ejemplo, si necesita
crear informes de auditora y pistas de auditora para presentar a auditores y grupos de
seguridad de informacin, asegrese de no archivar antes de crear estos informes. Deje
suficiente holgura para apoyar la regeneracin de los informes. Por ejemplo, si crea
informes de auditora mensualmente, archive los datos que tengan tres meses de
antigedad para evitar tener que restaurar los datos en caso de que alguien vea un
informe y desee profundizar an ms.

Archivar los informes producidos y entregables, no slo los senderos de auditora

en bruto. En la mayora de los casos, es posible que necesite estos informes con ms
frecuencia que los datos sin procesar.

Archive de una manera que no crear una pesadilla cuando necesite restaurar
datos para una investigacin o para cumplimiento normativo. Cree un manifiesto para
informacin archivada e indexe la informacin archivada con al menos un intervalo de
fechas y una especificacin del servidor de base de datos. Este es el conjunto mnimo de
informacin que necesitar para identificar los archivos que necesita restaurar. Cualquier
otra indexacin que haga probablemente le ayudar en caso de que necesite devolver (por
ejemplo) datos que pertenezcan a un usuario de base de datos que es sospechoso.

Utilice una red de rea de almacenamiento corporativa (SAN), un almacenamiento

conectado en red (NAS) o una solucin de almacenamiento diseada especficamente para
archivar (por ejemplo Centera de EMC). Esto se encargar de cuestiones tales como copias
de seguridad y reducir su costo total y dolor de cabeza.
Informacin de auditora segura
Una vez que se ha encargado de archivar la informacin de auditora, tambin debe
asegurarse de que esta informacin est protegida. No puede almacenar informacin
archivada en un mtodo que permita a alguien manipularla y cambiarla. Tambin debe
protegerlo de miradas indiscretas porque la informacin, en muchos casos, incluir
informacin privada y sensible.
Su solucin de auditora debe tener buenas provisiones de seguridad, y esto es ms amplio
que asegurar los datos archivados. La seguridad de su solucin de auditora debe tener en
 cuenta los cuatro "lugares" donde puede residir la informacin de auditora (ver Figura
13.4):

1. El repositorio principal donde reside la informacin de auditora mientras se est

recopilando y utilizando.

2. Archivar archivos en el servidor de auditora

3. Archivar archivos en trnsito

4. Archivos archivados en la ubicacin de almacenamiento

Un sistema de auditora suele almacenar la informacin de auditora recopilada en una base de
datos. Esta base de datos debe estar protegida desde el acceso externo, necesita ser endurecida y
necesita ser vista como una base de datos de un solo usuario utilizada por el sistema de auditora
solamente. Si no es as, crea otro punto de vulnerabilidad, y necesitar abordar la cuestin de
seguridad y auditora para la base de datos de auditora. Con el fin de no entrar en este escenario
de bucle infinito, los sistemas de auditora readymade han sido diseados para hacer este almacn
interno de datos inherentemente seguro. Esto se hace generalmente bloqueando el acceso a la
base de datos de cualquier cosa aparte del sistema de auditora y aplicando estrictas polticas de
seguridad en esta base de datos interna.
El archivado de datos de pista de auditora normalmente es un proceso de dos pasos. En primer
lugar, los datos se extraen a un conjunto de archivos en el disco local y se purgan de la base de
datos de auditora. Estos datos se cifran y se firman digitalmente (consulte el Apndice del
Captulo 13.A para obtener una breve descripcin general de PGP y GPG, que a menudo se utilizan
en estos escenarios). Es necesario cifrar los datos, porque cuando se descarga a un rea de
almacenamiento externo, a menudo se pierde el control sobre quin tiene acceso a estos
archivos. Cifrar estos archivos para hacerlos intiles a cualquier sistema que no sea el sistema de
auditora (que puede restaurar los archivos, descifrarlos y poner la informacin disponible para el
sistema de auditora). Tambin debe asegurarse de que los archivos estn firmados digitalmente
por el sistema de auditora, lo que le permite probar que los archivos fueron creados por el
sistema de auditora, demostrar cundo se crearon y para qu entorno de base de datos. Esto es
importante en caso de una investigacin y otros escenarios en los que es necesario demostrar la
exactitud de sus datos y resultados.
Debido a que sus archivos de almacenamiento estn encriptados y firmados en el servidor de
auditora, la seguridad de los archivos en trnsito y la seguridad de los archivos almacenados no
deben ser una preocupacin en cuanto a que alguien intercepte los archivos y los utilice. Sin
embargo, debido a que las regulaciones y sus polticas internas pueden requerir que se asegure de
que los datos estn disponibles durante un perodo de tiempo determinado, debe asegurarse de
que las direcciones de la solucin aseguren que los archivos archivados lleguen a la ubicacin de
almacenamiento correcta y que Estar all cuando los necesite, muchos aos desde el momento de
su creacin. Esto implica una copia segura que obtiene un reconocimiento cuando los archivos
estn en la ubicacin de almacenamiento, la seguridad en la ubicacin de almacenamiento y las
copias de seguridad para garantizar que los archivos se pueden restaurar en la ubicacin de
almacenamiento en caso de que se eliminen o se pierdan.
Auditora del sistema de auditora
De la misma manera que debe asegurarse de que la informacin de auditora est asegurada,
tambin debe asegurarse de que tiene una pista de auditora completa a cualquier acceso y
cambios realizados a la informacin de auditora. Esto incluye tanto los datos como las
definiciones de auditora. Un ejemplo del primer tipo es un registro de auditora del hecho de que
un usuario del sistema de auditora produjo un informe que muestra todas las DDL que ocurrieron
en el ltimo mes. Ejemplos del segundo tipo incluyen registros de auditora del hecho de que un
usuario del sistema de auditora cambi la definicin de un informe de auditora y un informe de
evaluacin o un cronograma para producir y distribuir los informes de auditora (algunos ejemplos
se muestran en la Figura 13.5).
En ambos casos, necesita auditora en el mismo nivel que se implement para sus propias bases
de datos. Si est construyendo su propia solucin de auditora, asegrese de tener los ganchos
adecuados para registrar toda esta actividad. Si est utilizando un sistema de auditora
empaquetado, asegrese de que el sistema admita esta pista de auditora; Casi siempre se le har
esta pregunta por su gerente o su comit de auditora.
Automatizacin y supervisin sostenibles de las actividades de auditora
Crear una solucin de auditora sostenible requiere una arquitectura que le permita automatizar la
generacin y distribucin de materiales de auditora. No puede darse el lujo de confiar en un
proceso manual para asegurarse de que todas las personas adecuadas firmen en los informes y
evaluaciones de auditora; Esto debe ser apoyado por su arquitectura para que no tenga que estar
ocupado con el proceso. Por lo tanto, asegrese de que puede conectarse a alguna infraestructura
de flujo de trabajo corporativo fcilmente o utilizar un sistema de auditora que solucione este
problema.
La automatizacin es una parte importante de una solucin sostenible, pero tambin lo es la
supervisin. Puede tener el mejor sistema para automatizar la distribucin de los datos de
auditora, pero tambin debe asegurarse de que las personas estn revisando y firmando los
datos. Usted necesita asegurarse de que usted sabe si alguien no est manteniendo y no est
mirando los informes. Como ejemplo, un proceso de auditora puede definir que un informe DDL
primero debe ser revisado por el DBA y luego por el gerente de operaciones. El flujo de trabajo se
puede definir para entregar el informe al DBA, y slo una vez que es aprobado por el DBA va al
administrador de operaciones. En este caso, si el DBA no lo revisa y lo libera, el gerente de
operaciones nunca lo recibir.
Para evitar estos problemas, debe tener una supervisin integrada para el proceso de
auditora. Esta supervisin garantizar que las tareas de auditora se activen continuamente y que
los revisores no frenen los procesos. La supervisin puede ser pasiva o basada en la gestin de
excepciones. La supervisin pasiva significa que su sistema de auditora proporciona una forma de
informar sobre todos los procesos activos y cuntas revisiones pendientes / firmas estn
pendientes. Como ejemplo, los monitores mostrados en la Figura 13.6 muestran que el DBA tiene
muchos elementos que revisar y probablemente est manteniendo el proceso mientras los
usuarios de InfoSec y de auditora estn revisando las cosas tal como vienen.

La supervisin basada en la excepcin (o supervisin activa) no requiere que supervise

continuamente el estado del flujo de trabajo. En su lugar, recibe alertas cuando alguien est
deteniendo el proceso y no revisa los resultados de auditora. En este caso, puede configurar
umbrales que definen que las alertas se activarn cuando an no se hayan revisado demasiadas
tareas de auditora pendientes.
Piensa en trminos de un almacn de datos
Vamos a revisar la cantidad de datos que crear pistas de auditora completa. Si est ejecutando
bases de datos de alto rendimiento, habr muchas llamadas SQL y muchas llamadas a
procedimientos almacenados. En estos casos, el sistema de auditora tendr que almacenar y
procesar un gran nmero de registros para producir informes y otros entregables. Veamos varios
escenarios para entender cun grandes pueden ser estos nmeros.
Escenario I: Aplicacin bancaria en lnea
Un banco grande tiene una aplicacin de banca en lnea utilizada por ms de 10 millones de sus
clientes. La aplicacin permite a los usuarios iniciar sesin, ver sus saldos, descargar informacin
de la cuenta, transferir fondos y pagar facturas. Un usuario promedio inicia sesin en el sistema
dos veces por semana y realiza un promedio de 10 acciones, lo que se traduce en un promedio de
50 llamadas de base de datos. Por lo tanto, el acceso de usuarios crea alrededor de 140 millones
de llamadas SQL por da. El mantenimiento y las actividades de DBA son otra fuente de actividad,
pero desde una perspectiva de volumen esto es insignificante. Adems, los trabajos por lotes
funcionan cada noche y representan 40 millones de llamadas ms diarias. En general, la base de
datos soporta 185 millones de llamadas al da, lo que puede traducir a 185 millones de eventos
que pueden necesitar ser registrados por el sistema de auditora.
Escenario 2: Sistema de grandes call center
Una aerolnea mantiene un centro de llamadas para reservar y cambiar reservas. El centro de
llamadas emplea a 1.500 representantes de servicio al cliente (CSR). Cada CSR toma un promedio
de cinco minutos por cliente. El turno nocturno (ocho horas del da) emplea slo 500 RSE. El
servicio a un cliente implica un promedio de 20 llamadas a la base de datos. El nmero total de
llamadas generadas por el centro de llamadas por da es de alrededor de 6,7 millones. Interfaces y
programas de lotes representan casi un milln ms de llamadas, para un total de casi 8 millones de
registros potenciales de auditora por da.
Escenario 3: Empresa de medios medianos
Una empresa de medios de comunicacin tiene 23 bases de datos en toda la organizacin,
incluyendo aplicaciones de finanzas, aplicaciones de publicacin y otras. Se estableci una
iniciativa a nivel de toda la empresa para crear registros de auditora para todas las bases de datos
de la empresa mediante un sistema centralizado de auditora. El resultado es un rendimiento
combinado de casi 4 millones de registros de auditora por da.
Estos escenarios apuntan al hecho de que la auditora detallada crea grandes cantidades de
informacin que deben almacenarse. La mayora de los sistemas de auditora y las soluciones
locales ahorrarn estos datos dentro de una base de datos, permitindole obtener la informacin
y ejecutar cualquier consulta para inferir informacin de los datos. Dados estos nmeros, debe
quedar claro que la nica manera de administrar eficientemente esta cantidad de datos es
utilizando tcnicas comunes en el almacenamiento de datos.
El hecho es que cada base de datos de auditora es un gran almacn de datos de informacin de
acceso a bases de datos. Si no se preocupa de que el esquema utilizado para almacenar los datos
utilice diversas tcnicas de agregacin y de precomputacin, estar obligado a obtener tiempos de
respuesta incorrectos al generar informes y, por lo general, sufrir de falta de espacio en
disco. Por lo tanto, uno de los requisitos arquitectnicos que debe prestar atencin tiene que ver
con la eficiencia con la que estos datos se almacenan.
Implementar buenas herramientas de minera y aplicaciones de seguridad
Si slo mantiene los datos en un archivo plano o un esquema de base de datos ingenuo, no slo se
ejecutar en problemas de almacenamiento, pero los datos tambin no estarn disponibles
cuando lo necesite. Cada ejercicio de auditora se convertir inmediatamente en un ejercicio de
buscar una aguja en un pajar. Con una arquitectura de data warehouse, los datos son accesibles
desde las herramientas de generacin de informes y de minera de datos.
Dos tipos de herramientas sern tiles para hacer el mejor uso de la informacin de auditora. Las
herramientas pueden incluir herramientas genricas de generacin de informes como Crystal
Reports, Business Objects o incluso soluciones OLAP, que pueden ayudarle a crear entornos de
generacin de informes y minera ms eficientes. La segunda clase de herramientas est orientada
a la seguridad o la auditora y aporta valor aadido a las herramientas genricas de generacin de
informes. Estas herramientas ms especficas incluyen informes preempaquetados que se basan
en las mejores prcticas de auditora comunes, alertar aplicaciones que se pueden configurar para
notificarle cuando se producen desviaciones de una poltica y herramientas de base que le
permiten generar pistas de auditora que pueden compararse con auditoras anteriores
caminos. El objetivo principal de estas herramientas avanzadas es permitirle administrar por
excepcin. A nadie le gusta mirar pistas de auditora infinitas, y cuanto menos trabajo el sistema
de auditora requiere de usted (suponiendo que le ayudar a identificar y resolver problemas),
mejor. Cuando disee o evale una solucin de auditora, debera intentar imaginar su rutina
diaria, semanal o mensual al usar estas herramientas para ver si las herramientas le pueden salvar
de la desagradable tarea de revisar informes y rutas grandes.
Apoyar cambios en los requisitos de auditora
La auditora de la actividad de la base de datos impulsada por el cumplimiento y los auditores es
un fenmeno relativamente nuevo. Es el resultado del hecho de que las interpretaciones de varias
regulaciones se correlacionan directamente con mejores controles en el acceso a la base de datos
(como se menciona en el Captulo 11). Hasta hace unos aos, la auditora de la base de datos era
responsabilidad exclusiva del DBA y fue iniciada e implementada (en su caso) por el grupo de
bases de datos. Ahora, la iniciativa a menudo pertenece al grupo de seguridad y al grupo de
seguridad de la informacin.
Los auditores y los profesionales de la seguridad de la informacin rara vez tienen la misma
habilidad y nivel de conocimientos que tienen los DBAs. El resultado es una brecha semntica que
existe entre los requisitos establecidos por el personal de establecimiento de polticas y los que
tienen que implementar la solucin, como se muestra en la Figura 13.7. La historia ilustrada en la
figura 13.7 es la siguiente:

1. Las malas prcticas y las personas malas crean una realidad en la que los
reguladores exigen a las compaas que cumplan con diversas normas y reglamentos.

2. Los auditores, los grupos de seguridad de la informacin y los ejecutivos se dan

cuenta de que, debido a que gran parte de la informacin ms importante reside en las
bases de datos, deben implementar varias polticas de seguridad y auditora en entornos
de bases de datos.

3. Dado que en la mayora de las organizaciones los grupos de datos (y los DBA) son
propietarios de todos los aspectos de la base de datos, los responsables de las polticas
recurren a los DBA y requieren que activen la auditora a nivel de base de datos.
 4. La primera reaccin es el desconcierto completo; Despus de todo, qu es
exactamente lo que significan? Qu debemos auditar, con qu frecuencia, a qu nivel de
granularidad, y as sucesivamente?

5. Cuando estas preguntas son planteadas por los DBAs, los auditores rara vez tienen
la respuesta. Esto es parte de la auditora semntica / brecha de conocimiento.

6. A continuacin, los auditores suelen hacer algunos deberes y volver con una lista
muy larga de requisitos de auditora, que a menudo son poco prcticos (o ineficaces), y los
DBA no son tmidos al comentar sobre este hecho.

7. Desafortunadamente, los prximos meses (ya veces incluso aos) se pueden

dedicar a establecer requisitos, implementarlos, revisar los requisitos, volver a
implementarlos, ms cambios de requisitos, etc.
La conclusin es que debido a que hay mltiples partes con distintos niveles de conocimiento
involucrados en este ejercicio y porque las regulaciones son bastante nuevas y sus
interpretaciones siguen evolucionando, los requisitos de auditora son dinmicos y estn
cambiando constantemente. Si est poniendo una solucin en su lugar, asegrese de que puede
adaptarse a los requisitos cambiantes rpidamente y que tales cambios no le vuelven loco o crear
la misma cantidad de trabajo cada vez que cambian.
En trminos arquitectnicos orientados a la flexibilidad, hay dos categoras principales de auditora
de bases de datos:

1. Auditora que se basa en la recopilacin de toda la informacin y la produccin de

informes segn lo definido por los requisitos

2. Auditora que recopila informacin segn lo definido por los requisitos

De los dos, la primera opcin es ms resistente a los requisitos cambiantes. Si est recopilando
todos los datos, es muy poco lo que necesita hacer cuando los requisitos cambian ~ es
simplemente un cambio en las definiciones del informe. Incluso puede apoyar un ejercicio de
exploracin y ensayo y error para ayudar a afectar los requisitos. La segunda opcin requiere
mucho ms trabajo porque tendr que cambiar casi todo cada vez que cambien los requisitos,
volver a probar todo, rehacer las estimaciones de tamao, etc. La compensacin es que el segundo
enfoque requiere recolectar menos informacin. Por lo tanto, puede optar por utilizar un enfoque
combinado en el que recoja toda la informacin para las categoras de auditora que no se han
solidificado todava y el segundo enfoque para las reas con requisitos estables.
Preferir una arquitectura de auditora que tambin es capaz de soportar la remediacin.
Por ltimo, recuerde que la auditora es un medio para un fin, no una meta. Nadie quiere recopilar
una gran cantidad de datos simplemente con el propsito de recolectar datos. A nadie le gusta
tamizar a travs de registros largos y revisar informes tediosos. Por otra parte, nadie quiere
descubrir problemas serios a menos que estos problemas puedan tambin ser resueltos
(preferiblemente al mismo tiempo). De hecho, la mayora de la gente prefiere no saber acerca de
sus problemas en absoluto a menos que tengan una manera simple y eficaz para resolver los
problemas.
Por lo tanto, una solucin arquitectnica que no slo las auditoras, pero tambin puede definir y
hacer cumplir una poltica y que ayuda a resolver los problemas que se identifican a travs de las
actividades de auditora es superior a un sistema de auditora independiente. La auditora de bases
de datos es ms efectiva si forma parte de una solucin de seguridad de bases de datos; Junto con
el hecho de que usted ya vio que la auditora es una parte integral de la seguridad de la base de
datos, puedo reiterar que la auditora de la base de datos y la seguridad de la base de datos son
ms eficaces cuando se entregan y se implementan en tndem.
Resumen
En este captulo explor los atributos arquitectnicos de una buena implementacin de
auditora. Aprendi que la auditora -como cualquier otra solucin- debe poseer algunas
caractersticas para hacerlo efectivo. Junto con el Captulo 12, esta informacin cubre todo lo que
necesita para utilizar la auditora para abordar los requisitos de seguridad y cumplimiento que
puede estar enfrentando en su entorno de base de datos.
En este captulo se concluye la segunda parte de este libro que se centra en la auditora. Este es
tambin el ltimo captulo de este libro, y junto con los captulos 1 a 10, que se ocupa de los temas
que hay que saber en la aplicacin de seguridad de base de datos eficaz y auditora.
Me gustara darle las gracias por la lectura de este libro. Espero que los captulos de este libro
ayud a obtener una mejor comprensin de la seguridad de base de datos. Tambin espero que
usted aprendi los mtodos y tcnicas que le pueden ayudar en su trabajo del da a da y que el
libro logr mantener un equilibrio entre las tcnicas y patrones que se pueden utilizar en todos los
entornos de bases de datos se refiera especficamente e incluyendo ejemplos reales suficientes
para hacer las tcnicas concretas e inmediatamente utilizable. Por ltimo, espero mucho que
hayan disfrutado de la lectura de este libro y que va a aplicar muchas de las tcnicas descritas en
este libro para hacer de este un mundo mejor y ms seguro.
PGP y GPG.
Pretty Good Privacy (PGP) fue desarrollado en 1990 con el RivestShamir-Adleman (RSA) sistema de
cifrado de clave pblica para responder a la necesidad de comunicaciones privadas y seguras entre
las personas de ms de un medio digital. PGP fue lanzado al pblico en 1991 y rpidamente se
convirti en el estndar de facto en todo el mundo para el cifrado de clave pblica segura. GNU
Privacy Guard, o GnuPG (GPG), es el equivalente de cdigo abierto de PGP y fue liberado bajo la
Licencia Pblica GNU (GPL). PGP y GPG se utilizan ampliamente para una variedad de tareas,
incluyendo la firma y el cifrado de documentos presentados a los socios comerciales, el cifrado de
archivos locales, la firma de los archivos y registros para los propsitos de no rechazo, la firma de
los correos electrnicos y archivos, y as sucesivamente.
De los dos, PGP ha sido por ms tiempo, pero es cada vez menos popular que GPG. GPG es de
cdigo abierto, por lo que es atractivo para los usuarios y empresas. GPG es totalmente
compatible con OpenPGP y fue construido desde cero a partir de cero. No utiliza de forma nativa
algoritmos patentados, es compatible con una amplia gama de tecnologas de cifrado actuales,
est construido para integrarse fcilmente con las futuras tecnologas de cifrado y descifra y
verifica las versiones de PGP 5.x, 6.x, 7.x y mensajes. Yo personalmente uso de GPG, por lo que los
ejemplos que se muestran de la siguiente se basan en GPG.
ws se basan en GPG. PGP y GPG se basan en el cifrado de clave pblica. Tras observar cmo
funciona clave pblica de cifrado en el captulo 10. Se basa en un par de claves: una clave,
mantenga privada, se utiliza para descifrar o firmar la informacin, y la otra clave es pblica y se
utiliza para cifrar los datos o verificar la firma. Tanto PGP y GPG pueden soportar varios algoritmos
de cifrado, que utilizan anillos de claves para mantener sus claves privadas y pblicas. Sus claves
secretas estn protegidos por las frases de contrasea que slo usted conozca y deben
mantenerse segura. La clave pblica, que puede ser distribuido libremente, da instrucciones al
GPG o aplicacin PGP cmo cifrar los datos, despus de lo cual solamente su clave privada puede
descifrarlo.
Con el fin de crear un par de claves, utilice el siguiente comando:
gpg --gen-clave
GPG le preguntar varias preguntas, entre ellas qu fin va a utilizar la tecla de (firma, el cifrado, o
ambos), lo tamao de la clave que desea, lo que debera ser la fecha de caducidad, as como la
informacin tal como su nombre, e- electrnico, y un comentario opcional (mis respuestas estn
en cursiva):