Objetivos de la unidad

El entorno que dejamos en la Unidad 1

El caso que vamos a proteger durante toda la unidad

Preparar el entorno

docker run --name dba-postgres -e POSTGRES_PASSWORD=<REDACTED> -p 5432:5432 -d postgres:16
docker exec -it dba-postgres psql -U postgres

CREATE TABLE clientes (
  id SERIAL PRIMARY KEY, nombre TEXT, correo TEXT, telefono TEXT,
  rfc TEXT, edad INT, clave_acceso TEXT
);
INSERT INTO clientes (nombre, correo, telefono, rfc, edad, clave_acceso)
VALUES ('Persona Ejemplo', 'estudiante@correo-demo.test', '667-123-45-67',
        'ABCD123456XYZ', 22, 'clave_demo');

docker run --name dba-mongo -p 27017:27017 -d mongo:7 --auth

use admin
db.createUser({ user: "admin", pwd: "<REDACTED>", roles: ["root"] })
db.auth("admin", "<REDACTED>")
use tienda_demo
db.clientes.insertOne({
  nombre: "Persona Ejemplo", correo: "estudiante@correo-demo.test",
  telefono: "667-123-45-67", rfc: "ABCD123456XYZ", edad: 22,
  clave_acceso: "clave_demo"
})

Actividad: Diagnóstico

1. Cualquier persona con la contraseña del usuario administrador puede leer, modificar o borrar cualquier dato.
2. No hay cifrado en las conexiones, las credenciales viajan en texto plano, no hay clasificación de qué datos son sensibles, y el servidor conserva su configuración de instalación por defecto.

¿Qué estamos tratando de proteger?

Un dato puede necesitar varias protecciones

                 DATOS (clientes)
                   |
        +----------+----------+
        v          v          v
      ACCESO   PROTECCION   EXPOSICION
        |          |          |
        v          v          v
   Usuarios y   Cifrado y   Servicios
   permisos     enmascar.   y puertos
     (2.2)      (2.3/2.4)     (2.6)

La tríada CIA aplicada a bases de datos

Referencia. Saltzer, J.H. y Schroeder, M.D. (1975). "The Protection of Information in Computer Systems". Proceedings of the IEEE, 63(9), 1278 a 1308.

Privilegio mínimo y separación de funciones

Inyección SQL y NoSQL: el concepto

Cómo se previene: consultas parametrizadas

# vulnerable
cur.execute(f"SELECT * FROM clientes WHERE nombre = '{entrada_nombre}'")

# parametrizada
cur.execute("SELECT * FROM clientes WHERE nombre = %s", (entrada_nombre,))

El motor recibe el valor por un canal separado de la consulta. Nunca se interpreta como código, sin importar qué contenga.

Cómo se previene: ORM con escape automático

# seguro, el ORM parametriza por debajo
session.query(Cliente).filter(Cliente.nombre == entrada_nombre)

# igual de vulnerable aunque esta "dentro" del ORM
session.execute(f"SELECT * FROM clientes WHERE nombre = '{entrada_nombre}'")

Cómo se previene: validación y tipado de entradas

const nombre = String(entrada_nombre)
const clave = String(entrada_clave)
db.clientes.findOne({ nombre, clave_acceso: clave })

Forzar el tipo esperado antes de construir la consulta impide que un objeto como {"$ne": null} llegue como operador en vez de como valor.

Cómo se previene: privilegio mínimo en la cuenta de aplicación

CREATE ROLE app_usuario WITH LOGIN PASSWORD '<REDACTED>';
GRANT SELECT, INSERT, UPDATE ON clientes TO app_usuario;

postgresql://app_usuario:<REDACTED>@servidor:5432/tienda_demo

Qué más se debe considerar

¿Debe haber escaneos? ¿De quién es la responsabilidad?

Referencia. OWASP SQL Injection Prevention Cheat Sheet. OWASP Testing for NoSQL Injection. ISO/IEC 27002:2022, sección 5.2, "Information security roles and responsibilities".

Actividad: Inyección

Más allá de RBAC: modelos de control de acceso

Caso de uso: DAC y MAC

RBAC y ABAC

Caso de uso: RBAC y ABAC

Referencia — Sandhu et al. (1996), IEEE Computer 29(2). Hu, V.C. et al. (2014), NIST SP 800-162.

Ventajas y desventajas de cada modelo

Los sublenguajes de SQL, y su equivalente en MongoDB

