Database Systems Labs
Lo que separa un ejercicio de un sistema: restauración probada, migraciones sin caída, control de acceso, observabilidad y privacidad.
6 clases · 19 horas · 24 conceptos · 17 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
Lo que separa un ejercicio de un sistema. Seis clases sobre las tareas que no aparecen en ningún tutorial de SQL y que son las que deciden si el sistema sobrevive a su segundo año: restaurar, migrar sin caída, controlar el acceso, no ser vulnerable, medir lo que los usuarios notan y tratar el dato personal como una obligación de diseño.
El orden es el de la gravedad de las consecuencias. Primero el respaldo, con la afirmación más incómoda del programa: solo cuenta lo que se ha restaurado. Después las migraciones evolutivas con expandir y contraer, que es el patrón que permite desplegar esquema y código por separado. Luego el control de acceso, con una comprobación que suele salir mal: si la aplicación se conecta como propietaria del esquema, no hay privilegio mínimo. Después la inyección SQL, explicada por su causa y con su solución completa. Luego la observabilidad, donde la media oculta y el p99 enseña. Y al final privacidad, retención y gobierno.
La clase 061 está clasificada como fundamentos a propósito, aunque esté en una parte avanzada: no hay nivel de experiencia en el que la parametrización sea opcional.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 058 | Respaldo y restauración: solo cuenta lo que se ha restaurado | Intermedio | 4 | 3 |
| 059 | Migraciones evolutivas sin ventana de caída | Avanzado | 3 | 3 |
| 060 | Control de acceso: privilegio mínimo, roles y seguridad por fila | Intermedio | 3 | 4 |
| 061 | Inyección SQL y el contrato de parametrización | Fundamentos | 3 | 4 |
| 062 | Observabilidad, objetivos de servicio y capacidad | Avanzado | 3 | 3 |
| 063 | Privacidad, retención y gobierno del dato | Intermedio | 3 | 3 |
La clase que convierte una intención en una garantía medida. RPO y RTO se declaran en números, la recuperación a un punto en el tiempo se demuestra restaurando de verdad, y la conclusión es incómoda a propósito: un respaldo que nunca se ha restaurado no es un respaldo, es un fichero con nombre esperanzador.
RPO RTO recuperación a un punto en el tiempo prueba de restauración
Cambiar el esquema con el sistema en marcha, usando expandir y contraer: primero añadir sin quitar, después trasladar el tráfico y rellenar el histórico por lotes reanudables, y solo al final eliminar lo viejo. La compatibilidad hacia atrás deja de ser una buena práctica y pasa a ser obligatoria en cuanto el despliegue es gradual.
expandir y contraer doble escritura relleno compatibilidad hacia atras
El control de acceso con una comprobación incómoda como punto de partida: si la aplicación se conecta como propietaria del esquema, no hay privilegio mínimo. Trata roles, separación de funciones y seguridad por fila, cuya ventaja sobre filtrar en la aplicación es que no hay consulta que se pueda olvidar del filtro.
privilegio mínimo rol seguridad por fila separación de funciones
La inyección SQL explicada por su causa —mezclar código y datos en la misma cadena— y su solución completa: la consulta parametrizada, que no es una mitigación sino una defensa total. Cubre además el caso que los parámetros no resuelven, los identificadores dinámicos, que solo se validan con lista blanca.
consulta parametrizada identificador dinamico lista blanca defensa en profundidad
Medir lo que los usuarios notan. La media oculta y el p99 enseña; con veinte consultas por petición, casi todo el mundo toca la cola lenta. Une objetivos de servicio, presupuesto de error, saturación como señal anticipada y el registro de consultas lentas ordenado por tiempo total, no por la peor.
percentil presupuesto de error saturación consulta lenta
El dato personal como una obligación de diseño y no como un anexo legal. Minimización, limitación de finalidad, seudonimización y derecho de supresión, con el choque que hay que resolver antes de que llegue la solicitud: los respaldos, las réplicas y los registros de auditoría también contienen ese dato.
minimización limitación de finalidad seudonimización derecho de supresión
Cada uno de estos es una creencia habitual y su corrección.
Los 24 términos que esta parte introduce. Todos están también en el glosario del programa con sus términos relacionados.
| Término | Qué significa | Se trabaja en |
|---|---|---|
| compatibilidad hacia atras | Que el código nuevo siga entendiendo los datos escritos por el viejo, y que el viejo no se rompa con los del nuevo. Es obligatoria en cuanto el despliegue es gradual, porque durante un rato conviven las dos versiones. | 059 |
| consulta lenta | Registro de las consultas que superan un umbral, agrupadas por forma —`pg_stat_statements` y equivalentes—. Lo que importa no es la más lenta, sino la que multiplica tiempo por frecuencia: mil consultas de 50 ms pesan más que una de 5 s. | 062 |
| consulta parametrizada | Enviar la sentencia y los valores por canales distintos, de modo que el motor nunca interprete el dato como código. Es la defensa completa contra la inyección SQL, no una mitigación: bien usada, no hay cadena de entrada que cambie la estructura de la consulta. | 061 |
| defensa en profundidad | Poner varias barreras independientes, de modo que fallar una no baste: parametrizar, además dar privilegio mínimo, además registrar, además limitar por fila. Cada capa asume que las otras pueden fallar. | 061 |
| derecho de supresión | Obligación de borrar los datos de una persona cuando lo solicita y no hay base para conservarlos. Choca de frente con los respaldos, las réplicas y los registros de auditoría, y por eso hay que diseñar dónde vive el dato personal antes de que lo pidan. | 063 |
| doble escritura | Fase transitoria en la que la aplicación escribe en la estructura vieja y en la nueva a la vez. Sostiene la migración mientras se rellena el histórico; hay que declarar desde el principio cuándo termina, porque si no se queda para siempre. | 059 |
| expandir y contraer | Patrón de migración en tres tiempos: primero se añade lo nuevo sin quitar lo viejo, después se traslada el tráfico y se rellena, y solo cuando nadie usa lo antiguo se elimina. Es lo que permite desplegar esquema y código por separado sin ventana de caída. | 059 |
| identificador dinamico | El caso que los parámetros no cubren: nombres de tabla, de columna o la dirección de un `ORDER BY` no se pueden enviar como valor. La única solución correcta es validarlos contra una lista blanca cerrada, nunca escaparlos a mano. | 061 |
| limitación de finalidad | Los datos recogidos para un fin no pueden reutilizarse para otro incompatible sin nueva base legal. Es lo que impide que un correo pedido para la facturación acabe alimentando un modelo de recomendación. | 063 |
| lista blanca | Permitir solo lo que está explícitamente enumerado y rechazar todo lo demás. Se prefiere a la lista negra porque no hay que anticipar todas las formas de atacar, solo todas las formas válidas de usar. | 061 |
| minimización | Recoger solo los datos personales necesarios para la finalidad declarada. Es la medida de protección más eficaz que existe, porque el dato que no se guarda no se filtra, no hay que cifrarlo ni hay que borrarlo después. | 063 |
| percentil | El valor por debajo del cual queda un porcentaje de las observaciones. La media oculta el problema; el p99 lo enseña. Y si una petición de usuario abre veinte consultas, casi todos los usuarios tocarán al menos una de la cola lenta. | 062 |
| presupuesto de error | Lo que resta entre el objetivo de servicio y el 100 %: con un SLO de 99,9 % se dispone de unos 43 minutos de fallo al mes. Convierte la fiabilidad en una cantidad que se gasta, y da una regla objetiva para decidir si se despliega o se estabiliza. | 062 |
| privilegio mínimo | Cada identidad recibe exactamente los permisos que necesita para su función y ninguno más. La comprobación práctica es incómoda y reveladora: si la aplicación se conecta como propietaria del esquema, no hay privilegio mínimo. | 060 |
| prueba de restauración | Restaurar la copia en un entorno limpio, comprobar la integridad de los datos y medir cuánto tardó. Un respaldo que nunca se ha restaurado no es un respaldo: es un fichero con nombre esperanzador. | 058 |
| recuperación a un punto en el tiempo | Restaurar una copia base y reaplicar el registro archivado hasta un instante concreto, justo antes del `DELETE` sin `WHERE`. Exige que el archivado del registro esté activo y verificado desde antes del incidente. | 058 |
| relleno | Copiar el histórico a la estructura nueva, por lotes y de forma reanudable, para no bloquear la tabla ni saturar el registro. Debe ser idempotente: se va a interrumpir y habrá que relanzarlo. | 059 |
| rol | Agrupación de privilegios que se concede a personas o a aplicaciones. Permite razonar sobre permisos por función en lugar de por individuo, y revocar el acceso de alguien sin tener que auditar cada objeto. | 060 |
| RPO | Objetivo de punto de recuperación: cuántos datos se acepta perder, medido en tiempo. Un RPO de cinco minutos obliga a archivar el registro al menos cada cinco minutos; si no está escrito y probado, el RPO real es «el que salga». | 058 |
| RTO | Objetivo de tiempo de recuperación: cuánto se acepta estar caído. Se mide restaurando de verdad y cronometrando, no estimando; casi siempre resulta ser varias veces mayor de lo que el equipo suponía. | 058 |
| saturación | Cuán lleno está el recurso más escaso: conexiones, entrada y salida, memoria, CPU. Es la señal que anticipa el incidente, porque la latencia se dispara de forma no lineal justo antes de que el recurso se agote. | 062 |
| seguridad por fila | Políticas que el motor añade automáticamente a cada consulta para que un usuario solo vea las filas que le corresponden. La ventaja sobre filtrar en la aplicación es que no hay consulta que se pueda olvidar del filtro. | 060 |
| separación de funciones | Que quien desarrolla no sea quien despliega en producción, y que quien opera no pueda borrar sus propias huellas de auditoría. Es un control organizativo antes que técnico, y sin él el registro de auditoría no prueba nada. | 060 |
| seudonimización | Sustituir los identificadores directos por referencias, guardando por separado la tabla que permite revertirlo. Reduce el riesgo pero no convierte el dato en anónimo: mientras exista la clave, sigue siendo dato personal. | 063 |
17 obras distintas sostienen lo que se afirma en estas 6 clases.