Seguridad y Privacidad de Bases de Datos: Guía para Principiantes para Proteger Datos Sensibles

Casi toda aplicación que usas termina en una base de datos: un formulario de inicio de sesión, un carrito de compras, una lista escolar, un portal de pacientes. Cuando se dice que una empresa fue “hackeada”, lo que suelen llevarse los atacantes es una copia de una base de datos. Eso convierte a la base de datos en el objetivo más valioso de la mayoría de los sistemas y en el lugar donde la seguridad y la privacidad más importan.

Esta guía explica cómo se vulneran las bases de datos, las capas de protección que hacen una filtración menos probable y menos dañina, y qué datos deben cifrarse. Usa PostgreSQL para los ejemplos de código (consulta la guía de PostgreSQL para principiantes si quieres configurar una), pero las ideas aplican a MySQL, SQL Server, Oracle y otras.

Seguridad vs. Privacidad en una Base de Datos

Las dos ideas trabajan juntas:

• La seguridad de la base de datos consiste en proteger los datos del acceso, cambio o pérdida no autorizados: contraseñas, cifrado, firewalls, respaldos.
• La privacidad de la base de datos consiste en decidir qué datos personales almacenas, quién puede verlos, para qué pueden usarse y cuánto tiempo los conservas. Para el panorama general, lee qué es la privacidad de datos.

Una base de datos perfectamente protegida que almacena muchos más datos personales de los necesarios sigue siendo un riesgo de privacidad. El registro más seguro es el que nunca recopilaste.

Cómo Se Vulneran las Bases de Datos

Conocer las causas comunes te dice dónde invertir esfuerzo primero:

La mayoría no son hackeos ingeniosos. Son fallas básicas.

Capa 1: Bloquea la Red

Trata tu base de datos como algo que nunca debe dar la cara a internet público.

• Colócala en una red o subred privada, accesible solo desde tus servidores de aplicaciones.
• Usa un firewall que permita solo las direcciones IP y puertos específicos que necesitan acceso (por ejemplo, el puerto 5432 de PostgreSQL o el 3306 de MySQL).
• Para la administración remota, usa una VPN o un túnel seguro, o una conexión SSH con llaves (consulta qué es SSH), en lugar de abrir el puerto.
• Cambia los puertos predeterminados y desactiva funciones de red innecesarias cuando tenga sentido, pero no dependas solo de eso.
• Aprende cómo encajan las capas en la guía de redes informáticas.

Capa 2: Autenticación Fuerte

• Sin contraseñas predeterminadas ni compartidas. Cambia de inmediato los valores del proveedor y da a cada persona y aplicación su propia cuenta.
• Usa contraseñas largas y aleatorias guardadas en un administrador de contraseñas o bóveda de secretos, nunca en el código fuente.
• Exige autenticación multifactor para el acceso administrativo donde tu plataforma lo permita.
• Usa certificados o identidad en la nube (como la autenticación de bases de datos basada en IAM) cuando esté disponible.
• Elimina o desactiva las cuentas sin uso y las bases de datos de prueba o de ejemplo.

Capa 3: Mínimo Privilegio

Mínimo privilegio significa que cada cuenta recibe solo el acceso que necesita y nada más. Limita el daño cuando se roba una cuenta o se explota un error.

• La aplicación web debe conectarse con una cuenta que solo pueda leer y escribir en las tablas que usa. No debe ser superusuario ni poder eliminar tablas o crear usuarios.
• Los analistas pueden necesitar acceso de solo lectura, quizá a un conjunto limitado de tablas o vistas.
• Los administradores deben usar cuentas de administración separadas solo para tareas administrativas.

Un ejemplo en PostgreSQL:

-- Un rol para la aplicación: puede iniciar sesión, nada más
CREATE ROLE app_user LOGIN PASSWORD 'use-a-long-random-password-from-your-vault';

-- Dale acceso solo a lo que necesita
GRANT CONNECT ON DATABASE shop TO app_user;
GRANT USAGE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE ON orders, customers TO app_user;

