1
PROBLEMAS DE SEGURIDAD EN BASES
DE DATOS
John A. Jiménez Cano – johnjimenez09@hotmail.com
 actuales. Pero para poder hablar de las vulnerabilidades y
Resumen— Los problemas en las bases de datos muchas veces
son más humanos que esencialmente de sistemas. Sin embargo, es
bueno conocer algunos de estos problemas para identificar como
se pueden solucionar y a que se enfrentan los administradores de
las bases de datos. Por lo menos para que los más simples no se
presenten y si se presentan tengan una pronta solución. De esta
manera, es así como cada uno de estos problemas tiene ciertas
configuraciones que se pueden realizar para prevenirlos, evitarlos
o después de presentados arreglarlos. Es aquí donde identificarlos
ayuda de sobremanera para proteger lo más importante de toda
organización, los datos, en este artículo se mostrarán los
problemas que pueden existir en la autenticación de las bases de
datos, el cifrado de las conexiones, las fallas de seguridad, los
mecanismos de respaldo y los problemas en la arquitectura de las
bases de datos.
Índice de términos— Autenticación, Control de Acceso,
Autorización, Encriptación, Cifrado, denegación de servicio,
inyección de código, auditoria, actualización, administradores de
bases de datos.
Abstract— Problems in databases are often more human than
essentially systems. However, it is good to know some of these
problems to identify how they can be solved and what the
administrators of the databases are facing. At least so that the
simplest do not arise and if they are presented have a prompt
solution. In this way, this is how each of these problems has certain
configurations that can be made to prevent them, avoid them or
after they are presented fix them. It is here where to identify them,
to help protect the most important thing of any organization, the
data, in this article the problems that can exist in the
authentication of the databases, the encryption of the connections,
the security failures, the backup mechanisms and problems in the
architecture of the databases.
Index Terms— Authentication, Access Control, Authorization,
Encryption, Encryption, denial of service, code injection, audit,
update, database administrators.
I. INTRODUCIÓN
A L igual que cualquier otro sistema de información, las
bases de datos no están exentas de sufrir problemas de
funcionamiento, malas programaciones, pésimas
configuraciones o errores conocidos. Más aun, no son
completamente infalibles a los problemas de seguridad que las
mismas puedan presentar en los desarrollos informáticos
riesgos que pueden tener las bases de datos es necesario hablar
de cómo están estructuradas, cuáles son sus mecanismos de
seguridad y cuáles han de ser las responsabilidades de las
personas que se encargan de configurarlas, tanto como de
administrarlas.
Las bases de datos contienen información que es relevante
para el negocio (toda la información de empresas,
corporaciones y también multinacionales se administra a través
de estos sistemas de información) y su continuidad operacional.
Pero esta información está relacionada con el tipo de base de
datos implementado para trabajarla y almacenarla
(relacional o no relacional) lo cual hace que la misma se
encuentre en un formato, un lenguaje, con sus mecanismos de
cifrado, autenticaciones de acceso y controles de seguridad
implementados para la preservación de la información y la
disponibilidad de la misma.
Conocer esta disposición de estructura y mecanismos o
controles de seguridad de algunas de los diferentes sistemas de
gestión de bases de datos y de los motores de bases de datos en
sí, nos ayudaran a identificar de manera oportuna algunas de las
fallas de seguridad más conocidas, ayudándonos a reducir las
brechas de inseguridad que se puedan presentar. Además de
conocer los mecanismos de respaldo para realizar las copias de
seguridad de las bases de datos, los mecanismos de
recuperación de la información en caso de pérdida o daño y cuál
de estas funciones pertenecen a los administradores de las bases
de datos (BDA) o los programadores y/o constructores de la
misma.
II. AUTENTICACIÓN EN BASES DE DATOS
Como mucho de los sistemas actuales, las bases de datos nos
son exentas de manejar un sistema de autenticación para
permitir el ingreso de usuarios a los datos que el SGBD
contiene. Tanto, motores de bases de datos convencionales
denominados SQL, como los que llevan años en el mercado,
pero en la actualidad empiezan a tomar auge e importancia
como los NO-SQL. Sin embargo, la seguridad es
completamente transversal a todos los sistemas y todos o
ninguno por mejor decirlo tiene un 100% de seguridad. Y tal
vez una de las brechas más apetecibles por los atacantes sea la
del sistema de autenticación.

