Top 10 dicas de segurança para aperfeiçoar na sua conta AWS

12 de setembro de 2022: Este blogpost foi atualizado para refletir o novo nome do AWS Single Sign-On (SSO) – AWS IAM Identity Center. Leia mais sobre a mudança de nome aqui.

Se você quiser aperfeiçoar a segurança na nuvem, um bom lugar para começar é seguindo as 10 principais dicas de segurança na nuvem que Stephen Schmidt, diretor de segurança da informação da AWS, expôs no AWS re:Invent 2019. Abaixo estão as dicas, expandidas para ajudá-lo a tomar ação.

1) Mantenha os contatos atualizados em sua conta

Quando a AWS precisa falar com você sobre a sua conta AWS, nós utilizamos as informações de contato definidas na Console de Gerenciamento da AWS, incluindo o e-mail utilizado para criar a conta e os outros e-mails listados como contatos alternativos.

Todos os endereços de e-mail devem ser configurados para serem entregue a um “alias” ou uma lista de correio, ou seja, entregando as mensagens de alerta e contato da AWS para mais de uma pessoa. Você também deve ter um processo para verificar regularmente se esses endereços de e-mail funcionam e se você está avaliando esses e-mails, especialmente notificações de segurança que você pode receber de abuse@amazon.com. Saiba como definir os contatos alternativos para ajudar a garantir que alguém esteja recebendo mensagens importantes, mesmo quando você não estiver disponível.

2) Utilize o segundo fator de autenticação (MFA)

MFA é a melhor forma de proteger as contas de um acesso indevido. Sempre configure o MFA para o usuário root e usuários AWS Identity and Access Management (IAM). Se você utiliza o AWS IAM Identity Center (sucessor do AWS Single Sign-On) para controlar o acesso na AWS ou para federar seu gerenciamento de identidade corporativa, você pode impor o MFA. Implementar o MFA no seu diretório de Identidade federada (IdP) implica que você consegue adquirir vantagens do processo de MFA já existentes em sua organização. Para começar a utilizar, veja Utilizando Fato de autenticação múltipla (MFA)

3) Sem credenciais incorporadas ao código

Quando você cria aplicações na AWS, é possível utilizar o AWS IAM Role para designar credenciais temporárias, com curto tempo de vida, para chamadas de outros serviços AWS. Contanto, algumas aplicações necessitam credencias de longo tempo de vida, como por exemplo senha de banco de dados ou outras chaves de API. Se este for o caso, você nunca deve incorporar as informações na aplicação ou no código fonte.

Você consegue utilizar o AWS Secrets Manager para controlar as informações na sua aplicação. O Secrets Manager permite que você rotacione, gerencie, e recupere credenciais para o banco de dados, chaves para API, e outros segredos durante o ciclo de vida. Usuários e aplicações podem recuperar os segredos com uma chamada para as APIs do Secrets Manager, eliminando a necessidade de incorporar no código a informação como texto simples. Você também deveria aprender como utilizar o AWS IAM roles para aplicações rodando no Amazon EC2. Para um melhor resultado, aprenda como providenciar de forma segura as credenciais do banco de dados para funções AWS Lambda utilizando o Secrets Manager

4) Limite o security groups

Security Groups é o modo chave para que você consiga permitir o acesso de rede para recursos provisionados na AWS. Garantindo que apenas as portas necessárias estão abertas e conexões serão permitidas a partir do intervalo de redes conhecidas é um passo fundamental para a segurança. Você consegue utilizar serviços como  AWS Config ou AWS Firewall Manager para programaticamente garantir que a configuração do Security Group da sua Virtual Private Cloud (VPC) é o pretendido. O pacote de regras do acesso à rede analisa sua configuração de rede da Amazon Virtual Private Cloud (Amazon VPC) para determinar se suas instâncias Amazon EC2 podem ser acessadas de redes externas, como a Internet, um Virtual Private Gateway, ou AWS Direct Connect. AWS Firewall Manager pode ser utilizado para aplicar de forma automática as regras do AWS WAF para recursos voltado para a Internet. Saiba mais em detectando e respondendo a mudanças no Security Group na VPC.

5)Política de dados intencional

Nem todos os dados são criados iguais, o que significa que a classificação correta dos dados é crucial para sua segurança. É importante acomodar as trocas complexas entre uma postura rígida de segurança e um ambiente ágil flexível. Uma postura rígida de segurança, que exige procedimentos longos de controle de acesso, cria garantias mais fortes sobre a segurança dos dados. No entanto, essa postura de segurança pode contrariar ambientes de desenvolvimento ágeis e de ritmo acelerado, onde os desenvolvedores exigem acesso de autoatendimento aos armazenamentos de dados. Crie sua abordagem para a classificação de dados para atender a uma ampla gama de requisitos de acesso.

Como você classifica os dados não precisa ser tão binário quanto público ou privado. Os dados vêm em vários graus de sensibilidade e você pode ter dados que caem em todos os diferentes níveis de sensibilidade e confidencialidade. Projete seus controles de segurança de dados com uma combinação apropriada de controles preventivos e de detetive para corresponder adequadamente à sensibilidade dos dados. Nas sugestões abaixo, lidamos principalmente com a diferença entre dados públicos e privados. Se você não possui uma política de classificação atualmente, pública versus privada é um bom ponto de partida.

Para proteger seu dado uma vez que esteja classificado, ou enquanto está sendo classificado:

1.      Se você tiver buckets do Amazon Simple Storage Service (Amazon S3) para uso público, mova todos esses dados para uma conta separada da AWS reservada para acesso público. Configure políticas para permitir que apenas processos — não humanos — movam dados para esses buckets. Isso permite que você bloqueie a capacidade de tornar um bucket público do Amazon S3 em qualquer outra conta da AWS.

2.      Use o Amazon S3 para bloquear o acesso público em qualquer conta que não possa compartilhar dados por meio do Amazon S3.

3.      Use duas roles diferentes do IAM para criptografia e descriptografia com KMS . Isso permite que você separe a entrada de dados (criptografia) e a revisão de dados (descriptografia) e permite que você faça a detecção de ameaças nas tentativas de descriptografia falhadas, analisando essa função.

6) Centralize os logs do CloudTrail

Log e o monitoramento são partes importantes de um plano de segurança robusto. Ser capaz de investigar alterações inesperadas em seu ambiente ou realizar análises para iterar sua postura de segurança depende de ter acesso aos dados. A AWS recomenda que você grave logs, especialmente do AWS CloudTrail, em um bucket do S3 em uma conta da AWS designada para registro em log (Log Archive). As permissões no bucket devem impedir a exclusão dos logs e também devem ser criptografadas em repouso. Depois que os logs estiverem centralizados, você poderá se integrar com soluções SIEM ou usar os serviços da AWS para analisá-los. Saiba como usar os serviços da AWS para visualizar logs do AWS CloudTrail. Depois de centralizar os logs do CloudTrail, você também pode usar a mesma conta do Log Archive para centralizar logs de outras origens, como o CloudWatch Logs e os balanceadores de carga da AWS.

7) Validade as IAM Roles

À medida que você opera suas contas da AWS para criar recursos, você pode acabar criando várias IAM Roles que você descobre mais tarde que não precisa. Use o AWS IAM Access Analyzer  para analisar o acesso aos recursos internos da AWS e determinar onde você tem acesso compartilhado fora de suas contas da AWS. A reavaliação rotineira das roles e permissões do AWS IAM com o Security Hub ou produtos de código aberto, como Prowler, lhe dará a visibilidade necessária para validar a conformidade com suas políticas de governança, risco e conformidade (GRC). Se você já ultrapassou esse ponto e já criou várias funções, você pode pesquisar funções do IAM não utilizadas e removê-las.

8) Tome medidas sobre as descobertas do Amazon GuardDuty

AWS Security Hub, Amazon GuardDuty, e AWS Identity and Access Management Access Analyzer são serviços gerenciados da AWS que fornecem descobertas acionáveis em suas contas da AWS. Eles são fáceis de ativar e podem se integrar em várias contas. Ligá-los é o primeiro passo. Você também precisa tomar medidas quando você vê as descobertas. As ações a serem tomadas são determinadas pela sua própria política de resposta a incidentes. Para cada descoberta, certifique-se de ter determinado quais devem ser as ações de resposta necessárias.

A ação pode ser notificar um ser humano para responder, mas à medida que você tiver mais experiência em serviços da AWS, você desejará automatizar a resposta às descobertas geradas pelo Security Hub ou pelo GuardDuty. Saiba mais sobre como automatizar a resposta e a correção das descobertas do Security Hub.

9) Rotacionar chaves

Uma das coisas que o Security Hub fornece é uma visão da postura de conformidade de suas contas da AWS usando os CIS benchmarks  Uma dessas verificações é procurar usuários do IAM com chaves de acesso com mais de 90 dias. Se você precisar usar chaves de acesso em vez de IAM Roles, você deve rotacionar regularmente. Analise as práticas recomendadas para gerenciar chaves de acesso da AWS para obter mais orientação. Se seus usuários acessarem a AWS via federação, você poderá remover a necessidade de emitir chaves de acesso da AWS para seus usuários. Os usuários se autenticam no IdP e assumem uma função do IAM na conta da AWS de destino. O resultado é que credenciais de longo prazo não são necessárias, e seu usuário terá credenciais de curto prazo associadas a uma IAM Role.

10) Esteja envolvido no ciclo de desenvolvimento

Todas as orientações até este momento foram focadas na configuração de tecnologia que você pode implementar. O último conselho, “estar envolvido no ciclo de desenvolvimento”, é sobre pessoas e pode ser amplamente resumido como “aumentar a cultura de segurança da sua organização”. O papel das pessoas em todas as partes da organização é ajudar a empresa a lançar suas soluções de forma segura. Como pessoas focadas na segurança, podemos orientar e educar o resto de nossa organização para entender o que precisam fazer para elevar o nível de segurança em tudo o que constroem. Segurança é o trabalho de todos — não apenas para aqueles que têm o título de trabalho.

O que as pessoas de segurança em todas as organizações podem fazer é facilitar a segurança, deslocando o processo para tornar a ação mais fácil e desejável que seja quase a mais segura. Por exemplo, cada equipe não deve criar sua própria federação de identidade ou solução de log. Somos mais fortes quando trabalhamos juntos, e isso se aplica à proteção da nuvem também. O objetivo é tornar a segurança mais acessível para que os colegas de trabalho queiram conversar com a equipe de segurança porque eles sabem que é o lugar para obter ajuda. Para obter mais informações sobre como criar esse tipo de equipe de segurança, leia Cultivando Liderança de Segurança.

Agora que você revisitou as 10 principais coisas para tornar sua nuvem mais segura, certifique-se de que as tenha configuradas em suas contas da AWS — e construa com segurança!

Traduzido por:

Kimmy Wu é arquiteta de soluções e responsável por ajudar clientes enterprise, com foco na área financeira, a criarem workloads que permitem o avanço da sua jornada de transformação digital na nuvem da AWS.