Utilizações autorizadas de navegadores multiperfil em QA, agências e segurança

Regra essencial: separe trabalho que já é permitido

Um perfil do navegador pode manter cookies, armazenamento, histórico, extensões, permissões e definições separados de outro contexto de trabalho. Essa separação é útil quando a atividade subjacente é autorizada. Não concede direitos sobre uma conta, um serviço, uma rede, uma pessoa ou um conjunto de dados.

Antes de criar um perfil, torne explícita a cadeia de autorização:

Pergunta	Provas a conservar
Quem é proprietário do sistema ou da conta?	Organização identificada e contacto responsável
Quem autorizou o trabalho?	Contrato, declaração de trabalhos, pedido, plano de testes ou regras de execução do teste
Que recursos e contas estão abrangidos?	Ambientes, origens, IDs de contas, IDs de perfis e exclusões exatos
Que ações são permitidas?	Ler, publicar, testar, repor, convidar, exportar, automatizar ou outras operações indicadas
Que dados podem ser utilizados?	Classificações de dados sintéticos, de teste, fornecidos pelo cliente, pessoais, confidenciais e de retenção
Quando se aplica a autorização?	Início, validade, janela de manutenção e percurso de revogação
O que exige aprovação?	Ações externamente visíveis, destrutivas, em massa, que alterem acessos ou gerem custos
Quando deve o trabalho parar?	Incerteza de âmbito, dados inesperados, impacto no serviço, acesso revogado ou resultado desconhecido

O acesso técnico não prova a autorização. Uma sessão guardada pode continuar a funcionar depois de um membro sair da equipa ou de um cliente terminar a colaboração. O operador tem de parar quando a autoridade é retirada, mesmo que o navegador ainda consiga abrir a conta.

Um padrão operacional partilhado

As mesmas cinco etapas tornam responsáveis diferentes fluxos multiperfil.

1. Autorizar

Identifique o proprietário do sistema, o cliente quando aplicável, os operadores, a finalidade permitida, os recursos, as contas, as ações, as datas, o tratamento dos dados, as aprovações e as condições de paragem. Um cliente pode autorizar trabalho nos recursos que controla; não pode conceder direitos que não possui sobre outro serviço.

2. Preparar

Crie um perfil para o ambiente, cliente, função ou caso de teste específico. Aplique apenas as extensões, o proxy, a configuração regional, as permissões e as credenciais necessários. Prefira a delegação suportada pelo serviço e contas individuais à partilha de palavras-passe ou cópia de material de sessão.

3. Executar

Utilize um operador ou carga de trabalho responsável de cada vez para estado mutável. Imponha limites de âmbito, destino, simultaneidade, ritmo e custos. Pré-visualize alterações de alto impacto e vincule a aprovação ao destino e à ação exatos.

4. Registar

Registe o interveniente, a carga de trabalho delegada, a referência do perfil, a ação, a aprovação, a hora, o destino, o resultado e as versões relevantes. As orientações da OWASP sobre registos recomendam capturar quando, onde, quem e o quê, protegendo os registos e excluindo segredos técnicos. Mantenha cookies em bruto, palavras-passe, tokens, credenciais de proxy, conteúdo das páginas e dados pessoais desnecessários fora dos registos correntes.

5. Recuperar e encerrar

Pare o perfil corretamente, verifique o estado esperado, conserve apenas as provas aprovadas, revogue o acesso temporário e devolva o perfil ao respetivo proprietário. Se a execução terminar num estado desconhecido, investigue antes de tentar novamente. Restaure uma cópia em bom estado conhecida ou coloque em quarentena o estado danificado, em vez de continuar silenciosamente.

Equipas de QA e localização

Limites de perfil úteis

As equipas de QA podem utilizar perfis separados para:

• estados anónimo, com sessão iniciada e recém-registado;
• funções de administrador, editor, apoio e utilizador comum;
• desenvolvimento, pré-produção e testes rápidos de produção expressamente aprovados;
• combinações de configuração regional, idioma, fuso horário, esquema de cores e permissões;
• configurações com e sem extensões;
• um estado limpo de primeira execução e um estado persistente atualizado deliberadamente; e
• participantes em paralelo num cenário aprovado com vários utilizadores.

