Introducción

Las filtraciones de datos son algo habitual. A la mayoría de las personas les robaron sus correos electrónicos o números de teléfono. Debería ser una realidad impactante, pero la magnitud del problema y las frecuentes filtraciones lo han normalizado, convirtiéndolo en algo que todos aceptan y, en su mayoría, ignoran.

El robo de datos sigue siendo uno de los problemas más persistentes y perjudiciales en la seguridad de la información. Las organizaciones almacenan grandes cantidades de información confidencial, y el volumen sigue creciendo. El potencial de una filtración de datos catastrófica nunca ha sido tan alto.

Existen importantes incentivos financieros para los actores de amenazas, tanto internos como externos, y los resultados hablan por sí solos. Se proyecta que el cibercrimen le costará al mundo 23 billones de dólares para 2027, y el costo promedio de una filtración de datos en 2024 fue de casi 5 millones de dólares. Son cifras alarmantes y, de alguna manera, todos piensan que no les sucederá. Sin embargo, le sucede a alguien constantemente. No pasa una semana sin que se produzca una nueva filtración escandalosa.

Por insuperable que parezca este problema, en realidad no lo es. Solo se necesita un enfoque diferente. La solución más eficaz, y a menudo pasada por alto, reside en proteger los propios datos. Esto implica asegurar las bases de datos que los contienen. Si se protegen los datos, un hacker que penetre en la red corporativa o un empleado interno que viole la confianza no provocará una filtración de datos. La seguridad perimetral impide el acceso de las personas, mientras que la seguridad de las bases de datos controla lo que hacen una vez dentro. Este artículo explica cómo implementar este tipo de seguridad.

Cumplimiento Normativo

El robo de datos no se trata solo de dinero. Se trata de la privacidad, los datos personales, el robo de identidad y mucho más. Estas violaciones perjudican a las personas, erosionan la confianza de los clientes y dañan su reputación.

Es un problema grave para la mayoría de las empresas y las numerosas personas que trabajan con ellas. Como resultado, los gobiernos y los organismos reguladores intervienen. Esto significa que ahora tenemos una presión más para proteger la información: el cumplimiento normativo. Ya no se trata solo de proteger nuestros negocios y hacer lo correcto: es la ley.

Privacidad

Las regulaciones de privacidad tienen múltiples facetas. Además de las restricciones sobre cómo las empresas pueden usar nuestros datos personales, un aspecto fundamental de las leyes de privacidad es mitigar el riesgo de robo de datos. El RGPD (Reglamento General de Protección de Datos) de la Unión Europea es probablemente la regulación de privacidad más conocida. Sin embargo, en los últimos años, la mayoría de los países y estados han promulgado leyes de protección de la privacidad.

Si bien cada ley regula a diferentes entidades y establece restricciones distintas, en lo que respecta a la seguridad de los datos, los objetivos son prácticamente idénticos.

Datos Financieros, Historiales Médicos, Datos Corporativos y Más

El robo de datos representa un riesgo para muchas categorías de información. Hay muchos datos que esperamos que se mantengan confidenciales, y confiamos en que así sea. Las leyes y regulaciones en la mayoría de los países ya cubren datos personales, como información financiera, historiales médicos y números de tarjetas de crédito. En lo que respecta a los datos corporativos y la propiedad intelectual, estos son fundamentales para el negocio, y las empresas ya están incentivadas a protegerlos.

Si personas no autorizadas o el público en general accedieran a cualquiera de estos océanos de datos, se produciría un daño significativo para la persona o empresa cuyos datos se divulgaron.

Los hackers también evolucionan, descubriendo formas más creativas de explotar nuestra dependencia de la información. El ransomware es la estrategia más reciente para extorsionarnos negándonos el acceso a nuestros datos. Para aumentar la presión para pagar el rescate, los hackers utilizan una doble extorsión: también roban los datos y amenazan con exponerlos. Por lo tanto, el ransomware y el robo de datos están estrechamente vinculados.

Hoy en día, pocas personas en el mundo necesitan que se les convenza de la plaga que representa el robo de datos y de la urgente necesidad de detenerlo. La cuestión, entonces, no es si actuar o no, sino cómo construir una defensa sólida que proteja los datos.

