Dar aos colaboradores acesso à 2FA sem lhes dar o segredo

Desenhar os acessos 2FA dos colaboradores: o que se concede por conta e por papel, e como gerir entradas, mudanças de função e saídas.

Dê aos colaboradores acesso aos códigos e guarde o segredo com a pessoa que administra a conta. Em concreto: uma pessoa introduz cada segredo uma vez, concede o acesso por pessoa e por conta, e retira esse acesso quando alguém muda de função ou sai. Ninguém inscreve a sua própria aplicação de autenticação, por isso ninguém leva um acesso que não consiga retomar.

Este artigo trata do lado do empregador desse arranjo: quem obtém o quê, e como o fazer funcionar. O raciocínio por trás da separação está em como partilhar códigos 2FA em equipa com segurança, e a mecânica que permite distribuir um código enquanto o segredo fica onde está está em partilhar códigos TOTP sem partilhar o segredo.

Comece por decidir qual é a unidade de acesso

A maioria das equipas concede os acessos 2FA como distribui as chaves do escritório: alguém pede, outro diz que sim, e não se escreve nada. Aguenta até à quarta contratação. Escolha antes uma unidade, e mantenha-a; três defendem-se.

Por conta. A escolha por omissão. Cada identificador partilhado é algo para que se está autorizado ou não: os pagamentos, a cloud, o registador de domínios, o perfil social principal, cada painel de cliente.

Por papel. Em vez de conceder à Amira, concede a quem faz o trabalho da Amira. «Financeiro» fica com o prestador de pagamentos e a ferramenta de contabilidade. «Social» fica com os dois perfis e a ferramenta de agendamento. Quando a Amira muda de equipa, a lista que o seu substituto herda já está definida.

Por missão. As agências precisam de um terceiro eixo: o cliente. O acesso às contas de um cliente para quando a missão para, sejam quais forem as pessoas ainda em funções.

Cruzar papel e conta não exige cerimónia nenhuma. Uma tabela pequena, uma linha por papel e uma coluna por conta partilhada, é o documento que vai usar na chegada de uma pessoa e nas revisões.

O privilégio mínimo, aplicado aos códigos

Duas perguntas decidem cada atribuição. Esta pessoa entra nesta conta no âmbito do seu trabalho? E se lhe roubassem o portátil esta noite, quereria ver essa conta na lista de exposições?

A primeira afasta os acessos especulativos. «É mais simples dar tudo a toda a gente» é verdade no dia da instalação e falso em todos os dias seguintes, porque o custo chega mais tarde, num incidente ou numa saída. A segunda é um teste de bom senso sobre a antiguidade: fundadores e responsáveis técnicos acumulam todas as contas por omissão e tornam-se o alvo mais interessante da empresa.

Privilégio mínimo não quer dizer obrigar as pessoas a pedir sempre. Se alguém precisa de uma conta todas as semanas, conceda-a. Um acesso incómodo de usar é contornado, em geral por alguém que lê os códigos numa conversa.

Como são os primeiros dez minutos de quem chega

A ativação tem de ser uma tarefa, não um projeto. Se levar uma tarde, será mal feita.

Antes do primeiro dia

Procure o papel na tabela e anote as contas que lhe correspondem. Se o papel for novo, decida a lista agora, não durante a integração.

No próprio dia

O administrador concede essas contas. Quem chega entra, vê as contas para que está autorizado, e consegue produzir um código para cada uma. Não há código QR para ler nem segredo para guardar: não tem, portanto, nada a perder nem a copiar.

O que merece ser dito em voz alta

Diga-lhe duas coisas. Primeiro, que nunca verá o segredo por trás de um código, e que isso é deliberado. Segundo, que se precisar de uma conta ausente da sua lista, a resposta é um pedido e não um contorno. As equipas que saltam a segunda frase herdam acessos paralelos: alguém captura um código QR de configuração para um colega, e o número de cópias torna-se impossível de conhecer. Porque essa cópia nunca pode ser chamada de volta é tratado em como funcionam os segredos TOTP e porque não se devem partilhar.

Entradas, mudanças de função, saídas

A palavra que a maioria das equipas esquece é mudanças de função. As entradas e as saídas são vigiadas; a mudança de papel raramente, e é assim que os acessos se acumulam.

Entrada. Conceda a lista do papel. Nada mais, mesmo que a pessoa seja experiente.

Mudança de função. Conceda as contas do novo papel e retire as do antigo. A retirada é o passo que se salta, e é assim que um agente de apoio que passou para o marketing há dois anos continua com o prestador de pagamentos. Conceda por papel e uma mudança passa a ser a comparação de duas listas.

Saída. Retire a pessoa de todas as contas, no dia em que sai, numa ação que não muda nada para os outros. Se, pelo contrário, a saída obrigar a repor a 2FA em nove contas e a pedir a oito colegas que ficam para se reinscreverem, é o sinal: os seus colaboradores detêm segredos, não acessos.

Os prestadores entram no mesmo circuito, com uma data de fim anotada no momento em que o acesso é concedido. Ninguém se lembra de revogar o acesso de uma missão de três semanas que acabou sem ruído.

O que vê um colaborador, e o que vê um administrador

Ser explícito sobre esta assimetria evita muitas suspeitas.

Um colaborador vê as contas para que está autorizado e, para cada uma, o código atual e o tempo que lhe resta. Não consegue ver nem o segredo, nem as contas que não lhe foram concedidas, nem a forma de conceder acesso a quem quer que seja.

Um administrador vê todas as contas, quem tem acesso a cada uma, e o registo dos códigos consultados com a sua marca temporal. Os administradores são também as pessoas que introduzem os segredos e conservam os códigos de recuperação do fornecedor.

