Artigo original: AWS Identity and Access Management (IAM) – Explained With an Analogy

O AWS IAM (Identity and Access Management) oferece controle sobre quem pode acessar seus serviços e recursos da AWS com base em algumas permissões predefinidas.

As duas palavras-chave aqui são "quem" e "permissões". "Quem" refere-se a uma identidade específica, que pode ser um usuário, grupo ou role (em português, função ou papel). "Permissões" referem-se às políticas anexadas a uma identidade. Essas permissões permitem ou negam acesso a um recurso.

O IAM é a maneira de a AWS autenticar e autorizar identidades. Autenticação não é, no entanto, o mesmo que autorização. A autenticação está relacionada com o "quem", enquanto a autorização está relacionada com as "permissões".

A diferença entre autenticação e autorização

Autenticação é quando uma identidade prova que é o que/quem diz ser. A autorização, por outro lado, prova que você tem as permissões para acessar um recurso.

Para entender completamente a diferença, considere a seguinte analogia. Você precisa ser autenticado e autorizado para embarcar em um voo. A autenticação é feita com o seu passaporte ou documento de identificação, onde é verificado se a fotografia do seu passaporte corresponde ao seu rosto. Isso prova que você é quem diz ser.

Depois de autenticado, você precisa provar que tem permissão para fazer um voo específico. Isso é feito com seu cartão de embarque.

Tanto a autenticação quanto a autorização precisam ser realizadas antes de embarcar em um voo. Do mesmo modo, ambos precisam ser executados antes que você possa acessar os recursos da AWS.

Você pode ler mais sobre autorização versus autenticação aqui.

image-70
Autenticação e autorização não são o mesmo

Os usuários, grupos e roles do IAM se preocupam com a autenticação, ou seja, provar que você é quem diz ser. Eles são como passaportes que permitem que você passe pela segurança de um aeroporto.

Sem um cartão de embarque, no entanto, você não pode embarcar em um avião. A política do IAM é como um cartão de embarque, pois concede ou nega acesso a recursos específicos.

O que são usuários do IAM?

Esta é qualquer identidade (humana ou um aplicativo) que requer acesso de longo prazo aos recursos da AWS. Essas entidades fazem solicitações ao IAM para serem autenticadas antes que qualquer interação com os recursos da AWS seja permitida.

A autenticação é feita usando uma combinação de nome de usuário/senha para humanos acessando a AWS por meio do console ou por meio de chaves de acesso para uma aplicação ou um humano acessando a AWS por meio da interface de linha de comando.

O que são os grupos do IAM?

Os usuários do IAM podem ser colocados em um grupo do IAM. Os grupos do IAM facilitam a organização de um grande número de usuários do IAM e a aplicação de permissões em um nível de grupo em vez de um nível individual. Isso ocorre porque o último não é dimensionado para um grande número de usuários.

Imagine que você tem uma equipe composta por desenvolvedores, arquitetos, equipe administrativa, engenheiros de DevOps, suporte ao vivo e testadores. Cada uma dessas equipes tem 10 pessoas, em um total de 60 pessoas.

Em vez de definir políticas de permissão para 60 pessoas individualmente, você pode colocar usuários do IAM em seus respectivos grupos e aplicar permissões em um nível de grupo. Isso facilita a organização de permissões e também o dimensionamento à medida que sua equipe cresce.

image-72
Os grupos do IAM podem ser criados para equipes separadas

Não há credenciais de login para grupos do IAM. Além disso, um usuário pode pertencer a vários grupos. Por exemplo, um usuário do IAM que está no grupo de DevOps também pode estar no grupo de suporte ao vivo. Isso mapeia perfeitamente o mundo real, onde um engenheiro de DevOps também pode estar no suporte ao vivo.

O que são roles do IAM?

Roles (ou funções) do IAM são usadas para conceder acesso temporário a várias identidades. Essas identidades podem ser pessoas externas à AWS acessando seus serviços, usuários do IAM ou aplicações.

Essas identidades assumem a role temporariamente e quaisquer políticas de permissão anexadas à role são aplicadas por extensão à identidade que assume essa role.

As roles do IAM são importantes porque a AWS tem limites rígidos para o número de usuários do IAM (atualmente, 5 mil – documentação em inglês).

Políticas de confiança x políticas de permissão

As políticas do IAM anexadas às roles são de dois tipos – política de confiança e política de permissão.