Bases de datos: La frontera de seguridad más eficaz y desafiante

La seguridad perimetral busca evitar que agentes maliciosos accedan a la red corporativa, mientras que la seguridad de las bases de datos controla el acceso a los datos y la información que sale. Por lo tanto, las bases de datos son el lugar perfecto para identificar el robo de datos. Ninguna otra capa en la pila tecnológica es capaz de identificar con facilidad y precisión qué información sale y cuánta.

Sin embargo, esto conlleva un desafío importante: TODA la información pasa por la base de datos. No se trata solo de información sensible, y es para cualquier propósito posible. Esto implica miles de millones de consultas y volúmenes masivos de información que alimentan a cada consumidor de datos en cualquier parte de la empresa.

Esto presenta un doble desafío: capturar toda esa actividad sin afectar el rendimiento e identificar la actividad maliciosa en este mar de consultas. Si logramos esto eficazmente, protegeremos nuestros datos. Esa es la clave de la seguridad de los datos.

Tecnologías

Antes de entrar en detalles de implementación, analicemos brevemente las tecnologías necesarias para proteger la base de datos. Estas tecnologías se dividen en dos categorías principales: captura y procesamiento.

Captura

Capturar la actividad implica generar un flujo de auditoría que incluya toda la actividad. En esencia, se trata de “ver” todo lo que ocurre en la base de datos. Esto supone un reto especial para el robo de datos, ya que la mayor parte de la actividad de la base de datos se compone de consultas (las SQL que extraen datos, y existen miles de millones). El reto con tantas SQL es que capturarlas puede afectar al rendimiento de la base de datos. Una solución parcial es capturar un pequeño subconjunto de esas SQL, lo que genera una visibilidad insuficiente. Otro reto de visibilidad es la actividad dentro del servidor de la base de datos y la actividad interna en la base de datos.

Existen tres tecnologías de captura principales en el mercado de la seguridad de bases de datos:

• La auditoría nativa aprovecha las capacidades integradas de la base de datos. Las soluciones que se basan en ella son más económicas, pero tienen una visibilidad limitada y un alto impacto en el rendimiento de la base de datos.
• Las soluciones de captura de red pueden verlo todo con una sobrecarga mínima. Requieren un agente para capturar la actividad local y no pueden capturar la actividad interna de la base de datos. También pueden presentar problemas con las conexiones cifradas.
• La captura completa (Full Capture) es una tecnología que se conecta directamente al motor de la base de datos. Puede verlo todo con un impacto mínimo en el rendimiento. Es lo mejor de ambos mundos: le ofrece una visibilidad superior con menos del 3 % de altura.

Procesamiento

Una vez que se cuenta con un flujo de auditoría, es necesario aprovecharlo. Es necesario, de alguna manera, aumentar la seguridad. Recuerde que hablamos de miles de millones de SQL. La solución es dividir y vencer: utilizar diferentes enfoques para los distintos subconjuntos del flujo de actividad.

Las distintas soluciones del mercado ofrecen distintas capacidades, pero una solución integral debe ofrecer una combinación de métodos cuyas capacidades combinadas aborden toda la actividad de la base de datos.

Los enfoques de procesamiento se dividen en cuatro categorías principales. Primero, explicaremos qué son y, posteriormente, cómo combinarlos para construir una defensa adecuada.

