Como desativar uma aplicação auto-hospedada preservando os dados e removendo vias de acesso

A aposentação de uma aplicação é um projeto de governação de dados, não uma tarefa de servidor

Para desativar uma aplicação auto-hospedada em segurança, trate o trabalho como uma aposentação controlada de registos, fluxos de trabalho, identidades e infraestrutura. Parar um contentor ou eliminar um servidor virtual pode encerrar o serviço visível, mas não responde às questões importantes: que registos têm de continuar disponíveis, quem ainda lhes pode aceder, de que aplicação ainda dependem outros sistemas e quando as cópias retidas devem ser eliminadas.

Um plano de aposentação sólido separa três resultados frequentemente confundidos. Uma exportação é uma representação utilizável dos registos para pessoas ou para um sistema de substituição. Uma cópia de segurança para recuperação é destinada a restaurar a aplicação após uma falha. Uma decisão de retenção determina que informação deve ser mantida, para que finalidade, sob que controlos e durante quanto tempo. Por vezes, um artefacto pode servir mais de uma finalidade, mas isso não deve ser presumido.

Designe um responsável pela aplicação e envolva as pessoas responsáveis por operações, registos, segurança, finanças e processos de negócio. Se a aplicação contiver informação pessoal, financeira, contratual ou regulamentada, obtenha a orientação jurídica, de privacidade ou de gestão de registos adequada à sua organização antes da destruição.

• Defina por escrito o objetivo de aposentação e a data-alvo.
• Nomeie responsáveis pelas decisões relativas aos dados, execução técnica e aprovação final.
• Registe o motivo da aposentação, substituição ou consolidação.
• Defina o sucesso como a disponibilidade dos registos e a remoção dos acessos desnecessários, e não apenas como um servidor offline.

Escolha o estado de aposentação antes de planear o encerramento

Nem todas as aplicações devem passar diretamente de produção para eliminação. Selecione primeiro o estado final pretendido, porque este determina como migrará os dados, comunicará com os utilizadores e removerá os acessos.

Uma migração para uma solução de substituição é adequada quando outro sistema assumirá o trabalho ativo. O modo apenas de arquivo é adequado quando os registos podem ser necessários, mas não deve ocorrer novo trabalho. O encerramento completo só é adequado quando os registos tiverem sido tratados de acordo com a decisão de retenção aprovada e as dependências tiverem sido removidas. Estes estados podem ser faseados: produção, arquivo em modo só de leitura e, depois, aposentação completa.

Não utilize o modo só de leitura como um adiamento vago. Defina quem pode entrar, que registos pode consultar, como o acesso é aprovado, se as integrações são desativadas, durante quanto tempo o arquivo existirá e que evento autoriza a sua eliminação final.

• Substituição: migre os registos ativos, confirme a titularidade no novo sistema e estabeleça uma data clara de transição.
• Apenas arquivo: impeça alterações, minimize o acesso dos utilizadores e mantenha apenas a infraestrutura necessária para a consulta aprovada.
• Encerramento completo: remova o encaminhamento público, pare os serviços, revogue credenciais e elimine a infraestrutura apenas após verificação.
• Pause a aposentação completa quando suspensões legais, obrigações de auditoria, lacunas de migração não resolvidas ou potenciais ações judiciais exigirem preservação continuada.

Crie um inventário que acompanhe a aplicação para além do seu contentor principal

Comece com um inventário que outra pessoa possa utilizar para compreender a aplicação depois de o administrador original sair. Inclua a finalidade de negócio, responsável, utilizadores, categorias de dados, localização de alojamento, domínios, sistema de substituição e decisão de aposentação.

