Este artigo é totalmente dedicado ao AWS IAM, como já comentamos no post anterior, esse serviço é de longe o mais importante da AWS, afinal é nele que definimos todas as permissões e níveis de acesso que determinado usuário e/ou serviço poderá ter. Podemos assumir que o AWS IAM é o principal recurso que temos para gerenciar o conceito de responsabilidade compartilhada que toda cloud pública tem.
Muitas vezes essas configurações não são feitas da melhor forma possível nem utilizando as melhores práticas indicadas pela AWS. Abaixo você pode conferir breve resumo dessas melhores práticas:
- Evite ao máximo usar a conta root ou nem use!!! Ela deve ser usada apenas para criar a conta na AWS e definir pelo menos o primeiro user admin e caso seja uma conta empresarial, o melhor é que o "dono" dessa conta seja alguém que nunca sairá da empresa por exemplo;
- Criar usuários individuais;
- Crie grupos e gerencie as permissões através deles;
- Sempre conceda o menor privilégio de permissão, comece sempre com o mínimo de acesso e aumente caso seja realmente necessário;
- Configure uma política de senhas forte;
- MFA, Múltiplo Fator de Autenticação, sempre habilite, principalmente para usuários com privilégios de Admin;
- Use e abuse das IAM Roles, principalmente com instâncias EC2;
- Dê preferência para IAM Roles para compartilhar acessos, é muita mais fácil e simples de gerenciar;
- Sempre renove suas credenciais de segurança;
- Ative o AWS CloudTrail para fazer auditoria - "O AWS CloudTrail é um serviço que possibilita governança, conformidade, auditoria operacional e auditoria de riscos em sua conta da AWS".
- Utilize "Condition" para restringir ainda mais os acessos (Ex.: Um bucket S3 estará com acesso full liberado SE o usuário fizer o login com MFA).
E não falo apenas do acesso de forma profissional, mas também de sua conta pessoal, afinal quando criamos uma conta para estudos por exemplo, temos acesso aos itens do free tier da AWS e dá para fazer/aprender muita coisa com os serviços que fazem parte do nível gratuito. Neste artigo conto um pouco sobre o que é o nível gratuito da AWS, além de falar como você pode monitorar sua conta e não exceder seu budget.
Antes de falarmos um pouco sobre os recursos do IAM que tal validar o status de segurança de sua conta pessoal (ou até mesmo profissional)? São 5 passos bem simples que precisam ser realizados assim que você cria a sua, e que muitas vezes são ignorados. Caso não tenha interesse, vá para o final do artigo que vou dar mais detalhes sobre os recursos do AWS IAM.
Ao criar a conta e acessar o IAM a sua tela deve ficar da seguinte forma:
E a seguir os 5 passos que você deve seguir:
1. Utilize grupos para dar permissões. Ao menos um grupo precisa ser criado, vamos criar um grupo que terá acesso full, acesso de Administrador (root) a esta conta, para isso siga os abaixo.
Vá em Groups - Create New Group.
Step1: Defina um nome para o Grupo. No exemplo, está Admins, pois este grupo terá acesso full na conta.
Step2: Adicione policies para este grupo. A policy que dá acesso full a conta é a AdministratorAccess. Dessa forma podemos vincular ao menos um usuário a este grupo e ao invés de utilizar o root para acessar a conta (conforme boas práticas), utilizaremos este novo usuário que será criado no segundo passo.
Step3: Revise e crie o grupo.
Feito isso, já podemos partir para o segundo passo, criar ao menos um usuário e vincular a este grupo, para não utilizarmos mais o root no dia a dia.
2. Crie usuários. Um usuário com acesso de administrador precisa ser criado para que a conta root não seja utilizada nas tarefas diárias, para isso siga os passos abaixo.
Vá em Users - Add user.
Step1: Escolha o nome do usuário. Como esse usuário irá fazer o papel de Admin da conta, você pode marcar os dois tipos de acesso, via acesso programático (permite que você utilize as credenciais de acesso - Access Key ID e Secret access Key - para acessar a AWS) e via console, já coloque uma senha forte e assim não será necessário alterar depois.
Importante: O acesso programático é extremamente perigoso, sempre guarde muito bem as credenciais de acesso geradas para tal e jamaisssss coloque essa informação no GitHub e afins.
Step2: Vincule o usuário a um grupo. Ou escolha outras opções de acordo com a necessidade. Aqui vamos vincular o usuário ao grupo Admins recém criados.
Importante: Para que usuários IAM tenham acesso ao Billing dessa conta não basta eles estarem com permissões de Admins, a conta root precisa "liberar" esse acesso e para isso existe um item que precisa ser atualizado. Vá no nome da conta e depois em My Account/Minha Conta que fica no menu superior a direita, role a tela até chegar no item, IAM User and Role Access to Billing Information - Vá em Edit - Clique em Activate IAM Access e Update.
Step3: Adicione Tags ao usuário. Este item é opcional e vamos deixá-lo em branco, mas ele serve para identificar e/ou separar os recursos AWS, ele utiliza o conceito chave:valor. Por exemplo, queremos separar usuários, máquinas, buckets utilizadas pelo departamento Financeiro da empresa dos itens do departamento Fiscal, poderíamos colocar Departamento: Financeiro ou Departamento: Fiscal, de acordo com o uso/criação.
Step4: Revisar as informações e criar o usuário.
Step5: Usuário criado, e ele traz as informações de acesso para este usuário, como: URL para acessar o console, afinal não utilizaremos mais a opção Root user e sim IAM user, e caso não utilize a url fornecida nesse momento, você precisará saber o ID da conta do root. Além disso, também é fornecido o Access Key ID e Secret access Key desse usuário.
Importante: Faça o Download do .csv ou salve a Access Key ID e Secret access Key ou envie por e-mail, pois essa será a única vez que poderá visualizar essa informação.
Pronto! Grupo e Usuário criado. Estamos quase finalizando, logo mais não precisaremos acessar com o usuário root da conta.
3. Defina uma politica para senhas na conta. É essencial definir uma politica para que sejam criadas senhas fortes.
Para isso, é só expandir o último item e clicar no botão Manage Password Policy
Abrirá a página abaixo, é só clicar em Set password policy.
Escolha os itens, aconselho a escolher os 4 primeiros itens pelo menos. Clique em Save changes.
E está feito!
4. Ative o MFA na conta root. É onde você consegue habilitar o Múltiplo Fator de Autenticação. Aconselho inclusive a habilitar o MFA em todas as contas que possuem acesso de administrador.
Vá para o item MFA, que será o único com o " ! " e clique em Manage MFA.
Ele vai abrir está página e você de clicar no botão Activate MFA.
Ao clicar abrirá as seguintes opções. Optei por validar com um app no meu celular.
Dá pra ver uma lista de apps compatíveis, eu instalei o Authy. Após instalar o app no celular, mostre o QR code, leia com o app e coloque o primeiro código, espere o tempo e informe o segundo código e clique em Assign MFA.
Importante: Salve o print desse QR code, caso você perca ou troque de telefone.
A mensagem abaixo vai aparecer
E ao fechar irá para a tela a seguir. Onde dá para visualizar e gerenciar o MFA gerado para a conta.
Agora, todas as vezes que acessar com o root da conta, depois que informar a senha, vai pedir o código logo é só aplicar o app e informar o número e seja feliz com sua conta mais protegida.
5. Não deixe credenciais de segurança para o root. Normalmente quando criamos a conta, este é o único item que está com check ok, portanto não temos o que fazer, caso você já seja um usuário da AWS e utilize a conta root apenas, faça todo o procedimento acima e depois apague suas credencias de segurança e gere novas para o user que acabou de criar.
E abaixo tem um exemplo de como a sua conta root deve ficar!!!
Que tal mais detalhes sobre os recursos do AWS IAM?
IAM Users - É o velho conceito de usuários que temos, seja ele um usuário por pessoa, por aplicação, por API. Exemplo fictício fora do mundo AWS: Você é contratado numa empresa e ao chegar para acessar o seu computador te passam um usuário e senha.
IAM Groups - É outro conceito simples, determinado usuário pertence a um grupo de pessoas que podem ter acessos a determinadas coisas na empresa. Exemplo fictício fora do mundo AWS: Ainda pensando na sua contratação na empresa, você é do departamento do Financeiro e aquele usuário que você acessou o computador vai estar no grupo Financeiro e vai poder acessar as pastas ContasPagar e ContasReceber na rede.
IAM Policies - É o item mais granular de permissões na AWS. Aqui você vai poder dizer que determinado recurso pode ou não executar uma ou mais ações. Por exemplo, podemos definir uma policy onde se tenha apenas o acesso de start e stop de instâncias EC2. Exemplo fictício fora do mundo AWS: Continue a pensar na sua contratação, o seu usuário está em apenas no grupo Financeiro, mas também está vinculado a uma policy que permite que você acesse para visualizar um determinado arquivo na pasta Faturamento, mas não tenha acesso de copiar nem modificar este arquivo.
IAM Roles - O conceito é bem similar ao de IAM Users, Roles é um conjunto de policies que permitem o acesso aos recursos da AWS, podendo executar n funções, só que ao invés de ser vinculado a apenas uma pessoa, várias podem ter acesso. Além disso, ele é um acesso temporário ou especifico para um dado recurso ou situação, ele pode ser facilmente vinculado/desvinculado de um recurso ou conta. Exemplo fictício fora do mundo AWS: Essa empresa criou um conjunto de regras, que em determinado período você pode acessar a pasta Contabilidade e realizar consultas e alterações em alguns documentos e pastas.
ARNs (Amazon Resource Names) - É um identificador único dos recursos da AWS. Sempre que vamos criar um nível maior de granularidade em policies devemos informar o ARN do item em questão. É um item que pode passar desapercebido quando você utiliza apenas a console (mas você consegue vê-lo e copiá-lo), mas quem lida com criação de policies diariamente ou utiliza os recursos AWS via API, seja com o Terraform, Ansible ou o AWS CLI já deve conhecer bem o arn. A estrutura geral do ARN é:
arn:partition:service:region:account-id:resource
Onde:
- arn: A primeira parte é sempre “arn”.
- partition: A partição na qual o recurso está localizado. Uma partição é um grupo de regiões da AWS. Normalmente sempre é "aws", salvo se utilizar uma região especial como a China que seria "aws-cn" ou uma do governo "aws-us-gov".
- service: É um serviço da AWS, como "s3" ou "ec2".
- region: É a região que o serviço está localizado. Exemplo: us-east-2 para Leste dos EUA (Ohio).
- account-id: O ID da conta da AWS que possui o recurso, sem hífens. Exemplo: 1234567890.
- resource: É o identificar do recurso, que pode ser o nome ou o ID ou um caminho do recurso. Depende do serviço da AWS que vai utilizar.
Exemplos:
arn:aws:s3:::nomebucket
arn:aws:s3:::nomebucket/pasta
arn:aws:ec2:us-east-2:1234567890:instance/i-1234567890abczx
Para finalizar, a AWS oferece dois recursos bem simples para nos ajudar a validar e até mesmo sermos mais assertivos ao criar as policies, que na minha opinião é um dos itens mais chatos de se trabalhar no IAM.
Temos o IAM Policy Simulator, que é um simulador como o próprio nome já diz, e com ele é possível validar se o que você criou está de acordo ou não. E para nos ajudar a gerar as policies temos o AWS Policy Generator, você configura o que precisa e como precisa, e ele gera o código JSON para que você copie e cole no console quando for criar suas policies. Apesar de ambos serem simples de usar, pretendo dedicar um artigo exclusivo para eles.
Muitos outros pontos do AWS IAM não foram falados aqui nesse artigo, porém acredito que a principal mensagem foi passada, o IAM é um serviço de enorme potencial e não pode ser negligenciado, portanto dedique horas de estudo e planeje muito bem a configuração e segurança de sua(s) conta(s) e serviços.