Audito las capas de la plataforma que forman parte del alcance acordado.
He visto caídas, brechas y recuperaciones fallidas cuyo origen no estaba en una sola capa. Examino las relaciones entre el código, los datos, la arquitectura y la infraestructura, sin separar el rendimiento, la seguridad, la accesibilidad y la continuidad.
De la observación a la decisión
Relaciono lo que encuentro con su consecuencia, la decisión pendiente y la forma de comprobar que se ha resuelto.
Código, configuración y comportamiento dentro del alcance acordado.
Registro la evidencia y las condiciones para reproducirla.
Busco explicaciones alternativas antes de dar por válido el hallazgo.
Compruebo la corrección con una prueba ligada al problema.
Criterio profesional
He recibido informes de auditoría de doscientas páginas que no permitían tomar ni una decisión. Estas son las condiciones que me exijo.
Cuando está en el código, indico el fichero, la línea y el fragmento exacto; en configuración, ejecución u operación, cito la clave, la traza, la métrica, el intervalo y los pasos necesarios para reproducirlo. Cuando se trata de una ausencia, documento el alcance completo revisado.
Lo que expone datos o tumba el servicio va primero. Lo que molesta al leerlo va al final. Mezclar las dos cosas en la misma lista es la forma más rápida de que no se arregle ninguna.
La revisión determina si esa observación constituye un hallazgo. Separo los datos comprobables de los juicios técnicos y documento ambos de forma distinta.
Intento refutar la observación y contrastarla con la ejecución antes de incorporarla al informe. Si falta evidencia, documento la incertidumbre y lo que queda por comprobar.
Dónde se concentra la complejidad
Aceptar una entrega, heredar código sin documentación, comprar un producto, entender un incidente o averiguar qué impide actualizar. La pregunta de fondo se repite: qué hay realmente ahí dentro.
El desarrollo llega terminado y alguien tiene que decir si se acepta. Sin criterio técnico, la conversación se reduce a si la pantalla se ve bien.
Cambia el proveedor o se va la persona que lo mantenía. Falta documentación sobre lo que hace el código, sus dependencias y los riesgos de modificarlo.
Se va a adquirir un producto o a integrar un equipo, y la decisión depende de qué deuda técnica se compra con él y cuánto costará mantenerla.
Ha ocurrido algo y hace falta saber si fue un caso aislado o el síntoma de una forma de programar que va a repetirlo.
Cada versión nueva exige un proyecto. Hay que saber qué desarrollos concretos lo impiden y qué costaría desatascarlos.
Antes de distribuir una extensión o abrir un servicio, conviene que alguien lo revise con la mirada de quien intentará romperlo.
Qué miro y qué queda por escrito
Audito código, datos, configuración e infraestructura según el alcance acordado. La revisión de código es una de esas dimensiones, no necesariamente el encargo completo.
Permisos, validación de entrada, escapado de salida, consultas, control de acceso y tratamiento de datos personales. Cada hallazgo llega con la línea exacta y con lo que un atacante conseguiría.
Estructura, duplicación, acoplamiento, cumplimiento de las convenciones de la plataforma y decisiones que pueden dificultar una actualización. Estos factores condicionan el coste de mantenimiento durante el horizonte acordado.
Si las pruebas fallan cuando deben, si cubren el recorrido real y no solo el recorrido previsto, y qué casos quedan sin comprobar. La ausencia se verifica sobre toda la batería, no fichero a fichero.
Consultas, índices, caché, procesos en segundo plano y comportamiento con volumen. Además, qué se ve cuando algo falla y si se puede revertir un despliegue.
Revisión con arreglo a criterios acordados antes de aceptar el trabajo, con un veredicto que la organización puede defender en una conversación contractual.
He montado las mismas reglas para que se ejecuten en cada cambio, de forma que el equipo recibe el hallazgo cuando aún es barato corregirlo y no dos años después en un informe.
Responsabilidades concretas
Un informe que nadie puede verificar no cambia nada. Cada hallazgo lleva su cita, su gravedad razonada y la decisión que abre, para que la organización pueda actuar o aceptar el riesgo a sabiendas.
Qué se audita, con qué profundidad y contra qué criterios. Una auditoría sin alcance escrito acaba siendo interminable o superficial, y a veces las dos cosas.
Permisos que no se comprueban, entradas que no se validan, consultas construidas por concatenación, datos personales que salen donde no deben y control de acceso que se apoya en que nadie mire la dirección.
No cuento cuántas pruebas hay: compruebo si fallan cuando el código se rompe. Una batería que pasa haga lo que haga el programa da una seguridad falsa.
Duplicación, dependencias sin gobierno, acoplamiento con detalles internos de la plataforma y todo lo que convierta la próxima actualización en un proyecto.
Lo que se lee bien puede caerse con volumen. Reviso consultas, índices, caché y lo que ocurre en el momento de más uso, que es cuando importa.
Cuando es posible estimarlo, cada hallazgo incluye un rango para corregirlo y para asumir el riesgo, con sus supuestos e incertidumbre. La organización conserva la decisión.
Mapa de especialización
Cuando reviso el rendimiento de una plataforma no empiezo por la configuración: busco qué operación genera la demanda y qué recurso deja de atenderla. Estos son los frentes que miro y los términos con los que trabajo en cada uno.
He encontrado caídas que no nacían de una única configuración incorrecta, sino de la coincidencia entre una ráfaga, una cola, un bloqueo o una dependencia externa. Por eso no busco una receta universal: reconstruyo qué operación generó la demanda y qué recurso dejó de atenderla.
No reduzco Moodle a PHP, base de datos y nodos web. Sigo el recorrido hasta el motor de preguntas, las calificaciones, las tareas planificadas, los eventos, las extensiones y `moodledata`.
Construyo el modelo de demanda con llegadas, concurrencia efectiva, throughput y duración de cada operación. Cuando procede, utilizo la ley de Little para comprobar si las cifras de concurrencia, tasa y tiempo de respuesta son coherentes.
Organizo la observabilidad alrededor de operaciones Moodle y de recursos concretos. Utilizo métricas RED —tasa, errores y duración— para los recorridos y USE —utilización, saturación y errores— para la infraestructura.
Sigo las llamadas a SAML, OAuth 2/OIDC, LDAP, sistemas académicos, ERP, HRIS, CRM, proctoring, videoconferencia, correo, antivirus y repositorios. Mido cuánto presupuesto de latencia consume cada una y qué ocurre cuando responde tarde o deja de responder.
Evito que informes, exportaciones y cuadros de mando compitan con cuestionarios, entregas y calificaciones. Analizo qué datos necesitan inmediatez y cuáles pueden trasladarse mediante ETL o ELT a un almacén analítico.
Documento el síntoma, la evidencia, las hipótesis descartadas, la causa demostrada, el impacto y la prueba que confirma la corrección. Si una afirmación depende de una métrica, conservo el intervalo, la zona horaria, la consulta, el filtro y la versión de la configuración utilizada.
Casos de uso
Cada caso conserva el síntoma, la comprobación, la decisión y su límite. Retiro las combinaciones de entidad y cifra que podrían identificar a terceros; las magnitudes solo sitúan la escala del problema.
Durante una prueba de carga, el clúster caía al poco de comenzar y devolvía errores de servidor. Medí la latencia en el balanceador, las conexiones activas a Redis y la E/S de disco en PostgreSQL. Al principio pensé en falta de escalado en la base de datos o en los nodos de PHP-FPM, hasta que vi que la saturación coincidía con miles de consultas idénticas y con el agotamiento de conexiones a Redis. Era una estampida de regeneración: muchas claves de la caché de aplicación expiraban a la vez y cientos de procesos PHP reconstruían los mismos objetos de contexto y de plugins. Separé las sesiones y la caché de aplicación en almacenes de Redis independientes, mantuve la caché de petición dentro de cada proceso, escaloné las caducidades y añadí un bloqueo por clave con actualización en segundo plano: mientras un proceso regenera, los demás reciben temporalmente la copia caducada. Activé además conexiones persistentes con serialización binaria para evitar una nueva conexión TCP en cada petición. En el recorrido documentado en el informe confidencial, la plataforma sostuvo una concurrencia de decenas de miles de sesiones. Las cifras detalladas de latencia y uso de CPU pertenecen a ese escenario y no constituyen una capacidad general de la plataforma.
En una convocatoria con decenas de miles de cuestionarios a la vez, los intentos y las respuestas se bloqueaban, los interbloqueos se repetían y el rendimiento se desplomaba a mitad de examen. Medí las consultas lentas, los hilos en espera de bloqueo, la memoria de la base de datos y la frecuencia de autoguardado. Lo primero que me pidieron fue una instancia con más CPU y memoria. Los datos decían otra cosa: la carga se concentraba en escrituras síncronas periódicas y en la competencia entre lecturas y escrituras sobre el mismo nodo. El origen era el autoguardado de respuestas, que se ejecutaba cada minuto mientras las consultas de intentos y de navegación seguían leyendo del nodo de escritura. Ajusté el intervalo de autoguardado y las peticiones de finalización. Desvié a réplicas únicamente las lecturas que toleraban retraso y mantuve en el nodo principal las que debían reflejar de inmediato una escritura. También afiné max_connections, shared_buffers, work_mem y el autovacuum. En la repetición documentada desaparecieron los interbloqueos y se alcanzó la concurrencia prevista; las métricas detalladas pertenecen al informe confidencial del caso.
Después de una migración de versión, abrir la página principal de un curso pasó de responder en menos de un segundo a necesitar varios segundos bajo carga. Perfilé las peticiones con instrumentación de PHP, conté las consultas de cada una y medí su duración. Sospeché primero de la memoria de los nodos PHP y de la acumulación histórica en la base de datos. El perfilado lo desmintió al aislar una sola consulta cuyo plan recorría la tabla entera. Venía de una tabla propia de un plugin de seguimiento con millones de filas y sin un índice compuesto por curso y usuario. Activé el registro de consultas lentas, analicé el plan de ejecución, creé el índice que faltaba y reescribí el código para sustituir las consultas dentro del bucle por una sola consulta agregada. La prueba interna confirmó una reducción de un orden de magnitud en el tiempo de respuesta y muchas menos lecturas de disco; la serie pertenece al informe confidencial.
La plataforma se congelaba cada mañana cuando se generaban los informes de seguimiento. Medí las consultas lentas, los aciertos de caché y los bloqueos de metadatos. Parecía que faltaban procesos PHP para atender un pico de actividad, pero los bloqueos coincidían con consultas por fecha y contexto sobre un registro con decenas de millones de filas sin particionar. Los informes ocupaban memoria de la base de datos y expulsaban del área de trabajo las páginas que utilizaba la actividad diaria. Separé los registros hacia un almacén de solo lectura, dejé de guardar eventos sin uso, particioné por rangos de fecha y programé el archivado según la política de retención. Se acabaron las congelaciones durante los informes y la base operativa quedó reducida a una fracción de su tamaño anterior; no publico la serie completa.
La base de datos respondía más despacio después de purgar decenas de miles de usuarios inactivos y reiniciar miles de cursos, aunque contenía muchos menos datos lógicos. Medí el tamaño físico en disco, la fragmentación de los índices y las lecturas de página por consulta. Parecía corrupción de la base de datos o un fallo del almacenamiento, y lo descarté porque los ficheros conservaban prácticamente el mismo tamaño y las consultas seguían recorriendo páginas vacías. Los borrados masivos habían dejado huecos en las páginas de tablas e índices, pero el motor mantenía ese espacio fragmentado. Escribí una comprobación para localizar las tablas con una proporción elevada de espacio libre, reconstruí tablas e índices durante una ventana de mantenimiento y ajusté el factor de llenado para las tablas con muchas lecturas y pocas actualizaciones. La prueba interna confirmó una recuperación importante de espacio y una reducción clara del tiempo de las consultas por índice; no publico las magnitudes exactas.
Una revisión detectó un control de autorización insuficiente en un servicio propio. Contrasté el análisis del código con pruebas dentro del alcance acordado. Corregí la validación de permisos y contextos, reduje la información expuesta y comprobé de nuevo los límites de acceso. La reevaluación confirmó el cierre del problema observado. Conservo los detalles de reproducción en el informe reservado.
La plataforma tenía que cumplir los requisitos de accesibilidad definidos para el encargo y la revisión inicial encontró barreras. Combiné el escaneo automático con una revisión manual, con lectores de pantalla y navegando solo con el teclado. Así vi que los cuestionarios atrapaban el foco, el tema corporativo no llegaba al contraste mínimo y varios componentes de terceros no funcionaban con lectores de pantalla. Sobre el papel podía parecer suficiente superar el estándar técnico más conocido, pero la norma europea y la legislación española aplicables añadían requisitos propios. El uso real destapó problemas que el escaneo no encontraba. Reescribí el CSS y las plantillas para corregir el contraste, añadí los atributos que anuncian los cambios de estado en menús, acordeones y ventanas modales, y recuperé el indicador de foco que alguien había suprimido. Resolví además la trampa de foco de las preguntas de arrastrar y soltar con una alternativa por teclado. En la versión, la muestra y los criterios evaluados, la revisión final no dejó hallazgos abiertos en la interfaz base ni en los tipos de cuestionario incluidos.
Una revisión de seguridad detectó entradas sospechosas en un desarrollo propio. Parecían neutralizadas en el punto de entrada, pero seguí el recorrido completo y comprobé que otra etapa volvía a interpretarlas fuera del límite de confianza y podía producir una ejecución no autorizada. Sustituí la construcción dinámica de las operaciones por la API parametrizada de la plataforma y añadí a la integración continua una regla que rechazaba ese patrón. Eliminé el vector y la auditoría externa terminó sin hallazgos críticos. Omito las entradas, las funciones afectadas y la cadena de explotación para impedir que el caso permita reconstruir el ataque.
Durante una auditoría interna detecté que una extensión sin mantenimiento permitía superar los permisos previstos. El análisis estático localizó una interpretación insegura de datos guardados que podía reconstruir objetos ejecutables. Sustituí ese formato por una representación limitada a datos y, durante la transición de los registros antiguos, bloqueé la creación de objetos. Eliminé el vector y la extensión quedó conforme al estándar de desarrollo seguro de la plataforma. Omito el rol, las entradas y la cadena de explotación para impedir que el caso permita reproducirla.
Cómo trabajo
Las reglas deterministas producen observaciones reproducibles; la lectura experta decide cuáles constituyen un problema en este contexto. Antes de escribir un hallazgo, intento demostrar que me equivoco.
Qué entra, qué queda fuera, con qué criterios se juzga y qué decisión debe permitir tomar el informe.
Comprobaciones deterministas sobre la estructura del código. Con la misma versión, configuración, entorno y datos de entrada, producen un resultado reproducible y no dependen de quién pulse el botón.
La revisión experta encuentra problemas de diseño y de contexto que las reglas no expresan. Sus resultados se combinan con las comprobaciones automáticas y la evidencia de ejecución.
Antes de escribirlo, busco la explicación que lo invalide. Lo que sobrevive a ese intento es lo que entra en el informe.
Cada hallazgo con su gravedad, su cita, lo que cuesta arreglarlo y lo que cuesta dejarlo. La organización decide con esa información delante.
Recorrido profesional
Blog
Escribo sobre los hallazgos que se repiten en casi todas las auditorías, sobre las pruebas que dan seguridad falsa y sobre cómo se defiende un veredicto técnico delante de un proveedor que no lo comparte.
Contacto
Aceptar una entrega, heredar un desarrollo o explicar una actualización bloqueada exigen evidencias distintas y un alcance acordado.