Muchos clientes necesitan definir requisitos, pero elaborar un buen documento de requisitos para la auditoría de bases de datos no es sencillo. La razón es que los clientes que son nuevos en el mundo de la auditoría de bases de datos probablemente no sean conscientes de las dificultades y limitaciones que tienen los productos y elaboren documentos de requisitos que no los protegen de tales limitaciones.
Para superar esto, muchos clientes optan por copiar total o parcialmente los requisitos de diversas fuentes. Esto da lugar a documentos que están excesivamente adaptados a productos concretos y que exigen cosas que el cliente no necesita ni desea.
El asistente de requisitos
Este asistente de requisitos le permitirá seleccionar los requisitos que le resulten relevantes y le explicará cuándo y por qué cada requisito es importante. Además, es completamente anónimo y no envía ninguna información a Blue Core Research. Cuando haya terminado, podrá guardar o copiar el resultado, pero Blue Core Research no tendrá conocimiento de sus elecciones ni de los requisitos resultantes.
Expanda cada elemento a continuación y seleccione los requisitos que le resulten relevantes. A medida que seleccione los elementos, se creará el documento en la parte inferior. Cuando haya terminado, pulse el botón de impresión en la parte inferior y podrá guardar el documento que ha creado.
Fuentes de actividad
Puede parecer una tontería especificar cada tipo de fuente de actividad que necesita auditar, pero muchas tecnologías tienen limitaciones en cuanto al tipo de actividades que pueden auditar. Por lo tanto, debe especificar exactamente qué tipo de actividad necesita que audite la solución de auditoría.
Actividad local
Algunas soluciones tienen limitaciones a la hora de capturar la actividad de la base de datos local. Esto significa que si un administrador de bases de datos (DBA) o un atacante ha iniciado sesión en el equipo de la base de datos, la solución no podrá ver su actividad en la base de datos. Algunas soluciones tienen diferentes limitaciones de rendimiento u otras limitaciones a la hora de capturar la actividad local. Si la actividad local es importante, debe especificarla.
La solución debe ser capaz de capturar la actividad local de la base de datos. Cualquier conexión que se origine en la máquina de la base de datos y se conecte localmente a la base de datos debe ser auditada. Todos los requisitos de esta solicitud de propuesta, incluidos los requisitos de rendimiento, deben cumplirse cuando se captura la actividad local de la base de datos.
DBA y actividad privilegiada
Algunas soluciones tienen limitaciones a la hora de supervisar la actividad privilegiada. En ocasiones, la actividad privilegiada no se audita para determinados usuarios privilegiados. Otras veces, los usuarios privilegiados pueden impedir que se audite su actividad o eliminarla posteriormente del registro de auditoría. En algunas implementaciones, los DBA implementan las reglas de auditoría que se utilizan para auditarlos. Si la actividad privilegiada es importante, debe especificarla.
La solución debe capturar la actividad de todas las cuentas de DBA y privilegiadas, incluidas las cuentas de bases de datos integradas. Los DBA no deben ser una parte necesaria en la implementación de reglas y políticas de auditoría. Los usuarios privilegiados no deben poder impedir que se audite su actividad y no deben poder eliminar ni alterar sus registros de actividad.
Actividad cifrada
Algunas soluciones no admiten la auditoría de conexiones cifradas a bases de datos. Otras requieren componentes adicionales para admitir el cifrado de red, lo que puede suponer una mayor complejidad, instalación y coste. Si actualmente utiliza el cifrado de red en sus bases de datos o tiene previsto hacerlo en el futuro, debe especificarlo. Además, tenga en cuenta que algunas bases de datos siempre permiten conexiones cifradas y, si desea auditar esas conexiones, necesitará compatibilidad con el cifrado de red.
La solución debe ser capaz de auditar las conexiones cifradas a bases de datos. Todas las funciones necesarias deben estar disponibles cuando el tráfico de red de la base de datos esté cifrado.
Actividad interna de la base de datos
Los usuarios pueden generar actividad dentro de la base de datos. Dicha actividad puede ser generada por procedimientos almacenados, disparadores o bloques anónimos. Esto es especialmente importante a la hora de auditar a los administradores de bases de datos, ya que siempre tienen la capacidad de generar dicha actividad. También es importante en SQL Server, donde es habitual que las aplicaciones utilicen procedimientos almacenados. Muchas soluciones no pueden capturar la actividad interna de la base de datos.
La solución debe ser capaz de capturar actividades internas de la base de datos, como las generadas dentro de procedimientos almacenados, desencadenadores y bloques anónimos. La solución debe ser capaz de capturar SQL generados dinámicamente (por ejemplo, utilizando «execute immediate» en Oracle o «exec(“sql”)» en SQL Server).
Actividad por lotes/bloques
En muchas bases de datos, es posible enviar varias sentencias SQL a la vez. Por ejemplo, en Oracle, esto se puede hacer con un bloque begin/end, y en SQL Server se denomina lote y es la forma habitual de enviar sentencias SQL. Identificar sentencias SQL individuales en un lote es especialmente importante a la hora de auditar a los administradores de bases de datos, ya que suelen crear este tipo de lotes. Si no se pueden identificar las sentencias SQL individuales, puede resultar difícil o imposible escribir reglas de auditoría para ellas. Esto es especialmente importante en SQL Server, ya que T-SQL no requiere separadores entre sentencias SQL consecutivas en un lote.
La solución debe ser capaz de identificar y auditar sentencias SQL individuales en bloques y lotes.
SQL de ejecución corta
Algunas soluciones tienen dificultades para capturar SQL que se ejecutan rápidamente. Sin embargo, en las auditorías de seguridad, los SQL de ejecución rápida suelen ser los más problemáticos. Los SQL de ejecución larga suelen proceder de informes o de una actividad intensa de las aplicaciones y son más importantes para el ajuste del rendimiento que para la seguridad. Si considera que los SQL de ejecución corta son importantes, debe especificarlo.
La solución debe ser capaz de auditar todos los SQL, independientemente de la rapidez con la que se ejecuten o del orden en que lo hagan.
Sobrecarga/Overhead de la base de datos
Una de las mayores preocupaciones en la auditoría de bases de datos es el impacto en el rendimiento de la base de datos. Dependiendo de la tecnología, ese impacto puede afectar a diferentes recursos.
Cobertura
La tecnología Core Audit Full Capture captura siempre toda la actividad de la base de datos y lo hace con una sobrecarga extremadamente baja. Sin embargo, algunas tecnologías con sobrecargas más altas pueden reducir esa sobrecarga limitando la actividad que se captura. Por lo tanto, es importante definir lo que se espera capturar según las directrices de sobrecarga que usted especifique. Edite esta sección para reflejar sus necesidades.
Todos los requisitos de este documento, y en concreto los requisitos de sobrecarga, son para auditar [toda] la actividad de la base de datos en una base de datos que ejecuta aproximadamente [10 000] SQL por segundo y utiliza un ancho de banda de red de aproximadamente [1 gbit].
CPU
La sobrecarga de la CPU es la sobrecarga más conocida y es importante definir límites. Algunas soluciones pueden ocultar su sobrecarga en los controladores del núcleo.
Al auditar la actividad definida anteriormente, la solución no creará una sobrecarga superior al 5 % de la potencia de la CPU disponible en la máquina de la base de datos. Este requisito de sobrecarga se aplica a todos los componentes de software de la solución, incluidos los controladores del núcleo.
Red
Las soluciones de auditoría de bases de datos generan una sobrecarga de red tan grande que requieren la instalación de una tarjeta de red adicional en el equipo que aloja la base de datos. Si estos requisitos suponen un problema en su entorno, debe especificar unos límites.
Al auditar la actividad definida anteriormente, la solución no consumirá más del 5 % del ancho de banda de red de la base de datos.
Latencia
Algunas soluciones de auditoría de bases de datos generan latencia. La latencia es un retraso en la comunicación con la máquina de la base de datos y viceversa. Incluso una latencia pequeña puede acumularse y ralentizar significativamente las aplicaciones comunicativas que envían un gran número de consultas SQL cortas. Esto es especialmente común en algunos sistemas OLTP.
Las soluciones de proxy inverso son un ejemplo de soluciones que introducen latencia. Algunas soluciones solo introducen latencia cuando funcionan en determinados modos. Es difícil definir límites de latencia, ya que su efecto depende de la «chatter» de la aplicación. Si considera que la latencia es un problema, no debería permitirla.
Al auditar todas las fuentes de actividad y proporcionar todas las funciones requeridas por este documento, la solución no debería causar ninguna latencia en la comunicación con la base de datos.
Valor inmediato
Una característica importante para muchos clientes es el valor inmediato. En otras palabras, ¿cuánto esfuerzo se necesita para satisfacer sus necesidades básicas? La pregunta nos lleva de vuelta a la definición de las necesidades básicas, pero a continuación se incluye una breve lista de las necesidades básicas que requieren la mayoría de los clientes. Añada requisitos adicionales en función de sus necesidades. Core Audit utiliza asistentes para ayudar a conseguir valor inmediato, y estos requisitos proceden de los cuatro asistentes más utilizados.
Sesiones
La auditoría de sesiones es la auditoría de inicios de sesión correctos y fallidos. Es muy habitual solicitar este tipo de informes.
La solución nos permitirá configurar rápidamente políticas e informes sobre inicios de sesión correctos y fallidos en la base de datos.
Administradores de bases de datos (DBA) y usuarios con privilegios
La auditoría de la actividad de los administradores de bases de datos (DBA) y los usuarios con privilegios es uno de los requisitos más comunes. Dado que los DBA rara vez ejecutan DML, resulta útil poder separar la actividad DML.
La solución nos permitirá configurar rápidamente políticas e informes sobre la actividad de las cuentas de administradores de bases de datos y usuarios con privilegios. Los informes deben incluir un informe separado para la actividad DML.
Acceso a tablas confidenciales
La auditoría del acceso a tablas confidenciales es un requisito muy común.
La solución nos permitirá configurar rápidamente políticas e informes que supervisen el acceso a tablas confidenciales.
DDL y DCL
Un requisito muy común es auditar los DDL (cambios en los metadatos de la base de datos), tales como la creación o modificación de la estructura de las tablas. En algunos casos, se utiliza el término DCL para diferenciar una categoría de DDL que se ocupa del sistema de autenticación y autorización.
La solución nos permitirá configurar rápidamente políticas e informes que supervisen los DDL, así como informes especiales sobre los DCL (DDL relacionados con la autenticación y la autorización).
Informes, alertas e integración
Los informes y las alertas son la funcionalidad más importante para muchos clientes. Como resultado, es la funcionalidad mejor soportada en la mayoría de los productos. Es importante especificar lo que se necesita lograr, pero es muy probable que la mayoría de las soluciones puedan lograrlo.
Listo para usar
Un requisito habitual es disponer de informes y alertas listos para usar que se puedan personalizar fácilmente para el entorno supervisado.
La solución incluirá informes y alertas listos para usar que se pueden personalizar fácilmente para el entorno supervisado.
Fácil de personalizar
Cada base de datos es diferente, lo que significa que los informes y las alertas siempre deben personalizarse para adaptarse al entorno supervisado. Además, cada responsable de cumplimiento normativo o auditor puede requerir información diferente para cumplir con la normativa. Con el tiempo, tanto los entornos como los requisitos cambian, lo que hace necesario realizar ajustes adicionales. Para evitar una inversión significativa de tiempo y dinero, es posible que se requiera que los informes y las alertas se puedan personalizar fácilmente.
Los informes y las alertas deben ser fáciles de personalizar para adaptarse a nuestro entorno y a los requisitos de cumplimiento. La personalización debe incluir el control tanto de los datos que se muestran como de los filtros de los datos. La personalización debe ser posible tanto durante la configuración inicial como de forma continua, según sea necesario.
Informes
El cumplimiento normativo suele requerir informes sobre diversos aspectos de la actividad en el entorno supervisado. Los informes sirven como registro documental que demuestra que el entorno se ha supervisado de forma regular. Si necesita auditar la base de datos con fines de cumplimiento normativo, necesitará informes que se generen automáticamente.
La solución debe ser capaz de generar automáticamente informes sobre todos los aspectos del entorno supervisado que se hayan detallado previamente. La solución debe tener una capacidad integrada para programar automáticamente estos informes y debe incluir todos los componentes necesarios para esta generación automática.
Alertas
Un requisito común es que las soluciones envíen alertas. Las alertas tienen dos propósitos principales: (a) ser notificado tan pronto como ocurra algo sin esperar al siguiente informe y (b) supervisar un gran número de aspectos sin recibir un gran número de informes diarios. Las alertas pueden lograr esto cuando los filtros están configurados de manera que normalmente no producen resultados, pero requieren que la alerta sea detallada e incluya toda la información relevante.
La solución debe ser capaz de generar alertas sobre todos los aspectos del entorno supervisado que se han detallado previamente. La solución debe tener una capacidad integrada para generar automáticamente estas alertas y debe incluir todos los componentes necesarios para ello. Las alertas deben ser detalladas e incluir todos los detalles de la actividad relevante.
Entrega por correo electrónico
Muchos clientes requieren que los informes y las alertas se envíen por correo electrónico.
La solución debe poder enviar todos los informes y alertas por correo electrónico.
Formatos de archivo de los informes
Algunos clientes necesitan que los informes se proporcionen en formatos de archivo específicos, como html, PDF y csv. Si tiene estos requisitos, especifique los formatos de archivo pertinentes.
La solución debe poder generar informes en formatos de archivo html, PDF y csv.
Gestión de informes
Algunos clientes desean que las soluciones de auditoría incluyan capacidades de gestión de informes. Las capacidades de gestión de informes permiten a los usuarios de la solución revisar informes y alertas, clasificarlos (por ejemplo, revisados, requieren más acciones, etc.) y conservarlos de forma organizada. Esto no es una alternativa a un sistema adecuado de gestión de tickets, sino simplemente una forma de gestionar el volumen de informes.
La solución debe incluir un sistema de gestión de informes que pueda clasificar los informes y las alertas en varias categorías personalizadas y conservarlos durante largos periodos de tiempo.
SIEM y Syslog
Algunos clientes desean integrar la auditoría de bases de datos en su solución SIEM. Normalmente, SIEM acepta información a través del protocolo Syslog. Aunque ningún SIEM puede gestionar la carga de toda la actividad de auditoría de bases de datos, sí pueden gestionar el reenvío de un pequeño número de eventos específicos.
La solución debe poder reenviar eventos específicos directamente a un sistema SIEM a través del protocolo Syslog. La solución debe permitir la personalización de los eventos reenviados al sistema SIEM para incluir cualquier evento que pueda ser objeto de un informe o una alerta.
Acciones personalizadas e integración
Algunos clientes requieren otras integraciones, acciones o reacciones automáticas. Algunos ejemplos son el envío de trampas SNMP, la ejecución de scripts que puedan reaccionar ante amenazas graves de seguridad, notificaciones personalizadas y mucho más. Si tiene en mente acciones o integraciones específicas, por favor, especifíquelas. El lenguaje incluido en esta sección es adecuado si, en general, desea tener la opción de realizar dichas integraciones.
La solución debe ser capaz de ejecutar scripts personalizados en respuesta a informes o alertas. Los scripts deben recibir la información del informe o la alerta, lo que les permite integrarse libremente con cualquier sistema externo o reaccionar a la situación en consecuencia.
Investigaciones forenses
Las capacidades forenses en la auditoría de bases de datos pueden servir para dos fines importantes y distintos. El primero y más obvio es reactivo. Eso significa que en respuesta a una infracción, un evento sospechoso, una notificación, etc. El segundo, que es igual de importante, es proactivo. Eso significa que para comprender la actividad, planificar los controles (políticas e informes), identificar las deficiencias en los controles, etc.
Análisis forense de sesiones
El análisis forense de sesiones tiene como objetivo inspeccionar quién ha iniciado sesión en la base de datos, cuándo y desde dónde. También tiene como objetivo inspeccionar los intentos fallidos de inicio de sesión. Se trata de la visión más básica de las solicitudes de acceso a la base de datos.
La solución debe permitir investigar quién ha iniciado sesión en la base de datos, cuándo y desde dónde.
Análisis forense de SQL: auditoría declarativa
La auditoría declarativa consiste en que la solución registre la actividad basándose en las reglas especificadas por el cliente. Por ejemplo, registrar DDL, actividades privilegiadas, determinadas IP o programas, etc. Esta actividad suele ser objeto de informes, pero también es importante poder proporcionar capacidades forenses.
La solución debe permitir investigar toda la actividad registrada en la base de datos, tanto por sesión como entre sesiones. La solución también debe poder asociar cada actividad con la sesión que la realizó y proporcionar toda la información de la sesión.
Todas las actividades: análisis forense de fuentes
Además de la auditoría declarativa, Core Audit también contiene información agregada sobre todas las fuentes de actividad. Este tipo de análisis forense es muy útil para saber dónde y cuándo se ejecutó la actividad. Si considera que esto es importante, debe solicitarlo.
La solución debe permitir investigar desde dónde se ejecutó cualquier actividad en las bases de datos. Esta investigación debe permitir examinar todas las cuentas, programas, direcciones IP, etc. que ejecutaron la actividad en la base de datos. La investigación debe permitir averiguar cuándo se ejecutó la actividad desde cada fuente de actividad o combinación de fuentes (por ejemplo, una combinación de usuario y programa).
Toda la actividad: análisis forense de SQL
Otra potente agregación disponible en Core Audit, además de la auditoría declarativa, es la relativa a toda la actividad de la base de datos. Este tipo de análisis forense es muy útil para saber qué construcción SQL se ejecutó, quién la ejecutó y cuándo. Si considera que esto es importante, debe solicitarlo.
La solución debe permitir investigar todas las construcciones SQL que se ejecutaron en la base de datos, quién las ejecutó y cuándo. Esta investigación debe permitir examinar todas las cuentas, programas y actividades que se ejecutaron en la base de datos. La investigación debe permitir averiguar qué construcción SQL se ejecutó, desde qué usuario y programa, y cuándo.
Investigación forense gráfica
Las investigaciones forenses suelen realizarse con tablas que contienen una gran cantidad de información. Sin embargo, a menudo resulta útil poder realizar investigaciones gráficas utilizando gráficos de línea temporal, gráficos circulares, gráficos de barras, etc. Estos son útiles tanto para comprender los datos como para presentarlos a otras personas.
La solución debe mostrar al menos parte de la información forense mediante gráficos y tablas que permitan comprender la información de forma más rápida y sencilla, y localizar rápidamente posibles problemas de seguridad.
Automatización
A diferencia de la auditoría declarativa, que registra todo lo que se configura en las políticas, la automatización tiene como objetivo identificar actividades sospechosas y señalárselas al usuario. Existen muchas tecnologías que pueden utilizarse para la automatización, por lo que es difícil redactar requisitos independientes del producto. Sin embargo, es posible especificar ciertos tipos de actividades inusuales que se espera que la automatización identifique, teniendo en cuenta que es probable que pueda hacer mucho más.
Detectar nuevas cuentas
Una expectativa sencilla es poder identificar cuándo una nueva cuenta se conecta a la base de datos. A veces las cuentas son de nueva creación y otras veces son antiguas y están inactivas. Sin embargo, cuando se observa actividad en una cuenta que no se ha conectado recientemente a la base de datos, es razonable que la automatización le avise de la situación.
La solución debe incluir una automatización que avise al cliente cuando haya actividad en una cuenta que no ha estado activa recientemente.
Detectar nuevas máquinas/IP
Una expectativa similar a la de las cuentas nuevas es recibir una alerta cuando haya actividad en una máquina o dirección IP que no ha estado activa recientemente.
La solución debe incluir una automatización que avise al cliente cuando haya actividad en una máquina o dirección IP que no ha estado activa recientemente.
Detectar nuevos programas
Otra dimensión importante para identificar nuevas actividades son los programas. Debe recibir una alerta cuando haya actividad de un programa que no haya estado activo recientemente.
La solución debe incluir una automatización que alerte al cliente cuando haya actividad de un programa que no haya estado activo recientemente.
Detectar nuevas fuentes de conexión
Un requisito ligeramente más complejo es identificar nuevas actividades a partir de una combinación de fuentes de actividad. Por ejemplo, un usuario que ha estado activo recientemente y un programa que ha estado activo recientemente, pero ese usuario no ha utilizado ese programa recientemente.
La solución debe incluir una automatización que alerte al cliente cuando haya actividad de una combinación de usuarios, programas y máquinas/IP que no hayan estado activos recientemente. Por ejemplo, si un usuario utiliza un programa que no ha utilizado recientemente o se conecta desde una máquina o dirección IP desde la que no se ha conectado recientemente.
Detectar posibles inyecciones SQL
Un requisito más complicado es identificar posibles inyecciones SQL. En Core Audit, esto se puede generalizar a cualquier construcción SQL sospechosa, pero, como mínimo, la solución debe contar con alguna tecnología que alerte de una posible inyección SQL.
La solución debe incluir una automatización que alerte al cliente cuando haya una posible inyección SQL desde la aplicación.
Detectar anomalías en el tiempo de actividad
Otro tipo de actividad que debería llamar la atención es la actividad en un momento inusual del día. Por ejemplo, un usuario que normalmente trabaja de 9 a 5 ejecutando algo a medianoche.
La solución debe contener una automatización que alerte al cliente cuando un usuario, programa, máquina/IP o combinación de estos esté activo en un momento inusual del día en relación con su perfil de actividad reciente.
Detectar anomalías en el volumen de actividad
El comportamiento anómalo también puede darse en el volumen de actividad o datos. Esto es especialmente importante para detectar la extracción de volúmenes inusuales de datos.
La solución debe incluir una automatización que alerte al cliente cuando un usuario, programa, máquina/IP o una combinación de estos esté procesando o extrayendo una cantidad inusual de datos.
Descubrimiento
Un tema que no forma parte de la auditoría de bases de datos, pero que a menudo está disponible en las herramientas de auditoría de bases de datos, se refiere al escaneo y descubrimiento del entorno. Este tipo de capacidades tienden a ayudar al cliente que utiliza la solución de auditoría de bases de datos.
Escaneo de red
Algunos clientes desean escanear su red en busca de bases de datos. Estos escaneos pueden ayudar con el inventario de bases de datos, así como a identificar nuevas bases de datos que se ponen en línea. Si considera que esto es importante, especifíquelo.
La solución debe ser capaz de escanear la red e identificar las bases de datos que se ejecutan en rangos de puertos específicos. La solución también debe permitir la identificación de nuevas bases de datos identificadas por estos escaneos.
Detección de datos confidenciales
Algunos clientes desean escanear sus bases de datos en busca de datos confidenciales. El escaneo se realiza tomando muestras de algunas filas de cada columna y realizando una comparación de patrones para ver si los datos se parecen a lo que el cliente está buscando.
La solución debe ser capaz de escanear la base de datos en busca de información confidencial identificando los patrones de datos que el cliente está buscando.
Detección de permisos
Un requisito habitual es identificar las cuentas, privilegios y permisos actuales, así como los cambios que se producen en ellos.
La solución debe ser capaz de identificar las cuentas, privilegios y permisos actuales, y notificar o alertar sobre los cambios que se produzcan en ellos.
Detección de administradores de bases de datos y cuentas con privilegios
Un requisito habitual es identificar a los administradores de bases de datos y las cuentas con privilegios, así como otras cuentas con privilegios elevados.
La solución debe ser capaz de identificar a los administradores de bases de datos y las cuentas con privilegios, así como las cuentas con privilegios elevados. La solución también debe notificar o alertar sobre los cambios que se produzcan en ellos.
Medidas preventivas: bloqueo SQL
El bloqueo SQL permite ampliar las medidas preventivas mucho más allá de la funcionalidad integrada en la base de datos. Entre ellas se incluyen requisitos prácticos como reducir el riesgo de los administradores de bases de datos y las cuentas con privilegios, limitar el acceso a datos confidenciales y mucho más. Aunque son muy eficaces, hay que tener especial cuidado al implementar estas medidas y, por lo general, es mejor hacerlo como parte de un proceso de madurez.
No es necesario actualmente
La implementación adecuada del bloqueo SQL requiere un conocimiento sólido de la actividad de la base de datos y, por lo general, no recomendamos a los compradores primerizos que se lancen a ello. Sin embargo, si está considerando el bloqueo SQL para el futuro, debe especificar los requisitos futuros para no quedarse atrapado en un producto que no le pueda proporcionar estas capacidades en el futuro.
El bloqueo SQL no es actualmente necesario para la solución. Sin embargo, la solución debe ser capaz de proporcionar las capacidades especificadas en esta sección si decidimos adquirir los módulos adicionales necesarios.
Bloqueo de actividad
Se espera que la solución sea capaz de bloquear la actividad basándose en reglas definidas por el cliente.
La solución debe ser capaz de bloquear la actividad SQL basándose en reglas definidas por el cliente. La actividad debe bloquearse y no ejecutarse por la base de datos. Por ejemplo, una consulta no devolverá un conjunto de resultados y un DML no realizará modificaciones en las tablas.
Latencia
Al habilitar el bloqueo SQL, muchas soluciones cambian la forma en que se implementan o implementan módulos adicionales de una manera que introducirá una latencia significativa en algunas o todas las conexiones de la base de datos.
Concretamente, algunas soluciones en algunos modos de funcionamiento enviarán mensajes a su servidor central por cada paquete recibido por la base de datos y esperarán una respuesta antes de dejar pasar el paquete. Esto hace que las conexiones a la base de datos sean extremadamente lentas.
Todos los requisitos de este documento deben cumplirse cuando se utiliza el bloqueo SQL, incluidos los requisitos de sobrecarga. Cuando se utiliza el bloqueo SQL, no debe haber latencia adicional en ninguna sesión, incluidas las sesiones que se supervisan para detectar bloqueos.
Todas las fuentes de actividad
Dado que el bloqueo SQL a veces lo proporcionan módulos independientes que se implementan de forma diferente, es importante reiterar la necesidad de cubrir todas las fuentes de actividad mencionadas anteriormente.
En concreto, algunas soluciones solo permiten bloquear la actividad de red. Esto supone una limitación importante, especialmente cuando es necesario restringir las cuentas de administradores de bases de datos y cuentas con privilegios. Además, algunas soluciones ofrecen múltiples opciones de bloqueo que permiten elegir entre bloquear solo la actividad de red y la latencia adicional.
La solución debe ser capaz de bloquear todas las fuentes de actividad especificadas en este documento, incluidas la actividad local y la actividad cifrada. La solución debe ser capaz de bloquear todas estas fuentes sin añadir latencia adicional y sin permitir que la actividad se ejecute en la base de datos.
Actividad interna de la base de datos
La mayoría de las soluciones no podrán bloquear la actividad que se produce dentro de la base de datos, como los SQL generados dinámicamente. Esto supone una limitación importante si es necesario restringir las cuentas de administradores de bases de datos y cuentas con privilegios.
La solución debe ser capaz de bloquear la actividad interna de la base de datos, como la actividad generada dentro de procedimientos almacenados y bloques anónimos. En concreto, la solución debe ser capaz de bloquear SQL generados dinámicamente (por ejemplo, utilizando «execute immediate» en Oracle o «exec(“sql”)» en SQL Server).
Administradores de bases de datos (DBA)
Algunas soluciones requieren la participación de los administradores de bases de datos (DBA) en la implementación de reglas de bloqueo. Si planea utilizar el bloqueo SQL para restringir el acceso a cuentas con privilegios, es importante que los DBA no sean una parte esencial de la implementación de las reglas de bloqueo.
La solución no debe requerir que los DBA o los usuarios con privilegios participen en la implementación de las reglas y políticas de bloqueo SQL.
Prácticas recomendadas y modo solo registro
El bloqueo SQL puede interrumpir la actividad de producción por diversas razones, entre ellas un error cometido por el cliente en la definición de las reglas de bloqueo. Uno de los métodos para reducir ese riesgo es implementar el modo solo registro antes de habilitar el bloqueo. También se espera que los proveedores proporcionen prácticas recomendadas para reducir los diversos riesgos que conlleva la implementación del bloqueo SQL.
El proveedor debe proporcionar mejores prácticas para reducir el riesgo de implementar el bloqueo SQL. Estas mejores prácticas deben cubrir diversos riesgos, incluidos los errores cometidos por el cliente en la definición de las reglas de bloqueo. El producto también debe admitir el modo de solo registro, en el que algunas o todas las reglas de bloqueo registrarán cuándo se debe bloquear la actividad, pero no la bloquearán realmente.
Limitar el acceso a cuentas privilegiadas y de administrador de bases de datos (DBA)
Una de las razones para implementar SQL Blocking es limitar las cuentas privilegiadas y de administrador de bases de datos (DBA). En concreto, para impedir que dichas cuentas accedan al esquema de datos. Si esta es una de las expectativas que tiene de SQL Blocking, debe especificarlo.
La solución debe poder restringir las cuentas DBA y privilegiadas. En concreto, la solución debe poder impedir que dichas cuentas accedan al esquema de datos.
Proteger las tablas confidenciales
Una de las razones para implementar SQL Blocking es limitar el acceso a las tablas confidenciales. Por ejemplo, para garantizar que solo se pueda acceder a determinadas tablas desde la cuenta de la aplicación y desde los servidores de la aplicación. Si esta es una de las expectativas que tiene de SQL Blocking, debe especificarla.
La solución debe poder restringir el acceso a las tablas confidenciales para que solo se pueda acceder a ellas desde la cuenta de la aplicación y desde el servidor de la aplicación. Cualquier acceso que no provenga de la cuenta de la aplicación o del servidor de la aplicación debe bloquearse.
Proporcionar separación de funciones
SQL Blocking puede crear una separación de funciones en la base de datos. Esto se consigue bloqueando las actividades de riesgo y otorgando al personal de seguridad la capacidad de conceder a determinados usuarios una exención temporal de estas restricciones. Si esta es una de las expectativas que tiene de SQL Blocking, debe especificarlo.
La solución debe ser capaz de crear una separación de funciones en la base de datos. La separación de funciones se llevará a cabo mediante personal privilegiado que requerirá un permiso temporal del personal de seguridad para realizar determinadas acciones.
Restricciones de día y hora
El bloqueo SQL puede restringir la actividad solo en días u horas concretos. Por ejemplo, para restringir la actividad por la noche y los fines de semana. Si esta es una de las expectativas que tiene del bloqueo SQL, debe especificarlo.
La solución debe poder bloquear la actividad solo durante determinados días y horas. En concreto, la solución debe poder bloquear la actividad solo por la noche y durante los fines de semana.
Restricción por origen de la actividad
Una de las ventajas de SQL Blocking es que permite bloquear por origen de la actividad, como la dirección IP o la subred. Si esta es una de las expectativas que tiene de SQL Blocking, debe especificarlo.
La solución debe poder bloquear la actividad por origen de la actividad, como la dirección IP o la subred.
Personalización
El bloqueo SQL siempre debe personalizarse para adaptarse a cada entorno. Un falso positivo significa que se ha bloqueado la actividad de producción, por lo que es importante poder personalizar rápida y fácilmente todos los aspectos de las reglas de bloqueo para adaptarlas a una base de datos específica.
La solución debe proporcionar una interfaz sencilla para personalizar rápida y fácilmente todas las reglas de bloqueo, incluida la capacidad de ponerlas en práctica de inmediato.
Hardware del servidor de auditoría
Dependiendo de la solución, los requisitos de hardware del servidor de auditoría pueden ser significativos. Estos requisitos dependen de varios parámetros, como la cantidad de actividad que se debe procesar y almacenar. A continuación se ofrecen algunas sugerencias sobre cómo especificar estos requisitos.
Opción de software/hardware
Algunas soluciones se ofrecen como dispositivos, mientras que otras se ofrecen como software. Las soluciones de software suelen ser más económicas y permiten al cliente implementarlas en una máquina virtual. Si para usted es importante que la solución se pueda implementar en una máquina virtual sin instalar hardware adicional en su centro de datos, debe especificarlo.
La solución debe proporcionarse como una solución de software que se pueda implementar en una máquina virtual.
Hardware proporcionado por el cliente
Algunas soluciones tienen requisitos de hardware muy exigentes, como una CPU de alta potencia o un gran número de tarjetas de red de alto rendimiento. Se recomienda especificar qué hardware razonable puede proporcionar y solicitar al proveedor que proporcione cualquier hardware adicional.
El cliente puede proporcionar una máquina virtual con [1] tarjeta de red, hasta [4] núcleos de CPU y [8] GB de memoria. Si la solución tiene requisitos de hardware más elevados, el proveedor deberá proporcionar dicho hardware.
Almacenamiento
Los requisitos de almacenamiento pueden ser significativos en muchas soluciones y dependen en gran medida de la cantidad de datos que se planee almacenar. Le recomendamos que especifique la cantidad razonable de datos que espera capturar y el almacenamiento razonable que puede asignar para ello. El proveedor deberá proporcionar cualquier almacenamiento adicional.
Esperamos almacenar hasta [500 000] SQL por base de datos al día y necesitamos conservar esta actividad en línea durante [10] años. Podemos proporcionar [1 TB] de almacenamiento para estos datos. El proveedor deberá proporcionar cualquier almacenamiento adicional.