Dos notas sobre esta tabla

Usuarios, roles y permisos en la práctica

Ejemplo guiado: roles con privilegio diferenciado (PostgreSQL)

CREATE ROLE lector WITH LOGIN PASSWORD '<REDACTED>';
GRANT SELECT ON clientes TO lector;

CREATE ROLE editor WITH LOGIN PASSWORD '<REDACTED>';
GRANT SELECT, INSERT, UPDATE ON clientes TO editor;

CREATE ROLE administrador WITH LOGIN PASSWORD '<REDACTED>' SUPERUSER;

\du
       Rol       | Atributos
-----------------+------------
 administrador   | Superuser
 editor          |
 lector          |

MongoDB sin autenticación por defecto

> db.getUsers()
{ ok: 1 }

Ejemplo guiado: roles con privilegio diferenciado (MongoDB)

db.createRole({
  role: "lector",
  privileges: [{ resource: { db: "tienda_demo", collection: "clientes" },
                 actions: ["find"] }],
  roles: []
})
db.createRole({
  role: "editor",
  privileges: [{ resource: { db: "tienda_demo", collection: "clientes" },
                 actions: ["find", "insert", "update"] }],
  roles: []
})
db.createUser({ user: "lector1", pwd: "<REDACTED>", roles: ["lector"] })
db.createUser({ user: "editor1", pwd: "<REDACTED>", roles: ["editor"] })

lector1 solo puede leer clientes. root es el equivalente a SUPERUSER.

Fuente. MongoDB Manual, "Role-Based Access Control".

Nota avanzada: control de acceso a nivel de fila (PostgreSQL)

ALTER TABLE clientes ENABLE ROW LEVEL SECURITY;

CREATE POLICY solo_mis_clientes ON clientes
  FOR SELECT
  USING (vendedor_id = current_user);

Referencia. PostgreSQL Documentation, "Row Security Policies".

Actividad: Matriz de roles

Instrucciones completas: unidad02_actividades.md, Actividad 3

Protección de datos sensibles

Proteger una base de datos no significa únicamente impedir accesos no autorizados.

También implica controlar:

• qué información se almacena
• quién puede utilizarla
• cómo se transforma
• cuánto tiempo se conserva
• cuándo debe eliminarse

El DBA administra datos, pero también administra riesgos asociados a esos datos.

Clasificación de datos

La clasificación permite determinar qué nivel de protección necesita cada información.

Idea clave

La clasificación debe determinar los controles, no solamente el nombre de la columna.

¿Por qué clasificar los datos?

Sin clasificación, resulta difícil decidir:

• quién puede acceder
• qué debe cifrarse
• qué puede enmascararse
• cuánto tiempo debe conservarse
• qué debe registrarse
• qué debe eliminarse

Ejemplo

correo electrónico
      ↓
dato personal
      ↓
acceso restringido
      ↓
protección y trazabilidad

Datos personales vs datos sensibles

No todos los datos personales tienen el mismo nivel de riesgo.

Importante

"Confidencial" y "sensible" no son necesariamente sinónimos.

La clasificación organizacional y la clasificación jurídica cumplen funciones diferentes.

Datos sensibles y decisiones del DBA

Cuando un dato presenta mayor riesgo, pueden requerirse controles adicionales:

• acceso restringido
• cifrado
• enmascaramiento
• monitoreo
• minimización
• retención limitada
• eliminación segura

Pregunta para el DBA

¿Necesitamos que todos los usuarios vean el valor real?

Si la respuesta es no, debe analizarse una alternativa.

Enmascaramiento de datos

El enmascaramiento modifica la forma en que se presenta un dato.

Ejemplo:

Original
juan.perez@empresa.com

Enmascarado
j***@empresa.com

Otro ejemplo:

4111111111111111

4111********1111

Objetivo

Permitir trabajar con información sin exponer innecesariamente el valor completo.

¿Cuándo utilizar enmascaramiento?

Puede ser útil en:

• ambientes de pruebas
• soporte técnico
• reportes
• interfaces administrativas
• consultas de usuarios
• capacitación

Pero no es cifrado.

El dato puede seguir existiendo en su forma original.

Seudonimización

La seudonimización sustituye identificadores directos por otros valores.

Ejemplo:

Cliente:
14420708

↓

Identificador:
CLI-8F3A21

La información original puede recuperarse mediante información adicional.

