Universidad Fermín Toro, Auditoría de Sistemas: Cómo Hacer una Auditoría

Publicado por Eduardo Iribarren

Cuando alguien escucha la palabra "auditoría" suele pensar en cuentas, facturas y un contador con calculadora. Pero en el mundo del software hay otra auditoría, igual de rigurosa, que no revisa dinero sino código, datos y controles: la auditoría de sistemas. En este artículo explico qué es, cómo se hace paso a paso, y — para que no quede en teoría — la aplico de principio a fin sobre un sistema real: EduManage v1.0, la plataforma de gestión académica que desarrollé para la Unidad Educativa "Bolívar y Bello".

1. Definición y tipos de auditoría

1.1 ¿Qué es una auditoría de sistemas?

Una auditoría de sistemas (o auditoría informática) es el proceso sistemático de recopilar y evaluar evidencia sobre el diseño, la operación y los controles de un sistema de información, con el fin de determinar si:

• protege adecuadamente los activos de información,
• mantiene la integridad de los datos,
• permite que la organización alcance sus objetivos de forma eficaz, y
• utiliza los recursos de manera eficiente.

En pocas palabras: no basta con que el sistema "funcione". Una auditoría pregunta si funciona bien, de forma segura y de forma verificable.

1.2 Tipos de auditoría de sistemas

No existe un único tipo de auditoría; el enfoque cambia según qué se quiera evaluar:

También se clasifica según quién la realiza:

• Auditoría interna: la ejecuta personal de la propia organización o el mismo equipo de desarrollo, de forma preventiva.
• Auditoría externa: la realiza un tercero independiente, generalmente con fines de certificación o de mayor objetividad.

Y según el momento:

• Auditoría previa a producción (antes de que el sistema entre en uso real).
• Auditoría periódica (revisiones programadas sobre un sistema ya en marcha).
• Auditoría post-incidente (después de una falla o brecha de seguridad).

Para este artículo aplico una auditoría interna, de aplicación y seguridad, previa a producción, sobre EduManage v1.0 — el escenario más común y más útil para un sistema recién construido.

2. Procedimiento para realizar una auditoría de sistemas

Toda auditoría seria sigue una secuencia de fases. Estas son las que utilicé, adaptadas de marcos de referencia como COBIT e ISO 19011:

1. Planificación y definición del alcance
Se define qué se va a auditar (el sistema completo, un módulo, un tipo de control), con qué objetivo, y qué criterios se usarán para evaluar (buenas prácticas de seguridad, requisitos funcionales, normativa aplicable).

2. Relevamiento de información
Se recopila toda la documentación disponible: manuales de usuario y de sistema, diagramas de arquitectura, modelo de datos, código fuente, políticas de acceso. En esta fase se entiende cómo debería funcionar el sistema antes de comprobar cómo funciona en realidad.

3. Ejecución de pruebas (trabajo de campo)
Es el corazón de la auditoría. Incluye:

• Revisión de código (auditoría estática): inspección línea por línea de los archivos fuente en busca de fallas de seguridad, lógica incorrecta o desviaciones respecto a la documentación.
• Pruebas funcionales: verificar que los módulos hagan lo que el manual dice que hacen.
• Pruebas de penetración básicas: intentar vulnerar controles de acceso, inyectar datos maliciosos, forzar sesiones.
• Revisión del modelo de datos: integridad referencial, normalización, consistencia de reglas de negocio.

4. Evaluación de hallazgos y análisis de riesgo
Cada hallazgo se clasifica por severidad (crítica, alta, media, baja) según su probabilidad de ocurrencia y el impacto que tendría.

5. Elaboración del informe de auditoría
Se documentan los hallazgos, la evidencia que los sustenta, el riesgo asociado y las recomendaciones de remediación, en un lenguaje claro para que la organización pueda actuar.

6. Seguimiento (follow-up)
Una auditoría sin seguimiento es solo un diagnóstico. La fase final verifica que las recomendaciones se implementaron.

3. Cómo apliqué esta auditoría al sistema EduManage v1.0

Con el marco anterior ya definido, así fue el proceso concreto sobre EduManage:

Alcance: auditoría interna de aplicación y seguridad, previa a producción, sobre el código fuente completo del sistema (14 módulos PHP + configuración de base de datos) y su documentación (Manual de Usuario y Manual del Sistema).

Relevamiento: partí de los dos manuales ya elaborados, que me dieron el modelo de datos, la arquitectura declarada y las reglas de negocio esperadas (tres momentos pedagógicos, escala 1–20, nota mínima 10, roles administrador/operador). Esto me sirvió como "línea base" contra la cual comparar el comportamiento real del código.