La autenticación basada en contraseña es probablemente
una de las funciones más importantes que se usan todos los días,
sin embargo, no se ha evolucionado mucho desde los primeros
sistemas informáticos de usuarios múltiples, incluso cuando se
desarrollan métodos más seguros. Los esquemas de
autenticación débiles permiten a los atacantes asumir la
identidad de los usuarios de bases de datos legítimos.
Estrategias de ataque específicas incluyen ataques de fuerza
bruta, la ingeniería social, y así sucesivamente.
La implementación de contraseñas o autenticación de dos
factores es una necesidad. Para la escalabilidad y facilidad de
uso, los mecanismos de autenticación deben integrarse con las
infraestructuras del directorio / gestión de usuarios de la
empresa y seguridad web. [1]
De esta manera, en este problema que aqueja a las bases de
datos, existen dos tipos de autenticación, la lógica (usuario y
contraseña) e identificación por Hardware.
A. Mecanismos de autenticación lógicos
Las claves de acceso, que se utilizan de manera general para los
SGBD deben otorgárseles características especiales, para evitar
que se convierta en un problema al permitir contraseñas o claves
de usuario demasiado sencillas. Hoy en día no es raro
encontrarnos pares de datos “usuario/password” del tipo
“admin/12345” o similar. Esta es la primera línea de defensa de
entrada a nuestra información y debemos optar por el uso de
algo más complejo que sea complicado de conseguir por parte
de cualquier atacante.
Algunos sistemas muestran asteriscos al momento del
ingreso de una clave (********) y otros simplemente no
muestran nada, para ni siquiera dar la evidencia de cuántos
dígitos tiene esa clave. Otras características que hacen a las
claves un buen control, y que no sea un problema es:
 El forzar un tamaño en dígitos mínimo.
 Obligar mezclas de números y letras (no sólo números o
sólo letras)
 Prohibir el uso de datos personales, como nombre apellido
o fecha de cumpleaños como clave.
 Obligar un tiempo mínimo de uso de clave para no volver a
la anterior luego de haberla cambiado.
Otro de los problemas que se presentan con relación a los
usuarios es la definición de los privilegios que se concederán a
los usuarios después de garantizar una autenticación de acceso
a los servicios de SGBD. Algunos motores de base de datos
cuentan con un segundo mecanismo de “autorización” con el
cual se le conceden permisos para realizar cambios a nivel de
un objeto de la Base de datos para que tengan permisos de
escribir sentencias como SELECT, GRANT Y REVOKE, y
tener los privilegios adecuados para dichos cambios.
A estos usuarios se le pueden conceder autorización para
visualizar los datos de un subconjunto de columnas definidas
en “una vista” las cuales proporcionan variedad de los controles
de seguridad Una vez que un usuario ha tenido acceso al
2
sistema, tendrá disponibles ciertas funciones, y otras no,
dependiendo de la definición que hayamos hecho. Por ejemplo,
un usuario de tipo A puede leer los archivos de información de
clientes, pero no podrá actualizarlos. Un usuario de tipo B podrá
hacer esas actualizaciones. Los mecanismos de autenticación
compleja dependen de que un usuario proporcione información
que sólo él sepa y de que un dato personal se pueda verificar.
Un nombre de usuario es un ejemplo de información que la
persona sabe.
Algunos métodos de autenticación lógicos que se tienen en
las diferentes bases de datos pueden ser:
 Kerberos: Sistema de seguridad para sistemas distribuidos
sobre una red pública.
 Ident: Método de autenticación mediante usuario de sistema
operativo, se basa en el protocolo RCF 1413.
 PAM: método de autenticación que hace uso de los módulos
PAM con el objetivo de conseguir la autenticación.
 RPC seguro: un mecanismo de autenticación que utiliza el
protocolo de Diffie-Hellman para proteger los montajes NFS
y un servicio de nombres, como NIS o NIS+.
 Autenticación sencilla y capa de seguridad (SASL): una
estructura que proporciona servicios de autenticación y
seguridad para protocolos de red.
 Secure Shell: un protocolo de inicio de sesión remoto seguro
y transferencia que cifra comunicaciones en una red no
segura.
Para que este problema sea más mitigable en las
organizaciones, las bases de datos deben respaldarse por
políticas y procedimientos dentro de las organizaciones, que no
permitan las contraseñas simples o fáciles al definir sus
atributos, además de la segregación de permisos dependiendo
del tipo de usuario o rol que este tenga, entre estos podemos
encontrar algunos tales como:
 ID de Autorización: Se controla el acceso a los datos mediante
