Gerir a 2FA das contas de clientes quando se é uma agência

Peçam a cada cliente que vos acrescente em vosso nome, em vez de vos enviar o seu identificador. Quase todas as plataformas onde uma agência trabalha têm uma forma de conceder acesso a uma organização externa: acesso de parceiro, convite de membro, papel entre contas, um utilizador vosso no CMS deles. Onde isso existe, não há palavra-passe partilhada nem segundo fator partilhado para gerir.

O que resta depois é uma lista curta por cliente: as contas sem delegação, as que a reservam aos planos de empresa, as que foram configuradas por alguém que já saiu. Essas exigem uma guarda que possam auditar durante a missão e desfazer com limpeza no fim.

A restrição que torna diferente a 2FA de agência

Uma equipa interna possui as suas contas. Se o segundo fator estiver no sítio errado, pode deslocá-lo: repor a 2FA, acrescentar um segundo administrador, ligar a conta a uma caixa partilhada. É maçador, mas é possível.

Uma agência não tem nenhuma dessas alavancas. As contas pertencem ao cliente, foram configuradas há dois anos por alguém do departamento financeiro dele, e a vossa influência sobre essa configuração resume-se a um pedido educado no arranque. Não podem corrigir a conta. Só podem corrigir o vosso lado.

A segunda diferença é aritmética. Uma equipa interna tem talvez quinze contas partilhadas ao todo. Uma agência tem um certo número por cliente. Com três clientes, tem tudo na cabeça. Com quarenta, a prática informal deixa de ser uma escolha de estilo, é o que vai ceder, e vai ceder sobre a propriedade de outra pessoa.

O raciocínio geral sobre a guarda das contas partilhadas está em a 2FA de uma conta partilhada: como deve uma equipa lidar com ela?. O modelo de exploração de uma agência assenta por cima.

O que pedir em vez de uma palavra-passe

As formas de um acesso em regra

Os nomes diferem de plataforma para plataforma, a forma não. Alguém de fora da organização do cliente recebe um nível de acesso definido sobre um recurso definido, com o seu próprio identificador e o seu próprio segundo fator.

O cliente ganha mais do que vocês, e é isso que torna a conversa fácil. Ele vê que alterações são vossas, pode retirar-vos sem repor nada para os seus próprios colaboradores, e nenhuma das suas palavras-passe acaba num fio de emails. Digam isso ao pedir.

As versões próprias de cada ferramenta são tratadas noutro sítio: uma conta Stripe partilhada, uma conta AWS partilhada, e as contas de redes sociais partilhadas, onde o modelo de acesso de parceiro está mais desenvolvido.

Como conduzir a conversa

Peçam no arranque, por escrito, conta a conta. Uma missão que começa com uma palavra-passe enviada por email nunca volta à questão.

Duas coisas fazem o pedido passar. Dirijam-se à pessoa que administra mesmo a conta, não à responsável de marketing que passará o vosso pedido a alguém de férias. E enviem os passos em vez do pedido: uma lista numerada e curta daquilo em que clicar, por plataforma, elimina o esforço que é a verdadeira objeção. «Por razões de segurança» lê-se como um problema vosso; «para que vejam o que alterámos e nos possam cortar com um clique» lê-se como o dele.

Contem com uns quinze dias e dois lembretes nalgumas contas. Não deixem o trabalho parar atrás disso.

Quando o cliente envia na mesma a palavra-passe

Alguns fá-lo-ão. Uma empresa em nome individual em que o dirigente é o único administrador, um cliente cujo prestador informático não responde, uma plataforma realmente sem delegação. Recusar o identificador não é uma opção real: reduzam antes a exposição.

• Tirem-no da caixa de correio logo que o recebam. A cópia na vossa caixa de entrada e a das mensagens enviadas dele continuam lá, e só dominam uma.
• Peçam-lhe que mude a palavra-passe assim que a detiverem, ou mudem-na vocês se tiverem autorização. Isso mata a cópia enviada por email, que é a única coisa que podem mesmo fazer.
• Nunca aceitem o código de inscrição 2FA. Nem a captura do código QR, nem a cadeia por baixo, por canal nenhum. Se ele o oferecer, recusem e expliquem porquê: é a credencial permanente e não uma palavra-passe, as suas cópias não podem ser contadas nem retomadas, e desfazer uma obriga a repor a 2FA da conta. A mecânica está em como funcionam os segredos TOTP.
• Se ele referir tê-lo enviado por email a um prestador anterior, digam-lhe para o considerar comprometido e repor. Mensagem incómoda, conselho certo.
• Anotem o que receberam, de quem, e quando. É esse hábito que torna possível o fim da missão.

Nada disto torna retroativamente segura uma palavra-passe enviada por email. Encurta a janela e deixa-vos um rasto.

Um cliente, uma fronteira

Com quarenta clientes, a separação é a propriedade que mantém pequeno um pequeno incidente.

