Proteger una base de datos significa controlar quién puede leer, modificar o eliminar información, y guardar copias de seguridad por si algo falla.
El día que el IMSS casi pierde millones de registros
Era un martes por la mañana en la Ciudad de México. Una técnica de sistemas del IMSS llegó a su oficina y encontró un mensaje de error en pantalla: el servidor de base de datos no respondía. En esa máquina había información médica de más de 70 millones de derechohabientes. Durante 40 minutos, nadie pudo consultar historial clínico alguno.
Lo que salvó la situación no fue un héroe de película. Fue algo silencioso y aburrido: un respaldo automático que se había ejecutado la noche anterior a las 2:00 a.m. En menos de una hora, el sistema fue restaurado desde esa copia. Sin ese respaldo, el daño habría sido irreparable.
Este momento ilustra algo que muchos principiantes ignoran: diseñar una base de datos bien estructurada es solo la mitad del trabajo. La otra mitad es protegerla y mantenerla viva.
Los tres pilares de la seguridad en bases de datos
Existen tres conceptos que forman la base de la seguridad en cualquier sistema de datos, desde una pequeña startup hasta el SAT.
El primero es la autenticación: verificar que quien intenta acceder es quien dice ser. El segundo es la autorización: definir qué puede hacer esa persona una vez adentro. El tercero es la auditoría: registrar qué acciones se realizaron, cuándo y quién las hizo.
Piensa en el SAT. Millones de contribuyentes en México entran cada año a declarar impuestos. El sistema verifica tu RFC y contraseña (autenticación). Una vez adentro, tú solo puedes ver tus propios datos, no los de otra empresa (autorización). Y cada consulta queda registrada con fecha, hora y dirección IP (auditoría). Los tres pilares trabajan juntos.
¿Cómo funcionan los permisos en una base de datos?
La mayoría de los sistemas de bases de datos, como MySQL o PostgreSQL, tienen un sistema de permisos muy preciso. Puedes dar acceso a una persona para que solo lea datos, pero no los modifique. O puedes permitir que un programa inserte registros, pero no los borre.
En SQL, esto se hace con los comandos GRANT y REVOKE.
Imagina que Liverpool tiene una base de datos de clientes. Hay tres tipos de usuarios:
El equipo de atención a clientes necesita consultar pedidos, pero nunca debe modificar precios. Un analista de datos necesita leer toda la base para generar reportes, pero no escribir nada. Y el sistema de ventas en línea necesita insertar nuevos pedidos automáticamente.
Así se verían los permisos en SQL:
-- Permiso solo para leer la tabla de pedidos
GRANT SELECT ON pedidos TO usuario_atencion;
-- Permiso para leer toda la base de datos
GRANT SELECT ON ALL TABLES IN SCHEMA public TO usuario_analista;
-- Permiso para insertar nuevos pedidos
GRANT INSERT ON pedidos TO sistema_ventas;
Si en algún momento el analista intenta modificar un precio, el sistema lo rechaza automáticamente. No porque alguien esté vigilando en tiempo real, sino porque la base de datos tiene esa regla grabada.
El comando REVOKE hace lo contrario: quita permisos que antes se habían dado. Si un empleado de Liverpool deja la empresa, ejecutas REVOKE SELECT ON pedidos FROM usuario_atencion; y ese usuario ya no puede ver nada.
El respaldo: la red de seguridad que nadie nota hasta que la necesita
Un respaldo (o backup) es una copia exacta de la base de datos en un momento específico del tiempo. Si algo falla, puedes regresar al estado anterior.
Existen dos tipos principales de respaldo. El respaldo completo copia absolutamente todo. Es el más seguro, pero también el más pesado. Una empresa como FEMSA, con datos de millones de transacciones de OXXO, no puede hacer un respaldo completo cada hora porque tardaría demasiado.
El respaldo incremental solo copia lo que cambió desde el último respaldo. Es mucho más rápido y ligero. FEMSA podría hacer un respaldo completo cada domingo a medianoche, y respaldos incrementales cada hora durante la semana. Si algo falla el miércoles a las 3:00 p.m., restauran el respaldo del domingo más todos los incrementales hasta ese momento.
Un dato que sorprende: según estudios de continuidad de negocio, el 60% de las pequeñas empresas que pierden sus datos por completo cierran en menos de seis meses. El respaldo no es un lujo técnico. Es supervivencia.
¿Qué es el cifrado y por qué importa?
Imagina que alguien logra robar el archivo físico de tu base de datos. Sin cifrado, puede abrir ese archivo y leer todos los datos directamente: nombres, contraseñas, números de tarjeta. Con cifrado, el archivo parece una cadena de caracteres sin sentido. Solo quien tenga la llave correcta puede interpretarlo.
En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares obliga a las empresas a proteger datos sensibles. Si un banco mexicano guarda números de tarjeta de crédito sin cifrar y hay una filtración, enfrenta multas millonarias del INAI.
El cifrado más común para contraseñas se llama hashing. Cuando creas tu cuenta en Mercado Libre y pones tu contraseña, Mercado Libre no guarda "micontraseña123" en texto plano. Guarda algo como $2b$10$XkZ9... que es el resultado de pasar tu contraseña por un algoritmo. Ni siquiera los empleados de Mercado Libre pueden ver tu contraseña real.
Errores comunes que destruyen bases de datos
El error más frecuente entre principiantes es darle permisos de administrador a todo el mundo "para que no haya problemas". Es como darle llaves maestras del edificio a cada empleado. Si una cuenta es hackeada, el atacante tiene acceso total.
Otro error grave es olvidar probar los respaldos. Muchas empresas hacen respaldos automáticos durante años sin verificar si realmente funcionan. El día que necesitan restaurar, descubren que el archivo estaba corrupto desde hace meses. Un respaldo no probado no es un respaldo: es una ilusión.
Finalmente, guardar contraseñas en texto plano es un error que sigue ocurriendo en 2024. Si tu base de datos tiene una columna que dice contraseña = "patito123", estás un paso de un desastre. Siempre usa hashing.
El mantenimiento continuo: una base de datos viva necesita cuidados
Una base de datos no es estática. Con el tiempo, acumula datos obsoletos, índices fragmentados y espacio desperdiciado. El mantenimiento regular la mantiene rápida y confiable.
Tres tareas básicas de mantenimiento son: limpiar registros que ya no sirven (como pedidos cancelados de hace cinco años), reorganizar los índices para que las búsquedas sigan siendo rápidas, y monitorear el espacio en disco para evitar que se llene de sorpresa.
Bimbo, por ejemplo, procesa pedidos de miles de rutas de distribución cada día. Si nadie limpia los registros históricos con regularidad, la base de datos crece sin control. Una consulta que tardaba 2 segundos puede empezar a tardar 40 segundos. Eso se traduce en retrasos reales en la cadena de suministro.
El regreso al martes del IMSS
La técnica de sistemas que encontró el error aquella mañana no solo restauró el servidor. Después de resolver la crisis, escribió un nuevo protocolo: respaldo completo cada noche, respaldo incremental cada dos horas, y una prueba de restauración obligatoria cada mes.
Ese protocolo aburrido y silencioso es lo que separa una base de datos profesional de una que vive al borde del desastre. Los grandes sistemas de México, del SAT al IMSS, del BBVA Bancomer a Mercado Libre, invierten tanto en seguridad y mantenimiento como en diseño. Porque de nada sirve una base de datos perfectamente diseñada si un solo error la puede borrar para siempre.