Top 10 das melhores práticas de segurança na AWS Amazon

Neste artigo abordamos as 10 melhores e mais importantes práticas de segurança na AWS, muitas delas bastante simples de serem implementadas, que se executadas permitem que o ambiente esteja mais seguro e menos vulnerável a ataques em sua conta da AWS Amazon.

Muitas inclusive não custam nada, ou bem pouco.

Item #1: Cuidado com a conta Root: desabilite as Access Keys

A conta Root (também chamada de Root Account) é a credencial principal da sua conta na AWS. Ela é a primeira e fundamental credencial do ambiente, pois é gerada no momento da criação da conta na Amazon AWS.

Como a conta Root possui “super-poderes” ilimitados dentro do ambiente da AWS, ela não deve ser utilizada. Ao invés disso, devemos criar usuários por meio do IAM com permissões capazes de executar as tarefas administrativas que supostamente seriam executadas pela Root Account.

Uma das “portas” de acesso à AWS é o uso da API. Para estes acessos são utilizadas as credenciais do tipo Access Keys. Um passo fundamental de segurança é desativar as Access Keys da Root Account. Isto pode ser realizado acessando o IAM, e removendo as Access Keys da conta Root.

Item #2: Habilitar MFA em todas as credenciais

A AWS permite a utilização de dispositivos MFA (multi factor authentication) para acesso, por exemplo, ao Console do usuário ou à API. Em resumo, dispositivos MFA são como os utilizados pelos bancos, como tokens físicos que geram, em geral, 6 números aleatórios que precisam ser digitados no site do banco após a validação da senha do usuário.

Eles garantem uma segurança adicional à senha do usuário, que pode ser eventualmente interceptada por outra pessoa. Se isso acontecer, somente com a senha, o ofensor não conseguirá se autenticar.

Embora não seja obrigatória, a autenticação MFA na AWS Amazon é bastante desejada, importante e gratuita!

Usar MFA especialmente na Root Account é fundamental, mas também deve aplicada para todos os usuários do IAM.

Ativar o MFA é muito simples e não necessita de um dispositivo físico, podendo ser utilizado um aplicativo no celular (como o Google Authenticator). A ativação é sempre realizada na interface do IAM.

Item #3: Manter o mínimo de usuários administradores no IAM

Quando criamos usuários, grupos ou roles no IAM, é tentador utilizar políticas padrão como “Administrator” ou “Power User Access” . Não é preciso fazer grande exercício de raciocínio para perceber que esta não é uma boa prática.

Manter usuários administradores no ambiente, sem necessidade de serem de fato administradores, é um risco muito grande. Principalmente porque a grande maioria das atividades executadas dentro do ambiente, seja através de API’s ou Console do usuário não requerem permissões de um administrador da AWS.

Além de manter o mínimo de administradores no IAM, o ideal é somente utilizá-los quando realmente for necessário e não no dia a dia, onde as tarefas podem ser executadas com usuários menos privilegiados.

Item #4: Use Roles para instâncias EC2

Uma funcionalidade muito importante do cloud da AWS Amazon é a possibilidade de utilizarmos roles dentro de instâncias EC2. As roles permitem a rotação automática e frequente de credenciais de segurança (Access Keys) dentro das instâncias, ao invés de manter estes dados salvos dentro de arquivos ou bases de dados.

Com as roles, as aplicações podem capturar as credenciais de acesso à API da AWS através do Instance Metadata, à cada vez que precisam executar uma chamada. O IAM cuida do rotacionamento destas credenciais várias vezes ao dia.

Lembre-se de adicionar roles à sua instância no momento do lançamento, pois no momento que escrevemos este artigo, a AWS não permite adicionar roles (ou alterá-las) depois de lançada a máquina no EC2.

Item #5: Aplique o menor privilégio possível no IAM

No IAM, é possível criarmos:

• Usuários: são as credenciais de usuários (ou de aplicações que não suportam roles) para acesso ao ambiente.
• Grupos: agrupam os usuários dentro de funções comuns.
• Roles: são as credencias de instâncias no EC2

Quando criamos qualquer um dos itens acima, por padrão, esta credencial não poderá fazer nada. Para que ela seja útil, é preciso que apliquemos uma política àquela credencial (usuário, grupo ou role) para acesso à AWS Amazon.

A primeira observação que fazemos é: nunca aplique políticas diretamente aos usuários. Aplique somente em grupos, isso facilita a gestão das credenciais dentro de funções em grupos.

O segundo e importante ponto: quando aplicar políticas de acesso a grupos ou roles é importante aplicar o mínimo possível de permissões. Por exemplo, se uma determinada role do EC2 existe para que o servidor envie backups para um bucket no S3, libere somente acesso a leitura e gravação a este bucket específico de backup do S3 (e não utilize, por exemplo, a política padrão S3FullAccess, que libera acesso a todos os buckets do S3).

O importante é simples: se o usuário não precisa da permissão, não permita. Na pior das hipóteses, em caso de problemas, é mais fácil para entender o que aconteceu com o ambiente quando menos credenciais possuem permissão em um determinado serviço.

Item #6: Rotacione as chaves frequentemente

Esta é uma das mais tradicionais ações de segurança para todos os ambientes. Na AWS Amazon elas compreendem além da troca das senhas de acesso dos usuários (que são utilizadas para acesso ao Console do usuário), a rotação de Access Keys de usuários (que permitem acesso à API).