• Políticas, Informes, Alertas. Estas funciones permiten registrar subconjuntos específicos de la actividad, generar informes y enviar alertas. Este tipo de auditoría se denomina auditoría declarativa: se le indica a la solución qué actividad registrar y qué incluir en los informes y alertas. Estas medidas son excelentes para controlar actividades de alto riesgo y bajo volumen, como las de los administradores.
• Análisis de Anomalías. Estas funciones analizan el perfil de actividad para detectar comportamientos inusuales. Pueden gestionar cualquier volumen de actividad y su objetivo es identificar actividades sospechosas dentro del flujo. Las anomalías pueden ser un nuevo SQL, un nuevo usuario, una máquina diferente, una hora inusual, un mayor volumen de actividad, etc. Se trata de encontrar una aguja en un pajar y funciona especialmente bien con la actividad repetitiva. El perfil de actividad de la aplicación es repetitivo, y las anomalías pueden identificar ataques dirigidos a vulnerabilidades de la aplicación, como inyecciones de SQL.
• Análisis Forense Proactivo. Estas funciones buscan brindar al personal de seguridad visibilidad sobre lo que sucede en la base de datos. Le permite investigar el 100% de la actividad pasada de la base de datos para comprender el comportamiento de individuos, programas y más. Esta visibilidad puede servir como un control independiente o como un medio para planificar otros controles e identificar sus deficiencias.
• Bloqueo avanzado. Estas funciones están diseñadas para prevenir actividades no deseadas. Amplían las medidas de seguridad integradas de la base de datos al analizar cada SQL en cada conexión. Si bien la prevención es una herramienta poderosa, úsela con precaución. Puede bloquear la actividad legítima, causando interrupciones del servicio y quejas de los usuarios.

Con Core Audit, todas estas capacidades están integradas en la solución, lo que le permite lograr más con una interfaz fácil de usar.

Diseño de la Seguridad

El control de actividad es la medida de seguridad más eficaz en las bases de datos. Algunos podrían decir que es la única seguridad eficaz. Sin embargo, diseñar un plan de seguridad para el control de actividad no es trivial. No se puede pulsar un botón y todo está protegido. Esta sección ofrece una guía inicial sobre los pasos necesarios para crear un plan de control de actividad.

Paso 1: Visibilidad

Puede parecer un paso obvio, pero la mayoría de las personas lo pasan por alto. Debe obtener visibilidad del perfil de actividad de la base de datos. Necesita saber quién accede a su base de datos, desde dónde, cuándo y qué hace en ella. Comprender el perfil de actividad que desea proteger es esencial para protegerlo. No se puede proteger lo que no se puede ver ni comprender.

En soluciones como Core Audit, esto forma parte del Análisis Forense Proactivo. El Análisis Forense Proactivo es un conjunto de herramientas de visualización y análisis gráfico que le ayudan a comprender las fuentes de actividad y su función, el volumen de actividad a lo largo del tiempo y la relación entre múltiples dimensiones.

Paso 2: Clasificación de Cuentas y Riesgos

Existen muchas maneras de diseñar un plan de control de actividades. Se pueden diseñar controles para cada riesgo, subdividir la actividad en diferentes dimensiones, etc. Descubrimos que el enfoque más sencillo se basa en las cuentas.

Las cuentas en la base de datos suelen clasificarse en categorías como administradores de bases de datos (DBA), la aplicación, analistas, etc. El perfil de actividad de cada tipo de cuenta suele tener características únicas y una lista de riesgos distinta. Con estas características, podemos diseñar un plan específico para cada tipo de cuenta. Lo explicaremos más adelante, pero primero debemos clasificar las cuentas e identificar los riesgos.

Estos son los pasos:

• Agrupe las cuentas según su tipo. Por ejemplo: DBA, Aplicación, Conexión local, Analistas.
• Considere rutas de actividad inusuales, como conexiones locales y nuevas cuentas.
• Determine los riesgos para cada tipo de cuenta. Debe considerar cómo el usuario objetivo puede abusar de sus privilegios y cómo un hacker externo puede penetrarla. Una brecha externa podría ocurrir, por ejemplo, mediante el robo de credenciales. Las cuentas utilizadas por la aplicación también podrían ser explotadas mediante una vulnerabilidad, como una inyección SQL.

Por ejemplo, estos son tres tipos de cuenta estándar que existen en todas las bases de datos:

• DBA. Una categoría que incluye cuentas de DBA individuales y cuentas con privilegios compartidos, como SYS, SYSTEM o SA. Esta categoría está sujeta a riesgos como el abuso de privilegios, el robo de credenciales y la vulneración de escritorios.
• Aplicación. Un tipo de cuenta que incluye una o más cuentas de aplicación. Está sujeta a riesgos como el abuso de privilegios (por ejemplo, por parte de un administrador de aplicaciones), el robo de credenciales y vulnerabilidades (por ejemplo, la inyección SQL).
• Conexión local. En la mayoría de las bases de datos, existe al menos una cuenta del sistema operativo que puede conectarse a la base de datos sin contraseña. Por lo tanto, vulnerar la cuenta del sistema operativo del servidor otorga al atacante acceso a la base de datos. Los riesgos incluyen el abuso de privilegios y una cuenta del sistema operativo vulnerada.

