Um dos tópicos mais desafiadores em segurança de ambientes AWS é o controle de acesso às APIs de gerenciamento do ambiente, também conhecido como control plane. É muito freqüente que incidentes de segurança sejam causados por má configuração de privilégios, desde o simples caso de buckets S3 totalmente abertos para leitura quanto no caso de roubo de credenciais e uso de permissões excessivas concedidas a roles ou usuários.
O serviço IAM é o coração da segurança de um ambiente AWS, porque é ele que controla a autenticação e autorização um usuário junto às APIs da AWS. O IAM é um conjunto de controles que permitem dar acesso de forma granular, com múltiplo fator de autenticação (MFA), políticas e regras que se integram com praticamente todo o ecossistema de serviços da AWS.
Mas para organizações de tamanho não trivial, é imperativo segregar diferentes sistemas e ambientes em múltiplas contas AWS para facilitar o controle e conter danos causados em incidentes. E contas de usuário de IAM são associados a apenas uma conta AWS. Organizações devem então seguir as melhores práticas e usar um serviço de federação de identidades para conceder acesso controlado às diferentes contas sem multiplicar a quantidade de contas e credenciais de acesso.
Justamente para simplificar esta federação é que foi criado o AWS Single Sign-On (SSO), que permite o uso de uma base própria de usuários ou integração com um diretório Active Directory na nuvem ou on-premises. Até recentemente, a única opção para usar MFA era implementar isto diretamente no Active Directory utilizado pelo SSO. No final de outubro, contudo, o SSO passou a permitir o uso de autenticadores TOTP mesmo que o diretório faça uso exclusivamente de autenticação com senha. Se aproximou, assim, do que já existe há algum tempo para contas de usuários de IAM.
Seria de se esperar, então, que como é a própria AWS que está implementando esse segundo fator de autenticação no login do SSO, que do ponto de vista de monitoramento de segurança e políticas de controle de acesso isso seria idêntico a quando usuários de IAM fazem o mesmo.
Resolvemos então testar esta hipótese e realizar testes desta nova funcionalidade. Em especial, queríamos:
- identificar se neste cenário de SSO com autenticador TOTP seria possível identificar nos logs de CloudTrail quais usuários usam ou não o segundo fator;
- confirmar se é possível utilizar políticas de IAM com condicionais de existência de MFA para aumentar a segurança de ambientes.
Um acesso a um recurso por um usuário de IAM sem MFA habilitado gera um registro similar a este no CloudTrail:
Se o mesmo usuário tiver se autenticado utilizando MFA, aparecerá um campo chamado mfaAuthenticated com valor true que registra isso:
O surpreendente é que quando você utiliza Single Sign On para acessar o AWS Console, mesmo tendo se autenticado com MFA, o mesmo campo mfaAuthenticated é populado com o valor false:
Podemos concluir então que infelizmente o teste 1) acima falhou.
Em seguida resolvemos testar a hipótese 2), usando condicionais em políticas IAM para exigir que determinadas operações só possam ser feitas por usuários usando MFA. Criamos um política de bucket S3 bem simples, não permitindo que usuários sem MFA não pudessem listar buckets ou qualquer ação que iniciasse com List*.
Em seguida fizemos duas tentativas de acesso com MFA, uma com usuário IAM e outra com acesso via SSO.
O acesso com usuário IAM é bem sucedido:
Acesso via SSO não é autorizado:
Então o teste 2) também falhou, não é possível usar as condicionais de MFA com usuários de SSO mesmo que usem o segundo fator de autenticação.
Este comportamento é contraintuitivo, mas ele está de acordo com a documentação. Ela diz que usuários autenticados através de federação ou credenciais temporárias de STS (via operações da família AssumeRole) não são considerados como tendo um segundo fator de autenticação. E o SSO é de fato uma forma de federação, e conta com credenciais geradas através de AssumeRole para acesso às diferentes contas. Então mesmo sendo a própria AWS que faz a validação do segundo fator de autenticação neste cenário, o fato não é reconhecido nos logs nem nas condicionais de política.
Escrito por Rodrigo Montoro e Alexandre Sieira.
Nossos agradecimentos a Paul Wakeford e Josh Frantz pelas contribuições à discussão de Slack que deu origem a este blog post.
