Gerir a 2FA de uma conta AWS partilhada

Ninguém devia entrar na AWS com um identificador partilhado. O acesso diário pertence a identidades por pessoa através do IAM Identity Center, e a automação pertence a papéis e não a seja o que for que um humano escreva.

Resta o utilizador raiz, que é mesmo um identificador único por conta. O que é útil saber é que também não têm de partilhar o seu segundo fator: a AWS permite registar vários aparelhos MFA no utilizador raiz, portanto dois ou três administradores podem inscrever cada um o seu. Copiar um segredo TOTP é uma solução de recurso para os casos em que isso não é possível, não a escolha por omissão.

Três identificadores diferentes

«A nossa conta AWS» quer em geral dizer uma destas três coisas, e elas têm respostas diferentes.

O utilizador raiz. Um por conta, identificado por um endereço de email, capaz de fazer tudo, incluindo fechar a conta e mudar a faturação. Não foi feito para o trabalho diário.

As identidades por pessoa. Utilizadores do IAM Identity Center, ou utilizadores IAM nas configurações mais antigas. É aí que o trabalho se faz mesmo, e é aí que cada um tem o seu próprio segundo fator.

As chaves de acesso. Credenciais de longa duração para o acesso programático. Não é um início de sessão, não está protegido pela MFA como as pessoas supõem, e é o que mais frequentemente se encontra num repositório antigo.

A maioria das perguntas sobre a «2FA AWS partilhada» diz na verdade respeito ao primeiro, e surge porque os outros dois nunca foram montados.

Trabalho diário: identidades por pessoa

O IAM Identity Center dá a cada pessoa o seu próprio início de sessão, a sua própria MFA, e credenciais de duração limitada nas contas e papéis a que tem direito. O acesso é concedido por atribuição em vez de se entregar seja o que for, e retirar alguém é uma ação num único sítio, seja qual for o número de contas AWS que exploram.

Se ainda estão em utilizadores IAM, o mínimo é um utilizador por pessoa, cada um com o seu aparelho MFA, e nenhum utilizador partilhado para a equipa. Um utilizador IAM partilhado tem todos os problemas de um utilizador raiz partilhado sem nenhuma das suas razões de ser.

Para uma agência que trabalha na conta de um cliente, o equivalente de «convidem-me» é um papel entre contas: o cliente mantém a propriedade e pode revogá-lo num único sítio, e ninguém envia credenciais por email.

Automação: papéis, não inícios de sessão

Tudo o que corre sem supervisão devia assumir um papel em vez de iniciar sessão. Na própria AWS, isso significa perfis de instância, papéis de tarefa ou uma federação OIDC a partir do vosso fornecedor de CI. São credenciais de duração limitada, sem segredo para guardar e sem nada que um humano tenha de escrever.

Se um script pede um código de seis dígitos a alguém, é porque está a usar a identidade de um humano, e vai partir no dia em que esse humano sair.

As chaves de acesso de longa duração são a outra metade do assunto. São revogáveis e renováveis individualmente, o que é uma vantagem real sobre um segredo TOTP, mas são também as credenciais que fogem nos commits. Tenham poucas e rodem-nas segundo um calendário que cumpram mesmo.

O utilizador raiz: a verdadeira conta partilhada

A raiz existe, várias pessoas têm de lhe conseguir chegar, e não deve depender do telemóvel de uma só pessoa.

Registem mais do que um aparelho MFA

É a resposta própria da AWS, e elimina inteiramente a questão da partilha. Inscrevam a aplicação ou a chave física de cada administrador que tenha de poder agir como raiz. Cada aparelho detém o seu próprio segredo, e nenhum segredo é alguma vez copiado. Uma saída é o cancelamento do registo de um aparelho, não a reposição da 2FA da conta e a reinscrição de toda a gente.

Onde uma chave física seja viável, é aqui que ela vale o seu preço: o segundo fator não pode ser fotografado, nem transferido, nem sincronizado.

Apontem o email raiz para uma caixa que duas pessoas possam ler

