Um ambiente de staging mais seguro para aplicações autoalojadas: isolamento, dados e efeitos secundários

Comece por definir o objetivo do staging

Um ambiente de staging para uma aplicação autoalojada é um local onde pode testar uma alteração planeada antes de esta chegar à produção. A configuração adequada depende do que precisa de comprovar: que uma configuração funciona, que uma integração se comporta como esperado, que é possível concluir uma atualização ou que um fluxo de trabalho é aceitável para os utilizadores.

Registe o objetivo do teste antes de criar ou atualizar o staging. Uma verificação de configuração pode precisar apenas de um pequeno conjunto de registos representativos. Um teste de integração pode precisar de uma conta de teste no serviço externo. Um teste de aceitação do utilizador pode precisar de funções e fluxos de trabalho realistas, mas não de identidades reais de clientes.

Evite tratar o staging, por predefinição, como um segundo sistema de produção. Reproduza os componentes e o comportamento necessários para o teste e isole ou substitua tudo o que possa causar efeitos no mundo real.

• Que alteração ou fluxo de trabalho está a ser testado?
• Que resultado será considerado um teste bem-sucedido?
• Que dependências de produção têm de ser representadas para que o resultado seja relevante?
• Que ações nunca devem ser executadas pelo staging sobre utilizadores reais, dinheiro ou registos empresariais?

Mapeie as dependências antes de copiar o ambiente

Elabore uma lista das dependências da aplicação e classifique cada uma como necessária, simulada ou intencionalmente indisponível no staging. Considere a base de dados, o armazenamento de ficheiros, os serviços de identidade e autenticação, o envio de correio eletrónico, o processamento de pagamentos, os webhooks, as tarefas agendadas, as API externas, o DNS e qualquer sistema que receba dados da aplicação.

Em seguida, defina o que significa paridade com a produção para o teste em causa. Replicar a configuração da aplicação ou a estrutura da implementação pode ser útil; copiar todos os registos e ligações de produção não é automaticamente útil nem seguro. A documentação do Docker descreve a utilização de configurações do Compose específicas para cada ambiente, como staging e produção, incluindo diferenças nas portas, nas variáveis de ambiente e nas definições dos serviços externos.

Registe cada diferença intencional. Por exemplo, o staging pode usar uma base de dados e um domínio separados, credenciais de teste, ações agendadas desativadas ou uma substituição para um serviço externo. Assim, é mais fácil interpretar os resultados dos testes e voltar a avaliar as diferenças quando a aplicação ou as respetivas dependências mudarem.

• Dependência: a que serviços se liga a aplicação?
• Necessidade do teste: que comportamento tem de ser reproduzido?
• Opção para o staging: serviço de teste real, substituto controlado ou desativado?
• Risco de configuração incorreta: o que poderia um teste enviar, expor ou alterar?

Separe instâncias, domínios, credenciais e permissões

Atribua ao staging a sua própria instância da aplicação e os seus próprios armazenamentos persistentes, em vez de o ligar a recursos de produção. Use um domínio ou subdomínio de staging claramente identificável e confirme que o encaminhamento o direciona para o serviço de staging. Por exemplo, os routers do Traefik podem corresponder aos pedidos com base no nome do anfitrião e encaminhá-los para um serviço configurado; a regra do nome do anfitrião deve corresponder ao ambiente pretendido.

Use credenciais específicas de staging para a base de dados, a aplicação e os serviços externos. Não copie segredos de produção para o staging só porque a configuração da implementação é semelhante nos restantes aspetos. Os segredos do Docker Compose podem ser atribuídos explicitamente a serviços, o que permite limitar quais os serviços que lhes podem aceder.

Analise as permissões de acesso com tanto cuidado como a infraestrutura. Limite o acesso ao staging às pessoas que dele necessitam e, sempre que possível, use contas e funções separadas. O staging não é automaticamente privado por ter um nome ou URL diferente. Antes de partilhar o endereço, verifique a autenticação, o encaminhamento e qualquer exposição à rede.

Verifique como são publicadas as portas. A documentação do Docker indica que as portas publicadas podem estar acessíveis através dos endereços de rede do anfitrião; associar uma porta a uma interface específica é uma decisão de exposição, não apenas uma definição de conveniência. Exponha o acesso ao staging apenas na medida necessária para o teste.

