Comment mettre hors service une application auto-hébergée tout en préservant les données et en supprimant les voies d’accès

Le retrait d’une application est un projet de gouvernance des données, pas une tâche serveur

Pour mettre hors service une application auto-hébergée en toute sécurité, considérez ce travail comme le retrait contrôlé de données, de workflows, d’identités et d’infrastructure. Arrêter un conteneur ou supprimer un serveur virtuel peut mettre fin au service visible, mais cela ne répond pas aux questions importantes : quelles données doivent rester disponibles, qui peut encore y accéder, quels autres systèmes dépendent toujours de l’application et à quel moment les copies conservées doivent être supprimées.

Un plan de retrait solide distingue trois résultats souvent confondus. Un export est une représentation exploitable des données destinée à des personnes ou à un système de remplacement. Une sauvegarde de restauration est une copie destinée à rétablir l’application après une défaillance. Une décision de conservation détermine quelles informations doivent être gardées, dans quel but, sous quels contrôles et pendant combien de temps. Un même artefact peut parfois répondre à plusieurs finalités, mais cela ne doit pas être présumé.

Désignez un responsable métier clairement désigné et impliquez les personnes responsables des opérations, des archives, de la sécurité, de la finance et des processus métier. Si l’application contient des informations personnelles, financières, contractuelles ou réglementées, obtenez les conseils juridiques, relatifs à la confidentialité ou à la gestion des archives appropriés pour votre organisation avant toute destruction.

• Définissez un objectif de retrait écrit et une date cible.
• Nommez un responsable pour les décisions relatives aux données, l’exécution technique et la validation finale.
• Consignez le motif du retrait, du remplacement ou de la consolidation.
• Définissez la réussite comme la disponibilité des données et la suppression des accès inutiles, et non simplement comme un serveur hors ligne.

Choisissez l’état de retrait avant de planifier l’arrêt

Toutes les applications ne doivent pas passer directement de la production à la suppression. Sélectionnez d’abord l’état final visé, car il détermine votre méthode de migration des données, vos communications avec les utilisateurs et votre suppression des accès.

Une migration vers un système de remplacement convient lorsqu’un autre système reprend le travail actif. Le mode archive seule convient lorsque les données peuvent être nécessaires, mais qu’aucun nouveau travail ne doit avoir lieu. L’arrêt complet ne convient que lorsque les données ont été traitées conformément à la décision de conservation approuvée et que les dépendances ont été supprimées. Ces états peuvent être séquencés : production, archive en lecture seule, puis retrait complet.

N’utilisez pas le mode lecture seule comme un report imprécis. Définissez qui peut accéder à l’application, quelles données ces personnes peuvent consulter, comment l’accès est approuvé, si les intégrations sont désactivées, combien de temps l’archive existera et quel événement autorise sa destruction finale.

• Remplacement : migrez les données actives, confirmez leur responsabilité dans le nouveau système et fixez une date de bascule claire.
• Archive seule : empêchez les modifications, réduisez au minimum l’accès des utilisateurs et ne conservez que l’infrastructure nécessaire à la consultation approuvée.
• Arrêt complet : supprimez le routage public, arrêtez les services, révoquez les identifiants et éliminez l’infrastructure uniquement après vérification.
• Suspendez le retrait complet lorsque des obligations de conservation légale, d’audit, des lacunes de migration non résolues ou des réclamations juridiques potentielles exigent une préservation continue.

Établissez un inventaire qui suit l’application au-delà de son conteneur principal

Commencez par un inventaire permettant à une autre personne de comprendre l’application après le départ de l’administrateur d’origine. Incluez l’objectif métier, le responsable, les utilisateurs, les catégories de données, l’emplacement d’hébergement, les domaines, le système de remplacement et la décision de retrait.

