Preguntas Frecuentes

No, DS no posee tales capacidades. Cabe destacar que DS es una solución de seguridad de bases de datos y no un WAF (Firewall de Aplicaciones Web). DataSunrise protege bases de datos, no aplicaciones ejecutadas sobre ellas.

Lo único que puede usarse como una especie de parcheo virtual es la Regla de Seguridad para Prevención de Inyección SQL, ya que el ataque de inyección SQL usualmente se realiza en el nivel de la aplicación aprovechando un mal diseño que permite a un atacante enviar comandos SQL maliciosos junto con parámetros de solicitud sin parametrizar o sin escapar.

No, el Escáner VA de DataSunrise solo puede usarse para fines de reporte y no realiza ningún parcheo como parte de la lógica de negocio del escáner.

Sin embargo, para el rango seleccionado de motores y versiones de DBMS, DataSunrise puede proporcionar una lista de acciones a realizar para endurecer el DBMS desde el punto de vista de las Referencias de Seguridad CIS y STIG.

DataSunrise solo es capaz de detectar y sugerir la corrección de vulnerabilidades y configuraciones erróneas diagnosticadas y corregibles mediante comandos a través de la interfaz SQL.

DataSunrise ya no dispone de componentes para trabajar en HA (activo/pasivo o activo-activo).

El balanceo de carga o el failover deben configurarse utilizando soluciones de terceros (comerciales o de código abierto):

• Keepalived (Failover HA activo/pasivo) en Linux

• HAProxy (Balanceador de Carga L4/L7 activo/activo)

Las soluciones mencionadas a continuación son comerciales, no podemos recomendarlas pero deben ser mencionadas:

• Citrix

• Kemp

• F5

• Cualquier otro (por ejemplo, CISCO) balanceador de carga de hardware

La configuración de DS en modo totalmente HA está fuera del alcance del equipo de soporte de DS y debe ser realizada por los propios clientes de acuerdo a sus propias decisiones.

Por defecto, DataSunrise ofrece las siguientes técnicas de HA:

• Múltiples nodos DS pueden operar sobre una única base de datos de configuración, eliminando la necesidad de configurar cada nodo de manera individual (la configuración se toma de un Diccionario compartido)

• En caso de pérdida de la conexión al Diccionario principal, se utiliza una Copia de Seguridad del Diccionario del Sistema como base de datos de configuración de reserva. DS verifica periódicamente si la conexión al Diccionario se ha restablecido y vuelve a cambiar cuando está disponible.

• Si una base de datos de Almacenamiento de Auditoría se vuelve inaccesible, DataSunrise puede escribir los datos auditados en archivos planos almacenados localmente y volcarlos a la DB de Almacenamiento de Auditoría tan pronto como DS detecte que la conectividad se ha restablecido.

No, no tenemos recomendaciones adicionales sobre el endurecimiento de la aplicación (Puntos finales de Proxy / Consola de Gestión).

Generalmente, esto depende de los requisitos que tenga el entorno o el cliente específico para las aplicaciones desplegadas en su sitio.

DataSunrise ofrece una amplia variedad de Parámetros Adicionales para el endurecimiento y la optimización del rendimiento. Estos son completamente opcionales y se deben configurar de manera individual para cada caso.

No obstante, los valores predeterminados para la mayoría de los parámetros en DataSunrise fueron configurados para ser óptimos en la mayoría de los casos.

En términos de Arquitectura de Procesos, una instancia de DataSunrise consta de un único AppBackendService (o Backend, BE para abreviar) y de cero o múltiples procesos AppFirewallCore (o Core para abreviar).

El Backend es una entidad que gestiona la configuración de DS y ejecuta diversas tareas de utilidad (generar informes, actualizar metadatos, enviar alertas SMTP, ejecutar Data Discovery, etc.).

El Core procesa el tráfico recibido de Proxy/Sniffer/Trailing/Agent (TBA) y realiza Auditoría/Enmascaramiento/Bloqueo.

La RAM consumida por un Core depende del volumen de los metadatos (tablas y sus detalles de columnas, vistas, paquetes (Oracle), procedimientos, funciones, sinónimos) de la Base de Datos Objetivo para la cual está configurado este Proxy/Sniffer/Trailing/Agent: los metadatos se cargan en la caché.

