Auditoría de la base de datos Oracle

 

La auditoría de la base de datos es la actividad de monitorear y registrar las acciones configuradas de la base de datos de los usuarios de la base de datos y los usuarios que no lo son, para garantizar la seguridad de las bases de datos.

Un administrador puede realizar auditorías en acciones individuales, como el tipo de declaración de lenguaje de consulta estructurado (SQL) ejecutada, o en combinaciones de datos que pueden incluir el nombre de usuario, la aplicación o la marca de tiempo, por ejemplo. Los auditores deben auditar tanto las actividades exitosas como las fallidas, e incluir o excluir a usuarios específicos de la auditoría:

La auditoría adecuada de una base de datos garantizará la protección de la base de datos, lo que significa que la instalación de la base de datos y sus funciones, la cuenta predeterminada, los parches, los servicios, la política de contraseñas, la política de bloqueo de cuentas y la política de auditoría han demostrado que la auditoría es un proceso continuo.

Los principales tipos de actividades de riesgo incluyen:

• Error: no mantener u operar la base de datos como se requiere conduce a la divulgación accidental de información, y los cambios no autorizados dan lugar a divulgaciones, inserciones, actualizaciones o eliminaciones accidentales y no autorizadas.
• Uso indebido: no mantener los derechos de acceso a la base de datos conduce al abuso del acceso privilegiado y la filtración de información.
• Acción maliciosa: si no se mantiene una configuración lógica y segura de la base de datos, se produce el robo de datos o un ataque de denegación de servicio (DoS).

Vulnerabilidades comunes encontradas en ataques a bases de datos

Muchos ataques comienzan con la ingeniería social:

• El phishing es un método de fraude por correo electrónico en el que el perpetrador envía correos electrónicos de apariencia legítima en un intento de recopilar información personal y financiera de los destinatarios. Por lo general, los mensajes parecen provenir de sitios web conocidos y confiables. Los sitios web que frecuentemente son falsificados por phishers incluyen PayPal, eBay, MSN, Yahoo y Best Buy, por ejemplo.

• La inyección SQL es una técnica que se utiliza para aprovechar las vulnerabilidades de entrada no validadas para pasar comandos SQL a través de una aplicación web para su ejecución por una base de datos back-end. Los atacantes aprovechan el hecho de que los programadores a menudo encadenan comandos SQL con parámetros proporcionados por el usuario y, por lo tanto, pueden incrustar comandos SQL dentro de estos parámetros. El resultado es que el atacante puede ejecutar consultas SQL arbitrarias y / o comandos en el servidor de base de datos back-end a través de la aplicación web.

• La exfiltración de datos es la copia, transferencia o recuperación no autorizada de datos de una computadora o servidor. La exfiltración de datos es una actividad maliciosa realizada a través de diversas técnicas, generalmente por ciberdelincuentes a través de Internet u otra red. La exfiltración de datos también se conoce como extrusión de datos, exportación de datos o robo de datos.
• El servidor de ensayo es un servidor que permite ensamblar, implementar y probar un software o un sitio web en una instancia de servidor, similar al servidor de producción. Normalmente, el software o un sitio web se implementa en el servidor de ensayo desde el servidor de desarrollo cuando se completa el desarrollo. Un servidor intermedio ayuda a identificar el comportamiento, la experiencia y el rendimiento del software o del sitio web, ya que será visible en el servidor de producción. Esto ayuda a los desarrolladores de software o al personal de control de calidad (QA) a identificar y resolver cualquier problema, error, problemas de rendimiento o usabilidad u otros problemas antes de que el software o el sitio web se implemente en el servidor de producción. El servidor intermedio puede ser un servidor de base de datos intermedio, un servidor de sitio web intermedio o un servidor de aplicaciones intermedias, por ejemplo.

El análisis de la configuración de la base de datos es fundamental para determinar las vulnerabilidades y garantizar la auditoría estándar. La auditoría de la base de datos incluye:

