Security Essentials

Segurança e conformidade constituem uma responsabilidade compartilhada entre a AWS e o cliente. Seguindo esse modelo compartilhado, os clientes podem reduzir a carga operacional, pois a AWS assume a responsabilidade de operar, gerenciar e controlar os componentes "da nuvem". Isso permite que os clientes se concentrem em criar suas aplicações e implementar os serviços, ao mesmo tempo em que assumem a responsabilidade de proteger esses serviços "na nuvem". Saiba mais sobre o modelo de responsabilidade compartilhada.

Ao criar uma conta da AWS, você começa com o que é conhecido como usuário raiz. Esse é o primeiro usuário que existe em sua conta da AWS. A AWS recomenda que você não use essa conta para operações diárias, pois ela tem acesso e controle totais da conta e deve seguir as práticas recomendadas para proteger o usuário raiz. Isso inclui bloquear as chaves de acesso do usuário raiz, usar uma senha forte, ativar a autenticação multifator da AWS e criar um usuário do IAM para acessar a conta. Essa conta pode ter privilégios de administrador e deve ser usada para todas as tarefas administrativas futuras.

Em seguida, você deve atribuir contatos de segurança alternativos à sua conta. O contato alternativo de segurança receberá notificações relacionadas à segurança, incluindo notificações da equipe de confiança e segurança da AWS. Você pode aprender mais sobre a importância de definir essas informações de contato logo no início da configuração da sua conta, na postagem do blog Atualize o contato de segurança alternativo em suas contas da AWS para receber notificações de segurança pontuais.

Depois de confirmar seus contatos de segurança, você deve considerar as regiões da AWS em que suas workloads devem ser executadas e as regiões onde elas não devem ser executadas. Em seguida, você pode bloquear as regiões não utilizadas para garantir que nenhuma workload possa ser executada nessas regiões. Embora isso ajude na otimização de custos, também se presta à segurança. Como assim? Ao bloquear as regiões nas quais você não espera executar workloads, você pode concentrar seus esforços de monitoramento nas regiões que usa ativamente.

Até aqui, você protegeu o usuário raiz, criou um ou mais usuários do IAM, atribuiu contatos de segurança e bloqueou as regiões nas quais as workloads podem ser executadas. Em seguida, vamos considerar como os usuários interagirão com os recursos da AWS. Há dois métodos principais de interação: a AWS CLI e o Console de Gerenciamento da AWS. É recomendável configurar um login único para a AWS CLI e o console. Consulte o artigo Configurar a AWS CLI para usar o Centro de Identidade do AWS IAM (sucessor do AWS Single Sign-On) para obter detalhes sobre como gerenciar centralmente o acesso com o Centro de Identidade do AWS IAM.

A próxima etapa para proteger sua conta é configurar os grupos de usuários do AWS IAM para controlar o acesso. Em vez de controlar o acesso de usuários individuais definindo políticas diretamente no usuário, é melhor criar um grupo, atribuir as permissões necessárias a ele e, em seguida, atribuir usuários ao grupo. Os usuários herdarão as permissões desse grupo. Isso oferece uma maneira mais escalável de fornecer controle de acesso a muitos usuários. É importante entender o IAM e os grupos do IAM porque eles abrangem vários serviços. O IAM é um serviço que interage de alguma forma com todos os serviços da AWS, então não deixe de se familiarizar com ele.

A adoção dessas práticas desde o início ajudará a fornecer acesso seguro aos recursos da AWS. A seguir, discutiremos como proteger a infraestrutura que você constrói na AWS.

A infraestrutura que você cria geralmente é ignorada, pois faz parte da arquitetura subjacente e não é voltada para o cliente. No entanto, se essa infraestrutura falhar, os serviços que você fornece aos seus clientes falharão. Por esse motivo, é fundamental que a infraestrutura esteja protegida desde o primeiro dia.

