Seguridad en producción para equipos medianos: la base que tu proyecto necesita antes del go-live

La seguridad en producción suele abordarse al revés. Los equipos activan opciones, añaden reglas, configuran alertas y asumen que el sistema está cubierto. Pero lo que obtienen no es seguridad, sino un conjunto de intenciones.

El problema aparece cuando esas intenciones se ponen a prueba. Una cuenta que no debería existir sigue activa, una credencial acaba en un log, una base de datos es accesible desde internet porque nadie revisó un atajo inicial, un backup que parece crearse correctamente pero no puede restaurarse. Y las alertas generan tanto ruido que la importante queda ignorada.

Un sistema en producción no es seguro porque se hayan aplicado configuraciones de un documento, sino cuando el equipo puede explicar qué riesgo reduce esa configuración, verificar que funciona y mantenerlo mientras el sistema cambia.

Este artículo no es un programa de seguridad corporativo, sino una base práctica para proyectos medianos: las condiciones que deberían cumplirse antes de considerar que un sistema está listo para producción.

Para qué sirve este artículo (y para qué no)

Para la mayoría de los equipos, la seguridad en producción no va de atacantes avanzados ni de modelos de amenaza exóticos. Va de evitar fallos que se repiten una y otra vez en proyectos normales.

Los problemas habituales son siempre los mismos: una cuenta administrativa comprometida, una credencial filtrada, una base de datos expuesta porque nadie revisó una configuración temporal, una copia de seguridad que parece sana pero no restaura nada útil, o un flujo de alertas tan ruidoso que la señal importante se pierde.

El objetivo es convertir esos riesgos en garantías concretas. En cada área, tu equipo debería poder responder tres cosas con claridad: qué debe ser cierto, qué riesgo reduce esa verdad y cómo se verificaría en condiciones reales. Si esas respuestas son vagas, el modelo de seguridad también lo es.

Fundamentos de seguridad en producción: acceso, secretos y exposición

La primera capa de seguridad no es glamourosa, pero es donde empiezan muchos incidentes evitables. Antes de pensar en problemas a nivel de aplicación, tu equipo debería tener claro que el acceso está controlado, los secretos son manejables y el sistema solo expone lo que pretende exponer.

Identidad y control de acceso

La mayoría de los equipos subestima cuántos problemas empiezan con accesos normales — no con una vulnerabilidad desconocida ni con un ataque sofisticado, sino con una cuenta que ya no debería existir, un privilegio que nunca se revisó o una autenticación reforzada que faltaba en el momento equivocado.

El principio es sencillo: solo las personas correctas deberían tener acceso, solo a lo que necesitan, y de una forma que pueda atribuirse y revocarse.

Eso implica más que métodos de login más fuertes. Un entorno de producción seguro no debería depender de cuentas compartidas, excepciones puntuales ni conocimiento informal sobre quién tiene acceso a qué. El acceso administrativo debería ser personal y revisable, el modelo de permisos debería seguir el principio de mínimo privilegio (no el de la conveniencia) y la baja de accesos debería formar parte de la operación normal.

En equipos medianos aparece rápido otro riesgo. El acceso a producción se fragmenta entre infraestructura, repositorios, DNS, correo, monitorización, CI/CD y APIs de terceros. Aunque cada cuenta individual esté protegida, el modelo completo se vuelve frágil si nadie puede verlo como un solo sistema.

La prueba importante no es si existe una política de acceso, sino si una revocación real puede hacerse con rapidez y de forma completa. Si esta noche roban el portátil de un desarrollador principal, ¿puede tu equipo retirar en minutos su acceso a todo? Infraestructura, despliegues, logs, proveedores externos. Si la respuesta es "depende de quién esté disponible", el control de acceso es más débil de lo que parece.

Secretos y configuración sensible

Muchos equipos tratan los secretos como si fueran solo otra categoría de configuración. Eso es un error.

Los secretos no son valores normales de ejecución, sino activos de alto impacto con un ciclo de vida propio: pueden filtrarse, copiarse, reutilizarse, rotarse, invalidarse u olvidarse. Un sistema de producción no está listo si solo responde a "¿dónde guardamos los secretos?". También tiene que responder a "¿qué pasa cuando uno se expone?".

