Automação de privilégio mínimo para perfis do navegador

Comece por um perímetro de autorização

O NIST define o privilégio mínimo como a restrição dos utilizadores, e dos processos que atuam por eles, ao acesso mínimo necessário para as tarefas atribuídas. Uma única função como automation é, por isso, demasiado ampla para o trabalho com perfis do navegador. Indica quem chama o sistema, mas não que perfil pode abrir, que site pode contactar, o que pode alterar nem durante quanto tempo a permissão é válida.

Um perímetro de autorização útil tem oito dimensões:

Dimensão	Pergunta a responder	Predefinição robusta
Interveniente	Que pessoa, carga de trabalho ou agente iniciou a tarefa?	Uma identidade atribuível por pessoa ou carga de trabalho
Inquilino	Que limite de organização ou cliente se aplica?	Uma organização; sem acesso entre inquilinos
Conjunto de perfis	Que perfis exatos podem ser utilizados?	IDs explícitos ou um seletor de pasta/etiqueta revisto
Operação	O que pode fazer a automação?	Ações de domínio com nome, não primitivas de ficheiros ou processos
Destino	Que sites, APIs ou ambientes pode contactar?	Apenas origens e ambientes aprovados
Tempo	Quando começa e expira a autoridade?	Credenciais de curta duração e duração limitada da tarefa
Ritmo	Quanto trabalho pode realizar?	Limites de simultaneidade, pedidos e custos
Efeito secundário	O que pode alterar, publicar, eliminar ou gastar?	Primeiro apenas leitura; aprovação para ações de maior impacto

A decisão da política deve ser avaliada em cada comando. O arranque bem-sucedido de um perfil não pode conceder silenciosamente a exportação de cookies, a administração da equipa, alterações de faturação ou autorização para agir em qualquer site que o navegador consiga alcançar.

Separe três tipos de autoridade

A automação do navegador combina muitas vezes três credenciais diferentes num único fluxo:

1. A credencial de automação autoriza chamadas ao gestor de perfis ou ao serviço de automação.
2. O estado da sessão do perfil pode autenticar uma pessoa ou uma conta de teste num site.
3. A delegação do serviço de destino determina o que essa conta pode fazer no site.

Estas credenciais não são intercambiáveis. Um token de automação não deve conter nem revelar os cookies do perfil. Um perfil autenticado não demonstra que quem chama está autorizado a realizar todas as ações disponíveis no site. Uma palavra-passe do site ou token OAuth não deve ser reutilizado como credencial do gestor de perfis.

Esta separação importa porque o estado autenticado do navegador é, por si só, sensível. O Playwright avisa que o estado guardado pode conter cookies e cabeçalhos capazes de representar a conta de teste. Trate esse estado como um artefacto com segredos: mantenha-o fora do controlo de versões, dos registos correntes, das transcrições de chat, dos sistemas de acompanhamento de problemas e dos resultados gerais de automação.

O controlo remoto do navegador exige o mesmo cuidado. A partir do Chrome 136, o Chrome deixou de respeitar os parâmetros de depuração remota no diretório de dados predefinido e recomendou um diretório de dados do utilizador personalizado para isolar a depuração de perfis reais. No seu aviso de segurança de 17 de março de 2025, a Google indicou a extração de cookies através da depuração remota como motivo para a alteração. Não ligue a automação ao perfil de navegação diário de uma pessoa como atalho.

Classifique as ações antes de atribuir permissões

A superfície de controlo deve expressar ações do trabalho e o respetivo risco, em vez de expor uma ligação sem restrições ao navegador.

Classe de ação	Exemplos	Controlo predefinido
Observar	Enumerar perfis permitidos, ler o estado de funcionamento, ver um estado ocultado	Permitir com um âmbito de leitura estreito
Ciclo de vida	Iniciar, parar, adquirir a concessão de um perfil, criar uma captura de teste	Permitir apenas nos perfis indicados; registar cada transição
Interagir	Navegar para uma origem aprovada, executar um teste definido, transferir um artefacto de teste	Restringir destinos, entradas, percursos de saída e duração
Alto impacto	Enviar conteúdo, repor dados de teste, alterar acessos, gerar custos, eliminar um perfil	Pré-visualização, aprovação explícita e política mais rigorosa
Com segredos	Exportar cookies, credenciais, palavras-passe de proxy, material de recuperação ou estado do perfil em bruto	Recusar através das interfaces normais de automação

O risco depende do contexto. Enviar um formulário para uma conta de teste descartável pode ser um teste corrente; a mesma ação numa conta de produção pode criar consequências jurídicas, financeiras ou reputacionais. Associe a decisão ao ambiente, à conta e à alteração exata proposta.