A recuperação da raiz passa por esse endereço. A caixa pessoal de um fundador torna a conta irrecuperável no dia em que ele já não estiver: usem uma lista de distribuição ou uma caixa partilhada, e assegurem-se de que quem a pode ler são pessoas a quem confiariam a recuperação da conta, porque funcionalmente é isso que esse endereço concede.

Apaguem as chaves de acesso raiz

Não devia haver nenhuma. Se existirem, são credenciais partilhadas sem qualquer MFA à frente, o que é pior do que tudo o resto neste artigo.

Vigiem os inícios de sessão raiz

O CloudTrail regista-os, e um alarme sobre o uso da raiz é prática corrente. Numa conta saudável, os inícios de sessão raiz são raros e explicáveis, o que os torna baratos de vigiar e valiosos de ver.

Quando um segredo TOTP partilhado continua a ser a resposta

Os aparelhos MFA múltiplos cobrem a maioria dos casos. Alguns resistem:

• A conta de um cliente que não administram, onde vos entregam credenciais sem que possam reestruturar nada.
• Consolas antigas ou de terceiros à volta da AWS (um portal de faturação, um painel de revendedor, um fornecedor de supervisão) que aceitam exatamente uma inscrição TOTP.
• Um identificador de emergência que o vosso procedimento exige que várias pessoas possam usar depressa, onde aparelhos individuais não são praticáveis.

Para esses, as exigências são as de qualquer conta partilhada: uma guarda única do segredo, um acesso aos códigos concedido por pessoa, um registo de quem leu um código, e códigos de recuperação arrumados fora da conta que recuperam. O raciocínio está em como partilhar códigos 2FA em equipa com segurança, e a comparação dos mecanismos nas melhores formas de gerir a 2FA de uma conta partilhada. O mesmo raciocínio aplicado a um prestador de pagamentos está em gerir a 2FA de uma conta Stripe partilhada.

Um procedimento de emergência que merece ser escrito

Para a raiz, e para tudo o que só serve em caso de urgência:

1. Quem a pode usar, nominalmente, e o que a desencadeia.
2. Onde vivem o identificador e o seu segundo fator, e quantas pessoas chegam a cada um.
3. Onde estão os códigos de recuperação, fora da conta que recuperam.
4. O que dispara um alerta ao ser usado, ou seja, o alarme do CloudTrail acima.
5. O que acontece a seguir: quem é avisado, o que é revisto, o que é eventualmente renovado.
6. Quando foi testado pela última vez. Um procedimento nunca ensaiado será descoberto na noite em que alguém precisar dele.

Quando alguém sai de uma conta AWS

1. Retirem as suas atribuições do Identity Center ou apaguem o seu utilizador IAM.
2. Desativem e apaguem as suas chaves de acesso, incluindo as usadas pelas suas ferramentas.
3. Cancelem o registo do seu aparelho MFA raiz, se tinha algum.
4. Se alguma vez deteve um segredo TOTP partilhado, reponham essa 2FA e mudem a palavra-passe associada. O segredo não sai do telemóvel dele sozinho.
5. Verifiquem se ainda consegue ler o endereço de email raiz.
6. Releiam o CloudTrail à volta da sua saída, à procura do inesperado.

O passo 5 é o que se esquece. Aceder à caixa raiz é aceder à conta raiz, seja o que for que tenham revogado noutro lado.

Onde se coloca a Share Auth

De forma estreita, e deliberada. Para as contas da secção acima, ou seja, a consola de um cliente, um painel de terceiros que só aceita uma inscrição, ou um identificador de emergência: o segredo é introduzido uma vez e cifrado em repouso, as pessoas que precisam dos códigos veem o código e a sua contagem decrescente em vez do segredo, as permissões são por membro, e cada consulta fica registada.

Para um utilizador raiz da AWS que administram, registar um segundo aparelho MFA vale mais do que tudo o que um cofre possa fazer, o nosso incluído. Façam isso primeiro.