O material sensível fica assim nas mãos de um pequeno número de pessoas nomeadas, e «quem pode entrar na conta de publicidade?» tem uma resposta verdadeira em vez de uma estimativa.

Como apresentar isto sem que soe a vigilância

O registo de acessos é a parte que faz reagir, e a reação é legítima: ninguém gosta de saber depois que as suas leituras ficam gravadas.

Diga-o logo, na ativação, e explique para que serve em termos operacionais. Quando um identificador partilhado faz algo que ninguém explica, a primeira pergunta é quem estava ligado, e o registo da plataforma diz apenas que a conta foi usada. O registo dos códigos é o único sítio que distingue cinco colegas. Também protege quem o usa: um registo que mostra quem consultou um código mostra igualmente quem não o fez.

O que não ajuda é apresentá-lo como uma medida de confiança. Descreva-o como canalização, porque é o que é.

«Confiamos nas nossas pessoas»

A objeção merece uma resposta franca, porque a sua premissa costuma estar certa: a maioria das equipas tem de facto colaboradores de confiança. Mas a confiança não é a propriedade que se gere aqui. Outras duas são.

A contagem. Devia conseguir dizer quantos aparelhos podem atualmente produzir um código para uma conta. Se as pessoas inscreveram as suas próprias aplicações, esse número é desconhecido e assim fica; nada na página de segurança da conta o reporta.

A revogabilidade. Devia conseguir pôr fim ao acesso de alguém sem tocar na conta. Se pôr-lhe fim obrigar a repor a 2FA e a reinscrever todos os outros, vai evitá-lo, e o acesso persistirá.

Nenhuma das duas supõe que alguém se comporte mal. Uma equipa perfeitamente honesta tem na mesma telemóveis esquecidos em táxis, pessoas que saem em bons termos, e prestadores cuja missão acabou em março. É para esses acontecimentos que esta organização existe.

Uma versão da objeção merece, porém, ser concedida. Se duas pessoas partilham um identificador, nenhum modelo de permissões faz disso duas identidades. Onde a conta gere verdadeiros acessos individuais, isso vale mais do que qualquer arranjo de partilha, e é a primeira coisa a verificar ao arrumar as suas contas. Ver a 2FA de uma conta partilhada: como deve uma equipa lidar com ela?.

Reveja os acessos em data fixa

Uma vez por trimestre, leia a lista de cada conta partilhada e retire os nomes que não deviam lá estar. Acrescente uma revisão a cada mudança de função e a cada fim de missão.

Leva alguns minutos se o acesso foi concedido conta a conta. Se o seu único rasto for uma pasta de cofre partilhada que uma dúzia de pessoas pode abrir, não há nada a rever: a resposta é sempre «toda a gente». As contas que ninguém consultou há meses em geral não precisam de ser partilhadas de todo.

Os erros que voltam

Tudo para toda a gente por omissão. Em geral justificado pelo receio dos estrangulamentos. Transforma cada portátil perdido numa exposição de toda a empresa.

Conceder à pessoa em vez de à função. O acesso segue um nome, o nome muda de trabalho, e ninguém sabe que atribuições estavam ligadas ao papel antigo. Conceda ao papel e a mudança torna-se mecânica.

Nenhum administrador nomeado. Se ninguém for responsável pelo segredo de uma conta, ninguém conserva os seus códigos de recuperação e ninguém vê os acessos derivarem.

Tratar a saída como um projeto de segurança em vez de como uma linha de lista. Arruma-se ao lado do portátil e do cartão, com o mesmo prazo.

Escolher o mecanismo antes de ter arrumado as contas. Compare os mecanismos só para os identificadores que têm mesmo um único conjunto de dados de acesso, como nas melhores formas de gerir a 2FA de uma conta partilhada.

Onde se coloca a Share Auth

A Share Auth está construída à volta desta forma. Introduz o segredo de cada conta uma vez, e ele é cifrado em repouso. As pessoas que convida veem o código atual e a sua contagem decrescente, não a cadeia de onde ele vem: não há, portanto, nada que possam inscrever noutro lado.

As permissões são concedidas por membro e por conta, o que torna a tabela por papel acima exprimível em vez de teórica. Cada consulta é escrita num registo de acessos. Retirar um membro retira-lhe o acesso em todas as contas de uma vez: uma saída é uma ação, não uma migração. Há uma API se a integração de quem chega já estiver automatizada.

O plano gratuito cobre três segredos e três membros sem cartão bancário, o suficiente para fazer funcionar as contas reais de uma equipa e ver se o modelo de permissões aguenta.

O que isto não resolve

Um identificador partilhado continua a ser uma identidade partilhada. Códigos concedidos por pessoa dizem-lhe quem obteve um; não fazem o rasto de auditoria da plataforma distinguir os seus colegas, e não lhe dão qualquer permissão por pessoa dentro da conta. Onde um fornecedor propõe verdadeiras contas de utilizador ou SSO, essa continua a ser a melhor resposta, e esta organização vale para as contas que não oferecem nem uma coisa nem outra.

Também não faz nada quanto à palavra-passe. Se ela anda por algum sítio onde toda a gente a pode ler, guardar o segredo à parte comprou-lhe a independência do segundo fator e nada mais. É algo, mas não é todo o controlo de acessos.

Perguntas frequentes

Não. Os colaboradores precisam de códigos válidos, não da entrada de onde esses códigos saem. Guarde o segredo com as pessoas que administram a conta e conceda a todos os outros o acesso aos códigos: retirar alguém passa a ser alterar uma lista em vez de repor uma conta.

Leia também · Partilhar códigos em equipa

7 min de leitura

Várias pessoas podem usar o mesmo TOTP?

Sim, tecnicamente: vários aparelhos com o mesmo segredo produzem o mesmo código. O que acontece mesmo a dois, e quanto custa.