Uma entrada por conta de cliente. Nomeada por cliente e por conta, nunca um monte comum de «identificadores de clientes». É o monte que torna inaplicáveis todas as regras seguintes.

Um acesso concedido por pessoa, para os clientes em que ela trabalha. O gestor de projeto de um pacote não tem razão para chegar ao registador de domínios de outro cliente. Não é desconfiança dos vossos colaboradores; quer dizer que um portátil roubado é o problema de um só cliente e que uma saída é uma só conversa.

Um registo que mantenham a sério. Não um documento escrito uma vez no arranque:

Uma revisão num momento fixo, agarrada à revisão do pacote ou à faturação. Um acesso nunca revisto só se acumula.

O custo honesto: a separação vai bloquear alguém, em geral quem substitui à última hora um colega num cliente. A resposta é uma atribuição que leva trinta segundos, não um acesso permanente para toda a gente. Se conceder for lento, as pessoas dão a volta, e dão a volta com uma palavra-passe numa mensagem.

A chegada de um cliente

Tratem a recolha de acessos como um entregável, com um responsável e uma data, tal como a reunião de lançamento.

1. Listem as contas de que o trabalho precisa mesmo, não tudo o que o cliente possui. O alargamento do âmbito dos acessos é como uma agência acaba a deter o identificador de um registador que nunca usa.
2. Descubram quem administra cada uma e que delegação permite. A segunda pergunta costuma responder-se na página de definições deles.
3. Peçam um acesso delegado, com os passos em anexo.
4. Para o que sobrar, acordem explicitamente a guarda: quem, na agência, detém o identificador, onde vive, e quem pode ler os seus códigos.
5. Registem tudo, incluindo as contas que pediram sem obter.
6. Acordem já o estado final, enquanto a boa vontade está alta: o que vão devolver, o que vão retirar, o que lhe vão pedir para renovar.

O passo 6 custa cinco minutos no arranque e evita uma negociação mais tarde, quando um pacote acaba e ninguém se sente generoso.

O fim de uma missão

A saída de um colaborador discute-se. O fim de uma missão de cliente é o que os clientes notam mesmo, e costuma correr pior.

1. Retirem o que dominam. Saiam da relação de parceiro, abandonem o papel assumido, apaguem os vossos próprios utilizadores onde tenham esse direito.
2. Enviem ao cliente a lista do que só ele pode retirar. Utilizadores nomeados, ligações de parceiro, chaves de API, palavras-passe de aplicação, integrações. Ele não se vai lembrar do que vos foi dado; o vosso registo lembra-se.
3. Apaguem os identificadores que detêm, e digam-no.
4. Nomeiem cada conta onde detiveram um segredo TOTP, e peçam para repor a 2FA e desligar todas as sessões em cada uma. É o passo que toda a gente salta.
5. Ponham tudo isso numa passagem de testemunho escrita, datada, com o que detinham, o que retiraram, e o que pedem para renovar.

Sobre a prova de que já não detêm nada: não conseguem provar a ausência de uma cópia, e uma agência que alegue fazê-lo está a exagerar. O que podem fazer é pôr o cliente numa posição em que tudo o que ainda pudessem ter não vale nada. Uma palavra-passe mudada e um segundo fator reposto são a única prova verdadeira, e cabe-lhe a ele produzi-la: construam portanto a passagem de testemunho à volta desse pedido em vez de à volta de palavras tranquilizadoras.

É aqui que uma prática informal se torna visível. Se os identificadores viveram num só sítio, com um rasto de quem os podia ler, o passo 4 é um parágrafo que podem escrever honestamente. Se onze pessoas leram códigos de inscrição ao longo de três anos, não o podem escrever de todo, e é o facto de escreverem uma versão mais vaga que devia incomodar-vos.

Prestadores e freelancers

A rotação é a condição normal, não a exceção, e dá-se mal com tudo o que é permanente.

Concedam por cliente, e anotem a retirada no próprio dia da atribuição. Um freelancer num cliente durante seis semanas devia ter acesso a um cliente durante seis semanas. Essa data é fácil de pôr quando já estão na página de definições, e impossível de reconstituir quatro meses depois.

Deem-lhes códigos, nunca segredos. Um subcontratado trabalha no seu próprio aparelho, com o seu gestor de palavras-passe e as suas cópias de segurança. Tudo o que consiga copiar fica com ele depois de paga a fatura, e nenhuma cláusula muda seja o que for. A distinção é o assunto de partilhar códigos TOTP sem partilhar o segredo.

Onde a plataforma do cliente o permitir, arranjem ao freelancer um utilizador próprio do lado do cliente. O cliente vê de quem vem o trabalho, e a retirada é uma ação do lado dele que não vos envolve.

Nunca deixem um freelancer ser o ponto de inscrição da 2FA de um cliente. Acontece por acidente: ele configura a conta durante um lançamento, a aplicação de autenticação acaba no telemóvel dele, e dois anos depois ninguém consegue entrar e ele mudou de profissão. Nalgumas plataformas isso não tem saída fiável, apenas uma fila de apoio.