Idea clave

La seudonimización reduce exposición, pero no elimina necesariamente la posibilidad de identificar a la persona.

Anonimización

La anonimización busca impedir que una persona pueda ser identificada razonablemente a partir de los datos resultantes.

Ejemplo:

Edad: 37
Ciudad: Culiacán
Ingreso: $28,500

↓

Rango de edad: 35–40
Región: Sinaloa
Rango de ingreso: 25–30 mil

La transformación debe evaluarse frente al riesgo de reidentificación.

Enmascaramiento, seudonimización y anonimización

No son equivalentes.

Cada técnica responde a un problema diferente.

Retención de datos

La retención determina durante cuánto tiempo se conserva información.

El DBA debe conocer:

• motivo de conservación
• periodo requerido
• responsable
• ubicación
• controles de acceso
• mecanismo de eliminación

Pregunta

¿Por qué seguimos almacenando este dato?

Si no existe una razón válida, debe revisarse su permanencia.

Retención y eliminación segura

Eliminar datos no significa únicamente ejecutar:

DELETE FROM clientes;

También deben considerarse:

• copias de respaldo
• réplicas
• archivos temporales
• exportaciones
• logs
• snapshots
• ambientes de pruebas

Idea clave

El ciclo de vida del dato continúa después de eliminarlo de una tabla.

Eliminación segura

Una política de eliminación debe definir:

Identificar
    ↓
Autorizar
    ↓
Eliminar
    ↓
Verificar
    ↓
Registrar

Debe existir evidencia de que la operación fue realizada correctamente.

Actividad 2.3

Protección de datos

Analizar un conjunto de datos y determinar:

1. clasificación
2. nivel de riesgo
3. usuarios que requieren acceso
4. datos que deben enmascararse
5. datos que podrían seudonimizarse
6. periodo de retención
7. mecanismo de eliminación

Evidencia

Una matriz de clasificación y protección.

2.4 | Cifrado y protección técnica

El cifrado busca proteger la confidencialidad de la información.

Puede aplicarse:

• durante la comunicación
• durante el almacenamiento
• en respaldos
• en determinados campos
• en credenciales mediante mecanismos especializados

El cifrado es un control, no una estrategia completa de seguridad.

Cifrado en tránsito

Protege información mientras se desplaza entre componentes.

Cliente
   ↓
Canal protegido
   ↓
Servidor

Ejemplos:

• TLS
• conexiones seguras
• túneles cifrados
• VPN

Sin protección:

Cliente ────────────── Servidor
          datos

Con protección:

Cliente ══ TLS ══════ Servidor

2.4 | TLS en bases de datos

TLS puede proteger conexiones entre:

• aplicación y PostgreSQL
• aplicación y MongoDB
• herramienta administrativa y servidor
• componentes de una arquitectura distribuida

Protege principalmente:

• confidencialidad
• integridad del canal
• autenticación del servidor

2.4 | Cifrado en reposo

Protege información almacenada.

Puede aplicarse mediante:

• cifrado de discos
• cifrado de volúmenes
• cifrado de respaldos
• cifrado de archivos
• cifrado a nivel de aplicación
• mecanismos específicos del motor

Pregunta

¿Qué sucede si alguien obtiene una copia física del almacenamiento?

El control de acceso al servidor por sí solo puede no ser suficiente.

2.4 | Cifrado de datos vs hashing

No son lo mismo.

Contraseñas

No deberían almacenarse mediante cifrado reversible.

2.4 | Manejo seguro de credenciales

Una credencial puede ser:

• contraseña
• token
• API key
• certificado
• clave privada
• cadena de conexión
• secreto de aplicación

Nunca debe asumirse que una contraseña es el único secreto que debe protegerse.

2.4 | Almacenamiento de contraseñas

Una contraseña no debería almacenarse así:

usuario | contraseña
juan    | Secreto123

Ni simplemente mediante:

SHA-256(contraseña)

Para contraseñas se utilizan funciones diseñadas para derivación de claves y resistencia a ataques de fuerza bruta.

Ejemplos:

• Argon2id
• bcrypt
• scrypt

Idea clave

Una contraseña debe almacenarse mediante un mecanismo diseñado específicamente para contraseñas.

2.4 | Credenciales expuestas en aplicaciones

Un error frecuente:

DB_HOST=servidor
DB_USER=admin
DB_PASSWORD=123456

dentro del código fuente.

