Avaliar alterações em massa numa aplicação autoalojada: perguntas práticas
Um conjunto estruturado de perguntas para analisar a seleção de registos, alterações em massa, resultados de falhas, evidências e opções de correção numa aplicação específica. Use-o para organizar a sua investigação, não como um teste de segurança validado.
Defina a alteração em massa que pretende avaliar
Neste artigo, uma operação em massa significa alterar vários registos existentes através de uma única ação ou fluxo de trabalho. Alguns exemplos incluem editar campos, alterar estados, atribuir um responsável ou arquivar registos. A importação e a exportação de dados estão fora do âmbito deste artigo.
Use as perguntas abaixo para organizar uma investigação específica da aplicação. As evidências necessárias dependem da aplicação, da versão, da configuração, da função do utilizador e das consequências da alteração.
- Identifique a ação: que campo ou estado deve mudar e que resultado espera a sua equipa?
- Defina o alvo: como identificará o operador os registos pretendidos e como poderá a equipa verificar a respetiva composição e quantidade?
- Identifique as funções: quem deve selecionar, executar, rever ou corrigir a alteração?
- Registe as dependências: que trabalho subsequente, notificações ou decisões poderão ser afetados?
Investigue a seleção e a execução
Comece pelo fluxo de trabalho exato que a sua equipa espera utilizar. Consulte a documentação oficial atual da aplicação e, sempre que possível, pergunte ao fornecedor sobre comportamentos que não estejam documentados. Trate as observações de um teste como evidência relativa às condições testadas.
Considere os casos-limite relevantes para o seu fluxo de trabalho, como registos com estados atuais diferentes, valores em falta ou restrições de responsabilidade. Defina primeiro o que a sua equipa espera que aconteça.
- O operador pode rever os registos selecionados e o respetivo total antes de aplicar a alteração?
- Existe uma pré-visualização ou outra forma de inspecionar as alterações propostas e o âmbito dos registos abrangidos?
- Como são tratados os registos que não cumprem as condições da alteração? Procure documentação específica da aplicação ou evidências de um teste controlado.
- O que podem ver ou executar os utilizadores com funções diferentes? Se os limites entre funções forem relevantes, investigue com contas representativas.
- A confirmação é suficientemente clara para o operador distinguir a ação e o âmbito pretendido?
Verifique situações de falha e de nova tentativa
Nos fluxos de trabalho em que seja adequado, investigue o que acontece quando não é possível alterar alguns registos ou quando o operador não recebe um resultado claro. Utilize um ambiente controlado, se estiver disponível, e registe as observações em vez de presumir que todos os registos selecionados foram alterados.
Escolha cenários com base no seu fluxo de trabalho. As perguntas seguintes são sugestões para orientar a investigação.
- Conclusão parcial: alguns registos podem ser alterados enquanto outros permanecem inalterados? Que evidências permitiriam distinguir os grupos?
- Interrupção ou tempo limite: se o resultado não for claro, como poderia a sua equipa determinar o que aconteceu antes de considerar uma nova tentativa?
- Ação repetida: o que acontece se a ação for submetida novamente? Investigue o fluxo de trabalho exato em vez de presumir que repetir a ação não apresenta riscos.
- Erros de validação: os problemas são identificados por registo ou é apresentado apenas um resultado geral?
- Edições simultâneas: se outro utilizador editar um registo abrangido durante a operação, que resultado é apresentado? Considere esta possibilidade se a edição simultânea for plausível no seu fluxo de trabalho.
Determine que evidências ficam disponíveis posteriormente
Decida o que a sua equipa precisaria de apurar após uma alteração. Dependendo do fluxo de trabalho, isso poderá incluir quem a iniciou, quando aconteceu, que registos estavam abrangidos, o que mudou e se a operação foi concluída na totalidade. Verifique que informações a aplicação disponibiliza; não presuma que regista estes detalhes.
Se a aplicação disponibilizar histórico ou registos, consulte-os com a função que investigaria um incidente. Considere o nível de detalhe, durante quanto tempo as evidências permanecem disponíveis e quem lhes pode aceder.
- É possível identificar a conta que iniciou a ação e a hora em que ocorreu?
- É possível determinar que registos foram afetados e o que mudou em cada um?
- É possível distinguir um resultado completo de uma conclusão parcial ou de uma tentativa cujo resultado não é claro?
- Um revisor autorizado consegue recuperar as informações relevantes mais tarde?
Planeie a correção e a recuperação
Considere como a sua equipa reagiria a uma alteração incorreta. Verifique se a aplicação dispõe de um processo de reversão adequado; não presuma que existe uma função de anulação. Se não for possível reverter diretamente, considere que ação compensatória poderá ser necessária para repor o fluxo de trabalho.
Uma cópia de segurança, por si só, não demonstra que seja possível anular seletivamente uma única alteração em massa. Verifique o que abrange, como funciona o restauro, quem o pode efetuar e que outras alterações poderão ser afetadas.
- Um operador pode reverter diretamente a alteração? Que funções o podem fazer e que histórico é mantido?
- Se não for possível reverter diretamente, que correção alternativa poderá ser viável?
- Como poderia a equipa identificar os registos exatos e os valores anteriores necessários para a correção?
- Quem decidiria o que fazer se a correção fosse incompleta?
Registe as suas conclusões
Utilize um registo breve para cada fluxo de trabalho investigado. Assim, a sua equipa poderá distinguir o que verificou daquilo que continua por esclarecer.
Se realizar um teste, utilize um ambiente que não seja de produção, sempre que disponível. Registe primeiro o resultado esperado e evite testes exploratórios em registos ativos. Defina os critérios de decisão especificamente para o seu fluxo de trabalho e para as possíveis consequências.
- Fluxo de trabalho e resultado pretendido
- Versão e configuração da aplicação, função do utilizador de teste e identificadores dos registos selecionados, quando disponíveis
- Evidências consultadas ou condições de teste utilizadas
- Mensagens observadas e estados finais dos registos
- Questões por resolver, evidências adicionais necessárias e pessoa responsável pelo acompanhamento
Use as conclusões para orientar a decisão sobre o fluxo de trabalho
Utilize a documentação, as conversas com o fornecedor e quaisquer observações controladas para fundamentar a sua decisão. Este conjunto de perguntas não certifica que uma aplicação é segura ou adequada a um fluxo de trabalho específico. Se algum comportamento importante continuar pouco claro ou não cumprir os seus requisitos, poderá discutir opções como restringir a ação, dividi-la em lotes sujeitos a revisão, acrescentar uma etapa de aprovação ou reformular o processo. São possibilidades a avaliar, não garantias de que a aplicação as suporte ou de que sejam adequadas.
A autoalojagem e a infraestrutura gerida não determinam como uma aplicação trata as alterações em massa. A Airbip gere a implementação de aplicações do catálogo como cargas de trabalho Docker em servidores cloud da Airbip e automatiza o encaminhamento e os certificados TLS; também disponibiliza 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. Estas capacidades de infraestrutura não verificam o comportamento das operações em massa de uma aplicação nem garantem que uma recuperação específica seja bem-sucedida. Confirme separadamente o comportamento da aplicação e as suas próprias responsabilidades relativas aos dados e ao acesso.
Referências de infraestrutura
Estas referências oficiais descrevem a documentação do Docker, do Traefik e do Let’s Encrypt. São relevantes para as tecnologias de infraestrutura mencionadas acima, não constituindo evidência sobre as proteções contra alterações em massa de qualquer aplicação empresarial: [documentação do Docker](https://docs.docker.com/), [documentação do Traefik](https://doc.traefik.io/traefik/) e [documentação do Let’s Encrypt](https://letsencrypt.org/docs/). Para informações sobre o comportamento de uma aplicação, consulte a documentação oficial da aplicação e da versão específicas que pretende utilizar.
Não é mencionada nenhuma aplicação específica, pelo que este artigo não pode fornecer ligações para a documentação de uma aplicação em particular.
Perguntas frequentes
As operações em massa são o mesmo que importar registos?
Não. Neste artigo, operação em massa significa alterar vários registos existentes através de uma ação ou fluxo de trabalho da aplicação. As importações e exportações estão fora do âmbito.
A documentação do produto, por si só, permite determinar como se comportará uma alteração em massa?
A documentação pode descrever o comportamento esperado, mas confirme se se aplica à versão, configuração e funções que a sua equipa pretende utilizar. Identifique quaisquer questões por resolver e as evidências necessárias para o seu fluxo de trabalho.
Uma cópia de segurança garante que é possível anular uma alteração em massa?
Não. Confirme o que a cópia de segurança abrange e como funciona o restauro. Não presuma que permite anular seletivamente uma única ação e considere o que poderá ser afetado pelo restauro de dados.
E se a aplicação não conseguir mostrar exatamente que registos foram alterados?
Considere o resultado por esclarecer, em vez de presumir que a ação foi concluída na totalidade. Pondere se outra fonte fiável pode apurar o que aconteceu ou se deve restringir, reformular ou adiar o fluxo de trabalho até a sua equipa dispor de evidências adequadas.
Este é um procedimento de teste validado ou uma norma de segurança?
Não. É um conjunto estruturado de perguntas de planeamento e um auxiliar de registo, não um procedimento validado, critérios universais de aprovação ou reprovação, nem uma certificação de uma aplicação.
Fontes e leituras adicionais
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group