El objetivo es que los secretos estén separados del código, limitados en alcance, protegidos durante la operación y reemplazable sin pánico.

Las fugas rara vez parecen dramáticas al principio. Un token aparece en un log. Una credencial queda en un volcado de entorno. Una clave privada se copia en una nota de despliegue. Un secreto de integración se reutiliza entre entornos porque una vez fue cómodo. Con el tiempo, el sistema acumula una fragilidad invisible.

Una forma más sólida de pensar en los secretos es hacerlo en términos de duración y alcance. Si un secreto se filtra, lo que importa es cuánto tiempo sigue siendo válido, a qué puede acceder, si puede reemplazarse de forma limpia y si aparece en logs, listados de procesos o informes de fallo.

En un proyecto Django desplegado en AWS o en un VPS, los secretos deberían vivir en variables de entorno o en un gestor dedicado. AWS Secrets Manager o HashiCorp Vault son opciones habituales. Nunca en el repositorio. El archivo .env en local sirve para desarrollo. En producción, los valores deben inyectarse de forma controlada a través del pipeline de despliegue.

La prueba correcta no es "¿usamos un almacén de secretos?". Es "¿podemos rotar una credencial de producción de forma segura y rápida?". Si la respuesta requiere coordinar a tres personas y tocar cuatro servicios a mano, el modelo sigue siendo frágil.

Exposición de red y límites de infraestructura

Una de las formas más simples de reducir el riesgo es exponer menos. Cada puerto público, endpoint, panel administrativo o subdominio olvidado amplía la superficie de ataque.

Los proyectos medianos rara vez necesitan una exposición pública amplia. Pero muchos acaban con servicios internos accesibles desde internet porque fue la forma más rápida de que algo funcionara. Es habitual encontrar un panel de administración de Django sin restricción de IP, un endpoint de debug que quedó activo, un servicio de staging accesible sin VPN o dominios antiguos que siguen apuntando a sistemas en vivo.

El objetivo es claridad: los puntos de entrada públicos deben ser deliberados, los servicios internos deben seguir siendo internos y el acceso administrativo debe estar restringido por IP, por VPN o por ambos.

En infraestructura AWS, los security groups y las VPCs hacen este trabajo. En un VPS, las reglas de firewall (iptables, ufw) y una configuración limpia de Nginx. En ambos casos, la verificación no puede ser solo interna.

Revisar las reglas de firewall previstas no basta. Revisar un diagrama de infraestructura tampoco. La seguridad aquí debe comprobarse desde fuera: verificar qué responde desde una red pública, qué puertos son accesibles, qué dominios siguen resolviendo y qué interfaces exponen más de lo debido.

La verdad de la exposición de red no está dentro del servidor. Es lo que ve un escaneo externo.

Aplicación y runtime: qué se le permite confiar al sistema

Una vez cubiertos los fundamentos, la siguiente pregunta es si el sistema en ejecución se comporta de forma segura. Aquí es donde muchos equipos se centran primero. Pero la seguridad a nivel de aplicación solo funciona bien cuando el modelo operativo que la rodea ya es razonable.

Límites de confianza de la aplicación

La mayoría de los fallos de seguridad en aplicaciones son fallos de límites.

La aplicación confió en una entrada en la que no debería haber confiado. Asumió que un usuario autenticado estaba autorizado para todo. Trató tráfico interno como seguro solo porque venía de la red privada. Expuso detalles internos de error porque nadie revisó la ruta de excepción. Reutilizó datos de producción en un lugar donde nunca deberían haber acabado.

El marco más útil para pensar la seguridad de la aplicación no es una lista de nombres de vulnerabilidades. Es un mapa de límites de confianza.

La entrada del usuario, los archivos importados y las peticiones del navegador deben tratarse como no confiables. Las peticiones de servicios internos también deben evaluarse según lo que realmente pueden hacer, porque autenticación no es lo mismo que autorización, e "interno al sistema" no es lo mismo que seguro.

