Come dismettere un’applicazione self-hosted preservando i dati e rimuovendo i percorsi di accesso

Il ritiro di un’applicazione è un progetto di governance dei dati, non un’attività sui server

Per dismettere in sicurezza un’applicazione self-hosted, considera il lavoro come un ritiro controllato di record, workflow, identità e infrastruttura. Arrestare un container o eliminare un server virtuale può interrompere il servizio visibile, ma non risponde alle domande importanti: quali record devono restare disponibili, chi può ancora accedervi, quali altri sistemi dipendono ancora dall’applicazione e quando le copie conservate devono essere eliminate.

Un solido piano di ritiro distingue tre risultati che spesso vengono confusi. Un’esportazione è una rappresentazione utilizzabile dei record per le persone o per un sistema sostitutivo. Un backup di ripristino è una copia destinata a ripristinare l’applicazione dopo un guasto. Una decisione di conservazione stabilisce quali informazioni mantenere, per quale finalità, con quali controlli e per quanto tempo. Talvolta un singolo artefatto può supportare più di una finalità, ma non lo si deve presumere.

Assegna un unico responsabile dell’applicazione e coinvolgi le persone responsabili di operazioni, gestione dei record, sicurezza, finanza e processi aziendali. Se l’applicazione contiene informazioni personali, finanziarie, contrattuali o regolamentate, ottieni dalla tua organizzazione l’appropriata consulenza legale, sulla privacy o sulla gestione dei record prima della distruzione.

• Stabilisci per iscritto l’obiettivo del ritiro e la data prevista.
• Nomina un responsabile per le decisioni sui dati, l’esecuzione tecnica e l’approvazione finale.
• Registra il motivo del ritiro, della sostituzione o del consolidamento.
• Definisci il successo sia come disponibilità dei record sia come rimozione degli accessi non necessari, non semplicemente come un server offline.

Scegli lo stato di ritiro prima di pianificare lo spegnimento

Non tutte le applicazioni devono passare direttamente dalla produzione all’eliminazione. Seleziona prima lo stato finale previsto, perché determina come migrare i dati, comunicare con gli utenti e rimuovere gli accessi.

Una migrazione verso un sistema sostitutivo è appropriata quando un altro sistema assumerà il lavoro attivo. La modalità solo archivio è appropriata quando i record potrebbero essere necessari ma non dovrebbero essere svolte nuove attività. Lo spegnimento completo è appropriato soltanto quando i record sono stati gestiti in base alla decisione di conservazione approvata e le dipendenze sono state rimosse. Questi stati possono essere graduali: produzione, archivio in sola lettura, quindi ritiro completo.

Non usare la modalità sola lettura come un rinvio vago. Definisci chi può accedere, quali record può visualizzare, come viene approvato l’accesso, se le integrazioni sono disabilitate, per quanto tempo esisterà l’archivio e quale evento ne autorizza la dismissione definitiva.

• Sostituzione: migra i record attivi, conferma la titolarità nel nuovo sistema e stabilisci una data di cutover chiara.
• Solo archivio: impedisci le modifiche, riduci al minimo l’accesso degli utenti e conserva solo l’infrastruttura necessaria per il recupero approvato.
• Spegnimento completo: rimuovi il routing pubblico, arresta i servizi, revoca le credenziali e dismetti l’infrastruttura soltanto dopo la verifica.
• Sospendi il ritiro completo quando obblighi di conservazione legale, obblighi di audit, lacune di migrazione irrisolte o potenziali pretese legali richiedono una conservazione continuativa.

Crea un inventario che segua l’applicazione oltre il suo container principale

Inizia con un inventario che un’altra persona possa usare per comprendere l’applicazione dopo l’uscita dell’amministratore originale. Includi la finalità aziendale, il responsabile, gli utenti, le categorie di dati, la posizione di hosting, i domini, il sistema sostitutivo e la decisione di ritiro.