Através da interface do IAM é possível realizar o processo de rotação de senhas e Access Keys. Para estas últimas, vale lembrar que é possível ativar duas chaves simultâneas, permitindo assim que a antiga seja trocada pela nova. Quando a troca for concluída, deve-se remover a antiga.

Item #7: Utilize autoscaling

Utilizar o serviço AWS AutoScaling é uma medida que aparentemente parece estar relacionada a prover maior escalabilidade ao ambiente, e isto é verdade. O que muitas pessoas não percebem é que o autoscaling pode colaborar, em muito, para melhorar a segurança do ambiente.

Primeiro, porque através dele é possível reciclar os servidores sistematicamente (por exemplo, diariamente). Com isso é possível minimizar efeitos de eventos atuais sofridos pelos servidores (como por exemplo implantação de bots nas aplicações). Reduzindo o tempo de vida do servidor, conseguimos reduzir a probabilidade de ter um servidor comprometido no ambiente.

O segundo ponto importante para utilizar autoscaling é exatamente porque através da alta escalabilidade que ele provê, é possível suportar demandas de ataques DDoS. Neste tipo de ataque, que aliás é bastante difícil de ser evitado, uma enorme demanda de acessos passa a chegar no ambiente, com um único objetivo: tirar o serviço do ar. A primeira medida quando este ataque acontecer é sempre escalar o ambiente para suportar a alta demanda enquanto se estuda uma maneira de realizar um bloqueio ou identificar o atacante.

Item #8: Não utilizar 0.0.0.0/0 em Security Groups

Os Security Groups são utilizados para liberar portas de acesso às instâncias ou loadbalancers (ELB) dentro da AWS Amazon. A configuração deles é bastante simples, lembra bastante a criação de regras de um Firewall convencional (stateful).

Por padrão todo o tráfego de entrada de um Security Group (inbound) é bloqueado, obrigando o usuário a criar as regras de liberação.

Por isso a observação aqui é simples: basta liberar somente para os endereços de origem necessários, e evitar ao máximo a liberação para o “mundo todo”, ou seja, o endereço 0.0.0.0/0.

Esta ação é especialmente importante para serviços de administração remota, como SSH ou RDP (Windows).

Item #9: Utilizar VPC’s e Network Acls

Embora sejam atualmente o modo padrão de lançamento de instâncias na AWS, as VPC’s frequentemente não são utilizadas pelos clientes. Além disso, muitos clientes que utilizam VPC, em geral não utilizam adequadamente as Network ACL’s.

Em resumo, Network Acl’s são Firewalls que servem para filtrar o tráfego entre redes de uma VPC, diferentemente do Security Group, que trata o tráfego por instância. Outra diferença importante da NACL para o Security Group é que enquanto a primeira é stateless (não leva em consideração o estado do pacote, portanto precisa de regras liberando os dois sentidos do tráfego), o segundo é stateful (apenas a regra de início do tráfego é necessária ser criada).

Por padrão as NACL’S possuem regras liberando todo o trafégo, e a maioria dos clientes as mantém assim. É importante, todavia, rever esta política para refletir de fato o perfil de tráfego do ambiente.

Além disso, as NACL’s são especialmente úteis para bloquear IP’s específicos que estejam atacando o ambiente, já que uma vez bloqueado aqui, todo o tráfego para instâncias ou load balancers dentro da VPC estarão bloqueados.

Item #10: Ativar o serviço CloudTrail

A AWS Amazon possui um serviço extremamente simples e importante: o CloudTrail. Basicamente a responsabilidade deste serviço é logar todas as ações realizadas no ambiente da AWS, ou seja, toda alteração realizada no ambiente é logada, incluindo informações como horário, credencial que realizou a alteração e qual alteração foi realizada.

Todas estas informações vão para um bucket no S3 em formato simples de log (texto plano). Se for necessário, existem ferramentas de terceiros capazes de analisar estes logs para geração de relatórios, por exemplo, ou mesmo para monitoração das atividades.

Além disso, é possível através do Clouwatch gerar alarmes a partir de possíveis dados do CloudTrail. Um exemplo simples de alarme seria: caso alguém lance uma nova instância na região us-west-1, envie-me um email.

Algumas observações importantes sobre o CloudTrail são:

• Ele deve ser ativado por região (não é um serviço global). Ative o CloudTrail em todas as regiões, mesmo as que não estiverem sendo utilizadas: isto permite logar todas as ações realizadas dentro da nuvem da AWS Amazon.
• Todos os logs podem ir para um único bucket, mas atenção: não libere acesso de gravação neste bucket para os usuários (e roles). Isso evita que usuários tenham permissão para deletar logs dentro do CloudTrail bucket e, portanto, eliminar eventuais “rastros”.
• Se o objetivo for de manter os logs somente por um tempo (exemplo 6 meses) ative o lifecycle no bucket do S3, solicitando para eliminar os arquivos mais velhos do que esta data.
• Se o objetivo for manter os logs para “sempre”, é possível usar o lifecycle do bucket para enviar os logs ao Glacier e, desta forma, pagar um valor mais baixo pelos gigas armazenados de logs.

Vale lembrar que o custo do CloudTrail é irrisório: unicamente o espaço do S3 (ou do Glacier) armazenado.