Además, el Core de DataSunrise también almacena en caché las consultas SQL reconocidas en el tráfico para aumentar la velocidad de procesamiento.

El consumo de memoria del Core también aumenta si las especificaciones del Servidor de Base de Datos de Auditoría no permiten procesar los eventos a tiempo: DataSunrise envía los eventos procesados al Almacenamiento de Auditoría a través de una cola interna. El procesamiento ocurre casi de inmediato; sin embargo, si la BD de Auditoría no puede procesar los eventos a tiempo, estos pueden acumularse en el lado del servidor DS y causar un aumento en el consumo de RAM, que se reduce a medida que los eventos se envían al Almacenamiento de Auditoría.

Finalmente, se reserva algo de memoria para los búferes del analizador de protocolos y para cada conexión de proxy.

Luego, DataSunrise informa sobre el consumo de Memoria Virtual.

La memoria virtual no se corresponde 1:1 ni en otra proporción con la Memoria Física (RAM).

Esto significa que un alto consumo de Memoria Virtual no puede provocar un fallo del host DS debido a baja memoria.

DataSunrise utiliza la Memoria Virtual para monitorear la asignación de Memoria Virtual para los objetos en ejecución que DS genera durante su operación. Usamos esta métrica para monitorizar el funcionamiento del servicio DataSunrise en un host y, en caso de que el consumo de memoria supere un umbral interno, los procesos pueden reiniciarse automáticamente.

Por favor, consulte los Parámetros Adicionales MaxCoreMemoryForTerminate o MaxBackendMemoryForTerminate para conocer el umbral definitivo (en unidades de Memoria Virtual) que, al ser superado, fuerza automáticamente la terminación del proceso DS Core o Backend.

Por lo tanto, los picos de memoria están bien, especialmente cuando se utilizan especificaciones de hardware promedio.

Lo más importante, si el consumo de memoria disminuye con el tiempo, entonces no hay nada de qué preocuparse.

Sin embargo, si el consumo de Memoria Virtual se mantiene alto después de un período de actividad intensiva, podría haber fugas de memoria u otros aspectos que investigar.

En este caso, es importante compartir los archivos de registro del entorno problemático utilizando el botón Descargar Todo.

Puede hacer esto en Configuración del Sistema -> Registro y Logs -> Pestaña de Logs -> Para cada Servidor disponible en la lista desplegable Servidores*, use “Descargar Todo”.

NB: esto resulta en un archivo comprimido (ZIP) con los registros que se descargará en su estación de trabajo, por lo que podría necesitar permitir ventanas emergentes para esta operación.

Si es posible, se recomienda compartir los métodos para reproducir el problema del consumo persistente de memoria. Si se han configurado Reglas, es importante proporcionar capturas de pantalla de la configuración de sus Reglas. La mejor opción es utilizar la opción de respaldo del Diccionario en Configuración del Sistema -> General. Tenga en cuenta que un archivo de respaldo puede ser grande.

DataSunrise puede ejecutarse en cualquier hardware convencional. No hay requisitos especiales de hardware. Si se va a utilizar DataSunrise en producción, sugerimos algo como las siguientes especificaciones:

• CPU: 8 núcleos

• RAM: 8-16GB son suficientes

• No hay requisitos especiales de almacenamiento

• Espacio en disco disponible: 100 GB para auditoría de datos

• Sistema operativo: Linux de 64 bits (Red Hat Enterprise Linux 7+, Debian 10+, Ubuntu 18.04 LTS+, Amazon Linux 2) o Windows Server 2019+ de 64 bits

DataSunrise es compatible con balanceadores de carga. Por ejemplo, soportamos el Classic Load Balancer en AWS. También puede utilizar un determinado balanceador de carga al desplegar DataSunrise en instalaciones propias en una configuración HA. DataSunrise es compatible con varios tipos de balanceadores de carga. Por ejemplo, DataSunrise soporta aplicaciones basadas en AWS que se integran completamente con AWS Classic Load Balancer. Además, DataSunrise se puede configurar para utilizar un balanceador de carga como HAProxy, etc. Nota: DataSunrise soporta balanceadores de carga únicamente cuando opera en modo HA.