También pueden aparecer en:

• repositorios Git
• archivos .env
• logs
• scripts
• imágenes de contenedores
• archivos de configuración
• pipelines CI/CD

2.4 | ¿Qué hacer ante una credencial expuesta?

La respuesta no debe limitarse a eliminar el archivo.

Secuencia recomendada:

Detectar
   ↓
Revocar
   ↓
Rotar
   ↓
Investigar exposición
   ↓
Verificar accesos
   ↓
Corregir almacenamiento
   ↓
Registrar incidente

Importante

Una credencial publicada debe considerarse comprometida.

2.4 | Gestión de llaves

Las claves criptográficas también necesitan protección.

Debe controlarse:

• generación
• almacenamiento
• acceso
• distribución
• rotación
• revocación
• respaldo
• destrucción

Problema

Cifrar correctamente pero almacenar la clave junto al dato reduce considerablemente la protección.

2.4 | Ciclo de vida de una llave

Generación
    ↓
Almacenamiento seguro
    ↓
Uso controlado
    ↓
Rotación
    ↓
Revocación
    ↓
Destrucción

La gestión de llaves debe ser independiente del dato que protegen cuando sea posible.

2.4 | Base64 no es cifrado

Ejemplo:

SG9sYQ==

puede representar:

Hola

Base64 solamente codifica datos.

No proporciona:

• confidencialidad
• protección criptográfica
• resistencia contra lectura

Regla

Codificación no significa cifrado.

2.4 | PostgreSQL: pgcrypto

PostgreSQL puede proporcionar funciones criptográficas mediante pgcrypto.

Ejemplos conceptuales:

CREATE EXTENSION pgcrypto;

Puede utilizarse para:

• hashing
• cifrado
• funciones criptográficas

Advertencia

Las claves no deben quedar expuestas directamente en consultas, código fuente o repositorios.

2.4 | MongoDB: protección criptográfica

MongoDB puede utilizar mecanismos de seguridad para proteger:

• comunicaciones
• autenticación
• determinados datos
• almacenamiento

La disponibilidad exacta de determinadas capacidades depende de la versión y edición utilizada.

Principio

El mecanismo técnico debe seleccionarse de acuerdo con el riesgo y la arquitectura.

2.4 | Actividad 2.4

Protección criptográfica

Analizar:

1. una contraseña
2. una conexión de base de datos
3. un dato almacenado
4. una credencial de aplicación
5. una clave criptográfica

Para cada caso determinar:

• qué debe protegerse
• contra qué amenaza
• qué mecanismo utilizar
• dónde almacenar los secretos
• cómo verificar el control

2.5 | Privacidad y cumplimiento normativo

La seguridad busca proteger la información.

La privacidad busca asegurar que los datos personales sean tratados de manera adecuada.

Seguridad
¿Qué controles protegen los datos?

Privacidad
¿Por qué tenemos estos datos y cómo los utilizamos?

2.5 | Principios prácticos de protección de datos

El tratamiento debe considerar principios como:

• licitud
• consentimiento
• información
• calidad
• finalidad
• lealtad
• proporcionalidad
• responsabilidad

Estos principios deben traducirse en decisiones técnicas.

2.5 | Marco normativo mexicano

En México existen marcos diferenciados para:

Sector privado

Ley Federal de Protección de Datos Personales en Posesión de los Particulares.

Sector público

Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados.

La aplicación concreta depende de:

• quién trata los datos
• qué tipo de organización es
• qué información se procesa
• cuál es la finalidad del tratamiento

2.5 | ¿Qué significa para el DBA?

El cumplimiento no se resuelve únicamente con documentos legales.

Puede tener consecuencias técnicas sobre:

• acceso
• clasificación
• retención
• eliminación
• trazabilidad
• respaldos
• cifrado
• auditoría
• minimización

El DBA participa en la implementación técnica de controles relacionados con el tratamiento de datos.

2.5 | GDPR, SOX y HIPAA

Son marcos diferentes y no deben tratarse como equivalentes.

Su aplicación depende del contexto y alcance de la organización.

Idea clave

No se implementa una norma únicamente porque el nombre aparezca en una lista de cumplimiento.

2.5 | Aviso de privacidad

El aviso de privacidad informa al titular sobre aspectos del tratamiento de sus datos.

Entre otros elementos, puede explicar:

• quién trata los datos
• qué datos se recopilan
• para qué se utilizan
• cómo pueden ejercerse derechos
• con quién pueden compartirse

