AWS Permission Boundaries for Dummies

Os permission boundaries da AWS são confusos. Sei que são confusos porque me confundiram e levei alguns anos para os compreender. Também sei que são confusos porque Corey Quinn o disse e pediu que alguém os tornasse menos confusos.

Provavelmente vou falhar, mas aqui vai.

Resumindo: as políticas IAM normais permitem-lhe fazer coisas, mas também o podem impedir de as fazer. Os permission boundaries apenas o impedem de fazer coisas. Na maioria dos casos, utiliza-os para permitir que alguém administre algumas partes do IAM, mas não tantas que consiga escalar privilégios (para si próprio ou para outra pessoa). São um mecanismo de segurança. Se permitir que alguém faça a gestão do IAM numa conta e não quiser que essa pessoa consiga escalar privilégios, quase sempre precisará de um permission boundary!

A documentação oficial da AWS tem muitos detalhes, mas continua a ser algo confusa. Este artigo destina-se a ajudá-lo a compreender os conceitos e a razão da sua existência, não a dominar os pormenores de como os escrever (com uma exceção).

Imagine que sou uma criança, não um totó, e explique outra vez

Bom, se insiste.

Antes dos IAM Permission Boundaries, era MUITO DIFÍCIL permitir que alguém gerisse as permissões IAM dos seus próprios recursos sem criar um problema de segurança ao atribuir permissões em excesso a algo como uma instância EC2 ou… a si próprio. O problema surgia sobretudo quando se pretendia deixar essa pessoa escrever políticas IAM e depois atribuí-las. É o problema da administração delegada. “Permitir que alguém administre algumas coisas relacionadas com o IAM, mas não aquelas coisas”.

Este é um cenário muito comum. Os programadores criam frequentemente uma função para uma instância, uma função lambda ou uma tarefa de contentor na sua stack aplicacional e depois atribuem permissões a essa função. Pode ser algo tão simples como permitir que uma instância leia dados de um bucket S3. Acontece que isto é difícil de gerir do ponto de vista da segurança:

• Se permitir que o programador escreva as suas próprias políticas, ele pode acrescentar privilégios excessivos… como *.*.
• Se permitir que o programador atribua políticas, ele pode associar uma política existente com demasiadas permissões.
• Se permitir que o programador crie uma nova função E atribua uma política… tem os mesmos problemas.

Sim, poderia simplesmente deixar que a equipa de segurança ou um administrador de alto nível tratasse de tudo isto, mas seria ineficiente. Os permission boundaries permitem-lhe ter dois níveis de administradores IAM: os de alto nível, com responsabilidade global pela segurança, e os de nível inferior, que tratam das tarefas do dia a dia.

Um permission boundary é apenas uma política IAM que enumera os privilégios máximos que alguém ou algo pode ter. Associa essa política e os programadores que gerem o recurso nunca lhe poderão dar mais permissões do que as permitidas no boundary. Pode até permitir que o programador crie novas funções e utilizadores e lhes atribua permissões, exigindo que tudo o que criar tenha esse permission boundary. Assim, nunca poderá criar ou alterar nada e atribuir-lhe mais permissões do que aquelas que pretende.

Não sei se isto serviu para uma criança, mas talvez me possa dar um exemplo

A Alice é a superadministradora de uma organização AWS. Tem de supervisionar centenas de contas e cada conta tem os seus próprios administradores locais e programadores que fazem a construção efetiva das aplicações.

O Bob é um desses programadores locais. O Bob está a construir uma nova aplicação e é mais eficiente que crie as suas próprias funções e políticas, uma vez que sabe aquilo de que a sua aplicação precisa.

A Alice decide permitir que o Bob faça a gestão do IAM de partes da sua aplicação. Em concreto:

• O Bob pode escrever e atribuir novas políticas IAM com as permissões de que as suas instâncias e funções lambda necessitam.
• Existem outros serviços AWS em utilização nos quais esses componentes nunca devem tocar. Por isso, não se podem simplesmente desativar com uma Service Control Policy. Isso inviabilizaria esses serviços para os componentes autorizados a utilizá-los.
• O Bob não está autorizado a atribuir uma nova política a si próprio.

É um caso clássico de administração delegada: o Bob só está autorizado a administrar parte do IAM. É aqui que utilizaria um permission boundary:

• A Alice cria um permission boundary “A” que autoriza permissões para os serviços AWS com os quais as instâncias e as funções lambda do Bob podem comunicar (por exemplo, S3, SNS, SQS).
• A Alice cria um permission boundary “B” que permite ao Bob criar funções e políticas IAM (e atribuí-las), mas NÃO atribuí-las a si próprio.
• A Alice dá ao Bob permissões IAM para criar e atribuir novas funções e políticas, mas quaisquer novas funções têm de ter o permission boundary “A”. Isto significa que essas instâncias e funções lambda NUNCA terão mais permissões do que as constantes do boundary, embora possam ter menos.
• A Alice atribui o permission boundary “B” ao Bob para o impedir de atribuir permissões a si próprio. Assim, ele não pode eliminar a exigência de implementar os recursos com o “A” aplicado.