Esto importa especialmente en sistemas que crecen por iteración. Una ruta empieza como una comodidad interna y después pasa a formar parte de un flujo sensible. Un proceso en segundo plano recibe más permisos de los previstos porque era más fácil. Un modelo de roles se vuelve inconsistente con el tiempo.

En un proyecto Django, esto se traduce en medidas concretas: validación estricta de formularios y serializers, permisos por vista (no solo por login), protección CSRF activa y rutas de error que no revelen stack traces ni configuración. El DEBUG = True que todo el mundo usa en desarrollo debe estar en False en producción. Parece obvio, pero sigue apareciendo en auditorías reales.

Los fallos de producción también entran aquí. Las rutas de error no deberían revelar detalles de implementación ni contexto sensible. La aplicación debería fallar de forma segura para los usuarios y de forma útil para quienes la operan. Ahí es donde una herramienta como Sentry aporta valor real: captura el contexto completo del error sin exponerlo al usuario final.

La comprobación es directa: ¿puede un usuario inesperado, una petición, un archivo o un llamador interno cruzar un límite que tu equipo da por protegido? Si eso no se ha probado de forma deliberada, los límites son más débiles de lo esperado.

Runtime, cadena de suministro y comportamiento público

La seguridad no termina en la lógica de la aplicación. Lo que se ejecuta en producción, cómo se ejecuta, de dónde viene y lo que ve el exterior afectan al perfil real de riesgo.

El objetivo es mantener el entorno de ejecución comprensible, controlado y limitado en privilegios: los servicios no deberían ejecutarse con más permisos de los necesarios, los artefactos de producción deberían poder trazarse hasta un cambio controlado y las dependencias no deberían acumularse sin revisión.

Aquí es frecuente que los equipos confundan estable con seguro. Componentes que no se han revisado en mucho tiempo pueden seguir funcionando, pero también tienden a volverse opacos: nadie sabe exactamente qué versiones están en producción, nadie quiere tocar el árbol de dependencias y nadie confía en el impacto de una actualización necesaria.

En un proyecto Django con Python, el requirements.txt o pyproject.toml debería estar auditado periódicamente. Herramientas como pip-audit o Dependabot revisan vulnerabilidades conocidas en tus dependencias de forma automática. En una app Flutter, las dependencias de pub.dev merecen la misma atención.

El mismo problema aparece en la capa pública. Tu equipo configura la aplicación de una forma y asume que el protocolo de transporte, las redirecciones, las cookies y las cabeceras se comportan en consecuencia. Pero nunca verifica la respuesta pública. Sobre el papel, todo parece correcto. En la práctica, el endpoint público puede contar una historia distinta.

El estándar práctico es claro. Tu equipo debería poder relacionar un artefacto de producción con un cambio controlado, identificar qué dependencias están en uso y detectar un comportamiento anómalo antes de que los usuarios lo reporten. Y las respuestas públicas deberían coincidir con las garantías que crees estar ofreciendo.

La configuración segura no es la que existe en el repositorio. Es la que el mundo exterior puede observar.

Resiliencia operativa: cómo el equipo cambia y recupera el sistema

Un sistema puede tener controles sólidos y seguir siendo frágil. La seguridad en producción no consiste solo en evitar malos resultados. También consiste en cambiar el sistema con seguridad, detectar problemas pronto y recuperarse de forma controlada.

Seguridad en despliegues y operación

Muchos incidentes de producción los introduce el propio equipo — no por negligencia, sino por cambios normales hechos bajo presión: un despliegue precipitado, una corrección manual no revisada, un rollback que en realidad no restaura el estado anterior o un comando de emergencia que resuelve un problema mientras crea otro.

El objetivo es que el cambio en producción sea predecible, atribuible y reversible. Un sistema es más seguro cuando los despliegues siguen un camino controlado, cuando las acciones de emergencia tienen reglas claras y cuando la recuperación no depende de improvisar.

Esto importa porque los atajos operativos acumulan riesgo oculto. Los equipos suelen creer que tienen un proceso de despliegue fiable, pero en la práctica tienen dos o tres: el documentado, el no oficial y el que alguien usa cuando todo va mal. Así la configuración se desvía del estado esperado, se pierden secretos y producción acaba en un estado que nadie puede explicar del todo.