Fechem os acessos no fim do contrato com a mesma certeza com que enviam a fatura. Uma das duas coisas é sempre feita. Agarrem a outra a essa.

O que pôr na carta de missão

Coisas operacionais, não jurídicas: a redação do contrato é uma questão para um advogado, e nada aqui é aconselhamento jurídico. Mas um parágrafo no caderno de encargos ou no email de arranque resolve as disputas do nono mês, e devia cobrir:

• para que contas a agência detém identificadores, e a quais chega por um acesso delegado;
• que o cliente mantém a propriedade e pode revogar qualquer acesso a qualquer momento, sem pré-aviso nem explicação;
• quem, na agência, está autorizado, e que o acesso é por pessoa e não à agência enquanto entidade;
• que os códigos de inscrição 2FA e os segredos não circulam por email nem por mensagem, em nenhum sentido;
• o que acontece no fim: a lista de passagem, as retiradas que a agência efetua, e as renovações que pedirá ao cliente;
• a quem contactar quando um identificador deixa de funcionar, para que ninguém resolva isso publicando uma palavra-passe num canal às 19h.

O interesse não é ser oponível. É que a conversa aconteça uma vez, no início, durante uma semana calma.

O que parte quando isto tudo fica informal

As falhas são reconhecíveis, e vêm todas da mesma estrutura em falta.

O revezamento. Os códigos vêm do telemóvel de um gestor de projeto. Praticável com quatro clientes, até que essa pessoa tire uma semana de férias.

Quem sai e não se consegue desligar. Alguém sai depois de ter inscrito a sua aplicação de autenticação numa dúzia de contas de clientes. Fazê-lo bem implica contactar doze clientes para lhes pedir que reponham a 2FA, e explicar porquê. A maioria das agências abstém-se sem o dizer, o que quer dizer que a próxima nota de passagem contém uma afirmação falsa.

A conta que ninguém consegue recuperar. Registada num endereço ou número pessoais, por alguém que já não se consegue contactar.

A pergunta sem resposta. Um cliente pergunta quem abriu a sua conta de publicidade no dia 14. «Uma de quatro ou cinco pessoas, achamos» é uma má resposta para dar a um cliente sobre a sua própria propriedade, e é em geral o momento em que uma agência muda a sua forma de trabalhar.

O raio de ação. Um monte comum faz de um portátil comprometido um incidente para todos os clientes ao mesmo tempo, e a conversa de notificação torna-se quarenta conversas.

Onde se coloca a Share Auth

Para as contas de clientes que ficam depois da delegação: as que só têm um identificador, sem modelo de parceiro, e com um cliente que não vai reestruturar nada.

O segredo é introduzido uma vez e cifrado em repouso. As pessoas que convidam veem o código de seis dígitos em vigor e a sua contagem decrescente em vez da cadeia por trás, o que torna o acesso de um subcontratado verdadeiramente revogável. As permissões regulam-se por membro e por conta, portanto a separação dos clientes torna-se exprimível em vez de ser um desejo. Cada consulta é escrita num registo de acessos, portanto «quem leu o código no dia 14» tem uma resposta com um nome e uma marca temporal. Retirar um membro retira-lhe o acesso em todas as contas de clientes de uma vez. Uma ação, sem reposições em doze clientes. Há uma API para os casos em que é uma máquina, e não uma pessoa, que precisa do código. O plano gratuito cobre três segredos e três membros sem cartão bancário, o suficiente para fazer passar um cliente por todo o ciclo antes de decidir seja o que for.

O que não faz: não vos arranja acesso delegado, que continua a ser a melhor resposta onde quer que exista, não mantém o vosso registo nem as vossas notas de passagem, e não consegue desfazer um código de inscrição já enviado por email. Também não é um gestor de palavras-passe, e a palavra-passe deve ficar naquele que já têm, pela razão exposta em como partilhar códigos 2FA em equipa com segurança. Se ainda estão a pesar as opções, os mecanismos são comparados nas melhores formas de gerir a 2FA de uma conta partilhada, e o protocolo subjacente é tratado no guia completo do TOTP em equipa.

Por onde começar

Não por quarenta clientes ao mesmo tempo.

1. Peguem no cliente com os acessos mais emaranhados e construam com limpeza a sua entrada de registo. Uma tarde, e diz-vos como são os outros trinta e nove.
2. Escrevam dois modelos: os passos numerados do pedido enviado no arranque, e a nota de passagem com o seu pedido de renovação. É o facto de estarem escritos que os faz sair.
3. Peçam acesso delegado a todos os vossos clientes atuais onde exista, ao ritmo de um cliente por semana.
4. Para as contas que ficam partilhadas, ponham o segredo num só sítio com acesso aos códigos por pessoa, e reponham a 2FA de qualquer conta cujo código de inscrição tenha alguma vez sido enviado ou publicado.

O estado final não tem nada de brilhante: um cliente pergunta o que detêm e quem o usou, e vocês respondem no próprio dia.