Después de identificar nuestros grupos de cuentas y sus riesgos, comencemos a configurar los controles para cada uno.

Paso 3: Controles de Sesión

Los controles de sesión proporcionan protección según la información de conexión. Por ejemplo, la cuenta, el programa que se conecta y la dirección IP de origen. Estos son los controles más sencillos que se pueden implementar y son fáciles de entender.

Los controles de sesión son como juzgar un libro por su portada. Es la perspectiva más simple la que puede ofrecer mucha información, pero no se compara con mirar dentro. Son rápidos y fáciles de entender, y pueden ser suficientes para algunos vectores de ataque, pero no para todos.

Los controles de sesión se engloban en los mismos cuatro enfoques mencionados anteriormente:

• Informes y alertas: Estos informes muestran las conexiones a la base de datos. Por ejemplo, quién se conectó a las cuentas de administrador de base de datos (DBA), desde dónde y cuántas veces. También pueden alertarle cuando la cuenta de la aplicación tiene una conexión que no proviene del programa ni del equipo de la aplicación.
• Análisis de anomalías: Una anomalía puede alertarle cuando las conexiones provienen de orígenes inusuales. Por ejemplo, cuando un DBA se conecta desde un programa o una dirección IP inusuales. También puede enviar una alerta cuando una nueva cuenta, un nuevo programa, una combinación diferente de programa e IP, etc., se conecta a la base de datos.
• Análisis forense proactivo: Al igual que obtuvo visibilidad de la actividad de la base de datos en el paso 1, puede optar por utilizar este método como control continuo. Al evaluar periódicamente quién se conecta y desde dónde, puede detectar comportamientos sospechosos e identificar deficiencias en sus controles existentes.
• Preventivo: Puede bloquear la actividad de las conexiones que no cumplen con los requisitos específicos. Por ejemplo, puede permitir la actividad en la cuenta de la aplicación solo cuando se origina desde el servidor y el equipo de la aplicación.

Los controles de sesión suelen dirigirse a grupos de cuentas específicos, como administradores de bases de datos (DBA) o la aplicación. Sin embargo, también pueden ser globales, como alertar sobre nuevas cuentas o realizar una investigación forense proactiva.

Los controles de sesión suelen ser eficaces contra diversas formas de robo de credenciales, ya que explotarlas suele implicar conectarse desde una máquina o programa diferente. Sin embargo, son completamente ineficaces contra el abuso de privilegios o las vulnerabilidades de la aplicación, ya que este tipo de actividad proviene de fuentes válidas.

Paso 4: Controles SQL

Los controles SQL o de actividad ofrecen protección según la actividad dentro de la conexión. Por ejemplo, el nombre de una tabla dentro del SQL o el comando SQL (p. ej., Crear, Modificar, Eliminar, Insertar, Actualizar, Eliminar, Seleccionar).

Los controles de actividad son más complejos y requieren cierta comprensión de la actividad de la base de datos. Es importante comprender no solo lo que se está analizando, sino también cómo un adversario podría intentar lograr sus objetivos. En otras palabras, comprender cómo trabajan las personas en un entorno de bases de datos.

Los controles SQL son eficaces contra casi cualquier riesgo; solo es cuestión de saber qué buscar.

Es lo opuesto a juzgar un libro por su portada. Es como abrir un libro y mirar en su interior. Hay muchísima información y mucho que ver. De hecho, hay demasiada información, y es muy poco probable que pueda inspeccionarlo todo usted mismo. Sin embargo, si sabe lo que busca, puede encontrarlo basándose en las características que pueda presentar.

Los controles SQL se dividen en los mismos cuatro enfoques:

• Informes y alertas: Estos informes muestran una actividad específica, como un informe DDL para validar el control de cambios. También pueden alertarle cuando el administrador de base de datos (DBA) toca una tabla sensible.
• Análisis de anomalías: Una anomalía puede alertarle cuando se produce un cambio en el perfil de actividad de la base de datos. Por ejemplo, cuando la aplicación tiene una nueva construcción SQL que podría ser una inyección SQL. También puede alertar si una cuenta inusual accede a una tabla sensible o si se produce actividad en un momento inusual del día.
• Análisis forense proactivo: Obtener visibilidad de la actividad de la base de datos puede ser un potente control continuo. Al evaluar periódicamente quién accede a datos sensibles, a cuántos datos se accede y cuándo, puede detectar comportamientos sospechosos e identificar deficiencias en sus controles existentes.
• Preventivo: Puede bloquear la actividad que no se ajuste a sus expectativas. Por ejemplo, puede impedir que los DBA accedan a datos sensibles. También puede implementar la separación de funciones exigiendo a los DBA que obtengan códigos de amnistía antes de realizar actividades restringidas.

La mayoría de los controles SQL son específicos de tipos de cuenta concretos (p. ej., administradores de bases de datos o aplicaciones), pero en algunos casos pueden utilizarse globalmente, como en un informe DDL.

Estos controles son muy eficaces contra la mayoría de los riesgos. Funcionan tanto para actividades de alto riesgo como las de los administradores de bases de datos, como para actividades de gran volumen, como las aplicaciones que gestionan miles de millones de SQL. Este es un control indispensable para proteger la actividad cuando el origen de la misma parece legítimo (p. ej., un abuso de privilegios o una vulnerabilidad de la aplicación), y funciona igual de bien para actividades que probablemente tengan un origen diferente (p. ej., el robo de credenciales).

Controles Recomendados sobre el Robo de Datos

Toda organización debería diseñar controles específicos para su entorno. Sin embargo, muchas organizaciones utilizan algunos controles comunes. Analicemos estos controles y expliquemos por qué funcionan:

• Uso de cuentas de DBA (informe de sesión) o Anomalía de sesión de DBA. Este informe resume las conexiones a cuentas de DBA y con privilegios. También puede configurarlo como una alerta de anomalía que solo resalta los cambios en las fuentes de actividad. Este es un control importante contra el robo de credenciales de DBA, ya que detecta cuándo las conexiones de DBA provienen de fuentes inusuales o son sospechosas.
• Informe de acceso a datos confidenciales de DBA. Este informe enumera la actividad SQL de DBA que accede al esquema de datos o a las tablas de datos confidenciales. Las cuentas de DBA no suelen acceder a datos confidenciales. Es un control sólido, ya que si las conexiones de DBA no acceden a datos confidenciales, significa que no se han utilizado para el robo de datos. Es eficaz contra el abuso de privilegios de DBA, así como contra diversas suplantaciones de identidad de DBA (incluido el robo de credenciales).
• Anomalía de sesión de aplicación. Esta alerta le informa cuando la actividad de la aplicación proviene de una máquina que no es el servidor de aplicaciones o de un programa que no es la cuenta de la aplicación. Este es un control vital para combatir el robo de credenciales de aplicación y el abuso de la cuenta de aplicación. En ambos casos, las conexiones se originan en programas distintos del software de la aplicación.
• Anomalía de SQL de la aplicación. Este es un control crítico contra la inyección de SQL y muchos otros tipos de vulnerabilidades de la aplicación. La actividad de la aplicación siempre es repetitiva, incluso para aplicaciones que generan SQL dinámico. Esta alerta le informará cuando cambie el perfil de actividad de la aplicación.
• Informe DDL. Los DDL son cambios en los metadatos de la base de datos. Si bien no constituyen un robo de datos en sí mismos, los DDL pueden utilizarse para comprometer la seguridad. DCL es una subcategoría de los DDL que gestiona usuarios y permisos, mientras que otros DDL gestionan tablas, procedimientos, desencadenadores y más. Un informe DDL es un control fundamental para cerrar el ciclo y complementar el proceso de control de cambios.
• Anomalía de nuevo usuario y Anomalía de nuevo programa. Estas alertas de nuevas fuentes de actividad son importantes para controlar la superficie de ataque y mantenerle al tanto de cambios fundamentales en el perfil de actividad de la base de datos que requerirán el ajuste de sus controles. Por ejemplo, si un nuevo usuario se conecta a la base de datos, es algo que debe saber. Probablemente también necesite ajustar uno de los controles para supervisar a este nuevo usuario.
• Diagrama de dispersión o Anomalía de la relación filas/SQL. Estas prácticas inspeccionan básicamente el promedio de filas por SQL. El robo de datos muestra grandes extracciones que aumentan significativamente esta relación. Observar los diagramas de dispersión o el análisis de relaciones identifica rápidamente posibles extracciones. Por ejemplo, si una determinada combinación de usuario, programa e IP tiene una relación filas/SQL mucho mayor o si dicha relación cambia drásticamente, probablemente significa que esta conexión se utilizó para volcar una tabla.