Ejecución de pruebas: revisé el código fuente completo (config/db.php y los 14 archivos .php del sistema) buscando específicamente:

• consistencia entre lo documentado y lo implementado,
• uso de sentencias preparadas vs. concatenación directa de consultas SQL,
• verificación de sesión y rol en cada módulo protegido,
• manejo de contraseñas y credenciales,
• protección contra ataques de falsificación de solicitudes (CSRF),
• validación de datos de entrada (especialmente en el módulo de calificaciones, por ser el núcleo de la lógica de negocio),
• manejo y exposición de errores.

Esta combinación — auditoría documental + auditoría de código + pruebas dirigidas — es exactamente el tipo de trabajo que un analista de sistemas haría antes de dar luz verde a un sistema para producción.

4. Informe de auditoría — EduManage v1.0

4.1 Resumen ejecutivo

EduManage v1.0 es un sistema funcionalmente completo y con una base de datos bien modelada (3FN, claves foráneas consistentes, trazabilidad de reglas de negocio). El código muestra buenas prácticas defensivas en varios frentes: uso sistemático de sentencias preparadas (no se encontró ni un solo punto de inyección SQL clásica), verificación de sesión y rol en todos los módulos protegidos, y validación server-side de las reglas críticas de negocio (rango de notas 1–20, redondeo). Sin embargo, se identificaron hallazgos de severidad crítica y alta relacionados principalmente con el manejo de credenciales y la ausencia de protección contra falsificación de solicitudes, que deben resolverse antes de exponer el sistema a un entorno de producción con datos reales de estudiantes.

4.2 Matriz de hallazgos

4.3 Aspectos positivos verificados

Para que el informe sea justo, es tan importante documentar lo que funciona bien:

• ✅ Cero inyecciones SQL detectadas: las 18 consultas que no usan prepare() corresponden a listados sin parámetros de usuario (ORDER BY estático); toda consulta que recibe datos externos usa bind_param() correctamente.
• ✅ Control de acceso consistente: los 14 módulos verifican sesión activa, y los que requieren rol de administrador (usuarios.php) verifican el nivel antes de ejecutar cualquier acción.
• ✅ Validación de reglas de negocio en servidor, no solo en el navegador: el módulo de calificaciones rechaza notas fuera del rango 1–20 y aplica el redondeo (PHP_ROUND_HALF_UP) de forma centralizada.
• ✅ Escape de salida con htmlspecialchars() aplicado de forma extendida en todos los módulos, mitigando XSS reflejado.
• ✅ Integridad referencial bien definida con FOREIGN KEY ... ON DELETE CASCADE en todas las tablas relacionales.

4.4 Recomendaciones priorizadas

1. Inmediato (antes de producción): migrar el almacenamiento de contraseñas a password_hash() / password_verify(), y forzar el cambio de la contraseña del administrador por defecto.
2. Inmediato: sacar las credenciales de base de datos del código fuente (variables de entorno o archivo de configuración fuera del control de versiones y excluido de respaldos que se compartan).
3. Corto plazo: implementar tokens CSRF en todas las operaciones que modifiquen datos (crear, editar, eliminar), y migrar las eliminaciones de GET a POST donde aún falte.
4. Corto plazo: unificar el mensaje de error de login ("Usuario o contraseña incorrectos") y añadir un contador de intentos fallidos con bloqueo temporal.
5. Corto plazo: añadir session_regenerate_id(true) inmediatamente después de autenticar.
6. Mediano plazo: versionar CURSO_ASIGNATURA por ID_Periodo para conservar el histórico de pensum.
7. Mediano plazo: planificar la migración fuera de PHP 5.6 / MySQL 5.7 (ambos sin soporte de seguridad activo), documentando el riesgo aceptado mientras tanto.

4.5 Conclusión de la auditoría

EduManage v1.0 demuestra una base técnica y de modelado de datos sólida, con buenas prácticas defensivas frente a los riesgos más comunes en aplicaciones PHP (inyección SQL, XSS). No obstante, el sistema no debería considerarse listo para producción con datos reales de estudiantes hasta resolver los hallazgos críticos (H1 y H2) y altos (H3), ya que involucran directamente la confidencialidad de credenciales y la integridad de las operaciones administrativas. Con esas correcciones — que son puntuales y no requieren rediseñar el sistema — EduManage v1.0 alcanzaría un nivel de madurez adecuado para su despliegue en la Unidad Educativa "Bolívar y Bello".