Un modelo más fuerte define tres cosas: una forma normal de cambiar producción (el pipeline de CI/CD), una alternativa limitada cuando esa vía no está disponible y un punto claro en el que un incidente deja de ser "probar cosas" y pasa a ser un escenario de recuperación.

Si la vía principal de despliegue no funciona, ¿puede tu equipo recuperar el sistema sin hacerlo menos fiable? Si la respuesta depende de comandos no documentados o de que una persona recuerde la secuencia correcta bajo presión, la seguridad operativa es más débil de lo que parece.

Copias de seguridad, recuperación, RTO y RPO

Muchos equipos se tranquilizan en cuanto existen copias de seguridad. Esa tranquilidad suele ser prematura.

El objetivo no es tener archivos de backup, sino poder restaurar servicio y datos dentro de límites aceptables cuando algo falla.

Ahí es donde los objetivos de recuperación se vuelven útiles. El RTO (Recovery Time Objective) define cuánto tiempo puede estar caído el sistema antes de que el daño sea serio. El RPO (Recovery Point Objective) define cuántos datos recientes pueden perderse. Esas no son preguntas abstractas. Determinan si estás planificando un reinicio de servicio, una restauración de base de datos o la pérdida completa del host.

Aquí muchos equipos descubren la diferencia entre administrar backups y estar preparados para recuperar. Un job puede ejecutarse cada hora y no servir a la necesidad del negocio porque los puntos de restauración reales son más gruesos. Puede existir una política de retención y no conservar el punto que importa. Un archivo puede parecer sano y no restaurar nada útil.

La señal real de madurez no es la frecuencia del backup, sino la confianza en la restauración.

Esa confianza viene de un proceso de recuperación que existe fuera de la cabeza de las personas. Si esta noche tu equipo tuviera que restaurar una base de datos de producción, debería saber qué escenario aplica, qué artefactos necesita y cómo se valida el éxito. "Algo se ha roto" no es un único incidente. Reiniciar un servicio, corregir una corrupción lógica y recuperarse de la pérdida total de infraestructura son eventos distintos con caminos distintos.

Por eso un runbook de restauración importa. No como documentación de relleno, sino como una secuencia práctica que alguien pueda ejecutar bajo presión. La recuperación no debería depender de reconstruir decisiones a partir de mensajes viejos mientras la aplicación no está operativa.

La prueba es simple: cuándo fue la última prueba realista de restauración, cuánto tardó y si las credenciales y artefactos necesarios estaban disponibles fuera de los sistemas afectados. Si la respuesta es "nunca lo hemos probado de extremo a extremo", los backups todavía no son fiables.

Monitorización y detección de incidentes

Un sistema de producción sin monitorización va con retraso. Se entera de los problemas más tarde que los usuarios o cuando el incidente ya se ha vuelto caro.

El objetivo no es la máxima observabilidad, sino una monitorización útil.

Los equipos suelen recopilar demasiado y detectar poco. Acumulan logs, métricas, trazas, dashboards y reglas de alerta hasta que el sistema se vuelve lo bastante ruidoso como para forzar a todo el mundo a ignorarlo. Cuando eso ocurre, existe monitorización, pero no preparación real.

Un entorno de producción seguro debería poder confirmar rapidamente si el sistema está disponible, si está funcionando correctamente, si se está degradando y si ha cambiado algo que no debería haber cambiado. Los eventos relevantes para seguridad deben ser visibles y accesibles para investigarlos.

Eso incluye tanto fallos técnicos como comportamientos relevantes para seguridad: fallos repetidos de autenticación, acciones administrativas inusuales, errores de backup, problemas de despliegue, cambios extraños de tráfico o cambios de privilegios. No son simples detalles operativos, sino parte de la postura de seguridad del sistema.

Pero la relación señal-ruido importa más de lo que muchos equipos admiten. Una alerta debería significar que alguien quizá tenga que actuar. Si las alertas de seguridad acaban en una carpeta que nadie revisa, el sistema no funciona.

