Partilhar trabalho no navegador sem partilhar credenciais em bruto

As equipas dizem muitas vezes que precisam de «partilhar um início de sessão» quando a necessidade real é mais estreita: rever um rascunho, atualizar uma loja autorizada, reproduzir uma falha regional ou dar continuidade a um fluxo de apoio. Partir da tarefa cria mais opções do que partir da palavra-passe.

O que conta como credencial em bruto

Os exemplos óbvios são palavras-passe, códigos de recuperação, sementes de palavras-passe de utilização única, chaves privadas e palavras-passe de proxy. O trabalho no navegador introduz também credenciais menos visíveis:

• cookies de autenticação e identificadores de sessão;
• tokens OAuth de acesso e atualização;
• registos do gestor de palavras-passe e dados de preenchimento automático;
• material de chaves privadas de passkeys ou acesso ao autenticador que o detém;
• estado de dispositivo de confiança e de recuperação; e
• um arquivo de perfil que contenha qualquer um dos elementos anteriores.

As orientações do NIST sobre sessões descrevem uma sessão do navegador como uma continuidade baseada na posse de um segredo de sessão. A Folha de referência da OWASP sobre gestão de sessões torna clara a consequência operacional: enquanto for válido, um token de sessão pode equivaler à autenticação mais forte que o criou.

Um conjunto de perfil encriptado não expõe esses valores ao fornecedor de armazenamento nem a um observador ocasional. Depois de o dispositivo de um destinatário autorizado desencriptar e iniciar o perfil, o navegador continua a poder exercer a sessão. A transferência passou a autoridade, mesmo que o destinatário nunca leia um cookie.

Separe a tarefa da autoridade

Antes de escolher um mecanismo de partilha, escreva uma pequena declaração de acesso:

O operador identificado A pode realizar as ações B no recurso C, a partir do dispositivo aprovado D, até ao momento E, segundo a regra de aprovação e auditoria F.

Esta frase torna visível a autoridade desnecessária. Se a tarefa for «aprovar este rascunho», uma sessão administrativa completa é excessiva. Se o serviço de destino já suportar uma função de revisor, partilhar o estado do navegador acrescenta risco sem acrescentar capacidade.

A Arquitetura de Confiança Zero do NIST recomenda o acesso a recursos individuais por sessão e com os privilégios mínimos necessários à tarefa. Este princípio aplica-se sem adotar um produto chamado «confiança zero». É um teste de desenho útil para qualquer transferência no navegador.

Prefira estes modelos por ordem

1. Acesso nominal no serviço de destino

Utilize as funcionalidades de equipa, organização, função, delegação ou aprovação do próprio site ou da entidade responsável pela aplicação, quando existam. Cada pessoa autentica-se com uma conta e um autenticador individuais. O serviço de destino pode então impor as suas permissões, atribuir ações ao operador, aplicar os seus controlos de risco e revogar uma pessoa sem alterar a credencial de todas.

Este é geralmente o modelo mais forte, pois a autorização existe onde a ação é compreendida. Um gestor do navegador não consegue converter de forma fiável a sessão de administrador partilhada de um site numa função de revisor ao nível desse site.

As contas partilhadas e de grupo reduzem a responsabilidade. O NIST SP 800-53 Rev. 5 recomenda que as organizações restrinjam a sua utilização e definam condições explícitas antes de a permitirem.

2. Delegação limitada pelo serviço de destino

Quando um serviço disponibilizar OAuth ou outro protocolo de delegação, conceda a um cliente ou interveniente apenas os recursos, as ações e a duração necessários. A RFC 9700 recomenda restringir os privilégios dos tokens de acesso ao mínimo necessário e limitar o destinatário ao servidor de recursos pretendido.

Prefira concessões de curta duração, revogáveis e limitadas ao destinatário. Os tokens vinculados ao remetente podem reduzir a repetição caso um token seja divulgado, mas não ajudam quando um atacante obtém o token e o material de chave a que está vinculado. O dispositivo e o software do cliente permanecem dentro do limite de ameaça.

A delegação é particularmente útil na automação, pois um script pode receber autorização para uma operação definida sem receber a palavra-passe ou a sessão geral do navegador de uma pessoa. O evento de auditoria deve identificar a pessoa que iniciou a ação, o interveniente delegado, o recurso, o âmbito e o resultado.

3. Utilização intermediada de um segredo guardado

Alguns serviços antigos disponibilizam apenas uma credencial partilhada. Um intermediário de credenciais ou gestor de palavras-passe controlado pode reduzir a cópia, permitindo a um fluxo aprovado no navegador utilizar um segredo sem o mostrar em chats, pedidos, documentos ou resultados normais da aplicação.

Isto melhora a custódia, a rotação e a análise do acesso, mas não corrige o modelo de contas do serviço de destino. Depois do início de sessão, todos os operadores podem continuar a agir como a mesma identidade no site. A sessão resultante permanece sensível e precisa dos seus próprios controlos de tempo limite, revogação e dispositivo.