Emita credenciais restritas e de curta duração

Utilize uma identidade de serviço distinta para cada carga de trabalho. Não empreste a sessão de um administrador humano à integração contínua (CI), a um script local ou a um agente. Um token útil é limitado por:

• organização e, quando relevante, cliente ou espaço de trabalho;
• IDs de perfis, pastas, etiquetas ou outros seletores de recursos estáveis;
• operações permitidas;
• serviço ou destinatário pretendido;
• hora de emissão, validade e estado de revogação;
• identidade do dispositivo ou carga de trabalho quando a plataforma o suportar; e
• limites de simultaneidade, ritmo e custos.

A RFC 9700 recomenda restringir os privilégios dos tokens de acesso ao mínimo necessário, incluindo o servidor de recursos, os recursos e as ações pretendidos. Também explica por que razão a restrição do destinatário reduz o impacto de um token divulgado. A atual especificação de autorização do Model Context Protocol (MCP) também exige a validação do destinatário e indica aos clientes que peçam apenas os âmbitos necessários à operação pretendida.

Prefira a autorização incremental. Inicie uma tarefa com direitos de descoberta e pré-visualização. Se um passo posterior precisar de uma permissão superior, peça uma nova concessão de curta duração para esse passo. Não emita um token permanente com acesso total porque um ramo do fluxo poderá vir a precisar dele.

Num MCP ou noutro intermediário, mantenha separadas as credenciais a montante. As considerações de segurança da autorização do MCP exigem tokens específicos de recursos e proíbem a transmissão do token MCP recebido para uma API a montante. A conclusão mais ampla aplica-se a qualquer porta de entrada de automação: cada limite de confiança valida a sua própria credencial e emite ou obtém apenas a autoridade a jusante necessária para a ação aprovada.

Torne a aprovação específica e verificável

Uma aprovação deve responder a «aprovar o quê?». Uma confirmação genérica como «permitir este agente» pode autorizar mais do que o revisor compreendeu.

Para um comando de alto impacto, apresente uma pré-visualização que contenha:

• o interveniente e a carga de trabalho que iniciaram a ação;
• a organização, o perfil, a conta de destino e o destino;
• uma descrição inteligível da alteração proposta;
• os recursos exatos afetados e o número máximo;
• o custo ou efeito externo esperado, quando exista;
• os valores que mudarão, com os segredos ocultados;
• o percurso de reversão ou recuperação;
• uma validade curta da aprovação; e
• a razão pela qual a ação não pode prosseguir com menor privilégio.

Vincule a aprovação a um resumo criptográfico do pedido normalizado, à versão da política e à versão do perfil. Torne-a de utilização única quando a ação for irreversível ou externamente visível. Se o pedido, o destino, o número de recursos ou o estado relevante mudarem, invalide a aprovação e apresente uma nova pré-visualização.

A aprovação não substitui a autorização. Um revisor não pode conceder direitos que a organização não possui, e um pedido não deve transformar um fluxo proibido num fluxo aceitável.

Conceba a execução para falhar em segurança

O privilégio mínimo também limita o que acontece depois de um erro. O contrato de execução deve incluir concessões de perfis, pré-condições, novas tentativas limitadas, cancelamento e comportamento de recuperação.

Falha	Resposta segura
Permissão recusada	Parar. Comunicar a permissão em falta sem a aumentar automaticamente.
Perfil já em utilização	Não iniciar um segundo processo de escrita. Esperar dentro de um limite ou devolver um conflito claro.
Concessão perdida durante uma execução	Interromper novas ações, conservar provas ocultadas e encaminhar o perfil pelo percurso de recuperação.
Tempo limite da rede antes de uma leitura	Tentar novamente apenas dentro do limite e prazo declarados.
Ligação perdida após um envio	Marcar o resultado como desconhecido. Não repetir a ação, salvo se o destino fornecer um mecanismo seguro de idempotência.
Aprovação expirada ou pedido alterado	Cancelar a ação e pedir uma nova pré-visualização e aprovação.
Destino da auditoria indisponível	Seguir uma política declarada. As ações de alto impacto devem normalmente falhar de forma fechada; os eventos de baixo risco podem utilizar uma memória intermédia local protegida e limitada.
Falha na verificação da captura ou do restauro	Colocar em quarentena o estado afetado. Não substituir a última versão em bom estado conhecida.

Cada comando que altere estado deve definir se é idempotente, que pré-condição verifica e como quem o chama pode descobrir o resultado final após uma interrupção. «Tentar novamente perante qualquer erro» é inseguro para envios, compras, eliminações, convites e alterações de permissões.