Según las prácticas documentadas en el Google SRE Book, las alertas deben requerir acciones, no solamente ser informativas. Una alerta que no requiere acción inmediata debería ser un ticket o una entrada en un dashboard, no una alerta.

La comprobación correcta no es si existen alertas. Es si el equipo confía en ellas y si los primeros minutos de un incidente están lo bastante estructurados como para convertir la señal en la acción requerida.

Obligaciones sobre los datos: más allá del uptime

Los equipos técnicos suelen tratar esta parte como algo separado de la ingeniería, pero no lo es.

El objetivo es asegurarse de que el sistema puede asumir las obligaciones reales asociadas a los datos que almacena, procesa y exporta. Para un equipo técnico, la forma más útil de pensarlo no es con lenguaje de cumplimiento normativo, sino como capacidad de ciclo de vida de los datos.

Tu sistema debería poder identificar dónde viven los datos de cada usuario, borrarlos mediante un proceso operativo razonable y exportarlos sin cirugía manual sobre la base de datos. Los periodos de retención para registros de negocio, logs y copias de seguridad deberían estar definidos. Y los terceros que procesan datos deberían estar identificados y revisados.

Muchos fallos legales y de privacidad son fallos de ingeniería. El sistema no puede borrar limpiamente a un usuario porque los datos se dispersaron en demasiados sitios. La política de backups conserva datos más tiempo del previsto porque nadie modeló la retención. Una exportación de soporte contiene más de lo debido porque nunca se aclararon los límites. Un proveedor externo procesa datos bajo supuestos que nadie documentó.

En un proyecto Django, la capacidad de borrado y exportación debería ser una funcionalidad del sistema, no un script que alguien ejecuta a mano cuando llega una solicitud. El RGPD no es opcional si tienes usuarios europeos, y cumplirlo desde el diseño del producto es más barato que retroadaptarlo después.

Tu equipo no necesita ser experto en derecho para mejorar este punto. Necesita suficiente claridad para saber qué debe ser capaz de hacer el sistema con los datos que retiene. Ese es un requisito técnico, no solo legal.

Antes del go-live: qué debería cumplirse

Antes de salir a producción, tu equipo no debería depender del optimismo, del conocimiento local ni de la esperanza de que nada raro ocurra al principio.

La base debería verse ya en la forma en que se opera el sistema. Los accesos pueden revocarse rápido, los secretos pueden rotarse sin pánico, la exposición pública es deliberada y verificable desde fuera. La aplicación hace cumplir sus límites de confianza incluso cuando las peticiones vienen desde dentro. El comportamiento público coincide con las suposiciones sobre transporte, redirecciones, cabeceras y cookies.

El mismo estándar se aplica a la operación. Los cambios en producción siguen un camino controlado y el fallo de ese camino no obliga al equipo a improvisar. Las expectativas de recuperación se entienden en términos prácticos: cuántos datos podrían perderse, cuánto tardaría la restauración y qué hace falta para ejecutarla. El fallo de los backups se detecta antes de que haga falta restaurar. Las alertas son lo bastante creíbles como para actuar sobre ellas. El borrado, la exportación y la retención de datos existen como capacidades del sistema.

Si esas condiciones todavía no se cumplen, el problema no es que el sistema haya suspendido un checklist formal. El problema es que los supuestos de producción siguen ocupando el lugar de las garantías de producción.

Seguridad en producción: una base, no una insignia

La forma más fácil de hacer que la seguridad en producción parezca completa es nombrar muchas configuraciones. La forma más difícil —y más útil— es definir las garantías que el sistema debe ofrecer y verificarlas a medida que evoluciona.

Ese es el enfoque que necesitan los proyectos medianos. No teatro corporativo. No culto a las herramientas. No una colección de ajustes que resultan tranquilizadores en documentos internos pero en la realidad se comporten de otra forma.

Una base de seguridad en producción es mucho más práctica que eso: el acceso está controlado, los secretos son manejables, la exposición es intencional, la aplicación hace cumplir sus límites, el entorno de ejecución es comprensible, los cambios están controlados, los backups realmente restauran, las alertas significan algo y las obligaciones sobre datos se reflejan en el comportamiento del sistema.