Implicación para el DBA

La base de datos debe almacenar solamente la información necesaria para las finalidades definidas.

2.5 | Consentimiento y finalidad

Antes de almacenar un dato debe existir una razón válida para hacerlo.

Dato
 ↓
¿Por qué se necesita?
 ↓
¿Para qué finalidad?
 ↓
¿Quién lo necesita?
 ↓
¿Durante cuánto tiempo?

La finalidad ayuda a determinar qué datos son necesarios y qué tratamiento está justificado.

2.5 | Minimización de datos

Un diseño puede ser técnicamente funcional y aun así recopilar información innecesaria.

Ejemplo:

Registro de usuario

Necesario:
nombre
correo
contraseña

¿Realmente necesario?
fecha de nacimiento
CURP
teléfono
dirección

Principio

No almacenar información solamente porque técnicamente podemos hacerlo.

2.5 | Derechos ARCO

Los titulares pueden ejercer derechos relacionados con sus datos personales.

A → Acceso
R → Rectificación
C → Cancelación
O → Oposición

La organización debe contar con mecanismos para responder a estas solicitudes conforme al marco aplicable.

2.5 | Trazabilidad del tratamiento

La trazabilidad permite responder:

• quién accedió
• cuándo accedió
• qué operación realizó
• sobre qué información
• desde dónde
• con qué cuenta

Ejemplo:

Usuario
  ↓
Autenticación
  ↓
Consulta
  ↓
Registro de actividad
  ↓
Evidencia

La trazabilidad permite investigar y demostrar.

2.5 | Base de datos y privacidad

El diseño de la base de datos puede facilitar o dificultar el cumplimiento.

Ejemplos:

• almacenar únicamente datos necesarios
• separar información sensible
• controlar privilegios
• registrar accesos
• aplicar retención
• eliminar información cuando corresponda
• proteger respaldos

2.5 | Actividad 2.5

De requisito de privacidad a control técnico

Para un caso de tratamiento de datos:

1. identificar el dato
2. identificar su finalidad
3. determinar quién debe acceder
4. definir periodo de retención
5. seleccionar controles
6. definir evidencia

Resultado

Requisito
   ↓
Riesgo
   ↓
Control
   ↓
Implementación
   ↓
Evidencia

2.6 | Protección de servidores de bases de datos

Una base de datos no funciona de manera aislada.

Datos
  ↓
Motor de BD
  ↓
Sistema operativo
  ↓
Red
  ↓
Infraestructura

Cada capa puede introducir riesgos.

2.6 | ¿Qué es hardening?

Hardening es el proceso de reducir la superficie de ataque y fortalecer la configuración de un sistema.

Incluye:

• eliminar configuraciones innecesarias
• restringir accesos
• proteger servicios
• proteger archivos
• reducir exposición
• aplicar actualizaciones
• registrar eventos
• establecer una línea base

2.6 | Reducción de superficie de ataque

Cada componente innecesario puede aumentar el riesgo.

Más servicios
+
Más puertos
+
Más usuarios
+
Más permisos
+
Más interfaces
=
Mayor superficie de ataque

Hardening busca reducirla sin afectar la función necesaria.

2.6 | Configuración segura por defecto

Una instalación funcional no necesariamente es una instalación segura.

La pregunta no es:

¿Funciona?

La pregunta es:

¿Funciona con la menor exposición razonable?

Ejemplos:

• escuchar solamente donde sea necesario
• deshabilitar funciones no utilizadas
• evitar cuentas innecesarias
• restringir accesos
• utilizar autenticación adecuada

2.6 | Instalación funcional vs instalación segura

Una instalación funcional es solamente el punto de partida.

2.6 | Cuentas, servicios y extensiones innecesarias

Durante el hardening deben revisarse:

• cuentas
• roles
• servicios
• procesos
• extensiones
• módulos
• puertos
• interfaces

Antes de eliminar algo:

1. identificar su función
2. determinar dependencias
3. evaluar impacto
4. aplicar el cambio
5. verificar

2.6 | Separación de ambientes

Los ambientes de:

Desarrollo
Pruebas
Producción

no deberían tratarse como uno solo.

Deben controlarse:

• datos
• credenciales
• accesos
• configuraciones
• permisos
• conexiones

Ejemplo

Los datos reales de producción no deberían copiarse directamente a desarrollo sin controles apropiados de protección y transformación.

