Well-Architected Framework – Security Pillar – Parte 1

Olá, pessoal. Tudo bem?

Hoje vamos falar um pouco mais sobre o Well-Architected Framework. O assunto deste e do próximo post da série será o pilar de segurança.

Ainda hoje, muitas empresas consideram segurança da informação como secundária, e só vão dar o real valor quando o pior acontece. Ameaças, como o vazamento de informações, podem destruir com a reputação de uma empresa. Este pilar traz algumas estratégias simples que, se bem adotadas, reduzem consideravelmente problemas futuros.

Princípios de design

  • Implementar uma base forte de identidade: Para manter a infraestrutura segura, é extremamente importante termos controle sobre os usuários e serviços que podem acessá-la, e o que podem executar dentro dela. Sempre que possível, devemos manter a estratégia de privilégio mínimo, permitindo que os usuários executem as tarefas necessárias, dentro das suas responsabilidades atribuídas;
  • Implementar segurança em todas as camadas: Para dificultar qualquer tentativa de acesso não autorizado, é importante termos todas as camadas de nossa arquitetura protegida. Desde a borda da rede até a aplicação que está executando no servidor;
  • Habilitar o rastreamento: É extremamente importante podermos rastrear toda e qualquer atualização efetuada em nosso ambiente. Um excelente caminho é possibilitar o monitoramento de métricas e logs, para que ações possam ser tomadas em tempo real (utilizando automação);
  • Automatizar as melhores práticas de segurança: Como citado no item acima, é importante definirmos artefatos autômatos para garantir que o nosso ambiente responda à eventos o mais rápido possível, permitindo que atualizações no workload sejam feitas de forma segura;
  • Proteger dados em trânsito e em repouso: Outro aspecto importante é a segurança dos dados armazenados e que trafegam no ambiente de nuvem. Estratégias de criptografia e gerência de acesso devem ser aplicadas;
  • Manter as pessoas longe dos dados: Evitar que pessoas tenham acesso direto aos dados também é importante, principalmente para evitar perda de dados e erro humano;
  • Preparar-se para eventos de segurança: Eventos de segurança eventualmente irão acontecer, então é muito importante estar preparado. Para isso devemos definir processos e utilizar ferramentas que auxiliem na detecção, investigação e mitigação destes eventos.

O pilar de segurança é composto por cinco áreas específicas, tendo como base os princípios citados. Cada área define práticas e ferramentas para tratarmos um aspecto diferente a ser otimizado. Abaixo (e no próximo post da série) falaremos um pouco sobre cada uma delas.

Gerenciamento de identidade e acesso

O gerenciamento de identidade e acessa na AWS é efetuado através do IAM (Identity and Access Management). No IAM podemos definir grupos, politicas, funções entre outros artefatos que flexibilizam bastante esse gerenciamento.

Um dos primeiros pontos que devemos observar quando criamos uma conta na AWS é o usuário raiz. Este usuário tem autonomia total sobre a conta, podendo, inclusive, removê-la. Por ser um usuário chave, o mesmo deve ser extremamente seguro. Uma das boas práticas que devemos seguir é nunca usá-lo em tarefas diárias, mas apenas para criar outro usuário administrador no IAM, que será utilizado para as tarefas de gerenciamento da conta. Também devemos remover todas as chaves de acesso deste usuário, pois muitas vezes as críamos para fazer algum tipo de implantação utilizando o AWS CLI (Command Line Interface).

Outro aspecto importante é utilizarmos MFA (Multi-Factor Authentication), para adicionarmos mais um nível de segurança no acesso aos usuários criados no IAM, e principalmente (obrigatório!) ao usuário raiz.

É importante também utilizarmos politicas fortes para gerenciamento de senhas, como definir uma complexidade mínima, um tamanho mínimo, composição de caracteres e uma expiração para as senhas, fazendo com que os usuários atualizem periodicamente.

Em relação ao armazenamento de chaves de acesso, devemos tomar alguns cuidados, como armazená-las em local seguro, evitar salvá-las em algum VCS (Version Control System) e, sempre que possível, substituí-las por chaves temporárias.

Caso tenhamos mais de uma conta na AWS, podemos utilizar o AWS Organizations, que permite o agrupamento destas contas em árvore e a aplicação de politicas de controle de serviço, ou SCP (Service Control Policy). As SCPs podem ser aplicadas a um nodo superior na árvore do AWS Organizations, e essas politicas são aplicadas a todas as contas filhas.

AWS Organizations – Concepts

Controles detetives

Controles detetives são ferramentas que podemos utilizar para auxiliar na detecção, prevenção e mitigação de ameaças, bem como em políticas de governança e compliance. Algumas das principais ferramentas na AWS são:

  • CloudTrail: é uma das ferramentas mais importante neste aspecto, pois permite que façamos auditorias sobre qualquer chamada de API que ocorra em nossa infraestrutura. Podemos ativar ele em todas as regiões da AWS e concentrar os logs no S3;
  • CloudWatch: Outra ferramenta extremamente importante. O CloudWatch permite a extração de logs e métricas de quase todos os serviços gerenciados da AWS, das instâncias EC2, além de permitir a integração com a nossa aplicação;
  • Guard Duty: O Guard Duty é uma ferramenta que avalia continuamente os logs de DNS, logs de fluxo de VPC e o Cloud Trail. Utilizando estas informações e algumas estratégias de machine learning, ele auxilia na identificação e mitigação de ameaças;
  • AWS Config: Fornece informações sobre os recursos existentes no ambiente, permitindo a auditoria de configurações e validação das mesmas, com base em configurações padrões preestabelecidas;
  • Amazon Inspector:  O Amazon Inspector avalia as aplicações publicadas na AWS fornecendo informações sobre possíveis vulnerabilidades.

É importante ressaltar que não basta armazenarmos logs e métricas, pois se não observarmos ativamente as mesmas, com certeza não teremos assertividade na identificação e mitigação de ameaças. Por isso devemos integrar os eventos de segurança fornecidos pelas ferramentas citadas (como os eventos do CloudWatch ou as regras do AWS Config) em nossos serviços de notificações e ferramentas de fluxo de trabalho, para torná-los evidentes. Devemos também utilizar estes eventos como parte de workflows automatizados, responsáveis por eliminar ameaças e manter a consistência das configurações de segurança, sempre que possível.

Continua….

No próximo post da série, vamos falar sobre as demais áreas deste pilar: proteção da infraestrutura, proteção dos dados e resposta a incidentes.

Um grande abraço e até a próxima!



Postado em AWS

2 comentários sobre “Well-Architected Framework – Security Pillar – Parte 1

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s