Cómo retirar una aplicación autoalojada preservando los datos y eliminando las vías de acceso

El retiro de una aplicación es un proyecto de gobernanza de datos, no una tarea de servidor

Para retirar una aplicación autoalojada de forma segura, trate el trabajo como un retiro controlado de registros, flujos de trabajo, identidades e infraestructura. Detener un contenedor o eliminar un servidor virtual puede finalizar el servicio visible, pero no responde a las preguntas importantes: qué registros deben seguir disponibles, quién puede acceder todavía a ellos, qué otros sistemas siguen dependiendo de la aplicación y cuándo deben eliminarse las copias retenidas.

Un plan de retiro sólido diferencia tres resultados que suelen confundirse. Una exportación es una representación utilizable de los registros para las personas o para un sistema de sustitución. Una copia de seguridad de recuperación es una copia destinada a restaurar la aplicación tras un fallo. Una decisión de retención determina qué información debe conservarse, con qué propósito, bajo qué controles y durante cuánto tiempo. En ocasiones, un mismo artefacto puede servir para más de un propósito, pero no debe asumirse que sea así.

Designe a una persona responsable de la aplicación e involucre a quienes sean responsables de operaciones, registros, seguridad, finanzas y procesos empresariales. Si la aplicación contiene información personal, financiera, contractual o regulada, obtenga la orientación jurídica, de privacidad o de gestión documental adecuada para su organización antes de destruirla.

• Establezca un objetivo de retiro por escrito y una fecha objetivo.
• Designe responsables de las decisiones sobre datos, de la ejecución técnica y de la aprobación final.
• Registre el motivo del retiro, la sustitución o la consolidación.
• Defina el éxito tanto como disponibilidad de los registros como eliminación de accesos innecesarios, y no simplemente como un servidor desconectado.

Elija el estado de retiro antes de planificar el cierre

No todas las aplicaciones deben pasar directamente de producción a la eliminación. Seleccione primero el estado final previsto, porque determina cómo migrará los datos, se comunicará con los usuarios y eliminará los accesos.

Una migración a un sistema de sustitución es adecuada cuando otro sistema asumirá el trabajo activo. El modo de solo archivo es adecuado cuando los registros pueden ser necesarios, pero no debe realizarse trabajo nuevo. El cierre completo solo es adecuado cuando los registros se han gestionado conforme a la decisión de retención aprobada y se han eliminado las dependencias. Estos estados pueden organizarse por fases: producción, archivo de solo lectura y, después, retiro completo.

No utilice el modo de solo lectura como un aplazamiento impreciso. Defina quién puede acceder, qué registros puede consultar, cómo se aprueba el acceso, si las integraciones están desactivadas, cuánto tiempo existirá el archivo y qué evento autoriza su eliminación final.

• Sustitución: migre los registros activos, confirme la titularidad en el nuevo sistema y establezca una fecha clara de transición.
• Solo archivo: impida cambios, minimice el acceso de los usuarios y conserve únicamente la infraestructura necesaria para la recuperación aprobada.
• Cierre completo: elimine el enrutamiento público, detenga los servicios, revoque las credenciales y deseche la infraestructura solo después de verificarlo.
• Pause el retiro completo cuando retenciones legales, obligaciones de auditoría, brechas de migración sin resolver o posibles reclamaciones legales requieran una conservación continuada.

Elabore un inventario que siga a la aplicación más allá de su contenedor principal

Comience con un inventario que otra persona pueda utilizar para entender la aplicación después de que el administrador original se haya ido. Incluya el propósito empresarial, la persona responsable, los usuarios, las categorías de datos, la ubicación de alojamiento, los dominios, el sistema de sustitución y la decisión de retiro.