1. Encontrar privilegios y datos confidenciales
2. Impedir el acceso a los datos
3. Validar que los mecanismos de detección y alerta estén en su lugar
4. Hay varios mecanismos disponibles que deben estar en su lugar cuando se configuran las bases de datos, que incluyen:

• La redacción de datos proporciona una redacción selectiva y sobre la marcha de datos confidenciales en los resultados de las consultas SQL, antes de la visualización de la aplicación, para que los usuarios no autorizados no puedan ver los datos confidenciales. Permite la redacción coherente de las columnas de la base de datos en los módulos de la aplicación que acceden a la misma información de la base de datos. La redacción de datos minimiza los cambios en las aplicaciones porque no altera los datos reales en los búferes, cachés o almacenamiento de la base de datos internos, y conserva el tipo de datos y el formato originales cuando los datos transformados se devuelven a la aplicación. La redacción de datos no tiene ningún impacto en las actividades operativas de la base de datos, como copia de seguridad y restauración, actualización y parche, y en clústeres de alta disponibilidad.
• El enmascaramiento de datos confunde los datos confidenciales reemplazándolos con otros datos, generalmente caracteres que cumplirán los requisitos de un sistema diseñado para probar o seguir funcionando con los resultados enmascarados. El enmascaramiento garantiza que partes vitales de la información de identificación personal (PII), como los primeros cinco dígitos de un número de seguro social, se oculten o se desidentifiquen.
• El cifrado de datos implica convertir y transformar datos en texto cifrado codificado, a menudo ilegible, utilizando algoritmos y cálculos matemáticos no legibles. Restaurar el mensaje requiere un algoritmo de descifrado correspondiente y la clave de cifrado original.

Pasos de auditoría de la base de datos

Se deben seguir los siguientes pasos para la auditoría de la base de datos.

Paso 1: determinar si las cuentas predeterminadas se han modificado o desactivado

Las cuentas de Oracle privilegiadas predeterminadas siguen siendo el problema de mayor riesgo que se encuentra comúnmente. Es un problema fácil de solucionar y prevenir. Después de la instalación, Oracle tiene varias cuentas predeterminadas, cada una con un valor predeterminado predeterminado. Después de la instalación de la base de datos, el asistente de configuración de la base de datos de Oracle (DBCA) bloquea automáticamente y expira la mayoría de las cuentas de usuario predeterminadas de la base de datos. Además, DBCA cambia la cuenta SYSTEM al valor especificado durante la rutina de instalación.

Si una base de datos de Oracle se instala manualmente, el DBCA nunca se ejecuta y esas peligrosas cuentas con privilegios predeterminados nunca se bloquean ni caducan. Por defecto, su contraseña es la misma que su nombre de usuario. Estas serán las primeras credenciales que un hacker intentará utilizar para conectarse a la base de datos. Como práctica recomendada, cada una de estas cuentas debe configurarse con una contraseña única segura y, si no se requiere una cuenta, debe bloquearse y caducar.

Paso 2: auditar la solidez de Oracle Database SID

El ID del sistema de Oracle (SID) es un valor único que se requiere para que todos los clientes se conecten a la base de datos de Oracle. Debido a que debe ser única, no puede haber más de una base de datos con el mismo SID en el mismo servidor Oracle.

Si una conexión de cliente utiliza un SID incorrecto para conectarse a una base de datos de Oracle, recibirá el mensaje "ORA-12505: TNS: el oyente no conoce actualmente el SID proporcionado en el descriptor de conexión". Sin embargo, los SID pueden ser de fuerza bruta. Existen numerosas herramientas para forzar el SID de Oracle, incluidos los módulos Metasploit, las pruebas de aceptación operativa (OAT) y SIDGuess.

La clave para frustrar los ataques de fuerza bruta de SID es seleccionar un SID que sea fuerte. Al crear un SID de Oracle, la selección debe:

• No ser una palabra de diccionario
• Tener al menos 10 caracteres de longitud
• Incluya al menos un carácter especial

La incorporación de estos elementos asegura que el SID sea fuerte, es decir, difícil para un atacante utilizar la fuerza bruta.

¿Por qué es importante un SID fuerte cuando el SID se almacena como un valor de texto sin cifrar dentro del archivo de configuración del cliente de Oracle, TNSNAME.ora, en cada sistema que está configurado para conectarse a la base de datos? Es importante porque siempre que un atacante pueda comprometer al menos un sistema que está configurado para conectarse a la base de datos de Oracle, obtener el SID del archivo TNSNAMES.ORA es trivial. Sin embargo, es importante considerar los casos en los que el atacante es externo a la organización y ha comprometido un solo host que no tiene configurada una conexión de cliente de Oracle. Un SID sólido no impedirá por sí mismo que los piratas informáticos obtengan una conexión con la base de datos Oracle de una organización, pero es una buena práctica como parte de un enfoque de seguridad de defensa en profundidad.

Paso 3: auditar las actualizaciones de parches críticos de Oracle

Esta es una de esas recomendaciones de mejores prácticas de seguridad con las que la mayoría de las organizaciones luchan comúnmente. Dependiendo del esquema de la base de datos, las actualizaciones de parches críticos (CPU) de Oracle pueden tener un impacto significativo en la base de datos de Oracle, lo suficientemente significativo como para que la organización tenga que realizar pruebas de regresión exhaustivas para garantizar que la aplicación de las últimas CPU de Oracle no afecte la funcionalidad de la base de datos.

Oracle lanza CPU trimestralmente el martes más cercano al día 17 del mes. Oracle tiene una página de boletín especial que describe todas las actualizaciones y advertencias de parches críticos de Oracle más recientes.2 Afortunadamente, las CPU son de naturaleza acumulativa. Uno puede simplemente instalar la última CPU de Oracle para obtener todos los parches de seguridad desde el lanzamiento inicial del producto.

La clave para un proceso de parches de CPU eficaz es crear un proceso de prueba de regresión reglamentado que corresponda a los cuatro lanzamientos programados de Oracle cada año. Incluso en organizaciones con los procesos de prueba de regresión más estrictos, las CPU generalmente se pueden diseñar de tal manera que se puedan aplicar no más de tres meses después de la última versión de la CPU. Además, todos los administradores de bases de datos deben registrarse en el servicio de asesoramiento de alertas de seguridad por correo electrónico de Oracle3 para garantizar la notificación oportuna de los parches y alertas de seguridad de Oracle.

También existe un mecanismo que Oracle emplea si se descubre una vulnerabilidad crítica que justifica la publicación inmediata del parche. Oracle se refiere a los parches lanzados inmediatamente bajo este programa como "alertas de seguridad fuera de horario". Desde que comenzó el programa de CPU en 2005, solo ha habido unas pocas veces en las que Oracle lanzó parches bajo este proceso de emergencia. Las organizaciones deben desarrollar un método para aplicar estos parches lanzados de emergencia, pero dado su bajo volumen histórico, la atención debe centrarse en la aplicación rutinaria de parches de CPU cada trimestre.4

Paso 4: Auditar el rol PÚBLICO para la identificación de privilegios innecesarios

En Oracle, existen rutinas extendidas que permiten a los usuarios con privilegios mínimos ejecutar funciones que de otro modo no podrían ejecutar. Estas rutinas extendidas se denominan paquetes y son aproximadamente equivalentes a los procedimientos almacenados extendidos en Microsoft SQL Server. Un rol especial, llamado PUBLIC, actúa como un rol predeterminado asignado a cada usuario en la base de datos de Oracle. Cualquier usuario de la base de datos puede ejecutar los privilegios otorgados a PUBLIC. Esto se aprovecha comúnmente para la escalada de privilegios de la base de datos.

Estos paquetes y subtipos deben revocarse de PUBLIC y hacerse ejecutables para una aplicación solo cuando sea absolutamente necesario.