Registe decisões sem registar segredos

Um evento de auditoria deve permitir reconstruir uma ação sem se transformar num segundo cofre de credenciais. As orientações da OWASP sobre registos recomendam registar falhas de autorização e operações de maior risco, capturar «quando, onde, quem e o quê» e proteger o acesso aos dados dos registos. Também avisam que os registos podem expor palavras-passe e outros segredos técnicos.

Para cada decisão de automação, registe:

• as identidades dos intervenientes humano, de serviço e delegado;
• a organização e uma referência ocultada do perfil;
• o nome do comando, ID do pedido e chave de idempotência, quando aplicável;
• a versão da política, a decisão e o código do motivo;
• a referência da aprovação e o aprovador de uma ação aprovada;
• o destino ocultado e o número de recursos;
• a hora de início, a hora de conclusão e o resultado;
• as versões do navegador, do cliente e do adaptador de automação; e
• o estado de recuperação, cancelamento ou revisão manual.

Não registe valores de cookies, palavras-passe, tokens de acesso ou atualização, cabeçalhos de autorização, credenciais de proxy, chaves de encriptação, conteúdo integral das páginas, valores de formulários nem arquivos de perfis em bruto. Minimize os URLs, pois os percursos e parâmetros de consulta podem conter dados pessoais ou segredos. Proteja o acesso à auditoria, defina a retenção e teste o que acontece quando os registos estão lentos, cheios ou indisponíveis.

Um exemplo concreto de política

O pseudocódigo seguinte é um exemplo de desenho, não uma configuração do Isoline. Autoriza uma carga de trabalho de CI a executar testes rápidos regionais em perfis de pré-produção e nada mais:

principal: "workload:regional-smoke-tests"
tenant: "org:example-studio"
profiles:
  selector: "tag == qa-staging"
operations:
  allow:
    - "profile.read"
    - "profile.launch"
    - "test.run-approved-suite"
    - "profile.stop"
  deny:
    - "profile.export-session-state"
    - "profile.delete"
    - "team.manage"
destinations:
  allow:
    - "https://staging.example.test"
conditions:
  expiresAt: "2026-08-26T18:00:00Z"
  maxConcurrentProfiles: 2
  maxRuns: 20
  requireCleanStop: true
approvals:
  "staging-data.reset": "single-use-human-approval"
onUnknownSideEffect: "stop-and-review"

A política não concede navegação geral, acesso à produção, exportação de segredos, administração da equipa nem a capacidade ilimitada de acrescentar âmbitos. Se o teste rápido precisar de uma nova origem ou operação, a alteração passa por uma revisão da política, em vez de ser inferida durante a execução.

Lista de verificação

Antes de ativar um fluxo de automação de perfis do navegador, confirme que:

• o proprietário do sistema e, quando aplicável, o cliente documentaram a finalidade permitida;
• cada pessoa e carga de trabalho tem uma identidade atribuível;
• o token é limitado por inquilino, perfil, operação, destinatário, tempo e ritmo;
• as contas de destino têm apenas as funções necessárias para a tarefa;
• os perfis pessoais de utilização corrente estão excluídos;
• o estado da sessão e outros segredos não podem aparecer através de leituras ou registos normais;
• as ações de alto impacto têm pré-visualizações específicas e aprovações que expiram;
• o bloqueio do perfil impede vários processos de escrita simultâneos;
• os comandos que alteram estado definem pré-condições, idempotência e tratamento de resultados desconhecidos;
• foram testados os percursos de cancelamento, revogação, interrupção e restauro;
• o registo de auditoria permite reconstruir decisões sem expor conteúdo sensível; e
• o fluxo para quando a autorização é retirada ou o serviço de destino recusa a ação.

Limitações

O privilégio mínimo reduz o impacto dos erros e da divulgação de credenciais; não torna aceitável um fluxo não autorizado nem garante que um serviço de terceiros permita uma ação. A separação de contextos do navegador pode melhorar o isolamento dos testes, como descreve a documentação do Playwright sobre contextos do navegador, mas não transforma uma máquina em vários dispositivos com confiança independente. Um endpoint comprometido, uma extensão maliciosa, uma conta de destino com privilégios excessivos ou um serviço a jusante inseguro podem continuar a violar o limite pretendido.

Reveja as permissões quando os fluxos mudarem. Remova âmbitos não utilizados, faça expirar credenciais inativas, volte a testar os percursos de recusa e trate qualquer pedido de material de sessão em bruto como uma revisão de segurança separada e de alto risco, não como uma função corrente de automação.