la utilización de identificadores para representar cada proceso
o inicio de sesión den DB2.
 Privilegios y autorizaciones ID de autorización: Control por
medio de conjunto de privilegios <<acción sobre un objeto>>
 Control Subsistemas DB2: Comprobaciones de seguridad
antes de acceder a cualquier dato del sistema o subsistema.
 Control de Acceso a objetos mediante autorizaciones y
privilegios explícitos: Permite la segregación de privilegios a
niveles más profundos, no solo de esquema, base de datos o
tabla sino mucho más interiorizado.
 Control de acceso a nivel de fila y/o Columna: Se controla el
acceso a nivel de fila y columna para restringir el acceso a
ciertos tipos de información que exigen seguridad adicional.
 Seguridad a Varios Niveles: Política de seguridad que
clasifica los datos y usuarios según sistema de seguridad
jerárquicos.
 Utilización de vistas para control de acceso: Se pueden
otorgar permisos a nivel de Vista para conceder privilegios
sobre esta y proporcionar a un ID de Autorización el acceso a
un subconjunto específico de datos.

B. Mecanismos de autenticación por Hardware
Existen varios mecanismos a nivel de hardware para
autenticación de los diferentes motores de las bases de datos,
los cuales también deben programarse correctamente para que
no se conviertan en un problema por “vulnerabilidad de
plataforma”, muchas de estos tipos de problemas están dados
por la autenticación a nivel de servidor, en la mayoría de los
casos, como por ejemplo con Oracle, se puede escoger un tipo
de autenticación OPS$ que define que la cuenta no se almacena
en la base de datos, sino que tiene una autenticación externa,
como por ejemplo en los sistemas operativos Windows®
Por ejemplo, es muy común que en sistemas operativos Linux,
se configure la base de datos con el usuario súper-administrador
“root” y la clave sea la misma, por lo cual, al conseguir la clave
del servidor, se tiene la clave de acceso a la base de datos. Cabe
también aclarar que, aunque es un error de principiante, no se
está exento al problema de que la configuración inicial de las
bases de datos viene con la contraseña de “root” en blanco y no
se debe dejar así, ya que es un problema de seguridad enorme.
Otro tipo de autenticación que se puede dar por medio de
hardware para evitar el problema de la mala configuración de la
autenticación son los mecanismos de autenticación como:
 Server_Encrypt: La autenticación también se lleva a cabo en
el servidor, pero las contraseñas son cifradas en la máquina
cliente ante de viajar por la red hacia el servidor.
 Kerberos: La autenticación es dada por este software.
 Data_Encrypt: La autenticación se lleva a cabo al lado del
servidor, sin embargo, tanto las contraseñas como los datos de
conexión y de usuario son encriptados en la máquina cliente.
Se diferencia del server_encrypt ya que el primero solo cifra
la contraseña mientras que este último, cifra todos los datos.
 Autenticación LDAP: Un grupo seguro de Elasticsearch
puede autenticar a los usuarios desde un directorio del
Protocolo ligero de acceso a directorios (LDAP). Con la
autenticación LDAP, puede asignar roles a los grupos LDAP.
Cuando un usuario se autentica con LDAP, los privilegios
para ese usuario son la unión de todos los privilegios definidos
por los roles asignados al conjunto de grupos al que pertenece
el usuario.
 Directorio Activo: Autenticación a través de un servicio
externo de Active Directory.
 Autenticación de usuario basada en archivos: Puede