2.6 | Configuración segura del servidor

El DBA debe revisar parámetros relacionados con:

• conexiones
• interfaces
• autenticación
• autorización
• logging
• TLS
• límites
• extensiones
• archivos
• almacenamiento

La configuración debe documentarse.

REFERENCIA OPERATIVA

2.6 | PostgreSQL: archivos y rutas importantes

En instalaciones mediante paquetes Debian/Ubuntu, las rutas habituales son:

Nota

Las rutas pueden cambiar según versión, distribución y método de instalación.

2.6 | PostgreSQL: postgresql.conf

Archivo principal de configuración.

Parámetros relevantes:

listen_addresses
port
max_connections
ssl
logging_collector
log_connections
log_disconnections

Pregunta

¿Qué exposición genera cada parámetro?

2.6 | PostgreSQL: pg_hba.conf

Controla las reglas de autenticación y acceso.

Ejemplo conceptual:

host  db_app  usuario_app  red_autorizada  scram-sha-256

La regla puede determinar:

• tipo de conexión
• base de datos
• usuario
• origen
• método de autenticación

pg_hba.conf es uno de los archivos más importantes para el control de acceso en PostgreSQL.

2.6 | PostgreSQL: directorio de datos

Ruta habitual:

/var/lib/postgresql/16/main/

Contiene información interna del cluster.

Debe protegerse:

• propietario
• grupo
• permisos
• acceso administrativo
• respaldos

No debe utilizarse como un directorio común de intercambio de archivos.

2.6 | PostgreSQL: logs

Ruta habitual:

/var/log/postgresql/

Los logs pueden ayudar a detectar:

• conexiones
• desconexiones
• errores
• problemas de autenticación
• eventos administrativos
• problemas operativos

2.6 | MongoDB: archivos y rutas importantes

En instalaciones habituales:

Nota

Las rutas pueden variar según instalación y versión.

2.6 | MongoDB: mongod.conf

Archivo principal de configuración.

Puede contener parámetros relacionados con:

• red
• almacenamiento
• logging
• seguridad
• operación

Ejemplo:

net:
  port: 27017
  bindIp: 127.0.0.1

Pregunta

¿En qué interfaces debe aceptar conexiones el servidor?

2.6 | MongoDB: autenticación y autorización

Son conceptos diferentes.

Autenticación

¿Quién eres?

Autorización

¿Qué puedes hacer?

La autorización basada en roles permite limitar las operaciones disponibles para cada usuario.

2.6 | MongoDB: directorio de datos

Ruta habitual:

/var/lib/mongodb/

Debe protegerse:

• propietario
• grupo
• permisos
• acceso administrativo
• respaldos

El acceso directo al almacenamiento debe estar restringido.

2.6 | MongoDB: logs

Ruta habitual:

/var/log/mongodb/mongod.log

Pueden proporcionar evidencia sobre:

• arranque
• detención
• errores
• conexiones
• autenticación
• comportamiento del servidor

2.6 | PostgreSQL y MongoDB: referencia rápida

No son equivalencias funcionales exactas.

La tabla sirve como referencia operativa.

2.6 | Usuario del servicio de base de datos

El motor de base de datos normalmente se ejecuta con una cuenta específica.

Ejemplo conceptual:

PostgreSQL
    ↓
usuario postgres
    ↓
proceso del servidor
    ↓
archivos de PostgreSQL

El proceso no debería ejecutarse como root.

Principio

Si un servicio es comprometido, sus privilegios deben estar limitados.

2.6 | Protección de archivos de configuración

Los archivos de configuración pueden modificar el comportamiento del servidor.

Por ello deben protegerse:

/etc/postgresql/16/main/
/etc/mongod.conf

El DBA debe revisar:

• propietario
• grupo
• permisos
• usuarios con acceso
• posibilidad de modificación

2.6 | Protección de archivos de datos

Los directorios de datos contienen información crítica.

PostgreSQL
/var/lib/postgresql/16/main/

MongoDB
/var/lib/mongodb/

Deben evitarse:

• permisos excesivos
• acceso de usuarios no autorizados
• copias no controladas
• exposición innecesaria

2.6 | Protección de respaldos

Un respaldo contiene información que puede ser tan sensible como la base de datos original.

Debe protegerse:

• acceso
• almacenamiento
• transmisión
• cifrado
• retención
• eliminación

