Políticas de IAM Gerenciadas pela AWS
Entendendo as Políticas de IAM Gerenciadas pela AWS
Políticas de IAM Gerenciadas pela AWS representam uma funcionalidade interessante e poderosa na nuvem da AWS. Essencialmente é uma biblioteca de políticas de IAM escritas e mantidas pela equipe da AWS e que você pode usar (mas não alterar) em suas contas.
Em nossa opinião, os principais benefícios do uso de políticas de IAM gerenciadas pela AWS são os seguintes:
- Maior eficiência devido ao reuso de políticas existentes escritas pela AWS ao invés da escrita do zero.
- Maior legibilidade ds políticas, dado que administradores experientes de AWS em teoria já conhecem as políticas de IAM gerenciadas pela AWS.
- Auto-adaptação, dado que a AWS mantém as políticas atualizadas de acordo com que novas operações e serviços são lançados na sua dinâmica API. Por exemplo, o uso da política SecurityAudit para uma ferramenta de segurança ou auditor irá garantir que novos privilégios sejam adicionados pela AWS no futuro.
Esses benefícios não são diferentes daqueles trazidos pelo uso de bibliotecas de código de terceiros em seu código. Porém, isto traz também alguns riscos significativos que vamos explorar mais na próxima seção.
Neste artigo eu vou incluir alguns gráficos gerados com código Python usando boto3, Jupyter notebooks, Pandas e matplotlib, de forma a facilitar a análise de dados históricos de versões publicadas de políticas de IAM gerenciadas pela AWS. Os mesmos dados podem ser obtidos com qualquer SDK usando as operações de API ListPolicies e ListPolicyVersions, ou neste repositório GitHub mantido por Victor Grenu. Os dados utilizados foram os de 2 de Novembro de 2020.
Primeiramente, a AWS muda estas políticas com alguma freqüência. Vamos tentar visualizar quantas vezes uma nova versão foi publicada por quarters (trimestres).:
Note que, após a carga inicial no primeiro trimestre (Q1) de 2015, existe uma clara tendência de crescimento na quantidade de versões de políticas publicadas ao longo do tempo.
Além disso, as mudanças tendem a ocorrer em maior volume no último trimestre (Q4) de cada ano. Isso imediatamente nos remeteu à série de novos lançamentos da AWS a cada ano antes e durante a re:Invent, a conferência global da empresa que é historicamente realizada no final de novembro. Visualizando os meses em que versões de políticas foram publicadas, o mês de novembro se destaca o que parece confirmar a hipótese:
Tendo dito isto, a maioria das políticas têm poucas versões. Mais de 88% das políticas tem 5 versões ou menos, por exemplo. Esta concentração fica ainda mais clara quando se vê este histograma:
E para referência, estas são as 19 políticas com maior número de versões:
RankPolicyVersions1ReadOnlyAccess712AWSConfigRole343SecurityAudit334AWSConfigServiceRolePolicy205AmazonECS_FullAccess196AmazonSageMakerFullAccess177AWSElasticBeanstalkService168FMSServiceRolePolicy169AWSCodeCommitPowerUser1410AWSMobileHub_FullAccess1411AWSSupportServiceRolePolicy1312AWSCodeBuildDeveloperAccess1313AWSGlueConsoleFullAccess1214AWSOpsWorksCMServiceRole1215AmazonDynamoDBFullAccess1216AWSSSOServiceRolePolicy1217AWSCodeBuildAdminAccess1218AWSServiceRoleForImageBuilder1119AWSCodeBuildReadOnlyAccess11
As Desvantagens
Infelizmente, apesar das APIs mostrarem todas as versões das políticas, os usuários não podem escolher qual irão usar. Tão logo a AWS publica uma nova versão e a define como o novo default, ela é imediatamente aplicada a todas as contas. E para piorar as coisas, como Richard H. Boyd colocou muito bem, “qualquer publicação vai ser fora do horário comercial para cerca de dois terços do mundo”.
Isso está longe de ser ideal, e torna a gestão de mudanças pelos clientes essencialmente impossível. Mudanças realizadas pela AWS podem acontecer a qualquer momento, e atualmente a única maneira de são ser afetado é não utilizar políticas de IAM gerenciadas pela AWS.
E o que isso quer dizer na prática é que qualquer mudança não compatível com versões anteriores tem o potencial de impactar todas as contas e sistemas que usem as políticas alteradas. E mesmo não sendo just dizer que isso ocorre com freqüência, sabemos que acontece:
ReadOnlyAccess just had 83 privileges deleted from it. 😮 That's abnormal. Hope this doesn't break anything. Also apparently there were 3 changes in the past 4 hours to that policy. https://t.co/ySDI3HVZGk
— Scott Piper (@0xdabbad00) October 16, 2020
Além disso, a AWS aparentemente publicou por acidente e depois apagou políticas que deveriam ser apenas internas:
I wonder what “Thor” is.
I think might be a candidate for shortest lived IAM managed policy at a mere 11 hours. Even Cheesepuffs lasted four days. pic.twitter.com/h8h0guBfPY
— Aidan W Steele (@__steele) June 19, 2020
Também não existem, até onde saibamos, qualquer tipo de guia ou compromisso que limite o tipo de alterações que a AWS pode fazer nestas políticas. Remover ou adicionar novas condições para privilégios pode quebrar ambientes que dependiam deles. Adicionar novos privilégios pode trazer preocupações de segurança.
Recomendações
Se você é um usuário de AWS típico, evite usar políticas de IAM gerenciadas pela AWS para qualquer workload automatizado ou sistêmico. Ou escreva as suas políticas do zero, ou copie o conteúdo da versão de uma política gerencia que melhor te atenda. Assim, será possível evitar problemas associados a futuras mudanças feitas pela AWS.
Duas exceções a esta regra geral seriam situações onde as alterações feitas pela AWS são mais funcionalidade do que bug:
- Usar SecurityAudit para conceder acesso cross-account a um terceiro. O trabalho envolvido em constantemente atualizar o role de acesso para uma solução SaaS ou prestador de serviços em cada uma das suas contas pesa a favor do uso de uma política gerencia pela AWS… desde que você mantenha em mente que a AWS muitas vezes demora até refletir novos serviços nela.
- Quando privilégios são associados por papel a pessoas no AWS SSO, em especial para times como TI e auditoria, se há um bom alinhamento com o uso desejado da política e os usuários são razoavelmente confiáveis.
Por fim, existe muito que a AWS deveria fazer para melhorar a situação aqui. Nosso desejo seria que eles passassem a tratar atualizações de políticas de IAM gerenciadas da mesma forma que o RDS trata upgrades de motores de bases de dados:
- Permitir que os clientes controlem se as atualizações serão automáticas ou manuais;
- Permitir que os clientes definam uma janela de mudanças quando as alterações seriam de fato aplicadas;
- Separar mudanças não compatíveis com versões anteriores daquelas que não introduzem quebras, permitindo que os clientes automatizem apenas estas últimas. Seria o equivalente à diferenciação que o RDS faz entre versões major e minor durante as atualizações.
Não hesite em entrar em contato se quiser saber mais sobre como implementar controle de acesso eficaz e uma boa postura de segurança em seus ambientes de nuvem com apoio da Tenchi Security.
Pesquisa e artigo realizados por Alexandre Sieira.
