Compartilhar trabalho no navegador sem compartilhar credenciais em bruto

As equipes dizem muitas vezes que precisam de «compartilhar 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 senha.

O que conta como credencial em bruto

Os exemplos óbvios são senhas, códigos de recuperação, sementes de senhas de uso único, chaves privadas e senhas 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;
• registros do gerenciador de senhas 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 pacote de perfil criptografado no dispositivo só oculta as credenciais do provedor de armazenamento se ele não tiver a chave de descriptografia. Isso também reduz a exposição a quem possa vê-las por acaso. Quando o dispositivo de um destinatário autorizado descriptografa e abre o perfil, o navegador continua podendo usar as permissões da sessão. A transferência passa essa autoridade ao destinatário, mesmo que ele nunca leia um cookie.

Separe a tarefa da autoridade

Antes de escolher um mecanismo de compartilhamento, 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é o 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, compartilhar 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 equipe, 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 controles 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 gerenciador do navegador não consegue converter de forma confiável a sessão de administrador compartilhada de um site numa função de revisor no nível desse site.

As contas compartilhadas e de grupo reduzem a responsabilidade. O NIST SP 800-53 Rev. 5 recomenda que as organizações restrinjam seu uso 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 senha 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. Uso intermediado de um segredo guardado

Alguns serviços antigos disponibilizam apenas uma credencial compartilhada. Um intermediário de credenciais ou gerenciador de senhas 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 controles 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, controles 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 compartilhado 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 controles 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;
• criptografia 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 senha, cookie, código de recuperação, passkey ou arquivo de perfil para uma mensagem, planilha, 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 criptografia da mensagem como substituto da responsabilidade individual ou de um registro 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 compartilhado e intermediado	Muitas vezes, não, após o início de sessão	Limitado pela conta compartilhada	Rodar o segredo e terminar as sessões	Identidade compartilhada no site e sessões ativas
Sessão criptografada do navegador	Normalmente, não, no serviço de destino	No nível do perfil e frequentemente amplo	Revogar o compartilhamento 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 confiá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 senha» é 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 no compartilhamento

O WebAuthn cria uma credencial de chave pública limitada a uma entidade usuária. 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 equipe. Um serviço de destino pode registrar uma credencial separada para cada membro identificado, preservando o acesso individual. Um fornecedor de passkeys também pode suportar sincronização ou compartilhamento de chaves de autenticação. O NIST SP 800-63B-4 reconhece esse modelo e identifica riscos como uso não autorizado de chaves, proliferação por dispositivos, comprometimento do mecanismo de sincronização e revogação difícil.

Numa equipe autorizada, prefira uma conta e um autenticador nominais no serviço por pessoa. Se uma passkey compartilhada for o único modelo suportado, trate-a como um autenticador compartilhado, documente quem a pode receber e em que dispositivos gerenciados e verifique como o fornecedor apresenta, revoga e recupera as chaves compartilhadas. O serviço de destino pode continuar a registrar 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á agindo? Utilize uma identidade nominal da organização, nunca uma etiqueta genérica de operador.
2. Quem autorizou? Registre o proprietário ou a decisão da política sem guardar segredos de aprovação.
3. O que é compartilhado? Identifique o perfil e a tarefa. Evite um inventário em bruto dos respectivos cookies ou credenciais.
4. O que pode fazer o destinatário? Separe permissões de inicialização, edição, exportação, automação, compartilhamento e administração.
5. Onde pode ser executado? Limite o acesso a dispositivos registrados 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 é registrado? Registre interveniente, dispositivo, referência do perfil, ação, resultado e hora. Exclua por padrão os valores secretos e o conteúdo das páginas.
9. Como é revogado? Abarque tanto a concessão de compartilhamento 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 criptografia pertence a este contrato. Protege os dados durante o armazenamento ou a transferência. A autorização decide quem pode obter o percurso de descriptografia. A confiança no dispositivo e o isolamento local protegem o uso. A auditoria apoia a responsabilidade e a investigação. Nenhum destes controles 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, senhas, 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, o compartilhamento 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 confiáveis. Uma instrução numa página não pode conseguir convencer um agente a revelar material de sessão através de registros, resultados de ferramentas, capturas de tela 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 descriptografado, e uma sessão copiada ou ainda em execução pode continuar.

Quando o acesso termina normalmente:

1. revogue a concessão da equipe e feche a concessão do perfil;
2. remova o material local criptografado segundo a política de retenção;
3. termine a sessão relevante no serviço de destino, quando suportado;
4. remova a associação da pessoa ou a concessão delegada 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 compartilhados 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 criptografia no cliente protege os dados guardados e transmitidos, mas um endpoint autorizado tem de descriptografar o que o navegador precisa.
• Um bloqueio do navegador controla a simultaneidade no nível do produto, não todas as ações no serviço de destino.
• Uma sessão compartilhada costuma dar ao serviço de destino uma identidade de conta, independentemente de o produto de navegador ter um registro de auditoria mais rico.
• Um dispositivo ou extensão comprometidos podem agir através de uma sessão válida sem extrair uma senha 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 do compartilhamento de sessões. Ocultar as credenciais reduz a divulgação; não reduz a autoridade que o navegador pode exercer.