Pregunta

¿Qué ocurriría si un atacante obtiene nuestro respaldo?

2.6 | Gestión de parches y actualizaciones

Las actualizaciones pueden corregir:

• vulnerabilidades
• errores
• problemas de estabilidad
• fallas de seguridad

Pero actualizar también requiere control.

Proceso:

Identificar
   ↓
Evaluar
   ↓
Probar
   ↓
Aplicar
   ↓
Verificar
   ↓
Documentar

2.6 | Restricción del acceso administrativo

No todos los usuarios deben administrar el servidor.

Debe controlarse:

• cuentas administrativas
• acceso remoto
• privilegios
• sudo
• acceso al sistema operativo
• acceso a la base de datos

Principio

Administrar una base de datos no implica administrar todo el servidor.

SEGURIDAD DE RED

2.6 | Segmentación de red

La segmentación limita qué sistemas pueden comunicarse entre sí.

Ejemplo conceptual:

Usuarios
   ↓
Red de aplicaciones
   ↓
Servidor de base de datos

No todos los componentes necesitan comunicarse directamente.

Objetivo

Reducir movimiento lateral y exposición.

2.6 | Reglas de firewall

Un firewall puede controlar:

• origen
• destino
• protocolo
• puerto
• dirección
• estado de conexión

Una política básica puede expresarse:

Permitir lo necesario
        +
Bloquear lo innecesario

2.6 | Allowlists

Una allowlist define explícitamente qué orígenes están autorizados.

Ejemplo conceptual:

Servidor de aplicación
        ↓
TCP 5432
        ↓
Servidor PostgreSQL

En lugar de:

Cualquier origen
        ↓
TCP 5432
        ↓
Servidor PostgreSQL

Principio

Es preferible autorizar explícitamente lo necesario.

2.6 | Redes privadas y túneles seguros

Un servidor de base de datos no necesita estar expuesto directamente a Internet.

El acceso administrativo puede realizarse mediante:

• redes privadas
• VPN
• túneles seguros
• bastiones
• canales administrativos controlados

Objetivo

Reducir la exposición pública.

2.6 | Restricción de exposición pública

Una mala configuración:

Internet
   ↓
5432
   ↓
PostgreSQL

Una arquitectura más restrictiva:

Red autorizada
      ↓
  PostgreSQL

El puerto del motor no debería exponerse públicamente si la operación no lo requiere.

2.6 | Diagnóstico de una conexión

Cuando una conexión falla, analizar por capas:

Cliente
  ↓
Conectividad
  ↓
Firewall
  ↓
Puerto
  ↓
Servicio
  ↓
Configuración
  ↓
Autenticación
  ↓
Autorización
  ↓
Permisos

No cambiar cinco configuraciones al mismo tiempo.

Primero identificar dónde está el problema.

LÍNEA BASE

2.6 | ¿Qué es una línea base?

Una línea base es una configuración de referencia considerada aceptable.

Permite comparar:

Estado inicial
      ↓
Hardening
      ↓
Estado esperado

Sin línea base es difícil determinar si un servidor continúa endurecido.

2.6 | Configuración mínima aceptable

Una línea base puede definir:

• usuarios autorizados
• servicios necesarios
• puertos permitidos
• interfaces permitidas
• autenticación requerida
• privilegios
• archivos protegidos
• logging
• actualizaciones
• reglas de firewall

La línea base debe ser verificable.

2.6 | Checklist de hardening

Sistema operativo

• [ ] usuarios identificados
• [ ] privilegios revisados
• [ ] acceso administrativo restringido
• [ ] servicios innecesarios deshabilitados
• [ ] actualizaciones aplicadas
• [ ] logs disponibles

Base de datos

• [ ] usuarios y roles revisados
• [ ] privilegios mínimos
• [ ] conexiones restringidas
• [ ] autenticación configurada
• [ ] TLS evaluado
• [ ] logging revisado

Red

• [ ] puertos necesarios identificados
• [ ] origen permitido definido
• [ ] firewall configurado
• [ ] exposición pública evaluada

2.6 | Comparación antes y después

El hardening debe producir evidencia.

La evidencia debe demostrar el cambio.

2.6 | Documentación de cambios

Todo cambio relevante debe registrar:

¿Qué se cambió?
¿Por qué?
¿Quién lo realizó?
¿Cuándo?
¿Qué riesgo reduce?
¿Cómo se verificó?
¿Qué impacto tuvo?
¿Cómo revertirlo?