La implementación variará de un proyecto a otro, pero las garantías no deberían hacerlo. Y los supuestos, en producción, tienen una esperanza de vida muy corta.

Checklist de seguridad en producción

Esta lista está pensada para revisarse en cada proyecto antes del go-live y periódicamente después. Cada punto debería poder verificarse con un sí o un no. Si la respuesta es "no" o "no lo sé", ese punto necesita atención. Algunos puntos están pensados para el stack de Mecexis y/o pueden ser opcionales según el proyecto, pero seguro que los puedes trasladar fácilmente a las particularidades de tus técnologias, entorno y equipo.

Acceso e identidad

• Todo acceso administrativo a producción es personal y nominativo (no hay cuentas compartidas ni genéricas).
• Cada persona tiene activada la autenticación en dos pasos (2FA) en todos los servicios de producción.
• Los permisos siguen el principio de mínimo privilegio: nadie tiene más acceso del que necesita para su trabajo.
• La baja de accesos forma parte del proceso de offboarding (cuando alguien deja el equipo o el proyecto, se retira su acceso el mismo día).
• Una revocación completa de acceso (infraestructura, repositorios, DNS, CI/CD, servicios de terceros) puede hacerse en menos de una hora.
• Existe un inventario actualizado de todos los accesos a producción, incluyendo quién tiene acceso a qué y con qué nivel de permisos.
• Los accesos se revisan periodicamente para detectar cuentas obsoletas o permisos excesivos.
• Las claves SSH de producción están asociadas a personas concretas y se rotan periódicamente.

Secretos y credenciales

• Ningún secreto (tokens, claves API, contraseñas, claves privadas) está en el código fuente ni en el historial de git.
• Los secretos de producción viven en variables de entorno o en un gestor dedicado (AWS Secrets Manager, HashiCorp Vault u otro equivalente).
• Ningún secreto aparece en logs, volcados de entorno, informes de fallo ni mensajes de error.
• Los secretos de producción y los de staging/desarrollo son diferentes (no se reutilizan entre entornos).
• Toda credencial de producción puede rotarse de forma rápida sin necesidad de un despliegue de emergencia.
• Cada secreto tiene un alcance limitado: accede solo al recurso que necesita, con los permisos mínimos.
• Existe un proceso documentado para actuar cuando un secreto se expone (rotación, notificación, verificación de impacto).
• El archivo .env o equivalente está en el .gitignore y nunca se sube al repositorio.

Exposición de red e infraestructura

• Los puntos de entrada públicos (dominios, puertos, endpoints) son deliberados, documentados y revisados.
• Los servicios internos (bases de datos, colas, caches) no son accesibles desde internet.
• El panel de administración de Django (o equivalente) está restringido por IP, VPN o ambos.
• Los puertos abiertos en servidores de producción están justificados y documentados (solo HTTP/HTTPS y SSH como mínimo).
• No hay dominios antiguos, subdominios de prueba ni registros DNS apuntando a sistemas en vivo sin revisar.
• Los entornos de staging y desarrollo no son accesibles públicamente sin autenticación.
• La configuración de firewall (security groups en AWS, iptables/ufw en VPS) se ha verificado con un escaneo externo.
• El certificado SSL/TLS está configurado correctamente y se renueva automáticamente.
• Las redirecciones HTTP → HTTPS están activas en todos los dominios de producción.

Aplicación y código

• La entrada del usuario se valida y sanitiza en todas las rutas de la aplicación (formularios, API, uploads).
• Autenticación y autorización son controles separados: estar logueado no significa tener permiso para todo.
• Las rutas de error no revelan stack traces, configuración interna, rutas del servidor ni datos sensibles.
• DEBUG = False en producción (verificado, no solo asumido).
• La protección CSRF está activa en todos los formularios y endpoints que modifican datos.
• Las cabeceras de seguridad están configuradas: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security.
• Los uploads de archivos están validados por tipo y tamaño, y se almacenan fuera del directorio web público.
• Las dependencias de Python (requirements.txt o pyproject.toml) se auditan periódicamente con pip-audit, Dependabot o equivalente.
• Las dependencias de Flutter (pubspec.yaml) también se revisan para vulnerabilidades conocidas.
• Los artefactos desplegados en producción pueden trazarse hasta un commit concreto en el repositorio.
• No hay endpoints de debug, test o desarrollo accesibles en producción.

