AWS IAM (AWS Identity and Access Management) é o serviço gerenciamento de identidades da AWS (Amazon Web Services). São reconhecidas como identidades os grupo de usuários, usuários e funções (roles). Com esse serviço é possível ter controle sobre a autenticação dos usuários e sobre quais serviços e recursos eles podem acessar dentro da conta da AWS.
Ao criar uma conta na AWS é necessário informar um e-mail que será considerado como usuário root, ou seja, o principal usuário da conta AWS. Esse é o único usuário que tem acesso total sobre todos os recursos e consequentemente sobre todos os demais usuários da conta, então é importante ter todo o cuidado possível com esses dados de acesso, pois se suas credenciais forem comprometidas, toda a sua conta também será. A própria AWS recomenda que o usuário root não seja utilizado no dia a dia, e sim apenas para as funções que os outros usuários não podem executar. Dito isto, já sabemos que temos que criar um usuário no serviço IAM para as tarefas diárias. E se está achando confuso, eu confirmo, sim, o proprietário terá dois usuários, o root e outro usuário que deverá ser criado no serviço IAM, para as tarefas diárias, com uma permissão de administrador. Os usuários criados no IAM são conhecidos por possuirem credenciais de longo prazo, pois conseguem acessar a conta até que alguém remova ou desabilite esse usuário.
O IAM faz parte das tecnologias de segurança da AWS, então é importante citar algumas boas práticas de segurança recomendadas ao utilizar o serviço que por muitas vezes são negligenciadas por parte de quem gerencia a nuvem. Lembro que após ocorrer o incidente de segurança já é tarde para levar em consideração as práticas de segurança.
Boas práticas de segurança
-
Proteção do usuário principal (root)
Como já citei anteriormente, não devemos utilizar o usuário root no dia a dia e sim um usuário com permissão de administrador. -
Habilitar MFA
O multifator de autenticação deve ser habilitado para todos os usuários da conta, inclusive o usuário root. Com essa opção não basta ter o usuário e senha para logar mas também, por exemplo, um segundo código gerado por um aplicativo que é atualizado a cada 30 segundos. -
Atualização das senhas
Deve existir uma política de padrões de senha que exija a atualização recorrente delas e também que tenha um mínimo de caracteres contendo letras maiúsculas, minúsculas, números e caracteres especiais para assim aumentar a segurança. -
Privilégio mínimo
Ao criar um usuário devemos sempre dar permissões míminas para ele e aumentar apenas conforme necessidade. -
Dar preferência aos usuários federados
Não é necessário criar usuários no serviço IAM para dar acesso à conta. É recomendável utilizar usuários já cadastrados em provedores de identidades reconhecidos, como por exemplo, Google Workspaces e Active Directory da Microsoft. Com essa opção podemos utilizar usuários já gerenciados por nós em outras plataformas para acessar a AWS. Uma funcionalidade importante na utilização dos usuários federados é poder limitar o tempo de acesso deles entre 1 e 12 horas.
Identidades
Vamos falar um pouco sobre os grupos de usuários, usuários e funções.
Grupo de usuários
Os grupos de usuários representam um conjunto de usuários do IAM. É aconselhável gerenciar as permissões dos usuários a partir dos grupos e não a partir dos usuários. Isso facilita o gerenciamento das permissões de acesso dos usuários que tende a ficar mas complexo conforme cresce a quantidade de usuários. Ao dar ou remover permissão ao grupo, automaticamente é refletida essa configuração nos usuários
Usuários
Os usuários são quem de fato irão acessar a conta da AWS, seja pelo console de gerenciamento (navegador), SDK ou CLI. Esses usuários terão acesso aos recursos e serviços conforme permissões atribuídas ao seu grupo ou a ele próprio, pois é possível atribuir permissão diretamente ao usuário, além de funções que veremos logo em seguida. Já os usuários federados recebem a permissão via funções.
Funções
As funções são como se fossem usuários, porém elas são utilizadas sendo atribuídas aos usuários ou serviços em determinados momentos. No momento em que um usuário assume uma função ele deixa de lado todas as permissões atribuídas a ele para utilizar apenas as permissões atribuídas à função. Realmente no primeiro momento é um pouco confuso mas vou citar um exemplo para facilitar o entendimento. Quando utilizamos o serviço do RDS (Relational Database Service) para hospedar um banco de dados e precisamos guardar o backup desse banco no serviço do S3 (Simple Storage Service), precisamos dar permissão para o RDS salvar esse arquivo de backup no S3 e nesse caso teremos que criar uma função com permissão de escrita no S3 e atribuir esse função ao RDS. Um exemplo ainda melhor é dar permissão do EC2 (Elastic Compute Cloud) acessar um bucket do S3, porque geralmente as pessoas instalam o AWS CLI (AWS Command Line Interface) na máquina do EC2 com permissões de longo prazo de um usuário do IAM e isso não é nem um pouco recomendável, pois essas credenciais ficarão vulneráveis e também terão que ser modificadas caso o profissional siga as recomendações de segurança que é manter a senha atualizada.
Políticas
As políticas são formadas por permissões que podem dar ou negar acesso a um recurso ou serviço e em sua maioria são atribuídas aos grupos, usuários e funções. Existem 6 tipos de políticas, porém normalmente as que mais teremos contato são as de identidade e recurso. As de identidade são atribuídas diretamente as identidades e as de recurso existem em alguns serviços da AWS como o S3.
Composição da permissão
A permissão é formada por um JSON (JavaScript Object Notation) que tem seus atributos formados de acordo com o tipo de política.
Política de identidade
A imagem acima apresenta uma política que dá permissão para ler e deletar o bucket chamado backup-documentos, caso a requisição tenha origem no IP 10.10.10.10/24. O atributo "Effect" tem a função de permitir (Allow) ou negar (Deny) o acesso, por padrão, dentro da AWS toda requisição que não tenha a permissão explícita será negada, ou seja, só em casos específicos veremos a opção "Deny" porque a princípio tudo já está negado. Pode acontecer de liberarmos todo o acesso para o serviço do EC2, mas negarmos apenas a exclusão das instâncias por ser algo bem sensível, então nesse caso utilizaremos o "Deny" para a ação "ec2:TerminateInstances". O atributo "Action" é justamente a ação que o usuário poderá ou não fazer, nela consta o serviço seguido da ação e toda a listagem de ações pode ser encontrada na documentação da AWS que está na seção fonte no final desta matéria. Por exemplo, teremos as ações de ler, editar, listar e deletar determinados recursos e serviços. Já o atributo "Condition" não é obrigatório, mas quando ele estiver presente, a ação só terá efeito caso a condição seja atendida. Existem condições bem interessantes para quem trabalha com uma grande quantidade de usuários, como controlar o acesso por tags. Podemos colocar a tag (Name: Setor, Valor: Administração) nos recursos e usuários que fazem parte da administração. Assim os usuários da administração não terão acesso aos recursos que possuírem a tag (Name: Setor, Valor: Financeiro), porque o valor da tag setor dos usuários da administração não será igual ao valor da tag setor dos recursos. E finalmente o atributo "Resource" é quem indica qual recurso o usuário terá acesso.
Política de recurso
Essa política é basicamente igual a política de identidade, a diferença está no atributo "Principal" que define quais usuários terão acesso aos recursos presentes no S3. Para não haver conflito de políticas existe uma hierarquia e a política de recursos está acima da política de identidade, ou seja, você pode dar permissão de acesso a todos os recursos do S3 para um determinado usuário utilizando a política de identidade mas se esse usuário tiver o acesso negado na política de recurso do S3, ele não conseguirá acessar.
Access Advisor (Consultor de acesso)
Esse serviço ajuda a manter os usuários com privilégio mínimo de acesso e o controle sobre eles. Ao acessar o cadastro do usuário no IAM e ir na aba Access Advisor (Consultor de acesso), é possível saber há quanto tempo um usuário não acessa determinado serviço e também qual permissão ele utilizou quando acessou. Caso tenha muito tempo que um usuário não acessa determinado serviço, então é um indício que ele não precisa ter esse acesso e assim podemos remover essa permissão.