12 fallas y errores de seguridad de las bases de datos

0
12

En la mayoría de los stacks empresariales actuales, la base de datos es el lugar donde aguardan todos nuestros secretos. Es en parte una casa segura, una habitación preparada y un lugar de paso para los bits que pueden ser intensamente personales o extremadamente valiosos. Defenderla contra todas las incursiones es uno de los trabajos más importantes para los administradores de bases de datos, los programadores y los equipos de DevOps que dependen de ella.

Por desgracia, el trabajo no es fácil. Los creadores nos dan todas las herramientas. Incorporan buenas medidas de seguridad y las documentan. Sin embargo, docenas de posibles fallas, errores, y descuidos, tanto comprensibles como tontos, lo convierten en un desafío sin fin.

Para ayudarnos a realizar un seguimiento y mantenernos alerta, se presenta una lista de diferentes fallas que le han ocurrido incluso a los mejores.

1. Gestión inadecuada de accesos
Muchas bases de datos residen dentro de su propia máquina y ésta debe estar lo más protegida y bloqueada posible. Solo deben poder acceder como administrador de base de datos los usuarios imprescindibles, y los inicios de sesión deben estar limitados a un estrecho rango de redes y otras máquinas. Los firewalls pueden bloquear direcciones IP. Las mismas reglas deberían aplicarse también a la capa del sistema operativo y, si se ejecuta en una máquina virtual, al hipervisor o la administración de la nube. Estas restricciones ralentizarán el trabajo de actualización de software y la solución de problemas, pero vale la pena restringir los caminos que pueden tomar los atacantes.

2. Fácil acceso físico
No se sabe qué podría hacer un atacante inteligente dentro de la sala de servidores. Las empresas de la nube y las instalaciones de coubicación ofrecen jaulas cerradas dentro de edificios fuertemente vigilados con acceso limitado. Si sus datos son almacenados de manera local en su centro de datos, siga las mismas reglas asegurándose de que solo la gente de confianza tenga acceso a la sala que contiene las unidades de disco físicas.

3. Copias de seguridad desprotegidas
No es raro que un equipo haga un gran trabajo asegurando un servidor de base de datos, pero luego se olvide de las copias de seguridad. Contienen la misma información, así que necesitan el mismo cuidado. Las cintas, unidades y otros medios estáticos deben guardarse en una caja fuerte, preferiblemente en otro lugar donde no se puedan dañar con la misma catástrofe que destruya los originales.

4. Datos no cifrados en reposo
Los algoritmos para codificar datos suelen ser confiables porque han sido probados ampliamente y los estándares actuales no tienen debilidades conocidas públicamente. Ahora es fácil agregar un buen cifrado a la base de datos y las copias de seguridad para todos los datos en reposo. Incluso si los algoritmos y las implementaciones son seguros, las claves también deben protegerse cuidadosamente. Los proveedores de la nube y los desarrolladores de servidores están creando hardware confiable que esté separado del flujo de trabajo promedio para que las claves estén más seguras dentro. Incluso si los sistemas no son perfectos, son mejores que nada. Cuando los datos permanecen cifrados en reposo durante un tiempo, algunos prefieren una ubicación física diferente para las claves, de preferencia offline. Algunos imprimen las claves y guardan el papel en una caja fuerte.

5. No utilizar algoritmos de protección de la privacidad
El cifrado es una buena herramienta para proteger copias físicas de la base de datos, siempre que se pueda resguardar la clave. Existe una amplia variedad de algoritmos que codifican los datos de forma permanente. No pueden resolver todos los problemas, pero pueden ser sorprendentemente efectivos cuando no hay necesidad de que todos los datos confidenciales estén disponibles. Uno de los más sencillos es simplemente reemplazar nombres por seudónimos aleatorios. Hay docenas de otros enfoques que utilizan la cantidad justa de matemáticas para proteger los datos personales y, al mismo tiempo, logran los objetivos de la base de datos.