Per le distribuzioni basate su Docker, inventaria lo storage persistente separatamente dai container. I [volumi Docker](https://docs.docker.com/engine/storage/volumes/) sono archivi dati persistenti e possono restare anche dopo l’eliminazione di un container. Eliminare un container di servizio arrestato non equivale a un’esportazione dei dati: i dati al di fuori di un volume possono andare persi quando i container vengono rimossi. Identifica volumi nominati e volumi anonimi, poiché lo storage anonimo può essere rimosso durante la pulizia dei container.

Conserva la definizione del deployment prima di modificarla. I file Compose possono definire servizi, reti, volumi e configurazioni correlate. Identifica inoltre la configurazione Compose specifica per la produzione, che Docker raccomanda per impostazioni quali variabili d’ambiente, policy di riavvio e servizi aggiuntivi come il logging. Acquisisci la configurazione in modo sicuro e non copiare segreti in documenti ampiamente accessibili. La [guida Docker Compose per la produzione](https://docs.docker.com/compose/how-tos/production/) spiega questa separazione.

• Database, volumi nominati, volumi anonimi, directory montate tramite bind e file caricati.
• File Compose, file d’ambiente, note di deployment, riferimenti alle immagini, reti e configurazione del reverse proxy.
• Domini, sottodomini, record DNS, certificati TLS e rotte pubbliche.
• Processi pianificati, processi worker, code, attività di reportistica e destinazioni dei log.
• Impostazioni email in entrata e in uscita, fornitori di pagamento, webhook, API, provider di identità e analytics.
• Account di servizio, account amministratore, gruppi utenti, token API, accesso SSH e accesso di emergenza o break-glass.
• Abbonamenti a fornitori, risorse cloud, posizioni di archiviazione e responsabili della fatturazione.

Classifica i record prima di decidere cosa esportare, conservare o eliminare

Crea un registro di destinazione dei dati anziché compiere scelte estemporanee durante lo spegnimento. Per ogni insieme di record, documenta finalità, responsabile aziendale, sensibilità, base di conservazione, destinazione approvata, metodo di recupero, controlli di accesso e condizione di eliminazione. Separa i record operativi dagli artefatti di sistema: file dei clienti, fatture, evidenze di audit e documenti firmati possono richiedere un trattamento diverso rispetto a dati di cache, caricamenti temporanei e log.

Per le organizzazioni soggette al GDPR, il principio di limitazione della conservazione implica che i dati personali non debbano essere mantenuti più a lungo del necessario per la finalità della raccolta. Ciò non significa che l’eliminazione immediata sia sempre corretta. La conservazione può essere necessaria, ad esempio, per obblighi legali o per l’accertamento, l’esercizio o la difesa di diritti in sede giudiziaria. Consulta la [guida della Commissione europea sui principi del GDPR](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) e l’[articolo 17 del GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04). Le indicazioni sul GDPR non costituiscono un piano completo di conservazione e non devono essere interpretate come consulenza legale: i requisiti settoriali, contrattuali e specifici della giurisdizione possono differire.

Gli archivi conservati richiedono misure di protezione. Secondo i principi del GDPR, integrità e riservatezza richiedono misure tecniche e organizzative appropriate contro trattamenti non autorizzati o illeciti e contro perdita, distruzione o danneggiamento accidentali. Limita l’accesso all’archivio alle persone che ne hanno necessità e registra chi approva il recupero.

• Conserva: record approvati con una finalità, un responsabile, un periodo di conservazione e un metodo di accesso identificati.
• Esporta: record necessari per una sostituzione operativa, un audit, il servizio clienti o future evidenze.
• Elimina: dati senza una finalità di conservazione approvata dopo aver verificato obblighi di conservazione e dipendenze.
• Documenta: decisioni, approvatori, posizioni degli archivi, date di eliminazione ed eccezioni.

Convalida le esportazioni come record utilizzabili, non solo come download riusciti

Un’esportazione è utile soltanto se l’organizzazione può identificarla, aprirla, interpretarla e ricollegarla in seguito ai record originali. Un dump del database o un archivio di volumi può essere prezioso per il ripristino, ma inadeguato per un team finanziario, di assistenza o legale che necessita di una fattura specifica, della cronologia di un cliente o di un documento senza ricostruire l’intera applicazione.

Per ogni esportazione, documenta l’ambito, l’orario di cutoff, l’applicazione sorgente, il formato, la codifica, i conteggi dei record ove significativi, la gestione degli allegati, le definizioni dei campi e il responsabile. Includi contesto sufficiente per interpretare identificatori, valori di stato e timestamp. Conserva i manifest delle esportazioni insieme all’archivio, non soltanto nelle note di un amministratore in uscita.

Verifica con domande realistiche di recupero. Chiedi al responsabile designato dei record di trovare un insieme rappresentativo di record, aprire i file associati, confermare i campi importanti e confrontare i risultati con l’applicazione attiva prima dello spegnimento. Se è coinvolta una migrazione, riconcilia origine e destinazione e risolvi le eccezioni prima del cutover finale.

• Un utente autorizzato non amministratore può trovare e leggere un record in futuro?
• Gli allegati e i documenti caricati sono inclusi e collegati correttamente?
• Le esportazioni includono relazioni, identificatori e timestamp necessari?
• Il formato e l’eventuale software richiesto sono documentati?
• Il responsabile dell’archivio è noto e l’accesso per il recupero è stato testato?
• Un campione rappresentativo è stato riconciliato con l’origine?

Mappa e disabilita ogni dipendenza esterna

Un’applicazione ritirata può ancora inviare email, accettare richieste, attivare automazioni o generare costi presso terze parti se le sue dipendenze restano attive. Crea una mappa delle dipendenze che mostri la direzione: cosa invia richieste all’applicazione, cosa l’applicazione richiama all’esterno e cosa viene eseguito a intervalli pianificati senza un’azione dell’utente.

Esamina attentamente la configurazione di runtime. Tratta i segreti separatamente dalle impostazioni ordinarie. Identifica i valori sensibili nella configurazione dell’applicazione, dell’host e del deployment, quindi revocali o ruotali invece di fare affidamento soltanto sull’eliminazione dell’infrastruttura.

Disabilita le dipendenze in un ordine deliberato. Arresta i produttori pianificati e i webhook in entrata prima di acquisire lo snapshot finale dei dati, in modo che non arrivino inaspettatamente nuovi record. Quindi revoca le credenziali in uscita e disabilita i consumer che si aspettano una risposta dall’applicazione. Conserva una registrazione di ogni modifica e del relativo risultato di verifica.

• Endpoint webhook e segreti di firma.
• Chiavi API, client OAuth e token di integrazione.
• Credenziali SMTP, regole di inoltro email e rotte email in entrata.
• Applicazioni del provider di identità, connessioni SSO e regole di provisioning.
• Chiavi del servizio di pagamento, URL di callback e dipendenze dagli abbonamenti.
• Processi pianificati, code, worker, attività cron e automazioni esterne.
• Destinazioni di monitoraggio, avvisi, logging ed esportazione dei dati.

Rimuovi gli accessi a livelli: persone, macchine e rotte pubbliche

Eliminare gli account utente nell’applicazione è necessario ma non sufficiente. L’accesso può persistere tramite credenziali amministrative, password condivise, token API, account di servizio, chiavi SSH, sessioni del provider di identità, autenticazione del reverse proxy e account di emergenza. Crea un registro degli accessi e assegna un responsabile che attesti che ogni percorso è stato rimosso o intenzionalmente mantenuto per l’accesso all’archivio.

Pianifica attentamente l’ordine. Conserva un percorso di accesso di emergenza strettamente controllato finché esportazioni, copie di ripristino e verifiche non sono complete. Non lasciarlo privo di documentazione o condiviso. Una volta ottenuta l’approvazione, revoca il percorso amministrativo finale e registra ora, soggetto che ha eseguito l’azione ed evidenza.

Se Traefik fa parte del deployment, esamina i router nell’ambito della rimozione dell’esposizione pubblica. Un [router HTTP](https://doc.traefik.io/traefik/reference/routing-configuration/http/routing/router/) corrisponde alle richieste in entrata e le inoltra a un servizio. Se l’API o la dashboard di Traefik sono abilitate e la configurazione pertinente è accessibile, possono aiutare a enumerare router, servizi, middleware, entry point e relazioni. La [documentazione sull’API e sulla dashboard di Traefik](https://doc.traefik.io/traefik/operations/dashboard/) mette in guardia dall’esposizione pubblica in produzione; limitane l’uso agli amministratori autorizzati e alle reti interne.

• Disattiva gli account utente e rimuovi i ruoli privilegiati.
• Revoca o ruota password amministrative, token API e credenziali degli account di servizio.
• Rimuovi assegnazioni SSO e di gruppi di directory; verifica il comportamento del deprovisioning.
• Rimuovi chiavi SSH, accesso alla console del server e segreti condivisi.
• Disabilita le rotte proxy e la configurazione di autenticazione non più necessaria.
• Conserva soltanto l’accesso all’archivio approvato e limitato nel tempo fino al ritiro definitivo.

Arresta il carico di lavoro, rimuovi l’esposizione DNS e verifica il ritiro

Esegui lo spegnimento finale soltanto dopo che il lavoro approvato su esportazioni, archivi e dipendenze è completo. Arresta il carico di lavoro dell’applicazione e i worker, i pianificatori e i servizi di supporto associati che non sono più necessari. Prima di dichiarare completo il ritiro, disabilita il comportamento di riavvio nella definizione di deployment in produzione oltre che nell’ambiente in esecuzione. Docker Compose supporta policy di riavvio tra cui `always`, `on-failure` e `unless-stopped`; un servizio arrestato potrebbe altrimenti tornare attivo dopo il riavvio di un host o di un servizio. Consulta il [riferimento dei servizi Docker Compose](https://docs.docker.com/reference/compose-file/services/).

Gestisci domini e DNS come un’attività di cutover esplicita. Elenca ogni hostname, tipo di record e rotta pubblica che raggiunge l’applicazione, inclusi i sottodomini usati per webhook, API o servizi correlati alla posta. Per ciascun hostname, decidi se rimuovere il record, reindirizzare gli utenti a un sistema sostitutivo approvato o mantenere una destinazione di archivio con accesso limitato. Registra la destinazione prevista e il responsabile prima di modificare il DNS.

Considera il TTL DNS e il comportamento di propagazione applicabili ai record modificati. Dopo la finestra di modifica pianificata, verifica ciascun precedente hostname dalle reti pertinenti e conferma che non risolva più verso l’applicazione ritirata né instradi il traffico a essa. Verifica anche ogni reindirizzamento o destinazione sostitutiva approvata. Controlla la configurazione del reverse proxy e, ove applicabile, router e servizi Traefik, affinché una rotta obsoleta non continui a inoltrare richieste al carico di lavoro.

Acquisisci le evidenze di verifica prima della dismissione dell’infrastruttura. Possono includere lo stato del servizio arrestato, la configurazione di riavvio disabilitata, risultati dei test DNS e delle rotte, conferme di disabilitazione delle dipendenze, registri di revoca degli accessi e accettazione dell’archivio. Conserva le evidenze con il record di ritiro affinché lo stato finale possa essere compreso e sottoposto ad audit in seguito.

• Arresta l’applicazione, i worker, le code e i servizi pianificati che non sono più approvati.
• Disabilita il comportamento di riavvio di Compose o di altri carichi di lavoro prima dell’approvazione finale.
• Rimuovi, reindirizza o limita ogni record DNS e rotta pubblica approvati.
• Verifica che i precedenti hostname non raggiungano più l’applicazione dopo la finestra pianificata di modifica DNS.
• Conferma che qualsiasi destinazione sostitutiva o rotta di archivio si comporti come previsto.
• Registra l’ora dello spegnimento, l’esecutore, i test effettuati, i risultati e le eccezioni.