-- Un rol de solo lectura para analistas
CREATE ROLE analyst LOGIN PASSWORD 'another-long-random-password';
GRANT CONNECT ON DATABASE shop TO analyst;
GRANT USAGE ON SCHEMA public TO analyst;
GRANT SELECT ON orders TO analyst;

Puedes ir más lejos exponiendo vistas que muestren solo columnas seguras (por ejemplo, ocultando correos o teléfonos), o usando seguridad a nivel de fila para que los usuarios vean solo las filas que tienen permitido ver.

-- Una vista que omite las columnas sensibles
CREATE VIEW customer_summary AS
SELECT id, first_name, city, signup_date
FROM customers;

GRANT SELECT ON customer_summary TO analyst;

Capa 4: Detén la Inyección SQL

La inyección SQL ocurre cuando una aplicación pega la entrada del usuario directamente en una consulta. Un atacante escribe SQL en lugar de un nombre, y la base de datos lo ejecuta. Sigue siendo una de las causas más comunes de robo de datos. Lee la guía completa sobre la inyección SQL y cómo prevenirla.

La solución es usar consultas parametrizadas (también llamadas sentencias preparadas), que mantienen separados el SQL y los datos. Un ejemplo en Python con la biblioteca psycopg2:

# Inseguro: la entrada del usuario se pega en el texto SQL
cur.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Seguro: el controlador envía el valor por separado de la consulta
cur.execute("SELECT * FROM users WHERE email = %s", (email,))

Además, valida la entrada, usa un ORM o constructor de consultas con cuidado y da a la cuenta de la aplicación solo los permisos que necesita, para que un error de inyección no pueda hacer mucho.

Capa 5: Cifrado

El cifrado convierte datos legibles en datos ilegibles que no sirven sin una llave. En bases de datos hay tres lugares donde aplicarlo.

Cifrado en tránsito

Los datos que viajan entre la aplicación y la base de datos pueden ser leídos por cualquiera que vea la red. Exige TLS/SSL en todas las conexiones y rechaza las no cifradas. En PostgreSQL, por ejemplo, activas SSL en la configuración del servidor y haces que los clientes se conecten con sslmode=verify-full para que verifiquen el certificado del servidor.

Cifrado en reposo

Esto protege los datos almacenados en disco, incluidos los archivos de la base de datos, los registros y los respaldos. Si se roba un disco, una instantánea o un respaldo, los datos siguen siendo ilegibles. Las opciones incluyen:

• Cifrado de disco completo o de volumen (por ejemplo, LUKS en Linux, BitLocker en Windows o volúmenes cifrados en la nube)
• Cifrado transparente de datos (TDE) en productos como SQL Server, Oracle y algunas ediciones de MySQL
• Bases de datos administradas con cifrado en servicios en la nube, normalmente una opción que se activa

El cifrado en reposo no protege contra alguien que inicia sesión con credenciales válidas ni contra una inyección SQL exitosa, porque la base de datos descifra los datos para cualquier consulta autorizada. Por eso la protección a nivel de columna importa para los campos más sensibles.

Cifrado de campos específicos (a nivel de columna o de aplicación)

Aquí los valores individuales se cifran antes o durante su almacenamiento, de modo que incluso un administrador de la base de datos o una copia activa robada solo ve texto ilegible. Es más difícil buscar y ordenar columnas cifradas, así que aplícalo de forma selectiva. Eso nos lleva a la pregunta clave.

¿Qué Datos de una Base de Datos Deben Cifrarse?

Una regla práctica: cifra todo en tránsito y en reposo por defecto, y luego agrega cifrado a nivel de campo o hash para tus datos más sensibles. La tabla siguiente muestra cómo tratar los tipos de datos comunes.

Algunas formas sencillas de decidir para cualquier columna:

1. ¿Su exposición causaría daño? Robo de identidad, pérdida financiera, discriminación, riesgo para la seguridad o sanciones legales apuntan al cifrado.
2. ¿Está regulado? Leyes y estándares como el RGPD, HIPAA, PCI DSS y las leyes estatales de privacidad pueden exigirlo o fijar expectativas.
3. ¿Necesitas buscarlo o compararlo? Si debes consultar por el valor, considera guardar un hash en una copia separada de “búsqueda”, o usa cifrado determinista o con búsqueda con cuidado, porque esas funciones reducen la protección.
4. ¿Necesitas recuperar el original? Las contraseñas no necesitan recuperarse, así que aplícales un hash. Un número fiscal puede necesitar mostrarse después, así que cífralo.
5. ¿Podrías evitar almacenarlo? Eliminarlo, acortarlo (los últimos cuatro dígitos) o tokenizarlo es más fuerte que cifrarlo.

Hash vs. cifrado

Un pequeño ejemplo de cifrado a nivel de campo

La extensión pgcrypto de PostgreSQL puede aplicar hash a contraseñas y cifrar valores. Es un ejemplo de aprendizaje: en un sistema real, guarda la llave en un administrador de secretos o servicio de gestión de llaves, no en la consulta ni en la base de datos.

CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Aplica hash a una contraseña (un solo sentido) con bcrypt
INSERT INTO users (email, password_hash)
VALUES ('[email protected]', crypt('a-strong-passphrase', gen_salt('bf')));

-- Verifica un intento de inicio de sesión
SELECT id FROM users
WHERE email = '[email protected]'
  AND password_hash = crypt('a-strong-passphrase', password_hash);

-- Cifra un valor sensible (reversible, requiere la llave)
INSERT INTO patients (name, ssn_encrypted)
VALUES ('Ana Lopez', pgp_sym_encrypt('123-45-6789', 'key-from-your-secrets-manager'));

-- Descífralo
SELECT pgp_sym_decrypt(ssn_encrypted, 'key-from-your-secrets-manager') FROM patients;

Ten en cuenta que cifrar dentro de SQL significa que la llave y el valor en claro pasan por la base de datos y pueden aparecer en los registros. Muchos equipos cifran en el código de la aplicación, de modo que la base de datos solo ve texto cifrado. Las contraseñas se procesan mejor con hash en la aplicación, usando una biblioteca bien revisada.

La gestión de llaves importa tanto como el cifrado

Los datos cifrados son tan seguros como la llave:

• Nunca guardes las llaves junto a los datos ni en el código fuente.
• Usa un servicio de gestión de llaves (KMS), un módulo de seguridad de hardware o una bóveda de secretos.
• Rota las llaves según un calendario y tras cualquier sospecha de exposición.
• Limita quién puede usar las llaves, de forma separada de quién puede acceder a la base de datos.
• Respalda las llaves de forma segura. Perder la llave significa perder los datos.

Capa 6: Respaldos y Recuperación

• Respalda con regularidad y conserva al menos una copia fuera de línea o inmutable para que el ransomware no pueda cifrarla ni borrarla.
• Cifra los respaldos y protégelos con el mismo cuidado que la base de datos activa.
• Prueba las restauraciones. Un respaldo que nunca se ha restaurado es una esperanza, no un plan.
• Elimina los respaldos antiguos según tu política de retención. Las copias viejas siguen conteniendo datos personales.
• En PostgreSQL, herramientas como pg_dump y pg_restore cubren los respaldos lógicos, como se explica en la guía de PostgreSQL.

Capa 7: Auditoría y Monitoreo

No puedes responder a lo que no ves.

• Registra inicios de sesión, inicios fallidos, cambios de privilegios y cambios de esquema.
• Registra el acceso a tablas sensibles donde tu base de datos lo permita (por ejemplo, la extensión pgaudit para PostgreSQL).
• Envía los registros a un sistema separado que los administradores de la base de datos no puedan alterar.
• Alerta sobre actividad inusual: exportaciones grandes, inicios de sesión a horas extrañas, cuentas nuevas, muchos intentos fallidos o consultas desde ubicaciones inesperadas.
• Revisa cuentas y permisos con regularidad y elimina lo que ya no se necesite.