administrar y autenticar usuarios con el reino interno del
archivo incorporado. Con el reino de archivos, los usuarios se
definen en archivos locales en cada nodo del clúster.
3
También se deben optar por formas de mejorar la seguridad a
nivel de hardware con dispositivos como:
Tarjeta inteligente: Permite suplementar la protección del
proceso de autenticación. La contraseña puede así ser muy
compleja y cambiada regularmente de manera automática y
aleatoria. Sin la tarjeta, y sin su código PIN, no se puede acceder
a la contraseña. Esta solución se aplica generalmente para el
proceso de autenticación inicial
Autenticación biométrica: Se basa en la verificación de un
elemento del cuerpo del usuario (generalmente la huella
dactilar). Puede basarse en un distribuidor central, en el puesto
de trabajo o en una tarjeta inteligente para almacenar los datos
biométricos del usuario. Esta solución se aplica en general para
el proceso de autenticación inicial y/o para proteger el acceso a
aplicaciones muy sensibles.
El RFID es una tecnología que hoy se despliega en los
proyectos de Identificación/Autenticación. Un chip RFID es
insertada en una tarjeta y lleva un número de identificación.
Este número se asocia a continuación a un usuario en un sistema
informático. A la base es una tecnología de Identificación que
puede, acoplado a una contraseña proporcionada por el usuario,
por ejemplo, utilizarse en procedimientos de autenticación.
Token: Una de las técnicas utilizada es el “token” de
autentificación. Este “token” es un conjunto de datos que
contienen los elementos que comprueban la identidad del
usuario y que presenta a la aplicación.
El OTP emplea un dispositivo de seguridad en posesión del
usuario y un servidor back-end. El dispositivo de seguridad
puede estar basado en hardware, como por ejemplo un llavero
de control remoto a prueba de manipulaciones, o basado en
software, como, por ejemplo, una aplicación de teléfono móvil.
Es por esto, que todo administrador de un SGBD debe validar
de acuerdo a su presupuesto y a lo que la organización quiera
proteger, cuál de estos sistemas o mecanismos de autenticación
considera mejor para resguardar sus datos y evitarse así los
problemas de seguridad que se le pueden presentar por no
proteger correctamente los datos y permitir, privilegios
excesivos, autenticación débil o vulnerabilidades en la
plataforma.
De igual forma, es considerable cambiar la configuración por
defecto que trae todo motor o sistema de base de datos, ya que
este es universal y por consiguiente muchas personas ya
conocen como acceder y vulnerarlo. Conocen los usuarios y las
claves iniciales de cada uno de estos sistemas, como por
ejemplo que en MySQL se autentiquen por defecto con root, o
que en SQL Server con SA entre otros.

Ilustración 1 Fuente: https://www.onasystems.net/wp-
content/uploads/2016/09/Bases-de-datos-Vulnerabilidad.jpg
III. CIFRADO DE CONEXIONES E INFORMACIÓN EN
SGBD
Otro de los grandes problemas que se pueden presentar en
seguridad de bases de datos es una constante preocupación la
configuración de los procesos de conexión. Es su configuración
para cifrar o escribir en forma de clave tanto la información que
hace parte de la base de datos como las conexiones entre las
mismas. O entre el SGBD y la aplicación a la que esta
suministra la información.
Por lo cual, es necesario conocer con que se cuenta en el
cifrado del motor de base de datos para evitar o prevenir que se
presenten estos problemas de seguridad.
Las vulnerabilidades en los protocolos de bases de datos
pueden permitir el acceso no autorizado a datos, la corrupción
o la disponibilidad. Por ejemplo, SQL Slammer worm se
aprovechó de una vulnerabilidad de protocolo de Microsoft
SQL Server para ejecutar código de ataque en los servidores de
base de datos destino.
Los protocolos de ataques pueden ser derrotados mediante el
análisis y validación de las comunicaciones de SQL para
4
asegurarse de que no están malformados.
A. Cifrado de Conexiones
Algunos sistemas de gestión de base de datos, sino todos,
admiten el uso de Secure Sockets Layer (SSL) y su sucesor,
Transport Layer Security (TLS), para permitir que un cliente
autentique un servidor y para proporcionar comunicación
privada entre el cliente y el servidor mediante el uso de
cifrado. La autenticación se realiza mediante el intercambio
de certificados digitales. Sin cifrado, los paquetes de
información viajan a través de las redes a plena vista de
cualquier persona que tenga acceso. Puede usar SSL para
proteger los datos en tránsito en todas las redes que usan TCP
/ IP (puede pensar en una conexión SSL como una conexión
TCP / IP segura).
“La autenticación con cifrado es la base de una
comunicación segura. La autenticación ayuda a garantizar
que el origen y el destino sean las partes deseadas. El cifrado
codifica la comunicación en el origen y decodifica la
comunicación en el destino. El cifrado impide que los
intrusos puedan leer cualquier transmisión que logren
interceptar. Entre las funciones de Oracle Solaris para la
comunicación segura, se incluyen:
Secure Shell: un protocolo para proteger transferencias de
datos y sesiones de red de usuarios interactivos contra
intrusiones, usurpaciones de sesión y ataques de tipo “Man-
in-the-middle”. La autenticación compleja se proporciona
mediante criptografía de clave pública. Los servicios de
ventanas X y otros servicios de red se pueden enviar por túnel
de manera segura mediante conexiones de Secure Shell para
obtener una protección adicional.
Servicio Kerberos: una arquitectura de cliente y servidor
que proporciona autenticación con cifrado.
Arquitectura de seguridad de protocolo de Internet (IPsec):
una arquitectura que proporciona protección de datagramas
de IP. Las protecciones incluyen la confidencialidad, la
integridad sólida de los datos, la autenticación de datos y la
integridad de secuencia parcial.”
B. Cifrado de Información
Es importante verificar que la información que se tiene en la
base de datos, si es de vital importancia esté cifrada, en relación
a la importancia de estos datos. Es muy posible que cierta
información pueda caer en manos de las personas equivocadas
porque les fue posible superar nuestra seguridad o encontraron
un problema en nuestra seguridad que supieron explotar. Sin
embargo, si esta información se encuentra encriptada o cifrada,
les será muy difícil a los atacantes obtener los datos reales, ya
que primero deben lograr descifrar la información que

