Gestión de acceso y seguridad

Imagínate una pesadilla: eres el admin de la base de datos y de repente una tabla importante con los datos de clientes... desaparece. ¿Quién lo hizo? ¿Por qué? Quizá fue un becario sin experiencia que por accidente escribió DROP TABLE. O tal vez fue un usuario malintencionado que tenía acceso a la base... Sea lo que sea, ya es tarde para correr. Solo queda despertar, volver en ti y ponerte a estudiar cómo proteger bases de datos. Porque una base de datos sin seguridad es como una casa sin cimientos.

En bases de datos, la protección tiene que estar a tope para evitar amenazas como:

• Acceso no autorizado: alguien consigue acceso a datos para los que no tiene permisos.
• Fuga de datos: contraseñas, tarjetas de crédito o info confidencial acaban en manos equivocadas.
• SQL-injection: un método tramposo que puede permitir a un atacante manipular tu base a través de consultas mal protegidas.
• Errores humanos: borrar datos por accidente o hacer cambios que no se pueden deshacer.

En PostgreSQL la seguridad se implementa en varios niveles: desde la creación de roles y gestión de permisos hasta la restricción del acceso por red. Esto te permite configurar de forma flexible quién puede hacer qué con tus datos.

Niveles principales de seguridad en PostgreSQL

En PostgreSQL hay tres niveles clave donde puedes gestionar el acceso:

1. Gestión de acceso a nivel de base de datos. En este nivel decides quién puede conectarse a tu base de datos y qué puede hacer el usuario una vez conectado. Por ejemplo, puedes prohibir que algunos usuarios entren a la base. A otros, solo permitirles leer datos. La herramienta clave aquí son los roles.

2. Control de acceso a nivel de tablas, filas y columnas.

En PostgreSQL puedes restringir el acceso a los datos de forma muy precisa. Puedes:

• Permitir que un usuario lea solo ciertas columnas.
• Permitir leer datos en una tabla solo si el usuario es el dueño de la fila. Esto se llama ROW LEVEL SECURITY (RLS), y lo veremos en detalle en las próximas lecciones.
• Restringir el acceso solo a ciertas partes de la base (esquemas) donde están los datos importantes.

3. Configuración del acceso de red. La base de datos se puede configurar para aceptar peticiones solo de clientes de confianza. Esto se hace en el archivo de configuración de PostgreSQL llamado pg_hba.conf. Con este archivo puedes, por ejemplo, permitir conexiones solo desde la máquina local o desde ciertas direcciones IP.

Herramientas de seguridad de PostgreSQL

Vamos a ver qué herramientas de seguridad ofrece PostgreSQL y cómo funcionan en la práctica.

Empezamos con los roles y privilegios — la base del sistema de gestión de acceso. En PostgreSQL un rol no es solo un usuario, es algo más flexible. Puede representar tanto a una persona como a un grupo entero. Por ejemplo, puedes crear un rol llamado manager que tenga acceso total a la tabla de pedidos, y para el becario usar el rol intern, que solo tenga permisos de lectura — así no rompe nada sin querer.

Los roles se pueden configurar bastante a medida: a unos darles más permisos, a otros menos, y también permitir que un rol herede permisos de otro. Así decides quién puede conectarse a la base, qué esquemas y tablas puede ver, e incluso qué filas puede ver o modificar.

Luego están los archivos de configuración. En PostgreSQL hay dos archivos de configuración clave que juegan un papel importante en la seguridad.

El primero es pg_hba.conf. Se encarga del acceso de red a la base de datos. Aquí configuras quién puede conectarse al servidor, desde qué dirección IP y cómo se va a autenticar. Si necesitas restringir el acceso solo a ciertas máquinas o usuarios — aquí es donde lo haces.

El segundo archivo es postgresql.conf. Gestiona la configuración general del servidor, y entre otras cosas, aquí se definen los parámetros de logging y auditoría. Esto te permite ver quién hace qué, detectar actividad sospechosa a tiempo y, si hace falta, investigar los detalles.

Por último, logging y auditoría. "Los logs son tu mejor amigo". Suena raro, pero para un admin de base de datos es la regla número uno. En PostgreSQL puedes configurar el logging de todas las consultas y acciones de los usuarios. Esto te ayuda a saber quién hizo qué en la base si algo sale mal.

Ejemplo: proteger datos de SQL-injection

SQL-injection es una de las formas más populares de atacar una base de datos. Y es súper importante saber protegerse. Imagina que tienes una app donde el usuario mete el ID de su cuenta para ver su perfil. Y la app lanza una consulta así:

SELECT * FROM users WHERE id = 123;

¿Y si el usuario mete 123 OR 1=1 en vez de un número? Entonces la consulta se convierte en algo así:

SELECT * FROM users WHERE id = 123 OR 1=1;

Y en vez de un solo registro toda la tabla users queda accesible.

¿Cómo protegerse? PostgreSQL te permite usar consultas parametrizadas o comandos preparados (PREPARE y EXECUTE), para que los datos del usuario nunca se mezclen con el código SQL. Así es como se hace:

PREPARE get_user_by_id (int) AS
SELECT * FROM users WHERE id = $1;

EXECUTE get_user_by_id(123);

Más ejemplos de amenazas reales

Para que veas claro por qué hace falta seguridad, te dejo dos escenarios reales:

Ejemplo 1: "Un empleado borró toda la tabla"

Una vez en una empresa (bueno, en realidad ha pasado muchas veces y en muchas empresas...) un becario metió por accidente en la consola el comando:

DROP TABLE employees;

Y 10 años de datos de empleados se fueron al garete. ¿Cómo evitarlo?

• ¡Gestiona los permisos! Por ejemplo, al rol intern solo dale permisos de lectura.
• ¡Configura la auditoría! Los logs te dirán quién lanzó la consulta fatal.

Ejemplo 2: "Fuga de datos por conexión sin cifrar"

Si un usuario se conecta al servidor PostgreSQL sin cifrado, su login y contraseña pueden ser interceptados por un atacante. Configura SSL y asegúrate de que las conexiones estén protegidas.

Tareas clave para administradores

Para cerrar esta intro, aquí tienes las tres tareas principales de cualquier admin de PostgreSQL:

• Separar los accesos. Asegúrate de que solo los usuarios autorizados puedan hacer ciertas acciones.
• Cifrado. Los datos confidenciales siempre deben almacenarse y transmitirse cifrados.
• Monitorización. Configura la auditoría y vigila la actividad sospechosa en los logs.

En las próximas lecciones vas a aprender cómo crear roles, gestionar el acceso con GRANT y REVOKE, implementar control de acceso a nivel de filas y usar cifrado para proteger los datos.