Quando a gente usa a AWS qualquer coisa que fazemos passa pelo IAM, seja quando criamos uma instância EC2, quando adicionamos um objeto no S3 ou quando invokamos um lambda.
O IAM ou Identity and Access Management é um conceito global de gestão de acesso e não foi criado pela AWS, esse acrônimo foi adotado pelo provedor de nuvem para um dos serviços mais importantes, que a cada segundo recebe mais de 400 milhões de chamadas.
E o IAM serve para controlar autenticação e autorização. Autenticação é o processo que a gente se autentica seja com um usuário e senha, com uma chave e logo depois vem a autorização, então apesar de você estar autenticado, será que você tá autorizado, ou tem aquela determinada permissão?
Ele é composto por usuários, grupos, políticas de permissões, roles, MFA, SSO, etc, sendo uma ferramenta bem completa, onde a AWS investe bastante para que a gente consiga fazer toda a gerencia necessária.
Então quando a gente fala de IAM a gente pode pensar nele como um firewall de gestão de acesso, um firewall do presente e por que? Por ser uma ferramenta que ajuda no controle de acessos assim como faz o firewall de rede com determinadas conexões.
MODELO DE POLÍTICA
As políticas do IAM são compostas por alguns elementos e são escritas em Json. Esses elementos que a compõem são o version, sid, statement, action, effect, resource, condition.
O version é uma anotação da versão que vai definir quais são os elementos que irão compor uma política, até o momento isso é imutável e a AWS não tem uma nova versão ainda, então ainda sempre vai ser o mesmo.
O SID é um identificador da política e aí você pode dar um nome, ou algo que ajude a entender o que ela faz.
O statement é um bloco e é nele que a gente vai definir o que a nossa política faz, adicionar as condições, quais vão ser nossas permissões, ações que a gente pode tomar e todas as regras que irão compô-la
O effect dentro de uma política é o switch que diz se você vai ou não permitir aquela determinada ação, então ele vai ser deny ou allow e serão somente esses dois valores.
O resource é o ARN do seu serviço AWS, o ARN é como se fosse um ID daquele serviço, então por exemplo eu tenho um EC2 e pra eu saber qual é um EC2 específico, eu tenho o ARN dele. Então é uma string que a AWS cria pra identificar ali os serviços.
O condition é uma expressão lógica, elementos que vão te ajudar a definir o que você vai fazer com aquela permissão ou negativa, ela pode ser um IP, um usuário, uma TAG, uma condição no sentido literal.
E uma coisa que também é importante falar é que também temos a negativa desses elementos, como ao invés de ter um action, teremos um NOTaction, um NOTresource, NOTcondition, e sempre que não for aquele resource, condition ou action você faz o que o effect diz.
Então, sempre que a gente falar em política do IAM, a gente fala de um documento Json com vários elementos que vão negar ou permitir determinadas ações.
E pode parecer intimidador no início e levar ao pensamento de que é necessário decorar todos esses elementos, juntos com todas as formas de associar um recurso ou não, mas pelo contrário, você não precisa decorar e sim entender o que são esses elementos e aí que entra o pulo do gato, usar uma ferramenta da AWS que é o AWS Policy Gen que irá criar a política para você.
LÓGICA DA AVALIAÇÃO DA POLÍTICA DO IAM
As lógicas de avaliação de política servem para definir um fluxo que o IAM faz para decidir se você está autorizado ou não a realizar determinada ação. É importante falar do implicit deny e saber que tudo que é IAM já começa com esse implicit deny, mas o que é isso? É basicamente falar que tudo no IAM é proibido, exceto o que é liberado. Para gente entender, vamos pensar no seguinte. Você acessa o console e tenta visualizar as instâncias EC2 que a conta possui. Nesse primeiro momento o AWS IAM assume que você não tem acesso a nada, mas aí ele corre lá e analisa as politicas que o seu usuário possui e se alguma politica disser que você tem acesso a algum ou todos os EC2 da conta, ele permite o seu acesso e caso nenhuma que você possui fale nada sobre instâncias EC2, ele assume o implict deny e você não consegue acessar nada ali do painel de EC2.
Então a lógica começa assim, você autenticou e pediu acesso ao EC2, O IAM vai assumir um implict deny nesse primeiro momento e depois passa a analisar as politicas que você tem pra ver se alguma te permite acessar esse recurso. Mas aí, imagina a seguinte situação, o IAM está analisando sua politica nessa sequência encontra um deny, na AWS além do implict deny, a gente tem o explicit deny e esse explicit deny é quando escrevemos um deny em uma política e ao contrario do implicit deny, o explicit sobrepoe um allow. Resumindo, primeiro começa com tudo negado, se tiver um allow ele permite, mas se tiver um deny escrito, ele nega novamente a sua permissão.
ROLES
Quando a gente fala sobre roles ou funções no IAM, podemos pensar que uma role é como um entidade que tem certas permissões definidas e estão ali para direcionar as autorizações que dizem quais ações podem ser feitas ali com os recursos.
O que é bem interessante ao usar as roles é que elas não estão atribuidas a um usuário ou grupo, como geralmente acontece com as permissões. Ao contrário, um usuário (ou até mesmo um serviço da AWS) pode “assumir”essa função quando precisar e depois que terminar o que precisava, “desassumir” e assim as permissões são retiradas.
O uso de roles pode ser válido em situçoes assim:
- Quando um usuário precisa de permissões adicionais por um período limitado.
- Quando aplicaçoes ou serviços da AWS precisam se comunicar com outros recursos da AWS.
- Para permitir que usuários de contas da AWS que são externas possam acessar os recursos em sua própria conta da AWS.
Isso é um jeito bastante seguro e eficaz de conceder permissões temporários, porque você não precisa mexer nos permissões permanentes do usuário. Além disso, as credenciais que o usuário/recurso recebe quando “assume” uma função são temporárias e são criadas automaticamente pela AWS. Então, você não precisa se preocupar em gerenciá-las.
MODELO TRADICIONAL RBAC
O RBAC ou role-based access control émétodo eficiente para determinar as permissões de cada indivíduo em um sistema. Ele funciona da seguinte forma, você dertemina roles, regras e atacha ao recurso, usuário, grupo que você precisa. Esse modelo é mais tradicional, mais comum e mais utilizado no IAM.
Em termos práticos, ao invés de conceder a cada usuário permissões individuais para acessar determinados recursos, o RBAC agrega estas permissões em funções. Dessa forma, os usuários são designados para uma ou mais funções, e assim, adquirem as permissões vinculadas a essa função.
É importante que você aplique o conceito do privilégio mínimo ao usar um RBAC para evitar acidentes.
MODELO ESCALÁVEL ABAC
O modelo ABAC, atribuct-based access control, ou modelo escalável usa uma variedade de atributos, incluindo os atributos do usuário, recurso, ambiente, etc, para decidir quem pode acessar o que.
No ABAC, os atributos são essencialmente qualidades ou características que podem ser utilizadas para estabelecer regras de acesso. Por exemplo, os atributos do usuário podem incluir sua função, departamento ou localização geográfica. Os atributos do recurso podem compreender o tipo de recurso (como um arquivo, um equipamento de rede, etc.) e sua classificação de segurança. Os atributos do ambiente podem englobar o horário, a localização ou a segurança da rede.
Para entender melhor, vamos usar o seguinte cenário. Imagina só que você tem vários lambdas ali e que você precisa dar permissão para alguns usuários. Se você for usar o modelo RBAC, a cada nova função lambda você precisaria adicionar o ARN na política e no modelo ABAC, a gente só cria o lambda com uma TAG e então aqueles usuários que tiverem aquela política, vão conseguir acessar tudo que tiver a TAG que você criou para esses lambdas.
E aí você pode criar a personalização que você necessitar, como TAGS para localização geografica, grupos de usuários, recursos, ambientes, etc.
O AWS IAM é um serviço global que você pode usar para gerenciar o acesso aos serviços e recursos da AWS. O acesso pode ser concedido a usuários, grupos e funções do IAM usando políticas de permissão. Ele é uma ferramenta complexa e que precisa de cuidados ao trabalhar, mas muito essencial e importante
Top comments (0)