Paso 5: Verifique que la auditoría de la base de datos esté habilitada

Para identificar las actividades maliciosas o autorizadas en una base de datos, es importante verificar que las opciones de auditoría de la base de datos estén habilitadas. Para asegurarse de que la auditoría de la base de datos esté habilitada, es necesario realizar las siguientes actividades durante la auditoría de la base de datos:

• Auditoría de operaciones SYS: de forma predeterminada, las bases de datos de Oracle no auditan los comandos SQL ejecutados por el SYS privilegiado y los usuarios que se conectan con privilegios SYSDBA o SYSOPER. Si se piratea una base de datos, estos privilegios serán el primer objetivo del pirata informático. Afortunadamente, auditar los comandos SQL de estos usuarios privilegiados es muy simple: 

sqlplus> alter system set audit_sys_operations = true scope = spfile.

• Habilitar la auditoría de la base de datos: de nuevo, de forma predeterminada, la auditoría de Oracle de los comandos SQL no está habilitada. La auditoría debe estar activada para todos los comandos SQL. La auditoría de la base de datos se activa con el parámetro audit_trail: sqlplus> alter system set audit_trail = DB, EXTENDED scope = spfile. (Nota: El comando habilita la auditoría desde la base de datos, pero no la información de la bóveda de la base de datos, en la tabla SYS. AUD $.) En realidad, hay cuatro tipos de auditoría de bases de datos: OS, DB, EXTENDED y XML.
• Habilite la auditoría en objetos importantes de la base de datos: una vez que se ha habilitado la auditoría, se puede activar para los objetos en los que una pista de auditoría es importante.

Paso 6: Auditoría para garantizar que los activadores de la base de datos para la auditoría de esquemas y los eventos de inicio / cierre de sesión estén configurados

Para auditar eficazmente los cambios de esquema y los eventos de inicio y cierre de sesión, Oracle proporciona activadores de lenguaje de definición de datos (DDL) para auditar todos los cambios de esquema y puede informar el cambio exacto, cuándo se realizó y qué usuario.

• Activador de inicio de sesión: al usar un activador de inicio de sesión, se pueden enviar eventos de inicio y cierre de sesión en tiempo real a otro sistema. Piense en ello como un demonio syslog para los eventos de su base de datos. El siguiente ejemplo enviaría todos los eventos de inicio y cierre de sesión a un servidor web en tiempo real.

SQL> crear o reemplazar el disparador sec_logon después de iniciar sesión en la base de datos.

• Activador DDL: mediante los activadores DDL, un administrador de bases de datos de Oracle puede realizar un seguimiento automático de todos los cambios en la base de datos, incluidos los cambios en las tablas, los índices y las restricciones. Los datos de este activador son especialmente útiles para el control de cambios para Oracle DBA. El siguiente ejemplo envía eventos para GRANT, ALTER, CREATE, DROP.
• Disparador de error: los disparadores de error son mensajes de error de Oracle. Pueden ser útiles para detectar ataques de inyección SQL y otros métodos de ataque.

Paso 7: Auditoría para garantizar que se implemente una solución DAM

Si una organización puede permitirse el gasto adicional de un producto de software adicional, una solución de monitoreo de base de datos puede ser muy útil. Resuelve el problema de no poder monitorear la actividad del DBA a nivel organizacional. También proporciona información útil sobre consultas SQL peligrosas y modificaciones de roles que podrían indicar que un atacante ha comprometido una base de datos. La clave para todas las soluciones de monitoreo de actividad de bases de datos (DAM) es que operan dentro de la memoria del servidor Oracle y operan independientemente de las funciones nativas de auditoría y registro de la base de datos. Para cualquiera que esté familiarizado con los sistemas de detección de intrusiones en la red (IDS), los DAM tienen una función análoga: operan dentro de la capa de la base de datos en el servidor en lugar de en cualquiera de las capas de la red.

