Preguntas Frecuentes

No, DS no tiene tales capacidades. Cabe señalar 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 que se ejecutan sobre las bases de datos (DBs).

La única cosa que puede usarse como una especie de parcheo virtual es la Regla de Seguridad para la Prevención de Inyección SQL, ya que el ataque de inyección SQL generalmente se realiza en el nivel de la aplicación aprovechando un diseño deficiente de la aplicación que permite a un atacante enviar comandos SQL maliciosos junto con parámetros de solicitud no parametrizados o no escapados.

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

Sin embargo, para el rango seleccionado de motores y versiones de DBMS, DataSunrise puede proporcionar una lista de acciones a realizar para fortalecer el DBMS desde el punto de vista de los Puntos de Referencia de Seguridad CIS y STIG.

DataSunrise solo puede encontrar y sugerir la corrección de vulnerabilidades y configuraciones incorrectas diagnosticadas y corregibles a través de comandos de la interfaz SQL.

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

El balanceo de carga o conmutación por error debe configurarse utilizando soluciones de terceros (comerciales o de código abierto):

• Keepalived (conmutación por error 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 HA completo queda fuera del alcance del equipo de soporte de DS y debe ser realizada por los propios clientes según sus propias decisiones.

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

• Múltiples nodos DS pueden trabajar en una única base de datos de configuración, mitigando la necesidad de configurar cada nodo por su cuenta (las configuraciones se toman de un Diccionario Compartido)

• En caso de que se pierda la conexión del Diccionario principal, utilice una copia de seguridad del Diccionario del Sistema como una base de datos de configuración de reserva. DS verifica una vez cada cierto tiempo si la conexión del Diccionario se restablece y cambia automáticamente cuando está disponible.

• Si una base de datos de Almacenamiento de Auditoría se vuelve inaccesible, DataSunrise puede escribir datos auditados en archivos locales y posteriormente vaciarlos en la base de datos de Almacenamiento de Auditoría tan pronto como DS detecte que la conectividad se ha restablecido.

No, no tenemos recomendaciones sobre endurecimiento adicional de la aplicación (Endpoints Proxy/Consola de Administración).

Por lo general, estos dependen de los requisitos que el entorno/cliente particular tenga para las aplicaciones desplegadas en su sitio.

DataSunrise ofrece una rica variedad de Parámetros Adicionales para endurecimiento/optimización del rendimiento. Estos son completamente opcionales y deben discutirse para ser configurados individualmente en cada caso.

Sin embargo, los valores predeterminados para la mayoría de los parámetros a lo largo de DataSunrise se configuraron 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 en corto) y de cero a muchos procesos AppFirewallCore (o Core en corto).

El Backend es una entidad que gestiona la configuración de DS y ejecuta diferentes tareas de utilidades (generación de informes, actualización de metadatos, envío de alertas SMTP, ejecución de Descubrimiento de Datos, etc.)

Los procesos Core gestionan el tráfico recibido de Proxy/Sniffer/Trailing/Agent (TBA) y realizan Auditoría/Mascarado/Bloqueo.

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

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

El consumo de memoria del Core también aumenta si las especificaciones del servidor de la base de datos de auditoría no pueden manejar los eventos a tiempo: DataSunrise está enviando eventos procesados al Almacenamiento de Auditoría a través de una cola interna. El procesamiento ocurre casi de inmediato, sin embargo, si la base de datos de auditoría no puede procesar los eventos a tiempo, los eventos pueden acumularse en el lado del servidor DS y causar un aumento en el consumo de RAM que desaparece 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 proxy.

Luego, DataSunrise informa sobre el consumo de Memoria Virtual.

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

Esto significa que el alto consumo de Memoria Virtual no puede causar un bloqueo del host DS debido a baja memoria.

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

Consulte los Parámetros Adicionales MaxCoreMemoryForTerminate o MaxBackendMemoryForTerminate para el umbral máximo (en unidades de Memoria Virtual) que al excederse fuerza automáticamente la terminación del proceso DS Core o Backend.

Por lo tanto, los picos de memoria son aceptables, especialmente cuando se usan especificaciones de hardware promedio.

Lo más importante es que si el consumo de memoria desaparece 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 intensa, entonces podría haber algunas fugas de memoria u otros aspectos para explorar.

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

Puedes hacerlo en Configuración del Sistema -> Registro y Registros -> Pestaña de Registros -> Para cada Servidor disponible en la lista desplegable de Servidores* “Descargar Todo”.

NB: esto resulta en un archivo de registros (ZIP) que se descarga en tu estación de trabajo, por lo tanto, podrías necesitar permitir ventanas emergentes para esta operación.

Si es posible, se recomienda compartir formas de reproducir el problema de consumo persistente de memoria. Si hay Reglas configuradas, entonces es importante proporcionar las capturas de pantalla de la configuración de tus Reglas. La mejor opción es usar la opción de respaldo del Diccionario en Configuración del Sistema -> General. Nota: un archivo de respaldo puede ser grande.

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

• CPU: 8 núcleos

• RAM: 8-16GB es suficiente

• No hay requisitos especiales de almacenamiento

• Espacio de 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 admite balanceadores de carga. Por ejemplo, admitimos el Balanceador de Carga Clásico en AWS. También puedes usar un cierto balanceador de carga al implementar DataSunrise en las instalaciones en una configuración HA. DataSunrise admite diversos tipos de balanceadores de carga. Por ejemplo, DataSunrise admite aplicaciones basadas en AWS que están completamente integradas con el Balanceador de Carga Clásico de AWS. Además, DataSunrise puede configurarse para usar un balanceador de carga específico como HAProxy, etc. Nota: DataSunrise admite balanceadores de carga solo cuando opera en modo HA.