7 min de leitura
Identidades compartilhadas de equipe: uma identidade, muitas pessoas
Uma equipe pode compartilhar uma identidade CardanoWall compartilhando seu Identity Seed — mas isso entrega a cada detentor todo o poder de assinatura e decifração, sem revogação parcial ou por pessoa.
Uma equipe pode compartilhar uma identidade CardanoWall, mas compartilhar uma identidade significa compartilhar o Identity Seed. Não existe uma versão mais leve disso.
Entregar a semente é uma delegação completa. Qualquer pessoa que a detenha pode assinar registros como aquela identidade e decifrar registros selados endereçados a ela. A CardanoWall consegue tornar o fluxo de trabalho confortável entre contas separadas, mas não consegue transformar uma semente em autoridade parcial, revogável e individual. A criptografia não se dobra a isso.
Então use uma identidade compartilhada apenas quando autoridade compartilhada for exatamente o que você quer.
O que é uma identidade compartilhada de equipe?
É uma identidade Label 309 usada por mais de uma pessoa ou conta.
Uma identidade Label 309 tem como raiz um único Identity Seed de 32 bytes. Quem importa essa semente reconstrói a mesma chave de assinatura e as mesmas chaves de recebimento, em qualquer conta e em qualquer ferramenta compatível. A identidade não está atrelada a uma conta CardanoWall, porque a semente sozinha a define.
Uma redação poderia operar uma identidade "Equipe de Imprensa" dessa forma. O editor-chefe cria a identidade, salva a semente e a compartilha com colegas selecionados por um canal confiável. Cada colega importa a semente em sua própria conta e a desbloqueia com suas próprias passkeys. A partir daí, todos eles detêm a mesma identidade criptográfica.
O que cada detentor da semente pode fazer?
Tudo o que a identidade pode fazer. A semente é a raiz, não uma permissão limitada.
Cada detentor pode:
- assinar novos registros Label 309 como a identidade;
- decifrar registros selados endereçados à identidade;
- ler registros selados recebidos assim que os desbloqueia;
- exportar a semente novamente e repassá-la adiante;
- importar a identidade em outra ferramenta compatível, como a CLI de código aberto;
- publicar os endereços de recebimento da identidade em qualquer lugar.
Isto não é como convidar alguém para um espaço de trabalho com permissões limitadas e um botão de revogar. Não há um nível "somente leitura" ou "publicar-mas-não-decifrar". Quem detém a semente detém a identidade inteira.
Quando uma identidade compartilhada faz sentido?
Quando o mundo externo deve enxergar uma identidade que representa um papel, não uma pessoa.
Casos razoáveis incluem:
- um endereço de recebimento de uma redação;
- a identidade de provas de um departamento jurídico;
- um contato para divulgação de falhas de segurança;
- a identidade de um comitê de auditoria;
- a identidade de uma equipe de conformidade;
- a identidade de registros de uma empresa;
- a identidade compartilhada de um projeto pequeno.
Em cada um desses, a identidade voltada ao público representa uma função ou uma equipe, e o fato de várias pessoas estarem por trás dela é justamente o objetivo.
Quais são os riscos de uma identidade compartilhada?
A atribuição passa a ser compartilhada — e a exposição também.
Se várias pessoas podem assinar como a mesma identidade, um verificador externo sempre vê apenas uma chave pública Ed25519. A cadeia não registra qual humano usou a semente. Isso pode ser exatamente o que a equipe quer — ou um problema real de responsabilização, dependendo da situação.
Os demais riscos decorrem da mesma raiz:
- qualquer membro pode vazar a semente, de propósito ou por acidente;
- um único dispositivo comprometido pode comprometer toda a identidade;
- um ex-membro pode manter uma cópia depois de sair;
- todo registro selado enviado à identidade é legível por todos os detentores da semente;
- não há rotação de chaves implementada — trocar de chaves significa migrar para uma nova identidade.
A autoridade compartilhada funciona, mas exige disciplina operacional ao seu redor.
Como a CardanoWall lida com isso entre contas?
Cada conta mantém sua própria cópia cifrada da identidade compartilhada.
Se duas pessoas — chamemos de Alice e Bob — importam a mesma semente, cada conta recebe seu próprio vínculo conta-identidade e seu próprio cofre cifrado. As passkeys da Alice abrem o cofre da Alice; as do Bob abrem o do Bob. A mesma identidade criptográfica simplesmente aparece nas duas contas, sem nenhum estado compartilhado no servidor entre elas.
Para vincular uma identidade pré-existente, quem importa precisa provar que de fato detém a semente — não apenas que conhece as chaves públicas, que qualquer pessoa pode ler de um perfil ou da cadeia. A conta assina um desafio único do servidor com a chave derivada da semente antes de o vínculo ser criado. Isso impede que alguém vincule uma identidade cujas chaves públicas apenas conhece, ao mesmo tempo em que permite que um detentor legítimo da semente a vincule.
Os rótulos de exibição permanecem privados para cada conta. A Alice pode rotular a identidade como "Equipe de Imprensa"; o Bob pode rotulá-la como "Recepção". Esses rótulos vivem dentro do cofre cifrado de cada conta, nunca na identidade pública, de modo que nenhuma conta enxerga o rótulo da outra e uma violação do banco de dados não revela nenhum deles.
A cobrança também permanece por conta. Se a Alice publica a partir da conta dela, a conta dela paga. Não há saldo compartilhado, porque nenhum saldo poderia ser imposto criptograficamente quando qualquer pessoa com a semente já pode publicar de qualquer maneira.
Uma identidade compartilhada pode ser revogada de uma única pessoa?
Não criptograficamente — não depois que ela já conhece a semente.
A CardanoWall consegue remover a identidade do cofre de uma conta, remover uma passkey ou desativar a identidade em uma determinada conta. Esses são controles reais na camada de serviço, e importam para as contas que você controla.
Mas nenhum deles alcança uma cópia da semente que já vive no gerenciador de senhas de alguém, em uma impressão, na memória dessa pessoa, em um backup, em uma ferramenta de desktop ou em uma segunda conta. O conhecimento de 32 bytes não pode ser revogado.
Então, se alguém que detinha a semente não deve mais ter autoridade, a atitude honesta é criar uma nova identidade e aposentar a antiga — não fingir que a semente antiga pode voltar a ser secreta.
Qual é um bom procedimento para uma identidade compartilhada?
Trate a semente como o segredo compartilhado de alto valor que ela é.
Antes de qualquer pessoa compartilhá-la, a equipe deve combinar:
- quem tem permissão para deter a semente;
- como a semente é transferida (pessoalmente ou com criptografia fim-a-fim);
- onde fica a cópia de backup oficial;
- quem pode adicionar a identidade a uma conta;
- quais passkeys abrem o cofre de cada conta;
- quem tem permissão para publicar sob a identidade;
- o que acontece quando alguém sai;
- quando a identidade deve ser substituída;
- onde as novas chaves públicas são anunciadas.
Escreva isso antes que um incidente ou uma mudança de equipe force a decisão sob pressão.
Uma equipe deve usar uma única identidade compartilhada para tudo?
Geralmente não.
Identidades separadas mantêm os fluxos de trabalho organizados e contêm danos. Uma empresa pode operar uma identidade para divulgações de segurança, outra para provas jurídicas, outra para lançamentos públicos e outra para auditorias internas.
Essa separação limita o raio de impacto. Se uma identidade é comprometida, as outras não herdam automaticamente o comprometimento. Também mantém a agenda de contatos e o modo de lista de permissões mais fáceis de compreender, já que cada identidade tem um propósito claro e restrito.
O que fazer quando a equipe muda?
Crie uma nova identidade. O conhecimento da semente antiga não pode ser revogado, então um corte limpo é a única solução real.
Quando uma identidade compartilhada é comprometida, ou quando um ex-detentor deve perder o acesso, o caminho é:
- criar uma identidade nova e salvar a nova semente;
- compartilhar a nova semente apenas com os membros que ainda devem tê-la;
- atualizar perfis públicos, endereços de recebimento e contatos com as novas chaves;
- desativar a identidade antiga nas contas que você controla;
- parar de usar os endereços de recebimento antigos;
- opcionalmente, publicar um registro sob a nova identidade que substitua a antiga.
Os registros selados já endereçados à chave antiga continuam legíveis por todos que algum dia detiveram a semente antiga — inclusive a pessoa de quem você está se afastando na rotação. Isso é uma propriedade de cifrar para uma chave pública de longo prazo, não um bug que você possa corrigir. Planeje em torno disso; não finja que a semente antiga pode ser descompartilhada.
A versão curta
As identidades compartilhadas de equipe são poderosas e sem meio-termo.
Elas permitem que uma equipe opere uma única identidade pública Label 309 em várias contas e dispositivos. Mas todos com a semente têm pleno poder de assinatura e decifração, e esse poder não pode ser concedido parcialmente nem revogado discretamente.
Use uma identidade compartilhada para papéis que genuinamente precisam de autoridade compartilhada. Use identidades separadas sempre que responsabilização, separação ou rotação importarem mais.