En implementaciones basadas en Docker, inventaríe el almacenamiento persistente por separado de los contenedores. Los volúmenes de Docker (https://docs.docker.com/engine/storage/volumes/) son almacenes de datos persistentes y pueden permanecer después de eliminar un contenedor. Eliminar un contenedor de servicio detenido no equivale a exportar datos: los datos fuera de un volumen pueden perderse al eliminar contenedores. Identifique los volúmenes con nombre y los volúmenes anónimos, ya que el almacenamiento anónimo puede eliminarse durante la limpieza de contenedores.

Conserve la definición de despliegue antes de modificarla. Los archivos Compose pueden definir servicios, redes, volúmenes y configuración relacionada. Identifique también la configuración de Compose específica de producción, que Docker recomienda para parámetros como las variables de entorno, las políticas de reinicio y servicios adicionales como el registro de eventos. Capture la configuración de forma segura y no copie secretos en documentos ampliamente accesibles. La guía de Docker Compose para producción (https://docs.docker.com/compose/how-tos/production/) explica esta separación.

• Bases de datos, volúmenes con nombre, volúmenes anónimos, directorios montados mediante bind y archivos cargados.
• Archivos Compose, archivos de entorno, notas de despliegue, referencias de imágenes, redes y configuración de proxy inverso.
• Dominios, subdominios, registros DNS, certificados TLS y rutas públicas.
• Tareas programadas, procesos de trabajo, colas, tareas de informes y destinos de registros.
• Configuración de correo electrónico entrante y saliente, proveedores de pago, webhooks, API, proveedores de identidad y analítica.
• Cuentas de servicio, cuentas de administrador, grupos de usuarios, tokens de API, acceso SSH y acceso de emergencia.
• Suscripciones de proveedores, recursos en la nube, ubicaciones de almacenamiento y responsables de facturación.

Clasifique los registros antes de decidir qué exportar, conservar o eliminar

Cree un registro de disposición de datos en lugar de tomar decisiones improvisadas durante el cierre. Para cada conjunto de registros, documente su propósito, responsable de negocio, sensibilidad, fundamento de retención, destino aprobado, método de recuperación, controles de acceso y desencadenante de eliminación. Separe los registros operativos de los artefactos del sistema: los archivos de clientes, facturas, evidencias de auditoría y documentos firmados pueden requerir un tratamiento diferente de los datos de caché, las cargas temporales y los registros de eventos.

Para las organizaciones sujetas al RGPD, el principio de limitación del plazo de conservación implica que los datos personales no deben conservarse más tiempo del necesario para el propósito de su recopilación. Eso no significa que la eliminación inmediata sea siempre correcta. La retención puede ser necesaria por motivos como obligaciones legales o la formulación, el ejercicio o la defensa de reclamaciones legales. Consulte la guía de principios del RGPD de la Comisión Europea (https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) y el artículo 17 del RGPD (https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04). La orientación sobre el RGPD no constituye un calendario de retención completo y no debe interpretarse como asesoramiento jurídico: los requisitos sectoriales, contractuales y específicos de cada jurisdicción pueden variar.

Los archivos retenidos requieren salvaguardas. Conforme a los principios del RGPD, la integridad y confidencialidad exigen medidas técnicas y organizativas adecuadas contra el tratamiento no autorizado o ilícito y contra la pérdida, destrucción o daño accidentales. Limite el acceso al archivo a las personas que lo necesiten y registre quién aprueba cada recuperación.

• Conservar: registros aprobados con un propósito, responsable, periodo de retención y método de acceso identificados.
• Exportar: registros necesarios para una sustitución operativa, auditoría, atención al cliente o evidencia futura.
• Eliminar: datos sin un propósito de retención aprobado una vez verificadas las retenciones y dependencias.
• Documentar: decisiones, personas aprobadoras, ubicaciones de archivo, fechas de eliminación y excepciones.

Valide las exportaciones como registros utilizables, no solo como descargas correctas

Una exportación solo es útil si la organización puede identificarla, abrirla, interpretarla y relacionarla posteriormente con los registros originales. Un volcado de base de datos o un archivo de volumen puede ser valioso para la recuperación, pero no resultar adecuado para un equipo de finanzas, soporte o jurídico que necesite una factura, historial de cliente o documento concreto sin reconstruir toda la aplicación.

Para cada exportación, documente el alcance, la hora de corte, la aplicación de origen, el formato, la codificación, los recuentos de registros cuando sean significativos, el tratamiento de adjuntos, las definiciones de campos y la persona responsable. Incluya suficiente contexto para interpretar identificadores, valores de estado y marcas de tiempo. Conserve los manifiestos de exportación junto con el archivo, no solo en las notas de un administrador que se marcha.

Pruebe con preguntas de recuperación realistas. Pida a la persona responsable de los registros designada que encuentre un conjunto representativo de registros, abra los archivos asociados, confirme los campos importantes y compare los resultados con la aplicación activa antes del cierre. Si hay una migración implicada, concilie el origen y el destino y resuelva las excepciones antes de la transición final.

• ¿Puede una persona autorizada que no sea administradora localizar y leer posteriormente un registro?
• ¿Se incluyen los archivos adjuntos y documentos cargados y están vinculados correctamente?
• ¿Las exportaciones incluyen las relaciones, identificadores y marcas de tiempo requeridos?
• ¿Están documentados el formato y cualquier software necesario?
• ¿Se conoce a la persona responsable del archivo y se ha probado el acceso de recuperación?
• ¿Se ha conciliado una muestra representativa con el origen?

Asigne y desactive todas las dependencias externas

Una aplicación retirada aún puede enviar correo electrónico, aceptar solicitudes, activar automatizaciones o generar cargos de terceros si sus dependencias siguen activas. Elabore un mapa de dependencias que muestre la dirección: qué llama a la aplicación, qué llama la aplicación hacia fuera y qué se ejecuta de forma programada sin intervención de un usuario.

Revise cuidadosamente la configuración de ejecución. Trate los secretos por separado de los ajustes ordinarios. Identifique los valores sensibles en la configuración de la aplicación, del host y del despliegue, y luego revóquelos o rótelos en vez de depender únicamente de la eliminación de infraestructura.

Desactive las dependencias en un orden deliberado. Antes de detener productores programados o webhooks entrantes, establezca una ventana de corte aprobada, comuníquela a los emisores y defina cómo se tratarán los eventos legítimos durante la transición. Cuando proceda, mantenga una cola, un mecanismo de reintento o una captura alternativa para esos eventos. Tome la instantánea final de datos una vez controlada la entrada y, después, concilie los eventos recibidos, en cola o capturados con la exportación final. Luego revoque las credenciales salientes y desactive los consumidores que esperan que la aplicación responda. Mantenga un registro de cada cambio y de su resultado de verificación.

• Endpoints de webhook y secretos de firma.
• Claves de API, clientes OAuth y tokens de integración.
• Credenciales SMTP, reglas de reenvío de correo y rutas de correo entrante.
• Aplicaciones de proveedores de identidad, conexiones SSO y reglas de aprovisionamiento.
• Claves de servicios de pago, URL de devolución de llamada y dependencias de suscripciones.
• Tareas programadas, colas, trabajadores, tareas cron y automatización externa.
• Ventana de corte aprobada, notificación a emisores, mecanismo de cola, reintento o captura alternativa cuando proceda, y conciliación posterior.
• Destinos de monitorización, alertas, registros y exportación de datos.

Elimine el acceso por capas: personas, máquinas y rutas públicas

Eliminar cuentas de usuario dentro de la aplicación es necesario, pero no suficiente. El acceso puede persistir mediante credenciales de administrador, contraseñas compartidas, tokens de API, cuentas de servicio, claves SSH, sesiones de proveedores de identidad, autenticación de proxy inverso y cuentas de emergencia. Elabore un registro de accesos y asigne a una persona responsable de confirmar que cada vía se ha eliminado o se conserva intencionadamente para el acceso al archivo.

Planifique cuidadosamente el orden. Conserve una vía de acceso de emergencia estrictamente controlada hasta que las exportaciones, copias de recuperación y verificaciones estén completas. No la deje sin documentar ni compartida. Una vez obtenida la aprobación, revoque la última vía administrativa y registre la hora, la persona que actuó y las pruebas.

Si Traefik forma parte del despliegue, revise los routers como parte de la eliminación de la exposición pública. Un router HTTP (https://doc.traefik.io/traefik/reference/routing-configuration/http/routing/router/) coincide con solicitudes entrantes y las reenvía a un servicio. Si la API o el panel de Traefik están habilitados y la configuración pertinente es accesible, pueden ayudar a enumerar routers, servicios, middlewares, puntos de entrada y relaciones. La documentación de la API y el panel de Traefik (https://doc.traefik.io/traefik/operations/dashboard/) advierte contra la exposición pública en producción; restrínjalos a administradores autorizados y redes internas.

• Desactive las cuentas de usuario y elimine los roles privilegiados.
• Revoque o rote las contraseñas de administrador, los tokens de API y las credenciales de cuentas de servicio.
• Elimine las asignaciones de SSO y grupos de directorio; verifique el comportamiento de desaprovisionamiento.
• Elimine las claves SSH, el acceso a la consola del servidor y los secretos compartidos.
• Desactive las rutas de proxy y la configuración de autenticación que ya no sean necesarias.
• Conserve únicamente el acceso a archivos aprobado y con plazo definido hasta el retiro final.

Cierre la carga de trabajo, elimine la exposición DNS y verifique el retiro

Realice el cierre final solo después de completar el trabajo aprobado de exportación, archivo y dependencias. Detenga la carga de trabajo de la aplicación y los trabajadores, programadores y servicios de soporte asociados que ya no sean necesarios. Antes de declarar el retiro como completo, desactive el comportamiento de reinicio en la definición de despliegue de producción y también en el entorno en ejecución. Docker Compose admite políticas de reinicio como `always`, `on-failure` y `unless-stopped`; de otro modo, un servicio detenido puede volver tras reiniciar el host o el servicio. Consulte la referencia de servicios de Docker Compose (https://docs.docker.com/reference/compose-file/services/).

Trate los dominios y el DNS como una tarea de transición explícita. Enumere cada nombre de host, tipo de registro y ruta pública que alcance la aplicación, incluidos los subdominios utilizados para webhooks, API o servicios relacionados con el correo. Para cada nombre de host, decida si elimina o cambia el registro DNS, o si lo conserva para un destino de archivo restringido. Si necesita redirigir a los usuarios a un sustituto aprobado, configure esa redirección HTTP o URL en un servidor web, proxy inverso o servicio de redirección que permanezca bajo control. Registre el destino previsto y la persona responsable antes de cambiar el DNS o la ruta.

Tenga en cuenta el TTL de DNS y el comportamiento de propagación aplicable a los registros que cambie. Después de la ventana de cambios prevista, pruebe cada antiguo nombre de host desde las redes pertinentes y confirme que ya no resuelve ni enruta hacia la aplicación retirada, salvo el destino de archivo restringido aprobado. Pruebe también cualquier redirección configurada y el destino de sustitución aprobado. Revise la configuración del proxy inverso y, cuando corresponda, los routers y servicios de Traefik, para que una ruta obsoleta no siga reenviando solicitudes a la carga de trabajo.

Capture evidencias de verificación antes de desechar la infraestructura. Estas pueden incluir el estado de servicio detenido, la configuración de reinicio desactivada, los resultados de pruebas de DNS y rutas, las confirmaciones de desactivación de dependencias, los registros de revocación de acceso y la aceptación del archivo. Conserve las evidencias junto con el registro de retiro para que el estado final pueda entenderse y auditarse posteriormente.

• Detenga la aplicación, los trabajadores, las colas y los servicios programados que ya no estén aprobados.
• Desactive el comportamiento de reinicio de Compose u otra carga de trabajo antes de la aprobación final.
• Elimine o cambie cada registro DNS aprobado; configure las redirecciones HTTP o URL por separado en una capa que siga controlada.
• Elimine o restrinja cada ruta pública aprobada.
• Verifique que los antiguos nombres de host ya no alcanzan la aplicación tras la ventana de cambio DNS prevista.
• Confirme que cualquier redirección, destino de sustitución o ruta de archivo se comporta según lo previsto.
• Registre la hora del cierre, la persona ejecutora, las pruebas realizadas, los resultados y las excepciones.