6. Falta de controles de proliferación
Cuando se utilizan los datos, se copian en cachés y servidores en ejecución. El objetivo de los arquitectos de almacenamiento de datos es minimizar el número de copias y garantizar que se destruyan en cuanto los datos no se utilicen. Muchas bases de datos ofrecen opciones para duplicar o realizar copias de seguridad de forma rutinaria como una función para defenderse contra fallas de la máquina. Si bien esto puede ser esencial para brindar un servicio estable, vale la pena pensar cuidadosamente sobre la proliferación durante el diseño. En algunos casos, puede ser posible limitar el copiado desenfrenado sin comprometer demasiado el servicio. En otros, puede ser mejor elegir opciones más lentas y menos redundantes si estas limitan el número de lugares por los que un atacante podría entrar.

7. Falta de controles de la base de datos
Las mejores bases de datos son el producto de décadas de evolución, impulsadas por un sinfín de pruebas e investigaciones de seguridad. Elija una buena. Además, los creadores de la base de datos agregaron buenas herramientas para administrar y limitar el acceso. Debería usarlas. Asegúrese de que solo las aplicaciones correctas puedan ver las tablas adecuadas. No reutilice la misma contraseña para todas las aplicaciones. Ciertamente, no use la que viene de forma predeterminada. Limite el acceso a los procesos locales o a la red local cuando sea posible.

8. Bases de datos secundarias vulnerables
Muchas pilas utilizan cachés rápidas in-memory como Redis para acelerar las respuestas. Estas bases de datos secundarias y redes de distribución de contenido suelen tener copias de la misma información en la base de datos. Dedique la misma cantidad de tiempo para configurarlas como lo hace con las bases de datos principales.

9. Aplicaciones vulnerables con acceso a datos
La seguridad cuidadosamente planeada de la base de datos no vale mucho cuando una aplicación de confianza actúa de manera inadecuada, especialmente cuando ésta tiene acceso a todos los datos. Un problema común es la inyección de SQL, un ataque en el que una aplicación mal codificada es engañada para que pase SQL malicioso a la base de datos. Otro problema es la seguridad deficiente de la propia aplicación. En muchas arquitecturas, la aplicación lo ve todo. Si no se bloquean correctamente a los usuarios adecuados, todos los datos podrían verse comprometidos.

10. Exposición riesgosa a Internet
Es ideal que las bases de datos permanezcan en una parte de la red sin acceso público. Si bien algunos desarrolladores buscan simplificarse la vida abriendo la base de datos a la Internet general, cualquiera que guarde información no trivial debería pensar de manera diferente. Si la base de datos solo va a comunicarse con los servidores front-end, puede permanecer en una parte de la red donde únicamente estos servidores tengan acceso.

11. Falta de gestión de la integridad
Las bases de datos modernas ofrecen una amplia variedad de características que evitarán que se produzcan errores e inconsistencias en el conjunto de datos. La especificación de un esquema para los datos garantiza que los elementos de datos individuales se ajusten a un conjunto de reglas. El uso de transacciones y bloqueos evita que se introduzcan errores cuando una tabla o fila se actualiza y otra no. La implementación de estas opciones de gestión de la integridad añade una sobrecarga computacional, pero su uso reduce los efectos de errores aleatorios, y también puede evitar que los usuarios inserten datos inconsistentes o incorrectos.

12. Conservación de datos innecesarios
A veces, la solución más segura es destruir la base de datos. Muchas veces los equipos de desarrollo piensan como coleccionistas y almacenan información para un futuro que posiblemente nunca llega. Una de las formas más sencillas de protegerse contra las filtraciones de datos es borrar la información. Si no la necesita para prestar algún servicio en el futuro y los clientes nunca pedirán verla, puede deshacerse de la información para no tener que protegerla. Si no está completamente seguro de que los datos no van a volverse a utilizar, puede borrar las copias en línea y mantener solo las copias de seguridad sin conexión en un almacenamiento donde el acceso sea aún más limitado.

Peter Wayner CSOonline.com – CIOPeru.pe

 

Artículo anteriorActivos de Mercantil Servicios Financieros se incrementaron 241,1 % en comparación con el cierre de diciembre 2020
Artículo siguienteLos ingresos por ventas de PC siguen superando los niveles de 2019