Pour les déploiements basés sur Docker, inventoriez le stockage persistant séparément des conteneurs. Les volumes Docker (https://docs.docker.com/engine/storage/volumes/) sont des magasins de données persistants et peuvent demeurer après la suppression d’un conteneur. La suppression d’un conteneur de service arrêté n’est pas un export de données : les données hors d’un volume peuvent être perdues lorsque les conteneurs sont supprimés. Identifiez les volumes nommés et anonymes, car le stockage anonyme peut être supprimé lors du nettoyage des conteneurs.

Préservez la définition du déploiement avant de la modifier. Les fichiers Compose peuvent définir des services, réseaux, volumes et configurations associées. Identifiez également la configuration Compose propre à la production, que Docker recommande pour des paramètres tels que les variables d’environnement, les politiques de redémarrage et les services supplémentaires tels que la journalisation. Capturez la configuration de façon sécurisée et ne copiez pas les secrets dans des documents largement accessibles. Les recommandations Docker Compose pour la production (https://docs.docker.com/compose/how-tos/production/) expliquent cette séparation.

• Bases de données, volumes nommés, volumes anonymes, répertoires montés par liaison et fichiers téléversés.
• Fichiers Compose, fichiers d’environnement, notes de déploiement, références d’images, réseaux et configuration du proxy inverse.
• Domaines, sous-domaines, enregistrements DNS, certificats TLS et points d’accès publics.
• Tâches planifiées, processus workers, files d’attente, tâches de reporting et destinations des journaux.
• Paramètres de messagerie entrante et sortante, prestataires de paiement, webhooks, API, fournisseurs d’identité et outils d’analytique.
• Comptes de service, comptes administrateur, groupes d’utilisateurs, jetons d’API, accès SSH et accès d’urgence ou de type break-glass.
• Abonnements fournisseurs, ressources cloud, emplacements de stockage et responsables de la facturation.

Classez les données avant de décider quoi exporter, conserver ou supprimer

Créez un registre de sort des données plutôt que de prendre des décisions ponctuelles pendant l’arrêt. Pour chaque ensemble de données, documentez son objectif, son responsable métier, sa sensibilité, le fondement de conservation, la destination approuvée, la méthode de consultation, les contrôles d’accès et le déclencheur de suppression. Distinguez les données opérationnelles des artefacts système : les fichiers clients, factures, preuves d’audit et documents signés peuvent nécessiter un traitement différent des données de cache, téléversements temporaires et journaux.

Pour les organisations soumises au RGPD, le principe de limitation de la conservation implique que les données personnelles ne doivent pas être conservées plus longtemps que nécessaire à la finalité de leur collecte. Cela ne signifie pas qu’une suppression immédiate est toujours correcte. La conservation peut être nécessaire, par exemple, pour respecter des obligations légales ou pour la constatation, l’exercice ou la défense de droits en justice. Consultez les orientations de la Commission européenne sur les principes du RGPD (https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) et l’article 17 du RGPD (https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04). Les orientations relatives au RGPD ne constituent pas un calendrier de conservation exhaustif et ne doivent pas être interprétées comme un avis juridique : les exigences sectorielles, contractuelles et propres à chaque juridiction peuvent varier.

Les archives conservées exigent des protections. Selon les principes du RGPD, l’intégrité et la confidentialité requièrent des mesures techniques et organisationnelles appropriées contre le traitement non autorisé ou illicite ainsi que contre la perte, la destruction ou les dommages accidentels. Limitez l’accès aux archives aux personnes qui en ont besoin et consignez qui approuve leur consultation.

• Conserver : les données approuvées disposant d’un objectif identifié, d’un responsable, d’une période de conservation et d’une méthode d’accès.
• Exporter : les données nécessaires à un remplacement opérationnel, à un audit, au service client ou à de futures preuves.
• Supprimer : les données sans objectif de conservation approuvé, une fois les obligations de conservation et dépendances vérifiées.
• Documenter : les décisions, approbateurs, emplacements d’archives, dates de suppression et exceptions.

Validez les exports comme données exploitables, pas seulement comme téléchargements réussis

Un export n’est utile que si l’organisation peut l’identifier, l’ouvrir, l’interpréter et le rattacher ultérieurement aux données d’origine. Un dump de base de données ou une archive de volume peut être utile pour la restauration, tout en étant inadapté à une équipe finance, support ou juridique ayant besoin d’une facture précise, de l’historique d’un client ou d’un document sans reconstruire l’application complète.

Pour chaque export, documentez le périmètre, l’heure de coupure, l’application source, le format, l’encodage, le nombre d’enregistrements lorsque pertinent, le traitement des pièces jointes, les définitions des champs et le responsable désigné. Incluez suffisamment de contexte pour interpréter les identifiants, valeurs d’état et horodatages. Conservez les manifestes d’export avec l’archive, et non uniquement dans les notes d’un administrateur partant.

Testez avec des questions réalistes de consultation. Demandez au responsable désigné des données de retrouver un ensemble représentatif de données, d’ouvrir les fichiers associés, de confirmer les champs importants et de comparer les résultats à l’application active avant l’arrêt. En cas de migration, rapprochez la source et la destination, et résolvez les exceptions avant la bascule finale.

• Une personne autorisée qui n’est pas administratrice peut-elle retrouver et lire une donnée ultérieurement ?
• Les pièces jointes et documents téléversés sont-ils inclus et correctement liés ?
• Les exports comprennent-ils les relations, identifiants et horodatages requis ?
• Le format et tout logiciel nécessaire sont-ils documentés ?
• Le responsable de l’archive est-il connu et l’accès de consultation a-t-il été testé ?
• Un échantillon représentatif a-t-il été rapproché de la source ?

Cartographiez et désactivez chaque dépendance externe

Une application retirée peut encore envoyer des e-mails, accepter des requêtes, déclencher de l’automatisation ou occasionner des frais tiers si ses dépendances restent actives. Établissez une carte des dépendances montrant le sens des flux : ce qui appelle l’application, ce que l’application appelle et ce qui s’exécute selon un planning sans action d’un utilisateur.

Examinez attentivement la configuration d’exécution. Traitez les secrets séparément des paramètres ordinaires. Identifiez les valeurs sensibles dans la configuration de l’application, de l’hôte et du déploiement, puis révoquez-les ou effectuez leur rotation plutôt que de vous fier uniquement à la suppression de l’infrastructure.

Désactivez les dépendances dans un ordre réfléchi. Arrêtez les producteurs planifiés et les webhooks entrants avant de réaliser l’instantané final des données, afin que de nouvelles données n’arrivent pas de manière inattendue. Révoquez ensuite les identifiants sortants et désactivez les consommateurs qui attendent une réponse de l’application. Conservez une trace de chaque modification et de son résultat de vérification.

• Points de terminaison de webhook et secrets de signature.
• Clés API, clients OAuth et jetons d’intégration.
• Identifiants SMTP, règles de transfert d’e-mails et routes de messagerie entrante.
• Applications du fournisseur d’identité, connexions SSO et règles d’approvisionnement.
• Clés de services de paiement, URL de rappel et dépendances d’abonnement.
• Tâches planifiées, files d’attente, workers, tâches cron et automatisation externe.
• Destinations de supervision, d’alerte, de journalisation et d’export de données.

Supprimez les accès par couches : personnes, machines et points d’accès publics

La suppression des comptes utilisateurs dans l’application est nécessaire, mais insuffisante. L’accès peut persister via des identifiants administrateur, mots de passe partagés, jetons API, comptes de service, clés SSH, sessions de fournisseur d’identité, authentification du proxy inverse et comptes d’urgence. Créez un registre des accès et attribuez à un responsable la tâche d’attester que chaque voie a été supprimée ou intentionnellement conservée pour l’accès aux archives.

Planifiez soigneusement l’ordre des opérations. Conservez une voie d’accès d’urgence étroitement contrôlée jusqu’à la fin des exports, copies de restauration et vérifications. Ne la laissez pas non documentée ou partagée. Une fois la validation obtenue, révoquez la dernière voie administrative et consignez l’heure, l’intervenant et les éléments de preuve.

Si Traefik fait partie du déploiement, examinez les routeurs dans le cadre de la suppression de l’exposition publique. Un routeur HTTP (https://doc.traefik.io/traefik/reference/routing-configuration/http/routing/router/) associe les requêtes entrantes et les transmet à un service. Si l’API ou le tableau de bord Traefik est activé et que la configuration pertinente est accessible, il peut aider à recenser les routeurs, services, middlewares, points d’entrée et relations. La documentation de l’API et du tableau de bord Traefik (https://doc.traefik.io/traefik/operations/dashboard/) met en garde contre une exposition publique en production ; restreignez-les aux administrateurs autorisés et aux réseaux internes.

• Désactivez les comptes utilisateurs et supprimez les rôles privilégiés.
• Révoquez ou effectuez la rotation des mots de passe administrateur, jetons API et identifiants de comptes de service.
• Supprimez les attributions SSO et de groupes d’annuaire ; vérifiez le comportement de déprovisionnement.
• Supprimez les clés SSH, l’accès à la console serveur et les secrets partagés.
• Désactivez les règles de proxy et la configuration d’authentification qui ne sont plus nécessaires.
• Ne conservez que l’accès aux archives approuvé et limité dans le temps jusqu’au retrait final.

Arrêtez la charge de travail, supprimez l’exposition DNS et vérifiez le retrait

N’effectuez l’arrêt final qu’une fois les travaux approuvés d’export, d’archivage et de gestion des dépendances terminés. Arrêtez la charge de travail de l’application ainsi que les workers, planificateurs et services de support qui ne sont plus nécessaires. Avant de déclarer le retrait terminé, désactivez le comportement de redémarrage dans la définition de déploiement de production comme dans l’environnement d’exécution. Docker Compose prend en charge des politiques de redémarrage telles que `always`, `on-failure` et `unless-stopped` ; autrement, un service arrêté peut revenir après le redémarrage d’un hôte ou d’un service. Consultez la référence des services Docker Compose (https://docs.docker.com/reference/compose-file/services/).

Traitez les domaines et le DNS comme une tâche de bascule explicite. Répertoriez chaque nom d’hôte, type d’enregistrement et point d’accès public qui atteint l’application, y compris les sous-domaines utilisés pour les webhooks, API ou services liés à la messagerie. Pour chaque nom d’hôte, choisissez explicitement l’une des options approuvées : supprimer l’enregistrement DNS, faire pointer l’enregistrement vers un service de remplacement, ou conserver le DNS tout en configurant une redirection HTTP contrôlée au niveau du proxy inverse ou d’un autre service web. Le DNS ne réalise pas lui-même de redirection HTTP. Un changement de destination peut aussi nécessiter de vérifier le certificat TLS et les règles de routage de la nouvelle destination. Consignez la destination prévue et le responsable avant toute modification.

Tenez compte du TTL DNS et du comportement de propagation applicables aux enregistrements que vous modifiez. Après la fenêtre de changement planifiée, testez chaque ancien nom d’hôte depuis les réseaux concernés et confirmez qu’il ne se résout plus vers l’application retirée et qu’il n’y est plus routé. Testez également tout service de remplacement ou toute redirection HTTP approuvée. Vérifiez la configuration du proxy inverse et, le cas échéant, les routeurs et services Traefik, afin qu’une règle obsolète ne continue pas à transmettre des requêtes à la charge de travail.

Capturez les éléments de preuve de vérification avant l’élimination de l’infrastructure. Il peut s’agir de l’état du service arrêté, de la configuration de redémarrage désactivée, des résultats des tests DNS et de routage, des confirmations de désactivation des dépendances, des traces de révocation d’accès et de l’acceptation de l’archive. Conservez ces éléments avec le dossier de retrait afin que l’état final puisse être compris et audité ultérieurement.

• Arrêtez l’application, les workers, les files d’attente et les services planifiés qui ne sont plus approuvés.
• Désactivez le comportement de redémarrage de Compose ou d’une autre charge de travail avant la validation finale.
• Pour chaque nom d’hôte, supprimez l’enregistrement DNS, faites-le pointer vers une destination de remplacement ou conservez-le avec une redirection HTTP contrôlée.
• Vérifiez les certificats TLS et les règles de routage lorsqu’un nom d’hôte pointe vers une nouvelle destination.
• Vérifiez que les anciens noms d’hôte n’atteignent plus l’application après la fenêtre de changement DNS planifiée.
• Confirmez que tout service de remplacement, toute redirection HTTP ou toute route d’archive se comporte comme prévu.
• Consignez l’heure d’arrêt, l’exécutant, les tests effectués, les résultats et les exceptions.