Para implementações baseadas em Docker, inventarie o armazenamento persistente separadamente dos contentores. Os [volumes do Docker](https://docs.docker.com/engine/storage/volumes/) são armazenamentos de dados persistentes e podem permanecer depois de um contentor ser eliminado. Eliminar um contentor de serviço parado não é uma exportação de dados: os dados fora de um volume podem perder-se quando os contentores são removidos. Identifique volumes nomeados e volumes anónimos, pois o armazenamento anónimo pode ser removido durante a limpeza de contentores.

Preserve a definição de implementação antes de a alterar. Os ficheiros Compose podem definir serviços, redes, volumes e configuração relacionada. Identifique também a configuração Compose específica de produção, que o Docker recomenda para definições como variáveis de ambiente, políticas de reinício e serviços adicionais, tais como registo de logs. Capture a configuração de forma segura e não copie segredos para documentos amplamente acessíveis. As [orientações de produção do Docker Compose](https://docs.docker.com/compose/how-tos/production/) explicam esta separação.

• Bases de dados, volumes nomeados, volumes anónimos, diretórios montados por bind e ficheiros carregados.
• Ficheiros Compose, ficheiros de ambiente, notas de implementação, referências de imagens, redes e configuração de proxy reverso.
• Domínios, subdomínios, registos DNS, certificados TLS e rotas públicas.
• Tarefas agendadas, processos de worker, filas, tarefas de relatórios e destinos de logs.
• Definições de e-mail de entrada e saída, fornecedores de pagamento, webhooks, APIs, fornecedores de identidade e analítica.
• Contas de serviço, contas de administrador, grupos de utilizadores, tokens de API, acesso SSH e acesso de emergência.
• Subscrições de fornecedores, recursos cloud, localizações de armazenamento e responsáveis pela faturação.

Classifique os registos antes de decidir o que exportar, reter ou eliminar

Crie um registo de destino dos dados em vez de tomar decisões ad hoc durante o encerramento. Para cada conjunto de registos, documente a sua finalidade, responsável de negócio, sensibilidade, fundamento de retenção, destino aprovado, método de consulta, controlos de acesso e condição de eliminação. Separe os registos operacionais dos artefactos de sistema: ficheiros de clientes, faturas, evidências de auditoria e documentos assinados podem exigir um tratamento diferente de dados de cache, carregamentos temporários e logs.

Para organizações sujeitas ao RGPD, o princípio da limitação da conservação significa que os dados pessoais não devem ser conservados durante mais tempo do que o necessário para a finalidade da sua recolha. Isto não significa que a eliminação imediata seja sempre correta. A retenção pode ser necessária por razões como obrigações legais ou a declaração, o exercício ou a defesa de ações judiciais. Consulte as [orientações da Comissão Europeia sobre os princípios do RGPD](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) e o [artigo 17.º do RGPD](https://eur-lex.europa.eu/eli/reg/2016/679/2016-05-04). As orientações sobre o RGPD não constituem um calendário completo de retenção e não devem ser interpretadas como aconselhamento jurídico: os requisitos setoriais, contratuais e específicos de cada jurisdição podem diferir.

Os arquivos retidos exigem salvaguardas. Nos termos dos princípios do RGPD, a integridade e a confidencialidade exigem medidas técnicas e organizativas adequadas contra o tratamento não autorizado ou ilícito e contra a perda, destruição ou dano acidental. Limite o acesso aos arquivos às pessoas que dele necessitam e registe quem aprova a consulta.

• Manter: registos aprovados com finalidade, responsável, período de retenção e método de acesso identificados.
• Exportar: registos necessários para uma substituição operacional, auditoria, apoio ao cliente ou prova futura.
• Eliminar: dados sem finalidade de retenção aprovada, depois de verificadas as suspensões e dependências.
• Documentar: decisões, aprovadores, localizações de arquivo, datas de eliminação e exceções.

Valide as exportações como registos utilizáveis, não apenas como transferências bem-sucedidas

Uma exportação só é útil se a organização a puder identificar, abrir, interpretar e relacionar mais tarde com os registos originais. Um despejo de base de dados ou arquivo de volume pode ser valioso para recuperação, mas inadequado para uma equipa de finanças, apoio ou jurídica que necessite de uma fatura, histórico de cliente ou documento específico sem reconstruir toda a aplicação.

Para cada exportação, documente o âmbito, a hora de corte, a aplicação de origem, o formato, a codificação, as contagens de registos quando relevantes, o tratamento de anexos, as definições de campos e o responsável. Inclua contexto suficiente para interpretar identificadores, valores de estado e marcas temporais. Mantenha manifestos de exportação com o arquivo, e não apenas nas notas de um administrador que está de saída.

Teste com questões de consulta realistas. Peça ao responsável designado pelos registos para localizar um conjunto representativo de registos, abrir ficheiros associados, confirmar campos importantes e comparar os resultados com a aplicação em produção antes do encerramento. Se houver migração, reconcilie a origem e o destino e resolva as exceções antes da transição final.

• Uma pessoa autorizada que não seja administradora consegue localizar e ler um registo mais tarde?
• Os anexos e documentos carregados estão incluídos e corretamente associados?
• As exportações incluem as relações, identificadores e marcas temporais necessários?
• O formato e qualquer software necessário estão documentados?
• O responsável pelo arquivo é conhecido e o acesso de consulta foi testado?
• Uma amostra representativa foi reconciliada com a origem?

Mapeie e desative todas as dependências externas

Uma aplicação aposentada ainda pode enviar e-mail, aceitar pedidos, acionar automações ou gerar custos de terceiros se as suas dependências continuarem ativas. Crie um mapa de dependências que mostre a direção: o que chama a aplicação, o que a aplicação chama externamente e o que é executado de forma agendada sem ação de utilizador.

Reveja cuidadosamente a configuração de execução. Trate os segredos separadamente das definições comuns. Identifique valores sensíveis na configuração da aplicação, do anfitrião e da implementação, e depois revogue-os ou rode-os em vez de depender apenas da eliminação da infraestrutura.

Desative as dependências numa ordem deliberada. Pare os produtores agendados e os webhooks de entrada antes de obter a captura final dos dados, para que novos registos não cheguem inesperadamente. Em seguida, revogue as credenciais de saída e desative os consumidores que esperam que a aplicação responda. Mantenha um registo de cada alteração e do respetivo resultado de verificação.

• Endpoints de webhook e segredos de assinatura.
• Chaves de API, clientes OAuth e tokens de integração.
• Credenciais SMTP, regras de reencaminhamento de e-mail e rotas de e-mail de entrada.
• Aplicações do fornecedor de identidade, ligações SSO e regras de aprovisionamento.
• Chaves de serviços de pagamento, URLs de callback e dependências de subscrição.
• Tarefas agendadas, filas, workers, tarefas cron e automação externa.
• Destinos de monitorização, alertas, logs e exportação de dados.

Remova o acesso por camadas: pessoas, máquinas e rotas públicas

Eliminar contas de utilizador dentro da aplicação é necessário, mas não suficiente. O acesso pode persistir através de credenciais de administrador, palavras-passe partilhadas, tokens de API, contas de serviço, chaves SSH, sessões do fornecedor de identidade, autenticação de proxy reverso e contas de emergência. Crie um registo de acessos e atribua a um responsável a confirmação de que cada via foi removida ou deliberadamente retida para acesso ao arquivo.

Planeie cuidadosamente a ordem. Preserve uma via de acesso de emergência estritamente controlada até as exportações, cópias de recuperação e verificações estarem concluídas. Não a deixe sem documentação ou partilhada. Assim que a aprovação for obtida, revogue a última via administrativa e registe a hora, o interveniente e a evidência.

Se o Traefik fizer parte da implementação, reveja os routers como parte da remoção da exposição pública. Um [router HTTP](https://doc.traefik.io/traefik/reference/routing-configuration/http/routing/router/) corresponde a pedidos recebidos e encaminha-os para um serviço. Se a API ou o painel do Traefik estiverem ativados e a configuração relevante for acessível, podem ajudar a enumerar routers, serviços, middlewares, entry points e relações. A [documentação da API e do painel do Traefik](https://doc.traefik.io/traefik/operations/dashboard/) alerta contra a exposição pública em produção; restrinja-os a administradores autorizados e redes internas.

• Desative contas de utilizador e remova funções privilegiadas.
• Revogue ou rode palavras-passe de administrador, tokens de API e credenciais de contas de serviço.
• Remova atribuições de SSO e grupos de diretório; verifique o comportamento de desprovisionamento.
• Remova chaves SSH, acesso à consola do servidor e segredos partilhados.
• Desative rotas de proxy e configurações de autenticação que já não são necessárias.
• Mantenha apenas o acesso ao arquivo aprovado e limitado no tempo até à aposentação final.

Encerre a carga de trabalho, remova a exposição DNS e verifique a aposentação

Execute o encerramento final apenas depois de o trabalho aprovado de exportação, arquivo e dependências estar concluído. Pare a carga de trabalho da aplicação e os workers, agendadores e serviços de suporte associados que já não sejam necessários. Antes de declarar a aposentação concluída, desative o comportamento de reinício na definição de implementação de produção e também no ambiente em execução. O Docker Compose suporta políticas de reinício que incluem `always`, `on-failure` e `unless-stopped`; caso contrário, um serviço parado pode regressar após o reinício do anfitrião ou serviço. Consulte a [referência de serviços do Docker Compose](https://docs.docker.com/reference/compose-file/services/).

Trate os domínios e o DNS como uma tarefa explícita de transição. Liste todos os nomes de anfitrião, tipos de registo e rotas públicas que alcançam a aplicação, incluindo subdomínios utilizados para webhooks, APIs ou serviços relacionados com e-mail. Para cada nome de anfitrião, decida se deve remover o registo, redirecionar os utilizadores para uma substituição aprovada ou manter um destino de arquivo restrito. Registe o destino pretendido e o responsável antes de alterar o DNS.

Considere o TTL do DNS e o comportamento de propagação aplicável aos registos que alterar. Após a janela de alteração planeada, teste cada antigo nome de anfitrião a partir das redes relevantes e confirme que já não resolve nem encaminha para a aplicação aposentada. Teste também qualquer redirecionamento ou destino de substituição aprovado. Verifique a configuração do proxy reverso e, quando aplicável, os routers e serviços do Traefik, para que uma rota obsoleta não continue a encaminhar pedidos para a carga de trabalho.

Recolha evidências de verificação antes da eliminação da infraestrutura. Estas podem incluir o estado do serviço parado, a configuração de reinício desativada, resultados de testes de DNS e rotas, confirmações de desativação de dependências, registos de revogação de acesso e aceitação do arquivo. Conserve as evidências com o registo de aposentação para que o estado final possa ser compreendido e auditado posteriormente.

• Pare a aplicação, os workers, as filas e os serviços agendados que já não estão aprovados.
• Desative o comportamento de reinício do Compose ou de outra carga de trabalho antes da aprovação final.
• Remova, redirecione ou restrinja todos os registos DNS e rotas públicas aprovados.
• Verifique que os antigos nomes de anfitrião já não alcançam a aplicação após a janela planeada de alteração do DNS.
• Confirme que qualquer destino de substituição ou rota de arquivo se comporta como previsto.
• Registe a hora do encerramento, o executor, os testes efetuados, os resultados e as exceções.