O que tenho aprendido sobre segurança na AWS
Perspectiva de uma estudante de cibersegurança
A segurança dentro da nuvem AWS é composta por um vasto ecossistema de serviços e ferramentas que permitem aos clientes proteger seus dados, gerenciar identidades e garantir a conformidade de suas aplicações. E tudo isso é construído sobre o que eu chamaria de “alicerce” de responsabilidade compartilhada, tecnologias avançadas e boas práticas de arquitetura.
Visto que a AWS protege a infraestrutura global que executa todos esses serviços dos quais grande parte, são responsabilidade do cliente, existem uma série de serviços e funções que compoem toda a segurança.
"A segurança na nuvem AWS é a maior prioridade. Como cliente AWS, você se beneficia de uma arquitetura de data center e rede criada para atender aos requisitos das organizações mais sensíveis à segurança." - Documentação oficial AWS
Vou começar pelo que considero a base de toda a segurança da aws.
Modelo de responsabilidade compartilhada.
O modelo de responsabilidade compartilhada é o fundamento de toda a estratégia de segurança da AWS. Aqui é definido claramente quais responsabilidades cabe a cada um.
➤ O que é responsabilidade da aws?
Enquanto estudava para tirar minha certificação aws cloud practitioner, coloquei na cabeça uma coisa, tudo o que eu não tenho acesso da nuvem, como datacenters, hardwares e infraestrutura… São consequentemente responsabilidade da aws.
E num panorama geral, acaba sendo isso mesmo, já que eles são responsáveis por:
- Hardware físico: servidores, storage, equipamentos de rede nos data centers
- Infraestrutura global: Regiões, Zonas de Disponibilidade e Pontos de Presença
- Software de virtualização: hipervisores e camadas de sistema operacional host
- Segurança física das instalações: controle de acesso, câmeras, perímetro físico
- Rede de backbone global: cabos, switches, roteadores da infraestrutura AWS
E uma coisa interessante que aprendi recentemente é que auditores terceirizados testam e verificam regularmente a eficácia de segurança da AWS como parte dos programas de conformidade, que visa garantir a transparência e confiabilidade.
➤ O que é responsabilidade do cliente?
Aqui eu poderia dizer… “A responsabilidade do cliente é inverso da aws”, mas a verdade é que não é tão óbvio assim. A responsabilidade do cliente é determinada pelo serviço que ele vai utilizar.
Vou usar uma Instância EC2 como exemplo, aqui o cliente assume a responsabilidade e gerenciamento do sistema operacional convidado, incluindo atualizações e patches de segurança, software e criptografia de dados do lado do servidor, e claro as configurações de firewall.
E aqui o porquê de eu ter dito que não era tão óbvio assim, em serviços como Amazon S3, DynamoDB e alguns outros, a aws ainda opera em algumas camadas, como a da infraestrutura e do sistema operacional. O cliente acessa os endpoints (que nada mais é que um endereço web para interagir com um serviço na nuvem) para armazenar e recuperar dados e consequentemente acaba sendo responsável por gerenciar seus dados, criptografia, classificar ativos e usar apropriadamente as permissões da aws.
Ou seja, tanto cliente quanto a AWS tem um papel de atuação fundamental para um bom design de segurança.
O que nos leva ao….
Gerenciamento de identidade e acesso IAM.
Apesar de não ser exatamente esta definição, veja que isso é uma visão pessoal, eu costumo "ver" o IAM como peça central para o controle sobre a segurança da sua conta e consequentemente negócio. Isso porque uma má configuração e definição de usuário em uma conta, representa não só um risco enorme, como é um dos principais problemas de falha de segurança. Porque é aqui onde você controla quem pode fazer o quê nos recursos da AWS.
O que nos leva ao pilar de segurança do AWS Well-Architected Framework que abordarei mais a frente no texto, que entre muitas outras coisas, exige a implementação de privilégio mínimo e separação de tarefas com sua respectiva autorização.
Eu não estou aqui para listar as funcionalidades do gerenciamento de acesso e sim para dizer como isso acaba sendo de fato, um ponto de segurança fundamental, aquele que não pode em nenhuma hipótese ser negligenciado. Seguido daquilo que você vai cansar de ouvir, que é: proteger as credenciais do usuário-raiz, usar somente para tarefas que exigem credenciais máximas para uma tarefa extremamente especifica que um Administrador com acesso máximo não é capaz de fazer, como excluir a conta ou mudar o plano de suporte, para qualquer coisa além disso, NÃO use a conta raiz.
Pode parecer um pouco exagerado, mas não é.
A AWS recomenda fortemente a adoção do Centro de Identidade do AWS IAM, para gerenciar centralmente identidades. Esse serviço permite integrar provedores de identidade corporativos como Okta, Active Directory ou Ping Identity, oferecendo aos usuários uma experiência de login único que sincroniza grupos e permissões. Trabalhando lado a lado com o MFA, que adiciona uma camada extra de proteção ao exigir uma segunda forma de verificação além da senha. Na prática, mesmo que alguém descubra ou roube suas credenciais, ainda precisará desse segundo fator para conseguir acessar a conta.
O princípio do menor privilégio é enfatizado como conceito fundamental em controle de acesso e medida preventiva contra acesso não autorizado e possíveis violações de dados. Credenciais excessivamente permissivas aumentam o escopo do impacto em caso de comprometimento.
Well-Architected Framework - Pilar de Segurança
O Well-Architected Framework formulou sete princípios de design de segurança que transformam orientações específicas em orientações práticas para fortalecer a segurança.
E esses pilares são:
- Implementar uma base sólida de identidade
- Habilitar a rastreabilidade
- Aplicar segurança em todas as camadas
- Automatizar as melhores práticas
- Proteger os dados em trânsito e em repouso
- Manter as pessoas afastadas dos dados
- Preparar-se para eventos de segurança
Proteção de dados
Antes de criar a arquitetura de qualquer carga de trabalho devem ser adotadas práticas fundamentais que influenciam a segurança. A classificação de dados fornece uma forma de categorizar os dados organizacionais com base nos níveis de sensibilidade, e a criptografia protege os dados tornando-os ininteligíveis ao acesso não autorizado.
➤ Criptografia em repouso
Criptografar dados privados em repouso mantém a confidencialidade e oferece uma camada adicional de proteção contra divulgação e exfiltração acidental. A criptografia protege os dados para que não possam ser lidos nem acessados sem serem descriptografados primeiro.
O AWS Key Management Service, ou só KMS, é o cofre que mantém essas chaves seguras. Ele armazena e gerencia chaves de forma centralizada e auditada. Um exemplo é que quando você criptografa um volume EBS, ou um objeto no S3, o KMS é responsável por guardar essa chave, e o IAM controla quem pode acessar essa chave de descriptografia. O que mostra ligeiramente, como os serviços e recursos se complementam aqui.
IAM controla quem acessa -> KMS controla quem descriptografa == Dados protegidos em duas camadas.
Porém, antes disso, é importante saber que nem todos os dados têm o mesmo nível de sensibilidade. Não se deve aplicar controles desproporcionais, isso pode gerar mais transtorno que segurança. Não faz sentido aplicar o mesmo nível de rigor a um nome público disponível em um cadastro simples e a informações como CPF, dados financeiros ou dados de saúde. Então chegamos a um serviço para isso, o Macie, que faz uma varredura em busca de dados sensíveis automaticamente em um S3.
A definição do que exige maior proteção é influenciada por leis, regulamentações e pelas próprias políticas da organização. No Brasil, a principal referência é a LGPD. Por isso, um profissional não só de cibersegurança, mas de toda a área que atua ativamente com dados, precisa conhecer muito bem essas leis e regulamentações.
Segurança da Rede
Chegamos a parte que mais tenho estudado atualmente. A segurança da rede.
A AWS oferece diversos serviços que atuam em camadas para proteger, isolar e controlar o tráfego. E o centro de tudo isso é o Amazon VPC.
➤ Amazon VPC
Uma Virtual Private Cloud ou só VPC nada mais é que uma rede virtual privada dentro da AWS. Ela é completamente isolada das outras contas. E dentro dela você consegue configurar as sub-redes, sejam elas públicas para acesso a internet e privadas para o que não deve ter contato com a internet.
E para controlar o tráfego, existem duas ferramentas importantíssimas.
- Grupos de segurança: Funcionam como um firewall a nível de instância. Você define quais portas e IPs podem se comunicar com o respectivo recurso.
- ACLs de rede: Aqui elas já funcionam no nível da sub-rede, elas permitem ou negam tráfego antes mesmo de chegar aos recursos.
Indo além, chegamos a outros dois serviços para complementação dessa parte da segurança.
- Web Application Firewall ou WAF: Ele é um firewall que vai filtrando as requisições HTTP maliciosas antes que elas cheguem a aplicação. É a principal linha de defesa de um SQL injection, XSS e até mesmo bots. Tem regras gerenciadas pela AWS que são frequentemente atualizadas automaticamente ao passo em que novas ameaças vão surgindo.
- AWS Shield advanced: Protege contra ataques DDoS, quando atacantes tentam derrubar um serviço enviando volumes altos de tráfego, o shield detecta e mitiga esses ataques automaticamente.
Um atenção aqui, não confunda com WAF de firewall com o WAF do Well-Architected framework, visto que ele também é abreviado assim em alguns cenários, mas o contexto tende a deixar claro.
Atente-se também que eu menciono o shield advanced, mas ele não é o único shield, além de que essa definição que usei é apenas uma simplificação.
Agora, precisamos ir além e enxergar o que passa na rede.
O VPC Flow Logs registra todo o tráfego de rede que entra e sai dos recursos VPC. Aqui você não impede o tráfego, mas tem o registro de tudo o que acontece, e aqui é o lugar onde você vai para investigar incidentes.
Seguindo por esse caminho, entramos em uma parte que eu particularmente gosto muito, que é o de monitoramento e detecção.
Nós sabemos que nenhum sistema é impenetrável, até porque se isso fosse verdade, o profissional de cibersegurança seria uma coisa completamente diferente do que é hoje.
É preciso detectar rapidamente quando algo está acontecendo, seja uma simples configuração incorreta, um comportamento suspeito ou acesso não autorizado. Para isso, existem serviços que trabalham juntos.
➤ Registrando tudo com CloudTrail e Cloudwatch
Como meu professor de AWS diz, “CloudTrail é o dedo duro”. Ele registra quem faz o quê, quando e onde, além de todas as chamadas de API. Se alguém alterar uma vírgula, ele registra. Ele é, ao meu ver, um dos pontos iniciais de qualquer investigação.
O Cloudwatch vem para complementar o CloudTrail, monitorando as métricas e logs em tempo real. Você pode configurar alarmes para ser notificado quando algo anormal acontece, inclusive eu tenho um pequeno projeto sobre isso no github. Que eu pretendo melhorar exponencialmente nas próximas semanas, já que ele foi um projeto que iniciei para ter uma visão melhor sobre o que eu estava estudando.
➤ Detecção inteligente
O GuardDuty analisa automaticamente o CloudTrail, os logs de DNS e o VPC Flow logs, usando machine learning e inteligência de ameaças para identificar comportamentos suspeitos. E eu não estou limitando aqui a comportamentos de “um ip fazendo requisições suspeitas”, aqui vai além, como em uma instância EC2 consultando DNS em domínios conhecidos por malware, ou até mesmo um usuário que começa a acessar ou baixar conteúdo em uma região diferente da habitual.
Esse serviço sem dúvidas é um dos primeiros da minha lista do que mais quero me aprofundar em breve. Por enquanto tem sido apenas teoria.
➤ Avaliando as vulnerabilidades
Aqui mais um pra minha lista de estudos mais aprofundados para os próximos dias, o Amazon Inspector.
Ele examina continuamente as instâncias EC2, imagens de contêiner e até funções lambda em busca de vulnerabilidades conhecidas, as CVEs. Com isso, ele mantém um banco de dados atualizado de vulnerabilidades e se detectar qualquer exposição aos recursos, ele gera um alerta.
Aqui temos vários serviços funcionando e gerando alertas, é preciso centralizar isso de alguma forma, certo? Para isso serve o AWS Security Hub. Ele agrega tudo em um único painel. Priorizando alertas, e com isso, mostra quais são os mais críticos e ainda verifica se boas práticas estão sendo implementadas na segurança.
Até porque não adianta nada uma variedade de serviços a disposição, se nenhum deles é configurado corretamente ou o usuário simplesmente não habilita algo tão simples e necessário quanto MFA.
➤ Como tudo se conecta
Até aqui, coloquei tudo separadamente. Mas algo que tentei deixar claro no meu texto e espero ter conseguido, é como os serviços e recursos se integram e criam uma força de segurança.
- Temos um usuário chamado “userMalicioso” que tenta acessar um banco de dados muito importante para uma organização.
- O IAM verifica se o userMalicioso tem a permissão de acessar esse Banco de Dados - Ele verifica então que o userMalicioso não tem permissão - ele nega o acesso.
- Já o user dev tem acesso mínimo, ele pode ler os arquivos do Banco de Dados, o IAM checa e encontra a permissão de leitura, o dev pode então ler o arquivo necessário para seguir com sua função.
- Os dados desse Banco de Dados estão criptografados pelo KMS. mesmo que o userMalicioso invada o Banco de Dados diretamente, ele não consegue ler nada sem a chave.
- Toda a comunicação está passando pela VPC, os grupos de segurança estão restringindo onde o tráfego pode ir e vir.
- O cloudtrail está registrando esses acessos, seja do userMalicioso ou do dev, o cloudwatch está monitorando os comportamentos em tempo real, ele poderá detectar o userMalicioso, e o Security Hub está centralizando o alerta.
Escrever essa parte foi muito interessante, foi como se eu pudesse visualizar minhas palavras. Mas sinto que consegui isso por já ter feito alguns laboratórios práticos de segurança dentro da AWS.
Você pode ter notado que este meu texto não está completo, não só porque preciso me aprofundar mais em alguns serviços e na própria governança em si, mas porque tenho plena consciência que tudo o que eu escrevi até aqui é uma ponta de Iceberg quando o assunto é segurança. Inclusive, acho que não abordei quase nada do que a AWS tem a oferecer, até porque só o manual do IAM tem mais de 3000 páginas explicando o serviço, as políticas detalhadamente e muito mais. Então, imagine só todos os outros serviços e recursos? Sim, é um caminho, mas um caminho que tenho me animado muito em seguir.
Principalmente levando em conta que a cibersegurança, independente de ser na AWS ou fora dela, é uma prática contínua de não só configurar bem, mas monitorar constantemente e melhorar sempre. Não é só executar ferramentas. É entender o que elas fazem, como foram construídas e por que existem.
Tendo em vista que nenhum sistema é impenetrável, tenho um longo caminho pela frente.
Fique a vontade para apontar qualquer erro no meu texto. Estou trilhando meu caminho nos estudos e qualquer apontamento é sempre bem vindo!
Referências
➤ Modelo de responsabilidade compartilhada
➤ Fundamentos de Segurança AWS
➤ Pilar de segurança do Well-Architected