obtuvieron. Así que uno de los problemas que afrontan muchas
veces es la encriptación de la información, por no poseer un
sistema que logre encriptar los datos importantes para la
compañía y que eviten que en caso de pérdida, estos sean muy
difíciles o imposibles de acceder. Entre algunos de estos
métodos de encriptación de datos podemos contar con:
Cifrado sobre objetos: algunos SGBD permiten realizar una
segregación más a fondo sobre tablas, filas o columnas para
realizar un cifrado más personalizado y no una llave primaria al
principio de la data, de esta manera evita que un hacker con un
id y contraseña pueda llevarse estos datos. Por esto, se ofrece
una capa de cifrado a columnas que encripta la información
confidencial de los datos que allí reposan. Todo esto se realiza
a través de una segunda contraseña de cifrado con una longitud
de 6 a 127 bytes.
MD5: Es otro algoritmo de cifrado con el cual se pueden
guardar contraseñas, aunque se ha demostrado que este
algoritmo presenta vulnerabilidades, en la práctica sigue siendo
complejo alcanzar esta contraseña, por lo cual no vale la pena
el esfuerzo.
AES: El algoritmo AES es el más completo y complejo, tiene
posibilidad de revertirse y se utiliza con una llave privada, es
decir, debemos proporcionar dicha llave para encriptar y
desencriptar las contraseñas. Sería vulnerable en el caso de que
alguien consiguiese violar nuestro código fuente y viera que
llave estamos pasando a la cadena.
El propósito de un sistema de cifrado seguro es convertir texto
plano de datos en ininteligible texto cifrado basado en una
clave, de tal manera que es muy difícil (computacionalmente
imposible) para convertir texto cifrado de nuevo en su
correspondiente texto plano sin el conocimiento de la clave
correcta
IV. PRINCIPALES CAUSAS QUE GENERAN FALLAS
DE SEGURIDAD EN LAS BASES DE DATOS
Causa Física: Daño en el servidor donde se aloja la base de
datos, daño de disco o CPU pueden ocasionar perdida de
información de una transacción que se estuviera ejecutando.
Causa del Entorno: Un desastre natural o provocado en el lugar
donde reside la base de datos (DataCenter) tales como
terremotos, incendios entre otros.
De programación: Huecos o fallas de seguridad dejadas
durante la creación del código o programación de la base de
datos o asignación de permisos que se convierten en
vulnerabilidades que pueden ser explotadas por medio de
ataques cibernéticos con personas con conocimientos.
Características de bases de datos innecesariamente habilitadas
Cada instalación de base de datos viene con una serie de
5
paquetes o módulos adicionales de distintas formas y tamaños
que en muy pocas ocasiones todos ellos son utilizadas por las
compañías, lo que las convierten en una posible puerta de
entrada para sufrir algún tipo de ataque si en esos paquetes se
descubre cualquier problema de seguridad. Para reducir riesgos,
es recomendable que los usuarios detecten esos paquetes que no
se utilizan y se desactiven del servidor donde estén instalados.
Esto no sólo reduce los riesgos de ataques, sino que también
simplifica la gestión de parches ya que únicamente será de
máxima urgencia actualizar aquellos que hagan referencia a un
módulo que estemos utilizando.
De personal: Dejar contraseñas que pueden ser robadas,
programar malas contraseñas, no estar pendiente de la correcta
ejecución del backup o no revisar los logs para corroborar que
si se hizo correctamente el backup. La asignación de permisos
son criterios de medida entre otras.
Bases de datos sin actualizar Como ocurre con cualquier tipo
de aplicación que tengamos instalada en nuestra máquina, es
necesario ir actualizando la versión de nuestra base de datos con
las últimas versiones lanzadas al mercado, ya que en ellas se
solucionan aquellos problemas de seguridad detectados, por lo
que pondremos más barreras a los posibles atacantes.
Inyecciones SQL Un ataque de este tipo puede dar acceso a
alguien a una base de datos completa sin ningún tipo de
restricción, pudiendo llegar incluso a copiar y modificar los
datos.
Desbordamiento de búfer Se trata de otro de los medios
favoritos utilizados por los piratas y que se dan por el exceso de
información que se puede llegar a enviar por medio del ingreso
de información mediante el uso de formularios, es decir, se
recibe mucha más información de lo que la aplicación espera.
Por poner un ejemplo, si se espera la entrada de una cuenta
bancaria que puede ocupar unos 25 caracteres y se permite la
entrada de muchos más caracteres desde ese campo, se podría
dar este problema.
Datos sensibles sin cifrar, Aunque pueda ser algo obvio, a la
hora de la verdad no todo el mundo cifra la información más
importante que se almacena en base de datos. Esto es una buena
práctica para que en caso de hackeo, sea complicado para el
atacante poder recuperar esa información.
Confidencialidad y cifrado en el almacenamiento. Por lo
general, el almacenamiento de los datos se realiza en texto
plano y salvo escasas excepciones como por ejemplo Cassandra
y su tecnología Transparent data encryption, no se incorporan
mecanismos de cifrado integrados. En la mayoría de los casos
sigue siendo necesario delegar el cifrado a procesos en la capa
de aplicación o del propio sistema de ficheros.
Causa Autenticación: Es muy común en Cassandra encontrar
cuentas de usuario sin auditar, o que incorporan credenciales
por defecto, basadas en entornos de confianza en lugar de la
autenticación del usuario. Es un punto fundamental de chequeo