• Use uma instância, uma base de dados e um local de armazenamento distintos.
• Use um domínio de staging que não possa ser confundido com o de produção.
• Crie credenciais específicas para o staging e conceda acesso apenas onde for necessário.
• Verifique a autenticação e a exposição à rede antes de convidar os testadores.
• Confirme que a configuração específica do ambiente não pode recorrer silenciosamente a pontos de ligação de produção.

Use dados de teste representativos sem copiar registos sensíveis por predefinição

Os dados de teste devem ser suficientemente realistas para testar o comportamento em análise, mas isso não exige uma cópia integral da produção. Comece por registos gerados ou selecionados deliberadamente. Inclua os casos-limite de que o teste depende — como diferentes funções de conta, registos incompletos ou valores-limite — sem importar desnecessariamente informações que identifiquem clientes.

Se forem realmente necessários dados semelhantes aos de produção, decida que campos são necessários e como os campos sensíveis serão removidos, mascarados ou anonimizados antes da utilização. O DevSecOps Maturity Model da OWASP descreve a utilidade de dados de teste semelhantes aos de produção e refere que as informações de identificação pessoal são frequentemente anonimizadas. Trate a atualização dos dados como uma operação sujeita a regras: defina quem a pode solicitar, quem pode aceder ao resultado e quando este tem de ser removido.

Lembre-se de que uma base de dados não é o único local onde as informações podem persistir. Inclua no plano de dados os ficheiros carregados, as exportações, os registos da aplicação, as contas de teste e as cópias de segurança. Defina as regras de retenção antes de carregar os dados, e não depois de terminar um teste.

• Prefira registos de teste gerados ou criados especificamente para o efeito.
• Importe apenas os campos e registos necessários para o teste.
• Anonimize ou proteja de outra forma as informações pessoais antes de as utilizar.
• Defina um responsável e uma data de retenção para os dados de staging e respetivas cópias.
• Verifique também os registos, os ficheiros e as cópias de segurança, não apenas a base de dados.

Evite efeitos secundários em correio eletrónico, pagamentos, webhooks e tarefas

Trate todas as ações de saída como um possível incidente de produção até ter comprovado que estão contidas. Um teste que parece correto na aplicação pode, ainda assim, enviar uma mensagem a um cliente, criar um pagamento real, atualizar um CRM ligado ou acionar outro sistema através de um webhook.

Sempre que possível, use o modo de teste ou sandbox do fornecedor externo e credenciais específicas para o staging. A Stripe documenta valores de teste para simular cenários de pagamento sem movimentar dinheiro e recomenda a utilização de chaves de API de teste em vez de dados reais de cartões. Para cenários de correio eletrónico, o Amazon SES disponibiliza um simulador de caixas de correio para testar resultados como entrega, devolução, reclamação e respostas automáticas.

Para serviços sem um modo de teste adequado, use um substituto controlado ou desative a ligação durante o staging. No caso dos webhooks, encaminhe-os para um recetor de teste ou outro destino explicitamente aprovado para o staging. Analise as ações agendadas e o trabalho em segundo plano: desative-os, limite o respetivo âmbito ou encaminhe-os para serviços de teste, para que uma execução de rotina não afete a produção.

Teste também as próprias salvaguardas. Confirme que uma mensagem de staging permanece no percurso de teste, que um pagamento usa credenciais de teste e que um webhook chega ao recetor pretendido. Não confie num aviso visível ou numa convenção de nomes como única barreira.

• Substitua as chaves de API e os identificadores de conta de produção pelos equivalentes de teste.
• Use as funcionalidades de sandbox ou simulador do fornecedor, quando disponíveis.
• Redirecione o correio eletrónico e os webhooks para destinos de teste controlados.
• Desative ou limite as ações agendadas que possam contactar sistemas reais.
• Faça um pequeno teste de verificação e inspecione o destino antes de iniciar testes mais abrangentes.

Limite o acesso à rede ao que o teste exige

O isolamento abrange também as ligações que saem do staging, não apenas o acesso de entrada à sua interface Web. Identifique os serviços externos de que o teste necessita e, sempre que o modelo de implementação o permita, restrinja ou omita as restantes integrações. Isso reduz a probabilidade de uma configuração incorreta, de uma credencial copiada ou de uma tarefa em segundo plano chegar a um sistema não pretendido.

Considere também dependências que são fáceis de esquecer: bases de dados de produção, armazenamentos de ficheiros partilhados, fornecedores de identidade, registos DNS e destinos de monitorização ou notificação. Se um teste exigir realmente uma dependência ligada à produção, documente o motivo, as ações permitidas e as salvaguardas antes de a ativar.