A Folha de referência da OWASP sobre gestão de segredos recomenda acesso preciso, interação humana mínima com valores secretos, controlos do ciclo de vida e auditoria de quem pediu e utilizou um segredo. Sempre que possível, um produto de navegador deve integrar-se através de uma referência opaca, em vez de se tornar outro armazenamento geral de segredos.

4. Transferência protegida de uma sessão do navegador

Utilize um perfil autenticado partilhado apenas quando o serviço de destino não tiver delegação adequada e o fluxo autorizado exigir realmente a continuidade da sessão. Esta é a transferência normal de maior risco, pois o destinatário recebe a capacidade de agir através da conta ativa.

Os controlos mínimos incluem:

• um proprietário explícito e um destinatário aprovado;
• uma tarefa, um recurso e uma hora de validade declarados;
• um único processo de escrita ativo ou um modelo de conflitos testado;
• encriptação no cliente antes de qualquer carregamento na nuvem;
• autorização do dispositivo do destinatário e proteção local;
• um bloqueio que impeça trabalho simultâneo ambíguo;
• eventos de auditoria relativos à concessão, transferência, abertura, ação sensível, fecho, revogação e recuperação;
• interfaces normais que devolvem estado ocultado em vez de cookies ou tokens; e
• um plano de revogação da sessão no serviço de destino.

Este modelo pode proteger o valor da credencial contra cópias casuais e armazenamento na nuvem. Não permite ao serviço de destino distinguir duas pessoas que utilizam a mesma conta autenticada. Também não protege a sessão contra software malicioso, uma extensão maliciosa ou um destinatário autorizado que utilize indevidamente a autoridade concedida.

5. Transferência de credenciais em bruto

Copiar uma palavra-passe, cookie, código de recuperação, passkey ou arquivo de perfil para uma mensagem, folha de cálculo, pedido, script ou exportação não protegida cria um segredo duradouro, com cópias pouco claras e revogação fraca. Evite fazê-lo.

Se um processo antigo excecional exigir uma transferência, trate-a segundo o procedimento de credenciais aprovado pela organização, minimize os destinatários e a duração e rode ou revogue a credencial posteriormente. Não trate a encriptação da mensagem como substituto da responsabilidade individual ou de um registo de todas as cópias.

Compare a autoridade, não apenas a conveniência

Modelo	O serviço de destino identifica o operador	O âmbito pode corresponder à tarefa	Limite de revogação	Principal risco restante
Membro nominal do serviço de destino	Normalmente, sim	Normalmente, o mais forte	Remover um membro ou uma função	Permissões excessivas no serviço de destino
Token delegado com âmbito limitado	O interveniente e o cliente podem ser representados	Forte quando os âmbitos e o destinatário são estreitos	Revogar a concessão ou o token	Comprometimento do token, cliente ou chave
Início de sessão partilhado e intermediado	Muitas vezes, não, após o início de sessão	Limitado pela conta partilhada	Rodar o segredo e terminar as sessões	Identidade partilhada no site e sessões ativas
Sessão encriptada do navegador	Normalmente, não, no serviço de destino	Ao nível do perfil e frequentemente amplo	Revogar a partilha e a sessão de destino	O dispositivo do destinatário pode exercer toda a autoridade da sessão
Cópia de credencial em bruto	Sem identidade individual fiável	Normalmente amplo	Encontrar cópias, rodar e terminar sessões	Cópias desconhecidas e responsabilidade fraca

A tabela explica por que razão «ninguém consegue ver a palavra-passe» é um critério de êxito incompleto. O resultado importante é quanta autoridade o destinatário pode exercer, durante quanto tempo e que sistema a pode revogar.

As passkeys melhoram a autenticação, mas exigem cuidado na partilha

O WebAuthn cria uma credencial de chave pública limitada a uma entidade utilizadora. A especificação WebAuthn Nível 3 indica que o autenticador detém a chave privada e o script do site recebe resultados assinados, não a própria credencial privada. Isto proporciona autenticação resistente a phishing quando a implementação é correta.

As passkeys não criam automaticamente funções de equipa. Um serviço de destino pode registar uma credencial separada para cada membro identificado, preservando o acesso individual. Um fornecedor de passkeys também pode suportar sincronização ou partilha de chaves de autenticação. O NIST SP 800-63B-4 reconhece esse modelo e identifica riscos como utilização não autorizada de chaves, proliferação por dispositivos, comprometimento do mecanismo de sincronização e revogação difícil.

Numa equipa autorizada, prefira uma conta e um autenticador nominais no serviço por pessoa. Se uma passkey partilhada for o único modelo suportado, trate-a como um autenticador partilhado, documente quem a pode receber e em que dispositivos geridos e verifique como o fornecedor apresenta, revoga e recupera as chaves partilhadas. O serviço de destino pode continuar a registar todas as ações numa única conta.

Defina a transferência no navegador como um contrato

Uma transferência controlada deve responder a estas perguntas antes de mover o estado do perfil:

1. Quem está a agir? Utilize uma identidade nominal da organização, nunca uma etiqueta genérica de operador.
2. Quem autorizou? Registe o proprietário ou a decisão da política sem guardar segredos de aprovação.
3. O que é partilhado? Identifique o perfil e a tarefa. Evite um inventário em bruto dos respetivos cookies ou credenciais.
4. O que pode fazer o destinatário? Separe permissões de arranque, edição, exportação, automação, partilha e administração.
5. Onde pode ser executado? Limite o acesso a dispositivos registados e de confiança adequados aos dados.
6. Durante quanto tempo? Defina uma validade e encerre sessões inativas.
7. Podem agir dois processos de escrita? Utilize um único processo ativo, salvo se o comportamento dos conflitos tiver sido deliberadamente concebido e testado.
8. O que é registado? Registe interveniente, dispositivo, referência do perfil, ação, resultado e hora. Exclua por predefinição os valores secretos e o conteúdo das páginas.
9. Como é revogado? Abranja tanto a concessão de partilha do navegador como a sessão do serviço de destino.
10. Como é recuperado? Preserve uma última versão em bom estado conhecida sem restaurar acidentalmente uma autorização revogada.

A encriptação pertence a este contrato. Protege os dados durante o armazenamento ou a transferência. A autorização decide quem pode obter o percurso de desencriptação. A confiança no dispositivo e o isolamento local protegem a utilização. A auditoria apoia a responsabilidade e a investigação. Nenhum destes controlos substitui os restantes.

Mantenha a automação fora do limite dos segredos

As APIs, os SDK, as ferramentas de linha de comandos e os agentes precisam muitas vezes de iniciar um perfil ou realizar uma ação aprovada do ciclo de vida. Raramente precisam de valores de cookies, palavras-passe, passkeys, credenciais de proxy ou um arquivo do perfil em bruto.

Uma interface limitada pode aceitar uma referência opaca de perfil ou segredo e devolver:

• se a ação foi autorizada;
• um estado ocultado como pronto, bloqueado, expirado ou revogado;
• uma referência de processo ou sessão com duração limitada;
• um erro estruturado e um passo de recuperação; e
• uma referência do evento de auditoria.

Não deve devolver uma credencial apenas porque quem chama pode iniciar o perfil. A exportação, a partilha em massa ou outra operação que contenha segredos precisa de uma política separada e, quando adequado, de aprovação explícita.

O conteúdo dos sites e as entradas da automação também permanecem não fidedignos. Uma instrução numa página não pode conseguir convencer um agente a revelar material de sessão através de registos, resultados de ferramentas, capturas de ecrã ou um canal de apoio.

A revogação tem duas camadas

Remover um colaborador de um espaço de trabalho do navegador impede o futuro acesso autorizado por esse espaço. Não demonstra que a sessão no serviço de destino é inválida. Um dispositivo pode já possuir estado desencriptado, e uma sessão copiada ou ainda em execução pode continuar.

Quando o acesso termina normalmente:

1. revogue a concessão da equipa e feche a concessão do perfil;
2. remova o material local encriptado segundo a política de retenção;
3. termine a sessão relevante no serviço de destino, quando suportado;
4. remova a qualidade de membro ou a concessão delegada da pessoa no serviço de destino; e
5. conserve provas de auditoria ocultadas durante o período aprovado.

Quando houver suspeita de comprometimento, coloque também em quarentena as versões afetadas do perfil, revogue sessões e tokens ativos, remova autenticadores não autorizados, rode segredos partilhados expostos e reveja os eventos de auditoria. Restaurar uma captura mais antiga do perfil pode restaurar um segredo de sessão antigo, pelo que a recuperação deve respeitar o estado de revogação.

Limites que permanecem após uma transferência cuidadosa

• A encriptação no cliente protege os dados guardados e transmitidos, mas um endpoint autorizado tem de desencriptar o que o navegador precisa.
• Um bloqueio do navegador controla a simultaneidade ao nível do produto, não todas as ações no serviço de destino.
• Uma sessão partilhada costuma dar ao serviço de destino uma identidade de conta, independentemente de o produto de navegador ter um registo de auditoria mais rico.
• Um dispositivo ou extensão comprometidos podem agir através de uma sessão válida sem extrair uma palavra-passe legível.
• Revogar uma concessão do espaço de trabalho e revogar uma sessão no site são operações distintas.
• Os termos do serviço de destino, o contrato do cliente e a lei aplicável continuam a determinar se um fluxo pode ser delegado.
• Alguns serviços não disponibilizam uma alternativa segura ao acesso individual. Nesse caso, reduzir o âmbito ou recusar a transferência pode ser o resultado responsável.

A RFC 6265 descreve os cookies como autoridade ambiente: um navegador pode anexá-los a um pedido mesmo quando a parte que causa o pedido não conhece o valor do cookie. Esta é a limitação central da partilha de sessões. Ocultar as credenciais reduz a divulgação; não reduz a autoridade que o navegador pode exercer.