para realizar las respectivas configuraciones. También es muy
dado encontrar que Cassandra no exige mayor seguridad en sus
contraseñas, las claves de registro de usuarios no pasan por
cumplir con estándares de contraseñas fuertes. Es decir,
permiten que los usuarios utilicen contraseñas simples o fáciles
de identificar.
Seguridad en las comunicaciones. El uso de cifrado y
protocolo SSL es habitual en bases de datos relaciones, en
cambio en sistemas NoSQL generalmente se encuentra
deshabilitado por defecto, es opcional (por ejemplo,
Cassandra), o bien es necesaria una configuración específica en
la instalación (MongoDB).
Causa Auditoria de Datos: Carece de mecanismos propios y
robustos de auditoria como en las relacionales, lo que le impide
detectar posibles ataques mediante la observación de eventos en
los registros.
Error de nodos: Las fallas de los nodos o los tiempos de espera
pueden resultar de bloqueos del proceso de búsqueda de
elasticsearch o de los nodos en sí. Este tipo de falla es menos
común, y generalmente es el resultado de una carga de recursos,
como la sobrecarga de un clúster que es demasiado pequeño
para el volumen de datos / solicitud. Recomendamos
permanecer dentro de una proporción de datos de 1x5 a RAM.
Si el tiempo de respuesta de la solicitud es importante, debe
tener una proporción de 1-1 dependiendo de la complejidad de
sus consultas.
Explosion de mapas: Una forma rápida de hacer que una base
de datos se quede sin memoria y tener dificultades para
recuperarse es ignorar la diferencia entre claves y valores al
indexar documentos, en esencia es que las claves en los
documentos cambian, con el resultado de que las asignaciones
para el índice son cada vez mayores. A pequeña escala, esto
requerirá una gran cantidad desproporcionada de espacio de
almacenamiento dinámico y, para los clústeres más grandes,
normalmente causará problemas con la distribución del estado
del clúster.
Demasiados fragmentos o el problema de fragmentos de
Gazillion: Demasiados fragmentos o el problema de gazillion
shards, como a algunos de los desarrolladores de Elasticsearch
les gusta referirse a él, se debe al hecho de que existe un costo
base para cada fragmento e índice, incluso si no contiene ningún
documento.
Scripting: En la academia es un problema conocido que no se
puede determinar si un proceso en ejecución terminará o no, y
como Elasticsearch no tiene un tiempo de espera para los scripts
de ejecución prolongada, el siguiente script nunca se detendrá.
Esto hace que el script guarde un hilo de búsqueda que nunca
se volverá a lanzar al grupo. Las ejecuciones posteriores de
dichos scripts consumirán finalmente todos los subprocesos de
búsqueda y pondrán todas las búsquedas futuras en la cola hasta
que la cola alcance su máximo y todas las búsquedas futuras se
6
detengan. Este es también el caso de los nuevos scripts de
espacio aislado.
V. MECÁNISMOS Y PLAN DE RESPALDO DE LAS
BASES DE DATOS
Otros de los problemas de seguridad que pueden tener las
bases de datos, es no definir correctamente un mecanismo de
respaldo de la información que allí se tiene a fin de generar
copias de respaldo de la infraestructura o la data de forma
correcta. Muchas veces, los administradores de bases de datos
programan los backups que se realizarán sobre las bases de
datos, pero no verifican que estas copias hayan quedado
correctamente ejecutadas en los logs.
De esta manera, solo existe la ejecución, pero la data que se
respalda no sirve porque está mal respaldada, porque está
corrupta y no sirve para volver a restaurar la base de datos o
porque sencillamente, aunque la tarea se disparó y se ejecutó el
backup no hay información en él.
VI. RESPONSABILIDADES EN LA PROTECCIÓN DE LA
INFORMACIÓN EN UNA BASE DE DATOS
Otro de los riesgos o problemas de seguridad que se pueden
tener a la base de datos, es que el administrador de la misma no
cumpla con sus responsabilidades a la hora de realizar su trabajo
con los SGBD, por esto, se debe vigilar que estos profesionales
cumplan con sus responsabilidades, las cuales deben ser:
a) Mantener, administrar y controla los elementos que
conforman la Base de Datos e informar de los cambios
a los usuarios.
b) Asegurar la máxima disponibilidad de los datos, por
ejemplo, haciendo copias de seguridad e los datos,
administrando los dietarios entre otros.
c) Resolver emergencias que se presenten en las bases de
datos y que ocasionen indisponibilidad del servicio.
d) Vigilar la integridad y calidad de los datos.
e) Diseñar el nivel físico de la Base de Datos, las
estrategias de caminos de acceso y las
reestructuraciones.
f) Controlar el rendimiento y las decisiones relativas a
las modificaciones en los elementos que confirman la
Base de Datos y/o parámetros del SGBD y del sistema
operativo.
g) Establecer normativas y asesorar a los programadores
y los usuarios finales sobre la utilización de la Base de
Datos.
h) Controlar y administrar la seguridad: gestión de
usuarios, concesión y revocación de autorizaciones
entre otros.