Paso 8: Auditoría para garantizar que la administración de contraseñas para todos los inicios de sesión de Oracle esté habilitada

Oracle proporciona una gestión de contraseñas bastante sólida para los inicios de sesión de Oracle. Desafortunadamente, ninguno de estos se aplica en el perfil de cuenta de Oracle predeterminado.

En Oracle, a los inicios de sesión se les asigna una política de cuenta a través de un perfil de Oracle. Cada inicio de sesión se puede aplicar a un solo perfil de Oracle. Si no se especifica ningún perfil de Oracle cuando se crea el inicio de sesión, se le asigna el perfil de Oracle predeterminado.

Paso 9: Verifique para asegurarse de que se realizan evaluaciones regulares de seguridad de la base de datos

Cada configuración segura que se ha discutido podría detectarse fácilmente con una herramienta de vulnerabilidad de base de datos automatizada. Las herramientas automatizadas de vulnerabilidad de bases de datos proporcionan una manera excelente de validar rápidamente las configuraciones seguras de Oracle de una organización. Obviamente, este tipo de herramientas solo son útiles si uno tiene privilegios. Están pensados ​​para que los administradores de bases de datos, auditores y profesionales de la seguridad realicen evaluaciones periódicas. Estas herramientas son propensas a generar falsos positivos y, desafortunadamente, falsos negativos, pero sus beneficios superan con creces el riesgo.

Paso 10: Determine que el tráfico de la base de datos está cifrado

Esta recomendación rara vez se implementa, excepto en las organizaciones más seguras. Oracle admite el cifrado a nivel de red mediante Secure Sockets Layer (SSL), utilizando certificados firmados X.509v3 y cifrado nativo sin certificados.

La conclusión con el cifrado a nivel de red no es solo que los datos confidenciales en tránsito están protegidos cuando se emplea el cifrado, sino también que el SID está protegido. Sin cifrado, el SID se puede enumerar fácilmente mediante ataques man-in-the-middle.

Paso 11: Audite las amenazas y contramedidas a la seguridad adecuadamente

Una organización debe crear una política de seguridad escrita para enumerar las amenazas de seguridad contra las que está tratando de protegerse y las medidas específicas que debe tomar la organización. Las amenazas a la seguridad se pueden abordar con diferentes tipos de medidas:

• Procedimientos, como exigir a los empleados del centro de datos que muestren credenciales de seguridad
• Físico, como asegurar computadoras en instalaciones de acceso restringido
• Técnico, como la implementación de requisitos de autenticación sólidos para sistemas comerciales críticos
• Relacionado con el personal, como la realización de verificaciones de antecedentes o la investigación de antecedentes de personal clave

Conclusión

Los datos son un recurso muy decisivo para cualquier negocio debido al blindaje; La auditoría periódica de la base de datos nunca debe dejarse al azar ni a soluciones de mosaico. Durante el período de auditoría, las partes interesadas deben identificar que un sistema está configurado según el estándar que garantiza la mitigación del riesgo de datos.

Se debe implementar una solución de auditoría completa e integral que pueda lograr fácilmente cada uno de los siguientes:

• Auditoría de acceso y autenticación
• Auditoría de usuarios y administradores
• Auditoría de actividades sospechosas
• Auditoría de vulnerabilidades y amenazas
• Auditoría de cambios

Sin una solución de auditoría que lo abarque todo, las organizaciones ponen en riesgo datos valiosos. Los datos corruptos, inexactos o comprometidos equivalen a pérdida de ingresos, tiempo perdido y relaciones comprometidas con clientes y empleados.

La auditoría es un proceso continuo y continuo sin importar qué sistema o proveedor esté en uso. Incluso los aspectos básicos deben revisarse periódicamente para evitar una falsa sensación de seguridad. La base de datos es un componente sensible en los negocios; por lo tanto, es importante asegurarse de que la base de datos esté configurada correctamente para garantizar la seguridad de los datos comerciales.