Esto convierte una modificación técnica en un cambio administrado.

2.6 | Revisión periódica

El hardening no es una actividad de una sola vez.

Debe revisarse periódicamente porque cambian:

• software
• usuarios
• servicios
• aplicaciones
• vulnerabilidades
• requisitos
• arquitectura

Pregunta

¿El servidor sigue cumpliendo la línea base seis meses después?

2.6 | Línea base y deriva de configuración

Con el tiempo pueden aparecer cambios:

Línea base
    ↓
Cambios
    ↓
Nuevos servicios
    ↓
Nuevos usuarios
    ↓
Nuevos puertos
    ↓
Configuración modificada
    ↓
Deriva

La revisión periódica busca detectar esta deriva.

2.6 | Actualizaciones y parches

El DBA debe conocer:

• versión instalada
• versión disponible
• vulnerabilidades relevantes
• dependencia con aplicaciones
• ventana de mantenimiento
• procedimiento de reversión
• evidencia posterior

No basta con decir: "está actualizado".

Debe poder demostrarse.

2.6 | Actividad de hardening

Reducción de superficie de ataque

Los estudiantes deberán:

1. identificar servicios activos
2. identificar puertos
3. relacionar puertos y procesos
4. revisar configuraciones
5. identificar componentes innecesarios
6. analizar privilegios
7. aplicar cambios controlados
8. verificar funcionamiento
9. documentar evidencia

2.6 | Metodología de laboratorio

Utilizar la secuencia:

Preguntar
    ↓
Observar
    ↓
Decidir
    ↓
Cambiar
    ↓
Verificar
    ↓
Documentar

El objetivo no es memorizar comandos.

El objetivo es aprender a tomar decisiones de administración segura.

2.6 | Evidencia de hardening

La evidencia puede incluir:

• comandos ejecutados
• configuración antes/después
• servicios activos
• puertos abiertos
• permisos
• usuarios
• reglas de acceso
• logs
• pruebas de conexión

Una evidencia debe permitir que otra persona comprenda qué ocurrió.

2.6 | Defensa en profundidad

La seguridad debe combinar controles.

Datos
  ↓
Roles y privilegios
  ↓
Motor de BD
  ↓
Sistema operativo
  ↓
Firewall
  ↓
Segmentación
  ↓
Red

Si una capa falla, otras pueden limitar el impacto.

2.6 | Principio de mínimo privilegio

El principio aplica en todas las capas.

Base de datos

GRANT SELECT

Sistema operativo

sudo systemctl reload postgresql

Red

permitir únicamente origen autorizado

Mínimo privilegio significa otorgar solamente la capacidad necesaria.

2.6 | Integración de controles

Un servidor endurecido debe combinar:

Usuarios
   +
Privilegios
   +
Configuración
   +
Archivos
   +
Servicios
   +
Red
   +
Logs
   +
Parches
   +
Línea base

Ningún control individual resuelve todos los riesgos.

2.6 | Actividad integral

Evaluación de seguridad

Para un servidor de base de datos:

1. identificar activos
2. identificar datos
3. identificar usuarios
4. identificar servicios
5. identificar puertos
6. revisar configuración
7. revisar privilegios
8. revisar archivos
9. revisar red
10. revisar actualizaciones
11. establecer línea base
12. documentar hallazgos

2.6 | Resultado esperado

Al finalizar esta unidad, el estudiante debe poder:

• proteger datos
• administrar privilegios
• reconocer información sensible
• aplicar mecanismos de protección criptográfica
• identificar riesgos de credenciales
• relacionar privacidad con bases de datos
• analizar un servidor
• reducir superficie de ataque
• aplicar controles de hardening
• verificar configuraciones
• documentar evidencia

2.6 | Pregunta de cierre

Una base de datos tiene usuarios correctamente configurados, pero el servidor permite acceso administrativo amplio, tiene servicios innecesarios y expone el puerto del motor a Internet.

¿Está realmente segura?

Respuesta esperada

No.

La seguridad debe evaluarse de forma integral.

Datos
+
Base de datos
+
Sistema operativo
+
Red
+
Administración
+
Evidencia

El DBA debe proteger el sistema completo, no solamente la base de datos.

2.6 | Referencia rápida del DBA

Utiliza esta tabla como referencia durante las prácticas, no como sustituto de la documentación oficial del motor.