A política de confiança controla qual identidade (por exemplo, usuários do IAM, recursos da AWS, como instâncias de EC2, entidades anônimas) pode assumir essa role. Depois que uma role é assumida por uma identidade, a AWS emite credenciais de segurança temporárias (documentação em inglês).

Você pode pensar na política de confiança como a maneira como a AWS autentica uma role do IAM para garantir que apenas a identidade com permissão para assumir a role possa fazer isso, ou seja, que uma identidade tenha provado ser quem/o que diz ser.

Há, no entanto, um porém. Com políticas de confiança, essa autenticação funciona apenas por um período de tempo. Depois de decorrido esse tempo, a identidade precisa se autenticar novamente e obter novas credenciais de segurança temporárias.

A política de permissões é relativamente simples: ela define as permissões que a role tem. A role, por sua vez, define as permissões que a identidade que assumir essa role terá.

As roles do IAM são um conceito relativamente difícil de entender. Portanto, se você ainda não o entende bem, continue lendo e ele ficará mais claro.

Como as políticas do IAM funcionam

As políticas do IAM são anexadas a identidades (portanto, aos usuários, grupos ou roles). As políticas do IAM também podem ser anexadas a alguns recursos da AWS. Esses tipos de políticas são chamados de políticas baseadas em recursos.

As políticas do IAM são documentos JSON, que consistem em uma ou mais instruções que concedem ou negam acesso aos recursos da AWS.

A política do IAM abaixo mostra como as permissões são concedidas a uma identidade para ler e gravar em um bucket de S3.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListObjectsInBucket",
            "Effect": "Allow",
            "Action": ["s3:ListBucket"],
            "Resource": ["arn:aws:s3:::bucket-name"]
        },
        {
            "Sid": "AllObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object",
            "Resource": ["arn:aws:s3:::bucket-name/*"]
        }
    ]
}
Uma política do IAM que concede acesso de leitura e escrita a um bucket de S3
  • Sid significa "statement ID" (ou, em português, identificação de declaração), um campo opcional que permite ao leitor identificar rapidamente o que uma declaração faz.
  • Effect pode ser allow ou deny (em português, permitir ou negar, respectivamente)
  • Action refere-se a qual ação você está tentando efetuar. O formato é serviço:operação.
  • Resource refere-se a com qual recurso você está interagindo. Tipicamente, você vai usar o ARN (Amazon Resource Name, documentação em inglês) que identifica, de forma exclusiva, recursos da AWS.

Por padrão, todas as solicitações são negadas implicitamente, a menos que uma política tenha explicitamente uma "permissão", como é o caso do exemplo acima.

Esse princípio de privilégio mínimo garante que uma identidade não possa usar um recurso, a menos que receba explicitamente a permissão para fazê-lo.

Juntando tudo – como o IAM funciona

Considere um restaurante. Ele terá alguns funcionários em tempo integral – como chefs, garçons e faxineiros. Também pode ter alguns chefs de meio período para ajudar durante o pico de demanda à noite e nos fins de semana. Se o restaurante for bom, também terá clientes que podem comer no local e levar para viagem.

image-73
Analogia do restaurante de IAM

Para fazer uma analogia com o AWS IAM, os funcionários em tempo integral são como usuários do IAM. Eles exigem acesso de longo prazo aos recursos do restaurante, conforme mostrado acima. Todos esses usuários pertencerão a grupos diferentes – o grupo de garçons, chef e faxineiros (ou seja, todos os garçons, por exemplo, terão o mesmo cargo de "garçom").

image-74
Analogia do restaurante de IAM

Como os funcionários do restaurante são autenticados? Como sabemos que eles são quem dizem ser? Crachás com uma foto servirão. Eles também podem mostrar seu cargo, que é análogo ao grupo IAM ao qual eles pertencem.

As políticas de permissão que definem quais recursos os funcionários do restaurante podem acessar são aplicadas no nível do grupo, pois todos os garçons, chefs e faxineiros terão as mesmas permissões. Isso pode não ser verdade na realidade, pois o chefe de cozinha, por exemplo, pode ter acesso privilegiado. Para simplificar, porém, vamos supor que seja verdade.

Como o gerente do restaurante controla quem tem acesso a quais recursos? Portas com fechaduras servirão perfeitamente. As chaves funcionam como uma política, pois controlam o acesso a partes do restaurante.