Despliegues y operación

• Los despliegues a producción siguen un camino controlado y reproducible a través del pipeline de CI/CD.
• El pipeline ejecuta tests automáticos antes de cada despliegue (ningún código llega a producción sin pasar los tests).
• Existe una alternativa documentada para desplegar si el pipeline principal no está disponible.
• Todo cambio en producción es atribuible: quién lo hizo, cuándo y qué cambió.
• El rollback a la versión anterior funciona y se ha probado al menos una vez.
• Los despliegues no requieren acceso SSH directo al servidor en condiciones normales.
• Los cambios de configuración en producción (variables de entorno, DNS, reglas de firewall) también se registran y son trazables.
• Existe un criterio claro para distinguir cuándo un incidente se resuelve con un fix rápido y cuándo requiere un rollback.

Backups y recuperación

• Los backups de base de datos se ejecutan automáticamente con la frecuencia que el negocio necesita (RPO definido y documentado).
• El tiempo máximo aceptable de caída del sistema está definido (RTO documentado).
• Los backups se almacenan en una ubicación separada del servidor de producción (otra región de AWS, otro proveedor o almacenamiento externo).
• La integridad de los backups se verifica automáticamente (no basta con que el job diga "OK").
• La última prueba real de restauración fue en los últimos tres meses y fue exitosa.
• Las credenciales y artefactos necesarios para restaurar están disponibles fuera de los sistemas afectados (si se pierde el servidor, se puede restaurar igualmente).
• Existe un runbook de restauración con pasos concretos que cualquier miembro del equipo puede seguir bajo presión.
• Los backups cubren no solo la base de datos, sino también archivos subidos por usuarios, configuración y cualquier dato que no esté en el repositorio.
• Se ha verificado que el backup y la restauración cumplen con los tiempos definidos en RTO y RPO.

Monitorización y alertas

• Existe un healthcheck automático que verifica la disponibilidad de la aplicación al menos cada minuto.
• Se monitorizan las métricas básicas: disponibilidad, tasa de errores y saturación de recursos.
• Los errores de aplicación se capturan automáticamente con Sentry o equivalente, con contexto suficiente para diagnosticarlos.
• Las alertas van ligadas a acciones: cada una tiene una respuesta esperada y documentada.
• Existen al menos dos niveles de alerta: urgente (notificación inmediata) e informativo (revisión en horario laboral).
• La relación señal-ruido es suficiente para que el equipo confíe en las alertas y actúe cuando saltan.
• Los eventos relevantes para seguridad son visibles: fallos repetidos de autenticación, acciones administrativas inusuales, cambios de privilegios y errores de backup.
• Los logs están centralizados y son consultables sin necesidad de conectarse por SSH a cada servidor.
• Los primeros minutos de un incidente están estructurados: quién investiga, dónde se mira primero y cómo se escala.

Datos, privacidad y obligaciones legales

• El sistema puede identificar dónde viven los datos de cada usuario (base de datos, archivos, logs, backups, servicios de terceros).
• Existe un proceso operativo para borrar los datos de un usuario bajo petición, dentro de los plazos que exige el RGPD.
• La exportación de datos de usuario no requiere cirugía manual sobre la base de datos.
• Los periodos de retención están definidos para datos de negocio, logs de aplicación, logs de acceso y backups.
• Los datos de producción no se copian a entornos de desarrollo o staging sin anonimizar.
• Los terceros que procesan datos de usuarios (pasarelas de pago, servicios de email, analytics, proveedores de infraestructura) están identificados y documentados.
• Existe una política de cookies implementada y verificada en todos los dominios públicos.
• Los formularios que recogen datos personales informan al usuario de cómo se tratarán esos datos.