Capa 8: Mantén el Software con Parches

Los motores de bases de datos, sistemas operativos, controladores y extensiones reciben correcciones de seguridad con regularidad. Suscríbete a los avisos de seguridad de tu proveedor, prueba las actualizaciones y aplícalas con prontitud. Si ejecutas bases de datos en contenedores, reconstruye las imágenes con versiones actualizadas (consulta la guía de MySQL con Docker). Elimina el software y las funciones que no uses.

Privacidad desde el Diseño en tu Base de Datos

Los controles técnicos son solo parte del panorama. Incorpora la privacidad en tu diseño desde el inicio, como se explica en diseño de bases de datos:

• Recopila solo lo que necesitas. Cada columna es una responsabilidad. Pregúntate si puedes prescindir de ella.
• Separa los datos sensibles en su propia tabla con permisos más estrictos, vinculada por un ID.
• Seudonimiza o anonimiza los datos usados para pruebas, análisis e informes. Nunca copies datos de producción sin procesar a entornos de desarrollo.
• Enmascara los datos que se muestran a usuarios que no necesitan el valor completo (por ejemplo, mostrando solo los últimos cuatro dígitos).
• Define reglas de retención y elimina o archiva los datos que ya no necesitas.
• Respalda los derechos de las personas: debes poder encontrar, exportar, corregir y eliminar los datos de una persona cuando la ley lo exija.
• Documenta tus datos: qué contiene cada tabla, por qué y quién es su responsable.

Lista de Verificación de Seguridad de Bases de Datos

Red y acceso

• La base de datos no es accesible directamente desde internet
• El firewall solo permite los hosts y puertos necesarios
• Sin cuentas predeterminadas ni compartidas; las contraseñas son largas, únicas y están en una bóveda
• MFA para administradores
• Cada aplicación y persona tiene el mínimo privilegio necesario

Protección de datos

• TLS obligatorio en todas las conexiones
• Cifrado de disco, volumen o TDE activado
• Contraseñas con hash mediante bcrypt, scrypt o Argon2
• Campos muy sensibles cifrados a nivel de campo o tokenizados
• Llaves de cifrado guardadas en un KMS o bóveda, rotadas y con acceso controlado
• Datos sensibles enmascarados o minimizados cuando sea posible

Aplicación

• Todas las consultas usan parámetros, no concatenación de cadenas
• La cuenta de la aplicación no es superusuario

Operaciones

• Respaldos cifrados, probados y en parte fuera de línea
• Registro de auditoría y alertas activados
• Aplicación regular de parches
• Revisión regular de cuentas y permisos
• Plan de respuesta a incidentes que incluya filtraciones de bases de datos

Errores Comunes que Debes Evitar

• Usar la misma cuenta de base de datos para la aplicación, los informes y la administración
• Dejar bases de datos de prueba y datos de ejemplo en servidores de producción
• Subir cadenas de conexión y contraseñas a un repositorio de código
• Creer que el “cifrado en reposo” protege contra una contraseña robada o una inyección SQL
• Copiar datos de producción a desarrollo o a una hoja de cálculo
• Olvidar que los registros, exportaciones y respaldos contienen los mismos datos sensibles
• Tratar la seguridad como una configuración única en lugar de una rutina continua

Conclusión

Proteger una base de datos es cuestión de capas. Mantenla fuera de internet público, da a cada cuenta solo el acceso que necesita, usa consultas parametrizadas, cifra los datos en tránsito y en reposo, protege los campos más sensibles con cifrado a nivel de campo o hash, cuida las llaves, respalda y prueba, y vigila la actividad inusual. Sobre todo, almacena menos: los datos que nunca recopilas no pueden ser robados.

Si apenas empiezas, elige tres acciones esta semana: elimina las cuentas predeterminadas o compartidas, asegúrate de que la base de datos no esté expuesta a internet y activa TLS y los respaldos cifrados. Luego avanza por la lista de verificación. Para el lado personal del tema, consulta cómo proteger la información personal.