Hay muchos más controles que puedes implementar, pero estos proporcionan una cobertura buena y amplia para la mayoría de las bases de datos contra la mayoría de las amenazas.

Revisión de controles

Aquí se muestra la correlación entre las amenazas y los controles recomendados. Simplemente revisamos las amenazas detectadas en el paso 2 (y añadimos algunas más):

• Riesgos para el administrador de bases de datos (DBA):
  • Abuso de privilegios. El informe de acceso a datos confidenciales del DBA revelará cualquier acceso malicioso por parte de los DBA. El informe DDL también es fundamental para garantizar que todos los cambios sean aprobados por el proceso de control de cambios y que los DBA no abusen de los DDL para obtener acceso. Para lograr un control más estricto, también puede implementar medidas preventivas que, por ejemplo, impidan el acceso del DBA a datos confidenciales y establezcan una separación de funciones.
  • Robo de credenciales. Una anomalía en la sesión del DBA le alertará cuando se utilicen las credenciales del DBA desde una máquina o programa inusual. El informe de acceso a datos confidenciales del DBA también le informará si la cuenta se utiliza para actividades maliciosas. Los controles preventivos más estrictos, como el bloqueo del acceso o la separación de funciones, también son eficaces.
  • Escritorio comprometido. Un escritorio de DBA comprometido es idéntico, desde la perspectiva de la base de datos, a un abuso de privilegios y se beneficia de los mismos controles.
• Riesgos de la Aplicación:
  • Abuso de privilegios. La alerta de anomalía de sesión de la aplicación detectará un abuso de privilegios, ya que dicho abuso se originará en un programa diferente y probablemente también en una máquina distinta. Si los administradores utilizan la cuenta de la aplicación con frecuencia, la anomalía de SQL de la aplicación alertará sobre un comportamiento inusual. Sin embargo, si los administradores utilizan esta cuenta con frecuencia, se recomienda implementar también las medidas de DBA en esas sesiones específicas.
  • Robo de credenciales. El robo de credenciales de la aplicación se manifiesta de forma similar al abuso de privilegios y puede detectarse con las mismas medidas.
  • Vulnerabilidad (p. ej., inyección SQL). La anomalía de SQL de la aplicación detectará una vulnerabilidad de la aplicación. Esta anomalía detectará cualquier cambio en el perfil de actividad de la aplicación, y una vulnerabilidad explotada, inevitablemente, cambiará dicho perfil. Para un control más estricto, también puede realizar investigaciones forenses o configurar anomalías en los volúmenes de actividad. Puede supervisar el número de SQL o el número de filas procesadas.
• Riesgos de Conexión Local:
  • Abuso de privilegios. En conexiones locales, esto constituye un abuso por parte de los administradores de bases de datos (DBA) y se identificará de la misma manera que otros abusos de privilegios por parte de DBA.
  • Cuenta del sistema operativo vulnerada. En la mayoría de las bases de datos, los DBA utilizan las cuentas del sistema operativo local con regularidad, pero con poca frecuencia. Puede configurar una alerta de inicio de sesión si la cuenta se utiliza con poca frecuencia. Dado que esta cuenta suele ejecutar las mismas SQL, una alerta de SQL anómala sería eficaz. En todos los casos, los controles del DBA, como el informe de acceso a datos confidenciales, detectarían el ataque.

