Implicações do AuthN/AuthZ Gap

Tornou-se consenso que, na cloud, "a identidade é o novo perímetro". É uma frase interessante, fácil de incluir numa apresentação ou num artigo, mas transformá-la em orientação prática é um pouco mais difícil. Hoje pretendo concentrar-me apenas num aspeto do IAM na cloud, ao qual chamo "AuthN/AuthZ Gap". Na verdade, trata-se de uma questão que surge sempre que se utiliza federação, mas os riscos na cloud são maiores, uma vez que o plano de gestão da cloud está sempre exposto à internet.

Primeiro, uma breve introdução a AuthN vs. AuthZ:

• AuthN é autenticação. O ato de provar que se é uma determinada entidade. Para os simples mortais, isto significa normalmente um nome de utilizador, uma palavra-passe e, eventualmente, MFA.
• AuthZ é autorização. O ato de verificar se uma ação é permitida. Na cloud IaaS, isto corresponde quase sempre a uma chamada de API, mesmo quando se utiliza a consola/portal web.

Autenticação e autorização são tarefas distintas, com fluxos distintos. Quando iniciamos sessão num site, autenticamo-nos e, normalmente, isso cria uma sessão. Não temos de voltar a introduzir as credenciais sempre que clicamos em algo; o browser limita-se a enviar um token válido durante um determinado período. As autorizações são normalmente verificadas sempre que tentamos fazer algo, para garantir que dispomos das permissões adequadas.

Pensando bem, depois de se obter esse token de sessão, ele não volta a ser verificado, a menos que algo no código force uma nova verificação. A autenticação é válida para a sessão e, por isso, é possível fazer tudo o que estiver no âmbito das autorizações. Consoante a plataforma/sistema, essas credenciais temporárias continuarão a funcionar mesmo que sejam revogadas ou que a conta seja totalmente eliminada. É este o AuthN/AuthZ Gap.

Dedico bastante tempo a este tema quando leciono Cloud Incident Response, porque constatei que mesmo profissionais experientes em resposta a incidentes nem sempre compreendem as implicações. Imagine o caso de credenciais de cloud roubadas: revoga ou elimina as credenciais, mas o atacante tem uma sessão ativa aberta e pode continuar a executar ações autorizadas. Isto é… mau.

Como resolver a situação

Consoante a forma como utiliza essas credenciais, a opção mais simples é normalmente alterar a autorização. Basta aplicar uma política de negação à entidade (ou remover as ações permitidas), uma vez que esta é avaliada em cada chamada de API feita pelo atacante. Embora seja a opção mais simples, nem sempre é a melhor, pois pode interromper tarefas em execução (as credenciais roubadas nem sempre estão associadas apenas a utilizadores). Outras opções, consoante o suporte do seu fornecedor de cloud, incluem:

• Adicionar condicionais para restringir o IP de origem das chamadas de API.
• Negar todas as sessões criadas antes de uma determinada data/hora.

É mais provável deparar-se com este problema ao federar para um fornecedor de cloud do que dentro do próprio fornecedor. Fiz agora um teste na AWS e perdi o acesso em sessões abertas bastante depressa após eliminar um utilizador IAM. No entanto, o mesmo não acontece necessariamente ao federar a partir de um fornecedor de identidade externo e, mesmo dentro da AWS, alguns serviços não voltam a verificar as credenciais durante sessões ativas (por exemplo, a minha sessão do Session Manager manteve-se ativa durante cerca de 15+ minutos depois de eliminar a role que permitia o acesso).

Não se trata de uma grande vulnerabilidade desconhecida, mas de algo a ter em conta ao desenvolver os seus controlos de segurança na cloud e os playbooks de resposta a incidentes. Diferentes tipos de credenciais têm diferentes tempos de vida, tanto entre fornecedores de cloud como dentro de cada um. O seu fornecedor de identidade será igualmente um fator, bem como o local onde tenta revogar as credenciais. Por exemplo, se tiver um utilizador no Active Directory que depois federa para a AWS, e esse utilizador assumir uma role na AWS e obtiver credenciais de sessão para essa role, é necessário revogar ou restringir as credenciais da role assumida, mesmo que restrinja o utilizador no AD. A AWS não terá qualquer conhecimento de que a sessão do utilizador proveniente do AD deixou de ser válida até ao final da sessão, momento em que procede à revalidação da autenticação.

Internamente, passámos a utilizar a nossa ferramenta Authorization Control, que suporta a criação de sessões com restrições através de ChatOps, sem acrescentar qualquer atrito que possa atrasar os nossos programadores. Embora ainda não esteja disponível de forma geral, se tiver interesse em experimentá-la em acesso antecipado, basta enviar-me um email diretamente para rich.mogull@firemon.com.