VII. CONCLUSIONES
Como todo sistema en lo que a las tecnologías se refiere los
sistemas de gestión de bases de datos no están libres de
presentar problemas de seguridad o vulnerabilidades que
puedan ser aprovechadas por personas con o sin experiencia en
causar daño en la información, deteriorando y no asegurando
los pilares de confidencialidad, integridad y disponibilidad de
la misma.
Sin embargo, es de reconocer que muchos de estos problemas
están basados en errores u olvidos humanos, ya que se puede
determinar que parte de estos problemas provienen de
contraseñas débiles, muchos permisos a usuarios que no los
necesitan, dejar las configuraciones iniciales o por defecto con
las que los motores de bases de datos se instalan, debilidad en
el endurecimiento de las plataformas de sistema operativo sobre
las que se instalen estos motores entre otros. Sin embargo, los
otros aspectos de problemas de seguridad en bases de datos
también son prioritarios y tan importantes como los primeros,
por esto, como profesionales en seguridad informática es
prioritario identificar estos hallazgos dentro de la configuración
de los SGBD a nivel de posibles vulnerabilidades que sean
aprovechadas por ataques de inyección de código, de
denegación de servicio o de una auditoria débil para no ver los
posibles problemas que se presentan.
También es importante recordar los protocolos y los
mecanismos de cifrado que se pueden tener en una base de
datos, protocolos como SSL o TSL y cifrados como MD5 o
HASH1 entre otros que logren mitigar los problemas que se
puedan presentar por la no configuración de estos. O el no cifrar
las contraseñas y que al viajar a través de la red en texto plano
o sin cifrado puedan ser interceptados por ataques de Sniffer o
MIM.
De esta forma es necesario realizar las configuraciones
necesarias para evitar que estos problemas que son comunes y
están presentes en los SGBD se vuelvan más grandes y puedan
incurrir en problemas de seguridad en toda la infraestructura de
una entidad.
REFERENCIAS BIBLIOGRÁFICAS
[1] Milligan, Kent. “Seguridad y Cifrado de datos en DB2” Recuperado de:
http://www.help400.com/test/M02.htm
[2] Desarrollador de base de datos Recuperado de:
https://www.quest.com/mx-es/toad/database-developer.aspx
[3] Reded Tinoco, Bruno. Configuración de la arquitectura base de Apache
Cassandra (2018) Recuperado de:
https://www.ibm.com/developerworks/ssa/library/ba-set-up-apache-
cassandra-architecture/index.html
[4] Lopez, Antonio. (2015) “Bases de datos NoSQL. Rendimiento y...
¿seguridad?” Recuperado de: https://www.incibe-
cert.es/blog/bases-de-datos-nosql.
[5] Operaciones de copia de seguridad, restauración y de recuperación en
avance dentro deDB2 pureScale Feature Recuperado de:
7
https://www.ibm.com/support/knowledgecenter/es/SSEPGG_10.5.0/com
.ibm.db2.luw.licensing.doc/doc/c0061013.html.
[6] Recursos y herramientas de copia de seguridad y recuperación.
Recuperado de:
https://www.ibm.com/support/knowledgecenter/es/SSEPEK_10.0.0/intr
o/src/tpc/db2z_backupandrecoveryresourcesandtools.html .
[7] José Pablo, (2018) “Replicación, controlador Datastax Php y cifrado SSL
– Apache Cassandra – parte 2” Recuperado de:
https://www.elconspirador.com/2018/02/01/replicacion-controlador-
datastax-php-y-cifrado-ssl-apache-cassandra-parte-2/.
[8] GlobalGate (2018). PostgreSQL: Múltiples Vulnerabilidades. Tomado
de: http://www.globalgate.com.ar/novedades-postgresql-multiples-
vulnerabilidades.html
[9] AcensTechnologies. Base de datos y sus vulnerabilidades más comunes.
Whitepaper: Base de datos y sus vulnerabilidades más comunes. Tomado
de: https://www.acens.com/wp-
content/images/2015/03/vulnerabilidades-bbdd-wp-acens.pdf.
[10] Santana Macías Jesús Daniel, “Administración de Bases de Datos”,
Problemas de seguridad en las BD. Recuperado de:
http://dan1456bd.blogspot.com/p/problemas-de-seguridad-en-las-
bd.html.
[11] acensTechnologies, “Bases de datos y sus vulnerabilidades más comunes”
Telefónica, recuperado de: https://www.acens.com/wp-
content/images/2015/03/vulnerabilidades-bbdd-wp-acens.pdf.
[12] PowerData, “La importancia de la seguridad e integridad en base de
datos” (2017). El valor de la gestión de datos. Recuperado de:
https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/la-importancia-
de-la-seguridad-e-integridad-en-base-de-datos.
[13] Vulnerabilidades importantes que afectan la seguridad de bases de datos
en las empresas, Recuperado de.
https://www.onasystems.net/vulnerabilidades-importantes-afectan-la-
seguridad-bases-datos-las-empresas/
(T’02–Te’12–P’19)
Jiménez Cano John Andrés
Nacido en la ciudad de Villavicencio en el
departamento del Meta en el año de 1984.
Estudiante de ingeniería desde temprana
edad, pasando por ser técnico en ingeniería
de sistemas en el año de 2002, tecnólogo en
informática en el año 2012 y futuro
ingeniero de sistemas en el año 2019.
Apasionado por los video juegos y la
programación, realiza actualmente créditos en especialización
en seguridad informática como opción de grado para obtener el
título del pregrado mencionado en esta biografía. Actualmente
vive en la ciudad de Bogotá, trabaja como ingeniero de
infraestructura en una empresa del estado y desarrolla funciones
de manera responsable y ordenada, con dedicación y superación
de acuerdo a recomendaciones de sus superiores.