O Playwright utiliza contextos isolados do navegador para que os testes recebam cookies, armazenamento local e armazenamento de sessão separados, e suporta vários contextos em cenários com vários utilizadores. A respetiva documentação sobre contextos do navegador também explica por que razão o isolamento com estado limpo reduz a propagação de falhas. Este é um padrão de teste útil, mas um perfil persistente de produto e um contexto temporário de automação podem conservar estado diferente. Registe qual deles o teste utiliza efetivamente.

Testes regionais e de localização

Uma matriz de localização repetível pode variar a configuração regional declarada, o fuso horário, a janela de visualização, o método de introdução, a direção do texto e os dados de teste. O Playwright documenta a emulação da configuração regional, do fuso horário, da geolocalização, do esquema de cores e de outras definições de contexto no respetivo guia de emulação. Trate a emulação como uma entrada controlada, não como prova de que o teste representa todos os dispositivos, redes, regiões jurídicas ou experiências reais dos utilizadores.

Utilize um proxy ou uma entrada de geolocalização apenas quando o proprietário da rede, o serviço de destino e o acordo de testes o permitirem. Alterar o percurso de rede não cria o direito a conteúdo limitado a uma região nem a contornar uma decisão de acesso do serviço.

As sugestões rápidas de internacionalização do W3C recomendam UTF-8, idioma declarado do documento, formatos de dados locais, navegação visível entre idiomas, direção apropriada do texto da direita para a esquerda e validação. Converta estes princípios em verificações observáveis, por exemplo:

• o idioma escolhido sobrevive à navegação e a uma nova autenticação;
• datas, horas, números, nomes, moradas, ordenação e plurais utilizam a configuração regional pretendida;
• o texto traduzido pode expandir-se sem ser truncado nem ocultar controlos;
• o conteúdo multilingue e da direita para a esquerda preserva a ordem de leitura e de foco;
• os formulários aceitam e devolvem os conjuntos de caracteres pretendidos; e
• as ligações e as mensagens de erro permanecem compreensíveis sem depender de tradução automática.

Testes de acessibilidade

Mantenha separados os estados de acessibilidade quando isso melhorar a reprodutibilidade, mas não reduza a acessibilidade a uma predefinição do perfil. Teste o teclado, o foco, a ampliação, os leitores de ecrã, as preferências de contraste, o movimento reduzido, os erros e a autenticação acessível segundo as WCAG 2.2. A visão geral da avaliação do W3C afirma que as ferramentas ajudam, mas nenhuma consegue determinar, por si só, se um site é acessível; continua a ser necessária uma avaliação humana informada.

Manual de QA: verificação de uma versão regional

Autorização: o proprietário do produto aprova a origem de pré-produção, duas funções de teste, as configurações regionais suportadas, as datas dos testes e as contas sintéticas.

Perfis: um perfil limpo por par de função e configuração regional, acrescido de um perfil de atualização separado que conserva o estado da versão anterior.

Ações: autenticar através do percurso de teste suportado, executar verificações de navegação e formulários, inspecionar o comportamento do idioma e da acessibilidade, capturar artefactos de teste aprovados e parar corretamente cada perfil.

Provas: ID da compilação, versão do navegador, entradas de configuração regional e fuso horário, função, resultado do teste, detalhes ocultados dos erros e referências dos artefactos.

Condições de paragem: origem de produção inesperada, dados reais de clientes, permissão fora da função atribuída, degradação do serviço ou pedido de exportação do estado de uma sessão ativa.

Agências e operações de clientes

Limites de perfil úteis

As agências podem separar o trabalho por cliente, entidade jurídica, marca, ambiente, serviço de destino e função do operador. Isto pode reduzir ações acidentais entre clientes e tornar as transferências mais claras. O limite mais forte combina a separação de perfis com as funções de organização, permissões e acesso delegado do próprio serviço de destino.

Um fluxo de agência deve ter:

• uma autorização atual do cliente e um responsável identificado no cliente;
• um utilizador ou uma função delegada suportada pelo serviço para cada operador, quando disponível;
• um proprietário do perfil e um estado de transferência registado;
• pastas, etiquetas, extensões, proxies e regras de retenção específicas do cliente;
• aprovação para publicação, alterações de acesso, ações em massa, eliminação e despesas;
• um registo de auditoria visível para o cliente ou titular da conta adequado;
• um processo rápido para revogação, perda do dispositivo, alterações de pessoal e termo do contrato; e
• um plano de exportação e eliminação acordado antes da integração.

Evite partilhar credenciais em bruto como mecanismo de colaboração. Quando as ferramentas de teste ou automação guardarem estado autenticado, proteja-o como uma credencial. As orientações do Playwright sobre autenticação avisam que o estado guardado do navegador pode conter cookies e cabeçalhos capazes de representar a conta e não deve ser integrado em repositórios.

Manual de agência: transferência aprovada de conteúdo

Autorização: a declaração de trabalhos identifica o sistema de conteúdos controlado pelo cliente, a marca, os operadores, as operações de conteúdo permitidas, o responsável pela aprovação e a data de termo da colaboração.

Perfis: um espaço de trabalho do cliente com perfis separados de editor e publicador. Cada operador utiliza uma identidade individual no serviço; o perfil de publicador não é um cofre partilhado de palavras-passe.

Ações: o editor prepara um rascunho, o sistema regista uma pré-visualização e a revisão do conteúdo, o aprovador identificado do cliente aceita a revisão exata e o publicador envia-a uma vez.

Provas: interveniente, cliente, perfil, revisão do conteúdo, referência da aprovação, destino, resultado do envio e hora. Os valores do conteúdo só são conservados quando o acordo com o cliente e a política de dados o permitirem.

Recuperação: se a resposta se perder após o envio, verifique o sistema de destino antes de tentar novamente. Se a colaboração terminar, revogue o acesso, devolva os registos aprovados e elimine ou conserve os restantes dados dos perfis segundo o acordo.

Limites que continuam proibidos

O trabalho de clientes não justifica:

• criar contas, avaliações, interações ou identidades falsas;
• enviar spam ou mensagens não solicitadas em massa;
• aceder a uma conta depois de o cliente ou o proprietário do serviço retirar a autorização;
• comprar, recolher, repetir ou partilhar credenciais ou sessões roubadas;
• ocultar quem realizou uma ação perante uma investigação autorizada;
• contornar a aplicação de regras da plataforma para restaurar acesso proibido; ou
• operar fora dos direitos do cliente, da lei aplicável ou dos termos do serviço.

Se uma plataforma rejeitar uma ação, investigue a autorização e o processo de trabalho. Não trate um perfil, proxy ou percurso de automação como autorização para contornar a decisão.

Equipas de segurança e resposta a incidentes

O âmbito escrito vem primeiro

As equipas de segurança precisam de mais do que um pedido geral para «testar o site». O NIST SP 800-115 fornece orientações para planear e realizar testes técnicos de segurança, analisar resultados e desenvolver medidas de mitigação. O NIST define regras de execução do teste como restrições estabelecidas antes dos testes que dão à equipa autoridade para realizar atividades definidas.

As regras de execução do teste devem identificar:

• anfitriões, aplicações, APIs, inquilinos e contas exatos abrangidos;
• serviços de terceiros e dependências de produção expressamente excluídos;
• técnicas e ferramentas permitidas;
• redes ou dispositivos de origem dos testes, quando relevante;
• limites de calendário, ritmo, simultaneidade e impacto no serviço;
• contas de teste, funções e dados aprovados;
• ações proibidas, como persistência, engenharia social, alterações destrutivas ou negação de serviço;
• tratamento, encriptação, acesso, retenção e destruição das provas;
• contactos de incidentes e de emergência;
• condições de paragem imediata; e
• expectativas de relatórios, correções, novos testes e divulgação.

Se a demonstração exigir acesso ou impacto para além destas regras, pare e obtenha autorização escrita antes de continuar.

Limites de perfil úteis

Numa avaliação autorizada, os perfis separados podem isolar:

• o cliente A do cliente B;
• as identidades dos responsáveis pelos testes da navegação pessoal comum;
• cada função ou inquilino de teste;
• a validação passiva dos testes ativos aprovados;
• uma linha de base limpa de um estado de teste alterado;
• as provas de resposta a incidentes do trabalho operacional em curso; e
• o estado de um novo teste do resultado original.

Utilize os perfis para proteger o âmbito e as provas, não para ocultar a origem ou a finalidade dos testes. Não alterne entre perfis, redes ou identidades para contornar limites de ritmo, bloqueios ou outros controlos, salvo se o proprietário do sistema tiver incluído expressamente esse comportamento nas regras de execução do teste.

Manual de segurança: regressão autorizada do controlo de acesso

Autorização: o proprietário do sistema indica a aplicação de pré-produção, dois inquilinos de teste, funções normais e de administrador, pedidos permitidos, limite de ritmo, janela e contacto de emergência. A produção e a infraestrutura de identidade de terceiros estão excluídas.

Perfis: um perfil limpo para cada função e inquilino aprovados. Cada um contém dados sintéticos de teste e uma identidade de teste emitida pelo serviço.

Ações: verifique que cada função consegue aceder aos recursos esperados e, depois, execute os casos negativos aprovados que confirmam que as restantes funções e inquilinos recebem uma recusa. Utilize o número mínimo de pedidos necessário para reproduzir um resultado.

Provas: versões da aplicação e do navegador, caso de teste, interveniente, referências do inquilino e da função, IDs de correlação dos pedidos, provas ocultadas da resposta, hora e resultado. Não conserve registos não relacionados encontrados durante os testes.

Condições de paragem: aparecem dados pessoais ou de produção, o serviço fica instável, um teste sai do inquilino indicado, são expostas credenciais fora do conjunto de teste ou o proprietário retira a autorização.

Recuperação: pare os pedidos ativos, notifique o contacto indicado, conserve as provas mínimas e protegidas, revogue as credenciais de teste, restaure o estado de teste e documente se é seguro repetir o teste.

A autorização tem várias camadas

Utilize esta tabela de decisão quando a autorização não for clara:

Situação	Decisão
A empresa é proprietária do sistema de pré-produção, o plano de testes identifica a conta e as ações e o operador possui a função atribuída	Prosseguir dentro dos limites documentados
Um cliente pede a uma agência que gira uma conta através das funções suportadas pelo serviço e o contrato abrange o trabalho	Prosseguir com acesso nominal, aprovação, auditoria e controlos de saída
Um cliente pede acesso a uma conta de terceiros que não possui nem controla	Parar; o cliente não pode conceder essa autorização
Um contacto de segurança manifesta incentivo geral, mas não fornece uma lista de recursos nem um âmbito de testes	Parar; obter regras de execução do teste por escrito
Uma sessão válida permanece depois de uma pessoa sair da equipa	Parar e revogá-la; o acesso técnico sobreviveu à autorização
Um teste encontra credenciais reais ou dados pessoais fora do conjunto aprovado	Parar, minimizar o acesso, proteger as provas e notificar o contacto indicado
Uma plataforma bloqueia uma ação e a resposta proposta é mudar de perfis ou proxies	Parar; não utilizar o isolamento para contornar a aplicação de regras
Um fluxo cria interações falsas, spam, fraude, phishing, roubo de credenciais ou acesso não autorizado	Proibido

O que a separação de perfis não consegue estabelecer

Um limite de perfil pode reduzir a mistura acidental de estado. Não consegue, por si só, provar que:

• o operador está autorizado;
• a identidade da conta é genuína;
• o navegador representa um dispositivo físico separado;
• uma configuração regional simulada representa um residente ou um direito regional legítimo;
• um proxy autoriza o acesso a partir da localização aparente;
• as extensões ou o endpoint são fidedignos;
• um site aceitará a sessão; ou
• um teste de segurança está dentro do âmbito.

Trate o perfil como um controlo dentro de um sistema mais amplo de identidade, autorização, tratamento de dados, auditoria, recuperação, contratos e revisão humana. Quando qualquer destas camadas deixar de ser clara, uma operação segura significa parar e resolver a ambiguidade antes de continuar.