Um conjunto idêntico será dado a todos os garçons, uma vez que os garçons precisarão do mesmo nível de acesso ao depósito de alimentos/bebidas, cozinha e mesas.

A mesma lógica será aplicada ao restante dos colaboradores em tempo integral, onde são entregues as devidas chaves para que possam utilizar os recursos do restaurante conforme as suas necessidades.

Fornecer chaves aos funcionários do restaurante é semelhante a anexar uma política a um usuário ou grupo do IAM. Sem as chaves, os funcionários não podem acessar partes do restaurante.

Do mesmo modo, na AWS, sem políticas que permitem explicitamente uma ação, as solicitações não podem ser feitas aos recursos da AWS. O estado padrão na AWS e em nossa analogia com o restaurante é uma negação implícita ao tentar acessar recursos.

Os funcionários de meio período (como um chef temporário, por exemplo) e os clientes não precisam de acesso de longo prazo aos recursos, mas precisarão de acesso de curto prazo, semelhante às roles do IAM.

Os funcionários de meio período só podem trabalhar durante um breve período – digamos durante a noite no fim de semana. Fora desse horário, eles não têm permissão para usar os recursos do restaurante.

O chef de meio período não precisa ser a mesma pessoa. Pode ser uma pessoa diferente a cada semana, ao contrário dos funcionários em tempo integral que têm identidades específicas.

Um chef de meio período, portanto, assumirá a função (role) de chef e receberá um crachá temporário que manterá durante o turno. Isso é análogo a uma entidade que assume uma role do IAM que tem uma política anexada a ela e obtém credenciais de segurança temporárias que expirarão após algum tempo.

Novamente, a política aqui é o conjunto de chaves que concede permissão para partes do restaurante, enquanto a credencial de segurança temporária é o crachá temporário usado para autenticar o chef.

Do mesmo modo, os clientes são análogos às roles do IAM por dois motivos. Primeiro, eles exigem apenas acesso temporário ao restaurante. Em segundo lugar, e talvez mais importante, um restaurante de sucesso terá dezenas de milhares a centenas de milhares de clientes únicos ao longo de sua vida.

Ter um grande número de entidades não identificadas é um caso de uso perfeito para roles do IAM. Lembre-se de que, com a AWS, há um limite rígido de 5 mil para o número de usuários do IAM que você pode ter. Se houver um caso de uso em que o número necessário de usuários do IAM exceda esse limite de 5 mil, usar as roles do IAM é sua única opção.

Assim como as funções do IAM são assumidas, o cliente primeiro precisa solicitar algo para provar que é um cliente e pode assumir a role de cliente.

Depois que a role do cliente é assumida, a política de permissões anexada à role do cliente também é aplicada ao cliente. Os clientes têm permissão para usar apenas alguns recursos, como as mesas e o banheiro.

Para manter a analogia realista, o acesso ao banheiro é controlado digitando uma senha que muda todos os dias, garantindo assim que o acesso seja temporário. Essa senha é análoga à política anexada à role do cliente que concede acesso temporário ao banheiro.

image-75

Exemplo de caso de uso de roles do IAM

Considere a seguinte arquitetura muito simples: uma instância de EC2 executando uma aplicação que precisa de acesso total a um bucket de S3.

Como você daria à instância de EC2 permissão para ler e gravar objetos de um bucket do S3? Isso é explicado no diagrama abaixo:

image-77
Anexando uma política a uma role de IAM e deixando que uma instância de EC2 assuma aquela role
  1. Crie uma role do IAM para sua instância do EC2
  2. Anexe uma política do IAM à role que concede acesso total ao bucket de S3
  3. Deixe a instância de EC2 assumir a role

A política de IAM para o acesso total ao S3 mencionado na etapa 2 é:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "s3-object-lambda:*"
            ],
            "Resource": "*"
        }
    ]
}

Agora, você pode ler e gravar no bucket do S3. Observe que, na política acima, não é especificado nenhum ARN. Ela apenas contém "*" para o recurso. Isso representa todos os buckets de S3. Se é isso que você quer, então essa política serve. Se, porém, você quiser especificar um único bucket, precisará fornecer o ARN do bucket.

Resumo

Compreender o IAM e a diferença entre usuários, roles, grupos e como as políticas funcionam oferece a você uma base sólida sobre a qual você pode arquitetar e criar soluções seguras com a AWS.

Obrigado pela leitura!