Apps del sector público: cuando la digitalización encuentra la realidad
05 de agosto de 2025
El momento que me abrió los ojos sobre digitalización estatal
Plot twist de la modernización: El sector público decidió que ya era hora de digitalizar servicios. ¿El resultado? Applications que hacen que las apps bancarias parezcan el Banco Central de Fort Knox.
Mi primer encuentro revelador: Una aplicación para trámites administrativos que almacenaba información sensible en texto plano. Datos personales completos, documentos, contactos, todo visible para cualquier pata con conocimientos básicos de testing.
Mi reacción inicial: “Esto debe ser un ambiente de desarrollo, ¿no?” Spoiler: Era el sistema en producción, funcionando desde hace 2 años.
Patrones comunes en el sector público digital peruano
La clásica: “¿Para qué cifrado si es solo información de ciudadanos?”
En sistemas típicos de trámites documentarios he observado patrones que te hacen llorar:
- Almacenamiento de información personal sin cifrado adecuado (“muy caro, pues”)
- Contraseñas por defecto que los usuarios no están obligados a cambiar (“ya funciona así”)
- Comunicaciones que no siempre implementan HTTPS (“¿eso para qué sirve?”)
- Validación de datos principalmente en el frontend (“es más rápido, hermano”)
El razonamiento común: “No es plata del banco, no necesita tanta protección.”
Mi perspectiva: Los datos de los peruanos merecen mejor trato que el que les dan a los expedientes en Mesa de Partes.
Vulnerabilidades que no deberían existir ni en el gobierno de Fujimori
En sistemas de consultas administrativas es común encontrar:
- Falta de sanitización adecuada en los campos de búsqueda (programador junior a S/. 1,200)
- Mensajes de error que revelan información técnica innecesaria (“así salía en el tutorial de YouTube”)
- Bases de datos sin controles de acceso apropiados (“todos los funcionarios necesitan acceso, pues”)
- Ausencia de logs de auditoría para accesos sensibles (“para qué, si aquí nadie roba información”)
¿Cómo es posible? Según las mejores prácticas de desarrollo web, estas vulnerabilidades se evitan con validaciones básicas tanto en cliente como servidor. Pero claro, eso requiere un programador que sepa más que PHP básico.
El “cifrado de grado empresarial” hecho en casa
En aplicaciones de servicios ciudadanos que presumen usar “algoritmos de seguridad avanzados”, he observado:
- Implementaciones de cifrado caseras en lugar de estándares probados
- Técnicas de “seguridad por oscuridad” fácilmente reversibles
- Comentarios en código que revelan intenciones futuras de mejora
La realidad: Los estándares de cifrado existen por una razón. Reinventar la rueda en seguridad casi siempre termina mal.
Recomendación: Usar librerías de cifrado establecidas y auditadas en lugar de implementaciones propias.
La realidad del procurement tecnológico público peruano
”La propuesta más económica siempre gana” (y el sobrino también)
El proceso típico de contratación pública:
- Funcionario responsable: “Necesitamos digitalizar este proceso” (después de 3 años de usar Excel)
- Términos de referencia: “Que tenga seguridad” (copiado de otro TOR sin entender ni papa)
- Empresa ganadora: La que ofreció “una solución segura” al menor costo (S/. 25,000 para todo)
- Plot twist: El gerente de la empresa ganadora es cuñado del jefe de sistemas
- Resultado: Vulnerabilidades que harían llorar a un estudiante de instituto
¿Control de calidad técnico? “No estaba contemplado en el contrato, hermano. Además, el presupuesto ya se acabó.”
El equipo de desarrollo “especialista” (entre comillas bien grandes)
Perfil típico del team que desarrolla apps públicas:
- “Senior” Developer: 8 meses de experiencia copiando código de Stack Overflow
- Security Expert: Una vez configuró un antivirus en su casa
- Database Administrator: Sabe que existe phpMyAdmin
- Project Manager: Sobrino del alcalde que estudió “sistemas” en un instituto de 6 meses
- QA Tester: La secretaria que “sabe de computadoras”
Presupuesto real del proyecto: S/. 15,000 (el resto se fue en “gastos administrativos”)
Resultado predecible: Apps que un chibolo de quinto de secundaria hackearía en el recreo.
Casos de estudio (anonimizados) que me quitaron el sueño
La aplicación de trámites que regalaba información como volantes
En sistemas de licencias administrativas es común encontrar:
- APIs con controles de autorización más flojos que la moral de congresista
- Endpoints que devuelven más información de la necesaria (“para que el ciudadano esté informado, pues”)
- Ausencia de rate limiting para prevenir automatización (“¿quién va a automatizar trámites municipales?”)
- Logs de acceso más vacíos que promesa electoral
¿Por qué pasa? Frecuentemente porque el “especialista en seguridad” aprendió todo en un curso de Domestika.
Recomendación: Implementar controles de acceso que no sean “username: admin, password: admin”.
El sistema de pagos con validaciones más débiles que excusa de político
En plataformas de pagos administrativos he observado:
- Validaciones de seguridad implementadas únicamente en el frontend (“es más barato, hermano”)
- Falta de verificaciones server-side para transacciones críticas (“confío en mi código JavaScript”)
- Ausencia de logs de auditoría para operaciones financieras (“para qué, si la plata siempre aparece”)
- Procesos de confirmación de pago más simples que sacar DNI
El problema fundamental: Confiar únicamente en validaciones del lado del cliente. Como confiar en que un político no va a robar.
Recomendación: Toda validación crítica debe realizarse en el servidor, especialmente cuando hay plata de por medio. Obvio, ¿no?
La aplicación de salud que manejaba datos sensibles
En sistemas de seguimiento sanitario desarrollados durante situaciones de emergencia:
- Exposición de información médica personal con controles insuficientes
- Falta de implementación de normativas de protección de datos
- Ausencia de mecanismos de consentimiento informado claro
- Accesos no auditados a información médica confidencial
El desafío: Balancear la necesidad de respuesta rápida en emergencias con la protección adecuada de datos sensibles.
Recomendación: Implementar marcos de protección de datos desde el diseño, incluso en desarrollo acelerado.
La psicología del “esto no importa, pe”
El mito de la irrelevancia peruana
Frase típica de responsables técnicos:
“¿Quién va a querer atacar datos administrativos? No somos el BCP, hermano.”
Mi reflexión: Los datos del sector público son más jugosos que pollo a la brasa para:
- Suplantación de identidad (para sacar préstamos falsos)
- Ataques de phishing dirigidos (te llegan sabiendo hasta tu segundo apellido)
- Estafas personalizadas (“Hola, soy de la muni, necesito actualizar sus datos”)
- Análisis de patrones poblacionales (para campañas políticas sucias)
- Mercados de información personal (se vende como pan caliente)
“Es solo para uso administrativo, pues”
Otra justificación más común que la corrupción:
“El sistema es solo para personal autorizado, no requiere medidas de seguridad complicadas.”
La realidad que he observado en el Perú profundo:
- Credenciales compartidas entre más gente que en cuenta de Netflix familiar
- Sistemas “internos” más abiertos que las puertas del Congreso
- Bases de datos sin controles de acceso (cualquiera entra como Pedro por su casa)
- Información sensible que aparece en Google más rápido que escándalo de Magaly
El impacto real de las deficiencias técnicas
Más allá de la crítica técnica
Lo que realmente me preocupa no es solo la calidad técnica, sino las consecuencias tangibles:
Para los ciudadanos:
- Exposición no consentida de datos personales
- Vulnerabilidad ante ataques de ingeniería social
- Pérdida de confianza en servicios digitales públicos
- Riesgos de seguridad personal y financiera
Para las instituciones:
- Deterioro de la credibilidad institucional
- Costos ocultos de incidentes de seguridad
- Dependencia de soluciones técnicamente deficientes
- Obstáculos para la verdadera modernización digital
El círculo vicioso más peruano que la salsa criolla
- Presupuesto mínimo (“no hay plata”) → Proveedores de baja calidad (sobrino del funcionario)
- Sin especificaciones técnicas (“que funcione nomás”) → Desarrollos sin estándares
- Sin auditorías de seguridad (“muy caro, después vemos”) → Vulnerabilidades pasan desapercibidas por años
- Problemas salen a la luz (“hackean la muni”) → “La tecnología no sirve”
- Menos presupuesto para tecnología (“mejor seguimos con papel”) → Vuelta al paso 1
Bonus track: Cuando sale mal, echan la culpa al “personal técnico” (que cobra S/. 2,500 y tiene que mantener 15 sistemas diferentes).
Mi propuesta constructiva (porque la crítica sin propuesta es como político sin robar)
Basándome en mejores prácticas internacionales y marcos de referencia (que existen pero nadie lee en el sector público peruano), recomendaría:
Nivel básico - supervivencia digital:
- Implementación obligatoria de HTTPS en todos los servicios (“sí, cuesta más, pero vale la pena”)
- Uso de algoritmos estándar para hashing de contraseñas (nada de MD5, por favor)
- Validaciones de seguridad tanto en cliente como servidor (“redundancia necesaria, no pereza”)
- Implementación de logging y auditoría básica (“para saber quién la cagó”)
Nivel intermedio - como países normales:
- Sistemas de autenticación robustos basados en estándares (no contraseñas en Excel)
- Aplicación del principio de menor privilegio (“no todos necesitan acceso a todo, pues”)
- Estrategias de backup automatizado y cifrado (“para cuando se malogre todo”)
- Monitoreo proactivo de eventos de seguridad (“detectar problemas antes que salgan en ATV”)
Nivel avanzado - el sueño del peruano:
- Auditorías regulares de seguridad por terceros (que no sean compadres del alcalde)
- Programas de capacitación continua en seguridad (más allá de “no abrir archivos sospechosos”)
- Documentación técnica completa y actualizada (no apuntes en servilleta)
- Planes de respuesta a incidentes bien definidos (“protocolo de crisis que no sea correr como cucaracha”)
La implementación práctica (aka “la realidad peruana”)
¿Qué se necesita para la implementación? Según frameworks como NIST y ISO 27001 (que suenan bonito en las presentaciones):
- Asignación específica de presupuesto para seguridad (“imposible, no hay plata”)
- Capacitación técnica especializada del personal (“muy caro, mejor YouTube”)
- Adopción de metodologías de desarrollo seguro (“mucha burocracia, hermano”)
- Cambio cultural hacia la seguridad como prioridad (“que funcione nomás, después vemos”)
Recursos recomendados: Guías del NIST, estándares ISO, frameworks de OWASP para desarrollo web seguro.
¿Los van a leer? Probablemente no, pero al menos quedó bonito en el informe final.
Reflexión final: entre el análisis técnico y la esperanza peruana
Lo que me mantiene reflexionando no son las deficiencias técnicas en sí, sino la oportunidad de mejora que representan. Porque hasta en el Perú se puede hacer las cosas bien, pues.
¿Es preocupante la situación actual? Más que ver a Toledo libre. ¿Es irreversible? Para nada, pe.
La digitalización del sector público peruano no tiene por qué ser sinónimo de “vulnerabilidades made in Perú”. Los ciudadanos peruanos merecen servicios digitales que protejan adecuadamente su información personal y garanticen procesos seguros. Porque nuestros datos valen tanto como los de cualquier gringo.
¿Mi perspectiva? Que estas observaciones lleguen a algún funcionario con poder de decisión (y ganas de trabajar honestamente) que entienda que la seguridad es una inversión en la confianza ciudadana y la eficiencia institucional.
Mientras tanto, seguiré documentando estos patrones con la esperanza de contribuir a una discusión constructiva sobre cómo mejorar la calidad técnica de los servicios digitales públicos. Y quién sabe, tal vez algún día tengamos apps públicas que no den vergüenza.
PD: Todos los ejemplos están basados en patrones reales observados en el sector, pero generalizados y anonimizados. La intención es constructiva: mejorar la calidad de los servicios digitales que todos usamos. Si trabajas en el sector público y te molestaste… mejor ponte a trabajar en serio, pues.