Para que sea eficaz, deberá ajustar los controles a su entorno. Por ejemplo, si la aplicación utiliza una cuenta privilegiada como “SA”, los controles deben distinguir entre el acceso de DBA y el acceso a la aplicación (normalmente según el programa o la máquina). Se recomienda encarecidamente que las aplicaciones utilicen una cuenta dedicada con privilegios mínimos. Sin embargo, este tipo de cambio puede ser difícil y requerir mucho tiempo de implementación. Otro ejemplo de ajuste es que los informes DDL a menudo deben excluir tablas temporales o actividades comunes similares que pueda tener en su entorno.

Puede observar que las recomendaciones de control incluían una anomalía de nuevo usuario y un diagrama de dispersión que no se asignaron a los riesgos. La anomalía de nuevo usuario se asigna al riesgo de una nueva cuenta en la base de datos. Parte de ese riesgo proviene de que un DBA cree una nueva cuenta para robar datos. Sin embargo, la mayor parte del riesgo reside en no ajustar los controles de seguridad cuando hay un nuevo usuario. El control del diagrama de dispersión es más global y tiene como objetivo identificar grandes extracciones de datos de la base de datos, independientemente de cualquier riesgo específico.

	DBA			Aplicación			Local
	Abuso de Privilegios	Robo de Credenciales	Escritorio comprometido	Abuso de Privilegios	Robo de Credenciales	Vulnerabilidad	Abuso de Privilegios	Cuent OS
Uso de la cuenta DBA Anomalía en la sesión DBA		X
Acceso a datos confidenciales del DBA	X	X	X				X	X
Anomalía en la sesión de la aplicación				X	X
Anomalía de SQL de la aplicación				X	X	X
Informe DDL	part.	part.	part.	part.	part.	part.	part.	part.
Anomalía de nuevo usuario Anomalía de nuevo programa	part.	part.	part.	part.	part.	part.	part.	part.
Diagrama de dispersión Anomalía en la relación filas/SQL	X	X	X	X	X		X	X

Conclusión

Hay dos cosas que debe reconocer: primero, proteger la base de datos es importante. segundo, es posible. Este artículo pretende demostrar estos hechos.

En el pasado, las tecnologías de seguridad de bases de datos eran mucho menos efectivas. Nuestra incapacidad para defenderlas hizo que la mentalidad de seguridad pasara de centrarse en lo obvio a centrarse en las herramientas disponibles que aportaban valor.

La tecnología de seguridad de bases de datos ha cambiado drásticamente en los últimos 25 años. Las tecnologías modernas son mucho más efectivas tanto para capturar como para analizar los datos. Al mismo tiempo, los atacantes encontraron formas nuevas y efectivas de penetrar el perímetro, lo que limita la eficacia de esas defensas. La ineficacia del perímetro acentúa aún más la necesidad ineludible de proteger la base de datos.

Detectar y prevenir el robo de datos a nivel de base de datos no solo es posible, sino que es un paso crucial en la seguridad. Si bien requiere un poco de trabajo y conocimientos técnicos, las tecnologías modernas lo convierten en la medida más eficaz para identificar un ataque y responder a él.

Siga los vectores de ataque que llevan a los atacantes a los datos. Un control eficaz de la actividad que accede a los datos le permite detectar, prevenir y responder ante una filtración de datos en caso de que ocurra. Una vez que aborde estas diferentes amenazas, combatirá con éxito el riesgo de robo de datos.

La base de datos es el único punto que controla todos los accesos a los datos. No hay otro punto igual. No hay alternativa a las soluciones avanzadas de seguridad de bases de datos. La base de datos es la última y más poderosa línea de defensa en la batalla contra el flagelo del robo de datos.

A medida que avanzamos hacia el futuro utilizando la nube y el teletrabajo, el perímetro se desintegrará por completo. Controlar los datos es el único camino a seguir.

¿Listo para ir más allá de la seguridad perimetral y construir una defensa adecuada para sus datos? Contáctenos para aprender a construir una seguridad robusta de bases de datos con Core Audit.