Ao criar sua infraestrutura de nuvem, você começará criando uma Amazon Virtual Private Cloud (Amazon VPC). Essa é uma rede virtual que você define (uma rede padrão é criada em cada região quando você cria sua conta) que permite iniciar os recursos. Uma VPC se assemelha a uma rede tradicional, pois tem um intervalo de endereços IP CIDR atribuído a ela e é subdividida pela criação de sub-redes. As sub-redes podem ser usadas para fornecer isolamento para diferentes conjuntos de recursos. As sub-redes podem ser públicas ou privadas. As sub-redes públicas têm uma rota para um gateway da Internet, têm acesso à Internet por meio desse gateway e podem ser acessadas pela Internet se os controles de acesso relevantes permitirem. As sub-redes privadas também têm uma tabela de roteamento, mas não têm uma rota para um gateway da Internet. Por padrão, essas redes não podem acessar a Internet e não podem ser acessadas pela Internet. Para permitir que recursos em uma sub-rede privada acessem a Internet, é necessário um gateway NAT. No nível da sub-rede, uma lista de controle de acesso à rede (ACL) permite ou recusa o tráfego específico de entrada ou saída. Você pode usar a ACL de rede padrão para a VPC ou criar uma ACL de rede personalizada para sua VPC. As ACLs de rede são listas numeradas, processadas em ordem decrescente e não têm estado. Isso significa que você precisará de uma regra de ACL de rede de entrada e saída para permitir o tráfego bidirecional.

Ao implantar recursos do EC2 em sua VPC, você associará um grupo de segurança a eles. Um grupo de segurança controla o tráfego de entrada e saída que pode alcançar os recursos do EC2. Os grupos de segurança são semelhantes a um firewall, mas em vez de usar apenas uma lista ou um intervalo de endereços IP, eles podem apontar para uma referência de recurso. Uma referência de recurso é um grupo nomeado que mantém uma lista atualizada de endereços IP atribuídos a cada recurso do grupo. Por exemplo, se você criar um grupo de escalonamento automático para gerar instâncias do Amazon EC2, cada instância receberá um novo IP quando for inicializada. Ao adicionar um grupo de segurança a essas instâncias, você pode conceder acesso ao grupo de segurança do seu servidor de banco de dados por meio do ID do grupo de segurança das instâncias do EC2, e qualquer nova instância do EC2 lançada terá acesso ao banco de dados sem precisar adicionar seu endereço IP à lista permitida.

As regras do grupo de segurança são semelhantes às ACLs de rede porque, ao criá-las, você combina a porta, o protocolo e os endereços, porém elas têm estado reconhecido. Você pode considerá-las semelhantes a um firewall com estado. Quando você cria uma entrada para permitir um tipo específico de tráfego, não é necessário criar uma regra que corresponda ao tráfego de retorno. Como ela tem estado, o tráfego de retorno será permitido. Para entender melhor como os grupos de segurança e as ACLs interagem, essa comparação é útil.

Para adicionar uma camada adicional de segurança à infraestrutura, você pode implantar o AWS Network Firewall. O Network Firewall é um serviço gerenciado que implanta proteção para o Amazon VPC. Ele fornece proteção mais refinada do que os grupos de segurança, porque pode incorporar o contexto de fluxos de tráfego, como conexões de rastreamento e identificação de protocolos, para aplicar políticas como prevenção de acesso a domínios por suas VPCs por meio de um protocolo não autorizado. Isso é feito por meio da configuração de regras do Suricata personalizadas. Por exemplo, você pode configurar o Network Firewall para se proteger contra ataques de malware. Avançando um pouco mais, você pode implantar outro serviço gerenciado, o AWS Shield Avançado, para se proteger contra ameaças de DDoS.

Os clientes armazenam uma grande quantidade de dados na Nuvem AWS. Esses dados contêm informações essenciais para a operação de uma organização. Isso inclui dados de clientes, propriedade intelectual, pedidos vinculados diretamente à receita e muito mais. Nesta seção, compartilhamos os fundamentos sobre como configurar dados armazenados na AWS, bem como dados que são transferidos pela rede pela AWS.