Sim, existem várias formas de abordar este problema… mas, em resumo, sempre que quiser permitir que alguém administre parte do IAM numa conta, provavelmente precisará de um permission boundary se não quiser que essa pessoa faça demasiado.

Diga-me outra vez porque é que uma Service Control Policy não funciona aqui

Por vezes uma SCP pode funcionar, mas só pode utilizar uma SCP se estiver numa Organization, ao passo que um permission boundary funciona em qualquer conta. Além disso, as SCPs são muito boas para coisas como limitar as chamadas de API que se podem fazer (e, por conseguinte, os serviços AWS que se podem utilizar), mas não foram realmente concebidas para este tipo de granularidade e de condições.

Pense no exemplo acima: a Alice poderia ter de conhecer os identificadores dos recursos para permitir o acesso aos serviços na conta, mas não a partir dos recursos criados pelo Bob. Há formas de lidar com isto (por exemplo, caminhos de recursos), mas não são mais simples do que o nosso exemplo com permission boundary e nem sempre funcionam, dependendo das chaves de condição suportadas.

No meu Incident Response Training Range, utilizo uma SCP para impedir que os utilizadores administradores (os formandos) nas contas quebrem o meu acesso ao nível da Organizations, entre outras coisas. Mas isso só funciona porque lhes dou IAM completo e eles já são um desses superadministradores. Se quisesse limitar a sua capacidade de criar recursos com permissões excessivas, precisaria de um permission boundary ou de uma SCP que os restringisse à atribuição de determinadas políticas previamente definidas.

Não posso simplesmente usar políticas de negação

Na verdade, não. Tentámos isso antes de existirem os permission boundaries e, além da complexidade, havia demasiadas brechas.

Pode dar-me mais um exemplo simples

Com certeza! Aqui fica um que nós próprios utilizamos.

Alguns utilizadores permitem-nos fazer alterações de IAM nas suas contas. Para isso utilizamos funções entre contas. Quando os utilizadores implementam a função, aplicam um permission boundary que nunca nos permite alterar as permissões sobre nós próprios. Isto impede a escalada de privilégios.

Acho que percebi, mas como interagem todas estas políticas IAM

Consulte a documentação da AWS sobre a lógica de avaliação de políticas, mas aqui ficam os meus apontamentos:

• As Service Control Policies limitam o que qualquer pessoa pode fazer numa conta (por exemplo, podem ativar e desativar serviços).
• As políticas de permissões IAM permitem que utilizadores e funções façam coisas numa conta.
• As políticas de recursos IAM permitem que utilizadores e funções interajam com o recurso ao qual a política está associada.
• Os permission boundaries definem os privilégios máximos que um utilizador ou função pode ter. Não lhe permitem fazer coisas, mas podem impedi-lo de as fazer.

As políticas funcionam todas em conjunto. Para fazer algo, tem de ter uma permissão em algum ponto do conjunto que o autorize e não pode haver, em lado algum, políticas de negação que o impeçam. Uma única negação prevalece sobre qualquer autorização, independentemente de onde esteja.

Relembre-me quando devo utilizar permission boundaries

Quando quiser permitir que alguém administre parte do IAM numa conta, mas ainda assim limitar até que ponto, deve pensar num permission boundary.

Mesmo quando utiliza ferramentas IAM avançadas como o nosso novo FireMon Authorization Control, poderá ainda assim querer alguns permission boundaries, sobretudo em contas altamente sensíveis.

Qual é o exemplo que você disse que incluiria?

Embora os permission boundaries tenham o objetivo de impedir que você faça determinadas coisas, eles ainda exigem que você especifique todas as permissões de allow. Em outras palavras, se você escrever um permission boundary com uma instrução DENY para bloquear a única coisa que não quer que aquele usuário/função faça, ainda assim será necessária uma instrução ALLOW * ou eles não poderão fazer nada.

Essa é a parte que me confundiu no início, pois interpretei mal a descrição da Amazon e achei que bastava usar um permission boundary para bloquear ações. É possível, mas, exceto por um caso de uso de política de recurso que não quero abordar hoje, o permission boundary também precisa incluir tudo o que você deseja permitir. Você não pode simplesmente aplicar DENY a uma coisa no permission boundary e ALLOW a outras coisas na política de permissões IAM comum e esperar que funcione. O permission boundary também precisa conter as instruções ALLOW (e sim, eu faço uma trapaça e às vezes uso ALLOW * aqui).

Ainda estou confuso

Envie-me um e-mail. Sério, essas coisas são realmente confusas.