Os testes de TLS também exigem cuidado. A Let’s Encrypt recomenda a utilização do respetivo ambiente de staging antes da produção, mas os certificados de staging não são considerados fidedignos pelos repositórios de confiança habituais dos browsers e clientes. O projeto também observa que os pedidos externos à API de staging podem introduzir instabilidade e identifica o Pebble como um servidor ACME destinado a testes de CI e desenvolvimento. Escolha uma abordagem de teste adequada à tarefa, em vez de presumir que um certificado de staging é apropriado para utilização normal num browser.

• Permita apenas o acesso de entrada necessário aos testadores e às verificações automatizadas.
• Liste os destinos de saída necessários e volte a analisá-los após alterações de configuração.
• Mantenha o staging afastado das bases de dados de produção e do armazenamento partilhado, salvo se um teste específico exigir o contrário.
• Documente qualquer ligação inevitável à produção e limite as respetivas permissões.
• Separe os testes de certificados das expectativas normais de confiança dos browsers.

Mantenha o staging útil à medida que a produção muda

O staging torna-se enganador quando as diferenças em relação à produção não estão documentadas ou ficam desatualizadas. Mantenha uma nota breve sobre o ambiente, incluindo a configuração da aplicação, a abordagem aos dados, as substituições de serviços externos, as regras de acesso e as limitações conhecidas. Quando a produção mudar, reveja se o staging continua a representar o comportamento que o próximo teste precisa de avaliar.

O Docker Compose permite aplicar configurações específicas de cada ambiente através de um ficheiro Compose adicional. Isso pode ajudar a explicitar as diferenças, mas não determina quais são seguras ou adequadas para a sua aplicação. Reveja a configuração e os segredos antes de cada ciclo de testes, sobretudo após alterações de domínios, integrações ou definições de implementação.

Um ambiente de staging útil não tem necessariamente de ser idêntico à produção. Tem de ser suficientemente representativo para um teste definido, mantendo-se isolado dos dados e dos efeitos secundários da produção. Se não for possível reproduzir com segurança uma dependência crítica, documente essa limitação e evite tratar o resultado como prova de um comportamento que não foi testado.

• Mantenha uma lista concisa das diferenças intencionais em relação à produção.
• Reveja essa lista após alterações na aplicação, nas integrações ou na infraestrutura.
• Confirme que o ambiente de teste continua a abranger o comportamento em avaliação.
• Registe as limitações para que os testadores não exagerem o que um teste bem-sucedido comprova.

Defina regras de retenção e planeie uma remoção cuidadosa

Antes de iniciar os testes, decida quando as contas de staging, os registos de teste, os logs, os ficheiros carregados e as cópias de segurança serão revistos ou removidos. Designe um responsável e especifique que recursos têm de ser preservados para um teste de seguimento. Um ambiente de staging que nunca é limpo pode acumular dados sensíveis, credenciais antigas e artefactos de teste difíceis de interpretar.

Planeie a remoção como uma revisão, não como a execução de um único comando. A documentação do Docker indica que o comando Compose down não remove volumes nomeados por predefinição; a opção --volumes remove os volumes nomeados declarados no ficheiro Compose e os volumes anónimos associados aos contentores. Como os volumes podem conter dados persistentes da aplicação, inspecione a configuração e confirme o ambiente de destino antes de os remover.

Se o staging for gerido por um fornecedor de alojamento, esclareça que tarefas de infraestrutura são da responsabilidade do fornecedor e que decisões continuam a ser suas. A Airbip gere a implementação de aplicações como cargas de trabalho Docker nos seus servidores na nuvem e automatiza o encaminhamento e os certificados TLS, com verificações de DNS, gestão do ciclo de vida dos serviços e cópias de segurança diárias, semanais e mensais configuráveis. Essas capacidades de infraestrutura não determinam que dados coloca no staging, quem lhes pode aceder ou que integrações podem ser contactadas. Defina essas regras para a sua própria aplicação e equipa.

• Identifique a pessoa responsável pelos dados de staging e pela respetiva limpeza.
• Decida o que deve ser conservado, durante quanto tempo e porquê.
• Antes da remoção, confirme que o projeto, o domínio, a base de dados e os volumes pertencem ao staging.
• Verifique se as cópias de segurança ou os ficheiros exportados contêm dados que também têm de ser removidos.
• Confirme que os serviços e dados de produção permanecem intactos após a remoção.