Na AWS, os dados são armazenados no Amazon S3, que tem vários controles para proteger os dados. O artigo As 10 melhores práticas de segurança para proteger dados no Amazon S3 aborda as técnicas mais fundamentais. Isso inclui o bloqueio de buckets públicos do S3 no nível da organização, o uso de políticas de bucket para verificar se todo o acesso concedido é restrito e específico e a criptografia e proteção de dados.

Para criptografia, o AWS Key Management Service (AWS KMS) permite criar e controlar chaves usadas para criptografar ou assinar digitalmente os dados. Se você quiser criptografar seus dados na AWS, você tem algumas opções. A primeira é usar uma criptografia do lado do servidor com chaves de criptografia gerenciadas pelo Amazon S3 (SSE-S3) Usando esse método, a criptografia acontece depois que os dados são enviados para a AWS usando chaves gerenciadas pela AWS.

A segunda opção é criptografar os dados quando estiverem na AWS, mas em vez de usar as chaves criadas e gerenciadas pela AWS, você pode realizar a criptografia no lado do servidor com chaves mestras do cliente (CMKs) armazenadas no AWS KMS (SSE-KMS).

A terceira opção para armazenar os dados criptografados na AWS é usar a criptografia do lado do cliente. Com essa abordagem, os dados são criptografados antes de serem transferidos para a AWS.

Um exemplo de como a criptografia do lado do cliente e a criptografia do lado do servidor beneficiam os clientes pode ser visto na imagem a seguir.

As VPNs podem abranger várias tecnologias. A ideia por trás de uma VPN é que seus dados em trânsito mantenham sua integridade e possam ser trocados com segurança entre as duas partes. A AWS oferece várias tecnologias que ajudam a manter seus dados em trânsito seguros. Uma delas é o AWS PrivateLink, que fornece conectividade criptografada e privada entre VPCs, serviços da AWS e as redes on-premises. Isso é feito sem expor seu tráfego à Internet pública. Isso também pode ser considerado uma rede privada virtual.

No entanto, na maioria dos casos, uma discussão sobre VPN gira em torno do uso da criptografia de dados. Dependendo das circunstâncias, talvez seja necessário fornecer criptografia entre um cliente e seus recursos da Nuvem AWS. Essa situação exigiria o AWS Client VPN. Por outro lado, você pode estar passando dados entre o datacenter ou filial e seus recursos da AWS. Você pode fazer isso usando túneis IPsec entre os recursos on-premises e as Amazon VPCs ou AWS Transit Gateway. Essa conectividade segura é conhecida como VPN Site-to-Site (VPN de local a local).

Por fim, o gerenciamento dos recursos de nuvem usando o Console de Gerenciamento da AWS também oferece dados criptografados em trânsito. Embora você normalmente não se refira à conectividade com o console como uma VPN, sua sessão usa a criptografia TLS (Transport Layer Security). Assim, suas configurações são mantidas em sigilo à medida que você cria sua arquitetura segura. O TLS também é usado com a API da AWS.

A AWS oferece vários serviços gerenciados para auxiliar no monitoramento do seu ambiente, além de opções de autoatendimento. Por exemplo, você pode usar o VPC Flow Logs para registrar e visualizar os fluxos de tráfego da rede ou o Amazon CloudWatch para analisar os logs do AWS WAF, ou até mesmo para criar alarmes para as instâncias do EC2. Saiba mais sobre o Amazon CloudWatch neste workshop.

O AWS CloudTrail monitora e registra a atividade da conta por toda a infraestrutura da AWS, oferecendo controle sobre o armazenamento, análise e ações de remediação. Isso é essencial para criar uma trilha de auditoria administrativa, identificar incidentes de segurança e solucionar problemas operacionais.

Por fim, o Amazon GuardDuty pode ser usado para detectar ameaças e até mesmo para dar um passo adiante, permitindo que as descobertas publicadas iniciem ações de remediação automática no seu ambiente da AWS.

Ao abordar cada uma dessas áreas operacionais, você estará no caminho certo para estabelecer recursos de segurança essenciais para seu ambiente de nuvem.